HPC Memory Controller Write but can't Read

Usual causes for this are

1 - You have a clock that's not connected.

2 - You have a reset that's not connected or is improperly connected (logic high vs. logic low).

3 - The HPC controller is not coming out of reset because it can't initialize the RAM. Are you using a DDR controller?

4 - Are you running through a clock-crossing bridge? Did you verify that you are meeting all timing requirements?

Jake

1 - You have a clock that's not connected.

:confused:pll_ref_clk is a 100MHz clock being fed into the core. Core is configured for a half-rate bridge already so effective 200Mhz with 32-bit data. All other clocks are outputs so I have listed those as 'open' in the instantiations (aux_full/half_rate_clk, phy_clk, dll_ref_clk)

2 - You have a reset that's not connected or is improperly connected (logic high vs. logic low).

:confused: global_reset_n is connected to the system reset, which is also active low. soft_reset_n is tied to '1' in the instantiation because it is not being used.

3 - The HPC controller is not coming out of reset because it can't initialize the RAM. Are you using a DDR controller?

:confused: The HPC controller is the DDR2 controller. Are you inferring I need another controller? The interfaces that are created during the SOPC generate process are the correct ones for our DDR2 we are using.

4 - Are you running through a clock-crossing bridge? Did you verify that you are meeting all timing requirements?

:confused:No clock-crossing bridge in the system. According to Time Quest all constraints and requirements are being met.

pinscore

Okay a further explanation. The reason that things hang on the read is because a waitrequest signal is asserted and not being deasserted. You can write to the DDR2 controller because there is a FIFO. Have you tried performing a lot of writes to the DDR2 controller and seeing if that also causes it to hang? I suspect it just might once the FIFO fills up.

So it sounds like you believe you have all your clocks connected correctly. You may want to check to verify they are actually running.

It sounds like you believe all your resets are connected correctly.

Okay so# 3. No you are using the right controller. Here's the thing. The DDR2 HPC goes through a calibration sequence on startup where it tries to determine the proper alignment for DQ/DQS signals. If it fails to achieve this, it will essentially never accept transactions on its interface. One way to check for this is to look at the "local_init_done" signal from the core. If this signals is low, your DDR2 controller is not going to accept write or read requests. Again, you may be able to shove a few write commands into the FIFO before it fills up.

Now if this is occurring, it's because the controller is unable to properly interface to the DRAM on the board. This could be either because there is a physical problem on the board (layout, routing, assembly, whatever) or it could simply be that the parameters you gave to the DDR2 controller when configuring it weren't quite right. The third would be that things aren't meeting timing but you've indicated that Timequest thinks that is not the case.

The first thing I would do is peek at that "local_init_done" signal and see what it claims.

Jake

Jake,

Did a signal tap and local_init_done is asserted. Multiple writes work just fine.

ST shows the writes look great, all signals behaving as they should. On the reads though, as I indicated the, all activity stops the bus. Interesting observations though:

1. Correct data does appear on the read bus.

2. Local_read_req is normal operation.

3. Local_readdatavalid never asserts.

4. Local_ready, which my understanding is an invert of a slave waitrequest never deasserts during the first clock cycle of the read but stays asserted. My experience in other simulations is that there is always a single waitstate associated with reads.

I am doing simple basic read/write, 32-bit data, no bursting.

Thoughts?

Hmmm... Are you using HPC or HPCII? What version of the tools are you using? Are you using altmemphy or uniphy?

Jake

HPC...

We discovered a bug in the HPCII and Altera is working on it. We are also using the altmemphy.

I mis-read signal tap. The data never appears on the readdata bus. Immediately at assertion of the read, the cpu_data_master_waitrequest is asserted and never deasserted. The local_read_req is asserted for 2 sample cycles (nios system clock) and then deasserts, leaving local ready and cpu_data_master_waitrequest asserted.

?????

And what version of the tools are you using?

Yeah I'm puzzled. Is the cpu_data_master deasserting its read signal? It should not do that while waitrequest is asserted.

We are using quartus II 10.0 SP1.

No, the cpu_data_master_read is not deasserting...it stays asserted and doesn't budge