Avalon-MM Master reading

[Altera_Forum]

Hello, 

I am trying to run Avalon-MM master to read data from memory chip, so I've written a code accessible here: http://paste.org/41475  When I try to count data when readdatavalid is asserted, the counter doesn't work (even doesn't start to count) and the FSM is stuck on state "end_read".  When I disable the readdatavalid signal check (code part 2), then everything works ok, but the counted data is wrong, since readdatavalid signal sometimes is deasserted by the interconnect. The counter then fills up before the valid data ends and goes to the first state again - all the data after counter fill up is lost.  Why the counter doesn't work, when readdatavalid is asserted? I suppose this is the issue of the first read cycle. I can see write master writing data to the memory, so I am sure about mem_write signal as it is also goes until the last state and stucks there waiting for readdatavalid signal to comeup.  I can't catch signal in SignalTap to check what's happening on the very first FSM cycle when I assert read signal, but it should work fine as the FSM is trivial here.  I am out of ideas :(

[Altera_Forum]

Hi, 

Is there a pipelining in your memory ? The lock might mean that the asserted read doesn't guarantee that you actually read datavalid on the bus. so when waitrequest is deasserted, the datavalid is low and your counter doesn't count. (It's just an assumption). all this is a bit tricky to manage the bursting access. In Qsys, it's automatically done for you by setting the burst count in the slave access arbitration (right click, show arbitration). Hope this helps...

[Altera_Forum]

Well I assume what is happening: 

I assert read and wait until waitrequest goes down, then I wait for readdatavalid, but it never comes up. Now I've done a watchdog that waits if valid data wasn't received then asserts read signal once more. This solved the situation, but thats rather workaround than a solution.  I'm still using SOPC.

[Altera_Forum]

Yes, it seams like a work around. 

While waitrequest is asserted, read signal should not change. Couldn't get if you respect that. read request and readdatavalid are quiet independent unless you make assumptions about the pipelining of the slave and its response. If what you intend to do is working, then it's fine.If you want more variants, I used to lock the arbitration in SOPC till the master got what it needs. But I wouldn't advise it as the burst is much safer as arbitration...

[Altera_Forum]

Well I agree that bursting should solve the problem more safely, than locking the arbitration.  

I assert burstcount, address and read signal until waitrequest is 0 - everything within' specs here.

[Altera_Forum]

Hard to tell what's going wrong here without seeing what is controlling the memory writing. The read statemachine looks safe to me so I wonder if your logic is issuing a read and write simultaneously since that could easily cause the readdatavalid to never return. I highly recommend you simulate your logic since that would make it really easy to find a simultaneous and other bugs. 

 I would also evaluate whether or not it would be easier to split your reading and writing into separate masters.

[Altera_Forum]

The problem solved and the system works fine. 

I've made separate writing and reading masters. Writing master writes using simple write (write assert on data valid and provide data+address). Reading master use bursts. However I had to add watchdog counter for data loss somewhere in the session beginning: I wait for readdatavalid to go high, then count the packets, but somehow, the first read signal assert doesn't return me data in some time I have to reassert read signal again. This only occurs somewhere after fpga image upload and never in the future.

[Altera_Forum]

FPGA image upload. Do you mean the bug only happens for the first read or are you downloading Nios II code? If you are downloading code maybe your system is being reset. 

 Another thing that could be happening.... are you reading from DDR SDRAM by any chance? Those memory controllers perform a calibration cycle after reset and it takes a while (150us I think....) So perhaps your master is reading from that memory and it's just taking a long time due to the controller performing calibration. The easiest way to find this out would be to remove any watchdog type features and make your hardware perform a single read. If the calibration is holding things up then your read will return around 150us later.

[Altera_Forum]

No, I use SDRAM. However if I remove that watchdog counter, the reading master gets stuck in the state after read signal assertion, waiting for readdatavalid to go high. Since readdatavalid never goes high, all the logic after this part stops working. I know I had to simulate the design, but I was too lazy to write a testbench after I came with this workaround. 

 I've also wasn't able to catch that situation with signaltap, since it occurs very fast, but there were no other logic explanations, since the only check for the current state was checking for readdatavalid to go high.  Now I see readdatavalid to go high in about 7-12 clk cycles after I assert read signal for one cycle.

[Altera_Forum]

If your master is fairly well self contained you might not need to write much testbench code. If it takes Avalon accesses to your core to start it up I would recommend using a bus functional model to start it up. Based on what you described I would suspect there could be a problem with the logic leading up to the first read. I would be careful since if your master is not following the spec due to a bug you could run into a really tricky corner later down the road that would be hard to debug. The fabric doesn't have much or any logic to 'fix up' the fabric after a master or slave violates the spec and those are some of the trickiest issues to debug from my own experience without simulating the system.

[Altera_Forum]

Well it's a simple state machine: avalon-mm read master. (http://paste.org/42242) 

You can see the end_read state counting valid and invalid packets.  Nothing fancy here, but this solution works. The data is read from SDRAM and moved to DCFIFO.