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 32025

Article: 32025
Subject: Re: XC4005XL is it a modern chip?
From: robin@ivo.co.uk (Robin Kinge)
Date: 11 Jun 2001 06:27:16 -0700
Links: << >>  << T >>  << A >>
> Shameless plug ;-)

Sounds like a good start though. Anyone in the UK give us a clue if this available here?

Robin

Article: 32026
Subject: Re: Force tristate enable register into IOB
From: Matthias Fuchs <matthias.fuchs@esd-electronics.com>
Date: Mon, 11 Jun 2001 15:32:09 +0200
Links: << >>  << T >>  << A >>
Tobias Stumber wrote:
> Use:
>   attribute IOB: string;
>   attribute IOB of ge_mem_oe_reg : signal is "true";
> This makes XST to replicate the FFs again after (!) having merged them into
> one in the final optimization phase.
> Works great !
> 
> Tobias
Hi,

I tried to attach the IOb attribute but it did not work ! Even if I
instanciate FlipFlop components(FD) by hand, they are optimized away and
a single flop drives 16 tristate signals. I also tried the max_fanout
attribute:

attribute max_fanout : integer;
attribute max_fanout of ge_mem_tri_reg : signal is 1;

.. same result !

What is wrong ?

Matthias
-- 
-------------------------------------------------
\ Matthias Fuchs                                 \
 \ esd electronic system design Gmbh              \
  \ Vahrenwalder Straße 205                        \
   \ D-30165 Hannover                               \
    \ email: matthias.fuchs@esd-electronics.com      \
     \ phone: +49-511-37298-0                         \
      \ fax:   +49-511-37298-68                        \
       --------------------------------------------------

Article: 32027
Subject: Xilinx PCI core location constraints
From: "Jamie Sanderson" <jamie@nortelnetworks.com>
Date: Mon, 11 Jun 2001 11:24:52 -0400
Links: << >>  << T >>  << A >>
Hi all;

I am working on the initial floor plan of a design using the Xilinx PCI
core. Using their constraints generator, I have requested that the PCI pins
be on the slot side of the device. This causes them to be spread evenly
across the end of I/O bank 2 and beginning of bank 3. I would like to shift
the core and its I/O such that it resides within a single quadrant of a
device. I've been experimenting with their UCF generator, but am having a
problem. In the device I'm using, the IRDY and TRDY pins are the first two
pins in the 3rd bank. In the UCF generator, I have re-ordered the signals
such that the RDY lines are first, with all others following them.

This has nearly the desired effect. All of the pins are now in the third
bank. However, the internal location constraints do not make sense to me.
While most are shifted downwards in the Y plane, the address/data TBUFs are
shifted up. In other words, while the pins and everything else move down
into the South-East quadrant, the AD TBUFs have moved further into the
North-East quadrant.

Does anyone know why this is? Is it a bug in their UCF generator, or due to
some peculiarity of what I'm trying to do?

Thanks in advance,
Jamie



Article: 32028
Subject: Re: Xilinx webpack annoyances (long and whiny)
From: "Jeffrey Vallier" <jvallier@gibson.com>
Date: Mon, 11 Jun 2001 09:50:17 -0700
Links: << >>  << T >>  << A >>
(snip)

>
> Xilinx: are you listening?
>
> --andy
>

Welcome to the world of Xilinx :) In an unusual defensive stance for Xilinx,
I should let you know I met with the team leader for the Webpack project a
few weeks ago to discuss my _long_ list of gripes with the tool. They were
sincerely interested in listening to customer comments, so we should see
some improvements down the road...

cheers,

Jeff

--
***********************************************
Jeffrey Vallier            Sr. FW Engineer
Gibson Guitar Corp.  GMICS Division
1283 F Old Mtn View/Alviso Rd.
Sunnyvale, CA 94089 408 734 4394
***********************************************



Article: 32029
Subject: Re: Triscend A5: can it reconfigure itself?
From: "Steve Beaver" <sbeaver@columbus.rr.com>
Date: Mon, 11 Jun 2001 16:53:49 GMT
Links: << >>  << T >>  << A >>
At a recent seminar I attended on the Triscend chip, they said it could.

Steve



Article: 32030
Subject: Re: Help in FIFO design
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Mon, 11 Jun 2001 19:08:30 +0200
Links: << >>  << T >>  << A >>
Peter Alfke schrieb:
> 
> Of course, and you had to make sure that the red cut-out piece wordn't drop down
> somewhere elso...
> Later we checked larger circuits by crawling on the floor.

;-))

Ohh, I would give a kingdom to see a picture from this old days  . . .

-- 
MFG
Falk



Article: 32031
Subject: Re: Help in FIFO design
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Mon, 11 Jun 2001 19:09:37 +0200
Links: << >>  << T >>  << A >>
Peter Alfke schrieb:
> 
> Of course, and you had to make sure that the red cut-out piece wordn't drop down
> somewhere elso...
> Later we checked larger circuits by crawling on the floor.

Floorplanner V0.01 ;-))))))

SCNR.
-- 
MFG
Falk



Article: 32032
Subject: Re: On the prices of the FPGA and how to buy it
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Mon, 11 Jun 2001 19:21:31 +0200
Links: << >>  << T >>  << A >>
Kolja Sulimma schrieb:
> 
> Virtex is too expensive.
> You should buy Virtex-E or Spartan-II.

Do you know why Virtex is that expensive?? Virtex-E is better and
cheaper.
Is it a matter of production volume?

-- 
MFG
Falk


Article: 32033
Subject: Re: safe state machine design problem
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Mon, 11 Jun 2001 11:05:32 -0700
Links: << >>  << T >>  << A >>
Thomas Karlsson wrote:
 
> I have a state machine with 18 states. No matter what kind of state encoding

> I force the state vector flops into an illegal state for a moment (two flops
> set in a one-hot coded machine in this case)
> to simulate a disturbance, but then the next_state signal doesn't get the
> value for the state IDLE. (It gets a "five-hot" value!).

If you leave your encoding setting on AUTO,
Leo will choose a failsafe encoding for you.
Or you can design your own with explicit state values.
Some designers worry about illegal state recovery.
Some don't.
If you want it, it may cost you a gate or two.

       -Mike Treseler

Article: 32034
Subject: Re: On the prices of the FPGA and how to buy it
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Mon, 11 Jun 2001 11:57:33 -0700
Links: << >>  << T >>  << A >>


Falk Brunner wrote

>
> Do you know why Virtex is that expensive?? Virtex-E is better and
> cheaper.
> Is it a matter of production volume?

Virtex-E is a redesign to smaller geometries,  resulting in a smaller chip, but
on a different process ( that's why the 1.8 V instead of 2.5 V).
We pass on the savings...

Yes, Virtex-E is a better buy. The only concern might be the need for a 1.8 V
supply, and the lack of direct  5-V tolerance on the inputs  ( although there
are ways around that, with external resistors).

Peter Alfke


Article: 32035
Subject: Re: On the prices of the FPGA and how to buy it
From: Kolja Sulimma <kolja@sulimma.de>
Date: Mon, 11 Jun 2001 21:14:37 +0200
Links: << >>  << T >>  << A >>
FPGAs are quite large chips.
Chip area is therefore a relatively large cost factor.

In a modern process technology you get more gates on a wafer therefore
reducing the cost per gate.
Also, FPGAs have a lot of wiring. Using more metal layers further
reduces the chip size.

Virtex uses a 0,22um 5 layer metal technology.
Virtex-E uses a 0,18um 6 layer metal technology.
Virtex-II uses a 0,15um 8 layer metal technology.

If you look up old devices at www.nuhorizons.com you will find that the
cost per gate becomes very expensive for older parts. This is mainly due
to manufacturing costs.

Once our webserve is back online you can look up a comparison where the
FPGA price is plotted
against the gate count for various xilinx families.
http://www.em.informatik.uni-frankfurt.de/~prak/ss01/Woche1/sld033.htm
The feature size shown in the slide is the effective channel length and
therefore differs form the above numbers.

For a good laugh also look at the following slides.

Kolja Sulimma


Falk Brunner wrote:

> Kolja Sulimma schrieb:
> >
> > Virtex is too expensive.
> > You should buy Virtex-E or Spartan-II.
>
> Do you know why Virtex is that expensive?? Virtex-E is better and
> cheaper.
> Is it a matter of production volume?
>
> --
> MFG
> Falk


Article: 32036
Subject: Re: On the prices of the FPGA and how to buy it
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Mon, 11 Jun 2001 22:29:51 +0200
Links: << >>  << T >>  << A >>
Peter Alfke schrieb:
> 
> 
> Virtex-E is a redesign to smaller geometries,  resulting in a smaller chip, but
> on a different process ( that's why the 1.8 V instead of 2.5 V).
> We pass on the savings...

Nice.

> 
> Yes, Virtex-E is a better buy. The only concern might be the need for a 1.8 V
> supply, and the lack of direct  5-V tolerance on the inputs  ( although there
> are ways around that, with external resistors).

No problem in a 3.3V environment.

-- 
MFG
Falk

Article: 32037
Subject: Re: On the prices of the FPGA and how to buy it
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Mon, 11 Jun 2001 22:32:25 +0200
Links: << >>  << T >>  << A >>
Kolja Sulimma schrieb:
> 
> 
> For a good laugh also look at the following slides.

;-))))))))))))))))))

-- 
MFG
Falk

Article: 32038
Subject: Re: Pin locking in Maxplus2
From: eteam <eteam@aracnet.com>
Date: Mon, 11 Jun 2001 14:21:37 -0700
Links: << >>  << T >>  << A >>
What version SW are you using?  The currrent release, 10.0, is
pretty solid with Quartus fitter enabled or disabled.  Previous versions
did have a problem with the Quartus fitter (which could be disabled).

Version 10.0 has been around for about 6 months or more.

-- bob elkind, the e-team -- fpga design, consulting

Russell Shaw wrote:
> 
> Using the Quartus fitter in maxplus2 (for acex1k), it crashes at
> 28% when doing a simple 32x8 lpm fifo function and not much else
> (pc has 256MB ram). By setting the option not to use quartus, the
> compilation completes without error. Have you found the same bugginess?
> 
> bob elkind wrote:
> >
> > The Max7K family, in my experience, tends to be more finicky about
> > being filled to >80% utilisation with pinouts pre-defined.  The 6K and the
> > Acex 1K families (my current favourites) are much more forgiving in this
> > regard (and of course, they also have many more pins :=) ).
> >
> > You may wish to consider replacing your Max7Ks device with a
> > Flex6Ka (3.3V) or Acex1K (3.3V/2.5V) with an EPC2 (in-system
> > programmable config EEROM).  You probably won't be very far
> > removed in cost, and you will be light-years ahead in usable gates,
> > power consumption, AC performance, and pinot flexibility.
> >
> > -- Bob Elkind, the e-team (fpga/asic design, consulting, etc.)
> >
> 
> --
>    ___                                           ___
>   /  /\                                         /  /\
>  /  /__\                                       /  /\/\
> /__/   / Russell Shaw, B.Eng, M.Eng(Research) /__/\/\/
> \  \  /  Victoria, Australia, Down-Under      \  \/\/
>  \__\/                                         \__\/

Article: 32039
Subject: Re: one state machine
From: "Austin Franklin" <austin@dar09kroom.com>
Date: Mon, 11 Jun 2001 17:38:49 -0400
Links: << >>  << T >>  << A >>
> The difference here is that ViewDraw et al are proprietary whereas the 2
major
> HDLs are public standards.
> Hence if you stick to the defined synthesisable subset you know that all
the
> tools have to support your code.

The FPGA tools are proprietary too!  Also, I tell clients to archive the
tools with the project.

> One of the big uses of modern, large, FPGAs is for ASIC prototyping.

How big?  I don't believe it sells many FPGAs...and I don't believe it's
THAT big...  It certainly IS a use, but big...I'm skeptical...

> The second place where portability comes in is the entire IP arena.
>
> Portability takes some work but with effort its possible to reduce the
> technology changes to this list:
>
> o IO buffer selection.
> o Clock trees.
> o DP RAMs.
> o DLL/PLLs.
> o Choosing a cell for any clock domain synchronisers.
>
> I also notice that you haven't taken up the question re version control &
the
> ability to do a diff between revisions.

Because it has never ever been an issue with me, or any of my clients.  You
can version control the schematics, what's so hard about that?  I've never
had to diff between revisions...I can visually see what the differences are,
that is if the schematic is drawn correctly.   The reason you DO need "diff"
with text based is because it is so hard to find the differences!




Article: 32040
Subject: Doing Ethernet in a Virtex ?
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Mon, 11 Jun 2001 23:50:29 +0100
Links: << >>  << T >>  << A >>

I'm trying to work out whether its possible to do Ethernet in an FPGA.
Not just the MAC layer and then out on MII to an external PHY but
connect directly to the TP transformer. Does anybody know if any of the
Virtex2 differential IO standards would work either directly or with a
minimal amount of level shifting ?



Article: 32041
Subject: Gray Code Guard bits (was Re: Help in FIFO design)
From: husby_d@yahoo.com (Don Husby)
Date: 11 Jun 2001 16:06:49 -0700
Links: << >>  << T >>  << A >>
"iglam" <rluking@deletethispart.home.com> wrote:
> In general, I agree.  Grey code address counters and a comparitor in
> one clock domain.  One trick I like to do is use an extra address bit.
> If you have a 16 word fifo, use a 5 bit address counter.

Bzzzzzt. This won't work.

Consider a 4-word fifo using a 3-bit gray-code counter.  The
count sequence is:
   000
   001
   011
   010
   110
   111
   101
   100

The low 2 bits follow a different sequence between the first
4 counts and the second 4 counts.  Your data would get scrambled.

To do this correctly, you'd have to implement your counters as
a binary counters, and then translate them to gray code to cross
the clock boundary, and then translate them back to binary to do
the arithmetic.

Article: 32042
Subject: Re: Doing Ethernet in a Virtex ?
From: "Jeffrey Vallier" <jvallier@gibson.com>
Date: Mon, 11 Jun 2001 17:11:35 -0700
Links: << >>  << T >>  << A >>

"Rick Filipkiewicz" <rick@algor.co.uk> wrote in message
news:3B254B35.D80BFD4F@algor.co.uk...
>
> I'm trying to work out whether its possible to do Ethernet in an FPGA.
> Not just the MAC layer and then out on MII to an external PHY but
> connect directly to the TP transformer. Does anybody know if any of the
> Virtex2 differential IO standards would work either directly or with a
> minimal amount of level shifting ?
>

Nope. We researched this pretty throughly and from our perspective there's
too much mixed signal crap involved to make it worthwhile. Good idea though
:)  Don't despair, 'cause I have heard rumors of Phy-in-an-FPGA floating
around. I think this is a solution that many designers wish for--we just
have to wait for a "big" customer to want it enough to cough up the
development costs and then have it filter down the product channels as a
standard part for the rest of us.

good luck,

Jeff

--
***********************************************
Jeffrey Vallier            Sr. FW Engineer
Gibson Guitar Corp.  GMICS Division
1283 F Old Mtn View/Alviso Rd.
Sunnyvale, CA 94089 408 734 4394
***********************************************



Article: 32043
Subject: Re: Xilinx webpack annoyances (long and whiny)
From: "Andy Peters <andy [@] exponentmedia" <".> com">
Date: Tue, 12 Jun 2001 00:59:21 GMT
Links: << >>  << T >>  << A >>
Jeffrey Vallier wrote:
> 
> (snip)
> 
> >
> > Xilinx: are you listening?
> >
> > --andy
> >
> 
> Welcome to the world of Xilinx :) In an unusual defensive stance for Xilinx,
> I should let you know I met with the team leader for the Webpack project a
> few weeks ago to discuss my _long_ list of gripes with the tool. They were
> sincerely interested in listening to customer comments, so we should see
> some improvements down the road...

Ahhh, I've been living the Xilinx world for quite some time.  I'm still
sorta annoyed that the nifty tristate registers in the XC4KX/XL/XLA
parts are never going to be supported without a hack, but the newere
chips are cheaper.

Actually, I'm trying to figure out where Xilinx positions Webpack.  I
mean, it doesn't support a lot of the chips, but the tools (other than
the goofy project manager) seem to be the same as the mainstream F3.3i stuff.
 
> Jeffrey Vallier            Sr. FW Engineer
> Gibson Guitar Corp.  GMICS Division

Gibson, huh? Mebbe you could explain to me why my new (in 1996, when I
bought it, anyways) Gibson Les Paul Special needed a fret dress...

-andy

Article: 32044
Subject: Re: Xilinx webpack annoyances (long and whiny)
From: "Andy Peters <andy [@] exponentmedia" <".> com">
Date: Tue, 12 Jun 2001 01:00:30 GMT
Links: << >>  << T >>  << A >>
Ian,

I think the documentation should've come right out and said: "We don't
support VHDL'93."

A good question would be: "Why the hell not?"  I mean, even Synopsys
supports some of VHDL'93...

Ian Young wrote:
> 
> "Andy Peters" <andy(@)exponentmedia(.)com> wrote:
> 
> >Hmmm..Ashenden sez this is OK; so does ModelSim.
> 
> I'm also a Xilinx WebPACK user.  I also have a copy of that book.
> 
> Ashenden says this is OK in _VHDL-93_, which ModelSim also supports.
> 
> >So, what's wrong?  Does XST support generates?
> 
> The problem is that, as far as I can tell, XST only understands
> _VHDL-87_.
> 
> Turning to p.645 of your copy of Ashenden, note that some syntax is
> underlined.  Anything underlined is VHDL-93 only, and I haven't found
> any of it usable under XST.
> 
> [Not quite true, you can bind ports to literal values in XST, but I
> think that is strictly a VHDL-93 extension.]
> 
> >But the example in the docs does NOT have the BEGIN, and the synth
> >is happy if I remove it from my code.  But I'm not happy, since I
> >have to modify my code to satisfy the quirks of a non-compliant tool.
> 
> It annoys me too, but you can't really say it is a non-compliant tool
> just because it isn't compliant with the most recent version of the
> language.  Archaic, yes, but not non-compliant.
> 
> >OK, so the tools are FREE.  What should I expect?
> 
> Curiously, I understand that Xilinx also sell the XST stuff
> (certainly, a synthesis bug in the WebPACK XST I found was apparently
> also present in the pay-for package).  Now, 1993 is quite a long time
> ago and I'm pretty surprised that XST apparently doesn't include most
> of the later extensions.  However, if you take this limitation into
> account and re-read Ashenden with that in mind (in other words, ignore
> the huge tracts of useful stuff it turns out you can't actually use)
> then things fall into place fairly well.
> 
> Actually, if you're using Ashenden as a reference I'm surprised you
> didn't hit the lack of direct instantiation in VHDL-87 and XST first,
> as he spends eight pages (136--144) on how that's the obvious way to
> do things before finally saying you can't do it at all in VHDL-87...
> 
> >Xilinx: are you listening?
> 
> I'd certainly be interested to know if they plan to do something about
> this, but given the size of the differences between VHDL-87 and -93, I
> don't imagine it will happen at all soon.
> 
>         -- Ian

Article: 32045
Subject: Re: Xilinx PCI core location constraints
From: Matthieu Cossoul <Matt.Cossoul@xilinx.com>
Date: Mon, 11 Jun 2001 19:14:05 -0700
Links: << >>  << T >>  << A >>
Jamie,

That's a feature and a bug:
. the feature: the TBUF placement algorithm is assuming that the datapath (ADs
and CBEs) is surrounding RDY signals, which makes some sense timing wise.
. the bug: the test that was supposed to enforce this didn't report an error as
it was supposed to.

Gathering all PCI signals on a single bank is freeing up a bank where a
different IO standard could be used. The new version of the UCF Generator to be
released this Friday would now allow you to do that. Meanwhile, I could
generate for you the UCF you need.

Sorry for the inconvenience,
- Matt

Jamie Sanderson wrote:

> Hi all;
>
> I am working on the initial floor plan of a design using the Xilinx PCI
> core. Using their constraints generator, I have requested that the PCI pins
> be on the slot side of the device. This causes them to be spread evenly
> across the end of I/O bank 2 and beginning of bank 3. I would like to shift
> the core and its I/O such that it resides within a single quadrant of a
> device. I've been experimenting with their UCF generator, but am having a
> problem. In the device I'm using, the IRDY and TRDY pins are the first two
> pins in the 3rd bank. In the UCF generator, I have re-ordered the signals
> such that the RDY lines are first, with all others following them.
>
> This has nearly the desired effect. All of the pins are now in the third
> bank. However, the internal location constraints do not make sense to me.
> While most are shifted downwards in the Y plane, the address/data TBUFs are
> shifted up. In other words, while the pins and everything else move down
> into the South-East quadrant, the AD TBUFs have moved further into the
> North-East quadrant.
>
> Does anyone know why this is? Is it a bug in their UCF generator, or due to
> some peculiarity of what I'm trying to do?
>
> Thanks in advance,
> Jamie


Article: 32046
Subject: Re: XC4005XL is it a modern chip?
From: Simon Gornall <simon@unique-id.com>
Date: Mon, 11 Jun 2001 22:18:51 -0400
Links: << >>  << T >>  << A >>
Robin Kinge wrote:
> 
> > Shameless plug ;-)
> 
> Sounds like a good start though. Anyone in the UK give us a clue if this available here?
> 
> Robin

I got one a while ago, before the new 'select-any-frequency-you-like' module
was part of it :-(

Apart from a rather zealous customs inspection, it arrived fine - Customs managed
to put about 6 tons of yellow 'This has been inspected' tape all over the
packaging, inside and out ... God alone know what they thought it was:-)

I've got Webpack, (it comes on a CD with the kit, although I'd already
downloaded it - ADSL is great :-)) and it works pretty well, although
I'm told it's not as good as the stuff you pay for (FPGA editor ?) I
think it's good enough for my (hobby-like) purposes though...

Frankly, I think it's worth a shameless plug :-) No I'm not in any way
associated, yada yada yada...

Simon.

-- 
Freedom ? What's that ? (see http://www.domesday.co.uk/ )

Article: 32047
Subject: Re: Gray Code Guard bits (was Re: Help in FIFO design)
From: John_H <johnhandwork@mail.com>
Date: Tue, 12 Jun 2001 02:43:50 GMT
Links: << >>  << T >>  << A >>
Don,
I'm disappointed you didn't give iglam the benefit of the doubt in his short
response.

Converting both ways between binary and Gray and using 4 bit comparators is
more resource intensive than the Gray counter's msb inversion of the lsbs of
the address and the comparator xor.  No data scramble.

Of course using the lsbs unmodified would scramble your data.  Iglam
incorrectly mentioned the msb was ignored but I don't see that as reason to
dismiss the idea out of hand.



Don Husby wrote:

> Bzzzzzt. This won't work.


Article: 32048
Subject: Re: Gray Code Guard bits (was Re: Help in FIFO design)
From: John_H <johnhandwork@mail.com>
Date: Tue, 12 Jun 2001 02:51:56 GMT
Links: << >>  << T >>  << A >>
Don,

I'm disappointed you didn't give iglam the benefit of the doubt in his short

response.

Look at your example of why the count sequence "won't work" and take an xor
of the two msbits instead of ignoring the msbit.  Suddenly there's no data
scramble.

Converting both ways between binary and Gray and using 4 bit comparators is
more resource intensive than the xor of the Gray counter's two msbits and
the
comparator xor.

Of course using all the lsbs unmodified would scramble your data.  Iglam
incorrectly mentioned the msb was ignored but I don't see that as reason to
dismiss the idea out of hand.

Gray is powerful, but you can't ignore the fact that it's different from
what we're "used to."




> Bzzzzzt. This won't work.
>
> Consider a 4-word fifo using a 3-bit gray-code counter.  The
> count sequence is:
>    000
>    001
>    011
>    010
>    110
>    111
>    101
>    100


Article: 32049
(removed)




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