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
Tim schrieb: > Hi there > > I like to realize a counter, which has an UP and DOWN (and others). > I know, I need a clock for realizing asynchronious reset. > UP and DOWN are triggered by user switches. But I just found a > possiblity for realisation by using an extra Clock-Button - that's a > pretty bad solution! > > Can somebody help me and tell me what to change in my ABEL-Code, so I > don't need the Clock-Button?? > > I use this code > > MODULE unicnt > > > title '6 bit universal counter with parallel load' ; > "constants > X,C,Z = .X., .C., .Z. ; > > > "inputs > D5..D0 pin ; "Data inputs, 4 bits wide > clk pin ; "Clock input > rst pin ; "Asynchronous reset > cnten pin ; "Count enable > ld pin ; "Load counter with input data value > up pin ; "Up/Down selector: HIGH selects up > down pin; > > "outputs > q5..q0 pin istype 'reg'; "Counter outputs > > "sets > data = [D5..D0]; "Data set > count = [q5..q0]; "Counter set > > "mode equations > MODE = [cnten,ld,up,down]; "Mode set composed of control pins. > LOAD = (MODE == [ X , 1, X, X ]);"Various modes are defined by > HOLD = (MODE == [ 0 , 0, X, X ]);"values applied to control pins. > UP = (MODE == [ 1 , 0, 1, 0 ]);"Symbolic name may be defined as > DOWN = (MODE == [ 1 , 0, 0, 1 ]);"a set equated to a value. > > equations > when LOAD then count := data "Load counter with data > else when UP then count := count + 1 "Count up > else when DOWN then count := count - 1 "Count down > else when HOLD then count := count "Hold count > else count := count; > > count.clk = clk; > "Counter clock input > count.ar = rst; "Counter reset input > > END > may be i not really understand what you want to do, but any action of your counter (except reset) can only take place, if there is an counter clock present. Therefore you need clock for LOAD too :-( You could synchronize your input signal with a higher frequency clock or use asynchronous set and preset to load the counter this line is redundant: > else when HOLD then count := count "Hold count regards, Bertram -- Bertram Geiger, Graz - AustriaArticle: 60326
We see a variety of configuration issues on comp.arch.fpga, and we also see these in Altera's support center. To make it easier to debug these issues, Altera has created an online troubleshooter for configuration. This troubleshooter works by asking you various questions about your setup and what you are seeing on the board, then suggests various actions to take to solve the problem. I encourage designers to check it out if seeing configuration problems. The URL is here: http://www.altera.com/cgi-bin/ts.pl?fn=configuration Altera also has other online troubleshooters for PCI and licensing issues, found here: http://www.altera.com/support/kdb/troubleshooter/ts-index.html These tools will be useful for designers as you debug your systems. Enjoy! Sincerely, Greg Steinke gregs@altera.comArticle: 60327
"ykagarwal" <yog_aga@yahoo.co.in> wrote in message news:4d05e2c6.0309092246.2ead33f0@posting.google.com... (snip regarding pipelined divider) > well my requirement is too for double precision .. would u like to > suggest me a pipelined > comp arch book for this purpose.. anyway what is the best way, that's > what i want to explore first. The one I have here is "The Architecture of Pipelined Computers" by Kogge. > Xilinx coregen divider core doesn't offer that much width in its > pipelined divider .. don't know why > may be xilinx gurus can justify .. anybody knows which algorithm they > are using ? I don't know that, either. It might be because they didn't imagine anyone wanting to put something like that into an FPGA. They are likely pretty big, but in some cases it might be worth the size. -- glenArticle: 60328
I don't see in the Xilinx documentation in what clock domain the LOCK signal coming from a DCM is produced. Do I need to synchronize it into the CLK0 domain to avoid metastability? Thanks! John ProvidenzaArticle: 60329
You don't ask for much, do you? ;) Tom Hawkins wrote: > > I need a single chip solution for a control system and DSP > application. The only hard part of your request is the single chip requirement. You can get a lot of peripherals and memory embedded into an MCU, either small and cheap or some fairly large and powerful. But not many (if any) FPGAs have anything other than digital circuits. One exception is the PSOC from Cypress. This is an MCU (don't remember the type, it is either an 8051 derivative or a custom, 8 bit RISC chip) with programmable peripheral blocks and memory. The peripherals can be digital like a UART or analog like an ADC. If you only need 50 Hz and not simultaneous, you can mux a single ADC. The programmable digital blocks may be enough for your needs if combined with MCU code. > The primary consideration is board area. The second, cost. > Here's what I'm looking for: > - 5V supply and I/O. > - Embedded ADC (at least 1, preferably 8). Slow rate (50 Hz). > - Small FPGA fabric. About the size of a small spartan. > - Embedded block ram (4 KBytes). > - Flash FPGA. Would like not to have separate config prom. > - Low I/O count. I only need about 30 pins. > > Does anything like this exist? If 5V I/O is not possible, what's > needed to translate about 12 pins from 3.3/1.2 to 5V? I don't remember if the PSOC has 5 volt tolerant IOs. These have largely disappeared from newer families of logic. There are several ways to interface 3.3 volt IOs to 5 volt logic. It partly depends on the nature of your 5 volt interface. If it is just TTL, then you likely need to do nothing unless there is a chance the TTL levels will exceed 3.5 volts. Or you can use a bus switch driven from about 4 volt Vcc as a voltage limiter. Or you can use a level shifter bus chip. The bus chips come in 8 and 16 bit widths and some are very small packages. If the PSOC does not float your boat, you will likely need a two chip design, one for analog and one for FPGA. You can get an MCU in either chip along with the analog or FPGA. There are Flash FPGAs such as the Lattice XPLD devices. You didn't give a price target, but I got a quote once on the 512 macrocell part under $20, IIRC. Or if you get an MCU with analog IO, it will likely have enough Flash to program one of the smaller FPGAs. May be cheaper than the Flash FPGA. You didn't say anything about power. Most FPGAs are pretty power hungry. The CPLDs can be *very* low power. Both the Lattice parts and the Xilinx Coolrunner parts can get way below 1 mA if not clocked at a high rate. > Also, what's envolved for FPGA based software defined radio? I'd like > to build an RC (as in radio control airplane) receiver. Most FM > radios hop between 2 frequencies to encode pulse widths which in turn > drive the RC servos. So nothing digital. It just needs to extract > the pulse train from the FM. I would consider trading an FM receiver > chip for an external high-speed ADC and a larger FPGA if it buys > enough flexibility. It has been awhile since I have looked at digital radios, but if I am still current, the term "software defined radio" implies the final demodulation stage being done in software. The processing required for a digital radio means a high speed ADC at the IF stage and dedicated hardware for conversion to baseband. This can be done in an FPGA, but you are looking at a lot of power to make it work. This is likely way overkill for your application. You would still need the RF part of the receiver. Since an analog FM receiver is pretty much one chip, I don't see how this would help you. I expect you will find digital receivers are an advantage when you can share the IF stage between a lot of downconverters and demodulators such as in a cell phone base station or similar application. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 60330
In Xilinx ISE/Webpack, among the clock constraints you can also define the clock duty cycle. Why? I believed that all flip-flops were edge-sensitive. Is the placer&router somehow influenced by these constraints? If yes, how? My question comes from a practical problem I'm having. I need to use a short pulse (around 4-5 ns) as a clock in a Spartan2 (the frequency is around 100 MHz, but the problem persists at frequencies a lot lower). Apparently, even if the FF should be edge-sensitive, there are a lot of problems with short pulses, sometimes the edges are ignored or "doubled". My first idea was to "enlarge" the pulses by using a FDC with CLK connected to pulse, D connected to VCC and Q connected to CLR through some "delay" logic (buffers, inverters and so on), in order to have some propagation delay added to the pulse width. This solution worked poorly: sometimes I compile the project and the FPGA works nicely, but if I just add a flip-flop or move a signal and recompile the project, the result is totally unknown. Since I need to change the firmware often, and I can't test it every single time, this is bad. Now I have found a way that seems to work always, the schematic is like this: http://www.enetsystems.com/~lorenzo/temp/pulse.gif But I don't think it's very orthodox. :) So I remembered the duty cycle constraint. Could it help? Actually I need an input stage able to accept either negative and positive pulses, so the duty cycle would vary from nearly 0% to nearly 100%. (of course: no, I can't add external circuits) -- LorenzoArticle: 60331
Peter Alfke wrote: > > Let me try to repair the damage I did with my impatience: > > When capturing data that is asynchronous with the clock, the flip-flop > will inevitably go metastable sooner or later. > Metastability manifests itself in unpredictable additional clock-to-out delay. > The user knows the clock frequency, probably knows the data freqiuency > at least roughly, and should know the amount of tolerable extra delay, > or the acceptable Mean-Time-Between-Failure. > > Then one can consult the app note and table and see the connection. > MTBF is always inverse proportional to the product of the clock and data frequencies. > > Last October I published a XilinxTechXclusives paper which shows that at > a 300 MHz clock rate and 50 MHz data rate, the MTBF is one microsecond > for a total clock-to-Q plus set-up time of 1.0 ns. MTBF then increases a > million times for every additional half nanosecond available as extra delay. > At 3 ns, the MTBF is over a billion years. > All MTBF values must be scaled by the product of the two frequencies: > At 100 MHz clock and ~10 MHz data, the MTBF is, therefore, 15 times > longer. Is this correct ? Wouldn't the 3.3nS to 10nS increase in clock time, buy you (10-3.3)/0.5 lots of 'a million times' scalings ? Of do you mean the time to trigger a Event, not fail due to one ? What about this issue: With a CLK.Data stream, the CLK pulses that are not adjacent to the DATA edges, cannot have metastable events, so should not enter the scaling ? The best model would seem to be a Data.Aperture AND a Clock.Aperture, (both very small, but I don't think they HAVE to be equal ) and when they overlap/come closer than a critical time threshold, the metatstable dice rolls. What happens after the roll, depends on how far away the next clock is (call this the settling tail) Prediction stats would be an area-overlap basis, and assuming async signals ( non zero phase velocity ) the area product would be proportional to (Data.Aperture/Data.EdgeT) x (Clock.Aperture/Clock.EdgeT) Typically, Data.EdgeT = Data H or L time Clock.EdgeT = ClkPeriod This is average trigger/dice roll prediction, but the actual 'metastable dice roll profile' will depend on the phase velocity, and will have peaks much higher than the average. What if your system hits/moves very slowly over this 'phase jackpot' ? Here, area-mitigation stats are not much use, and you have to rely mainly on the settling tail to next clock ( and maybe a small amount on the natural system jitter ) IIRC Peter quoted 0.05fs virtual aperture time, and natural jitter is likely to be some few ps - certainly large relative to the aperture ? An experimental setup designed to focus on this phase jackpot, would give interesting results, and allow peak estimates, as well as a higher occurance for more usefull Tail stats gathering. Summary : Best predictor model would have Data.Aperture, Clock.Aperture and a Settling Tail. Exact nature of the settling tail is system measurable over a range of a few decades, but extrapolation is dangerous. > So, in short: > Metastability is unavoidable. All attempts to avoid it are inherently > doomed, but the quantitative impact of metastability is quite tolerable. > > That's it. Agreed. I still think from an 'average user' perspective, that a specific 'design cell' approach would help. Also, from a technical detail viewpoint, implementing a 'regenerative latch triplet' [Pre-Latch + Flip Flop] or [Dual Flip Flop] in a single local space, removes routing delays from one metastable tail. It does NOT 'fix' metastable behaviour, but it does encapsulate it, and move it to the best the silicon can provide, and eliminates the potentially variable routing delays. It also allows for future technical research and improvements to reduce the apertures, and the settling tail. - jg > Peter Alfke, Xilinx Applications > =================== > Jim Granville wrote: > > > > Austin Lesea wrote: > > > > > > So what is wrong with telling folks that fixing > > > metastability is a myth and waste of time? > > > > Nothing. > > > > > It is similar to the patent office not considering perpetual motion > > > machines. > > > > > > The basic physics of it is well understood, and that is that..... > > > > Perhaps not a ideal choice of words :) > > > > The practical reality and impact of metastability are (hopefully) > > well understood. > > As to basic physics, or even models, well - that seemed to be pretty > > much up in the air :) > > > > From all of this, I think there emerges a case for > > a 'Metastable Block' or cell, which can be used in the tools, > > and that the tools can model, and sdvise-the-use-of. > > > > This could have variants of Fall/Rise edge dual Flip Flips, or > > a Latch+FF ( effectively the same thing, but may be a better hardware > > fit on some target devices ) > > ( Tsu = half clock), > > or > > Rise/Rise dual Flip Flop > > ( Tsu = full clock, but longer metastable settling time ) > > > > This would help those who have yet to encounter WHY they > > need to address metastable events. > > > > - jgArticle: 60332
You should be careful to try to get as close as you can to the exact timing values. We had a lab-full of students implementing VGA controllers as part of their end-of-semester project, and they managed to burn out quite a few monitors before they got the kinks worked out (luckily, they were old monitors just laying around the lab, but the lab techs still weren't too happy with them ;). I suggest you find up a beat-up old monitor that someone is throwing out to use for your tests... Have fun, Pierre-OlivierArticle: 60333
Hi Ken, When I was working on a part of my project that had a clk and a clk2x, I didn't even need to specify the 2x period, as my signal was comming from the DCM, and ISE found that one itself. However, I did need to insert a timing ignore constraint (TIG) on the path that crossed my clock domain boundary. I'm always queasy about doing such things, and I haven't tested it out physically yet, so take it for what it's worth, but it got rid of my error messages, at least. Pierre-OlivierArticle: 60334
Tom Hawkins wrote: > > I need a single chip solution for a control system and DSP > application. > The primary consideration is board area. The second, cost. > Here's what I'm looking for: > - 5V supply and I/O. > - Embedded ADC (at least 1, preferably 8). Slow rate (50 Hz). > - Small FPGA fabric. About the size of a small spartan. > - Embedded block ram (4 KBytes). > - Flash FPGA. Would like not to have separate config prom. > - Low I/O count. I only need about 30 pins. > > Does anything like this exist? All in one package ? No. Triscend do a 80C51 + FPGA -> needs external loader, no ADC SoftCores + Std FPGA -> needs external loader, No ADC ActelProASIC -> Is FLASH, but needs Core + ADC STm uPSD family -> Has CPLD to 32 MCells Q42003 Cygnal -> FLASH.ADC, needs external FPGA Generic DSP devices -> needs external FPGA You need to nail down just how much DSP or control maths you need, and then find out how much of the small FPGA cannot be done in SW, or in the case of uPSD, in the Timer/Counter Peripherals assisted by the CPLD. - jgArticle: 60335
nagaraj_c_s@yahoo.com (Nagaraj) wrote in message news:<91710219.0309100448.6e8ab050@posting.google.com>...
> Hi,
> I want to interface a crystal to a Xilinx FPGA. Earlier Xilinx FPGA
> devices like XC2000 series had crystal input provision which is not
> there in Spartan 30K gate device which I am using for my design.
> I want to know how to build an oscillator circuit (amplifier) for
> the crystal in FPGA.
> Any references?
>
> Regards,
> Nagaraj
>Hi,
> I want to interface a crystal to a Xilinx FPGA. Earlier Xilinx FPGA
>devices like XC2000 series had crystal input provision which is not
>there in Spartan 30K gate device which I am using for my design.
> I want to know how to build an oscillator circuit (amplifier) for
>the crystal in FPGA.
> Any references?
>
>Regards,
>Nagaraj
>
mmm many people are paranoid about xtal oscillators it seems.
Still I agree the small integrated DIL ones are cheap and easy,
but for the ones who MUST use an xtal when all shops are closed,
this solution has always worked for me:
+5V
| drain
|----
----------------------->| BF245 B
| | | |----
| | === C |-----------0 to TTL level input
| | |-------------|
| | | |
--- | | | | |
= | | | | |
--- | |100k | | | 1k5
|XTAL | === 2 C |
| | | |
-----------------------------------------0
It can drive a HCT7404 or such directly.
Stability is very very good.
The caps ratio is 1 to 2 C, values like 22 and 44 pF (2 22 in parallel)
I use.
If the drawing looks distorted use a fixed spacing font perhaps.
I have uses this at 20MHz, 8.8MHz, 6 MHz, 100kHz, etc...
Always works.
Decauple the +5.
The output looks like a sine wave, bit flatted, but very clean.
If you want total separation, you can use a drain resistor and take
the signal from there.
Add a varicap with a small series cap parallel to the XTAL to make a voltage
controlled oscillator for a PLL etc..
(For example color subcarrier lock).
JP
Article: 60336You can phase align feedback using either the CLK0 or CLK2X DCM outputs. There is a relatively new application note on DCMs in Spartan-3 that may be useful to your question. XAPP462: Using Digital Clock Managers (DCMs) in Spartan-3 FPGAs http://www.xilinx.com/bvdocs/appnotes/xapp462.pdf Phase alignment is optional for the Digital Frequency Synthesizer function in a DCM. --------------------------------- Steven K. Knapp Applications Manager, Xilinx Inc. Spartan-3/II/IIE FPGAs http://www.xilinx.com/spartan3 --------------------------------- Spartan-3: Make it Your ASIC "John Providenza" <johnp3+nospam@probo.com> wrote in message news:349ef8f4.0309101349.2cbe675a@posting.google.com... > I don't see in the Xilinx documentation in what clock domain > the LOCK signal coming from a DCM is produced. Do I need to > synchronize it into the CLK0 domain to avoid metastability? > > Thanks! > > > John ProvidenzaArticle: 60337
I checked with Spartan marketing ( I will never quote specific prices without their blessing ), and they confirmed my numbers: The price per LUT/flip-flop is not constant. At the small end, the package cost drives it up, and at the high end, it is the yield loss that drives it up. The sweet spot is around the 3S1000 with 15 360 LUTs/FFs. It will sell in late 2004, slowest speed grade in large quantities for $20. That's 0.13 cents per LUT/FF. The number for the 2S400 is $10 for 3840 LUTs/FFs = 0.26 cents per LUT For the top-end 3S5000 it is $150 for 66 560 LUTs/FFs = 0.23 cents per LUT. That means I was pretty close with my 0.2 cents. Peter Alfke =================================== rickman wrote: > > Peter, > > I would like to know how you came to this number for the Spartan3 > parts. If I use this number for the XC3S400, I get 7168 x $0.002 = > $14.336. For the XC3S5000 I get 66,560 x $.002 = $133.12. Are these > realistic prices at all? What assumptions did you use? > > I understand that your .2 cents figure is only a rough rule of thumb, > but to be at all useful an understanding of the basis is needed. > > BTW, the discussion on metastability may appear to be a waste of > "bandwidth", but it is an important discussion since most people seem to > learn about it here rather than in school or elsewhere. I know there > were a great many things that were never even mentioned in school that > turned out to be essential to designing good circuits in the "real > world". > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAXArticle: 60338
Maybe a dumb question, but can a schematic built and tested in circuit maker 2000 be imported to Xilinx webpack and fitted to cpld rather then using webpacks schematic entry. Thanks, FredArticle: 60339
This is a classical circuit that always works. Note that there is only a single stage of amplification, a single transistor. So no weird phase/gain characteristi, just a single stage with a 6dB per octave roll-off. Unfortunately you cannot implement this between two FPGA pins. We added too much stuff (for a good reason, to serve normal applications ). Peter Alfke ============ Jan Panteltje wrote: > > > mmm many people are paranoid about xtal oscillators it seems. > Still I agree the small integrated DIL ones are cheap and easy, > but for the ones who MUST use an xtal when all shops are closed, > this solution has always worked for me: > > +5V > | drain > |---- > ----------------------->| BF245 B > | | | |---- > | | === C |-----------0 to TTL level input > | | |-------------| > | | | | > --- | | | | | > = | | | | | > --- | |100k | | | 1k5 > |XTAL | === 2 C | > | | | | > -----------------------------------------0 > > It can drive a HCT7404 or such directly. > Stability is very very good. > The caps ratio is 1 to 2 C, values like 22 and 44 pF (2 22 in parallel) > I use. > > If the drawing looks distorted use a fixed spacing font perhaps. > I have uses this at 20MHz, 8.8MHz, 6 MHz, 100kHz, etc... > Always works. > Decauple the +5. > The output looks like a sine wave, bit flatted, but very clean. > If you want total separation, you can use a drain resistor and take > the signal from there. > Add a varicap with a small series cap parallel to the XTAL to make a voltage > controlled oscillator for a PLL etc.. > (For example color subcarrier lock). > JPArticle: 60340
"Steven K. Knapp" <steve.knappNO#SPAM@xilinx.com> writes: > WebPack ISE 5.2i only supports the device called the XC3S50J (note the 'J'), > which has no block RAM or multipliers. > > WebPack ISE 6.1i, due out at the end of September, supports the XC3S50 (no > 'J'), which has four 18Kbit block RAMs, four 18x18 hardware multipliers, > and two Digital Clock Managers (DCMs). Will 6.1i and future versions continue to support the XC3S50J? Or do we need to keep the 5.2i release around for those? What does the "i" at the end of the software version mean, anyhow?Article: 60341
"Peter Alfke" <peter@xilinx.com> wrote in message news:3F5FB508.CC525671@xilinx.com... > I checked with Spartan marketing ( I will never quote specific prices > without their blessing ), and they confirmed my numbers: > > The price per LUT/flip-flop is not constant. > At the small end, the package cost drives it up, > and at the high end, it is the yield loss that drives it up. > > The sweet spot is around the 3S1000 with 15 360 LUTs/FFs. > It will sell in late 2004, slowest speed grade in large quantities for > $20. > That's 0.13 cents per LUT/FF. > I'm assuming XC3S1000-4FG676C will cost $85.65 in 5000 quantities. (This was a recent Xilinx quote.) I also assume that the $20 figure is for seriously large quanities, but I'm still surprised there's that much of a difference.Article: 60342
"Nagaraj" <nagaraj_c_s@yahoo.com> wrote in message news:91710219.0309100448.6e8ab050@posting.google.com... > Hi, > I want to interface a crystal to a Xilinx FPGA. Earlier Xilinx FPGA > devices like XC2000 series had crystal input provision which is not > there in Spartan 30K gate device which I am using for my design. > I want to know how to build an oscillator circuit (amplifier) for > the crystal in FPGA. > Any references? The oscillator that I used to know used three CMOS inverting gates in series with the crystal wrapped around them. Possibly some resistors, too. Usually one more gate to buffer and shape the result. Though I remember people having a hard time sometimes with the 32kHz crystals, it worked well for everything else. -- glenArticle: 60344
Use the micro to set up the packets in an FGPA/ASIC under isocronous control, and stream them out from there, if you can deal with the low data/frame rates - I used to build large format (4 x 5 and hasseblad) camera digital inserts using big CCD's - USB (even at 12Mbs is too slow for this stuff ( a 1Mpixel at 8 bit will require 2/3 sec + overhead to empty one frame) - tell you boss it sounds cool, but you need 1394 (firewire) or SCSI to do this worth a DS. If you simply want to capture one frame and empty it - consider dumping it to RAM and then out from there. Leaving stuff on a sensor - CCD or CMOS (yes CCD's are CMOS, both n and p type are built) results in large dark currents that make them unusable. At 2/3 second, well depth will be a large consideration here - electrons like to move around. Andrew james wrote: >On Sun, 07 Sep 2003 15:03:39 GMT, "GB" <donotspam_grantbt@jps.net> >wrote: > > > >>Hi, >> >>I'm a firmware guy pulled into a project well out of my area of >>expertise. My boss wants to build (essentially) a digital camera >>using an image sensor chip (1600x1200) and output it's data >>"as fast as possible" using USB2.0. His initial concept, being >>that I'm a firmware guy, was to use a "really fast micro." >>Normally the company is involved with small 8-bitter micro >>projects, so you can see I'm well out of my normal bounds. >> >>Now this seems like a pretty big stretch to me... and I don't see >>how it can be done without the speed of hardware (the image >>chips all seem to have clock speeds in the tens of MHz and the >>USB2 transfer rate is 480Mbps (theor.). Do aspects of this >>project require an FPGA to keep the data "as fast as possible?" >>If we use and FPGA for camera-to-RAM and then use a >>micro for the USB2 part, what kind of fast micros can >>move data at that rate? >> >>Also, this is something that I am sure we will have to contract >>out, so if you have any past experience with this, please let >>me know your thoughts (and if you are available). >> >>Thanks! >> >> >> >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >1600x 1200 is essentially a 2 megapixel camera! > >1) First step is to determine what the camera is going to be used for! > >Terrestial or astronomical or video photography > >2) Pick an imager! Either Sony, TI, Kodak, or Panasonic to name a few. > >3) From the Imager specs you can derive how fast the data can be >clocked out of the imager. Most imagers will transfer the image area >into a serial register one line at a time. How fast this is depends on >how fast you can clock the serial register. Transfer speeds differ >from vendor to vendor. > >4) Then build the circuitry around the imager based on its ability to >transfer the full image as fast as you want and that meet your cost >goals. > >Again depending on what you determine as reasonably fast will effect >the cost of the imager along with its size. Another consideration will >be the speed of the ADC. That can slow things down also. Even if you >can clock the serial register of the imager out at 20Mhz rate, if the >ADC sasmple rate is 10 MHz that is as fast as you can get the pixel >data out. > >IF your imager's max clock frequency for the serial register is 20 >MHz., you can clock a 1600 pixel row out in about 80 uS. Or the whole >image area out of the chip in about 100 mS. So your microC or FPGA >will have to read the ADC once every 50 nS or so during the readout >period. > >There are some CPU cores as well as USB cores that can drop into an >FPGA. You can build a large FIFO or add onboard flash to store the >picture. > >It is not crazy at all in fact it is quite doable. The two key items >in a digital camera is the imager and the ADC. All the rest is digital >hardware that is well suited for an ASIC or FPGA. > > >james > > >Article: 60345
turn it into an EDIF with no in/out buffers, and use it as a black box. Andrew juice28 wrote: >Maybe a dumb question, but can a schematic built and tested in circuit maker >2000 be imported to Xilinx webpack and fitted to cpld rather then using >webpacks schematic entry. > >Thanks, > >Fred > > > > >Article: 60346
Jim Granville wrote: > > Peter Alfke wrote: > > > > Let me try to repair the damage I did with my impatience: > > > > When capturing data that is asynchronous with the clock, the flip-flop > > will inevitably go metastable sooner or later. > > Metastability manifests itself in unpredictable additional clock-to-out delay. > > The user knows the clock frequency, probably knows the data freqiuency > > at least roughly, and should know the amount of tolerable extra delay, > > or the acceptable Mean-Time-Between-Failure. > > > > Then one can consult the app note and table and see the connection. > > MTBF is always inverse proportional to the product of the clock and data frequencies. > > > > Last October I published a XilinxTechXclusives paper which shows that at > > a 300 MHz clock rate and 50 MHz data rate, the MTBF is one microsecond > > for a total clock-to-Q plus set-up time of 1.0 ns. MTBF then increases a > > million times for every additional half nanosecond available as extra delay. > > At 3 ns, the MTBF is over a billion years. > > All MTBF values must be scaled by the product of the two frequencies: > > At 100 MHz clock and ~10 MHz data, the MTBF is, therefore, 15 times > > longer. > > Is this correct ? > Wouldn't the 3.3nS to 10nS increase in clock time, buy you (10-3.3)/0.5 > lots of 'a million times' scalings ? Jim, I have seen your name here before, but I don't know what your level of understanding of metastability is. So forgive me if I sound like I am talking down to you. I don't know if you are trying to discuss fine details of this topic or if you are new to the issues of metastability. If you look up references about metastability you will find that the MTBF time scales linearly with clock and data rate, but exponentially with settling time. There is a constant for each part of the equation. These two constants are what characterize a particular FF design and process used to build it. Peter's comment is saying that if you allow just 3 ns settling time with his rates and parts, you will have an MTBF of a billion years. Certainly you can go longer and get MTBF times longer than the age of the universe. So yes, 10 ns would be way more than enough. > Of do you mean the time to trigger a Event, not fail due to one ? No, a metastable event will happen with a much higher rate based only on the rate of the clock and data. But it will have no impact on your circuit if you don't use the output until after the metastability has settled out. Given a time period this calculation determines how often the metastable event will persist and cause an error. > What about this issue: > With a CLK.Data stream, the CLK pulses that are not > adjacent to the DATA edges, cannot have metastable events, so > should not enter the scaling ? This is already considered in the calculation. That is why the frequencies are multiplied. The assumption is that the two rates are truely asynchronous and are not correlated in any way. The the chance of them happening in just the right timing relation is a function of how often each of them is occuring. > The best model would seem to be a Data.Aperture AND a Clock.Aperture, > (both very small, but I don't think they HAVE to be equal ) and > when they overlap/come closer than a critical time threshold, > the metatstable dice rolls. What happens after the roll, depends on > how far away the next clock is (call this the settling tail) This may sound good, but it no different than the current model and would be much harder to measure. It is best not to think too hard about this, but rather to be a bit on the empirical side. That seems to be one way that Peter is very smart. His measurements seem very good to me and many others. It is no good to rationalize about things you really can't measure. > Prediction stats would be an area-overlap basis, and assuming > async signals ( non zero phase velocity ) the area product would > be proportional to > (Data.Aperture/Data.EdgeT) x (Clock.Aperture/Clock.EdgeT) > > Typically, Data.EdgeT = Data H or L time > Clock.EdgeT = ClkPeriod > > This is average trigger/dice roll prediction, but the > actual 'metastable dice roll profile' will depend on the > phase velocity, and will have peaks much higher than the average. I think "phase velocity" is *way* over the top. Before improving on the current formula, it would be good to find something wrong with it. Is there anything about it that falls short? > What if your system hits/moves very slowly over this 'phase jackpot' ? > > Here, area-mitigation stats are not much use, and you have to rely > mainly on the settling tail to next clock ( and maybe a small amount on > the natural system jitter ) > IIRC Peter quoted 0.05fs virtual aperture time, and > natural jitter is likely to be some few ps - certainly large relative to > the aperture ? All of this is really just a way to relate what is happening. Since the noise in the circuit is relatively large, I would expect tons more jitter in the "window" than the actual width. So really the fs window is just a concept, not a very real event. > An experimental setup designed to focus on this phase jackpot, > would give interesting results, and allow peak estimates, as well as a > higher > occurance for more usefull Tail stats gathering. > > > Summary : Best predictor model would have Data.Aperture, Clock.Aperture > and a Settling Tail. > Exact nature of the settling tail is system measurable over a range > of a few decades, but extrapolation is dangerous. Can you explain how this would be better than the current model? > > So, in short: > > Metastability is unavoidable. All attempts to avoid it are inherently > > doomed, but the quantitative impact of metastability is quite tolerable. > > > > That's it. > > Agreed. I still think from an 'average user' perspective, that a > specific 'design cell' approach would help. > > Also, from a technical detail viewpoint, implementing a > 'regenerative latch triplet' [Pre-Latch + Flip Flop] or [Dual Flip Flop] > in a single local space, removes routing delays from one metastable > tail. > > It does NOT 'fix' metastable behaviour, but it does encapsulate it, > and move it to the best the silicon can provide, and eliminates > the potentially variable routing delays. > It also allows for future technical research and improvements to > reduce the apertures, and the settling tail. Or you can just use the double FF approach and require a routing time for this path that is at least 3 ns less than the clock period. Again, simple, empirical and effective. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 60347
Pete Fraser wrote: > > "Peter Alfke" <peter@xilinx.com> wrote in message > news:3F5FB508.CC525671@xilinx.com... > > I checked with Spartan marketing ( I will never quote specific prices > > without their blessing ), and they confirmed my numbers: > > > > The price per LUT/flip-flop is not constant. > > At the small end, the package cost drives it up, > > and at the high end, it is the yield loss that drives it up. > > > > The sweet spot is around the 3S1000 with 15 360 LUTs/FFs. > > It will sell in late 2004, slowest speed grade in large quantities for > > $20. > > That's 0.13 cents per LUT/FF. > > > > I'm assuming XC3S1000-4FG676C will cost $85.65 in 5000 quantities. > > (This was a recent Xilinx quote.) > > I also assume that the $20 figure is for seriously large quanities, > but I'm still surprised there's that much of a difference. I recommend that you find an alternative and go back to your supplier for a better price. I have not gotten a quote for this part, but based on my experience you should be able to do better than $40 at your volume and package. You might be able to get below $30. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 60348
Glen Herrmannsfeldt wrote: > > "Nagaraj" <nagaraj_c_s@yahoo.com> wrote in message > news:91710219.0309100448.6e8ab050@posting.google.com... > > Hi, > > I want to interface a crystal to a Xilinx FPGA. Earlier Xilinx FPGA > > devices like XC2000 series had crystal input provision which is not > > there in Spartan 30K gate device which I am using for my design. > > I want to know how to build an oscillator circuit (amplifier) for > > the crystal in FPGA. > > Any references? > > The oscillator that I used to know used three CMOS inverting gates in series > with the crystal wrapped around them. Possibly some resistors, too. > Usually one more gate to buffer and shape the result. > > Though I remember people having a hard time sometimes with the 32kHz > crystals, it worked well for everything else. But what is the advantage over an oscillator unless you are trying to squeze every penny out of the design? The difference between an oscillator and a crystal is less than $.50. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 60349
Hi, During hierarchical design we often break down the design into small manageable parts. Now inter block communication specs are specified for this design alongwith internal function requirements. To verify the internal functioning and to simulate the external inputs to this design, we usually write force files in Modelsim. Now if we create a set of commmonly available stimuli like do-done handshake, random pulses, random duration levels, etc in Tcl, we could directly apply them to the signals on the interface we want to check. For response type of interfaces we could add dummy "done" generators. Now once such a suite of test inputs is available, we could easily test most of the small entities in a zap. Is such a tool done already? and are there some more types of communication behavious i am overlooking? I somehow think Modelsim signal forcing interface and the do-file writing for such a forcing is a dumb and painful way of testing things. regards, nachiket.
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