05.05.2018 13:09, Peter Stuge пишет:
Joachim Strömbergson wrote:
I like this idea, but I would definitely stick with a synchronous
bus such as SPI.
What would you say are the main reasons for using SPI?
It makes everything explicit.
Timing and packet/message/command boundaries are each given an
explicit signal, which allows for very clear and IMO simple behavior.
I tend to agree with Peter, in my opinion SPI seems more appropriate.
To me, a UART is simpler to not screw up.
Perhaps the UART itself, but please also consider the layers above it.
With a byte stream, all protocol state changes are data-dependant -
timing and all boundaries are implicit. This makes it impossible to
separate framing from message processing, essentially forcing a
layering violation. :\
We have a simplistic SPI master for the current master key serial SRAM.
But it would need to be extended to be able to handle other
records/commands etc.
Since both ends of this connection are made by CrypTech, we are
now able to design the communication protocol as we see fit.
The chief disadvantage I see is performance.
I also don't consider performance on this connection a priority.
The iCEstick includes an FTDI USB chip for easy flashing, but only
has 24 IOs spread over three connectors, only has a 12 MHz
oscillator and is designed to only be powered via USB.
Note that HX1K has no PLL in the VQ100 package used on both these
boards, so no clock can run faster than the oscillator. But a good
design should not rely on a clock for tamper detect anyway, I think
that should be asynchronous.
Good point on power supply. The stick would only be used for testing and
prototype development. Then we either have to design our own board that
fits on top of Alpha headers, or adapt something like the TinyFPGA
board. I think the stick is a good start for now.
As far as I see it, 24 I/Os are more than plenty (a few I/Os for the
interface, one or two for tamper detect and possibly a few for debug)
All right.
Regarding the clocking. The control FSM handling storage including
tamper reaction will be clocked.
The tamper event inputs needs to at least be sampled in a proper manner.
Just having a level input that pulls the reset of a register sounds to
me like asking for an over sensitive system that will cause reliability
issues and bad surprises. Please, explain why this would be good design.
I'm probably missing something smart.
I would like an asynchronous input and for any signal filtering to stay
outside the MKM, in order to achieve the minimum tamper response time.
The 12 MHz iCEstick clock has an 83 ns period.
That's almost 20 times the latency of an iCE40HX global input (5.00 ns
tCO Clock to Output - PIO Output Register (Using Global Buffer clock
without PLL) on p.28 of iCE40LPHXFamilyDataSheet.pdf DS1040) for one
single sample...
Speaking of asynchronous signals, I think the original idea was to have
several tamper detection inputs in the tiny MKM FPGA. Suppose that they
are active-low, this way as soon as a tamper event from a certain sensor
is detected, the corresponding input goes low. Tamper detection inputs
can be AND'ed together and routed to the reset signals of the flops
where the master key stored. This way the master key can we wiped
asynchronously and even if the clock signal is stopped for whatever reason.
--
With best regards,
Pavel Shatov
_______________________________________________
Tech mailing list
Tech@cryptech.is
https://lists.cryptech.is/listinfo/tech
