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 119375

Article: 119375
Subject: Re: clock wide pulse transfer b/w clock domains
From: Newman <newman5382@yahoo.com>
Date: 17 May 2007 11:18:00 -0700
Links: << >>  << T >>  << A >>
On May 17, 9:17 am, Paul <pauljbenn...@gmail.com> wrote:
> Peter,
>
>    I know you folks at Xilinx like to claim that you've permanently
> solved all the world's metastability problems, our xilinx fae tells us
> the same things....   And maybe you're right for telecom applications
> and whatnot.   But I hope you don't support many Hi-rel applications
> because I promise you, no defense or aerospace company is going to
> happy being told they don't need to double register asynchronous
> signals.  Our design guidelines here at unstated defense company
> (sorry, i dont disclose that on the net) are VERY strict about double
> registering ALL asynchronous signals, no questions asked. 2 D-Q
> crossings and nothing else.  Right or wrong, I haven't been in the
> business long enough to know for sure, we view metastability as a
> statistical thing...and like most naturally occurring statistics, zero
> probability tends to never exist, very very very small near zero
> probabilities exist.
>
> At anyrate... yes, I'm well aware of Xilinx's current stand on the
> metastability problem.   But you yourself just said that the problem
> exists for "a few ns" statistically exceeding 3ns once in a universe.
> So lets say 2 ns is something we should design for then....  2ns =
> 500MHz....  What's Xilinx's Fmax these days???  Even if its not a
> problem now, it's soon to become a problem again unless you're going
> to tell me you're done increasing your operating frequencies.
>
> anywho... our view and i believe the view of most of the defense/
> aerospace world is that something as simple as 2 registers is not
> worth ANY impact on system reliability.
>
> On May 16, 5:42 pm, Peter Alfke <p...@xilinx.com> wrote:
>
>
>
> > Maybe this is homework, or it is an interview question, but I took it
> > as a challenge.
> > Being a minimalist, and understanding metastability fairly well, I
> > came up with the following solution:
>
> > Only one 4-input LUT plus a flip-flop clocked by the slow clock.
> > LUT inputs are: INput pulse, slow CLK signal, its own output O, the
> > flip-flop output Q
> > ( set O if Qbar AND INpulse, reset O if Q AND CLKbar, otherwise keep
> > O. O drives flip-flop D)
>
> > Ah, but how about metastability?
> > If IN and CLK both go High within a certain bulls-eye that is <1
> > femtosecond wide, then Q might be undefined for a few ns after the
> > rising clock edge. Statistically, the "few ns" will not exceed 3 ns
> > during the lifetime of the universe. The, hopefully synchronous, slow
> > clock domain should be able to cope with that. Otherwise concatanate
> > another flip-flop.
>
> > Well, I do not know why anybody wants such a circuit, but it did
> > exercise the grey cells...
> > Peter Alfke
>
> > On May 16, 7:09 am, Paul <pauljbenn...@gmail.com> wrote:
>
> > > General rule of thumb is that you want 2 registers to cross between
> > > clock domains, follow that rule to deal with any metastability
> > > issues.  Now you just have the problem that your first clock domain is
> > > faster and you might not catch it with the slower domain.
>
> > > Personally, my approach here would be to "hold" the signal in your
> > > CLK_FAST with an enabled register until you receive some sort of feed
> > > back that you've grabbed it in CLK_SLOW, bearing in mind that those
> > > feedback / feedforward signals should all be double registered to
> > > prevent metastability.  Also keep in mind that an enabled register
> > > does NOT count as one of your two "synchronization" registers, because
> > > an enabled register is actually implemented as a register with a mux
> > > in front of it - only direct D-to-Q connections with NO combinational
> > > logic count for clock domain crossing issues.  Now, depending upon the
> > > timing of it all, this could end you up with more than 1 clock pulse
> > > width.  Assuming that you know your input pulses are spaced far enough
> > > apart that you KNOW it's not ACTUALLY multiple pulses, then a simple
> > > edge detect will fix this problem for ya.
>
> > > The ideal behind the metastability stuff is that if you clock a signal
> > > exactly at the transisition the output of the flop has some
> > > probability of floating somewhere between 0 and 1 for some amount of
> > > time.  Adding any combinatorial logic extends that amount of time.
> > > The idea of having 2 registers is that you reduce your probability of
> > > a metastable event because even if you hit that .01% chance of it
> > > remaining metastable for long enough to create a problem at the first
> > > register, you got another .01% on your side at the second register.
> > > (Note: .01% is much higher than it really is.. but remember, if you're
> > > clocking signals in the MHz range, those tiny probabilities add up
> > > REAL quick!)
>
> > > On May 16, 1:35 am, himassk <hima...@gmail.com> wrote:
>
> > > > Hi,
>
> > > > Please suggest me how to transfer a single clockwide pulse from high
> > > > frequency clock domain and create a single clockwide pulse in a slow
> > > > clock domain?
> > > > What are different methods available?
>
> > > > Thanks in advance.
>
> > > > Regards,
> > > > Himassk.- Hide quoted text -
>
> > - Show quoted text -- Hide quoted text -
>
> - Show quoted text -

Paul,
  I would rate Peter as one of the most knowledgable people in the
area of metastability,  He has published papers and performed
experiments characterizing metastability as Xilinx products have
evolved.  I think you have to take the comment within the context of
what he was explaining, that the circuit could be done with one LUT
and one FF.  As to whether it is worth the trouble of arguing and
guaranteeing that there is enough slack time to all the other FF's is
another story, and adding another stage may be the most expedient
method. He did mention it, and it is probably the way to go for those
of us less knowledgable in this area.

- Newman


Article: 119376
Subject: Re: clock wide pulse transfer b/w clock domains
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 17 May 2007 19:18:27 +0100
Links: << >>  << T >>  << A >>
"Paul" <pauljbennett@gmail.com> wrote in message 
news:1179407855.921375.242960@k79g2000hse.googlegroups.com...
> Peter,
>
> signals.  Our design guidelines here at unstated defense company
> (sorry, i dont disclose that on the net) are VERY strict about double
> registering ALL asynchronous signals, no questions asked. 2 D-Q
> crossings and nothing else.  Right or wrong, I haven't been in the
> business long enough to know for sure, we view metastability as a
> statistical thing...and like most naturally occurring statistics, zero
> probability tends to never exist, very very very small near zero
> probabilities exist.
>
Aha, the common spotted "that's the way we've always done it"! Guess what, 
you should do the maths to work out if you can use 1,2 or maybe more FFs as 
the technology changes rather than relying on what's gone before!
Cheers, Syms.
p.s. Here's a tip for the top, if want your unstated defense company 
employer to stay undisclosed on this, ahem, 'NG', you might consider not 
posting from work. Bless!



Article: 119377
Subject: Re: seeking insights for potential reconfigurable computing application platforms
From: Anne <anneatkinson@yahoo.com>
Date: 17 May 2007 11:24:47 -0700
Links: << >>  << T >>  << A >>
Excellent points, Symon -- things like that sure have happened in the
past!  There is also some focus on "dissimilar spares" in attempts to
mitigate what you describe.
Thank you for the insight!
Anne

On May 16, 4:57 pm, "Symon" <symon_bre...@hotmail.com> wrote:
> "Anne" <anneatkin...@yahoo.com> wrote in message
>
> news:1179331157.808046.24310@y80g2000hsf.googlegroups.com...
>
> > An ultimate goal of this sub-project is to reduce the total number of
> > spare parts that must be flown on a mission by having spares that are
> > reconfigurable such that, for example, they could function as a DSP or
> > microprocessor or microcontroller at any given time (just one specific
> > application at any given time).
>
> Hi Anne,
> Here's a thought. Imagine you make a bunch of identical thingies which can
> be either a dsp, a uP, whatever. Cool, you've reduced the parts inventory.
> You set off on your mission to Mars, and one of these things go wrong.
> However, it turns out this is not a random failure, but a systemic failure
> due to a design fault. (Perhaps the sub-contract designer mixed up imperial
> and metric units?!) This means, because all your replacements are identical,
> they'll all have the same fault. Kinda like the reason that some people
> think GM crops are bad, because a single disease can wipe out an entire
> harvest of a monoculture plant.
> Maybe there's an argument to have a couple (or maybe more) different designs
> of replacement. It's a long trip to Fry's from the red planet!
> Cheers, Syms.



Article: 119378
Subject: Re: VHDL newbie: building sequential circuits with basic gates
From: David R Brooks <davebXXX@iinet.net.au>
Date: Thu, 17 May 2007 10:33:04 -0800
Links: << >>  << T >>  << A >>
cs_posting@hotmail.com wrote:
> On May 17, 12:16 am, GomoX <gomox...@gmail.com> wrote:
>> Hey everyone,
>>
>> As an assignment for a course in my CS degree, I have to build a D
>> latch, a D flip flop and a 1 bit register with VHDL. I have been given
>> the "process" versions of those and I have to rewrite them using
>> elementary gates and feedback connections.
>>
>> My teachers are not really profficient in the topic (sadly) but we are
>> going through hoops to get stuff working. I have read on several pages
>> that because of limitations in VHDL simulations, basic sequential
>> circuits such as the latch/ff should not be implemented with gates but
>> using processes instead.
> 
> Yes, you really don't want to do that.  Looping back a combinatorial
> output makes a sort of infinite loop of dependencies for the simulator
> to try to make sense of.  In the real world it works because of delay
> and capacitance and stuff like that, but an HDL simulator it's not
> designed to do physical modeling of actual devices!   Instead it's
> designed to simulate the application-level behaviour of devices that
> can be reasonably represented with just a few paramaters (like
> propogation delay), and having just a few states, (like 1, 0,
> undriven, and unkown)
> 
> If you want to do something like what you are talking about, try
> playing with software that's designed to simulate the analog behaviour
> of real devices, which is to say spice.  Get yourself some simple
> logic gate circuits to put in a spice deck and play with graphing how
> that responds over time to "digital" inputs.
> 
> 
If you *must* build gate models in VHDL, be sure to include a delay in 
your gate, eg OUT <= not(IN1 and IN2) after 2 ns;

Article: 119379
Subject: Re: DDR 2 Memory controller own implementattion
From: fpgabuilder <fpgabuilder-groups@yahoo.com>
Date: 17 May 2007 11:55:19 -0700
Links: << >>  << T >>  << A >>
On May 17, 12:19 am, sudhakar...@gmail.com wrote:
> Hi to all  ............
>
> Now i am in to developing  DDR2memory contoller with STRATIX II EP2S
> 180 .
> Is there mega core which can support burst length 8 ?I found only
> burst lenth 4 controllers. So i have written and no problem with code.
> I am using DDIO bidirectional mega function  for data path to send and
> receive data on both edges . But problem is  so many set up and Hold
> time violations with this mega function .
> Has any body developed own memory controller for BURST LENTH 8 .
> please help me regarding this ..........
>
> thanks and regrads
> sudhakar

Hi Sudhakar,
Check out http://www.nwlogic.com.  They have cores that are allow
burst of len of 8.  But to get back to you problem, are you seeing
setup and hold time violations in simulation?

-sanjay


Article: 119380
Subject: Re: Power Consumption near Timing Failure Point
From: fpga_toys@yahoo.com
Date: 17 May 2007 12:18:52 -0700
Links: << >>  << T >>  << A >>
Since the OP specifically asked about a window where setup violations
occur, we are looking at metastablity from a different view point than
what is the probability of a metastable event from a random
asynchornous input. First metastability can be induced reliably in the
lab for demostration to students ... we did this in the 1980's, and
here is a current online reference http://www.sigcon.com/Pubs/news/4_4.htm
on how to demonstrate it. Note the key variable in not time or
probability, but a precise window of input voltage.

Metastability can occur any where we have a feedback path in logic,
but it's best understood in terms of FF's. It's generally defined as
an event when a FF continues to oscillate longer than a clock period.
What's particularly wicked about this, is any amount of oscillation
will result in additional dynamic switching power, including periods
less than a full clock period which would create a metastable event by
definition.

Now, if we consider just the switching interval of a CMOS logic gate
output, we have a predictable voltage/time ramp generator between the
two rails. The particular voltage of this ramp is predictable in time
relative to it's clock (or driving input), and by varying the time, we
can predictably produce inputs near/at the metastable input voltage
for the FF.

This is the state we are in with a synchronous system with setup
violations, as the OP specifically questions about. As any number of
inputs to FF's hover around the metastable input voltage, the amount
of oscillation will increase, and increase dynamic power as a
result ... the amount of power increase depends directly on the system
design. If the oscillations occur on high fanout signals with
excessive routing, the switched capacitance will be very high, and
possibly relatively high power will be consumed as compared to normal
operation. Even very small voltage changes in the ramp, as caused by
very small increases in timing delay by die thermal heating, may well
have the possiblity of pushing the ramp voltage closer to the
metastable voltage, so some thermal feedback is quite possible here,
depending on the design.

On May 17, 5:57 am, Paul Leventis <paul.leven...@gmail.com> wrote:
> There is an extremely narrow window of time where metastability occurs
> in a flip-flop, and the window in which prolonged metastability occurs
> (something close to the clock period, for example) is infintessimally
> small.  The chances of having a large number of FFs in a metastable
> state for any appreciable time is essentially nil.

Given the above, please explain why?





Article: 119381
Subject: Re: DDR 2 Memory controller own implementattion
From: Ben Twijnstra <ben.twijnstra@gmail.com>
Date: Thu, 17 May 2007 21:29:47 +0200
Links: << >>  << T >>  << A >>
sudhakarmvs@gmail.com wrote:

The Microtronix DDR core apparently is ble to handle BLEN=8. It's also very
robust when it comes to setup&hold.

Have a look at the FPGA Products page of wwww.microtronix.com

Best regards,


Ben


Article: 119382
Subject: Mobile DDR vs DDR2
From: fpgabuilder <fpgabuilder-groups@yahoo.com>
Date: 17 May 2007 12:35:00 -0700
Links: << >>  << T >>  << A >>
Hi Folks,

I need to put in DDR or DD2 interfaces.  I need about 1.2GB/s
bandwidth.  As I am targetting a low end fpga, I am limited by the max
bitrate on the i/o.  (DDR333 or DDR2-400).

What will be a better alternative go with DDR333 or DDR2-400?  My main
considerations are - power and ability to hide the latencies during
accesses.  From what I see on the usual memory vendors -

1. Mobile DDR available in x32 organization in one package
2. DDR2 available in x16 but significantly lower power at IDD7.

I would love to hear your thoughts.

Thank you.
Best regards,
Sanjay


Article: 119383
Subject: video soltion provider
From: M Ihsan Baig <mirzamihsan@hotmail.com>
Date: 17 May 2007 12:53:36 -0700
Links: << >>  << T >>  << A >>
Hello, Is there any expert who can guide me about the following
problem:

I need video system with following main specifications.
1) Input : standard video formats
2) compression: MPEG4/MPEG2 etc.
3) Output: RS232
4) Decoder: Soft decoder in PC

Is there any company who offers customized solutions in this area.
Thanks


Article: 119384
Subject: SystemC and TLM
From: confusedpp@gmail.com
Date: 17 May 2007 13:11:07 -0700
Links: << >>  << T >>  << A >>
Dear all,
Thank you for your patience...
I have looked up on the web and read quite a few articles but I am
still very confused re SystemC and TLM.
My understanding is that TLM allows you to model at an appropriate
level for what you want to do (communication and functional are
separated, timed and untimed detail for either possible).
However, I don't understand where TLMs go.
Say I have an architectural model in software - call it arch.  I have
a hardware RTL model for an FPGA.
I want arch to call up hardware.  Is the TLM used between arch and
hardware?  When the person's developing arch, is hardware replaced by
its equivalent TLM?

And, more fundamentally - is TLM just an abstract idea?  I mean, if
we
have to create another model (now called a TLM), why give it another
special name?  Isn't it just another block of SystemC?


I hope that you can help in some way, even if only to refer to some
online explanations or suggest another newsgroup.


regards,
confused


Article: 119385
Subject: Re: clock wide pulse transfer b/w clock domains
From: Paul <pauljbennett@gmail.com>
Date: 17 May 2007 13:13:01 -0700
Links: << >>  << T >>  << A >>
I am not trying to teach anyone anything, I have read many of your
documents and I realize you are a very informed source.  I apologize
if you took my comments any differently.  I simply wanted to point out
that if our initialer poster is eventually going to be working in a hi-
rel industry they very likely may be required to treat this as a
potential problem - whether or not it is necessarily proven by current
studies.  If you read my comments, I openly noted that I do not have a
wealth of experience but that in practice this is often the case in
such industries.  I claim to have no knowledge beyond that, nor did I
previously make that claim.  And I certainly did not question your
expertise in the area, I apologize if it came across that way.




On May 17, 1:24 pm, Peter Alfke <p...@xilinx.com> wrote:
> Paul, you don't have to teach me about the dangers of metastability. I
> am the one who has performed lots of quantitative measurements. But I
> am also fighting any un-qualified paranoia.
>
> In this particular design I pointed out that the effect of
> metastability is an uncontrollable statistical delay on the output of
> the flip-flop that, per description, is clocked by the "slow clock".
> I wrote that the "slow clock" domain probably has enough slack to
> accomodate a few ns of uncontrollable delay at the flip-flop output.
> "Slow clock"  does not mean 500 MHz, in my book.
>
> I know what I am talking about, and I was forthcoming and explicit.
> This was a specific circuit, no need to bombard me with
> generalities.
>
> And for the record:
> Xilinx and I personally have NEVER EVER claimed to have solved the
> metastability problem. Because we all known that to be impossible. I
> have just, quite often, quantified the probabilities.
>
> BTW: I consider your posting ill-informed, offensive and slanderous.
> Peter Alfke
>
> ==============
> On May 17, 6:17 am, Paul <pauljbenn...@gmail.com> wrote:
>
>
>
> > Peter,
>
> >    I know you folks at Xilinx like to claim that you've permanently
> > solved all the world's metastability problems, our xilinx fae tells us
> > the same things....   And maybe you're right for telecom applications
> > and whatnot.   But I hope you don't support many Hi-rel applications
> > because I promise you, no defense or aerospace company is going to
> > happy being told they don't need to double register asynchronous
> > signals.  Our design guidelines here at unstated defense company
> > (sorry, i dont disclose that on the net) are VERY strict about double
> > registering ALL asynchronous signals, no questions asked. 2 D-Q
> > crossings and nothing else.  Right or wrong, I haven't been in the
> > business long enough to know for sure, we view metastability as a
> > statistical thing...and like most naturally occurring statistics, zero
> > probability tends to never exist, very very very small near zero
> > probabilities exist.
>
> > At anyrate... yes, I'm well aware of Xilinx's current stand on the
> > metastability problem.   But you yourself just said that the problem
> > exists for "a few ns" statistically exceeding 3ns once in a universe.
> > So lets say 2 ns is something we should design for then....  2ns =
> > 500MHz....  What's Xilinx's Fmax these days???  Even if its not a
> > problem now, it's soon to become a problem again unless you're going
> > to tell me you're done increasing your operating frequencies.
>
> > anywho... our view and i believe the view of most of the defense/
> > aerospace world is that something as simple as 2 registers is not
> > worth ANY impact on system reliability.
>
> > On May 16, 5:42 pm, Peter Alfke <p...@xilinx.com> wrote:
>
> > > Maybe this is homework, or it is an interview question, but I took it
> > > as a challenge.
> > > Being a minimalist, and understanding metastability fairly well, I
> > > came up with the following solution:
>
> > > Only one 4-input LUT plus a flip-flop clocked by the slow clock.
> > > LUT inputs are: INput pulse, slow CLK signal, its own output O, the
> > > flip-flop output Q
> > > ( set O if Qbar AND INpulse, reset O if Q AND CLKbar, otherwise keep
> > > O. O drives flip-flop D)
>
> > > Ah, but how about metastability?
> > > If IN and CLK both go High within a certain bulls-eye that is <1
> > > femtosecond wide, then Q might be undefined for a few ns after the
> > > rising clock edge. Statistically, the "few ns" will not exceed 3 ns
> > > during the lifetime of the universe. The, hopefully synchronous, slow
> > > clock domain should be able to cope with that. Otherwise concatanate
> > > another flip-flop.
>
> > > Well, I do not know why anybody wants such a circuit, but it did
> > > exercise the grey cells...
> > > Peter Alfke
>
> > > On May 16, 7:09 am, Paul <pauljbenn...@gmail.com> wrote:
>
> > > > General rule of thumb is that you want 2 registers to cross between
> > > > clock domains, follow that rule to deal with any metastability
> > > > issues.  Now you just have the problem that your first clock domain is
> > > > faster and you might not catch it with the slower domain.
>
> > > > Personally, my approach here would be to "hold" the signal in your
> > > > CLK_FAST with an enabled register until you receive some sort of feed
> > > > back that you've grabbed it in CLK_SLOW, bearing in mind that those
> > > > feedback / feedforward signals should all be double registered to
> > > > prevent metastability.  Also keep in mind that an enabled register
> > > > does NOT count as one of your two "synchronization" registers, because
> > > > an enabled register is actually implemented as a register with a mux
> > > > in front of it - only direct D-to-Q connections with NO combinational
> > > > logic count for clock domain crossing issues.  Now, depending upon the
> > > > timing of it all, this could end you up with more than 1 clock pulse
> > > > width.  Assuming that you know your input pulses are spaced far enough
> > > > apart that you KNOW it's not ACTUALLY multiple pulses, then a simple
> > > > edge detect will fix this problem for ya.
>
> > > > The ideal behind the metastability stuff is that if you clock a signal
> > > > exactly at the transisition the output of the flop has some
> > > > probability of floating somewhere between 0 and 1 for some amount of
> > > > time.  Adding any combinatorial logic extends that amount of time.
> > > > The idea of having 2 registers is that you reduce your probability of
> > > > a metastable event because even if you hit that .01% chance of it
> > > > remaining metastable for long enough to create a problem at the first
> > > > register, you got another .01% on your side at the second register.
> > > > (Note: .01% is much higher than it really is.. but remember, if you're
> > > > clocking signals in the MHz range, those tiny probabilities add up
> > > > REAL quick!)
>
> > > > On May 16, 1:35 am, himassk <hima...@gmail.com> wrote:
>
> > > > > Hi,
>
> > > > > Please suggest me how to transfer a single clockwide pulse from high
> > > > > frequency clock domain and create a single clockwide pulse in a slow
> > > > > clock domain?
> > > > > What are different methods available?
>
> > > > > Thanks in advance.
>
> > > > > Regards,
> > > > > Himassk.- Hide quoted text -
>
> > > - Show quoted text -- Hide quoted text -
>
> - Show quoted text -



Article: 119386
Subject: Re: clock wide pulse transfer b/w clock domains
From: Peter Alfke <peter@xilinx.com>
Date: 17 May 2007 13:25:39 -0700
Links: << >>  << T >>  << A >>
Paul,
apologies are accepted.
In the future, when you admittedly are a novice, then do not start a
posting with an obnoxious statement, like:

"Peter,
   I know you folks at Xilinx like to claim that you've permanently
solved all the world's metastability problems, our xilinx fae tells
us
the same things...."

You seem to say that blindly obeying rules is more important than
thinking.
I am glad I do not work in such an environment.
Peter


Article: 119387
Subject: Re: clock wide pulse transfer b/w clock domains
From: "John_H" <newsgroup@johnhandwork.com>
Date: Thu, 17 May 2007 13:39:53 -0700
Links: << >>  << T >>  << A >>
Paul,

To paraphrase your original post.

"While you try to appear like you're not charlatans and yet 'solved the 
world's woes' and while some non-essential technologies might allow shoddy 
design practices you better not try to pass your lies on to those of us 
involved with 'real' technology who know better from experience."

If you honestly intended no insult, you did an absurdly poor job of 
communicating your intent.  Perhaps in the future it would be better to 
reread what you write, trying to look at the post from the perspective of 
someone else.  The best thing would be to set the post aside for a few days 
before rereading it or have someone else read it to make sure your thoughts 
are communicated effectively; but since neither of those luxuries may be 
available or appropriate, please try to catch yourself before you disturb 
others - many more than the person you're attacking.  Sorry... "responding 
to."

Since it's already sent, set the post aside for a few days.  If, next week, 
you can reread your response and believe that you were level-headed in your 
response with no assertion of "greater knowledge" and no appearance of 
belittling the author you were responding to... then there's no hope.  If 
you can see why others reacted poorly to your diatribe, you have a chance to 
avoid the extreme - and unintended - positions you portray.

Good luck and thanks for clarifying your viewpoint.

- John_H


"Paul" <pauljbennett@gmail.com> wrote in message 
news:1179432781.443392.211590@w5g2000hsg.googlegroups.com...
>I am not trying to teach anyone anything, I have read many of your
> documents and I realize you are a very informed source.  I apologize
> if you took my comments any differently.  I simply wanted to point out
> that if our initialer poster is eventually going to be working in a hi-
> rel industry they very likely may be required to treat this as a
> potential problem - whether or not it is necessarily proven by current
> studies.  If you read my comments, I openly noted that I do not have a
> wealth of experience but that in practice this is often the case in
> such industries.  I claim to have no knowledge beyond that, nor did I
> previously make that claim.  And I certainly did not question your
> expertise in the area, I apologize if it came across that way.

<snip>

>> On May 17, 6:17 am, Paul <pauljbenn...@gmail.com> wrote:
>>
>>
>>
>> > Peter,
>>
>> >    I know you folks at Xilinx like to claim that you've permanently
>> > solved all the world's metastability problems, our xilinx fae tells us
>> > the same things....   And maybe you're right for telecom applications
>> > and whatnot.   But I hope you don't support many Hi-rel applications
>> > because I promise you, no defense or aerospace company is going to
>> > happy being told they don't need to double register asynchronous
>> > signals.  Our design guidelines here at unstated defense company
>> > (sorry, i dont disclose that on the net) are VERY strict about double
>> > registering ALL asynchronous signals, no questions asked. 2 D-Q
>> > crossings and nothing else.  Right or wrong, I haven't been in the
>> > business long enough to know for sure, we view metastability as a
>> > statistical thing...and like most naturally occurring statistics, zero
>> > probability tends to never exist, very very very small near zero
>> > probabilities exist.
>>
>> > At anyrate... yes, I'm well aware of Xilinx's current stand on the
>> > metastability problem.   But you yourself just said that the problem
>> > exists for "a few ns" statistically exceeding 3ns once in a universe.
>> > So lets say 2 ns is something we should design for then....  2ns =
>> > 500MHz....  What's Xilinx's Fmax these days???  Even if its not a
>> > problem now, it's soon to become a problem again unless you're going
>> > to tell me you're done increasing your operating frequencies.
>>
>> > anywho... our view and i believe the view of most of the defense/
>> > aerospace world is that something as simple as 2 registers is not
>> > worth ANY impact on system reliability.



Article: 119388
Subject: Proper/recommended method for driving clock out from FPGA
From: "bwilson79@gmail.com" <bwilson79@gmail.com>
Date: 17 May 2007 13:52:12 -0700
Links: << >>  << T >>  << A >>
I've inherited a design at my new company where there are two source-
synchronous interfaces at 80MHz SDR.  On one interface a clock
(tx_clk) is forwarded to the FPGA and on the other the clock (rx_clk)
is forwarded from the FPGA.  rx_clk is generated from taking tx_clk
through an IBUF, BUFG, and finally an OBUF to the pad.  These are
single-ended LVCMOS25 clocks and the device is a Xilinx Virtex-4 LX80-
FF1148-10.  The entire system is synchronous to tx_clk.

At my previous company, it was generally a rule of thumb to use a DDR
IOB register to regenerate the clock when sending it out from the
FPGA.  Is this typically a good rule to follow, and, if so, is this
written in some documentation?

Thanks for any help!


Article: 119389
Subject: Visio logic symbols
From: Richard Henry <pomerado@hotmail.com>
Date: 17 May 2007 14:11:06 -0700
Links: << >>  << T >>  << A >>
Does anyone know of a location from which to download simple logic
symbol shapes for Visio (and gate, or gate, etc)?


Article: 119390
Subject: Re: Proper/recommended method for driving clock out from FPGA
From: Kevin Neilson <kevin_neilson@removethiscomcast.net>
Date: Thu, 17 May 2007 15:15:59 -0600
Links: << >>  << T >>  << A >>
bwilson79@gmail.com wrote:
> I've inherited a design at my new company where there are two source-
> synchronous interfaces at 80MHz SDR.  On one interface a clock
> (tx_clk) is forwarded to the FPGA and on the other the clock (rx_clk)
> is forwarded from the FPGA.  rx_clk is generated from taking tx_clk
> through an IBUF, BUFG, and finally an OBUF to the pad.  These are
> single-ended LVCMOS25 clocks and the device is a Xilinx Virtex-4 LX80-
> FF1148-10.  The entire system is synchronous to tx_clk.
> 
> At my previous company, it was generally a rule of thumb to use a DDR
> IOB register to regenerate the clock when sending it out from the
> FPGA.  Is this typically a good rule to follow, and, if so, is this
> written in some documentation?
> 
> Thanks for any help!
> 
Using the DDR registers is the recommended way to regenerate the clock. 
  It will be source-synchronous with the output data, provided that the 
output data is registered in the output IOBs.  This scheme removes the 
variables of BUFG delay times and fabric routing delays.  Note that your 
output rx_clk will not be phase-aligned with tx_clock.
-Kevin

Article: 119391
Subject: Re: Power Consumption near Timing Failure Point
From: Paul Leventis <paul.leventis@gmail.com>
Date: 17 May 2007 14:18:42 -0700
Links: << >>  << T >>  << A >>
> Given the above, please explain why?

The edges during transition inside FPGA are fairly sharp, therefore
there is a very short window in which the arrival of the clock could
cause a FF to go metastable.  And since this window of opportunity is
small and the arrival time of transistions to the various flops in a
design has some spread to it, it is very unlikely that many FF would
be metastable at the same time.

- Paul




Article: 119392
Subject: Re: Proper/recommended method for driving clock out from FPGA
From: "John_H" <newsgroup@johnhandwork.com>
Date: Thu, 17 May 2007 14:20:43 -0700
Links: << >>  << T >>  << A >>
<bwilson79@gmail.com> wrote in message 
news:1179435132.737655.222610@e65g2000hsc.googlegroups.com...
> I've inherited a design at my new company where there are two source-
> synchronous interfaces at 80MHz SDR.  On one interface a clock
> (tx_clk) is forwarded to the FPGA and on the other the clock (rx_clk)
> is forwarded from the FPGA.  rx_clk is generated from taking tx_clk
> through an IBUF, BUFG, and finally an OBUF to the pad.  These are
> single-ended LVCMOS25 clocks and the device is a Xilinx Virtex-4 LX80-
> FF1148-10.  The entire system is synchronous to tx_clk.
>
> At my previous company, it was generally a rule of thumb to use a DDR
> IOB register to regenerate the clock when sending it out from the
> FPGA.  Is this typically a good rule to follow, and, if so, is this
> written in some documentation?
>
> Thanks for any help!

I haven't come across specific documentation saying "do this!"

The desire to use the same structures as those that generate the data comes 
down to error budgets.  If you can guarantee that the clock and data are 
always in a valid relationship with the delivered source-synchronous 
communication channel, it doesn't matter which method you use.  Since it's 
significantly easier to deliver *matched* delays for the DDR-generated 
clock, the error budget has significantly lower uncertainty than the 
combinatorial path.

The skew can be a large factor in the overall error budget depending on the 
receiver.  While a clock edge centered precisely between the data edges 
might seem like the best solution from an oscilloscope's perspective, having 
the clock preceed the data output and encounter a route onto the receiver 
chip that's longer than the data path to the chip's innards might be a 
better match overall.

I'd suggest there's no "correct" way to cover all bases, just a "better" way 
for the specific transmit/receive pair characteristics.

Personally, I DDR all my generated clocks.

- John_H 



Article: 119393
Subject: Re: clock wide pulse transfer b/w clock domains
From: Eric Brombaugh <ebrombaugh.invalid.@earthlink.net>
Date: Thu, 17 May 2007 21:26:56 GMT
Links: << >>  << T >>  << A >>

http://idioms.thefreedictionary.com/teach+grandmother+to+suck+eggs

;)

Eric

Paul wrote:
> Peter,
> 
>    I know you folks at Xilinx like to claim that you've permanently
> solved all the world's metastability problems, our xilinx fae tells us
> the same things....   And maybe you're right for telecom applications
> and whatnot.   But I hope you don't support many Hi-rel applications
> because I promise you, no defense or aerospace company is going to
> happy being told they don't need to double register asynchronous
> signals.  Our design guidelines here at unstated defense company
> (sorry, i dont disclose that on the net) are VERY strict about double
> registering ALL asynchronous signals, no questions asked. 2 D-Q
> crossings and nothing else.  Right or wrong, I haven't been in the
> business long enough to know for sure, we view metastability as a
> statistical thing...and like most naturally occurring statistics, zero
> probability tends to never exist, very very very small near zero
> probabilities exist.
> 
> At anyrate... yes, I'm well aware of Xilinx's current stand on the
> metastability problem.   But you yourself just said that the problem
> exists for "a few ns" statistically exceeding 3ns once in a universe.
> So lets say 2 ns is something we should design for then....  2ns =
> 500MHz....  What's Xilinx's Fmax these days???  Even if its not a
> problem now, it's soon to become a problem again unless you're going
> to tell me you're done increasing your operating frequencies.
> 
> anywho... our view and i believe the view of most of the defense/
> aerospace world is that something as simple as 2 registers is not
> worth ANY impact on system reliability.
> 
> 
> 
> On May 16, 5:42 pm, Peter Alfke <p...@xilinx.com> wrote:
>> Maybe this is homework, or it is an interview question, but I took it
>> as a challenge.
>> Being a minimalist, and understanding metastability fairly well, I
>> came up with the following solution:
>>
>> Only one 4-input LUT plus a flip-flop clocked by the slow clock.
>> LUT inputs are: INput pulse, slow CLK signal, its own output O, the
>> flip-flop output Q
>> ( set O if Qbar AND INpulse, reset O if Q AND CLKbar, otherwise keep
>> O. O drives flip-flop D)
>>
>> Ah, but how about metastability?
>> If IN and CLK both go High within a certain bulls-eye that is <1
>> femtosecond wide, then Q might be undefined for a few ns after the
>> rising clock edge. Statistically, the "few ns" will not exceed 3 ns
>> during the lifetime of the universe. The, hopefully synchronous, slow
>> clock domain should be able to cope with that. Otherwise concatanate
>> another flip-flop.
>>
>> Well, I do not know why anybody wants such a circuit, but it did
>> exercise the grey cells...
>> Peter Alfke
>>
>> On May 16, 7:09 am, Paul <pauljbenn...@gmail.com> wrote:
>>
>>
>>
>>> General rule of thumb is that you want 2 registers to cross between
>>> clock domains, follow that rule to deal with any metastability
>>> issues.  Now you just have the problem that your first clock domain is
>>> faster and you might not catch it with the slower domain.
>>> Personally, my approach here would be to "hold" the signal in your
>>> CLK_FAST with an enabled register until you receive some sort of feed
>>> back that you've grabbed it in CLK_SLOW, bearing in mind that those
>>> feedback / feedforward signals should all be double registered to
>>> prevent metastability.  Also keep in mind that an enabled register
>>> does NOT count as one of your two "synchronization" registers, because
>>> an enabled register is actually implemented as a register with a mux
>>> in front of it - only direct D-to-Q connections with NO combinational
>>> logic count for clock domain crossing issues.  Now, depending upon the
>>> timing of it all, this could end you up with more than 1 clock pulse
>>> width.  Assuming that you know your input pulses are spaced far enough
>>> apart that you KNOW it's not ACTUALLY multiple pulses, then a simple
>>> edge detect will fix this problem for ya.
>>> The ideal behind the metastability stuff is that if you clock a signal
>>> exactly at the transisition the output of the flop has some
>>> probability of floating somewhere between 0 and 1 for some amount of
>>> time.  Adding any combinatorial logic extends that amount of time.
>>> The idea of having 2 registers is that you reduce your probability of
>>> a metastable event because even if you hit that .01% chance of it
>>> remaining metastable for long enough to create a problem at the first
>>> register, you got another .01% on your side at the second register.
>>> (Note: .01% is much higher than it really is.. but remember, if you're
>>> clocking signals in the MHz range, those tiny probabilities add up
>>> REAL quick!)
>>> On May 16, 1:35 am, himassk <hima...@gmail.com> wrote:
>>>> Hi,
>>>> Please suggest me how to transfer a single clockwide pulse from high
>>>> frequency clock domain and create a single clockwide pulse in a slow
>>>> clock domain?
>>>> What are different methods available?
>>>> Thanks in advance.
>>>> Regards,
>>>> Himassk.- Hide quoted text -
>> - Show quoted text -
> 
> 

Article: 119394
Subject: Re: Visio logic symbols
From: "scada" <scada@optonline.net>
Date: Thu, 17 May 2007 17:33:09 -0400
Links: << >>  << T >>  << A >>
I have Visio 2003, a search for gates bought it all up.


"Richard Henry" <pomerado@hotmail.com> wrote in message
news:1179436266.635156.169680@n59g2000hsh.googlegroups.com...
> Does anyone know of a location from which to download simple logic
> symbol shapes for Visio (and gate, or gate, etc)?
>



Article: 119395
Subject: Re: Power Consumption near Timing Failure Point
From: fpga_toys@yahoo.com
Date: 17 May 2007 14:34:02 -0700
Links: << >>  << T >>  << A >>
On May 17, 3:18 pm, Paul Leventis <paul.leven...@gmail.com> wrote:
> > Given the above, please explain why?
>
> The edges during transition inside FPGA are fairly sharp, therefore
> there is a very short window in which the arrival of the clock could
> cause a FF to go metastable.  And since this window of opportunity is
> small and the arrival time of transistions to the various flops in a
> design has some spread to it, it is very unlikely that many FF would
> be metastable at the same time.
>
> - Paul


And they are all very sharp independent of fanout?


Article: 119396
Subject: Re: SystemC and TLM
From: "HT-Lab" <hans64@ht-lab.com>
Date: Thu, 17 May 2007 21:38:28 GMT
Links: << >>  << T >>  << A >>

<confusedpp@gmail.com> wrote in message 
news:1179432667.625797.158110@l77g2000hsb.googlegroups.com...
> Dear all,
> Thank you for your patience...
> I have looked up on the web and read quite a few articles but I am
> still very confused re SystemC and TLM.
> My understanding is that TLM allows you to model at an appropriate
> level for what you want to do (communication and functional are
> separated, timed and untimed detail for either possible).

Correct, just think of TLM as a function call, so for example instead of 
changing address, assert read strobe and then read the data you would just 
issue a function called say read_data(address). The advantage is that your 
simulator has to schedule far less events and thus should run a lot quicker.

> However, I don't understand where TLMs go.
> Say I have an architectural model in software - call it arch.  I have
> a hardware RTL model for an FPGA.
> I want arch to call up hardware.  Is the TLM used between arch and
> hardware?  When the person's developing arch, is hardware replaced by
> its equivalent TLM?

yes, TLM sits between arch and your hardware, to be more precise, your 
hardware is connected to an adaptor which translates pins wiggles to TLM 
function calls.

>
> And, more fundamentally - is TLM just an abstract idea?  I mean, if
> we
> have to create another model (now called a TLM), why give it another
> special name?  Isn't it just another block of SystemC?

Yes, you could see it like that. TLM is just another model/block of 
concurrent processes communicating using functions calls.

Download the SCV library and have a look at some of the examples, they might 
explain things better.

>
> I hope that you can help in some way, even if only to refer to some
> online explanations or suggest another newsgroup.
>

Try the SystemC forum https://www.systemc.org/forum/forum.php?forum_id=5 
were a lot of the Doulos experts hang around :-)

>
> regards,
> confused

I am also still confused on a lot of SystemC (and C++) stuff....

Hans
www.ht-lab.com








Article: 119397
Subject: Re: Power Consumption near Timing Failure Point
From: fpga_toys@yahoo.com
Date: 17 May 2007 15:00:19 -0700
Links: << >>  << T >>  << A >>
On May 17, 3:18 pm, Paul Leventis <paul.leven...@gmail.com> wrote:
> > Given the above, please explain why?
>
> The edges during transition inside FPGA are fairly sharp, therefore
> there is a very short window in which the arrival of the clock could
> cause a FF to go metastable.  And since this window of opportunity is
> small and the arrival time of transistions to the various flops in a
> design has some spread to it, it is very unlikely that many FF would
> be metastable at the same time.

Thanks Paul. It's simple enough to verify with a worst case design
that exploits worst case switching power (from the oscillations) from
a small number of driving FF's located in areas with relatively low
clock skew, and constructed with worst case fanout to slow down the
switching speed. Next time I'm near a large Altera FPGA and software
in the lab with some time to spend, I'll give it a try.


Article: 119398
Subject: Re: Power Consumption near Timing Failure Point
From: fpga_toys@yahoo.com
Date: 17 May 2007 15:22:17 -0700
Links: << >>  << T >>  << A >>
One other question Paul ... do the Altera/Xilinx parts have any
problems with cut thru power (top and bottom transistors on at same
time) in any worst case situations related to setup violations, clock
rate, or fanout?


Article: 119399
Subject: Re: Visio logic symbols
From: Richard Henry <pomerado@hotmail.com>
Date: 17 May 2007 15:26:59 -0700
Links: << >>  << T >>  << A >>
On May 17, 2:33 pm, "scada" <s...@optonline.net> wrote:
> I have Visio 2003, a search for gates bought it all up.
>
> "Richard Henry" <pomer...@hotmail.com> wrote in message
>
> news:1179436266.635156.169680@n59g2000hsh.googlegroups.com...
>
>
>
> > Does anyone know of a location from which to download simple logic
> > symbol shapes for Visio (and gate, or gate, etc)?- Hide quoted text -
>
> - Show quoted text -

I have 2003, Standard Version.  I don't see any place to search for
shpes.




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