Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
11 years ago

Modular SGDMA - Streaming to Memory Mapped Random first write.

Hi,

I am using the Modular SGDMA to write memory into DDR3 memory, and then a second one to read it back out again. The reading is all working fine and writing into the memory works as well, except there is one minor glitch.

Basically when I issue a descriptor to write a given number of symbols to, say, address 0 (the burst length is 16 and I'm using a 512bit wide data bus).

Then, Symbol 0 arrives via Avalon-ST. It immediately gets written by the SGDMA to address 0xFFFFFFFF.

The next arrives and it gets queued up in the FIFO. Once symbol 16 arrives, there is a burst write of 16 symbols to address 0x0.

Essentially this means the first symbol to arrive for any descriptor appears to get written to 0xFFFFFFFF, and then the remaining symbols get written to memory one address earlier than they should, thus the first symbol is lost and the rest are shifted from where they should be.

Any thoughts on why this is happenning?

Thanks.

EDIT:

I'm using a Stratix V DSP board and Quartus 14 Subscription Edition, have SignalTap set up to look at important parts of the SGDMA controller and data input. Also the design meets timing comfortably.

19 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    I've been doing some tests and can see that the following work:

    (1) NIOS generates descriptor (not using supplied driver).

    (2a) First 32 bit is written to controller (read address) - this is set to zero as it is a write controller and doesn't matter. Byte Enable = 0x000F

    (2b) Second 32 bit chunk of descriptor written (write address) - trying say 64 (which is an aligned address). Byte Enable = 0x00F0

    (2c) Third 32 bit is written (length) - this is set to 0x480000 which is how much I want to transfer. Byte Enable = 0x0F00

    (2d) Fourth 32 bit word written. I have bits 8,9,12,24 and 31 set. Byte Enable = 0xF000

    - All of those transactions have been checked in signaltap and I can see the correct data and byte enables being sent along with the write signal being asserted correctly.

    (3) I can see the SGDMA dispatcher issue the write descriptor, but it seems that the data that gets sent to the write master via the write commands source port is basically just a whole lot of 1's (apart from the 'park writes' and 'transfer complete IRQ' bits which are 0).

    For clarification I have the following settings for the IP core:

    Streaming to MM

    Packet Support = Disabled

    Max Write Length = 512MB

    Descriptor FIFO = 8

    Data FIFO = 64

    Burst Count = 16

    Forced Burst Alignment = True

    Burst Enable = True

    Transfer Type = Full Word Accesses Only

    Data Width = 512

    Response Port = Disabled.

    No idea why the dispatcher is turning my descriptors into garbage when the descriptors bus at the input is presenting the correct data/control signals.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    Interestingly, despite the fact I have the 'Length' parameter set to 512MB, Quartus synthesizes away bits [31:16] of the length signal in the descriptor FIFOs.

    EDIT:

    QSys for some reason put a length signal width of 16 in the generated source file instead of 30. I've tried regenerating the QSys system, but each time it sets the 'LENGTH_WIDTH' parameter on the write_master to 16?!? Is this a glitch in QSys?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    I've also noticed from the signalTap traces, that for some reason, each time I write a 32bit symbol to the descriptor (with the correct byte enables set to 0), the other bytes in the descriptor get overwritten with 0xFFFFFFFF, even though the byteenables shouldn't allow that to happen. As a result the descriptor is getting corrupted by the time it leaves the dispatcher.

    Any suggestions why this would be happening?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    I think I have worked out the problem. In the fifo_with_byteenables module in the dispatcher, there are MLAB cells inferred for the FIFO. Each of these has a byteenable, but they are registered inputs. If the Avalon-MM interconnect to the descriptor input sets up the byte enable signal at the same time as the write signal, the write is going to reach the MLAB cell one clock cycle before the byte enables reach it (because they are pipelined). If I am not mistaken this means that the MLABs will write the data before it is properly masked causing corruption.

    Or is there something here I am missing?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    Hi TCWORLD,

    I haven't used the Modular-SGDMA controller, so cannot comment on what you are seeing, however, I can recommend that you create a Qsys system with this component and an Avalon-MM BFM, and then create a testbench that contains exactly the transactions you are debugging, so you can reproduce this "error". At that point you can submit a Service Request to Altera directly, or if you post a zip file with a complete simulation here, someone familiar with the IP core may take a look at the problem.

    If you have never used the BFM before, I've posted examples, eg., go to post# 25 in this thread

    http://www.alteraforum.com/forum/showthread.php?t=32952&page=3

    Cheers,

    Dave
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    Sounds like a good idea. I'll build a testbench tomorrow (I'm familiar with the BFMs, so shouldn't take too long to test).

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    Hmm, it seems to work fine (exact same setup) in simulation, but not in implementation.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    --- Quote Start ---

    Hmm, it seems to work fine (exact same setup) in simulation, but not in implementation.

    --- Quote End ---

    At least that tells you something ... :)

    Are you able to compare all the Avalon-MM signals from SignalTap II traces with exactly the same traces from the simulation, i.e., probe the bus signals at the SGDMA controller, rather than at the BFM, just in case the Avalon-MM fabric has the bug ... but its not affecting your simulation for some as-yet-undetermined reason?

    Cheers,

    Dave
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    I've been probing in signalTap and modelsim the signals directly at the SGDMA block. They seem both the same where it matters (i.e. there are don't cares in the simulation which have some value in signaltap).

    It seems that the problem is when the MLAB cells for the 'fifo with byte enable' block have their ena signal high, but their portabyteenamasks signal low, for some reason the contents gets written to 0xFFFFFFFF. But the same cells for a second SGDMA controller in the design (MM->ST one) are the same MLAB type, but work fine.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    Interesting, I increased the command FIFO depth from 8 to 32, and the problem appears to have miraculously fixed itself. Will do some more testing to check it is definitely working.