Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

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

Custom Search

Messages from 13875

Article: 13875
Subject: Re: 22V10 Metastability - help please
From: jim granville <Jim.Granville@DesignTools.co.nz>
Date: Thu, 31 Dec 1998 09:47:50 +1300
Links: << >>  << T >>  << A >>
Peter wrote:

> 

> I will simply put an HC74 on the async input :) 



Let us know if your 1 : 1 million error rate then goes away.

Also, look at Fairchilds website, they have just released 6 pin SOT23
single registers - if you just want a single FF, a very PCB frugal 
solution.



> Even if I could fix this 8-state state machine, I have another 16-state one in the same

> 22V10 which will be a good deal harder to fix, and that uses a similar

> async input as well.



The ATMEL ATFV750C is due out early Q1 99 :-)
( Its on our programmer menu now )


This is 3.3V, is 22V10 compatible, and has 10 more FF's, 
for a lot more 'elbow room' on syncronisers, or one-hot-bit state
machines...



If the system can be split, and usefully work with one state machine,

you can do a 'test PLD', that uses the now-spare 22V10 registers to
pre-sample, 

and also see if the problem goes away...



We have used this approach, on curly problems like this, with good

results.



I have seen, and used, a trick that GATE-Latches the Async IN, with the

CLOCK, so that

it cannot change in the half clock prior to the active edge.

This avoids nasty 'aperture effects' of a signal that straddles the

CLOCK edge.

It also introduces only a half cycle of pre-sample delay..



CUPL also has a MIN keyword, that allows override of the LOGIC MIN used, 
within CUPL.
( MIN Counta.d = 4; /* level 4 reduction */ ) etc
It is possible that fiddling with this, on your state engine, could
produce equations that both FIT inside the 22V10, and meet the
requirement of a single term -> State transistion 




- jg

Article: 13876
Subject: Re: How to import EDIF file in Foundation Software?
From: Mike Peattie <mpeattie@xilinx.com>
Date: Wed, 30 Dec 1998 12:53:59 -0800
Links: << >>  << T >>  << A >>
    Actually, there is the Design Manager executable bundled with Foundation.  You
just need to do
Start->Programs->Xilinx Foundation Series-> Accessories-> then Design Manager.
Alliance isn't required- you just need to bypass the front end tools.

Mike Peattie

Le mer Michel wrote:

> George wrote:
>
> > Hi, I am now trying to combine Mentor VHDL synthesize tool with Xilinx FPGA
> > Foundation software.
> > I using the Mentor Leonardo software to generate the EDIF file, which is
> > says to be netlist
> > file synthesized, but how can I import them into Xilinx software? Have
> > anybody do this before?
> > Thank you very much for your help!
> > Also, can somebody give me a more detailed description about what is EDIF
> > files?
> > Thanks a lot!
>
> Hi, you need the Xilinx Alliance tool, called M1.5 too. (this is not
> Foundation Express).
> You will just do a "new project" and define your edif file as the input file
> and precise the target.
>
> Basically, an edif file define the inputs and outputs of basic components (or,
> and, flip-flop...). Depending of the options used with Leonardo, basic
> components can be link to CLBs or not.
>
> Michel.
>
> Michel Le Mer
> Gerpi sa
> 3, rue du Bosphore
> Alma city
> 35000 Rennes
> France.



Article: 13877
Subject: Re: 22V10 Metastability - help please
From: jim granville <Jim.Granville@DesignTools.co.nz>
Date: Thu, 31 Dec 1998 11:09:35 +1300
Links: << >>  << T >>  << A >>
Jonathan Bromley wrote:
> 
<snip> 
> I've had no end of
> trouble with students' apparently simple, bulletproof sequential
> designs in small GAL devices making apparently ridiculous state
> transitions, almost always caused by ground bounce.  The output
> structures on fast CMOS GALs are so fast and brutal that the
> dI/dt in the device's ground lead can disturb input thresholds
> enough to make another, false clock pulse appear to occur;
> since this false pulse is very short indeed, it may fail to
> trigger some of the f/fs in the device and so you can get
> completely inexplicable activity.

 This is a real problem, and why I lobby for Hysteresis on PLD lines.

It is not getting better, with 'newer' parts ::
- the shrinks on devices decrease the aperture times
- 'Zero power' devices are mostly Power Wakeup, fastest spec devices
- Suppliers can ship fastest spec devices, labeled as slowest


 As an example, consider a ~50nS risetime ( 10nS / Volt ), and add
200mV of ground noise to this.
 This produces a 'tolerance aperture' of 2nS - the signal has not
arrived at
an output pin inside this time, but is well on it's way through the
internals.

 ASIC internal Gate delays of under 100pS are typical of modern
processes
 50nS Tr is 'good' for a 4000 CMOS device, or a digital Optocoupler or
analog comparitor

 To be reliable, the clock edge must have slewed past the threshold, by
more than the ground 'bounces', when they arrive.

 In a real device, multiple currents contribute to the ground noise.
Quickest is the input buffers - with low injected currents, but soonest
arrivals. 
Then the internal AND/OR/FF logics current injections appear, and
lastly,
the output currents, and any load C they drive.

 Most vendors 'Z' PLDs achieve the low Icc, by fast wakeup of a 50-100mA
'core',
so have inbuilt ground bounce generators (!), and are the most
intolerant of 
slower edges.

 I have also seen erratic effects, on PLDs where the CLOCK line is very
fast/clean,
but other ( non dependant ) inputs are slower ( eg optocouplers ).
 As there is no logic coupling, this effect is due to buffer
Oscillations, within
the device. These can, in theory, be > 1GHz, and only need enough energy
to disturb
the GND metalisation voltage...

 Hysteresis eliminates the transistion oscillation effect, and if the Vh
>
ground bounce, can allow any rise times to be tolerated, while also
reducing the
overall current drain.

-jg

Article: 13878
Subject: Re: Xilinx XC4000 cinfigured from EPC2?
From: "Marc Levy" <marclevy@ix.netcom.com>
Date: Wed, 30 Dec 1998 16:13:28 -0800
Links: << >>  << T >>  << A >>
No guarantees, but it should be possible with the XC4000 device in 'slave
serial' mode.  The EPC2 has an on-chip oscillator as the Altera Flex10K
devices have no oscillator and therefore no 'master serial' mode.  The
serial config mode of the Altera Flex10K is similar to the XC4000 slave
serial mode.

Marc Levy


Carl R. Poirier wrote in message <75ato5$g0q$1@news.kodak.com>...
>I looking into loading an Altera EPC2 with configuration data for a Xilinx
>XC40xx.  Does anyone know if this is possible?
>
>I'm interested in the ISP capability of Altera's EPC2 using the JTAG bus,
>but I'm using Xilinx XC40xx devices.  I need the ability to reload the
>configuration EPROM using only the JTAG port.
>
>Thanks, Carl Poirier
>Eastman Kodak
>Electronic Products
>Design for Testability
>
>


Article: 13879
Subject: Re: 22V10 Metastability - help please
From: z80@ds2.com (Peter)
Date: Thu, 31 Dec 1998 07:08:53 GMT
Links: << >>  << T >>  << A >>
No, because its effect will be blocked by the other logic. Only one
D-type at any one time will see it.

>But if the same input can do this in more than one place in the
>sequence of states then it may still be controlling more than one
>state ff


--
Peter.

Return address is invalid to help stop junk mail.
E-mail replies to zX80@digiYserve.com but
remove the X and the Y.

Article: 13880
Subject: Re: 22V10 Metastability - help please
From: z80@ds2.com (Peter)
Date: Thu, 31 Dec 1998 07:08:54 GMT
Links: << >>  << T >>  << A >>

>Let us know if your 1 : 1 million error rate then goes away.

No errors yet, after some 40-50 hours. Looks like the *AMD* 22V10 was
very dodgy. Anyway as I said I will sync it for good measure, esp. as
my i/p Tr is 50ns and the spec on the Philips P3Z22V10 is 20ns max.

>The ATMEL ATFV750C is due out early Q1 99 :-)
>( Its on our programmer menu now )

Which programmer?

>This is 3.3V, is 22V10 compatible, and has 10 more FF's, 
>for a lot more 'elbow room' on syncronisers, or one-hot-bit state
>machines...

Well, if Lattice ever did a full-*CMOS* version of their ancient
39V18, a.k.a. GAL6001, none of this would be needed. Every half-good
PLD compiler of the past 10 years supports the 6001. The 22V10 pin
compatibility is handy though.

>I have seen, and used, a trick that GATE-Latches the Async IN, with the
>CLOCK, so that it cannot change in the half clock prior to the active edge.
>This avoids nasty 'aperture effects' of a signal that straddles the
>CLOCK edge.
>It also introduces only a half cycle of pre-sample delay..

I think you are referring to the ability to build a S-R latch within
the product matrix, but I think this still uses up at least one output
pin. Details please?

I once learnt a wonderful trick, involving the creation of a
"clock-enable" function, which almost gives you separate clocks -
something badly missing in most GALs.

>CUPL also has a MIN keyword, that allows override of the LOGIC MIN used, 
>within CUPL.
>( MIN Counta.d = 4; /* level 4 reduction */ ) etc
>It is possible that fiddling with this, on your state engine, could
>produce equations that both FIT inside the 22V10, and meet the
>requirement of a single term -> State transistion 

Yes, I discovered this too. Unfortunately it doesn't do it, because a
"zero level" minimisation chucks in a load of zero (empty) terms, and
these overflow the product term limit. Stupid program. The next
smallest minimisation is what I already use.

Obviously there is a way around this, either typing it all in by hand,
or hacking the CUPL-generated .doc file to edit the dodgy terms. But
my problem is that I am in a "long term" business and often have to
revisit designs after some years. (Being my own business I don't have
the option of walking away from everything I have done every year or
two). So I try really hard to make very project so it is fully
automated so I just change to the relevant directory and type MAKE.


--
Peter.

Return address is invalid to help stop junk mail.
E-mail replies to zX80@digiYserve.com but
remove the X and the Y.

Article: 13881
Subject: Re: program flow chart to state machine ?
From: z80@ds2.com (Peter)
Date: Thu, 31 Dec 1998 07:08:55 GMT
Links: << >>  << T >>  << A >>

>  I developed assembly code for a micro controller to prototype a design. I
>also have the program flow chart for the design. How do I go from the program
>flowchart to a state diagram so that I can implement the design in an FPGA ?

You will get many replies, but basically you need to draw your state
diagram, then enter it in the language of some program which can
convert it into an FPGA netlist, then compile it into the FPGA
vendor's netlist format.

How much money do you want to spend?

I have done this with CUPL, outputting PALASM format, then used
PDS2XNF.EXE, then XNFOPT.EXE to convert to Xilinx XNF netlist format.
One could simulate, etc, in Viewlogic. This is a very old way to do it
though.

Today, a much more popular way to do this would be to use VHDL. I
don't know if there is a really cheap route from VHDL to XNF;
certainly there never used to be in the past. I know Cypress do a
cheap VHDL kit for *their* CPLDs but those devices covered by that kit
might not be big enough for what you want.

Once you have the XNF netlist then you can use Xilinx's place & route
tools to generate the config stream for the chosen Xilinx device.

Alternatively, if the state machine is simple, you could design it by
hand as a schematic, or even (if you are a masochist) as a netlist
directly. Xilinx now offer some cheap starter kits.

>  Also, in my micro controller prototype, I used analog peak detectors(have
>capacitors in them) as sensors. When I move the design to an FPGA, I would
>like the entire design to be digital so that it can be easily integrated into
>an ASIC. Does any one have any experience with designing digital peak
>detectors ? (ie. No capacitors). I have some ideas, but would like to hear
>about some proven designs.

I don' think this is possible. You would need an A-D converter, then
some logic to sample the values, compare with previous highest and
retain the value if higher than previous. Not a big deal but not
completely trivial either.


--
Peter.

Return address is invalid to help stop junk mail.
E-mail replies to zX80@digiYserve.com but
remove the X and the Y.

Article: 13882
Subject: Re: How to import EDIF file in Foundation Software?
From: Le mer Michel <michel.lemer@ago.fr>
Date: Thu, 31 Dec 1998 09:36:11 +0100
Links: << >>  << T >>  << A >>
So why did xilinx say us we needed Xilinx Foundation and Xilinx Alliance and asked us
to PAY for both?

Michel.


Mike Peattie wrote:

>     Actually, there is the Design Manager executable bundled with Foundation.  You
> just need to do
> Start->Programs->Xilinx Foundation Series-> Accessories-> then Design Manager.
> Alliance isn't required- you just need to bypass the front end tools.
>
> Mike Peattie
>
> Le mer Michel wrote:
>
> > George wrote:
> >
> > > Hi, I am now trying to combine Mentor VHDL synthesize tool with Xilinx FPGA
> > > Foundation software.
> > > I using the Mentor Leonardo software to generate the EDIF file, which is
> > > says to be netlist
> > > file synthesized, but how can I import them into Xilinx software? Have
> > > anybody do this before?
> > > Thank you very much for your help!
> > > Also, can somebody give me a more detailed description about what is EDIF
> > > files?
> > > Thanks a lot!
> >
> > Hi, you need the Xilinx Alliance tool, called M1.5 too. (this is not
> > Foundation Express).
> > You will just do a "new project" and define your edif file as the input file
> > and precise the target.
> >
> > Basically, an edif file define the inputs and outputs of basic components (or,
> > and, flip-flop...). Depending of the options used with Leonardo, basic
> > components can be link to CLBs or not.
> >
> > Michel.
> >
> > Michel Le Mer
> > Gerpi sa
> > 3, rue du Bosphore
> > Alma city
> > 35000 Rennes
> > France.

Article: 13883
Subject: Re: 22V10 Metastability - help please
From: Magnus Homann <d0asta@mis.dtek.chalmers.se>
Date: 31 Dec 1998 12:07:23 +0100
Links: << >>  << T >>  << A >>
"Bruce Nepple" <brucen@imagenation.extra.com> writes:

> Yes Yes Yes.  You got it! I challenge anyone here to come up with a gray
> code state machine that can reside in state A and conditionally branch to
> either state B or State C based on an async. input.

I can't think of one. But you added yet another requirement to Peter's
list. With thse requirements, one should be safe.

> "Having spent untold hours at analyzing and measuring metastable
> behavior, I can assure you that it is (today) a highly overrated
> problem.  You can almost ignore it."
> Peter Alfke
> 12/28/98

Are you going to hold it to him? :-)
-- 
   Magnus Homann  Email: d0asta@dtek.chalmers.se
                  URL  : http://www.dtek.chalmers.se/DCIG/d0asta.html
  The Climbing Archive!: http://www.dtek.chalmers.se/Climbing/index.html

Article: 13884
Subject: Re: 22V10 Metastability - help please
From: Magnus Homann <d0asta@mis.dtek.chalmers.se>
Date: 31 Dec 1998 12:21:34 +0100
Links: << >>  << T >>  << A >>
ems@riverside-machines.com.NOSPAM writes:

> On 29 Dec 1998 17:23:25 +0100, Magnus Homann
> <d0asta@mis.dtek.chalmers.se> wrote:
> > Indeed
> >tht logic hazards do matter, because they can (and do) occur just as
> >the the DFF is sampled. Whether it's one or more DFFs, doesn't matter.
> 
> Sure, but my point is that a problem can only occur when the async
> input is changing. If the input is changing, then it doesn't matter
> whether the f/f decides to settle to 1 or to 0 - either the f/f gives
> us the new value of the input, or the old value. Both are ok, and so
> hazards on the input don't matter *when you've only got one f/f*.

The problem in Peter's SM was, that the old value was the same as the
new value. The same value should come out of the comb logic,
regardless of the async input. In that case, it is not true that both
values were OK. Getting a glitch seriously disrupts the SM.

[ alot snipped]
> Ok, I'm sure you're right when you say that you can make this case
> work by removing the hazards, but I don't think that this is a
> practical solution in general (and what if your machine has more than
> one state exiting from the sample state?

I agree completely. I would have synchronized the input as the very
first step.

Homann
-- 
   Magnus Homann  Email: d0asta@dtek.chalmers.se
                  URL  : http://www.dtek.chalmers.se/DCIG/d0asta.html
  The Climbing Archive!: http://www.dtek.chalmers.se/Climbing/index.html

Article: 13885
Subject: Re: 22V10 Metastability - help please
From: Magnus Homann <d0asta@mis.dtek.chalmers.se>
Date: 31 Dec 1998 12:54:44 +0100
Links: << >>  << T >>  << A >>
rk <stellare@NOSPAMerols.com> writes:

> sorry, bit of a disagreement here in definitions.  i actually went
> back and re-read a bunch of my logic books.  gray codes, as it turns
> out, are not tied to flip-flops, but to a sequence of numbers.

Yes, you are right abot this. It's not tied to any sort of
implementation.

> again, let me repeat, if you sample something that has more than one
> bit changing at a time you are not sampling a gray code sequence and
> it's a bad circuit.

[...]

> now, of course it is common to think of a sequencer using a gray
> coded sequence (which is what you are referring to).

Yes, gray coded state machines has been the subject of this thread.

> these can be
> very handy and i use them all of the time.  they have the very nice
> property that you can sample them any old time you want to,
> asynchronously, and only have small errors (where 1 is considered
> small).

Wait a second. You make the assumption that 'any old time' is more
often than the cray coded sequence change. What if it changes each
second, but you sample every 10 seconds. Is it still a gray code? I
think you make he hidden assumption, that only one bit changes
_between sampling_.

> i don't care if it's the output of a shaft encoder, an ADC, a
> combinational logic network, or a set of flip-flops.  if the outputs
> when viewed with inifite time resolution do not glitch and only
> change one bit at a time in a gray code sequence you are in good
> shape (as long as you don't do anything really stupid).

With infininte time resolution? I challenged anyone to build a comb
logic that changes more than 1 bit per ps. You do mean change 1 bit
per samlping, donät you? That's what you say elsewhere in your post.

The glitch, on the other hand is more important. Even gray coded SM
can have glitches in their comb. logic.
 
> if multiple
> bits are changing, you are not sampling a gray code sequence and you
> have a bad circuit.  which is why the original posters circuit most
> probably failed.

> > > these are safe to sample asynchronously assuming that after
> > > sampling the flip-flop outputs are allowed to settle to avoid metastability
> > > problems before being used in the next stage of logic.  further, at most one
> > > of the flip-flops doing the same can go metastable, since by definition of a
> > > gray code, all the other bits are constant.
> >
> > Only one bit of the state registers change at the same time, but
> > which? Both 00 to 01 and 00 to 10 are legal transitions in a gray coded
> > SM, but logic hazard can make you take the 00 to 11 transition, which
> > is illegal. Ergo, your SM isn't fool proof for asynch inputs.
> 
> sorry, you can't have it both ways.  if you have a logic hazard in
> the combinational network, then the input to the registers isn't
> guaranteed to have only 1 input changing at a time,

There is no such thing as simultaneous changes. No two bits in a
comb. logic can change at the same time. What is your implied
timing ref. here?

> so you are not
> sampling a gray coded sequence, so the circuit will fail.  you are
> not describing my SM, but a poorly designed one.

On the example above, the comb logic is a gray coded sequence. First
it's "00", then it is "01", then 100 ps later it is "11", then 100ps
later it is "10". A gray coded sequence. Unfortunately, the SM clock
decides to sample this gray coded sequence, at the time it's "11". So
it takes an illegal jump.

That the SM is gray coded doesn't necessarily mean that the comb logic
in front of it is free from glitches. See Peter's example. 

Homann
-- 
   Magnus Homann  Email: d0asta@dtek.chalmers.se
                  URL  : http://www.dtek.chalmers.se/DCIG/d0asta.html
  The Climbing Archive!: http://www.dtek.chalmers.se/Climbing/index.html

Article: 13886
Subject: Re: 22V10 Metastability - help please
From: ems@riverside-machines.com.NOSPAM
Date: Thu, 31 Dec 1998 12:27:24 GMT
Links: << >>  << T >>  << A >>
On 31 Dec 1998 12:21:34 +0100, Magnus Homann
<d0asta@mis.dtek.chalmers.se> wrote:

>> Sure, but my point is that a problem can only occur when the async
>> input is changing. If the input is changing, then it doesn't matter
>> whether the f/f decides to settle to 1 or to 0 - either the f/f gives
>> us the new value of the input, or the old value. Both are ok, and so
>> hazards on the input don't matter *when you've only got one f/f*.
>
>The problem in Peter's SM was, that the old value was the same as the
>new value. The same value should come out of the comb logic,
>regardless of the async input. In that case, it is not true that both
>values were OK. Getting a glitch seriously disrupts the SM.

good point - agreed.

evan

Article: 13887
Subject: Re: about using Mentor and Foudation together
From: s_clubb@NOSPAMnetcomuk.co.uk (Stuart Clubb)
Date: Thu, 31 Dec 1998 12:55:45 GMT
Links: << >>  << T >>  << A >>
On Wed, 30 Dec 1998 11:38:48 GMT, ems@riverside-machines.com.NOSPAM
wrote:

>does mentor own exemplar?? MGC's website describes exemplar as 'an
>independent company'.

Exemplar Logic's products, just like Model Technology's are available
through the direct Mentor Channel to their direct customer base. For
those unaware of recent movements within the EDA industry, this may
help to draw some dots:

http://www.mentor.com/press_releases/nov98/curtisvp_pr.html

Cheers
Stuart
For Email remove "NOSPAM" from the address

Article: 13888
Subject: Re: 22V10 Metastability - help please
From: terry.harris@dial.pipex.com (Terry Harris)
Date: Thu, 31 Dec 1998 13:03:03 GMT
Links: << >>  << T >>  << A >>
z80@ds2.com (Peter) wrote:

>No, because its effect will be blocked by the other logic. Only one
>D-type at any one time will see it.

Unless that 'other logic' creates a static hazard which is what I said
the problem was?  


>>But if the same input can do this in more than one place in the
>>sequence of states then it may still be controlling more than one
>>state ff

Cheers Terry...

Article: 13889
Subject: Re: program flow chart to state machine ?
From: Eli Keren <elik@dsi.co.il>
Date: Thu, 31 Dec 1998 17:04:05 +0200
Links: << >>  << T >>  << A >>
I suggest to contact with israeli company called sumit-design they build a program
that convert from state machine bubble diagram into vhdl code and backwards.

 best regards

Peter wrote:

> >  I developed assembly code for a micro controller to prototype a design. I
> >also have the program flow chart for the design. How do I go from the program
> >flowchart to a state diagram so that I can implement the design in an FPGA ?
>
> You will get many replies, but basically you need to draw your state
> diagram, then enter it in the language of some program which can
> convert it into an FPGA netlist, then compile it into the FPGA
> vendor's netlist format.
>
> How much money do you want to spend?
>
> I have done this with CUPL, outputting PALASM format, then used
> PDS2XNF.EXE, then XNFOPT.EXE to convert to Xilinx XNF netlist format.
> One could simulate, etc, in Viewlogic. This is a very old way to do it
> though.
>
> Today, a much more popular way to do this would be to use VHDL. I
> don't know if there is a really cheap route from VHDL to XNF;
> certainly there never used to be in the past. I know Cypress do a
> cheap VHDL kit for *their* CPLDs but those devices covered by that kit
> might not be big enough for what you want.
>
> Once you have the XNF netlist then you can use Xilinx's place & route
> tools to generate the config stream for the chosen Xilinx device.
>
> Alternatively, if the state machine is simple, you could design it by
> hand as a schematic, or even (if you are a masochist) as a netlist
> directly. Xilinx now offer some cheap starter kits.
>
> >  Also, in my micro controller prototype, I used analog peak detectors(have
> >capacitors in them) as sensors. When I move the design to an FPGA, I would
> >like the entire design to be digital so that it can be easily integrated into
> >an ASIC. Does any one have any experience with designing digital peak
> >detectors ? (ie. No capacitors). I have some ideas, but would like to hear
> >about some proven designs.
>
> I don' think this is possible. You would need an A-D converter, then
> some logic to sample the values, compare with previous highest and
> retain the value if higher than previous. Not a big deal but not
> completely trivial either.
>
> --
> Peter.
>
> Return address is invalid to help stop junk mail.
> E-mail replies to zX80@digiYserve.com but
> remove the X and the Y.

Article: 13890
Subject: JOB FPGA/CA Startup
From: Margie Way <margiew@surfnetusa.com>
Date: Thu, 31 Dec 1998 09:06:40 -0800
Links: << >>  << T >>  << A >>
Tharas Systems in San Jose, CA. is a well funded start-up developing a
verilog simulator with an RTL hardware engine that will deliver 1000x
the performance of current software verilog simulators. We have
developed an innovative, patent pending hardware/software architecture
to achieve this goal.

Please see our website at  http://www.tharas.com and the job description
below:

Principal Engineer – FPGA/Board/Systems Design
Skills Required:   MSEE or equivalent with 5+ years of experience
designing Multiple Board / System Designs.   High speed digital design
and strong FPGA design background are essential.   Must have experience
using signal integrity analysis tools.  Must have worked a design
process from start to finish.
Skills Desired:  PCI experience and Chassis based systems design
experience a plus.  EDA background.
Duties:   Need individual contributor with very strong system design
skills to design from start to finish a high speed chassis based
multiple board digital system.   You will work with the design process
flow including schematic capture, timing analysis, BOM generation, fab
and assembly.   You will use your good problem solving skills and
communication skills and work independently or with a small team.

Thanks for any interest you may have and Happy New Year.

Please contact:
Margie Way
Tharas Systems, Inc.
408-557-5324
408-557-5460 fax
margie@tharas.com or hr@tharas.com

Article: 13891
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10 Metastability - help please
From: "Bruce Nepple" <brucen@imagenation.extra.com>
Date: Thu, 31 Dec 1998 11:36:58 -0800
Links: << >>  << T >>  << A >>

Peter Alfke wrote in message <3689409A.9126686@xilinx.com>...

>> Race Conditions:
>> Picture an ordinary cross coupled latch made of 2 nand-gates with
>> exactly
>> identical finite prop delays.   Connect both inputs together, and
>> ground
>> them.  Both outputs are high.  Now, connect both inputs to logic 1.
>> You now
>> have an oscillator that will never stop.
>
>Try it: You have a latch that is stable in either state. No way does it
>oscillate !
>



So if a cross coupled latch with an input race condition can not oscillate,
then it is a metastable free synchronizer and all the years of research and
Xilinx app notes were wasted.

Peter, I think you need to rethink a few things.

Bruce

"Having spent untold hours at analyzing and measuring metastable
behavior, I can assure you that it is (today) a highly overrated
problem.  You can almost ignore it."
Peter Alfke
12/28/98

"Having spend untold hours debugging digital designs, I can assure you that
metastable behavior is a real problem, and every digital designer had better
understand it"
Bruce Nepple
12/31/98


Article: 13892
Subject: IS: 2001, A Logic Odyssey (WAS: 22V10 Metastability - help please)
From: rk <stellare@NOSPAMerols.com>
Date: Thu, 31 Dec 1998 16:23:39 -0500
Links: << >>  << T >>  << A >>
happy new year!

well, it'll be new year when the ball drops in times square, NY.

now back to our favorite program ...

rk

==========================================

Magnus Homann wrote:

> rk <stellare@NOSPAMerols.com> writes:
>
> > sorry, bit of a disagreement here in definitions.  i actually went
> > back and re-read a bunch of my logic books.  gray codes, as it turns
> > out, are not tied to flip-flops, but to a sequence of numbers.
>
> Yes, you are right abot this. It's not tied to any sort of
> implementation.

no problem - i think most internet disagreements are mostly over definitions and stuff
like that.

-------------------------------------------------------------------

> > again, let me repeat, if you sample something that has more than one
> > bit changing at a time you are not sampling a gray code sequence and
> > it's a bad circuit.
>
> [...]
>
> > now, of course it is common to think of a sequencer using a gray
> > coded sequence (which is what you are referring to).
>
> Yes, gray coded state machines has been the subject of this thread.

yes, although i had talked directly about gray codes and their use in asynchronous
sampling.  a very important destinction.  a gray code sequencer is one whose state
assignment results in a transition of states where the vectors form a gray code
sequence.  this is handy if the output of this machine is to be sampled
asynchronously.

on the other hand, if you have a state machine with gray code outputs whose input is
asynchronous causing the next state equations to glitch, have logic hazards, etc.,
etc., then you just have a state machine that is poorly designed and will be
error-prone.

==============================================

> >
> these can be
> > very handy and i use them all of the time.  they have the very nice
> > property that you can sample them any old time you want to,
> > asynchronously, and only have small errors (where 1 is considered
> > small).
>
> Wait a second. You make the assumption that 'any old time' is more
> often than the cray coded sequence change. What if it changes each
> second, but you sample every 10 seconds. Is it still a gray code? I
> think you make he hidden assumption, that only one bit changes
> _between sampling_.

no, multiple bits can change between sampling of a gray code as multiple states are
passed through.  in fact, this type of circuit makes very good use of the gray code.
here are two examples, perhaps repeating myself from earlier posts, but hopefully we
can get this down in one place and keep confusion to a minimum.

assume that you have a rotating shaft with a position encoder.  the shaft rotates at
the rate of once per second and the position encoder has a resolution of 1024
positions.  furthermore, electical contacts convert position into a binary word.  as
the shaft rotates, the output vector changes, well, 1024 times per second.  now let us
say that we attach an electrical detector of some sort to the shaft, which has an
angular field of view of, say, 360/1024 degrees.  let the shaft rotate around for
hours if you wish, then when the big radar signal comes in, from one of our friends
around the world, the detector puts out a nice big fat logic pulse.  since these
friends may, in fact, wish to send you a little ol' package, you may wish to know
where they are.  so, you take your nice logic pulse and then latch the output of the
position encoder into a register.  fortunately, your angular encoder puts out a gray
code, so you know just about where they are, with respect to angle.  "just about"
means that your error is at most one unit of your resolution, in this case 1024th of a
resolution.

here's another case, a real one, although the numbers and scenario's are changed to
make things simple.  suppose you are up in space, just for kicks, and you shoot a
laser beam straight down.  well, as the laser hits stuff, you can get some light
reflected back.  in fact, if you put say a photomultiplier on your detector and
appropriate pulse shaping electronics, you can get, say, a nicely formed pulse 20 nsec
wide.  furthermore, let's say that your detector+pulse shaping electronics has a
pulse-pair resolution of 1 usec, so that you don't have to worry about insufficient
clock low time, causing your flip-flops to go metastable.  now, your friend, the guy
who pays your salary, asks you to count the number of output pulses every 1 msec of
clock time.  you can then, if you know your altitude, convert your counts into a
measure of what's in the atmosphere at different altitudes.  this is important for a
bunch of scientific reasons but you gotta get the right answer.  well, take the output
of the pulse detector and put it into the clock of a counter that goes through a gray
code sequence.  of course, this will not be a regular clock at all, but will be quite
irregular, depending on what's at what altitude in the atmosphere, and within a band,
will have arrival times that appear random, which is a separate topic.  anyways, we
know that the photomultiplier tube pulses will by asynchronous to your other counter,
which counts off 1 msec intervals.  but, since your counter (or state machine if you
like) is going in a gray code sequence, you can simply latch the output of the counter
(state machine) and have a very small error and shove the values into a fifo.  no dead
time on your detector, everybody's happy.  later, you can do a gray => binary
conversion and figure out what it all means.

so no, there is no hidden assumption there of the kind you mentioned.

===================================================

> > i don't care if it's the output of a shaft encoder, an ADC, a
> > combinational logic network, or a set of flip-flops.  if the outputs
> > when viewed with inifite time resolution do not glitch and only
> > change one bit at a time in a gray code sequence you are in good
> > shape (as long as you don't do anything really stupid).
>
> With infininte time resolution? I challenged anyone to build a comb
> logic that changes more than 1 bit per ps. You do mean change 1 bit
> per samlping, donät you? That's what you say elsewhere in your post.

yes,  infinite time resolution means no glitches.  some engineers take the approach
that delays in these sort of devices should match reasonably well and that logic gates
act as low pass filters.  this statement was simply saying that i would not count on
those things saving your hide.  note earlier brief discussion about the modelling of
delays in vhdl, which can either be transport or inertial, with inertial delays being
the default.

==================================================

> The glitch, on the other hand is more important. Even gray coded SM
> can have glitches in their comb. logic.

yes, but if you use the asynchronous input as the clock of the gray coded state
machine, it's a don't care, as long as you don't do anything stupid. here, not stupid
means that the pulse-pair resolution is greater than it takes for your glitchy logic
to settle down.  basic synchronous design practices, really, nothing special.  if you
choose to have a clock asynchronous to the input and then have the inputs go into the
combinational logic, then you must ensure that your logic does not glitch and that it
presents a gray code to the inputs of the d flip-flops, which samples them, which must
be a gray code (or some code with similar properties like the output of a johnson ring
counter) with only 1 bit changing per change in state.

===================================================

> >
> if multiple
> > bits are changing, you are not sampling a gray code sequence and you
> > have a bad circuit.  which is why the original posters circuit most
> > probably failed.
>
> > > > these are safe to sample asynchronously assuming that after
> > > > sampling the flip-flop outputs are allowed to settle to avoid metastability
> > > > problems before being used in the next stage of logic.  further, at most one
> > > > of the flip-flops doing the same can go metastable, since by definition of a
> > > > gray code, all the other bits are constant.
> > >
> > > Only one bit of the state registers change at the same time, but
> > > which? Both 00 to 01 and 00 to 10 are legal transitions in a gray coded
> > > SM, but logic hazard can make you take the 00 to 11 transition, which
> > > is illegal. Ergo, your SM isn't fool proof for asynch inputs.
> >
> > sorry, you can't have it both ways.  if you have a logic hazard in
> > the combinational network, then the input to the registers isn't
> > guaranteed to have only 1 input changing at a time,
>
> There is no such thing as simultaneous changes. No two bits in a
> comb. logic can change at the same time. What is your implied
> timing ref. here?

the timing reference for a state machine is the clock.  the probability of two events
occurring at exactly the same time is 0.  but if you have multiple bits changing to
the input of a real circuit, then you are, well, screwed, for this class of circuit.
and that's why the static hazard must be eliminated.

============================================================

> >                                                                           so you
> are not
> > sampling a gray coded sequence, so the circuit will fail.  you are
> > not describing my SM, but a poorly designed one.
>
> On the example above, the comb logic is a gray coded sequence. First
> it's "00", then it is "01", then 100 ps later it is "11", then 100ps
> later it is "10". A gray coded sequence. Unfortunately, the SM clock
> decides to sample this gray coded sequence, at the time it's "11". So
> it takes an illegal jump.

no, this is not a gray coded sequence.  this is simply  a lousy circuit, most
probably.  if the circuit is glitching, through the sequence at 100 psec/glitch, "00"
=> "10" => "11" with a single state transition, you have a mess, not a gray code.  for
a gray code, you should change one bit per step.  you are changing two bit, going from
"00" to "11" and the circuit will fail.  that's why they have gray codes which don't
do that.

if your transitions are really moving that fast, with 100 psec between transitions,
then the circuit, using available PAL or FPGA logic will fail, as 100 psec is simply
too fast.

======================================================

> That the SM is gray coded doesn't necessarily mean that the comb logic
> in front of it is free from glitches. See Peter's example.

a gray coded state machine is designed so that another register, run off a clock
asynchronous to the gray coded state machine, can sample it asynchronously.

the logic in a gray coded state machine can glitch as much as it wants, it's a don't
care, as it only cares about what happens at the clock edge.  if you choose to insert
an asynchronous input into the combinational logic of a state machine, any state
machine, then you can have problems, irregardless of what the coding is.

using a state machine whose sequence of states is a gray code (or any other code that
you happen to choose) does not provide relief from the requirement that inputs obey
the setup and hold times.  standard logic design.

===========================================================

> Homann

rk



Article: 13893
Subject: Re: 22V10 Metastability - help please
From: Rickman <spamgoeshere4@yahoo.com>
Date: Thu, 31 Dec 1998 16:33:13 -0500
Links: << >>  << T >>  << A >>
Magnus Homann wrote:
> 
> "Bruce Nepple" <brucen@imagenation.extra.com> writes:
> 
> > Yes Yes Yes.  You got it! I challenge anyone here to come up with a gray
> > code state machine that can reside in state A and conditionally branch to
> > either state B or State C based on an async. input.
> 
> I can't think of one. But you added yet another requirement to Peter's
> list. With thse requirements, one should be safe.
> 
> > "Having spent untold hours at analyzing and measuring metastable
> > behavior, I can assure you that it is (today) a highly overrated
> > problem.  You can almost ignore it."
> > Peter Alfke
> > 12/28/98
> 
> Are you going to hold it to him? :-)

Hey! He did say "almost"!!!  >:^)


-- 

Rick Collins

redsp@XYusa.net

remove the XY to email me.

Article: 13894
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10 Metastability - help please
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 31 Dec 1998 14:09:34 -0800
Links: << >>  << T >>  << A >>


Bruce Nepple wrote:

> Peter Alfke wrote in message <3689409A.9126686@xilinx.com>...
>
> So if a cross coupled latch with an input race condition can not oscillate,
> then it is a metastable free synchronizer and all the years of research and
> Xilinx app notes were wasted.
> Peter, I think you need to rethink a few things.
>
> Bruce
>
> "Having spend untold hours debugging digital designs, I can assure you that
> metastable behavior is a real problem, and every digital designer had better
> understand it"
> Bruce Nepple
> 12/31/98

  The year comes to an end, but this thread goes on.
I never said that metastability does not exist. I have measured it. It does
exist, but the recovery delay  from the metastable (=balanced) condition to the
ultimately stable state is so short in modern CMOS latches and flip-flops, that
the problem has lost most of its impact.
I have published numbers that have never been challenged, and these numbers
prove my point.

The contentious question here is not metastable recovery, but oscillations.

This  is what I  e-mailed recently to Bruce:

If each NAND gate is a single-stage circuit with a 6-dB per octave gain
roll-off, then cross-connecting two of them will never generate an
oscillator.

If, however, each NAND gate ( really an inverter once the common input
is brought High) is a multi-stage circuit, which, in linear terms, means
a faster roll-off in gain, and thus an additional phase lag at high
frequency, then the cross-connection might, at a certain frequency, have
a total phase lag of not 360 degrees ( 2 inverters ) but 720 degrees (
or even 1080 degrees) and also a gain of at least 1 at this frequency.
That circuit can thus oscillate at the frequency where the additional
phase lag is 360 ( or n times 360 degrees).
Call that a marginally stable ring oscillator.

In my defense I can say that nobody should build a latch this way, and
no modern latch or flip-flop would show this behavior. We always make
sure that the feedback  loop is as tight as it possibly can be made,
thus avoiding the situation I mentioned.

It would be interesting to configure a perverse latch in an FPGA, with
several or even many stages of gain inserted in the feedback loop, and
then carefully try to make it oscillate. FPGAs are wonderful toys to
explore this. No breadboard, no wire-wrap, no mess.



So I now claim:

1. A modern CMOS latch can go metastable, but recovers so fast that the problem
is, in most applications, irrelevant. ( see curves in the Xilinx data book,
page 13-49 )

2. A modern CMOS latch cannot be made to oscillate while its control inputs are
stable.

3. A latch with multiple ( or many ) additional stages in its feedback loop can
( most likely)  be made to oscillate.

Can we agree on that?

Happy New Year!

Peter Alfke, speaking for himself.





Article: 13895
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10 Metastability - help please
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 31 Dec 1998 14:10:17 -0800
Links: << >>  << T >>  << A >>


Bruce Nepple wrote:

> Peter Alfke wrote in message <3689409A.9126686@xilinx.com>...
>
> So if a cross coupled latch with an input race condition can not oscillate,
> then it is a metastable free synchronizer and all the years of research and
> Xilinx app notes were wasted.
> Peter, I think you need to rethink a few things.
>
> Bruce
>
> "Having spend untold hours debugging digital designs, I can assure you that
> metastable behavior is a real problem, and every digital designer had better
> understand it"
> Bruce Nepple
> 12/31/98

  The year comes to an end, but this thread goes on.
I never said that metastability does not exist. I have measured it. It does
exist, but the recovery delay  from the metastable (=balanced) condition to the
ultimately stable state is so short in modern CMOS latches and flip-flops, that
the problem has lost most of its impact.
I have published numbers that have never been challenged, and these numbers
prove my point.

The contentious question here is not metastable recovery, but oscillations.

This  is what I  e-mailed recently to Bruce:

If each NAND gate is a single-stage circuit with a 6-dB per octave gain
roll-off, then cross-connecting two of them will never generate an
oscillator.

If, however, each NAND gate ( really an inverter once the common input
is brought High) is a multi-stage circuit, which, in linear terms, means
a faster roll-off in gain, and thus an additional phase lag at high
frequency, then the cross-connection might, at a certain frequency, have
a total phase lag of not 360 degrees ( 2 inverters ) but 720 degrees (
or even 1080 degrees) and also a gain of at least 1 at this frequency.
That circuit can thus oscillate at the frequency where the additional
phase lag is 360 ( or n times 360 degrees).
Call that a marginally stable ring oscillator.

In my defense I can say that nobody should build a latch this way, and
no modern latch or flip-flop would show this behavior. We always make
sure that the feedback  loop is as tight as it possibly can be made,
thus avoiding the situation I mentioned.

It would be interesting to configure a perverse latch in an FPGA, with
several or even many stages of gain inserted in the feedback loop, and
then carefully try to make it oscillate. FPGAs are wonderful toys to
explore this. No breadboard, no wire-wrap, no mess.



So I now claim:

1. A modern CMOS latch can go metastable, but recovers so fast that the problem
is, in most applications, irrelevant. ( see curves in the Xilinx data book,
page 13-49 )

2. A modern CMOS latch cannot be made to oscillate while its control inputs are
stable.

3. A latch with multiple ( or many ) additional stages in its feedback loop can
( most likely)  be made to oscillate.

Can we agree on that?

Happy New Year!

Peter Alfke, speaking for himself.





Article: 13896
Subject: Can a cross coupled latch "oscillate"? was Re: ..........
From: "Bruce Nepple" <brucen@imagenation.extra.com>
Date: Thu, 31 Dec 1998 19:12:43 -0800
Links: << >>  << T >>  << A >>
Peter, you seem to be missing the point which is that the cross coupled
latch, as I described it, will oscillate, illustrating the effect which
causes metastability.  You claim that model is bogus.  You are incorrect.  I
feel compelled to continue this thread because it is such a good example,
and you dismissed it out of hand.  I wish we could spend 15 minutes at a
blackboard.

Just to be sure there is no mis-understanding, I describe this "ideal" latch
as follows:

2 nand gates with 1 ns prop delay and 0 ns. rise/fall time, are connected as
a simple RS latch.  The R and S inputs are connected together.  Initially
they are connected to ground, and then are brought to logic 1.  The ideal
latch then oscillates forever (as a digital ring oscillator).

Your talk about linear oscillators is completely irrelevant.  A looped
digital delay line can oscillate for a while if you inject a short pulse,
and it has no gain.  Saturated digital logic is a different animal with
regard to prop. delays.

There is no need to reply further if you cannot answer this 2 part question:

If a cross coupled latch does not go unstable when there is a race on its
input, then why is it not, then, a metastable free synchronizer? (which
according to theories I am familiar with, is impossible).

If your answer is that metastability is different, please, then, what model
do you use to explain how metastability occurs in a simple cross coupled
latch?

To simply dismiss my example as "bogus" without offering up the "real" model
is a cheap shot.

Bruce


Article: 13897
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10 Metastability - help please
From: "Bruce Nepple" <brucen@imagenation.extra.com>
Date: Thu, 31 Dec 1998 19:30:45 -0800
Links: << >>  << T >>  << A >>
I once ran some experiments on 74S74 flip flops to determine the extent of
their metastable behavior.  There was some difference from vendor to vendor
and part to part, but it was worthwhile to characterize what might be a
reasonable settling time.  If you have the time, it would be educational to
duplicate what I did.  I essentially built a 2 stage synchronizer with
clocks driven from two identical Schmidt triggers.  The input to one of the
schmitt triggers was delayed slightly by an RC network (variable R, small
C).  The delayed circuit drove the second flop.  I could adjust the R until
I saw unstable behavior on the output of the second flip flop.  (the first
flop should be connected to toggle).

osc ----schmitt ----schmitt ----first flop clock
     |--schmitt--RC--schmitt ----second flop clock

Still have some pretty neat pictures of flip flop outputs pulsing high then
low after the clock.  It was amazing how accurately I needed to adjust the
delay.  I expect it will be even harder now-a-days.  Also, the difference
between low to high D and high to low D was dramatic.

Bruce

.extra blows away the email



Tom Bruhns wrote in message <76biho$lhj@hpcvsnz.cv.hp.com>...
>
>Bruce Nepple (brucen@imagenation.extra.com) wrote:
>
>..
>
>: Nobody has really said much about metastability here, so I'd like to
share
>: what I think is a real good example (a simplification)  of exactly how
>: metastability can occur if a flip-flop.  There are two conditions that
can
>: easily cause metastability.  Race conditions and runt pulses.
>
>(Tried to email to Bruce, but "imagenation" wasn't recognized...)
>Anyone have any info on the current "state of the art" with regard to
>metastability in D flipflops?  I'm interested in using a 74AC74 at
>3.3V supply in a situation where metastability is very likely to
>be excited if it exists.  In this particular circuit, if the output
>isn't stable, that's not really a problem, but if metastability
>exists and causes unusual stresses to the 'AC74, or causes nasty
>power supply current spikes, that wouldn't be very nice.  Any
>insights anyone can offer would be most welcome.
>
>--
>Cheers,
>Tom
>tom_bruhns@hp.com


Article: 13898
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10 Metastability - help please
From: rk <stellare@NOSPAMerols.com>
Date: Thu, 31 Dec 1998 23:14:18 -0500
Links: << >>  << T >>  << A >>
hi bruce,

i ran similar experiments about 15 years ago using 54lsxx technology, since
that's what we were using for the most part.  i don't have the scope photos
(perhaps packed away somewhere else wheere i can easily find them :-) but
remember that an output would go to one state and then back to the original
one; the complement didn't move, iirc.  i never saw an oscillation and tried
hard to tweak it to get one or to get a non-logic level, which i didn't see
either.  like your experience, it was a tough tweak to get it to go metastable.

perhaps i'll build another set with the stanford digital delay generator (it's
the '90s, got digital tweakers now), see what happens with more modern
flip-flops like the 74ac74.

happy new year!

rk

==================================

Bruce Nepple wrote:

> I once ran some experiments on 74S74 flip flops to determine the extent of
> their metastable behavior.  There was some difference from vendor to vendor
> and part to part, but it was worthwhile to characterize what might be a
> reasonable settling time.  If you have the time, it would be educational to
> duplicate what I did.  I essentially built a 2 stage synchronizer with
> clocks driven from two identical Schmidt triggers.  The input to one of the
> schmitt triggers was delayed slightly by an RC network (variable R, small
> C).  The delayed circuit drove the second flop.  I could adjust the R until
> I saw unstable behavior on the output of the second flip flop.  (the first
> flop should be connected to toggle).
>
> osc ----schmitt ----schmitt ----first flop clock
>      |--schmitt--RC--schmitt ----second flop clock
>
> Still have some pretty neat pictures of flip flop outputs pulsing high then
> low after the clock.  It was amazing how accurately I needed to adjust the
> delay.  I expect it will be even harder now-a-days.  Also, the difference
> between low to high D and high to low D was dramatic.
>
> Bruce
>
> .extra blows away the email
>
> Tom Bruhns wrote in message <76biho$lhj@hpcvsnz.cv.hp.com>...
> >
> >Bruce Nepple (brucen@imagenation.extra.com) wrote:
> >
> >..
> >
> >: Nobody has really said much about metastability here, so I'd like to
> share
> >: what I think is a real good example (a simplification)  of exactly how
> >: metastability can occur if a flip-flop.  There are two conditions that
> can
> >: easily cause metastability.  Race conditions and runt pulses.
> >
> >(Tried to email to Bruce, but "imagenation" wasn't recognized...)
> >Anyone have any info on the current "state of the art" with regard to
> >metastability in D flipflops?  I'm interested in using a 74AC74 at
> >3.3V supply in a situation where metastability is very likely to
> >be excited if it exists.  In this particular circuit, if the output
> >isn't stable, that's not really a problem, but if metastability
> >exists and causes unusual stresses to the 'AC74, or causes nasty
> >power supply current spikes, that wouldn't be very nice.  Any
> >insights anyone can offer would be most welcome.
> >
> >--
> >Cheers,
> >Tom
> >tom_bruhns@hp.com



Article: 13899
Subject: Re: Can a cross coupled latch "oscillate"? was Re: ..........
From: wen-king@myri.com (Wen-King Su)
Date: 31 Dec 1998 21:17:14 -0800
Links: << >>  << T >>  << A >>
In a previous article "Bruce Nepple" <brucen@imagenation.extra.com> writes:

;If a cross coupled latch does not go unstable when there is a race on its
:input, then why is it not, then, a metastable free synchronizer? (which
;according to theories I am familiar with, is impossible).

Metastable does not equate oscillation.  When output stays in the illegal
region for an extented period of time, even if it is not oscillating, it
is still called metastable.  Oscillation-free synchronizer does exist and
is being used in many places.



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

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

Custom Search