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
I'm having real trouble getting the CLKFX output of a DCM to work on an
XC2V1000. Pretty much all other outputs work fine (CLK1X, CLK2X and the
various phases). Input frequency is 75MHz. I've tried various ratios. Funny
enough, 2/2 works, but other non-unity ratios don't. Where should I look?
What would make the DCM DFS not work? Input clock jitter is minimal,
definetly well below datasheet specs. The code is pretty much out of the
book, nothing fancy.
module Clocks(
input wire CLKIN_PAD, // 75MHz input
output wire CLKFX_PAD // 160.71MHz out
);
IBUFG U1 (.I (CLKIN_PAD), .O (CLKIN_BUFFERED));
BUFG U2 (.I (DCM0_CLK0), .O (DCM0_CLKFB_W));
// synthesis attribute CLKIN_PERIOD of DCM0 is 13.33;
// synthesis attribute DFS_FREQUENCY_MODE of DCM0 is "LOW"
// synthesis attribute CLKFX_MULTIPLY of DCM0 is "15"
// synthesis attribute CLKFX_DIVIDE of DCM0 is "7"
// synthesis attribute STARTUP_WAIT of DCM0 is "FALSE"
DCM DCM0 (
.CLKIN (CLKIN_BUFFERED)
.CLKFB (DCM0_CLKFB_W),
.CLK0 (DCM0_CLK0),
.CLKFX (DCM0_CLKFX),
);
BUFG U3 (.I (DCM0_CLKFX), .O (CLKFX_PAD));
endmodule
The "_PAD" signals are assigned to specific output balls via the UCF file.
I've verified that these physical outputs work and that there are no SI
issues at >75MHz rates by routing both the input clock and CLK2X to them. No
prolems there. I looked at the results of the above using the FPGA Editor
and nothing looks out of place at all.
Any thoughts?
Thanks,
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian
To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_" = "martineu"
Article: 55926John Williams <jwilliams@itee.uq.edu.au> wrote in message news:<bak44a$n2f$1@bunyip.cc.uq.edu.au>... [...] > I basically mapped all of the DCM component generic parameters into > EDK-style parameters, and that all looks fine so far - the problem is > after bitgen completes it says: > > WARNING:Bitgen:242 - CLKIN_PERIOD is set to 0 ps which is less than the > minimum > of 2000 ps. The CLKIN_PERIOD is the period of the input clock to the > DCM. The > CLKIN_PERIOD is used by the DCM for frequency synthesis. To set the > CLKIN_PERIOD in the UCF use the syntax: INST "DCM instance name" > CLKIN_PERIOD=X ns; > > This happens despite the fact that the vhdl entity is being provided > with a parameter called "CLKIN_PERIOD" for this DCM component, and it > has a value (10.0 in this case). You MIGHT be running into this bug: http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=15876 ( http://tinyurl.com/cikh ) For those looking, the correct syntax is here: http://toolbox.xilinx.com/docsan/xilinx5/data/docs/cgd/cgd0064_12.html#wp1021317 (if that wraps, click here: http://tinyurl.com/cikn ) Good luck, MarcArticle: 55927
Klix, everybody was a beginner at some time... But please tell us the important parameters of your "system", and what you want to use it for. Your question is unusual enough to catch our attention... Peter Alfke, Xilinx Klix wrote: > > hi > > There is only one problem because I'm totally beginers and i have no any > ideas. > In conditions i have to use C/A converter ZN-426 and EPROM 2764. > Have you any example??? > > Kind regards > > Użytkownik "Klix" <embnet@tlen.pl> napisa3 w wiadomości > news:bajao6$kil$1@korweta.task.gda.pl... > > Hi > > > > I'm looking for project of nois generator in Xilinx. > > > > Kind regards. > > > >Article: 55928
Hi Leon, > I had done a design with QuartusII2.1,fit to EP1K50-3, > and got Fmax at 61MHz. > Today when I try to fit it again with QuartusII 2.2SP2, > I can get Fmax at 58MHz ONLY! > So stupid!!! I have to concur with Paul - even the slightest change in the netlist may reduce or increase performance by up to 10%. There's a bunch of tricks you could try, one of them is saving placement in the constraint file, but there's a funny one that generally (but not always) works for me: fit for the EP1K50-1, then change device to EP1K50-3 and redo timing analysis. Quartus will warn you that some settings have changed and whether you want to recompile or not. Say no to the recompile. This generally gives me about 5% better performance... Best regards, BenArticle: 55929
"Johan" <grimaldi88@hotmail.com> wrote in message news:ee7d8c9.-1@WebX.sUN8CHnE... > Hi > I have a 50 MHz clock that I would like to run in 5 MHz. Thus making it neccessary to use two clkdlls in serial. > If I set the generic CLKDV_DIVIDE to 2 or use the default value, 2, the lock signal appears. But if I use any other valid number than 2 the lock signal does not appear even though the division of the clock seams ok in the wavetrace. > > The same problem occurs both in ncsim and modelsim. > > My code and testbench can be found at http://bart.sm.luth.se/~johmat-8/ > > Regards > Johan Is there any advantage using the CLKDLL to do this over using a counter? RalphArticle: 55930
John_H wrote: > > "Jim Ranlett" <ballsofsteel@rcsis.com> wrote in message > news:53de32df.0305211648.7e8fcb54@posting.google.com... > < snip > > > What I'm really trying to do is implement an asynchronous state > > machine that changes state only when its inputs change, without regard > > to clocks. I don't have a clock to supply to the system. > < snip > > > Greetings, Jim. > > For an asynchronous state machine to work, can you guarantee that the four > inputs never change at (approximately) the same time? > > One of several reasons why synchronous state machines are used is that > multiple input changes can be resolved on the same clock. If the events are > asynchronous, the inputs would first be sampled with the system clock so > that all bits - state machine bits and outputs - see the same input values > so they can acto on those values over one clock period. If the inputs are > asynchronous and *not* sampled, one state bit might think the input is zero > and another state bit thinks it's a one. This leads to major confusion. > > If you can guarantee that only one input changes at a time (in-to-out time > is smaller than the time between input changes) then an asynchronous state > machine is possible, though still difficult. To discern between the > "previous" and "next" states without confusion, either a clean synchronous > approach or a "gray" coding scheme where only on bit changes for one input > change would be needed. If the 13 states were all in sequence, you couldn't > use a simple gray sequence because any true gray sequence is an even number > of states. > > I did an asynchronous state machine in my early engineering days with a > simple little ROM. A more experienced engineer said "it'll never work" but > it did. Maybe I was lucky, because ROMs could produce glitches > transitioning between bits of the same logic value. It's these kind of > nuances you might have to watch out for. Using a Gray code for the states is one way to do it, but that only allows state transitions that change one bit at a time. This may require adding states to allow the transitions you really want. I am surprised that you could get this to work in a ROM, since a ROM is not guaranteed to avoid glitches on outputs that do not need to change state. But I guess the timing of the ROM was such that it was not sensitive to its own glitches. As others have said, asynch state machine design is not trivial. I was taught a method in grad school but have never used it. Thinking about it, I belive it allowed transitions by creating intermediate states that got you from where you were to where you wanted to be with one signal changing on every transition. So it was basicly a Gray code. I have seen one ASM design used in over 20 years of hardware development. -- 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: 55931
Michael Bills wrote: > > Also, I'll be using slave serial mode. > > Michael Bills wrote: > > If you hold the INIT or PROGRAM pins low during power up does it matter > > if the power takes an extraordinarily long time to stabilize? ie. 400ms. > > > > Does INIT or PROGRAM need a falling edge? I was planning on just > > holding one or the other low during voltage stabilization and then > > releasing them after power is up. Does it matter if I use INIT or > > PROGRAM? Is one better than the other to use for what I need to do here? > > > > TIA, > > Michael > > I have not looked at the specifics of the Spartan 3 yet, but in general all Xilinx parts are level sensitive to PROG and INIT. There is a minimum assertion time on PROG, but since INIT is asserted by the part you can ignore it. INIT is used to synch several parts, IIRC. I remember trying to learn the Xilinx protocol and always found it very complex and confusing. I think this is mainly because they try to explain a lot of stuff that is not relevant to most users. The simple description is this... PROG is an input only. You assert PROG and the FPGA enters the Clear Configuration mode where it clears the configuration memory in a (semi)sequential manner. So this takes a bit of time. When it enters this mode, it pulls the INIT pin low. INIT is bidirectional, open drain. You can release PROG and the part continues through the clearing process and then goes through the entire memory one more time (at least with the older parts, again, I have not studied this carefully for the newer ones). Once the process is done, INIT will be released. If INIT is not high (some other FPGA holding it low) the FPGA waits. Once INIT goes high configuration starts. It is up to you to provide the CCLK and serial data in. When the data stream is complete the part expects a few extra clocks to move the part through the states of releasing reset to the FFs, enabling the outputs and setting the DONE pin high. Actually DONE is another open drain pin that was pulled low when you asserted PROG. This is also for sync between different FPGAs and the part will wait in the "almost ready" state while DONE is low. So you can configure the part and have it "one clock away" from running by holding this pin low if you want. If you ignore all the stuff about synching and the internals it gets even simpler. Just pulse PROG low to start reconfig. Wait for INIT to go high. Strobe your data in with CCLK. When you are done give a few extra clocks and watch for DONE to go high or INIT to go back low. Of course, time out on any of this stuff not responding like it should. -- 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: 55932
Beginning to go a little OT, but I found some links on using a reverse biased diode (or section of a transistor) as a noise source. Google "Noise Sources", an example page is.... http://world.std.com/~reinhold/truenoise.html --JoshArticle: 55933
Martin, By instantiating the CLK0 output, you have told the software that you want the DLL to sync the DFS to it (phase locked, and deskewed). It appears that you have nothing connected the CLKFB, which is specifically prohibited. CLK0 must be connected to CLKFB if any output of the DLL part is used (CLK0, CLK90, CLK180, CLK270, CLKDV, CLK2X, CLK2X_180). CLKFB must be fed from CLK0 or CLK2X (never CLKFX). Also, you should bring out the reset of the DCM, and specifically reset it once the input clock is stable. Often, between the time configuration is complete, and the DCM is LOCKED is so short, that the DCM may have trouble starting up. Austin Martin Euredjian wrote: > > I'm having real trouble getting the CLKFX output of a DCM to work on an > XC2V1000. Pretty much all other outputs work fine (CLK1X, CLK2X and the > various phases). Input frequency is 75MHz. I've tried various ratios. Funny > enough, 2/2 works, but other non-unity ratios don't. Where should I look? > What would make the DCM DFS not work? Input clock jitter is minimal, > definetly well below datasheet specs. The code is pretty much out of the > book, nothing fancy. > > module Clocks( > input wire CLKIN_PAD, // 75MHz input > output wire CLKFX_PAD // 160.71MHz out > ); > > IBUFG U1 (.I (CLKIN_PAD), .O (CLKIN_BUFFERED)); > BUFG U2 (.I (DCM0_CLK0), .O (DCM0_CLKFB_W)); > > // synthesis attribute CLKIN_PERIOD of DCM0 is 13.33; > // synthesis attribute DFS_FREQUENCY_MODE of DCM0 is "LOW" > // synthesis attribute CLKFX_MULTIPLY of DCM0 is "15" > // synthesis attribute CLKFX_DIVIDE of DCM0 is "7" > // synthesis attribute STARTUP_WAIT of DCM0 is "FALSE" > DCM DCM0 ( > .CLKIN (CLKIN_BUFFERED) > .CLKFB (DCM0_CLKFB_W), > .CLK0 (DCM0_CLK0), > .CLKFX (DCM0_CLKFX), > ); > > BUFG U3 (.I (DCM0_CLKFX), .O (CLKFX_PAD)); > > endmodule > > The "_PAD" signals are assigned to specific output balls via the UCF file. > I've verified that these physical outputs work and that there are no SI > issues at >75MHz rates by routing both the input clock and CLK2X to them. No > prolems there. I looked at the results of the above using the FPGA Editor > and nothing looks out of place at all. > > Any thoughts? > > Thanks, > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Martin Euredjian > > To send private email: > 0_0_0_0_@pacbell.net > where > "0_0_0_0_" = "martineu"Article: 55934
On Fri, 23 May 2003 17:40:02 GMT, "Steve Casselman" <sc_nospam@vcc.com> wrote: <stuff snipped> >Are you programming when you write Verilog or VHDL? Not if I'm doing my job right. Bob Perlman Cambrian Design WorksArticle: 55935
> By instantiating the CLK0 output, you have told the software that you > want the DLL to sync the DFS to it (phase locked, and deskewed). I do need CLK0 within the design. Also, I had no choice but to instantiate it due to the feedback requirement. > It appears that you have nothing connected the CLKFB, which is > specifically prohibited. The CLKFB input is actually being fed by CLK0 via: BUFG U2 (.I (DCM0_CLK0), .O (DCM0_CLKFB_W)); BTW, CLK0, CLK90, CLK180, CLK270, CLK2X, CLK2X_180 work just fine. I didn't try CLKDV. CLKFX, in light of all of the above working, doesn't seem to want to cooperate. Obviously something I'm doing ... or not. :-) I'll try the reset trick and see what happens. However, the input clock is, of course, externally generated and it is stable (at least outside the FPGA) the whole time. Thanks, -MartinArticle: 55936
Thank you all for your responses. I have finally solved the problem. It apears that the problem was in clock rate: in SOPC builder there is an option to specify clock rate that is supplied to Nios (by default it's something like 33 MHz). Most of the components that SOPC adds don't care what you put there - they just use whatever you assign to the "clk" pin of the Nios processor. But it isn't so in case of the UART - it needs the exact clock rate in order to calculate the how many cycles the RXD was down/up (that's, as you know, how RS232 protocol works). Since I was using different board (with different clock rate), leaving the default clock rate caused UART to function incorrectly. Thanks everybody. Yevgeny kempaj@yahoo.com (Jesse Kempa) wrote in message news:<95776079.0305230959.79f6d2a9@posting.google.com>... > Hi all, > > In addition, with Nios 3.0 (and higher) there is an on-chip debug > module that supports stdout communication (sort of like a UART) > through the JTAG pins. So, to implement a minimal Nios system > (running GERMS) that the user can interact with, a UART *or* the OCI > debug module is needed. > > I suggest checking out any designs labeled "minimal" in the Nios kit - > these do not use any external memory, but do have the GERMS monitor as > the program which boots. These designs are board independent - just > re-assign pins such as clock, reset, and txd/rxd (for a UART) and > you're ready to go. > > Jesse Kempa > Altera Corp. > jkempa at altera dot com > > > > fredrik_he_lang@hotmail.com (Fredrik) wrote in message news:<77a94d51.0305230248.6c889bba@posting.google.com>... > > syevgen1@hotmail.com (Yevgeny K.) wrote in message news:<6c3628cf.0305222258.7e39a6c5@posting.google.com>... > > > > Hi Yevgeny, > > You are right in your assumption I have all Altera Nios dev boards. > > The only default device you need for GERMS (if I am not misstaken) is > > a UART to send and revive commands over. > > Cheers > > FredrikArticle: 55937
>I think ( nor being a real expert) that LFSRs are good enough for >generating randomness in the physical world, but not good enough to >fight an intelligent attacker (crypto). That matches my understanding. >Still, one can use two relatively LFSRs of different length and XOR >their outputs, to make it "more random". The crypto geeks will laugh at you. There are only so many state bits that you have to figure out, so it's probably not any/much harder than figuring out the state for a single LFSR with the combined length. >The LFSRs need not be long, but should be run fairly fast. Ideal >application of an FPGA. Does running faster help? If the LFSR clock runs 10x the data clock then it just makes a different pattern. I'd expect it might help if the LFSR clock was not synchronized to the data clock. It's also worth noting that LFSRs generate a "random" sequence of bits. If you need random bytes/words, taking N bits out of the register every clock will not give you very random data. (The n+1-st sample is just the n-th shifted a bit with a random bit shifted in.) I think it works OK if you can clock it N times between grabbing a sample. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 55938
Hal, I agree. When I wrote: "Not good enough for crypto", I wanted to leave that aspect totally behind me, and have all following discussion concentrate on physical randomness. And I think that LFSRs are good enough if used with some common sense. Like, if you need 8 bits in parallel, use eight different-length LFSRs in parallel, each of them supplying one bit. I also wanted to emphasize that LFSRs are beautifully compact and fast in FPGAs, and even more compact in Xilinx FPGAs with their 16-times more compact SRL16s. I would never consider short LFSRs. Use 20 to 40 bits, which costs almost nothing: Somewhere between 3 and 5 CLBs, out of the 64 to 10,000 CLBs available in a Virtex-II chip, and that's before you start using SRL16s, which gets it into one CLB). And 200 MHz is easy for such small subsystems... Peter Alfke, Xilinx Hal Murray wrote: > > >I think ( nor being a real expert) that LFSRs are good enough for > >generating randomness in the physical world, but not good enough to > >fight an intelligent attacker (crypto). > > That matches my understanding. > > >Still, one can use two relatively LFSRs of different length and XOR > >their outputs, to make it "more random". > > The crypto geeks will laugh at you. > > There are only so many state bits that you have to figure out, so it's > probably not any/much harder than figuring out the state for a single > LFSR with the combined length. > > >The LFSRs need not be long, but should be run fairly fast. Ideal > >application of an FPGA. > > Does running faster help? If the LFSR clock runs 10x the data > clock then it just makes a different pattern. > > I'd expect it might help if the LFSR clock was not synchronized > to the data clock. > > It's also worth noting that LFSRs generate a "random" sequence of bits. > If you need random bytes/words, taking N bits out of the register every > clock will not give you very random data. (The n+1-st sample is just the > n-th shifted a bit with a random bit shifted in.) I think it works > OK if you can clock it N times between grabbing a sample. > > -- > The suespammers.org mail server is located in California. So are all my > other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited > commercial e-mail to my suespammers.org address or any of my other addresses. > These are my opinions, not necessarily my employer's. I hate spam.Article: 55939
E.g. count on rising and falling edge.Article: 55940
Ray Andraka wrote: > IF you've successfully dabbled with hardware, you certainly are ahead of the game. > Software folks who understand basic digital hardware are relatively scarce. I've run > into many that have a lot of difficulty designing hardware because they are writing > the VHDL like software with no consideration of what the circuit they are creating > might be. A common trouble encountered with software folks doing hardware is the > concept of propagation delays and how that affects the design timing. Well, this is something of a hobby for me (and a part-time one at that, business is important, recently). Unless I suddenly have to retrain to become a h/w engineer [grin] I'm unlikely to advance beyond where I am in the near future ... The typical (software) system I design these days involves multiple co-operating (typically black-box) subsystems, more often than not using a producer/consumer model, and more often than not in a network-distributed system. I don't have to *base* my code around propogation delays, but I do have to cope with a variant-around-a-mean propogation time between producer and consumer. Propogation delays (albeit at a higher level) are very much part of modern s/w design, Lock-step programming is still popular, I hear ... WHEN I did the jpeg encoder (which took me months, btw - I'm not claiming to be an expert here), it was my first major project beyond the typical risc CPU. (I learnt a lot from Jan Grey's site about cpu's :-), I wrote the individual bits in modules which were as self-contained as I could make them, but interfacing it with the final video hardware was still a nightmare :-( How can I put this... I learnt a lot :-) [On re-reading that, it sounds very defensive :-) I think that's a reaction to the emphasised "IF" ] Since then, I've not had as much time to "play" as I would like, but I do have a plan to see just how fast I can get a large (1024, maybe 4096 if I can manage it, fixed point will probably do) FFT to run in the S2300E... I have a SETI station (yes, I know, odds are billions to one against...) at the back of my house (http://seti.gornall.net/img/dish.jpg) which I'd like to "help out" in the processing stakes. You can never get enough FFT's for signal processing... Even on a reasonable CPU (AMD 1900) it takes ~200 uS to do a 4096 point forward-FFT, running flat-out. Since I'm actually supposed to be good at the pattern-recognition stuff, I'd prefer the computer to be running the neural-network & statistic/stochastic analysis, and the FPGA's (I have 3 of the burchEd boards :-) to be doing the grunt work on the raw data... When I get around to doing this, perhaps it will be time to learn "the knowledge" as Jan likes to put it... Bob Perlman wrote: > On Fri, 23 May 2003 17:40:02 GMT, "Steve Casselman" wrote >>Are you programming when you write Verilog or VHDL? > > Not if I'm doing my job right. This was more what I was originally aiming my comments at, anyway. I think there's a continuum between the two, although I'd not like to place the mean, or give standard-deviation figures for the curve :-) I guess that means I think there's a lot of variation on both sides... Apologies if this has rambled a bit. It's late, and I'm tired.... Simon.Article: 55941
Rising and falling edge only doubles the frequency, and any duty-cycle distortion ends up as jitter on the output. Modern FPGAs, like Xilinx Virtex-II have sophisticated Clock Management programmable circuits that can multiply and divide ( even both simultaneously) by many values over wide frequency ranges. Look at the appropriate data sheet and websites. click on, for example: www.xilinx.com or http://www.xilinx.com/xlnx/xweb/xil_publications_display.jsp?category=/Data+Sheets/FPGA+Device+Families/Virtex-II&iLanguageID=1 Peter Alfke, Xilinx Applications valentin tihomirov wrote: > > E.g. count on rising and falling edge.Article: 55942
"Dennis Maasbommel" <aabbccdd00@hotmail.com> wrote in message news:S7lya.1857672$sj7.80152275@Flipper... > From: "Dennis Maasbommel" <aabbccdd00@hotmail.com> > Subject: Modelsim generating (Sigsegv BadPointer Access)-error on winXP > Date: zondag 18 mei 2003 22:59 > > Hello again, you all ! > > The advice on my previous post (see below) was to upgrade to Modelsim > version 5.7. > So I did, but unfortunately, the program running on my winXP system, still > collapses when > I try to add signals to the wave window. And here I have no solution or > workaround yet. > > It occured to me, that perhaps the system collapses if I'd try to add > signals to the wavetable, > if they haven't been forced a particular value at all. So I forces the > signals a value and simulated > the model for some time, and THEN added the signals to the wave table. > Unfortunately, still no success. > > Is somebody able to help this student out here? > Thanks in advance. > > Best regards, > Dennis Maasbommel > Try using modeltechxe from xilinx. Not had a single problem with 5.6e. Suggest completely uninstalling -> reboot delete any directories that may be left for modeltech. Then reinstall. You may have caused this problem by installing over the top of your previous modeltech install. Also when installing turn off antivirus software. AlexArticle: 55943
Part of the problem is that describing hardware with the current crop of HDL's is akin to learning to speak in canned phrases. These phrases, everyone's agreed, mean something that you might not think they'd mean in the software world (you learn that tools will infer this or that...). This is almost like speaking in some sort of a foreign language where everything is said in metaphores. As long as everyone understands what the agreed-upon metaphores mean people can communicate. I think that's why FPGA design can look like software to some. The example that comes to mind is a decoder. I know of at least three common ways to "request" that a decoder be infered: 1- for loop. 2- case statement with explicit assignement of all output bits. 3- case statment that only assigns the selected bit and is preceded by a statement clearing all bits. The first choice I simply don't like. It yells out "software!!!, software!!!, sequential process!!!" like no other. The second is like describing the truth table in the data sheet of a decoder. It's all there in reasonable "hardware culture" speak. However, this can be painful to write and maintain for large decoders. Imagine doing a 128+ bit decoder! The third is somewhere in between. You have to understand inference to know what it will produce. To a software guy all of this looks like software. Unless they take the time to study hardware design they'll just let the synthesis tool worry about the process and hack away happily ... writing software. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu"Article: 55944
I'm new to FPGA's. Can anyone please suggest me where to start? AlsoI want to buy an FPGA board. Please tell me the specifications of any FPGA board that costs about $200-$500. From where I'll purchase it? Thanks AtifArticle: 55945
>I'm new to FPGA's. Can anyone please suggest me where to start? 1) Type <FPGA FAQ> to google. 2) lurk here. >AlsoI want to buy an FPGA board. Please tell me the specifications of >any FPGA board that costs about $200-$500. From where I'll purchase >it? Follow links from above. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 55946
"Atif" <atif@kics.edu.pk> wrote in message news:6a0a3f23.0305232057.7dfb813c@posting.google.com... > I'm new to FPGA's. Can anyone please suggest me where to start? > AlsoI want to buy an FPGA board. Please tell me the specifications of > any FPGA board that costs about $200-$500. From where I'll purchase > it? > Thanks > Atif www.digilentinc.com have some nice ones. www.burched.com.au many other fpga boards see http://www.optimagic.com/ and look for their fpga board list also fpga makers have lists of boards on their web pagesArticle: 55947
Well there is another interesting thing I discovered about chaining DLL's. I year ago I had a project, where I did chain to DLL's within a Xilinx Spartan-II device to get ~80MHz for SDRAM logic. I worked well by driving the 2nd DLL's Reset Signal with the inverted Lock Signal of the first stage. Never a problem it worked. Now 2 weeks ago I did more or less the same except that I did a for the second stage - for 100 MHz in Spartan-II - a feedback through a global input buffer. Now it did not lock at at power-up. I always had to press the reset button after power- up, then it did lock. Some strange thing may happen on the 2nd stage if you have an external global input pin for the feedback input. Adding a FPGA internal Reset logic for the 2nd stage - DLL two - did solve the problem completely. Now it always works... It seems to me that having the external feedback input is more supicious to system noise, and then it is not enough to drive 2nd DLL reset input from the first stage lock signal ... markus "brijesh" <brijesh_spam@vt.edu> schrieb im Newsbeitrag news:3ECD8CCB.7000007@vt.edu... > Whenever you are chaining two DLL's or DCM's make sure that you get the > second DLL's out of reset only after the first one has achieved lock. > Preferably after some delay. > > A xilinx App note concerning the use of DLL's talks about this requirement. > In the example they are generating 4x clock using 2 DLL's. > > I had the same problem generating 4x clock. Now with the delayed reset > it works fine. > > Hope that helps. > > Brijesh > > > Johan wrote: > > Hi > > I have a 50 MHz clock that I would like to run in 5 MHz. Thus making it > > neccessary to use two clkdlls in serial. > > > > If I set the generic CLKDV_DIVIDE to 2 or use the default value, 2, the > > lock signal appears. But if I use any other valid number than 2 the lock > > signal does not appear even though the division of the clock seams ok in > > the wavetrace. > > > > The same problem occurs both in ncsim and modelsim. > > > > My code and testbench can be found at http://bart.sm.luth.se/~johmat-8/ > > > > Regards > > Johan > > > > -----= Posted via Newsfeeds.Com, Uncensored Usenet News =----- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -----== Over 80,000 Newsgroups - 16 Different Servers! =-----Article: 55948
How about calling FPGA design: as "configware". Just a thought. Dasari. "Kate Palmer" <Kate.Palmer@nosiraeospam.co.uk.> wrote in message news:<baksst$8a3$2$8302bc10@news.demon.co.uk>... > You may (or may not) be interested in ESA's definition of firmware in > ECSS-P-001 (www.ecss.nl) which I presume is derived from the definition in > ISO/IEC 9126:1991 > > Firmware : Hardware that contains a computer program or data that cannot be > changed in its user environment. The computer program and data contained in > firmware are classified as software; the circuitry containing the computer > program and data is classified as hardware (ISO/IEC 9126:1991). > > It is not really clear to me wether they mean to include FPGAs in this > definition. > > If you then read ECSS-Q-80 Space product assurance - Software product > assurance and ECSS-E-40 Space engineering - Software they seem extremely > "computer" software biased. They don't say much more than "Software includes > the software component of firmware" and a few lines about device programming > in ECSS-Q-80. > > Kate > > "Joe Frese" <joefrese@hotmail.com> wrote in message > news:c176b8c2.0305211126.6e642649@posting.google.com... > > I've got a question of terminology for the group: is FPGA design > > generally classified as hardware, firmware, or neither? Most of the > > designs I've worked on have served to interface firmware with > > hardware. It seems that firmware engineers like to think of FPGA > > designs as more firmware, and that hardware engineers like to think of > > FPGA designs as more hardware. As an FPGA developer, though, I'm of > > the mind that the unique design considerations of the technology > > justify a new and separate category . . . > > > > A coworker suggested the term "coreware," but apparently that's a > > registered trademark of LSI Logic. Is there another term with the > > -ware suffix commonly used to refer to code (VHDL, Verilog, or > > otherwise) intended to be implemented in an FPGA? > > > > JoeArticle: 55949
On Sat, 24 May 2003 04:41:13 GMT, "Martin Euredjian" <0_0_0_0_@pacbell.net> wrote: >The example that comes to mind is a decoder. I know of at least three >common ways to "request" that a decoder be infered: > >1- for loop. >2- case statement with explicit assignement of all output bits. >3- case statment that only assigns the selected bit and is preceded by a >statement clearing all bits. 4 - shift operator. Here's a 3-to-8 decoder; decode_en is the decoder enable (HIGH for enable): wire [7:0] decodes; wire [2:0] decode_sel; assign decodes = decode_en << decode_sel; Continuous assignments are very useful. I don't know why they're not more popular. Bob Perlman Cambrian Design Works
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