[J-core] Jcore mailing list and tutrle board

[Rob Landley]

>> You mind if I cc: the reply to the rest of your email to the list?
>>
>> Rob
>
> Yes good idea to cc reply to rest in the email list - then jeff gets
> to see - and saves me re typing the email!
>
> Actually thinking about it - wonder if the atmel chip is wired upto
> the jtag pins, and thats how it copies the bitsteam from flash to the
> ram in the FPGA.
>
> Regards,
>
> David.

And thus:

On 07/04/2017 02:30 PM, David Summers wrote:
> On 04/07/17 09:35, Rob Landley wrote:
>> On 07/03/2017 02:41 PM, David Summers wrote:
>>> Hi Rob,
...
>>> Anyway, you probably know the answer to what I was planning to ask
>>> anyway. Why on the turtle boards did you fix on the Spartan FPGA? The
>>> newer Artix is similar price and newer, e.g.:
>>>
>>> https://shop.trenz-electronic.de/en/TE0725-03-100-2C-FPGA-Module-with-Xilinx-Artix-7-XC7A100T-2CSG324C-2-x-50-Pin-with-2.54-mm-pitch
>>>
>>> a 100k gate FPGA for just over a $100.
>>
>> This is really a Jeff question, but my understanding is that's only true
>> in higher volumes. Spartan 6 is available cheap in lower volumes.
> I'll ask Jeff when I sign up ;)
> 
> But yes, you answer would make sense, Spartan 6  is end of line - so
> Xilinx may well be happing moving just what they have left.

Last I heard they're still making them, they're cheap, they work, and
they're what we did the majority of testing on when designing the chip.
(We've recently moved some stuff to Kintex 7, but that's way more
expensive.)

> I expect the line to be dropped soon.

If xilinx stops selling the chips we're using, we'll move to something
else. Might even be another xilinx chip, who knows? :)

> Artix7 is now what they say is the cheap FPGA -
> although they do a Spartan 7, which I'm not sure who its aimed at!

(I don't have a dog in this fight. I vaguely recall it involves moving
to a new software toolchain that threw some crazy internal error the
first time we tried to use it, but closed source toolchains are
notoriously crappy. We've had to work around the webice thing
segfaulting too. Part of the motivation for trying to get an open source
toolchain working is so we can _fix_ the darn thing when we break it.)

> Alas here at work, we go for the high end stuff; and often anti fuse
> FPGA - such is the space industry...

We talked about adding SECDED to our DRAM controller last year, but
current customers don't need it. And ITAR means all the US space guys
are read-only consumers of open source and thus developers in Canada and
Japan never hear from them. Oh well.

http://www.thespacereview.com/article/528/1
https://en.wikipedia.org/wiki/International_Traffic_in_Arms_Regulations#Effects_on_the_U.S._space_industry

>>> Rather than the usb to write the bitstream did you think of using jtag?
>>> E.g. adding FTDI FT232H chip, you could have attached to the jtag pins,
>>> and have the other end on usb which say openocd can access. With the
>>> jtag you should be able to both write the bitsteam, but also do a
>>> boundary scan when the j-core has been written to the device?
>
>> This is also really a Jeff question, but:
>
> Another question to ask when I get online;)
>
>> A) Even if it was jtag we'd still be using USB to write the bitstream?
>> (Or did you think we should connect a jtag riser to the gpio pins
>> somehow?)
>
> Yes - the FT232H chip is a very fast USB 2. So yes you still use USB to
> talk to it.  The Artix has JTAG pins, directly - so can just wire up to
> then. I *expect* spartan is the same - its the usual way to write FPGAs.
> I'm not sure if once programed, if you can reused the JTAG pins - I
> suspect not, but would have to ask someone at work.

As I said, a Jeff question. (Or Martin, or maybe Jen...)

>> B) Using jtag to write the bitstream would be about an order of
>> magnitude slower than this programmer.
>
> Yes again would have to ask at work, know that the JTAG programmers
> there are fast - (but also $$$$). The FT232H is a *very* fast USB
> device, so although it has to talk JTAG, I'd be surprised if it was very
> slow. AT work it take *far* longer turning VHDL into a bitsteam - even
> with the fast computers ...

Last I tried using OpenOCD to flash something on a regular basis (the
Tin Can Tools nail board), using the fully open source drivers was
_really_slow_. I mean amazingly slow. There was a binary-only module you
could use to speed it up, but even then it was still pretty darn slow.

*shrug* Maybe it's improved since then...

>> C) Requiring openocd setup as a hard prerequisite would probably
>> eliminate about 2/3 of our userbase. (That's why things like Numato
>> don't. Nor does our in-house EVB because customers wouldn't do it.)
>
> Ah - must admit I started using it becuase it is open! So anyone can
> download it. Horrible interface though, but then again when doing JTAG -
> one shouldn't expect it to be easy ;)

We don't expect jtag to be easy. We do expect using our board to be
easy. That's why we made an easy way to reflash the board.

> Suprised though that not used in-house. Here its the first thing we go
> to - means that a chip that is otherwise dead, can be reprogrammed.

We have an atmel boot processor that can reprogram a chip that is
otherwise dead. Built in.

Keep in mind we have _3_ levels of jtag todo items. There's "jtag talks
to board hardware at xilinx/flash level", "jtag talks to j-core SOC",
and "gdb can single-step our processor using upstream vanilla gdb source".

> I've
> a router I'm hacking, and when the flash doesn't boot - JTAG is the only
> way in ... (just to bring a MIPS AR7 to life again ...)

Which is why we put an atmel boot processor on the board you can use to
recover the thing, so you _can't_ brick it.

>> D) I've been poking Jeff for an openocd config for our boards for years,
>> but he uses some other open source jtag program, I forget which one
>> because I've never installed it. (Works better on a mac or something.)
>> So if you did get jtag, you'd have to install that other program or port
>> it to openocd yourself.
>
> Does Jeff use open source, or something bought?

It's an open source one. I just don't remember the name of it.

> In work we always buy
> what FPGA say you use, which again is $$$$. open jtag is something new,
> so little software out there -

I first learned to use openocd for the Tin Can Tools "nail board"
something like a decade ago. It's not that new. :)

What it _isn't_ is particularly interesting to a large number of
developers. OpenOCD is fiddly and has a terrible user interface, and
despite sitting down and trying to learn how to get it to workwith a
brand new board 3 times, I've only ever gotten it to do anything when
somebody ELSE gave me a config file for the board I'm using. (And when
the hardware guys didn't do that, I'm stuck with whatever FPGA tool
they've set up. I did get it to work when a chip got moved on the board
and I just had to adjust the stop numbers once, though.)

I think the main problem is everybody tries to do DRAM init
_through_the_jtag_, which is black magic at a level you really don't
want to get on you if you can avoid it. Boards with buckets of SRAM are
easier to bring up, but then you need dedicated multi-stage bootloaders
with relocation code and you've basically added a second layer of mess...

> and not much call as people doing FPGA
> unless professionals (where  time is $$, so $$$$ for software is a win).

We're trying to bring FPGA stuff to hobbyists. An atmel boot processor
that flashes the thing from a file on the sd card so you don't _have_ to
master a jtag before you can update your FPGA image was considered a win.

> last time I looked openocd seemed the only reasonable set up that was
> open. But yes, doing a config for AR7 was a hassle.

Jeff's been living in Japan for over a decade, and is familiar with
rather a lot of software that's never had an english translation of its
web page. :)

He's also a fan of a taiwanese RTOS layer for Linux that's a similar
"quite nice but nobody in this hemisphere's heard of it" thing. I don't
remember its name either but I remember I keep thinking it's a modern
rewrite of adeos, and _that_ name I can search my back email for, thus
finding:

http://events.linuxfoundation.org/sites/events/files/slides/rtmux_1.pdf
https://github.com/rtmux

Searching my back email for openocd didn't bring up the thing that's not
openocd, though. Mostly it's threads about debugging GDB integration for
superh...

Rob