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
Jurjen,
I helped write the Power On power supply specification, so maybe I can shed some
light on it.
The Spartan II is a Virtex derivative. Virtex has a requirement for 500 mA
minimum current capacity from the power supply, with the core voltage rising
within 2ms to 50 ms time window (any rise time slower than 2, or faster than 50,
is allowed).
Since a typical current requiement is a useless parameter, it does little to
tell you that 150 mA is typical, because the next part you get may be a little
more (or a little less).
Evey single part is tested so that you are gauranteed that if you have 500 mA
available, the part will power on cleanly, and startup properly, and configure.
This is a most important specification for a FPGA. Who else tests and specifies
that EVERY device will power on cleanly with any specified minimum current
capacity, and tests every device? I designed telecom equipment for twenty
years, and without a spec like that, I don't even consider the part for use.
If you look at TI's DSp's, or Intel's microprocesors, they require their own
special power control IC's in order to operate at all! At least we use the same
voltages that other devices do.
I am sorry that 500 mA is too much current for your application. I am aware
that a number of Spartan II potential customers are concerned with this issue.
I have yet to perform all of the power on characterization for all members of
the Spartan II family in the FPGA Lab, over all process corners and
temperatures, so we must stick to what we know right now.
We have a applications note in process for a "jump start" circuit to get the
Spartan II over the hump (so to speak) that you may contact me directly on at
austin@xilinx.com if you are interested. It uses a slightly larger capacitor
ahead of the core voltage regulator, and a hold off circuit (RC) for the
existing LDO core voltage regulator. At the expense of two added components (R
and C) it should be a useful circuit. We need to verify its operation over all
process corners, temperatures, and voltages, so there is work to do.
Austin
Jurjen Boss wrote:
> Hi,
>
> We want to implement a Xilinx Spartan-II FPGA, type XC2S50, in our
> (excisting) application. I'm trying to estimate the current supply of this
> device by using the datasheets ("Spartan-II 2.5V FPGA Family: DC and
> Switching Charateristics"). From this datasheet I get the following
> information:
> - Iccintq = 50mA; (supply current internal part)
> - Iccoq = 2mA; (supply current I/O-part)
> - Iccpo=500mA; (ramp rate 2ms)
>
> Does this FPGA needs so much current at power-up? How can this ramp rate be
> adjusted? I just can't imagine that this FPGA needs 500mA at power-up. I
> thought these devices where low-power!?! Is there some information available
> on this subject?
>
> Regards,
>
> Jurjen
Article: 27526Walter Haas wrote: <snip> > I am loving the clock enable signal though. My 5th clock is a 50MHz clock, which comes out of a DLL as a /2 of a 100MHz clock, which of course is on a global resource. If the USELOWSKEWLINES doesn't work, I'll try this. Thanks again for all your help. > > Cheers, > > Wally If you use the 1/2 speed output of the DLL then using the slow clock as a clock-enable for the fast ones becomes subject to DLL output-output skew as well as differential delays between the global clock networks are the secondaries. I've just been bitten by this when making domain changes between a 100MHz clock and its DLL double. [Fortunately I found this at the RTL level where I use a DLL model that deliberately introduces some clock jitter & skew - this piece of last year's paranoia has just paid off] You might consider making your 50MHz via a divide from the 100MHz so that the slow clock's edges are always after the fast clock's rising edges.Article: 27527
> I have just finished a roll-your-own FIFO. I addressed the problem > you mention by using two separate counters. One points to read > addresses and the other points to write addresses. The counters each > have their own enables and clocks, and these need not be synchronized > with each other. The counters are incremented only, never > decremented. I would also strongly recommend the use of gray coded counters, or your flags 'may' not always be correct.Article: 27528
In article <4DuR5.40671$Ze6.8222612@typhoon.tampabay.rr.com>, sramirez@deleet.cfl.rr.com (S. Ramirez) wrote: > Rex, > Perhaps your students will learn a valuable real world lesson from > Mark -- after all of the arguments are heard about how great a certain > vendor's tools are, most of the time the decision boils down to cost! But Altera have a free package too! > -Simon Ramirez, Consultant > Synchronous Design, Inc. > > > ******************************************************************** > "Mark Harvey" <mark.harvey@iol.it> wrote in message > news:8bqR5.81326$BF.2913634@news.infostrada.it... > > Why not use the Xilinx Webpack? -it will allow your students to use > > both > > CPLDs and Spartan-II and Virtex 300E FPGAs - and it's free! -- Steve Rencontre http://www.rsn-tech.co.uk //#include <disclaimer.h>Article: 27529
Hi Rick, Why not upgrade to a Athlon 1.2GHz, with 133MHz DDR? Then you can tell me whether or not I should do the same! Cheers, Phil Martin "Rick Filipkiewicz" <rick@algor.co.uk> wrote in message news:3A182F81.6F328944@algor.co.uk... > I've just upgraded my NT PC to a 600MHz PIII from a 450MHz PII and, to > my surprise, there's no discernable improvement in speed. Synplify is > exactly the same and the Xilinx PAR improves by a measly 2-3 min on a > run that used to take just over an hour. > > Am I doing something wrong or are these processes so memory bound that I > might as well use anything as long as its got 100MHz SDRAM ? [or an > Athlon PC with DDR memory]. > > Both PCs have 100MHz motherboards & I did remember to set the L2 cache > size entry in the registry. With 384MB of memory I'm nowhere near the > swapping limit. > >Article: 27530
The Xilinx 2.1i Simulation libraries are in the industry standard Verilog and VHDL languages. Therefore, you can use these libraries from either the PC or the WS. If you're talking about back-annotated (timing) simulation, you can use the time_sim.v and time_sim.sdf files to run simulation on either platform. The only problem might be that NC-Verilog might choke while reading a text file written on the PC platform. YOu can use a dos to unix conversion utility to get around that, if that happens. Mujtaba chsw wrote: > hello: > when i have synthesis my project in Windows NT on the platform of the pc,i plan to simulate with NC-VERILOG in Solaris 2.6 platform.how do i? Can the library of the xilinx Foundation 2.1i of the pc be used in NC-VERILOG in the Solaris?Article: 27531
Hi I'm finally going to bite the bullet and buy a board - just want to double check that my final selection is ok for what i want to do. Is a XS40-005XL ( http://www.xess.com/prod004.html ) board suitable for hardware evolution, has anyone actually used it for that purpose ? I'd like to be able to program it with a C or Java API, is there suitable for that ? All suggestions welcome. Thanks David Sent via Deja.com http://www.deja.com/ Before you buy.Article: 27532
Unless im mistaken, (considering I own one of these boards.) You dont map out the FPGA with C or Java, you use Xilinx Foundation.Article: 27533
On Mon, 27 Nov 2000 22:22:32 GMT, longwayhome@my-deja.com wrote: >Is a XS40-005XL ( http://www.xess.com/prod004.html ) board suitable for >hardware evolution, has anyone actually used it for that purpose ? I'd >like to be able to program it with a C or Java API, is there suitable >for that ? All suggestions welcome. I supposed you have noticed that there is a JBITs interface avaiable for that board? You can download it from XESS 'examples' web page. / JonasArticle: 27534
Question 1: How can I take a Xilinx Virtex FPGA design that contains instance-unique ROM (ROM values unique to each module/unit manufactured) and keep my core logic the same, but update the ROM for each SPROM/board manufactured, preferably without having to re-synthesize, re-place & route, re-verify, etc.,? Ideally, the designer would have a generic logic bitstream (with anything in the ROM) and be able to merge/append/over-write the ROM with the desired-ROM-contents file that is unique to each board. Note: whether the ROM is truly ROM or really RAM that can be further written over by the mission logic is irrelevent, the key is that at power-on the memory is ROM and has the desired unique values. I'm thinking specifically about building the ROM with BlockRAM, but the problem may be equally relevent to ROM built with the distributed, LUT-based RAM, too. Question 2: Suppose I want to build a 4kx8 ROM from instantiated BlockRAM (8 instances of 4kx1 aspect ratio RAMs), as opposed to inferred ROM via a big case statement. The required INIT statements (in the HDL code) to provide the right values for simulation & synthesis require a non-trivial bit-slicing & parsing operation to assemble the INIT statements from the ideal representation of values (i.e., one text file of 4k lines, where each line is a 8-bit binary or hex value). Are there any programs (shareware or $$) to do this bit-slicing & parsing or does everyone have to write their own C programs to do it? ============================== William Lenihan lenihan3weNOSPAM@earthlink.net .... remove "NOSPAM" when replying ==============================Article: 27535
For a product which will be manufactured in medium quantity but over a long period of time (> 10 years) we have to use a System On Chip We plan to use an FPGA and we have the choice to use an hard core (like Triscend or ATMEL FPSLIC) or a soft core (like NIOS) We think that the first solution is less expensive, but the other will garantee us a better availability can you give us your opinion about this choice? -- Pierre VERNEL ENSEM - INPL 2 avenue de la foret de Haye F 54516 VANDOEUVRE les NANCY Tel : +33 (0)3 83 59 55 70 Fax: +33 (0)3 83 59 55 73 Email:vernel@ensem.u-nancy.frArticle: 27536
In article <8vu6e5$3eu$1@nnrp1.deja.com>, nishioka@my-deja.com wrote: > Xilinx kindly allows me to use a variety of I/O standards. I am using a > Virtex-E. > > From a signal integrity and EMI standpoint, would it be better to use > LVDS at 150MHz or properly terminated single ended signals at 75MHz? > > These signals are being driven between pin limited FPGA's, so since LVDS > uses twice as many pins, I need to double the frequency to get the same > data rate. > > I greatly appreciate any insight into this issue. > > Alan Nishioka > > Sent via Deja.com http://www.deja.com/ > Before you buy. > I would use LVDS. Only with LVDS it is possible to have a well specified line impedence and therefore a well defined line termination. You have smaller currents and you avoid the crosstalk between the single TTL lines. LVDS should also behave much better with respect to EMI. Best regards Klaus -- Klaus Falser Durst Phototechnik AG I-39042 Brixen Sent via Deja.com http://www.deja.com/ Before you buy.Article: 27537
Bill Lenihan wrote: > Question 1: > > How can I take a Xilinx Virtex FPGA design that contains instance-unique > ROM (ROM values unique to each module/unit manufactured) and keep my > core logic the same, but update the ROM for each SPROM/board > manufactured, preferably without having to re-synthesize, re-place & > route, re-verify, etc.,? Ideally, the designer would have a generic > logic bitstream (with anything in the ROM) and be able to > merge/append/over-write the ROM with the desired-ROM-contents file that > is unique to each board. Note: whether the ROM is truly ROM or really > RAM that can be further written over by the mission logic is irrelevent, > the key is that at power-on the memory is ROM and has the desired unique > values. I'm thinking specifically about building the ROM with BlockRAM, > but the problem may be equally relevent to ROM built with the > distributed, LUT-based RAM, too. > The solutions are either J-bits or convert the routed database to text form via xdl, hack the init statements, then back to binary via xdl again. Beware with xdl though since including the ``pips'' routing info leads to huge text files. Run xdl -h to find out how to turn off the pips [I *think* its -nopips]. > > Question 2: > > Suppose I want to build a 4kx8 ROM from instantiated BlockRAM (8 > instances of 4kx1 aspect ratio RAMs), as opposed to inferred ROM via a > big case statement. The required INIT statements (in the HDL code) to > provide the right values for simulation & synthesis require a > non-trivial bit-slicing & parsing operation to assemble the INIT > statements from the ideal representation of values (i.e., one text file > of 4k lines, where each line is a 8-bit binary or hex value). Are there > any programs (shareware or $$) to do this bit-slicing & parsing or does > everyone have to write their own C programs to do it? > > I suspect you could probably do this in < 16 lines if you used Perl instead of `C'. Note that the xdl stuff above's also much easier to do in Perl - I've done a fair bit of Perl hacking on xdl data bases.Article: 27538
Walter Haas wrote: > > Ahh...you guys are classic.. > > Well, I understand the validity of the master-slave architecture, but I'm sorry when I'm coding in HDL, I would like to try and get above trying to split my domains into posedge and negedge designs. Not only that, wouldn't this design have to run at twice the speed, because now I only have 1/2 the clock cycle for my logic to complete (posedge to negedge)? And hand placing even a portion of a multi-million gate design? Unless it's less than 100 gates, then fuh-get it :) I do floorplanning on multimillion gate designs regularly. The key is to use hierarchy. I have many smaller design elements that are placed in the VHDL code. At the to p level it becomes a fairly simple exercise of placing a few RPMs. > > I am loving the clock enable signal though. My 5th clock is a 50MHz clock, which comes out of a DLL as a /2 of a 100MHz clock, which of course is on a global resource. If the USELOWSKEWLINES doesn't work, I'll try this. Thanks again for all your help. Careful about using the DLL /2 as your clock enable. It is very easy to violate the setup/hold at the flip-flop. > > Cheers, > > Wally -- -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 or http://www.fpga-guru.comArticle: 27539
This is my last chance... I have floorplanned an XCV2000E device through UCF by using LOC= commands. But PAR fails. The error is that PAR cannot place any more CLB, and it doesn't go any further. I have to use M2.1i SP6 for 3 weeks at least. The problem is, although PAR tells me that it is not possible to place a logic group to its rectangular area defined in UCF, I can see in FPGA Editor that there is a lot of space free in that rectangular. What strange is, that, when I don't use any placement constraint with UCF, the PAR is perfect to assign any logic in any area. But when you use something like: INST "top/block_bla_bla/*" LOC=CLB_RtlCtl:CLB_RbrCbr; (tl = top left corner of rectangular area) (br = bottom right corner of rectangular area) .. then PAR tries starts to place corresponding logic group from leftmost column and from lowermost row in its own rectangle. Only after it uses any complete column it advances next right column. And abnormally it stops to place the logic. If I open the FPGA editor and if you look at that rectangular area, I see lots of space is still not used. Why does PAR behave like this, when I define an area for a logic? I have looked at "all" postings in this newsgroup regarding this thing, couldn't find any mail. I have looked at "all" solutions at Xilinx database, there is no solution related to this. Is there anybody who faced this problem? I must use M2.1i SP6, for at least 4 weeks. UtkuArticle: 27540
Instantiate the 'OSC4' primitive in your HDL/Schematic and it should work - If I remember correctly, there is a limit of two 'taps' that can be used simultaneously. I have also noticed that the oscillator frequencies vary quite a bit, but for simple LED stuff (aka evaluation board) it works fine.Article: 27541
Pierre, the biggest advantage of NIOS is that it can never be discontinued and you'll never again have to re-write software because the previously chosen processor is no longer available. I think this is a tremendous advantage which the engineering community has not realized yet. When you build a NIOS core including it's peripherals and interfaces you'll get generic VHDL or Verilog code which you can synthesize to any architecture (there are only minor blocks instantiated). O.k. there's the license which only allows Altera but I think they'll always be around and future devices will be able to support NIOS. In current devices NIOS supports up to 50 MIPS. With APEX 20KC this will change significantly and it will be even faster in future devices. The only reason I could think of, that suggests a hard core is performance. If 50 MIPS is not enough your probably better off with a hard core solution - as long as there's a higher performance solution available yet. When you implement NIOS in an ACEX 1K device, which we successfully did, the silicon cost for the processor core is only about US-$ 5,- and the complete development environment is only US-$ 995,-. Best regards Wolfgang Loewer /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ El Camino GmbH Your Programmable Logic Design House http://www.elca.de /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Pierre VERNEL <vernel@ensem.u-nancy.fr> wrote in message news:8vvoif$igp$1@arcturus.ciril.fr... > For a product which will be manufactured in medium quantity but over a long > period of time (> 10 years) we have to use a System On Chip > > We plan to use an FPGA and we have the choice to use an hard core (like > Triscend or ATMEL FPSLIC) or a soft core (like NIOS) > > We think that the first solution is less expensive, but the other will > garantee us a better availability > > can you give us your opinion about this choice? > > -- > Pierre VERNEL > > ENSEM - INPL > 2 avenue de la foret de Haye > F 54516 VANDOEUVRE les NANCY > Tel : +33 (0)3 83 59 55 70 > Fax: +33 (0)3 83 59 55 73 > Email:vernel@ensem.u-nancy.fr > > >Article: 27542
On Tue, 28 Nov 2000 08:50:09 +0100, "Pierre VERNEL" <vernel@ensem.u-nancy.fr> wrote: >For a product which will be manufactured in medium quantity but over a long >period of time (> 10 years) we have to use a System On Chip > >We plan to use an FPGA and we have the choice to use an hard core (like >Triscend or ATMEL FPSLIC) or a soft core (like NIOS) > >We think that the first solution is less expensive, but the other will >garantee us a better availability > >can you give us your opinion about this choice? I think one thing is pretty much certain: no ic fpga available today will be available for purchase in 10 years. So you have to buy end-of-life parts within three years or so which makes the availability issue moot. But if you get the NIOS version, you can make enhancements if you need to. Muzaffer FPGA DSP Consulting http://www.dspia.comArticle: 27543
"Jason Daughenbaugh" <jad@aedinc.net> wrote in message news:ee6ed1a.2@WebX.sUN8CHnE... > Asynchronous FIFOs are quite possibly one of the most difficult modules to implement. In order to get water-mark flags to work properly (half-full, etc) you really need to use gray codes. The Xilinx app notes describe this well. One problem we had with the Xilinx app note FIFOs is that they use pipelined counters -- keeping around what the current gray count is, the next gray count, etc., and incrementing them in lock step -- and on a somewhat random basis the full and/or empty flags would go active when, indeed, we knew we hadn't really overflowed or underflowed the FIFO. Our best guess as to the cause of this was that we were using GSR as the reset input to the FIFO but also asserting either REn or WEn just as GSR went inactive, and one of those pipelined counters was getting corrupted (i.e., there was a race condition between the various counter bits with GSR going inactive and a clock arriving with REn or WEn active). (Note that the FIFO specifically allows you to assert REn or WEn when the FIFO is empty of full, respectively; it internal gates the signals so that they're ignored when neeeded.) I'd be curious to know if anybody else has had this experience. We ended up adding additional logic to make darn sure our REn and WEn signals were inactive until well after GSR had gone inactive, and that appeared to have solved the problem. I don't consider this as 100% proof that we really know what the problem was in the first place, however. :-) ---Joel KolstadArticle: 27544
On Tue, 28 Nov 2000 08:50:09 +0100, "Pierre VERNEL" <vernel@ensem.u-nancy.fr> wrote: >For a product which will be manufactured in medium quantity but over a long >period of time (> 10 years) we have to use a System On Chip > >We plan to use an FPGA and we have the choice to use an hard core (like >Triscend or ATMEL FPSLIC) or a soft core (like NIOS) > >We think that the first solution is less expensive, but the other will >garantee us a better availability > >can you give us your opinion about this choice? I think one thing is pretty much certain: no fpga available today will be available for purchase in 10 years. So you have to buy end-of-life parts within three years or so which makes the availability issue moot. But if you get the NIOS version, you can make enhancements if you need to. Muzaffer FPGA DSP Consulting http://www.dspia.comArticle: 27545
Hi everybody <Hi Dr. Nick> :) I didn't mean to imply that I'd use the 50MHz clock as a clock enable. I would actually just have a data_valid register, that was essentially just a flop with an inverter between it's Q->D data path, and that signal would be the clock enable. The rest of my design would consist of multi-cycle paths (2 cycles), because the FFs couldn't change on the odd cycle, and I'd still get the nice combinatorial buffer. Cheers, WallyArticle: 27546
Hi all, I access this forum through the Xilinx Support page, but I was hoping someone could tell me how I can access it through Netscape Navigator. Some fairly explicit instructions on what to set up in Navigator would be very helpful. Cheers, WallyArticle: 27547
Walter Haas wrote:
>
> Hi all,
>
> I access this forum through the Xilinx Support page, but I was hoping someone could tell me how I can access it through Netscape Navigator.
>
> Some fairly explicit instructions on what to set up in Navigator would be very helpful.
1) Set up news server
- Edit -> Preferences -> Mail&Newsgroups -> NewsGroup Servers -> Add
- enter the name of your NNTP server.
- OK
2) Subscribe to comp.arch.fpga
- Select the news server in the name column
File -> Subscribe
Then wait for all news group names to be loaded
- Open comp.*
Open comp.arc.*
Double click on comp.arch.fpga
look for the check mark in the subscribe column
select OK
3) Read newsgroup
- Open the news server (click on the '+')
- double-click on comp.arch.fpgs
- Select message to read
----
Keith
Article: 27548Whoops! I really mean Netscape Messenger. The Mail and Newsgroup tool from Netscape. Cheers, WallyArticle: 27549
> For a product which will be manufactured in medium quantity but over a long > period of time (> 10 years) we have to use a System On Chip > > We plan to use an FPGA and we have the choice to use an hard core (like > Triscend or ATMEL FPSLIC) or a soft core (like NIOS) > > We think that the first solution is less expensive, but the other will > garantee us a better availability > > can you give us your opinion about this choice? Pierre: The Triscend development tools will let you design your system more quickly, and the Triscend chips have special-purpose circuitry for interfacing the microcontroller core to peripherals implemented in the FPGA section. So you may not be as distracted by details if you use Triscend. (These statements may also be true if you use Atmel's FPSLIC, but I have no experience with it.) You will need to be more concerned with the details of interfacing a soft microcontroller core with other circuitry in a general-purpose FPGA, and you will use more of the FPGAs resources to implement the interfaces between the FPGA and the peripherals. But FPGAs are only getting bigger and cheaper so the resources used for glue-logic may not be much of a concern. The FPGA design tools will not hide the details like the Triscend tools do, so you will have to spend a bit more time creating your design. But you also get complete freedom to modify the circuitry to fit your application. And you can move your design to another FPGA family if your current device gets discontinued. (Assuming you have access to the source-level description of the core and there are no licensing restrictions.) As for speed, the FPGA manufacturers are fabbing chips at 0.18u right now while Triscend is currently at 0.25u with their new ARM7 CSoC. So the hard core in a Triscend chip may not get you much more speed than a soft core in an FPGA. Especially if you optimize it for your application. > > > -- > Pierre VERNEL > > ENSEM - INPL > 2 avenue de la foret de Haye > F 54516 VANDOEUVRE les NANCY > Tel : +33 (0)3 83 59 55 70 > Fax: +33 (0)3 83 59 55 73 > Email:vernel@ensem.u-nancy.fr -- || Dr. Dave Van den Bout XESS Corp. (919) 387-0076 || || devb@xess.com 2608 Sweetgum Dr. (800) 549-9377 || || http://www.xess.com Apex, NC 27502 USA FAX:(919) 387-1302 ||
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