[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: pci compliant devices?



Peter Marek wrote:
> 
> Hi,
> 
> the degree of compliance changes from vendor to vendor. Some just specify
> their drivers are compliant to the PCI spec, others also claim compliance to
> the timing spec. Regarding driver compliance: Some vendors state their
> devices are compliant with the PCI spec. and their devices are 3.3V and 5V
> tolerant. This does not neccessarily mean these devices are 3.3V PCI
> compliant. Some FPGAs are lacking the clamp diodes.

Peter makes a good point here. PCI compliance has to be considered in
selecting a vendor, either FPGA, or ASSP. PCI compliance has several
components:

Electrical: The device must be capable of driving the V/I curves and
comply with other rules like the clamp diodes and device protection. I
can't speak for other FPGA vendors, but all Xilinx FPGA families for
which we claim 3.3 V PCI compliance have the upper clamp diodes as
required. We do specify for universal PCI board that you have to load
the appropriate bitstream (with or without the the upper clamps)
depending on Vio.

Timing: The FPGA plus PCI core has to insure timing is met. The core
vendor has to test for minimum delays (e.g. min clock to out of 2 ns)
and guarantee the timing. Xilinx guarantees that our PCI cores meet PCI
timing. 

Protocol: The core has to correctly implement the PCI transaction rules.
All PCI core developers (including the ASSP and ASIC IP) have bugs in
their initial implementation. The key is to respin the design and remove
the bugs. Here FPGAs have an advantage as the design can be respun
quickly and retested, provided the FPGA vendor is putting the effort
into it. Xilinx has maintained a serious PCI effort, including fixing
issues and updating the PCI core to meet changes in the PCI spec and to
work with the latest Xilinx software, since we introduced our first
version in 1996. At this time we don't have any errata on our v3.0 PCI
core. 

Mechanical: Not a really big issue for FPGA vendors provided the pinout
allows the trace length to be met. Some of the newer small packages
(e.g. FG256) might not be advisable for 64-bit slot card applications,
unless you go with the PCI-X spec of 2.75' for the 64 bit extensions.
The PCI spec allows only 2' for the 64-bit extensions. Larger packages
such as the BG432 don't have an issue in this area.

 
> Another item is that PCI doesn't specify the time between reset and the
> first PCI bus access. This time may change from system to system, and your
> FPGA may still be loading its bitstream while the PCI BIOS first scans the
> bus...... you may choose to use PCI interface chips and/or non-volatile FPGA
> techniques (e.g. QuickLogic QuickPCI).

The PCI specification does specify the time between reset and the first
configuration access. 

In the PCI 2.2 spec, Trhfa (RST# High to First Access) is specified as
2^25 clocks. At 33 MHz, this is about 1 second. But this is a really old
issue that was resolved by an ECR to the 2.1 PCI specification. But even
if you're still working off the 2.1 PCI spec, this was never a real
issue as all PC vendors have a power-on reset that is usually measured
in hundreds of milliseconds. Even older FPGA families (such as the
Xilinx 4000 series) could meet this with a serial PROM in fast mode.

> Moreover, volatile FPGAs will not work in mixed (open) 32bit/64bit designs,
> since the bus width is configured at the end of reset on PCI. probably, SRAM
> based FPGAs will not be fully configured at that time.

This issue is the need to detect the state of REQ64# (and some other
signals in PCI-X) at the time RST# deasserts. This is only needed for
64-bit PCI and PCI-X and doesn't matter for 32-bit PCI. Previously, this
was specified as 1 ms min and 100 ms typ in the 2.2 spec.

To resolve this and give the SRAM FPGA vendors some time to configure,
an ECR was adopted by the PCI SIG. The new value, Tpvrh (Power Valid to
RST# high) is 100 ms for both PCI and PCI-X. The plug-in board designer
will need to evaluate that FPGA configuration method and insure that
they meet this specification. The largest announced Xilinx FPGA can meet
this using SelectMAP configuration. Smaller FPGAs can use a serial PROM
in fast mode. 

Admittedly, this can require some extra effort to meet in some of the
larger FPGAs, but it was a fair compromise between the motherboard
vendors and the FPGA vendors (and the instant-on PC developers who want
5 seconds max to start a PC). The challenge for SDRAM FPGA vendors is to
assure their largest FPGAs can configure in under 100 ms. Setting the
time at 100 ms means the PC vendors don't have to obsolete a lot of
hardware as most, if not all, were already meeting this spec (Intel was
already recommending 100 ms min for ATX power supplies when the ECR was
filed).

This one is a bit newer than the Trhfa ECR, so everyone might not be
aware of it. More details can be found on the ECR page:
http://www.pcisig.com/tech/ecn_ecr.html (PCISIG members only)


Jim McManus
Xilinx PCI Applications Engineer