How to interpret HPI timing diagrams for OMAP-L13x/C674x

rperezti

Other Parts Discussed in Thread: OMAP-L138

One of my customers is building a system in which AM335x GPMC is connected to OMAP-L138 HPI and I have been asked to help with the design of this interface. I have designed C5000-based systems with HPI interface several years ago, so I'm familiar with how the interface works. However, after spending some time looking at the OMAP-L138 HPI timing diagrams, I'm convinced that there are several errors and missing specs which complicate the task. I'm posting here in hopes that someone else has already looked at this and has figured out a way to make an OMAP-L1x/C674x HPI interface work on paper. If you're out there please help.

The first problem I see is with the HPI HRDY signal timing spec for a read. The TRM describes several read cases in which the HRDY signal will go high (not ready) during the first half word access, while the HPI completes the internal portion of the read. For these cases, I would expect the HRDY signal high pulse to occur before the HPI data bus becomes valid. In order to design the interface there needs to be a delay time spec for the leading (rising edge) and one for the trailing (falling) edge of the HRDY pulse. The rising edge, marked T1 in the diagram below, is very important because it defines when the host interface should start sampling the HRDY signal. This T1 could occur immediately after the falling edge of strobe (/HSTROBE low) if the data is not ready. The falling edge, marked T2 in the diagram below, should coincide with the data valid time when the HPI data is ready to be read by the host. It is critical to have a spec for both edges because the host has a sampling window requirement that must be met in order for a NOT READY condition to be recognized. So this is what I would expect to find in the datasheet. Instead of this, the datasheet has a single delay time defined for the HRDY pulse (timing 5, td(HSTBL-HRDYV)). This timing is referenced to the leading edge of HRDY, and its value is coincident with the data valid time (timing 15, td(HSTBL-HDV)). This definition of HRDY says that the HPI is ready until the data becomes valid, at which point the HPI becomes not-ready!!! The timing diagram must be drawn wrong, but this is carried forward from older C6000 datasheets like ‘C6424. Others must have run into this. Can anyone shed some light on this?
The second problem I see is with the data-bus timing for the HPI read. Again, the TRM describes cases for when read data is not ready and HRDY must be used to extend the cycle, and other cases for when data is ready and no HRDY pulse occurs. The datasheet specifies a single valid time for the data-bus, td(HSTBL-HDV). From the value of this parameter, I conclude that this is the data valid time after a not ready condition. However, there is no data-bus valid time spec for the cases when HRDY is not de-asserted (when data is immediately ready). Without this timing information, and considering the problem with #1 above, we have to design the system for worst case timing and ignore the HRDY signal. This causes a significant performance hit for the HPI interface.

I'm looking forward to hearing how others have dealt with this.

-Ruben

over 13 years ago

0 RandyP over 13 years ago

TI__Guru* 84110 points

Ruben,

I did not find the timing diagram that you pasted below. I only looked in the UHPI UG and the C6748 & OMAP-L138 datasheets, but I might have the wrong versions.

Since UHPI_HRDYz is an active low signal, it goes low when the HPI data bus becomes valid. You stated in #1 that you expect it to go high before HD becomes valid, which would be true if it were active high to indicate ready.

The Host has to guarantee that it waits at least td(HSTBL-HRDYV)=15ns (or 17ns or 22ns) before checking HRDYz to make sure it knows whether it needs to wait or not. Then once it sees HRDYz=0, the Host can sample the data because Timing 7 td(HRDYL-HDV)=0ns so HRDYz guarantees that HD will be valid when read.

This is a pain for trying to get the best possible performance because you might be waiting for nothing in the case of pre-fetched data already being there. But it is the way the UHPI works. A customer did not appreciate it, and they tried to find ways to predict that HRDYz could be ignored in some sequences, but I think they got bit by that and had to back off of it.

For #2, the td(HSTBL-HDV) spec is limited to the three cases listed in Table 5-115 (OMAP-L138 version) when HRDYz will not go high. But you cannot safely assume Case 2 "First half-word of HPID read with auto-increment and data is already in Read FIFO" because of the "is already in Read FIFO" caveat - it might not be if there were internal stalls. You can safely assume no HRDYz delay for the second half-word or for UHPI register reads, but that is all, for safety's sake.

Regards,
Randy

0 rperezti over 13 years ago in reply to RandyP

TI__Genius 12670 points

Randy,

Thanks for the time on this. See responses below.

RandyP said:

I did not find the timing diagram that you pasted below. I only looked in the UHPI UG and the C6748 & OMAP-L138 datasheets, but I might have the wrong versions.

I created that diagram so you won't find it in the documentation.

RandyP said:

Since UHPI_HRDYz is an active low signal, it goes low when the HPI data bus becomes valid. You stated in #1 that you expect it to go high before HD becomes valid, which would be true if it were active high to indicate ready.

No disagreement on this. The UHPI_HRDY is active low, so I expected it to transition high (not ready) ahead of the data valid time, and then I expected it to transition low (ready) at the same time as, or after the data becomes valid.

RandyP said:

The Host has to guarantee that it waits at least td(HSTBL-HRDYV)=15ns (or 17ns or 22ns) before checking HRDYz to make sure it knows whether it needs to wait or not. Then once it sees HRDYz=0, the Host can sample the data because Timing 7 td(HRDYL-HDV)=0ns so HRDYz guarantees that HD will be valid when read.

This is a pain for trying to get the best possible performance because you might be waiting for nothing in the case of pre-fetched data already being there. But it is the way the UHPI works. A customer did not appreciate it, and they tried to find ways to predict that HRDYz could be ignored in some sequences, but I think they got bit by that and had to back off of it.

I think you're saying that the HRDY can remain high (not ready) for an indeterminate amount of time due to stalls. Right? I think I missed the point about timing 15 (td(HSTBL-HDV) only applying to cases when HRDY never goes high. This one point clarifies the other questions.

RandyP said:

For #2, the td(HSTBL-HDV) spec is limited to the three cases listed in Table 5-115 (OMAP-L138 version) when HRDYz will not go high. But you cannot safely assume Case 2 "First half-word of HPID read with auto-increment and data is already in Read FIFO" because of the "is already in Read FIFO" caveat - it might not be if there were internal stalls. You can safely assume no HRDYz delay for the second half-word or for UHPI register reads, but that is all, for safety's sake.

I get it now.

Thanks again for the clarification. I think I understand what the datasheet is saying now. I may have more questions on the write timings:-)

Ruben

0 RandyP over 13 years ago in reply to rperezti

TI__Guru* 84110 points

Ruben,

RandyP said:

The Host has to guarantee that it waits at least td(HSTBL-HRDYV)=15ns (or 17ns or 22ns) before checking HRDYz to make sure it knows whether it needs to wait or not. Then once it sees HRDYz=0, the Host can sample the data because Timing 7 td(HRDYL-HDV)=0ns so HRDYz guarantees that HD will be valid when read.

This is a pain for trying to get the best possible performance because you might be waiting for nothing in the case of pre-fetched data already being there. But it is the way the UHPI works. A customer did not appreciate it, and they tried to find ways to predict that HRDYz could be ignored in some sequences, but I think they got bit by that and had to back off of it.

rperezti said:

I think you're saying that the HRDY can remain high (not ready) for an indeterminate amount of time due to stalls. Right? I think I missed the point about timing 15 (td(HSTBL-HDV) only applying to cases when HRDY never goes high. This one point clarifies the other questions.

Having to wait 15-22ns (depending on Cvdd) from HSTROBEz \_ to HRDYz valid can add unnecessary delays. In the case where you are doing auto-increment reads, after the first word has been read, the rest of the reads should be pre-fetched and there should be no delay. If they have been pre-fetched into the Read FIFO, then you can read the data td(HSTBL-HDV)=15/17/22ns (depending on Cvdd) after HSTROBEz \_.

But if you have to wait td(HSTBL-HRDYV)=15/17/22ns (Cvdd) after HSTROBEz \_, then read HRDYz, and then read HD, that usually adds a Host cycle to the sequence and that means it takes longer to get the data.

So if you could trust that HRDYz will stay low for the auto-increment reads, you could ignore HRDYz and read a little faster. Unfortunately, that might not always work because something inside the device could stall the UHPI from getting the next data into the pre-fetch Read FIFO, and that could mean that once-in-a-while HRDYz might go high even on an auto-increment read.

It is just a long-winded way of saying you have to wait for HRDYz on the first half-word, every time you read.

Regards,
Randy

Processors

Processors forum

How to interpret HPI timing diagrams for OMAP-L13x/C674x