Reset initialization timing requirement questions LS1043ARDB

[tracysmith]

Attached the reset timing initialization specifications.

1.  Reading the attached spec, the ‘POR Configs hold time is 2 SYSCLK’s min 5 SYSCLK’s M  At 100 MHz that’s a 30ns window’, is this correct?  Are we reading the requirements correctly? Yes, we do use actively driven configs.

2. Since NxP is specifying this in such small numbers of SYSCLKs, are these inputs intended to be synchronous to the SYSCLK of the MCU?  If synchronous, we are concerned that an internal CPLD generated clock (+/- a few %) may not work well, would this be the case?

3. Do we need to input the SYSCLK anyway in order to support the “PLL input setup time with stable SYSCLK before HRESET_B negation” with any accuracy?  The PLL lock time (given a stable 100MHz clock with easily a millisecond start-up time) is 100uS. 

4. HRESET_B” is both an output and an input, but it is less than clear how/when to handle the transition. How and when is this transition handled?

5. There is a requirement to drive PORESET active low "BEFORE" the core and platform supplies are powered up". Why is the requirement needed? What is the source and reason for this requirement?

[alexander_yakov]

1.  Reading the attached spec, the ‘POR Configs hold time is 2 SYSCLK’s min 5 SYSCLK’s M  At 100 MHz that’s a 30ns window’, is this correct?  Are we reading the requirements correctly? Yes, we do use actively driven configs.

Yes, you have this 3 clocks (30 ns) window to release config signals.

2. Since NxP is specifying this in such small numbers of SYSCLKs, are these inputs intended to be synchronous to the SYSCLK of the MCU?  If synchronous, we are concerned that an internal CPLD generated clock (+/- a few %) may not work well, would this be the case?

 This is up to CPLD designer. If CPLD designer can satisfy these requirements from internal CPLD clock, than internal CPLD clock is ok. On our QDS board CPLD clock is generated from the same clock source as SYSCLK, this allows CPLD design to be synchronous with SYSCLK.

3. Do we need to input the SYSCLK anyway in order to support the “PLL input setup time with stable SYSCLK before HRESET_B negation” with any accuracy?  The PLL lock time (given a stable 100MHz clock with easily a millisecond start-up time) is 100uS.

Yes, SYSCLK must be applied. The following is said in LS1043A Reference Manual, Section 4.4.1 “Power-on reset sequence”, Step 3:

3. The system applies a toggling SYSCLK signal and stable POR configuration inputs.At this point, SYSCLK is propagated throughout the device; the platform PLL is running in bypass mode.

4. HRESET_B” is both an output and an input, but it is less than clear how/when to handle the transition. How and when is this transition handled?

 The device stops driving HRESET at step 14, “after which, it becomes an input, allowing external devices to stall/hold the reset sequence.”

Note that Reference Manual recommends using PORESET for reset assertion to the chip, using HRESET for this purpose is not recommended. See Table 4-3.

5. There is a requirement to drive PORESET active low "BEFORE" the core and platform supplies are powered up". Why is the requirement needed? What is the source and reason for this requirement?

This is to prevent random states of device I/O signals during power-on.

Have a great day,
Alexander
TIC

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[Gandalf-kern]

Ans1) Hold time for por_configs is 2 SYSCLK minimum. 

5 SYSCLK is the time after which the multiplexed function on por_configs will be available.

This indicates that the IFC bus has its first access begin 5 SYSCLKs after release of PORESET_B.  Could you please point me to the initial timing used on the IFC interface before it has read the RCW?  Since this is the only issue, a brief contention on the signals should not cause any real harm unless it interferes with the first read of the RCW from the NOR Flash.

Ans4) HRESET_B is driven by the SoC when loading RCW data, post which it becomes an input. I did not quite understand what you mean by "how/when to handle the transition".

Changing the state of a pin (HRESET_B) from input to output (from our CPLD to the LS1043A) generally has a protocol or timing related to it, especially on a pin such as HRESET_B which can result in an improper Boot-up if not handled correctly.  I did not see a requirement for the HRESET_B having a pull-up to maintain an inactive state during the transition from output to input on the LS1043A.

Ans5) The voltage selection logic in SoC takes effect when PORESET_B is asserted, hence the PORESET_B must be asserted when the VDD supply ramps up.

I can accept the requirement, but the explanation is less than clear.  “The voltage selection logic in SoC takes effect when PORESET_B is asserted” relates to either the PORESET_B Going active or Being active.  If it is Going active that triggers the voltage selection logic, being active Before power is applied to the LS1043A results in the LS1043A never seeing the PORESET_B Going active.  If it is Being active that triggers the voltage selection logic, then it should function whenever the PORESET_B is active, not obviously requiring it be active Before power is applied to the LS1043A.  If the absence of voltages (or when VDD supply ramps up) is a requirement for the PORESET_B to enable the voltage selection logic to function then your statement is significantly incomplete.