[J-core] ROM image generator.

[Rob Landley]

On 11/19/19 10:52 AM, D. Jeff Dionne wrote:
> For this case there are a few things that come to mind:
> 
> - Lattice tools don’t properly elaborate some constructs.
> 
>  ...and so conv.c came out of frustration.

Yes but it's here, how do we improve it?

This is the only repo we have up on github, and it's the on

> - Latrice elaboration will assign a constant to a ROM.
> 
> But even though the whole ice40 port is a little hack to prove J1
> is feasible

No, it _started_ that way but once it did prove feasible we made plans for it.
That involves cleaning it up, and at some point unifying our 3 development forks.

> So, putting the ROM init contents in a separate package seemed like a good
> compromise, instead of just listing the values inline in the instantiation.

I'm not objecting to that, I'm saying there's a layering violation here I'd like
to clean up, and would prefer a different format for the data that's checked in
(one that goes "binary files differ" instead of "here's hundreds of lines of
diff dominating this commit". (We have the _source_ the binary was created from
checked in too, every time we change the binary we should also be changing the
source so you can already see what changed in a more useful format.)

> - The package should be general, and contain no implementation details, except about the code itself.
> 
> So exporting constants from the package seem to make a lot of sense.

It's a constant that can be calculated by the tool. It's the size of the binary
expressed as a power of 2, conv.c can trivially determine that and write it out,
the question is where.

> I’d go so far as to make conv.c create constants for entry point, length,
> stack etc. Prob. never used, but who cares, it doesn’t take long.

Except it doesn't know where we're relocating anything to, and "where we mapped
sram you can use as a stack" is an SOC detail. (Layering again, but we were
encoding that in the linker script if I recall...)

Is "the first byte of this blob is where you start executing" particularly
constraining, given that you have to READ a fixed location in the blob to find
out such relocation information?

The XIP (sram cache allowing SPI flash to execute in place) is very useful and
caused some design changes: I thought the boot room was going to do an ELF load
and relocate? ELF header is first 127 bytes, which can't move.

> - Use the VHDL language features.
> 
> In this case, it’s not even VHDL specific, but the best thing to do is to
> explicitly set only those elements that are non zero. Then in the
> instantiation entity, add (others => x”000000000”).

Does that save bitstream size? (I know these srams have bitstream data loaded
into them by the existing lattice plumbing, so it doesn't eat circuitry).

> In the package, maybe even make it sparse.

The above _isn't_ making it sparse?

> Then just make the init array just as long as the ROM data.

That other plumbing still needs the constant to know how many address lines to
allocate.

> If it’s too long, it’ll fail when you synthesise as needed, but you
> don’t need to keep the package and the instantiation in sync.
>
> I’ll try and find a few min to make an example today....

I'm confused, but an example would help, yes.

Rob