Forum Discussion

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

SGDMA debug

Hello,

I am trying to learn how to use SGDMA to transfer data to memory. First of all, I am trying to connect SGDMA TX directly to SGDMA RX and check results. You can find the source code ->here<- (http://www.codeupload.com/4051) (I've edited the code found on forum, so thanks the guy who provided it).

In order to check what is written to the memory, I've connected the SGDMA modules to ONCHIP memory (size: 32768 bytes) and enabled memory content reader on the on-chip memory options. You can see my connections ->here<- (http://i51.tinypic.com/1zz6fj5.png).

The problem is that this dma design doesn't work. The data I get is corrupted.

I've tried to disconnect cpu.instruction_master and cpu.data_master from onchip memory, then the memory start address goes to 0x00, but results are the same.

If I connect the DMA to the DDR memory, then the data passes correctly, Screenshot is ->here<- (http://i53.tinypic.com/2heak61.png).

Now why I get this situation:

either I try to read or write from/to onchip memory or DDR memory, the core always tries to read/write from/to address 0x800xxxxx. Obviously when it is connected to DDR ram it works, but when to onchip ram it doesn't. Why is this happening? Nios memory bus bugs? How can I check what is written to the memory? If I use only onchip memory for the whole system and DMA it also works fine, but I want a clear vision without Nios stuff in the memory.

Thanks.

55 Replies

Show More
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    Hi,

    Is it possible to cycle multiple descriptors using the mSGDMA park feature? For example, in a MM-ST and/or ST-MM configuration, if the descriptor queue has two descriptors, and then "park" the queue so it becomes a circular queue?

    It would be a good feature for ping-pong buffers, for example...

    Cheers,

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

    Unfortunately it doesn't have that type of functionality, my plans were to add a frontend that would provide this type of behavior instead using linked-list descriptors. If you set the park on multiple descriptors this is the type of behavior you should expect (assume the mSGDMA is sitting idle before these steps):

    1) descriptor# 1 has park bit set

    2) mSGDMA continues to keep reusing descriptor# 1

    3) descriptor# 2 has been written with the part bit set

    4) mSGDMA switches over to using descriptor# 2 until another descriptor is written

    With the existing hardware the only way to ping-pong between two buffers is that you need to keep writting the two descriptors over and over to the dispatcher. You could make a frontend hardware block that you write to the two descriptors and it manages stuffing the descriptors into the dispatcher. If you made this custom hardware master width the same as the dispatcher descriptor port issueing the descriptors should be really easy to do using a single write operation.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    --- Quote Start ---

    Unfortunately it doesn't have that type of functionality, my plans were to add a frontend that would provide this type of behavior instead using linked-list descriptors. If you set the park on multiple descriptors this is the type of behavior you should expect (assume the mSGDMA is sitting idle before these steps):

    1) descriptor# 1 has park bit set

    2) mSGDMA continues to keep reusing descriptor# 1

    3) descriptor# 2 has been written with the part bit set

    4) mSGDMA switches over to using descriptor# 2 until another descriptor is written

    With the existing hardware the only way to ping-pong between two buffers is that you need to keep writting the two descriptors over and over to the dispatcher. You could make a frontend hardware block that you write to the two descriptors and it manages stuffing the descriptors into the dispatcher. If you made this custom hardware master width the same as the dispatcher descriptor port issueing the descriptors should be really easy to do using a single write operation.

    --- Quote End ---

    Thank you for your reply! We have already implemented the descriptor recycler. I only proposed the circular FIFO as an enhancement suggestion. Who will be maintaining the mSGDMA moving forward, now that it will be pulled into the Altera Embedded IP suite?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    Someone other than me :) Altera will support the mSGDMA moving forward as an embedded IP just like the rest of the soft IP cores that are available in Qsys. I think the right approach is to have a frontend unit become part of the mSGDMA instead of trying to make the dispatcher handle this since the dispatcher is really designed to just execute descriptors in the order that it sees them. With a frontend that handles linked-lists then this becomes a more robust solution. This will also give similar functionality to the SGDMA that has been in Qsys for years except it's just an optional feature for those who want linked-list descriptor prefetching.

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

    Hello

    I'm also trying to learn how to use mSGDMA.

    Since the codes uploaded in the first, and second pages are no longer available I find it hard to understand the context. Is it possible for someone to reupload the codes just for learning purposes? This thread would've been the perfect starting point for someone trying to learn how to use the component.

    Apparently writing a program to control the mSGDMA requires more than just using the API given, seeing how you guys talked about allocating buffer using malloc and stuff...