Sign in
Search fpga-cpu
Subscribe to fpga-cpu
fpga-cpu by Keywords
Altera | CISCifying | IDE | ISA | Java | JHDL | JTAG | LBU | MicroBlaze | PAR | PCI | RISC | SoC | Spartan | Transputers | Verilog | VHDL | Virtex | VLIW | WebPack | Xilinx | Xsoc | YARD-1A
Ads
Discussion Groups
See Also
Discussion Groups | FPGA-CPU | Re: Re: why FPGA?
This list is for discussion of the design and implementation of field-programmable gate array based processors and integrated systems. It is also for discussion and community support of the XSOC Project (see http://www.fpgacpu.org/xsoc).
Re: Re: why FPGA? - Jeff Brower - Jan 11 16:48:00 2005
|
Rick- http://www.xilinx.com/xlnx/xil_ans_display.jsp?getPagePath=19146&BV_SessionID=@@@@1510964590.1105408727@@@@&BV_EngineID=ccceadddhmijiimcflgcefldfhndfmo.0 > > > > They do not mention PCI specifically. I will ask them about it. > > We are not communicating. The Xilinx app note only talks about how to > protect the Spartan 3 part. It does not address how well the signal > can be driven by the Spartan 3 part through the resistor. Sure we are, but you're not reading too well. I did say I would ask Xilinx about it, if you have a bit of patience you could wait for the answer. Just try to be nice Rick, you'd be amazed :-) -Jeff |
|
|
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: why FPGA? - Author Unknown - Jan 11 17:36:00 2005
|
--- In , Jeff Brower <jbrower@s...> wrote: > Rick- http://www.xilinx.com/xlnx/xil_ans_display.jsp?get PagePath=19146&BV_SessionID=@@@@1510964590.1105408 727@@@@&BV_EngineID=ccceadddhmijiimcflgcefldfhndfmo.0 > > > > > > They do not mention PCI specifically. I will ask them about it. > > > > We are not communicating. The Xilinx app note only talks about how to > > protect the Spartan 3 part. It does not address how well the signal > > can be driven by the Spartan 3 part through the resistor. > > Sure we are, but you're not reading too well. I did say I would ask Xilinx about it, > if you have a bit of patience you could wait for the answer. > > Just try to be nice Rick, you'd be amazed :-) I don't know what I said that set you off. But you don't need to discuss this with Xilinx on my account. The simple arithmetic says you can't drive a fast bus through a 220 ohm resistor. This is not a PCI issue, it is a signal integrity issue. I have already discussed this with Xilinx people in the comp.arch.fpga newsgroups. Xilinx is good at trying to work around any issues that their parts have. But often the work around is very limited, as it is in this case. If you feel I am being rude, please don't bother to reply. |
|
|
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: Re: why FPGA? - Kolja Sulimma - Jan 11 17:45:00 2005
|
wrote: > The simple arithmetic says >you can't drive a fast bus through a 220 ohm resistor. This is not a >PCI issue, it is a signal integrity issue. > Well, you can not do 33MHz PCI, because a PCI bus has extremely large worst case capacitances . But as I said before, many microcontrollers have output drivers that are weaker than 220R series resistance. You can access a small bus without connectors with tens of MHz with that drive strength. Put as you noted, any attached pullups must be weak enough. And point to point connections via 220R transmission lines should do hundreds of MHz. Kolja Sulimma |
|
|
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
RE: Re: why FPGA? - Austin Franklin - Jan 11 21:40:00 2005
|
Rick, > wrote: > > The simple arithmetic says > you can't drive a fast bus through a 220 ohm resistor. This is not a > PCI issue, it is a signal integrity issue. The PCI spec has timing requirements that if they are not met, would be a violation of the PCI spec. Not being fast enough is a timing issue, not a signal integrity issue. Austin |
|
|
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
RE: Re: why FPGA? - Peter C. Wallace - Jan 11 22:34:00 2005
|
On Tue, 11 Jan 2005, Austin Franklin wrote:
> Rick, > > > wrote: > > > > The simple arithmetic says > > you can't drive a fast bus through a 220 ohm resistor. This is not a > > PCI issue, it is a signal integrity issue. > > The PCI spec has timing requirements that if they are not met, would be a > violation of the PCI spec. Not being fast enough is a timing issue, not a > signal integrity issue. > > Austin Driving a bus that is guaranteed to have signal-signal capacitance and therefore crosstalk which will made worse with weak drivers is also a signal integrity issue... > To post a message, send it to: > To unsubscribe, send a blank message to: > Yahoo! Groups Links Peter Wallace Mesa Electronics |
|
|
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
RE: Re: why FPGA? - Austin Franklin - Jan 12 0:10:00 2005
|
Hi Peter, > > Rick, > > > > > wrote: > > > > > > The simple arithmetic says > > > you can't drive a fast bus through a 220 ohm resistor. This is not a > > > PCI issue, it is a signal integrity issue. > > > > The PCI spec has timing requirements that if they are not met, > would be a > > violation of the PCI spec. Not being fast enough is a timing > issue, not a > > signal integrity issue. > > > > Austin > > > > Driving a bus that is guaranteed to have signal-signal capacitance and > therefore crosstalk which will made worse with weak drivers is > also a signal > integrity issue... The claim was "fast enough", and that is simply not a signal integrity issue, but a timing issue. I don't agree with your claim of "guaranteed to have signal-signal capacitance" as being part of the PCI spec, as there is no specification for this in the PCI 2.2 spec that I have seen. If I am mistaken, and if there is, I'd appreciate you pointing it out. Crosstalk, I agree, would be a signal integrity issue, but that was not the issue that was raised that I was replying to. The PCI bus being a reflective wave bus, the signal integrity issue is reflection, if significant. At the reduced bus speed you would have to run with 220 ohm series resistors to make set-up and hold times, I believe that reflection would not be a significant issue. It's pretty easy to simulate, if you have a decent simulator...but you would need to know quite a bit more about the topology of the bus in order to do so. Regards, Austin |
|
|
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
RE: Re: why FPGA? - Peter C. Wallace - Jan 12 0:36:00 2005
|
On Wed, 12 Jan 2005, Austin Franklin wrote:
> Hi Peter, > > > > Rick, > > > > > > > wrote: > > > > > > > > The simple arithmetic says > > > > you can't drive a fast bus through a 220 ohm resistor. This is not a > > > > PCI issue, it is a signal integrity issue. > > > > > > The PCI spec has timing requirements that if they are not met, > > would be a > > > violation of the PCI spec. Not being fast enough is a timing > > issue, not a > > > signal integrity issue. > > > > > > Austin > > > > > > > Driving a bus that is guaranteed to have signal-signal capacitance and > > therefore crosstalk which will made worse with weak drivers is > > also a signal > > integrity issue... > > The claim was "fast enough", and that is simply not a signal integrity > issue, but a timing issue. I don't agree with your claim of "guaranteed to > have signal-signal capacitance" as being part of the PCI spec, as there is > no specification for this in the PCI 2.2 spec that I have seen. If I am > mistaken, and if there is, I'd appreciate you pointing it out. Crosstalk, I > agree, would be a signal integrity issue, but that was not the issue that > was raised that I was replying to. A bus on a real circuit card and with real connectors will have signal-signal capacitance, this is guaranteed. Signal-signal crosstalk is worse with high source impedances - hence - a signal integrity issue. Its not the clock rate thats an issue here either, its the edge rate. snip------------------------------------------------------------------ Peter Wallace |
|
|
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: why FPGA? - Author Unknown - Jan 12 1:43:00 2005
|
--- In , "Peter C. Wallace" <pcw@m...> wrote: > On Wed, 12 Jan 2005, Austin Franklin wrote: > > > > > Hi Peter, > > > > > > Rick, > > > > > > > > > dsprelated@a... wrote: > > > > > > > > > > The simple arithmetic says > > > > > you can't drive a fast bus through a 220 ohm resistor. This is not a > > > > > PCI issue, it is a signal integrity issue. To everyone. I am sorry I posted that. Maybe I am having a bad day, but this conversation does not seem useful to me. If I am mistaken, then please continue. Sorry if I ruffled anyones feathers. BTW, I did not mean anything specific when I used the term signal integrity. I just meant this is not specific to PCI or any other particular system. The issue is just the problem of reducing the drive capability of the output and *all* the many problems that it creates. After all, when you have a shared bus, they make very high current drivers for those applications. |
|
|
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: Re: why FPGA? - Kolja Sulimma - Jan 12 5:54:00 2005
|
Peter C. Wallace wrote: >A bus on a real circuit card and with real connectors will have signal-signal >capacitance, this is guaranteed. Signal-signal crosstalk is worse with high >source impedances - hence - a signal integrity issue. Its not the clock rate >thats an issue here either, its the edge rate. > At least inductive crosstalk should improve with higher source impedance (dI/dt) Also, reflections are inducing a high deal if crosstalk, so for a 220R transmission line the resistor should give you a better crosstalk than any other impedance value. Kolja Sulimma |
|
|
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: Re: why FPGA? - Peter C. Wallace - Jan 12 10:08:00 2005
|
On Wed, 12 Jan 2005, Kolja Sulimma wrote:
> Peter C. Wallace wrote: > > >A bus on a real circuit card and with real connectors will have signal-signal > >capacitance, this is guaranteed. Signal-signal crosstalk is worse with high > >source impedances - hence - a signal integrity issue. Its not the clock rate > >thats an issue here either, its the edge rate. > > > At least inductive crosstalk should improve with higher source > impedance (dI/dt) > Also, reflections are inducing a high deal if crosstalk, so for a 220R > transmission line the resistor should give > you a better crosstalk than any other impedance value. I'm not concerned with generated crosstalk from the weak driver -thats not the problem. The problem is that the signal with the weak driver is succeptable to crosstalk from other signals. If you are designing a card and use resistors for compatibility with a 5V chip you may get away with it, If you make a PCI card using 220 ohm resistors in series with drivers for 5V compatibility and plug it into unknown systems you are likely to fail in all sorts of interesting ways.... BTW how do you get such high trace impedances on normal multilayer FR4? I get around 70 ohms for our simple 4 layer cards = 6 mill/9.5 mill above ground plane traces. When I see 220 Ohms, it makes me think of twin lead (300) - that requres a lot of space between conductors > Kolja Sulimma > To post a message, send it to: > To unsubscribe, send a blank message to: > Yahoo! Groups Links Peter Wallace Mesa Electronics |
|
|
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: Re: why FPGA? - Kolja Sulimma - Jan 12 10:21:00 2005
|
It is clear that you can not sell a PCI board that has resistors or microswithes attached to the pins. PCI specifies that the signals must connect directly to the IC. So all these xilinx workarounds are designed only for embedded systems where you have to talk to pci chips (e.g. network controllers) and can you do not need to claim anything is pci compliant. The impedances I were talking about were differential impedances. I do not remember the single ended values. But the board has only about half the thicknes of a standard 4-layer board. Kolja Sulimma On Wed, 2005-01-12 at 16:08, Peter C. Wallace wrote: > On Wed, 12 Jan 2005, Kolja Sulimma wrote: > > > > > Peter C. Wallace wrote: > > > > >A bus on a real circuit card and with real connectors will have signal-signal > > >capacitance, this is guaranteed. Signal-signal crosstalk is worse with high > > >source impedances - hence - a signal integrity issue. Its not the clock rate > > >thats an issue here either, its the edge rate. > > > > > At least inductive crosstalk should improve with higher source > > impedance (dI/dt) > > Also, reflections are inducing a high deal if crosstalk, so for a 220R > > transmission line the resistor should give > > you a better crosstalk than any other impedance value. > > > I'm not concerned with generated crosstalk from the weak driver -thats > not the problem. The problem is that the signal with the weak driver is > succeptable to crosstalk from other signals. > > If you are designing a card and use resistors for compatibility with a 5V chip > you may get away with it, If you make a PCI card using 220 ohm resistors in > series with drivers for 5V compatibility and plug it into unknown systems you > are likely to fail in all sorts of interesting ways.... > > BTW how do you get such high trace impedances on normal multilayer FR4? I get > around 70 ohms for our simple 4 layer cards = 6 mill/9.5 mill above ground > plane traces. When I see 220 Ohms, it makes me think of twin lead (300) - that > requres a lot of space between conductors > > > > > > Kolja Sulimma > > > > > > To post a message, send it to: > > To unsubscribe, send a blank message to: > > Yahoo! Groups Links > > > > > > > > > > > > > > > > Peter Wallace > Mesa Electronics > > > To post a message, send it to: > To unsubscribe, send a blank message to: > Yahoo! Groups Links |
|
|
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
RE: Re: why FPGA? - Austin Franklin - Jan 12 10:34:00 2005
|
Kolja, > It is clear that you can not sell a PCI board that has resistors Correct... > or microswithes Not correct. There are quickswitches available that allow for full PCI compliance. > PCI specifies that the > signals must connect directly to the IC. No. The PCI spec specifies they have only ONE load on the plug-in card. > So all these xilinx workarounds are designed only for embedded systems > where you have to talk to pci chips (e.g. network controllers) > and can you do not need to claim anything is pci compliant. Again, not entirely true. Regards, Austin |
|
|
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
RE: Re: why FPGA? - Kolja Sulimma - Jan 12 10:52:00 2005
|
On Wed, 2005-01-12 at 16:34, Austin Franklin wrote: > > or microswithes > > Not correct. There are quickswitches available that allow for full PCI > compliance. > > PCI specifies that the > > signals must connect directly to the IC. > > No. The PCI spec specifies they have only ONE load on the plug-in card. Hmm. And let me guess, they do not define what a load is? A microwitch addes capacitance and inductance of two additional I/O pins to the signal, why should that be any better than adding a second FPGA to the signal, which clearly would be a second load. I am not saying that this rule makes a lot of sense, but it is there. Kolja |
|
|
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: why FPGA? - Author Unknown - Jan 12 12:47:00 2005
|
--- In , Kolja Sulimma <kolja@s...> wrote: > On Wed, 2005-01-12 at 16:34, Austin Franklin wrote: > > > > or microswithes > > > > Not correct. There are quickswitches available that allow for full PCI > > compliance. > > > > PCI specifies that the > > > signals must connect directly to the IC. > > > > No. The PCI spec specifies they have only ONE load on the plug-in card. > > Hmm. And let me guess, they do not define what a load is? > > A microwitch addes capacitance and inductance of two additional I/O pins > to the signal, why should that be any better than adding a second FPGA > to the signal, which clearly would be a second load. > > I am not saying that this rule makes a lot of sense, but it is there. I don't have the document in front of me, but I recall it specifically saying that you can not add components to the signal between the IC and the connector. I believe they also specifically ban resistors and clamping diodes. So they all must be inside the IC. I would expect that the Quickswitch parts would violate this spec as well. |
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
RE: Re: why FPGA? - Austin Franklin - Jan 12 13:47:00 2005
|
Hi Kolja, > > > or microswithes > > > > Not correct. There are quickswitches available that allow for full PCI > > compliance. > > > > PCI specifies that the > > > signals must connect directly to the IC. > > > > No. The PCI spec specifies they have only ONE load on the plug-in card. > > Hmm. And let me guess, they do not define what a load is? Sure they do. > A microwitch addes capacitance and inductance of two additional I/O pins > to the signal... No it doesn't. It's still ONE pin, therefore one load. Why do you believe it's two? The quick-switches are bi-directional. > I am not saying that this rule makes a lot of sense, but it is there. The single load rule makes a lot of sense, if you understand the reflective wave technology that the PCI bus uses. Regards, Austin |
|
|
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: Re: why FPGA? - Kolja Sulimma - Jan 12 14:05:00 2005
|
Austin Franklin wrote: >>A microwitch addes capacitance and inductance of two additional I/O pins >>to the signal... >> >> > >No it doesn't. It's still ONE pin, therefore one load. Why do you believe >it's two? The quick-switches are bi-directional. I never used them, by I thought the signal is routed through the switch? Can't do that with one pin. In the Xilinx schematic the pins are called A and B. Once you passed these two pins there is the FPGA Pin, which adds up to three pins. Kolja |
|
|
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
RE: Re: why FPGA? - Author Unknown - Jan 12 14:45:00 2005
|
More support for allowing components between the bus and IC pins can be found in the CPCI specification. My admittedly old copy (20.R2.1) REQUIRES 10 Ohm stub termination on most of the signals. Other than the requirement of the resistors, the stub length and single load requirements are the same. > Hi Kolja, > >> > > or microswithes >> > >> > Not correct. There are quickswitches available that allow for full >> PCI >> > compliance. >> >> > > PCI specifies that the >> > > signals must connect directly to the IC. >> > >> > No. The PCI spec specifies they have only ONE load on the plug-in >> card. >> >> Hmm. And let me guess, they do not define what a load is? > > Sure they do. > >> A microwitch addes capacitance and inductance of two additional I/O pins >> to the signal... > > No it doesn't. It's still ONE pin, therefore one load. Why do you > believe > it's two? The quick-switches are bi-directional. > >> I am not saying that this rule makes a lot of sense, but it is there. > > The single load rule makes a lot of sense, if you understand the > reflective > wave technology that the PCI bus uses. > > Regards, > > Austin |
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: why FPGA? - Author Unknown - Jan 12 15:04:00 2005
|
--- In , Kolja Sulimma <kolja@s...> wrote: > Austin Franklin wrote: > > >>A microwitch addes capacitance and inductance of two additional I/O pins > >>to the signal... > >> > >> > > > >No it doesn't. It's still ONE pin, therefore one load. Why do you believe > >it's two? The quick-switches are bi-directional. > > > > > I never used them, by I thought the signal is routed through the switch? > Can't do that with one pin. In the Xilinx schematic the pins are called > A and B. > Once you passed these two pins there is the FPGA Pin, which adds up to > three pins. That is exactly correct. A Quickswitch is not a buffer, it is a pass transistor which connects two pins together in the same way a series resistor would. They limit the high voltage that is passed through because Vgs drops off as the input voltage increases. This in turn increases the pass transistor resistance and will limit the voltage on the other pin to about Vdd-1.x, I don't remember the exact amount. I believe you can power one of these from the 5 volt rail through a diode, or it may be two, and the voltage to the FPGA will be limited to about 3.3 volts. But you do get the capacitance of all three pins which is what the PCI spec is trying to prevent (as well as the extra reflections from the impedance mismatch on the pins). |
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
RE: Re: why FPGA? - Austin Franklin - Jan 12 15:41:00 2005
|
Kolja, > >>A microwitch addes capacitance and inductance of two additional I/O pins > >>to the signal... > >> > >> > > > >No it doesn't. It's still ONE pin, therefore one load. Why do > you believe > >it's two? The quick-switches are bi-directional. > > > > > I never used them, by I thought the signal is routed through the switch? > Can't do that with one pin. In the Xilinx schematic the pins are called > A and B. > Once you passed these two pins there is the FPGA Pin, which adds up to > three pins. Perhaps you're not aware of the reason for the "only one pin" requirement in the spec. PCI is a reflective bus technology, and as such, it can't have branches on the cards (which is what two devices would give you)...topology is very important. Given this, using a quickswitch does not add any branches/stubs, so signal integrity, with respect to the bus topology, is maintained. As far as the VI/capacitance PCI specifications are concerned, there are some quickswitches that meet these specifications as well if you are careful in selecting them. Regards, Austin |
|
|
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: Re: why FPGA? - Kolja Sulimma - Jan 13 5:20:00 2005
|
Austin Franklin wrote: >Perhaps you're not aware of the reason for the "only one pin" requirement in >the spec. PCI is a reflective bus technology, and as such, it can't have >branches on the cards (which is what two devices would give you)...topology >is very important. Given this, using a quickswitch does not add any >branches/stubs, so signal integrity, with respect to the bus topology, is >maintained. So two loads that are very close together (e.g. two FPGA soldered back to back) would be no problem, but the spec forbids them anyway. Because a 2nd FPGA surely is a second load. Kolja Sulimma |
|
|
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
RE: Re: why FPGA? - Austin Franklin - Jan 13 8:25:00 2005
|
Hi Kolja, > >Perhaps you're not aware of the reason for the "only one pin" > requirement in > >the spec. PCI is a reflective bus technology, and as such, it can't have > >branches on the cards (which is what two devices would give > you)...topology > >is very important. Given this, using a quickswitch does not add any > >branches/stubs, so signal integrity, with respect to the bus topology, is > >maintained. > > > > > So two loads that are very close together (e.g. two FPGA soldered back > to back) would be no problem, > but the spec forbids them anyway. Because a 2nd FPGA surely is a second > load. I don't know about "no problem", but it certainly minimizes the problem. Even though they are say, back to back as you suggest, it still would create a violation of the topology, though obviously very minimized. ALL the pins would have to perfectly line up, which is highly improbable. It would more than likely violate the capacitance spec (10pf), unless the I/O cells were very low capacitance. The VI curve would probably not be a problem. Also, IDSEL, REQ#/GNT# would be an issue, as those are point to point signals. In a system that uses plug-in cards, you have to be a LOT more strict as to what you do, since you have unpredictable circumstances...which is why following the rules to the letter is your best option. In an embedded system, you can pretty much do about anything, as long as it works...and I highly recommend simulation if you are going to violate any of the rules significantly. As I've said, there is no problem using quickswitches. Regards, Austin |
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
RE: Re: why FPGA? - Austin Franklin - Jan 13 12:44:00 2005
|
Hi, > I just meant this is not specific to PCI or any other particular system. Agreed. > After all, when you have a shared bus, they make very high > current drivers for those applications. As a note, PCI being a reflective bus, and is not terminated, doesn't require the high current drivers that other similar terminated busses do. Regards, Austin |
|
|
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: why FPGA? - Author Unknown - Jan 13 17:06:00 2005
|
--- In , "Austin Franklin" <austin@d...> wrote: > Hi, > > > I just meant this is not specific to PCI or any other particular system. > > Agreed. > > > After all, when you have a shared bus, they make very high > > current drivers for those applications. > > As a note, PCI being a reflective bus, and is not terminated, doesn't > require the high current drivers that other similar terminated busses do. I don't agree with this. There is a far difference between not using a 64 mA driver and using a 220 ohm resistor in series with the driver. The PCI driver is spec'd with a particular IV curve and does require a high current level relative to typical CMOS outputs, including FPGAs. I belive the standard drive level in the Xilinx parts is 4 or 6 mA (although the parts can drive higher) which is below the requirement for PCI and most any other fast bus. The bottom line is that a 220 ohm series resistor will muck up nearly any high speed signal, including PCI. You might get away with it, but in a fully loaded system, this is the sort of trick that can make the bus fail even if you never see a problem with a small number of boards. If you want to driver a 5 volt PCI bus, use a 5 volt tolerant PCI bus part. |
|
|
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
RE: Re: why FPGA? - Austin Franklin - Jan 13 21:37:00 2005
|
Hi, > > > After all, when you have a shared bus, they make very high > > > current drivers for those applications. > > > > As a note, PCI being a reflective bus, and is not terminated, doesn't > > require the high current drivers that other similar terminated > busses do. > > I don't agree with this. I don't see how you could not agree with it, it's a statement of fact ;-) > There is a far difference between not using > a 64 mA driver and using a 220 ohm resistor in series with the driver. I believe you're off on a tangent that isn't related to my comment. My comment was in response to the comment quoted above it, relating to other busses requiring "very high current drivers". As I said, PCI is reflective and not terminated, therefore it does not require the higher drive current that some similar busses do. > The PCI driver is spec'd with a particular IV curve and does require > a high current level relative to typical CMOS outputs, including > FPGAs. PCI drive current varies depending on, well, voltage (hence, why it's called a VI curve ;-). The current is higher when the signal is in transition, but requires a VERY low drive current when at DC. Look at the VI curves. The DC drive point for 5V to maintain a high is as little as 2ma, and to maintain a low is 3 to 6ma. > I belive the standard drive level in the Xilinx parts is 4 or > 6 mA (although the parts can drive higher) which is below the > requirement for PCI and most any other fast bus. A "typical" 5V FPGA (say Spartan) drive current is 12ma (LVCMOS or TTL), and "high" drive is 24ma. I'm not sure where you get your "standard" FPGA drive current figures from, but for the Spartan series, which is Xilinx's typical 5V part, they are not correct. > The bottom line is that a 220 ohm series resistor will muck up nearly > any high speed signal, including PCI. Agreed, and I never said differently. > You might get away with it, but in a fully loaded system, this is the sort of > trick that can make the bus fail even if you never see a problem with a small > number of boards. Or, you are in an embedded application where you can control the environment, and you should have no problem there. > If you want to driver a 5 volt PCI bus, use a 5 volt tolerant PCI bus > part. I disagree. That may not be an option, and in that case, the better solution is to use quickswitches, which do in fact work just fine. The issue I personally have with it is the larger FPGAs are simply not 5V tolerant, and the majority of PCI busses are still 5V. I have had long discussions with Xilinx about this, and I also understand the reasons for their not supporting 5V tolerance. I've laid out all the facts as I know them. I'll add that I speak from a reasonable amount of PCI experience, having designed over 20 PCI cards (and quite a few of their PCI interfaces), was on the PCI spec. review committee, I designed the first PCI interface for Xilinx, and I've done the designs for four PCI ASICs, so I am pretty experienced when it comes to PCI. I believe we just have to agree to disagree. Regards, Austin |
|
|
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: why FPGA? - Author Unknown - Jan 13 22:02:00 2005
|
I don't know where you are going with all this. The discussion was about the 220 ohm resistor causing problems with driving shared busses. A 220 ohm resistor in series with an FPGA output will prevent it from properly driving any high speed bus, including PCI. I don't know what you call high current, but PCI does require a high current drive which is very well spec'd. Of course not much current is required to hold a high signal high or a low signal low. My only point was to keep your comments from misleading people into thinking that they can successfully use the Xilinx trick of a series resistor on a high speed output. It is very, very unlikely to produce an acceptable result. Likewise quickswitches are not a good solution since they violate the spec. You may well get away with using quickswitches. But they clearly violate the PCI spec since they are an extra pair of pins on the signal line. It is not just stubs that create extraneous reflections. Impedance mismatches (like pins) do also. PCI was originally designed for just 4 or 5 cards. But they found that it was more robust than this and the current spec allows for more. This is pushing the envelope and makes the signal integrity issues even more important. If you have designed boards using quickswitches, did you test them in a worst case system with a full complement of cards? Did you test with cards that are known to just barely meet the spec? The reason there are standards is to assure interoperability. Suggesting that people violate the spec is asking for trouble. Of course if you are working on a closed system, then you don't need to design to PCI, you can use your own spec. But in a PCI system, you need to stick to the spec. |
|
|
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
RE: Re: why FPGA? - Austin Franklin - Jan 14 0:21:00 2005
|
Rick, (you don't sign your posts, and I think people would appreciate it if you would, I know I would) > I don't know where you are going with all this. The discussion was > about the 220 ohm resistor causing problems with driving shared > busses. That was one aspect of the discussions, and may very well have been your focus...but it wasn't the only topic in the discussion. > A 220 ohm resistor in series with an FPGA output will prevent > it from properly driving any high speed bus, including PCI. You can drive a PCI bus with a 220 ohm resistor, but you have to reduce the clock frequency. I NEVER suggested that for a PCI plug in commercially available card. You seem to believe I have, I have not. I wouldn't even recommend it for any application, as I've stated, there is, IMO, a much better solution. > I don't > know what you call high current, but PCI does require a high current > drive which is very well spec'd. Only during transition. You can reduce the current requirements for a reduced speed application. > Of course not much current is > required to hold a high signal high or a low signal low. And that's some %90+ of the time. Typically, in a terminated system, you have the termination to overcome, which requires higher current for this large amount of time that you are "holding" a signal. > My only point was to keep your comments from misleading people into > thinking that they can successfully use the Xilinx trick of a series > resistor on a high speed output. I never even remotely suggested the such. You obviously didn't read what I wrote. I CLEARLY said that in order to do so they have to reduce the bus frequency, and that, in and of it self, would not work in a "standard" PCI application, obviously, since the spec is 0 to 33MHz. I also did not "recommend" doing this, I merely stated under which conditions it could be made to "work". I recommended using quickswitches instead. > Likewise quickswitches are not a good solution > since they violate the spec. They are an excellent solution, and clearly the best solution for certain circumstances. I am not sure what you believe engineering is, but it is about finding a solution, and typically, with what is available. Your, IMO, naive proposal of simply finding an IC that is 5V tolerant is not a viable solution for a lot of cases, for the reason I previously stated. > You may well get away with using quickswitches. But they clearly > violate the PCI spec since they are an extra pair of pins on the > signal line. Clearly violate? It's not clear at all to me they do, it's clear to me they in fact don't. There are no "extra pair of pins", the attachment to the PCI bus is one connection, which is what is important. This is not a problem. You are claiming a problem where it does not exist. > It is not just stubs that create extraneous reflections. > Impedance mismatches (like pins) do also. It's not significant. This isn't a problem when using quickswitches, of course, if designed properly. > PCI was originally > designed for just 4 or 5 cards. The original PCI spec was designed for, and spec'd for, 10 loads. A card was considered 2 loads, and an on-board component was considered 1 load. This happened to lead to a max of 4 cards plus the system bridge and one other on-board PCI device, 10 loads. > But they found that it was more > robust than this and the current spec allows for more. I don't know where you go that from. What we found was that it was "better" to change the spec to allow for characteristics (and 10 on-board devices was part of the spec, but was rather unworkable) which gave designers better controllability. > This is > pushing the envelope and makes the signal integrity issues even more > important. At first, it was (and I know first hand, trying to make the PCI timing with technology from 13+ years ago meant some very long nights), but today, 33MHz PCI is easy, and is far from "pushing the envelope". > If you have designed boards using quickswitches, did you test them in > a worst case system with a full complement of cards? I have DVT tested them thoroughly, not only in systems, but with PCI system analyzers and in an environmental chamber. Since we do quite a few PCI designs, we have three different PCI analyzers and we have our own environmental chamber. We typically do DVT (Design Verification Testing) under "extended" temperature, humidity and voltage conditions. I've also done simulations. They work just fine. As a note, we also do PCI compliance testing for other companies, so we have the tools to do this in house. > Did you test > with cards that are known to just barely meet the spec? I have never seen a list of cards that "just barely meet the spec", and I have not had any problems with the cards I've designed. I have *seen* problems with other cards (which some companies have had us fix for them), as well as system interface chips. I have had to make up for some PCI bridges that violated the PCI spec (protocol wise, not timing wise), but that's hardly my fault. > The reason > there are standards is to assure interoperability. I know the reasons for standards. I'm a professional engineer, and have been for over 25 years, and I've participated in writing quite a few standards. I also know how to engineer to meet the standards, as well as how to read and interpret them, and what is and isn't important in them. Good engineering isn't just about reading standards, it's about understanding them, and how they apply. > Suggesting that > people violate the spec is asking for trouble. I have not suggested people "violate the spec" in any way, without understanding exactly what they are doing. > Of course if you are working on a closed system, then you don't need > to design to PCI, you can use your own spec. And...you state it here like it's being said for the first time...but this is exactly what I've said in pretty much every post. > But in a PCI system, you > need to stick to the spec. For a "general purpose" commercially available plug-in card, I agree. For certain circumstances, there is no problem, again, if you understand exactly what you are doing. I really don't want to spend any more time on this. If you have something tangible to add to this, then by all means, but all I've seen is speculation, which doesn't hold any water IMO. You're not telling me anything I find useful, or that I didn't already know. I'm not sure what your PCI (or engineering) experience actually is, but I am confident in mine and will stand behind what I have written and what has proven to work just fine for me. Austin |
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )