[J-core] Jcore mailing list and tutrle board

David Summers jcore at davidjohnsummers.uk
Thu Jul 6 16:12:56 EDT 2017


I'll just reply to the bits that aren't covered in conversation with 
Jeff ...

On 05/07/17 21:58, Rob Landley wrote:
>> 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
Well ITAR is your side of the pond, not ours! My undesratdning though is 
that ITAR is typicaly attached to devices, and not alogoriths. So if we 
take a SECDED algorthm such as Hamming[8,4], I think its just the chip 
that impliments the algrothm that gets ITAR - and not the Hamming[8,4] 

Whats kind of interesting, is ITAR is one of the motivations behind 
ESA/Gaisler to do a VHDL of SPARC-V8 ISA. Here in europe we had 
relativlt few fault toleant CPUs that were avaiable, ERC32, and there 
was one other whose name slips me now.

Now fault tollerant cpu can typically survive one bit flip, and correct 
it. It means its technology that can be used in ICBMs - so fault 
tollerant cpus from US typically do have ITAR. and ITAR is far more 
paper work than is fun going through.

So ESA developed the LEON, the SPARC-V8 open CPU design; Gaisler 
continued the development, to several fault tollerant designs (majority 
voting flip flops etc). This means we have reasonable poerful flight 
CPUs avaible here in Europe.

But there it took space flight to develop an open CPU; so it amuses me 
that at least some of your motivation is CPU for synchrophasors. So two 
open cpu designs, but with motivation from opposite ends of the 

> ..
> 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...
well openocd is 10 years or so old. However yes its iterface is 
horrible. So last time I used it (few years ago) it wasn't nice.

Speed, well jtag its the prgrammer that sets the speed. need to make 
sure its not too fast, as the device may not cope. But this means the 
default speed in openocd is often quiet slow, as then you can check you 
can talk to the device. Once you can talk though - you can up the speed, 
at least until things start falling over ...
>>> 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.
Understood. Yes different user case.
>> 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".
Yes - and its understanding the different levels that is needed.

That is both the stength of jtag, but also what makes it a nightmare to use.
>> 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...
DRAM init I agree isn't fun! Its why computers have BIOS, so the BIOS 
does the hard stuff like DRAM init.

At work, we had one board we couldn't get working with dram, so it had a 
*whole* board of SRAM - just so we could get it to come up ...

Anyway JTAG is a bit like using a puppet, and you try kniting using a 
>> 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.
Far enough.

Thanks for the reply.



More information about the J-core mailing list