03-11-2019 01:57 AM
Hi I am using the MCDMA IP to transfer arrays of data across serial bus.
We have designed a hardware accelerator that manages BD chains for the MCDMA SG port using DP ram. It is unclear how to "reallocate" a BD chain.
The state machine does the following:
Set CH1 CD
&(0x48) <= 0x0
Set CH1 FETCH (Cannot unset this)
&(0x40) <= 0x1
&(0x00) <= 0x1
&(0x50) <= 0x40
Can see that it completed...
The mcdma registers also report a complete packet:
What is the appropriate way to get the CD register back to the top of the map? Any way I try to get the CD register back to 0 results in an error. I need to hammer a specific location in DRAM. Is BRAM not an adequate medium to hold the BDs? Does our accelerator need to be an AXI SG target and respond with the locations in RAM that have the current information being transferred?
Thank you -
03-11-2019 02:17 AM
So I gave it one last shot before headin home - The following sequence works. Please tell me if there is a better way, this one seems overly complicated:
1. Assert MCDMA.RS
2. Clear the CH.FETCH bit
3. Clear the TD Reg
4. Clear the CD Reg
5. Clear the Status regs in the BD Chain for each BD completed
6. Set the CD Reg
7. Set teh CH.FETCH bit
8. Set MCDMA.RS
9. Write the TD reg
I also was able to get this to work:
in a single BD, set SOF & EOF.
In the CH/MCDMA regs:
1. Set the CD
2. Set the Fetch bit (CH.RS = 1)
3. Start MCDMA (MCDMA.RS = 1)
4. Set the TD Reg to 1byte past the start reg,
the CD reg stays at the start location
5. Clear the status result in the BD Ram.
6. Set the TD reg
Doesn't allow you to build a packet from multiple locations though. Works for our application but seems wonky.
I would still appreciate any insight in how to get a cyclic like behavior out of MCDMA and I'd really like to use a hardware BD manager for determinism.
03-18-2019 10:48 AM
Okay - No-one has picked this question up to advise a better solution. My dirty work around was to ground wdata so that the MCDMA is unable to write the completed flag in the BD buffer. Hopefully this is unnecessary techincal debt and someone at Xilinx can respond with a more future proof solution.