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

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 14075

Article: 14075
Subject: Re: smallest DCT algorithm?
From: handleym@ricochet.net (Maynard Handley)
Date: Mon, 11 Jan 1999 15:55:13 -0800
Links: << >>  << T >>  << A >>
In article <uo9u2yjy4mw.fsf@netcom2.netcom.com>, Tom Lane <tgl@netcom.com>
wrote:

> 2. What you actually want is not a DCT but a quantized DCT.  Any
> multiply that you can push to the DCT-coefficient end of the operation
> can be eliminated by folding its constant into the coefficient 
> quantization factors that you're going to have to multiply or divide by
> anyway.  If you follow this road you find that you only need 5 or so
> multiplies per 1-D DCT inside the "DCT box" itself.  There are accuracy
> issues to contend with if you are using fixed-point math, but overall
> this approach yields the fastest practical DCT algorithms that I know
> about.

Call me an idiot, Tom, but it's not clear to me quite what you're getting
at here. 
The data flow simply following the spec looks something like 
    loop
        parse an AC coeff
        multiply it by quantization_scale*matrix[which AC Coeff]
    end loop
    IDCT this block which equals
     loop over rows and columns
        do a bunch of coeff[i]*some_fixed_point_value + more of the same

You seem to be proposing that this be replaced with 
    loop
        parse an AC coeff
    end loop
    IDCT this block which equals
     loop over rows and columns
        do a bunch of coeff[i]
         *quantization_scale*matrix[which AC Coeff]*some_fixed_point_value 
         + more of the same

So how does this in and of itself reduce the number of multiplies?

Is your assumption that quantization_scale changes infrequently (heck with
JPEG I don't know---maybe it's a one-off for the entire image) so that at
the start before parsing we calculate a matrix of size [64][11] which
equals 
quantization_scale*matrix[0..63]*theSpecificIDCTCoeff[0..10]?

Maynard

Article: 14076
Subject: Pre-route simulation in SYNOPSYS
From: Duck Foot <duckfoot11@hotmail.com>
Date: Tue, 12 Jan 1999 10:39:40 +0900
Links: << >>  << T >>  << A >>
    Will somebody give the detail on how to pre-simulate the netlist
generated with SYNOPSYS fpga compiler?

 i.e. I've used Altera's flex10k as the target library, and now try to
presim with flex10k's ftgs. In fact, I don't know even the differences
between ftgs, ftsm, etc.

    What I did after synthesis was adding the two lines

    library flex10k_ftgs;
    use flex10k_ftgs.all;

for each entity in the top netlist, and specify flex10k_ftgs in
.synopsys_vss.setup file.
    The result from running vhdldbx was so many WARNINGs for a component
being not instanced because it is unbound. For example, U147 - ATBL_1
which was instanced during synthesis is unbound.

    What's wrong? Do I have to configure all the instances, which, I'm
sure, is not the right way?

Article: 14077
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10 Metastability - help please
From: "Bruce Nepple" <brucen@imagenation.extra.com>
Date: Mon, 11 Jan 1999 18:19:35 -0800
Links: << >>  << T >>  << A >>
I have pretty strong opinions about this.  Hopefully when you read this you
will try to understand my points, not pick apart my choice of words:

1.  If you are a digital designer and you do not understand metastability,
you cannot do reliable digital design (except by luck, or as a synchronous
subsystem only)

2.  If you do not understand exactly what metastable behavior will do to
your design, your design should be considered "unsafe" in that it *might* do
something unpredictable.

3.  If you understand how often you design might fail due to metastability,
and the nature of the failure, and you are satisfied with it, you have done
your job.





>Fact is, I am designing relatively simple uP boards. I even
>have to write the software for it. My designs aren't 100%
>reliable, mostly because I haven't removed all software
>flaws yet. I can understand that one can get excited about
>metastability, but *I* couldn't care less. The article I
>have read, showed an example where an improvement was
>suggested, putting 2 d-flipflops in cascade, resulting in 1
>occurence of metastability once every 2 million years.
>Although very interesting, I am not even considering that
>advice for my future designs, because I like to see this
>metastability-thing at least once in my life.
>
What was the failure rate *before* the second flip flop was added?  The
whole point is that the second flip-flop makes the failure rate tolerable
(in most situations).  My rule of thumb is that if the metastable failure
rate is better that the failure rate for the worst part in the system, then
I'm in the right ballpark.  If your software crashes once a week, (and you
work for Microsoft so that is OK with you <g>),  then your metastable
requirements have opened up nicely.

The important point is that every digital designer *must* consider
metastability in the context in which the design is being done.  It should
never be totally overlooked.

bruce

"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

"Having spend untold hours debugging digital designs, I can assure you that
metastable behavior is a real problem, and every digital designer had better
understand it"
Bruce Nepple
12/31/98



Article: 14078
Subject: Re: smallest DCT algorithm?
From: Tom Lane <tgl@netcom.com>
Date: Tue, 12 Jan 1999 02:41:30 GMT
Links: << >>  << T >>  << A >>
handleym@ricochet.net (Maynard Handley) writes:
> Tom Lane <tgl@netcom.com> wrote:
>> 2. What you actually want is not a DCT but a quantized DCT.  Any
>> multiply that you can push to the DCT-coefficient end of the operation
>> can be eliminated by folding its constant into the coefficient 
>> quantization factors that you're going to have to multiply or divide by
>> anyway.  If you follow this road you find that you only need 5 or so
>> multiplies per 1-D DCT inside the "DCT box" itself.

> Call me an idiot, Tom, but it's not clear to me quite what you're getting
> at here. 
> The data flow simply following the spec looks something like 
>     loop
>         parse an AC coeff
>         multiply it by quantization_scale*matrix[which AC Coeff]
>     end loop
>     IDCT this block which equals
>      loop over rows and columns
>         do a bunch of coeff[i]*some_fixed_point_value + more of the same

> You seem to be proposing that this be replaced with 
>     loop
>         parse an AC coeff
>     end loop
>     IDCT this block which equals
>      loop over rows and columns
>         do a bunch of coeff[i]
>          *quantization_scale*matrix[which AC Coeff]*some_fixed_point_value 
>          + more of the same

> So how does this in and of itself reduce the number of multiplies?

No, that's not what I'm getting at.  What you do is adjust the
quantization multipliers (matrix[n] in your pseudocode above)
by multiplying them by DCT-determined constants before you start
the decoding pass.  The pseudocode still looks much as in your
first example --- but the number of multiplies needed per 1-D DCT
drops from 11 or so to 5 or so (something that can't be seen in
your pseudocode, since it glosses over the contents of the DCT step).

JPEG doesn't have quantization_scale, btw, unless you are implementing
some of the Part 3 extensions.

> Is your assumption that quantization_scale changes infrequently (heck with
> JPEG I don't know---maybe it's a one-off for the entire image) so that at
> the start before parsing we calculate a matrix of size [64][11] which
> equals 
> quantization_scale*matrix[0..63]*theSpecificIDCTCoeff[0..10]?

I'm not following what the second subscript is supposed to represent there,
but it's not needed in what I'm thinking of.

			regards, tom lane
			organizer, Independent JPEG Group

Article: 14079
Subject: Metastability Described
From: "Bruce Nepple" <brucen@imagenation.extra.com>
Date: Mon, 11 Jan 1999 18:43:27 -0800
Links: << >>  << T >>  << A >>
Please go to:

http://www.ti.com/sc/docs/psheets/abstract/apps/sdya006.htm

and all will be revealed!

bruce




Article: 14080
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10
From: Ray Andraka <randraka@ids.net>
Date: Mon, 11 Jan 1999 22:47:56 -0500
Links: << >>  << T >>  << A >>


Peter Alfke wrote:

> Luckily, most asynchronous interfaces operate at a much
> slower pace.

Peter,

I must admit I am surprised to hear you say this.  I guess you've
succumbed to the 'most designs' philosophy that had Xilinx management
convinced to not support schematic simulation for Virtex.  I suppose if
you consider that "most" FPGA designs are just random logic to
consolidate a bunch of TTL into one chip then OK.   When dealing with
high performance DSP designs such as found in radar and digital
communications, it is fairly common to have an async interface running
data rates in the 50-100 MHz range, often between clock domains with
similar clock rates.

--
-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: 14081
Subject: Re: smallest DCT algorithm?
From: Ray Andraka <randraka@ids.net>
Date: Mon, 11 Jan 1999 22:48:05 -0500
Links: << >>  << T >>  << A >>
The symmetry in a 1D DCt can be exploited to reduce the multiplies.
Additionally, if you look at the cos terms, you can pair terms so that you get
a sin and cos, then by using a CORDIC rotator you get two terms at a time
without an explicit multiplication.  By taking advantage of the sin and cos
plus symmetry, an 8 point DCT can be done with 6 CORDIC rotations and a bunch
of butterfly operations each consisting of an add and a subtract.  For high
speed (completely pipelined) hardware, the resulting complexity (number of
CLBS) is about the same as a distributed arithmetic approach.

The CORDIC approach appears off hand to have a smaller error than the
straightforward multipliers too because the number of truncations is reduced
in the process.

Maynard Handley wrote:

> In article <uo9u2yjy4mw.fsf@netcom2.netcom.com>, Tom Lane <tgl@netcom.com>
> wrote:
>
> > 2. What you actually want is not a DCT but a quantized DCT.  Any
> > multiply that you can push to the DCT-coefficient end of the operation
> > can be eliminated by folding its constant into the coefficient
> > quantization factors that you're going to have to multiply or divide by
> > anyway.  If you follow this road you find that you only need 5 or so
> > multiplies per 1-D DCT inside the "DCT box" itself.  There are accuracy
> > issues to contend with if you are using fixed-point math, but overall
> > this approach yields the fastest practical DCT algorithms that I know
> > about.
>
> Call me an idiot, Tom, but it's not clear to me quite what you're getting
> at here.
> The data flow simply following the spec looks something like
>     loop
>         parse an AC coeff
>         multiply it by quantization_scale*matrix[which AC Coeff]
>     end loop
>     IDCT this block which equals
>      loop over rows and columns
>         do a bunch of coeff[i]*some_fixed_point_value + more of the same
>
> You seem to be proposing that this be replaced with
>     loop
>         parse an AC coeff
>     end loop
>     IDCT this block which equals
>      loop over rows and columns
>         do a bunch of coeff[i]
>          *quantization_scale*matrix[which AC Coeff]*some_fixed_point_value
>          + more of the same
>
> So how does this in and of itself reduce the number of multiplies?
>
> Is your assumption that quantization_scale changes infrequently (heck with
> JPEG I don't know---maybe it's a one-off for the entire image) so that at
> the start before parsing we calculate a matrix of size [64][11] which
> equals
> quantization_scale*matrix[0..63]*theSpecificIDCTCoeff[0..10]?
>
> Maynard



--
-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: 14082
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10 Metastability - help please
From: murray@pa.dec.com (Hal Murray)
Date: 12 Jan 1999 06:47:12 GMT
Links: << >>  << T >>  << A >>
> Surely, if you can reliably detect the m-state, you can force it
> whichever way you want in a defined time, if possible short enough not
> to be of any significance? 

I don't think so.  You just pushed things around.

Consider what happens if the FF is late but about to switch to a 1,
and your window says "bad" and tries to fix it by resetting the FF.
(If your extra circuit wasn't there everything would be fine.)

You might get a runt pulse out of your circuit.  After that, all
bets are off.  (Unless you wait long enough, but then you would
have been better to start waiting when the clock ticked.)

I'm assuming that you gate your fix-up logic with, say, the middle
1/3 of the cycle.  You have to do something like that or your circuit
will go off everytime the FF tries to switch.

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

Article: 14083
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10 Metastability - help please
From: murray@pa.dec.com (Hal Murray)
Date: 12 Jan 1999 08:39:50 GMT
Links: << >>  << T >>  << A >>
> I don't know if it's possible to construct a device that guarantees a
> metastability time limit.  I am not convinced by the hand-waving
> arguments around here that say it's impossible -- but the maths is not
> simple.  A real device does not have one or two continuous state
> parameters, but infinitely many (think of the internal energy flows).

This whole mess might makes more sense if you put on an analog hat rather
than your digital one.  Both Mead and Conway and Glasser and Dobberphul
have good graphs.

Consider the internal voltage inside the FF.  If it is near the
metastability point it will drift exponentially to high or low.
The closer to the metastability point it starts the longer it
takes to get to a valid signal level.

When the clock ticks, that internal voltage gets set depending 
upon the input voltage.  (Or maybe the input voltage a few ns
before or after the clock.)

If you change the input voltage just a bit early or late, the internal
voltage will be close to metastable and it will take a long
time to recover to a clean output.

One of the standard reasons to show that metastability is
unavoidable is because the input voltage and internal voltage are
continous functions.  You also have to prove that any bi-stable device
is going to have similar characteristics.


Johnson and Graham have a very good section in their High-Speed Digital
Design - A Handbook of Black Magic.  They have a graph of clock-out time
as a function of input setup/hold time.  Ugly.  They also have a setup
for teasing metastability and a lot of really ugly scope pictures.

It is a wonderful book.  Everybody interested in fast designs should
get a copy.

----

Thanks for suggesting Mead and Conway.

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

Article: 14084
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10
From: rk <stellare@NOSPAMerols.com>
Date: Tue, 12 Jan 1999 05:32:02 -0500
Links: << >>  << T >>  << A >>
hi tim,

a few questions, comments.

good evening,

rk

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

Tim Hubberstey wrote:

      Peter Alfke wrote:
      >
      [snip}
      > I was just pointing out that the best of modern CMOS
      > flip-flops have reduced the likelihood of metastability to a
      > point where we can be more relaxed about it.
      > But it still makes for a spirited discussion...
      >
      > Peter Alfke
      > Xilinx Apps.

      I've heard these sentiments echoed in several posts in this thread and

      I'm afraid I have to disagree.

i basically agree with peter.  many situations a decade ago which drove a
design are now easily handled, as long as the design is reasonable (proper
syncing) and adequate settling time is provided.  for instance, a 100 kHz
request to memory on a 2.25 MHz clock is easy with modern technologies..
now, the case you describe is a bit different, with about 13 nsec for the
clock->clock delay.

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

      I am currently involved in a design involving several chips using a
0.25
      micron process from a large, respected vendor (who will remain
      undisclosed due to NDAs) and we have found metastability to be a very
      real potential problem. The chips in question fall into the "system on
a
      chip" category and as such have several high-speed clock domains.
      Analysis by the vendor has predicted an MTBF of less than a minute for

      the standard 2 flip-flop synchronizer when going between a 60 MHz and
a
      75 MHz clock domain. This is obviously not something "we can be more
      relaxed about".

no, this is not something to be relaxed about.  i started to run some
numbers on some different technologies, but i would like to run exactly your
case.  first, how often does the signal on the 60 MHz clock change?  second,
how much time is available in the 75 MHz clock period for settling?  lastly,
did you select the flip-flop for it's use in a synchronizer or did the
vendor analyze the flip-flop that the synthesis tool selected?  running some
numbers on chip express, for example, one can see that the choice of flip
flop can make a big difference in the results.  here's an example, assuming
a sync running at 75 MHz, and the data coming from the 60 MHz domain
switching at a 20 MHz average rate.

***************************************
Manufacturer = ChipExpress
F-F Model    = CX2000_DMxPP_FALL
Minimum Slack   = 1.000
Maximum Slack   = 13.000
Slack Increment = 1.000
K1 = 0.300
K2 = 6.000
Clock Frequency =  7.5000E+0007
Data Frequency  =  2.0000E+0007

Slack Time         MTBF (sec)        MTBF (years)
      1.00      8.965084E-0004      2.842810E-0011
      2.00      3.616773E-0001      1.146871E-0008
      3.00      1.459110E+0002      4.626809E-0006
      4.00      5.886472E+0004      1.866588E-0003
      5.00      2.374772E+0007      7.530353E-0001
      6.00      9.580515E+0009      3.037961E+0002
      7.00      3.865055E+0012      1.225601E+0005
      8.00      1.559275E+0015      4.944427E+0007
      9.00      6.290563E+0017      1.994724E+0010
     10.00      2.537794E+0020      8.047293E+0012
     11.00      1.023819E+0023      3.246510E+0015
     12.00      4.130382E+0025      1.309735E+0018
     13.00      1.666315E+0028      5.283850E+0020

    MTBF Improvement per increment = 403.429

***************************************
Manufacturer = ChipExpress
F-F Model    = CX2000_TFxPC_FALL
Minimum Slack   = 1.000
Maximum Slack   = 13.000
Slack Increment = 1.000
K1 = 6.900
K2 = 3.400
Clock Frequency =  7.5000E+0007
Data Frequency  =  2.0000E+0007

Slack Time         MTBF (sec)        MTBF (years)
      1.00      2.895082E-0006      9.180245E-0014
      2.00      8.674853E-0005      2.750778E-0012
      3.00      2.599342E-0003      8.242458E-0011
      4.00      7.788693E-0002      2.469778E-0009
      5.00      2.333812E+0000      7.400469E-0008
      6.00      6.993057E+0001      2.217484E-0006
      7.00      2.095407E+0003      6.644491E-0005
      8.00      6.278697E+0004      1.990962E-0003
      9.00      1.881355E+0006      5.965738E-0002
     10.00      5.637312E+0007      1.787580E+0000
     11.00      1.689170E+0009      5.356322E+0001
     12.00      5.061445E+0010      1.604974E+0003
     13.00      1.516616E+0012      4.809159E+0004

    MTBF Improvement per increment = 29.964

assuming 10 nsec of slack, and the above numbers, we have either 8E+12 years
as a mtbf or 1.8 years, which is
clearly not very good.  in any event, quite a large difference, which was
the point.  additionally, choice of edge makes a difference, too.

the data below, on a xilinx part, shows the best performance.

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

      One of the biggest contributors to this problem turns out to be
junction
      temperature. In these days of systems on a chip, the die will often
have
      a worst case temperature spec of over 100C. The vendor's projections
      show a 10000-fold difference in MTBF across a die temperature range of

      0C to 100C.

10^4 is quite a difference.  did they supply a curve of mtbf vs.
temperature?

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

    >  Your comment may be valid for FPGAs (I defer to your experience here)

    > but I can't agree with it as a blanket statement.

here's some numbers, with the same assumptions, run on an FPGA:

***************************************
Manufacturer = Xilinx
F-F Model    = XC4005E-3_CLB
Minimum Slack   = 1.000
Maximum Slack   = 13.000
Slack Increment = 1.000
K1 = 0.100
K2 = 19.400
Clock Frequency =  7.5000E+0007
Data Frequency  =  2.0000E+0007

Slack Time         MTBF (sec)        MTBF (years)
      1.00      1.775095E+0003      5.628790E-0005
      2.00      4.726445E+0011      1.498746E+0004
      3.00      1.258483E+0020      3.990626E+0012
      4.00      3.350893E+0028      1.062561E+0021
      5.00      8.922231E+0036      2.829221E+0029
      6.00      2.375672E+0045      7.533206E+0037
      7.00      6.325566E+0053      2.005824E+0046
      8.00      1.684272E+0062      5.340793E+0054
      9.00      4.484616E+0070      1.422062E+0063
     10.00      1.194093E+0079      3.786445E+0071
     11.00      3.179444E+0087      1.008195E+0080
     12.00      8.465724E+0095      2.684464E+0088
     13.00      2.254120E+0104      7.147768E+0096
    MTBF Improvement per increment = 266264304.669

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

  Tim Hubberstey, P.Eng. . . . . . . . . . . . . . .  Marmot Engineering
  Vancouver, BC, Canada  . . . . . Hardware/Software Consulting Engineer
  Email: marmot@rogers.wave.ca . . . . . . VHDL, ASICs, embedded systems

Article: 14085
Subject: Pre-simulation in SYNOPSYS
From: Duck Foot <duckfoot11@hotmail.com>
Date: Tue, 12 Jan 1999 19:51:50 +0900
Links: << >>  << T >>  << A >>
    Will somebody give the detail on how to pre-simulate the netlist
generated with SYNOPSYS fpga compiler?

 i.e. I've used Altera's flex10k as the target library, and now try to
presim with flex10k's ftgs. In fact, I don't know even the differences
between ftgs, ftsm, etc.

    What I did after synthesis was adding the two lines

    library flex10k_ftgs;
    use flex10k_ftgs.all;

for each entity in the top netlist, and specify flex10k_ftgs in
.synopsys_vss.setup file.
    The result from running vhdldbx was so many WARNINGs for a component

being not instanced because it is unbound. For example, U147 - ATBL_1
which was instanced during synthesis, says the simulator, is unbound.

    What's wrong? Do I have to configure all the instances, which, I'm
sure, is not the right way.



Article: 14086
Subject: Problems with processes
From: "Jeffrey L. Madden" <jlmadden@iupui.edu>
Date: Tue, 12 Jan 1999 10:03:06 -0500
Links: << >>  << T >>  << A >>
I am using FPGA Express with Foundation Series 1.4 to implement VHDL
code. I have been coming accross problems when using processes in my
code and I usually receive a warning that the output of the cell is
constant. This causes the cell to be eliminated when it is optimized. I
am using the student edition of this software if it makes any
difference. Here is a simple VHDL program that this error occurs with...

*****************************************
library IEEE;
use IEEE.std_logic_1164.all;
entity dff is
    port(D:in std_logic;
        CLK:in std_logic;
        CLEAR:in std_logic;
        Q:out std_logic);
end dff;

architecture dff1 of dff is
    signal V: std_logic;
begin
    process(CLK, CLEAR)
    begin
        if CLEAR = '1' then
            V <= '0';
        elsif (CLK = '1' and CLK'event) then
            V <= D;
        end if;
    end process;
    Q <= V;
end dff1;
**************************************************
Any help in this matter would be greatly appreciated.

    Thanks,
    Nick

Article: 14087
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10
From: Tim Hubberstey <marmot@rogers.wave.ca>
Date: Tue, 12 Jan 1999 16:14:17 +0000
Links: << >>  << T >>  << A >>
rk wrote:
> 
[snip]
> Tim Hubberstey wrote:
>       Peter Alfke wrote:
>       > I was just pointing out that the best of modern CMOS
>       > flip-flops have reduced the likelihood of metastability to a
>       > point where we can be more relaxed about it.
>       > But it still makes for a spirited discussion...
>       >
>       > Peter Alfke
>       > Xilinx Apps.
>       I've heard these sentiments echoed in several posts in this thread and
>       I'm afraid I have to disagree.
> i basically agree with peter.  many situations a decade ago which drove a
> design are now easily handled, as long as the design is reasonable (proper
> syncing) and adequate settling time is provided.  for instance, a 100 kHz
> request to memory on a 2.25 MHz clock is easy with modern technologies..
> now, the case you describe is a bit different, with about 13 nsec for the
> clock->clock delay.

I agree with both of you 100%. *IF* you are dealing with a situation
such as 
those that existed a decade ago then metastability is much less of a
problem.

My point, which I apparently didn't make clearly, is that my design
problem
is typical of those encountered in *CURRENT* leading-edge designs and
that you
cannot be complacent just because processes have improved. I have 
encountered similar problems in other recent designs.

[lots of interesting stuff snipped]

>       One of the biggest contributors to this problem turns out to be
> junction
>       temperature. In these days of systems on a chip, the die will often
> have
>       a worst case temperature spec of over 100C. The vendor's projections
>       show a 10000-fold difference in MTBF across a die temperature range of
>       0C to 100C.
> 10^4 is quite a difference.  did they supply a curve of mtbf vs.
> temperature?

Yes. That's where this data came from. Again, this is an example of a
current
design problem. 10 years ago I would never have considered designing for
a 
die temperature this high but without expensive cooling, fancy packages
and/or
gated clocks, this is the reality.

[FPGA data snipped]
--
Tim Hubberstey, P.Eng. . . . . . . . . . . . . . .  Marmot Engineering
Vancouver, BC, Canada  . . . . . Hardware/Software Consulting Engineer
Email: marmot@rogers.wave.ca . . . . . . VHDL, ASICs, embedded systems

Article: 14088
Subject: cypress isp cable?
From: ricchettiNOSPAM@eidomedia.com (Matteo Ricchetti)
Date: Tue, 12 Jan 1999 16:50:21 GMT
Links: << >>  << T >>  << A >>
Hi everyone,
can someone tell me which harware is presente in the cypress ISP cable
? Are there  just some buffers?

Thanks in advance

Matteo Ricchetti

ricchetti@eidomedia.com

Togliere NOSPAM dall' indirizzo 

Article: 14089
Subject: Re: programming language interface
From: rajesh52@my-dejanews.com
Date: Tue, 12 Jan 1999 18:27:13 GMT
Links: << >>  << T >>  << A >>
Greetings
Please check Verilog FAQ for list of free Verilog Simulators
It is located at http://www.angelfire.com/in/verilogfaq/


Here is s list of free simulators


There are three free Verilog simulators available with limited capabilities.

SILOS III from Simucad.  www.simucad.com SILOS III's high performance logic
and fault simulation environment supports the Verilog Hardware Description
Language for simulation at multiple levels of abstraction. The Environment's
state-of-the-art architecture incorporates an exclusive integrated / 
interactive multi-tasking graphical debugging environment that provides
unsurpassed accuracy and outstanding performance.

VeriLogger from SynaptiCAD
VeriLogger is a free an IEEE-1364 compliant Verilog simulator. VeriLogger
combines many of the best ideas from modern programming IDEs and
SynaptiCAD's timing diagram editing environment to created an interactive
simulator with graphical stimulus generation. VeriLogger has a powerful
hierarchical browser that displays the structural relationships of the
modules. It also includes waveform viewing, single step debugging,
point-and-click breakpoints, graphical and console execution (command line
version). Download a free evaluation version of VeriLogger Pro from
http://www.syncad.com/


SMASH from Dolphin Integration Dolphin Integration offers evaluation version
of SMASH simulator which is a mixed signal,multi-level simulator.SMASH
implements the full Verilog-HDL IEEE standard. The implementation is based on
the OVI Reference Manuals. SMASH supports the SDF (Standard Delay File)
format, to allow backannotation from layout tools. This evaluation version is
a full-featured system (they will not allow you to compile new behavioral
models though). They will not handle large circuits. The number of analog
nodes is limited to 25, and the number of digital nodes is limited to 50.
http://www.dolphin.fr/


Hope this helps.
Rajesh

Verilog Page : http://www.angelfire.com/in/rajesh52/verilog.html



In article <iUem2.3623$id.220@cabot.ops.attcanada.net>,
  "Michael Faltas" <mfaltas@attcanada.net> wrote:
> Does anyone know of a free Verilog simulator for any platform?
>
> takehiro@rr.iij4u.or.jp wrote in message
> <3698D73F.A044BCF8@rr.iij4u.or.jp>...
> >Dear all,
> >
> >I look for free Verilog-HDL simulator which lets me experience PLI
> >operation.
> >Does anyone have information on this?
> >I wish the Verilog-HDL simulator to run on Windows98(95)/NT.
> >
> >Thanks,
> >Hiro
> >
> >
>
>

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

Article: 14090
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10 Metastability - help please
From: "Frank Bemelman" <fbemelx@euronet.nl>
Date: Tue, 12 Jan 1999 22:01:48 +0100
Links: << >>  << T >>  << A >>
Bruce Nepple heeft geschreven in bericht ...
>I have pretty strong opinions about this.  Hopefully when
you read this you
>will try to understand my points, not pick apart my choice
of words:


I like strong opinions - it was the *crime against humanity*
(rk wrote that) comparison that made me write my reply ;-)

>1.  If you are a digital designer and you do not understand
metastability,
>you cannot do reliable digital design (except by luck, or
as a synchronous
>subsystem only)


Depends on how strict you specify 'reliable'. Don't forget
the possibilities to correct errors, by hardware and/or
software or whatever. Even with circuits that simply can't
suffer from metastability by design, it's not unusual to add
some extra safety, if certain risks are at
stake.

>2.  If you do not understand exactly what metastable
behavior will do to
>your design, your design should be considered "unsafe" in
that it *might* do
>something unpredictable.


Point taken. OTH for practical reasons it's not always
possible to mathematically prove that for instance a piece
of software will always behave according the intentions of
it's maker. Unpredictable systems are a part of life.
Metastabillty or not...

>3.  If you understand how often you design might fail due
to metastability,
>and the nature of the failure, and you are satisfied with
it, you have done
>your job.

A very good argument - the nature of the failure has a very
important weight.


>What was the failure rate *before* the second flip flop was
added?  The
>whole point is that the second flip-flop makes the failure
rate tolerable

54 minutes, it was a circuit that clocked a d-flipflop
(sn74als74)with a 10 Mhz system clock, and the q-output was
used to trigger an interrupt. This is -partially -  a kind
of circuit I sometimes use. The document also recommended a
different logic family (sn74as74) use for the particular
circuit, resulting in 2.4 x 10^21 years. If another logic
family is out of the question, a two stage circuit can be
made, resulting in 2 million years MTBF.

Even if my input circuit fails once per hour, it would not
hurt much, because I have not  the exactly the same circuit
as the example circuit. My input signal is much less than
10mhz, and the interrupt will be generated anyway, although
one clockcycle later. This is something I can live with,
because nobody would notice. The interrupt latency is much
and much bigger than this 0.1 uSec.

>(in most situations).  My rule of thumb is that if the
metastable failure
>rate is better that the failure rate for the worst part in
the system, then
>I'm in the right ballpark.  If your software crashes once a
week, (and you
>work for Microsoft so that is OK with you <g>),  then your
metastable
>requirements have opened up nicely.

>The important point is that every digital designer *must*
consider
>metastability in the context in which the design is being
done.  It should
>never be totally overlooked.

Your last phrase puts it (imho) in a nice perspective.

Met vriendelijke groeten,
Frank Bemelman
(reageren per email ? verwijder dan de 'x' uit mijn
emailadres)








Article: 14091
Subject: Re: smallest DCT algorithm?
From: knguyen <knguyen@ece.ubc.ca>
Date: Tue, 12 Jan 1999 13:12:03 -0800
Links: << >>  << T >>  << A >>
>
> > Tom Lane <tgl@netcom.com> wrote:
> >> 2. What you actually want is not a DCT but a quantized DCT.  Any
> >> multiply that you can push to the DCT-coefficient end of the operation
> >> can be eliminated by folding its constant into the coefficient

And the quantizing process can also be embedded into the DCT computation itself,
as described in "Quantized Discrete Cosine Transform: A Combination of DCT
and Scalar Quantization" by K.Nguyen-Phi et al., ICASSP'99.

Khanh Nguyen-Phi


Article: 14092
Subject: Re: cypress isp cable?
From: "Joel Kolstad" <JKolstad@Electroglas.Com>
Date: Tue, 12 Jan 1999 18:42:33 -0800
Links: << >>  << T >>  << A >>
Matteo Ricchetti wrote in message
<369b7cb0.21532686@news.interbusiness.it>...
>Hi everyone,
>can someone tell me which harware is presente in the cypress ISP cable
>? Are there  just some buffers?

It's just a buffer and a "brick" style DC to DC converter.  The Cypress
CPLDs use 12V during programming, and the Cypress ISP cable steals 5V from
your board and runs it through the DC to DC converter to provide that 12V.

I believe Cypress publishes the schematic of the thing somewhere.

Interestingly enough, the early versions of the Cypress cables used a
Cypress brand buffer that didn't interpret the output voltage levels of many
parallel ports the way the parallel port intended.  Newer versions use a
non-Cypress chip (different logic family) with different voltage thresholds.
:-)

---Joel Kolstad



Article: 14093
Subject: Foundation v1.5i Spartin Problems
From: "Mark Sasten" <sasten@gte.net>
Date: Tue, 12 Jan 1999 22:25:15 -0800
Links: << >>  << T >>  << A >>
I was wondering if anyone else has been having problems with the Foundation
v1.5i when compiling to a Spartin device.  (Specificly a XCS30-PQ208).

I have just installed the update and re-fit the design as a new revision.
Everything seems to run fine.  The processing reports about the same
statistics, but when I go to download using XChecker I get an error about
"INIT does not go high".  Everything is set up exactly the same as when I
ran it with v1.5.  The hardware debugger gets all the way through the
download before reporting this.

I uninstalled 1.5i and reinstalled 1.5, recompiled and was up and running
again.  When I initially installed v1.5i I uninstalled the previous version
as the documentation stated.

Thanks,

Mark Sasten
Apex PC Solutions


Article: 14094
Subject: Re: programming language interface
From: Andy Botterill <csm@plymouth2.demon.co.uk>
Date: Wed, 13 Jan 1999 06:45:09 +0000
Links: << >>  << T >>  << A >>
In article <77g460$57m$1@nnrp2.dejanews.com>, rajesh52@my-dejanews.com
writes
>SMASH from Dolphin Integration Dolphin Integration offers evaluation version
>of SMASH simulator which is a mixed signal,multi-level simulator.SMASH
>implements the full Verilog-HDL IEEE standard. The implementation is based on
>the OVI Reference Manuals. SMASH supports the SDF (Standard Delay File)
>format, to allow backannotation from layout tools. This evaluation version is
>a full-featured system (they will not allow you to compile new behavioral
>models though). They will not handle large circuits. The number of analog
>nodes is limited to 25, and the number of digital nodes is limited to 50.
>http://www.dolphin.fr/
>
Since this says it is mixed signal then does it support VERILOG-AMS ?
>
>Hope this helps.
>Rajesh
>
>Verilog Page : http://www.angelfire.com/in/rajesh52/verilog.html
>
>
>
>In article <iUem2.3623$id.220@cabot.ops.attcanada.net>,
>  "Michael Faltas" <mfaltas@attcanada.net> wrote:
>> Does anyone know of a free Verilog simulator for any platform?
>>
>> takehiro@rr.iij4u.or.jp wrote in message
>> <3698D73F.A044BCF8@rr.iij4u.or.jp>...
>> >Dear all,
>> >
>> >I look for free Verilog-HDL simulator which lets me experience PLI
>> >operation.
>> >Does anyone have information on this?
>> >I wish the Verilog-HDL simulator to run on Windows98(95)/NT.
>> >
>> >Thanks,
>> >Hiro
>> >
>> >
>>
>>
>
>-----------== Posted via Deja News, The Discussion Network ==----------
>http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

-- 
Andy Botterill

Article: 14095
Subject: Re: Problems with processes
From: "Jim King" <j_e_king@snotmail.com>
Date: Wed, 13 Jan 1999 10:17:30 -0000
Links: << >>  << T >>  << A >>

Jeffrey L. Madden wrote in message <369B642A.843BCDF1@iupui.edu>...
>I am using FPGA Express with Foundation Series 1.4 to implement VHDL
>code. I have been coming accross problems when using processes in my
>code and I usually receive a warning that the output of the cell is
>constant. This causes the cell to be eliminated when it is optimized. I
>am using the student edition of this software if it makes any
>difference. Here is a simple VHDL program that this error occurs with...
>
>*****************************************
>library IEEE;
>use IEEE.std_logic_1164.all;
>entity dff is
>    port(D:in std_logic;
>        CLK:in std_logic;
>        CLEAR:in std_logic;
>        Q:out std_logic);
>end dff;
>
>architecture dff1 of dff is
>    signal V: std_logic;
>begin
>    process(CLK, CLEAR)
>    begin
>        if CLEAR = '1' then
>            V <= '0';
>        elsif (CLK = '1' and CLK'event) then
>            V <= D;
>        end if;
>    end process;
>    Q <= V;
>end dff1;
>**************************************************
>Any help in this matter would be greatly appreciated.
>
>    Thanks,
>    Nick
>

I think it might have to do with the way you test for the clock edge.  I use
Express as well, and it is a bit picky about how the async clear and the
clock edge are tested for.  Try this:

process (clk, clear)
begin
if clear = '1' then
    V <= '0';
else
    if (clk = '1' and clk'event) then
        V <= D;
    end if;
end if;
end process;

I had this trouble.  In the help (somewhere) it says that the clock 'if
should simply be
if (clk stuff)
    code;
end if;
it should not have an else.  See the FPGA Express VHDL Reference (p.169 in
the .pdf version)

Something else:  is there a particular reason that you have the signal V?
Can't you simply assign D to Q within the process?

Hope this helps

Jim




Article: 14096
Subject: Re: Problems with processes
From: "Jim King" <j_e_king@snotmail.com>
Date: Wed, 13 Jan 1999 10:22:28 -0000
Links: << >>  << T >>  << A >>

Jeffrey L. Madden wrote in message <369B642A.843BCDF1@iupui.edu>...
>I am using FPGA Express with Foundation Series 1.4 to implement VHDL
>code.

I am on Express version 2.3ish, the reference I mentioned is dated December
1997.  I don't know if there are any differences, but it may affect the
usefulness of my previous post.

Cheers
Jim


Article: 14097
Subject: Re: I2C core
From: "SoonHuat Goh" <soonhuat@singnet.com.sg>
Date: Wed, 13 Jan 1999 22:30:11 +0800
Links: << >>  << T >>  << A >>
There is a I2C EEPROM Simulator at the site below. See if
it is of any use. It is written in VHDL.

http://www.eiv.vsnet.ch/electro/micro/pages/Vhdl.htm

Best Regards,
SoonHuat Goh <soonhuat@singnet.com.sg>


saffary wrote in message <7768i9$s6r$1@front5.grolier.fr>...
>Anyone know where I can find i2c VHDL core.
>
>thank.
>
>


Article: 14098
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10
From: alanm@hpl.hp.com (Alan Marshall)
Date: Wed, 13 Jan 1999 14:48:36 GMT
Links: << >>  << T >>  << A >>
Dan Prysby (dprysby1@email.mot.com) wrote:
: So if a combination of 3 FFs sample 1 signal close enough in time
: and each has a different threshold by design, then only 1 will go
: metastable. Just a supposition.

Probably true, but in the marginal case 1 FF will vote "1", 1 FF will
vote "0", and the third will go metastable.  Then whatever circuit
combines the 3 votes can potentially give an invalid output level
(part way between what it would give if the third FF had voted "0" or "1").

In other words, your suggestion doesn't solve the problem completely,
but might affect the probablility of a metastable signal propagating.

Best regards,

Alan Marshall

Article: 14099
Subject: 1-wire
From: G Henry Yogendran <yogi@airwire.com>
Date: Wed, 13 Jan 1999 09:33:24 -0600
Links: << >>  << T >>  << A >>
Hi:

Can anybody tell me where I can get 1-wire interface code for
Dallas parts.


Henry
--
------------------------------------




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

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