[Cryptech Core] proposed core reorganization

[Joachim Strömbergson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Aloha!

Yes. The general structure hat Pavel is suggesting is more in line with
what I suggested in the teleconf a couple of weeks ago. Having general
(i.e) not application specific cores in a tree of repos and then having
platform specific designs in separate repos for each platform.

Yours
JoachimS


Павел Шатов wrote:
> 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 
> _______________________________________________ Core mailing list 
> Core at cryptech.is https://lists.cryptech.is/listinfo/core


- -- 
Med vänlig hälsning, Yours

Joachim Strömbergson - Alltid i harmonisk svängning.
========================================================================
 Joachim Strömbergson          Secworks AB          joachim at secworks.se
========================================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJU9HPvAAoJEF3cfFQkIuyN5qYQAMANvTlBxKzIgWrtxTo3Jcew
51EeF8isr+FQ78YMJic1FaRSHf5EZTY1jHx/ziIOgFy05jILR9ZvugVVubfcfx96
hIHL6oibPdx9TuuB1S5VzFulR9V5/pgFFJzN7B+JHcztRovlOTdVFmq31SaF9zTs
VTKa43x2n+ugzQeQK/P2uxd0T/5zY/BC+ZYgLedb6jCzNIXLil1xwkokyf35zHM0
nG/KZtfZR1y6JooAH5P/CD4esa8umkUZkCAujhhqAgt6NX2Qn8wUzRUrMJGCqXJY
IveH5XflDPJUPdhId0rI0obv3Ao7faC4DwDAcPi1VKF9kaGc5vyNZSCAke5mpfly
epz/MoJMLShyOl/eVORt/WDeeZuK9ps8Fm2tahjrxHvzwD3d97HonxOpz67nSLNC
fmoTQFuSPDxaKlGqw4CAF90jJKKdQPV0908jMvpnPgh1DIuPGhNkG4Xfs5pI+fwA
rIy/K4Twr43GCCqSA+7ZpvItDWCMsGzKXh6Mj1xm08qKxiTTgnmAy5LeXJiLH10e
ZV3ZqSvEugUBysbxjEWyMCJEGQ+/Re/RbtlpEUMYhghPP3U4+V68FMz7s8e6HT48
ZwYZSi+GdloGCna77CEnN65Pf18Z9t2J3WsNQctWdss3ICD/kmhe6/GqVCimu6es
lR8hJRAEjjvB+0vMHspB
=ieKi
-----END PGP SIGNATURE-----