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 49675

Article: 49675
Subject: Re: Metastability in FPGAs
From: Phil Hays <SpamPostmaster@attbi.com>
Date: Tue, 19 Nov 2002 06:01:00 GMT
Links: << >>  << T >>  << A >>
Ray Andraka wrote:

> Where slack does come into play with metastability is that your
> metastability resolution time available is equal to the slack time.  If your
> path leading from your syncronizer  has little slack, your chances of a
> metastable event lasting long enough to matter is greatly increased.  You
> want to maximize the slack after a synchronizer, preferably with
> geographically close registers with no intervening logic.

I'd also suggest a TO:FROM spec for the path between the syncronizer and
the next register.  A suggested value would be:

period - needed_extra_delay - jitter_budget


Where the needed_extra_delay is more than enough to meet the MTBF goals
your design requires.

Without this, the router might send this path round the chip a few times
until there wasn't enough extra delay, even with registers nearby...


-- 
Phil Hays

Article: 49676
Subject: xilinx device inception dates
From: Matthew E Rosenthal <mer2@andrew.cmu.edu>
Date: Tue, 19 Nov 2002 01:29:16 -0500 (EST)
Links: << >>  << T >>  << A >>
Does anybody have the dates that specific versions of xilinx fpga's were
first produced?

I am hoping to get dates to within 1 month.

I am looking for the dates that these or any other devices were produced.

Virtex II
	2V40
	2V80
	2V250
	2V500
	2V1000
	2V1500
	2V2000
	2V4000
	2V6000
	2V8000

Spartan IIE
	XC2S50E
	XC2S100E
	XC2S150E
	XC2S200E
	XC2S300E
	XC2S400E
	XC2S600E

Spartan II
	any version

Thanks

Matt


Article: 49677
Subject: Re: Metastability in FPGAs
From: hmurray@suespammers.org (Hal Murray)
Date: Tue, 19 Nov 2002 06:33:34 -0000
Links: << >>  << T >>  << A >>

> Looking at it closer, you are right.
>You can (slightly) reduce the probability with voting, but cannot avoid 
>a 'just under vote' becomming 'just over vote' after the metastable
>delay, 
>and so cannot force a MAX value on the metastable time.

How does voting "(slightly) reduce the probability"?

Here is my analysis.  The setup times will be slightly different.
Pick the middle FF and concentrate on that.  It will go metastable
as often as any single FF.  You have added logic that eats up
some of the settling time so I claim that's worse rather than better.


> Simpler/better results can be got with opposite edge cascaded
>registers.

Beware.  Using opposite edges eats up a half cycle of settling time.
What sort of MTBF does that leave you?  Don't forget to round down
in case of clock asymmetry.

-- 
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: 49678
Subject: Re: Altera MAX7000E (EPM7128ELC84) - programmer?
From: "Philip Pemberton" <philpem@btinternet.com>
Date: Tue, 19 Nov 2002 06:42:03 -0000
Links: << >>  << T >>  << A >>
ted wrote:
> Be careful when buying these devices second hand, as the specs say the
> guaranteed number of programming cycles is only 100 times. YOu may get
> a "retired" device.
Hmm, never noticed that in the datasheet.

> You may be better off buying CPLDs from Xilinx. Xilinx sells online
> via their website I think (postage and import duty may cost you dear
> though!).
I've just finished looking at their website - the XC9500 CPLDs look very
nice, plus some of them are available in PLCC packages. And to top it all
off they've got a UK disti who (from experience) is quite good at giving out
samples.

> Their parallel programmer is also easy to make and you can download
> the circuit from their website.
Guess that settles it - Xilinx it is :-)
It's just a shame that Farnell don't seem to stock XC9500 CPLDs... I think
they stock some of Xilinx' FPGAs though.

Later.
--
Phil.
philpem@despammed.com  <<-- Yes, this address is real...
http://www.philpem.dsl.pipex.com/



Article: 49679
Subject: Re: Metastability in FPGAs
From: hmurray@suespammers.org (Hal Murray)
Date: Tue, 19 Nov 2002 06:43:17 -0000
Links: << >>  << T >>  << A >>
>I feel bad now.  I started this thread because I had hoped to get some
>definitive information to take back to a discussion that was hot in
>comp.lang.forth a few days ago.  I had some people over there telling me
>that they could "cure" metastability or that it was dealt with in the
>chips.  There was even one chip designer who told me that you could
>safely "ignore" metastability in modern logic (modern being anything
>smaller than 0.25 um) because of the high settling speeds.  

The only "cure" is to wait long enough so that the MTBF is good enough.
Most of the time, especially with modern silicon, you can get that out
to the age of the universe.

But you have to keep an eye on things, for example to make sure that
the the placer or router doesn't do something silly.

It's only "dealt with in the chips" if the designer thought about it
and did the right thing.  Yes, it is possible/reasonable to have
asynchronous inputs to chips.  But check the spec sheets.  Take
FIFOs for example.  Is write really a noop if the FIFO is full?
What happens if you write to a full FIFO just at the wrong time
relative to a read?  (I think we got burned by this, or maybe we
were just paranoid.)

I don't think you can ignore the issue, at least not "safely".
All that you need to cause problems is for the router to do
something dumb and we all know how often that happens.

Note also that real data is very hard to get.

-- 
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: 49680
Subject: Common sense and pin assignment.
From: chinook@pacific.net.sg (Michael)
Date: 18 Nov 2002 23:00:41 -0800
Links: << >>  << T >>  << A >>
Dear Group

I hope it is the right place to ask this question with so many IC
designers around. I often have to do PCB layout with standard
components and it always makes me wonder, "Why are address bus/ data
bus/ power/ ground pins placed that or this way?"  Take for example
industry standard flash memory 29x010 with oddly placed A10 pin. Or
MIC2550 USB transceiver with mixed up DPLUS and DMINUS pins. I
understand legacy issues and existing packaging constrains. Apart from
this what rules do you follow doing pin assignment?

Many Thanks
NuBe.

Article: 49681
Subject: Re: Metastability in FPGAs
From: hmurray@suespammers.org (Hal Murray)
Date: Tue, 19 Nov 2002 07:19:01 -0000
Links: << >>  << T >>  << A >>
>Denial: Early 70s - Widespread disbelief. Early analyses documenting
>inevitability of problem rejected by skeptical journal editors.
>
>Folk Cures: 70s-80s - Popular pastime: Concoct a “Cure” for the
>problem of “synchronization failure”. Commercial synchronizer
>products.
>
>Reconciliation: 80s-90s - Acceptance of the reality: synchronization
>takes time. Interesting special case solutions.

Sounds about right.

I had friends working at BBN in the early 70s.  They worked on the
Arpanet IMP/TIP.

One of them was out at Washington Univ, St Louis, for a year or so
when much of the early metastability work was going on.  He returned
to BBN as a believer and being a smart/senior hardware guy he spread
the word.

They finally tracked down a nasty bug in the 316 IMP (the second
generation IMP, less expensive than the first generation 516 military
spec version).  It was a "simple" metastability issue in the DMA logic.
A word out of a packet would get dropped or stored in the wrong place
or something nasty like that.

He couldn't convince the designers (Honneywell) it was a problem.
They didn't believe.  It wasn't part of the culture yet.

The software guys ended up hacking around it.  They lined up
a big row of add instructions and computed a cheap checksum
as fast as possible.  Observed reliability of the ARPAnet took
a great step in the right direction.


That was back in the days of TTL, well Schotky.  Nothing was all
that good at metastability.  I remember getting burned when we tried
to save a 1/2 cycle by picking a chip that clocked on the other edge.
That particular chip was real bad at metastability.  Sigh.


In the early/mid 80s, there was a conference in San Francisco.
I took the train up for the metastability session.  One of the guys
on the panel got it all wrong.  I thought John Wakerly (Stanford) did
the best job of explaining things, but I was already a believer so
I'm not sure how much that counts.  I do remember that he shot down
an example or two of "fixes", concluding with "believe me" even if
you can't find the bug in it.  He did mention that he was covering it
in classes so the word was getting out by then.

-- 
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: 49682
Subject: Re: Metastability in FPGAs
From: hmurray@suespammers.org (Hal Murray)
Date: Tue, 19 Nov 2002 07:35:52 -0000
Links: << >>  << T >>  << A >>
Here is an interesting web page by Howard Johnson:
  http://www.chipcenter.com/eexpert/hjohnson/hjohnson020.html

  I think John Wakerly covers a lot of good points about metastability in his
  book Digital Design Principles and Practices, Prentice-Hall, 1990 (ISBN
  0-13-212838-1). He has a nice "ball and hill" description that I find very
  helpful.

I think the ball/hill description is better than the balanced pencil.

Consider two kids on the floor rolling a ball back and forth between
them.  Now put a bump in the middle.  If you roll the ball slowly it
goes half way up the bump and then comes back.  If you roll it fast
enough it goes up and over the bump and down the other side.

If you roll the ball with a speed in the middle, there is some
speed where it will get up to the top of the hill and ballance
there until it falls off.  That's the metastable case.  Note that
there is sure to be some speed that will cause problems.  (Math
geeks have a good term for it - continious functions or something
like that.)

I don't have a good/simple story for why "fixes" don't work.
The runt pulse on the reset is enough to make me very suspicious.

If you start with the ball/hill example, could you fix that so it
couldn't dally on the top?

-- 
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: 49683
Subject: Re: Metastability in FPGAs
From: already5chosen@yahoo.com (Michael S)
Date: 19 Nov 2002 00:37:27 -0800
Links: << >>  << T >>  << A >>
nospam <nospam@please.com> wrote in message news:<653itussjd8u3unrcraov00snerb6e1t7q@4ax.com>...
> already5chosen@yahoo.com (Michael S) wrote:
> 
> >> The 'problem' inside the 386 is almost certainly a race and not
> >> metastability. 
>  
> >Do you think 386EX uses READY# input in multiple state machines
> >without sampling it in one FF ? If it was the case, I would expect the
> >problem to appear much more often then it actually does.
> 
> The timing specs for READY# and signals changing due to the completion of
> the cycle (which occurred because of READY#) are referenced to the same
> clock edge. So READY# is not synchronised with a single FF or everything
> would be delayed by a cycle. 

You assume that output signals are driven by FFs. I think it's not a
case. According to 386EX datasheet RD# Valid Delay is 4 to 30ns, CS#
Valid Delay is 4 to 33ns. Both numbers suggest that signals are driven
by combinatorial logic.
 
> 
> What READY# actually feeds I don't know but you don't need multiple state
> machines to race just multiple FFs which a single state machine has.

When I said multiple state machines I ment multiple FFs.

Article: 49684
Subject: Altera Byteblaster
From: FPGA Design / Logicblock <sales@logicblock.com>
Date: Tue, 19 Nov 2002 08:51:00 GMT
Links: << >>  << T >>  << A >>
We've recently launched a website where you can purchase Altera FPGA related hardware. Currently we offer a byteblaster-compatible programmer. Have a look at www.logicblock.com and mail us if you have 
any enquiries about related products. Products in the pipeline include small evaluation boards and a USB programmer. Bulk discounts are also available. All products are orderable via a secure server and 
shipping is done worldwide.



Article: 49685
Subject: Re: Metastability in FPGAs
From: already5chosen@yahoo.com (Michael S)
Date: 19 Nov 2002 01:08:50 -0800
Links: << >>  << T >>  << A >>
hmurray@suespammers.org (Hal Murray) wrote in message news:<utiom46n1pu6a7@corp.supernews.com>...
> >I have tried to analyze the behaviour of such an analogy in the presence
> >of noise, but I don't have the tools to do it rigorously.  It may well
> >be possible to shorten the metastable time with noise, but I really
> >can't prove it one way or the other.
> 
> Somebody mentioned noise recently, but I'll repeat.  It doesn't work.
> It kicks the system toward the stable point just as often as it helps
> you by kicking the system in the right direction.
> 

As I said above, there is very short time (metastability-catching
set-up time window) when noise has a chance to kicks the system in the
wrong direction.
On the other hand, in the properly designed system there is much
longer time (slack time) when noise might move a node out of
metastability.
According to Xilix estimations metastability-catching set-up time
window is 7 orders of magnitude shorter than typical slack time, so
the negative effect of the noise is negligible relatively to its
positive effect.

Before you start to argue, try to realize that I am not talking about
metastability as a theoretical phenomenon but about metastability as
something which can compromize the correctness of the design.
You are right, noise doesn't reduce the probability of entering
metastable state. However, it does increase a probability of resolving
metastability within a slack time window. If metastability resolved
within a slack time window - nobody care about it. I don't even know
how to detect the case. From the practical point of view the case is
the same as when metastability didn't happen.

Once again, I expect metastability-affected system to performe better
(produce longer MTBF) at higher temperature. I don't know how much
better. I would be glad to see the measurements results. Because Xilix
Lab alredy has a proper setup for the mesurements it must be easy for
them to repeat the tests at -40Deg and at +70Deg. It's all I am asking
for.

Article: 49686
Subject: Re: Metastability in FPGAs
From: already5chosen@yahoo.com (Michael S)
Date: 19 Nov 2002 01:23:07 -0800
Links: << >>  << T >>  << A >>
I don't suggest the noise as a cure for metastability. I only say that
measurements methodology, described in Xilix Lab article is likely to
be affected by the temperature. If Peter Alfke (or his stuff) would be
so kind to repeat the mesurements at lower temperature (-40Deg for
example), I would be pleased to see the results.

rickman <spamgoeshere4@yahoo.com> wrote in message news:<3DD9AE93.E9811DFC@yahoo.com>...
> Michael S wrote:
> > 
> > I feel those "others" were wrong.
> > There is relatively short period of time when noise might move a node
> > into metastability. It's what Xilix calls the metastability-catching
> > set-up time window.
> > The time period during which noise might move a node out of
> > metastability is typically much longer. This period is equal to the
> > timing margin of your design, i.e. the difference between clock period
> > and sum of the normal flip-flop delay, longest wire delay,
> > combinatorial logic delay and the setup time of the next flip-flop. In
> > the other words, the difference between actual clock period and the
> > shortest possible clock period of the design.
> 
> We call that slack time, the difference between the time allowed for a
> given clock controlled path and the actual time needed.  
> 
> 
> > I have no experience in ASIC/Custom chip design, but when designing
> > for FPGA I don't feel good when timing margin of my design is shorter
> > then 500ps. According to Xilinx's estimation the duration of the
> > metastability-catching set-up time window for their chips is 0.03
> > femtoseconds, i.e. 7 orders of magnitude shorter.
> 
> How is the metastable timing window related to the timing slack?  The
> time window is the period in time where the input must be in the
> undefined region of voltage to end up with a metastable internal state
> that lasts long enough to affect the settling time.  The timing slack is
> the amount of extra time that is available for the output to settle
> before it affects any FFs connected to the metastable output.  These are
> two different and unrelated aspects of metastability.  
> 
> 
> > So noise helps, I just don't know how much.
> 
> I don't agree with your analysis, because you make an *assumption* about
> the initial conditions which can lead to metastability, but that is not
> the real issue.  
> 
> The real issue that the knowledge of noise reducing the metastability
> settling time is not useful information.  To be able to use noise as a
> tool, you would have to provide a minimum noise spec.  How can a spec be
> generated of the required spectral characteristics of the noise to
> reduce metastable failures?  
> 
> I think that if you try to answer that question, you will see why noise
> does, in fact, *not* improve metastability recovery times.  
> 
> -- 
> 
> 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: 49687
Subject: Re: Metastability in FPGAs
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Tue, 19 Nov 2002 09:56:43 +0000
Links: << >>  << T >>  << A >>


Hal Murray wrote:

> Here is an interesting web page by Howard Johnson:
>   http://www.chipcenter.com/eexpert/hjohnson/hjohnson020.html
>
>   I think John Wakerly covers a lot of good points about metastability in his
>   book Digital Design Principles and Practices, Prentice-Hall, 1990 (ISBN
>   0-13-212838-1). He has a nice "ball and hill" description that I find very
>   helpful.
>
> I think the ball/hill description is better than the balanced pencil.
>
> Consider two kids on the floor rolling a ball back and forth between
> them.  Now put a bump in the middle.  If you roll the ball slowly it
> goes half way up the bump and then comes back.  If you roll it fast
> enough it goes up and over the bump and down the other side.
>
> If you roll the ball with a speed in the middle, there is some
> speed where it will get up to the top of the hill and ballance
> there until it falls off.  That's the metastable case.  Note that
> there is sure to be some speed that will cause problems.  (Math
> geeks have a good term for it - continious functions or something
> like that.)
>
> I don't have a good/simple story for why "fixes" don't work.
> The runt pulse on the reset is enough to make me very suspicious.
>
> If you start with the ball/hill example, could you fix that so it
> couldn't dally on the top?
>

As an ex maths-geek I'd say you are out of luck. If you plot the "kick energy"
vs. the max outward distance from the kicker we know of 2 points on this curve.
One where the max distance is < the top of the hill and one where its > than the
top. So the theory of continuous functions says that there must be an energy
value where the distance = the top.

So much for maths, now for the issues hidden behind this:

1. Can the kick function take all possible energy values ?

Imagine an FF so sensitive that it flips on receiving  a single electron on its
clock input. Is such a beast possible ? and if so would metatstability rear its
ugly head now in the form of the uncertainty principle ?

2. Is the physical world really continuous in the mathematical sense ?

This is a debate that's been going on for millenia and the modern notion of
mathematical continuity only dates from Dedekind in the 1870s with our present
definitions due, IIRC, to Cauchy a few years later.

Note that even in a quantum mechanical description a particle's wave function is
still assumed to be a continuous solution to the Schroedinger wave equation.


Article: 49688
Subject: Re: Metastability in FPGAs
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Tue, 19 Nov 2002 23:09:29 +1300
Links: << >>  << T >>  << A >>
Hal Murray wrote:
> 
<snip good stuff > 
> If you start with the ball/hill example, could you fix that so it
> couldn't dally on the top?

I've SEEN this in mini golf courses :)

Illustrates the point of gain asymmetry very nicely.

How about bumping the hill ?

Imagine a hill, with the hiccups - what does that do to the maximum
probable ball dally time ?

How to give the hill Hiccups ?

 Well, in a FPGA, one simple technique could be to drive, or not drive,
the surrounding logic, and see if there was any change in metastable
times.
 The bumps would come from the natural ringing in the Vcc.Gnd planes.

 I would like to see temperature plots, not just the Vcc ones as the
assertion Peter A. made of :

"Measurements were taken at room temperature, but testing at VCC 
extremes gives an indication of performance at higher and lower 
temperature."

 I think needs to be tested : Low Temp = faster, but Low temp also
is less thermal noise - which dominates ?

 It may be that the modern FPGAs are powerfull and flexible enough to 
get precision in the measurements, and to see 'better' and 'worse'
directions from stimulus changes.

 Jim G.

Article: 49689
Subject: Re: Programming Altera EPC16
From: Paul Bealing <paul@pmb.co.nz>
Date: Wed, 20 Nov 2002 00:08:30 +1300
Links: << >>  << T >>  << A >>
Markus Fras wrote:
> Hello,
> 
> I'm looking for some advice concerning Altera's EPC16 device. The problem is
> that I'd like to programm it in circuit via JTAG, but it just doesn't work.
> The JTAG chain is o.k., I can successfully scan the chain read the ID code,
> perform a device blank check. Also the programming procedure does not lead
> to an error. But when I try to verify the data it fails at once. I've tried
> with Quartus II V1.1 and Altera's jam-player, both with the same result. As
> download cable I'm using a standard Altera ByteBlasterMV.
> Has anybody an idea, what could be wrong or what I could try to get more
> information about the situation? Any advice is very wellcome - Thanks in
> advance!
> 
> Markus Fras
> 
> 
I recently found that the cable between the programmer and the chip was 
causing errors. I reduced the length and it worked fine, even with 1.5 
meters of round cable between the programmer and the PC parallel port.

Paul Bealing
www.pmb.co.nz


Article: 49690
Subject: What combinational logic will produce a falling edge only.
From: phil_j_connor@hotmail.com (Phil Connor)
Date: 19 Nov 2002 03:56:01 -0800
Links: << >>  << T >>  << A >>
Hi Everyone,

I'm using an fpga with the clock temporarily off and so have only
combinational logic.

Now, in this mode I need to generate a signal which is a falling edge
only. This edge needs to be produced whenever there is any change
(rising or falling) on any one of a set of input signals.

I've got as far as using XOR on all the inputs to produce a toggling
signal but I am now at a loss as to how to convert this to a falling
edge only.

 toggling_output <= A xor B xor C ..........

 falling_edge_only <= ?????

I suspect there is either a simple answer or it is impossible. Anybody
know which?

Solutions that will synthesise in VHDL would be appreciated. My
synthesis tool rejects all my attempts although they simulate
perfectly as a functional models.


Thanks for any pointers

Phil

Article: 49691
Subject: Re: What combinational logic will produce a falling edge only.
From: ae <>
Date: Tue, 19 Nov 2002 04:19:26 -0800
Links: << >>  << T >>  << A >>
I am curious about this as well.  Could you not just write a normal rising edge detector and invert the signal of interest prior to being placed on the input of the edge detector?

Article: 49692
Subject: Small Program for Functinality Test of ApexII
From: vikrampassi@yahoo.com (Vicky)
Date: 19 Nov 2002 04:23:21 -0800
Links: << >>  << T >>  << A >>
Dear all,

   I am designing an PLD using ALtera and now I require a
functionality check to be performed. I have a data from a device
"Serializer Deserilaizer" and this has to be sent to the APEXii and
then received from it for which the functionlaity test has to be
performed. one can also call it a feedthro´ check. I f any one of U
has the prog could u pls share it with me.

Luv
Vicky

Article: 49693
Subject: Re: What combinational logic will produce a falling edge only.
From: veit@borneo.gmd.de (Holger Veit)
Date: 19 Nov 2002 13:26:09 +0100
Links: << >>  << T >>  << A >>
Phil Connor <phil_j_connor@hotmail.com> wrote:
> Hi Everyone,
> 
> I'm using an fpga with the clock temporarily off and so have only
> combinational logic.
> 
> Now, in this mode I need to generate a signal which is a falling edge
> only. This edge needs to be produced whenever there is any change
> (rising or falling) on any one of a set of input signals.
> 
> I've got as far as using XOR on all the inputs to produce a toggling
> signal but I am now at a loss as to how to convert this to a falling
> edge only.
> 
>  toggling_output <= A xor B xor C ..........
> 
>  falling_edge_only <= ?????
> 
> I suspect there is either a simple answer or it is impossible. Anybody
> know which?

simple.

> Solutions that will synthesise in VHDL would be appreciated. My
> synthesis tool rejects all my attempts although they simulate
> perfectly as a functional models.

If "SIG='1' AND NOT SIG'STABLE" (or 'EVENT) is the complete 
conditional expression for the common synthesis shorthand 
"RISING_EDGE(SIG)", what is then the expression 
"SIG='0' AND NOT SIG'STABLE"?

Holger

-- 
Please update your tables to my new e-mail address: 
holger.veit$ais.fhg.de  (replace the '$' with '@'  -- spam-protection)


Article: 49694
Subject: Re: problem with clkdll on spartan2
From: Stefan Kulke <kulke@informatik.tu-cottbus.de>
Date: Tue, 19 Nov 2002 13:53:04 +0100
Links: << >>  << T >>  << A >>
Thanks for the answers!

I know now, that the input Pin GCK0 isnt a clock input in my schematic.
GCK0 => IBUFG => CLKIN from CLKDLL

The follow assignment is in my constraint file:
NET "gck0" LOC = "p80";

If i take this, i will not get a clocksignal.
If i take LOC = "DLL0", then the constraint file editor will overwrite 
it with old value.
If i take LOC = "p187", then the follow error message will appear:
    "ERROR:MapLib:103 - symbol "gck0" (pad signal=gck0) driving 
IBUFG->CLKDLL is
     LOCed to a generic IOB site. It must be LOCed to a GCLKIOB site."

If i have not got:
* a input gck0
   and
* old systemclock (pin 185,
   with 'TIMESPEC "TS_clk_a1" = PERIOD "clk_a1" 48 MHz HIGH 50 %;')
   and
* INST XLXI_15 LOC="DLL3" is in my constraint file
   (without using the editor, i dont know where is this option)
   (XLXI_15 is the instname of ibufg).
then the projectmanager say the ucf-file is corrupt.

Unfortunately the documents ds001_2.pdf and xapp174.pdf dont help me by 
this problem.
The documents can be found in support from xilinx.
I have try many others possibilities, but none were successfully.
I dont know, what i m doing wrongly.

I will be glad, if i can get more informations or answers.


with kind regards

Stefan



Article: 49695
Subject: Re: Metastability in FPGAs
From: Ray Andraka <ray@andraka.com>
Date: Tue, 19 Nov 2002 12:56:18 GMT
Links: << >>  << T >>  << A >>
This is true.  With the pre 4.1i router, you could depend on the router using the
direct path if the flip-flops were located in adjacent slices.  The new router
generally will not use that unless it deems it to be a critical path (which
putting the  from:to spec forces).  The new router apparently selects a few
critical paths based on slack times, nails those down then routes the rest not
caring how much time or resource is used as long as the slack is non-negative.
This is one of the cases where it matters. (BTW, routing the way the router does
it now also increases the power consumption considerably).

Phil Hays wrote:

> Ray Andraka wrote:
>
> > Where slack does come into play with metastability is that your
> > metastability resolution time available is equal to the slack time.  If your
> > path leading from your syncronizer  has little slack, your chances of a
> > metastable event lasting long enough to matter is greatly increased.  You
> > want to maximize the slack after a synchronizer, preferably with
> > geographically close registers with no intervening logic.
>
> I'd also suggest a TO:FROM spec for the path between the syncronizer and
> the next register.  A suggested value would be:
>
> period - needed_extra_delay - jitter_budget
>
> Where the needed_extra_delay is more than enough to meet the MTBF goals
> your design requires.
>
> Without this, the router might send this path round the chip a few times
> until there wasn't enough extra delay, even with registers nearby...
>
> --
> Phil Hays

--
--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: 49696
Subject: Input / Output flop in IOB + Virtex II
From: Anup Kumar Raghavan <anup@itee.uq.edu.au>
Date: Tue, 19 Nov 2002 23:38:40 +1030
Links: << >>  << T >>  << A >>
Hello, can someone point me to how I will be able to instantiate a
Virtex II - IOB component for implementing some logic in the IOB and
use the available registers? I use Leonardo Spectrum for Synthesis and I
know I have an option to Map registers in IOBs. But I want to be able to
do it manually in a vhdl file.

Thanks

Anup




Article: 49697
Subject: Re: Metastability in FPGAs
From: rickman <spamgoeshere4@yahoo.com>
Date: Tue, 19 Nov 2002 10:26:57 -0500
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
> 
> Where slack does come into play with metastability is that your
> metastability resolution time available is equal to the slack time.  If your
> path leading from your syncronizer  has little slack, your chances of a
> metastable event lasting long enough to matter is greatly increased.  You
> want to maximize the slack after a synchronizer, preferably with
> geographically close registers with no intervening logic.
> 
> rickman wrote:
> stuff about slack time not being related to metastability

That is the well understood part of metastability.  I was commenting on
Michael's post which seemed to confuse the very small calculated input
time window which will result in a FF going metastable and slack time
which will provide settling time for the metastability to be resolved to
a defined state.  These are two independant concepts and even though
they are both aspects of metastability, they have nothing to do with one
another.  

-- 

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: 49698
Subject: Re: Metastability in FPGAs
From: rickman <spamgoeshere4@yahoo.com>
Date: Tue, 19 Nov 2002 10:31:51 -0500
Links: << >>  << T >>  << A >>
Hal Murray wrote:
> 
> >I feel bad now.  I started this thread because I had hoped to get some
> >definitive information to take back to a discussion that was hot in
> >comp.lang.forth a few days ago.  I had some people over there telling me
> >that they could "cure" metastability or that it was dealt with in the
> >chips.  There was even one chip designer who told me that you could
> >safely "ignore" metastability in modern logic (modern being anything
> >smaller than 0.25 um) because of the high settling speeds.
> 
> The only "cure" is to wait long enough so that the MTBF is good enough.
> Most of the time, especially with modern silicon, you can get that out
> to the age of the universe.
> 
> But you have to keep an eye on things, for example to make sure that
> the the placer or router doesn't do something silly.
> 
> It's only "dealt with in the chips" if the designer thought about it
> and did the right thing.  Yes, it is possible/reasonable to have
> asynchronous inputs to chips.  But check the spec sheets.  Take
> FIFOs for example.  Is write really a noop if the FIFO is full?
> What happens if you write to a full FIFO just at the wrong time
> relative to a read?  (I think we got burned by this, or maybe we
> were just paranoid.)
> 
> I don't think you can ignore the issue, at least not "safely".
> All that you need to cause problems is for the router to do
> something dumb and we all know how often that happens.
> 
> Note also that real data is very hard to get.

You are preaching to the choir.  The trouble is that it is very hard to
convince people of this when they don't want to believe.  As you say,
there is little data on the subject that does more than show it exists.  

Fortunately it is quite easy to deal with in the vast majority of
designs, as long as you understand that you do *need* to address it.  

-- 

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: 49699
Subject: FPGA to implement Bluetooth baseband
From: tom_robinson6@yahoo.com (Tom)
Date: 19 Nov 2002 08:12:37 -0800
Links: << >>  << T >>  << A >>
I am trying to implement the baseband layer of Bluetooth on an FPGA,
using Xilinx (project navigator) software.
I have produced a simple maximal shift sequence and now want to
Gaussian filter this.
Has anybody used this software to complete this task before? If so
could you offer me any hints or tips on how to start as I'm
clueless, I had never used an FPGA or HDL until last week!
Thanks very much

Tom



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