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 13950

Article: 13950
Subject: Re: Bit-Serial Multiplier
From: Jan Coombs <jan.coombs@murray-microft.co.uk>
Date: Tue, 05 Jan 1999 01:13:59 +0000
Links: << >>  << T >>  << A >>
John Kennedy wrote:
> 
> I need some advice on how to implement a Bit-Serial multiplier using the
> Xilinx Logicore Scaled By 1/2 Accumulator.  I need to scale a 20 bit
> signed 2's complement number.  I am using XC4010 fpga to try to do some
> digital audio signal processing, and need a compact (ok if slow)
> multiplier.  Any advice would be greatly appreciated.
> 
> John

For a fader with 0.6dB steps to 1% accuracy this reduces to
two adders & some other bits - does this meet your
requirements? 

Are you tied to a data stream format with most significant
bit first? This significantly affects the complexity of the
logic.

Jan
--
Murray Microft          Logical design inside & outside
chips
+44-1703-909500

Article: 13951
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10 Metastability - help please
From: murray@pa.dec.com (Hal Murray)
Date: 5 Jan 1999 07:33:14 GMT
Links: << >>  << T >>  << A >>

Big snip here.  I'm extracting the parts I want to comment on.  I don't
think I've tossed too much context.

> I never said that metastability does not exist. I have measured it. It does
> exist, but the recovery delay  from the metastable (=balanced) condition to the
> ultimately stable state is so short in modern CMOS latches and flip-flops, that
> the problem has lost most of its impact.

> 1. A modern CMOS latch can go metastable, but recovers so fast that the problem
> is, in most applications, irrelevant. ( see curves in the Xilinx data book,
> page 13-49 )

I cringe when I see things like that, especially from people that I usually
agree with.


If the problem is "irrelevant" for "most applications", how do I tell
if I'm working on one where it is relevant?

I agree that it is easy to solve the metastability problem in many practical
systems.  You do have to understand the problem and you have to get data
from the vendor.  (or run your own tests)


But the same processes that are speeding up the metastability recovery
time constant are also speeding up everything else in FPGAs.  Designers
want to take advantage of that speed - they expect their designs to work
with a fast clock.

I think the key parameter is not the metastability recovery time constant
alone, but the ratio of that time to the system clock time.  If I have
a system with enough time for multiple levels of logic then it is
probably easy to cleanly process an asynchronous input - just leave out
those levels of logic (and their routing) and you have enough time between
a pairof FFs.  But what if I'm running a heavily pipelined system where
the system clock only leaves room for a timy bit of routing?  Now there
aren't any extra levels of logic to leave out.  The classic FF-no-logic-FF
synchronizer may not have a lot of leftover time.


Note that designers pushing system clock speed are likely to jump on
the next generation of faster chips as soon as they become available.
That's before the metastability data becomes availability.  Assuming
that the metastability recovery time constant speeds up just like
everything else seems like a good first guess but I don't see any
reason to bet much on it.

-- 
These are my opinions, not necessarily my employers.

Article: 13952
Subject: HELP!!!
From: Sergei Leginov <sergeil@ttu.ee>
Date: Tue, 05 Jan 1999 10:41:04 +0200
Links: << >>  << T >>  << A >>
Hi ppl!
I need some general information about FPGA&MPGA, C-, I-, CI-tetsting.
I don't need any technical specifications only common info.
All links and URLs are welcome. plz email me them to sergeil@ttu.ee
thnx.

Article: 13953
Subject: Re: 22V10 Metastability - help please
From: Sergei Leginov <sergeil@ttu.ee>
Date: Tue, 05 Jan 1999 10:44:49 +0200
Links: << >>  << T >>  << A >>
Magnus Homann wrote:

> "Bruce Nepple" <brucen@imagenation.extra.com> writes:
>
> > Yes Yes Yes.  You got it! I challenge anyone here to come up with a gray
> > code state machine that can reside in state A and conditionally branch to
> > either state B or State C based on an async. input.
>
> I can't think of one. But you added yet another requirement to Peter's
> list. With thse requirements, one should be safe.
>
> > "Having spent untold hours at analyzing and measuring metastable
> > behavior, I can assure you that it is (today) a highly overrated
> > problem.  You can almost ignore it."
> > Peter Alfke
> > 12/28/98
>
> Are you going to hold it to him? :-)
> --
>    Magnus Homann  Email: d0asta@dtek.chalmers.se
>                   URL  : http://www.dtek.chalmers.se/DCIG/d0asta.html
>   The Climbing Archive!: http://www.dtek.chalmers.se/Climbing/index.html

Article: 13954
Subject: Re: 22V10 Metastability - help please
From: John Chambers <johnc@ihr.mrc.ac.uk>
Date: Tue, 05 Jan 1999 10:41:35 +0000
Links: << >>  << T >>  << A >>
This thread has provided the solution to a problem I've been working on
for about 2 months.  Many thanks to the insight provided by everybody
here on the (rather more complex than first expected) subject of state
machines.


John

Article: 13955
Subject: Question on Exemplar synthesis
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Tue, 05 Jan 1999 11:04:16 +0000
Links: << >>  << T >>  << A >>
Does anybody out there using the  Leonardo tools know how to do
incremental compilation & linking.

i.e. I have a module foo with an instantiiated block-box called  bar
definined in foo.v with the real bar module held in a separate file
called bar.v. What I want to do is compile & synth foo.v and bar.v
separately into EDIF files foo.edn & bar.edn and then link them.  In
other words merge bar.edn into the correct place in foo.edn.  This would
save  a lot of time by not re-synthesising and re-optimising stable
pieces of the design.

Example:


*** in file foo.v ***

module foo (in0, in1, out, clk);

input in0, in1, clk;
output out;

 wire sync_in0;

 bar U0 (in0, sync_in0, clk); // Instantiate bar

assign out = in1 & sync_in0;

endmodule

/* Black-box definition of bar */

module bar (in, sync_in,clk);

   input in, clk;
   ouput  sync_in;

endmodule

*** In bar.v ***

module (in, sync_in, clk);

input in, clk;
output sync_in

 reg sync_in;

    always @(posedge clk)
      begin
         sync_in = in;
      end

endmodule

Article: 13956
Subject: Re: PLL in FPGAs?
From: nospam_ees1ht@ee.surrey.ac.uk (Hans)
Date: 5 Jan 1999 12:09:31 GMT
Links: << >>  << T >>  << A >>

Actel recently published an article on DPLL's in an Actel FPGA. Unfortunately I 
can remember were I've seen it. I remember that the author was Steff 
Niewadomski (spelling?).

Hans.


Brett George wrote in message <367F428F.5641E93E@clarityeq.com>...
>Hi all,
>
>Has anyone tried implementing a PLL in an FPGA (eg. ALTERA), we are
>thinking of using it to reduce clock jitter from an externally generated
>clock source.


Article: 13957
Subject: Re: PLL in FPGAs?
From: rk <rich.katz@nospam.gsfc.nasa.gov>
Date: Tue, 05 Jan 1999 08:12:00 -0500
Links: << >>  << T >>  << A >>
perhaps this is what you're looking for ...


    (From the June 1997 issue of Actel's "re.ACT" newsletter)

    <snip marketing garbage>

    iniADPLL is an all digital phase locked loop (ADPLL) core for applications
requiring
    clock recovery, clock generation, and clock supervision functionality. iniADPLL
features
    a maximum 10 ns jitter at 50 Mhz system clock, linear frequency range, infinite

    frequency hold time, programmable center frequency, and programmable filter
    characteristics. It comes as a structured, synthesizable VHDL model,
fully-synchronous
    design that can be customized for special design requirements.


--------------------------------------------

    Function: ADPLL

    <snip sales info garbage>

      All Digital Phase Locked Loop
      Maximum 10ns jitter at 50MHz
      Frequency range from 0 to n MHz
      Infinite frequency hold time
      Programmable center frequency
      Programmable filter characteristics (cut-off frequency, loop gain)
      Structured model description (SD)
      Fully synchronous design
      Adaptable phase detector
      Scalable oscillator and loop filter
      Customizable for special requirements

---------------------------------------------

... and perhaps this is not :-)


    The Actel ES Family

        <snip various other stuff>

    -- ClockSync -- Multiple Digital Phase Locked Loops (DPLL) -- provides
    balancing of multiple system clocks. Also enables effective clock-to-output
    delays to be reduced from 7ns to 0ns.

---------------------------------------------

rk

and for all you wise-guys out there, do they use a gray-coded state machine to run
the thing?

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

Hans wrote:

> Actel recently published an article on DPLL's in an Actel FPGA. Unfortunately I
> can remember were I've seen it. I remember that the author was Steff
> Niewadomski (spelling?).
>
> Hans.
>
> Brett George wrote in message <367F428F.5641E93E@clarityeq.com>...
> >Hi all,
> >
> >Has anyone tried implementing a PLL in an FPGA (eg. ALTERA), we are
> >thinking of using it to reduce clock jitter from an externally generated
> >clock source.



Article: 13958
Subject: Re: Bit-Serial Multiplier
From: Ray Andraka <randraka@ids.net>
Date: Tue, 05 Jan 1999 09:08:18 -0500
Links: << >>  << T >>  << A >>
Look at the multiplier page on my website.  The section you are interested
in is the scaling accumulator multipliers.    The scaling accumulator
architecture has an advantage over a modified booth serial by parallel
multiplier (built as a chain of serial adders) in that it can be run in msb
and lsb first systems and the result can be trimmed easily.  The output is
parallel.  The modified booth architecture (currently not on my website) has
a maximum clock rate advantage, as there is no combinatorial carry
propagation to slow it down.  The modified booth output is serial, LSB first
and the serial input needs to be padded so that it's length is the same as
the output length.  You can learn about the modified booth serial multiplier
by looking at my 'FIR fits in an FPGA' paper.  That paper discusses the
modified booth serial multiplier in detail.  The paper is also available on
my website.



John Kennedy wrote:

> I need some advice on how to implement a Bit-Serial multiplier using the
> Xilinx Logicore Scaled By 1/2 Accumulator.  I need to scale a 20 bit
> signed 2's complement number.  I am using XC4010 fpga to try to do some
> digital audio signal processing, and need a compact (ok if slow)
> multiplier.  Any advice would be greatly appreciated.
>
> John



--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 13959
Subject: Re: 22V10 Metastability - my 2c
From: Tim Forcer <tmf@ecs.soton.ac.uk.nojunk>
Date: Tue, 05 Jan 1999 14:22:32 +0000
Links: << >>  << T >>  << A >>
Peter wrote:
> 
>... 
> I have come across a weird problem.
> 
>...

And dozens of people generated oodles of interesting and useful replies,
all of this happening while I was not reading the group.  Fortunately
none of this excellent stuff has expired from my newsserver yet. 
Anybody feel like collating the material into a Webpage case study
somewhere?  Would get quite a few hits, I'm sure.

Sorry about coming to the party late, but there's a couple of things I
feel like adding.

The point made by several people, that one can code a state machine for
stable single output change per single input change only, then have the
minimiser/optimiser remove all supposedly redundant product terms and
open the door to internal glitches, is important, IMO.  In some of my
designs (using PLPL) I've deliberately edited the minimiser output file
to restore such (statically-redundant but dynamically-significant)
product terms.  Does anyone know of current tools where such "maximise"
options can be implemented by the tool rather than the designer?

FWIW, I had an almost identical problem to Peter's five years ago.  I
was decoding independent asynchronous interrupt sources into the
four-bit interrupt level for a SPARC CPU.  Synchronising the outputs (ie
making them registered) produced exactly the same problem Peter had -
intermittent false codes.  This was eventually traced to non-uniform
delays through the PLD's internals (alternatively the registers had
non-identical setup times or non-identical response to violation of
setup time - same results).  The right code always came out, but
sometimes there was a single cycle where the wrong code appeared first
(always the same wrong code for the same input pattern, went wrong
approx every 1 or 2 thousand times).  The solution was to make the
outputs combinatorial.  According to the SPARC data book, this should
have created more problems than it solved, but it didn't and the systems
have been working fine ever since.  Pre-synchronising the inputs (I'd
have used inverse clock) would have required adding a piggy-back IC to
the board, and was regarded as an option of last resort - there weren't
enough resources left in the PLD to do this internally, as there was
other functionality involved.

-- 
Tim Forcer               tmf@ecs.soton.ac.uk
Department of Electronics & Computer Science
The University of Southampton, UK

The University is not responsible for my opinions

Article: 13960
Subject: Re: 22V10 Metastability - my 2c
From: Jonathan Bromley <jsebromley@brookes.ac.uk>
Date: Tue, 05 Jan 1999 15:40:18 +0000
Links: << >>  << T >>  << A >>
Tim Forcer wrote:

<snip>
> In some of my
> designs (using PLPL) I've deliberately edited the minimiser output file
> to restore such (statically-redundant but dynamically-significant)
> product terms.  Does anyone know of current tools where such "maximise"
> options can be implemented by the tool rather than the designer?
>
Been there.  For all its many charms, PLPL had the serious disadvantage
that it never offered any localised control over minimisation.  I
haven't used it for a few years now, but IIRC there is some sort of
global control of optimisation level.  Typically, of course, designs
don't fit if you set this to a low enough level so that the hazard
covering terms are preserved.

Early versions of CUPL had the same problem, but for some time now it's
had a pragma (keyword? option? magic spell? hard to tell the difference
with CUPL) allowing you to control the minimisation strategy on an
output-by-output basis, which is often adequate.

For industrial as opposed to academic or prototyping applications, 
most people would regard it as unacceptable to have to hand-edit 
compiler output of any kind;  unless you can scriptfile the edit, which
seems unlikely in this case.

I have not myself met any tool which understands enough about the 
dynamics of state machines to be able to insert hazard covering 
terms automatically.  One of the problems, I think, is the extent 
to which such things are device-dependent.  Consider, for example, 
an attempt to hazard-cover an asynchronous transparent latch:

[version 1: no hazard coverage]
if (clk) then q=d else q=q   ---maps to-->    q = clk.d + /clk.q

[version 2: hazard covered]
q = clk.d + /clk.q + d.q

Commonsense says that version 1 is dodgy and version 2 is OK.  BUT:
in QuickLogic FPGAs, for example, [1] works just fine because clk is used
as the select input to a multiplexer implemented by break-before-make 
pass transistors with capacitive hold on its output.  On the other
hand, it is possible to imagine table-lookup implementations of
3-input OR which could make [2] fail despite the extra term.

The net result is that any tool that attempts to achieve automatic hazard
coverage will need to preserve information about the dynamic behaviour of 
the logic (which transitions it will make) all the way down to the
hardware - even, perhaps, down to place-and-route - in order to decide
how to implement the hazard coverage.

Or am I missing something?

Jonathan Bromley

Article: 13961
Subject: FPGA development system
From: renzo.arce@st.com
Date: 5 Jan 99 16:02:50 GMT
Links: << >>  << T >>  << A >>
Hi,

I am implementing a hardware lab. for our research's group and 
I must to make a decision on whish FPGA development system to buy
(Altera, Xilinx, etc).

We develop research's projects and we need a system hw/sw to 
simulate, debbuging and hardware implementation of advanced 
algorithm applications.

Somebody can give me some suggest?

Best regards

Renzo Arce
STMicroelectronics
Italy
renzo.arce@st.com

Article: 13962
Subject: Re: 22V10 Metastability - help please
From: tronsmith@my-dejanews.com
Date: Tue, 05 Jan 1999 16:37:45 GMT
Links: << >>  << T >>  << A >>
Yes, but how about the original poster, Peter?
Have been able to get your state machine running,
and what seems to have been the problem?

 Was it actually a meta-stability problem
 (which most respondents seem to agree not)
 or really a logic hazard condition ( cured
 by the addition of a 'redundant' coverage
 product term ) ?

 To get overly specific, if your state bits
are labelled [s2 s1 s0], the final equations
should include (sorry, ABEL was my PLD language
of choice):

 s2 := (other state control product terms)
     # s2 & !s1 & !s0 ;

  That term will fix your problem of going
from 100 to 001 instead of 100 to 101.

  BTW, IIRC, the ABEL documentation ( I know,
you're using a different package ) used to
have a description of this problematic
characteristic of PLDs.

  Once you understand all the ins and outs of
this idea of logic hazard, you are well on
the way towards having the necessary tools for
designing completely asynchronous state machines.
These are not generally recommended, but can
be useful when raw speed in response to an
input change is the most important design
requirement.


  John Chambers <johnc@ihr.mrc.ac.uk> wrote:
> This thread has provided the solution to a problem I've been working on
> for about 2 months.  Many thanks to the insight provided by everybody
> here on the (rather more complex than first expected) subject of state
> machines.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Article: 13963
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10 Metastability - help please
From: Peter Alfke <peter@xilinx.com>
Date: Tue, 05 Jan 1999 08:54:56 -0800
Links: << >>  << T >>  << A >>
Hal Murray wrote:

> Big snip here.  I'm extracting the parts I want to comment on.  I
> don't
> think I've tossed too much context.
>
> > I never said that metastability does not exist. I have measured it.
> It does
> > exist, but the recovery delay  from the metastable (=balanced)
> condition to the
> > ultimately stable state is so short in modern CMOS latches and
> flip-flops, that
> > the problem has lost most of its impact.
>
> > 1. A modern CMOS latch can go metastable, but recovers so fast that
> the problem
> > is, in most applications, irrelevant. ( see curves in the Xilinx
> data book,
> > page 13-49 )
>
> I cringe when I see things like that, especially from people that I
> usually
> agree with.
>  

What I meant to say was:
If your asynchronous events occurs at a few MHz rate, and you clock at
less than 50 MHz, and you have a few ns "slop" between the synchronizing
flip-flop and the next flip-flop, and you use modern chips ( I should
say Xilinx XC4000XL, but I don't want to be accused of advertising...),
then you can safely ignore the metastable probability.

If you try to synchronize an asynchronous even that is well above 10
MHz, and your clock rate is so high that you have not even 2 ns spare
time, then you should think about meatstability and do some
calculations.

I wanted to dispel some of the paranoia, and explain that our flip-flops
have become dramatically better, actually more so than the general chip
performance and thus system clock rate. Flip-flop gain-bandwidth
benefits directly from advances in semiconductor processing, while chip
performance unfortunately gets dragged down by interconnect capacitance.

I did not realize the hornets nest...

Peter Alfke, Xilinx Applications
 
 

Article: 13964
Subject: Dynamic reconfig
From: soto@caviar.igce.unesp.br
Date: Tue, 05 Jan 1999 17:12:56 GMT
Links: << >>  << T >>  << A >>
Hi

     I heard Xilinx abandoned XC6200, favouring Virtex. But has Virtex nice
dynamic reconfigurable features like 6200 does ? I couldnt find anything in
Virtex specs...

     Any information would be appreciated.

     []s

               Walter

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Article: 13965
Subject: Re: FPGA development system
From: Ray Andraka <randraka@ids.net>
Date: Tue, 05 Jan 1999 13:02:39 -0500
Links: << >>  << T >>  << A >>
Depends on your application.  If you are going to be doing alot of
arithmetic data path stuff, I would recommend Xilinx for the reasons
I've mentioned several times in this forum.  If on the other hand, you
are doing general logic by synthesis, you might find the Altera tools
easier to use.  In a research environment, you probably want to stick
with SRAM type parts.  Actel's reconfigurable line is currently rather
limited (most of their parts are antifuse one-time programmable) as is
Quicklogic's line.  If you are looking at reconfigurable computing,
especially involving partial reconfiguration, then the Atmel parts are
currently the best choice.

renzo.arce@st.com wrote:

> Hi,
>
> I am implementing a hardware lab. for our research's group and
> I must to make a decision on whish FPGA development system to buy
> (Altera, Xilinx, etc).
>
> We develop research's projects and we need a system hw/sw to
> simulate, debbuging and hardware implementation of advanced
> algorithm applications.
>
> Somebody can give me some suggest?
>
> Best regards
>
> Renzo Arce
> STMicroelectronics
> Italy
> renzo.arce@st.com



--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 13966
Subject: Re: Dynamic reconfig
From: Ray Andraka <randraka@ids.net>
Date: Tue, 05 Jan 1999 13:12:20 -0500
Links: << >>  << T >>  << A >>
Virtex does have partial reconfiguration ability.  Partial configuration is
accomplished in columns (the whole column is reconfigured), which really limits
the usefulness for partial reconfiguration while the system clock is running.
Partial reconfiguration has many pitfalls.  The current xilinx tools certainly
do not provide the level of support needed to handle partially reconfigured
designs, especially on the Virtex parts.  To Xilinx's credit, they have not
touted the partial reconfigurability of the Virtex part.

Right now, the Atmel parts are better suited to handling partial
reconfiguration.  With those parts you do give up the speed and convenience of
carry chains and the small granularity of the CLB RAM (the AT40 K has 32x4 Rams
distributed in the array to help compensate for the lack of CLB Ram).

soto@caviar.igce.unesp.br wrote:

> Hi
>
>      I heard Xilinx abandoned XC6200, favouring Virtex. But has Virtex nice
> dynamic reconfigurable features like 6200 does ? I couldnt find anything in
> Virtex specs...
>
>      Any information would be appreciated.
>
>      []s
>
>                Walter
>
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own



--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 13967
Subject: Re: 22V10 Metastability - help please
From: Peter Alfke <peter@xilinx.com>
Date: Tue, 05 Jan 1999 10:54:16 -0800
Links: << >>  << T >>  << A >>
Ken Coffman wrote:

> What about a Xilinx HardWired device where the pass transistors are
> replaced
> with metal? Could be ugly...

HardWire re-maps the LUTs into "normal" logic, which means the
"glitch-free" feature may be lost. But when you ask for conversion to
Hardwire, Xilinx will send you a report of all suspect asynchronous
signals. It's then up to you to accept the conversion, or to change the
design.

Peter Alfke, Xilinx Applications
  

Article: 13968
Subject: Re: 22V10 Metastability - my 2c
From: z180@nospam24.com (Peter)
Date: Tue, 05 Jan 1999 19:27:54 GMT
Links: << >>  << T >>  << A >>

>The point made by several people, that one can code a state machine for
>stable single output change per single input change only, then have the
>minimiser/optimiser remove all supposedly redundant product terms and
>open the door to internal glitches, is important, IMO.  In some of my
>designs (using PLPL) I've deliberately edited the minimiser output file
>to restore such (statically-redundant but dynamically-significant)
>product terms.  

My problem was that I wrote a SM in the CUPL state machine language,
with only *one* async input deciding whether a) you remain in present
state, OR b) move to another state. With a gray-coded SM this should
have worked fine, without the need for any extra terms whatever.

It didn't, on an AMD device. While I have no conclusive proof, I am
sure the reason is a combination of 

a) the timing skew between the data and !data outputs of the *AMD*
22V10 input buffer, and

b) CUPL's use of both the true and complement of the async input

so in effect I was sampling *two* async inputs.

Regarding a) I found that the AMD 22V10 was awful, while the Philips
one was "perfect". (There was a probably unrelated problem with the
early Philips samples I had being thoroughly duff). I had email from a
Philips man who saw my posts and he basically says that they don't
guarantee identical prop delays in the input buffer - well this is
clear since that would be a theoretical impossibility anyway. I would
however have hoped that the skew between the two signals would be less
than the response time of the product term AND gate and this certainly
seems to be the case in the current Philips P3Z22V10 several of which
have been running for a week or two now with not one error.

Regarding b) I don't know how to avoid this. There *could* be a
feature in e.g. CUPL to use either the input **OR** the !input, but
not both, but there isn't. The only solution is to code the SM by hand
(yawn!) and not use the SM proprocessor. And not use any minimisation.

I don't regard CUPL as a particularly good tool; I just know it well.
I have just purchased the latest one, having been told by them that it
WILL run in an NT4 DOS box, and it doesn't.

>Does anyone know of current tools where such "maximise"
>options can be implemented by the tool rather than the designer?

Not me. Maybe some of the VHDL-based tools can do this.


--
Peter.

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

Article: 13969
Subject: Re: 22V10 Metastability - help please
From: z80@ds2.com (Peter)
Date: Tue, 05 Jan 1999 20:44:29 GMT
Links: << >>  << T >>  << A >>

>Yes, but how about the original poster, Peter?
>Have been able to get your state machine running,
>and what seems to have been the problem?
>
> Was it actually a meta-stability problem
> (which most respondents seem to agree not)
> or really a logic hazard condition ( cured
> by the addition of a 'redundant' coverage
> product term ) ?

It was the latter. I had incorrectly used the term "metastability".
Hopefully you will see my other post today summarising the situation.


--
Peter.

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

Article: 13970
Subject: Re: 22V10 Metastability - my 2c
From: z80@ds2.com (Peter)
Date: Tue, 05 Jan 1999 20:44:29 GMT
Links: << >>  << T >>  << A >>

It would be nice to be able to tell the SM compiler to not use *both*
the true and complement versions of an input pin, in the equations
that drive the D of a particular D-type.

Then, gray coding the SM and ensuring that the input can either
advance to one other state, or remain in present state, is enough to
prevent async input sampling problems - as far as I can see.

>The net result is that any tool that attempts to achieve automatic hazard
>coverage will need to preserve information about the dynamic behaviour of 
>the logic (which transitions it will make) all the way down to the
>hardware - even, perhaps, down to place-and-route - in order to decide
>how to implement the hazard coverage.


--
Peter.

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

Article: 13971
Subject: Re: 22V10 Metastability - my 2c
From: rbmccammon@mmm.com (Roy McCammon)
Date: Tue, 05 Jan 1999 14:58:29 -0600
Links: << >>  << T >>  << A >>
Peter wrote:

>current Philips P3Z22V10 several of which
> have been running for a week or two now with not one error.
> 

now that you have it working, try cooling and heating it.
Your problem may come back.



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

Article: 13972
Subject: Re: 22V10 Metastability - my 2c
From: rk <stellare@NOSPAMerols.com>
Date: Tue, 05 Jan 1999 16:31:46 -0500
Links: << >>  << T >>  << A >>
Roy McCammon wrote:

> Peter wrote:
>
> >current Philips P3Z22V10 several of which
> > have been running for a week or two now with not one error.
> >
>
> now that you have it working, try cooling and heating it.
> Your problem may come back.

and for kicks, ramp the voltage over some wide swings in 100 mv increments

rk

Article: 13973
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10 Metastability - help please
From: John Woodgate <jmw@jmwa.demon.co.uk>
Date: Tue, 5 Jan 1999 22:07:20 +0000
Links: << >>  << T >>  << A >>
<76sf7q$1ip@src-news.pa.dec.com>, Hal Murray <murray@pa.dec.com> wrote:
>If the problem is "irrelevant" for "most applications", how do I tell
>if I'm working on one where it is relevant?

Assume that it is, until you prove that it isn't. In other words, if it
works, OK; if it doesn't, don't rule out metastability as the cause.
-- 
Regards, John Woodgate, Phone +44 (0)1268 747839 Fax +44 (0)1268 777124. 
OOO - Own Opinions Only. You can fool all of the people some of the time, but 
you can't please some of the people any of the time.

Article: 13974
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10 Metastability - help please
From: John Woodgate <jmw@jmwa.demon.co.uk>
Date: Tue, 5 Jan 1999 22:08:22 +0000
Links: << >>  << T >>  << A >>
<3692438A.37DDD046@xilinx.com>, Peter Alfke <peter@xilinx.com> wrote:
> you should think about meatstability
Watch the fridge temperature!
-- 
Regards, John Woodgate, Phone +44 (0)1268 747839 Fax +44 (0)1268 777124. 
OOO - Own Opinions Only. You can fool all of the people some of the time, but 
you can't please some of the people any of the time.



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