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
You can ignore this unless you are posting HTML to this (or other) news groups, or you are using the Xilinx gateway and you are un-aware that it is turning your nice text messages into crappy HTML. (Stewart, this would have been private email, but you have successfully de-spammed your email address, so I can't send this to you privately) You have posted articles to comp.arch.fpga via the Xilinx gateway to this news group. Unfortunately, this gateway mistakenly allows HTML posting, and even turns text postings into HTML. For all news groups, including comp.arch.fpga, the format is supposed to be text only. I have advised Xilinx about this problem, which they have said they will fix, but no schedule. This concerns me for 2 reasons. First, many other users of comp.arch.fpga either can't read your postings, or it is a pain, and secondly, I maintain the archive of this news group at www.fpga-faq.com and I have to spend several hours each month cleaning up the mess that is caused by HTML posts. An alternative free system that will allow you to read and post articles to comp.arch.fpga and that does not have this problem is the gateway provided by Google, which also maintains archives (for all news groups) in text form only. (The archive for this news group at google should have the same content as the one I maintain, but mine has nicer indices and threading by author, topic, and date) You can use google starting from the following page: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&group=comp.arch.fpga There is a link in the top right corner for posting. You may have to create an identity before posting, but that is free too. Thanks Philip Freidin =================== Philip Freidin philip@fliptronics.com Host for WWW.FPGA-FAQ.COMArticle: 56326
I recently downloaded the NIOS GNU source distribution (nios_gnupro_sources_010801). However, when I try to configure the cross compiler etc. I get: ../src/configure --prefix=/usr/local/nios --target=nios-unknown-elf ... checking host system type... i686-pc-linux-gnu checking target system type... nios-unknown-elf checking build system type... i686-pc-linux-gnu ... Configuring bfd... './../src/bfd/configure: line 80: syntax error near unexpected token `do './../src/bfd/configure: line 80: `do Configure in /usr/petter/to-install/nios_gnupro_sources_010801/build/bfd failed, exiting. Did anybody build this release successfully? What is the correct target name to use for the --target option, nios-unknown-elf was simply an educated guess... Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 56327
Is there any free online course available for FPGA using xilinx? In case of not free, how much it costs? Regards AtifArticle: 56328
Austin, I´m not complaining, just trying to undestand. Göran already explained the reason (RAM32X1D). I agree with you that a low power low speed part has a larger market but, SPARTAN3 is 2 CMOS generations ahead SPARTAN2E, so I expected it to be more than 13% faster (85 versus 75MHz). I'm aware of the problems with leakage current at the 90nm node, but I want to see how faster VIRTEX3 will be than the "old" VIRTEX2-PRO! And Austin, we want lots of logic, very fast parts and extremely low prices, and it's your job to bring them for us. :) Luiz Carlos KHOMP Solutions Austin Lesea <Austin.Lesea@xilinx.com> wrote in message news:<3EDB61B3.427E3823@xilinx.com>... > Luiz, > > As for the speed, one has to design to balance leakage current, and speed > with the latest technologies. There is a larger market for a Spartan 3 > that is less fast enough, and less power, than for a Spartan 3 that is > really fast, and has more power. > > Also, if you want the speed, there is Virtex II Pro. > > AustinArticle: 56329
"Ben Jackson" <ben@ben.com> wrote in message news:JSXCa.846692$Zo.194125@sccrnsc03... > In article <J0UCa.26060$DV.41038@rwcrnsc52.ops.asp.att.net>, > David Kinsell <kinsell@poboxyz.com> wrote: > > > >The P-III cable is marked 5 volt only, so I just assumed the 3.3 > >volts at the JTAG connector wasn't enough. But I see an Answer > >Record 8096 saying it should work at 5, 3.3, and 2.5 volts. > > Depends on how you build it. It calls for 74HC125 tristate buffers > behind a 1N5817. About 0.3V drop across the diode, so a system supply > of 2.5V-.3V = 2.2V which is within the range (at least of the Fairchild > part) of 2.0V to 5.5V. Maybe there's an issue reading those low voltage > signals at the parallel port? If I'd thought of that myself I would > have arranged for the 125 on the read side to be powered from the parallel > port side somehow. > The schematic I've seen shows the buffers being powered off of Vdd, but then doesn't show a Vdd on the schematic. Assuming it's Vcc after going through the diode seems reasonable, but it's not on the schematic. I didn't build a cable, it's factory-built, later than the 5000 serial number, and clearly marked for use at 5 volts. I think powering it at 2.5 volts would provide very marginal drive capability for most parallel ports. Even when powering it with 5 volts, I've sometimes had to tack small caps across the TCK line in order to make it work reliably. That trick didn't work in the current situation, the software showed a dozen devices in the chain when there was only two. Dave KinsellArticle: 56330
Hi, The sequential block which generates the output signals will be written as below. case(1) // synthesis full_case preset_state[s0]: begin a <= 1'b1; end present_state[s1]: begin a <= 1'b0; end present_state[s2]: begin a <= a; end endcase In the above piece of code, signal a is getting varied only in S0 and S1. But in S2 it remains unchanged. My question is: this a <= a is reduntand assignment. But it is really required because we have put the case as full_case. Else, when this state comes the output may not be un known. Is this correct? Will any sythesis tool could generate error on this reduntant assignment. Regards, MuthuArticle: 56331
If a case statement is naturally exclusive, then it does imply a muxing function
whether you put a parallel_case directive there or not. If the case statement
entries are NOT exclusive, then it implies a priority decoder, not a mux function.
If your question is "Should we use parallel_case?", I say avoid it at all costs
but use it if you _really_ need to and are careful (i.e. use a lint tool,
equivalency checker, and gate sims). Using parallel_case on a case statement
that is NOT exclusive can cause functional mismatches between RTL and gates.
I only use it for decoding one-hot state machines.
Mark
Muthu wrote:
>
>
> Hi Mark,
>
> Nice explaination.
>
> My question is , Case doesn't imply MUX by default? Should we have
> synthesis directive //Parallel_case
>
> Regards,
> Muthu
Article: 56332Are they the same ?Article: 56333
"rickman" <spamgoeshere4@yahoo.com> wrote in message news:3ED3A6C7.229A5223@yahoo.com... > I am finding JTAG to be a major hassle to try to use for both debug and > production boundary scan. Seems there are conflicting requirements > which the two camps are not generally interested in dealing with. > > The biggest problem is the fact that a lot of debugger tools don't like > having anything extra in the scan path. I have never gotten a clear > answer from TI about this on their DSPs. They have lots of app notes > telling you how to do it, the software has hooks for describing the > other devices, but support tells me not to try! I have not looked into > the issue with the ARM tools yet. > [---] In the past I have done a board with the TI DSP and a CPLD in chain. There were some problems at the beginning to configure the debugger but later it worked OK. I have also a board with two SHARCs and few CPLDs and FPGAs in series and everything works OK. But for now I prefer separate connectors: one for the processor and one for the CPLD/FPGA. With two connectors you can have connected both the processor emulator and the FPGA/CLPD programmer at the same time. This speeds up the debugging because you have both the hardware tool and software tools ready and can quickly update the H/W and S/W. Dz.Article: 56334
Hi Peter. I also think that encryption would be a very popular feature for SPARTAN devices. But I think it will be more usefull if we could program the decryption key in a non volatile memory, like PROM. It doesn't need to be erasable! So we could buy the FPGAs, program the decryption key, and sell them to our customers with the encrypted bitstream. Today, we only sell complete boards where we put at least one CPLD as hard-lock to try to protect our IP. Who more else can help us to make XILINX change it's mind? Luiz Carlos KHOMP Solutions Peter Alfke <peter@xilinx.com> wrote in message news:<3EDB8423.29CA2C46@xilinx.com>... > It's really quite simple: > The priorities for Spartan are: Low cost first, features and speed second. > For Virtex the priorities are reversed. > Makes a lot of sense, avoids unproductive overlap, and gives the user a > fair choice. Cheap or fancy. There is no free lunch... > > Now, if encryption were a popular feature in the low-cost market (please > tell us), then it would make sense to dedicate some silicon and a pin > for the on-chip decryption. > > Peter AlfkeArticle: 56336
Hi,
I want to build a memory using register array. I tried as below.
//----------------------------
reg[31:0] mem[DEPTH-1:0];
// Read LOGIC
always @(posedge clk or negedge rst_n)
begin
if(!rst_n)
begin
dout <= 0;
end
else
begin
for(i=0; i<DEPTH ; i=i+1)
begin
if(raddr == i)
begin
dout <= mem[i];
end
end
end
end
// Write LOGIC
always @(posedge clk or negedge rst_n)
begin
if(!rst_n)
begin
for(j=0; j<DEPTH; j=j+1)
begin
mem[j] <= 0;
end
end
else
begin
if(we)
begin
for(k=0; k<DEPTH; k=k+1)
begin
if(waddr == i)
begin
mem[i] <= din;
end
end
end
end
end
---------------------------
In the above Piece of code is not inferring all the register elements
for memroy. It is replacing registers by LOGIC, since it is
unchanging.
How do i code a memory using register array, which could be
parameterized. So, for-loop option could be better. But it is not
giving the desired result.
Regards,
Muthu
Article: 56338Hello, Can anyone tell me dimensions of FPGA programming elements like SRAMs, antifuses or EPROMs? How big are the differences in size between them?Article: 56339
Rick, Good points. We will takle one at a time. We reported one time a "red ink" which was a write down of property owned in San Jose. No money went anywhere, just the feds require that we value our investments, and when the investments would lose money (if we sold it) then you have to remove it from the bottom line. As I said, no real loss (until we sell the building, but that may be ten years from now). Of course, then we will have to show the profit on the building. Actual cash, always +. As for the stock dropping, whose did not? 90 to where it is now ~30 is pretty good. Just think if you had your retirement in the network folks, phone companies? Or maybe Enron? MCI/Worldcom? As for smug, GUILTY as charged. Can't help but feel good when you are winning. Have to fight it all day long. Tough when > 90% of the new sockets are ours. The last thing we are smug about is our products and services: we have to be the best, and invent the best, otherwise we might let competition gain market share. Competition? Yes. There are lots of folks. We keep our eyes on what they are doing, and how they position themselves. We carefully watch where the sockets go. So do they. Uneven? We compare the latest technology node with what we are doing obviously because it is the best comparison. No secret there. But if you want to design in 0.25u or 0.18 u(still pretty expensive there! and three years old) when you could have the latest and best technology (MGTs, PPC, etc.) in 0.13u, or 0.09u, what are you doing? No differentiation? Anyone can make that product for that price.... A long time ago I learned that if I used the best and latest technology I get a free ride down the cost curve to success. If I choose a nice old comfortable technology that is already discounted, I have no room to respond when my competition drops their prices (or my customer demands that I lower my price). Or they introduce the latest and greatest using reprogrammable FPGAs.....oh damn out of business again! And there is no argument anymore from the ASIC folks. We get their resumes in the mail by the boatloads. Even the industry acknolwedges the end of their era. Xiliinx does not even have to bring it up anymore, our customers do that for us. You think something is uneven? Happy to reply. No arguments, two sides to every coin. I see your points. Hope you see mine. Austin rickman wrote: > Austin Lesea wrote: > > > > Rick, > > > > Actually, the bonuses were good, the profit sharing adequate, and the fact > > that we had 0 layoffs, quite pleasant. > > > > Who else can say that they were: profitable, kept all of those inventive > > people happy, made lots of useful products for lots of customers (and sold > > them profitably), had no layoffs, and improved customer services, and > > introduced new products besides? > > > > No one. > > > > Sorry. Cheap shot on your part. But Peter is correct: the market decides, > > and it has voted overwhelming for our solutions. > > Sorry if you feel it was a cheap shot. But I felt that Peter's comment > was a cheap shot. As to the specifics of Xilinx economics, I can't seem > to get to any data at Yahoo at the moment so I can't speak from facts, > but I follow Xilinx stock and I remember seeing some pretty red ink > flowing over the last two years. Why else would the price drop from $90 > per share to under $15? > > As to the market, the fat lady has not sung. I like Xilinx products. I > think they are pretty good, although not perfect. But there are new > chips from the competion all the time and the competition is more than > just Altera. I am finding the new Lattice parts to be very, very > interesting. That does not take anything away from the advantages of > the Xilinx parts. But it does present some new options offered by no > one else that I can find. > > Sometimes I think the image projected here for Xilinx is a bit smug. I > am sorry if that offends you. I understand that your paycheck comes > from Xilinx and you are one of their biggest cheerleaders. But once in > awhile you and less often Peter cross a line when talking about the > competition. Boosting your products is one thing, but trying to tell us > what is wrong with the competition is not anyone's forte. Often I find > that the "facts" given in such a discussion are just plain wrong. > > A good example of of uneven comparison is the way that you often compare > the difficulty of making custom chips at current process technology vs. > buying FPGAs. This is apples to oranges since a given design that can > be done on an FPGA can be done on a chip much smaller on a process two > years old. The NRE of such a design will be much less than using > "current" technology and will still give a lower cost than FPGAs. I > have yet to see you reply to a posting which brings up these facts. > This is not germane to the issue discussed above, but illustrates my > point about uneven discussions. > > I don't wish to have an argument with you. I am just giving my > opinion. I hope you understand that. > > -- > > 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: 56340
Comments embedded: "rickman" <spamgoeshere4@yahoo.com> wrote in message news:3EDC3151.A1F6D88@yahoo.com... > Sorry if you feel it was a cheap shot. But I felt that Peter's comment > was a cheap shot. As to the specifics of Xilinx economics, I can't seem > to get to any data at Yahoo at the moment so I can't speak from facts, > but I follow Xilinx stock and I remember seeing some pretty red ink > flowing over the last two years. Why else would the price drop from $90 > per share to under $15? For the same reason that virtually all tech stocks went from high to low. I don't know of a single tech stock that did well through the "downfall." This whole "recession" thing can get in the way of high valuations. To keep sales steady or to increase during trying times like those is amazing. > As to the market, the fat lady has not sung. I like Xilinx products. I > think they are pretty good, although not perfect. But there are new > chips from the competion all the time and the competition is more than > just Altera. I am finding the new Lattice parts to be very, very > interesting. That does not take anything away from the advantages of > the Xilinx parts. But it does present some new options offered by no > one else that I can find. Options are great and I hope to find some exceptional price/performance offerings to earn a socket on my boards and to keep the big guys striving for the leading edge. > Sometimes I think the image projected here for Xilinx is a bit smug. I > am sorry if that offends you. I understand that your paycheck comes > from Xilinx and you are one of their biggest cheerleaders. But once in > awhile you and less often Peter cross a line when talking about the > competition. Boosting your products is one thing, but trying to tell us > what is wrong with the competition is not anyone's forte. Often I find > that the "facts" given in such a discussion are just plain wrong. Thankfully - in my own opinion, of course - these two professionals are pretty good about not taking cheap shots or passing seriously (or intentionally) misleading information. The "smug" may be a perception from the dominance the Xilinx devices have in discussions on this newsgroup. The market leader for any technology will tend to have much more traffic on a newsgroup dedicated to that technology. I personally love working with Xilinx parts even if I used to be a diehard Altera guy. > A good example of of uneven comparison is the way that you often compare > the difficulty of making custom chips at current process technology vs. > buying FPGAs. This is apples to oranges since a given design that can > be done on an FPGA can be done on a chip much smaller on a process two > years old. The NRE of such a design will be much less than using > "current" technology and will still give a lower cost than FPGAs. I > have yet to see you reply to a posting which brings up these facts. > This is not germane to the issue discussed above, but illustrates my > point about uneven discussions. Do you not believe that the difference between FPGA and custom chips has skewed from the reality of 5 years ago? If a designer still maintains the mindset that you have to go custom to get the right price based on the experience of years past, the opportunities to get the right overall price/performance value could be lost. It is a *much* cheaper NRE get a 0.25um custom chip than it is to get a 0.13um design but economies of scale allow 90nm technology to get into sockets in the form of an FPGA. Speeds of older technology custom chips can compare to the cutting edge FPGAs. Do you disagree? If you're pad limited, you still can't guarantee smaller silicon in the older device geometries so the price arguement can be skewed further by the pad-to-logic ratio. I appreciate that the issues with respect to ASIC vs. FPGA are discussed. I don't expect engineers to dismiss the custom approach becaue of what the "gurus" have stated but I expect the designers to reevaluate the tradeoffs of NRE and parts cost in the newer environment of rising NREs - a tradeoff that might not be reevaluated as rigorously without the discussions. > I don't wish to have an argument with you. I am just giving my > opinion. I hope you understand that. > > -- > > Rick "rickman" Collins Opinions are appreciated, but your reply earlier did seem like a "cheap shot." If you perceived Peter's comment to be a cheap shot, why retort with another? If you believe that stock price is the sole indicator of "a profitably growing sales volume" then your comment could be interpreted as not a cheap shot, but merely short-sighted. If you were to have the yahoo access you missed earlier and compare the stocks against each other, you'll see that over the last 5 years, XLNX has surpassed ALTR and LSCC. Over the last 2 years, ALTR and XLNX are pretty much neck-and-neck with LSCC lagging behind. ALTR has done better in the short term but LSCC continues to lag behind the big two in relative stock increase/decrease over time. - John_H, with more opinion.Article: 56341
Hi, I'm using the Convolutional Encoder IP core (ver 3.0) and I have a problem when the puncturing is employed. Infact, using the rate 1/2 I don't have any problem as in the following example: data IN: 0 1 0 1 1 1 0 1 1 1 1 1 1 .... data OUT: 0 0 1 1 0 1 1 0 0 0 0 1 0 1 0 0 1 0 0 0 1 1 1 0 1 1 1 0 0 1 0 1.... but if I apply the puncturing I obtain a wrong result: data OUT with puncturing: 0 0 1 0 1 0 0 1 0 0 1 0 1 0 0 0 1 1 1 1 1 1 1 0 ... in place of: 0 0 1 0 1 1 0 0 0 0 1 0 1 0 0... Solutions? Best Regards. VenexArticle: 56342
I do not have the numbers, but you also must understand that it is not just a matter of comparing square microns. Incorporating these additional technologies that inherently are not compatible with state- of-the-art main-stream CMOS, forces the whole fabrication process to be one or two generations behind, or crippled in some other way. You cannot optimize two parameters simultaneously, when they have conflicting demands. Just my $0.02 worth. Peter Alfke Wolfgang Schmiesing wrote: > > Hello, > > Can anyone tell me dimensions of FPGA programming elements like > SRAMs, antifuses or EPROMs? How big are the differences in size between them?Article: 56343
leon qin wrote: > Are they the same ? > > > they are different that SVF player accepts SVF files while stapl player accepts jam files.Article: 56344
Hi, I am getting this warning while synthesize my memory block which is written using register array. WARNING:Xst:738 - 256 flip-flops were inferred for signal <mem>. You may be trying to describe a RAM in a way that is incompatible with block and distributed RAM resources available on Xilinx devices, or with a specific template that is not supported. Please review the Xilinx resources documentation and the XST user manual for coding guidelines. Taking advantage of RAM resources will lead to improved device usage and reduced synthesis time. But, when i changed the coding style litte. I am not getting this warning. But when i am comparing the Resources in both approaches it is same. Then, what is really this warning talks. Regards, MuthuArticle: 56345
What is your desired code rate? You show 13 bits going in to the coder and you show your expected output having 15 bits. Does that mean you are puncturing for a 13/15 code rate? That's an unusual rate. How did you come up with your expected output? There are many puncturing matrices that yield the same punctured code rates, so what puncturing matrix are you using? -Kevin "Venex" <venexpal@hotmail.com> wrote in message news:ee7dca0.-1@WebX.sUN8CHnE... Hi, I'm using the Convolutional Encoder IP core (ver 3.0) and I have a problem when the puncturing is employed. Infact, using the rate 1/2 I don't have any problem as in the following example: data IN: 0 1 0 1 1 1 0 1 1 1 1 1 1 .... data OUT: 0 0 1 1 0 1 1 0 0 0 0 1 0 1 0 0 1 0 0 0 1 1 1 0 1 1 1 0 0 1 0 1.... but if I apply the puncturing I obtain a wrong result: data OUT with puncturing: 0 0 1 0 1 0 0 1 0 0 1 0 1 0 0 0 1 1 1 1 1 1 1 0 ... in place of: 0 0 1 0 1 1 0 0 0 0 1 0 1 0 0... Solutions? Best Regards. VenexArticle: 56346
Here are some answers: Spartan is low-cost driven and will only add silicon area for truly popular functionality. Once any function is added, everybody obviously has to pay for it, and that does not make sense when only a few designers might utilize this particular function. ( I know that there is a chicken-and-egg aspect to this). We obviously do not yet have a compatible, proven, reliable non-volatile storage solution. Of course we are still exploring the possibilities. Keep nagging us ! :-) Peter Alfke ==================== Luiz Carlos wrote: > > Hi Peter. > > I also think that encryption would be a very popular feature for > SPARTAN devices. > But I think it will be more usefull if we could program the decryption > key in a non volatile memory, like PROM. It doesn't need to be > erasable! > So we could buy the FPGAs, program the decryption key, and sell them > to our customers with the encrypted bitstream. > Today, we only sell complete boards where we put at least one CPLD as > hard-lock to try to protect our IP. > > Who more else can help us to make XILINX change it's mind? > > Luiz Carlos > KHOMP Solutions > > Peter Alfke <peter@xilinx.com> wrote in message news:<3EDB8423.29CA2C46@xilinx.com>... > > It's really quite simple: > > The priorities for Spartan are: Low cost first, features and speed second. > > For Virtex the priorities are reversed. > > Makes a lot of sense, avoids unproductive overlap, and gives the user a > > fair choice. Cheap or fancy. There is no free lunch... > > > > Now, if encryption were a popular feature in the low-cost market (please > > tell us), then it would make sense to dedicate some silicon and a pin > > for the on-chip decryption. > > > > Peter AlfkeArticle: 56347
I agree with Mark. parallel_case and full_case directives should be avoided in 99% of cases. They may easily cause rtl-gates simulation mismatches that are a nightmare to analyze. One of the cases when it is OK to use parallel_case is one hot state machines. Ljubisa Bajic ATI Technologies --- My opinion does not represent that of my employer --- Mark Schellhorn <mark@seawaynetworks.com> wrote in message news:<%71Da.4186$VS5.318946@news20.bellglobal.com>... > If a case statement is naturally exclusive, then it does imply a muxing function > whether you put a parallel_case directive there or not. If the case statement > entries are NOT exclusive, then it implies a priority decoder, not a mux function. > > If your question is "Should we use parallel_case?", I say avoid it at all costs > but use it if you _really_ need to and are careful (i.e. use a lint tool, > equivalency checker, and gate sims). Using parallel_case on a case statement > that is NOT exclusive can cause functional mismatches between RTL and gates. > > I only use it for decoding one-hot state machines. > > Mark > > Muthu wrote: > > > > > > Hi Mark, > > > > Nice explaination. > > > > My question is , Case doesn't imply MUX by default? Should we have > > synthesis directive //Parallel_case > > > > Regards, > > MuthuArticle: 56348
That is exactly what I did. SST did say they are coming back with an answer. We will see .. maybe there is a hidden door ... markus "Jim Granville" <jim.granville@designtools.co.nz> schrieb im Newsbeitrag news:3EDBCDDA.182D@designtools.co.nz... > Peter Wallace wrote: > > > > The SST 45LF010 (1Mb) has an all ones read command so it will connect with > > only one inverter as glue, alas it is the last of it kind, the later (and > > larger) 25 series parts have an 03 (ISTR) read command so they need a > > $.80 PIC or tiny CPLD helper, still cheaper than anything from X or A... > > > Markus Meng wrote: > > > > That's the way it is. I am jst wondering why SST or ST or others do not jump > > on this train by simply changing the command for the read array mode to > > something like all '0' and all '1'. > > They would not CHANGE the command, but there is certainly a > 'glaringly obvious' case for an ALIAS code of all 1's to > start a Read-all. > Besides system loaders, there are other applications that would > benefit from clock-only dump of the serial memory - trivial silicon > cost, for a bigger market footprint. > > Send an email to SST/ST/Atmel to suggest it ! > > -jgArticle: 56349
John_H wrote: > > Comments embedded: > > "rickman" <spamgoeshere4@yahoo.com> wrote in message > news:3EDC3151.A1F6D88@yahoo.com... > > Sorry if you feel it was a cheap shot. But I felt that Peter's comment > > was a cheap shot. As to the specifics of Xilinx economics, I can't seem > > to get to any data at Yahoo at the moment so I can't speak from facts, > > but I follow Xilinx stock and I remember seeing some pretty red ink > > flowing over the last two years. Why else would the price drop from $90 > > per share to under $15? > > For the same reason that virtually all tech stocks went from high to low. I > don't know of a single tech stock that did well through the "downfall." > This whole "recession" thing can get in the way of high valuations. To keep > sales steady or to increase during trying times like those is amazing. I lost quite a few bucks in most of my investments over the last two years, but my biggest holding has doubled, no tripled in that time. Many would consider it to be a defence stock. But in reality it is as much high tech as any, APSG. I bought a bunch at under $4. It is over $16 today. > > As to the market, the fat lady has not sung. I like Xilinx products. I > > think they are pretty good, although not perfect. But there are new > > chips from the competion all the time and the competition is more than > > just Altera. I am finding the new Lattice parts to be very, very > > interesting. That does not take anything away from the advantages of > > the Xilinx parts. But it does present some new options offered by no > > one else that I can find. > > Options are great and I hope to find some exceptional price/performance > offerings to earn a socket on my boards and to keep the big guys striving > for the leading edge. > > > Sometimes I think the image projected here for Xilinx is a bit smug. I > > am sorry if that offends you. I understand that your paycheck comes > > from Xilinx and you are one of their biggest cheerleaders. But once in > > awhile you and less often Peter cross a line when talking about the > > competition. Boosting your products is one thing, but trying to tell us > > what is wrong with the competition is not anyone's forte. Often I find > > that the "facts" given in such a discussion are just plain wrong. > > Thankfully - in my own opinion, of course - these two professionals are > pretty good about not taking cheap shots or passing seriously (or > intentionally) misleading information. The "smug" may be a perception from > the dominance the Xilinx devices have in discussions on this newsgroup. The > market leader for any technology will tend to have much more traffic on a > newsgroup dedicated to that technology. I personally love working with > Xilinx parts even if I used to be a diehard Altera guy. I think Peter is very good at being professional. But claiming that the competition's technology *must* be inferior because the company is not doing well is just plain silly. That is like saying that WDM is a *poor* technology because the suppliers are doing poorly. I guess I got a bit irritated from seeing so many postings from Xilinx claiming that they in essence *own* the PLD market. They get their share of design wins, but they seem to feel they are alone in the market place. I find this sort of smugness offensive. Most likely I should just ignore it since it means nothing. When they started trashing the competition, and in this case in spite of the facts, I let it push a button. I see new flash parts from Lattice taking sockets away from Xilinx and Altera FPGAs. Lucent competed with X and A in the big telecom customers. I don't know how sucessful they were. Now that Lattice owns the technology, they are working on the rest of the market. I fully expect the FPGA market to be a three way tie in a few years (X, A and L) compared to the current two way tie (X and A). > > A good example of of uneven comparison is the way that you often compare > > the difficulty of making custom chips at current process technology vs. > > buying FPGAs. This is apples to oranges since a given design that can > > be done on an FPGA can be done on a chip much smaller on a process two > > years old. The NRE of such a design will be much less than using > > "current" technology and will still give a lower cost than FPGAs. I > > have yet to see you reply to a posting which brings up these facts. > > This is not germane to the issue discussed above, but illustrates my > > point about uneven discussions. > > Do you not believe that the difference between FPGA and custom chips has > skewed from the reality of 5 years ago? If a designer still maintains the > mindset that you have to go custom to get the right price based on the > experience of years past, the opportunities to get the right overall > price/performance value could be lost. It is a *much* cheaper NRE get a > 0.25um custom chip than it is to get a 0.13um design but economies of scale > allow 90nm technology to get into sockets in the form of an FPGA. Speeds of > older technology custom chips can compare to the cutting edge FPGAs. Do you > disagree? If you're pad limited, you still can't guarantee smaller silicon > in the older device geometries so the price arguement can be skewed further > by the pad-to-logic ratio. I think that it is silly to compare a 90 nm FPGA to a 90 nm ASIC. The design I can fit in a 90 nm FPGA can easily be done in a 250 nm ASIC. That is the fact of the inefficiency of silicon when you implement a logic gate with SRAM and MUXes. I also think it is silly to argue that ASICs can't cut it because Xilinx received resumes from ASIC designers. I still see lots of job openings for ASIC designers. I don't think they are deserting the field in droves. The entire digital engineering market is shrinking and people are scrambling for any job they can get. It might be better to suggest that engineers talk to their representatives in Washington about not renewing the H1B vias. Then we can expect to see the employment market return to a more normal state. I don't have numbers for what process can run at what speed. I do know that a design in an FPGA is much slower and uses lots more silicon than a custom design even a couple of process revs back. Otherwise there would be *no* market for ASICs other than at Intel. > I appreciate that the issues with respect to ASIC vs. FPGA are discussed. I > don't expect engineers to dismiss the custom approach becaue of what the > "gurus" have stated but I expect the designers to reevaluate the tradeoffs > of NRE and parts cost in the newer environment of rising NREs - a tradeoff > that might not be reevaluated as rigorously without the discussions. Discussions are fine. But with some posters, the facts are used for marketing, not discussion. Have you not noticed that some posters never reply to posts in a thead that have too many facts they can't dispute? Or they reply, but ignore the facts that don't support their point of view? > > I don't wish to have an argument with you. I am just giving my > > opinion. I hope you understand that. > > > > -- > > > > Rick "rickman" Collins > > Opinions are appreciated, but your reply earlier did seem like a "cheap > shot." If you perceived Peter's comment to be a cheap shot, why retort with > another? If you believe that stock price is the sole indicator of "a > profitably growing sales volume" then your comment could be interpreted as > not a cheap shot, but merely short-sighted. If you were to have the yahoo > access you missed earlier and compare the stocks against each other, you'll > see that over the last 5 years, XLNX has surpassed ALTR and LSCC. Over the > last 2 years, ALTR and XLNX are pretty much neck-and-neck with LSCC lagging > behind. ALTR has done better in the short term but LSCC continues to lag > behind the big two in relative stock increase/decrease over time. I aplogize if my comments seemed like a cheap shot. But I felt I was responding in kind to Peter's comment. Peter said a new technology was bad because it came from a company that is hurting in the stock market. Of course this is silly and a non-sequitur. My point was that Xilinx is not doing well either. A lot of their stock holders lost some 80% of their investment in the company. Does that mean that their products are bad, no, of course not. Two years ago the Xilinx price was very over inflated which was not obvious because of various factors. When the facts came out about "one time write offs" and the general semi market started falling apart, Xilinx fell just as their competitors did. This has nothing to do with the usefulness of their products. I use Xilinx products and will continue to use them. My point about the stock price was simply that Xilinx is no investment queen. So it was a cheap shot for them to start denigrating their competition over their "success" in the market. -- 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
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