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 60000

Article: 60000
Subject: Re: Thinking out loud about metastability
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Wed, 3 Sep 2003 13:48:28 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <3F559A3F.91184B1A@yahoo.com>,
rickman  <spamgoeshere4@yahoo.com> wrote:
>
>There is no way to determine when a circuit is metastable or not.  Async
>circuits are not magic, they just depend on predictable delays, just
>like any other circuit.  The design is different because there is no
>common clock so each circuit can run with its own delay.  Since the next
>circuit will take the output when it is ready, there is no problem with
>synchronization.  

Silly question: I don't see why an ANALOG flip-flop couldn't determine
that it is in the intermediate state at some fixed interval after the
clock, and then force the flop one way or another.  Of course, it
might double-glitch in the meantime (flop goes up before logic forces
it down), but it would make a flop with a fixed-maximum metastabel
interval.

Of course, it seems like such a massive headache to do.

>One problem I do see is that if each stage has a different delay, then
>it can not accept a new input from the preceding stage until the output
>has been taken by the following stage.  It seems in the end the async
>circuit will run no faster than the slowest stage, which is what the
>sync clocked circuit will do.  

The trick with asynchronous logic is that the longest stage WHICH IS
IN THE COMPUTATION is the critical path.  EG, if 9 of the stages take
1 ns, and the last takes 2ns, but the last only affects 1/2 the data,
with the asynchronous circuitry doing the shortcutting, it will be
considerably faster than the synchronous one.

The problem is: You can automatically balance the pipelining
(retiming) for a synchronous circuit, while asynchronous really playes
havoc with the CAD flow and testing.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 60001
Subject: Re: HDL Designer from Mentor
From: "Kleven Bingham" <noone@nowhere.no>
Date: Wed, 03 Sep 2003 13:51:04 GMT
Links: << >>  << T >>  << A >>
Hi Jonathan -

I've evaluated Aldec and used ModelSim, HDL Designer, and Cadence NC-Sim
quite a bit over the last 5 years.  Several of the engineers that I've
worked with over that time tend to agree with the opinion that I've
developed about Aldec and ModelSim/HDL Designer, but that's still just my
humble opinion along with a just a few other guys - everyone has their own
take.

Our general conclusion was that Aldec is an excellent tool for small
projects, engineers new to combined HDL/Schematic Capture/Simulation
environments, and extremely cash-strapped organizations.  As you move into
larger projects with an engineering team of up to 5 or 6 engineers, HDL
Designer really starts to provide some benefits over Aldec that start to
justify the price tag.  (Can you tell yet that I think the Mentor tools are
over priced?)

Most folks that I have talked to that have used HDL designer focus on just a
few features - block diagram editing and creation either by schematic
capture or existing HDL import, integrated version management, push-button
simulation or synthesis flow (simulation is much more 'push-button' than
synthesis, for many reasons) and flexibility.  By flexibility, I mean that
you can use just about any text editor you like, and now they have added
additional 'modes' of support for text file based code so you can now have a
text file that the tool itself never modifies.  And also, the PERL plug-in
interface that runs downstream flows (simulation, synthesis, or whatever you
want to create).  Personally, I really like the PERL plug in environment
because if there are bugs (and there have been) I can fix them myself and
not have to wait for a new release.  I can also modify a downstream
interface to better suit the needs of my design environment.

HDL Designer does not have a very steep learning curve for the basic
features.  The advanced features, however, do require some time.  It takes a
while to figure out the details of the PERL downstream interface - it is
relatively complex under the hood.

Also remember that the HTML documentation feature is only available in the
full-up version and in HDL Detective, which allows full text to graphics
import but no graphical editing.  There used to be more options in the
features that you got, but now they have 'simplified' it - meaning they all
cost more. ;-)  As the tool is offered now, the only truly beneficial
combination of features for a design team are found in the full version,
IMHO.

As always though, your mileage may vary.  You might find that Aldec is just
what you want and HDL Designer annoys you to no end.  That's why I strongly
advise anyone to EVALUATE - and try to stretch that evaluation as long as
you can, because you may find a showstopper issue.  The vendors may whine a
bit, but usually will give you a fairly long string of evaluation licenses
if you really need to continue your testing of the tools.

Best of luck!

Kleven

"Jonathan Bromley" <jonathan.bromley@doulos.com> wrote in message
news:biv4fl$17e$1$8300dec7@news.demon.co.uk...
> "Paul Baxter" <pauljnospambaxter@hotnospammail.com> wrote in
> message news:3f524aa7$0$254$cc9e4d1f@news.dial.pipex.com...
>
> > At the risk of starting a toolset discussion, I would recommend
> > www.aldec.com and their ActiveHDL product.
> >
> > Its mainly a very user friendly simulator (still not perfect, but a lot
> > friendlier than Modelsim
>
> Can you explain a bit more please?  I've heard many people say that
> Aldec is more "user-friendly", but personally (strictly personally!)
> I've always found its project system and its obsessive copying of
> files from place to place to be thoroughly confusing.  It makes
> life very easy for you if you have just an HDL design and a
> single testbench file and no other tools interested in those
> source files, but as soon as I try to do anything more complicated
> I get hopelessly mired in its bizarre project system.  (By the
> way, I always detested the Aldec project machine in the older
> Xilinx tools!).
>
> Once again, for emphasis:  this is my personal opinion only;
> we're happy to support any simulators for our training
> courses and other work; and my experience with Aldec
> is fairly limited, whereas I use ModelSim for the majority
> of my day-to-day HDL work.  So I'd be delighted to hear from
> any Aldec champions out there.
> --
>
> Jonathan Bromley, Consultant
>
> DOULOS - Developing Design Know-how
> VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services
>
> Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW,
UK
> Tel: +44 (0)1425 471223                    mail:
jonathan.bromley@doulos.com
> Fax: +44 (0)1425 471573                           Web:
http://www.doulos.com
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.
>
>
>



Article: 60002
Subject: Re: Moving Sum
From: "Christos" <chris_saturnNOSPAM@hotmail.com>
Date: Wed, 3 Sep 2003 16:03:28 +0200
Links: << >>  << T >>  << A >>

"Tom Seim" <soar2morrow@yahoo.com> wrote in message
news:6c71b322.0309021211.522fed48@posting.google.com...
> > The processes that will go up to 100s will take an average of 8 values
and
> > store that value to the external memory. In that way the data are
minimised
> > by a factor of 8 and the system error is negligible.
> > The SRAM that was found can be used in the architecture of 1M x 72bit,
so 8
> > accesses in parallel times two in 40 us seems to be more than ok
> > One problem now is how to implement this! my experience do go that far!
> > You've said something about instantiating a processor (I guess something
> > like NIOS), are you sure that this will not complicate things more?
> > Is there something ready to implement a circular buffer to the external
ram?
> >
> > The second problem, and the reason why I asked for help in this group,
is
> > that those SRAMS are quite expensive and having in mind that 2000 of
them
> > will be needed, it increases the cost significantly. So they are
pressing me
> > to find some other way to implement it. (usual stuff: we want the pie
and
> > the dog fed!)
>
> I don't understand why you need 2000 SRAMs.
>
> 25 KHz x 16 x 100 = 40 MB
>
> or 8 SRAMs.

In the first paragraph I explain that saving the average values of 8 samples
the data are minimised by a factor of 8. So 5 MB have to be stored for this
system (up to 100s) which fit together with the data of the first system (up
to 10ms) in one SRAM. On the card there are 2 more to hold other data. And
650 of these cards are needed, that gives ~2000 SRAMs.

Sorry for not been that clear but the mail was already too long and I didn't
want to kill you with
boredom completely!

Christos



Article: 60003
Subject: Re: Compact FIR filters with multiplier blocks?
From: "Ken" <aeu96186_MENOWANTSPAM@yahoo.co.uk>
Date: Wed, 3 Sep 2003 15:14:22 +0100
Links: << >>  << T >>  << A >>
Ray,

Thanks for your quick response.

You raise some excellent points clearly derived from experience.

Hopefully my program will still be useful when filters can be fixed early on
in the project or when a synthesis/place and route run is an acceptable cost
for the area efficiency provided.

Also, for devices being used in consumer applications, perhaps the area
saved using a multiplier block filter would allow a smaller and cheaper
device within the family to be used - reducing production costs depending on
the number of units being produced.

Cheers,

Ken



"Ray Andraka" <ray@andraka.com> wrote in message
news:3F55E8A3.70936FBD@andraka.com...
> I agree the multiplier block style filters are more efficient area-wise.
It
> sounds like you have addressed the irregularity issues by using a program
> to do the generation, which I think is pretty much a necessity.  As I
thought
> I alluded to, the biggest problem with multiplier block filters is that
the
> layout/size is not a constant if you change the coefficients.  This means
that
> the fiter coefficients have to be constant and known earlier in the design
> cycle, and necessitates a rerun of synthesis, place and route for any
filter
> changes.  Depending on the implementation, it may also mean a change in
the
> filter's pipeline latency.  These factors can make them difficult to use
on
> some projects.  The filters typically used in my projects often need to be
> adjusted by the customer or late in the project to accommodate minor
> requirements changes.  I prefer to use a filter with reloadable
coefficients
> for that reason.
>
>
>
> Ken wrote:
>
> > Ray,
> >
> > I sent this to Michael via email and he suggested the group would be
> > interested also...
> >
> > My PhD (now drawing to the end) has been on implementing full-parallel
> > Transpose FIR filters using multiplier blocks that you mention (I use
> > techniques/algorithms that exceed the efficiency of CSD in terms of FPGA
> > area).
> >
> > The upshot of my work is that I have written a C++ program that will
> > generate RTL VHDL given the quantised filter coefficients, the type of
> > filter required (singlerate, interpolation, decimation etc.) and the
> > appropriate parameters (input width, signed/unsigned input, number of
> > channels, rate-change factor etc.)
> >
> > The VHDL my program generates exceeds the functionality (at a lower
> > cost) of that provided by Xilinx's Distributed Arithmetic core and
Altera's
> > FIR Compiler (also DA).  In fact, my program allows interpolation and
> > decimation factors up to the number of filter coefficients and any
number of
> > data channels (for interpolation/decimation filters also).
> >
> > The main point is that, once synthesised and mapped to a specific FPGA,
the
> > filters my program generates require far less FPGA area (slices/logic
cells)
> > than those generated using Distributed Arithmetic.  The critical path in
my
> > filters is just the longest adder carry chain so very high speeds are
> > possible.  E.g. 154MHz for a singlerate filter (25 bit output) in a
Xilinx
> > xc2v3000-fg676-5 - obviously the speed will depend on the device
> > family/speed grade and the longest carry chain.  The facility for
multiple
> > channels in interpolation/decimation filters (not supported by Xilinx)
> > allows lower than full-parallel sampling rates to be efficiently
processed
> > in one filter.
> >
> > As Michael points out in his post, this technique would be very suitable
for
> > a
> > Xilinx Spartan-IIE and indeed any FPGA - there are many cases where
these
> > filters would be useful even on devices with dedicated multipliers (when
> > they are all in use for example!  ;-)   ).
> >
> > You can find out more at http://www.dspec.org/rsg.asp - there are also
> > datasheets here that provide comparisons with Xilinx and Altera and
> > demonstrate the output of another application (written in java) that
> > generates schematic representations of the filters for use in reports,
> > meetings and thesises!  :-)
> >
> > I hope this information is of use to you - please contact me if you have
any
> > questions,
> >
> > Thanks for your time,
> >
> > Ken
> >
> > --
> > To reply by email, please remove the _MENOWANTSPAM from my email
address.
> >
> > "Ray Andraka" <ray@andraka.com> wrote in message
> > news:3F54F936.5E694FD1@andraka.com...
> > > The problem with the multiplier block approach is that the
> > > construction is predicated on the specific coefficients.  As
> > > a result it is considerably harder to use for an arbitrary
> > > set of coefficients.  It may reduce area over a straight FIR
> > > filter running at the same clocks per sample, but at a
> > > considerable cost in design time and flexibility.  You also
> > > give up regularity in the structure, which may reduce the
> > > overall performance.   Essentially what the block multiplier
> > > and distributed arithmetic approaches are is a rearrangement
> > > of the bitwise product terms.  The mutliplier block takes
> > > advantage of duplicate terms by adding the inputs before
> > > they are multiplied by the term.
> > >
> > > Michael Spencer wrote:
> > >
> > > > Hello,
> > > >
> > > > Has anyone compared FPGA implementations of full-rate
> > > > digital FIR filters based on the use of Multiplier Blocks
> > > > vs. traditional FIRs with constant coefficient
> > > > multipliers? By full rate, I mean: one output result per
> > > > clock cycle and no interpolation or decimation.
> > > >
> > > > For anyone not familiar, a multiplier block is a network
> > > > of shifters and adders that performs multiplications by
> > > > several coefficients efficiently by exploiting common
> > > > sub-expressions. The multiplier block can be exploited in
> > > > FIR filters by transposing the standard filter so that the
> > > > products of all the coefficients with the current
> > > > input-sample are required simultaneously.
> > > >
> > > > Also, by representing the coefficients in the
> > > > Canonical-Signed-Digit number system (a small number of
> > > > +1 and -1's) along common sub-expression sharing the
> > > > multiplier block can get even smaller.
> > > >
> > > > For example, the multiplier block for a 100 tap FIR filter
> > > > (fp=0.10 and fs=0.12) can be realized with only 61 adds
> > > > (zero explicit multiplications). See filter example #4 in
> > > > "FIR Filter Synthesis Algorithms for Minimizing the Delay
> > > > and the Number of Adders,"
> > > > http://ics.kaist.ac.kr/~dk/papers/TCAD2001.pdf
> > > > If the adder depth is constrained to a maximum of four,
> > > > then the authors' algorithm can do the multiplier block in
> > > > 69 additions.
> > > >
> > > > It would seem that this approach would be very efficient
> > > > in a target such as the Xilinx Spartan-IIE (with no
> > > > dedicated multipliers).
> > > >
> > > > Another question: If we only need one result per K clock
> > > > periods (K ~= 1000 for audio applications), could a
> > > > multiplier block approach realized with, say, bit-serial
> > > > addition be more efficient than some other approach such
> > > > as distributed arithmetic?
> > > >
> > > > Comments welcome. Thanks.
> > > >
> > > > -Michael
> > > > ______________________
> > > > Michael E. Spencer, Ph.D.
> > > > President
> > > > Signal Processing Solutions, Inc.
> > > > Web: http://www.spsolutions.com
> > >
> > > --
> > > --Ray Andraka, P.E.
> > > President, the Andraka Consulting Group, Inc.
> > > 401/884-7930     Fax 401/884-7950
> > > email ray@andraka.com
> > > http://www.andraka.com
> > >
> > >  "They that give up essential liberty to obtain a little
> > >   temporary safety deserve neither liberty nor safety."
> > >                                           -Benjamin
> > > Franklin, 1759
> > >
> > >
>
> --
> --Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com
>
>  "They that give up essential liberty to obtain a little
>   temporary safety deserve neither liberty nor safety."
>                                           -Benjamin Franklin, 1759
>
>



Article: 60004
Subject: Re: Measuring metastability.
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Wed, 03 Sep 2003 07:32:31 -0700
Links: << >>  << T >>  << A >>
Symon,

Agreed.  D FF is what I was assuming here, but folks do have different ways of building them, and
not all master-slave implementations are the same (in fact I have seen perhaps a dozen different
versions).

Peter will have some explaining to do when he gets back .... as the quote does sound odd.  There
is most definitely voltage levels that remain in the undecided region for various lengths of time
until the circuit resolves its state.

Austin

Symon wrote:

> Hi Austin,
>        Maybe I got the wrong end of the stick, but when Peter said:-
> "I have never seen strange levels or oscillations ( well, 25 years ago
> we had TTL oscillations). Metastability just affects the delay on the
> Q output." I thought he meant that he'd only seen metastability where
> the output from the FF was always either on or off, just that
> sometimes the transition was delayed. Philip's pictures clearly show
> 'strange levels'. This is important, I believe, when deciding what the
> effects of metastable FFs are on following circuitry. I guess we'll
> have to wait until he returns from his Portugese jaunt before we find
> out what he meant!!
>         Of course, I agree the Master/Slave thing helps. A master FF
> on its own is what I'd call a latch, the clock controlling whether
> it's transparent or not. The slave is the sameish circuit again, fed
> from the output of this, but its clock is inverted. So, I guess that
> you're saying because the master and slave are fabricated right next
> to each other, the input to the slave can be expected to transition
> faster than the input to the master which travels from further away?
> Less capacitive interconnect to drive. (BTW, I assumed throughout the
> metastability stuff we were talking about D-type FF, rather than
> latches.)
>                   thanks, Syms.
>
> Austin Lesea <Austin.Lesea@xilinx.com> wrote in message news:<3F550102.DC2B872F@xilinx.com>...
> > Symon,
> >
> > I think the sampling o-scope shots agree perfectly with what Peter said.
> > Runt pulse, and funny levels are the easiest metastable results to catch,
> > as they are just before the long unknown settling time behavior that is so
> > vexing to designers.
> >
> > It also makes a difference where you look:  a master-slave FF reduces the
> > duration of the unknown transistion over a simple FF without a slave to
> > help "sharpen up" the transistions.
> >
> > Austin
> >
> > Symon wrote:
> >
> > > Hi Philip,
> > >       Thanks for your post, those pictures were certainly very
> > > interesting! What parts did you use? I notice they seem to disagree
> > > with Peter's quote that "Metastability just affects the delay on the Q
> > > output.". I wonder, Peter, if Xilinx FFs behave differently from the
> > > ones in Philip's photos? (Other than speed, of course.) I must admit,
> > > one reason I posted was that I found hard to believe that any FF
> > > wouldn't show runt pulses, or funny output levels, albeit for brief
> > > periods of time, during metastable events.
> > >       It's also interesting that the straight shift register isn't
> > > necessarily the best way to reduce metastability effects. That was
> > > what I suspected and was another reason behind my post. I agree that
> > > the 'four paths out of phase' solution is better, and preserves the
> > > sampling resolution. Often the sampling resolution needs to be
> > > preserved, which was why I didn't present an 'enabled every third or
> > > fourth go' type circuit.
> > >       Anyway, thanks to all for their thoughts, it's an interesting
> > > topic!
> > >                    cheers, Syms.


Article: 60005
Subject: Re: Measuring metastability.
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Wed, 03 Sep 2003 07:36:27 -0700
Links: << >>  << T >>  << A >>
Rick,

I agree that the effect is the same:  you just don't know when it will
resolve, and thus the value that you "see" at the next level is basically
unknown.

It could be that Peter's point is that the next circuit in line does make a
decision, and it most certainly makes the "unknown" into a '1', or into a
'0'.  It is unlikely that the next circuit in line will propagate the same
intermediate behavior, and if it can (gain is too low), then things just get
more fuzzy until someone upstream ends up resolving the level back to a '1'
or a '0'.

Austin

rickman wrote:

> Symon wrote:
> >
> > Hi Austin,
> >        Maybe I got the wrong end of the stick, but when Peter said:-
> > "I have never seen strange levels or oscillations ( well, 25 years ago
> > we had TTL oscillations). Metastability just affects the delay on the
> > Q output." I thought he meant that he'd only seen metastability where
> > the output from the FF was always either on or off, just that
> > sometimes the transition was delayed. Philip's pictures clearly show
> > 'strange levels'. This is important, I believe, when deciding what the
> > effects of metastable FFs are on following circuitry. I guess we'll
> > have to wait until he returns from his Portugese jaunt before we find
> > out what he meant!!
>
> I think the exact behavior is largely irrelevant since a simple delay is
> just as disasterous as anything else you would encounter.  Since you
> don't know *when* the transition would happen, it could happen at the
> moment the next FF is latching the intermediate value.  That is enough
> for the next FF and all following logic to behave badly as well.
>
> --
>
> Rick "rickman" Collins
>
> rick.collins@XYarius.com
> Ignore the reply address. To email me use the above address with the XY
> removed.
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design      URL http://www.arius.com
> 4 King Ave                               301-682-7772 Voice
> Frederick, MD 21701-3110                 301-682-7666 FAX


Article: 60006
Subject: Re: Input comparator
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Wed, 03 Sep 2003 07:45:10 -0700
Links: << >>  << T >>  << A >>
Luiz,

Last things first, the LVTTL input does not use the comparator(s) (there are
three different comparators, as well as other ciruits for the various input
standards).

The comparator is designed to have a relatively high gain, so that it
switches quickly.

As I said, the offset voltage is due to the Vt mismatch on the pmos and nmos
diff pairs, and since these are built with .35u (VII) or .25u (VII Pro)
transistors, they are pretty darn fast diff-amps.  There is a classic gain
stage after the cmos diff-amp (similar to the ones in "CMOS Circuit Design,
Layout & Simulation" by Baker, Li, and Boyce).  The offset voltage is
typically less than a few 10's of mV (say 10 to 20 mV worst case).  I am sure
that if you vary the voltage difference slowly enough, you could measure the
gain of the diff-amp.  It was designed for HSTL and SSTL IO standards, which
as someone already pointed out, are pretty sloppy.  What I will point out
here, is that I am not aware of any monolithic separate comparator that is as
fast as the one that is in the input circuit.  This comparator is good for
400 Mbs+ speeds, which is a lot faster than most separate IC comparators....

Austin

Luiz Carlos wrote:

> Hi Austin.
>
> First, as Andrey pointed out, I took the wrong table.
> The best values are for GTL:
> Vout = low,  if Vin <= Vref - 0.05
> Vout = high, if Vin >= Vref + 0.05
>
> > There is some samll offset voltage from the mis-match between the
> > differential pairs (both nmos and cmos to cover the voltage range).  I
> > do not know what this offset might be, but I suspect it is less than a
> > few tens of millivolts, worst case from the transistor models.
> >
> > The comparator will switch as soon as the voltage is greater than the
> > offset (we spec 100 mV for speed reasons, not because it needs > 100 mv
> > to function).
> >
> > So with 50 mV it will switch, just more slowly than if it was 100 mV.
>
> I really would like to know what this offset is and to have a speed
> versus offset formula.
>
> But, let's suppose we didn't reach the offset value. If we range Vin
> from Vref-Voffset to Vref+Voffset, I think Vout will range from Vlow
> to Vhigh monotonically, maybe almost linearly. Am I right?
>
> Now, if we sample Vout with the input data flip-flop, FF DOUT will be
> 0 or 1 (forget about metastability for now). Can I say there is Vthr
> where: if Vout>Vthr then DOUT=1 and if Vout<Vthr then DOUT=0? What
> does happen when we feed a data flip-flop with an analog signal?
>
> I also would like to know if when we define an input as LVTTL (for
> example), the same input comparator is used (Vref connected to an
> internal reference), or if it is bypassed.
>
> Luiz Carlos


Article: 60007
Subject: Re: Input comparator
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Wed, 03 Sep 2003 07:48:15 -0700
Links: << >>  << T >>  << A >>
John,

Uh, it is an anolog comparator....just one optimized for HSTL and SSTL inputs.

Comments about noise are well put, and need to be considered if the comparator
is on the same chip, on the same board.

But to imply that we could somehow be sloppy, and design a crummy comparator is
a bit unfair, the comparator is probably much better than any single device you
could name, it is just that we did not characterize any more than we had to.

Austin

John_H wrote:

> "Luiz Carlos" <oen_br@yahoo.com.br> wrote in message
> news:8471ba54.0309020217.567a3f03@posting.google.com...
> > Peter, Austin!
> > Nobody can help me?
> >
> > Luiz Carlos
>
> Maybe they can shed some light, but using a digital circuit for analog
> functions is like trying to use a car as a tractor.  It might work but it
> sure as heck wasn't designed to plow fields - you're bound to have problems.
>
> Since digital logic has fixed thresholds and large noise margins (difference
> beteween Vih and Vil) there's no need for the designers to be detailed about
> keeping the internal noise to the sub-millivolt level when there's so much
> activity in the adjacent I/O cells or internal logic.
>
> The Vref pins on the bank are designed for I/O signalling where the
> threshold does not change so dynamically changing this value dramatically
> can have unforseen effects.
>
> LVDS signalling produces the best differential capability, allowing a
> dynamic "Vref" for your doomed analog comparator in the digital device but
> the noise margin for LVDS is still a rather large value.
>
> If you put nothing else in the FPGA, I imagine you could get good noise-free
> results with a consistent transition (though subject to an offset voltage in
> the many 10s of millivolts).  My guess is you want more than just the analog
> comparator in there.
>
> Consider using... an analog comparator!
>
> - John_H


Article: 60008
Subject: Re: Thinking out loud about metastability
From: hmurray@suespammers.org (Hal Murray)
Date: Wed, 03 Sep 2003 15:02:55 -0000
Links: << >>  << T >>  << A >>
>Silly question: I don't see why an ANALOG flip-flop couldn't determine
>that it is in the intermediate state at some fixed interval after the
>clock, and then force the flop one way or another.  Of course, it
>might double-glitch in the meantime (flop goes up before logic forces
>it down), but it would make a flop with a fixed-maximum metastabel
>interval.

DING DING DING

Nobody has been able to fix metastability yet.  If you really have
a fix, it's worth a Nobel Prize.

The usual problem with that sort of approach is that you get
a runt pulse on the fix-it signal in cases that would have worked
correctly without it.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 60009
Subject: Re: Thinking out loud about metastability
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Wed, 3 Sep 2003 15:17:12 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <vlc0kv1m4flm5f@corp.supernews.com>,
Hal Murray <hmurray@suespammers.org> wrote:
>>Silly question: I don't see why an ANALOG flip-flop couldn't determine
>>that it is in the intermediate state at some fixed interval after the
>>clock, and then force the flop one way or another.  Of course, it
>>might double-glitch in the meantime (flop goes up before logic forces
>>it down), but it would make a flop with a fixed-maximum metastabel
>>interval.
>
>DING DING DING
>
>Nobody has been able to fix metastability yet.  If you really have
>a fix, it's worth a Nobel Prize.
>
>The usual problem with that sort of approach is that you get
>a runt pulse on the fix-it signal in cases that would have worked
>correctly without it.

Yes, but the point is it would fix the maximum metastability window,
which is the key requirement, as "did the data come before or after
the clock edge" is really an irrelevant question at the metastable
capture point, you jsut want it to go to ONE or the other (not stick
around and make up its mind a half clock cycle later), and possibly to
tell you.  

This isn't FIXING metastability, this is detecting and responding to
it, changing an exponentially decaying bounds into a fixed bounds.

Of course, it seems like way too big a headache to bother with.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 60010
Subject: MICROBLAZE: user core problem
From: arkagaz@yahoo.com (arkaitz)
Date: 3 Sep 2003 08:23:34 -0700
Links: << >>  << T >>  << A >>
Hi,

I'm trying to connect a user peripheral to the Microblaze OPB bus. I
have done all as mentioned in the "User Core Template for OPB (Slave
Services Package 0) but without success.

I have added some code lines in the correponding places to match the
IPIF to my user_core.

I have routed the Bus2IP_CS, Bus2IP_WrCE and Bus2IP_RdCE to some user
leds in my development board and I haven't noticed any effect, so I
imagine that I'm not accesing to my peripheral.

I have also checked the BASEADDR and the HIGHADDR and I think they're
correct.

Here you are part of my MPD file

PARAMETER c_baseaddr     = 0xFFFFFFFF, DT = std_logic_vector, MIN_SIZE
= 0xFF
PARAMETER c_highaddr     = 0x00000000, DT = std_logic_vector
PARAMETER c_mir_baseaddr = 0xFFFFFFFF, DT = std_logic_vector, MIN_SIZE
= 0xFF
PARAMETER c_mir_highaddr = 0x00000000, DT = std_logic_vector
PARAMETER c_user_id_code = 3,          DT = integer
PARAMETER c_include_mir  = 0,          DT = integer
PARAMETER c_opb_awidth   = 32,         DT = integer
PARAMETER c_opb_dwidth   = 32,         DT = integer
PARAMETER c_family       = virtex2,    DT = string

Note that I actualize "c_baseaddr" and "c_highaddr" parameters on the
component as well as the "c_mir_baseaddr" and "c_mir_highaddr".

I'd be very grateful if someone could help me.

Thanks.

Arkaitz.

Article: 60011
Subject: Re: altera latch synthesis
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Wed, 03 Sep 2003 08:47:08 -0700
Links: << >>  << T >>  << A >>
Andrea wrote:
> I don't want to modify a complex VHDL code,

Why not?
If there isn't a functional testbench, that is your first job.

Once you have a testbench, you can easily verify your changes.

> moreover the architecture
> pipeline needs latch to work properly without loosing performances.

You can pipeline just as fast with D flops.
Use a PLL to double the clock if need be.

> What do you suggest?

Take the bull by the horns and design out the latches.

   -- Mike Treseler



Article: 60012
Subject: Re: OT: Block diagramming tools?
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Wed, 03 Sep 2003 08:56:37 -0700
Links: << >>  << T >>  << A >>
Jay wrote:
> 
> This is slightly off-topic but what do people in here use to create 
> their digital logic block diagrams?

related thread:

http://groups.google.com/groups?q=does_it_work_yet

  -- Mike Treseler


Article: 60013
Subject: Re: Selecting between two clock signals
From: "David Lamb" <gretzteam_nospam@yahoo.com>
Date: Wed, 3 Sep 2003 11:01:24 -0500
Links: << >>  << T >>  << A >>
Hi,
I used your circuit to switch between the two clocks. However, when I
synthetise in Xilinx ISE 5.2, I get the following warning:

(*) These 2 clock signal(s) are generated by combinatorial logic,
and XST is not able to identify which are the primary clock signals.
Please use the CLOCK_SIGNAL constraint to specify the clock signal(s)
generated by combinatorial logic.

I don't really understand what it means. I guess I need to tell ISE that the
output of the circuit is a clock, but I don't know how...

Thanks a lot
David

"Peter Alfke" <peter@xilinx.com> wrote in message
news:3F4E7B2D.CFBD1D0D@xilinx.com...
> Click at
> http://www.xilinx.com/xcell/xl24/xl24_20.pdf
>
> This circuit allows totally asynchronous selection between two clock
sources.
> But remember: both clock must be wiggling (however slowly). You cannot
> use this circuit to enable/disable a clock, which is actually a far
> simpler problem.
> The BUFGMUX in Virtex is not quite this clever, it has a set-up time
> requirement on the S control input.  :-(
> Glad that someone found this old tidbit useful...
> Peter Alfke
> =============================
> Marten wrote:
> >
> > "David Lamb" <gretzteam_nospam@yahoo.com> wrote in message
> > news:bilfne$sel$1@home.itg.ti.com...
> > > Hi all,
> > > I have a vhdl component with a "clock_in" input. Depending on the mode
of
> > > operation, I want to switch between two different clock signals. I
will
> > > never switch on the fly though.  Can I use a mux in front of the
clock_in
> > > input? I'm afraid it might glitch.
> > > Thanks
> > > David
> > >
> > >
> >
> > David,
> >
> > Do a query for 'clock sources' in the category 'XCELL Journals' on the
> > Xilinx web site. This will provide you with a link called 'XCELL 24 -
> > Trouble-Free Switching Between Clocks (Q1 97)', which, in turn will lead
you
> > to xl24_20.pdf, a neat little circuit that hopefully will ease your
worries
> > :)
> >
> > Keep in mind that whatever you put in the clock path will affect the
setup
> > and hold time requirements for the particular component.
> >
> > Take care,
> >
> > Marten
> >
> > ] remove the obvious to repy by e-mail [



Article: 60014
Subject: ISE 5.2 constraint file problem
From: "David Lamb" <gretzteam_nospam@yahoo.com>
Date: Wed, 3 Sep 2003 11:19:07 -0500
Links: << >>  << T >>  << A >>
Hi,
I have a vhdl project and I used a UCF file to assign the package pin to
each port in the design. This works fine. However, if I change my vhdl code
(let's say I remove an output port), I always get the following error when I
try to run the UCF editor:
ERROR:NgdBuild:756 - Line 3 in 'constraints.ucf': Could not find net(s)
   'outputA' in the design.  To suppress this error specify the correct net
   name or remove the constraint.

It seems like the UCF doesn't update itself with the new design. I tried
everything and I always have to start with a new UCF each time. The removed
port doesn't exist in the Edit constraints (TEXT) because I didn't add any
constraint to it. I really don't see how to do it.
Thanks
David



Article: 60015
Subject: Re: ISE 5.2 constraint file problem
From: "David Lamb" <gretzteam_nospam@yahoo.com>
Date: Wed, 3 Sep 2003 11:27:55 -0500
Links: << >>  << T >>  << A >>
I found a workaround. If I add a new UCF, it seems like the old one gets
updated with the new design (with missing ports). I just add a new UCF,
delete it right away, and work with the old one.
David
"David Lamb" <gretzteam_nospam@yahoo.com> wrote in message
news:bj547c$6pr$1@home.itg.ti.com...
> Hi,
> I have a vhdl project and I used a UCF file to assign the package pin to
> each port in the design. This works fine. However, if I change my vhdl
code
> (let's say I remove an output port), I always get the following error when
I
> try to run the UCF editor:
> ERROR:NgdBuild:756 - Line 3 in 'constraints.ucf': Could not find net(s)
>    'outputA' in the design.  To suppress this error specify the correct
net
>    name or remove the constraint.
>
> It seems like the UCF doesn't update itself with the new design. I tried
> everything and I always have to start with a new UCF each time. The
removed
> port doesn't exist in the Edit constraints (TEXT) because I didn't add any
> constraint to it. I really don't see how to do it.
> Thanks
> David
>
>



Article: 60016
Subject: Re: Measuring metastability.
From: symon_brewer@hotmail.com (Symon)
Date: 3 Sep 2003 09:36:06 -0700
Links: << >>  << T >>  << A >>
Hi Rick,
       Good point, the unknown delay is bad enough. Thinking about it,
I can't think of a 'sensible' digital metastability reduction circuit
and scenario which would differentiate between a simple delay, and
(say) a runt pulse. (Perhaps if the second FF was clocking faster than
the 'sample' FF? Doesn't make much sense!)
       OTOH, my concern is this. If the following FF also goes, or is
very likely to go, metastable if its D input is at a 'funny' level,
then the 'funny' level metastability is more likely to propogate than
a simple delay. This is because the simple delay has to hit a tiny
time window to propogate the metastability, whereas Philip's photo's
show the funny levels lasting a while.
          thanks, Syms.


rickman <spamgoeshere4@yahoo.com> wrote in message news:<3F55987E.ACCD59BE@yahoo.com>...
> Symon wrote:
> > 
> > Hi Austin,
> >        Maybe I got the wrong end of the stick, but when Peter said:-
> > "I have never seen strange levels or oscillations ( well, 25 years ago
> > we had TTL oscillations). Metastability just affects the delay on the
> > Q output." I thought he meant that he'd only seen metastability where
> > the output from the FF was always either on or off, just that
> > sometimes the transition was delayed. Philip's pictures clearly show
> > 'strange levels'. This is important, I believe, when deciding what the
> > effects of metastable FFs are on following circuitry. I guess we'll
> > have to wait until he returns from his Portugese jaunt before we find
> > out what he meant!!
> 
> I think the exact behavior is largely irrelevant since a simple delay is
> just as disasterous as anything else you would encounter.  Since you
> don't know *when* the transition would happen, it could happen at the
> moment the next FF is latching the intermediate value.  That is enough
> for the next FF and all following logic to behave badly as well.  
> 
> -- 
> 
> Rick "rickman" Collins
> 
> rick.collins@XYarius.com
> Ignore the reply address. To email me use the above address with the XY
> removed.
> 
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design      URL http://www.arius.com
> 4 King Ave                               301-682-7772 Voice
> Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 60017
Subject: Re: Selecting between two clock signals
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Wed, 03 Sep 2003 09:51:09 -0700
Links: << >>  << T >>  << A >>
David,

It simply means the tool is not smart enough to figure out what you are doing,
and since you have jumped off of a global clock resource, and passed through
logic on regular interconnect, skew and delay are no longer being kept track of
(it doesn't know where the clock comes from/goes to).

So, yes I think you have to tell it what is what, but since I am not a
software/synthesis guru, I can not tell you how to do that.  Perhaps someone
else can,

Austin


David Lamb wrote:

> Hi,
> I used your circuit to switch between the two clocks. However, when I
> synthetise in Xilinx ISE 5.2, I get the following warning:
>
> (*) These 2 clock signal(s) are generated by combinatorial logic,
> and XST is not able to identify which are the primary clock signals.
> Please use the CLOCK_SIGNAL constraint to specify the clock signal(s)
> generated by combinatorial logic.
>
> I don't really understand what it means. I guess I need to tell ISE that the
> output of the circuit is a clock, but I don't know how...
>
> Thanks a lot
> David
>
> "Peter Alfke" <peter@xilinx.com> wrote in message
> news:3F4E7B2D.CFBD1D0D@xilinx.com...
> > Click at
> > http://www.xilinx.com/xcell/xl24/xl24_20.pdf
> >
> > This circuit allows totally asynchronous selection between two clock
> sources.
> > But remember: both clock must be wiggling (however slowly). You cannot
> > use this circuit to enable/disable a clock, which is actually a far
> > simpler problem.
> > The BUFGMUX in Virtex is not quite this clever, it has a set-up time
> > requirement on the S control input.  :-(
> > Glad that someone found this old tidbit useful...
> > Peter Alfke
> > =============================
> > Marten wrote:
> > >
> > > "David Lamb" <gretzteam_nospam@yahoo.com> wrote in message
> > > news:bilfne$sel$1@home.itg.ti.com...
> > > > Hi all,
> > > > I have a vhdl component with a "clock_in" input. Depending on the mode
> of
> > > > operation, I want to switch between two different clock signals. I
> will
> > > > never switch on the fly though.  Can I use a mux in front of the
> clock_in
> > > > input? I'm afraid it might glitch.
> > > > Thanks
> > > > David
> > > >
> > > >
> > >
> > > David,
> > >
> > > Do a query for 'clock sources' in the category 'XCELL Journals' on the
> > > Xilinx web site. This will provide you with a link called 'XCELL 24 -
> > > Trouble-Free Switching Between Clocks (Q1 97)', which, in turn will lead
> you
> > > to xl24_20.pdf, a neat little circuit that hopefully will ease your
> worries
> > > :)
> > >
> > > Keep in mind that whatever you put in the clock path will affect the
> setup
> > > and hold time requirements for the particular component.
> > >
> > > Take care,
> > >
> > > Marten
> > >
> > > ] remove the obvious to repy by e-mail [


Article: 60018
Subject: Re: Using a different editor for ISE 5
From: Duane Clark <junkmail@junkmail.com>
Date: Wed, 03 Sep 2003 10:07:44 -0700
Links: << >>  << T >>  << A >>
Theron Hicks wrote:
> Hello,
>     Is there a way that I can (within ISE 5) use a different editor?  I want
> the editor to be integrated into the ISE system but I want to use a
> different editor.  The feature that I most want is automatic formating of
> indents, etc.  ISE does a good job, but if I screw up when I put in a new
> block of code I want to add auto-indent (like that available in Matlab).
> Folks at Xilinx.... Take this as a hint.

Why does it have to be "within ISE"? If you edit a file with an external 
editor and save it, ISE will see that it has changed and will get rid of 
all the green check marks to indicate the project has to be recompiled.

-- 
My real email is akamail.com@dclark (or something like that).


Article: 60019
Subject: Re: Measuring metastability.
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Wed, 03 Sep 2003 10:08:51 -0700
Links: << >>  << T >>  << A >>
Symon,

A long time ago, I designed a timing system for telecom that used a rubidium clock.  The
reason why this is interesting will become apparent in a moment.

One function of the system was to measure up to five external sync references (presumably
from traffic bearing lines from other offices).

The circuit to do this was basically a counter, that was sampled by a rubidium derived
clock.  All clocks were syntonous (same frequency, arbitray phase -- aka the SONET/SDH
telepone network).  As the phase wandered back and forth, the metastable regions would get
exercised, and the measurement board would report that an input signal had arbitrarily
"slipped" by some random number of bits (due to a metastable transistion of a bit in the
counter/latch).

This was so frustrating, because in real life, the inputs could slip due to failures,
glitches in the network, etc.  So how do you know a real bad slip, from a metastable one?

In the hope (vain and useless) of reducing the occurence of the metastable sample, we had
three levels of FFs to try to re-synchronize the sample count, along with an elaborate set
of clock enables.  We got it to the point where the false slip occurred about evey two
months, in a  typical network.  Since real outages were far more common, it was not a big
deal.

In spite of this, we wrote software to identify a real slip, from a false slip.  Basically,
if five successive samples were not equal (as the phase can't change that fast) we threw out
that set of measurements, and took another five.  This dropped the occurence of a false slip
to below the threshold that we could measure (but it could still happen and probably did -
still does out there somewhere).

So, metastability can sometimes be beaten into submission, but it never goes away....

The ultimate frustration is that one of these references gets used to track the rubidium
(steer it in a phase lockeed loop), so a fake glitch can cause quite a hit, which then
causes slips throughout the network as the rubidium runs off the the "wrong"
frequency/phase.  A real glitch can also cause the same behavior, so the locked loop is
quite loosely coupled, and before each update, one checks absolutely everything to be sure
that what you are trying to track is real....

I had heard there were some cases with equipment designed by others where the maintenance
folks would just disconnect the inputs, as the bare rubidium ran so clean, that it was
better to not track at all (fewer slips) than to bother with trying to track the references
and falsely running off into the weeds due to metastability and poor reference checking.

All of this became obsolete when GPS became available, as now precise time (frequency) was
broadcast for free.

Austin

Symon wrote:

> Hi Rick,
>        Good point, the unknown delay is bad enough. Thinking about it,
> I can't think of a 'sensible' digital metastability reduction circuit
> and scenario which would differentiate between a simple delay, and
> (say) a runt pulse. (Perhaps if the second FF was clocking faster than
> the 'sample' FF? Doesn't make much sense!)
>        OTOH, my concern is this. If the following FF also goes, or is
> very likely to go, metastable if its D input is at a 'funny' level,
> then the 'funny' level metastability is more likely to propogate than
> a simple delay. This is because the simple delay has to hit a tiny
> time window to propogate the metastability, whereas Philip's photo's
> show the funny levels lasting a while.
>           thanks, Syms.
>
> rickman <spamgoeshere4@yahoo.com> wrote in message news:<3F55987E.ACCD59BE@yahoo.com>...
> > Symon wrote:
> > >
> > > Hi Austin,
> > >        Maybe I got the wrong end of the stick, but when Peter said:-
> > > "I have never seen strange levels or oscillations ( well, 25 years ago
> > > we had TTL oscillations). Metastability just affects the delay on the
> > > Q output." I thought he meant that he'd only seen metastability where
> > > the output from the FF was always either on or off, just that
> > > sometimes the transition was delayed. Philip's pictures clearly show
> > > 'strange levels'. This is important, I believe, when deciding what the
> > > effects of metastable FFs are on following circuitry. I guess we'll
> > > have to wait until he returns from his Portugese jaunt before we find
> > > out what he meant!!
> >
> > I think the exact behavior is largely irrelevant since a simple delay is
> > just as disasterous as anything else you would encounter.  Since you
> > don't know *when* the transition would happen, it could happen at the
> > moment the next FF is latching the intermediate value.  That is enough
> > for the next FF and all following logic to behave badly as well.
> >
> > --
> >
> > Rick "rickman" Collins
> >
> > rick.collins@XYarius.com
> > Ignore the reply address. To email me use the above address with the XY
> > removed.
> >
> > Arius - A Signal Processing Solutions Company
> > Specializing in DSP and FPGA design      URL http://www.arius.com
> > 4 King Ave                               301-682-7772 Voice
> > Frederick, MD 21701-3110                 301-682-7666 FAX


Article: 60020
Subject: Re: ISE 5.2 constraint file problem
From: "steve" <srs@twcny.rr.com>
Date: Wed, 03 Sep 2003 17:23:01 GMT
Links: << >>  << T >>  << A >>

"David Lamb" <gretzteam_nospam@yahoo.com> wrote in message
news:bj54ns$7nr$1@home.itg.ti.com...
> I found a workaround. If I add a new UCF, it seems like the old one gets
> updated with the new design (with missing ports). I just add a new UCF,
> delete it right away, and work with the old one.
> David
> "David Lamb" <gretzteam_nospam@yahoo.com> wrote in message
> news:bj547c$6pr$1@home.itg.ti.com...
> > Hi,
> > I have a vhdl project and I used a UCF file to assign the package pin to
> > each port in the design. This works fine. However, if I change my vhdl
> code
> > (let's say I remove an output port), I always get the following error
when
> I
> > try to run the UCF editor:
> > ERROR:NgdBuild:756 - Line 3 in 'constraints.ucf': Could not find net(s)
> >    'outputA' in the design.  To suppress this error specify the correct
> net
> >    name or remove the constraint.
> >
> > It seems like the UCF doesn't update itself with the new design. I tried
> > everything and I always have to start with a new UCF each time. The
> removed
> > port doesn't exist in the Edit constraints (TEXT) because I didn't add
any
> > constraint to it. I really don't see how to do it.
> > Thanks
> > David
> >
> >
>
>

I use Aldec for a front end to Xilinx. This UCF editor is a major problem
for me always. The two don't communicate well with regards to the ucf, and
any changes that it may have.  You can get into an endless loop where one
wants the other to fix it, but it can't because he wants him to fix it etc..
"You must run translate after modifying the ucf". So try and run translate
and it says the ucf has an error because you added things etc. Very
frustrating.



Article: 60021
Subject: Re: Thinking out loud about metastability
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 03 Sep 2003 13:40:03 -0400
Links: << >>  << T >>  << A >>
Luiz Carlos wrote:
> 
> > Electron spin has all the same measurement issues that a FF has.  If the
> > state of the electron spin is changing as the measurement is made, then
> > what state is it in?  What will be the result of the measurement?
> >
> 
> Rick, the electron spin is +1/2 or -1/2, there is no in between state,
> it changes instantaneously (in one fundamental clock tick, ~10^-43
> seconds).
> 
> Luiz Carlos

But the measurement is not instantaneous.  So the transistion could
occur during a measurement.  Result... inconclusive measurement which is
what metastability is all about.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 60022
Subject: Re: Thinking out loud about metastability
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 03 Sep 2003 13:47:24 -0400
Links: << >>  << T >>  << A >>
"Nicholas C. Weaver" wrote:
> 
> In article <3F559A3F.91184B1A@yahoo.com>,
> rickman  <spamgoeshere4@yahoo.com> wrote:
> >
> >There is no way to determine when a circuit is metastable or not.  Async
> >circuits are not magic, they just depend on predictable delays, just
> >like any other circuit.  The design is different because there is no
> >common clock so each circuit can run with its own delay.  Since the next
> >circuit will take the output when it is ready, there is no problem with
> >synchronization.
> 
> Silly question: I don't see why an ANALOG flip-flop couldn't determine
> that it is in the intermediate state at some fixed interval after the
> clock, and then force the flop one way or another.  Of course, it
> might double-glitch in the meantime (flop goes up before logic forces
> it down), but it would make a flop with a fixed-maximum metastabel
> interval.
> 
> Of course, it seems like such a massive headache to do.

If you don't see the problem it is because you are not looking hard
enough.  The issue with metastability comes from trying to measure the
state of a FF or other digital voltage.  When a signal is at an
intermediate value a measurement can be inconclusive.  Your ANALOG FF
can be just as inconclusive as the digital FF.  Besides, the result is
always digital (or more accurately, discreet instead of continuous).  

You are suggesting that you add a third state to the measurement, but
you get the same inconclusive measurement between the metastable state
and either the one or the zero states.  The result is that the output of
your ANALOG FF would be indeterminate which could result in
metastability in the next stage. 

If I am not grasping your idea, then please provide more details. 


> >One problem I do see is that if each stage has a different delay, then
> >it can not accept a new input from the preceding stage until the output
> >has been taken by the following stage.  It seems in the end the async
> >circuit will run no faster than the slowest stage, which is what the
> >sync clocked circuit will do.
> 
> The trick with asynchronous logic is that the longest stage WHICH IS
> IN THE COMPUTATION is the critical path.  EG, if 9 of the stages take
> 1 ns, and the last takes 2ns, but the last only affects 1/2 the data,
> with the asynchronous circuitry doing the shortcutting, it will be
> considerably faster than the synchronous one.

Except that sync designs can do the same thing.  A multiply accumulate
typically takes twice as long as the other ops in a calculation.  So
they split it into two stages running at full speed.  Or if only half
the data needs the MAC, then they can do nothing since this will run at
full speed.  


> The problem is: You can automatically balance the pipelining
> (retiming) for a synchronous circuit, while asynchronous really playes
> havoc with the CAD flow and testing.

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 60023
Subject: Re: Measuring metastability.
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 03 Sep 2003 13:52:34 -0400
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> 
> Rick,
> 
> I agree that the effect is the same:  you just don't know when it will
> resolve, and thus the value that you "see" at the next level is basically
> unknown.
> 
> It could be that Peter's point is that the next circuit in line does make a
> decision, and it most certainly makes the "unknown" into a '1', or into a
> '0'.  It is unlikely that the next circuit in line will propagate the same
> intermediate behavior, and if it can (gain is too low), then things just get
> more fuzzy until someone upstream ends up resolving the level back to a '1'
> or a '0'.

If that were the case, then metastability would not be an issue at all. 
Having an indeterminate voltage is what creates metastability.  The
signal does not need to remain in the indeterminate value for any length
of time, so a transistion at the wrong time is as bad as any other
indeterminte value.  When FFs see an indeterminate input at the sampling
time (very small time and voltage window), they will create an
indeterminate value for an arbitrary period (or at an abritray delay) on
the output.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 60024
Subject: Re: Thinking out loud about metastability
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Wed, 3 Sep 2003 17:55:40 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <3F56292C.E9F89B7F@yahoo.com>,
rickman  <spamgoeshere4@yahoo.com> wrote:
>"Nicholas C. Weaver" wrote:
>If you don't see the problem it is because you are not looking hard
>enough.  The issue with metastability comes from trying to measure the
>state of a FF or other digital voltage.  When a signal is at an
>intermediate value a measurement can be inconclusive.  Your ANALOG FF
>can be just as inconclusive as the digital FF.  Besides, the result is
>always digital (or more accurately, discreet instead of continuous).  
>
>You are suggesting that you add a third state to the measurement, but
>you get the same inconclusive measurement between the metastable state
>and either the one or the zero states.  The result is that the output of
>your ANALOG FF would be indeterminate which could result in
>metastability in the next stage. 
>
>If I am not grasping your idea, then please provide more details. 

The flip flop core exists in one of THREE states: Vdd, Vss (the stable
points) and Vms +/- epsilon (the metastable range, in between Vdd and
Vss).

The analog circuitry in the flip flop measures the flip-flop state at
Tdelay after the clock edge.  

If it is within Vms +/- a large epsilon (that is, metastable at this
point in time), the analog circuitry forces the flip-flop to Vss, and
also signals that a metastable capture/correction was performed.

This may cause a spurrious transition (eg, the metastable state is
measured, it goes high, and then the post-measurement kick drags it
back down to Vss).

>> The trick with asynchronous logic is that the longest stage WHICH IS
>> IN THE COMPUTATION is the critical path.  EG, if 9 of the stages take
>> 1 ns, and the last takes 2ns, but the last only affects 1/2 the data,
>> with the asynchronous circuitry doing the shortcutting, it will be
>> considerably faster than the synchronous one.
>
>Except that sync designs can do the same thing.  A multiply accumulate
>typically takes twice as long as the other ops in a calculation.  So
>they split it into two stages running at full speed.  Or if only half
>the data needs the MAC, then they can do nothing since this will run at
>full speed.  

The promise of the asynchronous is that this can occur on a much finer
grain, eg if all the ops are 1 ns, but the final one is either 1 or
1.5 ns.

Of couse, it has never really lived up to this promise, mostly because
the handshaking overhead can be severe, as well as the other problems
(CAD, testing).
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu



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