Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
You probably already got the pin out information from Xilinx, but here
is the pin out I got from Insight Electronics Spartan-II PCI Development
Kit's schematics.
NET "CLK" LOC = "P185";
NET "RST_n" LOC = "P199";
NET "AD<31>" LOC = "P203";
NET "AD<30>" LOC = "P204";
NET "AD<29>" LOC = "P205";
NET "AD<28>" LOC = "P206";
NET "AD<27>" LOC = "P3";
NET "AD<26>" LOC = "P4";
NET "AD<25>" LOC = "P5";
NET "AD<24>" LOC = "P6";
NET "AD<23>" LOC = "P10";
NET "AD<22>" LOC = "P14";
NET "AD<21>" LOC = "P15";
NET "AD<20>" LOC = "P16";
NET "AD<19>" LOC = "P17";
NET "AD<18>" LOC = "P18";
NET "AD<17>" LOC = "P20";
NET "AD<16>" LOC = "P21";
NET "AD<15>" LOC = "P36";
NET "AD<14>" LOC = "P37";
NET "AD<13>" LOC = "P41";
NET "AD<12>" LOC = "P42";
NET "AD<11>" LOC = "P43";
NET "AD<10>" LOC = "P45";
NET "AD<9>" LOC = "P46";
NET "AD<8>" LOC = "P47";
NET "AD<7>" LOC = "P49";
NET "AD<6>" LOC = "P57";
NET "AD<5>" LOC = "P58";
NET "AD<4>" LOC = "P59";
NET "AD<3>" LOC = "P61";
NET "AD<2>" LOC = "P62";
NET "AD<1>" LOC = "P63";
NET "AD<0>" LOC = "P67";
NET "C_BE_n<3>" LOC = "P8";
NET "C_BE_n<2>" LOC = "P22";
NET "C_BE_n<1>" LOC = "P35";
NET "C_BE_n<0>" LOC = "P48";
NET "PAR" LOC = "P34";
NET "IDSEL" LOC = "P9";
NET "FRAME_n" LOC = "P23";
NET "IRDY_n" LOC = "P24";
NET "DEVSEL_n" LOC = "P29";
NET "TRDY_n" LOC = "P27";
NET "STOP_n" LOC = "P30";
NET "PERR_n" LOC = "P31";
NET "SERR_n" LOC = "P33";
NET "REQ_n" LOC = "P201";
NET "GNT_n" LOC = "P200";
NET "INTA_n" LOC = "P195";
The Insight Electronics Spartan-II PCI card used XC2S150-5CPQ208
(208 pin PQFP), but it should be pin compatible with smaller (XC2S30,
XC2S50, XC2S100-5CPQ208) and larger (XC2S200-5CPQ208) ones.
Insight Electronics discontinued the Spartan-II PCI card with
XC2S150-5CPQ208, and now it uses Spartan-II XC2S200-5CFG456 (456 pin
Fine-Pitch BGA) instead.
I know the package is different, but the card itself is very inexpensive
($225), so it might be worth having one.
Note: Unlike some posters of this newsgroup (i.e., Altera employees), I
don't work for PLD vendors or its distributors and use a personal E-mail
address to post here.
Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)
Anthony Ellis wrote:
>
> Hi,
>
> We are developing a PCI system based on Spartan II 208 pin PQFP devices. For
> this we are busy licensing the PCI core but need to finalise our schematic
> designs and hence need some information on the pre-allocated PCI pin numbers
> to use for the 32 bit/33 Mhz PCI core using this device.
>
> Thanks Anthony.
Article: 42901Hi. I need to generate fpga internal clock of 250 MHz in xilinx virtex2 device. I have 2 possibilities: 1. Use external oscilator of 125 MHz and use the DCM to multiply it by 2. 2. Use external oscilator of 25 MHz and use the DCM to multiply it by 10. What is expected to give me better results in term of lower jitter and simplicity ? ThankX Nahum.Article: 42902
Nahum, The jitter calculator program yields the following worst case results: 125 X 2 = 0.67 ns P-P, or 16.8% UI 50 X 5 = .61 ns P-P, or 15.2% UI 25 X 10 = violates the min freq in for HF mode, or the max freq out for LF mode (not allowed). The jitter calculator is supported through the hotline (email them with your request), or thru your FAE. Austin Nahum Barnea wrote: > Hi. > I need to generate fpga internal clock of 250 MHz in xilinx virtex2 device. > > I have 2 possibilities: > > 1. Use external oscilator of 125 MHz and use the DCM to multiply it by 2. > 2. Use external oscilator of 25 MHz and use the DCM to multiply it by 10. > > What is expected to give me better results in term of lower jitter > and simplicity ? > > ThankX > Nahum.Article: 42903
"Nahum Barnea" <nahum_barnea@yahoo.com> schrieb im Newsbeitrag news:fc23bdfc.0205061123.5b4b4bfd@posting.google.com... > Hi. > I need to generate fpga internal clock of 250 MHz in xilinx virtex2 device. > > I have 2 possibilities: > > 1. Use external oscilator of 125 MHz and use the DCM to multiply it by 2. > 2. Use external oscilator of 25 MHz and use the DCM to multiply it by 10. > > What is expected to give me better results in term of lower jitter > and simplicity ? I would say 1. -- MfG FalkArticle: 42904
"sanjay parekh" <saparekh@nortelnetworks.com> schrieb im Newsbeitrag news:3CD6CE8F.C86FF7C4@nortelnetworks.com... > Hi, > While going through appnotes, I see that clock to the BRAM is always > sent through a clk buffer. Why is this? > In my case I only have one clock that goes to block ram as well as rest > of the logic. And synplify, correctly identifies that as a system clock > and uses global clock lines to route that clock. I am assuming, that in > this case I will not necessarily have to route the clock to the bram via > clk buffer. No. If the clock for your system is already on a global clock net (driven by a global clock buffer) all is fine. -- MfG FalkArticle: 42905
Hi, Can the MAX7000 chip from altera hold a fairly complex design?Article: 42906
Short answer -- Yes. But to be more specific, you'd have to specify your specific needs (gates, macrocells). I've impemented designs using the 7128 and 7160 devices (128 and 160 macrocells) and have found them to be adequate. One macrocell holds the equivelant of one flip-flop. But for larger designs (cpu cores, etc) you may want to try something larger. "Roger King" <roger@king.com> wrote in message news:fpCB8.46513$zk1.12928@news01.bloor.is.net.cable.rogers.com... > Hi, > > Can the MAX7000 chip from altera hold a fairly complex design? > >Article: 42907
Not permanently programmed. They are tested with your bitstream and guaranteed to work
with THAT bitstream. Recompile the design, and all bets are off. Basically it is
writing a custom test for the devices to test only the logic that you use in your
design.
Georg Acher wrote:
> In article <3CC028CE.2CEBCABC@xilinx.com>,
> Austin Lesea <austin.lesea@xilinx.com> writes:
>
> |> 2. easy path does not map around 'bad logic'. You send us your stable
> |> design, and we send you chips marked just as ASICs are marked that are 100%
> |> good at speed for your application. That is why it is so easy! Customer does
> |> nothing, except make a committment to buy X units, non-refundable,
> |> non-returnable....hey just like an ASIC. The big difference? About a million $
> |> for the NRE for the ASIC, compared with our NRE for the test program, supply
> |> management, and marking. Oh, and no time delay, and no risk.
>
> I wonder how this can be done (technically)... How do you permanently program
> the chips? I remember vaguely a similar offer for the XC4k-series a while ago...
> --
> Georg Acher, acher@in.tum.de
> http://www.in.tum.de/~acher/
> "Oh no, not again !" The bowl of petunias
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 42908Hmmm... 128 macrocells.... so for example, one AND gate would take one macrocell? etc....? "******" <spam.dump.address@some.phoney.server.net> wrote in message news:6KCB8.47786$zk1.30670@news01.bloor.is.net.cable.rogers.com... > Short answer -- Yes. > > But to be more specific, you'd have to specify your specific needs (gates, > macrocells). > > I've impemented designs using the 7128 and 7160 devices (128 and 160 > macrocells) and have found them to be adequate. One macrocell holds the > equivelant of one flip-flop. But for larger designs (cpu cores, etc) you > may want to try something larger. > > > > "Roger King" <roger@king.com> wrote in message > news:fpCB8.46513$zk1.12928@news01.bloor.is.net.cable.rogers.com... > > Hi, > > > > Can the MAX7000 chip from altera hold a fairly complex design? > > > > > >Article: 42909
Usually when this happens it is due to another constraint inadvertantly taking
precedence over the intended constraint. Most likely you had some from:to constraints
(of the multi-cycle variety) that caused a problem with constraints you thought were
on the top level period constraint. It may have also been an input to or an output
from the FPGA, for which the period constraints don't apply.
Tullio Grassi wrote:
> Believe it or not we have a design strictly sinchronous (ALL flip-flops with the
> same clk),
> the logic simulation and the static timing analysis are fine,
> but the post-P&R simulation reports several timing violation from
> VirtexE dual-port RAMs (we use ISE4.2).
>
> Also in my case the Xilinx support (Case # 420370 and another one) was not
> satisfactory.
>
> Tullio Grassi
>
> Ray Andraka wrote:
>
> > I don't concur. It is very, no extremely, rare that the P&R tools screw up a
> > design. A post P&R won't tell much of anything that a thorough static timing
> > analysis and functional (pre-PAR) simulation won't tell you. It can actually be
> > rather dangerous, as it can be very difficult to come up with a set of vectors
> > that cover all paths, especially in a large design.
> >
> > To check on the synthesized results, use the mapped output from the synthesis
> > for a post synthesis functional simulation. It will run a lot faster than the
> > timing annotated post PAR simulation.
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 42910OK, I apologize in advance. What I'm asking is virtually guaranteed to start a firestorm. I realize that this is a topic about which people will have both strong biases and vested interests. So, before starting, I beg everybody: Please, let's not turn this question into a battle of opposing polemics. I'm involved in a commercial project with projected volumes into the 100's of thousands if not millions per month. We've got a PCI card, and we've decided to implement the PCI interface in an FPGA, along with multiple other functions. What I would like is opinions as to the best PCI core developers. Let's say for the moment that the FPGA brand isn't particularly important, or is open to change. I don't care if the core in question comes from the FPGA manufacturer, a third-party vendor or consultant, or a freeware download. We'd like people's real-world experiences as to which cores work reliably, efficiently, at high speed, bug-free, and in full compliance with the spec. Also, are there any cores where the source code isn't supplied and/or isn't modifiable? If so, I'd like to get some perspective on the quality/reliability of such "hard-coded" cores as opposed to "soft" cores which the user can modify as needed. I'd also like to know whether the cores that you recommend are 33 MHz, 66 MHz, what version of PCI they're compliant with, and whether they're target, master, or bridge. If the developer supplies various different types, and if you have experience, give me your opinions on each version if possible, so I can see how the relative merits stack up for each implementation. Alex Rast arast@inficom.com arast@qwest.netArticle: 42911
Roger King wrote: > > Hi, > > Can the MAX7000 chip from altera hold a fairly complex design? Yes and no. Perhaps you should explain 'fairly complex' better ? CPLDs commonly have a Wide AND.OR macrocell structure, normally each macrocell can contain one register, and up to 5 Ip OR, from Wide AND terms. Some CPLDs, like Atmel ATF150x, have dual feedback paths so you can squeeze two latches into one macrocell, or bury a counter and have some OR logic left. If you need many registers and little logic, CPLDs are not efficent. -jgArticle: 42912
On Mon, 06 May 2002 22:21:58 GMT, arast@inficom.com (Alex Rast) wrote: >OK, I apologize in advance. What I'm asking is virtually guaranteed to start a >firestorm. I realize that this is a topic about which people will have both >strong biases and vested interests. So, before starting, I beg everybody: >Please, let's not turn this question into a battle of opposing polemics. > >I'm involved in a commercial project with projected volumes into the 100's of >thousands if not millions per month. We've got a PCI card, and we've decided >to implement the PCI interface in an FPGA, along with multiple other >functions. > >What I would like is opinions as to the best PCI core developers. Let's say >for the moment that the FPGA brand isn't particularly important, or is open to >change. I don't care if the core in question comes from the FPGA manufacturer, >a third-party vendor or consultant, or a freeware download. We'd like people's >real-world experiences as to which cores work reliably, efficiently, at high >speed, bug-free, and in full compliance with the spec. > >Also, are there any cores where the source code isn't supplied and/or isn't >modifiable? If so, I'd like to get some perspective on the quality/reliability >of such "hard-coded" cores as opposed to "soft" cores which the user can >modify as needed. > >I'd also like to know whether the cores that you recommend are 33 MHz, 66 MHz, >what version of PCI they're compliant with, and whether they're target, >master, or bridge. If the developer supplies various different types, and if >you have experience, give me your opinions on each version if possible, so I >can see how the relative merits stack up for each implementation. > >Alex Rast >arast@inficom.com >arast@qwest.net Talk to Ray... http://www.andraka.com/ He knows a *lot* about this stuff. But at 'millions a month' an FPGA will be an expensive way to go. JohnArticle: 42913
Hi, I am trying to use an LVPECL clock input on a spartan2e. Which inputs should I use? If I recall correctly, there are standard clock inputs, standard LVPECL inputs and a CLKDLL input that is supposed to be LVPECL if I recall correctly. (Sorry, I am asking this from home and I don't want to wait to download the data sheet over the modem.) Which one is prefered? The clock goes immediately into a delay-locked-loop if this has any importance? The DLL is just being used to get the 0 degree and 90 degree outputs (freq is ~100 MHz.) Also, how do I instantiate this in webpack 4.2? If I recall correctly, an LVPECL input is just instantiated as a single input port. Does the other line show up either in the pad report or the constraints editor? Thanks, Theron HicksArticle: 42914
arast@inficom.com (Alex Rast) wrote in message news:<llDB8.174$vz5.79857@news.uswest.net>... > OK, I apologize in advance. What I'm asking is virtually guaranteed to start a > firestorm. I realize that this is a topic about which people will have both > strong biases and vested interests. So, before starting, I beg everybody: > Please, let's not turn this question into a battle of opposing polemics. > > I'm involved in a commercial project with projected volumes into the 100's of > thousands if not millions per month. We've got a PCI card, and we've decided > to implement the PCI interface in an FPGA, along with multiple other > functions. For this volume, why not go for an ASIC? both Altera and Xilinx offer "ASIC Replacement" FPGAs, but they are still more expensive than ASICs...especially if you add the cost of an external configuration-ROM. > > What I would like is opinions as to the best PCI core developers. Let's say > for the moment that the FPGA brand isn't particularly important, or is open to > change. I don't care if the core in question comes from the FPGA manufacturer, > a third-party vendor or consultant, or a freeware download. We'd like people's > real-world experiences as to which cores work reliably, efficiently, at high > speed, bug-free, and in full compliance with the spec. > We've used the Xilinx PCI core. It works OK, but requires non-trivial design work around it - the so-called "user application". This UA requires some state-machine design, and (harder to implement, MUCH harder to verify) logic to cross clock domains (async FIFOs and other nasty stuff). > Also, are there any cores where the source code isn't supplied and/or isn't > modifiable? If so, I'd like to get some perspective on the quality/reliability > of such "hard-coded" cores as opposed to "soft" cores which the user can > modify as needed. > The Xilinx core (and AFAIK the Altera core as well) come only in net-list format with constraint files. We haven't even been able to get source-code price quote from Xilinx (maybe we're too small). > I'd also like to know whether the cores that you recommend are 33 MHz, 66 MHz, > what version of PCI they're compliant with, and whether they're target, > master, or bridge. If the developer supplies various different types, and if > you have experience, give me your opinions on each version if possible, so I > can see how the relative merits stack up for each implementation. > We've used the 64-bit/66-MHz Master/Slave configuration. However, the absolute majority of PCs use 32-bit/33-MHz PCI. Only Server boards have 64/66 PCI buses (I am not sure if AMD's 760MPX chipset boards are considered server boards). If your design is for standard workstation PC, use 32/33 PCI. Master/Target vs. Target only: depends on your application. If your application moves non-trivial amount of data or accesses a non-trivial range of memory addresses, Master implementation is much better from system-design view. > Alex Rast > arast@inficom.com > arast@qwest.net Some other thoughts: * Any core that you buy will make it harder to convert to ASIC, unless you get it in source-code format. * PCI is not too hard to implement. The big problems are verification and, in FPGA, timing compliance. The PCI-bus has some async paths (especially around IRDY and TRDY) which makes timing compliance tricky. Regards Assaf Sarfati (assaf_sarfati@yahoo.com)Article: 42915
hello My name is gaurav & am working as a market analyst in india. I want to know if anyone of you had implemented a SAN or storage component like a RAID controller using a FPGA. It would be also encouraging to understand if there are any other storage / SAN components like HBA , SAN switch etc where FPGA implemantation been witnessed. In case somebody is engaged in such storage compoments design using FPGA or related design please do let me know your whats are the basic requiremenst and the kind of device or IPS that were used in such implementations. Am available on gauravhazra@yahoo.com I been working in this industry for about four years in the area of High performance computing , EDA , Servers & storage Entreprise newtorking , MCAD etc. regards gauravArticle: 42916
Alex Rast wrote:
>
> OK, I apologize in advance. What I'm asking is virtually guaranteed to start a
> firestorm. I realize that this is a topic about which people will have both
> strong biases and vested interests. So, before starting, I beg everybody:
> Please, let's not turn this question into a battle of opposing polemics.
>
I have seen some Altera employees posting in this newsgroup
using personal E-mail addresses, but almost none of them seem to want to
disclose their affiliation.
At least some Xilinx employees who post here use their work E-mail
address, so I know where their opinions come from.
When people from PLD vendors recommend their own company's products in
this newsgroup (I have seen one Altera employee do that frequently.), I
prefer if they will mention that they work at a PLD vendor, but most of
them don't.
Anyhow, I am not connected to any of those firms, so whatever I say is
my own opinion.
> I'm involved in a commercial project with projected volumes into the 100's of
> thousands if not millions per month. We've got a PCI card, and we've decided
> to implement the PCI interface in an FPGA, along with multiple other
> functions.
>
> What I would like is opinions as to the best PCI core developers. Let's say
> for the moment that the FPGA brand isn't particularly important, or is open to
> change.
Sounds like it will be cheaper to do an ASIC or a gate array
rather than using an FPGA, unless there is some kind of advantage using
an FPGA.
If you are doing PCI in an FPGA, my personal preference will be to go
with a Xilinx FPGA if you are planning to use an SRAM-based FPGA.
I don't personally recommend Altera because I have had lots of problems
with Quartus II 2.0's (I used the free Web Edition, not the full
version.) fitter and floorplanner when I tried to port my PCI IP core to
FLEX10KE.
In my opinion, Xilinx's tool gives users much more flexibility on the
backend side compared to Altera's Quartus II, and especially when using
a softcore PCI IP core, that's very important.
If you don't mind using an anti-fuse FPGA, Quicklogic's QuickPCI might
be interesting, but you won't have much flexibility because the PCI
interface will already be there.
> I don't care if the core in question comes from the FPGA manufacturer,
> a third-party vendor or consultant, or a freeware download.
> We'd like people's
> real-world experiences as to which cores work reliably, efficiently, at high
> speed, bug-free, and in full compliance with the spec.
>
First of all, you can try out Opencores.org PCI IP core
(http://www.opencores.org/projects/pci/) since it is free.
My own biased opinion about Opencores.org PCI IP core will be that the
authors didn't seem to care about readability and maintainability when
they designed it, so I think it will be pretty hard to make
modifications or fix bugs if you have to.
Of course, Xilinx has their own LogiCORE PCI, but the problem of
using theirs will be that you won't be able to do an ASIC conversion if
you want to.
The only way out will be to use AMI Semiconductor's FPGA to ASIC
conversion service which offers a LogiCORE PCI compatible PCI IP core.
LogiCORE PCI is a hard macro (an encrypted netlist), so other than
parameterizable portion of it, you won't be able to modify it even if
you want to.
Supposedly, there are some customization services, but that will be
extra.
An independent third party IP core vendor CAST
(http://www.cast-inc.com) also seems to offer a PCI IP core for Xilinx
FPGAs, and seems to let you port it to an ASIC.
They claim it can do 66MHz PCI in Virtex, but I will guess that it will
be with Virtex-E or faster parts. (I will explain that why I think so
later.)
Dark Room Technologies (http://www.darkroom.com/) also has a PCI IP core
done in Viewdraw schematics, but I am not sure if it can be licensed.
I believe there are a few more independent third party IP core vendors
who offer PCI IP cores, but I cannot think of their names.
I guess mine won't even meet your criteria considering that it
is not fully debugged yet, but I have been working on my own
synthesizable Verilog-based PCI IP core for some time. (> 1 year)
It should be fully debugged at some point, but if you want to be a
guinea pig now, that's possible.
Of course, it won't be free and it will cost something considering the
time and effort I have put into developing it.
> Also, are there any cores where the source code isn't supplied and/or isn't
> modifiable? If so, I'd like to get some perspective on the quality/reliability
> of such "hard-coded" cores as opposed to "soft" cores which the user can
> modify as needed.
>
In my opinion, Xilinx and Altera supplied PCI IP cores are there
to pin down the users to their FPGAs, so that users won't even think of
doing an ASIC conversion.
The only way out will be AMI Semiconductor's LogiCORE PCI clone, or
using third-party IP core vendors.
If you are planning to do an ASIC conversion, don't bother with the PCI
IP cores from the PLD vendors.
> I'd also like to know whether the cores that you recommend are 33 MHz, 66 MHz,
> what version of PCI they're compliant with, and whether they're target,
> master, or bridge. If the developer supplies various different types, and if
> you have experience, give me your opinions on each version if possible, so I
> can see how the relative merits stack up for each implementation.
>
> Alex Rast
> arast@inficom.com
> arast@qwest.net
First of all, I believe I said several months ago that even in
Spartan-II-5, 33MHz PCI is hard or impossible.
Well, I will take that back, and now I can say that 33MHz PCI is not too
hard in Spartan-II-5.
After several months of try, I got my synthesizable PCI IP core to meet
33MHz PCI 's Tsu < 7ns requirement without having to do too much manual
floorplanning.
However, 66MHz PCI still remains very hard in most FPGAs, and there are
several tricks needed to meet its brutal Tsu < 3ns requirement.
Xilinx resorts to two undocumented features to meet 66MHz PCI's timings,
PCILOGIC and BITGEN's /Gclkdel option, although I was able to figure out
a way to use PCILOGIC in my PCI IP core, and saw it actually working in
a real computer.
Other than the undocumented features, the logic has to be designed
carefully to have any chance of meeting Tsu < 3ns, and even after that,
my PCI IP core didn't meet Tsu < 3ns in Spartan-II-6.
Although it doesn't mean much since mine didn't meet Tsu < 3ns, it came
pretty close: Only 15 or so paths missed timings, and PAR's timing score
was about 1,500.
Because I found it very hard to meet Tsu < 3ns in Spartan-II-6, you
might need Virtex-E or Virtex-II for 66MHz PCI, unless you are using
LogiCORE PCI, but those two parts don't support 5V PCI, so you won't be
able to make a Universal PCI card with them. (A PCI card that supports
3.3V and 5V PCI signaling.)
Although PCISIG is trying to force manufacturers to adopt 3.3V PCI,
almost no one makes motherboards with 3.3V PCI (Only a few expensive
workstation class motherboards have 3.3V PCI slots.), so making a 3.3V
PCI only card will severely restrict its market potential.
To sell your company's card to the mass market (5V PCI), you should use
Virtex/Spartan-II for a Universal card, and not bother with 66MHz PCI if
you are not planning to use LogiCORE PCI. (i.e., Do a Universal card,
but support only 3.3V and 5V 33MHz PCI.)
Regards,
Kevin Brace
Article: 42917
Assaf Sarfati wrote:
>
>
> We've used the Xilinx PCI core. It works OK, but requires
> non-trivial design work around it - the so-called "user
> application". This UA requires some state-machine design,
> and (harder to implement, MUCH harder to verify) logic to
> cross clock domains (async FIFOs and other nasty stuff).
>
I think the problem with LogiCORE PCI is that it doesn't let the
backend side insert wait cycles in the middle of a transfer.
Therefore, it seems the use of FIFO buffers becomes near mandatory for
decent performance.
>
> The Xilinx core (and AFAIK the Altera core as well) come only
> in net-list format with constraint files. We haven't even been
> able to get source-code price quote from Xilinx (maybe we're too
> small).
>
I doubt Xilinx or Altera will ever give you the source code
considering their IP cores are there to prevent an ASIC conversion.
I heard that LogiCORE PCI was originally done in Viewdraw schematics,
but I also heard that they are moving towards using Synplify.
I don't how Altera did theirs, and I will be interested to hear that.
>
> We've used the 64-bit/66-MHz Master/Slave configuration. However,
> the absolute majority of PCs use 32-bit/33-MHz PCI. Only Server
> boards have 64/66 PCI buses (I am not sure if AMD's 760MPX chipset
> boards are considered server boards). If your design is for standard
> workstation PC, use 32/33 PCI.
>
I will consider AMD-760MPX a server/workstation class chipset
rather than a desktop chipset considering the cost of making such a
board.
Because there are so many 5V PCI cards, I predict PCISIG's intention to
kill 5V PCI will fail because there are so many 5V PCI cards out there,
it seems impractical to junk that many 5V PCI cards just because PCISIG
doesn't like it.
I will guess that 5V PCI will die when PCI Express (formerly 3GIO)
becomes cheap enough that even a $600 PCs can include it.
>
> Some other thoughts:
>
> * Any core that you buy will make it harder to convert to ASIC, unless
> you get it in source-code format.
> * PCI is not too hard to implement. The big problems are verification
> and, in FPGA, timing compliance. The PCI-bus has some async paths
> (especially around IRDY and TRDY) which makes timing compliance
> tricky.
>
> Regards
> Assaf Sarfati
> (assaf_sarfati@yahoo.com)
Timing closure is a problem in FPGAs, but from my own experience
of doing my own PCI IP core, it largely depends on the skill of the
designer.
When I first did mine, I didn't use CE (Clock Enable) in my PCI IP core
at all, so it cost me a lot in terms of timing closure, but after I
figured out how to use CE effectively (Took me 4 months to figure that
out.), the timing problems went away.
Also, knowing the IOB packing rules is equally important, and I didn't
know anything about it when I first did mine. (I was a total newbie of
FPGAs.)
Speaking of the IRDY and TRDY path, if you are using Virtex/Spartan-II,
there is a special undocumented logic called PCILOGIC which solves the
timing problems of the path you are referring to.
I incorporated that into my PCI IP core, and it worked when I tested in
a real computer.
Regards,
Kevin Brace
Article: 42918When you start thinking of producing 100s or 1000s it turns more into a business problem. First ask yourself a few questions: - What is your profit margin (cost for components, manufacturing, marketing, storage, shipping etc... +Profit)? - What is your time to market? If you spend 6 months on development your market might shrink or disappear, etc... - Is it very important that you have some control over your market (e.g. some weird 273.6 point FFT (joke) that will keep your edge). Everybody has some form of PCI bus interface, so if they want to copy it they can. - Do you want to play? Do you want your company to fork out $xxx for a nice new tool to play with FPGAs (I did that about 6 years ago) - Do you want flexibility? FPGAs gives you this but with PCI you might design yourself into a corner. - What is the life cycle of your product? If you sold millenium watches during 1999 you would have had less than a year to sell. With a military product you need to support it for about 15 years. - Play devils advocate. What if somebody like me saw your product and wanted to copy it? Would I go for a FPGA or a nicely sorted out hardwired core like the PCX (at a much lower cost) - How complex are your other functions? Example: Do you require PCI, with say a NE2000 network interface, with USB and a small processor? You will sometimes find that most of these functions can be bought off the shelf for cheaper than one FPGA. - What are you views on IP protection? If I see a PCB with a configuration EPROM I see something that can be copied and pushed on the grey market. - Do you have investers? An intelligent invester will recognize that money has to spent wisely and time/cost effectively. If you start using timescales like 6 months, but wow then you have your own IP core, as opposed to we buy it today and use it tomorrow but it might be double the cost I will go for the latter. - Do you really understand the complexity of FPGAs? You can whip up a small state machine in 5 minutes, but ending up debuging it for days. FPGAs are the technology for the relativily poor electronics guy that cannot affort to have a silicon processing plant like Intel. Once you have your design ready then it is clear sailing. Designing a FPGA into a new product, especially one that you aim to sell zillions of, is very much like investing in the stock market (you know the ability of performance but you cannot guarantee it nor investor confidence). People investing money (or worse your boss) might not be interested in: "oops, we need one more LUT" or "we cannot tristate this pin because of .....". FPGAs are my hobby. I sit and play and when something works, then I go and market. Many times I have promised a simple design that ended up using a CPLD/FPGA 4 times the size . Example: 4 years ago I swore by FPGAs and convinced my client to use a FLEX10K10 as a Dual Port Ram (plus the selling point of adding other functions) and we could lay out the board before we are even finished with the design. Result: The FPGA (doing 512 bytes DPR) and config EPROM was about 20% cheaper than the IDT/Cypress chip doing 16384 bytes. The FPGA design took 30 days longer to track down weird timing problems. The onboard CPU uses this device for scratch pad RAM but the code had to be seriously optimised to use only 256 bytes. The client ended up with the added problem that they had to find a facility to program the EPC1 config IC. The design now works and is in production, but any small change is still a mountain of a problem for the client. PS * I wanted to design my own CPU on FPGA, for several good reasons (especially cost), and my own C compiler. Instead of that I went and bought NIOS from Altera (still waiting for the Xilinx guys to get back to me). I was up and running in about a week. The new version can do 16/32 bit RISC code, run up to 125MHz in the newer ICs, includes peripherals like UARTs, Timers,SPI, DMA and you can evaluate PCI and USB (or buy) cores that fits directly into this plus you get a free C/C++ compiler along with it. My opinion:* If you have money ( or investors), then avoid developing to much( especially for gazillions of units). You just want to make money. *If you are flat broke and knows somebody with a PC and CAD software go for a FPGA. Experience told me that it will turn out into a muckup in any case ( Simple business equations Your idea(or capability) + someone elses requirement (and the line "we'll make lots of money) = Screwup+loss in food investment money+time wasted+wife/husband cheesed-off as apposed to Your capability + INVESTOR + Other people doing the work= Good prototype + happy investor (more money) + good marketing + real shot in getting it manufactured and sold) *If you run a small business and only want to sell about a 100 units then go for FPGAs. Don't reinvent the wheel, especially if you don't know it is round. Rather go to you nearest car dealer and choose one (with a maintenance plan). Victor Schutte Zerksus Engineering CC ZerTec Engineering MD "Alex Rast" <arast@inficom.com> wrote in message news:llDB8.174$vz5.79857@news.uswest.net... > OK, I apologize in advance. What I'm asking is virtually guaranteed to start a > firestorm. I realize that this is a topic about which people will have both > strong biases and vested interests. So, before starting, I beg everybody: > Please, let's not turn this question into a battle of opposing polemics. > > I'm involved in a commercial project with projected volumes into the 100's of > thousands if not millions per month. We've got a PCI card, and we've decided > to implement the PCI interface in an FPGA, along with multiple other > functions. > > What I would like is opinions as to the best PCI core developers. Let's say > for the moment that the FPGA brand isn't particularly important, or is open to > change. I don't care if the core in question comes from the FPGA manufacturer, > a third-party vendor or consultant, or a freeware download. We'd like people's > real-world experiences as to which cores work reliably, efficiently, at high > speed, bug-free, and in full compliance with the spec. > > Also, are there any cores where the source code isn't supplied and/or isn't > modifiable? If so, I'd like to get some perspective on the quality/reliability > of such "hard-coded" cores as opposed to "soft" cores which the user can > modify as needed. > > I'd also like to know whether the cores that you recommend are 33 MHz, 66 MHz, > what version of PCI they're compliant with, and whether they're target, > master, or bridge. If the developer supplies various different types, and if > you have experience, give me your opinions on each version if possible, so I > can see how the relative merits stack up for each implementation. > > Alex Rast > arast@inficom.com > arast@qwest.net >Article: 42919
Hi, How exactly are Xilinx's Foundation timing scores calculated? Write now I have just been comparing different incarnations of my design, and so things are relative to each other. But what is a good timing score, say for a 100 000 gate design? Thanks adrianArticle: 42920
rickman <spamgoeshere4@yahoo.com> writes: > I am discussing a spec problem with TI on the C6711B. Seems that they > spec'd the C6711 with a shorter hold time (although they lengthened it a > bit in the errata). The C6711B has a 2.5 nS hold time which is 1 nS > longer than the SBSRAM. But he also explained that "the device returned > to its standard operating voltage of 1.8V". So they must have been > spec'ing it at something higher although I can't find it. > Hi Rick, I seem to recall one bit fo the errata for the C6711 (non-B) that said increasing the core supply to 1.9V allowed you to meet the datasheet timing - maybe that's what he was referring to? Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt, Solihull, UK http://www.trw.com/conektArticle: 42921
"Noddy" <g9731642@campus.ru.ac.za> wrote in message various messages... > All I want to do is generate a +/- 32 MHz [down to mHz resolution] ... > The 5 MHz clock is highly stable, generated by a hydrogen maser. ... > I need to be able to set my 32 MHz frequency down to mHz accuracy ie. > 32.031 Mhz, and of course there should be no jitter ... > Sorry, meant to write 32.000000031 MHz... Not taking a cheap-shot here, just some constructive criticism ... you might want to consider turning off that maser before you get hurt and go figure out how to specify/communicate critical parameters like these. You had everybody going off in one direction, then you clarify with what was a very, very different degree of a problem and then you push everyone back in the abyss. Which is it? And, BTW, do you realize how hard it is to read 32.000000031 MHz instead of 32,000,000.031 Hz?. It seems you need 0.001 Hz resolution with a range from 31,500,000.000 Hz to 32,500,000.000 Hz. But... In one of your messages you state that you are trying to design a frequency synthesizer with 30 bits of precision. A quick bit of math and it is clear that you are applying the 30 bits to the 1 MHz range from 31.5 to 32.5. Now, that translates into a step size of 0.0009313 ... Hz. This is different from a 0.001 Hz step specification. If the 30 bit parameter was set to 100,000,000 your output frequency would be 31,593,132.2575 Hz, and not 31,600,000.0000 Hz, a difference of almost 7 KHz. Is that OK? Which one is it you want to synthesize? Is that significant for "coherent signal averaging"? BTW, I think that "no jitter" might not be a good thing to shoot for. Mother nature kinda works against you there. Please don't take this post the wrong way. I had a laugh seeing this go in a circle over a dozen messages and thought I might point out that the nomenclature simply didn't help. What is "coherent signal averaging" anyhow? Good luck. -- Martin E. To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu"Article: 42922
This is a multi-part message in MIME format.
--------------2BF5B2A9B6C6D0AB840428EF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I have following problem:
I tried to import and simulate the testbench of my Simulink model,
generated with Xilinx SysGen 2.1 under Visual HDL.
To get the simulation running properly, one has to adapt all generics
"c_mem_init_file" and "inputfile" to the absolute path manually.
Otherwise the simulator of VisualHDL cannot find the input files.
Is there a possibility to configure SysGen generating its VHDL files
with absolute path strings for these generics?
Here an component example with the above described problem:
component sysgenmacfir_xlsprom_dist1
generic (
-- synopsys translate_off
-- c_mem_init_file: string := "MAC_FIR_coef.mif";
c_mem_init_file: string :=
"D:\Data\SysGenTest\sysgen\MAC_FIR_coef.mif"; -- changed to absolute
path
-- synopsys translate_on
addr_arith: integer := xlUnsigned;
addr_bin_pt: integer := 0;
addr_width: integer := 2;
c_address_width: integer := 4;
c_depth: integer := 16;
c_enable_rlocs: integer := 0;
c_has_spo: integer := 0;
c_latency: integer := 1;
c_width: integer := 8;
data_arith: integer := xlSigned;
data_bin_pt: integer := 7;
data_width: integer := 8;
init_valid: integer := 0;
latency: integer := 1;
uid: integer := 0
);
port (
addr: in std_logic_vector (addr_width - 1 downto 0);
addr_valid: in std_logic;
ce: in std_logic;
clk: in std_logic;
clr: in std_logic;
data: out std_logic_vector (data_width - 1 downto 0);
data_valid: out std_logic
);
-- System Generator port information
end component;
Thanks for any response, (also directly from Xilinx)
Dirk
Article: 42923Martin Thompson wrote: > > rickman <spamgoeshere4@yahoo.com> writes: > > > I am discussing a spec problem with TI on the C6711B. Seems that they > > spec'd the C6711 with a shorter hold time (although they lengthened it a > > bit in the errata). The C6711B has a 2.5 nS hold time which is 1 nS > > longer than the SBSRAM. But he also explained that "the device returned > > to its standard operating voltage of 1.8V". So they must have been > > spec'ing it at something higher although I can't find it. > > > > Hi Rick, > > I seem to recall one bit fo the errata for the C6711 (non-B) that > said increasing the core supply to 1.9V allowed you to meet the > datasheet timing - maybe that's what he was referring to? > > Cheers, > > Martin Sometimes I don't know about TI. I was reading in one of the newsgroups where TI was compared to the "Intel of DSP". I think I know what they meant by that and it was not a complement. I used Intel products back in the 8080 days. They would come out with a new chip and it would not work right. There was no errata and it could take hours on the phone with them before you got someone who would acknowledge the fault in the chip. Mostly they did not think these were "faults", they were just features that required workarounds. I guess being incompatible with standard memory products is TI's idea of a "feature". It did catch my eye when I noticed that TI does not include an SBSRAM on the C6711 DSK. More than a coincidence I think. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 42924
Can one build an OP-AMP in an FPGA?
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z