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 13825

Article: 13825
Subject: Re: 22V10 Metastability - help please
From: rk <rich.katz@nospam.gsfc.nasa.gov>
Date: Mon, 28 Dec 1998 22:05:41 -0500
Links: << >>  << T >>  << A >>
Peter Alfke wrote:

> Bob Perlman wrote:
>
> > Hi -
> > <snip>
>
>
>
> > 22V10s and most other
> > PLDs are based on AND/OR planes, which are bound to be glitchy if the
> > designer hasn't (a) added product terms to mask the effects of
> > transition or (b) synchronized asynchronous inputs.
> >
> > The Xilinx FPGA implementation is completely different.  Each 4-input
> > LUT consists of 16 SRAM cells (latches, actually) followed by a 16:1
> > mux built with transmission gates.  The construction is such that, if
> > you switch a single LUT input, the mux switches between the outputs of
> >
> > two latches, and no others.   <snip> If the
> > two latches we're transitioning between have the same state, you get a
> >
> > glitchless transition.  There's no RAM decode glitch because there's
> > no decoder.
>
> Bob is right, but the reason that there is no glitch, even when the
> multiplexer acts like a break-before-make switch (  it undoubtably does,
> either in one direction or the other ) is more subtle., There is no
> glitch even with break-before-make because the stray capacitance between
> these pass transistors holds the old value for the fractional nanosecond
> in question.
>
> Having answered this question many times...

yes, this has come up several times - and note that xilinx is not alone with
this design for glitchless switching - quicklogic does the same sort of
thing.

rk

Article: 13826
Subject: Re: 22V10 Metastability - help please
From: "Stout" <stout@pdq.net>
Date: Mon, 28 Dec 1998 21:20:13 -0600
Links: << >>  << T >>  << A >>

rk wrote in message <36880CFA.B829591@NOSPAMerols.com>...
>
>you should, it's correct and exactly what i said.


I'm glad you agree with me.

Jeff Stout


Article: 13827
Subject: Re: smallest DCT algorithm?
From: bhaskaran vasudev <bhaskara@best.com>
Date: Mon, 28 Dec 1998 20:51:48 -0800
Links: << >>  << T >>  << A >>
Daniel Sears wrote:
> 
> Dan,
> 
> in principle, there isn't a big difference between finding nice
> numbers near the original cosine values and truncating them at
> a certain precision.  Both of these are approximations.
> 
> When I looked at this stuff, the shift and add approaches were
> for minimizing hardware.  If the hardware is given, and you
> are minimizing software instructions, I don't think it is profitable.
> 
> Multiplication free DCTs are a subset of multiplication free filters
> which are well published in the various research magazines.
> 
> You might look at:
> 
>  SPIE Proceedings Vol. 2419
>  Digital Video Compression: Algorithms and Technologies 1995
>  Multiplication free scaled 8 x 8 DCT algorithm with 530 additions

there is discussion about developing multiplier-free DCt in the
book
Image and Video Compression Standards: Algorithms and Architectures
(see www.best.com/~bhaskara).

The problem with mult. free DCTs is that they don't pass the IEEE
DCT accuracy test (which may or may not be okay depending on your
application). 
As for smallest DCT - if you mean code size, it depends on processor
for which you implement the DCT, if you mean fastest DCT that too
depends on processor. most of mult. free DCT implementations as
was done for HP's MPEG playback on PARISC CPUs, was motivated by
the fact that such CPUs did not have a multiplier unit in the integer
ALU. On the other hand, if you had a multiply-accumulate architecture
based CPU (Pentium MMX has such a thing), then a Chen DCT instead of
Feig-Winograd DCT may be a better choice since it needs only 416 
multiply accumulate operations.

- Bhaskaran Vasudev
  Epson Palo Alto Laboratory

Article: 13828
Subject: Circa 1994 Altera 881152GC192 FPGA
From: chakanp@hotmail.com ("Håkan Pettersson")
Date: Mon, 28 Dec 1998 23:02:18 -0800
Links: << >>  << T >>  << A >>
The only Flex8000 parts that were available in the 192 PGA was (and is) the
EPF8820 and the EPF8636.

The 8820 has some 16000 gates and 820 Flipflops

The 8636 has 12000 gates and 636 flipflops



*** Posted from RemarQ - http://www.remarq.com - Discussions Start Here (tm) ***

Article: 13829
Subject: Re: smallest DCT algorithm?
From: Tom Lane <tgl@netcom.com>
Date: Tue, 29 Dec 1998 07:51:31 GMT
Links: << >>  << T >>  << A >>
bhaskaran vasudev <bhaskara@best.com> writes:
> The problem with mult. free DCTs is that they don't pass the IEEE
> DCT accuracy test (which may or may not be okay depending on your
> application). 

Huh?  Take an IEEE-1180 compliant fixed-point DCT, expand its
multiplies by constants to shifts and adds, and voila.  Perhaps
we have different ideas of what is meant by a "mult-free DCT"?

			regards, tom lane

Article: 13830
Subject: Re: How to import EDIF file in Foundation Software?
From: Le mer Michel <michel.lemer@ago.fr>
Date: Tue, 29 Dec 1998 10:15:43 +0100
Links: << >>  << T >>  << A >>
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: 13831
Subject: Re: smallest DCT algorithm?
From: benyamin@my-dejanews.com
Date: Tue, 29 Dec 1998 10:39:41 GMT
Links: << >>  << T >>  << A >>
In article <768o2i$egq@sjx-ixn9.ix.netcom.com>,
  "Daniel Sears" <dbsears@ix.netcom.com> wrote:
> You might look at:
>
>  SPIE Proceedings Vol. 2419
>  Digital Video Compression: Algorithms and Technologies 1995
>  Multiplication free scaled 8 x 8 DCT algorithm with 530 additions
>
I don't see how this could be a 2-D DCT w/ 530 adds.  An 8-point DCT requires
7*8=56 adds, which makes 56*8=448 adds for a row or column transform.  So they
are using another 82 adds to perform the "multiplies".

For something like the single chip MPEG encoder ASICs, are they using
multiply-free structures, or something w/ multiplies and adds?	I would
assume that throughput requirements would necessitate fairly parallel
designs, but that the multipliers may be quite large.

Dan

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Article: 13832
Subject: NEW ENGINEERING PAGE: Please Visit
From: metad@globalnet.co.uk (Scott Paul Johnston)
Date: Tue, 29 Dec 1998 10:50:57 GMT
Links: << >>  << T >>  << A >>
Please visit and comment on my Electronics and Electrical Engineering
pages located at:

http://www.users.globalnet.co.uk/~metad/eee.htm

Containing:
Introduction to EEE
Resources (over 100 web links)
Employment Statistics and newspaper excerpts
Engineering Poems, Quotations and Jokes
EEE at Glasgow University

In addition my homepage (http://www.users.globalnet.co.uk/~metad/)
contains:

A section about me
My CV
A James Bond Section
A guestbook
Humour
500+ cool links in the "new look" bookpage
Cool background MIDI and graphics
Literary quotations
Photo Album
Student Resources
Awards Page
Poems...

Basically, something for everyone!

PLEASE VISIT VIA MY MAIN HOMEPAGE ADDRESS!

Please send you comments via the guestbook or by Email (containing
your full name and Email and webpage addresses) and visit via
http://www.users.globalnet.co.uk/~metad/.

Thanks
Scott Johnston
metad@globalnet.co.uk   

Article: 13833
Subject: Re: Async Fifo Core or Macro for Xilinx FPGA
From: "Daniel K. Elftmann" <elftmann@ix.netcom.com>
Date: Tue, 29 Dec 1998 09:49:10 -0500
Links: << >>  << T >>  << A >>
I've completed two different Async FIFO designs in HDL.  One in VHDL for an
Actel device, and one in Verilog for an ASIC.  Never trivial, but It can be
done.

rk wrote in message <3687A3AF.26248781@NOSPAMerols.com>...
>Edward Moore wrote:
>
>> then Ray Andraka <randraka@ids.net> wrote:
>>
>> >It is very difficult to get this kind of performance in a synthesized
design
>> >(especially with the async clocks).  In cases like this it is much
faster and
>> >easier to just to do it in schematic the way you know it needs to be
implemented
>> >and be done with it.
>>

NOTE: Ray did not say that it could not be done in an HDL, only that it is
much faster and easier to do it in a schematic IHOP (In His Honest Opinion).
I see this simply as opinion and a not a statement of fact that it can't be
done in HDL.  Every designer should work in the the design flow he/she is
most comfortable with and which allows them to get the design completed on
time and functional.

>> IMO one of the reasons why the schematic entry vs. HDL debate keeps
>> cropping up is statements like the above, which are originated by people
>> who either:
>>
>> a) might have a vested interest in persuading people that they won't be
>> able to use a HDL for their designs
>>
>> b) havn't tried using a HDL
>>
>> c) have tried a HDL, but didn't do it properly
>>
>> d) work for FPGA manufacurers and should perhaps know better.
>>

Not sure I understand d)???

I work for an FPGA manufacturer (Actel).  It appears to be some sort of jab,
but it didn't catch any flesh.

>> At it's heart, the 'cant do it in a HDL' arguement seems to stem from a
>> confusion between inferred and instantiated HDL. No one is claiming that
>> a synthesiser can infer a a complete async fifo. But using instantited
>> components is a direct textual equivalant to schematic entry, so there
>> is no design element that can be placed on a schematic that can't be
>> included in a HDL design. Period. (as you Americans say).
>
>i would strongly disagree that instantiated components in a hdl is a direct
>equivalent to schematic entry.  now, if you draw schematics such that there
is just a
>group of black blox symbols on the sheet, with a textual label on them as a
reference
>designator indentifying the function, and no interconnection between
components with
>lines, just labels for a small net attached to each pin, and the symbols
for each
>component positioned linearly on the page, without respect for data flow or
time,
>then you would have an equivalence.  while some engineers do draw
schematics that
>way, it loses a lot of information.
>

But functionally they still are equivalent, assuming the synthesis tool
treats instantiated components as black boxes and does not attempt to
re-optimize.  Aesthetically they are very different, put that's just a
matter of style.  I've seen schematics that would take days, weeks, or
months to determine the intended function intended by the original designer,
similarly I've seen HDL code that would take just as long.  Early in my
career there was a senior designer that thought that if no one else could
decipher his schematics it would give him some measure of job security.  He
actually stated this to me when I asked him why the 50 odd sheets in his
design used no hierarchy nor flow.  Later in my career I picked up a ASIC
design implemented in Verilog (75% structural and 25% RTL), which had
exactly ZERO comments.  It had a good use of hierarchy, but required a lot
of time with the Fujitsu cell library book.  It took several months with the
simulator and print outs before I got a solid grip on the design.  In
contrast to the above two ASICs designs, I've seen schematics with beautiful
use of hierarchy, flow, truth tables, etc... AND I've seen HDL designs with
the same that were quite easy to pick-up and take over.

When drawing schematics or writing HDL code, one should always taken into
consideration the following possibility:

The designer of the next iteration of the design or the continuation
engineer may be A CRAZED LUNATIC WHO KNOWS WHERE YOU LIVE!

The main point here is that either Schematics or HDLs can get the job done
and it is simply a matter of choice.  HDL (IMHO) is more portable, but in a
previous job we drew Viewlogic schematics which had ASIC cell mappings such
that we could take the same design to Toshiba, LSI, VLSI, etc.. depending on
which foundry our end customer selected.  For the last design I worked on
with this employer, the choice wasn't made until one week before the target
PNR netlist release date, no problem with the system we had in place.  The
biggest disadvantage I see with schematics is the dependency on the EDA
supplier, as moving a design from one schematic environment to another is
not as easy as changing synthesis vendors;  while neither is completely free
of pain, I'd choose the synthesis route.  One company I worked for still
uses the Vanguard Schematic capture system, years after Terradyne sold it
off and Sofia Systems stopped supporting it in the US, but re-drawing the
schematic database in another package never quite fit into the schedule
(especially with the amount of re-use we were able to employ).  We simply
chose to stay with the package we knew and it's known bugs and limited set
of seats we had (usually sufficient if the stars aligned properly), putting
off the inevitable transition till tomorrow.

If someone had asked me my opinion on this subject during my transition
period from schematic entry to HDL you'd definitely have received a much
different response.  But after the transition period,  in 8 years of Verilog
HDL design, I have yet to find the design that forced me back to schematics
(structural instantiation: yes; schematics: no).  Now as a Field
Applications Engineer I've picked up VHDL as well.  It was kind of like
learning PALASM after knowing ABEL, then later picking up CUPL, each new
language just gets easier.  But I have a good mix of customers that refuse
to go down the learning curve of HDLs and stick with the schematic tools and
methods they know.  The still get the job done, so I'd find it very
difficult in most cases to disagree with there decision.

The biggest problem I see with HDLs today is that younger designers who've
never drawn a schematic in there career are at a distinct disadvantage from
those that have, and are very much at the mercy of the synthesis tool.  Some
form of schematic capture still has to be taught at the pre-grad level to
ensure these engineers understand the underlying gates.

>=======================================================
>
>> I believe that the mixed inferred/instantiated method is used by most
>> experienced HDL designers. A designer might predominately infer logic,
>> but a some point will say to themselves 'it will be easier to just
>> instantiate this element and have done with it'.
>
>or hook a mixture of components, schematic, macro, and hdl on a top level
roadmap or
>dare i say, schematic.  a large amount of instantiated logic is good for
'puters, in
>my opinion, not for humanoids.
>
>========================================================
>
>rk
>


Article: 13834
Subject: Re: 22V10 Metastability - help please
From: z80@ds2.com (Peter)
Date: Tue, 29 Dec 1998 15:06:40 GMT
Links: << >>  << T >>  << A >>

>22V10s and most other
>PLDs are based on AND/OR planes, which are bound to be glitchy if the
>designer hasn't (a) added product terms to mask the effects of
>transition or (b) synchronized asynchronous inputs.

I do not agree with this. 

Let's say you are using a 22V10 as a simple decoder. If what you say
is true, it would be virtually impossible to make a decoder which does
not generate a glitch before settling down.

No, a GAL "must" be designed so that the skew between the true and
complement versions of an input, plus any other skews generated by the
layout of the product matrix, is **less than** the switching time of
the gate implementing the product matrix.

The situation is made more complex by the different implementation of
the product matrix in a conventional GAL (a load of wire-ORed signals
with pullups, feeding sense amplifiers, AIUI, which is why they draw
so much static current) versus a "zero power" GAL like the P3Z22V10
which uses a chain of gates to form a mux. On top of that you get the
weird "semi" zero power GALs which use input transition sensing to
power the product array up/down, to somehow achieve good data sheet
specs...

Without withing to make this thread even longer, and despite what has
been said here, I cannot see the problem in *sampling* a *single*
async input, with a *Gray-code* state machine. In such a state
machine, only *one* D-type at any one time can potentially act on that
input, so either a) the input change is just sampled (and you go to
the next state) or b) the input change is just missed (and you remain
in the present state). 

The only risk (which truly cannot be avoided) is with *metastability*,
and that comes down purely to whether the D-type settles down before
the next clock comes along.


--
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: 13835
Subject: Re: 22V10 Metastability - help please
From: ems@riverside-machines.com.NOSPAM
Date: Tue, 29 Dec 1998 15:38:19 GMT
Links: << >>  << T >>  << A >>
Here's another 2 centi-euros(?) worth. At the risk of annoying a lot
of people, there seem to be a number of red herrings here (doubtless
I'll be severely kicked if I've misunderstood):

1) Static hazards. This is irrelevant, since we're talking about a
synchro: it doesn't matter whether the output settles to 1 or 0, and
so it doesn't matter whether there are any glitches on the
combinatorial logic feeding the synchro f/f, or when these glitches
are sampled.

2) differential delays on a signal and its inverse in an AND-OR array:
doesn't matter, for exactly the same reason.

3) Metastability: not, per se, a problem.

There's no problem incorporating a synchro into a state machine, as
long as you can guarantee that only one register bit samples the
asynchronous signal (pretty much what Peter Alfke (among others?)
said, although in passing). In this case, both EQ2 and EQ0 sample
ENC_IN. This will eventually fail since EQ2 and EQ0 will occasionally
disagree on the value of ENC_IN. You don't need a Gray-coded machine -
you just have to make sure that only one f/f samples the input. The
only way that this can fail is if the f/fs output still hasn't
stabilised after one cycle, which is astronomically unlikely in this
case.

In this case, to explain the 100 -> 101 -> 001 sequence you may have
to invoke a hazard, or whatever (I can't explain it just by assuming
that EQ2 and EQ0 have sampled different values), but I find it hard to
believe that you could eventually make this machine work by removing
all hazards - you'll still have two registers sampling ENC_IN.

It would be nice to see your original state transition diagram.
Presumably the root of the problem is that you're looking at ENC_IN at
two different points on the diagram. If you were only looking at one
point, then the interesting question is why ENC_IN isn't optimised out
of the other two register bits.

Evan

Article: 13836
Subject: Re: 22V10 Metastability - help please
From: Magnus Homann <d0asta@mis.dtek.chalmers.se>
Date: 29 Dec 1998 17:23:25 +0100
Links: << >>  << T >>  << A >>
ems@riverside-machines.com.NOSPAM writes:

> Here's another 2 centi-euros(?) worth. At the risk of annoying a lot
> of people, there seem to be a number of red herrings here (doubtless
> I'll be severely kicked if I've misunderstood):

Where do you want to be kicked? :-)

> 1) Static hazards. This is irrelevant, since we're talking about a
> synchro: it doesn't matter whether the output settles to 1 or 0, and
> so it doesn't matter whether there are any glitches on the
> combinatorial logic feeding the synchro f/f, or when these glitches
> are sampled.

What do you mean by a "synchro"? Never heard that term before.  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.

[...]
> In this case, both EQ2 and EQ0 sample
> ENC_IN. This will eventually fail since EQ2 and EQ0 will occasionally
> disagree on the value of ENC_IN. You don't need a Gray-coded machine -
> you just have to make sure that only one f/f samples the input.

That wouldn't have helped. The logic hazards would still be there. In
fact, if you look at the equations, you do see that EQ0 and EQ2
samples ENC_IN at *differeent states*. They will never care what
the value of ENC_IN has at the same transition. The other terms in the
product take care of that.

> In this case, to explain the 100 -> 101 -> 001 sequence you may have
> to invoke a hazard, or whatever (I can't explain it just by assuming
> that EQ2 and EQ0 have sampled different values), but I find it hard to
> believe that you could eventually make this machine work by removing
> all hazards - you'll still have two registers sampling ENC_IN.

But not at the same time. I wish Peter would try the solution I
suggested, and see how it works.
 
> It would be nice to see your original state transition diagram.
> Presumably the root of the problem is that you're looking at ENC_IN at
> two different points on the diagram.

Actually, he is looking four times for the value of ENC_IN. Twice for
each EQ0/EQ2. That is the problem.

Hope this clarifies it.

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: 13837
Subject: Re: Async Fifo Core or Macro for Xilinx FPGA
From: rk <stellare@NOSPAMerols.com>
Date: Tue, 29 Dec 1998 11:42:06 -0500
Links: << >>  << T >>  << A >>
Daniel K. Elftmann wrote:

> >i would strongly disagree that instantiated components in a hdl is a direct
> >equivalent to schematic entry.  now, if you draw schematics such that there
> is just a
> >group of black blox symbols on the sheet, with a textual label on them as a
> reference
> >designator indentifying the function, and no interconnection between
> components with
> >lines, just labels for a small net attached to each pin, and the symbols for
> each
> >component positioned linearly on the page, without respect for data flow or
> time,
> >then you would have an equivalence.  while some engineers do draw schematics
> that
> >way, it loses a lot of information.
>
> But functionally they still are equivalent, assuming the synthesis tool
> treats instantiated components as black boxes and does not attempt to
> re-optimize.

functionally equivalent yes; direct equivalent nope.  this is always a nice
religious argument to get into, but the edif netlist produced by actmap, for
example, is functionally equivalent to say its structural vhdl input which is,
according to some, equal to a schematic.  well, if we only have computers
reading and writing these things i would agree [and at my day job we have a nice
little project where we do have computers writing the vhdl so i don't care what
it looks like or how awful it is to write, since it's generated algorithmically
by a HLL].  however, if we have humanoids writing, reading, and maintaining the
code, then they are most definitely not directly equivalent.  i have seen too
many schematics drawn w/ just isolated symbols with short unconnected nets that
are labelled.  that is the direct equivalent of a vhdl structural source file.
of course, one can avoid specifying the reference designators or labels for each
of them, making them both the direct equivalent mess when you gotta go in and
troubleshoot the thing.

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

>                                   Aesthetically they are very different, put
> that's just a
> matter of style.  I've seen schematics that would take days, weeks, or
> months to determine the intended function intended by the original designer,

yes, as i described above.  i've spent more than enough time redrawing
schematics so that i can understand what's going on.  and back in the '80s, when
we actually had draftsman and a drafting department, some of them would take the
nice hand drawn schematic and enter it into the machine, making the most
efficient use of the space on the paper, never sure why, probably some
government standard. :-)

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

> similarly I've seen HDL code that would take just as long.

yes, and at day job i had purchased "VHDL cores" that were, in a large part, a
structural vhdl netlist [friendly shot across the bow, sorry, couldn't resist
:-)].

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

>
> Early in my
> career there was a senior designer that thought that if no one else could
> decipher his schematics it would give him some measure of job security.  He
> actually stated this to me when I asked him why the 50 odd sheets in his
> design used no hierarchy nor flow.

interesting.  i remember one engineer who was less than happy with the fact that
the employer "owned" all of his notebooks, notes, etc.  troubled him a lot.  so
he kept all of his notebooks in chinese and happily turned them in when he left.

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

>                                                     Later in my career I
> picked up a ASIC
> design implemented in Verilog (75% structural and 25% RTL), which had
> exactly ZERO comments.  It had a good use of hierarchy, but required a lot
> of time with the Fujitsu cell library book.  It took several months with the
> simulator and print outs before I got a solid grip on the design.

and more recently, at day job, i received a "design" for a certain
manufacturer's device, with 8,000 gate capacity, that was 99% structural vhdl.
it seems that a contractor gave the design to a subcontractor who gave the
design to a sub-sub-contractor who took the original schematics and
hand-converted it into a structural vhdl description before tossing it into the
synthesis tool.  don't ask me why, perhaps a cost-plus contract?  the design had
timing problems and to figure out what was going on, i had to start drawing
schematics from the vhdl, as for some still unspecified reason, the schematics
were not available.  what a mess!

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

>
> In
> contrast to the above two ASICs designs, I've seen schematics with beautiful
> use of hierarchy, flow, truth tables, etc... AND I've seen HDL designs with
> the same that were quite easy to pick-up and take over.

agreed, 100%.  i used to hate drawing schematics on the machine, very time
consuming, much prefer the berol's 1/4 size template and a drafting table.
seemed to work well and was much quicker (circa '84, approx 4-5 seconds to call
up an AND gate).  it takes time to make a good schematic, but it's something
that you gotta live with for a long time, so it's worth it.  same with vhdl, i
take quite a bit of time in lining up columns and stuff [old habits from 20+
years of coding pascal no doubt].

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

> When drawing schematics or writing HDL code, one should always taken into
> consideration the following possibility:
>
> The designer of the next iteration of the design or the continuation
> engineer may be A CRAZED LUNATIC WHO KNOWS WHERE YOU LIVE!

a good point. but i'm from NY and just don't care.  :-)

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

> The main point here is that either Schematics or HDLs can get the job done
> and it is simply a matter of choice.  HDL (IMHO) is more portable,

i would agree, unless it's coded in structural vhdl.

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


>
> but in a
> previous job we drew Viewlogic schematics which had ASIC cell mappings such
> that we could take the same design to Toshiba, LSI, VLSI, etc.. depending on
> which foundry our end customer selected.  For the last design I worked on
> with this employer, the choice wasn't made until one week before the target
> PNR netlist release date, no problem with the system we had in place.

i've done similar things, using actel tools and libraries, since that's what's
available here at home, and then after logic simulation re-mapping primitives
onto chip express asic primitives, etc., and then a final sim on a machine with
a more power viewlogic license  it works rather nicely.

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

>
> The
> biggest disadvantage I see with schematics is the dependency on the EDA
> supplier, as moving a design from one schematic environment to another is
> not as easy as changing synthesis vendors;  while neither is completely free
> of pain, I'd choose the synthesis route.

i agree with this to a certain degree.  i have found that writing code for
multiple simulators/synthesizers takes some work, far too much in my opinion,
and that this really hurts the industry as a whole.  go ahead, write portable c
code, for instance; when i was doing it (late '80s) it was a mess, not sure if
it's really any better now.  it looks like the eda industry is determined to
screw themselves the same way.  ada was very strict about this sort of thing,
but was so strict about no subsets, for instance, that that killed the market.
vhdl is too much do your own thing - just look at all the notes here about
converting types, which libraries to use (since common functions are not part of
the language), etc., etc.

now, it is easier to port vhdl code from tool to tool than schematics.  on one
job i'm on [day job], multiple schematic tools were used for different boards.
seemed like a big mistake early on but, hey, the managers are always right.  no
attention was paid to partitioning and now, for the final product, several
boards done in different tool environments need to be merged.  so, what is
happenning?  we're paying engineers to re-type in schematics and we all have to
proof read them again, getting all of his new typographical errors out.  a total
pain.  and a waste of time and $.  now, i don't have any experience with it, but
does the edif system work well for transferring schematics between systems?  i
don't have the licenses for it for my viewlogic system so i was never able to
give it a try.

on the other hand, when you read a schematic you know exactly what has been
designed.  when reading hdl code, you can get an idea of what has been
designed.  however, the actual design will be a function of:

    - synthesizer used
    - version of the synthesizer used (can be updated day by day, apparrently)
    - constraint files for synthesizers
    - phase of the moon (aka random seed)
    - directives to synthesizers (i.e., state encoding method)
    - etc., etc.

so, one can make a good case that schematics have poor portability but vhdl is
even weaker, since the hdl files do not fully capture the design at all.

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

>                                                               One company I
> worked for still
> uses the Vanguard Schematic capture system, years after Terradyne sold it
> off and Sofia Systems stopped supporting it in the US, but re-drawing the
> schematic database in another package never quite fit into the schedule
> (especially with the amount of re-use we were able to employ).  We simply
> chose to stay with the package we knew and it's known bugs and limited set
> of seats we had (usually sufficient if the stars aligned properly), putting
> off the inevitable transition till tomorrow.

i feel your pain.  and i feel it hard.  and i will be feeling it harder in the
near future, i am sure.  one of the things that i'm evaluating now is whether to
keep the current design environment or upgrade to a newer, more modern one.
perhaps it's a question of long term gain vs. short term pain.  either way i
know i will suffer.

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

> If someone had asked me my opinion on this subject during my transition
> period from schematic entry to HDL you'd definitely have received a much
> different response.  But after the transition period,  in 8 years of Verilog
> HDL design, I have yet to find the design that forced me back to schematics
> (structural instantiation: yes; schematics: no).

one class of circuits that i like much better in schematics is synchronizers.
another is ripple counters.  of course, for ripple counters, it's easiest to
simply use programs like actgen and have it automagically generate a nice
symbol.  then i can take the symbol and just drop it down onto my higher level
schematic. less work and more readable than having to type in the component
definition and then the named association on parameters, or making sure that you
get the order right for positional parameters, or doing generate statements,
etc., etc.  of course, with a schematic and a symbol, it's easy to hook up and
verify, with no declarations needed.

another class of circuits that i like schematics better for is multipliers.
typing in Y = A*B just doesn't seem to make it for me.  especially if i decide
to control the pipelining myself and perhaps use signed magnitude numbers, which
have certain advantages.  high-speed, low-power accumulators also fit into this
area.  where i can optimize it far easier in a schematic (perhaps with a vhdl or
actgen subcomponents included) than i could in vhdl, which would be rather
clunky.

another nice example is the simple adder.  let's say i type Y = A+B and i'm
trying to minimize for area.  and let's say i do this with, for example, the
actmap synthesizer (so you can try this at home).  i find that actmap, when
configured for area optimization, calls actgen to do the heavy lifting, with a
medium speed adder called out.  is there a way to tell actmap to tell actgen to
give me a ripple carry adder?  there is a substantial difference in the number
of modules used, approximately 50%.  this is not just a function of actmap, but
i've tried some substantially more expensive tools which produced the same
result.  synopsys design compiler, with proper constraints, did do as well as
actgen.

i could go on and on, but there's enough cases where i find schematics easier to
get the answer that i want that i jump up and down everytime people say they're
not needed or won't be available.  it takes a lot of work, sometimes, to get the
answer that you want with HDLs.

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

>
> Now as a Field
> Applications Engineer I've picked up VHDL as well.  It was kind of like
> learning PALASM after knowing ABEL, then later picking up CUPL, each new
> language just gets easier.  But I have a good mix of customers that refuse
> to go down the learning curve of HDLs and stick with the schematic tools and
> methods they know.  The still get the job done, so I'd find it very
> difficult in most cases to disagree with there decision.
>
> The biggest problem I see with HDLs today is that younger designers who've
> never drawn a schematic in there career are at a distinct disadvantage from
> those that have, and are very much at the mercy of the synthesis tool.  Some
> form of schematic capture still has to be taught at the pre-grad level to
> ensure these engineers understand the underlying gates.

i'm not sure where this is to be taught, and perhaps i'm just a bit of a geezer,
but i think that schematics are important (currently my design mix is split
between vhdl, macro's, and schematics), especially at higher levels.  i much
prefer the schematic "roadmap" then structural vhdl, which does not show the
flow of data or timing for pipelined designs at all.

of course, some products in the marketplace do not support schematics!  an
example is, er, gatefield (friendly elbow to the ribs).  i called them up [well,
actually e-mailed them] and verified what i found on their www site, HDL entry
only.  same is true for the cx2001 and cx3001 series from chipx and we recently
had a nice, long, heated thread about the xilinx virtex situation.

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

well, i guess time to get a little work done,

rk

Article: 13838
Subject: Re: 22V10 Metastability - help please
From: bob@nospam.thanks (Bob Perlman)
Date: Tue, 29 Dec 1998 17:07:20 GMT
Links: << >>  << T >>  << A >>
Peter - 

On Tue, 29 Dec 1998 15:06:40 GMT, z80@ds2.com (Peter) wrote:

> (I wrote:)
>>22V10s and most other
>>PLDs are based on AND/OR planes, which are bound to be glitchy if the
>>designer hasn't (a) added product terms to mask the effects of
>>transition or (b) synchronized asynchronous inputs.
>
>I do not agree with this. 
>
>Let's say you are using a 22V10 as a simple decoder. If what you say
>is true, it would be virtually impossible to make a decoder which does
>not generate a glitch before settling down.
>
>No, a GAL "must" be designed so that the skew between the true and
>complement versions of an input, plus any other skews generated by the
>layout of the product matrix, is **less than** the switching time of
>the gate implementing the product matrix.

Sorry to say, they generally aren't designed to be glitchless.  Nor do
they have to be.   An address decoder *will* glitch, unless you do
something to keep it from glitching, like disabling a common decode
enable until the decode input lines settle (and it helps to have some
idea of how the common enable is implemented, to ensure it really is
gating off the outputs glitchlessly).

The way I deal with these glitches is to make them a don't-care by
doing synchronous design.  For example, if I use address decodes to
drive the (synchronous) clock enables of flip-flops, the glitch is a
don't-care as long as I meet the setup and hold times of the clock
enable.

This is an old, old problem, by the way.  Many of us old, old
engineers first encountered it when we watched someone try to use the
combinatorial terminal count output of a 74161 binary counter to clock
a flip-flop.  These terminal counts ORed the outputs of the four
synchronous counter bits (and a count enable input, too, if I remember
correctly).   Some of them would output narrow glitches at various
count transitions, such as 0111->1000.  I remember one designer
commenting that, although he knew his design was malfunctioning, he
couldn't see glitches on the terminal count when he put a scope probe
on it.  I commented that the design was probably OK as long as he
shipped it with the scope probe attached (probes were more capacitve
in those days, and I was more sarcastic).

Regards,
Bob Perlman
Cambrian Design Works 

Article: 13839
Subject: Re: 22V10 Metastability - help please
From: rk <stellare@NOSPAMerols.com>
Date: Tue, 29 Dec 1998 12:49:32 -0500
Links: << >>  << T >>  << A >>
Bob Perlman wrote:

> This is an old, old problem, by the way.  Many of us old, old
> engineers first encountered it when we watched someone try to use the
> combinatorial terminal count output of a 74161 binary counter to clock
> a flip-flop.  These terminal counts ORed the outputs of the four
> synchronous counter bits (and a count enable input, too, if I remember
> correctly).

for this series the RCO was ANDed with the ENT input and not the ENP.
didn't even have to look it up.  guess that makes me a geezer.  some of the
other TTL counters were a bit friendlier with their RCO, but not the
160-163 series.

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

rk

Article: 13840
Subject: Re: 22V10 Metastability - help please
From: rk <stellare@NOSPAMerols.com>
Date: Tue, 29 Dec 1998 12:50:11 -0500
Links: << >>  << T >>  << A >>
Peter wrote:

     < snip bunch of stuff on PAL internals >

> Without withing to make this thread even longer, and despite what has
> been said here, I cannot see the problem in *sampling* a *single*
> async input, with a *Gray-code* state machine. In such a state
> machine, only *one* D-type at any one time can potentially act on that
> input, so either a) the input change is just sampled (and you go to
> the next state) or b) the input change is just missed (and you remain
> in the present state).

i agree, 100%, there is no problem, that's why the gray code is popular.
the gray code can be generated by a mechanical device, or perhaps an
electro-mechanical one for things like shaft encoders, or the gray code
can be generated electronically.  for the latter, i typically have an
asynchronous input clock a gray code counter, which i can sample whenever
i feel like it, and never have an error more than one count.  in the
original topology, the output of a register is fed back into a logic
"cloud" along with an asynchronous input.  in this case, the logic must be
designed so that only 1 output can change at a time, which implies that
there are no static hazards, or this can be violated.

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

> The only risk (which truly cannot be avoided) is with *metastability*,
> and that comes down purely to whether the D-type settles down before
> the next clock comes along.

the failure rate is calculated and can be made small enough to be
negligible for most applications.

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

rk


Article: 13841
Subject: Re: 22V10 Metastability - help please
From: rk <stellare@NOSPAMerols.com>
Date: Tue, 29 Dec 1998 13:12:55 -0500
Links: << >>  << T >>  << A >>

--------------65EA94FA3AA6AE7F15D8131E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

ems@riverside-machines.com.NOSPAM wrote:

> Here's another 2 centi-euros(?) worth. At the risk of annoying a lot
> of people, there seem to be a number of red herrings here (doubtless
> I'll be severely kicked if I've misunderstood):
>
> 1) Static hazards. This is irrelevant, since we're talking about a
> synchro: it doesn't matter whether the output settles to 1 or 0, and
> so it doesn't matter whether there are any glitches on the
> combinatorial logic feeding the synchro f/f, or when these glitches
> are sampled.

sorry. <rk puts on his boots> it does matter that the combinational logic
glitches. if the output of the combinational circuit is supposed to be:

         Input   Y2   Y1   Y0
           0      1    0    0
           1      1    0    1

but there is a glitch or a static hazard, you can get:

         Input   Y2   Y1   Y0
           0      1    0    0
           1      0    0    1  <- an "oh, sh*t" state
           1      1    0    1

and you are unfortunate that your slow and easy 1 MHz clock edge samples
on the "OS" state, you will have a bad transition.

now, in the first case, suppose the 1 MHz edge arrives as Y0 is changing.
this can cause the f-f that samples it, Q0, to "go metastable" for a
certain amount of time.  the design needs to take this into account and
let the flip-flop settle (to whatever level or reliability is desired)
before sampling its output.

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

> 2) differential delays on a signal and its inverse in an AND-OR array:
> doesn't matter, for exactly the same reason.

i agree with this, provided the logic block doesn't have any glitches in
it, and provided that the sampling isn't ridiculously fast.

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

> 3) Metastability: not, per se, a problem.

as long as a reasonable amout of settling time is given.  with modern
high-speed flip-flops, this time is getting to be quite small.

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

> There's no problem incorporating a synchro into a state machine, as
> long as you can guarantee that only one register bit samples the
> asynchronous signal (pretty much what Peter Alfke (among others?)
> said, although in passing).

exactly, but in the original problem, it appeared that one input to the
logic block made perhaps two inputs to the register change.

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

>                                                In this case, both EQ2
> and EQ0 sample
> ENC_IN. This will eventually fail since EQ2 and EQ0 will occasionally
> disagree on the value of ENC_IN. You don't need a Gray-coded machine -
> you just have to make sure that only one f/f samples the input. The
> only way that this can fail is if the f/fs output still hasn't
> stabilised after one cycle, which is astronomically unlikely in this
> case.

agreed, and a f-f synchronizing the asynchronous input before it enters
the logic block would do the trick.  [i think i understood all of what you
wrote, if not, then my fault, scrolling back through these messages gets a
tad confusing].  but without the synchronizer on the asycn input, a gray
code output from the logic block is needed.  if the logic block glitches,
it's not gray code, be definition.

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

> In this case, to explain the 100 -> 101 -> 001 sequence you may have
> to invoke a hazard, or whatever (I can't explain it just by assuming
> that EQ2 and EQ0 have sampled different values), but I find it hard to
> believe that you could eventually make this machine work by removing
> all hazards - you'll still have two registers sampling ENC_IN.

again, trying to put multiple posts together, even if all of the outputs
of the logic block are a function of the asynchronous input, as long as
the unchanging outputs don't glitch (i.e., no static hazard), the machine
will work fine and the output of the logic block will be a gray code.  one
way to do that is to have the asynch input clock a gray coded state
machine.  not practical here, since the 22v10 doesn't have enough f-f's.
but you can eliminate static hazards and get the same effect.  the classic
example is the 2:1 mux.  if both inputs to the mux are a '1', then when
the select changes from a '1' to a '0', then it is possible that both
product terms will be off.  by adding in the extra term, the product of
the two inputs, you can be assured that the function will not glitch.  the
best explanation of this that i have seen is in DIGITAL CIRCUITS by
chirlian, 1976.  i think the new horowitz and hill has a good explanation
too, but the commander in chief stole it.  or, as peter a. explained,
sneak in some extra memory - xilinx and quicklogic do this by relying on
capacitance, which serves as a latch, one that will be stable for a short
period of time only, but enough time to get the job done.

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

just my $0.02 [don't know what a euro is worth],

rk

--------------65EA94FA3AA6AE7F15D8131E
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<HTML>
ems@riverside-machines.com.NOSPAM wrote:
<BLOCKQUOTE TYPE=CITE>Here's another 2 centi-euros(?) worth. At the risk
of annoying a lot
<BR>of people, there seem to be a number of red herrings here (doubtless
<BR>I'll be severely kicked if I've misunderstood):

<P>1) Static hazards. This is irrelevant, since we're talking about a
<BR>synchro: it doesn't matter whether the output settles to 1 or 0, and
<BR>so it doesn't matter whether there are any glitches on the
<BR>combinatorial logic feeding the synchro f/f, or when these glitches
<BR>are sampled.</BLOCKQUOTE>
<TT>sorry. &lt;rk puts on his boots> it does matter that the combinational
logic glitches. if the output of the combinational circuit is supposed
to be:</TT><TT></TT>

<P><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Input&nbsp;&nbsp;
Y2&nbsp;&nbsp; Y1&nbsp;&nbsp; Y0</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
1&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 0</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
1&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 1</TT><TT></TT>

<P><TT>but there is a glitch or a static hazard, you can get:</TT><TT></TT>

<P><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Input&nbsp;&nbsp;
Y2&nbsp;&nbsp; Y1&nbsp;&nbsp; Y0</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
1&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 0</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
0&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 1&nbsp; &lt;- an "oh, sh*t" state</TT>
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
1&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp; 1</TT><TT></TT>

<P><TT>and you are unfortunate that your slow and easy 1 MHz clock edge
samples on the "OS" state, you will have a bad transition.</TT><TT></TT>

<P><TT>now, in the first case, suppose the 1 MHz edge arrives as Y0 is
changing.&nbsp; this can cause the f-f that samples it, Q0, to "go metastable"
for a certain amount of time.&nbsp; the design needs to take this into
account and let the flip-flop settle (to whatever level or reliability
is desired) before sampling its output.</TT><TT></TT>

<P><TT>=================================================================</TT>
<BLOCKQUOTE TYPE=CITE>2) differential delays on a signal and its inverse
in an AND-OR array:
<BR>doesn't matter, for exactly the same reason.</BLOCKQUOTE>
i agree with this, provided the logic block doesn't have any glitches in
it, and provided that the sampling isn't ridiculously fast.

<P>==========================================================
<BLOCKQUOTE TYPE=CITE>3) Metastability: not, per se, a problem.</BLOCKQUOTE>
as long as a reasonable amout of settling time is given.&nbsp; with modern
high-speed flip-flops, this time is getting to be quite small.

<P>===========================================================
<BLOCKQUOTE TYPE=CITE>There's no problem incorporating a synchro into a
state machine, as
<BR>long as you can guarantee that only one register bit samples the
<BR>asynchronous signal (pretty much what Peter Alfke (among others?)
<BR>said, although in passing).</BLOCKQUOTE>
exactly, but in the original problem, it appeared that one input to the
logic block made perhaps two inputs to the register change.

<P>=============================================================
<BLOCKQUOTE TYPE=CITE>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
In this case, both EQ2 and EQ0 sample
<BR>ENC_IN. This will eventually fail since EQ2 and EQ0 will occasionally
<BR>disagree on the value of ENC_IN. You don't need a Gray-coded machine
-
<BR>you just have to make sure that only one f/f samples the input. The
<BR>only way that this can fail is if the f/fs output still hasn't
<BR>stabilised after one cycle, which is astronomically unlikely in this
<BR>case.</BLOCKQUOTE>
agreed, and a f-f synchronizing the asynchronous input before it enters
the logic block would do the trick.&nbsp; [i think i understood all of
what you wrote, if not, then my fault, scrolling back through these messages
gets a tad confusing].&nbsp; but without the synchronizer on the asycn
input, a gray code output from the logic block is needed.&nbsp; if the
logic block glitches, it's not gray code, be definition.

<P>==============================================================
<BLOCKQUOTE TYPE=CITE>In this case, to explain the 100 -> 101 -> 001 sequence
you may have
<BR>to invoke a hazard, or whatever (I can't explain it just by assuming
<BR>that EQ2 and EQ0 have sampled different values), but I find it hard
to
<BR>believe that you could eventually make this machine work by removing
<BR>all hazards - you'll still have two registers sampling ENC_IN.</BLOCKQUOTE>
again, trying to put multiple posts together, even if all of the outputs
of the logic block are a function of the asynchronous input, as long as
the unchanging outputs don't glitch (i.e., no static hazard), the machine
will work fine and the output of the logic block will be a gray code.&nbsp;
one way to do that is to have the asynch input clock a gray coded state
machine.&nbsp; not practical here, since the 22v10 doesn't have enough
f-f's.&nbsp; but you can eliminate static hazards and get the same effect.&nbsp;
the classic example is the 2:1 mux.&nbsp; if both inputs to the mux are
a '1', then when the select changes from a '1' to a '0', then it is possible
that both product terms will be off.&nbsp; by adding in the extra term,
the product of the two inputs, you can be assured that the function will
not glitch.&nbsp; the best explanation of this that i have seen is in DIGITAL
CIRCUITS by chirlian, 1976.&nbsp; i think the new horowitz and hill has
a good explanation too, but the commander in chief stole it.&nbsp; or,
as peter a. explained, sneak in some extra memory - xilinx and quicklogic
do this by relying on capacitance, which serves as a latch, one that will
be stable for a short period of time only, but enough time to get the job
done.

<P>==========================================================

<P>just my $0.02 [don't know what a euro is worth],

<P>rk</HTML>

--------------65EA94FA3AA6AE7F15D8131E--

Article: 13842
Subject: Re: 22V10 Metastability - help please
From: Peter Alfke <peter@xilinx.com>
Date: Tue, 29 Dec 1998 10:20:44 -0800
Links: << >>  << T >>  << A >>
Hal Murray wrote:

> Wow!  I haven't seen anything like that from Peter Alfke before.
>
> <snip>
>
> I claim the problem isn't under control until metatstbility
> data gets published in data sheets rather than ApNotes.

There is a problem: The numbers printed in the data sheet are supposed
to be 100% production tested, or at least be derived from 100%
production testing. And that's what we do, 100% production testing at
elevated temperature and low Vcc.This is just not possible with
metastability numbers. They can only be sample-tested in a specialized
jig.

>  
>
> Note that the Xilinx ApNote that Peter referenced is over
> a year old.  What if I want to use a chip released since then?

Anything we have designed and introduced recently is just plain better,
i.e. it resolves the metastable situation even faster. I did not publish
recent results because they were so much better than the previous ones
that I started to doubt their ( and my ) sanity.

>  
>
> What was the temp and Vcc during those tests?  Can I assume it
> is worst case?

No. But that's a suggestion for the next series of test.

Before I get accused of ignorance let me "make one point perfectly
clear":

Metastability is a nasty problem because it can cause a normally
well-behaved synchronous flip-flop to change  state at a completely
uncontrolled moment. That's ugly.

Modern CMOS flip-flops, however, have such a high gain-bandwidth product
in their feedback path that they recover extremely fast, usually in a
matter of fractional or a few nanoseconds.

The XC4005E-3 CLB flip-flop of 2 years ago, when synchronizing a 1 MHz
asynchr. event with a 10 MHz clock, would stay metastable for 2 ns once
in a million years.
At 20 MHz and a 50 MHz clock, those 2 ns would statistically occur once
per 10,000 years.
And the newer devices are much better.

That's what I meant when calling metastability an overrated problem. It
will never be eliminated, but progress in IC processing has dramatically
reduced its significance.
The XC3042-70 of 1988 would have the unpredictable 2 ns delay not once
per million years, but once every second !  That means, the frequency of
occurence ( for given clock rates and delays ) has been reduced by 14
decimal orders of magnitude, more than one order of magnitude every 
year, while average digital system speed has only been doubling every
four-to-five years.
I would call that progress.

Peter Alfke, Xilinx Applications 

Article: 13843
Subject: Re: 22V10 Metastability - help please
From: Magnus Homann <d0asta@mis.dtek.chalmers.se>
Date: 29 Dec 1998 20:45:32 +0100
Links: << >>  << T >>  << A >>
rk <stellare@NOSPAMerols.com> writes:
> Peter wrote:
> 
>      < snip bunch of stuff on PAL internals >
> 
> > Without withing to make this thread even longer, and despite what has
> > been said here, I cannot see the problem in *sampling* a *single*
> > async input, with a *Gray-code* state machine. In such a state
> > machine, only *one* D-type at any one time can potentially act on that
> > input, so either a) the input change is just sampled (and you go to
> > the next state) or b) the input change is just missed (and you remain
> > in the present state).
> 
> i agree, 100%, there is no problem, that's why the gray code is popular.

I disagree. In fact, here's an example.

Consider a SM where from state "00" you go to "01" on IN = '1' or to
"10" on IN = '0'. If the signals change within, say, x ps skew,
there's still a chance to get to state "11". I don't think you can
design a PAL to reliably handle this situation. Non-glitching LUTs
wont help you either.

It's a bit forced example, but not entirely unlikely to happen.

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: 13844
Subject: Glitchless Logic, hazards, and Metastability - Was Re: 22V10 Metastability - help please
From: "Bruce Nepple" <brucen@imagenation.extra.com>
Date: Tue, 29 Dec 1998 12:00:07 -0800
Links: << >>  << T >>  << A >>

Couldn't resist the chance to rename this thread, and put in my 2 cents
along with all of the illustrious respondents.  We have a long ways to go to
be the longest thread.

1. Glitchless logic - To summarize what most people are saying, even if the
logic in front of a gray coded state machine is glitchless, it can still
cause illegal transitions if more than 1 D input changes at the same time.
The logic must be designed not only glitchless, but also such that only 1 D
input can change at one time.  That's been covered very well, and was
enlightening to me.

2.  Metastability - seems not to be the problem here, and can burn you if
you do stupid things, such as use the output of a synchronizer to drive a
clock input, or depend on 2 synchronizers to make the same decision.

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.

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.

Runt Pulse:

Take the same cross coupled latch and start with a stable initial condition,
both inputs high and the top gate with its output low.  Apply a low going
pulse that is less than the prop delay to the top gate.  You now have
another oscillator.

Now, as a mental exercise, notice what happens in the race example if the
prop delays are not balanced, or in either example if there are imbalanced
finite rise and fall times.

Either of these conditions occurring inside a synchronizer will cause
strange results.  I'm not saying that these are the *only* conditions that
occur, but they are two fine examples of how unpredictable behavior can
occur when setup and/or hold times are violated, and illustrate how
metastable effects can be of infinite duration.

Bruce






Article: 13845
Subject: Re: 22V10 Metastability - help please
From: Peter Alfke <peter@xilinx.com>
Date: Tue, 29 Dec 1998 12:35:23 -0800
Links: << >>  << T >>  << A >>
Magnus Homann wrote:

> ....In fact, here's an example.
>
> Consider a SM where from state "00" you go to "01" on IN = '1' or to
> "10" on IN = '0'. If the signals change within, say, x ps skew,
> there's still a chance to get to state "11". I don't think you can
> design a PAL to reliably handle this situation. Non-glitching LUTs
> wont help you either.
>  

That's exactly what I tried to explain earlier.
Thanks, Magnus, for the simple example.

Grey code doesn't help, neither does the non-glitching LUT. It is more
fundamental:
NEVER synchronize an asynchronous control input in more than a single
flip-flop.

All the other dozen responses make for interesting reading, but I am
pretty sure that this example here explains the real root cause.

Peter Alfke, Xilinx Applications
 
 

Article: 13846
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10 Metastability - help please
From: Peter Alfke <peter@xilinx.com>
Date: Tue, 29 Dec 1998 12:50:51 -0800
Links: << >>  << T >>  << A >>
Bruce Nepple wrote:

> snip

> 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.
>
> 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 !

>  
>
> Runt Pulse:
>
> Take the same cross coupled latch and start with a stable initial
> condition,
> both inputs high and the top gate with its output low.  Apply a low
> going
> pulse that is less than the prop delay to the top gate.  You now have
> another oscillator.

No way again.

>  
>
> Now, as a mental exercise, notice what happens in the race example if
> the
> prop delays are not balanced, or in either example if there are
> imbalanced
> finite rise and fall times.
>
> Either of these conditions occurring inside a synchronizer will cause
> strange results.  I'm not saying that these are the *only* conditions
> that
> occur, but they are two fine examples of how unpredictable behavior
> can
> occur when setup and/or hold times are violated, and illustrate how
> metastable effects can be of infinite duration.

"Infinite duration". You mean a continuously running oscillator?Please,
this is engineering, not speculation. Go to the lab.Try it out, and you
will see that your explanation is completely wrong.
Two cross-coupled NAND gates will never oscillate.

Many of us understand metastability fairly well.
Let's not confuse the issue with bogus theories.

Peter Alfke, Xilinx Applications

>  

  

Article: 13847
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10 Metastability - help please
From: tomb@lsid.hp.com (Tom Bruhns)
Date: 29 Dec 1998 21:45:28 GMT
Links: << >>  << T >>  << A >>

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: 13848
Subject: Re: about using Mentor and Foudation together
From: s_clubb@NOSPAMnetcomuk.co.uk (Stuart Clubb)
Date: Tue, 29 Dec 1998 21:49:25 GMT
Links: << >>  << T >>  << A >>
On Thu, 24 Dec 1998 13:28:46 -0800, "George" <gazhao@ece.ucsd.edu>
wrote:

>Hi, Can anyone help me to solve this problems?
>I start to use xilinx and VHDL now, but my xilinx foundation basic software
>donot support
>VHDL synthesis, what a pity.
>Now I am thinking of using mentor leonardo to synthesis it, and function
>simulate it, and then generate EDIF file. Export it to xilinx foundation,
>and then do programming and timing verify.
>But, how to do timing verify just with a EDIF file?
>And, can I do the whole thing with mentor? with timing simulation and back
>annotation?

The third party flow is well defined for many vendors, not just Mentor
(MGC).

1 - Design Entry
	Text Editor + Renoir (MGC)
2 - Verification / Simulation
	ModelSim (MGC)
3 - Synthesis
	Leonardo Spectrum (MGC)
4 - FPGA P&R and static timing
	Alliance Series from Xilinx (and Spectrum)
5 - Post P&R Simulation
	ModelSim (MGC)

All you need is the place and route side of the Xilinx tools. This can
then produce an EDIF netlist, VHDL (or Verilog) netlist and an SDF.
The EDIF & SDF can go back into Spectrum for additional static timing
analysis, while the VHDL and SDF are used in ModelSim for timing
simulation. The Xilinx "trace" tool will do your static timing fine as
part of the flow.

Happy New Year.
Stuart
An employee of Saros Technology, The HDL Solutions Company:
Renoir
Model Technology
Exemplar Logic
TransEDA
www.saros.co.uk
(I sell these products, so paint me biased)

Article: 13849
Subject: Re: Aldec integration
From: s_clubb@NOSPAMnetcomuk.co.uk (Stuart Clubb)
Date: Tue, 29 Dec 1998 21:49:26 GMT
Links: << >>  << T >>  << A >>
On Fri, 25 Dec 1998 19:23:18 +0200, "Ido Kleinman"
<kleinn@REMOVETHIS.mail.biu.ac.il> wrote:

>I am using Aldec Active-VHDL 3.2 and Foundation M1.4 (haven't upgraded yet).

My sympathies :-)

>I need to know how to add xilinx libraries to Active-VHDL so I will be able
>to instanciate and simulate components such as TBUFs, IBUFs, BUFGs and so
>on.
>Foundation Library file-type isn't compatible to Aldec's.

You should just need the Vital libraries and map them to the various
libraries appropriately. Look in the VHDL directory of your Xilinx
installation and check xilinx www for the right way specifically for
Aldec.

>Also I want to be able to export my design from Active-VHDL to Foundation
>implementation and get it back for timing-simulation into Active-VHDL - I
>know it's possible and I saw the tutorial in Aldec's Site but it wasn't
>helpful since it referenced me to non-existant files.

Select the appropriate back-annotation for writing VHDL and SDF from
the Design Manager, and then just compile the time_sim.vhd output like
it was regular VHDL (it's just a structural netlist). Then you should
just simulate, applying the sdf to the appropriate unit under test.

This is what I do for ModelSim, and I'm sure that Aldec is fairly
similar.

Cheers
Stuart

An employee of Saros Technology, The HDL Solutions Company:
Renoir
Model Technology
Exemplar Logic
TransEDA
www.saros.co.uk
(I sell these products, so paint me biased)



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