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
In article <1141986452.587421.137510@i40g2000cwc.googlegroups.com>, <fpga_toys@yahoo.com> wrote: > >Allan Herriman wrote: >> You want to try it in your C -> hardware compiler? I'd be interested >> in the results. > >Me too :) > >I'll take a look at it this weekend, as it might make another >interesting example for the next FpgaC release. I have a pipelined >RSA-72 I did two years ago when looking at building dnet engines that >is a monster because of the barrel shifters and LUT RAMS required for >retiming. First glance at the referenced materials suggests the problem >with AES is going to be 80 or more block rams for S box lookups tables >to get any reasonable parallelism. It's not clear there is an easy way >to avoid using sbox tables, as the algorithm for creating the table is >itterative. There has been a lot of research put into efficient implementations of the S-boxes without using lookup tables; http://www.st.com/stonline/press/magazine/stjournal/vol00/pdf/art08.pdf might be an example. I went to a conference in August where http://class.ee.iastate.edu/tyagi/cpre681/papers/AESCHES05.pdf was presented, which runs AES at 25Gbits/second on an XC3S2000; the round function is pipelined into seven stages of three levels of LUT each. TomArticle: 98451
In EDK7.1 I could easily add any parameters to any of the IP cores. I can't find how this is done in 8.1... Is it still possible? It seems that even if I add a parameter manually to the MHS file, the tool then deletes it at some point... Thanks, /MikhailArticle: 98452
Paul, Nice post. Not often we agree. Overall, I am very pleased with the thread. LSI Logic was the dominant structured ASIC player with 42M$ in 2005 (numbers from ISuppli). There are 10 other vendors left now in this space, for a total market of 155M$ in 2005 (same source). Out of those 10 vendors, Toshiba announced in June that "there is no money in this market" (from a EE Times article, 6/5/2005). Is this a case of the "emperor having no clothes?" Or just no money in this business? 5 of those vendors offer 90nm, the rest all have older technologies, some as old as .18 micron. Two vendors that used to be in that business also left in the last year. If Altera gets some of that 42M$ that LSI has dropped (although LSI will convert anyone who desires to the standard cell flow), then that will be good for Altera. Good for the other 9 players, too. Generally, the structured ASIC venbdors have as many mask sets as they have customers, which means that the vendors have not saved a penny, and in fact are losing money. So, it is a great deal for a customer who wants a cheaper ASIC, but how long will companies stay in the business of losing money? When the dominant (that means #1) supplier of structured ASICs calls it quits, that is not a sign of a healty market (IMHO). So, while Altera runs off to do (structured) ASICs, we will instead continue to believe that programmable devices are the future, and continue to spend all of our effort (as in R&D $) on innovation in that field. AustinArticle: 98453
The opencores pci bridge can act as a wishbone bus master, so you can connect it directly to the CAN core. I don't know if you use your own PCI core, if so, you propably have to write a wishbone interface for it. Connecting the core to a CAN transceiver is simple. If you are using an FPGA without 5V tolerant I/Os use a 3.3V powered transceiver or a level converter. Weeeeeeekend!! Andre > > Hi Adrien, > > Maybe this is already clear to you, my apologies if so, but the > CAN protocol block and the PCI bridge are both peripherals which > are connected to the wishbone bus. Typically there will be > a bus master such as a micro-processor core (or equivalent state > machine) which will drive the bus to set-up the slave peripherals, > monitor the status registers of the slaves, identify when some > data needs to be moved from one to the other, and perform the > move or configure a DMA bus peripheral to do the move. > > So your project is not simply a case of connecting the CAN block > to the PCI block, you will also need a controller of some sort > sitting on the bus (micro-processor core etc). > > Not a trivial project, but not impossible either by any means. > > Alan > > > > > > > >Article: 98454
"MM" <mbmsv@yahoo.com> wrote in message news:47dki2Fem3plU1@individual.net... > In EDK7.1 I could easily add any parameters to any of the IP cores. I > can't > find how this is done in 8.1... Is it still possible? It seems that even > if > I add a parameter manually to the MHS file, the tool then deletes it at > some > point... > > Thanks, > /Mikhail > > Double click on the core and appears a window where you can change parameters. MarcoArticle: 98455
<simon.stockton@baesystems.com> wrote in message news:1141983034.185650.25270@z34g2000cwc.googlegroups.com... > Both FIFOs, and their respective READ_ENABLE signals, are manipulated > from within STATE MACHINES (clocked on the rising edge of the > respective READ_CLK's). For grins... For simulation... Delay the READ_ENABLE as seen by the FIFO by 1 nanosecond. These kinds of problems you're seeing are just *so* often a simulation problem because your RTL isn't simulation-ready when combined with models that have delay elements included.Article: 98456
Hows about making the signal drive some flip-flops inside the device. Make sure that the output of the flip-flops gets used somewhere else it'll all be optimised away. Oh, and I don't know your situation, but be careful about any unusual functions that you may have inferred on the CLK0, I did some tests with an XC95144XL a while ago: A clock in of 10MHz had a jitter of 70ps when it was directly output, that rose to 150ps when combinational stages appeared before the output. (well, in a simplified manner that's what I saw) Hope that helps. Ben "Arash Majd" <arash_majd@ee.sharif.edu> wrote in message news:1141989340.207522.111170@z34g2000cwc.googlegroups.com... > Hello and thanks for your attention > > Data bus signals, address bus signals, Micro(MPC 860) 50MHz clock, some > other clocks like (retiming clocks, 19.44 Mhz clocks) are some of the > other signals routed in our CPLD. I can not change my pin assignment, > because the zl_1944_clk comes into CPLD only from only GCK0 pin. > What I should do to make ISE consider zl_1944_clk as a global signal? > > (I would be grateful if possible for you to provide me with a phone > number to speak to you) >Article: 98457
Believe it or not, just taking jumper M0 off let me program the .bit file and it worked. But the USB cable is always hot, even when not programming (it's plugged into my laptop right now, without the Spartan-3 Board, and it's very warm/near hot. Still, I think that Digilent needs to do a little work with their software to avoid this inconvenience. But like I mentioned before, just pulling that jumper let it work, although it doesn't boot from the PROM anymore (because the jumper changes a mode setting). c d saunter wrote: > Hi Scott, > I can't shed any light on the issue you describe, but... > > When the SRAM fails to work, does the 'socket' (i.e. the shrinkwrapped IC > and PCB etc.) on the end of the JTAG-USB cable get very very hot? > > Twice now I have had occasions when programming .bit files through one of > these cables the end gets very very hot - although everything still seems > to work. Due to this and other not quite definable oddities I've switched > to programming the platform flash with .svf files and using this to > program the FPGA. > > It doesn't inspire faith in the things... > > cds > > Scott M. Kroll (none@nowhere.com) wrote: > : Well, I'm not sure if anyone here has had the same problem, but I have, > : and it has been driving me nuts. My primary machine is a laptop, which > : has no parallel port, so I am stuck with USB. Also, I am in a class > : where we are doing projects using the Spartan-3 Starter Kit from Digilent. > > : Since I have no parallel port, I have been using Digilent's JTAG-USB > : cable, which, for the most part, works great. However, there are two > : problems. > > : 1. You cannot use Xilinx IMPACT to program the Spartan-3 > : 2. The external SRAM does not work when using a .bit file > > : Well, #2 seems awfully strange. I know it did for me, I thought I was > : having a problem with VHDL, and that's why I thought it wasn't working. > : Well, I spent a long time tinkering with it over our winter break (I > : know, I know, but it's what I did) and just today I came up with the > : solution. > > : A little explanation for this is probably needed. Basically, anything I > : write and compile in IMPACT would work fine. LEDs light up, the > : 7-segment display works fine, everything I've done works great. > : However, every time I tried to write to the SRAM, nothing changed, I > : simply got back garbage/random data. Every time, no questions asked, it > : just didn't work. To make a long story short, here's a solution I > : discovered (which, is a whole another story to how I figured it out). > > : 1. Start IMPACT > : 2. Edit -> Add Device -> Xilinx Device > : 3. Loaded c:\Program Files\Xilinx\spartan3\data\xc3s200_ft256.bsd > : 4. Right-Clicked Device, Assigned Configuration File > : 5. Mode -> File Mode > : 6. Clicked SVF-STAPL-XSVF tab, clicked "Yes" when it asked to load from > : Boundary Scan > : 7. Chose to generate a new SVF file, named it > : 8. Right-Clicked Device, chose Program. > : 9. Output -> SVF -> Stop Writing to SVF File > : 10. Quit Impact > : 11. Started Export, did Device Scan, loaded SVF into the xc3s200, set > : the prom to bypass, hit program. Everything worked right. > > : Seems like a strange solution, but what I want to know, has anyone here > : had a problem like this? I have a feeling that loading a different .BSD > : file for other Xilinx chips should work just as well with the JTAG-USB > : cable/Digilent's ExPort software, but I couldn't tell you. > > : Hope this helps people out. > > : If anyone wants to contact me with any more information via email, > : please use: skroll at gmail dot com >Article: 98458
I belive you. there are some 'odd' things regarding the JTAG config, when during jtag config some other (serial or parallel) interface what is been selected by mode pins does clock in a valid config header things go crazy - there is a xilinx AR workaround also I think suggesting mode pin change AnttiArticle: 98459
Austin, Paul - Why no mention of EasyPath or HardCopy? Where do those flows fit into the FPGA vs. structured ASIC battle? Can you guys share any numbers for your respective "ASIC conversion" programs? As in how many design conversions per year, trends up or down over the last few years, profit margins vs. your FPGA business, cost for an EasyPath or HardCopy part vs. an equivalent structured ASIC part from one of the nine remaining vendors? Are these programs viable and will they continue? I've seen both of you guys bail from similar programs in the past. Good thread. RobArticle: 98460
Rob, Easypath is not a structured ASIC, it is an FPGA. Identical in every way to what the customer is already using. Except that we haven't tested the bits they don't use. As for "success" of Easypath, it requires no design, no software, and no support. No R&D. Completely different business model. So just one customer for Easypath is direct $ to the bottom line. Obviously, we have more than one customer, yet I am not able to give you the exact number (as we consider it proprietary). I do not consider Easypath as a competitor to ASICs (structured or otherwise), but as a cost lowering alternative for FPGA customers who no longer need to reconfigure their product. In effect, this is a new segment of an existing market. Would these customers go to an ASIC if Easypath was not an option? I really don't know. I suspect not. I suspect they would just move on to the next product, and either end the life of the one, or accept reduced profits and reduced sales. I know that Easypath is positioned as an alternative to Altera's HardCopy, but I disagree: Easypath is just that - easy. HardCopy is just that - hard. One is buying exactly the same silicon for a lower price, and moving on. The other is converting from a FPGA prototype of your design, to an ASIC, with all of those real risks (and I have heard of real cases of failure to converge from customers doing just that) and time to market issues. We did have a program for cost reduction, and hardening the FPGA design. It was called Hardwire. We had Hardwire 1, 2, 3... All we learned from this was the ASIC business is not our business (it is totally different business). And, we also learned that it is incredibly hard to make any money. Lots of competitors, many that are very hungry, and will drop the prices to take business beyond sanity. The structured ASIC shell and pea game is just that. Some of our hardwire products were just vias to short out memory cells, so the "conversion" was only a couple of masks, and costs were supposed to be incrediby low. Not. The story was good, but the reality was horrible: it didn't work the way it was supposed to (sound familar?). We eventually ended up with a standard cell ASIC flow after a gate array flow. Guess what? Didn't matter what the flow, it was still the ASIC business. You still did an incredible amount of work once, for one customer, with no guarantee of success, with no future, and no reuse of anything for the next technology node. With a real chance of failure. If the customer makes a mistake, we both fail. I like the model for FPGAs: if the customer makes a mistake, they fix it, and move on. Meanwhile we are succeeding with all of the other customers. They will succeed, too. If you will, we already have "been there, done that" and decided that we should stick with the customers, markets, business and business models that have made us the success we are today. Let those nine companies circle the drain, the plug has been pulled. AustinArticle: 98461
"Marco T." <marc@blabla.com> wrote in message news:dus9k9$lc1$1@nnrp.ngi.it... > > Double click on the core and appears a window where you can change > parameters. > That's the problem! You can change the existing parameters, but you cannot add new parameters! /MikhailArticle: 98462
RobJ wrote: > Austin, Paul - > > Why no mention of EasyPath or HardCopy? Where do those flows fit into the > FPGA vs. structured ASIC battle? Can you guys share any numbers for your > respective "ASIC conversion" programs? As in how many design conversions per > year, trends up or down over the last few years, profit margins vs. your > FPGA business, cost for an EasyPath or HardCopy part vs. an equivalent > structured ASIC part from one of the nine remaining vendors? Are these > programs viable and will they continue? I've seen both of you guys bail from > similar programs in the past. > > Good thread. Paul did mention this, in another branch : > HardCopy II is particularly exciting because it uses a very efficient > fine-grained logic fabric and provides a choice of migration devices > allowing greater cost reductions than previous members of the family. > HardCopy II also provides a significant speed-up over the equivalent > Stratix II FPGA devices and cuts power consumption in half. Which is interesting, because that offers a lot more than Xilinx's subset testing - and as Paul also mentions, it is the Prototyping, and tool flows, that make a large difference in taking this step. What is pretty much the same, in X & A's 'custom' offerings, is both will do the component testing, on their FPGA testers. Unlike other ASIC vendors, the FPGA players have (very) large investments in the SW side of their business. Of course HardCopy paths are only for a tiny % of customers, so from a design-start viewpoint, they are insiginifcant, but the revenue potential of that small group are significant. Still, if I were a Xilinx stock holder I might be a bit worried about their ignoring this sector. Let's see where they stand in 2008.. -jgArticle: 98463
Was just wondering if there were any cores out there ( not for a commercial product, just hobby experimentation here ) for the common support chips for a Z80. ( like SIO, DMA, etc ). I know a couple of CPU cores exist.. tks all.Article: 98464
How was it possible add new parameters to a core at the MHS level? EDK tools would issue an error stating property not found. This DRC goes far back to EDK3.1 days. You can only add a parameter if it also exists on the MPD of the core. MM wrote: > "Marco T." <marc@blabla.com> wrote in message > news:dus9k9$lc1$1@nnrp.ngi.it... >> Double click on the core and appears a window where you can change >> parameters. >> > That's the problem! You can change the existing parameters, but you cannot > add new parameters! > > /Mikhail > >Article: 98465
Arash Majd wrote: > Hello and thanks for your attention > > Data bus signals, address bus signals, Micro(MPC 860) 50MHz clock, some > other clocks like (retiming clocks, 19.44 Mhz clocks) are some of the > other signals routed in our CPLD. I can not change my pin assignment, > because the zl_1944_clk comes into CPLD only from only GCK0 pin. So you mean you have a pile of completed PCBs, and are after a 'SW only' solution ? > What I should do to make ISE consider zl_1944_clk as a global signal? Does the 19.44Mhz clock anything inside the CPLD ? If not, then it will not form a gCLK - but you could create a register for it to clock, and thus change the routing paths. How far, physically, between the IN and OUT pins ? Also, noise on Vcc/Gnd will aggravate this - PCB layers, decoupling ? What else happens to the 19.44Mhz ? - ie could you use a TinyLogic gate as Buffer/Switch, skipping the CPLD entirely - tiny logic devices will have very low jitter, as they have only one gate with its very-own supply rails. No common mode inductance at all.... -jgArticle: 98466
"Paulo Dutra" <paulo.dutra@NOSPAM.com> wrote in message news:dusi59$o7j1@cliff.xsj.xilinx.com... > How was it possible add new parameters to a core at the MHS level? > EDK tools would issue an error stating property not found. This DRC > goes far back to EDK3.1 days. > > You can only add a parameter if it also exists on the MPD of the core. You might be right that the parameter had to exist in the MPD-file, although I believe I did add a parameter which didn't exist in the MPD in the past. Correct me if I am wrong, but in 8.1 it doesn't seem to display all the available parameters, but rather only the ones it thinks you might need to change. /MikhailArticle: 98467
Jim, Let's see, Xilinx is "ignoring" a piece of a 155 M$ business with lousy margins and 9 other vendors competing and willing to drop prices below their costs? As a Xilinx stockholder, I am pleased to see that Xilinx can keep their eye on the prize, and not stray off to the "gold ring du jour." I do agree that having a cost reduction path is important for business. I do not agree that spending a proportion of your revenue is warranted to "capture" it. A simple ROI calculation will reveal if it is real business, or just plain dumb. Toshiba figured it out. LSI figured it out. We figured it out years ago. Two others figured it out (too late as they drove themselves right into the ground). AustinArticle: 98468
I know it's a mistake getting involved in this thread, but... here are some observations on EasyPath and (Structured) ASICs which don't appear to have come up elsewhere: 1 - EasyPath has an NRE. I don't have real numbers, but Xilinx's literature gives figures between $75K and $300K, and an MOQ of 50K pieces. It's not cheap. 2 - If you commit to EasyPath, you can't change your design without paying the NRE again. In this respect, EasyPath is the same as an ASIC. You have to be absolutely sure that it'll work. Just like an ASIC, in fact. 3 - The RapidChip NRE, for a device with about the same capacity as a very large Virtex-4, came in at about $100K - $150K, with much smaller MOQs. And this is a *small* device. 4 - EasyPath is not 'just the same' as the FPGA you were buying before. When I last looked, it was a device that had failed test. Perhaps someone from Xilinx could comment on whether this is true or not. This matters, because fewer devices will fail testing when yields go up, as they will. You're going to have to ask yourself whether Xilinx will carry on selling you cheap devices when they could sell them to someone else at full price. 5 - As I said in my other post in this thread, there is no comparison between EasyPath and even a 'structured' ASIC when it comes to capacity, performance, and power consumption. 6 - You can (or could) get RapidChip prototypes in about 8 weeks from handoff. I don't have EasyPath figures, but it's not going to be a lot less than that. 7 - I've seen (in several places) the claim that EasyPath devices are cheap because they require less testing. I don't believe it. They're cheap because they failed test in the first place, and so would have no value at all without the EasyPath route. It would be nice to have a definitive statement from someone in Xilinx if they happen to disagree with this. Where I agree with Austin is "I do not consider Easypath as a competitor to ASICs". So, what on earth is the point of spending all this (uninformed) effort knocking ASICs? If someone can get the business model right, then Structured ASICs will fit very nicely into the space between FPGAs and standard cell. And they will make no difference at all to the vast majority of the FPGA market. Evan -- Riverside emlat riverside-machinesdotcodotukArticle: 98469
"Benjamin Todd" <benjamin.toddREMOVEALLCAPITALS@cernREMOVEALLCAPITALS.ch> wrote in message news:dusaos$gv9$1@sunnews.cern.ch... > Hows about making the signal drive some flip-flops inside the device. > Make sure that the output of the flip-flops gets used somewhere else it'll > all be optimised away. > Oh, and I don't know your situation, but be careful about any unusual > functions that you may have inferred on the CLK0, I did some tests with an > XC95144XL a while ago: > A clock in of 10MHz had a jitter of 70ps when it was directly output, that > rose to 150ps when combinational stages appeared before the output. (well, > in a simplified manner that's what I saw) > Hope that helps. > Ben The 70ps and 150ps numbers are cleaner that what I expected but make good sense. The 0.12 UI doesn't make sense at 19.44 MHz but does for significantly higher output rates slaved off the 19.44 MHz clock. To the original poster or anyone else doing designs that have excessive constraints on jitter such as telecom systems and high speed/accuracy A/D converters, PLEASE design to provide the cleanest clock in the system to the stages that need the cleanest clock. Generic logic with unrelated activity "close by" will cause jitter either at the input to the chip or coming back off the chip. That's the nature of the beast. A discrete buffer would have been a better way to achieve the required low jitter levels.Article: 98470
First, I would like to see the Xilinx take on these items as well. Although I fell I "know" the issues, it's nice to have reassurance. Comments below: "Evan Lavelle" <me@seesig.com> wrote in message news:0tl3129i2hvcfs7ok5vliafonvf37blhbh@4ax.com... > > 4 - EasyPath is not 'just the same' as the FPGA you were buying > before. When I last looked, it was a device that had failed test. > Perhaps someone from Xilinx could comment on whether this is true or > not. This matters, because fewer devices will fail testing when yields > go up, as they will. You're going to have to ask yourself whether > Xilinx will carry on selling you cheap devices when they could sell > them to someone else at full price. At a structured ASIC presentation, I railed on the guy that said that Xilinx was selling bad parts. It's been underscored here before that the parts are *not* rejects from the main testing that get shoved over to the easypath line in the same sense as harddrives with bad sectors that didn't need "those" sectors. The parts are UNTESTED to begin with, have a yied% chance of being a 100% good device, and are *guranteed* not only for your explicit bitmap but for 100% LUT operation as well. 100% LUTs are good. 100% of the routing and resources you need are also good. If you have an error in the silicon, it doesn't burn a hole in your board; an unused feature or routing segment doesn't work which is inconsequential. Keep in mind that devices with redundancy have MANY chips that are shipped with KNOWN defects that are just "programmed out." *IF* you have a defect with EasyPath, it won't screw up the design that you submitted to them for 100% testing. > 7 - I've seen (in several places) the claim that EasyPath devices are > cheap because they require less testing. I don't believe it. They're > cheap because they failed test in the first place, and so would have > no value at all without the EasyPath route. It would be nice to have a > definitive statement from someone in Xilinx if they happen to disagree > with this. I worked at a company that produced a high-end piece of test equipment as well as a low-end box. The difference in the hardware was *minimal* but we opened ourselves to a market that required mininal NRE. The development for the big box was already bought and paid for. We still made a decent profit on the lower-cost box but it wasn't quite the margin of the more expensive brother. The margin we lost was made up for in reduced NRE costs up front. It's great when you can make *more* money by expanding your market without losing your base. It's *quite* probable that Xilinx doesn't save the cost difference between a production FPGA and an EasyPath FPGA with just the savings in test time. It's likely that they take a lower margin on the devices to keep customers who might change to a lower-cost, higher NRE solution by lowering their margins. They still make money. They don't need to provide the support and development to support 50 1k/yr customers compared to 1 50k/yr customers. Xilinx gets more profits. Customers get less costly solutions. The only folks left out are those that had alternative paths to offer beyond the Xilinx flow. My thoughts, my opinions. I like the business case. - John_HArticle: 98471
Hi, I plan to do a project using the AC97 codec on a Virtex-II Pro board. I'm thinking to read inputs from MIC, do some filtering work, and the output to speakers. I do not have any experience with audio devices. Does anyone know good references for a starter? Thanks! -EricArticle: 98472
Jim Granville wrote: > Arash Majd wrote: > > > Hello and thanks for your attention > > > > Data bus signals, address bus signals, Micro(MPC 860) 50MHz clock, some > > other clocks like (retiming clocks, 19.44 Mhz clocks) are some of the > > other signals routed in our CPLD. I can not change my pin assignment, > > because the zl_1944_clk comes into CPLD only from only GCK0 pin. > > So you mean you have a pile of completed PCBs, and are after a > 'SW only' solution ? > > > What I should do to make ISE consider zl_1944_clk as a global signal? > > Does the 19.44Mhz clock anything inside the CPLD ? > If not, then it will not form a gCLK - but you could create a > register for it to clock, and thus change the routing paths. > There is only two or three signal assignments. for example : CKREF0<=ZL_1944_CLK CKREF1<=ZL_1944_CLK How should I create a register for it ? you mean that I implement a counter in my design? > How far, physically, between the IN and OUT pins ? > The input pin(GCK0) belongs to functional block5 and the CKREF0 pin (output pin) belongs to FB15. and the CKREF0 and the optical driver module is nearly 10 cm far. > Also, noise on Vcc/Gnd will aggravate this - PCB layers, decoupling ? > I am sure that the power planes are O.K and the decoupling capacitances are proper, because when I input this signal from another input (by wire ) the output jitter is O.K. > What else happens to the 19.44Mhz ? - ie could you use a TinyLogic > gate as Buffer/Switch, skipping the CPLD entirely - tiny logic devices > will have very low jitter, as they have only one gate with its very-own > supply rails. No common mode inductance at all.... You mean that I change my PCB? > > -jgArticle: 98473
Evan, Thanks for bringing this up, Answers below, Austin -snip- > 1 - EasyPath has an NRE. I don't have real numbers, but Xilinx's > literature gives figures between $75K and $300K, and an MOQ of 50K > pieces. It's not cheap. Nope. We ask that folks are serious. Just like for ASICs. Don't want to waste our time on non-real requirements. > 2 - If you commit to EasyPath, you can't change your design without > paying the NRE again. In this respect, EasyPath is the same as an > ASIC. You have to be absolutely sure that it'll work. Just like an > ASIC, in fact. Not true: you may change any LUT contents that you already are using, and you may change any IO standard on any pin you are already using. There are other changes which are allowed. Try that with an ASIC! We call it the ECO capability of EasyPath (some stuff we have to test 100%, so you benefit). > 3 - The RapidChip NRE, for a device with about the same capacity as a > very large Virtex-4, came in at about $100K - $150K, with much smaller > MOQs. And this is a *small* device. RapidChip? Oh those guys that just left the business? Oh well. I could offer you gasoline at 8 cents a gallon, and I am sure I would have a long line at my station... > 4 - EasyPath is not 'just the same' as the FPGA you were buying > before. When I last looked, it was a device that had failed test. Not true: it is a device that is only tested for what you need. > Perhaps someone from Xilinx could comment on whether this is true or > not. Commonly asserted by others to apply FUD. This matters, because fewer devices will fail testing when yields > go up, as they will. You're going to have to ask yourself whether > Xilinx will carry on selling you cheap devices when they could sell > them to someone else at full price. We will start wafers just to meet EasyPath. It is that cost effective. And, we do just that. > 5 - As I said in my other post in this thread, there is no comparison > between EasyPath and even a 'structured' ASIC when it comes to > capacity, performance, and power consumption. Ohe really? I think one can comapre them. Some areas (like leakage) the ASIC will win. Some areas (like 10 Gb/s MGTs and a PPC, and a TEMAC) the EasyPath will win, as these IPs are not even available all together in 90nm! > 6 - You can (or could) get RapidChip prototypes in about 8 weeks from > handoff. I don't have EasyPath figures, but it's not going to be a lot > less than that. Yes. Except that now, RapidChip will arrive "never." When EasyPath arrives, there is nothing to do, but plug it in, and ship it. No requalification is required: there is NO DIFFERENCE in what goes in the socket. Re-qual costs can be substantial, and the re-qual can take months... > 7 - I've seen (in several places) the claim that EasyPath devices are > cheap because they require less testing. I don't believe it. Well, I can't convince you without desrcibing why. And in describing why, I will educate you. And I have no incentive to do that. You may look up the patent if you wish. They're > cheap because they failed test in the first place, and so would have > no value at all without the EasyPath route. It would be nice to have a > definitive statement from someone in Xilinx if they happen to disagree > with this. Definitive statement: testing a product for one use saves an incredible amount of money. Look at ASICs.... > Where I agree with Austin is "I do not consider Easypath as a > competitor to ASICs". So, what on earth is the point of spending all > this (uninformed) effort knocking ASICs? If someone can get the > business model right, then Structured ASICs will fit very nicely into > the space between FPGAs and standard cell. And they will make no > difference at all to the vast majority of the FPGA market. Oh, I don't know, sounds like you learned something today? And, you and I agreed on something. Not a bad result for a thread.Article: 98474
The tools do visually hide parameters that are automatically computed. There are tags within the MUI file that define the parameter as hidden. If you edit the MHS with a texteditor you'll can enter the value for the hidden parameter. MM wrote: > "Paulo Dutra" <paulo.dutra@NOSPAM.com> wrote in message > news:dusi59$o7j1@cliff.xsj.xilinx.com... > >>How was it possible add new parameters to a core at the MHS level? >>EDK tools would issue an error stating property not found. This DRC >>goes far back to EDK3.1 days. >> >>You can only add a parameter if it also exists on the MPD of the core. > > > You might be right that the parameter had to exist in the MPD-file, although > I believe I did add a parameter which didn't exist in the MPD in the past. > Correct me if I am wrong, but in 8.1 it doesn't seem to display all the > available parameters, but rather only the ones it thinks you might need to > change. > > > /Mikhail > >
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