PCI IOs, tiofoi, source sampling bypass

What I was told by my FAE is that the PCI timing specs cannot rely on the actual pad for a good signal in the allocated time. The reflections from several loads across a PCI-appropriate distance would take enough time to propagate out through the PCB traces and reflect back without a valid logic level on the driving pad that the bypass was needed in order to *meet* PCI timing.

If the signals in question are signals that you don't need your own output to drive your input, you can constrain those paths so the feedback is ignored. If you need the feedback, the internal route is the "appropriate" route.

If your system is embedded such that you don't have to worry about long traces with multiple loads, you can relax your Tcko, Tsu, and probably Thold values as well and be perfectly PCI compatible, just not PCI compliant. Also, a DCM might work well in systems where you know you will always have a clock.

So. . . what do you need? If you need more detail, you could provide the device - family, size, speed grade - for a little better footing for anyone intersted in bringing up PCI numbers from current or past projects. I'm in a Spartan3E, -5 speed grade with decent timing. My Spartan3 -4 design was nudged a little on some of the numbers if I recall correctly but perfectly fine for my embedded system.

Hi,

thank you very much for the very quick answer!

I am not quite sure to understand. If we take the example of the AD signals then, by the time it is next driven/read, it is 33 ns later, and the lines have had time to settle? Or I am misunderstanding something?

I take it it is the case of the AD signals. Then how do you constrain the paths so that the feedback is ignored? I was told this is a simple UCF constraint on Virtex 4 but I use a Spartan 3.

I was indeed thinking of relaxing the timings for some other timing violation.

What would you use the DCM for?

I use a Spartan 3 XC3S1500-4.

Again, thank you very much for your time.

Thanks, jb

Hello,

If I recall correctly, this source sampling bypass requirement was not present in the PCI Local Bus Specification v2.1, but was added in v2.2. It applies to both PCI and PCI-X, at all frequencies. The rule is that a device cannot "receive" a signal from the pad at the same time it is also driving the pad. Instead, the outbound signal (prior to the output driver) must be used to bypass the inbound signal (after the input buffer). It is natural that you'd want to do this with the tristate control signal.

The reason for this requirement is the specification claims that the timing budget does not cover the time for the "reflected wave" to return to the driving device in time to be properly received by the next clock edge. As you pointed out, it is hard to imagine this being a big issue at 33 MHz, but at 133 MHz, I would not dare ignore it.

Xilinx has implemented this feature directly in the IOB starting with the Virtex-2 family. This way, any customer using the PCI or PCI-X select I/O modes can be confident they have something that complies with this specification requirement without having to give it too much thought... It should be handled "automatically".

It is curious that you are having trouble with timing through this path, but I guess it will depend on how you have constructed your interface. I suggest you file a webcase with Xilinx customer applications for assistance.

Eric

With the Tcko specified for 33 MHz PCI feeding the required Tsu with as many PCI slots and loads as are permitted for 33 MHz PCI along with the prescribed clock skew limit, the reflected wave may not guarantee a valid logic level under all conditions. It doesn't seem to make sense from the

20k foot perspective, but the timing budgets are what they are for specific reasons.

The constraint is the same for Virtex-4 as it is for Spartan-3. I think I'd use a TIG, speciying the output FFS to the input FFS. The core's pcim_lc wrapper file would have the literal names for those registers and the Constraints Guide available in the xilinx.com online documentation would provide the syntax for the TIG.

If you can gurantee a clock is always present and stable, the DCM can improve the I/O timing for the FPGA. I believe the Tcko to Tsu requirement is actually less when the DCM is used but I haven't compared the non-DCM numbers lately. I've found it helpful to tune the Tcko (or Tckon) times relative to the PCI clock pad to be at the PCI timing limits and manipulate the placement for best Tsu. _____

I don't believe the -4 speed grade can give you PCI compliance so PCI compatible operation is probably your goal. You can look at your system timing budget using the PCI numbers as a guide but make the engineering decisions on your own implementation. Just improving on clock skew from the

2 ns datum for 33 MHz PCI is a lot of time to recoup as long as you can guarantee the skew for all elements in the system (such as a plug-in board from another manufacturer).

This gets interesting.

In the old/slow days, PCI was a multi-drop bus system. If the reflected wave didn't get back to you, it (most likely) didn't get back to the chip/card right next to you either. The timing budged had to cover that case so you got a free ride.

Are newer/faster PCI systems limited to point-point links rather than multi-drop busses? Are there requirements on the driving/source (termination) impedance to damp out multi-trip reflections?

--
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.

Hello,

Both PCI and PCI-X are inherently multi-drop. The specification defines the component I/O timing and also defines how to "measure" the bus propagation. As a system designer, you are then free to make a number of tradeoffs, including the physical bus topology, the number of loads and connectors, and the bus frequency.

damp out multi-trip reflections?

Both PCI and PCI-X drivers have AC performance specifications; there are also some pullups associated with the host bridge function for most of the "control" signals and the 64-bit extension to the datapath (I find this asymmetry odd...) Anyway, there isn't anything resembling termination schemes you reference. In fact, adding other components outside the "PCI(-X) device" is a violation of the specification.

Now, PCI Express -- on the other hand -- is a completely different beast. PCI Express is point to point and there are requirements on transmitter and receiver impedance.

Eric

Hello John,

I am not using the Xilinx PCI core IP but a custom target only design. It is going to be pretty complicatted to point at all the possible sources (output Fifos) and all possible destinations (input Fifos) in the design and assign them the TIG constraint. But I guess this is the only solution I have. FYI I was told that on a V4 you have the choice to assign or not to each IO a BYPASS attribute.

Yes. I had not thought of that.

You are right I just need to be PCI compatible. The skew is controlled on my embedded system and will be much less than

1ns. I reckon Tprop will be less than 10ns as well (short traces, 33MHz operation).

Thank you, jb

Thank you Eric. I found what you are referring to in the PCI Spec. rev.2.3, Chapter

3.10-9

"Special Design Considerations"

"Devices cannot drive and receive signals at the same time

------------------------------------------------------------------------------------ Bus timing requires that no device both drive and receive a signal on the bus at the same time. System timing analysis considers the worst signal propagation case to be when one device drives a signal and the signal settles at the input of all other devices on the bus. In most cases, the signal will not settle at the driving device until some time after it has settled at all other devices. Refer to Section 4.3.5. and Section 7.7.5. for a description of Tprop. Logic internal to a device must never use the signal received from the bus while that device is driving the bus. If internal logic requires the state of a bus signal while the device is driving the bus, that logic must use the internal signal (the one going to the output buffer of the device) rather than the signal received from the device input buffer. For example, if logic internal to a device continuously monitors the state of FRAME# on the bus, that logic must use the signal from the device input buffer when the device is not the current bus master, and it must use the internally generated FRAME# when the device is the current bus master."

It makes sense now.

Thank you for your help.

jb