05-19-2017 08:04 AM
I have the following configuration:
Counter -> AXIS -> DMA -> AXI -> DRAM
Everything works well except the counter should start from 0. During configuration of the DMA module there are some '1' on TREADY line from DMA to Counter and the counter starts counting and putting data on TDATA lines. And these data acquired during configuration are also saved in DRAM.
This is basically my code:
You can see that the output at 0xA000000 starts with 0x4, 0x5 and so on.
Apparently there is a TREADY during boot-up or power on (cannot get with the ChipScope), and there is another TREADY during XAxiDma_CfgInitialize(&AxiDma, CfgPtr).
You can see in the LogicAnalyzer that the counter starts with 0x4 and than there is a gap between 0x04, 0x5, 0x5, 0x7, 0x8 and the rest of the data. Why? What am I doing wrong? Why not 0x0, 0x1, 0x2... and all of them in a compact package.
My final goal is to replace the Counter with a ADC Reading Module where I want to acquire exactly 1024 values with not time/clocks gap between them.
05-19-2017 08:35 AM
just had a quick look, here are a few ideas :
if you have an AXI4-Lite register added to your counter, you could 'hold' the counter and give it a command to start (and set TVALID to '1' after the DMA is setup).
also bear in mind that some IP (like DMA, fifo, ...) have some pipeline registers at the input / output. Though I think data shouldn't get 'lost' as in your case.
to see what happens at boot with your counter, can you trigger the ILA on the rising edge of the reset?
the gap in between is maybe due to some 'startup' of the DMA : it needs to arbitrate with the ARM cores to access DDR memory I think.
05-19-2017 08:48 AM
thank you for your reply! that is a great idea with using a HOLD signal for my counter. Also I can keep TVALID low during DMA Config and problem solved. I start with the ADC module and I'm going to use it.
I don't actually lose pulses. It's just that DMA Modules stores values during XAxiDma_CfgInitialize(&AxiDma, CfgPtr) and before setting the RS bit from DMA on '1' (Run = '1', Stop = '0') and also before Writing the Destination Address and Length of data. And I see this values later in RAM
05-19-2017 03:15 PM
your welcome, using an 'enable data source' is always useful when something is being initialized.
how do you know that the DMA stores dat during the XAxiDma_CfgInitialize? I cannot clearly see it in the screenshot, do you trigger on some signal that configures the DMA?
05-22-2017 02:19 AM
DMA Transfer starts from the Counter value 0x8
During Initialization the counter is 0x4 to 0x7.
You can see that the values stored in DRAM after the AXI DMA transfer (starting with address 0xA..00) contains also 0x4 to 0x7.
I implemented an Enable/Hold but it's still not working properly. The TREADY line remains in '1' so it's mostly the same behaviour.
My Questions still remains: Why does the DMA AXI Module put the TREADY Line on '1' before starting the DMA Transfer. It should set it on '1' when I write the destination address and the bytes number in the S2MM registers and not before.
PS: I use now a FFT between my counter and AXI DMA. The AXIS frames between counter - FFT - AXI DMA are split in 3. First: 4 clocks after a while 99 clocks and after another while 25 clocks.
05-22-2017 03:16 AM - edited 05-22-2017 03:17 AM
did you control TVALID from your data source? When it's disabled, it should set TVALID '0', then when you enable it should set TVALID '1'. In your screenshot, TVALID is '1' all the time, so as soon as the DMA controller sets TREADY high, data is transferred.
an axi4-stream data transfer takes place when TVALID and TREADY are '1' at the same clock cycle.
I don't know the details of the DMA IP, but the fact that the DMA transfer is not 'continous' and shows 'hick-ups' is probably related to arbitration on the AXI bus. Maybe someone else can shed a light on this. Or you could create a new post to ask why this behaviour can be observed. However I don't think that it's related to your proble.
05-25-2017 11:21 PM
>> Why does the DMA AXI Module put the TREADY Line on '1' before starting the DMA Transfer.
this is per axi spec. A slave can (ie is allowed to) always set tready anytime, specifically before seeing a tvalid. As the other poster says, a transaction happens when tvalid & tready are both active and having tready on before tvalid allows the transaction to happen one cycle earlier than otherwise: if the slave waits for tvalid before setting tready, the transaction would need to wait for tready to come ie would add one wait cycle.