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
Jason Zheng wrote: > J o h n _ E a t o n (at) hp . com (no spaces) wrote: > >> Michael wrote: >> >>> Weng Tianxiang wrote: >>> >>>> Hi Pablo, >>>> Thank you for your useful information. >>>> >>>> Weng >>> >>> >>> >>> >>> The problem is "System Requirements": "SPARC CPU based system" >>> >> >> Is that for the software development environment?. Seems like the >> verilog rtl code should be pretty generic. From the description it >> sounds more like a big compute farm engine rather than something >> you would put in a fpga for an embedded system. >> >> >> >> John Eaton > > > Why not? This would be a great teaching tool for fpga design and/or > computer system design courses at college level. > > ~jz Only if it can fit into an FPGA. Anybody have a gatecount? John EatonArticle: 99376
Symon wrote: > "Symon" <symon_brewer@hotmail.com> wrote in message > news:4422e0f2$0$15787$14726298@news.sunsite.dk... > >>"Roger Bourne" <rover8898@hotmail.com> wrote in message >>news:1143136101.823610.180860@u72g2000cwu.googlegroups.com... >> >>>Hello all, >>> >>>I am planning to introduce a decimation filter in my FPGA design in >>>order to reduce the sample frequency by 8. This has resulted in a 61 >>>tap FIR filter. -It seems awfully large. Basically, I am asking , for >>>an FPGA implementation, what is a REASONNABLE number of taps for a FIR >>>filter? >>> >> >>Roger, >>Look at making your filter as a series of half-band FIR filters. These are >>efficient in that every other tap is zero. (Nice and easy to multiply by >>zero!) Use three, decimating by two at each stage. Your implementation >>should be a lot more compact. The later stages will probably have more >>taps, but the sample rate will be reduced, possibly allowing you to use >>distributed arithmetic. >>Cheers, Syms. >> > > Also, check out CIC (cascaded integrator comb) filters? Although 8 may not > be a high enough decimation factor to make this method worthwhile. > Cheers, Syms > > And keep in mind that when you decimate you don't need anti-aliasing at Nyquist (1/4 samples), you only need it at those frequencies where the energy is going to get through your IIR filters -- I see needing a 3-stage CIC filter to do this, which with a boneheaded implementation only requires 24 taps. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Posting from Google? See http://cfaj.freeshell.org/google/Article: 99377
Austin Lesea wrote: > Looks nice, but... > > If you could only get them (ST2GX or SC). > > At least we have shipped all our backlog on xc4vFX devices. > > Austin Are the MGTs up and running? I'd love to prototype with the FX20.Article: 99378
John, Antti, I will say that if you place an order now, you will get a real delivery date, and the parts will be shipped (we are not supply constrained for the part numbers). For details, you really need to contact your FAE. There are more than one sample part number for the FX20, FX60, and I believe now the FX100, that are available. The FXs with MGTs are rolling out now, so that train is back on its tracks. In all honesty, there is a lot of characterization left to do, that was delayed because of the changes, so we still very busy with MGTs here. I have been lately working with some universities and schools in the XUP program to expedite FX parts for them (as they were the last on the list, so if we are getting some MGTs for them, things must be better!). Austin John_H wrote: > Austin Lesea wrote: > >> Looks nice, but... >> >> If you could only get them (ST2GX or SC). >> >> At least we have shipped all our backlog on xc4vFX devices. >> >> Austin > > > Are the MGTs up and running? I'd love to prototype with the FX20.Article: 99379
Personally I think the best textbook on logic design is AMD PAL Device Handbook. All my logic training was based on the book, read by myself, not taught at any classes. I bought 5 VHDL books, but only the AMD book really teaches me how to program in logic. The open CPU source code is an excellent contributions to the generations of logic designers by Sun Microsystem. It would be much wonderful If there is an retired engineer from Sun who deeply invovled in the code making writes a book with the opened source code. It would be more valuable than any Verilog books available in the market. Teaching by example is the best way to teach a language and related technique. Real design examples give you really deep insights on what the designers were thinking about and how nicely they handle the difficult situations. I appreciate Sun's efforts to open its source code. Thank you, Sun Microsystem. WengArticle: 99380
Falk Brunner wrote: > > Theory: Nothing works but everone knows why. > Practice: Everything works but nobody knows why. > Theory + Practice : Nothing works and nobody knows why. > > ;-) This is one of the best I've ever heard! > > P.S. One of the problems with JTAG is/was, that people underestimate > problems due to the low frequencies involved. And as far as I > remember, the are/were some nasty problems with FPGAs for brand . . . > because the JTAG inputs (especially the clock) was sensitive to > non-perfect transitions, which means you have to treat the almost DC > like JTAG like a GBit transmission line. Not nice at all. The > suggestion of Austin to do a simulation is in general right, but > sounds a little bit strange to me. Simulate a 5 MHz clock signal > ?(Yeah yeah, I know, its transition time that matters, not frequency). > So why is the JTAG (clock) not INTENTINALLY made slower (+ schmitt > trigger) to avoid this problems? Nobody needs a 100MHz++ capable JTAG > port (today). On many FPGA's, especially Xilinx, the JTAG signals are on pins that can be used as normal user I/O pins. So, they would have to put special filters on the pins when used for JTAG, and remove the filter for normal use. Clearly could be done, but it gets complicated. And, you never know how fast any specific user might run their JTAG. In some cases, a user might rig an FPGA and a local memory to do very fast loading or testing on their production line. I had a similar problem with a 5 V Spartan FPGA. It implemented a long serial chain for configuration sensing/setup on a motherboard with up to 16 daughterboards. The command/control was via LVDS, which had WAY more bandwidth than needed, but they fit the other requirements. We had some reflections on the LVDS lines that caused double pulses on the serial clock. So, I had to implement an external filter with an RC and a Schmitt trigger before feeding the clock to the FPGA. It was hard to track down, it was one of those "only works with the scope probe on the pin" conditions. Once I knew what was going on, it was easy to fix. JonArticle: 99381
Falk Brunner wrote: <snip>> P.S. One of the problems with JTAG is/was, that people underestimate > problems due to the low frequencies involved. And as far as I remember, > the are/were some nasty problems with FPGAs for brand . . . because the > JTAG inputs (especially the clock) was sensitive to non-perfect > transitions, which means you have to treat the almost DC like JTAG like > a GBit transmission line. Not nice at all. The suggestion of Austin to > do a simulation is in general right, but sounds a little bit strange to > me. Simulate a 5 MHz clock signal ?(Yeah yeah, I know, its transition > time that matters, not frequency). So why is the JTAG (clock) not > INTENTINALLY made slower (+ schmitt trigger) to avoid this problems? > Nobody needs a 100MHz++ capable JTAG port (today). The latest Serial memories from Winbond can stream at 150Mbd, from an 8 pin package ! That makes even 100MHz look sluggish. There is talk of USB-JTAG, which is sensible, and that should be high speed USB, in that case, FPGA suppliers SHOULD be working on ~400MBd capable JTAG streaming. -jgArticle: 99382
If you had read the (admittedly sparse) documentation you would have noticed it is targeted by default to Xilinx architecture and instantiates directly some Xilinx primitives. In each file there is a second architecture (surrounded by --pragma translate_off / --pragma translate_on) statements which is a generic RTL version for the simulator. If you remove these pragmas, the synthesis tool will then see the generic version. I cannot help you more as you do not say which tool is generating the warnings, or what you are trying to do. /MikeJ "sel" <selva991@gmail.com> wrote in message news:1143128217.112200.175140@j33g2000cwa.googlegroups.com... > now i have the complete correct code ( i got that from open cores.org) > and i could pin point the errors im uploading the whole code > fist let me tell the errors when i compiled the code > 1.in mux8 file im getting > Warning: ELAB1_0026: mux8.vhd : (87, 0): There is no default binding > for component "lut4".(No entity named "lut4" was found). > Error: COMP96_0078: mux8.vhd : (84, 22): Unknown identifier > "mux8_lut4". > Error: COMP96_0133: mux8.vhd : (84, 22): Cannot find object > declaration. > Error: COMP96_0078: mux8.vhd : (83, 22): Unknown identifier > "mux8_lut3". > Error: COMP96_0133: mux8.vhd : (83, 22): Cannot find object > declaration. > Error: COMP96_0078: mux8.vhd : (82, 22): Unknown identifier > "mux8_lut2". > Error: COMP96_0133: mux8.vhd : (82, 22): Cannot find object > declaration. > > 2.in mux4 file im geting > Warning: ELAB1_0026: mux4.vhd : (75, 0): There is no default binding > for component "lut4".(No entity named "lut4" was found). > Error: COMP96_0078: mux4.vhd : (72, 22): Unknown identifier > "mux8_lut2". > Error: COMP96_0133: mux4.vhd : (72, 22): Cannot find object > declaration. > Compile Architecture "RTL" of Entity "MUX4" > Compile failure 2 Errors 1 Warnings Analysis time : 0.1 [s] > > 3.in risc5x_xil as > warning: ELAB1_0026: risc5x_xil.vhd : (189, 0): There is no default > binding for component "ramb4_s2_s2".(No entity named "ramb4_s2_s2" was > found). > > 4.in add_sub > Warning: ELAB1_0026: add_sub.vhd : (76, 0): There is no default binding > for component "lut4".(No entity named "lut4" was found). > Warning: ELAB1_0026: add_sub.vhd : (90, 0): There is no default binding > for component "mult_and".(No entity named "mult_and" was found). > Warning: ELAB1_0026: add_sub.vhd : (97, 0): There is no default binding > for component "muxcy".(No entity named "muxcy" was found). > Warning: ELAB1_0026: add_sub.vhd : (105, 0): There is no default > binding for component "xorcy".(No entity named "xorcy" was found). > better the whole proram is here u ca run urself and u could debug the > errors > " http://www.opencores.net/cvsweb.shtml/risc5x/" > > pls pls pls pls reply >Article: 99383
Hello I’m wondering if there is any filter design software that can handle all required calculations in designing decimating or interpolating filters or iir and fir filters? ThanksArticle: 99384
Jim Granville schrieb: > The latest Serial memories from Winbond can stream at 150Mbd, from an > 8 pin package ! Uuups! > That makes even 100MHz look sluggish. > > There is talk of USB-JTAG, which is sensible, and that should be > high speed USB, in that case, FPGA suppliers SHOULD be working on > ~400MBd capable JTAG streaming. Really? But would this kick out the basic concept of JTAG being simple and low efford? I mean a normal JTAG chain runs just TMS/TCK as a single line from chip to chip and TDI/TDO in a daisy chain. Done. 400 Mbit/s would require diffent I/Os than plain LVCMOS etc. Hmmm. Maybe for some memories, but for all other ICs?? Regards FalkArticle: 99385
When working on the low level design of FPGA modules I usually draw out a data path timing diagram showing what's happening on each sucessive clock cycle. I have a word 'template' I've been using to do this for years, but I often think it might be quicker/more permanent/better for documentation if I used a custom Timing Diagram drawing program. A very quick search shows these seem to be the options.... 1) Chronology's Timing Designer http://www.timingdesigner.com/ 2) Synapticad's Timing Diagrammer Pro http://www.syncad.com/ttd_main.htm Top of the range all singing all dancing design tools for complex board design/analysis. Quite complex to use (?) with a reasonable learning curve. Cost ~ $1500 for 1 node locked license. 3) Timing Tool http://www.timingtool.com/ This seems to be an interim solution, although it looks reasonably powerful. Probably not as difficult to pick up as 1) and 2). Cost - $795 3a) Timing Tool Lite - a web based lower featured version of timing tool. I'd rather be working directly on my PC, although this is free. 4) Timing Gen http://www.xfusionsoftware.com/ Low end diagram drawing tool, this seems to be fairly new and doesn't include any analysis features. I'm not sure how flexible this is, they suggest importing things into Word to aid annotation etc. Cost - $129.95 I think what I'm lookign for is something between 3) and 4). This isn't essential so I don't want to spend $800 on it, but I think I'd like something a bit more capable than Timing Gen although I haven't experimented with it much, and it would be hard to beat for the cost. Can anyone offer opinions on the packages above or and other suggestions? Thanks in advance for any feedback, Nial Stewart ---------------------------------------------------------- Nial Stewart Developments Ltd Tel: +44 131 561 6291 42/2 Hardengreen Business Park Fax: +44 131 561 6327 Dalkeith, Midlothian EH22 3NU www.nialstewartdevelopments.co.ukArticle: 99386
fpga_toys@yahoo.com wrote: > http://www.fpgajournal.com/articles_2006/20060321_bell.htm > and also this one : http://www.eet.com/news/design/showArticle.jhtml?articleID=183702216 Here, AMIS claim 3000+ (rolling sum) FPGA->ASIC conversions. Atmel also have a ULC conversion program. -jgArticle: 99387
Austin Lesea wrote > John, Antti, > > I will say that if you place an order now, you will get a real delivery > date, and the parts will be shipped (we are not supply constrained for the > part numbers). Hmmm. I think John and Antti should be careful here. We were stuffed with XC3S200 parts because Xilinx' distribution gave us exactly the line Austin suggests. So we ordered a thousand or so thinking we would get a delivery date, and then go ahead or reschedule or cancel depending on the date. What happened was an immediate delivery, and they would not take the parts back. They will finally be used in RockyLogic's next product but one ;-) So be very careful if Xilinx' outriders in distribution give you the story: "we cannot give a delivery date until you place an order". We have hard evidence that you could end up warehousing Xilinx parts until your project is ready for volume manufacturing. And woe betide you if your requirements change during development - not that ours ever do! Not good.Article: 99388
Austin Lesea wrote: > Bob, > > We designed the PMCD so that the outputs all all matched within tens of > picoseconds across P-V-T. From there, you get onto the BUFGs, and you > end up with the usual +/-100ps rule for match between BUFgs. > > Austin, That is basically what I was told when Virtex I came out too, but it turned out that jitter on the DLL input could cause a spread between the 1x and 2x clocks (IIRC, I had specifically asked both here on the NG and through the hotline about the alignment of the 1x and 2x clocks and whether it was safe to cross clock bounds without extra logic and was told it was fine. I don't think anyone realized then what effect jitter would have on the relative phases of the 1x and 2x outputs. So my question is, I realize you've designed the PMCDs for tight tolerances, but how well does that stand up to jitter on the clock input?Article: 99389
Hi - I'm pretty happy with Synapticad. I can't comment on the latest version, as I dropped maintenance a while back: the verion of the tool I have (7.9-something) is plenty good enough. Doing timing diagrams with Synapticad is *so* much better than with conventional drawing tools. I'm convinced that I wouldn't do nearly as many timing diagrams if I didn't have Synapticad. Bob Perlman Cambrian Design Works On Thu, 23 Mar 2006 21:00:04 -0000, "Nial Stewart" <nial@nialstewartdevelopments.co.uk> wrote: >When working on the low level design of FPGA modules I usually >draw out a data path timing diagram showing what's happening >on each sucessive clock cycle. > >I have a word 'template' I've been using to do this for years, but >I often think it might be quicker/more permanent/better for >documentation if I used a custom Timing Diagram drawing program. > >A very quick search shows these seem to be the options.... > >1) Chronology's Timing Designer >http://www.timingdesigner.com/ > >2) Synapticad's Timing Diagrammer Pro >http://www.syncad.com/ttd_main.htm > >Top of the range all singing all dancing design tools for complex >board design/analysis. Quite complex to use (?) with a reasonable >learning curve. Cost ~ $1500 for 1 node locked license. > >3) Timing Tool >http://www.timingtool.com/ > >This seems to be an interim solution, although it looks reasonably >powerful. Probably not as difficult to pick up as 1) and 2). >Cost - $795 > >3a) Timing Tool Lite - a web based lower featured version of timing tool. > >I'd rather be working directly on my PC, although this is free. > > >4) Timing Gen >http://www.xfusionsoftware.com/ > >Low end diagram drawing tool, this seems to be fairly new and doesn't >include any analysis features. I'm not sure how flexible this is, they >suggest importing things into Word to aid annotation etc. >Cost - $129.95 > > > >I think what I'm lookign for is something between 3) and 4). This isn't >essential so I don't want to spend $800 on it, but I think I'd like >something a bit more capable than Timing Gen although I haven't >experimented with it much, and it would be hard to beat for the cost. > > >Can anyone offer opinions on the packages above or and other suggestions? > >Thanks in advance for any feedback, > > >Nial Stewart > > > > >---------------------------------------------------------- >Nial Stewart Developments Ltd Tel: +44 131 561 6291 >42/2 Hardengreen Business Park Fax: +44 131 561 6327 >Dalkeith, Midlothian >EH22 3NU >www.nialstewartdevelopments.co.uk > > > > > > > >Article: 99390
bijoy wrote: > Hi > > I have a board with Spartan-3e-100VQFP FPGA mounted on it. > > I am using SPI flash (M25p20 ) from ST, to store the configuration bit map. > > After power-on, the FPGA's starts configuring (INIT-B goes high), then it comes to low. and DONE pin does not go high. Generally INIT going low means you have a bitstream error that is caught by the CRC detection logic. I would check that the data in the SPI flash is correct for the part you're using and that the bit order within bytes is correct for the stored format. How did you generate the data for the SPI? Did you make a "serial PROM" image using promgen (or impact)? > > All power suplly is correct. > > CCLK is coming but about 1.3 MHz and other signals like CSO_B,DIN some data is coming. > > But i am not able to trace why the configuration fails. > > May I get any help from you guys.. > > Thanks in advance... > > bijoyArticle: 99391
Tim, If you order them, they will arrive. I think that is how it is supposed to work? Sometimes sooner, sometimes on time (and the objective is to never be late). So don't blame us that we delivered an order, please! If you did not want early delivery, then you have to change the terms, and get the distributor to agree to that. I didn't say (in my previous post) "place an order," I said to contact your FAE for exact details on the part you want. Unless, of course, you do want a part, then please do place an order. Austin Tim wrote: > Austin Lesea wrote > > >>John, Antti, >> >>I will say that if you place an order now, you will get a real delivery >>date, and the parts will be shipped (we are not supply constrained for the >>part numbers). > > > Hmmm. I think John and Antti should be careful here. > > We were stuffed with XC3S200 parts because Xilinx' distribution gave us > exactly the line Austin suggests. So we ordered a thousand or so thinking we > would get a delivery date, and then go ahead or reschedule or cancel > depending on the date. What happened was an immediate delivery, and they > would not take the parts back. They will finally be used in RockyLogic's > next product but one ;-) > > So be very careful if Xilinx' outriders in distribution give you the story: > "we cannot give a delivery date until you place an order". We have hard > evidence that you could end up warehousing Xilinx parts until your project > is ready for volume manufacturing. And woe betide you if your requirements > change during development - not that ours ever do! > > Not good. > >Article: 99392
As Symon indicated, you should look into multi-rate filtering. Basically, decimate by 2 in 3 stages. Each subsequent stage works at half the data rate, and the length of the earlier filters needn't be as long as the later filters. That said, 61 taps is not outrageously long, (although by using multi-rate, you'll be able to at least reduce the sample rate of your longest filter). There is a paper by Goodman and Cary from the 70's that details a set of small half-band FIR filters (half the coefficients are zero) for decimating in multi-rate systems. Also, the decimating filter sections can be reduced using polyphase decomposition so that the filter sections run at the output sample rate rather than at the higher input sample rate. That sample rate reduction also allows you to make the filter physically smaller by using more than one clock per sample. The Goodman-Cary F8 filter is a 15 tap filter that has 5 unique non-zero coefficients. Through symmetry folding and polyphase decomposition, and using distributed arithmetic, filter breaks down into a 4 tap filter and a constant multiply added together, and it provides about 65db stopband attenuation and a reasonably steep transition. You'll have to work through the chart for you application, but you'll probably find you can use something like and F3, F5 and F8 filter in cascade to get attenuation in the aliased part of the stopband and a flat response in your final passband. A CIC filter would probably not buy you much here, as it basically takes the place of the F3 filters in the early part of a decimation chain as far as response curve goes. Where your total decimation is only by 8, the CIC is probably not going to buy you anything. CIC comes in really handy is where you have either a high decimation ratio, or a decimation ratio that has to be programmable. Your stated sample rates are actually quite low for an FPGA. You can easily run the FPGA clock at around 80 MHz without any special design considerations and do the whole filter serial, sequential or serial-sequential at a considerable area savings. (serial would be using distributed arithmetic, in which case you need a 16x clock, sequential uses one multiplier to multiply and accumulate several taps: basically timesharing the hardware). You may also find a FIR filter implementation for your final filter may be easier to deal with than an IIR implementation because you can generally getr by with far fewer data bits and the response is not subject to limit cycles and instabilities caused by finite precision of a fixed point implementation.Article: 99393
I'm working on a V2Pro design that needs to have a small
portion operate at over 400 MHz. As I've looked into the
timing, I've noticed that similar routing between slices
seems to have different timing delays. For example:
Location Delay type Delay(ns)
-------------------------------------------------
SLICE_X34Y1.YQ Tcko 0.374
SLICE_X34Y3.BY net (fanout=1) 0.614
SLICE_X34Y3.CLK Tdick 0.202
-------------------------------------------------
Total 1.190ns
**************************************************
Location Delay type Delay(ns)
-------------------------------------------------
SLICE_X66Y42.YQ Tcko 0.374
SLICE_X66Y44.BY net (fanout=1) 0.407
SLICE_X66Y44.CLK Tdick 0.202
-------------------------------------------------
Total 0.983ns
Note that both circuites route from a YQ output, jump two slices,
then go to a BY input. Yet, the net delays vary by 200 psec.
Ideally, I'd pack the 2 flip-flops in one slice, but in my design they
are clocked by opposite clock edges as I convert a DDR signal from
the negedge into the posedge domain.
Can anyone explain the difference in interconnect delay? Does
Xilinx publish anything that really explains how to get the
shortest routing delay?
Thanks!
John Providenza
Article: 99394All, For "burger counts": http://www.xilinx.com/prs_rls/silicon_vir/0397v10mil.htm (July 7, 2003) http://www.xilinx.com/prs_rls/silicon_spart/0471spartanleadership.htm (June 17, 2004) http://www.xilinx.com/prs_rls/silicon_spart/04105_1mil_s3.htm (September 21, 2004) http://www.xilinx.com/prs_rls/silicon_vir/0413790nmmilestone.htm (December 27, 2004) http://www.xilinx.com/prs_rls/silicon_spart/05118_90nm10mil.htm (December 20, 2005) http://www.xilinx.com/prs_rls/2006/xil_corp/0629_v4b.htm (February 28, 2006) And now, AMI... AMIS: FY 2001 2002 2003 2004 2005 $$ 326M 345M 454M 517M 504M SA 0 0 96.7M 119M 110.4M So, let me get this right, in 20 years, they have converted 3,000 FPGA designs to ASICs. And, in the last three years they have redefined part of their business segment, and called it 'Structured ASICs', and revenues were down this year from last. Anyway you cut it, it doesn't look pretty. The gross margins also look rough (anyone out there ever worked for a company with ~ 40% GM? not fun at all...bring your own hand towels time). That makes structures ASICs flat to down for 2004 to 2005 for AMI. This is similar to MacDonalds giving the bizillionth customer who orders a prize -- it tells you nothing, other than someone got lucky. Now a history of increasing 'burger counts', that at least tells you something. In this case, the 3,000th conversion customer got lucky: they got a working part! In all fairness, more power to AMI: they have been in this business for a very long time, and they obviously know how to make money in it. The other link for the FPGA journal is much more interesting (Kevin is pretty sharp!): (from his article) (when asked 'is structured dead...') "Our answer to these questions is an emphatic "no." The reasons behind LSI's strategy shift are complex and somewhat company-specific. No company can do everything at once and do it well, and smart executives know how and when to focus their company's energies on the projects that will bring the most return and growth and that capitalize on the organization's unique strengths. LSI had good momentum and competence in the storage and consumer markets, and those made sense as a place to focus the company's remaining resources in a difficult business situation." I call this the 'apologia' as it is the restatement of the company line why they left the business (even though they were #1). LSI found the business did not fit. It happens. "The part of the situation that isn't company specific is the orthogonal trend toward domain-specific optimization of silicon platforms. This specialization can be seen across industries and across silicon technologies. With the exception of full-blown ASIC, every customizable silicon technology makes some serious technical compromises. For FPGAs, these compromises are obvious in the LUT fabric which gives away an order of magnitude or so in speed, density, and power consumption for the privilege of reprogrammability. In structured ASIC and in non-volatile FPGA technologies like antifuse, the configurable fabric penalty is smaller, but still significant. Every vendor's solution to this problem is the same – create ASIC-like hard IP blocks for critical functions." Here Kevin answers the reasons why (that he artfully dodged earlier), without saying that LSI realized it was failing. He basically says: this business is really tough! You never have the right mix of IP, etc. Back to Kevin: "Hard IP can take large, performance-critical hardware, like multipliers, memory, and high-speed I/O standards, and implement them much more efficiently than a designer attempting to put that same capability in the programmable or customizable part. This gain comes at a cost, however. Every customer that doesn't use a particular function that is hard-wired on the chip is essentially paying for wasted silicon. The juggling act for semiconductor companies, therefore, is to decide which functions (and how many) should be hardened in order to give the best mix of performance and cost optimization. For example, if your customers are doing high-speed digital signal processing (DSP), it probably pays to put a number of hard-wired multipliers on your chip. Even then, however, the question of "how many" poses a challenge. Do you need ten? A hundred? A thousand? The particular application area determines the answer." So, the 'trick' is to know the customer, and know what 'works'. The way to tell if a company knows these things is to keep track of their financials. AustinArticle: 99395
Falk Brunner wrote: > Jim Granville schrieb: > >> The latest Serial memories from Winbond can stream at 150Mbd, from an >> 8 pin package ! > > > Uuups! > >> That makes even 100MHz look sluggish. >> >> There is talk of USB-JTAG, which is sensible, and that should be >> high speed USB, in that case, FPGA suppliers SHOULD be working on >> ~400MBd capable JTAG streaming. > > > Really? But would this kick out the basic concept of JTAG being simple > and low efford? I mean a normal JTAG chain runs just TMS/TCK as a single > line from chip to chip and TDI/TDO in a daisy chain. Done. 400 Mbit/s > would require diffent I/Os than plain LVCMOS etc. Hmmm. > Maybe for some memories, but for all other ICs?? The other postings have shown that the long lengths of JTAG chains still can cause problems, even at 5MHz. Maybe if it was called a 50MHz bus, more care would be taken :) 66-75MHz is now pretty standard for SPI devices, so it's about time the JTAG caught up a little... I'd suggest a Std Schmitt on the TCK, and then use the FPGA IO features for the rest - so it does not have any real additional cost. ie you go to whatever the FPGA and PCB allow, and do not limit to 5-10MHz. Clearly one would not chain at 400Mhz, but there is a case for fast loading to one device, or a star network, to load many, at very high speeds. Anyone got numbers on how fast the JTAG can clock, on the new 65nm Xilinx FPGAs, curently in the Labs ? -jgArticle: 99396
Johnp, The simple answer is, no, we don't publish the information you are asking for, as we have practically no reason to support 'hand crafted' designs (results in too many unhappy people -- been there, done that). Does the path in question span a BRAM column? That would be one reason for the difference. Generally, differences are real, and we know they are there, and they are ususally there for a very good reason (that is the way it was in layout). The "accepted" way of doing this, is to create a macro or block with its own contstraints, hard fixed or relatively fixed, and let the tools place it properly...but I admit that doing that is tough to fight the tools to squeeze ps out of a design. Resorting to FPGA_Editor, and just placing it exactly where it belongs and works is easier. It is just hell to support, and maintain. There are many on this forum who know how to squeeze and navigate, and do what you need done, but I suspect they get paid for that knowledge... Austin johnp wrote: > I'm working on a V2Pro design that needs to have a small > portion operate at over 400 MHz. As I've looked into the > timing, I've noticed that similar routing between slices > seems to have different timing delays. For example: > > Location Delay type Delay(ns) > > ------------------------------------------------- > SLICE_X34Y1.YQ Tcko 0.374 > > SLICE_X34Y3.BY net (fanout=1) 0.614 > SLICE_X34Y3.CLK Tdick 0.202 > > ------------------------------------------------- > Total 1.190ns > > ************************************************** > > Location Delay type Delay(ns) > > ------------------------------------------------- > SLICE_X66Y42.YQ Tcko 0.374 > > SLICE_X66Y44.BY net (fanout=1) 0.407 > SLICE_X66Y44.CLK Tdick 0.202 > > ------------------------------------------------- > Total 0.983ns > > Note that both circuites route from a YQ output, jump two slices, > then go to a BY input. Yet, the net delays vary by 200 psec. > > Ideally, I'd pack the 2 flip-flops in one slice, but in my design they > are clocked by opposite clock edges as I convert a DDR signal from > the negedge into the posedge domain. > > Can anyone explain the difference in interconnect delay? Does > Xilinx publish anything that really explains how to get the > shortest routing delay? > > Thanks! > > John Providenza >Article: 99397
Try posting this question to comp.dsp... "Bubb" <bubb@telia.se> wrote in message news:44230509$0$15784$14726298@news.sunsite.dk... > Hello > > > > I’m wondering if there is any filter design software that can handle all > required calculations in designing decimating or interpolating filters or > iir and fir filters? > > Thanks > >Article: 99398
Duane Clark wrote: > Stephen Williams wrote: >> What I would really like something that can write Xilinx .ACE files. >> The impact from Foundation 6.2 is terribly slow, and from Webpack8.1 >> is pretty flakey. (It wrote ace files everywhere but where I wanted >> them.) >> > > I'll agree that the interface is not particularly intuitive, but the > main limitation I see is that the ace files must always be placed two > directories deep. I've used Impact from ISE7.1 on Linux regularly, and > had no problems at all. I haven't used the 8.1 version much, but a quick > test seems to indicate that it works the same. When I wave my hands over it just right, it does. But for a few days I found it writing jtr/jtr/jtr.ace files in the most surprising places, including in jtr/jtr/jtr/jtr/jtr/jtr.ace, $HOME/jtr/jtr/jtr.ace, $(CWD)/jtr/jtr/jtr.ace, and a few other places I haven't thought of. I'm still occasionally finding jtr.ace files here and there. > Arrgg... I just noticed that the ipf project files have switched from > plain text in version 7.1 to binary in version 8.1. > > Hey Xilinx, please take a poll of your paying customers. We don't want > binary project files! And then there's that. -- Steve Williams "The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, http://www.icarus.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep."Article: 99399
Austin - Thanks for the comments. I'm just frustrated because if I run multi-pass P&R, the tools can find a solution that meets timing, but I don't see any hints as to how to use RLOCs to force the critical cells into magical alignments that produce the smaller interconnect delay. John Providenza
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