This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Data transfer between DM6467 and FPGA

Other Parts Discussed in Thread: TMS320DM6467

I want to transfer video data between FPGA and DM6467 using vlynq, I want to know

1. How to connect FPGA and DM6467 using vlynq.

2. Does DM6467 has the vlynq drivers and is there any limitations.

3. From the application development perspective what are all the API's are available for configuring VLYNQ device and how to use them ?

4. How actually data is getting transferred (In laymen terms)... ETC

  • I can provide comments for some of the items below.

    Girisha SG said:

    1. How to connect FPGA and DM6467 using vlynq.

    Xilinx has an IP core for VLYNQ that can be integrated.  For Altera, you will need to ask them if they have it.

     

    Girisha SG said:

    2. Does DM6467 has the vlynq drivers and is there any limitations.

    I found the following site or here.

     

    Girisha SG said:

    3. From the application development perspective what are all the API's are available for configuring VLYNQ device and how to use them ?

    I don't have a comment here.

     

    Girisha SG said:

    4. How actually data is getting transferred (In laymen terms)... ETC

    There actually is a brief Wikipedia article on VLYNQ.  I would also suggest looking at the Peripheral User's Guide for VLYNQ found on the TMS320DM6467 Product Folder.

    VLYNQ is a point-to-point, bi-directional interface.  You can not have more than 2 devices on a set of VLYNQ signals.  If you need more VLYNQ enabled devices, you will need to separate VLYNQ interfaces on each device to create a daisy-chain.  This is not common, but technically can be done.

    The VLYNQ interface was designed to take internal bus transactions (reads or writes) from an internal bus master, like a CPU, DMA or other functional block that can initiate bus transactions, and convert these into command/response packets over a serial interface.  That is its fundamental purpose.  In addition, the VLYNQ interface has functionality to perform remapping of the address.  What does this mean?  The VLYNQ interface has up to 4 memory "windows" that you can use to communicate to the remote device.  The VLYNQ memory space on a local device (let's call the local device the DM6467 and the remote device the FPGA) is where you would be reading from and writing to in order to access data on the remote device.  The address where this VLYNQ memory space is on a particular device like the DM6467 is device specific.  The VLYNQ interface on the local device will translate this "local" address to the targeted appropriate remote address and send that across the physical interface.

    I do want to mention, however, that many individuals have been "surprised" or caught off guard by throughput speeds of VLYNQ when performing read transactions.  I bring this up now because it seems to catch people off guard and ultimately, if their software is not designed to comprehend this, it creates a lot of frustration.

    Why do I pick on read transactions?  First, we need to establish some level set on what happens in a CPU when it tries to read from a memory location.  While I certainly don't have exposure to every possible CPU architecture, in general, most CPU pipelines require the targeted read data to return before moving on to the next instruction.  That said, when the CPU initiates the read transaction on the internal bus, it will need to sit and wait until the internal bus comes back with data.  (I'm not going to argue if the data is correct or not, just that the bus transaction was signaled complete).  This is important to keep in mind when we think about how the VLYNQ interface is going to respond to that read transaction.  The following steps are performed by the VLYNQ interface when a read occurs.

    1. LOCAL DEVICE : VLYNQ peripheral is accessed in its memory window with a read request from the initiator.
    2. LOCAL DEVICE : VLYNQ indicates to initiator "not ready" to complete transaction and performs the address translation.
    3. LOCAL DEVICE : VLYNQ generates a Read Command request and sends this over to the remote device via the physical interface.
    4. REMOTE DEVICE : VLYNQ receives Read Command Request and performs its own read transaction on the internal bus in the remote device.
    5. REMOTE DEVICE : Read transaction completes (could be held up by wait states, if needed by the remote device) and a Read Response packet is created with the desired data.
    6. REMOTE DEVICE : Read Response packet is sent back to the orignal device.
    7. LOCAL DEVICE :  VLYNQ receives the Read Response packet and completes the original read transaction for the initiator.

    This is a high level view and I may have missed a couple of subtle steps but you should get the idea.  For most CPU architectures, write transactions are usually fire-and-forget as in they don't generally force the CPU to stall until the entire transaction to the end targeted device occurs.