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
/proj/holistic/work/uhan/virtex5/tools/stampit BRAM ( updated ) ------ /proj/holistic/work/uhan/virtex5/tools/stampit/stampit.pl -design /proj/holistic/work/uhan/virtex5/tools/stampit/templates/ramb36_rnr_ra36_rb36_wa36_wb36_maWRITE_FIRST_mbWRITE_FIRST -device rnr_120x30i -tile RAMB36 -rpm /build/xfndry/HEAD/env/Databases/DeviceResourceModel/data/rainiers/rainier/model/lin64opt/x5vlx50t.rpm -instance top -outdir /proj/holistic/work/uhan/virtex5/tools/stampit/output/ramb36Article: 98476
Austin Lesea wrote: > 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? I have to smile - all those 'make it your ASIC' promotions by marketing, and here you now claim the market is tiny, and with no margins ?! ..... -jgArticle: 98477
> -device rnr_120x30i -tile RAMB36 -rpm cooooolArticle: 98478
Ui (daniel) Han wrote: > /proj/holistic/work/uhan/virtex5/tools/stampit > > > BRAM ( updated ) > ------ > /proj/holistic/work/uhan/virtex5/tools/stampit/stampit.pl -design > /proj/holistic/work/uhan/virtex5/tools/stampit/templates/ramb36_rnr_ra36_rb36_wa36_wb36_maWRITE_FIRST_mbWRITE_FIRST > -device rnr_120x30i -tile RAMB36 -rpm > /build/xfndry/HEAD/env/Databases/DeviceResourceModel/data/rainiers/rainier/model/lin64opt/x5vlx50t.rpm > -instance top -outdir > /proj/holistic/work/uhan/virtex5/tools/stampit/output/ramb36 > Does that mean that ramblocks on the Virtex-5 are 36kbits now ? SylvainArticle: 98479
Accidents happen. This was obviously not a newsgroup message. All of us have clicked a wrong button at a wrong time, at least once. We are sorry for the confusion this created. PeterArticle: 98480
Jim! That is a bait and switch on your part. The "make it your ASIC" program is selling Spartan 3 90nm part directly against gate arrays (an easy winner, no brainer), and selling Spartan 3 90 parts directly against a segment of the standard cell ASIC business (definetly can't win all of that market! - yet). In fact, the "make it your ASIC" (referring to Spartan 3 90nm) has been so successful, that with 10 million devices sold (see press announcement), it represents more 90nm, basically supplying 70% of all 90nm FPGAs. http://www.xilinx.com/prs_rls/silicon_spart/05118_90nm10mil.htm That was December, 2005. And now we have had almost a whole quarter of sales which just extend this lead by even more (which I can't say, as I really don't know the numbers until they are announced). How does that compare with 90nm ASICs? Well, I can say pretty safely that without this program, and these parts, there might be 10 million more 90nm ASICs in the world in the last year... But I really doubt it, as most ASICs don't work, never get to market, and generally just cause gray hair. We got the sockets. We got the parts. Austin Jim Granville wrote: > Austin Lesea wrote: > >> 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? > > > I have to smile - all those 'make it your ASIC' promotions by > marketing, and here you now claim the market is tiny, and with no > margins ?! ..... > -jg >Article: 98481
Hello,
I'm using ISE 8.1 and I'm facing problems to synthesize my VHDL
project. This project was simulated in modsim without problems. The
synthesis process is on-going for several minutes. I would like to know
which kind of problem in my project could cause such behavior?
Thank you in advance,
Fabio
Article: 98482Hard to say. You haven't given us much. Some of my sims run overnight. Have you given it enough time?Article: 98483
Austin Lesea wrote: > Jim! > > That is a bait and switch on your part. > > The "make it your ASIC" program is selling Spartan 3 90nm part directly > against gate arrays (an easy winner, no brainer), and selling Spartan 3 > 90 parts directly against a segment of the standard cell ASIC business > (definetly can't win all of that market! - yet). > > In fact, the "make it your ASIC" (referring to Spartan 3 90nm) has been > so successful, that with 10 million devices sold (see press > announcement), it represents more 90nm, basically supplying 70% of all > 90nm FPGAs. > > http://www.xilinx.com/prs_rls/silicon_spart/05118_90nm10mil.htm > > That was December, 2005. And now we have had almost a whole quarter of > sales which just extend this lead by even more (which I can't say, as I > really don't know the numbers until they are announced). > > How does that compare with 90nm ASICs? Well, I can say pretty safely > that without this program, and these parts, there might be 10 million > more 90nm ASICs in the world in the last year... Wow - and I have to smile again... :) Now you are saying that 100% of the Spartan 3 business is ASIC replacement, and that a spartan sold is an ASIC replaced/removed ? -jgArticle: 98484
When I upgrade(?) to ISE 7.1.4 and ModelSim 6.0 I find my testbenches can not read binary files. Is this a technical problem or a downgrade on ModelSIM XE free offering. Note this is a binary file read not a textio file read which, according to the manual, is still available. Brad Smallridge Ai VisionArticle: 98485
Evan Lavelle wrote: > I know it's a mistake getting involved in this thread, but... <snip> > 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. Many companies have 'bining' flows, where the same die attract different prices, sometimes over a 2:1 range. Yes, EasyPath helps if they can use otherwise reject parts, but remember if it failed a generic test, it is likely to fail in your application. ie Only a subset of failure types will be candidates. Testing IS expensive, but so also is running a custom test - thus the fairly high NRE prices on EasyPath - it also serves as a 'go away' flag to those with insufficent volumes :) Testers themselves are expensive, if your app can run on a low cost one, that frees up the cutting edge ones, for higher margin full FPGAs -jgArticle: 98486
Jim, OK, OK. You caught me in a wild unsupported assumption. No, not all of those 10M sockets stole an ASIC win. Austin Jim Granville wrote: > Austin Lesea wrote: > >> Jim! >> >> That is a bait and switch on your part. >> >> The "make it your ASIC" program is selling Spartan 3 90nm part >> directly against gate arrays (an easy winner, no brainer), and selling >> Spartan 3 90 parts directly against a segment of the standard cell >> ASIC business (definetly can't win all of that market! - yet). >> >> In fact, the "make it your ASIC" (referring to Spartan 3 90nm) has >> been so successful, that with 10 million devices sold (see press >> announcement), it represents more 90nm, basically supplying 70% of all >> 90nm FPGAs. >> >> http://www.xilinx.com/prs_rls/silicon_spart/05118_90nm10mil.htm >> >> That was December, 2005. And now we have had almost a whole quarter >> of sales which just extend this lead by even more (which I can't say, >> as I really don't know the numbers until they are announced). >> >> How does that compare with 90nm ASICs? Well, I can say pretty safely >> that without this program, and these parts, there might be 10 million >> more 90nm ASICs in the world in the last year... > > > Wow - and I have to smile again... :) > Now you are saying that 100% of the Spartan 3 business is ASIC > replacement, and that a spartan sold is an ASIC replaced/removed ? > > -jg >Article: 98487
Well, I has been running for 40 minutos. However, I don' t have any idea how long is "enought time". I thought it was a problem in my code. Thank you, Fabio Brad Smallridge wrote: > Hard to say. > You haven't given us much. > Some of my sims run overnight. > Have you given it enough time? > >Article: 98488
Hmm. I misread your post. It could be hung. What part are you running? BRad SmallridgeArticle: 98489
Scott M. Kroll wrote: > Believe it or not, just taking jumper M0 off let me program the .bit > file and it worked. It just occured to me... when I program the S3 kit with impact and the parallel cable, I get this little popup warning that it has changed that startup clock to jtag vs whatever was in the .bit file. Might this have anything to do with it - that change might get made in the SVF, but be missed if you take the .bit file directly to the USB downloader program?Article: 98490
OK, I have finally resolved this problem. I had to create a custom IP, which I called dcr_plug. It simply connects to the DCR master on one side and exposes the same pins on the other side. This made the tool happy... So, now I have the DCR bus in my top level design and I can do anything I want with it! /Mikhail "MM" <mbmsv@yahoo.com> wrote in message news:47c2naFei2s4U1@individual.net... > Dear EDK experts, > > Here I am again with an EDK problem... I have a top level ISE design and an > EDK submodule (PPC). I am trying to bring a DCR bus out from the EDK > submodule into the top level ISE design. Since I want this bus to be in the > normal address space I added the opb2dcr_bridge to my design. I assigned the > DCR master side of bridge to the external ports of the EDK submodule. All of > this seems fine, but it doesn't work... I can't see any activity on the DCR > bus when looking with the Chipscope except for I know that the clock is > present... What am I missing? > > One thing I noticed is that in the Bus Interface View the bridge shows as > not connected on the DCR master side... I tried adding a DCR bus, connecting > the bridge to it and bringing this bus to external ports instead of the > bridge's pins directly, however the EDK then would complain that there were > no slaves on that bus... The only connections it would allow to that bus in > the Bus Interface View are to the ppc405_0 and, I believe, > plb2opb_bridge_0... > > Has anyone been through this? > > Thanks, > /Mikhail > >Article: 98491
Here's my guess: You have a Zarlink low-jitter source for 19.44MHz and you are running through a CPLD before attaching to the ASIC connected to the board's optics. Whenever you use an expensive chip to give you a low jitter clock, you don't want to ruin it by running through a part with indeterminate jitter. You've just destroyed your clock's known jitter range. The output of the CPLD will be affected by nearby switching IO because the IO buffers share power and ground lines and they all feed noise to these lines on the chip. Most ASICs driving optics require a clock source with known jitter and you don't have it. I like the solutions you were given that bypass the CPLD altogether.Article: 98492
Thomas Womack wrote: > 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. Any clue what the specific GF functions and tables are?Article: 98493
Marco, The revised core ppc405_virtex4_v1_01_a is expected to be a drop-in = replacement for v1_00_a under all conditions, and this is the first = report I've seen indicating any problems resulting from upgrading to it. = The fix in v1.01.a redefines the default value of parameter = C_APU_CONTROL to avoid a potential intermittent PPC start-up failure = that had been observed in some (not all) V4FX designs when the APU = interface is not used. Assuming your design does not use the APU = interface, an alternative to upgrading the PPC is to just set parameter = C_APU_CONTROL =3D 0b1101111000000000 on the ppc405_virtex4_v1_00_a = instance in your design to guard against the potential start-up failure, = as described in Xilinx Answer Record: 22179. In designs that use APU, = the fix is irrelevant, so upgrading the PPC could just be bypassed. Please let me know if you continue have difficulty with this issue after = trying the above workaround. Regards, Jeff Seltzer, Xilinx Embedded Processor jeff.seltzer@xilinx.comArticle: 98494
Austin, > Let those nine companies circle the drain, the plug has been pulled. I'm really having great difficulty trying to understand why you think the ASIC/ structured ASIC market is going to die. Can you give us Xilinx's roadmap/business model that will compete? For instance: can you give me a 60k/annum pricing for a product that has a 3yr life--total pcs 180k of a 375k Gate device with 3Mbit of on chip ram and 4 PLL's? And I'll compare it to my quote from our ASIC vendor. When we started this design we were in a V2PRO30, since then our design has grown beyond the limits of this device. But since I only have pricing on the V2P30 my math will have to be based on this part. I will only give percentages as it would not be prudent for me to reveal the actual numbers. The ASIC is 8x cheaper than the V2P part. How much more lower would the ASIC be when compared to an FPGA that could hold our current design? It is very easy to see that we save the company BIG $$ by going to an ASIC. The structured ASIC pricing was approx 4x cheaper, which is still very much cheaper than going with an FPGA. Xilinx has decided to ignore this market, based on one of your posts--155M is too small for a 2B dollar company. Altera is not quite as large as Xilinx and perhaps those dollars seem more attractive. Or perhaps Altera is using their Stuctured ASIC program to pull in other FPGA businees that they would otherwise not have: get in the door with the HC program and hope that you can pull in some future FPGA business?? Regards, Rob "Austin Lesea" <austin@xilinx.com> wrote in message news:dusgjq$p671@xco-news.xilinx.com... > 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. > > Austin >Article: 98495
Hello all,
In a project, I use a Spartan-3 XC3S400 FPGA from Xilinx.
The design use a Microblaze CPU instantiated in the FPGA.
I use the Digilent Spartan-3 starter kit for prototyping. Note that the
original XC3S200 FPGA has been removed, and replaced by a XC3S400 FPGA.
I want to erase/program the platform FLASH PROM installed in this board (the
XCF02S IC) with a new FPGA configuration file, using the Microblaze CPU.
Xilinx application note xapp544 is a good starting point for doing this stuff.
But, there are some information that is missing to be able to achieve this
task. These informations are:
a) How long it take to program a PROM row (after the program row command
has been sent to the PROM) ?
b) What is the format a FPGA configuration file (.bit, .mcs, .hex), and
associated programmation algorithm to get the PROM programmed correctly ?
I was searching for more than 1 week about this information without finding
anything.
Is it possible that this information is confidential and can not be published ?
Claude Sylvain
Electro-Technica inc.
Article: 98496Rob wrote: > Austin, > > >>Let those nine companies circle the drain, the plug has been pulled. > > > I'm really having great difficulty trying to understand why you think the > ASIC/ structured ASIC market is going to die. Can you give us Xilinx's > roadmap/business model that will compete? Don't forget Xilinx have a (large) vested interest in talking down any ASIC MASK flows. > For instance: can you give me a 60k/annum pricing for a product that has a > 3yr life--total pcs 180k of a 375k Gate device with 3Mbit of on chip ram and > 4 PLL's? And I'll compare it to my quote from our ASIC vendor. When we > started this design we were in a V2PRO30, since then our design has grown > beyond the limits of this device. But since I only have pricing on the > V2P30 my math will have to be based on this part. I will only give > percentages as it would not be prudent for me to reveal the actual numbers. > > The ASIC is 8x cheaper than the V2P part. How much more lower would the > ASIC be when compared to an FPGA that could hold our current design? It is > very easy to see that we save the company BIG $$ by going to an ASIC. The > structured ASIC pricing was approx 4x cheaper, which is still very much > cheaper than going with an FPGA. Did you get a Hardcopy II price from Altera, or is that what you mean here ? Do you have any current consumption ratios ? > Xilinx has decided to ignore this market, based on one of your posts--155M > is too small for a 2B dollar company. That has to be a very hard number to quantify reliably - for example, I doubt if Altera's HardCopy is in that pigenhole, they will be called FPGA's. Altera only has to hit ~15% revenue via HardCopy, to equal that number. Another way to approach this, is the FSA just said their members hit $40B last year, and they are only a portion of FAB runs. TSMC alone is presently close to $10B/yr, at the FAB end. Everything a FAB makes, is an ASIC - a large chunk will not be reachable by FPGAs due to sheer low power, or Analog features ( tho Actel can start to argue on that last point, at least for average analog features ). -jgArticle: 98497
Rob wrote: > Austin, > > > Let those nine companies circle the drain, the plug has been pulled. > > I'm really having great difficulty trying to understand why you think the > ASIC/ structured ASIC market is going to die. Can you give us Xilinx's > roadmap/business model that will compete? We've just come thru one of the largest and longest tech slumps that has created MANY corrections and changes in the market. What has been not so profitable for the last five years is no indiction of what will be profitable for the next five years if we resume a normal boom cycle at this point. Cashflows have been VERY tight, making NRE's very difficult to swallow, which is certainly been tough on both the ASIC industry and all capital intensive related markets. Xilinx has substantial reasons to gain by declaring the ASIC markets dead, FUD to help push projects thinking about the NRE's to FPGAs. High end businesses sift thru technologies ranging from pure ASIC to PLD on a project by project basis, directly coupled to sales ... which if headed up will also mean they are headed up the logic food chain too.Article: 98498
On Fri, 10 Mar 2006 12:24:10 +0100, backhus <nix@nirgends.xyz> wrote: >> >> Google shows that there are many papers claiming rather fast AES in >> FPGAs (with some fine print saying they're using a non-feedback mode). >> I've never seen a feedback mode cypher in a real world application get >> anything over some Gb/s. >> >> Regards, >> Allan > >Hi Allan, >interesting point, but have you thought about what the reasons may be? > >Let's do some (approximative) calculations. > >Assume you have a single AES-Round that runs with a 100MHz Clock. >This round needs at least 10 clocks to produce an AES Cipher. > >With 128 Bits Data width that gives: > >128 * 100e6 /10 = 1,28e9 Bits per second > >So that is the limit for the assumed circuit. > >Adding a feedback path for block cipher modes will extend the number of >clocs to create a ciper. > >Let's assume 14 clocks to produce a CBC cipher > >Now we have: > >128 * 100e6 /14 = 914,3e6 Bits per second > >That's all what's possible with the assumed circuit. > >How can we increase the throughput? > >1) Wait for better silicon that allows higher clock rates. >2) Use more chip-space to implement aditional rounds and decrease the >number of iterations needed in the round. But that may be rather expensive! > >3) Improve the rounds latency. Make it fast to the limit. (Which is at >about 500MHz as some vendors claim for their products ;-) ) > >Now let's assume our circuit will still run at 100MHz, but the improved >round runs at 500 MHz. That will reduce the round latency to 2 100MHz >cycles. Which gives 6 cycles to create the CBC cipher. > >Now we have: > >128 * 100e6 /6 = 2,1e9 Bits per second > >So, that's the theoretical limit for the assumed circuit. You can exceed >it by investing in additional or better (ASIC) silicon, if you have the >money. > >As I understand the original posting, these guys want to spend some work >on solution 3 somehow. > >My tip to manjunath & co.: Have a look at the standard implementations >and the book "The design of rijndael" ISBN: 3540425802 >Identify the modules and start optimizing the designs to whatever your >goal is. > >Have a nice synthesis > Eilert Hi Eilert, That's the idea. Your numbers are a little out though. Using a mature FPGA process (with moderate speed grade) is likley to result in a clock of about 200MHz if hand placement of the sboxes is used. AES takes 14 rounds per block. It might be possible to have feedback around that block without wasting another clock, but let's assume that it takes 1 extra clock for the feedback mux, which gives 128 bits of result every 15 clocks. This results in a throughput of 1.7Gb/s. A newer FPGA + fastest speed grade + hand placement of some LUTs might double the numbers. I doubt it could reach a 500MHz clock in an FPGA. Of course, if one isn't using a feedback mode, many AES engines can be run in parallel for a vast increase in speed. Alternately, the loops can be unrolled for the same effect. I notice that OC192 / STM64 AES encryptors have been available for a couple of years. I assume these have a single FPGA which produces approx 20Gb/s of crypto material (10Gb/s encrypt, 10Gb/s decrypt + the encrypt and decrypt streams are different so they can't share any hardware). Regards, AllanArticle: 98499
On Fri, 10 Mar 2006 16:05:02 +0800, "kcl" <KCLO4[no_spam]@free.fr> wrote: >Hi everybody, > >I am beginner in FPGA design ( about 1 year of experience in VHDL design), I >enjoy my job but (there is always a but) I think I don't learn a lot of new >thing about FPGA since I have been out of my last internship . >So why I would like to know which book or website could you recommand me to >enhance my knowledge. I' d like to learn about multiple clock domain design, >making constraint (not only put a time constraint), interfacing fpga with >the 'real wolrd' and all that hint & tips that make the difference betwen a >good design and a beginner like me. Hi Alexis, You'll learn more by implementing real world designs. Your real world FPGA designs should be parts of real world products. That way you'll also learn about important aspects of engineering like marketing, customer interaction and support. Also, get yourself a mentor, i.e. someone who already knows about logic design and HDLs and can point out the pitfalls before you waste a lot of time with negative "learning experiences." Regards, Allan
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