[Cryptech Tech] IO interface (was Re: Incremental digest outputs)

[Rob Austein]

At Mon, 17 Nov 2014 09:48:47 +0100, Joachim Strömbergson wrote:
> 
> Btw: The cores deals with blocks (or whatever the fundamental data size
> the core operats o). The sha512_core.v for example has a 1024 bit input
> block port and a 512 bit digest output port. The top level wrapper
> (sha512.v for example) maps these into 32-bit words accessible fairly
> similar to a memory (chip select, write enable and address and data ports).
...

[Lots of good detail from Joachim elided here]

Overall design (in particular, separation of what the core needs from
how we think it ought to be presented) sounds very good to my
admittedly clueless eye.

> But what we could discuss is if the register based, memory like access
> is what we want as API between SW and HW. Or if it instead should be
> more command+data. It is quite possible that SW talks to the HW by
> writing to a single address. And what is written is formatted into
> packets with commands and data which then has to be parsed by the HW.

Yeah, this is where I'm not really sure what is the right way to go.

Eg, if we were just talking about what's most convenient for C code,
the representation that might make the most sense for a memory-mapped
implementation might be to map an entire block so one could just
memcmp() complete blocks in one go, similarly map the entire output
digest so one could memcmp() the result out.  Control registers might
be mapped directly; separating these into read-only and write-only
might be easier to get right, as read-write control registers would be
potential race conditions even when using C's "volatile" type
qualifier.  I would like to think that we can avoid byte swapping. :)

But if it turns out that it's simpler to do some kind of command +
data interface, that's probably OK too, and the semantics might be
better.  Still would prefer that the data in and out be simple byte
strings, preferably complete blocks where that makes sense.

If you think I'm nuts about the simple byte strings, say so.  I'm
trying to avoid a lot of complicated data shuffling that it sounds
like the core Verilog code doesn't really need, but if it turns out
that I'm just transferring pain from C to Verilog we may want
something else.

Paul, you've been closer to this part of the code, any opinions?

> We have been talking about things in this area (netstrings, Randys FIFOs
> etc) before.

I think Randy's FIFOs were memory mapped ring buffers with a control
block, or something like that, but he can speak for himself.

> And it is getting about time to decide on how we want to do this.

Yep.