EMIF read timing

Hi Michael,

Though the customer is reading the timing parameter correctly, I think they are not interpreting it in the right way.

The Read Strobe (RST) is set (R_STROBE value programmed in the EMIFA Async registers) based on some Chip Select-to-output delay spec of the device from which data is being read. This translates to the length of time that EM_OE_N is driven low. This can vary from the expected RST*E (where E is the EMIFA clock cycle) by 3 ns due to process and other variations in our devices.

Input data is latched just before this signal (EMA_OE_N) goes high (as indicated by the 0ns hold time requirement - parameter 13 in Table 5-23). We do specify a setup time requirement of 3ns to 7ns depending on core voltage used - parameter 12 in Table 5-23.

In Select Strobe mode, customer should make sure to set RST so that the worst case, RST*E-3 ns period meets  delay requirements of the device such that the our setup time requirement  is met. The interfacing device can stop driving the data lines immediately after EMA_OE_N goes high.

Hope this clarifies the customer's concern.

Rgds,

Sunil

In the OMAP L138 Tch Ref Manual at Table 20-21 (#2) and in  Figure 20-12 it implies that both CSn and OEn are synchronous with EMA_CLK.

During an Async Read Cycle in Select Strobe Mode, the processor needs 0ns of hold time (after rising edge of EMA_CLK). This requires OEn and CSn that enable this read to the responding device to occur on or after the clock edge (at least 0ns).

Where is the minimum clk-to-out for CSn and OEn defined in the processor datasheet? I cannot solve this timine analysis without this information.

thanks,

Jim Peterson (Honeywell)

thanks. We need to exactly quatify this with a minimum time for OEn and CSn going high relative to the EMA_CLK.

I appreciate you saying that we can stop driving the data lines immediately after EMA_OE_N goes high, but we design safety critical products so we have to see this as timing parameter in a published datasheet.

Bsically we are doing a read operation that ends when OEn and CSn go high, anI may have missed it, but I don't see the timing relationship between the OMAP sampling clock (EMA_CLK) and OEn and CSn defined in the datasheet.

 Jim Peterson 

Hi Jim,

jim peterson said:

During an Async Read Cycle in Select Strobe Mode, the processor needs 0ns of hold time (after rising edge of EMA_CLK). This requires OEn and CSn that enable this read to the responding device to occur on or after the clock edge (at least 0ns).

Bsically we are doing a read operation that ends when OEn and CSn go high, anI may have missed it, but I don't see the timing relationship between the OMAP sampling clock (EMA_CLK) and OEn and CSn defined in the datasheet.

Yes, OEn and CSn are synchronous to EMA_CLK internally, but interface between between the external memory and EMIFA is asynchronous and a clock is not part of the actual connections. As a result, all specified timings are required to be relative to the signals used in the interface and not a clock.

For a Select Strobe read operation on this async interface, the external memory will go by CSn being asserted (EMIF releases bus with OEn being asserted) and output data based on its internal delay. User has to set Read Strobe such that this delay + EMIF required setup time is covered by the strobe cycle. At the end of the strobe cycle, the data bus is latched and the OEn and CSn is deasserted which will signal to the external memory to stop driving the bus.

As you can see, the external memory does not work off of the EMA_CLK, so specifying timing with respect to it does not make sense.

By any chance, are you using the EMIF to interface to a custom device and not a standard memory device (NOR/NAND flash)? I apologize if I am not understanding your request correctly, but right now I do not see why timing spec w.r.t. EMA_CLK will be needed otherwise.

Rgds,

Sunil

thanks for the reply...we're getting closer. and yes, this interface is to a custome device (FPGA).

In the Tech Ref manual, Figure 20-12 and Table 5-24 it says that OEn and CSn are related to EMA clock...quote : "On the rising edge of the clock which is concurrent with the end of the strobe period : CSn and OEn rise".

The reason we're concerned is that OEn and CSn go high on the same clock edge (EMA_CLK) that the processor clocks in the read data....so what happens if the clk routing to OMAP OEn flipflop is faster than the clk routing to one of the OMAP data bit flipflops?...if this occurs then it's possible that OEn tells us to tri-state the databus before the OMAP L138 clocks the data in. This is why we need to quantify the relationship.

If you can show me somewhere where it states that OEn and CSn go high after read data is clocked in then we have a solution.

thanks again. Jim Peterson

Hi Jim,

Thanks for clarifying your concern. It is clearer to me now.

jim peterson said:

If you can show me somewhere where it states that OEn and CSn go high after read data is clocked in then we have a solution.

While such issues are considered during IP module design, it is not standard practice to include such details of the micro-architecture in the documentation because, as you might appreciate, there would be numerous instances of such conditions that would have to be included. It is however implied in the EMIFA timing spec in the datasheet which we have alluded to in earlier posts.

The 0ns hold time requirement for input data w.r.t. OEn implies that data has already been latched when OEn is de-asserted at the pin (including IO buffer delay). If this was not the case based on our characterization, an appropriate value for the hold requirement would have been specified instead.

I know this is the same point I had made before, but now considering the details of your concern, do you think that the 0ns hold time spec satisfies your requirement?

On a side note, realistically speaking, clock propagation delay variation within a small IP module (if any) will be trivial compared to the sum of delays through the IO buffers at both ends, board delay and any reaction delay before the data bus is tri-stated.

Rgds,

Sunil

ok - I think I am clear on OEn now...To be honest, I may have forgotten that the 0ns output hold time parameter is tied directly to OEn (not to EMA_CLK).

One more thing and I believe we are through. What is the relationship between CSn and OEn? If CSn changes even a nanosecond before OEn then we will tristate the databus because our device feels it is no longer selected.

thanks, Jim Peterson

Hi Jim,

From our design docs, I see that in select strobe mode, CSn has the same timing as OEn and is de-asserted on the same clock edge as OEn.This is also indicated in the TRM as you have observed in your posts.

So the same conclusions that we have come to for OEn can be applied to CSn. By the instant that CSn or OEn is de-asserted on the pins (does not matter which appears first on the pins), data has already been latched.

Rgds,

Sunil

Sunil,

Can you point me to the document and place where the alignment of CSn and OEn are defined?

It appears that the EMIFA read data hold time is tied to OEn, but not CSn...but since both strobes go to the device being read, I need to quantify the relationship between CSn and OEn in my worst case timing analysis.

thanks,

Jim

Jim,

OEn and CSn are defined with respect to the EMA_CLK internally as given in section 20.2.5.5.1 of the TRM. From the external device point-of-view, they are equivalent as per definition of select strobe operation. Both these signals are supposed to transition together and when one of them is de-asserted first at the end of the read cycle (assuming some propagation delay), it signals the end of the cycle to the external device cycle.

From the point-of-view of the OMAP, the input data is already latched before any of these signals are de-asserted at the pins.

Rgds,

Sunil