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.

Keystone II EMIF timings to NAND FLASH

Hi,

I am using Keystone II (K2H, K2K, K2L). Processor speed is 1.2GHz, so EMIF clock period is 5nS.

I have connected a NAND flash to the EMIF, and I am calculating the EMIF timing parameters. (Setup, strobe, hold etc)

I can meet all the timing parameters for isolated read and write cycles, but I cannot achieve the appropriate delay from a read to a write or a write to a read.

For example, the NAND requires a 100nS delay from the end of a read to the beginning of a write (Trhw). This corresponds to 20 EMIF clock cycles. The TA field only allows up to 4 cycles for turnaround.

Another issue is that the DSP will start driving the data bus to a parked value when the EMIF is idle. After a FLASH read, the FLASH data bus is not tri-stated for up to 65nS. The DSP will therefore cause data bus contention.

How should I solve the above two issues?

  • Hi SimonPack,

    Can I get some addition information on your applications? Can you provide the part number for the NAND flash you are using? The EMIF interface does support access to NAND but at a very low level and sometimes these types of issues need to be solved in software. I'll check with the team here at TI and see how they addressed these issues.

    Regards,

    Bill

  • For the purposes of this email, lets assume I am using the Texas Instruments  TCIEVMK2L EVM card.

    This uses a Micron MT29F16G08ADBCAH4:C NAND FLASH device, directly connected to the EMIF.

    The parameters I have an issue with are tWHR>80nS, tADL>100nS and tRHW>100nS. I guess these could be met with extra padding in the software, but if the internal bus is busy, what prevends a write being delayed and clashing into a subsequent read (violating tWHR).

    Also, the FLASH has a tRHZ max of 65nS, so if the K2L were to park the data bus in less than this time after a read, contention could occur. I see no way around this.

  • Any progress with my question ?
  • Hi SimonPack,
    Sorry for the delay. As you have seen, the EMIF interface was not designed to support all the features of current day NAND devices. There is not a way you can ensure a 100nsec delay between reads and writes through the programming of the EMIF interface. To ensure that the delay is met, I suggest you use a dummy read to a different CS with the appropriate timing parameters to ensure there will be a gap between the read and write.
    The EMIF will park the data bus after the read cycle is complete. That read cycle includes the r_setup, r_strobe and r_hold portions. Since the NAND will stop driving the data bus a maximum of 65ns after the OE signal goes high, you will need to program the r_hold portion of the access to greater then 65ns. This ill ensure that the EMIF doesn't drive the bus before the NAND has released it.
    Regards,
    Bill
  • Hi Bill,

    Thanks for the response. This confirms what I thought, including the idea of making dummy accesses to a spare CS space.

    With regards data bus parking, are you saying that the Keystone II will start to drive the data bus to a parked value immediately at the end of the r_hold phase, and not respect the 4 cycles of turnaround that I have programmed?

    Increasing the r_hold from 2 cycles to 13 cycles will seriously cripple the FLASH read bust rate. Is there no way to turn off this data bus parking as it appears to be more of a hindrance than a help. What degree of data contention is acceptable?

    Cheers,

    Simon

  • Hi Simon,

    I've checked the internal design documentation and it is clear that the output enable control for the pins associated with the EMIF data is disabled until the end of r_hold. The turnaround doesn't have any effect on that. 

    There is no way to disable the bus parking. That feature is hard wired into the EMIF IP. I can't give you any degree of acceptable contention. If the memory and the EMIF are driving the bus at the same time, either could be damaged over the long term. 

    The EMIF interface wasn't implemented in K2 parts for bursting large amounts of data. There have been other E2E posts concerning the throughput of the EMIF device and the delays observed between single accesses. The interface was mainly included as a boot option. I would suggest you use the K2E to model the possible throughput you can expect using a NAND connection to the EMIF.

    Regards,

    Bill

  • Hi Bill,

    Its a shame the data bus parking mechanism doesn't respect the turnaround parameter, because I guess the prime purpose of turnaround was to avoid contention.

    One last question. Could you confirm that the parked value driven onto the data bus is the last write value. If it is the last value (read or write) then the contention issue would no longer be an issue. (i.e. the K2H would be acting as a bus keeper).

    Cheers,

    Simon