Re: New PCI card developing

["Sergey Platovskikh" <sergey.platovskikh@vissim.no>]

> >We have been using AMCC S5935 for a long time, but it is PCI2.1
compatible
> >only, so we expecting some problems (and we have already met) in the
newest
> >motherboards.
>
>
>         What were the problems?

The card was given IRQ1 (that was indicated in BIOS information table,
before OS loading) in HP Vectra VL420 (Pentium 4, I845 chipset). So, the the
card wasn't working because of crasy IRQ assignment.
I haven't got this PC yet to analyse the problem, but it seems that the BIOS
can't correctly recognize the card.
Also we had problems with BARx assignment with Intel I845BG motherboard
under WinNT 4.0 . BIOS detected our card properly, but the driver could
register only 2 BARs out of 4 - we got a message that 2 BAR addresses are
busy but they were not (according to WinNT resource map). If we ignore this
error message everything is working Ok. The card was working fine under
Win2000. I am not an expert in drivers, so might be my explanation isn't
clear enough...

Anyhow thanks a lot to the group for the information.
I think I shall go for a PCI controller chip from Cypress or PLX. PCI cores
implementation seems too complicated for my FPGA knowledge.

Kind regards

Sergey.



> I don't believe PCI 2.2 is that different from PCI 2.1.
> Isn't the problem specific to AMCC's one rather than the PCI specification
> differences?
> For example, I heard that Intel chipsets and SiS chipsets handle target
> transactions differently (SiS chipsets keep deasserting IRDY# for a few
> cycles during the first microaccess. This is allowed by the PCI
> specification. See Master Data Latency 3.5.2.), although they are both PCI
> 2.1 or 2.2 compliant.
>
>
>
> >Considering this we decided to find a new PCI controller or
> >take a PCI core from Altera/PLDA/etc.
> >The controller will be connected to Altera APEX chip. Required data rate
is
> >about 40Mb/s.
> >I have checked PLX, Tundra, Galileo, Intel - all of them seems too
> >complicated and require complex logic in the Altera chip. PLX9056 seems
> >good, but still too complicated (and I haven't foud where to buy it).
> >I would really appreciate any advice. May be some other manufacturers are
> >producing PCI controllers?
> >May be somebody has a successful experience of implementing of PCI cores?
> >Can they be used "as is" or two years of investigation will be necessary?
>
>
>         Opencores.org has a PCI IP core that's free.
>
> http://www.opencores.org/projects/pci/
>
>
> I have been working on a PCI IP core of my own for about 14 months (Still
> not done, but it will be eventually.), and if you do your own, depending
on
> your skill level, it can really take more than a year for
development/timing
> closure/verification if you don't know much about HDL and/or FPGA, which
was
> the case in my case.
> After you try out Opencores.org PCI IP core, and not happy with it for
> whatever reason (The code is, in my own biased opinion, pretty hard to
> understand what's going on . . . ), I can consider letting you use my PCI
IP
> core if we can agree on terms, although I have no intention of giving out
my
> work for free.
> The fee I am thinking of charging will be substantially less than what
other
> vendors will charge, which seems to be at least $5,000 for a
> target/initiator PCI IP core. (The only exception will be Xilinx's $2,000
> LogiCORE PCI Spartan-II 'single' project license.)
> Whether you use mine or Opencore's one, if your board is going to be a 5V
> PCI card, from my own experience dealing with Xilinx and Altera FPGAs, I
> recommend using Xilinx devices like Spartan-II or Virtex (not Virtex-E or
> -II) rather than Altera's FLEX10KE or APEX20K.
> First of all, although FLEX10KE-1 supports 5V PCI, APEX20K doesn't
> officially support 5V PCI. (The APEX20K datasheet says it does, but Altera
> website admits that APEX20K can drive only 8-loads, 2-loads short of the
> requirement. If someone doesn't believe me, I will get the URL that says
> that for you.)
> The second reason will be that FLEX10KE and APEX20K have only one IOE (I/O
> Element) FF per IOE, furthermore, an IOE FF cannot do asynchronous preset
> (When RST# is asserted, set IOE FFs to 1.), so PCI control signals like
> FRAME#, IRDY#, TRDY#, etc.'s output FFs cannot be pushed into IOEs.
> Spartan-II and Virtex IOB (I/O Block) have three FFs per IOB, an input FF,
> an output FF, and an OE (Output Enable) FF, plus they can handle
> asynchronous reset and preset, so the IOB is more suited for PCI than
> Altera's.
> The third reason will be that because Altera IOE isn't suited for PCI,
most
> output FFs and OE FFs will come from LABs, and because Altera's fitter
> doesn't seem to do a good job meeting setup/clock-to-output time, I have
> seen highly questionable placements of output/OE FFs. (FFs getting placed
> very far away from the pin, wasting time on routing.)
> To give some credit to Altera's fitter, it seems to excel in maximizing
fmax
> compared to Xilinx's PAR, but for 33MHz PCI, frequency above 33MHz isn't
> that important, but meeting setup/clock-to-output time is.
> I am sure some wlll argue that I should use Quartus II's floorplanner,
which
> I have tried in the past, however, once I tried to assign 4 to 5 FFs to a
> LAB, the fitter complained that it cannot assign the FFs to that LAB.
> Is that suppose to be a bug or is it FLEX10KE's limitation?
> Anyhow, even with all these these bad experiences with FLEX10KE, it is
still
> possible to meet 33MHz PCI's timing requirements if you do some manual
> floorplanning, and somehow avoid upsetting the fitter, but I will guess
that
> you will have a much easier time with Spartan-II meeting PCI timings since
> my PCI IP core can meet 33MHz PCI timings with only 36 FFs having to be
> placed near the center of the chip to prevent a positive hold time. (Th <
> 0ns in PCI.)
> Sure, use of a handplaced PCI IP cores from Altera/PLDA can probably solve
> the timing issues, but that costs at least $5,000 for a target/initiator
PCI
> IP core, and you sound like that's too much.
> Although I said X is better than A here, I work for neither company nor
> their distributors, and the opinions I expressed came from my own
> experiences.
> I don't own their stocks either.
>         Going back to my shameless self-promotion (Sorry!), I did mine in
> Verilog RTL (You probably use VHDL, since almost all Europeans seem to
stick
> to VHDL rather than Verilog.), and the code is vendor independent although
I
> added a few Virtex/Spartan-II specific features that can easily be
disabled.
> I used Xilinx's free ISE WebPACK for the development, and I have done some
> simple (target mode only) testing using Insight Electronics Spartan-II PCI
> card, although the PCI IP core itself can handle no-wait target/initiator
> burst cycles.
> It can meet Tsu < 7ns with only automatic P&R (Takes only a few minutes.),
> although 36 FFs have to be handplaced far away from the pin to prevent a
> positive hold time.
>
>
>
> Kevin Brace
>
> _________________________________________________________________
> MSN Photos is the easiest way to share and print your photos:
> http://photos.msn.com/support/worldwide.aspx
>