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

Re: pci compliant devices?



Some comments below....

regards,

Peter Marek
General Director
MarekMicro GmbH
Kropfersrichter Str. 6-8
D-92237 Sulzbach-Rosenberg
Germany
Phone: 049 - 9661 - 908 - 210
Fax:      049 - 9661 - 908 - 100
----- Original Message -----
From: Jim McManus <Jim.McManus@xilinx.com>
To: Peter Marek <peter.marek@marekmicro.de>; <pci-sig@znyx.com>
Cc: <srisundar@dacafe.com>
Sent: Wednesday, March 15, 2000 5:58 AM
Subject: 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:

I didn't want to blame anybody special.... sorry if it sounded like this....
>
> 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.

Altera and others have 3.3V compliant devices and some non-compliant as
well.... like all other vendors do. Just watch out for that and ask whether
the diodes are really there... I know some ASICs that claim 3.3V compliance
and are lacking the diodes as well.... this is not an FPGA specific problem.

>
> 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.
>
Sure. But it's harder to achieve the timing in an FPGA than in an ASIC.
66MHz PCI, especially, is tough to meet with an FPGA structure.

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

It's an advantage as long as you have access to the VHDL source and expert
knowledge on PCI. Mostly, IP customers have neither nor. IP customers who
want to have the advantage of using an IP do not want to dig into the
details of the IP. That's the idea behind the IP, isn't it ?

>
> 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.
>
In my experience, machanical problems are not significant.

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

Ok, PCI2.2 specifies such a time... but not all systems are compliant with
PCI2.2. Especially embedded systems will boot very quickly, and I have seen
systems that do the first PCI configuration access in less than 1s.

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

Yes, but as soon as Intel will solve their Rambus issues on the latest
chipsets, 64bit PCI will become reality. We will see a lot of mixed
32bit/64bit systems by the end of this year. Embedded Platforms like PowerPC
boards for CompactPCI have 64bit PCI built into the Northbridge. So there's
a strong urge for 64bit in the Embedded world. And the embedded market is
said to top the PC market in the near furture, isn't it ?

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

That's what I wanted to say. I just wanted to make HW engineers aware of
some issues that are hidden below the stack of marketing material.

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

The problem is that if you design an add-in board that you need to be
compliant with both future and existing systems. So new ECRs are fine, but
there are millions of PCI systems out there. It will take some time before
these ECRs will be incorporated into the spec and it will take another time
before most of the systems in the filed will be compliant with this ECR.
BTw, ECR are EngineeringChange Requests, these may still not be integrated
into the spec if they are not accepted within the technical comittees within
the PCISIG. . ECRs need to become ECN (Engineering Change Note) before they
may be considered a change of the spec. You can't build systems on
speculations....


>
> Jim McManus
> Xilinx PCI Applications Engineer