[Cryptech Core] proposed core reorganization

[Paul Selkirk]

[First of all, I want to apologize for being so out of touch recently.
My horse (yes, really) suddenly developed a neurological condition where
she staggers around like a drunk, and occasionally just falls down. So
I've been spending a lot of time at the barn, dealing with the
veterinarian, etc. If she doesn't start responding to treatment in the
next day or two, I may have to put her down. (Which will be a logistical
as well as emotional nightmare, because the barn is currently snowed in.)]

> The only problem that I see right now is eim_regs.v module. This module
> contains some global (board-level) registers, like board type and
> firmware version. It is not related to EIM (it is not a communication
> channel, it is a set of board-specific registers), so it definitely
> should go under platform/novena. It was originally named novena_regs.v,
> we should have another such file (plarform/terasic_c5g/terasic_regs.v)
> with different board type value.

Sorry for the confusion. I actually (temporarily) dropped novena_regs.v
from this design, and added eim_regs.v. Each core has a set of registers
at relative address 0x00, for the name and version of the core. For most
cores, this is in the wrapper that implements the memory-like interface
to the computational core (e.g. sha1.v is all the registers, and
sha1_core.v does all the work). Even the communications cores have these
name and version register, but they kind of stand to the side, because I
didn't want to have to pass the communication ports all the way from the
top-level down through the core_selector mux to the communications core.
Thus the eim name and version registers are in eim_regs.v, rather than
eim.v.

By convention, the communications core is core #0, so the eim registers
are at relative address 0x0000, right where you wanted to put the
board-level registers. We could move the communications core to #1, or
we could even set up a separate segment for the board-level registers
and the communications registers, since neither one really belongs with
the hash core registers.

> I suggest that we instantiate global register module instead of one of
> the cores. You can create a separate Verilog file, say
> global_registers.v with the following content. It will hide all the
> "ugly" code from core_selector.v
>
> `define BUILD_NOVENA
> /* `define BUILD_TERASIC */
> /* `define BUILD_ALPHA */
>
> `ifdef BUILD_NOVENA
> global_regs_novena global_regs
> (
> ...
> );
> `endif
>
> `ifdef BUILD_TERASIC
> global_regs_terasic global_regs
> (
> ...
> );
> `endif
>
> `ifdef BUILD_ALPHA
> global_regs_alpha global_regs
> (
> ...
> );
> `endif

I really want to keep the different platforms separate from (and
ignorant of) each other. I'd much rather put each version of global_regs
in its own file, to live with the other platform-specific code. So there
would be platform/novena/novena_regs.v, platform/terasic/terasic_regs.v,
etc, each with module global_regs. This is what I did for the
communications registers - eim_regs.v, i2c_regs.v, and uart_regs.v all
define module comm_regs. The makefile or project file picks which
register file to include.

> Preprocessor is a very powerful feature of C/C++, why don't you guys
> want to use its equivalent in Verilog?

I actually want to use the preprocessor in Verilog, but I have a
question about where to put the defines, so that core_selector.v doesn't
have to know the location of a platform-specific (or project-specific)
header file. In C, I'd have a CFLAGS variable in the makefile, which
would contain a bunch of -D options. Does such a thing exist for the
Xilinx or Altera tools?

				paul