QorIQ T1040 HRESET assertion at PORESET

[fdm]

Hi,

What conditions should be met in order the T1040 to assert HRESET_B and deassert RESET_REQ_B after assertion of PORESET_B (for example, after RESET_REQ_B assertion during POR sequence)?

I'm observing that both HRESET_B and RESET_REQ_B do not change their states after PORESET_B assertion in my custom board:

Blue - PORESET_B

Magenta - RESET_REQ_B

Green - HRESET_B

BR,

   Denis

[fdm · Accepted solution]

Finally I have solved this puzzle!

Unlike other POR config inputs (cfg_rcw_src[0:8]), the cfg_eng_use[0:2] inputs must be in a valid state not only at the moment of POR deassertion, but all the time during the PORESET_B assertion.

[ufedor]

It is always reasonable to refer to the processor's Data Sheet:

[fdm]

These setup and hold times are relative to negation of PORESET_B, that is to the moment of PORESET_B deassertion!

There's nothing about POR config inputs, and particularly about cfg_eng_use[0:2], during PORESET_B assertion, besides the last 4T (=40ns @ Fsysclk=100MHz), isn't it?

[ufedor]

> isn't it?

No - refer to the Design Checklist.

[fdm]

Are you trying to convince me that the documentation is clear enough?

"Some signals must be driven high or low during the reset period. For details about all the signals that require external pull-up resistors, see the data sheet document." - are you saying about this?

Well, let's see:

Which of these notes are definitely saying about the need to drive the signals during all time while the PORESET_B is active?

On the other hand, the Design Checklist says that:

[ufedor]

> need to drive the signals during all time while the PORESET_B is active

The "all time" definitely is not required.

[fdm]

Well, what time is required?

[ufedor]

As specified in the T1040 Data Sheet, Table 21.

[fdm]

Are you saying about 1ms?

[ufedor]

I'm saying abot the whole table.

[fdm]

So what is the required time of the cfg_eng_use[0:2] signals with respect to the PORESET_B assertion and/or deassertion?

[ufedor]

Input setup time for POR configs with respect to negation of PORESET_B (min)  4 SYSCLKs
Input hold time for all POR configs with respect to negation of PORESET_B (min)  2 SYSCLKs

Maximum valid-to-high impedance time

for actively driven POR configs with respect to negation of PORESET_B (max)  5 SYSCLKs

[fdm]

I have had setup time of around 800us and hold time of around 50ns(~5Tclk) for both the cfg_eng_use[0:2] and cfg_rcw_src[0:8] at the waveform in the starting post. Why the HRESET_B and RESET_REQ_B behavior after PORESET_B assertion was nevertheless wrong?

[ufedor]

Please provide a trace simultaneously showing the following:

10 cycles  of SYSCLK

deassertion edge of PORESET_B in the middle

POR configuration signals

[fdm]

The problem is already solved, and now its solution seems quite straightforward, but I still think that some important aspects in documentation are not clear enough or aren't mentioned at all, and sometimes are wrong.

1. It is not clearly stated that cfg_eng_use[0:2] inputs should have valid state not only at the PORESET_B deassertion (unlike cfg_rcw_src[0:8]). These inputs (at least cfg_eng_use[0]) select SYSCLK source and, as such, they affect propagation of the PORESET_B, that is not completely asynchronous.
2. Table 4-3 of the Reference Manual ambiguously says that the PORESET_B and the HRESET_B "may be asserted completely asynchronously with respect to all other signals".
3. The cfg_eng_use[0:2] pins are referred as Power-On-Reset Configuration Signals (at least in the Pinout list). Figure 4-1 "Power-on reset sequence" in the Reference Manual erroneously shows that valid POR Configs may be applied after the RESET_REQ_B is tri-stated and the HRESET_B is asserted by the chip.
4. It is not mentioned that the RESET_REQ_B is negated during POR only after SYSCLK is applied (as it is for the HRESET_B).
5. The DIFF_SYSCLK input description erroneously references the "DC-level requirement for SerDes reference clocks" section. Unlike SerDes reference clocks, the DIFF_SYSCLK input doesn't allow an external DC-coupling.
6. It is not mentioned that the cfg_eng_use[0:2] pins affect the internal termination at the DIFF_SYSCLK input.

Thank you anyway for your help.

BR,

   Denis

[ufedor]

Thank you for the detailed list.

[fdm]

Hi Fedor,

Hard-coded RCW option has been used for the waveform shown.

When using e.g. I2C as RCW source, the HRESET_B is not deasserted in accordance with RM (valid RCW data are not applied yet), but again the RESET_REQ_B is not deasserted after the PORESET_B assertion.

BR,

   Denis

[ufedor]

It is required to doublecheck that all notes after the "Table 1. Pinout list by bus" in the "QorIQ T1040, T1020 Data Sheet" are fulfilled, power sequence is correct and all clocks are applied.

[fdm]

I have only DIFF_SYSCLK ans SD1_REF_CLK1 routed and applied. SYSCLK and DDRCLK are pulled down. Could it be the source of problem?

^{Обновлено}

It seems the RESET_REQ_B is deasserted when HRESET_B is asserted externally (w/o PORESET_B)

[ufedor]

It is required to doublecheck that all notes after the "Table 1. Pinout list by bus" in the "QorIQ T1040, T1020 Data Sheet" are fulfilled.