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

Re: [pci] RE: PCI power, 3.3v compliant



Dear Friends

I'm developing PCI solutions with Altera APEX E-series. It got the same 5V
problems so I looked a bit further into it. My observations gives some
interesting solutions and problems.
1. All normal PC computers got a 5V PCI slot. (Key slots in the connector.)
2. The drivers on the motherboard only send out 3.3V.
3. If a true 5V PCI card is inserted it will drive the bus up to 5V.

This looks like a mess but my conclusions are that it is possible to use a
3.3V PCI card in a normal, modern PC and it will work fine. Just make sure
you do not use a board that drive the bus up to 5V. My design is not sold to
any external customers so I have control of what other cards are used.
This is working in my computer right now and it should work in others too.

Please send me a note if you think that my solution might not work.

Have Fun



-----Ursprungligt meddelande-----
Från: owner-pci@opencores.org [mailto:owner-pci@opencores.org]För Paul
McFeeters
Skickat: den 13 november 2001 01:09
Till: pci@opencores.org
Ämne: [pci] RE: PCI power, 3.3v compliant

Mike,

Absolutely correct, sorry didn't make myself too clear there. Should
have been "5V isn't as big a concern as 3.3v is because if I don't support
3.3v then rumour has it that it won't be 66mhz compatible". To quote from
the Xilinx PCI Customer Tutorial Page 53 "66MHZ PCI buses can only use 3.3v
signaling". (I know signalling is the correct spelling but it is a quote!)
So in the interests of having a product life of more than a month I'm
worried
about 3.3v compatibility. Already PC cards are coming thick and fast with
the
"66mhz ready" attribute tagged to them.

Mind you Xilinx might be blowing smoke but if I can support both (and the
much rumoured but not seen yet 100mhz bus version) I'll feel much happier.

PS Anybody know why a 64bit data bus processor like the Pentium3+/Athlon
family still use a 32bit PCI bus? More Intel backward compatibility?
Come on Intel stop snoozing and start developing. (Just a little gripe)

Paul



-----Original Message-----
From: owner-pci@opencores.org [mailto:owner-pci@opencores.org]On Behalf
Of MikeJ
Sent: 12 November 2001 21:25
To: cores@opencores.org
Cc: pci@opencores.org
Subject: [pci] Re: [oc] Modular FPGA board (PCI)


Paul,

Just to repeat my concern, 'standard' 33Mhz 32 bit slots in PC's use 5V
signalling.

The pci connector has a keyed section, which must mate up with a
corresponding slot in the plug in card. This key slot can be in one of two
positions (actually the connector is just rotated 180) which indicate
whether the motherboard uses 5v or 3v3 signalling.  Many plug in pc cards
are 'universal' which means they have two slots and can fit in any hole -
this is possible by powering the ASIC's IO ring with the VIO supply on the
PCI connector.
This is not possible using virtex FPGA's as VCC_IO cannot be 5V.

If you can guarantee the dev board will only go in 3v3 slots (and these are
still quite rare) then everything will be fine.

I'm not sure you can get away with external buffers around the FPGA for PCI.
as was suggested :
1, as the signals are bi-directional you would have terrible timing problems
and two loads per net - which is illegal
2, the Virtex-1 devices have the correct diode termination in the IO cell
for 3V3 and 5V PCI - you are not going to get that in a standard part.
3, the track lenths from pci connector to fpga are tightly constrained -
under 1.5 inches for 32 bit signals

Sparten II devices are fine for the job, and a generic cheap PCI proto card
sounds great !

(sorry about the dual post, but I wasn't sure if you were reading the pci
list)
cheers,

Mike.
----- Original Message -----
From: "Paul McFeeters" <paul.mcfeeters@ntlworld.com>
To: <cores@opencores.org>
Sent: Monday, November 12, 2001 1:42 PM
Subject: RE: [oc] Modular FPGA board (PCI)


Mike,

thanks, as my initial PCI core will be hosted in a PC, 5V support
isn't a big concern at the moment. Once the core is working then it
will be available for people to use on any chip they want. The
Virtex-E board I'm using has the most I/O pins I can find on a
'cheaper' development board. I intend to also design a 'generic
PCI development board', I expect to use a Spartan II device
(3.3v, 5v tolerant) on it. Hopefully the board with FPGA and
support circuitry on it will be less than £50 ($75) thus  allowing
more people can develop PCI projects. The PCI connector will be
the 'standard PC' based PCI connector as I suspect most developers
will have access to a PC but people can adjust the boards connector
to suit their own needs.

Paul

-----Original Message-----
From: owner-cores@opencores.org [mailto:owner-cores@opencores.org]On
Behalf Of Mr mike johnson
Sent: 12 November 2001 09:42
To: cores@opencores.org
Subject: [oc] Modular FPGA board (PCI)


Chaps,

Just to make sure you're aware that Virtex-E devices are NOT 5V
tolerant, and should therefore not be used in a 33Mhz 5V PCI slot. This
may not be an issue in embedded apps, but
only Virtex (1) devices have the correct IO buffer for full spec
compliance.

If you look at the pci mail list theres a bit more discussion about
this. I have had my VHDL core running in real hardware for a while, but
I am trying to make a generic 64/66Mhz core with a seperate wishbone
backend. Timing is hard to meet in a non-E device !

Regards,
Mike.

John,

I too am working on a PCI card controlled by a FPGA. My main
consideration (apart from price) is how many I/O pins are left over
after
the 50 pins (includes _INTA). Theres nothing worse than finding a board

that suits your requirements except it doesn't have enough I/O pins.
I've ordered a PCI prototyping board and a FPGA development board
(Virtex-E) which I will 'glue' together and develop my PCI core. I have
a
copy of the PCI 2.2 specs and a pretty good book called "PCI BUS
Demystified by Doug Abbott" so I'm just waiting for my boards to arrive.

My board will support full Initiator/Target functionality, probably
will also
support 66mhz (not 100mhz yet) but not 64bit (which should be easy
enough to expand it to). Once my 'fudge board' works okay I'll get a
board manufacturer to make me some alpha-test boards with the FPGA
already mounted on them which will go out to my testers. Haven't
enquired about the prices for manufacturing the boards yet so fingers
crossed. The development platform & documentation costs are £260
($400) which I think is quite for a PCI+FPGA development system. Sure
beats the thousands of dollars some companies ask you for.

Paul McFeeters

----- Original Message -----
From: John Dalton <johnd@s... >
To: cores@o...
Date: Fri, 24 Nov 2000 14:12:43 +1100
Subject: Re: [oc] Modular FPGA board

>
>
>
> > Are you working in the development of the free PCI core?
>
> No.
>
> > My idea was the opposite of your: I was planning to
> > built a board for PCI testing only when the core will be
> finished.
>
> My plan is for the PCI hardware to be an FPGA connected directly
> to a PCI connector.  There would also be a bunch of pins going off
> to the
> main FPGA.  The only questions are:
> 1) How big an FPGA do you need, and
> 2) How many pins do you need to communicate with the main FPGA?
>
> An answer to question 1) is not too important, as within a
> family it is possible to get different sized FPGAs with a common
> footprint.
>
> In a way, I think it is a good thing to design the PCI core and the
> hardware
> at the same time.  This forces the hardware and core to be
> independent,
> leading to maximum portability for the core and maximum versatility
> for the hardware.
>
> > If a PCI core is validated through simulations and it doesn't
> work over a
> > specific board, what should I do to detect the problem?
> Measurements using
> > oscilloscopes and logical analysers are not possible, because
> they modify
> > the circuit when connected into them due to cable impedances,
> that
> > generates multiple reflection. Is there any solution?
>
> Since we are using programmable logic, it should be possible to use
> the system
> to validate itself.  Simply program a logic analyser into the FPGA.
> One of the initial applications of the Pamette (an FPGA board built
> bt Digital) was to verify the operation of a PCI bus to which it
> was
> connected.
>
> > I don't think that an FPGA for PCI have to fit in a socket.
> IMHO, it has
> > to be soldered in a board. And if this board should fit in a
> SIMM socket,
> > the FPGA has to be a TQFP or BGA packet.
>
> Agree.  My current thinking is to build the PCI as a separate
> board,
> with a chip soldered directly to it.  PCI tracks would go directly
> to
> a PCI connector.  The main logic board and PCI board would be
> plugged into each other.  Unfortunately I don't think a SIMM socket
> is possible due to mechanical constraints.
>
> > TO DO AT HOME??? Well, if I understood it right, it is much
> harder to do
> > the copper lines for the FPGA than for the edge connector.
>
> Yep.  Do at home.  I'm proposing to use CAD (ideally gpcb, but I
> don't
> think it is finished) to layout a board, printing it 1:1 then using
> optical
> means (Riston?) to transfer the design to a PCB.  With careful
> construction
> it *might* be possible to do a board for a chip with 0.5mm pins at
> home.
> In my experience, aligning two sides of a board, to a fraction of a
> mm, is
> difficult to do at home.  Hence it is difficult to do a double
> sided
> edge connector.  (Single sided is okay.)
>
> Of course this does not rule out the convenience of paying someone
> to build the board for you.  But it would be nice to cater for all
> tastes.
>
> > Is there any
> > problem if the lines of the edge connector have the right
> distance and
> > smaller width (ie, increasing the spacing)?
>
> Probably not a good idea.  Edge connector widths and spacings have
> generally been designed to maximise chances of a good connection
> while minimising chances of a short between contacts.  Changing
> widths could impact reliability.
>
> > Greetings from Brazil!
>
> G'day from Australia.
>
> John
>
--
To unsubscribe from cores mailing list please visit http://www.
opencores.org/mailinglists.shtml

--
To unsubscribe from cores mailing list please visit
http://www.opencores.org/mailinglists.shtml

--
To unsubscribe from cores mailing list please visit
http://www.opencores.org/mailinglists.shtml



--
To unsubscribe from pci mailing list please visit
http://www.opencores.org/mailinglists.shtml

--
To unsubscribe from pci mailing list please visit
http://www.opencores.org/mailinglists.shtml

--
To unsubscribe from pci mailing list please visit http://www.opencores.org/mailinglists.shtml