[J-core] Route to J1: Was: Re: Jcore mailing list and tutrle board

[David Summers]

Hi Rob,

What would be the reason for J1 to go via ice40 rather than direct to asic?

Yes cost is an issue, development though you could do on your current 
boards.

So ice40 vs asic only come up during production of devices. When going 
into production only reason to go for ice40 is if the market is small 
enough to not justify an asic.

I'd have though the choice was between going into production of j1, vs 
the arm route of letting 3rd parties use the j1 design in their own 
chips, for own needs.

Out of interest, what else would be stripped from J2 to make J1, I think 
we have so far:

  * Hardware multiply, etc (or rather doing multiply in one clock)
  * DRAM controller

Is anything else descoped?

David.


On 08/07/17 22:17, Rob Landley wrote:
> That ice40 stuff we were trying to get nvc to target to run j1 on is all
> sram. (When we say 'arduino country' that implies no dram controller.)
> And a lot of chips have a bunch of onboard sram even when they do have
> dram, so you can do your dram init from software. (Or NOR flash if you
> don't care about speed.) Heck, for years the reason you couldn't run
> u-boot under qemu is they refused to let you configure it NOT to do DRAM
> init, and although people eventually hacked their way around Wolfgang's
> persistent refusal/incomprehension:
>
> https://balau82.wordpress.com/2010/04/12/booting-linux-with-u-boot-on-qemu-arm/
>
> They still updated the u-boot FAQ entry saying "no, clearly not doing
> this is impossible because reasons, what's a QEMU?"
>
> https://www.denx.de/wiki/DULG/CanUBootBeConfiguredSuchThatItCanBeStartedInRAM
>
> As for j-core, we got dram init working long ago (there was an on-chip
> xilinx dram controller, then we wrote our own VHDL dram controller, then
> we wrote a_better_  one to replace the firs tone). So sure our designs
> have dram. Of course using it requires instantiating the j-core SOC on
> the board and running the boot ROM, which once again means your jtag is
> only useful in certain contexts unless you want to do a whole lot more
> work making it useful via duplicate infrastructure...


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.j-core.org/pipermail/j-core/attachments/20170712/3501feca/attachment.html>