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
I am not clear on what you are saying. Based on the number of cells in these chips, the area should be 50% larger. So you will get about 1/3 less die and you will have 50% more area to see defects in. The price of the 384XL is 3:1 over the 256XL price. Because of the lower number of 384XL die on the wafer, multiply the price of the 256XL by 3/2, now the ratio is 2:1. I think if you do the math, you will see that a 50% increase in chip area does not make a 50% reduction in yield unless your yield is already pretty low. Just how tiny are these two parts? Austin Lesea wrote: > > Falk, > > That is a bit unfair. > > Larger die parts cost more to make, because the yield is less. That is > semiconductor physics 101. > > To imply a yield "problem" is misleading, and untrue. > > And, quite frankly, a bit absurd. After all, it is a CPLD, is absolutely tiny > compared to the FPGAs that we make. > > Austin > > Falk Brunner wrote: > > > "rickman" <spamgoeshere4@yahoo.com> schrieb im Newsbeitrag > > news:3D78D726.A3FA9369@yahoo.com... > > > I have received an email reply from Xilinx which says that the XCR3384XL > > > device is significantly more expensive to make than the XCR3256XL and so > > > there are no plans to significantly reduce the price. > > > > Hmm, looks like a yield problem. So you will end up by using two 256er > > devices, wont you? > > -- > > MfG > > Falk -- 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: 46801
Hi, I have a specific query regarding the fixed point conversion routines in SystemC. I have observed that while using the SC_TRN (trruncation mode) of quantization, there is an anamoly that I am unable to figure out. Say we have a variable "x" quantized with "wl" bits and "iwl" integer bits. In the SC_TRN mode, all values of x in the range [-1/2^(wl-iwl),0] get quantized to 0. However, I expect the quantization to be towards -1/2^(wl-iwl) as SC_TRN represents the round towards minus infinity mode. why is this discrepency occuring? Can anyone please advice. Thanks VikramArticle: 46802
Nikhil Bhatia wrote:
In the following code, synplicity removes the "sk_wroffset_ctr_en " i.e optimises away.
Perhaps sk_wroffset_ctr_en is never assigned to a port pin.
Perhaps wroffset_ctr_en(i) evaluates to a constant.
Consider running a sim and tracing the code.
-- Mike Treseler
Article: 46803Rick, I am saying it has nothing to do with yield. Yield is not a factor. I defer to Peter's answer. Austin rickman wrote: > I am not clear on what you are saying. Based on the number of cells in > these chips, the area should be 50% larger. So you will get about 1/3 > less die and you will have 50% more area to see defects in. The price > of the 384XL is 3:1 over the 256XL price. Because of the lower number > of 384XL die on the wafer, multiply the price of the 256XL by 3/2, now > the ratio is 2:1. > > I think if you do the math, you will see that a 50% increase in chip > area does not make a 50% reduction in yield unless your yield is already > pretty low. > > Just how tiny are these two parts? > > Austin Lesea wrote: > > > > Falk, > > > > That is a bit unfair. > > > > Larger die parts cost more to make, because the yield is less. That is > > semiconductor physics 101. > > > > To imply a yield "problem" is misleading, and untrue. > > > > And, quite frankly, a bit absurd. After all, it is a CPLD, is absolutely tiny > > compared to the FPGAs that we make. > > > > Austin > > > > Falk Brunner wrote: > > > > > "rickman" <spamgoeshere4@yahoo.com> schrieb im Newsbeitrag > > > news:3D78D726.A3FA9369@yahoo.com... > > > > I have received an email reply from Xilinx which says that the XCR3384XL > > > > device is significantly more expensive to make than the XCR3256XL and so > > > > there are no plans to significantly reduce the price. > > > > > > Hmm, looks like a yield problem. So you will end up by using two 256er > > > devices, wont you? > > > -- > > > MfG > > > Falk > > -- > > 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: 46804
"Peter Alfke" <palfke@earthlink.net> schrieb im Newsbeitrag news:3D7C176F.D6CA850F@earthlink.net... > If I can decypher your drawing, thta's exactly what we use for measuring. > Look at XAPP094... Hmmm. If I got it right, you have a free running clock with 50 MHz and another free running 350 Mhz clock for sampling. Both clock are NOT related to each other by deriving them from the same clock source or by use of a PLL. In this case, the phase drift between the two clocks is undefined, random. What does it mean? If the two clock would be derived from the same source (350 MHz divided by 7 yields 50 Mhz) or phase coupled by a PLL, you would see a steady phase relation on your scope (if you trigger on the 50 MHz, not the 350 MHz ;-) If the two sources are real independent but exactly tuned, you would see this steady picture too, but not for a long time, since tempeature drift and other things will detune the oscillators. If you detune the two clocks by a given amount (some ppm), then there will be a given "crash" frequency, which is the number of transition crossing (data and sampling clock edges are happen simultaneously) that will cause metastable events. So how is this handeled in the setup? The application note just speaks about unrelated clocks. But with such a setup, is it possible to reproduce the measurement results? May it be possible that you just catch a (un)lucky canned oscillator and measure house numbers, since the "crash" frequency is totaly random. In the "bible" of Graham & Johnson, there is a circuit for metastability experiments. Why not using this one (or something similar). In my eyes, this cicuit gives much more possibilities to do repeatable mesurements. Yes, the original circuit produces metastable events with every sampling edge, which is not the case in real applications. But wouldnt it be better to do a maximum stress test and after this scale down to real application numbers, just as it is done with power consumtion (average toggle rate)? Just some ideas. -- MfG FalkArticle: 46805
Frank Instead of beating on C/C++/Java/.. to create HDL logic, you really could do a better job the other way around. Learn/use a simple subset of structural Verilog/VHDL that synthesizes easily to FPGA and the tools are not too expensive or even free. Then you can also reverse compile the same Verilog to C for really fast simulations. In most of my work I do a structural C model 1st then rewrite as Verilog almost 1 to 1 mapping. The Verilog code can then be put back through V2C to produce a C model that is equiv to Verilog but only runs about 2-5x slower than the best case hand written C model. I hope to release (gpl) this compiler when it is more user friendly but there are others out there too some for free. With the C model in hand you can also ship that as a perfectly good but much slower model of youy app. Now the C model can simulate many times faster than Verilog and you can also tweak the code to reduce the V2C penalties while getting the benfit of the maintenance being mostly on Verilog source. Win win alround & no $70K C to V to buy. IMHO using just C to do asic/fpga design is like driving a car from the back seat!Article: 46806
Mikeandmax wrote: > > OR - just perhaps evaluate Lattice ispMACH4384 - it is available in 1.8, 2.5 > and 3.3v versions - is also an extremely low current technology - Lattice went > to an all CMOS gate structure in this family - no sense amplifiers to gobble up > current. > > oops, affiliation and all that stuff - > > Michael Thomas > LSC SFAE > for the latest info on Lattice products - http://www.latticesemi.com Hmmm... you are going to make me work for this one aren't you? I checked the Lattice web site and the search says that ispMACH4384 is not a valid part number. Ah, there it is the ispMACH4384V. This part does not seem to be 5 volt tolerant, no? Can you help me out a little? I don't see a clear selection guide and I am working over a very low speed data link today. Can you find the parts that meet my criteria? I had pretty well settled on the XCR3256XL, but if you have something cheaper, I would love to hear about it. Requirements: small package such as 256 fine pitch BGA (17 mm sq) >=256 macrocells >160 IOs very low idle current low operating current 3.3 volt Vcc JTAG boundary scan JTAG programming onchip memory for FIFOs would be useful, but not required memory will allow fewer macrocells >140 Thanks, -- 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: 46807
--------------EA8EA0260D7110C20687AC52 Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit I thought that I had explained it pretty well ( see below). rickman wrote: > I am not clear on what you are saying. Based on the number of cells in > these chips, the area should be 50% larger. More than that, the routing grows overproportionally. > So you will get about 1/3 > less die and you will have 50% more area to see defects in. Wrong, see above > The price > of the 384XL is 3:1 over the 256XL price. Because of the lower number > of 384XL die on the wafer, multiply the price of the 256XL by 3/2, now > the ratio is 2:1. > > I think if you do the math, you will see that a 50% increase in chip > area does not make a 50% reduction in yield unless your yield is already > pretty low. Let's avoid "yield" and use the more common "net die per wafer". Net die per wafer will be substantially less ( or should I say fewer) due to overproportional chip size plus the effect of defect density limitations ( which kicks in at large chip sizes).. Just read my previous posting, repeated here: The original question was: Why four times the price for 50% more macrocells? Here is an attempt at a rational explanation. There are five factors that contribute to disproportionate pricing: 1. More chip area. CPLDs don't grow linearly, their interconnect grows faster. (Different from FPGAs) 2. Lower yield due to defect density on the wafer. That increases the cost for any die faster than the growth of the die area. (Semiconductor Physics 101) 3. Lower production volume. High volume drives cost down. The reverse is also true. 4. Fancier package. 5. And finally: Less competitive pressure. Everybody will understand this. These are the five factors that make the '384 overproportionally more expensive than the '256. You might argue about each individual factor, but you cannot overcome their composite effect. But CoolRunner-II uses smaller geometries and will be less expensive... Peter Alfke, Xilinx ApplicationsArticle: 46808
Noddy wrote:
>
> Hi,
>
> Sorry, been at conference and so haven't been able to respond.
>
> > This is all true. I expect that number 3 is what the OP would be
> > looking for, but he was not clear in his problem statement.
>
> Ok, this is my problem. I am building a filterbank receiver (to be precise,
> its a pulsar timer, but that is irrelevant) for a radio astronomy
> observatory. Hence, at the moment the design wil just quite a few boards
> with FPGAs on, each with a complex low pass filter (I am using quadrature
> signals). All have the same characteristics, and I do some digital complex
> mixing prior to the filters to shift the signals about DC.
>
> What I was thinking of doing was, since the filters have a cutoff of 0.125,
> I could move all the filtering onto a single FPGA by implementing a
> polyphase filter with N=8, followed by FFT etc. etc.
>
> What do you think?
>
> Adrian
That is exactly what polyphase filtering is good for. You can get by
with less hardware. But make sure you are not going to suffer from the
rolloff at your filter edge. The cutoff is not absolute and should be
slightly below the decimated Nyquist rate to allow the transistion band
to remove all artifacts before you reach the decimated Nyquist rate.
The decimated Nyquist rate should be in the stop band rather than at the
cutoff, or at least 1/2 way though the transistion band (which results
in the same amount of "junk" but will make it slightly harder to further
filter).
_______
\ ____ cutoff (-6dB)
\
\
\ Transistion band
+ --- Put Nyquist rate no lower than here
\
\
\ Stop band
\________________
Result after midtransistion band frequency folding
The transition band above the Nyquist rate is folded into the
same freqs as the transition band below the Nyquist rate
_______
\
\
\
\
>
/
/
/
_______/
--
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
Article: 46809I am considering using an Atmel ATF15xx series CPLD. This would be my first PLD of any sort, and I'm a little bit floundering. For instance, the part data sheet says that outputs can be configured for "open-collector" (open drain?) operation; but, I don't find any mention of that in the "Programmer's Reference Guide". Is there other documentation on these parts? Or, is there a better way to learn this stuff? Thanks, George -----= Posted via Newsfeeds.Com, Uncensored Usenet News =----- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -----== Over 80,000 Newsgroups - 16 Different Servers! =-----Article: 46810
I would like to know if anyone do FFT filter for NTSC or PAL in real time?Article: 46811
rickman <spamgoeshere4@yahoo.com> wrote: ... : Can you help me out a little? I don't see a clear selection guide and I : am working over a very low speed data link today. Can you find the : parts that meet my criteria? I had pretty well settled on the : XCR3256XL, but if you have something cheaper, I would love to hear about : it. : Requirements: : small package such as 256 fine pitch BGA (17 mm sq) :>=256 macrocells :>160 IOs : very low idle current : low operating current : 3.3 volt Vcc : JTAG boundary scan : JTAG programming : onchip memory for FIFOs would be useful, but not required : memory will allow fewer macrocells >140 Coolrunner II may be an alternative, also it seems no general available yet... Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 46813
On Wed, 04 Sep 2002 23:30:43 -0500, Mike Rosing <rosing@neurophys.wisc.edu> wrote: >George Eccles wrote: >> I am considering using an Atmel ATF15xx series CPLD. This would be my >> first PLD of any sort, and I'm a little bit floundering. For >> instance, the part data sheet says that outputs can be configured for >> "open-collector" (open drain?) operation; but, I don't find any >> mention of that in the "Programmer's Reference Guide". >> >> Is there other documentation on these parts? Or, is there a better >> way to learn this stuff? > >I just looked at an ATF1500 and I don't see it as having open-collector >drivers. I've never used these parts tho, so maybe I'm missing >something. It's on the first page of the data sheet I'm looking at: "– Programmable Output Open Collector Option per Macrocell" > What tools are you going to use to program the parts with? >Can you run them now? Can you get a demo version and try it out? Don't know, no, no. I'm just getting starting, trying to decide if it will do what I need. >You may be able to hit the "help" button and do a search for >"open-collector" and find the right place to set your outputs up. Done that (in CUPL); it doesn't appear to be listed. George -----= Posted via Newsfeeds.Com, Uncensored Usenet News =----- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -----== Over 80,000 Newsgroups - 16 Different Servers! =-----Article: 46815
rickman wrote: > > I am not clear on what you are saying. Based on the number of cells in > these chips, the area should be 50% larger. So you will get about 1/3 > less die and you will have 50% more area to see defects in. The price > of the 384XL is 3:1 over the 256XL price. Because of the lower number > of 384XL die on the wafer, multiply the price of the 256XL by 3/2, now > the ratio is 2:1. > > I think if you do the math, you will see that a 50% increase in chip > area does not make a 50% reduction in yield unless your yield is already > pretty low. For reference points, here is info from Lattice Web : # Pricing for the ispXPLD5512MC in volumes of >1000 pieces # starts at $17.75 # For high-volume applications, the ispMACH 4512C will be # priced below $15.00. # Projected pricing for the ispMACH5768VG is as low as # $33.00 in high-volume for the second half of 2002 Seems they also have a steepening of the price curve, but at 512->768, not 256->384. -jgArticle: 46816
Falk Brunner wrote: > Hmmm. > If I got it right, you have a free running clock with 50 MHz and another > free running 350 Mhz clock for sampling. > Both clock are NOT related to each other True, one is a canned crystal oscillator of 50 MHz, the other one is an hp pulse generator. Since the measurements give repeatable results that fit the exponential relationship between extra settling time and MTBF, I like this method. But I will look up the Howard Johnson "bible", it's right here on my bookshelf. Peter > So how is this handeled in the setup? The application note just speaks about > unrelated clocks. But with such a setup, is it possible to reproduce the > measurement results? May it be possible that you just catch a (un)lucky > canned oscillator and measure house numbers, since the "crash" frequency is > totaly random. No, I vary the hp output frequency around 350 MHz. We have changed the chip-internal design, giving us different interconnect delays, and the results have moved accordingly. All very repeatable, albeit statistical. > > In the "bible" of Graham & Johnson, there is a circuit for metastability > experiments. Why not using this one (or something similar). In my eyes, this > cicuit gives much more possibilities to do repeatable mesurements. Mine are repeatable already. > Yes, the > original circuit produces metastable events with every sampling edge, No, I sample 50 MHz with a >300 MHz clock. Most samples are naturally far away from the metastability-inducing window. > which > is not the case in real applications. What happens in a "real" application? I think I am close to a real synchronizing case. > But wouldnt it be better to do a > maximum stress test and after this scale down to real application numbers, I think that's what I am doing, when the circuit goes matastable many times a minute... Mit freundlichen Gruessen, that's what MfG stands for in German :-) Peter > > just as it is done with power consumtion (average toggle rate)? > > Just some ideas. > > -- > MfG > FalkArticle: 46817
"Falk Brunner" <Falk.Brunner@gmx.de> wrote: >"Peter Alfke" <palfke@earthlink.net> schrieb im Newsbeitrag >news:3D7C176F.D6CA850F@earthlink.net... > >> If I can decypher your drawing, thta's exactly what we use for measuring. >> Look at XAPP094... > >Hmmm. >If I got it right, you have a free running clock with 50 MHz and another >free running 350 Mhz clock for sampling. >Both clock are NOT related to each other by deriving them from the same >clock source or by use of a PLL. >In this case, the phase drift between the two clocks is undefined, random. I don't see it matters. As long as the clocks beat and the beat period is small compared to the measurement time. During a measurement period the number of times both clock edges occur within a given metastability window only depends on the ratio of the clocks, a few ppm off frequency gives a few ppm measurement error. I would be concerned about the clocks interacting with each other, a minute amount of jitter induced in one clock by the other could really distort the measurement. I think I would keep the clock generators physically separate with the device under test in the middle that way the device gets to see both clocks before the generators get to see each other.Article: 46818
nospam wrote: > > I think I would keep the clock generators physically separate with the > device under test in the middle that way the device gets to see both clocks > before the generators get to see each other. Sure, done that. Remember, I have been at this, on and off, for 14 years... Ciao Peter AlfkeArticle: 46819
You are right but my problem is twofold, first I don't know VHDL, I bought a book about digital design and VHDL and it's pretty straightforward, but the main thing is, my "algorithm" is huge in hardware, I couldn't easily make that within a year... If I would specify it in C, it would be several nested loops with lots of pattern recognition and very complex decisions. No way I will ever get that to work in VHDL. And I need to tweak it all the time, radically change it maybe, and I can start all over again in VHDL... We are talking about a newbie here, trying to put some major artificial intelligence into a FPGA... My idea was to code in C/Java, get a slow but working FPGA fast to play with, slowly learn VHDL at the same time, and replace more and more of my C/Java by handcoded VHDL. Comparable to coding a quick prototype, a proof of concept in Visual Basic, and then refining routine by routine, after which you hand-optimize it in assembly... In 1 week I'll get the board and I'm very anxious to get started... I'll sure try to code some Verilog or VHDL myself. I *need* the end result to be as fast as possible. It might even be that there is no gain at all when using a high-level procedural language converter... Frank "John Jakson" <johnjakson@earthlink.net> wrote in message news:38111bbc.0209090832.50335d7a@posting.google.com... > > Instead of beating on C/C++/Java/.. to create HDL logic, you really > could do a better job the other way around.Article: 46820
Peter Alfke wrote: > Falk Brunner wrote: <snips> > True, one is a canned crystal oscillator of 50 MHz, the other one is an hp > pulse generator. > > So how is this handeled in the setup? The application note just speaks about > > unrelated clocks. But with such a setup, is it possible to reproduce the > > measurement results? May it be possible that you just catch a (un)lucky > > canned oscillator and measure house numbers, since the "crash" frequency is > > totaly random. > > No, I vary the hp output frequency around 350 MHz. We have changed the > chip-internal design, giving us different interconnect delays, and the results > have moved accordingly. All very repeatable, albeit statistical. Maybe you should document this as 50Mhz[Xtal], and 350MHz+dF[Generator] - one problem with saying 50MHz and 350MHz is the (possible) inference of a x7 integer ratio. or quoting as : 50.000Mhz and 350.010MHz ? -jgArticle: 46821
What are the fundamental differences between Xilinx's CoolRunner XPLA3 and CoolRunner-II? And which family tends to use the least power?Article: 46822
Falk Brunner wrote: > In the "bible" of Graham & Johnson, there is a circuit for metastability > experiments. Why not using this one (or something similar). In my eyes, this > cicuit gives much more possibilities to do repeatable mesurements. With all due respect to Howard Johnson ( we know each other and have met twice ), his book is nine years old, and his examples are even older. Maybe he could successfully conduct such experiments when natural delays were 10 ns, and even longer in the case of TTL. Now we are talking about hundred picoseconds, and I see no way of balancing a circuit under these circumstances. And why even try to do it, when the statistical approach gives repeatable and justifyable results ? It worked in 1988 and 1995. Later I had a problem and got discouraged. Now, with much better clocking structures, we do it again. It's tough to argue against a successful set-up, isn't it? But, "this is a free country" and the chips are programmable. Anybody with minimal resources is capable to verify the results, or come up with a different set-up. I am amazed that some university hasn't done it already. I haven't heard from Washington U. (Dick Chaney) lately, they sure know a lot about metastability... Peter Alfke, Xilinx ApplicationsArticle: 46823
Xanatos wrote: > > Although I usually take press releases with a grain of salt, I have heard > lots of great things about Stratix and DSP...However, it seems like Altera > has a winner. > > http://biz.yahoo.com/prnews/020909/sfm036_3.html > > Looks great to me. Hmmm.... "Altera Stratix DSP Performance Increases Over 500 Percent Using Soft Multipliers" Wow, 500% PERFORMANCE!, now where's that grain of salt... Oh, here it is : "Using "soft" multipliers from Stratix(TM) TriMatrix(TM) memory structures, the number of high-performance multipliers in a Stratix FPGA can be increased up to 500 percent." and suddenly 'Performance' has morphed into 'number', and 'over' has morphed into 'up to' - and I see no mention of the fact that to even get to the quantity level, you consume all the on chip RAM. ( Real world deployment probability == zero ) Q: Does no one, with even a passing technical literacy, ever _read_ these press releases, before they are trotted out ? Now we know where the 'soap powder' copy writers go to die... -jgArticle: 46824
I used "roughly" and "about" for exactly that reason. And I assumed people would give me the benefit of the doubt that I have not (yet) gone completely senile. :-) The grey cells are still working under their grey cover. Have fun, life is too short to be taken seriously! More data soon (on metastability, that is...) Ciao Peter Jim Granville wrote: > Maybe you should document this as 50Mhz[Xtal], and 350MHz+dF[Generator] > - one problem with saying 50MHz and 350MHz is the (possible) > inference of a x7 integer ratio. > > or quoting as : 50.000Mhz and 350.010MHz ? > > -jg
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