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.

TMS320DM368 to FPGA

Other Parts Discussed in Thread: TMS320DM368

Hello, I'm working on interfacing the TMS320DM368 processor to an FPGA containing a proprietary communication protocol over GigE.  The idea to use the TMS320DM368 DaVinci processor to capture a 1080p60 video signal encoded in H.264, which is then passed on to the FPGA for transmission over the GigE link.  The other end will receive the H.264 video stream at the other end of the GigE link and pass the encoded video signal from its FPGA onto another TMS320DM368 for decoding and output to a display.   

My question is how/where to connect the FPGA with the TMS320DM368 processor.  

One idea is to use the TMS320DM368's HPI interface.  The HPI datasheet ( http://focus.ti.com/lit/ug/sprufi4a/sprufi4a.pdf )  indicates the following: "HPI is pin multiplexed with Asynchronous EMIF (AEMIF) and General-Purpose Input/Output (GPIO) at the output pin. HPI is available only when bootmode selected is HPI boot mode. In this configuration, DM36x will always act as slave device."  This means the FPGA would be master device, while also needing to provide boot up info for the TMS320DM368. 

The other idea is to map the FPGA into the TMS320DM368's memory map and have the FPGA act as a memory interface.  In this way, a block of H.264 encoded video data could be written to the FPGA and once the block is written, have the FPGA begin transmitting the encoded data over the GigE link. 

I would consider the FPGA to be more of a slave device and the TMS320DM368 the master.  This means that the HPI solution would not be feasible.  The HPI interface is appealing however, as it seems to provide access to the internal and external memories, needed by the FPGA. 

Any ideas as to how/where to best connect an FPGA to the TMS320DM368 for the application in question?

Thanks alot!
Derek

  • Hello again, well, I believe I found a potential solution after searching through the forums and seeing what others have attempted:

    The solution is to connect the FPGA to the TMS320DM368 via the EMIF.  This will map the FPGA into one of the two 32MB addressable spaces via EM_CE0 or EM_CE1.  The FPGA will then act as a block of memory that can be written to/read from.  I'm hoping that a 32MB addressable space is large enough to accomodate the H.264 data.  I believe that it will be.

    If anyone has any further insights, please let me know

    Thanks!

    Derek

  • The approach you mention is what I would recommend.

    I don't know that I quite understand your comment about the 32MB addressable space.  I suspect your implementation in the FPGA will be some kind of ping-pong buffer scheme or FIFO implementation.

  • Hi thanks for the response.

    Yes, I'm also guessing that some sort of FIFO implementation in the FPGA to buffer the video data should do the trick. 

    As for the 32MB addressable space, perhaps some clarity is required here.  I guess it depends how the EMIF pins are mapped from the DM368 to the memory. 

    Looking at the datasheet for the TMS320DM368 http://focus.ti.com/lit/ds/sprs668b/sprs668b.pdf , under section 2.6 (Memory Map Summary) on page 16, table 2-4 (Arm Configuration Bus Access to Peripherals) there are two "regions" from 0x02000000 <-> 0x03FFFFFF (ASYNC EMIF Data (CE0)) and 0x04000000 <-> 0x05FFFFFF (ASYNC EMIF Data (CE1)) of size 32M each.  This is what I was calling 32MB adressable space.  Not sure whether this is MB or Mb...

    The EMIF datasheet http://focus.ti.com/lit/ug/sprufi1c/sprufi1c.pdf indicates the following: "SRAM on up to two asynchronous chip selects addressable up to 16 Mega Bytes with 16 bit and 8 Mega Bytes with 8 bit each".  I understand that the EMIF only supports 16 bit and 8 bit data widths. 

     

     

    The EMIF datasheet also gives an example of how to interface the EMIF to the Toshiba TC55V16100FT-12 device on page 34.  The TC55V16100FT-12 is a 16Mb SRAM, organized as 1M words by 16 bits.  By tying in the appropriate chip select line (CE0 or CE1), I assume this will map the SRAM into one of the two 32M memory spaces above. 

    Is my understanding here correct?

    Thanks alot for the confirmation on the previous issue!

    Derek

  • Derek Richardson said:

    The EMIF datasheet also gives an example of how to interface the EMIF to the Toshiba TC55V16100FT-12 device on page 34.  The TC55V16100FT-12 is a 16Mb SRAM, organized as 1M words by 16 bits.  By tying in the appropriate chip select line (CE0 or CE1), I assume this will map the SRAM into one of the two 32M memory spaces above. 

    Is my understanding here correct?

    Yes, this is correct.  The device will be mapped into either the CE0 or CE1 space, depending on which you connect to it.

    Not to offer additional confusion, but the datasheet indicates a possible address reach for each chip select (CE0 and CE1) of up to 32M each.  However, the number of address lines available on the boundary of the device will dictate the actual reach available by the device.  The IP block used for the EMIF may have support for a larger address reach than what the device pins out.  Just verify this with the datasheet accordingly.

  • Hi again,

    I forgot to mention that we have the DM368 Evaluation Module.  I stumbled on a parts list for the eval board this morning, which led me to Spectrum Digital's website.  On the site, I managed to locate the reference design files for the eval kit, located here: http://support.spectrumdigital.com/boards/evmdm368/revg/ After finding the reference design files, it became alot clearer as to how the design works. 

    The DM368 has two EMIF ports, one dedicated to the DDR.  The other EMIF has two seperately addressable regions called chip enable spaces (CE0 and CE1).  The NAND flash, OneNAND and CPLD are mapped into these chip enable spaces.  The board features 2Gbytes of NAND Flash mapped into CE0 space, configured as 8-bit.  There is also128Mbyte of OneNAND mapped into CE0 space as well, configured as 16-bit.  There is also the dedicated 128Mbyte of DDR2, 16-bit.  The CPLD is mapped into CE1 memory space.   Can't use NAND and OneNAND at the same time. 

    So, I guess the FPGA in question will mostly likely get mapped into CE1 space. 

    Thanks again

    Derek

  • Great thanks Brandon!  Your insights have been greatly appreciated!

    Best Wishes

    Derek