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
Greetings, We're implementing a flash ADC data acquisition PCI card using a Xilinx XC2S50 to buffer samples. We have the Xilinx PCI core implemented as a target only. Under linux, we can see the card's configuration registers, the Xilinx vendor ID, base address registers, etc. One base address register points to a group of control registers for the front end hardware which we can read and write with no problem. So far, so good. Another base register points to a data FIFO. In our application, we don't know ahead of time how much data will be in this FIFO. The hope was to poll this FIFO with a burst read. Most of the time the FIFO should be empty, so we want 0 words to be returned. When the FIFO contains data we want to read all its words. Since this can vary, we want to use the PCI STOP signal to have a target-initiated termination. This seems to be much harder than we hoped. We haven't figured out how to do a PCI burst read under linux. A series of single reads sort of works, but hangs up the computer when there is no data in the FIFO. We're having a lot of trouble trying to find out how the computer's mother board translates kernel calls to PCI bus transactions. For example, what is the difference between a memory read (CBE 0110) and a memory read multiple (CBE 1100) ? How does the PCI core know whether to output S_SRC_EN ? We have the MindShare PCI book that came with the Xilinx PCI core. What we really need is information on exactly how to write software which causes various things to happen on the PCI bus. Any suggestions for other books, sample code, a software tool kit, etc. would be greatly appreciated. Paul Smith Indiana University PhysicsArticle: 42976
Hi, I will like to know if such a thing as an EDIF schematic editor exists. Lately, I have been trying to convert my design (A PCI IP core) from a one that needs to be synthesized with the rest of the design to a netlist so that I can reduce the backend synthesis time and be able to instantiate the IP core from a VHDL design. (The IP core is done in Verilog, so I hate to redo the work for VHDL.) The problem I have been experiencing was that (See: Duplicating IOB FFs Without I/O Pads Being Inserted in XST, How can I get rid of I/O pads from a netlist generated by XST? for details.) XST doesn't duplicate output and OE (Output Enable) FFs unless I add I/O pads (I/O buffers) to the design, but just to get the FFs duplicated, adding I/O pads to the IP core causes problems when I instantiate it from the backend module. (NGDBUILD will give me lots of errors because of duplicate I/O pads.) Unfortunately, the latest version of XST (Ver. E.xx) no longer generates an EDIF file, and instead generates an encrypted .NGC file, so I cannot tinker with the netlist at all. (I resent Xilinx for changing that.) Fortunately, I happened to have WebPACK ISE 3.3 in a CD-R, so I was able to use the older XST (Ver. D.xx) which generates an EDIF file. Of course, the older XST doesn't automatically duplicate FFs, so I had to go into an EDIF file, and manually duplicate FFs, which I hate, but I was able to duplicate some FFs by editing an EDIF file. However, it is sort of time consuming to have to edit an netlist by a text editor, so I was wondering, does an EDIF schematic editor exist where I can edit Xilinx library primitives XST generates? Obviously, I don't use schematics, and I am poor, so if it costs something, I probably won't get it, but just for my information I will like to know such a thing exists. It will be nice if ECS schematic editor that comes with ISE WebPACK can edit Xilinx library primitives of an EDIF file. Kevin Brace (In general, don't respond to me directly, and respond within the newsgroup.)Article: 42977
"Børge Strand" <borges@ping.uio.no> wrote: > I could need a FIFO . . . Spartan II How about searching xilinx.com? http://www.xilinx.com/xapp/xapp175.pdf http://www.xilinx.com/ipcenter/catalog/search/logicore/synchronous_fifo.htm http://www.xilinx.com/ipcenter/catalog/search/logicore/asynchronous_fifo.htm Paul.Butler@ni.comArticle: 42978
Probably more important, if the clock goes through a DCM phase shift relative to another clock you can end up with the source and destination clocks giving you different values. I believe this "PHASE" support started with the 4.1i Xilinx tools and has certainly messed up my rising edge, falling edge mix of logic in a couple spots. If you don't do any phase shifting and don't use negative clock edges you'll probably have everything report as you expect relative to the 3.3i tools. sanjay parekh wrote: > Can anyone tell me what is the meaning of these two lines in a trace > report - > > Source Clock: clk_c rising at 0.000ns > Destination Clock: clk_c rising at 5.000ns > > My guess is that it is just specifying the period. But if this clock > goes through a buffer does it say otherwise. > > Thanks. > -sanjayArticle: 42979
>Another base register points to a data FIFO. In our application, we >don't know ahead of time how much data will be in this FIFO. The hope >was to poll this FIFO with a burst read. Most of the time the FIFO >should be empty, so we want 0 words to be returned. When the FIFO >contains data we want to read all its words. Since this can vary, we >want to use the PCI STOP signal to have a target-initiated termination. > >This seems to be much harder than we hoped. We haven't figured out how >to do a PCI burst read under linux. A series of single reads sort of >works, but hangs up the computer when there is no data in the FIFO. PCI isn't designed to work that way. Think of it as memory. You asked to read location xxx. STOP says not-right-now, try again later. That "later" means right away, a few machine cycles, perhaps after some other device has used the PCI bus for another transaction. The STOP signal never gets back to the software. The hardware retries until it gets some data or maybe an error-abort timer goes off. One suggestion is to include a status bit so you can tell the software that the word it read was empty. If you have a FIFO, you can read the number of words in the FIFO (using a different address) and then read the right number of data words. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 42980
Can anyone say with any certainty that the timing of an XC2S200E-6FG456I will be the same as the XC2S200E-6FG456C? I need to do a design for both versions and we will be building boards with both versions of the FPGA. Some will actually be industrial boards, but sometimes we will use the industrial versions of the FPGA on the commercial temp boards if that is the FPGA we have on hand. Will I expect to see any differences in timing between the three verisons of the board (comm chips run at comm temps, ind chips run at comm temps and ind chips run at ind temps)? I know the ind chips will run better if kept within the comm temp range, but are the timing files the same? If I do a design that meets timing for the comm temp chip, can I expect that to meet timing in the ind temp chip at either temp range? -- 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: 42981
Your question - I don't know the answer, I only have my suspicions - seems to be whether the worst case timing numbers for an I suffix part match the worst case timing numbers for the C suffix device. For real compliance testing over all operating conditions, you need to run your timing analysis at specified voltages and temperatures. If the 25C nominal voltages are the same for the commercial and industrial parts, expect to see the timing different at the maximum ranges. You can run the speedprint utility with full part numbers and override for temperature and voltage to make a comparison for yourself, assuming the timing numbers are production. rickman wrote: > Can anyone say with any certainty that the timing of an XC2S200E-6FG456I > will be the same as the XC2S200E-6FG456C? I need to do a design for > both versions and we will be building boards with both versions of the > FPGA. Some will actually be industrial boards, but sometimes we will > use the industrial versions of the FPGA on the commercial temp boards if > that is the FPGA we have on hand. > > Will I expect to see any differences in timing between the three > verisons of the board (comm chips run at comm temps, ind chips run at > comm temps and ind chips run at ind temps)? I know the ind chips will > run better if kept within the comm temp range, but are the timing files > the same? If I do a design that meets timing for the comm temp chip, > can I expect that to meet timing in the ind temp chip at either temp > range? > > -- > > 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: 42982
Good question, and here comes the good anwer: There is only one speeds file for any part. The ac parameters are identical for the commercial and industrial part. Because it has to guarantee the same performance over a wider temperature range, the I part is better (faster), but all performance numbers are the same. This has been the rule in Xilinx since times immemorial, i.e. since 1985. Peter Alfke, Xilinx Applications =========================================== rickman wrote: > Can anyone say with any certainty that the timing of an XC2S200E-6FG456I > will be the same as the XC2S200E-6FG456C? I need to do a design for > both versions and we will be building boards with both versions of the > FPGA. Some will actually be industrial boards, but sometimes we will > use the industrial versions of the FPGA on the commercial temp boards if > that is the FPGA we have on hand. > > Will I expect to see any differences in timing between the three > verisons of the board (comm chips run at comm temps, ind chips run at > comm temps and ind chips run at ind temps)? I know the ind chips will > run better if kept within the comm temp range, but are the timing files > the same? If I do a design that meets timing for the comm temp chip, > can I expect that to meet timing in the ind temp chip at either temp > range? > > -- > > 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: 42983
John_H wrote: > Your question - I don't know the answer, I only have my suspicions - seems > to be whether the worst case timing numbers for an I suffix part match the > worst case timing numbers for the C suffix device. Yes they do, and that's the way the parts are tested. No ifs or buts. Peter Alfke, Xilinx ApplicationsArticle: 42984
Hi all, I'm doing some research into trends in programmable technologies, and would like to be able to compare the transistor counts of FPGAs and general-purpose microprocessors. However, finding data for the FPGAs is proving difficult. Does anyone have any reliable data for the transistor counts of Xilinx FPGAs newer than those listed below (and ideally, the XCV3200E and XC2V6000 devices)? Xilinx XC4085XL = 16 million transistors Xilinx XC40125XV = 25 million transistors Xilinx XCV1000 = 75 million transistors Note: this data comes from Xilinx's own literature. I could estimate the transistor counts, but there would be uncertainty involved that I would like to avoid if possible. Thanks, SteveArticle: 42985
What I'm missing is... the two devices use the same speed files. You can derate for temperature. If they're the same speed file, don't they give identical results for max commercial temp? So are the derating factors flat from commercial max temp to industrial max temp? I like your answer, it's just confusing my poor, addled gray matter. It sounds like the only thing an industrial temp part will guarantee over a commercial part "within the commercial temperature range" is an unknown better margin. Peter Alfke wrote: > Good question, and here comes the good anwer: > There is only one speeds file for any part. The ac parameters are identical > for the commercial and industrial part. Because it has to guarantee the same > performance over a wider temperature range, the I part is better (faster), > but all performance numbers are the same. > This has been the rule in Xilinx since times immemorial, i.e. since 1985. > > Peter Alfke, Xilinx Applications > =========================================== > rickman wrote: > > > Can anyone say with any certainty that the timing of an XC2S200E-6FG456I > > will be the same as the XC2S200E-6FG456C? I need to do a design for > > both versions and we will be building boards with both versions of the > > FPGA. Some will actually be industrial boards, but sometimes we will > > use the industrial versions of the FPGA on the commercial temp boards if > > that is the FPGA we have on hand. > > > > Will I expect to see any differences in timing between the three > > verisons of the board (comm chips run at comm temps, ind chips run at > > comm temps and ind chips run at ind temps)? I know the ind chips will > > run better if kept within the comm temp range, but are the timing files > > the same? If I do a design that meets timing for the comm temp chip, > > can I expect that to meet timing in the ind temp chip at either temp > > range? > > > > -- > > > > 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: 42986
Steve, 2V6000 = 320 million Will announce the others as they arrive..... Austin Steve Charlwood wrote: > Hi all, > > I'm doing some research into trends in programmable technologies, and > would like to be able to compare the transistor counts of FPGAs and > general-purpose microprocessors. However, finding data for the FPGAs is > proving difficult. Does anyone have any reliable data for the transistor > counts of Xilinx FPGAs newer than those listed below (and ideally, the > XCV3200E and XC2V6000 devices)? > > Xilinx XC4085XL = 16 million transistors > Xilinx XC40125XV = 25 million transistors > Xilinx XCV1000 = 75 million transistors > > Note: this data comes from Xilinx's own literature. > > I could estimate the transistor counts, but there would be uncertainty > involved that I would like to avoid if possible. > > Thanks, > > SteveArticle: 42987
Jonathan!!! >Lattice Semi have the ispPAC family which they acquired from a >small, now defunct startup whose name I've forgotten. It's a >configurable bag of gain blocks, filter blocks and suchlike >useful things. ispPAC is an all LATTICE development, begun in 1995 - lot of work and effort into making a digital CMOS process behave well enough for the designs to go. Devices have been in production and shipping since summer of 1999. Zetex rolled their own also- >Zetex have the TRAC range, marketed by their Fast Analog Solutions >division; >Anadigm's FPAA devices look suspiciously like the programmable >analog parts that Motorola launched a few years ago and then >withdrew in unseemly haste This is a clean assumption - after Motorola folded their effort, Anadigm got their hands on it, and have made a go of it. > thanks for mentioning us - Michael Thomas SFAE Lattice SemiconductorArticle: 42988
Roger King wrote: > > Can one build an OP-AMP in an FPGA? No, but you can buy an op-amp in a SOT23 package, in an analog optimised process, and with low noise supply connections. -jgArticle: 42989
Confusion, confusion. Let's forget temperature derating for a moment. Most delays get longer at higher temperature. So the data sheet and the speeds file list a worst-case number as max delay. It happens to apply to a commercial part @ 85 degr, and equally well to an industrial part @100 degr. That was the original question. The industrial part has the same timing over its wider range, as the commercial part has over its narrower range. Tomorrow I'll explain temperature derating, which is a newfangled thing. Peter Alfke, Xilinx Applications ==================================== John_H wrote: > What I'm missing is... the two devices use the same speed files. You can derate > for temperature. If they're the same speed file, don't they give identical > results for max commercial temp? So are the derating factors flat from > commercial max temp to industrial max temp? > > I like your answer, it's just confusing my poor, addled gray matter. > > It sounds like the only thing an industrial temp part will guarantee over a > commercial part "within the commercial temperature range" is an unknown better > margin. > > Peter Alfke wrote: > > > Good question, and here comes the good anwer: > > There is only one speeds file for any part. The ac parameters are identical > > for the commercial and industrial part. Because it has to guarantee the same > > performance over a wider temperature range, the I part is better (faster), > > but all performance numbers are the same. > > This has been the rule in Xilinx since times immemorial, i.e. since 1985. > > > > Peter Alfke, Xilinx Applications > > =========================================== > > rickman wrote: > > > > > Can anyone say with any certainty that the timing of an XC2S200E-6FG456I > > > will be the same as the XC2S200E-6FG456C? I need to do a design for > > > both versions and we will be building boards with both versions of the > > > FPGA. Some will actually be industrial boards, but sometimes we will > > > use the industrial versions of the FPGA on the commercial temp boards if > > > that is the FPGA we have on hand. > > > > > > Will I expect to see any differences in timing between the three > > > verisons of the board (comm chips run at comm temps, ind chips run at > > > comm temps and ind chips run at ind temps)? I know the ind chips will > > > run better if kept within the comm temp range, but are the timing files > > > the same? If I do a design that meets timing for the comm temp chip, > > > can I expect that to meet timing in the ind temp chip at either temp > > > range? > > > > > > -- > > > > > > 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: 42990
One reason we are not too eager to volunteer these numbers is that they often are being abused for a strange purpose, namely to calculate Mean Time Between Failure (MTBF). There still exists a misguided opinion, especially in military circles, that transistor count directly affects (un)reliabilty. Nothing could be further from the truth. Transistors well inside the chip hardly ever fail, I/O transistors are far more likely to fail. To say that an FPGA which may have many times more transistors than a Pentium, would therefore be less reliable is a naive oversimplification at best, total nonsense at worst. (Now you heard my biased opinion). At the upper end, we are still well below 1000 million transistors ( a billion in the US, a milliard in Europe). That should not be too surprising: A 20 x 20 mm chip obviously has an area of 400 million square microns, and a logic transistor is smaller than a square micron. Peter Alfke, Xilinx Applications ================================ Steve Charlwood wrote: > Hi all, > > I'm doing some research into trends in programmable technologies, and > would like to be able to compare the transistor counts of FPGAs and > general-purpose microprocessors. However, finding data for the FPGAs is > proving difficult. Does anyone have any reliable data for the transistor > counts of Xilinx FPGAs newer than those listed below (and ideally, the > XCV3200E and XC2V6000 devices)? > > Xilinx XC4085XL = 16 million transistors > Xilinx XC40125XV = 25 million transistors > Xilinx XCV1000 = 75 million transistors > > Note: this data comes from Xilinx's own literature. > > I could estimate the transistor counts, but there would be uncertainty > involved that I would like to avoid if possible. > > Thanks, > > SteveArticle: 42991
In article <88b55ba7f36a94f98979589c8a3ee425.60722@mygate.mailgate.org>, "Guy Schlacter" <g.schlact@attbi.com> wrote:
>Alex -
..(deletia)
>I ...realize that you are a small
>company. It is unclear the extent of your staffing and engineering
>capabilities
>but non the less it appears that you do not have the inhouse expertise
>for the
>customization and chip development.
(Deletia)
I am certainly an expert on chip design and FPGA design and programming.
However, I can't all do it by myself, of course, not unless I wish to spend
more years than I've got (any chip design process is a major undertaking
requiring multiple people simply to tackle the size of the data-entry
proposition!)
However, I'm certainly NOT the expert on PCI. This is where we are looking for
other people. Now, there are several unusual design concepts that we're
considering, that we would like to run past a PCI expert, but only if that
expert isn't the type to have preconceived ideas about what can or cannot be
done. We want somebody with enough of an open mind at least to examine the
possibility of a creative solution, when it's not immediately and
categorically obvious that the proposed solution is impossible, enough to give
us input on whether that solution is productive to implement. Also, someone
intelligent enough to recognize the difference between knowing something is
impossible or impractical and not knowing enough to be able to tell if the
proposal is impossible/impractical. He who can recognize that difference
should be wise enough to be able to start finding out, either by asking
others, reading, testing, or whatever, and then coming back to us with his
recommendations, rather than just dismissing the idea as impossible out of
hand.
>...HOwever here are some of
>the
>facts that I took into consideration for these suggestions...
>a. you are a startup and no matter how well funded - cash is king
If that is unequivocally true why try to build a startup company or do
anything innovative at all? It sounds to me like you believe no startup can
ever succeed, that they are all doomed to be squashed by big corporate
entities.
>b. not every great idea succeeds (lots of competition for wireless
>broadband)
Not every great idea fails, either.
>c. volumes are not yet truely defined unless you have minimums based on
>a contract with cusotmer
Of course volumes aren't truly defined. We know that. Everything that we
state on volumes is mostly conjecture. Nonetheless manufacturers have to have
some targets, in order to have "visibility" for production. We do
additionally have preorders that we are in part factoring in.
By the way, don't get me wrong - we're not so blind as to believe we can't
fail simply based on the strength of our idea. All startups involve risk and
we recognize and respect that. But we also believe that we must proceed
assuming to a certain extent that we will succeed because without that
assumption you can't get anything done because you can make no future plans.
>d. luckily PCI is a fairly mature spec and many people have experience
recommendations:
1. inficon should create the high level specification for what needs to
be developed for the whole chip or chip-set
Minor spelling note - you misspelled the name "Inficom" (I point this out for
humor - consider a name like "Inficon" - "Yeah...I've got the contracts for 5
Brooklyn Bridges I'd like to sell you...) :-)
2. implement a stagged solution that will reduce risk and ultimately
maximize profit
What we want to see more than anything else is maximized *value* to the
customer. We see what the customer will want - drop-in, turnkey networking
that will instantly work with a minimum of configuration on his part, and will
be reliable for many years. That's what we want to get out of the chute. Our
objective is a product that in the first generation doesn't scream "beta" -
buggy, slow, unreliable, difficult to install, riddled with incompatibilities,
etc.
3. for ultimate risk reduction use FPGA technology for prototypes (hash
out any bugs/spec changes) into initial-mid production
We also lean in that direction for early release. The benefits are enormous.
4. rather than spin it yourself, obtain a Fixed Bid from an FPGA
consultant partner program
...
I'm looking for all the options. Because of the nature of our design, I think
there are some integration issues which *will* require custom tweaking of
existing cores - my guess is that it'll be difficult simply to drop in a
canned core exactly as is. I also suspect that whoever does this work, they
will end up having to coordinate so closely with me that they'll end up
effectively being in-house, even if they're only working here as a contract
consultant. I'm willing to do the tweaking myself if necessary, but would
rather have someone else do it.
5. You should consider the initial project/bid from the consulting firm
to just include development of the low level spec such that
risk is further reduced and better fix-bid can be presented for full
implementation
Development of a low-level spec would almost certainly have to be a joint
project between me and the developer. I don't know how realistic it would be
to make it a fixed-bit situation. I think if it were an external person rather
than an internal hire, we'd need to use some sort of cost-reimbursement
contract.
6. involve your local FPGA vendor's sales teams
We've already done so. They've provided some help but most of the technical
questions I ask go right over the heads of even the local senior FAE's.
Usually I end up having to talk to a senior factory engineer.
7. once the high level spec and other details have been worked through,
estimate the size of the
actual FPGA device you will need and its embedded resources (ask
consultant)
We've got some ballpark numbers on that.
8. ask your FPGA vendor to provide you quotes for different volume
levels - specify the time fram for each volume level too
And we've got ballpark pricing as well.
9. ask your FPGA vendor what other suggestions they could make to
further reduce solution cost - example Altera Hard Copy
(non-programmable reduced cost) or
or Xilinx Easy Path (reduced cost but still needs configuration)
Usually our questions involve not so much solution cost but instead solution
flexibility - what things the solution will and will not allow us to do.
10. ask about IP source code - I know Altera will provide a quote if you
do need to ultimately go asic
This approach should reduce Inficon's risk yet provide an optimum manner
to implement your design needs,
reduce both technical and cost risks, minimize direct personnel
expenses, and maximize ultimate profits.
Many people jump to the conclusion that an asic would be best here since
you mentioned Millions of units.
However, being that it appears that you have unproven technology, your
specs may change or evolve which
is much better suited toward FPGAs especially since time to market will
likely be important too.
I likely forgot to mention something but it is "after hours" :-)
We aren't particularly strong on ASICs either, not yet. Our feel is that it is
still much too early to do an ASIC regardless of projected volumes. We lean
towards high-volume FPGA's for the moment.
Alex Rast
arast@inficom.com
arast@qwest.net
Article: 42992You could open the design in floor-planner, write the constraints to a .ucf file, then edit the LOCs to RLOCs and a couple of other things. That way, you can instantiate the core as a soft macro (RPM) with floor-planning intact. The PAR tools should just do the signal routing after that. You can graphically create a RPM using group/bind in floor-planner, but unfortunately, that process doesn't currently work in hierarchial projects. Kevin Brace wrote: > > Hi, I will like to know if such a thing as an EDIF schematic editor > exists. > Lately, I have been trying to convert my design (A PCI IP core) from a > one that needs to be synthesized with the rest of the design to a > netlist so that I can reduce the backend synthesis time and be able to > instantiate the IP core from a VHDL design. (The IP core is done in > Verilog, so I hate to redo the work for VHDL.) > The problem I have been experiencing was that (See: Duplicating IOB FFs > Without I/O Pads Being Inserted in XST, How can I get rid of I/O pads > from a netlist generated by XST? for details.) XST doesn't duplicate > output and OE (Output Enable) FFs unless I add I/O pads (I/O buffers) to > the design, but just to get the FFs duplicated, adding I/O pads to the > IP core causes problems when I instantiate it from the backend module. > (NGDBUILD will give me lots of errors because of duplicate I/O pads.) > Unfortunately, the latest version of XST (Ver. E.xx) no longer generates > an EDIF file, and instead generates an encrypted .NGC file, so I cannot > tinker with the netlist at all. (I resent Xilinx for changing that.) > Fortunately, I happened to have WebPACK ISE 3.3 in a CD-R, so I was able > to use the older XST (Ver. D.xx) which generates an EDIF file. > Of course, the older XST doesn't automatically duplicate FFs, so I had > to go into an EDIF file, and manually duplicate FFs, which I hate, but I > was able to duplicate some FFs by editing an EDIF file. > However, it is sort of time consuming to have to edit an netlist by a > text editor, so I was wondering, does an EDIF schematic editor exist > where I can edit Xilinx library primitives XST generates? > Obviously, I don't use schematics, and I am poor, so if it costs > something, I probably won't get it, but just for my information I will > like to know such a thing exists. > It will be nice if ECS schematic editor that comes with ISE WebPACK can > edit Xilinx library primitives of an EDIF file. > > Kevin Brace (In general, don't respond to me directly, and respond > within the newsgroup.)Article: 42993
http://www.eetimes.com/story/OEG20020507S0033Article: 42994
Steve Charlwood wrote > I'm doing some research into trends in programmable technologies, and > would like to be able to compare the transistor counts of FPGAs and > general-purpose microprocessors. However, finding data for the FPGAs is > proving difficult. Does anyone have any reliable data for the transistor > counts of Xilinx FPGAs newer than those listed below (and ideally, the > XCV3200E and XC2V6000 devices)? > > Xilinx XC4085XL = 16 million transistors > Xilinx XC40125XV = 25 million transistors > Xilinx XCV1000 = 75 million transistors > > Note: this data comes from Xilinx's own literature. At a DAC panel two years ago a "Very High Up" Xilinx guy claimed that the high-end chips in design (VirtexII, 10K?) have 500M transistors. He also claimed that current products run at 50 transistors per (marketing) gate, which fits in with the above.Article: 42995
You can try xdl (xilinx design language). xdl -ncd2xdl will give you a text file of the design. You can edit it and change it back to ncd (native circuit description) with xdl -xdl2ncd. Then you use it like a linkable module. Steve > Unfortunately, the latest version of XST (Ver. E.xx) no longer generates > an EDIF file, and instead generates an encrypted .NGC file, so I cannot > tinker with the netlist at all. (I resent Xilinx for changing that.)Article: 42996
Russell wrote: > > http://www.eetimes.com/story/OEG20020507S0033 I also came across this recently, http://www.research.microsoft.com/fse/asml/ and it seemed to me, this could have FPGA applications. A key weakness of C, is the sequential nature of all descriptions, and the fact that FPGA "C's" are not C at all, but are some 'variant of the C programming language' - they seem more keen on getting the magic buzzword C in there, than in how it can be used practically. Throwing thousands of HW novice C coders at FPGAs sounds more a problem than a solution :-) ASML is inherently parallel, until 'step' in invoked, and thus the SAME source could potentially target an OpCode or FPGA at runtime. This from the overview > It is only after a step has been made that the new values > become visible. > In general, a computation in AsmL is not sequential unless > explicitly marked as being so. ASML would encourage 'sea of CPU' innovations on the PC, as well as FPGA implementations. Because it has a path to compile -> Runs on a PC, that also gives a Simulation path, to verify the logic on FPGA. Comments ? Jim G.Article: 42997
That was what I was hoping. I have a broker offering to sell me a number of these devices from a manufacturer's overstock, but they are industrial temp. To make it worthwhile, I would need to use them on both the comm and ind versions of the board. I just wanted to make sure I would not have any problems. Now to see if I can get a better price than what disti will give. Peter Alfke wrote: > > Good question, and here comes the good anwer: > There is only one speeds file for any part. The ac parameters are identical > for the commercial and industrial part. Because it has to guarantee the same > performance over a wider temperature range, the I part is better (faster), > but all performance numbers are the same. > This has been the rule in Xilinx since times immemorial, i.e. since 1985. > > Peter Alfke, Xilinx Applications > =========================================== > rickman wrote: > > > Can anyone say with any certainty that the timing of an XC2S200E-6FG456I > > will be the same as the XC2S200E-6FG456C? I need to do a design for > > both versions and we will be building boards with both versions of the > > FPGA. Some will actually be industrial boards, but sometimes we will > > use the industrial versions of the FPGA on the commercial temp boards if > > that is the FPGA we have on hand. > > > > Will I expect to see any differences in timing between the three > > verisons of the board (comm chips run at comm temps, ind chips run at > > comm temps and ind chips run at ind temps)? I know the ind chips will > > run better if kept within the comm temp range, but are the timing files > > the same? If I do a design that meets timing for the comm temp chip, > > can I expect that to meet timing in the ind temp chip at either temp > > range? > > > > -- > > > > 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 FAX -- 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: 42998
Anyone out there have a pinter to a reference DDR design (or IP) they care to recommend ? Bob Elkind, eteam "Spam Hater" <spam_hater_7@email.com> wrote in message news:3cd933cf.3018963@64.164.98.7... > > Xilinx has two DDR reference designs available for free. > > And (almost) worth every penny. > > > > On 8 May 2002 00:45:00 -0700, eyals@hywire.com (Eyal Shachrai) wrote: > > >Hi , > > > >I'm working on a project which involves a xilinx's virtex-ii fpga. > >the core of this fpga will run with a 125 MHz clock and interface with > >a 250 MHz data rate DDR SRAM. > >I would like to know whether xilinx have a reference design of a DDR > >SRAM controller. and if not , would it be smart to use the QDR > >referance design (xapp 262) with some modifications , as a DDR > >controller? > > > >Thanks > > Eyal. >Article: 42999
Hi, I am having a problem in verilog back-annotated simulations as described below.Many thanks to anyone who can suggest a workaround. Everything was O.K with earlier versions of Xilinx SW and hence design issues are ruled out. In my design , I take Clk_66 as input and internally generate Clk_132 using DCM and external feedback. Some of the I/O's of FPGA are driven by logic running at Clk_66 while some other by logic running at Clk_132. My problem is that Xilinx verilog writer has added X_SUH elements for all the I/O's with clk as Clk_66..This is resulting in a setup violation being reported for all Clk_133 inputs. The PAR does not report any static timing violations. Please let me know if anyone has encountered something similar. Thanks Venu
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