06.05.2020 20:53, Peter Stuge пишет:
Hi Pavel,
Hi,
Pavel Shatov wrote:
doing the actual edits to the rev.03 hardware design to make it rev.04.
What's the plan for this? In particular, are you editing in KiCad or Altium?
I believe, the plan was outlined during the "restart" call we had last
year. The absolute minimum is to replace the master key memory with a
tiny Littice FPGA, the other two desired goals are: (1) remove AVR
tamper detection MCU and implement the functionality in the Lattice
device and (2) get rid of FTDI USB-UART chips.
I'm doing the edits in KiCad. I must admit, Fredrik did excellent job
converting the design to KiCad. There still are some cosmetic
differences between Altium's and KiCad's Gerbers, like Altium uses
vertial and horizontal thermal relieves, while KiCad does diagonal ones.
I'm not sure it makes sense to spend extra time trying to achieve 1:1
match given the current scarce funding.
Also more generally; I've noticed another signal that I would like to
have added to the UART daughterboard headers; DTR.
I see that you've sent a couple of e-mails to the list regarding your
UART solution recently. I did try to figure out all the implications,
but I'm not sure I have all the details in my head. How about we
schedule a call with you and maybe Joachim and anyone else interested
some time this weekend (maybe Zoom or something else with screen
sharing) to discuss it in more detail?
2. Clocking
I think we need to first clarify, whether the MKM needs any clock
source. I mean, if the device behaves like an SPI slave, in theory it
only needs SCLK, but some other clock source may be needed, for say
periodically polling some sensor or measuring timeouts, etc.
I want a clock, so that the MKM can periodically flip the key bits in RAM.
Yes, you're right, very good point. We want countermeasures against data
remanence in the MKM, so an always active clock is required.
LP/HX/LM devices don't have internal oscillators, so they all need
an external clock crystal.
Would it be possible to create a ring oscillator in logic in those devices?
This was my first thought when I discovered LP/HX/LM don't have built-in
oscillators. I believe a ring oscillator should work, but it's more
about black magic, and I'm not sure master key memories and black magic mix.
Note, that there's an additional series of iCE40 UltraPlus devices,
that do have at once two internal oscillators
A UltraPlus, Ultra or UltraLite device seems like a strong candidate.
Maybe it makes sense to have both an FPGA-internal clock source and an
external one? They can monitor each other.
Ultra and UltraLite have the same two oscillators as UltraPlus, fewer LUTs
and the same packaging. I suppose Ultra and UltraLite are UltraPlus devices
that failed production testing to some degree. To me that's an argument in
favor of an UltraPlus device, but on the other hand I think a part with
fewer LUTs also has some benefits - it further reduces the possibility
of the MKM doing something unwanted.
Ultra and UltraLite aren't supported by the IceStorm toolsuite, so it's
either UltraPlus 3K or 5K. I'm tempted by the 5K. Yes, it's large, but
it's available in QFN package. 3K only comes in that tiny chip-scale
BGA, I'm not sure how to breakout without blind or buried vias.
3. I/O Pins
6 pins
I think another few pins to STM32 and/or FPGA would be good. Especially
if we do move tamper detection into the FPGA (I am in favor of this) then
it's nice for the MKM to be able to let everyone know that something has
happened with an interrupt signal.
All in all, I tend to think, that the UP5K (UltraPlus 5K) device would
be the optiomal choice. It comes in either 30-pin WLCSP package with 21
user I/O pins or 48-pin QFN with 39 user I/Os. Currently the QFN looks
more friendly, but I haven't yet looked at Lattice recommendations
regarding their teeny weeny WLCSP and BGA packages.
iCE40UP5K-SG48I is the largest in terms of LUTs, and while 5k LUTs seems
quite excessive for the simple MKM task that we have in mind I can understand
the desire to give ourselves as much room as possible for experiments.
Thanks
//Peter
_______________________________________________
Tech mailing list
Tech@cryptech.is
https://lists.cryptech.is/listinfo/tech
--
With best regards,
Pavel Shatov
_______________________________________________
Tech mailing list
Tech@cryptech.is
https://lists.cryptech.is/listinfo/tech
