Avalon MM templates in Qsys

You have to make sure you don't write data into the FIFO when it's full. There should be an output to tell you when it's full. When full you should continue asserting the data and write signals until the FIFO leaves the full state (i.e. some data was removed from the FIFO because it was written out to memory).

That's it...... it's literally standard Avalon-ST handshaking except the signals have different names than 'data', 'ready', and 'valid'. If you time your signals properly then the data should be written into the FIFO correctly.

--- Quote Start ---

I've now tried writing my own simple Avalon MM master component to write and read a single word of data from DDR2 memory using the Altera high performance memory controller.

During the write transaction, the memory controller core does not assert waitrequest and it appears as though the write transaction completes according to the Avalon MM spec. However, the memory controller does not exert mem_we_n or mem_cs_n.

During the read transaction, the memory controller asserts waitrequest in response to the read signal and it remains high indefintely and doesn't complete the transaction.

I guess I'm doing something wrong in either the verilog control code or the qsys configuration. I would really appreciate it if anyone has time to look at the attached files and offer any advice.

Thanks,

John

--- Quote End ---

Hi,

I've run into the same (similar) problem with trying to use QDRII SRAM interface (AValon-enabled) in Qsys with Aletra's MM master read/write templates. The sims run correctly, but when I go to hadware, write transactions complte OK, but reads never return (control_done signal goes low upon asserting 'go' and never goes high again). I take it that the waitrequest from the fabric is staying high. Any clues?

The fifos are defined size 32 (someone had an issue with size '4'). In the sims the interface takes a while to complete calibration. Is it possible the same happens in real life, i.e. calibration never succeeds?

I'm using straix iv 100g dev board.

Thanks

It's possible that there is a memory problem and as a result the memory controller fails to calibrate and the waitrequest will stay high. Perhaps throw signal tap on the slave interface to see if waitrequest is stuck (trigger on read or write).

Another possibility is that your design isn't meeting timing. Have you ensured that it is meeting timing?

The calibration time in the simulation is similar to how long it takes to calibrate the memory in real hardware.

Thanks BadOmen

Here is what I can say :

1) The phsyical memory and the interface are likely to be OK: the FPGA kit comes with its own verification design and a test app program to control it. When I ran the board test applicaiton it was able to read/write successfully from/to the QDR SRAM.

2) Aslo, the design is constrained and meets timing - no warnings etc..

Actually, nither read nor write work. When I do a 'write', control_done is asserted (lookijng at signal tap), but wait request goes high and stays high, so that when I do a seocnd write request, the 'control done' goes low and does not go high again.

For the read operaiton, I never get 'control done' back and wait request to the read master also gets asserted indefinitely.

Anythie else you can suggest?

Thanks!

Try signaltapping the write and read master interfaces and trigger on the read and write signals. It's possible that they are issuing an incorrect access to the memory causing problems. The memory controller will only work if the master issues read or write transactions that are within the Avalon-MM spec (i.e. could be a master bug).

Once you get it captured attach the file to this post or take a screenshot with the first read/write captured and zoomed in on. I should be able to look at it and tell you if the master is staying within spec on the first access.