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
HL, It must be a simulation error, as all outputs of the DLL are phase aligned with the CLK0 output signal. Check the answers database on line, it is probably already reported and logged. Austin "H.L" wrote: > Hello all, > I use a Virtex-E for my design. I have an external clock 155MHz that I pass > through a CLKDLLE to acquire the divide by 2 clock. The timing analyzer > reports no timing errors but when I timing simulate the design in modelsim > (5.2) I get large clock skew between the DLL clocks. > > The CLK0 rising edge is delayed about 4.2 ns (clock race) with respect of > the CLKIN clock!! This clk0 signal is the input of a BUFG whose output is > the CLKFB of the CLKDLLE. The external 155 clock uses a LVDS_DLL pin... > (should I use the inverted signal for feedback?) > > The clock divided by two is delayed for less than 1 ns.. > > Is this a simulation error or an implementation error? Any help is very very > wellcome! > > Best Regards, > HarrisArticle: 42376
Patrik, You will get a warning if you use general interconnect to connect to the DCM, but it will route it. The warning basically just states what I said, that the delay (skew) is now not understood, and can not be corrected for. Austin Patrik Eriksson wrote: > Austin Lesea wrote: > > > Patrik, > > > > The CLKIN_STOPPED status bit will tell you if the input to the DCM has > > stopped, and the LOCKED signal will tell you if it has gone unstable (ie > > lose lock). > > > > The problem is that the BUFGMUX switches only between two transistioning > > clocks: if you stop one or the other, it does not switch, as it is a state > > machine that requires both clocks to be present. You may use a mux made > > from the CLB instead to control the source clock. Delay is now not > > controlled, so you would need to use a third DCM to deskew the new clock if > > deskew is needed. Otherwise get on the BUFG clock tree and go to work. > > OK! I understand that I can't use the BUFGMUX for this purpose. > The clock has to be deskewed. > > > > > I would mux between CLKA input, and CLKB input, based on CLKIN_STOPPED OR > > NOT(LOCKED), and not use the CLK0 outputs of the DCM's, and pass the > > selected clock from the mux to the CLKIN of the third DCM for deskew. That > > way, there is no jitter accumulation going through two DCMs. The first DCMs > > are only used as clock monitors. > > I didn't know that you were allowed to feed a DCM from CLB logic. > Unfortunately I only have two DCM left in my design, but the primary > function is to MUX between a non existing clock and an existing clock. > The automatic detection is not a requirement but it would be nice. > > If I can put user logic between the IBUFG and the DCM then there is no > problem. I this is OK I will put one MUX on the input clocks and feed > the MUX output to one DCM. The MUX control signal will be set during the > reset phase of the design (by system software). > > > > > One would almost surely have to reset the third DCM after a switch to be > > sure you don't unhinge the third DCM by the asynchronous switch froma bad > > clock, to the good clock. > > OK When the correct clock input is selected the DCM will be reset! > > > > > Austin > > > > > > Patrik Eriksson wrote: > > > > > >>Hi, > >> > >>I have a design where the input clock is driven from one of two sources > >>depending on board configuration i.e. either from osc. A or from osc. B. > >>The two oscillators are never connected at the same time. > >>Each of the two input clocks are connected to one DCM respectively. > >>The clk0 output from the two DCMs are connected to an BUFGMUX which is > >>used to select which of the two input that should be used for the > >>internal clock. Is it possible to use the status output from the DCM(s) > >>to determine which clock input to use, i.e. control the BUFGMUX? > >> > >> FPGA > >> +-------------------------------------------+ > >> | +----------------+ | > >>+-----+ | | +---+ fb | | > >>| osc.| _ | +-|DCM| | | > >>| A |----->(_)---|-->|in |---+ + | | > >>+-----+ | | | |__|\ | | > >> | +---+ | \_|___internal_clk | > >>+-----+ | +---+ __| / | | > >>| osc.| _ | |DCM| | |/| | | > >>| B |----->(_)---|-->|in |---+ | | | > >>+-----+ | +-| |--------+ | | > >> | | +---+ status(1)| | > >> | | | | > >> | +----------------+ | > >> | fb | > >> | | > >> +-------------------------------------------+ > >> > >>Thanks in advance > >> > >>Patrik Eriksson > >> > >>-- > >>Patrik Eriksson | patrik.eriksson@netinsight.net > >>Net Insight AB | phone: +46 8 685 04 89 > >>Västberga Allé 9 | fax: +46 8 685 04 20 > >>SE-126 30 STOCKHOLM, Sweden | http://www.netinsight.net > >> > > > > Thanks > /Patrik > > -- > Patrik Eriksson | patrik.eriksson@netinsight.net > Net Insight AB | phone: +46 8 685 04 89 > Västberga Allé 9 | fax: +46 8 685 04 20 > SE-126 30 STOCKHOLM, Sweden | http://www.netinsight.netArticle: 42377
Hal, I wish I had the answer to that. Complex chips = complex bypassing. Believe me when I say we are working on it. The hole in the center is great for hiding a bunch of bypass. Blind or hidden vias a re great for that as well (caps on the back of the board). 0402 is better than 0603 for SM caps (smaller is better, less inductance, and you can pack more on the pcb). Austin Hal Murray wrote: > > The reverse geometry is better, and the inter-digitated > > caps are even better. > > Both are expensive. Any indeas on how to get good bypassing > at good costs? > > This brings up a question I've been meaning to ask... Some big BGAs > have a hole in the center. From a board layout viewpoint, that > leaves a great place to put bypass caps. Assuming I need x pins, > how does a BGA with a hole compare with a dense BGA after it gets > on the board and we add bypass caps? (and everything else that > real designs need) > > -- > These are my opinions, not necessarily my employer's. I hate spam.Article: 42378
Tim, I don't recall the article, I'll go look... Austin Tim wrote: > Austin Lesea wrote > > > Remote locations vs. the main sites? We reached ~ 10,000 people, > > and I have to believe some of them are on this newsgroup. > > No use for either Colorado Springs or the UK. Still, it does > not sound as if much was missed. Now if X only had the consultants' > briefings of old... > > BTW, could you pls post a pointer to a recent X paper on power > dissipation in VirtexII. I saw a mention of it in EETimes around > a month ago. The conclusion was along the lines of 'routing burns > more than logic'Article: 42379
Rémi, Merci beaucoup, Austin RS wrote: > I attend to PW2002 in Paris. I quite agree with Greg and the feeling I > had, is that it was a bit too a "marketing show". I'd appreciated to > have more "technical" info. However I had interesting informations and > perhaps the most interesting was to meet Xilinx people > (distributor/rep/FAE) and others people who have common questions, to > learn a bit about their methods, etc. > I've preferred the day in november 2000 (at Versailles, France) where > technical people ask about our needs, what we think about their new > products... Yes it's "marketing" to learn about client feeling, but I > think I learn more things. > > Rémi. > > Austin Lesea <austin.lesea@xilinx.com> wrote in message news:<3CC03E94.88E21D74@xilinx.com>... > > Greg, > > > > Thank you for your honest comments. > > > > Anyone else out there wish to provide us with some feedback? Too techie? Too > > marketing? To Rah Rah Rah? > > > > Just because some of us are wildly excited doesn't mean that others are. I > > understand that. In fact, since I have been working on Virtex II Pro for more than a > > year now (old news for me), I was a more than a little suprised by the numbers > > attending, and the success of the event. In retrospect, I realize the revolutionary > > product that it is, and I am exciting about its future. > > > > Remote locations vs. the main sites? We reached ~ 10,000 people, and I have to > > believe some of them are on this newsgroup. > > > > If you feel that you do not want your comments in the public eye, I will respect > > that, and you can send them to Peter or myself directly. > > > > We are likely to do this again, and we strive to always be improving. > > > > Thanks, > > > > Austin > > > > > > > > Greg Neff wrote: > > > > > On Thu, 18 Apr 2002 16:57:21 -0700, Peter Alfke > > > <peter.alfke@xilinx.com> wrote: > > > > > > (snip) > > > >Within Xilinx, I am known to be the harshest critic of marketing BS in public > > > >seminars, and I have ( successfully?) fought for more and more technical "meat". > > > > > > > >Originally, I had been concerned about PW2002, therefore I attended in San > > > >Jose. And I came away excited, happy, and even proud. > > > > > > In San Jose you could pick and choose which technical training tracks > > > to attend. In Toronto we were shown four preselected videos. The > > > rational for this is obvious, but it results in my experience being > > > much different than your experience. > > > > > > Also, you have to put yourself in the shoes of an engineer that has > > > little or no knowledge of VirtexII Pro. If you were in this position, > > > how much would you have learned at PW2002? If you have not yet seen > > > the IBM (C1) track then I suggest you do. I think you will appreciate > > > my frustration with this presentation. > > > > > > (snip) > > > >Having won the attention, and perhaps even the hearts and minds of most design > > > >engineers, we now face a new challenge: We have to convince engineering and > > > >corporate management to change their mindset, to adopt multi-gigabit > > > >transceivers and on-chip PowerPC for their next-generation designs. Or to give > > > >up on ASICs. And in the larger companies, such decisions are usually not made at > > > >the design engineer's level. So we have to sell our capabilities higher up the > > > >corporate ladder. > > > >FPGAs are not glue-logic anymore, they are now part of high-impact > > > >architectural, system-level, and business decisions. So we have to change the > > > >tone of our story, to appeal to a new audience. > > > > > > As I said, it was clear that the target has shifted away from the > > > engineer. If that's what Xilinx wants to do then that's fine, but > > > this reduces the value of the presentation to me, since I am concerned > > > with the technical aspects. Since Xilinx listed engineers in the "who > > > should attend" list, I expected the same level of technical content as > > > was in previous seminars. > > > > > > > > > > >We still have lots of detailed technical info, app notes, cores, books and CDs > > > >and also training sessions and FAEs, ready to explore the finer details; and > > > >many of these details are really utilized by the software automatically. > > > > > > I agree whole-heartedly. My issue here is only with PW2002. > > > > > > > > > > >So, please, keep coming to our Seminars and Events, but also use all the other > > > >ways to inform yourself about Xilinx products and solutions. The era of FPGAs > > > >has just begun... > > > > > > Maybe Xilinx needs to have two different seminars. Something like > > > PW2002 for managers, and then in-depth technical presentations for > > > engineers. > > > > > > > > > > >BTW, we just finished a great quarter, increasing our sales 20% > > > >quarter-to-quarter, thanks to satisfied customers, like the ones in this > > > >newsgroup. We weathered the storm without any lay-offs, just with > > > >belt-tightening. That's something to be proud of, and thankful to you, our > > > >customers. > > > > > > I have always liked Xilinx technology, and I have no desire to change. > > > Xilinx competitors are always knocking on our door, and we always turn > > > them away. > > > > > > PW2002 rubbed me the wrong way, and I heard other attendees grumble as > > > well. Xilinx should know this, and that's why I posted my review. > > > > > > (snip) > > > > > > =================================== > > > Greg Neff > > > VP Engineering > > > *Microsym* Computers Inc. > > > greg@guesswhichwordgoeshere.comArticle: 42380
Bob, Contact your local Xilinx sales or FAE. Austin Bob Perlman wrote: > On Fri, 19 Apr 2002 13:33:52 -0700, Austin Lesea > <austin.lesea@xilinx.com> wrote: > > >Jay, > > > >Not so fast.... > > > >The devices have a custom test program that assures the part will meet all > >requirements at speed for the intended application. > > > >Who bothers to look for the bits that don't get used by the application? > >That would be really hard to do, and cost a lot of money, and take a lot > >of time. > > A couple of questions: > > 1) How many parts a month does a customer have to buy to offset the > cost of developing and running a special test program? Even if the > generation of the test program can be automated, I'd think that trying > to manage customer-specific test programs at the foundry would be > challenging. Foundries are best at doing the very same thing (same > die type, same test program) over and over. > > 2) Is what I pay for an EasyPath part a function of how much of the > part I use? If so, is there a rule-of-thumb metric for how much I > save for a given utilization? > > Bob Perlman > > > > >Austin > > >Jay wrote: > > > >> I was wondering when someone was going to do this. Correct me if I'm > >> wrong but basically the way this works is Xilinx screens parts at > >> wafer probe with known defects against a particular design's P&R to > >> see if it's fucntion would be adversly effected. If it isn't, then > >> the part can be delivered and guaranteed to work for this particular > >> design. Xilinx gets to sell silicon that would otherwise be discarded > >> (or sold as engineering versions with an erratta sheet) and the > >> customer gets some cost break on his mature application. > >> > >> I guess you still have to use the config parts as always, and you've > >> given up the field upgradability benefits touted for FPGA based > >> designs but for some applications this could really work. > >> > >> As an extension of this program, I'd like to these parts made > >> available for sale in small quantity without the NRE charges and an > >> RLOC file that goes with the serial number of the part or something > >> like that to be included in the P&R to work around. The chips can be > >> like diamonds where the price varies depending on the amount of > >> defects from "flawless", to "slight inclusions". You buy what you > >> need.Article: 42381
Jay, Cellular base stations, routers, switches, load balancers, the list is endless. ASIC prototyping? I actually don't know of any doing that. Maybe they are not telling me. With EasyPath, there is little reason to ASIC prototype. How could you justify it to your boss? Austin Jay wrote: > > I looked at the XC2V6000, which costs up to US$ 8700,--. That is somewhere > > at a small car. My question to somebody involved in production of such > > parts: Why are these parts that expensive? Please don't misunderstand me, > > I really accept the price. I simply don't have any idea what can make a > > chip that expensive. > > > > Another question: What are typical uses of a XC2V6000 with e.g. 1517 pins? > > :-) Are they used for fast routing of network traffic in Cisco Catalyst > > routers (or such things)? I guess, a PC will not use these parts. What > > are typical capabilities, what can one typically put together into one > > such FPGA? > > > > Thanks > > Hansi > > Hansi, > > To answer your question, "What makes them so expensive?" The answer > is the answer is quite simply the free market. The customer has the > ability and willingness to pay. There is no preceived subsitute at a > lower price. This whole business about how much money it costs Xilinx > to make one only tells you if its a viable buisiness or not, and > indicates little about the selling price. In fact, in a surplus > situtation, you will often pay less than the cost of item. I once > purchased a small car (great comparison by the way) for substatital > discount because of artificial surpluses generated by the govenments > CAFE(SP?) average milage regulations. > > Q: "What do you use a chip like this for?" The main use I've seen > them for is ASIC prototyping. A way to run cycle acurate emulation of > your ASIC at reduced speed (usually about 1/4) against something that > you would not be able to simulate (like a Microsft operating system). > > CheersArticle: 42382
Sasa Bremec wrote: > Hi! > > > Let me explain my synthesize problems of VHDL code > > I have a design with few models (state machine, counter, s2p shifter...) > when i put all this moduls together, the syntax is OK, but here comes > the problem. When i start the synthesize tool i get this error > > >> Clock variable 'CLK' is being used as data << > May be a problem with the port map of the top entity. Post your code. Consider simulation. -- Mike TreselerArticle: 42383
Itsaso Zuazua wrote: > Hi, > > I have problems when I want to do a post-synthesis pre-place and > route simulation in Modelsim. I have synthetized a VHDL design in a > apex20ke (an FPGA family of Altera), and I have obtained another VHDL > design which is an FPGA-independent netlist ready for place and > route. If it's ready for place and route, it is FPGA *dependent* and requires a vendor simulation library in scope. > This post-synthesis design exported from the synthesis tool give > me errors when I simulate it. Should I compile another library in my > work directory,first? The synth vendors web site has app notes on simulation. Consider synchronous design and static timing as an alternative. -- Mike TreselerArticle: 42384
Mark, I wasn't trying to dismiss the usefulness of an ISS. My point is that Nios simulation brings both software and hardware simulation together, which I think is a very powerful tool. -c-rob Mark Aaldering <Mark.Aaldering@xilinx.com> wrote in message news:<3CC0C237.1C7C3467@xilinx.com>... > C-rob, > > Hmmmm - Peripherals don't by default cause the processor pipeline to stall....unless I'm missing > something about nios. > > They could be: Polled, Interrupt Driven, DMA oriented, Share Dual port with semaphores, etc, etc. > > Having done Processors before PLDs in my career - it is occasionally important to software developers to > know how fast the code will run - especially if there is a critical code section. And running a hardware > simulator is clearly slower than a cycle accurate ISS, and probably a tad less intuitive to a software > developer than using GDB with the cycle accurate simulator to get a fix on Real Time. > > That all said - with the MicroBlaze MDK, you do get the ability to do both - so if for some reason you've > built your system to stall when data from a peripheral is not ready - you can figure that out too. > > - Mark > > crob wrote: > > > Mark, > > > > How can you get "real clock time" when your peripherals are not taken > > into account in the simulation? Are you saying they don't affect > > system performance? > > > > This is the key feature of using Modelsim to simulate your whole > > system, peripherals and software are siumulated together, showing how > > each affects the other. > > > > c-rob > > > > Mark Aaldering <Mark.Aaldering@xilinx.com> wrote in message news:<3CC0684E.24473151@xilinx.com>... > > > For what it's worth - the Xilinx MicroBlaze development kit *does* include a cycle accurate > > > instruction set simulator. > > > Thus cycles, and user designated Hz (0 to 150Mhz), yields real clock time. > > > > > > Of course you may also use Model Tech - but you are not forced to do this to get the real execution > > > time of your program. > > > > > > Matthew Mahr wrote: > > > > > > > The instruction set simulator has no awareness of the actual hardware > > > > environment, and thus does not give you an accurate idea how long your > > > > code takes to execute in real hardware. > > > > > > > > Matthew > > > >Article: 42385
Greg Neff <gregeneff@yahoo.com> wrote in message news:<urutbu0vun8dtq9669vmicilnmmdfe1pp7@4ax.com>... > Yesterday I attended PW2002 in Toronto. I have attended Xilinx > promotional seminars since the days of the XC2000. Until now, I have > found that the Xilinx seminars provided enough technical information > to make the marketing content tolerable. PW2002 was a radical shift > toward marketing glitz, at the expense of useful technical content. > I agree, I felt like I was in a tape-in of an infomercial or the shopping channel. > During the IBM "technical training" track I actually got angry. At > least 90% of the presentation was IBM marketing, describing various > IBM PowerPC processors and cores ...(snip>... we were > bombarded with features spanning the entire IBM product line. Same feeling here. I seemed like this session presented a migration path for Virtex II Pros into IBM ASICs: same wafer technology, same process, bus/macros from the same foundry... Easier that easypath? But I was expecting the marketing hipe. I attended to be able to understand some of the expectations designers might have after it. To provided better support to them. With that in mind, I was glad I went. Alfredo.Article: 42386
I tried to sell my fellow engineers on the concept that capacitors with a specific Series Resonant Frequency can be thought of as having a "circle of influence" on the board with good decoupling performance within a radius of about 1/10th the SRF wavelength. The "swiss cheese" in the ground and power planes luckily don't trash your impedance from the power pins to decoupling caps outside the swiss cheese but it does add a little inductance. It's better to have the caps underneath the chip when possible, more than one via per capacitor pad helps. If you could do via-in-pad, it's even better. Every little bit of inductance you can take out of the situation helps but lowest inductance isn't a catch-all. You're still limited by the SRF of the cap. An absolute lower limit of the capacitor efficiency is the equivalent series resistance: you could have the capacitor tied directly to the plane and still have the equivalent series resistance. The general rule is "the lower the inductance the better" but it won't do you much good if you have a cap with too low an SRF or too high an ESR. The specific influence of "under" versus "outside" the BGA is dependent on the caps used, the explicit placements, and the effects of the swiss cheese. Keep in mind you can still get some caps on the back side of the board with a complete grid since the vias can go "away from center" leaving a narrow cross on the back to put 0603 package parts (or is it 0402 for the 1mm pitch?). Hal Murray wrote: > > The reverse geometry is better, and the inter-digitated > > caps are even better. > > Both are expensive. Any indeas on how to get good bypassing > at good costs? > > This brings up a question I've been meaning to ask... Some big BGAs > have a hole in the center. From a board layout viewpoint, that > leaves a great place to put bypass caps. Assuming I need x pins, > how does a BGA with a hole compare with a dense BGA after it gets > on the board and we add bypass caps? (and everything else that > real designs need) > > -- > These are my opinions, not necessarily my employer's. I hate spam.Article: 42387
Regards to this excellent newsgroup! I have a design that uses several variations of dual port blockram in a xilinx virtex 1000E. Would it be beneficial for me to use RLOCs when generating the block ram models from coregen ? Or should I leave RLOCs turned off ? I'm going to have a pretty full chip. ~90% utilized. Thank You, WayneArticle: 42388
Dear All I have a design for Xilinx FPGA in which the INIT constraints for distributed ROM instances are used like below. INST "pci_bios_inst_rom16x1_inst0" INIT = 5; The descriptions are placed in UCF file and P&R is executed by ICE WebPack 4.2 But I think INIT constrains may not take effect. I would appreciate any ideas. SincerelyArticle: 42389
I had a similar problem with NIOS 1. It turned out that I had to be logged in as administrator in Win2000. Haven't actually tried to compile anything other than the examples in NIOS 2.0. "Itsaso Zuazua" <izuazua@ikerlan.es> wrote in message news:709383e9.0204170623.4cff9d1d@posting.google.com... > Hi, > > I have several problems with the Nios 2.0: > > 1-When I want to generate a Nios system module with the > SOPC_BUILDER it gives me errors saying that:"does´nt find boot > monitor, uname:unknown, grep:unknown... > 2-On the other hand, when I try to run the bash shell I have also > problems.It says me that 'bash.exe:can´t find /tmp file;create one' > > I´m thinking that I haven´t installed the NDK (HDK and SDK) tool > properly, despite the fact that I have installed it step by step as > it´s described in the documentation. Should I consider some > environment variables as PATH,TMP_DIR...? Is important the path where > I install the cygwin software? Should this path be the same or > relative to the SDK´s path? > Could anybody help me, please? > > Thanks a lot, > > ITSASOArticle: 42390
Peter Ormsby wrote from home: <snip> > > The Nios internal bus is a non-blocking slave-side arbitrated bus. What > this means is that custom-designed bus masters can be accessing a periheral > like a UART while the CPU is off doing something else. If the CPU decides > that it now wants access to the UART, your cycle-accurate Instruction Set > Simulator (ISS) now needs to understand not only the arbitration scheme, but > also the behaviour of the user-created bus master #2 (or 3 or 4 or...). > Depending on the arbitration priorities, the custom bus master could hold > off the CPU several clock cycles. How does your cycle-accurate Instruction > Set Simulator (ISS) account for these "hold-offs" without knowing anything > about how the custom-designed bus masters operate? The IBM CoreConnect Busses also support arbitration, priority, masters, slaves, split transactions, and on and on...I'm guessing that IBM knows a thing or so about high performance busses :-) You've assumed a processor <> peripheral critical interlock, which depending on the application, may not exist. > > Even more interesting is what happens when you've created your own custom > instruction(s) in the Nios ALU. Since custom instructions can interface to > user-created logic, I don't see how an ISS could accurately count cycles > without knowledge of the user-created hardware. And just to make things > even more challenging for a cycle-accurate ISS, the user-created logic that > a custom instruction ties to can contain sequential logic so that an > instrution could take, for example, one clock cycle most of the time and > three clock cycles the rest of the time. Once again, this makes a > cycle-accurate ISS practically impossible without knowledge of the other > hardware in the system. Ahhh - so now it get interesting - of course you can't build a cycle accurate ISS if your features (like customer defined opcodes) result in a non-deterministic (asynchronous?) pipeline timing. It sure would be 'fun' debugging a previous design teams effort if they did stuff like this... <snip> -- Mark Aaldering Sr. Director IP Solutions Division xilinx.comArticle: 42391
Lorenzo, I was informed of your problem from Peter Alfke, but saw also that you got a response from another comp.arch.fpga (Dziadek) suggesting you make a fast, monotonic power supply. If you can alter your power supply easily, I recommend it. However, if you can't, you may have obtained older material which exhibited sensitivity to a slow, noisy power supply while initializing. Depending on your system and incliniation, there are some choices. First, if you supply us the date code (basically all of the writing on the top of the chip), we can tell you which material to get in the future and your distributer can arrange a swap. Second, as you noted, the JTAG command basically "heals" the device. What is going on here is that at the end of a JTAG command (many of them, anyway), the internal TAP controller receives an additional command to re-transfer the internal Flash bits to SRAM cells within the chip. Naturally, this is a safe reload as the power supply is now stable. Even the sensitive material performs very well with a fast ramping VCC, but many people had problems making this happen. Let me know what you want to do. Jesse Jenkins, Xilinx CPLDs jesse@xilinx.com ========================= Lorenzo Lutti wrote: > "Jim Raynor" <chris@ultrasonix.com> ha scritto nel messaggio > news:h2%v8.3428$n%4.252313@news2.telusplanet.net... > > > I used the CPLD XC95288XL in my design and the program > > used up 97% of > > the macrocells of that CPLD. [...] > > 30 secs) and powered that up afterward. And I got that > > CPLD problem > > everytime now when I actually let the CPLD cool down and > > re-powered up. > > I have a very similar problem with a XC95144XL, but it isn't related to > the temperature and the cell use is quite low. Some devices always work > good, while others have several problems at power on. The problem is > very strange because: > > -The system stays in a reset state for 250 ms after the power up; > -If I restart the system by software (i.e. I start a debug session via > JTAG, I use a TI DSP) after a failure without powering off and on, the > CPLD works fine. > > Are there some tricks to make a CPLD start correctly? I haven't tied the > global reset pin to the system reset, should I? > > -- > LorenzoArticle: 42392
I'm using a ucf file to provide all of my constraints. I assign pin locations using NET <net-name> LOC = P[number]; That works fine, but no matter what I do I always end up with obuft_s_12 output buffers. Even if I specify a fast slew rate, and even if I tell it to use PCI33_5 as the IO standard instead. I get nothing but obuft_s_12. Applying a fast slew rate should give me a obuft_f_12 shouldn't it? Am I doing something wrong or does the FPGA Express schematic just not get updated everytime you do a new implementation of the design?Article: 42393
I am working with an old schematic based FPGA design (from a 4000 series Xilinx) that was done using Viewlogic. The design contains many LogiBlox cores. I have heard that LogiBlox are not supported at all by any of the new devices such as virtex 2. Is there any way to implement a portion of this design into a virtex 2 device? Do I have to convert all the LogiBlox cells to CoreGen blocks by hand? Does anyone have expereince with this? thanks in advance, Mike Schreiber Hardware EngineerArticle: 42394
Austin To help in the hunt, here is the reference to the eetimes news article: http://www.eetimes.com/semi/news/OEG20020228S0050 Quoting from eetimes: Despite this reluctance to tackle the issue head-on, power consumption could soon be at the top of the to-do list in the near future, especially if programmable logic device (PLD) makers are serious about winning sockets in power-sensitive consumer electronics applications, said Xilinx's Trimberger. Xilinx has already taken the first steps to raise the awareness of power issues by disclosing a study on the hot spots in its latest Virtex 2 architecture. In the paper, the company showed that 60 percent of the power consumption in the Virtex 2 family is from routing while logic and clocking account for 16 and 14 percent, respectively. Additionally, Xilinx found that the cluster of LUTs, flip-flops and other circuitry that make up its configurable-logic blocks take up 5.9 microwatts per MHz for a typical design. But this is just for "typical" designs; actual power consumption within the configurable logic blocks (CLBs) can change wildly depending on the switching activity. This can occur frequently in synchronous circuits, where the inputs to the LUTs come in at different times during the same clock cycle. This "glitching" effect could contribute up to 70 percent of the power dissipation in a CMOS circuit, whether it's an ASIC or FPGA. <end quote> I guess you feel an application note coming on :-) "Austin Lesea" <austin.lesea@xilinx.com> wrote in message news:3CC42242.B251D66F@xilinx.com... > Tim, > > I don't recall the article, I'll go look... >Article: 42395
Here is what I do in my design's UCF file to use 5V PCI I/O buffers.
_____________________________________________
NET "AD<31>" IOSTANDARD = PCI33_5;
NET "AD<30>" IOSTANDARD = PCI33_5;
NET "AD<31>" LOC = "P203";
NET "AD<30>" LOC = "P204";
_____________________________________________
By the way, fast/slow slew rate works only when you are using
LVTTL I/O buffers.
This UCF code should allow you to adjust slew rate.
_____________________________________________
NET "AD<31>" IOSTANDARD = LVTTL;
NET "AD<30>" IOSTANDARD = LVTTL;
NET "AD<31>" LOC = "P203";
NET "AD<30>" LOC = "P204";
NET "AD<31>" SLEW = FAST;
NET "AD<30>" SLEW = SLOW;
_____________________________________________
Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)
Sean wrote:
>
> I'm using a ucf file to provide all of my constraints. I assign pin
> locations using NET <net-name> LOC = P[number];
>
> That works fine, but no matter what I do I always end up with
> obuft_s_12 output buffers. Even if I specify a fast slew rate, and
> even if I tell it to use PCI33_5 as the IO standard instead. I get
> nothing but obuft_s_12. Applying a fast slew rate should give me a
> obuft_f_12 shouldn't it?
>
> Am I doing something wrong or does the FPGA Express schematic just not
> get updated everytime you do a new implementation of the design?
Article: 42396
Hiro,
Please look in FPGA Editor to verify if the INIT attribute was taken in. If
not, then you could also check the PCF file. In case this file does not show
the annotated constraint that you have, please make sure that your syntax is
correct:
refer to:
http://toolbox.xilinx.com/docsan/xilinx4/data/docs/cgd/i3.html#1004651
If none of this works, please open a webcase at support.xilinx.com.
An alternative to try is to use the VHDL / Verilog attribute INIT. I have a
working example for a LUT-based RAM for which I have pasted HDL to this e-mail.
Please use it and see if you get better results.
Regards,
Hari.
========================================================================
VHDL:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
entity block_inst is
Port ( WEx : in std_logic;
ENx : in std_logic;
RSTx : in std_logic;
CLKx : in std_logic;
ADDRx : in std_logic_vector(7 downto 0);
DIx : in std_logic_vector(15 downto 0);
Dout : out std_logic_vector(15 downto 0));
end block_inst;
architecture behavioral of block_inst is
component RAMB4_S16
port (
DO : out std_logic_vector (15 downto 0);
ADDR : in std_logic_vector (7 downto 0);
DI : in std_logic_vector (15 downto 0);
EN : in std_logic;
CLK : in std_logic;
WE : in std_logic;
RST : in std_logic
);
end component;
attribute INIT_00: string;
attribute INIT_00 of U1 : label is
"1F1E1D1C1B1A191817161514131211100F0E0D0C0B0A090706050403020100";
begin
U1: RAMB4_S16 port map (DO => Dout,
ADDR => ADDRx,
DI => DIx,
EN => ENx,
CLK => CLKx,
WE => WEx,
RST => RSTx);
end behavioral;
hiro wrote:
> Dear All
>
> I have a design for Xilinx FPGA in which the INIT constraints for
> distributed ROM instances are used like below.
> INST "pci_bios_inst_rom16x1_inst0" INIT = 5;
> The descriptions are placed in UCF file and P&R is executed by ICE WebPack
> 4.2
> But I think INIT constrains may not take effect.
>
> I would appreciate any ideas.
>
> Sincerely
Article: 42397Tim, I wondered why I was writing this note about power... (actually I am). In Virtex II and Virtex II Pro we see the beginnings of something that we need to address with design techniques, tools, and automated software awareness. If you can't do it manually, then there is no way to automate it. Techniques to reduce the 'glitch' power Steve mentions includes reducing the amout of interconnect attached to a toggling LUT node (ie register in the CLB), or registering ahead of the inputs to reduce the skew int he arrival times at the LUT to reduce gratuitous toggling. I imagine someday a button labled "optimize for power" in the FPGA synthesis flow, just as there are area vs speed buttons today. Right now, there is no "hot spot" as the silicon conducts the heat sufficiently well. The hot spots Steve is referring to are spots which a perhaps a few degrees C warmer than the surrounding areas. Easily imaged with IR sensors. Steve is right, and when he says "could be" he is just teasing. We are designing 'future' FPGAs already. Austin Tim wrote: > Austin > > To help in the hunt, here is the reference to the eetimes > news article: > > http://www.eetimes.com/semi/news/OEG20020228S0050 > > Quoting from eetimes: > > Despite this reluctance to tackle the issue head-on, power consumption > could soon be at the top of the to-do list in the near future, > especially if programmable logic device (PLD) makers are serious > about winning sockets in power-sensitive consumer electronics > applications, said Xilinx's Trimberger. > > Xilinx has already taken the first steps to raise the awareness of > power issues by disclosing a study on the hot spots in its latest > Virtex 2 architecture. In the paper, the company showed that 60 > percent of the power consumption in the Virtex 2 family is from > routing while logic and clocking account for 16 and 14 percent, > respectively. > > Additionally, Xilinx found that the cluster of LUTs, flip-flops and > other circuitry that make up its configurable-logic blocks take up > 5.9 microwatts per MHz for a typical design. But this is just for > "typical" designs; actual power consumption within the configurable > logic blocks (CLBs) can change wildly depending on the switching > activity. This can occur frequently in synchronous circuits, where > the inputs to the LUTs come in at different times during the same > clock cycle. This "glitching" effect could contribute up to 70 percent > of the power dissipation in a CMOS circuit, whether it's an ASIC or > FPGA. > > <end quote> > > I guess you feel an application note coming on :-) > > "Austin Lesea" <austin.lesea@xilinx.com> wrote in message > news:3CC42242.B251D66F@xilinx.com... > > Tim, > > > > I don't recall the article, I'll go look... > >Article: 42398
Hari Devanath wrote: > Hiro, > Please look in FPGA Editor to verify if the INIT attribute was taken in. Since this user said he is using WebPack, I assume he does not have FPGA Editor so I suggest you use a command-line tool called NCDREAD (I believe WebPack installs this) which will make a ASCII text version of the placed and routed NCD file and there you can verify the INIT values. Alternatively, you can also use a utility called XDL to do a similar thing. > If > not, then you could also check the PCF file. In case this file does not show > the annotated constraint that you have, please make sure that your syntax is > correct: > refer to: > http://toolbox.xilinx.com/docsan/xilinx4/data/docs/cgd/i3.html#1004651 > > If none of this works, please open a webcase at support.xilinx.com. > > An alternative to try is to use the VHDL / Verilog attribute INIT. I have a > working example for a LUT-based RAM for which I have pasted HDL to this e-mail. Actually if you are using the synthesis tool in ISE WebPack (XST) for synthesis, then I do not suggest you use the VHDL attribute syntax shown here and instead, pass the INITs via generics. You can see a write-up and examples on how to pass INIT attributes for BlockRAMs on the FPGA FAQ web site at http://www.fpga-faq.com/FAQ_Pages/0031_How_to_initialize_Block_RAM.htm There you will see an example that should work with XST as well as your simulators to properly pass the INIT attributes. -- Brian > > Please use it and see if you get better results. > Regards, > Hari. > ======================================================================== > VHDL: > library IEEE; > use IEEE.STD_LOGIC_1164.ALL; > use IEEE.STD_LOGIC_ARITH.ALL; > use IEEE.STD_LOGIC_UNSIGNED.ALL; > > entity block_inst is > Port ( WEx : in std_logic; > ENx : in std_logic; > RSTx : in std_logic; > CLKx : in std_logic; > ADDRx : in std_logic_vector(7 downto 0); > DIx : in std_logic_vector(15 downto 0); > Dout : out std_logic_vector(15 downto 0)); > end block_inst; > > architecture behavioral of block_inst is > > component RAMB4_S16 > port ( > DO : out std_logic_vector (15 downto 0); > ADDR : in std_logic_vector (7 downto 0); > DI : in std_logic_vector (15 downto 0); > EN : in std_logic; > CLK : in std_logic; > WE : in std_logic; > RST : in std_logic > ); > end component; > > attribute INIT_00: string; > attribute INIT_00 of U1 : label is > "1F1E1D1C1B1A191817161514131211100F0E0D0C0B0A090706050403020100"; > > begin > > U1: RAMB4_S16 port map (DO => Dout, > ADDR => ADDRx, > DI => DIx, > EN => ENx, > CLK => CLKx, > WE => WEx, > RST => RSTx); > > end behavioral; > > hiro wrote: > > > Dear All > > > > I have a design for Xilinx FPGA in which the INIT constraints for > > distributed ROM instances are used like below. > > INST "pci_bios_inst_rom16x1_inst0" INIT = 5; > > The descriptions are placed in UCF file and P&R is executed by ICE WebPack > > 4.2 > > But I think INIT constrains may not take effect. > > > > I would appreciate any ideas. > > > > SincerelyArticle: 42399
For a long time I've found CPU design interesting, but never had the
resources to go out and test any of my ideas.(strange memories of
arguing with my friends about CPU architecture at sushi restaurants
come to mind) Recently, I've been looking at FPGA boards, and would
like input. I'm a hobbyist(highschool student) and therefore have very
little funds.
Although I've been looking at doing very simple designs, I'd like
to have a larger device available if I need it(or try to do a system
with simple I/O, and maybe a VGA framebuffer), and a few megabytes of
RAM(this is where most low cost boards fall short). I've been
considering the following boards:
-Insight Electronics: SpartanIIE-300K. The only IIE-300K board I have
found, very reasonable price, no RAM. SDRAM on a P160 card would have
signal integrity problems, right?
-Insight Electronics: SpartanII-200K-PCI. Very nice, but I don't think
I need PCI(if I used it, I believe the opencores PCI core would use
close to half of the device resources...although it would be nice to
use it in a PC as a host processor and external ram), has 8MBytes of
onboard SDRAM. This would work for me as a standalone card.
-XESS: XSA-100. This board is great. It has on onboard CPLD which
allows you to write images to flash, boot from parallel port, read and
write SDRAM images(nice for booting small systems without lots of I/O
or loading and reading datasets without dedicated FPGA resources), and
could be reconfigured to the application, too. It has 16MBytes of
SDRAM. My only concern is the size of the device. If this were a 200K
device I'd be my first choice(some of the 100K SpartanII would already
be dedicated as a SDRAM controller).
- Other low cost SpartanII prototype/development/evaluation boards:
All theses seem to be 200K devices, but none seem to have onboard
SDRAM.
The ultimate solution would be one of the Insight Electronics
MicroBlaze boards with SDRAM, I/O galore, and a 1M gate VirtexII. It's
very expensive for me to tinker on, however. The MicroBlaze kit page
says that a SpartanIIE version is comming soon. Will there be a
version without the MDK just like the VirtexII version? Does anyone
have any information on suspected prices? Should I wait for these?
There's a chance I may be working on this with a friend(who got
into those arch. fights where the fish was the opcode and the rice the
operand...), in which case I planned on ordering two boards. We could
combine our funds and buy a single Virtex-II MB kit. I'd rather not do
that(we wanted to work over summer vacation...), but if that board
would be a significant improvement for our [hopefully] simple designs,
we could.
Can anyone comment, correct, recommend, etc?
Thanks in advance,
Michael <mikenetaim-removethis@attbi.com-removethis> (please respond
directly to usenet group if possible)
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