• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 100 subscribers
  • Views 1011 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

DDR collision problem

woodyiy
Intellectual 310 points
Other Parts Discussed in Thread: TMS320C6678

Hello,everyone,

I am now working on one custom board whose architecture is TMS320C6678 + FPGA. The DSP needs to communicate with FPGA via the SRIOx4 interface, and I store the received data which come from SRIO in DDR, meanwhile my DSP corepacs need to access the stored  data in DDR frequently.In this case my SRIO interface on the FPGA usually stops transportation, The phenomena is that the signal tready which comes from DSP is pulled down and can't retrun to normal. The SRIO on the FPGA endpoint runs on the Streaming Write mode. we find the reason is because of the collision of DDR access. Then I found the information In the document sprugw1.pdf, chapter 2.1.1 which says as follows:

2.1 Overview
2.1.1 Peripheral Data Flow
This peripheral is an externally-driven slave module that is capable of acting as a master within the DSP chip. This means that an external device can push (burst write) data to the DSP as needed without having to generate an interrupt to the CPU or without relying on the DSP EDMA. This has several benefits. It cuts down on the total number of interrupts, reduces handshaking (latency) associated with read-only peripherals, and frees up the EDMA for other tasks.

This means that, the transport  started by FPGA  is supported. 

I hope to wonder How can I solve this problem? Can anyone give me some suggestions?

  • 0
    TI__Mastermind 18136 points

    Hi Eric,

    I recommend you have a look into the DDR3 User' Guide (SPRUGV8E). There are a lot of other places where you can set priorities in the SoC but I'd start with trying mapping the SRIO master ID to a class of service. That way you can prioritize SRIO accesses to DDR3 over CPU accesses ...

    From User's Guide:

    2.6.4 Class of Service
    The commands in the Command FIFO can be mapped to two classes of service: 1 and 2. The mapping of
    commands to a particular class of service can be done based on the priority or the master ID. The
    mapping based on priority can be done by setting the appropriate values in the Priority to Class of Service
    Mapping register. The mapping based on master ID can be done by setting the appropriate values of
    master ID and the masks in the Master ID to Class of Service Mapping registers.
    There are three master ID and mask values that can be set for each class of service. In conjunction with
    the masks, each class of service can have a maximum of 144 master IDs mapped to it. For example, a
    master ID value of 0xFF along with a mask value of 0x3 will map all master IDs from 0xF8 to 0xFF to that
    particular class of service. By default all commands will be mapped to class of service 2.

    Kind regards,

    one and zero

  • 0 in reply to one and zero
    Intellectual 310 points
    Hi one and zero,
    Thank you for your reply,I will have a try.

    Regards,

    Eric
  • 0
    TI__Mastermind 28085 points
    Hi,

    The KeyStone architecture is designed to maximize the total throughput of the device. It uses multiple internal buses and the many TeraNet switches that make up the total TeraNet traffic control design. This robust and high-speed design reduces collisions by getting more data pushed through from source to destination and by doing that more quickly than previous architectures. Anytime two or more bus masters try to access the same endpoint, whether it is a C66x CorePac or an EDMA3 Transfer Controller or a Multi-core Navigator transfer or an SRIO operation, there will be a collision. But the bus and switch architectures handle this collision by forwarding the memory read and write commands in an orderly process so every requested transfer will take place as quickly as possible and always accurately.

    The DSPMemSpeed test deals with collision on the DDR3 interface, since all TCs are writing to the same DDR3 interface. It also deals with collision on the MSMCRAM interface because all TCs are reading from the same MSMCRAM module. You can change the location of srcBuff by changing the DATA_SECTION macro to src_section1 (in a later version I will make these names more clear, like src_sectionL2) and see that the performance drops significantly. This is because of the collision of four TCs at a single CorePac's EMC port, and the speed of reading from a single CorePac's L2 through a slower speed TeraNet switch.

    Thanks,
  • 0 in reply to one and zero
    Intellectual 310 points

    Hi one and zero,

    I have read the DDR3 User' Guide (SPRUGV8E.pdf) , and have  realized the meschinsm of the command scheduler.But I still have some questions that make me confused.

    1  How to set the priorities of the read/write command ?

    2 Both the classes of service 1 and 2 have no priorities, their priorities are set by the register PRICOSMAP, am I right?

  • 0 in reply to Ganapathi Dhandapani95
    Intellectual 310 points
    To Ganapathi,

    Thanks for your reply! I am afraid that the DSPMemSpeed test you mentioned may be very helpful to my problem, but I have never seen that demo before. Could you please post your demo here?

    Thanks ,

    Regards,

    Eric.