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
Kenneth, Put the period on the input clock to the DCM. The Xilinx tools will create the necessary period constraints for the output clocks of the DCM. Kate Kelley Kenneth wrote: > Dear all, > > Sorry, I added the following line to UCF file(I typed wrongly in my > previous post) > > NET "CLOCK/dcm0_clk1x" TNM_NET = "CLOCK/dcm0_clk1x"; > TIMESPEC "TS_CLOCK_dcm0_clk1x" = PERIOD "CLOCK/dcm0_clk1x" 25 ns HIGH > 50%; > NET "CLOCK/dcm0_clk2x" TNM_NET = "CLOCK/dcm0_clk2x"; > TIMESPEC "TS_CLOCK_dcm0_clk2x" = PERIOD "CLOCK/dcm0_clk2x" 12.5 ns HIGH > 50%; > NET "CLOCK/dcm0_clkfx" TNM_NET = "CLOCK/dcm0_clkfx"; > TIMESPEC "TS_CLOCK_dcm0_clkfx" = PERIOD "CLOCK/dcm0_clkfx" 6.25 ns HIGH > 50%; > (the hierarchy is Top_level -> CLOCK -> DCM0, > and the net name of the 1x output is dcm0_clk1x, > 2x output is dcm0_clk2x, > 4x output is dcm0_clk4x) > > Thanks again. > > Regards, > Kenneth > > Kenneth wrote: > > > > Dear All, > > > > I am not clear about how to set the timing constraint in VirtexII > > device when using the build-in DCM. > > > > Currently I am using Synplify Pro 6.2 for synthesis and Xilinx ISE > > 3.308i for implementation. My Design use an external 40MHz clock, > > and is fed into a DCM. Within the design, I use both the 2x(clk2x) > > and 4x(clkfx) clock output of the DCM to clock the internal logics. > > > > In the Synplify Pro, there is a field for me to specify the required > > operating frequency. However no matter what value(e.g. 40MHz) I set, > > the implementation will treat all the clock(1x, 2x and 4x) have the > > same timing constraint of 40MHz(this is shown in the Place and Route > > Report after the implementation). As a result, I got a poor > > implementation result. > > > > Even I add the the following constraints in the UCF file, > > > > NET "CLOCK/dcm0_clk1x" TNM_NET = "CLOCK/dcm0_clk1x"; > > TIMESPEC "TS_CLOCK_dcm0_clk1x" = PERIOD "CLOCK/dcm0_clk1x" 25 ns HIGH 50 > > %; > > NET "CLOCK/dcm0_clk2x" TNM_NET = "CLOCK/dcm0_clk2x"; > > TIMESPEC "TS_CLOCK_dcm0_clk2x" = PERIOD "CLOCK/dcm0_clk2x" 12.5 ns HIGH > > 50 %; > > NET "CLOCK/dcm0_clkfx" TNM_NET = "CLOCK/dcm0_clkfx"; > > TIMESPEC "TS_CLOCK_dcm0_clkfx" = PERIOD "CLOCK/dcm0_clkfx" 12.5 ns HIGH > > 50 %; > > (the hierarchy is Top_level -> CLOCK ->DCM) > > > > the Place and Route Report still shown that the required frequency > > for all clock are 40Mhz. > > > > So, what should be the correct method to set the timing in my case? > > > > Thanks in advance. > > > > Regards, > > KennethArticle: 37026
Kamal Patel wrote: > > Hello Rick, > > Devices supported in WebPACK besides all Xilinx CPLDs include > Virtex-E and Virtex-II devices up to 300K and all Spartan-II and > Spartan-IIE devices. I was asking so that I could be sure that the new VII parts were actually in the WebPack rather than just being planned for support. Thanks. > The main features that WebPACK is missing when compared to the > Foundation version of ISE are Core Generator, FPGA Editor, and > FPGA Express synthesis. > > As far as OS support, Windows XP is not officially supported but > many cases have been seen where the software has worked fine. > I know that the Xilinx support team has a machine with a fresh > install of XP up and running with no changes to the OS. You may > want to get in contact with an FAE about this as they've probably > seen cases for both sides of the story. > > I hope this helps. > > Regards, > Kamal Any idea when Xilinx plans to "officially" support XP? I really don't want to have to use an older copy of Windows and I don't want to have a dual boot machine, or triple boot machine since you don't support Win95 anymore :) -- 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: 37027
> > This is not for the faint of heart, and is considered advanced even > for Xilinx FAE's but it works great. Turn your little submodule into a > hard macro. This will fix the placement and routing. The other nice > thing about this is that every instatiation will be routed idencly, > instead of randomly. I use it mostly for circuits that have clocks > that are not on the globabl clock net. It's the only way I can > gurantee that I get a good route on the clock net everytime. > > This will get you started: > see Xilinx Answer Database record #10901 "FPGA Editor - How do I > create a hard macro?" > > Oh, and make sure you use LOCs for every instantiation of the macro, > otherwise your PAR time will go up, not down. > > Mark 5. To maintain the relative placement of the CLBs/Slices in the Macro, select a CLB to use as the reference, and go to Edit -> Set Macro Reference Comp. This will effectively create an RPM, and will make the system's timing as consistent as possible. Keep in mind that it is impossible to lock down routing, so there are no guarantees that the asynchronous paths will not change. This is from the answer record you mentioned. It says it is impossible to lock routing, so how did you get the clock route locked down? BryanArticle: 37028
"Rick Filipkiewicz" <rick@algor.co.uk> wrote in message news:3C0535D4.868C1E65@algor.co.uk... > o Do they relate to VirtexE's in the same way as SpartanII did to the > Virtex ? Esp wrt timing. http://fpgacpu.org/#011120: "You might think that as Virtex-E is to Virtex, so is Spartan-IIE to Spartan-II But you would be wrong. According to data sheets, whereas an XCV200 has 14 BRAMs (56 Kb) and the XCV200E has 28 BRAMs (112 Kb), in the Spartan-II/E family, both the XC2S200 and (alas) the XC2S200E have the same 14 BRAMs (56 Kb). ... But let us count our blessings. The new Spartan-IIE family is lower-voltage, faster (470 ps TILO (2SxxxE-6) vs. 700 ps TILO (2Sxxx-5)), offers a larger part (the 32x48 CLB = 6144 logic cell XC2S300E), supports tons of different I/O signalling standards, and (thank you Xilinx) comes in TQ144 and PQ208 QFP packages. " Jan Gray Gray Research LLCArticle: 37029
rickman wrote: > I can't say anything about the connection to the Virtex IIE parts except > that I expect that is correct. Spartan-IIE is functionally identical to Virtex-E, but has fewer BlockRAMs, and slightly different (?) timing parameters, and it comes in different packages and fewer speed grades. Peter Alfke > > > But the FT package is just a lower profile version of the FG package. > There are a lot of applications where height is very, very important. > Didn't you go to the web site to find the packaging data sheet? That is > where I found it. >Article: 37030
Rick, All fair and reasonable comments. The Virtex II has agressive forward pricing as a new product, and you would need to contact your appropriate sales channel. The prices you quote, are of course, today's list prices. I would say that some very large accounts are looking at the 2V40 and 2V80, where they would normally be interested in the Spartan IIE parts, and they have no problem with the pricing. Your comments on IOs are equally valid as to the numeric count, but if a Virtex II will support a ~380 Mb/s DDR IO, and a Spartan IIE supports a ~160 Mb/s DDR IO, Virtex II wins from a bits per second per package point of view. If you go to 700 Mb/s using LVDS, you only get 350 Mb/s per pin, still pretty respectable. Additionally, Spartan IIE has fewer power and ground pins than Virtex E, so the SSO table is less agressive, so unless you just need lots of LEDs and switches (which a lot of Spartan applications do require), you can't really run the IOs as agressively. So the ~160 Mb/s per pin of Spartan IIE is not sustained across as many IOs (exceeds SSO guideline). So what to choose? I would suggest that you look at more than just the pin counts, and look into the speeds, strengths, SSO's, and so on. Maybe Spartan IIE is the best for you. As for 2 amperes at -40C, this is the legacy of the orginal Virtex design, and we have only had the opportunity to address it in Virtex II, as Virtex E and Spartan II and Spartan IIE are all derivatives of the original Virtex design. Again, this specification as well, is under revision as we characterize Spartan IIE, and Spartan IIE. I would also like to say that the Virtex family and it derivatives is the best selling FPGA 'dynasty' in the history of FPGAs. It is hard to argue with that kind of sucess, so I will only suggest that using the 2V40 is an option, and one that should be considered. Austin rickman wrote: > Austin, > > I don't mean to pick on Xilinx, but to suggest that the Virtex II family > is a good replacement for a Spartan II device is hard to understand from > a cost and IO count perspective. > > Here are some devices side by side. All IO counts and prices are for the > slowest speed grade in the FG256/FT256 packages. > > Part IO Slices Price > XC2S50 176 768 $17 > XC2V40 88 256 $35 > > XC2S100 176 1200 $25 > XC2V80 120 512 $43 > > XC2S200 176 2352 $33 > XC2V250 172 1536 $79 > > As you can see there is no comparison between the actual part size, IO > count and price. To get an equivalent chip you would need to spend at > least double the money and more likely 3 or 4 times the money. > > The Virtex II chips may have solved the startup current issue, but they > are hard to justify in a cost sensitive application. I am fully aware of > the unique features of the Virtex II family. There is the DCM, the > bigger memory, the multipliers. But these features can only improve > usability if you need those features. I would love to have the DCMs on > my next board. But I can't justify the $146 price tag for the parts to > get the IO count I need when I can get an XC2S part for $35. > > If my information is incorrect, please let me know. I have been trying > to find out if the Virtex II prices will be coming down in the near > future and I am not hearing anything to make me think so. > > BTW, you quote 500 mA startup current in the commercial temp grade, but > in the industrial grade it is a full 2.0 AMPS per chip!!! Makes it hard > to turn on a board with 3 or 4 chips on it. > > Any idea when the updated info will be available? I am looking at a new > design and can't use the Spartan II chips until I know if I can power up > the board with the available power source. > > Rick Collins > > Austin Lesea wrote: > > > > Brad, > > > > In the data sheet there is a 'Supply Current Requirements During Power On' > > section for all Xilinx FPGAs. > > > > http://www.support.xilinx.com/partinfo/ds001_3.pdf > > > > This states clearly what the power supply must supply to power on the > > device reliably, 100% of the time. > > > > For a Spartan II, the current in the latest data sheet is 500 mA (C parts) > > for all device members. > > > > This number is under present study, and we are changing the data sheet to > > reflect the result of a massive re-characterization of the material from > > the fab's. > > > > It turns out that the smaller devices do not require as much current as > > the larger ones. > > > > As for why CMOS draws current? It isn't as simple as everyone suspects. > > If it was, then anyone would be able to make cost effective reliable > > FPGAs. Obviously, that isn't the case, and the hundreds of > > engineer-years that we dedicate to each family of FPGAs would not be > > required. > > > > There are many reasons why current can accumulate to large values. > > > > I will say that Virtex II is a much better choice for new small designs, > > where extremely low startup power is desired. Look at the similar section > > there. The 2V40 is 512 LUTs, so small is not an issue, and the price is > > pretty good there, too (simialr to Spartan pricing). > > > > Austin > > > > Brad Eckert wrote: > > > > > At a recent FPSLIC seminar, Atmel's marketing guy mentioned that some > > > FPGAs have high startup current (a couple of amps) so their FPSLIC > > > would have simpler power requirements than a soft CPU. > > > > > > Is this still true? I'm looking at a Spartan II XC2S30 or XC2S15 for a > > > soft CPU. Even a 1A startup current is a little hard to imagine, since > > > you'd expect the logic to start out in a cleared state. > > > > > > Can anyone tell me what kind of startup current to expect from low > > > cost FPGAs like Spartan or ACEX? > > > > > > -- > > > Brad Eckert > > -- > > 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: 37031
mrgs1000@yahoo.com (Mark) writes:
> Kees van Reeuwijk <C.vanReeuwijk@twi.tudelft.nl> wrote in message news:<3fl90u
k0l3mmebi1703urlud5e91rou5af@4ax.com>...
> >
> > I understand that the scarcity of such software is partly because
> > vendors do not release enough information. Are there any modern devices
>
> I would venture to say that the primary road block to open-source
> tools is that they are too dificult to support and keep current for
> people to do for free.
As opposed to tons of video and ethernet chips that the Linux people
seem to have no great problem with?
Just simply support those chips that members of the open source group
use. And the software users then buy those parts.
Hint to vendors: if your part has open source support, it gets more
recommendations ("take that one, it works"), and you get to sell more
of them. I principially buy video and ethernet cards after consultion
the on-line support databases.
> There are lots of flows for design entry and
> simulation,
Just support those that the present maintainers use. And use those
that are supported.
> and new devices are released on a weekly basis. I
Huh? As far as I see it Xilinx has so far created about 9 families
(2000 3000 4000/Sparten 4000XL/SpartanXL 5200 6200 Virtex/SpartenII
VirtexE/SpartanIIE Virtex2) in 15 years. Altera has 8 families
(MAX3000 MAX7000 MAX9000 FLEX6K FLEX8K FLEX10K/ACEX APEX Mercury)
in over 10 years. Lucent has IIRC 4 families of ORCA. Atmel 2
families (4000 6000). Actel I do not know, as I can not read their
website (damn Flash and not HTML alternative). And a few other
irrelevant manufacturers.
So that makes about 2 falimies per year industrywide to support. Or
simply only support a few of them and only use those.
> occasionaly start using parts before they are released so I would not
> be able to wait for open-source tools to have the support. In fact, I
> have started designs where the vendors own tools didnt suport the part
> I was using.
Does not look like you are an average user there. :-)
--
Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/
Hacker, Unix Guru, El Eng HTL/BSc, Sysadmin, Archer, Roleplayer
- Intellectual Property is Intellectual Robbery
Article: 37032adrian wrote: > > I'll tell you exactly what I need it for. I have designed an FPGA based Pulsar timer for a radio astronomy observatory. What the instrument essentially does is coherent averaging on pulses coming from neutron stars (pulsars)to build up a pulse profile. Averaging, right now, will take place over a maximum of 5 minutes, although this will probably be much less in the future. > > I need to be able to set a user defined sampling frequency to this resolution, and not have at move at all. If it does, it means that the pulse will being to drift across the averaged profile, and move around with jitter. How typical -- astronomers with astonishingly-stringent specifications that they don't understand... -aArticle: 37033
Austin Lesea wrote: > > Rick, > > All fair and reasonable comments. > > The Virtex II has agressive forward pricing as a new product, and you would need > to contact your appropriate sales channel. The prices you quote, are of course, > today's list prices. I would say that some very large accounts are looking at > the 2V40 and 2V80, where they would normally be interested in the Spartan IIE > parts, and they have no problem with the pricing. I got this pricing from my distributors. I am not a large customer so we don't get promises of big discounts. Even if I were larger, I seriously doubt that the part I would need due to pin count considerations will be dropping from $146 to $50 or less. > Your comments on IOs are equally valid as to the numeric count, but if a Virtex > II will support a ~380 Mb/s DDR IO, and a Spartan IIE supports a ~160 Mb/s DDR > IO, Virtex II wins from a bits per second per package point of view. If you go > to 700 Mb/s using LVDS, you only get 350 Mb/s per pin, still pretty respectable. This does not help for many designs. If a new design can run a arbitrarily high clock rate, then this would be ok. But many, if not most, designs have set constraints on clock speeds and IO rates. I can't change the number of IOs or the clock speed of a PCI interface for example. > Additionally, Spartan IIE has fewer power and ground pins than Virtex E, so the > SSO table is less agressive, so unless you just need lots of LEDs and switches > (which a lot of Spartan applications do require), you can't really run the IOs > as agressively. So the ~160 Mb/s per pin of Spartan IIE is not sustained across > as many IOs (exceeds SSO guideline). > > So what to choose? I would suggest that you look at more than just the pin > counts, and look into the speeds, strengths, SSO's, and so on. Maybe Spartan > IIE is the best for you. Does the Spartan IIE get around the heavy startup currents? Otherwise I might as well stick to the Spartan II since they are a bit cheaper. > As for 2 amperes at -40C, this is the legacy of the orginal Virtex design, and > we have only had the opportunity to address it in Virtex II, as Virtex E and > Spartan II and Spartan IIE are all derivatives of the original Virtex design. > > Again, this specification as well, is under revision as we characterize Spartan > IIE, and Spartan IIE. I understand the reason for the Spartan IIs having the same problems as the Virtex. But I remember this detailed characterization being announced back at the beginning of the year if I am not mistaken. It will be necessary to see the results before I can design in two or three Spartan II or IIE chips. > I would also like to say that the Virtex family and it derivatives is the best > selling FPGA 'dynasty' in the history of FPGAs. It is hard to argue with that > kind of sucess, so I will only suggest that using the 2V40 is an option, and one > that should be considered. You have a very different view of FPGAs from your customers. I don't care about the success of a "dynasty". I only care about the utility of a specific FPGA for my application. As to the 2V40, that part has only 88 IOs regardless of package and would only be usable in one possible use on my boards. That particular set of slots is currently being filled by a $10 Lucent (opps! Agere) chip while the 2V40 is $29. I am trying to replace these chips with a single less expensive solution. The XC2V parts just aren't cost effective enough. -- 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: 37034
Austin Lesea <austin.lesea@xilinx.com> wrote in message news:<3C0517E1.D2BA1B8C@xilinx.com>... > > In the data sheet there is a 'Supply Current Requirements During Power On' > section for all Xilinx FPGAs. > > http://www.support.xilinx.com/partinfo/ds001_3.pdf > According to the data sheet, this heavy current demand occurs during voltage rampup. Switching regulators put out more current at low voltage, so if 500mA current peak occurs at, say, 0.8V and the regulator's input is 5V then the 5V power supply would see something like 500*0.8/5 mA. About 100 mA with a 80% efficient switcher. As long as you're characterizing startup current, it would be useful to know at what voltage the heaviest current draw occurs. For example, some of my applications use USB, so I have limits on what I can draw from the 5V supply if the device is bus-powered. I thought Virtex was a lot more expensive than Spartan. What price point do you expect for the 2V80 in 2Q 2002? BTW, do you have a link to Virtex power requirements?Article: 37035
Mark <mrgs1000@yahoo.com> wrote: > Oh, and make sure you use LOCs for every instantiation of the macro, > otherwise your PAR time will go up, not down. Hi, I still confuse at this point. If I create a *hard* macro, shouldn't it contain all the placemanet and routing information need by par. Then why should I use LOC inside the FPGA editors again? Also, is there a way to do it in a high level (in VHDL level or enen UCF) but not donwto to the FPGA editor? The reasons for this are: 1. I don't always have access to the consol with *both* good display and fast CPU. I usually write the VHDL codes on my laptop and submit them to a SunE4500 machine though text mode. 2. Some one say (and what I always beleave is) that I can do every thing in VHDL as the schematic method can. Isn't that true in this case? (don't start a war on this, I just want to get my work done) 3. To ensure my instructions of LOCs in VHDL is correctly passed to par, I have checked the PCF (physical constrain file) generated by map tools. One interesting thing is that I can only find the LOCs from top level (i.e. indicating where the submodules should be placed) but not the LOCs inside the sum modules telling the locations of the internal components. If this is the normal case, how can the par tool know the information about the internal components? 4. My sub moduls are not quite simple. It use up to a 6x4 CLB block and use up all resource in that (including the TBUFs). Also, I am at the dead line of my project and it's looks impossible for me to get the schematic work within a day (I will finally do it after the dead line if this is the only way, but my report will have only estimated performance...so sad) Thanks for those all help me and spent time to read my news. Thanks again! ---- BrittleArticle: 37036
--------------8BA419420E4C016985287943 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Rick, See inbetween the lines, below. Austin rickman wrote: > Austin Lesea wrote: > > > > Rick, > > > > All fair and reasonable comments. > > > > The Virtex II has agressive forward pricing as a new product, and you would need > > to contact your appropriate sales channel. The prices you quote, are of course, > > today's list prices. I would say that some very large accounts are looking at > > the 2V40 and 2V80, where they would normally be interested in the Spartan IIE > > parts, and they have no problem with the pricing. > > I got this pricing from my distributors. I am not a large customer so we > don't get promises of big discounts. Even if I were larger, I seriously > doubt that the part I would need due to pin count considerations will be > dropping from $146 to $50 or less. OK. I hear you there. This is something of a disconnect from what I was told. If we price 2V40's like that, I can see why you don't like them. I will go find out why they are listed at this level. > > Your comments on IOs are equally valid as to the numeric count, but if a Virtex > > II will support a ~380 Mb/s DDR IO, and a Spartan IIE supports a ~160 Mb/s DDR > > IO, Virtex II wins from a bits per second per package point of view. If you go > > to 700 Mb/s using LVDS, you only get 350 Mb/s per pin, still pretty respectable. > > This does not help for many designs. If a new design can run a > arbitrarily high clock rate, then this would be ok. But many, if not > most, designs have set constraints on clock speeds and IO rates. I can't > change the number of IOs or the clock speed of a PCI interface for > example. > True, for a given problem, there may be no ability to do an optimal systems solution. > > Additionally, Spartan IIE has fewer power and ground pins than Virtex E, so the > > SSO table is less agressive, so unless you just need lots of LEDs and switches > > (which a lot of Spartan applications do require), you can't really run the IOs > > as agressively. So the ~160 Mb/s per pin of Spartan IIE is not sustained across > > as many IOs (exceeds SSO guideline). > > > > So what to choose? I would suggest that you look at more than just the pin > > counts, and look into the speeds, strengths, SSO's, and so on. Maybe Spartan > > IIE is the best for you. > > Does the Spartan IIE get around the heavy startup currents? Otherwise I > might as well stick to the Spartan II since they are a bit cheaper. > The Spartan IIE parts are smaller, so the currents are smaller. But I think that Spartan II is going to have lower values for the power on. > > > As for 2 amperes at -40C, this is the legacy of the orginal Virtex design, and > > we have only had the opportunity to address it in Virtex II, as Virtex E and > > Spartan II and Spartan IIE are all derivatives of the original Virtex design. > > > > Again, this specification as well, is under revision as we characterize Spartan > > IIE, and Spartan IIE. > > I understand the reason for the Spartan IIs having the same problems as > the Virtex. But I remember this detailed characterization being > announced back at the beginning of the year if I am not mistaken. It > will be necessary to see the results before I can design in two or three > Spartan II or IIE chips. > Well. The Spartan II new datasheet numbers are done. The revisions are in the mill. The Spartan IIE was just announced, so the intitial datasheets will be more conservatively stated until we have sufficient silicon to go back and look at it again. > > I would also like to say that the Virtex family and it derivatives is the best > > selling FPGA 'dynasty' in the history of FPGAs. It is hard to argue with that > > kind of sucess, so I will only suggest that using the 2V40 is an option, and one > > that should be considered. > > You have a very different view of FPGAs from your customers. I don't > care about the success of a "dynasty". I only care about the utility of > a specific FPGA for my application. As to the 2V40, that part has only > 88 IOs regardless of package and would only be usable in one possible > use on my boards. That particular set of slots is currently being filled > by a $10 Lucent (opps! Agere) chip while the 2V40 is $29. I am trying to > replace these chips with a single less expensive solution. The XC2V > parts just aren't cost effective enough. > Sure I do (have a different view). I work for Xilinx, you work for your clients. You are my customer. I am trying to help you solve your problems as effectively as possible. If, in that process, I am astonished at the success of a product that solved not only your problems, but everyone else's, I want to see what we did right, and do it more, and what we did wrong, and do it less. And, if you do not care that Virtex was successful, then I am a bit surprised! When I did jobs for my clients, it was important to choose suppliers that had superior quality, reliability, stability, and support. My clients sure as hell wouldn't let me design in parts that came from "fpga's R Us*." *Used as an example only. Purely a fictional company. Any possible resemblance to any FPGA supplier, living or dead is purely coincidental, and not the intent of the author. > > -- > > 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 --------------8BA419420E4C016985287943 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> Rick, <p>See inbetween the lines, below. <p>Austin <p>rickman wrote: <blockquote TYPE=CITE>Austin Lesea wrote: <br>> <br>> Rick, <br>> <br>> All fair and reasonable comments. <br>> <br>> The Virtex II has agressive forward pricing as a new product, and you would need <br>> to contact your appropriate sales channel. The prices you quote, are of course, <br>> today's list prices. I would say that some very large accounts are looking at <br>> the 2V40 and 2V80, where they would normally be interested in the Spartan IIE <br>> parts, and they have no problem with the pricing. <p>I got this pricing from my distributors. I am not a large customer so we <br>don't get promises of big discounts. Even if I were larger, I seriously <br>doubt that the part I would need due to pin count considerations will be <br>dropping from $146 to $50 or less.</blockquote> OK. I hear you there. This is something of a disconnect from what I was told. If we price 2V40's like that, I can see why you don't like them. I will go find out why they are listed at this level. <blockquote TYPE=CITE>> Your comments on IOs are equally valid as to the numeric count, but if a Virtex <br>> II will support a ~380 Mb/s DDR IO, and a Spartan IIE supports a ~160 Mb/s DDR <br>> IO, Virtex II wins from a bits per second per package point of view. If you go <br>> to 700 Mb/s using LVDS, you only get 350 Mb/s per pin, still pretty respectable. <p>This does not help for many designs. If a new design can run a <br>arbitrarily high clock rate, then this would be ok. But many, if not <br>most, designs have set constraints on clock speeds and IO rates. I can't <br>change the number of IOs or the clock speed of a PCI interface for <br>example. <br> </blockquote> True, for a given problem, there may be no ability to do an optimal systems solution. <blockquote TYPE=CITE>> Additionally, Spartan IIE has fewer power and ground pins than Virtex E, so the <br>> SSO table is less agressive, so unless you just need lots of LEDs and switches <br>> (which a lot of Spartan applications do require), you can't really run the IOs <br>> as agressively. So the ~160 Mb/s per pin of Spartan IIE is not sustained across <br>> as many IOs (exceeds SSO guideline). <br>> <br>> So what to choose? I would suggest that you look at more than just the pin <br>> counts, and look into the speeds, strengths, SSO's, and so on. Maybe Spartan <br>> IIE is the best for you. <p>Does the Spartan IIE get around the heavy startup currents? Otherwise I <br>might as well stick to the Spartan II since they are a bit cheaper. <br> </blockquote> The Spartan IIE parts are smaller, so the currents are smaller. But I think that Spartan II is going to have lower values for the power on. <blockquote TYPE=CITE> <br>> As for 2 amperes at -40C, this is the legacy of the orginal Virtex design, and <br>> we have only had the opportunity to address it in Virtex II, as Virtex E and <br>> Spartan II and Spartan IIE are all derivatives of the original Virtex design. <br>> <br>> Again, this specification as well, is under revision as we characterize Spartan <br>> IIE, and Spartan IIE. <p>I understand the reason for the Spartan IIs having the same problems as <br>the Virtex. But I remember this detailed characterization being <br>announced back at the beginning of the year if I am not mistaken. It <br>will be necessary to see the results before I can design in two or three <br>Spartan II or IIE chips. <br> </blockquote> Well. The Spartan II new datasheet numbers are done. The revisions are in the mill. The Spartan IIE was just announced, so the intitial datasheets will be more conservatively stated until we have sufficient silicon to go back and look at it again. <blockquote TYPE=CITE>> I would also like to say that the Virtex family and it derivatives is the best <br>> selling FPGA 'dynasty' in the history of FPGAs. It is hard to argue with that <br>> kind of sucess, so I will only suggest that using the 2V40 is an option, and one <br>> that should be considered. <p>You have a very different view of FPGAs from your customers. I don't <br>care about the success of a "dynasty". I only care about the utility of <br>a specific FPGA for my application. As to the 2V40, that part has only <br>88 IOs regardless of package and would only be usable in one possible <br>use on my boards. That particular set of slots is currently being filled <br>by a $10 Lucent (opps! Agere) chip while the 2V40 is $29. I am trying to <br>replace these chips with a single less expensive solution. The XC2V <br>parts just aren't cost effective enough. <br> </blockquote> Sure I do (have a different view). I work for Xilinx, you work for your clients. You are <b>my </b>customer. I am trying to help <b>you</b> solve your problems as effectively as possible. If, in that process, I am astonished at the success of a product that solved not only your problems, but everyone else's, I want to see what we did right, and do it more, and what we did wrong, and do it less. <p>And, if you do not care that Virtex was successful, then I am a bit surprised! <p>When I did jobs for my clients, it was important to choose suppliers that had superior quality, reliability, stability, and support. <p>My clients sure as hell wouldn't let me design in parts that came from "fpga's R Us*." <p>*Used as an example only. Purely a fictional company. Any possible resemblance to any FPGA supplier, living or dead is purely coincidental, and not the intent of the author. <blockquote TYPE=CITE> <br>-- <p>Rick "rickman" Collins <p>rick.collins@XYarius.com <br>Ignore the reply address. To email me use the above address with the XY <br>removed. <p>Arius - A Signal Processing Solutions Company <br>Specializing in DSP and FPGA design URL <a href="http://www.arius.com">http://www.arius.com</a> <br>4 King Ave 301-682-7772 Voice <br>Frederick, MD 21701-3110 301-682-7666 FAX</blockquote> </html> --------------8BA419420E4C016985287943--Article: 37037
Brad, http://www.support.xilinx.com/partinfo/ds003-3.pdf for virtex. The power on current is all required at ~ twice the Vt of the core transistors. Somewhere from 0.8 to 1.0 Vdc. A switcher running from 5 V (like the Elantec parts: >95% efficient) would supply a lot of current at that moment, being power limited, rather than current limited. Good point. For pricing on any parts, I can not speak, as I do not know. Our sales partners have their set pricing, based on all of the objectives .... so on and so forth. I know what our suggested pricing is, but that is not going to help you at all. The fact is that the Virtex II and Virtex E is less expensive to make than Virtex, for the same number of LUTs due to the shrink in technology (.22u to .18u to 0.15u). The same is true for Spartan II to Spartan IIE. Moving to 300 mm wafers also increases the yield, so parts on the new 300 mm wafers cost us less to make as well. All of this gets passed along to the customer, through the pricing models. Austin Brad Eckert wrote: > Austin Lesea <austin.lesea@xilinx.com> wrote in message news:<3C0517E1.D2BA1B8C@xilinx.com>... > > > > In the data sheet there is a 'Supply Current Requirements During Power On' > > section for all Xilinx FPGAs. > > > > http://www.support.xilinx.com/partinfo/ds001_3.pdf > > > According to the data sheet, this heavy current demand occurs during > voltage rampup. Switching regulators put out more current at low > voltage, so if 500mA current peak occurs at, say, 0.8V and the > regulator's input is 5V then the 5V power supply would see something > like 500*0.8/5 mA. About 100 mA with a 80% efficient switcher. > > As long as you're characterizing startup current, it would be useful > to know at what voltage the heaviest current draw occurs. For example, > some of my applications use USB, so I have limits on what I can draw > from the 5V supply if the device is bus-powered. > > I thought Virtex was a lot more expensive than Spartan. What price > point do you expect for the 2V80 in 2Q 2002? > > BTW, do you have a link to Virtex power requirements?Article: 37038
Hi, Would like to list some Eda tools' names and links used on linux?Article: 37039
On Wed, 28 Nov 2001 08:07:16 -0800, Austin Lesea <austin.lesea@xilinx.com> wrote: Hi Austin, [snip off topic stuff] > >The maximum current into, or out of a pin on a static basis is stated int >he absolute maximum DC ratings of the data sheet as 10 mA (notes 4 and 5) >for voltages forced above or below ground. The AC current is listed as >less than 100 mA. I understand these limits are latchup related. The I/O voltage will always be between the supply rails, so I don't think these apply. >If you are pulling up a load, as you describe, I expect the current to be >at least 24 mA, and perhaps as much as 60 mA, with no ill effects, forever >as long as you are within the Vol, Voh limits as well (ie not dissipating >a lot of power in the pmos pullup device, as it has a small voltage drop). Are you saying that metal migration doesn't happen in Spartan2? The 4000E devices had a limit of 20mA, based on metal migration. The output voltage is clamped well below Voh (actually about 900mV to 1V above ground), so I'll be dissipating a lot of power in the output. How do I find out the actual device limits for this case? I expect that there will be a few limits: 1. A maximum steady state current, based on metal migration 2. A maximum power dissipation in the output transistor(s), based on localised heating on the die. 3. A maximum current, with the voltage outside the supply rails, based on latchup. The data sheet has values for (1) but not the others. To know whether the particular design I'm interested in will work reliably, I require the other parameters. I realise that the output driver wasn't meant to be (ab)used in this way, but a redesign isn't possible. Thanks, Allan. >Austin > >Allan Herriman wrote: > >> Hi, >> >> I'm looking for the maximum current I can draw from a Spartan2 output >> (LVTTL mode) without impairing reliability. I'm only interested in >> sourcing current (i.e. from the P channel strong pullup). >> >> I found Xilinx Answer 4453: >> http://support.xilinx.com/xlnx/xil_ans_display.jsp?getPagePath=4453 >> that says that the figure is 20mA for 4000E/XL devices, based on metal >> migration. >> >> I couldn't find any figures for Spartan2 though. >> >> My next question: how does this scale with the selected I/O standard? >> E.g. if an LVTTL24 output has an absolute maximum current of 'X' mA, >> will an LVTTL12 output have an absolute maximum current of 'X' mA, or >> 'X'/2 mA? >> I guess it depends on which bits of metalization are the 'critial >> path'. >> >> Thanks, >> Allan. >Article: 37040
Allan Herriman wrote: > <snip> > The output voltage is clamped well below Voh (actually about 900mV to > 1V above ground), so I'll be dissipating a lot of power in the output. > How do I find out the actual device limits for this case? > > I expect that there will be a few limits: > 1. A maximum steady state current, based on metal migration > 2. A maximum power dissipation in the output transistor(s), based on > localised heating on the die. > 3. A maximum current, with the voltage outside the supply rails, > based on latchup. > > The data sheet has values for (1) but not the others. To know whether > the particular design I'm interested in will work reliably, I require > the other parameters. > > I realise that the output driver wasn't meant to be (ab)used in this > way, but a redesign isn't possible. Where I saw this tried on a uC, it failed in practice. You will need to characterise this yourself, as the IC suppliers do not do these tests. At significant current levels, the drop across the FET should be < 1V, and typ 0.5V. This tends to self-adjust, as a large PFET area can dissipate more, but has a lower on resistance. Above this, (continuous) and you start cooking the silicon / metalise. You could get an indication of the Temp rise, by ploting the drive current, which will decrease as the local heating occurs It will also vary batch to batch. Can you pick LVDS drive, which limits to 8mA, for this pin(s) ? What's clamping the pin, and why is a redesign not possible ? -jgArticle: 37041
Hi Thomas,
"Thomas Stanka" <thomas.stanka@de.bosch.com> wrote in message
news:Xns91675D2429562Stankasatcom@127.0.0.1...
> Xpost F'up2caf set.
>
> "Srinivasan Venkataramanan" <srinivasan@siliconsystems.co.in> wrote:
> > Pentium 4
> > OS: Windows XP (and Linux - will RH 7.1 do?)
>
> RH 7.1 should do for most tools that support Linux (great exception
is
> Synopsys tools in GUI-mode which need an older version of RH. AFAIK
> Pentium4 needs RH 7)
>
> > RAM: 256 MB
>
> Not enough for EDA. Take 511 MB to 1 GB. I think memory is the wrong
place
> to save money in EDA. BTW which type of RAM ?
>
> > Many other stuff are moderately high-end and I would like to know
if
> > any thing else (than listed above) will impact the PC for EDA
Usage.
> > The EDA Usage will be mostly based on FREE tools
>
> While doing simulation with Modelsim I learned that the graphiccard
has to
> be good (not excellent). No onboard 8MB graphiccard or something
like that,
> but of course you don't need the latest card with 128MB or more.
>
Thanks for the information.
> > Sorry for this slightly off-technical post.
>
> I don't think you miss the topic. But please learn to qoute and set
a
> Followup2 while Xposting.
>
Ok, I have now set "Show All Headers" and see what you mean. I
remember (vaguely) reading somewhere that a post being posted to
multiple NGs is a actually a SINGLE copy and all the NGs "refer" to
it - may be I had mistaken. Anyway will be careful from now on -
Thanks for the hint.
Bye,
Srinivasan
> bye Thomas
>
> --
> Thomas Stanka BC/EMD4
> Space Communications Systems
> Tesat Spacecom GmbH & Co KG
> thomas.stanka@de.bosch.com
--
Srinivasan Venkataramanan
ASIC Design Engineer
Software & Silicon Systems India Pvt. Ltd. (An Intel company)
Bangalore, India, Visit: http://www.simputer.org)
"I don't Speak for Intel"
Article: 37042If the SMPS was connected to the load only after its output caps had charged, then the current spike should be very short, and no load would happen on the regulator. Austin Lesea wrote: > > Brad, > > http://www.support.xilinx.com/partinfo/ds003-3.pdf > > for virtex. > > The power on current is all required at ~ twice the Vt of the core transistors. Somewhere from > 0.8 to 1.0 Vdc. > > A switcher running from 5 V (like the Elantec parts: >95% efficient) would supply a lot of current > at that moment, being power limited, rather than current limited. Good point. > > For pricing on any parts, I can not speak, as I do not know. Our sales partners have their set > pricing, based on all of the objectives .... so on and so forth. > > I know what our suggested pricing is, but that is not going to help you at all. > > The fact is that the Virtex II and Virtex E is less expensive to make than Virtex, for the same > number of LUTs due to the shrink in technology (.22u to .18u to 0.15u). The same is true for > Spartan II to Spartan IIE. > > Moving to 300 mm wafers also increases the yield, so parts on the new 300 mm wafers cost us less > to make as well. > > All of this gets passed along to the customer, through the pricing models. > > Austin > > Brad Eckert wrote: > > > Austin Lesea <austin.lesea@xilinx.com> wrote in message news:<3C0517E1.D2BA1B8C@xilinx.com>... > > > > > > In the data sheet there is a 'Supply Current Requirements During Power On' > > > section for all Xilinx FPGAs. > > > > > > http://www.support.xilinx.com/partinfo/ds001_3.pdf > > > > > According to the data sheet, this heavy current demand occurs during > > voltage rampup. Switching regulators put out more current at low > > voltage, so if 500mA current peak occurs at, say, 0.8V and the > > regulator's input is 5V then the 5V power supply would see something > > like 500*0.8/5 mA. About 100 mA with a 80% efficient switcher. > > > > As long as you're characterizing startup current, it would be useful > > to know at what voltage the heaviest current draw occurs. For example, > > some of my applications use USB, so I have limits on what I can draw > > from the 5V supply if the device is bus-powered. > > > > I thought Virtex was a lot more expensive than Spartan. What price > > point do you expect for the 2V80 in 2Q 2002? > > > > BTW, do you have a link to Virtex power requirements?Article: 37043
On Thu, 29 Nov 2001 17:02:31 +1300, Jim Granville <jim.granville@designtools.co.nz> wrote: >Allan Herriman wrote: >> ><snip> >> The output voltage is clamped well below Voh (actually about 900mV to >> 1V above ground), so I'll be dissipating a lot of power in the output. >> How do I find out the actual device limits for this case? >> >> I expect that there will be a few limits: >> 1. A maximum steady state current, based on metal migration >> 2. A maximum power dissipation in the output transistor(s), based on >> localised heating on the die. >> 3. A maximum current, with the voltage outside the supply rails, >> based on latchup. >> >> The data sheet has values for (1) but not the others. To know whether >> the particular design I'm interested in will work reliably, I require >> the other parameters. >> >> I realise that the output driver wasn't meant to be (ab)used in this >> way, but a redesign isn't possible. > > Where I saw this tried on a uC, it failed in practice. > >You will need to characterise this yourself, as the IC suppliers >do not do these tests. > At significant current levels, the drop across the FET should be < 1V, >and typ 0.5V. > This tends to self-adjust, as a large PFET area can dissipate more, but >has a lower on resistance. > > Above this, (continuous) and you start cooking the silicon / metalise. > > You could get an indication of the Temp rise, by ploting the drive >current, >which will decrease as the local heating occurs > It will also vary batch to batch. > > Can you pick LVDS drive, which limits to 8mA, for this pin(s) ? No LVDS on Spartan2. > What's clamping the pin, and why is a redesign not possible ? It's connected to the base of an NPN BJT. The emitter is connected to ground. There's no resistor. It's not my design. I'd like to find out how reliable it's going to be. If it turns out that these things will fail after a month, then I guess a redesign *is* possible :) 2nd best option would replace the BJT with a pin compatible N-ch MOSFET. A component change isn't as bad as a board change. Regards, Allan.Article: 37044
Hi Austin. I do'nt understand. What is "jitter filer" ? What is the "tap rate" ? I understand that tap step is ~50 ps. Do you mean that the minimum time it takes to reach to the maximum period jitter is 256 cycles ??? Bye, Nurit In article <3C050C22.4C93DBEF@xilinx.com>, Austin Lesea says... > >answered separately, > >jitter filer * 256 = update of the tap rate. > >Austin > >Nurit.Eliram@mailandnews.com wrote: > >> Hi Austin. >> ThankX for the answer. >> Since the DLL period jitter is ~150 ps, >> and the DLL cycle-to-cycle jitter is ~50 ps, >> >> I have the following question : >> >> Is the worst case is that for 3 consequtive clock cycles the >> jitter will rise to it's max value of ~150 ps, >> Or the worst case is that it will rise slower (i.e 100 clock cycles) ? >> >> Do I have a measure of time what is the minimum numver of clock >> cycles for the period jitter to happen ??? >> >> Thanks >> Nurit. >> >> In article <3BF94DBD.863C2064@xilinx.com>, Austin Lesea says... >> > >> >Nurit, >> > >> >From any cycle, to the next cycle, the period out of the Virtex II DCM >> >(using the DLL feature) can not change by more than a tap value, plus >> >whatever input jitter may also be present. >> > >> >For Virtex II that is ~ 55ps. >> > >> >The period jitter is measured by accumulating a histogram of > 200,000 >> >periods, and fitting a gaussian curve (left and right tail fitting) to get >> >the peak to peak value. >> > >> >Spectral analysis of the histogram shows that the jitter is random, and has >> >no deterministic component. >> > >> >Thus the input jitter going into the DLL may be added to the internal jitter >> >quadratically to get the output jitter. >> > >> >Clock forwarded interfaces have larger margin as a result, as the cycle to >> >cycle jitter is important as to the sampling of input data by the IOB's. >> >Worst case, the input data sampling instant error is not the peak to peak >> >value, but the cycle to cycle value. >> > >> >This behavior is completely different than than of a PLL, where the PLL >> >usually provides some filtering of high frequency jitter components, and >> >where there is no fixed relationship from an input clock to an output clock >> >as there is in the DLL (PLL cycle to cycle jitter is bounded only by the >> >peak to peak jitter, whereas the DLL cycle to cycle jitter is bounded the >> >delay line tap change). >> > >> >Austin >> > >> >nurit eliram wrote: >> > >> >> Hi. >> >> I have seen that the period jitter of DLL of virtex-II device is 150 ps. >> >> >> >> Can I have any figures about it's cycle-to-cycle jitter ? >> >> >> >> ThanKX >> > >Article: 37045
According to Spartan-IIE datasheet, both 200 parts have the same amount of block ram (56k). Damir "Jan Gray" <jsgray@acm.org> wrote in message news:9u3knp$53a$1@slb4.atl.mindspring.net... > "Rick Filipkiewicz" <rick@algor.co.uk> wrote in message > news:3C0535D4.868C1E65@algor.co.uk... > > o Do they relate to VirtexE's in the same way as SpartanII did to the > > Virtex ? Esp wrt timing. > > http://fpgacpu.org/#011120: > > "You might think that > > as Virtex-E is to Virtex, so is Spartan-IIE to Spartan-II > > But you would be wrong. According to data sheets, whereas an XCV200 has 14 > BRAMs (56 Kb) and the XCV200E has 28 BRAMs (112 Kb), in the Spartan-II/E > family, both the XC2S200 and (alas) the XC2S200E have the same 14 BRAMs (56 > Kb). > ... > But let us count our blessings. The new Spartan-IIE family is lower-voltage, > faster (470 ps TILO (2SxxxE-6) vs. 700 ps TILO (2Sxxx-5)), offers a larger > part (the 32x48 CLB = 6144 logic cell XC2S300E), supports tons of different > I/O signalling standards, and (thank you Xilinx) comes in TQ144 and PQ208 > QFP packages. " > > Jan Gray > Gray Research LLC > > >Article: 37046
>The beautiful thing about the hydrogen maser, is that it is 1E-14, but at >frequency all its own (in other words, not related by physics to a standard, >like a cesium standard). ?? What does the frequency depend upon? Hasn't somebody measured the magic number even if we don't know how to do the caclulations? -- These are my opinions, not necessarily my employer's. I hate spam.Article: 37047
> I'll tell you exactly what I need it for. I have designed an FPGA based > Pulsar timer for a radio astronomy observatory. What the instrument > essentially does is coherent averaging on pulses coming from neutron > stars (pulsars)to build up a pulse profile. Averaging, right now, will > take place over a maximum of 5 minutes, although this will probably be > much less in the future. What does "coherent averaging" mean? What's a "pulse profile"? > I need to be able to set a user defined sampling frequency to this > resolution, and not have at move at all. If it does, it means that > the pulse will being to drift across the averaged profile, and move > around with jitter. I'm missing the big picture. If you had the magic clock that you want, what would you do with it? Are you looking at the shape of an analog pulse? Or just the timing of a digital pulse? -- These are my opinions, not necessarily my employer's. I hate spam.Article: 37048
Hi all,
In my current project I have to implement scrambling and CRCs over a
128-bit data bus at a clock rate of 100 MHz. My combinatorial areas
are huge and I am having problems meeting the speed requirements.
Could someone give me an hint how to overcome this problem ?
Any hints will be appreciated.
Thank you for your time.
Best regards,
Ovidiu Lupas.
Article: 37049H.L <alphaboran@yahoo.com> wrote: > Hi all, > i have problems when i try to install xilinx foundation 3.1 on a p4 system. > i heard that the program is not compatible with this processor, is that > true? if yes, what do i need to download to make the program run properly? > Take care > Harris The Java runtime comes with 3.1i is not for P4 system. The solution is to copy all the data from CDs to HDD and then replace the java with the newly downloaded one. Finally install the software from HDD. ---- Brittle
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