[Cryptech Core] proposed core reorganization

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

On 27.02.2015 0:44, Paul Selkirk wrote:
> I just committed a 'toolsrun' branch on user/paul/core.
>
> This organization puts the platform- and project-specific files
> (top-level verilog files, build files) under the communications channel
> core, e.g. core/eim/toolruns/xilinx/novena,
> core/uart/toolruns/quartus/terasic_c5g.
>
> The biggest stumbling block was figuring out how the uart register
> module should pass config options to the uart core module. I did manage
> to build it under Quartus (and left the build artifacts in place), but I
> don't have the hardware to test it.
>
> Joachim and Pavel: Do either of these approaches make sense to you, or
> is there some other way we should organize the FPGA code?
>
> 				paul
>
> On 02/24/2015 12:04 PM, Paul Selkirk wrote:
>> Now that we've stabilized the EIM code in the 'test' tree, I've been
>> working on how/where to move it in the 'core' tree. I recently committed
>> a possible organization in 'user/paul/core', and would appreciate some
>> feedback on it.
>>
>> We have several kinds of cores in the 'core' tree:
>> - those that do something useful (hash, cipher, rng)
>> - host-fpga communication channels (uart, i2c, eim, coretest)
>> - platform/project specific (novena[i2c], novena_i2c_simple, novena_eim)
>>
>> To the extent possible, I've separated the EIM files into a generic
>> top-level core, alongside uart and i2c. (One could argue about how
>> generic these communication channels are, given that we have exactly one
>> platform that uses uart, and one that uses i2c and eim.)
>>
>> This leaves a single novena core directory, which builds both the i2c
>> and eim projects. Note this means two top-level verilog files, two
>> Makefiles, two .xise files, two .ucf files, which is unavoidably ugly.
>>
>> The Makefiles or project files have to know about every core to include
>> in the project, but the actual mux operation happens in core_selector
>> (hash_selector, etc), which is controlled by ifdefs in the code. I find
>> this extremely ugly, but I wasn't able to get a clean design where I
>> define say USE_CORE_SHA1 in say novena_toplevel.v, and have it control
>> synthesis in hash_selector.v. With ISE, I had to switch to "manual
>> compile order", but reordering files in the Makefile didn't work at all
>> - apparently each file in the command-line build is a separate
>> compilation unit. But I digress.

Paul, having defines in the top-level module is impossible, because they 
will not be visible in other modules. If you want to have defines 
separated, you can create a small file, say core_settings.v, move all 
the defines to this small file and then include it in core_selector. Is 
this what you want to do? I'm not very much familiar with console build 
process, I mostly use GUI flow.

>> The thing that's missing from my tree is uart and the Terasic project.
>> Joachim buries the project-specific stuff under
>> coretest_hashes/toolruns, because coretest_hashes.v is, at the same
>> time, a generic mux and a project-specific file (with specific
>> connections to the uart and the hash cores). As I discovered when I
>> started working on i2c, I needed an i2c-specific version of
>> coretest_hashes.v. My new stuff instantiates the communications channel
>> in the top-level, so at least removes that from the mux. But the
>> question remains:
 >>
>> Do we want explicit top-level cores for each platform (core/novena,
>> core/terasic, core/alpha)? Or do we maybe want to bury the
>> platform-specific stuff under say the communications channel core (e.g.
>> core/eim/toolruns/xilinx/novena, core/i2c/toolruns/xilinx/novena,
>> core/uart/toolruns/quartus/terasic_c5g)?

Since I joined this project I've worked with Novena only. As far as I 
understand, you have another platform (some Terasic Cyclone V board) and 
you want to have a somewhat more unified project for both platforms and 
for the forthcoming Alpha?

I've taken a look at coretest_hashes. Is this the current project for 
Terasic board? If we want it be unified with Novena, we should rewrite 
it. Do you remember the partitioning of my baseline design for Novena? 
It's top-level has three instantiations: 1)clock manager and 2)EIM 
arbiter are platform-specific, 3)core_selector which should be common 
for all platforms.

Coretast_hashes should have the same structure: all the core 
instantiations and the core multiplexor should be replaced with 
core_selector. Again, this core_selector should be common for all our 
platforms, it is basically a set of registers and has a memory-like 
interface. Both EIM arbiter for Novena and UART module for Terasic have 
memory-like interfaces too, so everything fits together nicely. The only 
difference is that EIM arbiter has Read/Write flags and UART module has 
ChipSelect/WriteEnable flags, which are equivalent, I've already 
discussed this.

My opinion is that we should have separate top-level modules for each 
platform. We are going to have different constraint files anyway, so it 
makes sense. Platform-specific stuff should be packed in modules and 
instantiated from the top-level module.

If I were organizing the repository, I would have something like this:

core/
core/common/
core/common/core_selector.v
core/common/...
core/common/hash/
core/common/hash/sha-256
core/common/hash/sha-512
core/common/hash/...
core/common/cipher/
core/common/cipher/des
core/common/cipher/aes
core/common/cipher/...
core/common/rng/
core/common/rng/...
core/platforms/
core/platforms/novena/
core/platforms/novena/novena_top.v
core/platforms/novena/constraints_novena.xxx
core/platforms/novena/...
core/platforms/novena/eim/
core/platforms/novena/eim/eim_arbiter.v
core/platforms/novena/eim/...
core/platforms/terasic/
core/platforms/terasic/terasic_top.v
core/platforms/terasic/constraints_terasic.xxx
core/platforms/terasic/...
core/platforms/terasic/uart/
core/platforms/terasic/uart/uart.v
core/platforms/terasic/i2c/
core/platforms/terasic/i2c/i2c.v

What is I2C used for btw?

--
With best regards,
Pavel Shatov