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

[Rob Austein]

At Wed, 30 Sep 2015 15:31:35 +0200, Joachim Strömbergson wrote:
> 
> I'm fairly (as in very) certain that we want to be able to trigger
> interrupt events in the CPU when things go bad in the FPGA. Typically
> that the TRNG monitor detected that it is b0rked. There might also be
> other rather important error events that we want to inerrupt the CPU for.

OK.  That's not what I thought the existing error wires were doing.  I
agree that asynchronous events like that might be a reasonable use of
interrupts.

> Now, in order to limit the number of IRQ wires from the FPGA to the CPU
> and also be able to keep an event history I proposed am IRQ trigger
> module in the FPGA that collects error signals from modules, stores them
> and also pulls the IRQ wire to the CPU. The CPU can then find out what
> error event it was in the FPGA that triggered the IRQ and take
> appropriate action.

So basically the IRQ would say "go read the something-awful-happened
error register/queue/... ASAP".  From the software side, the interrupt
handler itself would probably still just set a flag / send a condition
/ pick your programming abstraction, but the effect of that would be
tell main program level to schedule an immediate poll, for some safe
definition of "immediate".

> We could have no IRQ, but then SW would have to read status in each
> module very often and esp both before and after doing anything in the
> FPGA. There are also probable race conditions lurking with a setup lile
> this.

Agreed.

> The second issue is if we should also flag for impproper use of the API,
> which is what the error signal in the modules implement today.

Right, that's what I thought the error wires were, and that's the
function that seems like it could just be a bit in the status word.

> > Interrupt handlers are tricky; in practice, the safest thing to do
> > in an interrupt handler is usually just to set a status bit.  There
> > are situations where a hardware interrupt is the right answer, but
> > just signalling a condition to software that has to poll for other 
> > conditions anyway is probably not one of them.
> 
> Not sure. It is how IRQs I see it in embedded space are done. Either you
> have a single point of entry in the vector table and the code then looks
> at status to determine what specific event it was. Or you have multiple
> vectors and which one is triggered by the specific IRQ number.

Doctrine as I was taught is to do as little as one possibly can at
interrupt level: set a flag, signal a condition, whatever, then get
the hell out and let main program level handle it.  So using an
interrupt to schedule an immediate poll is fine, and using an
interrupt to say "everything you were doing on the FPGA is now
hopelessly borked, bye, have a nice life" would also be appropriate if
such a condition could occur, but having a real conversation with the
FPGA at interrupt level would frowned upon.

We may be in agreement here, can't quite tell.

> > Have I missed anything here?
> 
> That things can go bump in the dark between usages of cores since they
> have a life of their own. And some of those events you should probably
> be able to react to as soon as possible.

Fair enough.  Slightly wider conversation than I had originally
thought we were having, but no harm in that.