[Cryptech Tech] [Cryptech-Commits] [core/platform/novena] 21/21: Sick hacks to compensate for sparse MUX within TRNG core.

[Rob Austein]

At Mon, 05 Oct 2015 09:20:51 +0200, Joachim Strömbergson wrote:
...
> Rob Austein wrote:
> > Can we please just use the status register for status and the
> > control register for control?
> 
> The problem I have with this is that now you really need to write
> specific bit values, basically do read-modify-write so that the write to
> the control register needed to clear the error signal does not effect
> any other control bits.

Um, why?  As currently used, we blindly write bits to the control
register without ever checking its value, sometimes writing exactly
the same control bit as we did last time in order to cause something
new to happen (eg, writing CTRL_NEXT for the second, third, and fourth
blocks of a hash).

So, to date, the control register has acted as a command port to which
we send a control opcode, with a slightly weird encoding of that
opcode such that it can be parsed as bit flags if one prefers that.
I've been assuming that thinking of this as bit flags was easier for
the Verilog code, you tell me.

Is there some condition you envision under which the FPGA would light
the access violation error status bit but then go and do whatever it
was the software had requested anyway?  My assumption had been that
lighting that error bit meant that the operation had failed, so we're
going to have to start over, which is going to involve setting the
control word to some new value anyway.

> Just to clear confusion:
> 
> (1) Some access violation happens -> error bit in STATUS reg is set.
> 
> (2) SW writes a <0/1> to error bit in CONTROL reg to clear bit in STATUS
> reg.
> 
> (3) Error bit is cleared in the next cycle.

And core is now waiting for me to start a new operation, right?

> This is what you want? What bit value do you want to write?

Don't particularly care what opcode (or bit, if you prefer to think of
it that way) we use so long as it's consistent.