RomanRoman22
Newbie
Hi,
I have some problems with a FPGA/HPS – DDR3 interface and I could probably use some help from people who have experience on this kind of interferences. I think there is a problem between the HPS and the DDR3 interfere that appears after reset.
SOC FPGA – HPS
The SoC FPGA [Cyclone V - 5CSEBA5U23C7S] contains a (High-Speed Sync) HSSRx and a Streaming component. The HSSRx receives the serial 64MHz data from the ECU and drives the data to the Streaming in parallel (means that the HSSRx use a s/p shift register) additional to a single bit signal, the Valid signal. The Streaming takes the parallel data and with the use of State Machine creates an Avalon-MM interface with the HPS for the Valid data, at the frequency of 100MHz. Then the HPS interfere with the DDR3 (400MHz). With the use of terminal emulator, Tera Term, the DDR3-1600 [IS43/46TR85120AL] is monitored.
Testing
The test environment I have created is the that a Microcontroller (MPC) tell the Master (ECU) to send different data on specific addresses to the SoC FPGA. The SoC FPGA passes the data/addresses to the HPS (which I read from the Signal Tap). The data/addresses arrive in HPS,and then to DDR3(which I read from the Tera Term), read back from the MPC (through the Soc FPGA, back to the ECU and then to MPC). MPC compares the data/addresses have been received from the HPS with those that originally sent. If the received data/addresses are the same with those had been sent, then the MPC resets the ECU FPGA and the process starts again. This process goes for ever until the MPC reads different data/addresses of those MPC original sent to the HPS/DDR3.
The whole process goes around for some loops (loop: MPC reads back correct data/addresses, resets ECU FPGA and sends again new data). When the data/addresses are written correct in the DDR3, they can be confirmed by the Tera Term monitoring (see Figure 1).
The only known data are the inverted x“13D813D8” at the position 1 (1h) and that at position 0 (0h) it is always coming “00000000”, as it shown in Figure 2. The x“13D813D8” are the last data the MPC sends. Then it reset the ECU and starts again.
After some loops (different time of loops every time) and after the MPC resets the ECU FPGA; the DDR3 read wrong data and the loop stops.
Note: The Signal Tap always shows the correct data and addresses, no matter if the wrong data are written in the DDR3 (Tera Term).
The different cases of DDR3 error readings are:
Most of the times, the data/addresses come correct when I reset the Soc FPGA through the Tera Term (see Figure 6), but this is not a solution.
Checked
I have some problems with a FPGA/HPS – DDR3 interface and I could probably use some help from people who have experience on this kind of interferences. I think there is a problem between the HPS and the DDR3 interfere that appears after reset.
SOC FPGA – HPS
The SoC FPGA [Cyclone V - 5CSEBA5U23C7S] contains a (High-Speed Sync) HSSRx and a Streaming component. The HSSRx receives the serial 64MHz data from the ECU and drives the data to the Streaming in parallel (means that the HSSRx use a s/p shift register) additional to a single bit signal, the Valid signal. The Streaming takes the parallel data and with the use of State Machine creates an Avalon-MM interface with the HPS for the Valid data, at the frequency of 100MHz. Then the HPS interfere with the DDR3 (400MHz). With the use of terminal emulator, Tera Term, the DDR3-1600 [IS43/46TR85120AL] is monitored.
Testing
The test environment I have created is the that a Microcontroller (MPC) tell the Master (ECU) to send different data on specific addresses to the SoC FPGA. The SoC FPGA passes the data/addresses to the HPS (which I read from the Signal Tap). The data/addresses arrive in HPS,and then to DDR3(which I read from the Tera Term), read back from the MPC (through the Soc FPGA, back to the ECU and then to MPC). MPC compares the data/addresses have been received from the HPS with those that originally sent. If the received data/addresses are the same with those had been sent, then the MPC resets the ECU FPGA and the process starts again. This process goes for ever until the MPC reads different data/addresses of those MPC original sent to the HPS/DDR3.
The whole process goes around for some loops (loop: MPC reads back correct data/addresses, resets ECU FPGA and sends again new data). When the data/addresses are written correct in the DDR3, they can be confirmed by the Tera Term monitoring (see Figure 1).
The only known data are the inverted x“13D813D8” at the position 1 (1h) and that at position 0 (0h) it is always coming “00000000”, as it shown in Figure 2. The x“13D813D8” are the last data the MPC sends. Then it reset the ECU and starts again.
After some loops (different time of loops every time) and after the MPC resets the ECU FPGA; the DDR3 read wrong data and the loop stops.
Note: The Signal Tap always shows the correct data and addresses, no matter if the wrong data are written in the DDR3 (Tera Term).
The different cases of DDR3 error readings are:
- Misalignment: Where the known data (x“13D813D8” ) are written in the third position (2h address) and position one I filled with unknown data. Some of the rest of the data are coming on correct address, when other disappear or have been moved to the next position (see Figure 3).
- Frozen Data: where the same data appears in different addresses (see Figure 4).
- Zeros: Where nothing is written in the DDR3 as the HPS returns a constant high avm_master_waitrequest (see Figure 5). In this case, I tried to set the avm_master_write to ‘0’ after some time (hence it does not stay high at all time), but it did not help.
Most of the times, the data/addresses come correct when I reset the Soc FPGA through the Tera Term (see Figure 6), but this is not a solution.
Checked
- The PLL that drives the HSSRx is settle before the Streaming process starts. ECU starts the process after the SocFPGA PLL locked signal is ‘1’.
- The reset and the 100MHz clk of the Streaming are coming from the HPS so are synchronised.
- When the “HPS-to-FPGA use clock” is reduced, the slack is increased. Hence I left it at 100 MHz.
- Any addition of pipelines increases the slack.
- I had a timing failure (slack) on the 100MHz clock which is driven from the HPS to the Streaming. I reduced the frequency of the SDRAM DDR3 from 400MHz to 360MHz (PHY Settings/Clocks/Memory Clock frequency to correct the violation. Did not solve the problem though.
