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 49625

Article: 49625
Subject: problem with clkdll on spartan2
From: Stefan Kulke <kulke@informatik.tu-cottbus.de>
Date: Mon, 18 Nov 2002 14:19:52 +0100
Links: << >>  << T >>  << A >>
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


Article: 49626
Subject: programming Altera EPC1
From: "luigi funes" <fuzzy8888@hotmail.com>
Date: Mon, 18 Nov 2002 13:28:28 GMT
Links: << >>  << T >>  << A >>
Hi all,
I found a lot of EPC1 configuration EPROMs almost for free.
Unfortunately I have no programmers for this device.
Where can I found the programming algorithm specifications
to build a simple programmer?
Thank you in advance.

Luigi




Article: 49627
Subject: Re: max3000
From: "luigi funes" <fuzzy8888@hotmail.com>
Date: Mon, 18 Nov 2002 13:30:04 GMT
Links: << >>  << T >>  << A >>
Rinux ha scritto nel messaggio ...
>Hi all
>Anyone know a sinple way to program a max3000 ??
>
>regard


Ciao Rinux,
Altera MAX3000 are in system programmable devices.
The best way to program it is with a Byteblaster cable.
Bye

Luigi




Article: 49628
Subject: Re: Metastability in FPGAs
From: Ray Andraka <ray@andraka.com>
Date: Mon, 18 Nov 2002 13:48:57 GMT
Links: << >>  << T >>  << A >>
I don't think this is a metastability problem, rather it is improper use of an asynchronous design.
Metastability gets one flip-flop balancing in an unstable 'meta state' that is neither the high nor
the low state.  It only occurs if the D input is changed within a very narrow window around the clock
edge.  More likely, you've got an async signal feeding more than one flip-flop, so that within a
certain window around the clock you wind up with one of them interpreting the input before it
transitions and one interpreting the input post transition.  This is an asynchronous synchronization
problem, which is quite distinct from metastability.

Michael S wrote:

> hmurray@suespammers.org (Hal Murray) wrote in message news:<utd7cdm3r2gsac@corp.supernews.com>...
> > >I am not familiar with the techXclusive, can you provide a URL?
> >
> >  http://support.xilinx.com/support/techxclusives/metas-techX32.htm
>
> Good article. Unfortunately, it doesn't mention the temperature
> conditions for the mesurements.
>
> Recently we suffered a problem which I attribute to metastability. Our
> design fed Intel 386EX processor with asynchronous READY# signal.
> Simetimes it caused the hang up. The processor's RD# signal was
> indicating that READY# is accepted while correspondent CS# signal
> remained asserted, indicating that READY# was missed. Looks like
> classic metastability problem, doesn't it ?!
> The problem was very temperature dependent. I never did a statistical
> mesurements (was to busy to understand and resolve the problem), but
> there was at least order of magnitude difference between  0 and -20deg
> Celsius (the colder is worse).
> Theoretically, the strong temperature dependance is expectable. It
> would be fine if Xilix will provide us with temperature data.

--
--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: 49629
Subject: Re: Anyone has VHDL code for decimator and interpolater?
From: Ray Andraka <ray@andraka.com>
Date: Mon, 18 Nov 2002 13:51:51 GMT
Links: << >>  << T >>  << A >>
No,  The transaction is entirely with Amazon.  I get a referral fee paid to me
by Amazon at the end of each quarter.  At least right now your currency is
stronger against the dollar than it has been in recent years, so you do get
something of a discount.

Noddy wrote:

> > Buy, beg, borrow or steal (well, no don't steal) a copy of P.P.
> Vaidyanathan's multirate filtering
> > book (You can buy it through the bookstore on my website, which will give
> me a kickback which in
> > turn helps to support the website).
>
> Don't suppose you give student discounts ('specially students from countries
> with a 3rd world currency) ????? :)
>
> adrian

--
--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: 49630
Subject: Re: Metastability in FPGAs
From: already5chosen@yahoo.com (Michael S)
Date: 18 Nov 2002 06:43:15 -0800
Links: << >>  << T >>  << A >>
rickman <spamgoeshere4@yahoo.com> wrote in message news:<3DD87D53.C15787CE@yahoo.com>...
> 
> I am surprised that it got worse with temperature.  Silicon delays are
> less at colder temps, which in turn allows more time for metastability
> resolution within any path that has a significant delay.  Since you saw
> more frequent failures, this either might not have been metastability or
> if the metastable FF fed a path that had little delay and was mostly
> slack time, the increased incidence may have been due to the gain
> bandwidth being reduced at lower temps.  I don't know enough about FFs
> to know how this is affected by temperature.  
> 
> But I am not clear as to what you think the metastable path is.  If it
> is the Ready signal being presented to the 386, then the problem would
> be inside the 386.  So why would you be looking to Xilinx for info?  

It has nothing to do with Xilinx. I just brought my case as an example
of the temperature dependency of the (supposed) metastability.
 
> 
> In general, I would expect the effect of temperature to be small in
> relation to the exponential effect of slack time.  If you see a
> metastable failure at *any* temperature, it is because not enough time
> was provided for settling.  
> 
> -- 
> 
> 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


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 ?

Article: 49631
Subject: Re: Metastability in FPGAs
From: Bob Perlman <bobsrefusebin@hotmail.com>
Date: Mon, 18 Nov 2002 15:07:30 GMT
Links: << >>  << T >>  << A >>
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

Article: 49632
Subject: counter error no matching overload for "+"
From: sowteng@lycos.com (sowteng)
Date: 18 Nov 2002 07:11:12 -0800
Links: << >>  << T >>  << A >>
Hi, i was trying to synthesize a simple 4 bit up-counter using
synplify but I was returned a no matching overload for "+" for line
ctCOUNT <= ctCOUNT + "001"; Are there any libraries which i need to
include?


entity counter is
Port ( ctclk : in bit;
           ctrs : in bit;
			  ctce : in bit;
			   ctld : in bit;
				 ctbranchaddr : in bit_vector(2 downto 0);
           ctcount : inout bit_vector(2 downto 0));
			 
end counter;

architecture Behavioral of counter is

begin
 
process (ctCLK, ctRS)
begin
   if ctRS='1' then
      ctCOUNT <= "000";
   elsif ctCLK='1' and ctCLK'event then
      if ctLD='1' then
         ctCOUNT <= ctbranchaddr;
      else
         if ctCE='1' then
             
               ctCOUNT <= ctCOUNT + "001";      --<------------------
            
         
			end if;
      end if;
   end if;
end process; 
End Behavioral;

Article: 49633
Subject: Re: Metastability in FPGAs
From: already5chosen@yahoo.com (Michael S)
Date: 18 Nov 2002 07:11:25 -0800
Links: << >>  << T >>  << A >>
nospam <nospam@please.com> wrote in message news:<ppggtu0fe816a15l2lm9db3jnc9kii30li@4ax.com>...
> already5chosen@yahoo.com (Michael S) wrote:
> 
> >hmurray@suespammers.org (Hal Murray) wrote in message news:<utd7cdm3r2gsac@corp.supernews.com>...
> 
> I would attribute it to a duff design - the 386EX datasheets specify a
> setup and hold time for the READY# input. The datasheets do not specify
> what happens if READY# is not stable during that period. You experience
> shows the processor can get screwed up pretty badly - but it is still your
> fault. 
> 
I know it's my fault, never claimed otherwise. 

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

> I do wish chip manufacturers would be a bit more specific about which
> violation of timing specifications can really screw up their parts.

In the common case 386EX would not be screwed so badly by
asynchroneous READY#. Our case is particularly bad because our
peripheral (TMS320C5420 HPI) releases READY# signal immediately after
seeing RD# goes up. So the next clock 386EX samples READY# it is
already up. Most asynchroneous peripherals would not release READY#
until both RD# and CS# are released by 386EX.

Article: 49634
Subject: Re: max3000
From: Rene Tschaggelar <tschaggelar@dplanet.ch>
Date: Mon, 18 Nov 2002 16:38:09 +0100
Links: << >>  << T >>  << A >>
luigi funes wrote:
> Rinux ha scritto nel messaggio ...
> 
>>Hi all
>>Anyone know a sinple way to program a max3000 ??
>>
>>regard
> 
> Ciao Rinux,
> Altera MAX3000 are in system programmable devices.
> The best way to program it is with a Byteblaster cable.
> Bye

Schematics for the download cable is available on the Altera
website.

Rene


Article: 49635
Subject: Re: Metastability in FPGAs
From: nospam <nospam@please.com>
Date: Mon, 18 Nov 2002 16:16:30 +0000
Links: << >>  << T >>  << A >>
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. 

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. 



Article: 49636
Subject: looking for a VHDL imlementation of MD5 Hash algorithm.
From: "DarkDawn" <darkdawn@freemail.gr>
Date: Mon, 18 Nov 2002 18:19:26 +0200
Links: << >>  << T >>  << A >>
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: 49637
Subject: Re: counter error no matching overload for "+"
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Mon, 18 Nov 2002 18:45:02 +0100
Links: << >>  << T >>  << A >>
"sowteng" <sowteng@lycos.com> schrieb im Newsbeitrag
news:699d5bf2.0211180711.56d57bb6@posting.google.com...
> Hi, i was trying to synthesize a simple 4 bit up-counter using
> synplify but I was returned a no matching overload for "+" for line
> ctCOUNT <= ctCOUNT + "001"; Are there any libraries which i need to
> include?

Yes.

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;

And dont use bit and bit_vector, use std_logic and unsigned instead.

--
MfG
Falk




Article: 49638
Subject: Re: problem with clkdll on spartan2
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Mon, 18 Nov 2002 18:48:24 +0100
Links: << >>  << T >>  << A >>
"Stefan Kulke" <kulke@informatik.tu-cottbus.de> schrieb im Newsbeitrag
news:arapdo$1i5$1@Maust.bbone.tu-cottbus.de...

> 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

Looks good. Try to route the reset of the DLL to an IO and reset the DLL
manually a few times. Also rout the LOCKED output to an IO (a LED is nice
here) to see the status of the DLL.

--
MfG
Falk





Article: 49639
Subject: Re: Asynchronous FIFOs using Handel-C?
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Mon, 18 Nov 2002 18:55:21 +0100
Links: << >>  << T >>  << A >>
"Bernhard Mäder" <nonuschk@gmx.net> schrieb im Newsbeitrag
news:3dd7d934@news.swissonline.ch...
> >
> > I agree. So try a fast synchronous FIFO.
> >
>
> Yes, but the point is that I _have_ to handle an incoming clock of unknow
> frequency (up to 75MHz). Or is there any other technique that can be
> applied?

Peter, I gess this is an incomming call for you.  ;-)

ASYNCHRONOUS FIFOS!!!!!

Yes, there is a way. Use gray encoded read/write pointers to transfer them
over the clock boundary. Then make sure to stop writing, when the FIFO has
2..3 or less words free, NOT if there is just one word, free. Same with
reading.

--
MfG
Falk





Article: 49640
Subject: Re: CoolBlaze and PicoBlaze
From: Sylvain Yon <sylvain.yon@sbcglobal.net>
Date: Mon, 18 Nov 2002 18:16:20 GMT
Links: << >>  << T >>  << A >>
edaudio2000@yahoo.co.uk (ted) wrote in
news:c54bf83f.0211160213.723bdbaf@posting.google.com: 

> At a recent Xilinx seminar one of the presenters showed a slide
> describing PicoBlaze and CoolBlaze simple 8 bit cores for Xilinx
> products. 
> 
> Looking at the XIlinx site, I only find a mention about Picoblaze, no
> mention at all about CoolBlaze.
> 
> Google produced no results whatsoever. 
> 
> Is Coolblaze a real product? If not why was it shown on the slides?
> 
> PS we have a need for such a product, hence  the asking!
> 


You may give a look to triscend products. I don't have any link with that 
company ( except a friend who works there ), but I found their idea of 
combining a small uc with a cpld fabric pretty cool, and prbably more 
efficient than a soft core in a cpld...

hth,
Sylvain Yon

Article: 49641
Subject: Re: programming Altera EPC1
From: "Leon Heller" <leon@heller123.freeserve.co.uk>
Date: Mon, 18 Nov 2002 18:42:19 -0000
Links: << >>  << T >>  << A >>

"luigi funes" <fuzzy8888@hotmail.com> wrote in message
news:0W5C9.11488$Ka3.344765@twister1.libero.it...
> Hi all,
> I found a lot of EPC1 configuration EPROMs almost for free.
> Unfortunately I have no programmers for this device.
> Where can I found the programming algorithm specifications
> to build a simple programmer?
> Thank you in advance.


You can program them using a Byteblaster with a suitable socket for the
EPC1, a couple of resistors and a header for the BB, mounted on a small
piece of stripboard. We did this where I used to work.

Leon
--
Leon Heller, G1HSM
leon_heller@hotmail.com
http://www.geocities.com/leon_heller



Article: 49642
Subject: Re: Virtex is the 4th Xilinx Fpga generation
From: "Steve Casselman" <sc@vcc.com>
Date: Mon, 18 Nov 2002 19:42:37 GMT
Links: << >>  << T >>  << A >>
> Nor is the V2Pro.  It's a lateral move from the V2,
> kind of like the move from Virtex to Virtex-E

I have to disagree the Virtex E just a different mix of the same stuff.
The V2Pro adds Gbit transceivers and hard processors I think that is a big
difference.

Steve



Article: 49643
Subject: Re: Webpack and Virtex Pro?
From: "Speedy Zero Two" <david@manorsway.NOSPAMPLEASE.freeserve.co.uk>
Date: Mon, 18 Nov 2002 19:58:47 -0000
Links: << >>  << T >>  << A >>
I always assume that Xilinx want to sell silicon.
That's why they provide the free tools.

Anyone wanting state-of-the-art has to pay through the nose for it.
That makes them the market leaders.

After some time the tools may be made freely available to use mortals to
sure-up the market.

IMHO
Dave

<hamish@cloud.net.au> wrote in message
news:3dd5ee42$0$12778$afc38c87@news.optusnet.com.au...
> Eric Smith <eric-no-spam-for-me@brouhaha.com> wrote:
> > Has Xilinx said anything about future versions of WebPack being able
> > to support the 2VP4?  It seems a shame that it doesn't support at
> > least one part that actually contains a PowerPC processor.  The number
>
> Why wouldn't you buy the tools if using such a high-end part?
>
> Hamish
> --
> Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>



Article: 49644
Subject: Re: about schmatic symbol
From: Chen Wei Tseng <chenwei.tseng@xilinx.com>
Date: Mon, 18 Nov 2002 13:28:37 -0700
Links: << >>  << T >>  << A >>
Xie,

In 3.1i, there are macro libraries that are obseleted in later software. Starting from 4.1i, ECS no longer has macro libraries. Instead, it has macro symbols that's composed of primitives. Therefore, what you should try to do is perform post translate (NGDBUILD) simulation. Or run NGD2VHDL or NGD2VERILOG and run simulation on the returned source code.

-Wei

Xie Jubo wrote:

> Hi
> I create a schmatic symbol in ECS in foundation 3.1i, synthesize is passed, but when i simulate it in MODELSIM an error occured that is it can not find vertex_macro library, but when i map the library in FPGA library manager, i cannot find this library in it, there are only simprim and unisim and logibox library, if the file of fpgavender_xilinx.tcl is outdated?
>
> thanks
>
> xie


Article: 49645
Subject: Re: Metastability in FPGAs
From: rickman <spamgoeshere4@yahoo.com>
Date: Mon, 18 Nov 2002 16:00:50 -0500
Links: << >>  << T >>  << A >>
nospam wrote:
> 
> already5chosen@yahoo.com (Michael S) wrote:
> 
> >hmurray@suespammers.org (Hal Murray) wrote in message news:<utd7cdm3r2gsac@corp.supernews.com>...
> >> >I am not familiar with the techXclusive, can you provide a URL?
> >>
> >>  http://support.xilinx.com/support/techxclusives/metas-techX32.htm
> >
> >Good article. Unfortunately, it doesn't mention the temperature
> >conditions for the mesurements.
> >
> >Recently we suffered a problem which I attribute to metastability. Our
> >design fed Intel 386EX processor with asynchronous READY# signal.
> >Simetimes it caused the hang up. The processor's RD# signal was
> >indicating that READY# is accepted while correspondent CS# signal
> >remained asserted, indicating that READY# was missed. Looks like
> >classic metastability problem, doesn't it ?!
> 
> I would attribute it to a duff design - the 386EX datasheets specify a
> setup and hold time for the READY# input. The datasheets do not specify
> what happens if READY# is not stable during that period. You experience
> shows the processor can get screwed up pretty badly - but it is still your
> fault.
> 
> The 'problem' inside the 386 is almost certainly a race and not
> metastability.
> 
> I do wish chip manufacturers would be a bit more specific about which
> violation of timing specifications can really screw up their parts.

I had a similar problem with a TI DSP once and tried to get them to tell
me which edge of the clock the signal was sampled.  Then I could make a
resonable attempt to synchronize with the input sampling.  But they
would not or could not understand what I wanted to do and just kept
telling me that it was an "asynchronous" signal and there was *no* setup
or hold to the clock.  We all know the part is synchronous internally,
but I just could not get through to anyone that understood what I
wanted.  So I would not expect much understanding from a chip vendor on
an issue like this.  They tend to see their parts through blinders.  

-- 

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: 49646
Subject: Re: Virtex is the 4th Xilinx Fpga generation
From: ldoolitt@recycle.lbl.gov (Larry Doolittle)
Date: Mon, 18 Nov 2002 21:04:47 +0000 (UTC)
Links: << >>  << T >>  << A >>
>> Nor is the V2Pro.  It's a lateral move from the V2,
>> kind of like the move from Virtex to Virtex-E
>
>I have to disagree the Virtex E just a different mix of the same stuff.

If I understand correctly, the Virtex-E (and Spartan-IIE) are process
shrinks, without an architecture redesign.  So the voltages are lower
(damn) and the speeds are faster (hooray!), but this is not what
one would call qualitative change.

>The V2Pro adds Gbit transceivers and hard processors I think that is a big
>difference.

Sure, it can be a big difference for real-life use,
but it's not a change in the FPGA fabric itself.
Just in the "peripherals".  So calling it a new "generation"
of FPGA sounds like marketing fluff.  'Specially since
the FPGA cells that the PPC displaces are enough to make
a soft RISC core.

      - Larry

Article: 49647
Subject: Re: Metastability in FPGAs
From: rickman <spamgoeshere4@yahoo.com>
Date: Mon, 18 Nov 2002 16:05:29 -0500
Links: << >>  << T >>  << A >>
Hal Murray wrote:
> 
> Suppose the problem is a simple setup problem - it takes x ns to setup
> FF X, and y ns for the same signal to get setup for FF Y.  Anything
> between x and y will cause troubles.  Just adjust temperature to hit
> that window.

But if you are working on the late side of both X and Y you are
violating the setup time of each FF!  That is not the right place to be
since minimum delays are not guaranteed.  Any properly verified design
should be working on the early side of both X and Y and will only get
earlier as the temperature drops.  


> Similarly, if you only have one FF, and the setup time is z, then
> you will get no metastability problems if you meet z, and you will get
> a lot of them if you are a little under z.  (I'm talking measured
> setup times for this particular device/conditions, not data sheet times.)
> Temperature changes on one device (cold spray) could easily change the
> actual setup time for another device while the setup time it needs doesn't
> change much because its temperature doesn't change much.

Again, if you don't meet the data sheet times, you don't have a
correctly verified design.  Good synchronous design requires that you
meet all setup times under worst case conditions and input hold times
are best if they are zero, since that is the only hold time you can
guarantee. 

-- 

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: 49648
Subject: Re: Metastability in FPGAs
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Tue, 19 Nov 2002 10:15:39 +1300
Links: << >>  << T >>  << A >>
nospam wrote:
> 
<snip> 
> The 'problem' inside the 386 is almost certainly a race and not
> metastability.
> 
> I do wish chip manufacturers would be a bit more specific about which
> violation of timing specifications can really screw up their parts.

 This assumes they actually know this information :)

-jg

Article: 49649
Subject: Re: Metastability in FPGAs
From: rickman <spamgoeshere4@yahoo.com>
Date: Mon, 18 Nov 2002 16:20:20 -0500
Links: << >>  << T >>  << A >>
Michael S wrote:
> 
> It has nothing to do with Xilinx. I just brought my case as an example
> of the temperature dependency of the (supposed) metastability.

Ok, I thought you were referring the problem back into the Xilinx part.  


> >
> > In general, I would expect the effect of temperature to be small in
> > relation to the exponential effect of slack time.  If you see a
> > metastable failure at *any* temperature, it is because not enough time
> > was provided for settling.
> 
> 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 ?

There can be no local minimum or it is not a "meta"stable state.  Then
it would be a stable state in the absense of sigificant noise.  

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!).  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 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.  I think the bottom line is that
even if noise will help, you are not going to add noise to your digital
circuits to help metastability rather than to add the delay to the FF
output path.  It would be a bit hard to explain to a chip user that they
are *required* to provide a minimum amount of noise to make the chip
work to spec!!!

-- 

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



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