[Cryptech Core] proposed core reorganization

[Павел Шатов]

On 07.03.2015 4:36, Paul Selkirk wrote:
> [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.)]

[I'm sorry for your horse, honestly. I can still remember that evening, 
when I took my dachshund for his last walk, before taking him to a 
veterinary station in the morning to put him down because of untreatable 
cancer. Sad story.]

>> 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'm sorry, I must have misunderstood your idea. You want to have a set 
of global registers (board type, board version, etc) and you want 
communication cores to have their registers too (EIM arbiter version, 
UART interface version, etc), right?

>> 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?

I know that such thing exists at least in Xilinx tools. What you need is 
-vlgincdir XST option, it allows you to specify in what directory to 
look for `include files during synthesis. You can find more information 
here (page 354):
http://www.xilinx.com/support/documentation/sw_manuals/xilinx14_7/xst_v6s6.pdf

We can put all the `defines into a separate header.v file (a small file 
that contains only `defines and no module code). This file can be 
included where needed using `include "header.v" line. The file itself 
can be in any arbitrary directory, specified with -vlogincdir to help 
find it during synthesis. I believe Altera tools should have similar 
option. I'm not that much familiar with Quartus, Joachim knows about it 
maybe?

--
With best regards,
Pavel Shatov