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
oen_no_spam@yahoo.com.br (Luiz Carlos) wrote in message news:<3fd8f66b.0410070241.539ec1d5@posting.google.com>... > I was just thinking about: > > 1M/250k = 4 customers, ok? > > Why Xilinx, Altera, etc, give us prices for 250k pcs??? > > DSPs vendors had the same behavior some years ago, but now they use a > much more usefull range: price/10k pcs, sometimes price/1k pcs! > > Does someone else agree? Yes. And whats more, it would be better if they only advertised products that were actually available. The time taken to fab a structured-ASIC seems to be less than the lead time for some Xilinx parts ;) Cheers, JonBArticle: 74301
Luiz, Like Sylvain says, you should get your quote for smaller amounts from your distie. Often, they'll cut you a deal if you're using a lot of other parts from them. This means that each customer can negotiate a price depending on their individual situation. I guess Xilinx only supply direct to their biggest customers which is why they only quote the 250k price. HTH, All the best, Syms. "Luiz Carlos" <oen_no_spam@yahoo.com.br> wrote in message news:3fd8f66b.0410070241.539ec1d5@posting.google.com... > I was just thinking about: > > 1M/250k = 4 customers, ok? > > Why Xilinx, Altera, etc, give us prices for 250k pcs??? > > DSPs vendors had the same behavior some years ago, but now they use a > much more usefull range: price/10k pcs, sometimes price/1k pcs! > > Does someone else agree? > > Luiz Carlos.Article: 74302
Austin Lesea <austin@xilinx.com> writes: > Just remember that the PPC, MGT, DCM, EMAC, DSP48, etc. are all 'hard > cores' and do not 'suffer' from the same 10:1 disadvantages in speed > and power as plain old interconnect and logic. Only if you use them. Otherwise, they contribute even more to the area disadvantage of FPGAs over ASICs. *Usually*, there will always be some of hard blocks in a FPGA that you will not use for your application (the FPGA device having been chosen for cost, fitting your design, etc reasons). > Not mentioned here is that ASICs suffer a 10:1 disadvantage in single > event upsets. Every single upset in an ASIC is a functional failure > (plus they are a lot more sensitive being the smallest structure > possible). Only 1:10 SEUs in a FPGA cause a functional failure. The > two factors cancel out. This is firstly not germane to the discussion of FPGA area vs ASIC area, but more importantly an unsubstantiated claim. The only devices that have been recalled from the market due to SEU errors are Xilinx FPGAs. Besides as was the case with Xilinx, this is a problem that packaging can fix to some extent (at a cost of course). Since we are discussing all the other issues of ASIC vs FPGAs, we should also pay attention to the severe power/energy consumption disadvantage of FPGAs. Since 65% of the power dissipated by a FPGA is by its interconnect, this is an inherent problem with FPGAs (there are several papers that have studied the power breakdown of FPGAs). Soon, we will need heat sinks and other passive and active cooling for FPGAs as the number of gates and the speed at which they operate is increased. I have already heard from some folks that they are on the border of using cooling for the larger, faster FPGAs. The inherent disadvantage of FPGAs over ASIC implementations lies in the interconnect and configuration memory. Interconnect comprises about 60% of a FPGA fabric, configuration memory is about 30%, and only about 10% is the actual LUTs. This assumes no hard macros, just a pure sea of LUTs. Again these figures are well-known and published by multiple sources (search for Andre DeHon's thesis and papers for one). Even out of the 10% LUTs, the utilization of each LUT is low. This means, that even though every single LUT in a FPGA may be used, not each LUT is used to 100% capacity. For example, a LUT could be used to implement something as simple as an AND gate (highly likely, but possible) or much more complex 4-input functions (if its a 4-LUT). So, if you take what the percentage of each LUT is utilized into account, overall logic/LUT utilization is reasonably low (again something that I have seen figures around 30-50% before - probably from Jonathan Rose's work). Like I said before, these area, performance power, cost disadvantages of FPGAs all have to be measured against NRE cost, die cost, back-end tool costs, and volume of ASICs to determine whether you want to do a FPGA or an ASIC or a structured ASIC. Clearly, FPGAs come out on top a lot of times (and thus the large market for them). SumitArticle: 74303
> From: ian.dedic@fme.fujitsu.com (Ian Dedic) > Organization: http://groups.google.com > Newsgroups: comp.arch.fpga > Date: 6 Oct 2004 04:11:15 -0700 > Subject: Re: FPGA vs ASIC area -- the crucial issue is power consumption > Exactly what I was saying as a counterpoint to the Xilinx "FPGAs will > take over the world" point of view! In the functions-per-mW game ASICs > will always win. > > Ian Xilinx never said anything of this kind. We are not megalomaniacs. But we want to nibble away at the fringes of the ASIC market. If we can take those 10% that can benefit from the known FPGA advantages and do not care so much about some of the known ASIC advantages, then we double our sales, which keep us happy for a year or two. :-) ASICs really do us a favor when they create a world-wide appetite for complex electronic solutions, and tickle the system designers' imagination. Then, when some of them are disappointed that they cannot afford the ASIC for reasons of NRE, time or flexibility, we come in and explain our capabilties. We may be not as fast, not as big, not as low power, not as cheap in high volume, but instead we are more flexible, changeable, dynamically reconfigurable, without any NRE, faster to market, and easier (and more fun) to design with, since FPGAs allow unlimited design variations, modifications and, heaven forbid, even error fixes. We can live with ASICs, they are our big neighbor. Peter AlfkeArticle: 74304
Symon <symon_brewer@hotmail.com> wrote: : Luiz, : Like Sylvain says, you should get your quote for smaller amounts from your : distie. Often, they'll cut you a deal if you're using a lot of other parts : from them. This means that each customer can negotiate a price depending on : their individual situation. I guess Xilinx only supply direct to their : biggest customers which is why they only quote the 250k price. : HTH, All the best, Syms. For smal quantities , go to www.nuhorizons.com -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 74305
ALuPin@web.de (ALuPin) wrote > I have several signals in my design which are outputs that is > they are connected to output pin symbols in my schematic > top level file. > > BUT these several output signals are NOT assigned to PINS. > > Does the compiler (QuartusII) remove these "unused" signals or are they > preserved? If you look in the pin-out file (under Compilation Report / Fitter) I think you will find Quartus has allocated them to pins for you.Article: 74306
> I was just thinking about: Hi, I was just reading your post and told myself, so ok, let me say something... Of course you know that out of 1M or 4 x 250K, there would be thousands used by individuals, that already adopted S3 in everyday lifes gadgets, things like portable oscilloscopes or virtual head sets. These were once made up with asics but no more i beleive. And or course if they were to sell it in 1K chunks, then It wouldnt be profitable for them. There is a whole theory about economics here, and maybe for them, its better to be in the higher stratospheric levels that really down on earth. For sure if I were president of X, i would promote my products into the lower cast of society, or even give them away as samples (the ES series). And of course the minqty/order would be lower. That's the ideal world, but its been a while now that I stopped believing in utopia.... > 1M/250k = 4 customers, ok? > > Why Xilinx, Altera, etc, give us prices for 250k pcs??? > > DSPs vendors had the same behavior some years ago, but now they use a > much more usefull range: price/10k pcs, sometimes price/1k pcs! > > Does someone else agree? > > Luiz Carlos.Article: 74307
Hi, > Any suggestions for books, sites to read, FPGA > starter kits, etc would be greatly appreciated. You might find my website interesting: http://www.fpga-games.com I should point out that this is not sponsored or endorsed by my employer and the contents of it are entirely my own opinion. I've got a number of links to people doing the same kind of stuff -- there are a surprisingly large number of people interested in these kinds of projects. If you are looking for a good starter kit, the Spartan3 starter kit is an undeniably good value. There are fancier boards around, which are also attractive, but more expensive. It depends on your budget. Have fun, EricArticle: 74308
Brian, An oversight on my part. I apologize. Please let me know if there are any questions left unanswered. See below, Austin Brian Davis wrote: > Austin wrote: > >>But never silent. >> > > Google and I respectfully disagree with you. > > Taking just the most recent thread as an example: > http://groups.google.com/groups?hl=en&lr=&q=s3+dci+ramp+fpga > > You and Steve were both quick to discount the possiblity > of a parallel DCI startup transient triggering the S3 VCCO ESD > circuit; yet when I rephrased my original post to be less > ambiguous, there was no response. > > Outstanding questions from that thread: > > - Why is there no SSO data for VQ/PQ/TQ packages in the S3 datasheet? Spartan 3 belongs to the General Product Group here at Xilinx. I am employed by the Advanced Products Group. I do not know the answer, but I will ask Steve Knapp to reply. > > - Why did the blank column for said SSO data dissapear? Again, a Spartan issue, so I will let Steve reply. > > - Has Xilinx considered, tested, or characterized the possibility > of triggering the Spartan3 VCCO ESD circuit with an internal > VCCO rail collapse induced by the SSO-like effects of the > parallel DCI terminator startup current in the leaded packages? To the best of my knowledge, yes, this was simulated, as well as tested. The mechanism causing this is an active ESD clamp using transistors, so as such, its behavior is completely different when power is ramping, as opposed to after power has ramped ON. > > I haven't completed an S3 DCI design yet, so I haven't actually > witnessed this (hypothetical) problem, but past experience coupled with > the description of the VCCO ramp problem led me to ask the question. Perfectly valid questions. > > BrianArticle: 74309
oen_no_spam@yahoo.com.br (Luiz Carlos) wrote in message news:<3fd8f66b.0410070241.539ec1d5@posting.google.com>... > I was just thinking about: > > 1M/250k = 4 customers, ok? > > Why Xilinx, Altera, etc, give us prices for 250k pcs??? > > DSPs vendors had the same behavior some years ago, but now they use a > much more usefull range: price/10k pcs, sometimes price/1k pcs! > > Does someone else agree? > > Luiz Carlos. Give Xilinx a break, the Spartan III has only been released for 6 months or so. Most design cycles are at least 1-2 years. Those 1M are probably mostly sample quantities. But I agree with you 250K pcs is a lot of FPGA's. At my company if we sell 1,000 of one PCB a year we are doing good. Xilinx show give a more ala-cart pcs quantity when posting quotes on there website. Eric HollandArticle: 74310
SG, Comments below, Austin SG wrote: > Austin Lesea <austin@xilinx.com> writes: > > >>Just remember that the PPC, MGT, DCM, EMAC, DSP48, etc. are all 'hard >>cores' and do not 'suffer' from the same 10:1 disadvantages in speed >>and power as plain old interconnect and logic. > > > Only if you use them. Otherwise, they contribute even more to the > area disadvantage of FPGAs over ASICs. *Usually*, there will always be > some of hard blocks in a FPGA that you will not use for your > application (the FPGA device having been chosen for cost, fitting > your design, etc reasons). > You get to choose if you want to use them, yes. > >>Not mentioned here is that ASICs suffer a 10:1 disadvantage in single >>event upsets. Every single upset in an ASIC is a functional failure >>(plus they are a lot more sensitive being the smallest structure >>possible). Only 1:10 SEUs in a FPGA cause a functional failure. The >>two factors cancel out. > > > This is firstly not germane to the discussion of FPGA area vs ASIC > area, but more importantly an unsubstantiated claim. The only devices > that have been recalled from the market due to SEU errors are Xilinx > FPGAs. Besides as was the case with Xilinx, this is a problem that > packaging can fix to some extent (at a cost of course). 'Germane' is how a FPGA compares to an ASIC. SEU hardness is a factor. Perhaps a very important one. The alpha package contamination issue was not caused by cosmic rays, but by contaminated solder (alpha particles). Do not confuse the issue. We are not the first company to have that problem. Although, we are the first FPGA company to have that problem. I am supposing that ASIC vendors would not be likely to stand up and admit they have ever had that problem, but I am sure that they do (as we were not the only part that received that bad lot of material). The Rosetta experiments have proven the claim. Go ask you favorite ASIC vendor what their FIT/Mb is in their latest 90nm ASIC. Go ask what the MTBF is from cosmic ray neutron showers at sea level for their 10M gate part. Oh, and ask them how they know. Probably the most important question. With LANSCE (Los Alamos) closed due to security concerns, no one can do beam testing right now. And if you do beam testing, how does that correlate. Does it? Prove it. We have. And who has atmospheric test data? We do. 7400 device years and counting on .15u, .13u and 90nm. Make sure you ask your vendor for their data. It is not rocket science (to design for soft errors): if I make every single circuit as small as I possibly can, and load each cell with as small a load as possible, I have just made a neutron detector in 90nm. Oh, I just described an ASIC! If I have to connect everything to everything, and control it with memory bits, and run slower, and not use all of the transistors, then I have just described the common techniques used to improve hardness to neutron induced upsets. I have also described a FPGA. A radical statement, yet one I believe is true, is that FPGAs may be the only safe way to design in the future due to soft errors. Only if ASICs dedicate more area and have less speed and create rad hard cells will they be able to compete for basic reliability below 90nm. > > Since we are discussing all the other issues of ASIC vs FPGAs, we > should also pay attention to the severe power/energy consumption > disadvantage of FPGAs. Since 65% of the power dissipated by a FPGA is > by its interconnect, this is an inherent problem with FPGAs (there are > several papers that have studied the power breakdown of FPGAs). Soon, > we will need heat sinks and other passive and active cooling for FPGAs > as the number of gates and the speed at which they operate is > increased. I have already heard from some folks that they are on the > border of using cooling for the larger, faster FPGAs. In 20 years, we maximum power of the FPGA has not changed. When they ran at 20 MHz, they could dissipate 10 - 15 watts, and today at 500 MHz, they can dissipate 10 - 15 watts. Again, for what we do, we have done it better, every single time we introduce a product. We are not a uP, with 100W heatsink solutions, and at the end of the line for further improvements. Yes, many customers use cooling on their FPGAs. Always have, and probably always will, when they run at high frequencies in the larger parts. I also see heat sinks on ASICs. I will concede that an ASIC will always draw less power to do the same job as a FPGA. No argument there. But we do improve, and the hardened bits are just as good as an ASIC. > > The inherent disadvantage of FPGAs over ASIC implementations lies in > the interconnect and configuration memory. Interconnect comprises > about 60% of a FPGA fabric, configuration memory is about 30%, and > only about 10% is the actual LUTs. This assumes no hard macros, just > a pure sea of LUTs. Again these figures are well-known and published > by multiple sources (search for Andre DeHon's thesis and papers for > one). OK. Don't disagree with the numbers. "Inherent disadvatage" is a value judgement. If I can change it (reprogrammability), and if I am better able to deal with SEUs, than I claim that we have an inherent advantage. > > Even out of the 10% LUTs, the utilization of each LUT is low. This > means, that even though every single LUT in a FPGA may be used, not > each LUT is used to 100% capacity. For example, a LUT could be used > to implement something as simple as an AND gate (highly likely, but > possible) or much more complex 4-input functions (if its a 4-LUT). > So, if you take what the percentage of each LUT is utilized into > account, overall logic/LUT utilization is reasonably low (again > something that I have seen figures around 30-50% before - probably > from Jonathan Rose's work). Yes. That was my point as well why we are at parity (or better) for an ASIC for SEU. You are making my argument for me. Thank you. > > Like I said before, these area, performance power, cost disadvantages > of FPGAs all have to be measured against NRE cost, die cost, back-end > tool costs, and volume of ASICs to determine whether you want to do a > FPGA or an ASIC or a structured ASIC. Clearly, FPGAs come out on top > a lot of times (and thus the large market for them). > > SumitArticle: 74311
I want to realize an add/subtract function, a 2:1 mux between this adder
and a load value and an enable of the register in a single LE. As I can
see in the data sheet (Cyclone) this should be possible: There is an
extra input addnsub to decide between add and subtract. Two inputs of the
LUT are used for the add/sub, the remaining two inputs can perform the
2:1 mux. The register has an additional ena input.
However, with the following VHDL I get 2 LEs per bit instead of 1. Any
ideas?
Martin
VDHL example:
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity alu is
generic (
width : integer := 32 -- one data word
);
port (
clk : in std_logic;
lmux : in std_logic_vector(width-1 downto 0);
b : in std_logic_vector(width-1 downto 0);
sel_sub : in std_logic; -- 0..add,
1..sub
sel_amux : in std_logic; -- 0..sum,
1..lmux
ena_a : in std_logic; -- 1..store
new value
dout : out std_logic_vector(width-1 downto 0)
);
end alu;
architecture rtl of alu is
signal a : std_logic_vector(width-1 downto 0);
begin
-- this add/sub, the sum/lmux mux and the enable should fit into
-- a single LE.
process(clk, ena_a) begin
if rising_edge(clk) then
if ena_a='1' then
if sel_amux='0' then
if sel_sub='0' then
a <= std_logic_vector(signed(b) - signed(a));
else
a <= std_logic_vector(signed(b) + signed(a));
end if;
else
a <= lmux;
end if;
end if;
end if;
end process;
dout <= a;
end rtl;
--
----------------------------------------------
JOP - a Java Processor core for FPGAs:
http://www.jopdesign.com/
Article: 74312
Martin,
I'll guess. Is it because addnsub is low for an add? So try:-
if sel_sub='1' then
a <= std_logic_vector(signed(b) - signed(a));
else
a <= std_logic_vector(signed(b) + signed(a));
end if;
Cheers, Syms.
Article: 74313g. giachella wrote: > y design inside an Altera Stratix device. I have some doubts about > the usage of the Pll Lock signal (the output of the Fast Pll, which > indicates the Pll locked the input clock). In particular, I'm > currently assuming that, after power on, the Pll locks before the > completion of the fpga configuration, so that the PLL clock output can > feed the internal logic without any protection against VCO transients. > If this is not correct, I should in some way gate the Pll clock output > with the lock output. > > Any advice about this point ? The PLL will lock AFTER configuration, so after configuration (or a circuit break or so), lock will be deasserted. Also note that the lock signal is direcly derived from the phase comparator, so while the PLL is locking, you'll see the lock pin be asserted and deasserted a few times before it becomes a stable '1'. The best solution is to have a counter that counts up to some value as long as lock is '1', and gets reset when it becomes '0'. Once it reaches the count value (say 31) it should stop counting and tell the logic that the clock is stable, which I think is easiest to achieve by ANDing this signal with the (synchronous) reset signal for the circuit. Best regards, BenArticle: 74314
Hi all, Xilinx claimed all their currents device are available in lead free packages, but that not true... at least that's what I firgure out today. Does this device ever exist XC2S100-FGG256 (speed doesn't matter)? Seems I can't find any distributor has it, or just because this device is OBSOLETE? If so we probably shut down our business... Any advice is appreciate,Article: 74315
Mr Marlboro, this is a very specific question that I suggest you pose to your Xilinx distributor and up the Xilinx sales channel. That way you will get an answer from the people that are directly intersted in your specific business. Peter Alfke > From: ccon67@netscape.net (Marlboro) > Organization: http://groups.google.com > Newsgroups: comp.arch.fpga > Date: 7 Oct 2004 13:58:22 -0700 > Subject: Xilinx lead free parts hidden fact > > Hi all, > Xilinx claimed all their currents device are available in lead free > packages, but that not true... at least that's what I firgure out > today. Does this device ever exist XC2S100-FGG256 (speed doesn't > matter)? Seems I can't find any distributor has it, or just because > this device is OBSOLETE? If so we probably shut down our business... > > Any advice is appreciate,Article: 74316
In ISE6.i, I can use "Prohibit" constraint to disallow the use of CLBs in Virtex. However routing resources of Virtex are not applicable elements for "prohibit" constraint. I wonder if there is a way to reserve an certain routing area (disallow the use of an certain routing area) of Virtex FPGA. Thanks a lot.Article: 74317
> From: Jim Granville <no.spam@designtools.co.nz> > Organization: TelstraClear > Newsgroups: comp.arch.fpga > Date: Thu, 07 Oct 2004 11:11:51 +1300 > Subject: Re: DCM and CLKFX - is this allowed? > > Maybe you could try a maths based description, generally that's > much better than English ? > > Fo = fi * M/D; > Valid for > LLimitM < M < ULimitM [You fill out the Limits ] > LLimitD < D < ULimitD > > and if there are interactions (Limits depend on other variables value) , > then expand this as necessary. > Jim, that's not enough. We did that, M and D can be any intger up to 32, and the input frequency must be higher than 1 MHz, and the output frequency must be higher than 24 MHz, but not higher than 450 MHz But that does not stop users' imagination. So we get the question that started this thread. And that's why I added the explanation: multiply alone, or divide alone are allowed to seemingly violate the spec, as long as the input and output specs are obeyed. "Don't speculate, believe us!" We engineers have this wide-ranging imagination (thank God) and we are trained to think worst case (thank God, but sometimes it can mislead...) Peter AlfkeArticle: 74318
> Maybe they sells in theses qty for company like Avnet ... then avnet gives the price for 10k, 1k, and even 100 pieces. > > > > Sylvain Yes, maybe. But we (I, you,...) will make products using those FPGAs, not AVNET! We must know the prices. I don't care the price AVNET pays, I want to know the price I'll pay. Let's suppose a $10 FPGA. 250k*10= $2.5M It's time to think of ASICs, maybe not 90nm whith $1M mask sets, but 130 or 150nm or even older technology. But ASICs are far from our reality (well, must of us), as are 250k FPGAs! And I really think that even XILINX, ALTERA, etc, don't sell 250k pcs of those bigger (more expensive) FPGAs in one year. Luiz Carlos P.S.: a) Of course I know NuHorizons, AVNET, Insight, etc. But, as I said, I think the information must be addressed to the users. b) I think that discussion about ASICs versus FPGA very nonsense. I don't even dream making an ASIC, and probably the same for 99% of you. What is important is that FPGAs are making some of our dreams come true. I'm really pleased that every day they become larger, faster and cheaper.Article: 74319
On Thu, 07 Oct 2004 19:31:33 GMT, "Martin Schoeberl" <martin.schoeberl@chello.at> wrote: >I want to realize an add/subtract function, a 2:1 mux between this adder >and a load value and an enable of the register in a single LE. As I can >see in the data sheet (Cyclone) this should be possible: There is an >extra input addnsub to decide between add and subtract. Two inputs of the >LUT are used for the add/sub, the remaining two inputs can perform the >2:1 mux. The register has an additional ena input. >However, with the following VHDL I get 2 LEs per bit instead of 1. Any >ideas? > >Martin Too many inputs to the LUT. 1 for the A operand 1 for the B operand 1 for the add/sub signal 1 for the load value 1 for the carry in from the previous bit. I faced this problem back in 1990 when designing R16 for the XC4005. My solution was to make the load value come in on the "A" operand path. In the older Xilinx architectures this is not too hard, as the carry logic is separate from the LUT (but very close by), and the CE for the FFs is a separate signal. While the topology of the CLBs has changed significantly since then, I believe this can still be done in the more recent Xilinx devices. Many of the earlier Altera architectures implied this was possible in their data sheets, but the architecture could not actually support it, because the data sheets showed mutually exclusive functions, while not explaining that they were mutually exclusive. For example, the CE signal shared an input with the LUT, and the LUT was broken into two 3 input LUTs to implement ADD (1 for the sum bit and one for the carry out), so you could not even do add/sub in one LE. I believe these deficiencies have been corrected in more recent products, but you would need to look very carefully at what a LAB can really do. Philip Philip Freidin FliptronicsArticle: 74320
Hi folks, I have outputs being driven by a fast internal clock generated by a DCM. It would seem to me that I should be able to set up a clock to pad timing constraint for this animal. But the Xilinx tools says I need to specify a pad as the clock, and the DCM outputs don't show up as a viable clock source in the drop down menus, I would assume because they are not pads. What is the right procedure here? Brad Smallridge b r a d @ A i V i s i o n . c o m 415-661-8068Article: 74321
Peter Alfke wrote: > >>From: Jim Granville <no.spam@designtools.co.nz> >>Organization: TelstraClear >>Newsgroups: comp.arch.fpga >>Date: Thu, 07 Oct 2004 11:11:51 +1300 >>Subject: Re: DCM and CLKFX - is this allowed? >> >>Maybe you could try a maths based description, generally that's >>much better than English ? >> >>Fo = fi * M/D; >>Valid for >>LLimitM < M < ULimitM [You fill out the Limits ] >>LLimitD < D < ULimitD >> >>and if there are interactions (Limits depend on other variables value) , >>then expand this as necessary. >> > > Jim, that's not enough. > We did that, M and D can be any intger up to 32, and the input frequency > must be higher than 1 MHz, and the output frequency must be higher than 24 > MHz, but not higher than 450 MHz I think you are saying this : Fo = fi * M/D; Valid for this range of numbers 1 <= M <= 32 1 <= D <= 32 and this range of frequencies 24MHz <= Fo <= 450MHz and Fi >= 1MHz So why is this not enough - is there some technical blind spot, or are you saying users imagine there might be ? > > But that does not stop users' imagination. So we get the question that > started this thread. And that's why I added the explanation: multiply alone, > or divide alone are allowed to seemingly violate the spec, as long as the > input and output specs are obeyed. Here I am lost: the equation form I was proposing has no partial answer, so you cannot have multiply alone or divide alone. > "Don't speculate, believe us!" > We engineers have this wide-ranging imagination (thank God) and we are > trained to think worst case (thank God, but sometimes it can mislead...) > Peter Alfke Perhaps, but throw that collection of words at someone who has english as a second language, and they are likely to get confused. is this another warning/caveat, or an explanation ? My point is that concise expressions leave much less to the imagination, and cross language barriers much easier. -jgArticle: 74322
Austin Lesea wrote: > V4 has some changes to keep the oscilltor running even in adverse > conditions, as does Spartan 3, but we haven't finished characterizing > just how tolerant of the jumps the DFS is. And maybe we won't, as it > isn't worth it (such a phase glitch on CLKIN would cause lots of other > problems with timing violations in logic anyway). > > Changing M or D, and then reseting is supported, however. I'd love to be able to do that on a V2. I would be more then happy to go through a reset of the DCM to give it a chance. Alas, my design is a parasite project on a board made for another purpose, so I can't change the chip out:-( In my application, the DCM output is sent off-chip to devices under test. -- Steve Williams "The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, http://www.icarus.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep."Article: 74323
Kevin Neilson <kevin_neilson@removethiscomcast.net> wrote in message news:<cjs8cv$23d1@xco-news.xilinx.com>... > iceman wrote: > > > ei anyone can help me with the algorithm on how to control a > > servomotor... cause we are gonna use it on our thesis... by the it's > > called "FPGA based intravenous infusion monitoring and control system" > > > > can anyone help us out on how to control a servomotor...will be using > > the servomotor to clamp the tube of an I.V.(intravenous) tube... the > > flow of the algorithm will bw this... first a personnel will input how > > many dosage a patient gets and then the servomotor will clamp the I.V. > > tube so that the desired dosage is achive... by the way will be using > > optical sensors to monitor the drops of the I.V. fluid i will be > > placed at the outside of the drip chamber... > > > > but we have a problem what if the drip of the fluid change how will > > the servomotor adjust it so that the dosage will be maintained...will > > use a feedback but how are we gonna implement it on FPGA.. > > > > got any suggestion on the algorithm... or any sites that can help us > > solve this problem > > Is the volume of a drop constant no matter the drip rate? > > Controlling R/C servomotors is pretty easy. There is lots of info on > the web. I think the position is controlled by the length of an input > pulse. Maybe a better method would be to use a stepper motor connected > to a wormscrew clamp. Then you could control the absolute position > (rather than relative) better. -Kevin =============================================================================== yes the volume of the drop is constant...Article: 74324
Followup to: <36bd41b5.0410070335.5aeeacc3@posting.google.com> By author: david@fpgaworld.com (David Kallberg) In newsgroup: comp.arch.fpga > > I'm trying to run Synplify on a Fedora Core 2 platform but I get the > following error message: > > "relocation error: /../synplify_77/linux/mfw/lib-linux_optimized/libkernel32.so: > symbol errno, version GLIBC_2.0 not defined in file libc.so.6 with > link time reference" > > I'm in no way a Linux expert so this means nothing to me. > > Advice? > Presumably it means they've linked a Windows application against the MainWin library. MainWin seems to be stuck in the world of RedHat 7. The above error means that the library in question is not thread-safe, which is no longer supported. I don't know if there is a way around it (I tried a long time ago with no success), other than installing RH7 in a subdirectory and use chroot. -hpa
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