Hello, I have a similar problem to what has been mentioned in this post:
https://community.intel.com/t5/FPGA-Intellectual-Property/Avalon-MM-slave-burst-problem/td-p/202007
Unfortunately, it doesn't seem as if the issue was fully answered.
When the amount of data, that the MSGDMA is supposed to read via the Avalon-MM master, is larger than what the burstcount is able to process, the MSGDMA sends out two or more read requests (read = 1) . The same thing happens when the amount of data is not aligned with the data width of the streaming interface. E.g. the data width is 64 bit and the amount of data supposed to be read is 65 byte the MSGDMA sets read=1 and burstcount=8 for 1 clock and read=1 and burstcount=1, also for 1 clock. This behaviour seems ok to me.
But the Slave BFM does not answer to the second read request. The Slave BFM only answers to the first one, that requires 8*64 bit to be sent. Therefore the MSGDMA never sets the EOP and the CSR_IRQ for this transaction, because only 64 of the 65 byte really arrive.
I am using the Avalon-MM Slave BFM the same way it is done in the avlmm_1x1_vhdl example in the Avalon Verification package found here:
https://www.intel.com/content/www/us/en/programmable/support/support-resources/design-examples/design-software/simulation/exm-avalon-verification-ip.html
(Except that I removed the functions for the expected command and the verify command part, but it didn't change the behaviour at all.)
I have attached a screenshot showing the behaviour of the Avalon-MM master of the MSGDMA IP core in thix exact situation.
As you can see, the slave does react to both the 8-Word read requests, but not to the 1-Word read request at the end. (My testbench doesn't change/increment the initial data value 0x06060505 while bursting)
Does anyone have an idea where this behaviour is coming from?
Best Regards,
Florian
Link Copied
