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
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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 14050

Article: 14050
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10 Metastability - help please
From: z80@ds2.com (Peter)
Date: Sat, 09 Jan 1999 18:10:10 GMT
Links: << >>  << T >>  << A >>

Yes, but if a particular edge of the injected signal was just right to
push it *into* a MS state (which is quite possible) then the next edge
(of that injected signal) is guaranteed to push it *out* of that
state.

And you won't need a strong signal either, because the MS state is an
extremely fine balance between the two energy levels.

>It it was in exactly a metastable position. What if it was on its way
>to one of the stable states, but then got pushed back to MS state?


--
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: 14051
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10 Metastability - help please
From: Magnus Homann <d0asta@mis.dtek.chalmers.se>
Date: 09 Jan 1999 20:58:03 +0100
Links: << >>  << T >>  << A >>
z80@ds2.com (Peter) writes:

> Yes, but if a particular edge of the injected signal was just right to
> push it *into* a MS state (which is quite possible) then the next edge
> (of that injected signal) is guaranteed to push it *out* of that
> state.

But the same situation could happen at next edge. Just getting out of
MS, when the next edge comes and put it back in there. I'm not saying
it's *likely' to happen, but the entire MS situation isn't either... :-)

> And you won't need a strong signal either, because the MS state is an
> extremely fine balance between the two energy levels.

*If* the F/F was exactly in the MS state when the edge occur. I was
imagining a situation where it was X joule below the MS state, and the
edge adds exactly X joule.

Or I could be completley wrong.

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: 14052
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10 Metastability - help please
From: wen-king@myri.com (Wen-King Su)
Date: 9 Jan 1999 13:51:22 -0800
Links: << >>  << T >>  << A >>
In a previous article z80@ds2.com (Peter) writes:
:
;
:Yes, but if a particular edge of the injected signal was just right to
;push it *into* a MS state (which is quite possible) then the next edge
:(of that injected signal) is guaranteed to push it *out* of that
;state.
:
;And you won't need a strong signal either, because the MS state is an
:extremely fine balance between the two energy levels.

The worse case is when the first edge drives it across to the other side
and then the next edge drives it back.  If left along, the FF may be in
a state such that it will drift into a legal region by the time you need
to sample it, but the noise prolonged its stay in the illegal region. 

Article: 14053
Subject: Advanced VHDL Editor Available
From: "John Maher" <jmaher@silicon-systems.REMOVE.com>
Date: Sun, 10 Jan 1999 10:32:49 +1100
Links: << >>  << T >>  << A >>
Silicon Systems Solutions have released 'ED for Windows for HDL EXPERT' for
advanced VHDL editing.

Features include:

-Automatic Hierarchy extraction and display
-Automatic Testbench generation
-Colorised keyword
-automatic language templates

Check out http://www.silicon-systems.com/editore.htm for more details, and
free evalution of standard version.

Be patient, there are a number of detailed screen shots on there!

-John


Article: 14054
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10 Metastability - help please
From: z80@ds2.com (Peter)
Date: Sun, 10 Jan 1999 08:11:12 GMT
Links: << >>  << T >>  << A >>

Damn. You are right. I concede defeat. :)

Yes, it is right back to the old statistical argument, no matter what
you do.

>But the same situation could happen at next edge. Just getting out of
>MS, when the next edge comes and put it back in there. I'm not saying
>it's *likely' to happen, but the entire MS situation isn't either... :-)


--
Peter.

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

Article: 14055
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10 Metastability - help please
From: "Frank Bemelman" <fbemelx@euronet.nl>
Date: Mon, 11 Jan 1999 00:10:46 +0100
Links: << >>  << T >>  << A >>
rk heeft geschreven in bericht
<36934FF2.234F64BD@NOSPAMerols.com>...
>
>independent of what the design flaw is, assuming that a
circuit is good until
>proven guilty is really a crime against humanity and you
shouldn't really have
>anything to do with electronics, in my opinion.  in
practice, one should follow
>barto's law: EVERY CIRCUIT IS CONSIDERED GUILTY UNTIL
PROVEN INNOCENT!


I was reading some postings further down this thread,
postings I was not supposed to read... while I actually was
skipping posts in this thread for quite a while already. So
I started to track the messages backwards, to see what I had
missed.

Yesterday I picked up a recommended article on
metastability, because I had no idea what this was all
about. Until this thread started, I never realized that
metastability existed (!). The article explained it well
enough for me to understand.

I suppose if I had to design a
*plasma-regenerating-warp-core-stabilizer* for the next
generation of *enterprise starships* I would be a bit more
careful about my designs, not because of possible
metastability but for more down to earth reasons, such as -
but not limited to - simply staying within ac/dc
specifications to avoid blowing the top of chips.

Fact is, I am designing relatively simple uP boards. I even
have to write the software for it. My designs aren't 100%
reliable, mostly because I haven't removed all software
flaws yet. I can understand that one can get excited about
metastability, but *I* couldn't care less. The article I
have read, showed an example where an improvement was
suggested, putting 2 d-flipflops in cascade, resulting in 1
occurence of metastability once every 2 million years.
Although very interesting, I am not even considering that
advice for my future designs, because I like to see this
metastability-thing at least once in my life.

Still, I don't think I am irresponsible. I am not designing
medical life support systems. I do not design stuff for
airplanes. I dont know anything about satellite and
spaceships. But I do know my designs are more than adequate
for their purposes.

My point is, there's nothing wrong about different opinions
regarding metastabilty. And why is everbody always designing
such delicate apparatus ? I start to feel a bit silly ;-)

Met vriendelijke groeten,
Frank Bemelman
(reageren per email ? verwijder dan de 'x' uit mijn
emailadres)


Article: 14056
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10 Metastability - help please
From: rk <stellare@NOSPAMerols.com>
Date: Sun, 10 Jan 1999 19:49:24 -0500
Links: << >>  << T >>  << A >>
hi frank,

interesting post ... well, some of us have seen designs fail when
metastability is not taken into account - usually by those engineers who
don't believe in it - "it'll be either a '1' or a '0'".  these sorts of
problems can turn up in various circuits such as synchronizers,
arbiters, and interlocks.  one case that does come to mind is the young
engineer who insisted it would not be a problem when interfacing to
dual-port ram chips.  he built the board and failure there was quite
frequent, couldn't finish loading the board's code up.  i've seen other
failures in radar systems designs, for example, when each engineer
designed his own part of the system with his own clock.  failures there
were frequent enough that a complete set of tests could never be
completed and the entire system was scrapped and redesigned from
scratch.  with a lot fewer clocks and a minimized number of asynchronous
interfaces, each carefully managed.

today, with modern technology, a lot of this metastable stuff is more or
less academic - if reasonable design rules are followed and even a small
amount of settling time is given, the failure rate can be made below
that of the base cmos process for chips.  some of the manufacturers will
quote parameters for their chips and one can run the mtbf formulas and
get some comfort.  unfortunately, this isn't always done.

now, barto's law was quoted w.r.t. the philosophy of design by test -
since retracted as error, apparently - and simply trying a design and
say, 'hey it works' is not good enough.  after all, many systems need to
work without stop for 15 years or more without failing.  many readers
here are involved in military systems design and others do that
"plasma-regenerating-warp-core-stabilizer* for the next
generation of *enterprise starships* -thing.  for example, if one is
working on a billion+-dollar, one-of-a-kind product. some care should be
taken; same for life support, airplanes, and stuff like that.

if you would like to see metastability, it's easy enough to build a test
fixture for it (perhaps i'll scan and post some pictures from the
literature, if you or others would like).

are there different opinions about metastability?  sure, some have
"proved" that it can't be solved in unbounded time, others try to crack
it.  personally, i'd like to see a guaranteed circuit and be done with
it and every year or so come up with some scheme to try.

does your system need to be reliable?  that's a question for you to
answer.  and those that depend on it running correctly.

good evening,

rk

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

Frank Bemelman wrote:

> rk heeft geschreven in bericht
> <36934FF2.234F64BD@NOSPAMerols.com>...
> >
> >independent of what the design flaw is, assuming that a
> circuit is good until
> >proven guilty is really a crime against humanity and you
> shouldn't really have
> >anything to do with electronics, in my opinion.  in
> practice, one should follow
> >barto's law: EVERY CIRCUIT IS CONSIDERED GUILTY UNTIL
> PROVEN INNOCENT!
>
> I was reading some postings further down this thread,
> postings I was not supposed to read... while I actually was
> skipping posts in this thread for quite a while already. So
> I started to track the messages backwards, to see what I had
> missed.
>
> Yesterday I picked up a recommended article on
> metastability, because I had no idea what this was all
> about. Until this thread started, I never realized that
> metastability existed (!). The article explained it well
> enough for me to understand.
>
> I suppose if I had to design a
> *plasma-regenerating-warp-core-stabilizer* for the next
> generation of *enterprise starships* I would be a bit more
> careful about my designs, not because of possible
> metastability but for more down to earth reasons, such as -
> but not limited to - simply staying within ac/dc
> specifications to avoid blowing the top of chips.
>
> Fact is, I am designing relatively simple uP boards. I even
> have to write the software for it. My designs aren't 100%
> reliable, mostly because I haven't removed all software
> flaws yet. I can understand that one can get excited about
> metastability, but *I* couldn't care less. The article I
> have read, showed an example where an improvement was
> suggested, putting 2 d-flipflops in cascade, resulting in 1
> occurence of metastability once every 2 million years.
> Although very interesting, I am not even considering that
> advice for my future designs, because I like to see this
> metastability-thing at least once in my life.
>
> Still, I don't think I am irresponsible. I am not designing
> medical life support systems. I do not design stuff for
> airplanes. I dont know anything about satellite and
> spaceships. But I do know my designs are more than adequate
> for their purposes.
>
> My point is, there's nothing wrong about different opinions
> regarding metastabilty. And why is everbody always designing
> such delicate apparatus ? I start to feel a bit silly ;-)
>
> Met vriendelijke groeten,
> Frank Bemelman
> (reageren per email ? verwijder dan de 'x' uit mijn
> emailadres)



Article: 14057
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10 Metastability - help please
From: wen-king@myri.com (Wen-King Su)
Date: 10 Jan 1999 17:08:47 -0800
Links: << >>  << T >>  << A >>
In a previous article "Frank Bemelman" <fbemelx@euronet.nl> writes:
:
:Still, I don't think I am irresponsible. I am not designing
;medical life support systems. I do not design stuff for
:airplanes. I dont know anything about satellite and
;spaceships. But I do know my designs are more than adequate
:for their purposes.

While metastability can't be completely eliminated, it can be completely
compartmentalized to the extent that it is of no concern to most designers.
The issue can be restricted to a thin boundary in the part of the circuit
that interfaces differing clock domains or between a clocked domain and
an asynchronous domain.  Techniques exists to arbitrarily reduce the
probability of meta-stable state propogating into the core of the circuit.
It can be done so at the expense of latency without giving up bandwidth.

Article: 14058
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10 Metastability - help please
From: Peter Alfke <peter@xilinx.com>
Date: Sun, 10 Jan 1999 17:10:44 -0800
Links: << >>  << T >>  << A >>
 

Hi Frank.
If I were you, I would not brag about my ignorance.
Metastability has been a really ugly problem in the past.
Companies have gone bancrupt because they could not deliver
a reliable product.
I was just pointing out that the best of modern CMOS
flip-flops have reduced the likelihood of metastability to a
point where we can be more relaxed about it.
But it still makes for a spirited discussion...

Peter Alfke
Xilinx Apps.
 

Frank Bemelman wrote:

> Until this thread started, I never realized that
> metastability existed (!). snip

 

> Still, I don't think I am irresponsible. I am not
> designing
> medical life support systems. I do not design stuff for
> airplanes. I dont know anything about satellite and
> spaceships. But I do know my designs are more than
> adequate
> for their purposes.
>
> My point is, there's nothing wrong about different
> opinions
> regarding metastabilty. And why is everbody always
> designing
> such delicate apparatus ? I start to feel a bit silly ;-)

 

Article: 14059
Subject: DES Hardware Implementation!!
From: Samer EL HAJJ <samer@dotcom.fr>
Date: Mon, 11 Jan 1999 09:45:39 +0100
Links: << >>  << T >>  << A >>
Hello!
I'm working on the hardware inmplementation (with VHDL into an FPGA) of
DES decryption.
after many searh I did not find any publication or example about this
topic.

Can anyone point me to some documentation on the subject?
Thanks in advance!!

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Samer EL HAJJ
DotCom-Communication Numérique http://www.dotcom.fr
mailto:samer@writeme.com
S@merWeb: http://www.chez.com/samerweb
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


Article: 14060
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10 Metastability - help please
From: msimon@tefbbs.com (M.Simon)
Date: Mon, 11 Jan 1999 10:25:19 GMT
Links: << >>  << T >>  << A >>
Problem not eliminated.

1 f/f High
1 f/f Metastable
1 f/f Low

How do you decide?

Simon
============================================================
On Fri, 08 Jan 1999 09:31:48 -0600, Dan Prysby
<dprysby1@email.mot.com> wrote:

>Brad Taylor wrote:
>> 
>> Someone claims to be developing a 100% metastable-proof FF. Hmmm..,
>> since a FF has to make a decision as to whether a signal is above a
>> threshhold or below it and the signal can be exactly on the threshold,
>> this would seem unlikely.
>
>So if a combination of 3 FFs sample 1 signal close enough in time
>and each has a different threshold by design, then only 1 will go
>metastable. Just a supposition.
>
>Dan

Article: 14061
Subject: Xilinx Field Applications Engineer - Vacancy
From: "David Hawke" <dhawke@globalnet.co.uk>
Date: Mon, 11 Jan 1999 10:30:45 -0000
Links: << >>  << T >>  << A >>
One of the leading UK distributors has a vacancy for a Xilinx Field
Applications Engineer. Based in the South West of the UK you will look after
existing accounts as well as generating new business for the company.
You will be qualified to degree level in Electronic Engineering and have a
background in digital electronics. You must also be capable of working in a
pressure situation with a very outgoing personality and good communication
skills.

You will recieve 2 week 'Boot Camp' training in the US.
You will be rewarded for your efforts with an Executive Car, competitive
salary, high OTE, and healthcare.

For more information please email David Hawke at : dhawke@globalnet.co.uk


Article: 14062
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10 Metastability - help please
From: Manish_Shrivastava <manish@ieee.org>
Date: Mon, 11 Jan 1999 20:06:18 +0800
Links: << >>  << T >>  << A >>
Hal Murray wrote:

>
>
> I think the key parameter is not the metastability recovery time constant
> alone, but the ratio of that time to the system clock time.  If I have
> a system with enough time for multiple levels of logic then it is
> probably easy to cleanly process an asynchronous input - just leave out
> those levels of logic (and their routing) and you have enough time between
> a pairof FFs.  But what if I'm running a heavily pipelined system where
> the system clock only leaves room for a timy bit of routing?  Now there
> aren't any extra levels of logic to leave out.  The classic FF-no-logic-FF
> synchronizer may not have a lot of leftover time.
>
> Note that designers pushing system clock speed are likely to jump on
> the next generation of faster chips as soon as they become available.
> That's before the metastability data becomes availability.  Assuming
> that the metastability recovery time constant speeds up just like
> everything else seems like a good first guess but I don't see any
> reason to bet much on it.
>
> --
> These are my opinions, not necessarily my employers.


Hi
The whole concept of metability does not click to me, dont know why.
It is all about the probiblity being reduced by using back to back FF's and
reducing the probability of the input hitting the danger zone, ( Setup and hold)

But then how do you process data in a synchornous system. almost always at the
next clock from the driving FF. So why bother about the first .01 ns of the clock
period
when data is not defined. It will cause a dynamic current for the circuit a little
longer
then desired but what else.

Please do correct me and send me direct replies, but I think it is just a matter of
calculating whether I am consuming more current with the additional FF or by
the subnanosecond undefined logic level. Ok the other aspect is that you didnt
catch that input, but you will definitly not be sure if it comes so near to the
clock
edge which level will be caught anyway???


Regards
Manish

Article: 14063
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10 Metastability - help please
From: rk <stellare@NOSPAMerols.com>
Date: Mon, 11 Jan 1999 07:41:50 -0500
Links: << >>  << T >>  << A >>


hi manish,

Manish_Shrivastava wrote:

> Hi
> The whole concept of metability does not click to me, dont know why.
> It is all about the probiblity being reduced by using back to back FF's and
> reducing the probability of the input hitting the danger zone, ( Setup and hold)
>
> But then how do you process data in a synchornous system. almost always at the
> next clock from the driving FF. So why bother about the first .01 ns of the clock
> period
> when data is not defined. It will cause a dynamic current for the circuit a little
> longer
> then desired but what else.

most systems do not bother with the data right after the clock, in a synchrous system.
assuming ideal clock distribution, and a th of 0 nsec for each flip-flop, the data
right after the clock will be ignored.  in real world systems, the skew is, of course,
not zero. but the propagation delay, tclk-q, is a positive non-zero number also along
with any routing delays.  the trick is to get the skew time low, as prop delays and
routing times get smaller as processes improve.  in the area of fpga's, we have been
getting better and better clocks, making this, for the most part, not too much of a
problem.  of course, one must run the timing numbers.  and moving between different
clock trees, even for the clocks of the same frequency and phase can still be a
problem, if the clock delays are sensitive to loading.  for some older technologies,
you had to run a clock load balancing algorithm, select routing criteria, perhaps
taking over yourself, to make sure the minimum delays were large enough to give
adequate margin against skew time (i never trust the analyzer when it says my margin is
100 psec).  of course, in the highest performance circuits, skew may intentionally be
induced into the clock network for performance reasons, but that's another story.
_clock distribution networks in vlsi circuits and systems_, edited by eby friedman, is
a good collection, and has papers dealing with that.

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

> Please do correct me and send me direct replies, but I think it is just a matter of
> calculating whether I am consuming more current with the additional FF or by
> the subnanosecond undefined logic level. Ok the other aspect is that you didnt
> catch that input, but you will definitly not be sure if it comes so near to the
> clock edge which level will be caught anyway???

i think i understood what you said.  the problem is, according to theory, is that the
amount of time for a flip-flop to make up it's mind is unbounded and that you can never
say for certain that the flip-flop that synchronizes will be stable by the next clock
edge.  while people have come up with various schemes for helping things along, none
has been proven to guarantee anything, and most have been shown to fail.  [when i get
time, i will post more on some of that].

on the other hand, most modern flip-flops have small resolution times, making the
additional delay manageable in most situations.  of course, system clock rates have
been improving too, as HA has pointed out.  but as PA has mentioned, the resolving time
of the flip-flops has improved very fast.  as an example, here is some data i just ran,
and most definitely not the greastest and latest xilinx stuff:

***************************************
Manufacturer = Xilinx
F-F Model    = XC4005E-3_CLB
Minimum Slack   = 1.000
Maximum Slack   = 20.000
Slack Increment = 1.000
K1 = 0.100
K2 = 19.400
Clock Frequency =  5.0000E+0007
Data Frequency  =  1.0000E+0007

Slack Time         MTBF (sec)        MTBF (years)
      1.00      5.325286E+0003      1.688637E-0004
      2.00      1.417934E+0012      4.496238E+0004
      3.00      3.775451E+0020      1.197187E+0013
      4.00      1.005267E+0029      3.187683E+0021
      5.00      2.676669E+0037      8.487663E+0029
      6.00      7.127015E+0045      2.259962E+0038
      7.00      1.897670E+0054      6.017471E+0046
      8.00      5.052817E+0062      1.602238E+0055
      9.00      1.345385E+0071      4.266187E+0063
     10.00      3.582280E+0079      1.135933E+0072
     11.00      9.538332E+0087      3.024585E+0080
     12.00      2.539717E+0096      8.053391E+0088
     13.00      6.762361E+0104      2.144331E+0097
     14.00      1.800575E+0113      5.709587E+0105
     15.00      4.794289E+0121      1.520259E+0114
     16.00      1.276548E+0130      4.047907E+0122
     17.00      3.398992E+0138      1.077813E+0131
     18.00      9.050302E+0146      2.869832E+0139
     19.00      2.409772E+0155      7.641338E+0147
     20.00      6.416364E+0163      2.034616E+0156

MTBF Improvement per increment = 266264304.669

so, for properly designed systems, in most cases [adding appropriate disclaimers], it's
not a problem.  for systems with high clock rates, letting the input settle over
multiple periods will help, as it's a far from linear relationship, as you can see by
the above numbers.

good day,

rk




Article: 14064
Subject: Non-standard use of I/O blocks
From: Eduardo Augusto Bezerra <E.A.Bezerra@sussex.ac.uk>
Date: Mon, 11 Jan 1999 13:37:15 +0000
Links: << >>  << T >>  << A >>

Hi

I need to access the points 1 and 2 (see figure below) from the
outside of an FPGA. It doesn't matter if the inversors are located
in an I/O element or in a configurable block. I want to use the
invesrors as an amplifier, and for that I need to access the points
1 and 2 to include extra circuit.

Does anybody has any idea if it is possible? If yes, which FPGA
is more suitable (I've been working with Xilinx FPGAs)?


       |\           |\
  1    | \     2    | \
--@----|  O----@----|  O-------> to FPGA configurable blocks
       | /          | /
^      |/           |/
| 
+-- Input signal from outside


Any suggestion would be welcome.

Eduardo.

--
mailto:E.A.Bezerra@sussex.ac.uk


--
+-----------------------+---------------------------------------------+
|Eduardo Augusto Bezerra|mailto:E.A.Bezerra@sussex.ac.uk              |
|-----------------------|---------------------------------------------|
|Space Science Centre   |http://www.sussex.ac.uk/engg/research/space/ |
|School of Engineering  |http://www.sussex.ac.uk/Users/tapu9/         |
|University of Sussex   |http://www.inf.pucrs.br/~eduardob            |
|Falmer, Brighton       |---------------------------------------------|
|BN1 9QT, UK            |Phone: +44 (0)1273 877086        Fax: 678399 |
+-----------------------+---------------------------------------------+

Article: 14065
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10 Metastability - help please
From: rbmccammon@mmm.com (Roy McCammon)
Date: Mon, 11 Jan 1999 08:27:44 -0600
Links: << >>  << T >>  << A >>
Frank Bemelman wrote:


> Fact is, I am designing relatively simple uP boards. I even
> have to write the software for it. My designs aren't 100%
> reliable, mostly because I haven't removed all software
> flaws yet. I can understand that one can get excited about
> metastability, but *I* couldn't care less. The article I
> have read, showed an example where an improvement was
> suggested, putting 2 d-flipflops in cascade, resulting in 1
> occurence of metastability once every 2 million years.
> Although very interesting, I am not even considering that
> advice for my future designs, because I like to see this
> metastability-thing at least once in my life.

So lets assume that your design has 200 such ff's and
you sell 10K units.  Voila, you'll be looking at one
event per year.



Opinions expressed herein are my own and may not represent those of my employer.

Article: 14066
Subject: Re: I2C core
From: "George E. Smith, Jr" <jawbee@bellsouth.net>
Date: Mon, 11 Jan 1999 15:01:19 GMT
Links: << >>  << T >>  << A >>
Hi,

 I'm sory that I don't have the link. But I'm sure I've seen the VHDL
for Ic2 on one
of the free model sites. Hope that helps.

saffary wrote:

> Anyone know where I can find i2c VHDL core.
>
> thank.

--
     George Smith
     Avalex Technologies
     Atlanta, Ga.
     404.256.3010

   I.R.S. We have what it takes to take what you have.
  -- Support the national sales tax.


Article: 14067
Subject: Re: DES Hardware Implementation!!
From: Brian Boorman <XZY.bboorman@harris.com>
Date: Mon, 11 Jan 1999 12:17:01 -0500
Links: << >>  << T >>  << A >>
This topic was recently covered, either here or in comp.lang.vhdl (Sorry,
don't remember which). Try searching through back archives of the
comp.arch.fpga and .lang.vhdl groups. Was about November/early December
time frame.

Samer EL HAJJ wrote:

> Hello!
> I'm working on the hardware inmplementation (with VHDL into an FPGA) of
> DES decryption.
> after many searh I did not find any publication or example about this
> topic.
>
> Can anyone point me to some documentation on the subject?
> Thanks in advance!!
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Samer EL HAJJ
> DotCom-Communication Numérique http://www.dotcom.fr
> mailto:samer@writeme.com
> S@merWeb: http://www.chez.com/samerweb
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



--
Brian C. Boorman
Harris RF Communications
Rochester, NY 14610
XYZ.bboorman@harris.com
<Remove the XYZ. for valid address>


Article: 14068
Subject: Re: I2C core
From: tom_curran@memecdesign_dot_com (tom curran)
Date: Mon, 11 Jan 1999 17:30:52 GMT
Links: << >>  << T >>  << A >>
My company offers ÿ I2C core in two flavors -- a master-only version
and a master-slave version.  Both are optimized for FPGAs,
specifically Xilinx 4k and Spartan.  The Virtex implementation will be
released soon.

---
Tom Curran
Memec Design Services -- Boston
url:    www.memecdesign.com
email:  tom_curran@memecdesign_dot_com

Article: 14069
Subject: Re: Non-standard use of I/O blocks
From: Peter Alfke <peter@xilinx.com>
Date: Mon, 11 Jan 1999 09:52:23 -0800
Links: << >>  << T >>  << A >>
Eduardo Augusto Bezerra wrote:

> Hi
>
> I need to access the points 1 and 2 (see figure below)
> from the
> outside of an FPGA. Does anybody has any idea if it is
> possible? If yes, which FPGA
> is more suitable (I've been working with Xilinx FPGAs)?
>
>        |\           |\
>   1    | \     2    | \
> --@----|  O----@----|  O-------> to FPGA configurable
> blocks
>        | /          | /
> ^      |/           |/
> |
> +-- Input signal from outside
>  

It's simple. You just route those points to another pin or
pins as output(s).
But you should be aware that your drawing is deceptive: The
buffer or gain stage is really a multi-stage amplifier. So
from the input to the output you may have a six-stage
amplifier, and if you force that into its linear operating
range, you might have nasty gain and phase characteristics.
People have done it to build a crystal oscillator, but I
have always discouraged this.
Buy a canned oscillator, it's almost as cheap as a crystal,
it consumes less power and is more reliable. Definitely less
headache.

Peter Alfke, Xilinx Applications

Article: 14070
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10
From: Tim Hubberstey <marmot@rogers.wave.ca>
Date: Mon, 11 Jan 1999 18:19:26 +0000
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> 
[snip}
> I was just pointing out that the best of modern CMOS
> flip-flops have reduced the likelihood of metastability to a
> point where we can be more relaxed about it.
> But it still makes for a spirited discussion...
> 
> Peter Alfke
> Xilinx Apps.

I've heard these sentiments echoed in several posts in this thread and
I'm afraid I have to disagree.

I am currently involved in a design involving several chips using a 0.25
micron process from a large, respected vendor (who will remain
undisclosed due to NDAs) and we have found metastability to be a very
real potential problem. The chips in question fall into the "system on a
chip" category and as such have several high-speed clock domains.
Analysis by the vendor has predicted an MTBF of less than a minute for
the standard 2 flip-flop synchronizer when going between a 60 MHz and a
75 MHz clock domain. This is obviously not something "we can be more
relaxed about".

One of the biggest contributors to this problem turns out to be junction
temperature. In these days of systems on a chip, the die will often have
a worst case temperature spec of over 100C. The vendor's projections
show a 10000-fold difference in MTBF across a die temperature range of
0C to 100C.

Your comment may be valid for FPGAs (I defer to your experience here)
but I can't agree with it as a blanket statement.
-- 
Tim Hubberstey, P.Eng. . . . . . . . . . . . . . .  Marmot Engineering
Vancouver, BC, Canada  . . . . . Hardware/Software Consulting Engineer
Email: marmot@rogers.wave.ca . . . . . . VHDL, ASICs, embedded systems

Article: 14071
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10
From: Peter Alfke <peter@xilinx.com>
Date: Mon, 11 Jan 1999 11:21:27 -0800
Links: << >>  << T >>  << A >>
Tim Hubberstey wrote:

> The chips in question fall into the "system on a
> chip" category and as such have several high-speed clock
> domains.
> Analysis by the vendor has predicted an MTBF of less than
> a minute for
> the standard 2 flip-flop synchronizer when going between a
> 60 MHz and a
> 75 MHz clock domain. This is obviously not something "we
> can be more
> relaxed about".
>
> One of the biggest contributors to this problem turns out
> to be junction
> temperature. In these days of systems on a chip, the die
> will often have
> a worst case temperature spec of over 100C. The vendor's
> projections
> show a 10000-fold difference in MTBF across a die
> temperature range of
> 0C to 100C.

Wow, anybody bridging the gap between 60 MHz and 75 MHz
*must* not only be concerned about metastability, but should
also question the conceptual design.If the bridge is really
unavoidable, then use triple or quadruple synchronizers and
give these flip-flops some "breathing space", i.e. make sure
the routing delays between them use up an inignificant
portion of the clock period.

I  would never recommend a relaxed attitude in *that* kind
of environment.

Luckily, most asynchronous interfaces operate at a much
slower pace.

Peter Alfke, Xilinx Applications
 
 

>  
>  

 

Article: 14072
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10 Metastability - help please
From: Peter Alfke <peter@xilinx.com>
Date: Mon, 11 Jan 1999 11:55:14 -0800
Links: << >>  << T >>  << A >>
The problem with a flip-flop or latch in a metastable state
is not its output level while it is in this state. It is
easy enough to build a level shifter that reliably
interprets the balanced condition as High ( or as Low, if
that is preferred ).
The terrible problem is that the flip-flop or latch will
leave the metastable state at a moment that is uncontrolled
( and uncontrollable ) by any external signal, and thus can
create a level change at an "awkward" moment.
So the unsolvable problem is the unpredictable nature of the
metastable recovery delay.

And the thread goes on and on...
Peter Alfke, Xilinx Applications
 

M.Simon wrote:

> Problem not eliminated.
>
> 1 f/f High
> 1 f/f Metastable
> 1 f/f Low
>
> How do you decide?
>
> Simon

 

Article: 14073
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10 Metastability - help please
From: "Frank Bemelman" <fbemelx@euronet.nl>
Date: Mon, 11 Jan 1999 21:39:10 +0100
Links: << >>  << T >>  << A >>
rk heeft geschreven in bericht
<36994A94.C9130453@NOSPAMerols.com>...
>if you would like to see metastability, it's easy enough to
build a test
>fixture for it (perhaps i'll scan and post some pictures
from the
>literature, if you or others would like).


There was a little circuit inside the sdya006.pdf document I
downloaded from the Texas Instruments site, couple of
d-flipflops, comparators etc.

>are there different opinions about metastability?  sure,
some have
>"proved" that it can't be solved in unbounded time, others
try to crack
>it.  personally, i'd like to see a guaranteed circuit and
be done with
>it and every year or so come up with some scheme to try.
>
>does your system need to be reliable?  that's a question
for you to
>answer.  and those that depend on it running correctly.


No complaints from the customers, they judge our stuff as
highly reliable - and so do we.

Met vriendelijke groeten,
Frank Bemelman
(reageren per email ? verwijder dan de 'x' uit mijn
emailadres)


Article: 14074
Subject: Glitchless Logic, hazards, and Metastability - Was Re: 22V10 Metastability - help please
From: John Woodgate <jmw@jmwa.demon.co.uk>
Date: Mon, 11 Jan 1999 23:17:38 +0000
Links: << >>  << T >>  << A >>
<369A5718.4D793D87@xilinx.com>, Peter Alfke <peter@xilinx.com> wrote 
 **Please** note that I prefer **not** to receive an e-mail copy:
>he problem with a flip-flop or latch in a metastable state
>is not its output level while it is in this state. It is
>easy enough to build a level shifter that reliably
>interprets the balanced condition as High ( or as Low, if
>that is preferred ).
>The terrible problem is that the flip-flop or latch will
>leave the metastable state at a moment that is uncontrolled
>( and uncontrollable ) by any external signal, and thus can
>create a level change at an "awkward" moment.
>So the unsolvable problem is the unpredictable nature of the
>metastable recovery delay.

Surely, if you can reliably detect the m-state, you can force it
whichever way you want in a defined time, if possible short enough not
to be of any significance? 

I would again draw attention to the work of McClintock and Luchinsky at
Lancaster University (UK) on the effects of noise on non-linear systems,
which seems maybe to offer a novel approach, if not a solution. Go to
http://www.newscientist.com.
-- 
Regards, John Woodgate, Phone +44 (0)1268 747839 Fax +44 (0)1268 777124. 
OOO - Own Opinions Only. ERROR! OUT OF CORNFLAKES. Please check cereal port 
configuration.



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
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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