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
What you say is: CPLD is not good/cost-efficient for simple solution. "Simon Peacock" <nowhere@to.be.found> wrote in message news:<416e1e2a@news.actrix.gen.nz>... > that's as good as you can get.. unless you buy 1/2 a million > > "Zimmer" <zihu882@yahoo.com> wrote in message > news:65a3fa49.0410131936.2bdeb565@posting.google.com... > > Hi Everyone, > > > > Can anybody let me know where to buy the EPM1270 TQFP CPLD in a cheap > > price? I've checked altera.com, the online wholesale price is $4.25/pc > > for 500K units. But the distributor here would charge me over $24 for 10 > > pc. (ebay.com is not a good site for the stable supply) > > > > Any advice appreciated! > > > > -ZimmerArticle: 74576
"Zimmer" <zihu882@yahoo.com> wrote in message news:65a3fa49.0410140701.4dd39773@posting.google.com... > What you say is: CPLD is not good/cost-efficient for simple solution. Can you find a cheaper device for your "simple" function? How about the EPM240? At 240 LCells, it's gonna be a whole lot cheaper. Are you only interested in buying 10 pieces? Suck it up and lay out the money! If you want more, then contact your sales rep or distributor and talk volume and price. Sometimes they'll shave a little off their margin if they can get the socket. It's the way it goes in the semiconductor business.Article: 74577
Here is a response to this inquiry on Xilinx 64-bit support so that there is no misunderstanding about it however I must first give the disclaimer that plans can and do change so this information may not follow exactly how things will get rolled out. I am also not going to claim to be an expert in operating systems so some of the information here may be incorrect so take what you hear here with a grain of salt as they say. One last thing, the main motivation to going to 64-bit is not really speed but more memory space (not sure if everyone understands this). 32-bit limits you to 4 Gigs of memory space which for the larger and more complex FPGAs, is starting to "bump its head" on this memory limit for all phases of design. In the past, significant speed gains has not been seen by moving from 32-bit to 64-bit and many times the opposite has been seen as well as memory requirements can be raised. This is not to say that things can not or will not be faster when working on 64-bit systems/OS/software but to set a realistic expectation, I would not count on it. At this point and time, I would suggest to look for a 64-bit OS and applications mainly if you expect to need the more memory space, rather than trying to buy additional speed of processing. The memory space is a for sure thing, the speed is not so sure. Place & route and other algorithms have got smarter when it comes to memory usage and Linux is better (requires less) memory than Windows Operating system to run our software and we have been able to increase the memory ceiling from 2 GB to 3 GB to 4 GB however at the same time FPGAs continue to grow significantly from family to family and soon if not already will outgrow the limits of a 32-bit system. The current released version of the software, ISE 6.3 is all 32-bit however there is an internal 64-bit version for Solaris that can be released upon request. The 64-bit version can be slower and consume more memory than the 32-bit version and since the 32-bit version of Solaris can allocate 4 Gigs to applications, we have found that it is not necessary for all but the rarest of occasions an thus have held on to it. As for Linux, as mentioned, the current version is 32-bit. How much memory that can be allocated to it depends on the Linux kernel. Some 32-bit Linux distribution kernels by default allocate 2 GB to applications, other 3 GB (RHEL allocates 3 GB). 32-bit Linux kernels can also be reconfigured to allocate over 3 Gigs but generally do not come "out of the box" that way. If you have a 64-bit version of Linux and run the current 32-bit ISE application, then you generally get a full 4 GB of memory space as you do for Solaris. Similarly, this is generally more than enough for most current FPGA targets in most situations. A native 64-bit version of ISE for Linux Red Hat Enterprise Edition is intended to be released in the 7.1i software. It will support the Opteron processor with support for the Intel Xeon-64 pending. Speed and memory characteristics are yet to be determined so I can not comment on that yet however there should be a seemingly unlimited memory space available to that version. How much memory you can have will more be determined on what the hardware and your wallet can support than the OS and ISE software. That software is due out the first quarter of next year. In following releases, Windows 64-bit support can be expected likely on the same processors as the Linux support. -- Brian General Schvantzkoph wrote: > On Wed, 06 Oct 2004 15:08:00 -0400, Geoffrey Wall wrote: > > >>does any one know if there is a 64 bit windows or linux version of xilinx >>ISE available? >> >> >>thanks >> >>Geoffrey Wall >>Masters Student in Electrical/Computer Engineering >>Florida State University, FAMU/FSU College of Engineering >>wallge@eng.fsu.edu >>Cell Phone: >>850.339.4157 >> >>ECE Machine Intelligence Lab >>http://www.eng.fsu.edu/mil >>MIL Office Phone: >>850.410.6145 >> >>Center for Applied Vision and Imaging Science >>http://cavis.fsu.edu/ >>CAVIS Office Phone: >>850.645.2257 > > > I'm surprised that no one from Xilinx has answered this question. Early > last year, when 6.1 was in the works, I was told by someone at Xilinx that > they were holding off the Linux native version until they had a 64 > version. Obviously that didn't happen, the current version is Linux native > but not 64 bit (unless the Solaris version is 64 bit, does anyone know?). > I would expect that the 7.1 release will probably have 64 bit support now > that AMD64s are common. The memory requirements for routing the largest > V4s must be bumping up against the 32 bit limit unless they've gotten much > smarter with their routing algorithms (which they may have). Only map and > par need to be ported to 64 bits so the job shouldn't be that hard. >Article: 74578
A good source for 1-10ea components is
http://www.digikey.com/
But they only have atmel, cypress, xilinx
If you want a stable supply, check price and
distribution before you design in the part.
-- Mike Treseler
Article: 74579> Hi Everyone, > > Can anybody let me know where to buy the EPM1270 TQFP CPLD in a cheap > price? I've checked altera.com, the online wholesale price is $4.25/pc > for 500K units. But the distributor here would charge me over $24 for 10 > pc. (ebay.com is not a good site for the stable supply) Always the same story!!! > Any advice appreciated! > > -Zimmer Use an FPGA. Luiz Carlos.Article: 74580
I would like to read about any details on the Xilinx Image Processing FPGA which is mentioned in the below press release. Does anybody know what Xilinx has planned ? Related press releases below: [external] Toshiba to make image-processing chips for U.S. firm Xilinx http://www.forbes.com/technology/feeds/infoimaging/2004/10/14/infoimagingcomtex_2004_10_14_ky_0000-104128-3rdleadtoshiba-us.html?partner=yahoo&referrer= http://www.xilinx.com/prs_rls/xil_corp/04112toshiba.htmArticle: 74581
Hi Adarsh, If you are driving either of the Comma Alignment inputs on the MGT, make sure follow the guidelines for phase aligning your signals to the MGT from Chapter 2 of the RocketIO Transceiver user guide (p67 in the version I keep on my desk). In my experience, if the comma align signals are used but not phase aligned correctly, the resulting timing problems can make device behavior change from MGT to MGT. If you need an example, try downloading the Aurora reference design for Core Generator and take a look at the phase_align module and the corresponding constraints in the ucf file. You can get to it by going to www.xilinx.com/aurora. If this isn't your problem, you'll probably want to look at all the usual culprits for flaky Transceiver behavior: power supply noise, too much jitter on reference clocks and incorrect coupling/termination. Failing that, you should be on the lookout for accidental asynchronous design. Regards, Nigel Adarsh Kumar Jain wrote: > Hello All, > Another question for the Gurus. > Besides the fact that each device is unique and has a "mind (or body or > whatever !) of its own, what do you think could be other possible causes for > the same bitstream behaving differently in different devices ? > I have a board which has 9 Xilinx V2P7s and all of them are identical in > function. I configure all of them with the same configuration file. But when > i test them, some of them behave differently than the others.(5 are perfect > and 3 have problems, for example). > I use all 8 Rocket IOs on each of the 9 devices. My refclk is 80 MHz, > userclk is 40 MHz and we are running at 800Mbps on our differential inputs. > Our system clock is 40 MHz and so I would like to think that we are not > really in the "high speed" domain. I don't see any timing violations. > Am I just getting lucky with the 5 devices or unlucky with the 3 ? > What are the chances of this being an external problem vis-a-vis and > internal one ? > We have been in a tough loop for a long time. > The board also has, besides the Xilinxs, a couple of Stratix devices, a VME > interface, Memories, Transcievers and a few other ICs. So the source of > problems could be potentially a lot of things. > Any similar experiences/suggestions/solutions ? > Thanks in advance, > Adarsh > >Article: 74582
Hi. I've used the ONSEMI's NCP565D2T to generate 1.2V for Spartan-3. It has the 0.9V Vref and costs $0.457. Good luck. "John_H" <johnhandwork@mail.com> wrote in message news:<L3dbd.10$vk2.1566@news-west.eli.net>... > "colin" <colin_toogood@yahoo.com> wrote in message > news:885a4a4a.0410130836.783072db@posting.google.com... > > Hi > > > > Does anyone know the cheapest way to generate the 1.2V needed for > > spartan3. All the linear regs that say they go down to 1.2 have a vref > > that is 1.2 to 1.3V. All I can think is that the leakage on the adj > > pin when it is grounded makes some difference or that 1.2 is the > > marketing b*ll. > > > > Colin > > Do you not believe that the linear regulators that supply sub-1.245V are > producing the results you see in the data sheet graphs? > > After a 12 second search, the $0.19 National LMS5258 is limited to 150mA > (you didn't specify your current needs or your Spartan-3 size) but has full > documentation on current versus voltage. You should be able to find many > devices out there that fit your needs, whatever they may happen to be.Article: 74583
Dan DeConinck of PixelSmart wrote: > I would like to read about any details on the Xilinx Image Processing FPGA > which is mentioned in the below press release. > > Does anybody know what Xilinx has planned ? > > > Related press releases below: > > [external] Toshiba to make image-processing chips for U.S. firm Xilinx > http://www.forbes.com/technology/feeds/infoimaging/2004/10/14/infoimagingcomtex_2004_10_14_ky_0000-104128-3rdleadtoshiba-us.html?partner=yahoo&referrer= > > http://www.xilinx.com/prs_rls/xil_corp/04112toshiba.htm As I understand it, this article just mentioned FPGA and Devices which have image processing capabilities. Doesn't mean, there are new FPGA to expect with image processing capabilities ... " production of FPGA chips, which are used in such products as TV sets and mobile computerized terminals with image-processing features." And, there is nothing about imaging in the xilinx article ... So, for you, it is same busines as usual ;-) just my .0002Article: 74584
On Thu, 14 Oct 2004 09:51:51 -0600, Brian Philofsky wrote: > > > Here is a response to this inquiry on Xilinx 64-bit support so that > there is no misunderstanding about it however I must first give the > disclaimer that plans can and do change so this information may not > follow exactly how things will get rolled out. I am also not going to > claim to be an expert in operating systems so some of the information > here may be incorrect so take what you hear here with a grain of salt as > they say. One last thing, the main motivation to going to 64-bit is not > really speed but more memory space (not sure if everyone understands > this). 32-bit limits you to 4 Gigs of memory space which for the larger > and more complex FPGAs, is starting to "bump its head" on this memory > limit for all phases of design. In the past, significant speed gains > has not been seen by moving from 32-bit to 64-bit and many times the > opposite has been seen as well as memory requirements can be raised. > This is not to say that things can not or will not be faster when > working on 64-bit systems/OS/software but to set a realistic > expectation, I would not count on it. At this point and time, I would > suggest to look for a 64-bit OS and applications mainly if you expect to > need the more memory space, rather than trying to buy additional speed > of processing. The memory space is a for sure thing, the speed is not > so sure. Place & route and other algorithms have got smarter when it > comes to memory usage and Linux is better (requires less) memory than > Windows Operating system to run our software and we have been able to > increase the memory ceiling from 2 GB to 3 GB to 4 GB however at the > same time FPGAs continue to grow significantly from family to family and > soon if not already will outgrow the limits of a 32-bit system. > > The current released version of the software, ISE 6.3 is all 32-bit > however there is an internal 64-bit version for Solaris that can be > released upon request. The 64-bit version can be slower and consume > more memory than the 32-bit version and since the 32-bit version of > Solaris can allocate 4 Gigs to applications, we have found that it is > not necessary for all but the rarest of occasions an thus have held on > to it. As for Linux, as mentioned, the current version is 32-bit. How > much memory that can be allocated to it depends on the Linux kernel. > Some 32-bit Linux distribution kernels by default allocate 2 GB to > applications, other 3 GB (RHEL allocates 3 GB). 32-bit Linux kernels > can also be reconfigured to allocate over 3 Gigs but generally do not > come "out of the box" that way. If you have a 64-bit version of Linux > and run the current 32-bit ISE application, then you generally get a > full 4 GB of memory space as you do for Solaris. Similarly, this is > generally more than enough for most current FPGA targets in most > situations. A native 64-bit version of ISE for Linux Red Hat Enterprise > Edition is intended to be released in the 7.1i software. It will > support the Opteron processor with support for the Intel Xeon-64 > pending. Speed and memory characteristics are yet to be determined so I > can not comment on that yet however there should be a seemingly > unlimited memory space available to that version. How much memory you > can have will more be determined on what the hardware and your wallet > can support than the OS and ISE software. That software is due out the > first quarter of next year. In following releases, Windows 64-bit > support can be expected likely on the same processors as the Linux support. > > -- Brian Do you know if they are using GCC or are they using the Pathscale compilers? The Pathscale compilers should give much better results for the AMD64 architecture.Article: 74585
General Schvantzkoph wrote: > On Thu, 14 Oct 2004 09:51:51 -0600, Brian Philofsky wrote: ... >>situations. A native 64-bit version of ISE for Linux Red Hat Enterprise ... > Do you know if they are using GCC or are they using the Pathscale > compilers? The Pathscale compilers should give much better results for the > AMD64 architecture. For floating point code, yes. Not so much integer code. Mapping, P&R, etc are all pure integer workloads. TommyArticle: 74586
I need to send a couple signals across a clock boundary (27 MHz to 36 MHz) so I put in a pipeline for each signal to take care of metastability (in Verilog):
input CLK36, RSTn;
input x1, x2, x3;
output x1_buf, x2_buf, x3_buf;
reg [3:0] pipe1, pipe2, pipe3;
reg x1_buf, x2_buf, x3_buf;
always @ (negedge RSTn or posedge CLK36)
if (!RSTn)
begin
pipe1 <= 0;
pipe2 <= 0;
pipe3 <= 0;
x1_buf <= 0;
x2_buf <= 0;
x3_buf <= 0;
end
else
begin
pipe1 <= {pipe1[2:0],x1};
pipe2 <= {pipe2[2:0],x2};
pipe3 <= {pipe3[2:0],x3};
x1_buf <= pipe1[3];
x2_buf <= pipe2[3];
x3_buf <= pipe3[3];
end
Pretty simple. If I use x1_buf, x2_buf, and x3_buf the circuit doesn't work -- these signals are enables to clock data from the processor into some registers, and the registers never get updated. Worse, the board sometimes draws about twice as much power as it's supposed to. If I get rid of this entire section of code and just use x1, x2, and x3 without anything to take care of the clock boundary everything works fine, but you never know the circuit might work intermittently because of metastability.
What's up with that?
I'm using Xilinx Foundation, and the synthesizer has a warning saying I should get rid of the reset circuitry so I can use an SRL16 but that's all I could see that could be wrong.
Article: 74587<Chris> wrote in message news:ee89805.-1@webx.sUN8CHnE... > I need to send a couple signals across a clock boundary (27 MHz to 36 MHz) so I put in a pipeline for each signal to take care of metastability (in Verilog): > [snip] > > Pretty simple. If I use x1_buf, x2_buf, and x3_buf the circuit doesn't work -- these signals are enables to clock data from the processor into some registers, and the registers never get updated. Worse, the board sometimes draws about twice as much power as it's supposed to. If I get rid of this entire section of code and just use x1, x2, and x3 without anything to take care of the clock boundary everything works fine, but you never know the circuit might work intermittently because of metastability. > > What's up with that? [snip] It may look simple but you may be expecting all 12 bits of data to show up at the same 36MHz clock edge. It won't. One solution is to use one signal that goes through the metastability pipe to select *which* of two differently delayed version of the data to use. A properly designed FIFO is the general solution to this problem. Please check out Peter Alfke's TechXclusive article on crossing time domains for ideas: (short version) http://tinyurl.com/4q79k (long version) http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?sGlobalNavPick=&sSecondaryNavPick=&category=&iLanguageID=1&multPartNum=1&sTechX_ID=pa_clock_bound&lan guageID=1Article: 74588
IIRC, with "IOPin <= 'Z';", typically, when one implements the design, the Xilinx tools will optimize out the IOPin signal (XST?). You might even get a UCF error saying it cannot find IOPin in the design if the IOPin is defined in the UCF. "Falk Brunner" <Falk.Brunner@gmx.de> wrote in message news:<2t5m92F1r90atU1@uni-berlin.de>... > "Urban Stadler" <u.stadler@pfeilheim.sth.ac.at> schrieb im Newsbeitrag > news:416da060$0$8024$3b214f66@usenet.univie.ac.at... > > hi > > > > i have the following question: > > > > i'm using a spartan 3 and was wondering if it is possible to set an io pin > > to tristate. > > is this possible by using the following vhdl command " IOPin <= 'Z'; " ? > > Yes. > > Regards > FalkArticle: 74589
I see what you mean, but I don't think I explained my problem clearly enough. My processor runs at 27 MHz and it needs to set a couple registers in the FPGA that runs at 36 MHz. The processor sets the 8-bit data and 8-bit address and then a little later sets a flag high. By this time the data and address have been stable for numerous clock cycles (of both the 27 and the 36 MHz clock) so there's no metastability problem on either of them. In order to clock them in, the processor sets another signal high, for instance x1 in the code above. I'm not in a big hurry here so I ran it through some registers to take care of the metastability, otherwise I might look into a dual-port FIFO or something. I should get something like this: 27 MHz x1 000000011111111111000000000 36 Mhz pipe1[0] 00000000xx111111111xx000000 36 MHz x1_buf 000000000000111111111111000 The data and address are stable long before x1 goes high and long after x1_buf should go low. I'm not concerned about speed, all I care about is that x1_buf has no metastability, which it shouldn't. I've done stuff like this before and it worked fine, but in this case it didn't work at all.Article: 74590
Xilinx and Stratix on the same board?!?!?? ;)Article: 74591
Arash Salarian wrote: > > "rickman" <spamgoeshere4@yahoo.com> wrote in message > news:416E1A9B.35BCC6F2@yahoo.com... > > > I belive there is a pretty good Spartan 3 dev board available for $99 > > that Xilinx supports (XC3S200 vs. XC3S400). I don't know of any that > > cheap from Altera. > > > > Altera's evaluation board is $99 but it includes XC3S400 while the board > from the Xilinx is XC3S200 (though, personally I think the cyclone version > is better because the FPGA has more resources than XC3S400). You can the > Altera's board with the free version of the development software from Xilinx > or Altera so I think this is an interesting offer. I think you are confusing Altium with Altera. I have not been able to confirm that the Altium board is usable without the Altium software (demo version has a 30 day license only). There are JTAG ports on the board, but the use a connector for the PC parallel port. I also don't understand why there are *two* of them, soft and hard. > Btw, Rickman, you asked me about a direct link for the technical docs of the > Altera's boards. I found it and that is it: > http://www.dxpcentral.com/LiveDesign/default.asp Yes, after nosing around on the web site I called Altium and they pointed me to the manual. But this still does not answer a lot of my questions. But it does show the user IO which is only 36 pins. > The shematics for the Cyclone and Spartan version are: > http://www.dxpcentral.com/LiveDesign/LiveDesign_EB_Schematics-Altera_Cyclone.pdf > http://www.dxpcentral.com/LiveDesign/LiveDesign_EB_Schematics-xilinx_spartan.pdf > > and the technical reference manual is: > http://www.dxpcentral.com/LiveDesign/LiveDesign_Eval_Board_Tech_Ref_Manual.pdf Have you been able to verify if this board can be used with conventional tools? Does it have connectors for a Xilinx or other cable? -- 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: 74592
Hi all, I tried to program a Lattice CPLD LC5512MB via the Xilinx parallel cable by using Xilinx iMPACT in batch mode with an ISC-file. The programming perfectly worked with an empty CPLD but if the CPLD already was programmed , strange things was happened - all Bits was programmed with zeros. It looks like as the ERASE OpCode in the LATTICE 1532-BSDL-file would not work. Does somebody know a solution? Thanks and regards BurkhardArticle: 74593
Chris wrote: > > I see what you mean, but I don't think I explained my problem clearly enough. > > My processor runs at 27 MHz and it needs to set a couple registers in the FPGA that runs at 36 MHz. The processor sets the 8-bit data and 8-bit address and then a little later sets a flag high. By this time the data and address have been stable for numerous clock cycles (of both the 27 and the 36 MHz clock) so there's no metastability problem on either of them. In order to clock them in, the processor sets another signal high, for instance x1 in the code above. I'm not in a big hurry here so I ran it through some registers to take care of the metastability, otherwise I might look into a dual-port FIFO or something. I should get something like this: > > 27 MHz x1 > 000000011111111111000000000 > > 36 Mhz pipe1[0] > 00000000xx111111111xx000000 > > 36 MHz x1_buf > 000000000000111111111111000 > > The data and address are stable long before x1 goes high and long after x1_buf should go low. I'm not concerned about speed, all I care about is that x1_buf has no metastability, which it shouldn't. I've done stuff like this before and it worked fine, but in this case it didn't work at all. There is still a bit of info missing. Did you *simulate* this design? If it passes simulation and fails in the chip, then you have a real issue, or your inputs are not what you think they are. If both fail, then I guess you can find the problem more easily in the simulation. But your metastabilitly circuit should work fine. So I suggest you look at how the delays are affecting the rest of the circuit. -- 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: 74594
Continued from previous post: I cannot recall exactly, but I recall a story of a signal defined "IOPin <= 'Z';" got trimmed during the map step, and an unconstrained test I/O pin got placed in what was thought to be LOC'd position. It maybe a pecularity of the pin in question, for this particular case "TDI". Anyways, "IOPin <= 'Z';" may not do what you intend it to do. Newman "Falk Brunner" <Falk.Brunner@gmx.de> wrote in message news:<2t5m92F1r90atU1@uni-berlin.de>... > "Urban Stadler" <u.stadler@pfeilheim.sth.ac.at> schrieb im Newsbeitrag > news:416da060$0$8024$3b214f66@usenet.univie.ac.at... > > hi > > > > i have the following question: > > > > i'm using a spartan 3 and was wondering if it is possible to set an io pin > > to tristate. > > is this possible by using the following vhdl command " IOPin <= 'Z'; " ? > > Yes. > > Regards > FalkArticle: 74595
If you have your values latched and stable... If you take one synchronizing signal through a synchronizing pipe... Check to make sure your synthesis didn't do you a "favor" by replicating one or more registers in your synchronizing pipe. I've heard of people getting multiple, sometimes conflicting versions of what should be a single node, resynchronized pulse.Article: 74596
Nice chip, but it's MPEG-4 at 30 fps (good), CIF resolution (320x240 - yuck). They list one of its applications is a PVR.... Who's going to build a PVR out of that?Article: 74597
I'm using WebPACK 6.3.01i. The synthesis report tells me the minimum clock period is about 17 ns. How do I get the same kind of static timing info after place and route? The P&R report shows max clock delay, net skew, pin delay, etc., but I don't see min period or max frequency. The async delay report says that the max delay is about 6.6 ns; am I supposed to infer a minimum clock period from that? Thanks, EricArticle: 74598
On Thu, 14 Oct 2004 12:04:08 -0600, "E.S." <emu@ecubics.com> wrote: >Dan DeConinck of PixelSmart wrote: >> I would like to read about any details on the Xilinx Image Processing FPGA >> which is mentioned in the below press release. >> >> Does anybody know what Xilinx has planned ? >As I understand it, this article just mentioned FPGA and Devices which >have image processing capabilities. Doesn't mean, there are new FPGA to >expect with image processing capabilities ... > >" production of FPGA chips, which are used in such products as TV sets >and mobile computerized terminals with image-processing features." > >And, there is nothing about imaging in the xilinx article ... > >So, for you, it is same busines as usual ;-) > >just my .0002 I agree with E.S. 's assessment. The Xilinx press release is clear that this is an extension of their fabless manufacturing strategy, and they are adding another foundry to their list of foundries that manufacture chips for them. The Forbes article is less clear, because they have latched onto one of the applications for high end FPGAs, and managed to promote it all the way to the article title. PhilipArticle: 74599
> Did you *simulate* this design?
No, I don't have a simluation tool -- startup company, shoestring budget, etc. I've always been a fan of the big simulator called real life anyway.
> Check to make sure your synthesis didn't do you a "favor" by replicating
one or more registers in your synchronizing pipe
I'll look into it. I've had this sort of trouble with CPLDs before.
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