[Cryptech Tech] [Cryptech-Commits] [core/platform/novena] 21/21: Sick hacks to compensate for sparse MUX within TRNG core.

[Paul Selkirk]

Apologies for the late reply, but I think I've reviewed all the affected
code, as well as my own thoughts from when I started down the path of
dynamic build-time FPGA configuration.

On 09/29/2015 08:12 AM, Rob Austein wrote:
> At Tue, 29 Sep 2015 09:50:56 +0200, Joachim Strömbergson wrote:
>>
>> We could fix this in TRNG instead.
> 
> Indeed.

And that's the best solution. But Rob's config script (like mine before
it) deals with things as they are today, and demonstrates that this is
something we can automate, even if it has some ugly edge cases.

> Sorry, I should have provided some explanation, but it was late, and
> having finally gotten something that mostly worked, I wanted to push
> code to the public repository so that Paul could have a look at it.

For the record, I approve of everything you've done. And as usual I
learned a little more about Python while reading the code.

> There's one other small issue that affects not just the build-time
> Python code but also the runtime C code:
> 
> - Right now the C code has to guess how much bus address space each
>   core consumes in order to probe for cores.  This is nasty and
>   fragile.

Well, it's more like "know" how much bus address space each core
consumes, but I take your point.

>   Perhaps there should be a fourth word in each core header (just
>   after the two words of core name and one word of core version)
>   telling the C code how much bus address space each core consumes.
>   Having an explicit length would also give us a way to skip over
>   holes in the bus address space (as with the current TRNG MUX) if for
>   any reason we can't just fix them.

Another idea I had was to build a directory into the FPGA. Say we put it
in the board-register segment, with one register for the base address of
each subsequent core; that would allow us up to 253 cores, which is way
more than we'd ever use.

Again, it's not how the FPGA is configured at the moment, but it would
be easy enough to implement, especially if we're agreed upon having the
verilog read header files.

>   We could of course just generate a static address map for the C code
>   at build time, but that has its own form of fragility (tighter
>   coupling between rtl and sw than would otherwise be necessary).

The problem is that you can't assume that what's running on the FPGA was
built from the same configuration that's on your hard disk. Which I
think is what you're saying.

> Last: it's not obvious to me that this dynamic configuration mechanism
> really belongs in core/platform/novena, it seems likely to end up
> being more general than that.  My guess is that it's in
> core/platform/novena because that's where the Makefiles are, but I
> suspect we'll end up moving it, eg, to core/platform/common.

You're right on all counts. The one caveat is that the core_selector
ports (names and widths of signals) are platform-specific, if not
strictly Novena-specific.

				paul