Avalon-MM slave burst problem?

[Altera_Forum]

I set up a simulation to test the Altera mSGDMA core (two instances, one MM -> ST and the other ST -> MM, looped through an Avalon-ST FIFO on the ST side) and used BFMs on all of the mSGDMA MM interfaces (master BFM on CSR and descriptor interfaces, slave BFM on the read and write MM interfaces). 

 Shout out to Dave Hawkins for his extremely helpful tutorial and reference design for using the BFMs:  http://www.alteraforum.com/forum/showthread.php?t=48928&highlight=  I had problems in simulation if the mSGDMA transfer size was larger than the maximum burst size. One example was with a transfer size of 4096 bytes and a maximum burst size of 64 beats (1024 bytes with a 128-bit data path). In that situation the MM -> ST mSGDMA engine issues 4 1024-byte read requests to the slave BFM very close together (the BFM queues them up internally). The first 1024-byte burst comes out of the BFM correctly but then the interface hangs (the last three bursts never happen). I did not spend a lot of time trying to debug this but I could see that the requests were queued up inside the BFM. The last three just never got serviced.  Transfers would only complete successfully in simulation if the transfer size was <= the maximum burst size so that only one read command was issued to the BFM per transfer. Interestingly, we saw similar behavior in hardware (Arria 10 SoC dev kit). The Linux page size in HPS memory is 4096 bytes in our system so we were trying to do 4096-byte mSGDMA transfers. These did not work in hardware or in simulation until I made the maximum burst size 256 beats (4096 bytes).  Has anyone else see this kind of behavior? At this point I don't know if it's a BFM problem or a real problem in the HPS. The downside of making the maximum burst size 4096 bytes is that the mSGDMA requires its internal data path FIFO to be at least 4x the maximum burst size, so each instance of the mSGDMA has a 16kB internal data FIFO (each FIFO consumes 9 M20K RAM blocks). I would prefer to keep the max burst size at 64, but so far that has not worked.  The attached zip file has screen grabs of the mSGDMA settings.  Thanks, Bob

[Altera_Forum]

--- Quote Start ---   Shout out to Dave Hawkins for his extremely helpful tutorial and reference design for using the BFMs   --- Quote End ---   Thanks! Beware that I got the BFMs working "well enough" for my application. It is quite possible that I did not turn on some feature that your design would rely on.  I'd recommend filing a service request with Altera and send them your testbench. Maybe you'll get lucky and someone will be able to take a look.  Cheers, Dave

[Altera_Forum]

Hi Dave - 

 Yes, an SR is the next step (always reluctantly - I've had very mixed results with SRs over the years). When I started this effort I let Qsys generate the testbench and instantiate all of the BFMs, but I got errors when vsim loaded and ran the testbench. I filed a SR for that one. Ends up the problem was that Qsys generates a verilog testbench but the BFMs use system verilog features, so it's broken right out of the box. I should have caught that myself but the ModelSim error message was pretty cryptic and I have never used system verilog. Easy fix by changing the file extension from .v to .sv and editing the msim_setup.tcl script to compile the testbench as a system verilog file. But by the time I got that response to the SR (several days later, which is one of the problems with SRs) I had already moved on to your method of including the BFMs in the Qsys system and then writing your own sv testbench. Your tutorial saved me a ton of time figuring out how to set up the testbench and use the BFMs. Thanks again!  Bob

[Altera_Forum]

--- Quote Start ---   Your tutorial saved me a ton of time figuring out how to set up the testbench and use the BFMs. Thanks again!   --- Quote End ---   Glad to help!  Cheers, Dave