[J-core] Route to J1: Was: Re: Jcore mailing list and tutrle board
D. Jeff Dionne
jeff at SE-Instruments.co.jp
Wed Jul 12 09:29:08 EDT 2017
On Jul 12, 2017, at 22:12, David Summers <jcore at davidjohnsummers.uk> wrote:
> Hi Rob,
> What would be the reason for J1 to go via ice40 rather than direct to asic?
I don’t think there is any pressing reason for J1 in ASIC. The multiplier is perhaps 5000gates, the J2 is about 27.5k gates, and only 0.45mm^2 in 152nm. In a main stream 2017 process like 65nm, the thing is trivial size. We have no reason to make J-Core smaller for ASIC, at the moment… the memories for a practical ASIC dominate.
> Yes cost is an issue, development though you could do on your current boards.
Well, we do...
> 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.
No, I think ICE40 is useful because it is cheap (one chip to stock) and more importantly it can become anything you want it to. ICE40 is a good replacement for low cost AVR and PIC processors, if you have an SoC platform you can program it with. We see it that way.
> 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.
You can do that with J2, I’m not sure J1 makes a large difference for an ASIC design.
> 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)
Likely, you add microcode to do shift and add.
> • DRAM controller
This isn’t ‘part’ of J2. The SoC platform can already be configured with anything you want (more than one DDR controller, or none, for instance).
> Is anything else descoped?
I think it is a repackaging of the IP. J1 would benefit from combining the I and D busses at the processor, for instance. J2 has them separate. Likely, we drop the co-processor interface. The microcode could be changed to be SH1 instruction set, but the benefit is fairly small (I estimate maybe 2k gates).
With all that changed, you can likely get to 18k gates, and one set of busses. That saves something like 0.19mm^2 in 180nm technology. That is pretty small savings. Maybe that is worth it, depending on what you’re doing? In ICE40, it is the difference between something that barely fits and something you can do your own project with.
> 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:
>> They still updated the u-boot FAQ entry saying "no, clearly not doing
>> this is impossible because reasons, what's a QEMU?"
>> 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
>> 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...
> J-core mailing list
> J-core at lists.j-core.org
More information about the J-core