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
Yves Savard wrote: > I need for clocks out, one at 236,16Khz, a other at > 245Khz, thirth > 254,8Khz and the last 269,5kHz from reference crystal at > 10Mhz i need a PLD > or PFGA to make a counter with 4 output for each frequency > !! > My question what the best I can use for this ? > > It is inherently impossible to derive the frequencies mentioned from a 10 MHz crystal, if you expect jitter-free output clocks. The reason is simple: Any edge derived from a 10 MHz input will be on boundaries that are n times 100 ns apart, but the frequencies mentioned have periods that are not integer multiples of 100 ns. Now, you can cheat and generate average freuencies that come very close to your desired values, by using direct digital synthesis or phase accumulators, but you must first decide how much systematic jitter you can accept. Peter Alfke, Xilinx ApplicationsArticle: 15026
On Wed, 3 Mar 1999 09:48:57 -0800, "Joel Kolstad" <JKolstad@Electroglas.Com> wrote: >Assume you have a state machine that has some "interesting" state >encoding... say the reset state encodes to 1010, and then the state machine >always steps to a state encoded by 0101. This state machine has an >asynchronous reset input, which comes from a pin on a CPLD or FPGA. The >clock to this synchronous state machine also comes from a pin. > >Isn't a completely asynchronous reset input just asking for trouble? While >reset is active, the state machine is sitting at 1010. If I now assume that >reset goes inactive just a split (nano)-second before the active clock edge, >I don't have any guarantees at all that some of the state encoding bits are >going to transition to their expected new values, whereas some won't >transition at all, correct? Absolutely correct. If the reset is deasserted asynchronously at or near the active clock edge, your next state may be hash. >If this is really an issue, it would appear that the correct way to apply an >asynchronous reset is to first run it through a synchronizer before applying >it to the asynchronous reset input of the state machine. The rule I follow is to assert reset asynchronously and deassert it synchronously. Resetting asynchronously ensures that the state machine initializes correctly even in the absence of a good clock; this can be important if, say, the state machine is controlling TriState buffers that must not contend (and that might contend if the state machine is in an illegal state). Deasseting reset synchronously circumvents the problem you described. There are situations in which asynchronous assertion/deassertion is OK, though. If you can guarantee that the state machine isn't going to transition states immediately after reset is deasserted, then asynchronous deassertion should work (counter-examples, anyone?). Clearly, this doesn't work for the state machine you've described, which transitions to the next state immediately, rather than waiting for an input. I prefer to always synchronize deassertion, so as not to have to guard against all possible cases of immediate state change. Bob Perlman ----------------------------------------------------- Bob Perlman Cambrian Design Works Digital Design, Signal Integrity http://www.best.com/~bobperl/cdw.htm Send e-mail replies to best<dot>com, username bobperl -----------------------------------------------------Article: 15027
Joel Kolstad wrote: > Isn't a completely asynchronous reset input just asking > for trouble? > snip > If this is really an issue, it would appear that the > correct way to apply an > asynchronous reset is to first run it through a > synchronizer before applying > it to the asynchronous reset input of the state machine. > > ---Joel Kolstad You got it. There was a spirited discussion here about this subject in late Dec 98. Peter Alfke, Xilinx ApplicationsArticle: 15028
Davide Rizzo a écrit dans le message <7bjm50$io$1@nslave1.tin.it>... >"saffary" <saffary@club-internet.fr> wrote: > >>Does anyone have a lcd cntrol core, and ,or info about this. > >>Thanks > > >Please be more specific, which kind of LCD ? Static, multiplexed, or >grafic? How many segments (/pixels) ? > > Grafic (128*64 ) ThanksArticle: 15029
Bob Sefton wrote in message <36DD861A.5B0EF4A9@home.com>... >Create a divide_by_5 circuit, delay it by 2.5 cycles, then OR the >original and delayed versions together. OK, but how do I reliably create a "delay by half a cycle" circuit? At the rising edge of the 100MHz clock, say my divide_by_circuit circuit fires an output active. To delay by half a clock, another register has to pick up this active output on the falling edge of that same clock, 5ns later, correct? Hence you need a CPLD that could internally clock at 200MHz, no? Thanks for the the response. ---Joel Kolstad Any CPLD that can clock on >both edges of the 100MHz clock should be able to do this. You may >then want to register the ORed result again with 100MHz. > >Bob S. > >Joel Kolstad wrote: >> >> Does anyone have a clever circuit that can divide an input clock by two and >> a half? We're looking to go from 100MHz down to 40MHz. I've thought of a >> couple of ways to do this, but they all had some asynchronous parts to them >> that required that I could guarantee minimum propagation delays. In a >> 100MHz part I didn't really want to have to guess at the minimum propagation >> delays (neither Xilinx nor Cypress nor Vantis -- vendors whose CPLDs we're >> thinking of implementing this in -- mention their minimum propagation delays >> in the data sheets that I looked at). >> >> Additionally I don't want to buy a faster speed grade device -- any change >> in speed grade would cost more than the ~$3 of an external PLL. (In which >> case I'd divide by 5 and multiply by 2.) >> >> Most CPLDs these days can clock on either edge of the incoming clock, and it >> initially seemed that a design that had two "divide by fives" and then >> combinatorially ORed the results together would work. Getting the two >> circuits synchronized is the problem. Either they have to rely on each >> other's output, which effectively means the design is running at 200MHz >> internally, or they have to rely on an external result pulse, and generating >> it at the exact time point required appeared difficult. >> >> ---Joel KolstadArticle: 15030
"FPGA system clock speed" usually refers to the maximum rate at which an output flip-flop can reliably drive an input flip-flop on another device of the same type. The SUM of the clock-to-output and input setup times must be less than the clock cycle time, i.e. 12.5 ns for 80 MHz. The '98 Xilinx book shows the smaller -09 parts meeting this spec (4005XL: 5.4ns Tickof + 5.6 ns Tpsd = 11ns) using fast outputs, but add 1.7 ns for slew-rate limited outputs. And subtract 0.8 ns if the capacitive loading is 20pf instead of 50 pf. The bigger parts have slower I/O: 9 + 8.4 = 17.4 ns or 57 MHz for the 4085. Various tricks with fast clocks, using no-delay IFF's etc. can help somewhat, but reliable 100 MHz system clock rates are still a challenge with these parts. The XLA and Spartan look better for 100 MHz operation. Pierre Langlois wrote: > > Hello all, > > I find that the Xilinx documentation is vague on this subject. For > example, for a certain design I have, the TRACE tool reports that all > constraints are met for a clock frequency of 100 MHz in a X4000XL-09 > chip. This includes 10ns constraints on "from pads to INFF" and "from > OUTFF to pads". This is consistent with "IOB Input and Output Switching > Characteristic Guidelines" for the family, which list propagation delays > all well under 5ns for the XL-09 family. > > However, the generic Xilinx document "XC4000E and XC4000X Series FPGAs", > dated Nov 10, 1997, says that the devices " ... can run at synchronous > system clock rates of up to 80 MHz, and internal performance can exceed > 150 MHz." > > Is there some limitation that kicks in at 80 MHz for the I/Os? What is > it? Any suggestions on how to get around it? Thanks in advance. > -- Tom Burgess Email: tom.burgess@hia.nrc.caArticle: 15031
I was having problems with inserting bi-directional buffers with an Orca FPGA. I have tried both using the "insert_pads" command with Synopsys and instantiating directly a "BTZ6" cell. From what I can tell, it looks like the output buffer side is staying tri-stated. Previously, I had been using two pins tied together (one in, and the other a simple tri-state out) and this has worked fine. But, I would like to not have to do this for a larger set of signals that I now need to use. Curious if there are any "tricks" or bugs that I'm not aware of. Thanks for any help. -- -- Allen Norskog Hewlett-Packard allen@fc.hp.com (970) 898-9120 FAX: (970) 898-6580Article: 15032
Hi Yves, as counters cannot provide the fractional divisions you need, you'll have to use another method. Search the web for "direct digital synthesis" to get more information about a recommendable one than i could write here. On Wed, 03 Mar 1999 15:33:57 GMT, "Yves Savard" <ysavard@riq.qc.ca> wrote: >I need for clocks out, one at 236,16Khz, a other at 245Khz, thirth >254,8Khz and the last 269,5kHz from reference crystal at 10Mhz i need a PLD >or PFGA to make a counter with 4 output for each frequency !! >My question what the best I can use for this ? > >Thank you !!Article: 15033
TNG associates 301 Histon Road Cambridge CB4 3NF Tel 01223 358988 Fax 01223 358970 web site http://tngrec.com e-mail mrn@tngrec.com Hello! I hope that this communication does not breach newsgroup etiquette. We are placing it (manually) on a small number of specialist sites. We are keen to hear from any embedded engineers who would like to look at other job opportunities. The type of positions we are dealing with can be seen on our Website. We guarantee that CVs are never sent out without the permission of the individual on each separate occasion, and even then are only sent to specific companies who have expressed interest in receiving such details from us. Indeed, the majority of the positions we are handling are exclusive to us. We hope to hear from you. Yours, Murray Newlands Example Senior Software Design Engineer. Idyllic rural location near Ipswich. Salary negotiable The company designs, develops and manufactures systems for subtitle generation, storage and transmission, for sale to the Broadcasting Industry. Strong ‘C’ programming in embedded real-time systems are the core skills required. Ref 1739n Contact Michael Wyatt at mjw@tngrec.comArticle: 15034
True. I should have read your entire post. You don't want to pay the premium for that much speed. If you can handle 5ns (1/2 of a 100MHz cycle) of jitter on the 40MHz clock you can alternately div_by_2/div_by_3. Otherwise it sounds like the PLL is your best (and most flexible) bet. Good luck. Bob S. Joel Kolstad wrote: > > Bob Sefton wrote in message <36DD861A.5B0EF4A9@home.com>... > >Create a divide_by_5 circuit, delay it by 2.5 cycles, then OR the > >original and delayed versions together. > > OK, but how do I reliably create a "delay by half a cycle" circuit? At the > rising edge of the 100MHz clock, say my divide_by_circuit circuit fires an > output active. To delay by half a clock, another register has to pick up > this active output on the falling edge of that same clock, 5ns later, > correct? Hence you need a CPLD that could internally clock at 200MHz, no? > > Thanks for the the response. > > ---Joel KolstadArticle: 15035
Joel Kolstad wrote: > Does anyone have a clever circuit that can divide an input > clock by two and > a half? We're looking to go from 100MHz down to 40MHz. The easiest, simplest and safest method is to cheat and build a circuit that divides alternatingly by 2 and by 3. So it generates two output periods for every five input periods. You have your 40 MHz average output frequency, but the two adjacent output periods are of unequal length, one of them 20 ns, the other one 30 ns. That circuit is trivial to implement in two CLBs. The price you pay is that, worst-case, the output is as demanding as 50 MHz, and the spectrum is not pure. May be good enough in many applications. Peter Alfke, Xilinx >Article: 15036
Hi Robert
About a couple of years ago I was at the point you describe, and went with
Altera. Their MaxplusII software includes a library of TTL macrofunctions that
can easily be included in your design. However once you get the hang of their
LPMs (Library of Parameterised Megafunctions) I doubt you'll use them very much.
A good example is the 10 bit counter you need. Typically you might have to wire
that up using 3 4-bit counters, if restricted to TTL 74 series style functions.
The alternative is just to use a LPM_COUNTER WITH (LPM_WIDTH=9). If your
requirment changes, then just change the LPM_WIDTH value. If you choose to
design in Altera Hardware Design Language (AHDL) you can define a parameter
early in the design file, and declare your counter and any other datapath
elements in terms of that parameter. This parameter can be passed down to
whatever level of hierarcy nesting you like.
I know of no other HDLs that provide this facility - allowing that VHDL &
Verilog are synthesis languages rather than simple hardware description
languages. Please correct me if I'm wrong.
Initially I'd say stay away from VHDL & Verilog - their way too complicated for
what you describe.
Hardware wise look at Altera's MAX7000S series, the schematic for a parallel
port programmer is on their website. 5 volt family.
Other useful sites are www.freecore.com - a collection of utilities, modules &
tutorials for Altera parts. www.optimagic.com has a whole bunch of useful stuff.
Disclaimer: I speak as a satisfied Altera customer who uses their parts for
low speed (<20 MHz) designs. I have no other relationship with Altera.
In article <19990302151902.13531.00003629@ng-ch1.aol.com>
robert4422@aol.com "Robert4422" writes:
> Hello folks,
>
> I am trying to get started in programmable logic, but so far having somewhat of
> a hard time. I have a simple project sitting in my digital circuit emulator
> program, and I would like to realize it using some kind of programmable logic
> device. Actually, I had been planning to realize the design in discrete 74xx
> TTL's (it's that simple--just a 10-bit counter, some AND gates, some flip
> flops, and some NAND gates), but I thought this might be a good time to get
> into the world of programmable logic devices. So far, however, I'm having a
> lot of trouble sorting through all the different kinds of devices that are
> available, and was wondering if anyone here could help me out.
>
> Specifically, perhaps someone could help me with the following questions:
>
> 1. What kind of programmable devices should I be looking into to implement the
> design mentioned above? I assume the presence of flip-flops and an n-bit
> counter is a little beyond the level of PALs and GALs, but perhaps I'm wrong?
> Is FPGA what I need/want, or something else entirely?
>
> 2. Moreover, can someone give a brief description of the differences between
> the major families of programmable devices? e.g., PAL vs. GAL vs FPGA etc.
> (if there's a FAQ or other reference that does this, please just point me to
> it.)
>
> 3. Which families of devices have TTL-level inputs/outputs?
>
> 4. What are some good introductory reference materials? Books, websites, etc.
>
> Thank you for your time and help in getting a beginner started!
>
> Rob
>
>
>
--
Steve Dewey
Steve@s-deweynospam.demon.co.uk
Too boring to have an interesting or witty .sig file.
Article: 15037Peter Alfke wrote: > JThe easiest, simplest and safest method is to cheat and > build a circuit that divides alternatingly by 2 and by 3. > So > it generates two output periods for every five input > periods. You have your 40 MHz average output frequency, > but > the two adjacent output periods are of unequal length, one > > of them 20 ns, the other one 30 ns. That circuit is > trivial > to implement in two CLBs. > > The price you pay is that, worst-case, the output is as > demanding as 50 MHz, and the spectrum is not pure. > May be good enough in many applications. Joel told me that he cannot tolerate the jitter.So here is the real solution: Do as described above, then add one more flip-flop, clocked on the opposite edge and straddling the boundary between the two output periods. Then use an OR gate to force the output Low for an additional half period of the incoming clock. Advantage: no possible glitches, no flip-flop with tight timing requirements. Disadvantage: one unavoidable additional gate delay behind the flip-flop. Cost: 2 or max 3 CLBs. Incremental cost of a CLB is often zero, when it's just there, sitting unused. The statistical average cost of a CLB is around 10 cents. So this beats the external $3.- extra component by a long shot. Fun stuff. Peter Alfke, Xilinx > > > Peter Alfke, Xilinx > > > >Article: 15038
Joel Kolstad wrote: > Does anyone have a clever circuit that can divide an input clock by two and > a half? We're looking to go from 100MHz down to 40MHz. I've thought of a > couple of ways to do this, but they all had some asynchronous parts to them > that required that I could guarantee minimum propagation delays. In a > 100MHz part I didn't really want to have to guess at the minimum propagation > delays (neither Xilinx nor Cypress nor Vantis -- vendors whose CPLDs we're > thinking of implementing this in -- mention their minimum propagation delays > in the data sheets that I looked at). > > Additionally I don't want to buy a faster speed grade device -- any change > in speed grade would cost more than the ~$3 of an external PLL. (In which > case I'd divide by 5 and multiply by 2.) > > Most CPLDs these days can clock on either edge of the incoming clock, and it > initially seemed that a design that had two "divide by fives" and then > combinatorially ORed the results together would work. Getting the two > circuits synchronized is the problem. Either they have to rely on each > other's output, which effectively means the design is running at 200MHz > internally, or they have to rely on an external result pulse, and generating > it at the exact time point required appeared difficult. > > ---Joel Kolstad The Vantis CPLD family MACH5 has FFs that can toggle on both clock edges (and with two clock enables, one for each edge). If you use a divide by 5 binary counter that counts on both 100MHz clock edges you will get a 40MHz output (with 40%-60% duty factor on Q1 and 20%-80% on Q2). Since this solution is completely synchronous you do not have minimum delay problems. Catalin BaetoniuArticle: 15039
The other way to go is to have everything reset to a passive state. When the async reset is removed the circuit stays put until some synchronous event which you control triggers it. The synchronous event could be a timeout, a microcontroller register write, or even a synchronized version of your async reset used as an input to the state machine vs. as an async reset. Much better way to go IMO and allows you to make use of the built-in global reset logic in the device. Bob S. Joel Kolstad wrote: > > Assume you have a state machine that has some "interesting" state > encoding... say the reset state encodes to 1010, and then the state machine > always steps to a state encoded by 0101. This state machine has an > asynchronous reset input, which comes from a pin on a CPLD or FPGA. The > clock to this synchronous state machine also comes from a pin. > > Isn't a completely asynchronous reset input just asking for trouble? While > reset is active, the state machine is sitting at 1010. If I now assume that > reset goes inactive just a split (nano)-second before the active clock edge, > I don't have any guarantees at all that some of the state encoding bits are > going to transition to their expected new values, whereas some won't > transition at all, correct? > > If this is really an issue, it would appear that the correct way to apply an > asynchronous reset is to first run it through a synchronizer before applying > it to the asynchronous reset input of the state machine. > > ---Joel KolstadArticle: 15040
Hi I intend to start to start with isp CPLD designs. My designs are usually quite simple. They are mainly intended for simple state machines, address decoding, input/output buffering of analog converters and input capture of digital signals. They will mainly be used with 16bit DSP's. Packages should ideally be PLCC 44/84 (easy handling on experimental boards). I am already familiar with small PAL's (20v8 etc.). I have looked already at several chips. These are: Xilinx - XC 95xx Altera - MAX 7000 Lattice - ispl.. My applications are low volume/ research type. I do design work only very infrequently, so the design software should be as simple as possible and somewhat foolproof. A simple homebrewed parallel port cable should hopefully do the programming. Are there any suitable free integrated software packages? Which family/ software package is best suited to my need? What are the approx. prices and how is availability? How well does schematic capture work - is it useful? Thanks a lot for any help, opinion and recommendation.Article: 15041
Catalin wrote:
>
snip
>
> The Vantis CPLD family MACH5 has FFs that can toggle on both clock edges (and
> with two clock enables, one for each edge). If you use a divide by 5 binary
> counter that counts on both 100MHz clock edges you will get a 40MHz output (with
> 40%-60% duty factor on Q1 and 20%-80% on Q2). Since this solution is completely
> synchronous you do not have minimum delay problems.
>
> Catalin Baetoniu
how about using the divided clock to enable/disable the edges?
count three rising edges, invert clk_out, count three
falling edges invert clk_out.....
increment counter here:(on rising when clk_out = 1, on falling when
clk_out = 0)
| | | | | | | | | |
v v v v v v v v v v
_ _ _ _ _ _ _ _ _
clk _| |_| |_| |_| |_| |_| |_| |_| |_| |
________ _________
clk_out \_________/ \____
is it possible ?
--L2C
--___--_-_-_-____--_-_--__---_-_--__---_-_-_-__--_----
Lasse Langwadt Christensen, MSEE (to be in 1999)
Aalborg University, Department of communication tech.
Applied Signal Processing and Implementation (ASPI)
http://www.kom.auc.dk/~fuz , mailto:langwadt@ieee.org
Article: 15042On Wed, 03 Mar 1999 22:49:59 GMT, Bob Sefton <rsefton@home.com> wrote: >The other way to go is to have everything reset to a passive >state. When the async reset is removed the circuit stays put until >some synchronous event which you control triggers it. The >synchronous event could be a timeout, a microcontroller register >write, or even a synchronized version of your async reset used as >an input to the state machine vs. as an async reset. Much better >way to go IMO and allows you to make use of the built-in global >reset logic in the device. I should have elaborated further. I sent the following to Joel a few hours ago: ---------- I work mostly with Xilinx chips, so I tend to do something a bit different [than creating a single reset that asserts synchronously and deasserts synchronously]. The global reset nets in Xilinx parts can be pretty slow; for some of the larger 4KXL devices, delays can be as long as 35ns. (To complicate matters even more, I can't find reset recovery times for the CLB flip-flops.) With a reset net this slow, it may not be possible to guarantee that even a synchronized reset deasserts in a single state machine clock cycle. To get around these problems, I feed my state machines both an asynchronous reset and a synchronous reset. The async reset is usually just the global chip reset. The synchronous reset is created with two or three flip-flops wired in series, with the D of the first flip-flop wired HIGH. The flip-flops are reset by global reset; when global reset is deasserted, a HIGH propagates through the flip-flops; the output of the last flip-flop is inverted and fed to the state machine flip-flops as a synchronous input. One advantage of this approach is that if your design contains state machines operating at different frequencies, they can still share the global asynchronous reset net. ---------- By the way, the comment about slow global reset nets is not a knock against Xilinx. I suspect that other vendors' parts are comparable. Bob Perlman ----------------------------------------------------- Bob Perlman Cambrian Design Works Digital Design, Signal Integrity http://www.best.com/~bobperl/cdw.htm Send e-mail replies to best<dot>com, username bobperl -----------------------------------------------------Article: 15043
Catalin wrote in message <36DDB822.DD4263E3@spam.com>... >The Vantis CPLD family MACH5 has FFs that can toggle on both clock edges (and >with two clock enables, one for each edge). If you use a divide by 5 binary >counter that counts on both 100MHz clock edges you will get a 40MHz output (with >40%-60% duty factor on Q1 and 20%-80% on Q2). Since this solution is completely >synchronous you do not have minimum delay problems. This requires you to buy a device with a "counting" frequency of 200MHz though, doesn't it? BTW, for other people who have offered suggestions -- thanks. Since there's been some confusion as to what the requirements of the output are, I'll explain further. The 40MHz output is a pixel clock to a frame grabber. The frame grabber has a PLL on-board, so it wants a 40MHz input that has relatively low jitter from one cycle to the next (the PLL happens to be a Cypress CY7C992 RoboClock). The output doesn't have to be precisely 40MHz; something within +5%/-10% would be OK as well. ---Joel KolstadArticle: 15044
--------------CC6F767DDE0CB83F33914371 Content-Type: text/plain; charset=iso-8859-1; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 8bit Bob Perlman wrote: > The global reset nets in Xilinx parts can > be pretty slow; for some of the larger 4KXL devices, > delays can be as > long as 35ns. (To complicate matters even more, I can't > find reset > recovery times for the CLB flip-flops.) With a reset net > this slow, > it may not be possible to guarantee that even a > synchronized reset > deasserts in a single state machine clock cycle. > > To get around these problems, I feed my state machines > both an > asynchronous reset and a synchronous reset. The async > reset is > usually just the global chip reset. The synchronous reset > is > created with two or three flip-flops wired in series, with > the D of > the first flip-flop wired HIGH. The flip-flops are reset > by global > reset; when global reset is deasserted, a HIGH propagates > through the > flip-flops; the output of the last flip-flop is inverted > and fed to > the state machine flip-flops as a synchronous input. One > advantage of > this approach is that if your design contains state > machines operating > at different frequencies, they can still share the global > asynchronous > reset net. > ---------- > This is what I posted on my internal information page, for use by Xilinx applications engineers. It agrees with Bob's idea. Beware of the Asynchronous Global Reset. GSR is a nice and efficient feature, since it consumes no available routing resources. But it also is slow, which can lead to ugly problems. When the design includes a state machine, GSR will make sure that it is automatically reset during configuration, and also any time GSR is activated. The problem is the slow routing, and thus the slow trailing edge of this signal. It can take more than 30 ns to reach all flip-flops. It is thus quite probable that one user clock edge occurs during this time, while some flip-flops are still being held reset, but others have already been released. As a result, the state machine might do strange things, even go into never-never land. The work-around is to give the critical flip-flops an additional synchronous (!) reset input that stays active for a few clock ticks after GSR has been released. That assures that the state machine will wake up properly and not stumble on its first step “out-of-bed”. Peter Alfke --------------CC6F767DDE0CB83F33914371 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit <HTML> <BODY BGCOLOR="#FFFFFF"> Bob Perlman wrote: <BLOCKQUOTE TYPE=CITE>The global reset nets in Xilinx parts can <BR>be pretty slow; for some of the larger 4KXL devices, delays can be as <BR>long as 35ns. (To complicate matters even more, I can't find reset <BR>recovery times for the CLB flip-flops.) With a reset net this slow, <BR>it may not be possible to guarantee that even a synchronized reset <BR>deasserts in a single state machine clock cycle. <P>To get around these problems, I feed my state machines both an <BR>asynchronous reset and a synchronous reset. The async reset is <BR>usually just the global chip reset. The synchronous reset is <BR>created with two or three flip-flops wired in series, with the D of <BR>the first flip-flop wired HIGH. The flip-flops are reset by global <BR>reset; when global reset is deasserted, a HIGH propagates through the <BR>flip-flops; the output of the last flip-flop is inverted and fed to <BR>the state machine flip-flops as a synchronous input. One advantage of <BR>this approach is that if your design contains state machines operating <BR>at different frequencies, they can still share the global asynchronous <BR>reset net. <BR>---------- <BR> </BLOCKQUOTE> This is what I posted on my internal information page, for use by Xilinx applications engineers. It agrees with Bob's idea. <BR> <H3> Beware of the Asynchronous Global Reset.</H3> <P>GSR is a nice and efficient feature, since it consumes no <BR>available routing resources. But it also is slow, which can <BR>lead to ugly problems. <P>When the design includes a state machine, GSR will make sure <BR>that it is automatically reset during configuration, and <BR>also any time GSR is activated. The problem is the slow <BR>routing, and thus the slow trailing edge of this signal. It <BR>can take more than 30 ns to reach all flip-flops. <BR>It is thus quite probable that one user clock edge occurs <BR>during this time, while some flip-flops are still being held <BR>reset, but others have already been released. As a result, <BR>the state machine might do strange things, even go into <BR>never-never land. <P>The work-around is to give the critical flip-flops an <BR>additional synchronous (!) reset input that stays active for <BR>a few clock ticks after GSR has been released. That assures <BR>that the state machine will wake up properly and not stumble <BR>on its first step “out-of-bed”. <P>Peter Alfke <BR> <BR> </BODY> </HTML> --------------CC6F767DDE0CB83F33914371--Article: 15045
Joel - A trick the RF guys like to play is to filter and amplify an odd harmonic from a lower frequency square-wave clock, e.g., you could divide 100MHz by 15 and pick out the third harmonic of that signal. I think this can be done for much less than $3 and will give you a very clean clock. You filter a sine wave from a square wave and then convert it back to a square wave using a CMOS gate. I've always had the luxury of being able to spend the cash for a faster PLD, but problems like this can be fun to solve. Please post your final solution. Bob S. Joel Kolstad wrote: > > Catalin wrote in message <36DDB822.DD4263E3@spam.com>... > >The Vantis CPLD family MACH5 has FFs that can toggle on both clock edges > (and > >with two clock enables, one for each edge). If you use a divide by 5 binary > >counter that counts on both 100MHz clock edges you will get a 40MHz output > (with > >40%-60% duty factor on Q1 and 20%-80% on Q2). Since this solution is > completely > >synchronous you do not have minimum delay problems. > > This requires you to buy a device with a "counting" frequency of 200MHz > though, doesn't it? > > BTW, for other people who have offered suggestions -- thanks. Since there's > been some confusion as to what the requirements of the output are, I'll > explain further. The 40MHz output is a pixel clock to a frame grabber. The > frame grabber has a PLL on-board, so it wants a 40MHz input that has > relatively low jitter from one cycle to the next (the PLL happens to be a > Cypress CY7C992 RoboClock). The output doesn't have to be precisely 40MHz; > something within +5%/-10% would be OK as well. > > ---Joel KolstadArticle: 15046
alex_schreiber@my-dejanews.com wrote: > > Hi, > snip > > In traditional (synchronous) design techniques you always have > the problems of wiring delays. This becomes even more problematic > when you are moving towards smaller gate length (Very Deep SubMicron). > The transistor switching time becomes less important in comparison > to the wire delay. Additionally the amount of gates per area becomes > higher as well, which leads to longer clock nets as well. smaller chips leading to longer nets, that doesn't make sense ? > > In a synchronous system you need to guarantee that there is not too > much skew between the each clock input of the same clock net. The > effort to achieve this becomes higher and higher. > > Exactly here is the advantage of self-timed logic. Because a > proceeding action is triggered by the completion of the previous > one, you do not have such distribution problems. won't you have more or less the same problems, just on the signals timing instead of the clock? > > You can have a look on articles of the following authors: > > Robert Broderson (Berkeley University, early 90s) > Eric Brunvand (Carnegy Mellon University, early 90s) > > As far as I remember the approach of E. Brunvand is not > delay insensitive, but he implemented it into FPGAs. > > The whole topic is not just a theoretic playing. Philips > implemented an error correction algorithm using this > technique. > snip --L2C --___--_-_-_-____--_-_--__---_-_--__---_-_-_-__--_---- Lasse Langwadt Christensen, MSEE (to be in 1999) Aalborg University, Department of communication tech. Applied Signal Processing and Implementation (ASPI) http://www.kom.auc.dk/~fuz , mailto:langwadt@ieee.orgArticle: 15047
alex_schreiber@my-dejanews.com wrote: : Hi, : in self-timed logic there is no global clock existing, i.e. : from this point of view it's an asynchronous design technique. : But it's not at all based on race conditions and wiring delays : as it is the case when you have asynchronous parts in a : synchronous design. : Usually a very strict 4-phase-full handshake protocoll is : implemented, which is based on 'request' and 'acknowledge' : signals (to be a bit faster you can also use a 2-phase : handshake protocoll). This protocoll implies two things: : - control overhead : - special kind of logic gates (SSDL) : To be able to generate an acknowledge signal as a result : of the evaluation of the logic, special logic gates with : differential outputs are needed like Sample Set Differential : Logic (SSDL). : In traditional (synchronous) design techniques you always have : the problems of wiring delays. This becomes even more problematic : when you are moving towards smaller gate length (Very Deep SubMicron). : The transistor switching time becomes less important in comparison : to the wire delay. Additionally the amount of gates per area becomes : higher as well, which leads to longer clock nets as well. : In a synchronous system you need to guarantee that there is not too : much skew between the each clock input of the same clock net. The : effort to achieve this becomes higher and higher. : Exactly here is the advantage of self-timed logic. Because a : proceeding action is triggered by the completion of the previous : one, you do not have such distribution problems. IMO, the world is moving toward a model of "locally synchronous", globally asynchronous" model. You can subdivide the clock nets, and only distribute within a relatively small area. Communications with another net will have to be passed through an interface that can absorbe the differential in local clock signals. Perhaps even by self timed circuits! I still think that async design is too hard for a large project, and keeping locally sync blocks, and just deal with async interface would be a lot easier. : You can have a look on articles of the following authors: : Robert Broderson (Berkeley University, early 90s) : Eric Brunvand (Carnegy Mellon University, early 90s) : As far as I remember the approach of E. Brunvand is not : delay insensitive, but he implemented it into FPGAs. : The whole topic is not just a theoretic playing. Philips : implemented an error correction algorithm using this : technique. : Have fun, : Alex Schreiber : In article <36DCDC1C.C1817CD7@ieee.org>, : khatib@ieee.org wrote: : > Hi : > Please what is the Self-Timed circuit design technique? Is it : > synchronous, asynchronous or something different? : > : > What its advantage over the traditional design techniques? : > : > Thanks in advance : > : -----------== Posted via Deja News, The Discussion Network ==---------- : http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own -- No SPAM or email wholly without substance please davewang@cslab.kecl.ntt.co.jp.I.like.green.eggs.and.ham,not.spam All statements are personal opinions Not speaking for NTT or University of Maryland Kyoto, Japan.Article: 15048
Lasse Langwadt Christensen (fuz@kom.auc.dk) wrote: : alex_schreiber@my-dejanews.com wrote: : > : > Hi, : > : > In traditional (synchronous) design techniques you always have : > the problems of wiring delays. This becomes even more problematic : > when you are moving towards smaller gate length (Very Deep SubMicron). : > The transistor switching time becomes less important in comparison : > to the wire delay. Additionally the amount of gates per area becomes : > higher as well, which leads to longer clock nets as well. : smaller chips leading to longer nets, that doesn't make sense ? smaller transistors leads to an imbalance, as gate delay continues to drop, but wire delay stays mostly constant, eventually come to dominate. plot the graph on a percentage basis, it looks like the clock net is "longer", on chips of the same size, but smaller/faster transistors. -- No SPAM or email wholly without substance please davewang@cslab.kecl.ntt.co.jp.I.like.green.eggs.and.ham,not.spam All statements are personal opinions Not speaking for NTT or University of Maryland Kyoto, Japan.Article: 15049
"Joel Kolstad" <JKolstad@Electroglas.Com> wrote: >Does anyone have a clever circuit that can divide an input clock by two and >a half? We're looking to go from 100MHz down to 40MHz. Here's one additional idea on how to fix the asymmetric problem, if you have CMOS output pin drivers with fairly symmetrical drive. Peter Alfke suggested that it's easy to alternate a divide by two with a divide by three. Do that and send the output out through a pin. Call it pin 'A' Couple that back into another pin 'B' via a series capacitor, perhaps 100 pF. Invert that with an FPGA inverter and send that back out on a third pin, 'C'. Couple pin 'C' to pin 'B' with a 1M Ohm resistor. The 2/3 signal is the correct frequency, but it's not quite 50% duty cycle. The non symmetrical duty cycle problem is like a DC offset problem, and could be fixed if the edges are sloppy enough, and we can just shift the DC. The cap and resistor is a way to automatically shift the DC so that the signal entering pin 'B' has its DC exactly at the Voltage that the inverter will flip. If that's true, the output of the FPGA inverter should be 50%. Buffer it and have a ball. The edges of the signal on pin 'A' must be slow enough so that you could draw a straight line through the signal such that all points, where the line intersects the signal, are equally spaced. If this is not so, because the output drivers are just too good, and the edges are straight up and down, you might have to slow the edges down with a series R and a cap to ground between 'A' and the series 100pF Cap. I haven't tried this with a signal being sourced from the FPGA, but I have, many times, stolen a little energy from a crystal on a micro, and coupled it to an FPGA through a CAP using an inverter and 1M to set the DC. Works every time. Dave Decker Diablo Research Co LLC Dave Decker Diablo Research Co. LLC Please use only one 'h' in mush. I'm trying to reduce the spam. "Animals . . . are not brethren they are not underlings; they are other nations, caught with ourselves in the net of life and time, fellow prisoners of the splendor and travail of the earth." Henry Beston - The Outermost House
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