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.

F28M35x - EPI GPmode throughput

Hello,

I've been working with the Concerto ControlCard to test the EPI bus performance. The EPI module runs in 8-bit GP mode, along with RD / WR / CLK signals (and no address bits), and perform a Non-Blocking read using TI's driverlib functions (no uDMA): EPINonBlockingReadConfigure() and EPINonBlockingReadStart(). When I read a few bytes and measure the behavior of the Read pin on the oscilloscope I see that the RD strobe is active on the alternating EPI clock cycles. I suppose this is caused by the RD2CYC bit that must be set according to the datasheet at all times when using GP mode.

In SPRUH22B a contradication is clearly shown if we compare Figure 19-15 with Table 17-12. In the image the RD strobe remains high throughout reading 3 consecutive data words. In the caption of the figure it shows that RD2CYC is set to 1! However, the description of the RD2CYC bit in the table states:

Reads are two EPI clock cycles, with address on one EPI clock cycle (with the RD strobe asserted) and data captured on the following EPI clock cycle (with the RD strobe de-asserted). The next address (if any) is in the cycle following.

So which part of the datasheet is correct? And is there any way to get maximal read performance on the EPI bus in General Purpose mode (i.e. reading data in a burst)?

Regards,

Bas

  • Hi Bas,

    In GP mode RD2CYC need to be set to '1' for proper functionality. With this configuration, Ist cycle will be address phase and data will be sampled on rising edge of clock in next cycle (when RD strobe is '0'). So RD strobe will be active on alternate EPI clock cycles (what you are seeing on oscilloscope), which is best case RD access time.

    The figure 19-15 is erroneous and we'll correct it. Thanks for pointing this out.

    Let us know if you have any further query.

    Regards,

    Vivek Singh 

  • Hi Vivek,

    Ok, I see. It's a pity the reads are not pipelined, as one or two additional cycle(s) latency would not have been any problem. Are there any other options/modes to achieve a better trhoughput using an 8-bit data interface? We require short cyclic updates of ~1 MHz with the transmission of a small number of read and write bytes that are fixed in length. I've looked into the other modes:

    -SDRAM seems to be able to burst data, but looks impractical as there overhead on the startup of the sequences and also requires additional pin connections/design effort in the FPGA.

    -Hostbus XFIFO seems a good alternative. But from what I understand, although being asynchronous uses 2 internal clock cycles per read/write as control/data signals are changed on alternating internal clock cycles. So this would effectively be just the same in throughput as the GPmode. Although, I find this hard to verify with the given timing diagrams. XFIFO timing Figure 19-11 doesn't match the description and the image shown is a copy of Figure 19-10. When compared to another EPI datasheet (e.g. Stellaris http://www.ti.com/lit/ds/symlink/lm3s1b21.pdf) Figure 10-11 of that datasheet seems to match a lot better. Is this also valid for the F28M35x?

    So a 2-cycle read seems the fastest possible burst?

    btw. The paragraph numbering seems one too deep, as both Hostbus and GPmode fall under section 19.6 "SDRAM mode".

  • Hi Bas,

    As you correctly pointed out, SDRAM is the only mode where data can be read in one cycle but it's got other overhead. Beside this, 2-cycle read in GP mode is the fastest burst. 

    Also the detail given in EPI datasheet for Stellaris are applicable to F28M35x as well.

    We'll correct such issues in next revision of user guide.

    Regards

    Vivek Singh

  • Hi Vivek,

    Ok, thank you for the help and clarification on this topic. Fortunately for us, alternating read cycles are just enough to achieve the required bandwidth.

    Regards,

    Bas