Sinara@DIOT Power Sequencing

[kaolpr]

As a few of Sinara modules already has native DIOT support and we're heading to a more wide-spread adoption, I believe it would be beneficial to agree on how power sequencing should be implmeneted. Please note that DIOT does not provide any reference design here - last month revied new version of DIOT FMC Carrier does not have any hardware power sequence implemented.

What we have in DIOT is RSN_N line shared across all peripherals. In EEM FMC Carrier there is a geographical position based delay. It is also implmenented in SiLPA, HVSUP_ISOL and Fastio DIOT. This implementation looks like this:

Before propagating this implementation any further we should resolve sinara-hw/SiLPA_HL#6

There is also a question if we want to have any software control over the process, e.g. some individual, I2C controlled peripheral hard-reset? Is there anything else you need from power sequencing circuit?

[kaolpr]

I tried to reproduce sinara-hw/SiLPA_HL#6 using DIOT crate, Kasli w/DIOT Kasli Adapter and 2 EEM FMC Carriers. Reset was observed on pin 3 of IC39. I did not mange to reproduce the issue, but I've measured actual delay times between peripheral slot 2 and 3-8:

Slot	Delay [ms]
3	0.8
4	2.1
5	2.1
6	3.6
7	5.1
8	6.8

Delays are clearly different from what states note on schematics.

I'm also not quite sure what was the initial idea for the startup sequence. Up till now I believed that controller pulls RST_N low until it is initialized and only then RST_N goes high. It would therefore seem reasonable to have RST_N pulled down and require actively driving it high by the FPGA/MCU.

However, RST_N is pulled up on most of the controllers (Kasli DIOT, DIOT SB and DIOT Kasli Adapter) and connected to MCU without any pull up/down on STM System Board. So before pull-up is powered up, this line is unpowered. Even when pull-up power becomes present, it may still take some time before it will be driven active state (low) what may lead to peripherals becoming active in the meantime.

Additionally, the delay circuit has no way of knowing when RST_N was released, as P3V3_MP_B is generated directly from P12V0_CPCIS that is always present.

If the goal was to postpone powering peripherals until the controller is ready and then power them up in a sequence with time delays, it does not seem to be realized in a current implementation.

[gkasprow]

this circuit won't work for slots 7 and 8 and this was already observed.
This is fixed circuit