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
"Peter Alfke" <peter.alfke@xilinx.com> schrieb im Newsbeitrag news:3CBEF902.77945FC@xilinx.com... > Yes, the XC2V6000 is in production, and it has 1,104 user I/O pins in the FF1517 > package. The small-quantity price is several thousand dollars. You can find it > listed at the distributors web sites. ( insight-electronics.com, avnet.com, > nuhorizons.com,) Question is, does he really need the pins AND logic, or just the pins. Maybe its a good idea to have some low cost, low capacity FPGAs to handle the IOS, bundle the data stream, and process it in a not so big FPGA. -- MfG FalkArticle: 42226
I am using xilinx foundation series software, In simulations, I have found that if you try and address a memory location higher than 1023 on the rams on the virtex e there is an error. i.e every time you set the 10 or 11 address lines to 1, on any of the 12 bit addressable RAM's (B4RAM_S1 etc). Please could someone tell me if this is a software problem and how i can fix it so i can use the full 12 address lines on the RAM's rather than just the first 10.Article: 42227
Martin E. wrote: > What is it with HDL programmers? Is there a fobia for commenting code? I > mean, huge app notes for things like synthesizable DDR RAM code and > virtually not a single comment to be found! Designers writing production code are more motivated to document design intent than ap note writers are. A historical aspect is that programmable devices used to be much smaller and the default HDL writer used to be a pcb designer in a big hurry. As more engineers become full time coders, I expect that quality will improve. > A hands-on, practical, "this is how you do this" book would be of value to > beginners and advanced HDL programmers alike. I'd pay $150 for a book like > that. There is an economic problem in writing books for a niche market. It takes a year of full time work and the publisher would only sell only a few thousand copies. The author might get $10 a book. -- Mike TreselerArticle: 42229
So you're talking basically about an XC2V6000. We've been paying several thousand dollars each for these. What speed are we talking about anyway? Regards "Sum" <anonymous@nospam.invalid> wrote in message news:<a9mink$arv$1@wanadoo.fr>... > "Steffen Thieringer" <steffen.thieringer@nmb.co.uk> a écrit dans le message > news: a9mf36$4g6ga$1@ID-41871.news.dfncis.de... > > > > "UK Gary" <deton8@aol.com> schrieb im Newsbeitrag > > news:a9m9g1$28d$1@helle.btinternet.com... > > > I need to design something where the FPGA must have about 1000 I/O pins. > > > What is my cheapest option? The design must fit into a single FPGA, but > > > apart from that and the pin count I don't have any special requirements. > > > > Upcoming Altera Stratix devices do have more than 1000 I/O (up to 1310)! > > > > http://www.altera.com/products/devices/stratix/overview/stx-overview.html > > Xilinx Virtex-II have more than 1000 I/O (up to 1108) and they are not > upcoming ! > http://www.xilinx.com/xlnx/xil_prodcat_landingpage.jsp?title=Platform+FPGAsArticle: 42230
Correct me if I am wrong, but I think its up to you to constraint the pins with respect to the simultanous switching rule. -Manfred KrausArticle: 42231
Steffen Thieringer wrote: > > "Russell" <rjshaw@iprimus.com.au> wrote > > > How about just using a smaller fpga as a dedicated pwm/timer peripheral > > for a cpu. Better still, a motor control dsp. > > sure, a motor control dsp solution is better, but not done in 10 minutes. > i need a driver now, and for the changeover (8051-hardware to dsp-hardware) > i want to go for the 8051 software. > > the way to go for a speeded up 8051 ip-core is for using a program which has > done the job very well on 8051 hardware, but became obsolete because of > speed. First check out the fast 80C51s : www.Cygnal.com - Single clock, 25 MIPS, Mixed signal/PWM/ADC Dallas Semi - Single Clock, 50 MIPS Sharp - Mentor M8051 core, 2 clocks, 24 MIPS, Mixed signal, smart PWM (new) A FPGA will struggle to deliver a CPU core + Code memory that competes with available 80C51, and will find Voltage references, and ADC's very difficult. FPGA will do PWM and Timers easily, but is typically a 3 chip solution : FPGA + Loader + ExternalCode Memory. Mentor offer a soft-core 8051, that Sharp use in their device. Seems a better tack would be Fast C51 + CPLD/FPGA PWM logic, or if it's a complex inner control loop, move that small but critical SW function into FPGA HW. eg Sharp have a interesting idea, of a dual port scanning memory for their DACs, targeting motor control. - jg -- ======= 80x51 Tools & IP Specialists ========= = http://www.DesignTools.co.nzArticle: 42232
If you use this device, could someone please contact me immediately! We have 210pcs in stock that we can no longer use. They are factory sealed, factory original, new parts. Avnet, Insight, NuHorizons, Digi-Key, etc. sell these for $1,100.00+ EACH (!!) I will let whoever needs them have the parts @ $580.00 per chip. We paid $1,160.00, and are willing to take a 50% hit in order to re-claim some of our money for other projects. Please call me Toll-Free @ 888-690-8899 x40. Thanks!! -- Posted via Mailgate.ORG Server - http://www.Mailgate.ORGArticle: 42233
In article <a9m9g1$28d$1@helle.btinternet.com>, UK Gary <deton8@aol.com> wrote: >I need to design something where the FPGA must have about 1000 I/O pins. >What is my cheapest option? The design must fit into a single FPGA, but >apart from that and the pin count I don't have any special requirements. Why? Could you possibly split the design into 2 or 4 parts, with some of the parts using high speed dedicated IOs to interconnect them? Harder design, but it may be MUCH cheaper. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 42234
Vaggelis, This is a known issues too: Follow this answer: http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=10717 Cheers, Hari.Article: 42235
Jay wrote: > So you're talking basically about an XC2V6000. We've been paying > several thousand dollars each for these. Somewhere around $2000? Is anyone using these in volume? Does anyone have a projection on when these parts go below $1000 (in hundreds, not thousands)? How about $500?Article: 42236
There is a also an equivalent limitation for simultanious switching outputs in ASIC's as well. Basically you can't try to dump a ton of current out one side of the chip (ASIC or FPGA) all at once because the supply pin inductance is too high to do so without significant voltage droop. Its usually not as big an issue in FPGA's because they generally operate at low frequencies (and thus lower required edge rates) compared to the ASIC cousins. So do the tools automatically handle this? The answer is no, but it most cases your FPGA emulation of your ASIC will be a in a completely different package anyway. Ways to help SSO (simulatanious switching outputs) 1) Use the slowest edge rate you can get away with 2) Use the lowest current driver you can get away with 3) Don't use flops in the output cells they tend to synchronize (by design) the output changes. Regards Sujatha Sriram <sujathasriram@yahoo.com> wrote in message news:<3CBE8A79.FB53A92C@yahoo.com>... > I have read that there is a limitation to the number of adjacent output > drivers that can switch at the same time in an FPGA. There are rules > stated in terms of SSO(simultaneous switching outputs) pads between > power/gnd pins. Can anyone please elaborate on that.. > In such a case, consider a RTL written for ASIC, and say it has to be > prototyped. Tools are used to partition the design into multiple FPGA's. > How is this condition taken care of by the tool. Does it place the > interface signals taking the limitation into account? or does the > designer have to take care of it manually.. > > > >Article: 42237
In article <1019161867.29969.0.nnrp-13.9e9832fa@news.demon.co.uk>, Tim <tim@rockylogic.com.nooospam.com> wrote: >Jay wrote: > >> So you're talking basically about an XC2V6000. We've been paying >> several thousand dollars each for these. > >Somewhere around $2000? Is anyone using these in volume? > >Does anyone have a projection on when these parts go below >$1000 (in hundreds, not thousands)? How about $500? Probably never, those things are BIG. According to what I've heard, if xilinx can yield 3/wafer, they have customers who'd buy them. Which, by delidding the largest chip, gives you an idea of the defect density of the process they are using. At a few thousand $$$/wafer for just manufacturing, I doubt you will ever get the parts to drop THAT much in price, even in large volume. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 42238
Nicholas, Don't forget about the EasyPath program: up to 70% off for a part that does exactly what you want it to do. For details: http://www.xilinx.com/prs_rls/silicon_vir/0248easypath.html As for commenting on yield, that is considered Proprietary and Confidential. I will say that in 12" fab, in a few months, the yield will be much improved (from whatever it is today - 'good' or 'bad' - do not assume anything, as it is nothing but idle speculation, or unfounded rumors from disgruntled competitors). Intel already announced that fab in 12" resulted in better gross margins. No secret here. That is why it is always a safe bet to wager that the present technology will be the least expensive in time. Otherwise, why would we be so hell-bent on shrinking geometries? Check out the finanical news for Xilinx for last quarter: that will give some insight into the comments above. AustinArticle: 42239
I've noticed the same thing over the years also. I'm thinking that maybe the lower paying jobs like tech jobs require 2 incomes to support a household with children. The kids have to be at school early anyway, so they just go from dropping kids at school to work. I've had similar frustrations with needing tech support late in the afternoon and everybody has just taken off (gotta get my kids!). My solution- learn to work the tools yourself, if they can be trained to do it, you can too. And to answer the timing problem question: sounds like you've got an asynchrounous timing situtation with at least 3 different domains. FPGA tools don't like this, they want it nice simple single clock design. Many static timing checks won't even try to check between domains. Make sure you're interfaces between domains are bullet proof, so that regardless of phase, no setup-hold violations will happen. Think about a DataReady/Acknowledge protocol. The issue of having different behaviour for each P&R kind of points in the direction of relying on some timing that is not guaranteed. You never want to have a design that you can't turn at will. If seen this too many times to mention "Don't rebuild the FPGA, last time it took 10 trys to get it to work!" Regards John Larkin <jjlarkin@highlandSNIPTHIStechnology.com> wrote in message news:<Xt68PBLDZOsrEop6+udYs5ye81GL@4ax.com>... > Why is it that all the production people like to get to work real > early and then leave early, while the engineers arrive late and work > late, so that when you really need a big chip replaced there's nobody > around to do it for you? > > JohnArticle: 42240
Jay, I disagree with 3, below, as we take this into account when we design our IOBs. The SSO guidelines in the datasheets takes into account both AC and DC currents (ie for DCI), so that it makes design easier. It is a manual operation, however. The guideline does assume near perfect bypassing. By that I mean that if you can not bypass every power ground pin pair with a cap, then the guideline must be reduced by the reduction in bypassing. Near perfect bypassing is a cap from 0.1uF to 0.01 uF (not much difference) 604 surface mount, with at least two vis at each end abutting the pads to the power planes, along with some lo esr tantalums (maybe 1 390 uF or larger) per IO bank. Traces to pads, minimum via diameters, are all very bad for ground bounce. Flip chip packages, and minimal inductance is very good for minimizing ground bounce. After all, V= - L di/dt. As for low frequencies, 420 MHz in Virtex II, and 500 MHz in Virtex II Pro doesn't sound all that low to me. Wake up: FPGAs are right up there with the ASICs.....and we are available NOW. About the time you finish that ASIC that you claim beats us flat out, we will already have our next generation, after the next one, and still be ahead. Austin Jay wrote: > There is a also an equivalent limitation for simultanious switching > outputs in ASIC's as well. Basically you can't try to dump a ton of > current out one side of the chip (ASIC or FPGA) all at once because > the supply pin inductance is too high to do so without significant > voltage droop. Its usually not as big an issue in FPGA's because they > generally operate at low frequencies (and thus lower required edge > rates) compared to the ASIC cousins. So do the tools automatically > handle this? The answer is no, but it most cases your FPGA emulation > of your ASIC will be a in a completely different package anyway. > > Ways to help SSO (simulatanious switching outputs) > 1) Use the slowest edge rate you can get away with > 2) Use the lowest current driver you can get away with > 3) Don't use flops in the output cells they tend to synchronize (by > design) the output changes. > > RegardsArticle: 42241
Firstly let me reiterate one thing I originally said: > You may think I absolutely loathed the book. That's not the case as it does present some useful cookbook-style topics, but its lack of a coherent presentation style, poorly chosen example code and in the end is a missed opportunity < That doesn't mean the book is worthless. It means I had high expectations and a combination of poor presentation in places and 'thorough' code examples rather than illustrated snippets with the full code on the CD made me think it was a missed opportunity. My previous review was a little unfair in that I mainly criticised style and layout but didn't applaud what I do like about this book. Ben has spent time with all of these designs. He has created simulations and shows you timing waveforms and in most cases an RTL view. We all know this takes time and helps our understanding of the results. There are some diagrams that Ben has created that really do bring home the ideas. For instance I'm currently looking at figure 3.5.5 which clearly showed a dual clock FIFO with its control logic and the clocking associated with all that logic. Diagrams like that are invaluable to understanding. There are topics here that are not covered particularly well in app notes which Ben has expanded upon, so all in all I don't doubt that some of the information will be invaluable to everyone. I am certainly unhappy about the way my first review may have belaboured the issue of lack of original content. Yes there are whole sections almost lifted from app notes, but they are usually expanded, and there are certainly many other sections that Ben has created original content or summarised from multiple sources. As such this will no doubt save valuable time for the engineer. Now onto the reply itself... "VhdlCohen" <vhdlcohen@aol.com> wrote in message news:20020418130404.01584.00001197@mb-mg.aol.com... > <I'm afraid that the ad-hoc style of presentation with poor and > inconsistently styled diagrams is the first thing to hit you. > Tables of text that look like they were converted to bitmap and then > stretched are really unacceptable in this day and age. Same applies to > certain equations (how long would that have taken to typeset > properly?)Probably an easy way of scanning source material though :( > You quoted this IMHO valid criticism and then talk about unrelated issues. In fairness I should say that this is only distracting in a few places though. The MTBF section is a particular mess with pixellated equations, a spreadsheet where you can't actually see the numbers (well the all important exponent digits). Its a shame that things like timing diagrams couldn't have been exported to one tool for a consistent polished display. Instead we have a combination of about four or five different simulators/waveform display tools or styles of which one or two look quite dreadful on the page. I know many tools make it difficult to get a good waveform display but we've probably all found ways round this if such waveforms need to be presented in a customer report. I say all this because quite apart from being distracting, it makes it difficult to see the information you're trying to view. > BEN: The goals for the book "Real Chip Design and Verification Using > Verilog and VHDL" were: > 1. Address issues that I experienced with designers who thought that > knowing an HDL meant that you were ready to do designs. That in why > in the chapter on Fundamentals, I covered with guidelines, the topics of > reg, latch, 2 edges of clk, and various types of counters (e.g., LFSR, > Johnson, etc), memories, primitives, and clockboost). It is true that > some material were extracted, with permission, from various vendors and > authors. However, the object here was to put relevent information in > one place. I have not criticised your choice of topics. On the whole I was very pleased with them. Better arrangement of the topics into chapters would definitely have helped though. > 2. Address the topic of asynchronous signals. Again, you'll be surprised > as to the number of engineers who fail to understand how to deal with that > issue. Agreed > 3. Verification: Here I used 2 examples: a counter and a memory with EDAC. > I was working on a project that spent many many (really many!) hours on > the design and verification of a memory with EDAC, anyway, far more than > the $80 cost of the book. Cost of the book isn't an issue. I certainly know just have long it takes to do this kind of thorough job. > 4. Design process in defining a control machine: I have seen horrible code > an processes in the definition of such design. Here I attempted to define > a usable, and hopefully practical approach with a process, or a flow. Yep > 5. In arithmetic machines, I was defining the usable packages, and issues > with Verilog. > 6. Mixed simulation is something that is common now because many vendors > require Verilog for the release sims, and many IPs come in Verilog (at > first). > 7. I wanted to present Verilog as an HDL for several reasons: > a. Verilog is really gaining in popularity. > b. Many IPs come in VErilog first. > c. Release sioms are often required in Verilog. > By demonstrating designs in both HDLs, my intent was to facilitate the > transition from one HDL into the other, and to sho that the real design > issues are not necessarily the HDL, but the process and architectures. > I also includes a tutorial of Verilog for VHDL users to explain the > differences between the two HDL. A cookbook of ideas/things you should know is one thing, a book describing the transitions between VHDL and Verilog is another. I don't think the two ideas sit well together in one book as it often leaves part of the readership out. That said, the Mixed simulation chapter is a useful adjunct to even a VHDL-only book. > <Granted there's a CD with a lot of the files on, and the book does > provide a central repository, but I don't think that justifys the expenditure > of your effort> > The book sells for $80. If you can do better thatn than by searching >things on the web, extracting meaningful info, print the material needed > for less than $80, my hat goes to you! I deliberately DID NOT mention money as you are right, it isn't at all expensive in this field of publishing. I also think I was a little unfair, in that I perhaps expected too much of this book. I see lots of mainly presentation issues that stop this book being a must-have book. Perhaps that's where most of my frustration lies. This book was SO close to being a classic as you have all the content required just not the execution of bringing it together. If you were to republish this content having tidied up the diagrams/tables (and removed that annoying Synplicity/Synplify pro or Cadence NC next to every other diagram), rearranged the chapters and maybe presented it as two volumes ( a VHDL and a Verilog volume) you really would have an instant classic. Economic realities probably mean this wouldn't be possible but its hopefully a clear indication that I do think highly of the content. If an engineer is prepared to take the time avoiding the pitfalls, he will come away having learned something valuable. > <There are items that everyone from newcomers to moderately well-versed > HDL engineers will learn, but it isn't presented in a coherent style, > instead my impression is that its stitching articles together in the hope > of getting a book published quickly> > You are entitled to your opinions. If you feel cheated after receiving > the book, you may return for a refund. However, the reviewers of the > book, including corporate VPs from Cadence and Synplicity really felt > that the book had a lot of values as an investment. I'm afraid your need to put a Synplify or Cadence tag line next to half the diagrams rather than a simple acknowledgement at the start did rather temper my opinion of the validity of these reviews. I look forward to viewing other independent reviews. > By the way, writing a book, and going the process of publishing (wheter > thru a major publisher or self-publishing) is not a "quick" manner and > DOES take many, many hours of work, particularly when the code has > to also be verified and explained. It also does take research on the web, > something that was brought up as a "trivial manner, not worth the effort > of the consolidation of the necessary, and filtered information". I never suggested it was 'quick'. I also did not suggest that research on the web was at all trivial. In fact I don't recall seeing your quoted statement in the thread. I personally find the internet an invaluable source of such information and know how time-consuming it can be to take some information and validate it yourself. > I hope that this explanation provides some info as to why I wrote the > book. I know that I did my best, and with a lot of effort. Style is an > issue own by the beholder. My style, like it or not, is by complete > example and graphics. If anything the book tries too hard to give too much content at the expense of polish. My opinion only. I really look forward to future books aiming to provide this sort of cookbook style guide to hard-fought design tips. I wish Ben well with this and I hope many other books in the future. Paul BaxterArticle: 42243
On Thu, 18 Apr 2002 11:07:55 +0200, "Steffen Thieringer" <steffen.thieringer@nmb.co.uk> wrote: >Hello newsgroup! >I am looking for a 8051 Core to implement in an Xilinx Spartan2 FPGA. >The task for it is a control of a sensorless brushless DC motor. >The software for the processor is already done but needs to be speeded up. >So i need pwm, capture/compare units, several timers ans so on... >I have several in my mind but not yet found 'the one'. >I am not looking for freeware, but if there are some out there, please let >me know:-) > >Thanks in advance > >Steffen Thieringer > Since you want custom peripherals with an 8051, this seem like an excellent opportunity for you to look at the Triscend E5. http://www.triscend.com/products/indexe5.html Philip Freidin FliptronicsArticle: 42244
On Thu, 18 Apr 2002 14:40:47 +0200, "Stefano M" <stefano.mora@antispam.libero.it> wrote: >Hi everybody, >i'm using WebPack by Xilinx and in particular the >Schematic Editor. >How can i draw (and how can i specify) grafically >a 4-bits vector starting from a 8-bits vector ? > I haven't used this sw, but usually you do it by drawing a sub-bus with then required range. I.e. if you have a bus line drawn, and the signal label is data_bus_[7:0] , then if you attach another bus line and label it data_bus_[5:2] you will have extracted the middle 4 bits. If you want to rename a bus, you usually do this by passing the signals through a BUF symbol. I.e. connect data_bus_[2] to the input of a BUF, and label the BUF output net new_bus_[0] (in some schematic systems, the brackets must not be included for single signals) >Where i can find a description of some library >modules ? Example: what's the difference between >CC8CE and CB8CE counters ? Look in the libraries guide sectio of: http://toolbox.xilinx.com/docsan/xilinx4/manuals.htm >Thanks a lot ! >Bye Good luck, Philip Freidin Philip Freidin FliptronicsArticle: 42245
Both Altera and Xilinx compete for this application, nobody else is even close to being as large. Both vendors have very capable parts of similar density. If one of them has a special feature that you can directly deploy (Built in ARM9 as one person mentioned), this might be the deciding factor. Don't worry about probing the ARM busses because in general, for pin densities like this, you're going to want to use one of the great embedded logic analyzer functions that these 2 vendors offer. The speed will be much less than your ASIC unless you are willing to spend alot of time writing FPGA specific code. On all the projects I've done, we always seem to end up about 1/4 speed of the real part we are emulating. Size- The biggest FPGA isn't that big by comparison to ASIC standards. Remember, the FPGA is likely build with the same process technology that your ASIC will be. The considerable overhead of the general purpose layout really cuts into your effective density. My advice, get a temp license if you can and compile your source code to FPGA LUTs before your buy your proto hardware so you know if you're buying enough LUTS in your FPGA protoboard. On one of my ASIC proto projects we ended up scaling the design to fit in the available gates. And no, it wasn't a identicle source code data base, but the emulation was still an invaluable tool. "Peter Ormsby" <faepete.deletethis@attbi.com> wrote in message news:<q2Bt8.4749$c6.413595@typhoon.mn.ipsvc.net>... > Gil, > > It might be worth your while to take a look at Altera's Excalibur ARM FPGA. > > It's a device that put an ARM 922T processor on the same die as a 100K, > 400K, or 1M marketing gate FPGA array (if you have good idea of the number > of registers in your design, it's better to use that to determine size > requirements rather than ASIC gates). Inside the Excalibur part, the ARM > will run at 200 MHz and is attached (via AMBA AHB bus) to 256K Bytes SRAM, > 128K Bytes dual-port SRAM, an SDRAM controller, a serial port, and several > other peripherals. The device is available today and Altera sells a > development board with the 1M gate version of the part on it. The > development board also has PMC connectors on it for expansion daughter > cards. You can get more details on Altera's web site. > > In case you're not familiar with the clocking differences between an FPGA > and an ASIC, I should point out that the much-used practice of gating clocks > in ASICs is generally a big no-no in FPGAs. Synplicty's Certify is a tool > which can convert gated-clocks in your design to the more FPGA-friendly use > of clock enables if you don't want to do it manually. There's sort of a > trade-off between keeping your design as close to your ASIC as possible > (gated clocks) and getting the most speed out of the FPGA (clock enables). > > -Pete- > > Gil Herbeck <gil@radix20.com> wrote in message > news:3CB61C7B.700@radix20.com... > > I need to prototype an ASIC design and am looking for > > advice on type of FPGA and on FPGA board as well. > > > > The board needs to have an ARM9, external memory, an > > interface to a PC (serial is ok), the FPGA (or ASIC), > > and a header to plug in a daughter card with some pins > > routed to the FPGA. > > > > The ASIC will have between 100K and 500K ASIC Logic > > Gates. It will run at about 150 MHz. It needs about > > 200 KB of internal RAM. And it will have a lot of > > multipliers. There will probably be some pipelining > > in the ASIC to meet speed - and probably deeper pipes > > in the FPGA. We want to match the FPGA to the ASIC > > as closely as possible. > > > > I think the key factors in FPGA selection are: > > - Capacity. We want to fit in one FPGA. > > - Performance. We want to run at speed. > > - "ASIC-like" synthesis library (see below)? > > - Availability of board described above. > > > > "ASIC-like" synthesis library... The datapath > > content on the ASIC may force us to use one of the > > datapath synthesis tools. These tools don't support > > FPGA architectures directly. I've heard that since > > the Actel architecture is "fine-grain" that it works > > best for these types of designs. > > > > Any advice will be much appreciated. > > > > Thanks, > > Gil > >Article: 42246
Take a look at the clock net in the FPGA editor and you'll find the jumpoff point for the clock that goes to the IOB is right by the global clock buffer. The very low skew global clock distribution only feeds clocks - clocks on the IOBs, clocks in the CLBs, no .O pins are accessible directly or indirectly through the routing boxes. You could achieve a "with the data" timing if you used a /4 clock instead of the /8 clock but you don't have guaranteed zero hold. If you move your clock by the global clock buffer and use the net which drives the global clock input to drive your /8 external clock, you may get a better timing relationship at the cost of a (different) sub-optimal PC board layout. You should get clock-to-out times for the flops and in-to-out times for the 36MHz clock to 5MHz clock path from the timing analyzer, but I'm not certain dince the DLL adds some confusion to the mix. Right now I'm spelunking into the Virtex-II's resources by way of the FPGA editor so I have a particular empathy for your situation. Enjoy. - John_H Falk Brunner wrote: > Hello everyone, > > Iam afraid Iam missing a major point in FPGA clock routing. > I have a Virtex-E (300), feed a clock from a Xtal (36 MHz) into a global > clock input, divide it down by 8 by means of a DLL and provide this clock to > a clock buffer. A big part of my design runs at this ~5Mhz clock. So far, so > good. But now comes the tricky part. I have some block which handles a > interface with another device (its a UTOPIA2). All output signals use IO > FFs. The clock is simply routed to an IO pin and from there to the other > chip. The interface is fully synchronous, everything works on the rising > edge. > I expected, that the datas are slightly delayed behing the clock, by the > clock-2-output time of the IOB FF, but they were NOT!!!! > The clock IS delayed by ~3 ns behind the data!!!! > First question, how does this happen? I thougt the clock nets are low skew, > means the clock arrives at all cell at the same time. But the P&R tools tell > me, that the clock is driving non-clock load, which can cause skew trouble > (and it does :-( > Second, what is the clean approach for clock distribution (without DLL > usage) > At the moment, I use a registers clocked on the other (falling) edge to > "simulate" the right phase relation between clock and data. > > -- > MfG > FalkArticle: 42247
On 18 Apr 2002 11:01:02 -0700, 13378988@qub.ac.uk (almost_a_gnome) wrote: >I am using xilinx foundation series software, > >In simulations, > >I have found that if you try and address a memory location higher than >1023 on the rams on the virtex e there is an error. > >i.e every time you set the 10 or 11 address lines to 1, on any of the >12 bit addressable RAM's (B4RAM_S1 etc). > >Please could someone tell me if this is a software problem and how i >can fix it so i can use the full 12 address lines on the RAM's rather >than just the first 10. You should have the source for the simulation models. Have you looked at the code? Philip Freidin FliptronicsArticle: 42248
I'd like to have the option of lotsa pins available for some of my designs. I've been buying extra logic to get my needed pin count (Altera sometimes gives better pin counts than the Xilinx I've been designing with lately) but the sad truth is that the number of I/O often dictate the amount of silicon area - the "pad limited" characteristics you hear about with ASICs. For the highest pin count device in a series, you effetively buy the pins and you get the logic for free. Falk Brunner wrote: > "Peter Alfke" <peter.alfke@xilinx.com> schrieb im Newsbeitrag > news:3CBEF902.77945FC@xilinx.com... > > > Yes, the XC2V6000 is in production, and it has 1,104 user I/O pins in the > FF1517 > > package. The small-quantity price is several thousand dollars. You can > find it > > listed at the distributors web sites. ( insight-electronics.com, > avnet.com, > > nuhorizons.com,) > > Question is, does he really need the pins AND logic, or just the pins. Maybe > its a good idea to have some low cost, low capacity FPGAs to handle the IOS, > bundle the data stream, and process it in a not so big FPGA. > > -- > MfG > FalkArticle: 42249
> Hello newsgroup! > I am looking for a 8051 Core to implement in an Xilinx Spartan2 FPGA. > The task for it is a control of a sensorless brushless DC motor. > The software for the processor is already done but needs to be speeded up. > So i need pwm, capture/compare units, several timers ans so on... > I have several in my mind but not yet found 'the one'. > I am not looking for freeware, but if there are some out there, please let > me know:-) > > Thanks in advance > > Steffen Thieringer > > The Atmel FPSLIC is a very good part for your application, but it does not have the 8051, it has an AVR, which runs at 25 Mhz for about 20 MIPS. The AT94S series has a built in configurator for small foot print. The FPGA SRAM makes it ideal for making multi-channel timers/capture registers -- Best Regards Ulf at atmel dot com These comments are intended to be my own opinion and they may, or may not be shared by my employer, Atmel Sweden.
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