[Cryptech Tech] Documentation, I2C, and an embarrassment of options

[Paul Selkirk]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/07/2014 08:47 AM, Joachim Strömbergson wrote:
> Rob Austein wrote:
>> It seems that we have (at least) two different I2C interfaces to
>> the digest cores on the Novena, with very different APIs:
> 
> Dunno what there are two different I2C interfaces. Paul?

See https://lists.cryptech.is/archives/tech/2014-September/000849.html

novena_i2c_simple has a streamlined read()/write() interface, which
requires less code on the user side, and provides better performance
over what is still admittedly a serial interface. It was an idea I was
playing with about what I'd like to see as a software guy writing to
the FPGA.

For novena_eim, I've gone back to your pseudo-memory interface, albeit
without the serial command processor in coretest.v.

> This also includes subsystems for talking to HW functions via a
> defined interface such as i2c, uart and eim on the novena. (i2c and
> uart being cores too) These systems with multiple cores may
> primarily be used for the development and test of Cryptech HW, but
> they are not exeperimental things.
> 
> When I have implemented fore example coretest_hashes on different 
> platforms I've placed platform specific stuff under 
> coretest_hashes/toolruns/quartus/c5g (for the C5G board). This
> means that there really is only one coretest_hashes system core,
> but then it contains fixes for different platforms.
> 
> Paul has choosen another scheme and created novena-something-cores
> for the adaptations for the novena platform.

I don't claim to have the best organization (I don't actually enjoy
duplicating code all over the source tree), but we have to face the
fact that the top-level (coretest_hashes) is tied to a specific
communications channel.

Maybe if we put the variants in the coretest_hashes repo (e.g.
srt/rtl/coretest_hashes_i2c.v or src/rtl/i2c/coretest_hashes.v), and
put the board-specific stuff (novena_fpga.v) in toolruns.

But then we're still faced with the channel-specific hash_tester code
in src/sw. It would have to have a similar naming or subdirectory
scheme to src/rtl.

Mabye something like the following:

coretest_hashes
  src
    rtl
      coretest_hashes_uart.v
      coretest_hashes_i2c.v
      coretest_hashes_i2c_simple.v
      coretest_hashes_eim.v
    sw
      hash_tester_uart.py
      hash_tester_i2c.py
      hash_tester_i2c.c
      hash_i2c.c
      hash_tester_i2c_simple.c
      hash_i2c_simple.c
      hash_tester_eim.c
      novena
        configure.sh
  toolruns
    quartus
      terasic_c5g
        coretest_hashes.qpf
        coretest_hashes.qsf
        coretest_hashes.sdc
        cryptech_pre_build_image
          coretest_hashes.sof
    xilinx
      novena
        novena_i2c.v
        novena_i2c.ucf
        novena_eim.v
        novena_eim.ucf
        Makefile_i2c
        Makefile_i2c_simple
        Makefile_eim
        xilinx.mk
        xilinx.opt

Is this the sort of thing you had in mind?

> test/ contains cores that are for testing ideas before promoting
> them to a real cryptech core. Things in here may never become
> usable in any sense of the word.

I'd be willing to move the i2c_simple stuff to test/ if it would make
things less confusing.

				paul
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUXVKeAAoJELAqzRn9CEWT9TgIAI7Dv4L8fuv6bDvlTaZLvlLf
95tcqAY8jPtyIFp/mo2s3m9bU0KBcP7JzCwgpYgVoN5uKs1SKRJ5G/I2AfQt6bp9
U7vLNsmuK6j4ubNoq+Lb7WvR91Ug/7MRBrMB70Ci3JcR1qP0r3Vh+e23P1XUbha6
RoZkpoAnybqs03pkSxnorNGDdYxLgEtBSwZXUQwV6eXlmNt0rN4jtpmDq76Ow3+O
M3LuFhO7qflxlCAFw/37P82cX878JnaUbinFQfP5f8v42lJ2n/mL9g+0ZYDf2Lcr
P2N63AIa1SuV1nqx+D6kISm6Vw3sSLPkXQ/XWKkZEOzxicV2JdX+thELTZq0E6U=
=jcd+
-----END PGP SIGNATURE-----