[J-core] Porting J1 to LiteX

[Rob Landley]

On 6/15/21 2:15 AM, William D. Jones wrote:
> Hi Jeff,
> 
> Good to hear from you again!
> 
>  > But does it fit reasonably?  I had found that J1 was impractical in 
> HX, and so did not investigate further.
> 
> I guess it depends on what you mean by "reasonably"- LUT usage or RAM usage.
> 
> The entire SoC uses ~5300 LUTs on HX8K vs ~4300 LUTs on UP5K. This 
> leaves room for some peripherals like LEDs, GPIO, and UART, XIP from SPI 
> flash, and cache.
> 
> However, since 8K doesn't have SPRAM, I reduced the amount of "bulk" RAM 
> to 1Kb. This is still enough to run the bootrom, and there's still a 
> good 25% of the EBR (4kB) left unused. The smallest e.g. ARM 
> microcontrollers had like 4kB flash and 1kB of RAM (LPC810), and I am 
> partial to msp430 (some of them have 128 bytes of RAM). So I'm very 
> tolerant of microcontrollers w/ limited memory :D!
> 
> Based on prior experience targeting Micropython to 8k parts, I think 8k 
> support is worth exploring at this point. Using j1 to its full power w/ 
> e.g. Micropython on HX8K will most likely require a small icache and SPI 
> Flash XIP. This configuration w/ lm32 on TinyFPGA halves execution time 
> compared to without; we can probably go without a dcache. And even if 
> it's not ideal, we can use j1 until j0 is ready :D!

J0 is a bit of a redesign, but might bubble back UP to the rest of the codebase
depending on how we do it.

In theory our soc_gen plumbing is designed to arbitrarily wire together
arbitrary components, and Jeff always intended that to include INSIDE the CPU
itself. With tomasulo dispatch you can have multiple instances of adders,
multiplers, shifters, and so on, so it's not just multi-issue to run multiple
instructions in one clock but can theoretically go the OTHER way and help us
make components optional, see what we can _yank_ and still have it work. (As
with the shift-and-add microcoded multiply, you could have a similar microcoded
"repeating shift-by-one" trading cycles for circuitry.)

Alas, Jeff and I haven't physically been in the same room for 8 months (doing
this sort of design work remotely turns out to be a lot harder), and what we
HAVE been working on is... much less technically interesting. :(

> If you want to duplicate my results and see LUT/EBR uages, use my copy 
> of j1 (https://github.com/cr1901/jcore-j1-ghdl/tree/hx8k) and run "make 
> TARGET=ice40hx8k_b_evn". LiteX is using my own copy of j1 for now, just 
> in case I need to make changes and experiment; this is temporary.

Last time we were in Japan I did the merge work so j1 and j2 could build from
the same CPU repository, but unfortunately it involved renaming a couple files
and manually editing a third because we haven't implemented the config selection
stuff for... synchronous vs asynchronous sram blocks implementing the register
file was it? (I dunno how to do that bit and everybody else has been too busy.)

Jeff, can we upload what we have of that so far as a temporary branch to the cpu
repo?

>  >for now another place to look is here: 
> https://github.com/j-core/j-core-ice40/tree/master/testrom 
> <https://github.com/j-core/j-core-ice40/tree/master/testrom> which while 
> less clean, is closer to what you'll need.
> 
> Ack. Where is the script/program you use to convert the testrom to a 
> VHDL array? I think I'd rather reuse yours for now than write my own.

https://github.com/j-core/j-core-ice40/blob/master/conv.c

> Ack. One thing I'd like to add: nextpnr has trouble routing the up5k 
> version of the SoC, even with the DSPs and SPRAM relieving about 1k LUTs 
> for other use. nextpnr can take upwards of 5 minutes to route on up5k, 
> and by changing the PCF, I could get nextpnr to take over 10 minutes to 
> route before I cancelled it. I'll ask one of the nextpnr devs for some 
> insight.

We've sent them some test code and bug reports before. They were really busy for
a while there, possibly less swamped now?

All we've regression tested in a while is "does new toolchain build the
./ghdl.sh image", and we're not that conscientious about do that regularly
because customer demand has been on the xilinx side in the most recent project.

Rob