PCI IOs, tiofoi, source sampling bypass

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
The following is taken from a Xilinx Webcase (18292,
http://tinyurl.com/hclbc )

"My design is a simple circuit with an IOB that utilizes an output FF,
IOBUF PCI, and an input FF. The timing tools analyze a path from the
output FF through IOBUF PCI to the input FF. However, if I change the
IOSTANDARD attribute to another value (like LVTTL) , TRACE does not
show a path from the output FF through IOBUF LVTTL to the input FF."

The web case says it is normal that XST analyses it but does not say
why it should be. Anybody has an explanation?

This path makes meeting PCI timings pretty tough!

Many thanks,

Jean-Baptiste.


Re: 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.


Quoted text here. Click to load it



Re: PCI IOs, tiofoi, source sampling bypass
Hi,

thank you very much for the very quick answer!

Quoted text here. Click to load it

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?

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

Quoted text here. Click to load it

What would you use the DCM for?

Quoted text here. Click to load it

I use a Spartan 3 XC3S1500-4.

Again, thank you very much for your time.

Thanks,
jb


Re: PCI IOs, tiofoi, source sampling bypass
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



Re: PCI IOs, tiofoi, source sampling bypass
Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: PCI IOs, tiofoi, source sampling bypass
Hello,

Quoted text here. Click to load it

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.

Quoted text here. Click to load it
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



Re: PCI IOs, tiofoi, source sampling bypass
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


Re: PCI IOs, tiofoi, source sampling bypass
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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).



Re: PCI IOs, tiofoi, source sampling bypass
Hello John,

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

Yes. I had not thought of that.

Quoted text here. Click to load it

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


Site Timeline