DDR3 interface section does not have dedicated reset signal for T2080. Please let me know how to interface reset with DDR3 between processor and DDR3 component.
Can RESET_REQ_B be used for this?
We recommend to use T2080's HRESET signal as a source for DDR3 reset. Note that these signals have different power rails (HRESET - OVDD, DDR3 - GVDD), so an addition voltage converting circuit (OVDD -> GVDD) needs to be used.
Hello Bulat Karymov,
Thanks for your reply.
Can you please let me know the reason for selecting HRESET instead of RESET_REQ_B?
In custom design board i have done the following for RESET section:
PORESET_B : Main board reset
HRESET_B : Push-button switch
RESET_REQ_B : Reset to all peripherals (DDR3, Ethernet,..) on the board. (NOTE: Considered this reset because "Asserted either of HRESET_B or PORESET_B been detected)
Please confirm the usage.
'HRESET low' indicates the fact of reset. 'RESET_REQ low' indicates that the processor requests reset, depending on the design the reset can happen later.
A bit deeply:
'HRESET low' means that the processor resets, this is good time to reset external devices, e.g. memory. Note that during PORESET the HRESET is low as well.
If you use RESET_REQ to reset DDR3, you can face with some unwanted issues.
1) When the processor asserts RESET_REQ indicating that it requires to be reset, the cores are still running(!), but the memory gets lost due to DDR3 reset.
2) DDR3 will NOT be reset at Power On. This is because PORESET assertion does not cause RESET_REQ to be low. Instead, PORESET puts RESET_REQ into hi-z state. So there is a great chance to get non-functional memory right at start up.
Hello Bulat Karymov,
Thanks for your detailed reply.
I have made changes for HRESET signal.
Can you let me know usage / connectivity of RESET_REQ signal. Can this signal be connected to HRESET?
Yes, you can connect RESET_REQ to HRESET. However typically the connection is a bit more complex. HRESET may require to be asserted from several sources. For example a) corresponding signal from the debug header (JTAG/COP), b) from a reset button. In such a case you will need to arrange a logic (AND-like gate) allowing to all external sources to assert HRESET signal.
I found the problem:
There was an issue with the CPLD IO configuration file which did not
allowed the signals which are part of a group of signals defined as
"debug" list of T4240 IO (DMA2, EVT9, CKSTP_OUT_B etc.) to be stable
during power on. It was not a PORESET issue, as these signals were not
power of the POR configuration but more of a power stability of these
signals immediately after PORESET_B was de-asserted.
The solution was to change the IO settings and the problem went away.
I want to thank you for looking into this matter for me.