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
As the name implies, an asynchronous reset resets the flip-flop or register immediately, without a clock. A synchronous reset input effectively forces the D input Low, sotat the flip-flop or register gets reset by the next clock, not immediately. Synchronous resets, in conjunction with low-skew global clocks, result in the best predictive behavior. But in certain special cases, you might need an asynchronous reset, to get the flip-flop reset before the next clock comes around. The penalty is less predictable, "sloppier" timing, especially if the asynchronous line has to drive many loads. Peter Alfke, XilinxArticle: 101376
On 28 Apr 2006 11:30:00 -0700, "rickman" <spamgoeshere4@yahoo.com> wrote: >People here are driving me crazy insisting that the Xilinx factory has >told them that you *MUST* tie the mode pins to either Vaux or GND. >After finding all the info in the data sheet and talking with support, >it looks pretty clear to me that the S3 parts have a very stiff >internal pull up and there is no need for an external pull up of any >kind, resistor or direct connection to Vaux. > >Am I misunderstanding? Why did the factory tell us before that the >mode pins *MUST* be tied to Vaux? Did we misunderstand what they were >saying? > >I promise this is the last time I will ask about this. I am totally >sick of going around this loop with everyone here. We leave them open, slave serial. Works fine. JohnArticle: 101377
Peter Alfke wrote: > John, this is analog territory, and there is NOT just ONE right answer. > > Obviously, a short circuit will always work, if you never need the pin > for any other purpose. > But we will not force you to do that, since you may have reasons not > to like it. It's a free country! > There is no mystery here, the purpose is only to establish a High > logic level. Nothing more, nothing less. > Obviously, a built-in pull-up resistor will establish a High logic > level, but it might be sensitive to crosstalk coming from your > pc-board.. > Obviously, any external resistor reduces the pull-up impedance, and > improves the situation. > Obviously an external pull-down resistor must be low enough in value to > overcome the internal pull-up resistance. > > And I still favor a multimeter for getting a grip on fundamentals. Wasn't there some question on just WHEN these pullups are 'alive' ? - a multimeter is not going to be much help there.... :( But a simple table in the data sheet, giving defined values, for all phases of Config state (includes Vcc's ), and what is needed (or not needed) for a legal logic condition, should nail it ? -jgArticle: 101378
Jim, please give us the benefit of the doubt, that we are not totally stupid. The mode pins are of interest at the very beginning of the configuration process. That's obviously when the pull-ups are active. I do not know when they are being de-activated, but trust us that they are active when it matters. We have 22 years experience in this technology, and have shipped many hundreds of millions of FPGAs... But you are right, there is always an opportunity for better documentation. Remember: This whole lengthy discussion never mentioned a technical problem or malfunction, only a diversity of suggestions, all of them correct. Peter Alfke, Xilinx, from homeArticle: 101379
Hello Peter, thank you for the answer. But the XC3190A is big enougth for my small projects and the package is good for hand soldering... ..and at last I have the parts but not the money;) For any projects I use the XC9536 and webpack 8.1i (21st century stuff!). The Book price is about 25eur and even if the Software is not comfortable I think its good enougth for my home build stuff. That is the reason for my question: Can I use the Book Software for my XC3190A? Thank you tuxfriend Peter Alfke wrote: > The XC3190A was introduced 15 years ago, which makes it hopelessly > obsolete. Even if you find the hardware sufficient (no on-chip RAM!), > the software is so antiquated that nobody should be forced to use it. > Get yourself a modern chip of Spartan or Virtex caliber and of 2003+ > vintage. The hardware is cheap, and the software is free, and both are > very competent. > Happy designing with 21st century stuff! > Peter Alfke, XilinxArticle: 101380
Hi all I am looking for ideas for: "FPGA Single LED Demos", The requirements for the demo Application are following: * Display visible 'sign of live' or 'self-test passed' message * Impemented in FPGA Vendor neutral HDL * <= 3000 LUT * <= 4KB of Block RAM * uncalibrated (+-50%) high frequency oscillator * 1 user LED for display The Demo application should have some sort of LED visible 'message' to indicate the demo is working or has passed internal self test code. There is no user interface byeound one single LED. Current list of Applications ================== 1) LED Blink (MSB of counter) - VHDL 2) LED Blink (MSB of counter) - Verilog 3) LED Blink (MSB of counter) - MyHDL (Python) 4) LED Fade with PWM (waveform from counter bits) 5) LED Fade with Delta-Sigma DAC (waveform from counter bits) 6) LED Fade with DDS and Delta-Sigma (waveform from ROM Table) 7) PacoBlaze LED Blink with Assembler Program 8) PacoBlaze LED Blink with C Program 9) SPoC(bit-serial-processor) LED Blink with Assembler Program 8) AVR like MCU LED Blink with Basic Program 10) PIC like MCU LED Blink with Assembler Program 11) C16 (16 Bit CPU) LED Blink with C Program 12) LED Blink with 32-bit Programmable Micro-Sequencer 13) Frequency Measurement demo (use stop watch and calculator) 14) ? your idea ? The above is my current list of demo applications, I am considering some more soft-core CPU's, but all those demos would be very similar to the existing soft-core demos. So any ideas to demo some other functionality are welcome. Best ideas can be rewarded with an FPGA evaluation board (with your idea pre-programmed). Suggestions a-la "soft-core cpu acme/xyz" will not count. AnttiArticle: 101381
Michael Hennebry wrote: > rickman wrote: > >> I am asking that you not wait until a frustrated user reports your >> mistakes. I am asking that you have someone look at what it takes to >> find all the info that an engineer needs to configure these parts and >> make the info consistent and more usable. > > Documentation by the designer is notoriously awful, > but to start with, the designer is who is available. > It takes a truly wonderful designer to put himself in the > position of someone encountering his design for the first time. > Just ask the people trying to use my documentation. > Input from frustrated users is necessary. > I don't have the information to know whether the documentation > for this part is as good as it could be given the user input. If they guy making development board for a part would not have access to anything except the datasheet, then maybe there would be improvements. Documentation is improved if it can be measured against a standard on what the documentation should contain. -- Best Regards, Ulf Samuelsson ulf@a-t-m-e-l.com This message is intended to be my own personal view and it may or may not be shared by my employer Atmel Nordic ABArticle: 101382
I may have overlooked something but I cant seem to find the dimensions of the platform flash PROM in a FS48 package. I have the datasheet but it appears not to be in it. Also had a look on the Xilinx website but again no luck. Can someone point me to the right place? Cheers JonArticle: 101383
Hi Antti, What about morse code to give the status? I should have some code in VHDL which I will dig out and send to you, Regards, Hans www.ht-lab.com Antti Lukats wrote: > Hi all > > I am looking for ideas for: "FPGA Single LED Demos", The requirements for > the demo Application are following: > > * Display visible 'sign of live' or 'self-test passed' message > * Impemented in FPGA Vendor neutral HDL > * <= 3000 LUT > * <= 4KB of Block RAM > * uncalibrated (+-50%) high frequency oscillator > * 1 user LED for display > > The Demo application should have some sort of LED visible 'message' to > indicate the demo is working or has passed internal self test code. There is > no user interface byeound one single LED. > > Current list of Applications > ================== > 1) LED Blink (MSB of counter) - VHDL > 2) LED Blink (MSB of counter) - Verilog > 3) LED Blink (MSB of counter) - MyHDL (Python) > 4) LED Fade with PWM (waveform from counter bits) > 5) LED Fade with Delta-Sigma DAC (waveform from counter bits) > 6) LED Fade with DDS and Delta-Sigma (waveform from ROM Table) > 7) PacoBlaze LED Blink with Assembler Program > 8) PacoBlaze LED Blink with C Program > 9) SPoC(bit-serial-processor) LED Blink with Assembler Program > 8) AVR like MCU LED Blink with Basic Program > 10) PIC like MCU LED Blink with Assembler Program > 11) C16 (16 Bit CPU) LED Blink with C Program > 12) LED Blink with 32-bit Programmable Micro-Sequencer > 13) Frequency Measurement demo (use stop watch and calculator) > 14) ? your idea ? > > The above is my current list of demo applications, I am considering some > more soft-core CPU's, but all those demos would be very similar to the > existing soft-core demos. So any ideas to demo some other functionality are > welcome. > > Best ideas can be rewarded with an FPGA evaluation board (with your idea > pre-programmed). Suggestions a-la "soft-core cpu acme/xyz" will not count. > > Antti > > > > >Article: 101384
Antti Lukats wrote: > Hi all > > I am looking for ideas for: "FPGA Single LED Demos", The requirements for > the demo Application are following: > > * Display visible 'sign of live' or 'self-test passed' message > * Impemented in FPGA Vendor neutral HDL > * <= 3000 LUT > * <= 4KB of Block RAM > * uncalibrated (+-50%) high frequency oscillator > * 1 user LED for display > > The Demo application should have some sort of LED visible 'message' to > indicate the demo is working or has passed internal self test code. There is > no user interface byeound one single LED. > > Current list of Applications > ================== > 1) LED Blink (MSB of counter) - VHDL > 2) LED Blink (MSB of counter) - Verilog > 3) LED Blink (MSB of counter) - MyHDL (Python) > 4) LED Fade with PWM (waveform from counter bits) > 5) LED Fade with Delta-Sigma DAC (waveform from counter bits) > 6) LED Fade with DDS and Delta-Sigma (waveform from ROM Table) > 7) PacoBlaze LED Blink with Assembler Program > 8) PacoBlaze LED Blink with C Program > 9) SPoC(bit-serial-processor) LED Blink with Assembler Program > 8) AVR like MCU LED Blink with Basic Program > 10) PIC like MCU LED Blink with Assembler Program > 11) C16 (16 Bit CPU) LED Blink with C Program > 12) LED Blink with 32-bit Programmable Micro-Sequencer > 13) Frequency Measurement demo (use stop watch and calculator) > 14) ? your idea ? > > The above is my current list of demo applications, I am considering some > more soft-core CPU's, but all those demos would be very similar to the > existing soft-core demos. So any ideas to demo some other functionality are > welcome. Most obvious is to extend to a BiColour LED, Driven from 2 pins, so that you can generate : Pure RED, Modulated RED (OE), Pure GREEN, Modulated GREEN (OE) and Colour Modulated (PWM %R/100-% G) Control lines are : R, R.oe, G, G.oe Then at eye-ball rates, you can signal something over 4 states, without needing long dividers. [Well, yes, this is only partially vendor neutral: it works on all those vendors who actually gave this some thought, and installed a BiColour LED ] My preferred modulation is PDM (Rate Multiplier), rather than PWM : PDM uses the least resource in CPLDs, and filters better in DAC applications. Also not on your list, is a RC5 / manchester Encoded LED modulate. Target the std IR-Remote Receivers, perhaps with an IR led in Parallel if the RED energy is too low to activate a NearBy - StdIR RX unit. That allows actual BIT serial (status flags) info to be sent, into a simple receiver. One-Wire encoding is another way to send Freq tolerant information, in an easily decoded manner. > Best ideas can be rewarded with an FPGA evaluation board (with your idea > pre-programmed). Suggestions a-la "soft-core cpu acme/xyz" will not count. -jgArticle: 101385
Hi all, I'm trying to develop a controller for the ZBT SRAM present on the ML403 board. When I make a post P&R simulation (using manufacturer verilog models of the memory) all is ok. But when I make on board tests nothing works. I even added a DCM for making board level clock deskewing. Please help. I would like to have a small basic example of a controller. CheersArticle: 101386
On Sat, 29 Apr 2006 18:54:31 -0700, Peter Alfke wrote:
> I am all for clear documentation, but it never hurts to keep the
> engineering mind alive.
> Compared to multi-gigabit receiver issues, this mode-pin level debate
> is really a trivial subject.
Not if you are not doing multi-gigabit receivers. The longer design
review issues go unresolved, the greater the probability they start
reaching non-engineering minds. You do not want "help" from these people!
~Dave~
Article: 101387
Peter Alfke wrote:
> Jim, please give us the benefit of the doubt, that we are not totally
> stupid.
Where did I claim that ?
> The mode pins are of interest at the very beginning of the
> configuration process.
> That's obviously when the pull-ups are active.
> I do not know when they are being de-activated, but trust us that they
> are active when it matters.
> We have 22 years experience in this technology, and have shipped many
> hundreds of millions of FPGAs...
> But you are right, there is always an opportunity for better
> documentation.
> Remember: This whole lengthy discussion never mentioned a technical
> problem or malfunction, only a diversity of suggestions, all of them
> correct.
Just to remind you - the audience, here is not you, Austin, Rickman,
etc, ( we ALL know 'it works' ) but those in rickman's reference :
" But some people here ("here" my work, not "here" the newsgroup) just
won't let go of the bone. They are insisting that the pins must be
connected to Vaux directly because of what they were told a year ago."
ie they are saying to him : 'Prove it'.
He is asking for Xilinx to help him do that.
-jg
Article: 101388Dave wrote: > On Sat, 29 Apr 2006 18:54:31 -0700, Peter Alfke wrote: > > >>I am all for clear documentation, but it never hurts to keep the >>engineering mind alive. >>Compared to multi-gigabit receiver issues, this mode-pin level debate >>is really a trivial subject. > > > Not if you are not doing multi-gigabit receivers. The longer design > review issues go unresolved, the greater the probability they start > reaching non-engineering minds. You do not want "help" from these people! Well said :) A little knowledge is a dangerous thing... -jgArticle: 101389
Antti Lukats <antti@openchip.org> wrote: >Hi all >I am looking for ideas for: "FPGA Single LED Demos", The requirements for >the demo Application are following: >* Display visible 'sign of live' or 'self-test passed' message >* Impemented in FPGA Vendor neutral HDL >* <= 3000 LUT >* <= 4KB of Block RAM >* uncalibrated (+-50%) high frequency oscillator >* 1 user LED for display >The Demo application should have some sort of LED visible 'message' to >indicate the demo is working or has passed internal self test code. There is >no user interface byeound one single LED. *) RS232 signaling sending something like "POST ok". Then you could just direct it to any laptop with ir-serial. Possibly IrDA. *) Morse code. *) Maybe 10 Mbps ethernet is doable. Guess not thoe :-) *) With an external mirror+stepper you could reflect the led light onto a paper and draw something. With a more stable oscillator possibilities vastly increase. contact at pb (a) ludd . luth DOT seArticle: 101390
Peter Alfke wrote: > We had a massive network problem inside Xilinx in San Jose, but that > was resolved on Friday. > Peter Alfke It seems OK now. LeonArticle: 101391
Hi all, I have a problem with MPPR (MultiPass Place and Route). The
first pass ends normally but at the begin of the place phase of the
second pass the processus fails and I get a {Process "Place & Route"
failed} message.
The problem apeared after I installed ISE8.1i service pack 03.
Any adea about the probelm?
Cheers
Article: 101392"Peter Alfke" <alfke@sbcglobal.net> wrote: >I much rather spend 10 minutes with a multi-meter than indulge in >contankerous debates in the newsgroup. >We are all engineers and not scribes, aren't we? I much rather chip manufacturers provide the required documentation so that thousands of engineers don't have to independently waste 10 minutes with a multimeter. Such questions need to be answered before you have any hardware to poke with a multimeter anyway. --Article: 101393
Peter Alfke wrote: > Jim, please give us the benefit of the doubt, that we are not totally > stupid. > The mode pins are of interest at the very beginning of the > configuration process. > That's obviously when the pull-ups are active. > I do not know when they are being de-activated, but trust us that they > are active when it matters. > We have 22 years experience in this technology, and have shipped many > hundreds of millions of FPGAs... > But you are right, there is always an opportunity for better > documentation. > Remember: This whole lengthy discussion never mentioned a technical > problem or malfunction, only a diversity of suggestions, all of them > correct. > > Peter Alfke, Xilinx, from home Lilliput in Gulliver's Travels comes to mind - wars fought over whether to break boiled eggs at the big or small end! LeonArticle: 101394
On Sun, 30 Apr 2006 08:51:30 +0200, tuxfriend wrote: > Hello Peter, > thank you for the answer. But the XC3190A is big enougth for my small > projects and the package is good for hand soldering... ..and at last I > have the parts but not the money;) For any projects I use the XC9536 and > webpack 8.1i (21st century stuff!). The Book price is about 25eur and > even if the Software is not comfortable I think its good enougth for my > home build stuff. That is the reason for my question: Can I use the Book > Software for my XC3190A? > > Thank you > tuxfriend > > Peter Alfke wrote: > >> The XC3190A was introduced 15 years ago, which makes it hopelessly >> obsolete. Even if you find the hardware sufficient (no on-chip RAM!), >> the software is so antiquated that nobody should be forced to use it. >> Get yourself a modern chip of Spartan or Virtex caliber and of 2003+ >> vintage. The hardware is cheap, and the software is free, and both are >> very competent. >> Happy designing with 21st century stuff! Peter Alfke, Xilinx Software support for the 3000 series was dropped years ago. What's the copyright date on the book that you are looking at? If the copyright is from the early to mid-90s then the included software will support the 3000 series. If the book has been updated in recent years the chances are they have a slightly obsolete version of Webpack included which won't support the 3000 series. If the book is from the early 90s, what media are the included tools on? Early 90s PCs had 5 1/4" floppies, good luck finding a 5 1/4" floppy drive. If it's on 3 1/2" floppies then you'll be able to read them because 3 1/2" drives are still available, your system might even have on if it's more than 2 years old. If the software is on a CDROM that's a sure indicator that it won't have 3000 series support. By the time that CDROMs became the standard means of distributing software support for the 3000 series had already been dropped. If what you want to do is to learn how to design with FPGAs it's not necessary to actually build something. My suggestion would be to download a copy of Icarus Verilog (it's free) and a copy of the current Xilinx Webpack (also free). Do design in Verilog and debug it using Icarus. Then you can place and route it using Webpack. 21st century FPGA designers don't spend much time in the lab debugging on the actual hardware, the debugging is done using a Verilog simulator.Article: 101395
Hans wrote: > Hi Antti, > > What about morse code to give the status? > > I should have some code in VHDL which I will dig out and send to you, > Best to then blink the Morse dots using PWM at 1KHz and 50% duty cycle so that you can also hear it with a solar cell and a piezo earpiece ;-) BenArticle: 101396
John Larkin wrote: > On 28 Apr 2006 11:30:00 -0700, "rickman" <spamgoeshere4@yahoo.com> > wrote: > > >People here are driving me crazy insisting that the Xilinx factory has > >told them that you *MUST* tie the mode pins to either Vaux or GND. > >After finding all the info in the data sheet and talking with support, > >it looks pretty clear to me that the S3 parts have a very stiff > >internal pull up and there is no need for an external pull up of any > >kind, resistor or direct connection to Vaux. > > > >Am I misunderstanding? Why did the factory tell us before that the > >mode pins *MUST* be tied to Vaux? Did we misunderstand what they were > >saying? > > > >I promise this is the last time I will ask about this. I am totally > >sick of going around this loop with everyone here. > > > We leave them open, slave serial. Works fine. At last, a clear, rational statement. Thanks. I can't say that solves my problem though. I have little doubt that there is any issue to the pullups working if you just leave them open. The fact that they are such a low resistance seems to me to make it a near certainty that they will pull up properly if left open. This board is currenly ready to come out of layout with the only remaining issues, SI on the data and address bus which we think is due to an overly agressive TI IBIS model, it does not match the units we can measure; and this stupid pullup resistor issue. There is little doubt in my mind that the stiff internal pullups make an external pullup unnecessary. I spoke with the engineer who had spoken with the Xilinx factory person and I had trouble finishing a sentance without being interrupted. It is very likely that she misunderstood what Xilinx was saying to her. I expect she was told that the pull *down* resistors needed to be tied directly to GND and/or the distinction between the pull ups and pull downs was not made. The fact that the data sheet and app notes show direct connections to Vaux and GND does not make the matter any more clear. Just to be very clear that the difference between a resistor pullup and a direct connection is not splitting hairs, we have a current part on a board that does not work correctly because of a similar issue. The pin has three states for setting an I2C bus address; high, low and open. Seems the part is having trouble distinguishing the difference between high and open with most reistor values. That data sheet also did not make it clear what value resistor was required as well as the level of noise immunity on the input. That engineer is working a lot of unpaid overtime at the moment. I prefer to get this ironed out before I am done with layout and can still make a change if *required*.Article: 101397
Josh Rosen wrote: >If what you want to do is to learn how to design with FPGAs it's not >necessary to actually build something. My suggestion would be to download >a copy of Icarus Verilog (it's free) and a copy of the current Xilinx >Webpack (also free). Do design in Verilog and debug it using Icarus. Then >you can place and route it using Webpack. 21st century FPGA designers >don't spend much time in the lab debugging on the actual hardware, the >debugging is done using a Verilog simulator. ModelSim XE starter is also a free simulator, and supports both VHDL and Verilog. Both languages are widely used. -- Phil Hays (Who is leaving on a trip today to get a Xilinx badge, among other things.)Article: 101398
> Software support for the 3000 series was dropped years ago. What's the > copyright date on the book that you are looking at? If the copyright is > from the early to mid-90s then the included software will support the 3000 > series. If the book has been updated in recent years the chances are they > have a slightly obsolete version of Webpack included which won't support > the 3000 series. The Book is copyright 1999 and available at amazon.de: http://www.amazon.de/exec/obidos/ASIN/0130216178/qid=1146409138/sr=8-10/ref=sr_8_xs_ap_i10_xgl/028-0087165-6861379 But for that ISBN there are 3 Versions of this book !?!? http://dogbert.abebooks.com/servlet/SearchResults?isbn=0130216178 > If the book is from the early 90s, what media are the > included tools on? Early 90s PCs had 5 1/4" floppies, good luck finding a > 5 1/4" floppy drive. That is no problem, I have some of these in my personal museum ;) > If it's on 3 1/2" floppies then you'll be able to > read them because 3 1/2" drives are still available, your system might > even have on if it's more than 2 years old. If the software is on a CDROM > that's a sure indicator that it won't have 3000 series support. By the > time that CDROMs became the standard means of distributing software > support for the 3000 series had already been dropped. Oh, I think that will be the problem. > > If what you want to do is to learn how to design with FPGAs it's not > necessary to actually build something. My suggestion would be to download > a copy of Icarus Verilog (it's free) and a copy of the current Xilinx > Webpack (also free). Do design in Verilog and debug it using Icarus. Then > you can place and route it using Webpack. 21st century FPGA designers > don't spend much time in the lab debugging on the actual hardware, the > debugging is done using a Verilog simulator. I would like to build something, and as I wrote before I did it with the XC9536 now it should be a little bit more. I think it would be the best I try to find it in a library before to buy. Thank you for the usefull information tuxfriendArticle: 101399
Hi, I am targeting the design for XC2C512 coolrunner device. That's the biggest device i could find. Are you aware of any larger CPLD device? I have a dual-edge triggered clock i.e i have no other CPLD choice other than the coolrunner series. I find that i am falling short of a dozen macrocell counts. The fitter report says it needs 524 macrocells and i have 512 macrocells available to me :-( I have tried to optimize the design to my best possible knowledge (and my knowledge is not that profound). Can anybody here advise me on how to squeeze the design a LITTLE BIT more to make it fit into the XC2C512 device? Thanks.
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