[Cryptech Core] proposed core reorganization

[Paul Selkirk]

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.
> 
> 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)?
> 
> I'd like to get this resolved soon, so I can push this stuff into core,
> remove the embarrassing novena_eim core, shift novena_i2c_simple to test
> (or remove it entirely), update the build instructions, and generally
> tidy up.
> 
> 				paul
> _______________________________________________
> Core mailing list
> Core at cryptech.is
> https://lists.cryptech.is/listinfo/core
>