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 49650

Article: 49650
Subject: Re: Metastability in FPGAs
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Tue, 19 Nov 2002 10:35:49 +1300
Links: << >>  << T >>  << A >>
rickman wrote:
> 
<snip>
> An analogy is a pencil balanced on its rounded eraser end (I used to say
> a perfectly sharp point, but some started to argue about how sharp it
> could be before quantum mechanics kicked in... jeeeez!). 

They may have been more relevant ( to the point :) than they realised..

> Like a switching FF, it will take some time to go to a stable state.  But it
> can be just close enough to the perfect balance point that it might take
> a while to move off center.  The closer to the balance point, the longer
> it can take, so there is no maximum metastable time.

 I'm not sure this assertion can apply forever. 
See Peter A's notes on metastable times, that
reflected to very narrow time windows, and working that to a 
Wave-transit time, you get less than the order of a gate-length.

 Given this extremely short physical equivalence, it opens the idea of
a triple register, using traces as delay lines, and then taking a vote
of the outputs on the basis that all 3 cannot have the same metastable
lifetimes.

 I did ask if anyone knew how many electrons were 'active' in this time
window, but it must start to get quantized by electron charge at some
point.

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

Thermal noise maybe, it's hard to see how electrical noise will help, 
due to the very narrow effective windows.

-jg

Article: 49651
Subject: Re: Metastability in FPGAs
From: hmurray@suespammers.org (Hal Murray)
Date: Mon, 18 Nov 2002 21:59:32 -0000
Links: << >>  << T >>  << A >>
>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.

When metastability was first becoming known to the design world,
there was a flurry of "fixes" proposed.  All are bogus, bordering
on snakeoil.  The classic is a few gates to detect the metastable
state and reset the FF.  That's a recipe for runt pulses which puts
you right back where you started.

Basically, you have to believe in metastability.  Once you do that,
then you can stop paying attention to noise and kludges.

-- 
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: 49652
Subject: Re: Metastability in FPGAs
From: hmurray@suespammers.org (Hal Murray)
Date: Mon, 18 Nov 2002 22:44:54 -0000
Links: << >>  << T >>  << A >>
> Given this extremely short physical equivalence, it opens the idea of
>a triple register, using traces as delay lines, and then taking a vote
>of the outputs on the basis that all 3 cannot have the same metastable
>lifetimes.

That sounds like one of the kludges I was talking about.

What do you do if one path says 0, the other says 1, and the third
goes metastable?

You can't "fix" metastability.  Get suspicious when somebody tries,
or appears to be trying.  It means they don't understand it.


As Peter often says, you can make things good enough, especially
with modern silicon.  But the basic mechanism is still exponential
decay.

-- 
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: 49653
Subject: Re: Metastability in FPGAs
From: already5chosen@yahoo.com (Michael S)
Date: 18 Nov 2002 14:46:30 -0800
Links: << >>  << T >>  << A >>
Bob Perlman <bobsrefusebin@hotmail.com> wrote in message news:<q80ituogem7vbhnoard9tm0bdlalsa84ev@4ax.com>...
> On 18 Nov 2002 06:43:15 -0800, already5chosen@yahoo.com (Michael S)
> wrote:
> 
> >I never studied the theory of metastable flip-flops. But intuitively I
> >see metastable state as a very small local minimum on the energy
> >curve. At the higher temperature the thermal noise can be strong
> >enough to rescue the flip-flop out of this state to the stable one.
> >It's all my speculations, may be, I erroneously apply the lows of
> >microworld lows to the macroworld phenomenon ?
> 
> Back when the phenomenon of metastability was first observed and
> discussed, some people suggested that metastable behavior could be
> circumvented, or at least improved, by injecting noise that would move
> the offending device away from its metastable point.  But others
> pointed out that while noise might move a node out of metastability,
> it was equally likely that noise would move an almost-metastable node
> into metastability.
> 
> Bob Perlman
> Cambrian Design Works


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.

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.

So noise helps, I just don't know how much.

Article: 49654
Subject: Re: cpld pin configuration is wrongly assigned
From: Dennis McCrohan <mccrohan@xilinx.com>
Date: Mon, 18 Nov 2002 14:48:57 -0800
Links: << >>  << T >>  << A >>
suchitra wrote:

> hello all
> I am programming XC9536 xl cpld using webpack's impact for the first time.
> When i programme the cpld it doesnot give any error or warning.
> But actually i am not achieving the functionality.
> May be because of wrong pin assignment or some other problem.
> Can any one of u guide me.

Your problem description is vague enough that it's going to be hard for anyone
to offer much help... but here it goes:

1. Why do you say you are not achieving the desired functionality? Are you
just putting the part in the board and not seeing what you expect on a logic
analyzer???
2. Have you checked the fitter report (.rpt file) ? This file contains a lot
of information about how the fitter fit your design, including pin
assignments, and the logic equations created for each signal. Make sure
everything is as you expect it to be.
3. Have you run a simulation? If not, you should. A starter version of
ModelSim is available with Webpack. Create a VHDL or Verilog testbench to
exercise your design, and run the Post-Fit simulation process in iSE. If you
are not familiar with writing HDL testbenches, take a look at some of our
examples (found in <XILINX>/iseExamples) or use TestBencher, which is an
optional Webpack tool that allow you to graphically draw your stimulus and
generate testbench code automatically.

IF the fitter report looks good AND the Post-Fit simulation looks good, then
most likely the part is not getting programmed correctly. I'm not very
knowledgable about that end of things, so I would suggest contacting
support.xilinx.com.

-Dennis McCrohan
Xilinx CPLD S/W Development.




Article: 49655
Subject: Re: Metastability in FPGAs
From: Bob Perlman <bobsrefusebin@hotmail.com>
Date: Mon, 18 Nov 2002 23:00:56 GMT
Links: << >>  << T >>  << A >>
On 18 Nov 2002 14:46:30 -0800, already5chosen@yahoo.com (Michael S)
wrote:

>Bob Perlman <bobsrefusebin@hotmail.com> wrote in message news:<q80ituogem7vbhnoard9tm0bdlalsa84ev@4ax.com>...
>> On 18 Nov 2002 06:43:15 -0800, already5chosen@yahoo.com (Michael S)
>> wrote:
>> 
>> >I never studied the theory of metastable flip-flops. But intuitively I
>> >see metastable state as a very small local minimum on the energy
>> >curve. At the higher temperature the thermal noise can be strong
>> >enough to rescue the flip-flop out of this state to the stable one.
>> >It's all my speculations, may be, I erroneously apply the lows of
>> >microworld lows to the macroworld phenomenon ?
>> 
>> Back when the phenomenon of metastability was first observed and
>> discussed, some people suggested that metastable behavior could be
>> circumvented, or at least improved, by injecting noise that would move
>> the offending device away from its metastable point.  But others
>> pointed out that while noise might move a node out of metastability,
>> it was equally likely that noise would move an almost-metastable node
>> into metastability.
>> 
>> Bob Perlman
>> Cambrian Design Works
>
>
>I feel those "others" were wrong. 

OK.  Good luck.

Bob Perlman
Cambrian Design Works

Article: 49656
Subject: Re: looking for a VHDL imlementation of MD5 Hash algorithm.
From: "Gary Desrosiers" <gtdesrosi@cox.net>
Date: Mon, 18 Nov 2002 23:10:48 GMT
Links: << >>  << T >>  << A >>
Where did you find the FPGA implementation? Is it in ABEL? If you the info
you've found so far, I may convert to VHDL since this is some interest to me
as well.

"DarkDawn" <darkdawn@freemail.gr> wrote in message
news:arb3v8$aht$1@nic.grnet.gr...
> Hi all,
>
> I have already found some resources about FPGA implementation of MD5 hash
> algorithm, but I couldn't find any VHDL source code. Could anyone please
> help me?
>
> Thanks in advance for any assistance,
> Antonis.
>
>
>



Article: 49657
Subject: Re: Tristate buffers + leonardo Spectrum
From: "pradeep" <uqpprabh@dingo.cc.uq.edu.au>
Date: Tue, 19 Nov 2002 10:12:11 +1000
Links: << >>  << T >>  << A >>
Statements within a 'process' execute Sequentially , not Concurrently..

"when-else" , "with-select-when" are concurrent statements..."if-then-else"
, "case-when" are sequential statements..

Pradeep


"Anup Raghavan" <anup@itee.uq.edu.au> wrote in message
news:9d80c593.0211121820.e951e8d@posting.google.com...
| Hello, when i try to synthesize the following code using Leonardo
| Spectrum for Xilinx FPGAs, I get errors " Syntax Error near 'when' "
| If I dont use a process and then synthesize this code, it works fine.
| But I do need to have a process in my design. Can someone provide me a
| solution for this.
|
| Thanks
| Anup Raghavan
|
| entity mux_tbuf is
|
| port (SEL: in STD_LOGIC_VECTOR (4 downto 0);
| A,B,C,D,E: in STD_LOGIC;
| clk : in std_logic;
| SIG: out STD_LOGIC);
| end mux_tbuf;
|
| architecture RTL of mux_tbuf is
| begin
|
| sync: process (clk) is
|
| begin
|   if clk'event and clk = '1' then
| sig <= A when sel = "11110" else 'Z';
| sig <= B when sel = "11101" else 'Z';
| sig <= C when sel(2)= '1' else 'Z';
| sig <= D when sel(3)= '1' else 'Z';
| sig <= E when sel(4)= '1' else 'Z';
|   end if;
|
| end process sync;
|
| end RTL;



Article: 49658
Subject: Some Basic Understanding - RTL
From: "Ralph Mason" <masonralph_at_yahoo_dot_com@thisisnotarealaddress.com>
Date: Tue, 19 Nov 2002 13:42:19 +1300
Links: << >>  << T >>  << A >>
I am just trying to get these concepts straight in my mind.

If I clock data our of a ram (say block ram in a Spartan) this data is
available on the rising edge after the address is set up.

Can I use that data in a process that is clocked of the same rising edge?

Say I have

BLOCK_RAM myram(clk, address, dataout )

am I correct to say

always @(posedge clk){
    case data
....

Will 'data' ever be in intermediate states? What about a propagation delay
where the clock edge arrives before the data? Would you always have to use
to cycles to do this (meaning that your data is 3 cycles behind the address
output)?

While I am here ( and this is really driving the questions ) I am trying to
get this simple cpu to run.  When I synthise it can't  infer block ram from
the ram declaration - short of actually declaring a block ram using the
xlinx primitive is there any way to get it to do that?  Any other comments
about the below code are greatly appreciated also


module top();
 reg clk;
 wire [7:0] A;

 ultra u1(clk,A);

 always
 begin
   clk=0; #1
   clk=0;#1
 end
endmodule

module ultra(clk,A);
    input clk;
  output A;

  reg [7:0] PC, MA;
 reg [7:0] A, IR, MD;
 reg [7:0] MEM[0:63];     // 64 words of 8-bit memory

 reg [1:0] state; //0 INS Fetch

 wire [5:0] imm = IR[5:0];
 wire [1:0] ins = IR[7:6];

 reg [1:0] icur;
 reg we;

/*
00  LOAD M   loads the contents of memory word M into the accumulator.
01  STORE M  stores the contents of the accumulator in memory word M.
10  ADD M    adds the contents of memory word M to the contents of the
accumulator.
11  JUMP M   jumps to location M in memory.
 Address Contents
 0 Load  4
 1 Add   5
 2 Store 6
 3 Jump  1
 4 Data  1
 5 Data  2
*/

 initial begin
  MEM[0]=8'h04;
  MEM[1]=8'h85;
  MEM[2]=8'h46;
  MEM[3]=8'hc1;
  MEM[4]=8'h01;
  MEM[5]=8'h02;
 end

 always @(posedge clk)
 begin

   if ( we ) begin
    MEM[MD] <= A;
    we <= 0;   end
   else
    IR <= MEM[MD];

     case (state)
    2'b00:
     PC<=PC+1;  ///Ins fetch
    2'b01:begin
     MD<=imm;  //Decode
     icur<=ins; end
    2'b10:  //execute
     case (icur)
     2'b00: A<=IR;
     2'b01: we<=1;
     2'b10: A <= A + {2'b00,imm};
     2'b11: PC<= {2'b00,imm};
     default:;
     endcase
            2'b11: MD<=PC;
           default:;
     endcase

     state=state+1;
end

endmodule

Thanks
Ralph




Article: 49659
Subject: Re: Metastability in FPGAs
From: nospam <nospam@please.com>
Date: Tue, 19 Nov 2002 01:33:26 +0000
Links: << >>  << T >>  << A >>
Jim Granville <jim.granville@designtools.co.nz> wrote:

>> Like a switching FF, it will take some time to go to a stable state.  But it
>> can be just close enough to the perfect balance point that it might take
>> a while to move off center.  The closer to the balance point, the longer
>> it can take, so there is no maximum metastable time.

> I'm not sure this assertion can apply forever. 

An infintite metastable state will occur with a 1/infinity probability :) 

>See Peter A's notes on metastable times, that
>reflected to very narrow time windows, and working that to a 
>Wave-transit time, you get less than the order of a gate-length.
>
> Given this extremely short physical equivalence, it opens the idea of
>a triple register, using traces as delay lines, and then taking a vote
>of the outputs on the basis that all 3 cannot have the same metastable
>lifetimes.

It doesn't buy you anything, the one in the 'middle' will go metastable
with the same probability as a single flipflop. 


Article: 49660
Subject: Re: Metastability in FPGAs
From: nospam <nospam@please.com>
Date: Tue, 19 Nov 2002 01:58:02 +0000
Links: << >>  << T >>  << A >>
hmurray@suespammers.org (Hal Murray) wrote:

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

It depends where the noise is. Yes noise on the input signal makes no
difference. Noise (or preferably a well defined high frequency 'agitation')
in the flipflop feedback path would limit the duration of the metastable
state. 




Article: 49661
Subject: Re: Metastability in FPGAs
From: hmurray@suespammers.org (Hal Murray)
Date: Tue, 19 Nov 2002 02:05:06 -0000
Links: << >>  << T >>  << A >>
>> Given this extremely short physical equivalence, it opens the idea of
>>a triple register, using traces as delay lines, and then taking a vote
>>of the outputs on the basis that all 3 cannot have the same metastable
>>lifetimes.
>
>It doesn't buy you anything, the one in the 'middle' will go metastable
>with the same probability as a single flipflop. 

Actually, it's worst than the 1 FF case.  The prop time through
the voting logic gets subtracted from the settling time.  You are
much better off with that time in an exponent.

-- 
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: 49662
Subject: Re: Metastability in FPGAs
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Tue, 19 Nov 2002 15:30:39 +1300
Links: << >>  << T >>  << A >>
nospam wrote:
> 
> Jim Granville <jim.granville@designtools.co.nz> wrote:
> 
> >> Like a switching FF, it will take some time to go to a stable state.  But it
> >> can be just close enough to the perfect balance point that it might take
> >> a while to move off center.  The closer to the balance point, the longer
> >> it can take, so there is no maximum metastable time.
> 
> > I'm not sure this assertion can apply forever.
> 
> An infintite metastable state will occur with a 1/infinity probability :)

That's a mathematician's answer, and is the standard 'party line'.

A quantum-physicist's analysis is what I would like to see :)


> >See Peter A's notes on metastable times, that
> >reflected to very narrow time windows, and working that to a
> >Wave-transit time, you get less than the order of a gate-length.
> >
> > Given this extremely short physical equivalence, it opens the idea of
> >a triple register, using traces as delay lines, and then taking a vote
> >of the outputs on the basis that all 3 cannot have the same metastable
> >lifetimes.
> 
> It doesn't buy you anything, the one in the 'middle' will go metastable
> with the same probability as a single flipflop.

 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.

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

-jg

Article: 49663
Subject: Re: problem with clkdll on spartan2
From: chopra_vikram@excite.com (Vikram)
Date: 18 Nov 2002 18:55:35 -0800
Links: << >>  << T >>  << A >>
Stefan Kulke <kulke@informatik.tu-cottbus.de> wrote in message news:<arapdo$1i5$1@Maust.bbone.tu-cottbus.de>...
> Hello,
> 
> I should like to create a simple example for using a clkdll on Spartan 2
> XC2S200 with a Expansionboard (with LEDs and Pushbuttons).
> I have created a circuit without DLL. This works correctly. The 
> clockspeed is 48 Mhz.
> The circuit with clkdll, ibufg, bufg etc. doesn't work correctly.
> It seems to be, the clk2x (clkdll) dont generate a clock signal.
> 
> 
> I work with XILINX 4.2WP3. My toplevel circuit is a schematic, which
> was created with Xilinx ECS.
> There are an 16bit counter (with control logic) and an interface circuit
> (for the expansion board).
> The Clock from the counter should be the double frequency (96 Mhz).
> 
> Now i try to explain my schematic:
> 
> Pin GCK (p80)-> IBUFG -> CLKIN from CLKDLL -> CLK0 from CLKDLL -> BUFG 
> -> CLKFB from CLKDLL
> 
> CLK2x from CLKDLL -> BUFG -> CLK-Input from Counter.
> GND -> Reset from CLKDLL
> 
> Constraint Implentation Editor:
> The conduction (from CLK2x to BUFG) is identified as an clock net.
> 
> I will be glad, if anybody tell me, where is my mistake in the design.
> 
> with kind regards
> 
> Stefan

Usage of DLLs in a design is subject to certain location constraints,
that is only a specific BUFG/DLL is associated with a particular GCLK
pin, and this needs to be specified with a LOC constraint.

Refer to foll. PDF for more info -
http://direct.xilinx.com/bvdocs/publications/ds001_2.pdf

Hope this helps,
Vikram.

Article: 49664
Subject: Re: Metastability in FPGAs
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Tue, 19 Nov 2002 03:00:04 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <3DD9A24F.766D@designtools.co.nz>,
Jim Granville  <jim.granville@designtools.co.nz> wrote:
>> An infintite metastable state will occur with a 1/infinity probability :)
>
>That's a mathematician's answer, and is the standard 'party line'.
>
>A quantum-physicist's analysis is what I would like to see :)

I'd bet that a quantum physicist would say "quantized noise makes it
shorter".

But thats just a Wild Ass Guess.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 49665
Subject: Re: Metastability in FPGAs
From: rickman <spamgoeshere4@yahoo.com>
Date: Mon, 18 Nov 2002 22:22:59 -0500
Links: << >>  << T >>  << A >>
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: 49666
Subject: Re: Metastability in FPGAs
From: rickman <spamgoeshere4@yahoo.com>
Date: Mon, 18 Nov 2002 22:24:18 -0500
Links: << >>  << T >>  << A >>
Hal Murray wrote:
> 
> > Given this extremely short physical equivalence, it opens the idea of
> >a triple register, using traces as delay lines, and then taking a vote
> >of the outputs on the basis that all 3 cannot have the same metastable
> >lifetimes.
> 
> That sounds like one of the kludges I was talking about.
> 
> What do you do if one path says 0, the other says 1, and the third
> goes metastable?

How do you know that one is metastable?  Have you developed a metastable
detector?  ;^)


> You can't "fix" metastability.  Get suspicious when somebody tries,
> or appears to be trying.  It means they don't understand it.
> 
> As Peter often says, you can make things good enough, especially
> with modern silicon.  But the basic mechanism is still exponential
> decay.


-- 

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: 49667
Subject: Re: Metastability in FPGAs
From: rickman <spamgoeshere4@yahoo.com>
Date: Mon, 18 Nov 2002 22:26:35 -0500
Links: << >>  << T >>  << A >>
Jim Granville wrote:
> 
> nospam wrote:
> >
> > Jim Granville <jim.granville@designtools.co.nz> wrote:
> >
> > >> Like a switching FF, it will take some time to go to a stable state.  But it
> > >> can be just close enough to the perfect balance point that it might take
> > >> a while to move off center.  The closer to the balance point, the longer
> > >> it can take, so there is no maximum metastable time.
> >
> > > I'm not sure this assertion can apply forever.
> >
> > An infintite metastable state will occur with a 1/infinity probability :)
> 
> That's a mathematician's answer, and is the standard 'party line'.
> 
> A quantum-physicist's analysis is what I would like to see :)

There you go looking for trouble.  If you know anything about quantum
mechanics you would realize that he/she would say that the FF can exist
in *both* stable states at once!!!  How are you going to analyze that??


-- 

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: 49668
Subject: Re: Metastability in FPGAs
From: rickman <spamgoeshere4@yahoo.com>
Date: Mon, 18 Nov 2002 22:55:39 -0500
Links: << >>  << T >>  << A >>
nospam wrote:
> 
> hmurray@suespammers.org (Hal Murray) wrote:
> 
> >>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.
> 
> It depends where the noise is. Yes noise on the input signal makes no
> difference. Noise (or preferably a well defined high frequency 'agitation')
> in the flipflop feedback path would limit the duration of the metastable
> state.

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.  

Now it looks like the FPGA people here can't even agree among
themselves!!! 

Maybe I need to ask the people in comp.arch.embedded?  ;^)

-- 

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: 49669
Subject: Re: Metastability in FPGAs
From: Bob Perlman <bobsrefusebin@hotmail.com>
Date: Tue, 19 Nov 2002 03:59:51 GMT
Links: << >>  << T >>  << A >>
Hi - 

I was searching Google for the words "metastability" and "noise." and
came across an interesting MIT course presentation that I'd commend to
anyone new to the topic.  The presentation, part of a Computing
Structures course, can be found at:

http://6004.lcs.mit.edu/Fall01/handouts/L08-1up.pdf

One of the foils has an interesting, abbreviated history of
metastability, which I've reproduced below:

=====
The Metastable State: a brief history

Antiquity: Early recognition - Buriden’s Ass, and other fables…

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

If you lived through this, you know that it's absolutely on target.  

Apparently, we're in the midst of a 70's revival.  I guess I can put
up with it, as long as David Cassidy doesn't make a comeback.

Bob Perlman
Cambrian Design Works



Article: 49670
Subject: Re: Some Basic Understanding - RTL
From: "Rob Finch" <robfinch@sympatico.ca>
Date: Mon, 18 Nov 2002 23:00:07 -0500
Links: << >>  << T >>  << A >>
> If I clock data our of a ram (say block ram in a Spartan) this data is
> available on the rising edge after the address is set up.

Yes, after a few ns. ( A few ns after the rising edge)

>
> Can I use that data in a process that is clocked of the same rising edge?

I don't think so, in the manner you imply. The data becomes valid sometime
after the clock edge used to register the address of the ram. This is just
like the output of a ff. You cannot use the output of that ff as valid data
for input of other logic which is clocked on that very same rising edge. You
have to wait for the next rising edge.

> am I correct to say
>
> always @(posedge clk){
>     case data
> ....
>
Yes, but remember the 'data' from the ram acts just like the output of a ff.
So the data will have to have been made valid as a result of the previous
clk edge (ie sometime after the previous clk - before this one).

> Will 'data' ever be in intermediate states? What about a propagation delay
> where the clock edge arrives before the data? Would you always have to use
> to cycles to do this (meaning that your data is 3 cycles behind the
address
> output)?
>

Yes, the data is 'behind' the address input, but only by a single cycle. If
your address becomes valid sometime after the clock edge of one cycle, then
the data from the bram becomes valid sometime after the next clock edge. So
it looks like <clk edge> <address being made available during this clock>
<clk edge> < data being made available during this clk>

It is a standard synchrounous approach. The ram acts just like a ff except
it has a few more ns delay. (It has a longer clk to valid output time)


> While I am here ( and this is really driving the questions ) I am trying
to
> get this simple cpu to run.  When I synthise it can't  infer block ram
from
> the ram declaration - short of actually declaring a block ram using the
> xlinx primitive is there any way to get it to do that?  Any other comments
> about the below code are greatly appreciated also
>
It's possible to infer a block ram, but to do so the address inputs of the
ram must be registered by a clock edge. I ususally do this both ways. For
simulation I use an inferred block ram, but for synthesis I use the
primitive to make it easier to set the initial contents of the ram.

>  always @(posedge clk)
>  begin
>
>    if ( we ) begin
>     MEM[MD] <= A;
>     we <= 0;   end
>    else
>     IR <= MEM[MD];

Unfortunately it can't be done this way and infer a block ram. What's
appears to be inferred in this case is an asynchronous ram, probably
constructed out of LUT resources. In order to get an inferred block ram, it
has to look something like:

module....

reg [3:0] memAddr;

// register the address input to the memory in order to infer a block ram
always @(posedge clk) begin
    memAddr <= MD;

    if ( we )
        MEM[memAddr] <= A;

     IR <= MEM[memAddr];
end


Putting it in it's own module would be good, because then the code can be
reused, and it might make it easier for the synthesizer to synthesize a
bram.

There are a couple of simple ways of working around this characteristic of
bram if you want to emulate an asynchronous ram. 1) Use two clock cycles and
alternate between the two. One to setup the address and the next to access
the ram. Or 2) clock the ram on the negative edge of the clock while the
rest of the design works on the positive edge. (Effectively cuts the
performance of the design in half. Or 3) (this is a method I use alot)
create (outside of clocked logic) a 'next address' signal that represents
what the next address would be after the clock edge, and feed that into the
address input for the bram. so rather than using MD use MD_nxt, where MD <=
MD_nxt after the clock edge.

Other than that, you have to look into pipelining the design which is a good
way of obtaining performance and works very well in an FPGA.

Rob
www.birdcomputer.ca






Article: 49671
Subject: Newbie Question: Instantiating Muliplier18X18
From: jyoti_wagholikar@yahoo.com (Jyoti Wagholikar)
Date: 18 Nov 2002 20:12:40 -0800
Links: << >>  << T >>  << A >>
Hi,
  
    I am trying to instantiate embedded MULT18X18 signed multiplier in
Xilinx foundation 3.1i series. While implementing the design on
XCV100E-8-PQ240, I am getting the following error:

ERROR:NgdBuild:432 - logical block 'M1' with type 'MULT18X18' is
unexpanded

I noticed that libraries getting attached to the project are : Virtex
and Simprim, I tried to change the library to virtex II ( It contains
MULT18X18). But while implementing, the library, automatically, got
changed to virtex.

Can you please give me the direction regarding this? It will help me
to go ahead in my project.

I tried to generate multiplier core from Logicore, I found that the
timing analysis (delay) for pipelined and non pipelined multiplier is
same. I am wondering if core uses internal pipelined register while
generating pipelined multiplier.

thanks in advance,

-Jyoti

Article: 49672
Subject: Re: Metastability in FPGAs
From: Ray Andraka <ray@andraka.com>
Date: Tue, 19 Nov 2002 05:21:14 GMT
Links: << >>  << T >>  << A >>
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

--
--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: 49673
Subject: Re: Are block RAMs supported in simulation?
From: "Stan" <vze3qgji@verizon.net>
Date: Tue, 19 Nov 2002 05:31:19 GMT
Links: << >>  << T >>  << A >>
Also, both the write-enable and the enable need to be asserted, with setup
and hold wrt the rising edge.  -Stan

"Peng Cong" <pc_dragon@sohu.com> wrote in message
news:ar9g3e$1vjj$1@mail.cn99.com...
> ModelSim support Block RAM simulation, I just use it now.
> Check you write enble signal if the data write into block ram really.
>
> "Lorenzo Lutti" <lorenzo.lutti@DOHtiscalinet.it> Đ´ČëĎűϢĐÂÎĹ
> :1NVB9.43841$8E3.1278377@twister2.libero.it...
> > This question is likely very trivial, but I haven't found the answer in
> > any FAQ. I'm developing a ISE project for a Spartan II device; when I
> > simulate it with ModelSim (I use the post-place&route model) the values
> > stored in block RAM during the simulation aren't retained, and if I read
> > back the same locations I apparently just get the initialization values.
> >
> > Is this correct? I hope it's just my mistake. :)
> >
> > --
> > Lorenzo
> >
> >
>
>



Article: 49674
Subject: Re: clock difference between DLL input and output?
From: Ray Andraka <ray@andraka.com>
Date: Tue, 19 Nov 2002 05:33:28 GMT
Links: << >>  << T >>  << A >>
First, you need to go back and revisit the data sheet.  I believe you will find a
minimum DLL input clock frequency of 25 MHz there.  It will work at lower
frequencies, but is not guaranteed over voltage, temperature and process...in other
words if you put this into production I guarantee you'll have failures.

Xilinx originally said that it was safe to go directly between the clock domains,
however experience dictates otherwise.   If the DLL output jitter plus intrinsic
clock tree skew in the part are less than the minimum propagation time between the
registers, then you are OK.  Since there is no minimum propagation time specified,
you already have a problem if there is *any* jitter, but practically speaking there
is a minimum prop time.  For a jitter-free clock coming in, and matched clock
distribution, you can go directly between....but:  The incoming clock jitter is
seldom small, and if you have single ended outputs on the same bank as the clock
you can introduce considerable jitter on the clock through threshold modulation due
to switching I/O.  Also, the clock distribution is not closely matched unless you
load each very similarly in each column (you'd have to do this by hand, as the
placer won't even come close).  We saw this happen soon after Virtex first came
out.

Instead, I recommend that you be very careful about how you transfer data across
the 1x/2x clock boundaries, as the edge can fluctuate by several hundred ns
relative to the edge in the other domain...enough to cause mis-clocking.   Positive
edge to negative edge should be fine

louis wrote:

>   There's a external clock input (20MHz) on my system, and I multiply
> it to 2X (40MHz) by DLL as the working clock.
>   However, I have to exchange data in several
> modules between these two clock domains. I don't know if it safe to sample data
> on both positive edges of these two clocks?
>   Will the clock jitter cause the metastability? Or I have to generate data
> on positive edge and retrieve data on negative edge instead?
>   The target chip is SpartanIIE. Any comment and suggestion will be very
> appreciated.
>
> louis

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





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