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
> Although it may seem at first blush to be simple - buy some IP - there > are details that would need to go into the datasheet, change pin > assignments etc. A clock buffer is NOT anything like an I/O buffer as > made today. There would be 2 dedicated pins needed, I suppose. For an internal calibrated RC-osciallator this is no issue anyway. > Beyond that, I don't know if you have ever designed onto an onboard > oscillator for microcontrollers - the documentation stinks, in general > (there are a number of choices in crystal and resonator parameters - > you can't just say "10MHz crystal") because of too little detail. > This was Xilinx' old problem (and the fact that a lot of people don't > understand the meaning of the documentation even when they get it). > > Because it is now expected on microcontrollers and processors, the mfrs > will often specify a suitable crystal (within some range too) known to > actually operate on that circuit. I have used plenty of crystals on plenty of uCs and had never any problems. I had problems in video-applications where the frequency must be very precise and the crystals must be pullable, and also with ceramic resonators and self-made oscillator-circuits, but crystal + uC always just worked fine for me... > For a FPGA, that may not be suitable - you may want 10MHz - I might > need 20.48MHz - someone else might want to start at 100MHz - who knows. > That's a wide range and unless *all* the details are available, you'll > have to try a number of solutions before you get it right (if you ever > do for the application). Of course there will be a limited range (e.g. 6 to 30MHz), I think most people won't start to mess around with 3rd overtone crystals, etc. for other frequencies, they can use the PLLs or dividers. > That would take two pins for an oscillator (which you would not want to > feed into the core directly anyway) rather than using them for I/O. But saves one pin for the clock input ;-) > It's not often I defend Xilinx, but on this, the range of applications > and the fact it's not their core competence are decent reasons not to > have an oscillator section. > In the vast majority of cases with FPGAs, there is a clock already > being generated elsewhere used to clock data in (not always, I am aware > - I have one where I need an oscillator in front of me), and the pins > would be wasted. > > Keep in mind that a microcontroller *always* needs a clock. A FPGA does > not *always* need a dedicated clock. In most of my designs I have the controller integrated and would like to have a stable clock for it, or I need at least a clock for the PLLs to generate memory-clocks, etc. The other clocks on board have often the problem that they are either not always running, or not fixed frequency, or do not meet the required edge-rates for the FPGA-clock-inputs. Maybe this is not to most important missing feature, but it would be a nice step towards even higher integration. Thomas www.entner-electronics.comArticle: 106551
Mike Treseler schrieb: > I would write some hdl code and run a simulation > to answer questions like that. > How can the Simulation "know", in which way the mathematical function is realized, and if a synthesis tool can save particular resoures in a certain FPGA type? Anyway, I did some experiments with signal assignments and had a look at the required resources in Quartus. As expected, the number of used multiplier signals directly corresponds to the number of outputs signals. But the number of MULs this is not so obvious to me. In one case, I expected at least 8 9-bit-MULs to be used, where Quartus only used 6. Hm...Article: 106552
Hi, I have a question regarding the way the Xilinx blockset interprets wires: Are they considered to be parallel or serial? For example: the AddSub block requires a number of bits to operate on. Does that mean that all of these bits must be provided in parallel or is the block serially operated with a clock? If it is in parallel, is there a way to make the blocks operate serially? Thank you,Article: 106553
Thomas Entner wrote: > An addition or alternative to the crystal-oscillator could be a calibrated > internal oscillator with reasonable precision (e.g. +/-1 %). For the Spartan 3E, there is an internal oscillator (CCLK), but I don't know the precision. If configured in default mode, the datasheet says 485 ns to 1,250 ns, but I didn't found anything about long-term stability etc. If it has good precision, you could measure the frequency and write it in some config memory. Is it possible to use this clock as a clock source for cores? And there are some applications for which it is ok to have a variation between 1 MHz and 2 MHz, e.g. if you build a meaure device, which is accessed by a protocol like I2C, where the clock is transfered from a master. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 106554
Mark McDougall wrote: [snip] > > I used to swear at Quartus, but now I have a new-found appreciation for > it! And whoever decided that the ISE files should be binary... just give > me *two* minutes alone with them... >:/ > The new ISE versions with the binary project files can still read the old .npl project file format and convert it to the new style. This is a very useful way to back up your project settings. There is a drawback, that the settings are now entered by hand (or using ISE 6.1i or earlier) AND you must keep a backup of the .npl file before allowing the newer ISE to convert it (the .npl file gets trashed in the conversion process). But having this file around is very handy for the cases where ISE "blows up" and leaves you with an unusable .ise project file. Otherwise when (notice I didn't say "if") your .ise project file becomes unusable you need to start fresh. Good Luck, GaborArticle: 106555
Erik Verhagen wrote: > Does anyone knows where I can find an example of an IIR filter in VHDL ? It is incredible, I can't find one on google... > thanks, process(clk) begin wait until rising_edge(clk); output <= (output + input)/2; end process; Kolja SulimmaArticle: 106556
Kolja Sulimma wrote: > Erik Verhagen wrote: >> Does anyone knows where I can find an example of an IIR filter in VHDL ? It is incredible, I can't find one on google... You should learn how to use Google: http://www.google.com/search?q=iir+filetype%3Avhd > process(clk) > begin > wait until rising_edge(clk); > output <= (output + input)/2; > end process; Is this synthesizable? -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 106557
"Peter Mendham" <petermendham@NOCANNEDMEAT.computing.dundee.ac.uk> wrote in message news:ebrv8s$ojc$1@dux.dundee.ac.uk... > > Thanks, after staring at that table for a long time (that was where I > got the 101, 102 etc numbers from in the first place) I realised that > the XnYm numbers were supposed to tell me that the tiles were split into > two columns, where n is constant for a column. Whilst this seems > blatantly obvious in retrospect, I can't see anywhere where it actually > makes that clear. > I guess you never dealt with location constraints in Xilinx chips. Everything in recent Xilinx FPGA has its XY Cartesian coordinates. Among possible other places it is described in the Constraints Guide under LOC Description. You can also learn about this system by browsing through your design in either floorplanner or FPGA Editor. /MikhailArticle: 106558
homoalteraiensis wrote:
> How can the Simulation "know", in which way the mathematical function
> is realized, and if a synthesis tool can save particular resoures in a
> certain FPGA type?
Simulation lets me explore the logical description
and do the math. Integer ranges vs bit widths etc.
Synthesis finds a netlist to match the description.
Perhaps I misunderstood your question.
-- Mike Treseler
Article: 106559>So we do not specify max current per pin. >There are two limitations: power and metal migration. >For a given current, the power depends on the voltage drop, and it >depends on the strength of the output, and that is programmable. This >would make the spec very complicated. >Moreover, power per individual pin is not so important, since silicon >is such a good thermal conductor. >The other constraint is metal migration, which has become better since >we now use Cu instead of Al in the metallization. 40 mA is tolerable >"forever". What's the corresponding mA value for Al .. ?Article: 106560
Todd Fleming wrote: > The first two examples produce 16 4-input LUTs on a Spartan 3 and the > third produces only 8 4-input LUTs. Is there a way to get ISE to use > only 8 LUTs without adding flipflops or resorting to a structural > (XORCY, MUXCY, etc.) description? I kept trying various approaches but was unable to find a way to get XST to synthesize an efficient structure, so I resorted to a structural description with XORXY and MUXCY using Verilog's generate. ToddArticle: 106561
MM wrote: > I guess you never dealt with location constraints in Xilinx chips. You're right. This is a prototyping board, and time constraints mean that I am developing the hardware in parallel with the guys doing the chip design. There is a bunch of stuff on the chip and they only just started to tackle the MGT side of things. All this means that 1) I have a pretty open remit and 2) I don't have the fullest idea of what I'm doing, as you suspected :) Mind you, I would have thought that it was fairly common for the task to be split up in this way, with the chip and hw design being done by different people. Even if the vhdl was complete, it's not going to help the poor hw designer who has to grapple with that documentation. Just MHO. -- PeterArticle: 106562
Dear all, I apologise if this is an FAQ, but can someone point me in the direction of a document that allows me to go from a date code for a Spartan 3 device to a mask revision. We have some vacuum sealed parts which I really don't want to open before I send them to our assemblers and I'm dying to know the mask revision. The only thing printed on the outside is the date code and our distributors are being a bit useless. I can't see anything in the docs in the Spartan 3 section of the Xilinx website... TIA, -- PeterArticle: 106563
Kolja Sulimma wrote: > The OP said he wanted to buy only a few. Let's say 10 pieces. So maybe a > different solution would save him $20. I would say the easiest solution > to achieve these $20 savings would be to work a few hours at McDonalds > and then spend the money on the simple to use but more expensive > oscillators. Thank you for the smart tip. Sumit > > For higher quantities the OSC should not cost more than $1. > > Kolja SulimmaArticle: 106564
Despite copper being a better conductor, It is all nonsense, as the copper interconnect is thinner, and requires a barrier material (making the conductor even more thin). Like I said in my posting: If PCI and GTL require 45 mA nd ~ 70 mA forever, you can bet that the IC designers made sure that all associated connections were designed to meet the worst possible case currents, flowing there. Austin pbdelete@spamnuke.ludd.luthdelete.se.invalid wrote: >> So we do not specify max current per pin. >> There are two limitations: power and metal migration. >> For a given current, the power depends on the voltage drop, and it >> depends on the strength of the output, and that is programmable. This >> would make the spec very complicated. >> Moreover, power per individual pin is not so important, since silicon >> is such a good thermal conductor. >> The other constraint is metal migration, which has become better since >> we now use Cu instead of Al in the metallization. 40 mA is tolerable >> "forever". > > What's the corresponding mA value for Al .. ? >Article: 106565
Austin Lesea <austin@xilinx.com> wrote: >Perhaps the specification is too simple, as we allow you to do many >bizarre things (which may not be very useful, but they will not cause >any damage, or reduce the device lifetime). > >Perhaps you are not usd to FPGA design, where you have to have many >choices, and are in complete control? Our specification is written to >allow you to do whatever it is you desire. > >In fact, the more specifications we add to the data sheet, the less >useful the device is, and the more business we potentially lose. A case >where more is not better, and less is ideal. In fact, even less abs max >would be even better (we only place a specification there when we know >it will affect reliability). Sorry, but I'm finding this statement a total disregard towards Xilinx's customers. Because Xilinx's datasheets lack important information on how the IOB are grouped together and the clock distribution limits resulting from that grouping, I have to do an extensive re-design of a PCB. The only way to find out about severe limitations in a Xilinx is by bumping your head at least once for each limitation. Some may call that learning, I call it wasting customer's time and money. May I introduce the term 'sales droid approved datasheets'? So don't give me crap about 'less is better'. Less simply means too little. If you are afraid to lose business, have a simple datasheet and an extensive datasheet. Designers that want to push parts to the edge without hassle really need the latter. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 106566
Impossible in replaying to the newsthread "ModelSim Designer", I'd like to place my quastion here: Is the a free tool to draw state machine with and handle signals in an graphical environment? I agree to the former article where it has been said, that most design engineers might not use HDl-Designer, but I found it very convenient for keep the overwiev in design with a large amonunt of signal interactions.Article: 106567
>> An addition or alternative to the crystal-oscillator could be a >> calibrated >> internal oscillator with reasonable precision (e.g. +/-1 %). > > For the Spartan 3E, there is an internal oscillator (CCLK), but I don't > know the precision. If configured in default mode, the datasheet says 485 > ns to 1,250 ns, but I didn't found anything about long-term stability etc. > If it has good precision, you could measure the frequency and write it in > some config memory. Is it possible to use this clock as a clock source for > cores? I think the variation with voltage and temperature will be quite large. > And there are some applications for which it is ok to have a variation > between 1 MHz and 2 MHz, e.g. if you build a meaure device, which is > accessed by a protocol like I2C, where the clock is transfered from a > master. I agree. I think almost all FPGAs have an internal RC-oscillator used for configuration. In MAXII (not really an FPGA but also not really a CPLD...) e.g., I know it is accessible, but is it also accessible in other families? Of course there are also people out there building ring-oscillators, but there you have almost no guarentee regarding frequency at all.. ThomasArticle: 106568
Thomas Entner schrieb: > >> An addition or alternative to the crystal-oscillator could be a > >> calibrated > >> internal oscillator with reasonable precision (e.g. +/-1 %). > > I agree. I think almost all FPGAs have an internal RC-oscillator used for > configuration. In MAXII (not really an FPGA but also not really a CPLD...) > e.g., I know it is accessible, but is it also accessible in other families? > Of course there are also people out there building ring-oscillators, but > there you have almost no guarentee regarding frequency at all.. > > Thomas Hi Thomas, the internal oscillators are present in almost all fpga families but they are not accessible in all of them. However this is not a big problem on-chip oscillators can be utilized in any FPGAs. Their implementation is usually family dependant and may require some tricks. for s3,s3e,v4 it is also possible to use the DCM in as on-chip free running oscillators by enabling factory test mode. Antti http://xilant.com the second screenshot shows Virtex-4 dcms running as free in self oscillating modeArticle: 106569
Nico Coesel wrote: > So don't give me crap about 'less is better'. Less simply means too > little. If you are afraid to lose business, have a simple datasheet > and an extensive datasheet. Designers that want to push parts to the > edge without hassle really need the latter. Amen ...Article: 106570
"Erik Verhagen" <Erik.Verhagen@cern.ch> wrote: >Does anyone knows where I can find an example of an IIR filter in VHDL ? = >It is incredible, I can't find one on google...=20 >thanks, I did a similar search a couple of weeks ago, but I ended up rolling my own. This will get you started: http://www.opencores.org/projects.cgi/web/biquad/overview -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 106571
Frank Buss wrote: > Is this synthesizable? If you add a few declarations it is. http://home.comcast.net/~mike_treseler/irr.vhd http://home.comcast.net/~mike_treseler/irr.pdf -- Mike TreselerArticle: 106572
Mike, What's the advantage of the coding style you demonstrated in this example with procedures instead of direct assignments in the process? Thanks, /Mikhail "Mike Treseler" <mike_treseler@comcast.net> wrote in message news:4kejgsFbq463U1@individual.net... > Frank Buss wrote: > > > Is this synthesizable? > > If you add a few declarations it is. > > http://home.comcast.net/~mike_treseler/irr.vhd > http://home.comcast.net/~mike_treseler/irr.pdf > > -- Mike TreselerArticle: 106573
Nico, You posted: " datasheets lack important information on how the IOB are grouped together and the clock distribution limits resulting from that grouping " Could you be more specific? What is it that you found to be missing? Which part? Which package? What 'important information'? We spend quite a bit of time on the IO specifications, I would like to understand better what you felt is missing. Thank you, AustinArticle: 106574
I recently downloaded and installed XIlinx's Webpack ISE, version 8.2. I have been trying to work throught the quick start tutorial. I am at the part, where you create a test bench waveform for the simple counter example by having the tool plug in the anticipated results. When I select this option from the menu, the simulator tool (?) crashes with error code 222 and says that it was unable to run. I am not receiving any other information that seems relevant to the situation. The HDL syntax checker completes without complaint, nor can I see anything erroneous in the simple, example code. I have attempted to search on Xilinx's website for this error code. Their website has a caption about how there are numerous issues that can cause the simulator to crash and they are working through them. The cause that they have posted a solution for is that the installation directory can't have spaces in it (such as Program Files), which is not the cause of my problem as it is in the \xilinx directory. I also tried downloading and installing the service pack, with no success. Has anyone else encountered this problem and have a potential solution?
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