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 28375

Article: 28375
Subject: Re: grey code counters
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Wed, 10 Jan 2001 12:58:34 -0800
Links: << >>  << T >>  << A >>


Eric Smith wrote:

> "If you're using Gray counters because you have counters in two clock
> domains (e.g., for a FIFO), doesn't implmenting them as binary counters
> with converters defeat the purpose?  With that implementation you can
> have glitches where multiple bits change simultaneously.

Only if you do a combinatorial (XOR) decode of the binary.
No problem if you re-register the Gray, and also no problem if you derive the
input to the Gray registers from the binary Ds.

Peter Alfke



Article: 28376
Subject: Simulation File
From: sharifs@psu.edu
Date: Wed, 10 Jan 2001 22:19:16 GMT
Links: << >>  << T >>  << A >>
Hi,

This is probably a basic question. I am using cadence tool for designing
FPGA. Everything there is compiled as verilog. I need
to run the simulation to test the design. Cadence supports "singnalscan"
to view the waveforms... But I dont understand where I
should put the timing values for different signals from cadence. When I
run the simulation I can see only flat waveforms. Looks
like it needs a simulation file with *.trn extension.... Can anyone
enlighten me on that... Like How I can write a simulation file
OR how  I can specify the waveforms of different input signals to see
the response!!?

Thanks
Sharif


Sent via Deja.com
http://www.deja.com/

Article: 28377
Subject: Xilinx XPERT Partner seeking Senior FPGA/ASIC & HDL Engineers
From: "ed.mccauley" <ed.mccauley@bltinc.com>
Date: Wed, 10 Jan 2001 17:33:31 -0500
Links: << >>  << T >>  << A >>
Bottom Line Technologies Inc., designing with Xilinx since 1986 and one of
Xilinx's first XPERT partners, is hiring senior engineers with experience in
FPGA and/or ASIC design and Verilog and/or VHDL expertise.

See our web site www.bltinc.com and select EMPLOYMENT or call us at
908-713-6100 for further information.




Article: 28378
Subject: Re: grey code counters
From: "Kevin Neilson" <kmneilson@earthlink.net>
Date: Wed, 10 Jan 2001 23:49:30 GMT
Links: << >>  << T >>  << A >>
You are right that the design wouldn't work if you just read the
unregistered XOR outputs in another domain.  The second set of flops are
required.  That is, you clock the conventional counter and the Gray pipeline
registers on clock A,  and then you can read the Gray registers from domain
B safely.  The XOR outputs can glitch so they need to be registered.


Eric Smith wrote in message ...
>"Kevin Neilson" <kmneilson@earthlink.net> writes:
>> Making a Gray counter is surprisingly simple.  I have some code, which I
>> can't  give out, but it is basically just a conventional counter and some
>> XORs.  Say you have an N-bit counter, CNT, and want an N-bit Gray
counter.
>> Gray[0] is (CNT[1] ^ CNT[0]), Gray[1] is (CNT[2] ^CNT[1]), ... Gray[N-2]
=
>> (CNT[N-1] ^ CNT[N-2]), and finally, the last bit, Gray[N-1] = CNT[N-1].
>> "Gray" can just be the output of the flipflops, or you can pipeline the
>> output for extra speed.  In that case the Gray counter would run at
whatever
>> speed the convential counter ran.
>
>If you're using Gray counters because you have counters in two clock
>domains (e.g., for a FIFO), doesn't implmenting them as binary counters
>with converters defeat the purpose?  With that implementation you can
>have glitches where multiple bits change simultaneously.
>



Article: 28379
Subject: Re: Alliance for Linux
From: Simon Gornall <simon@unique-id.com>
Date: Wed, 10 Jan 2001 23:57:30 +0000
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> 
> 
> I have forwarded these request to the appropriate party (and also to the
> highest level) within Xilinx. I will let them come up with the right
> response.
> We are aware of the problem and the opportunity.
> 
> Peter Alfke, Xilinx Applications

Is there any benefit in a larger number of requests ? If so, count me :-)

Simon.

-- 
Physicists get hadrons!

Article: 28380
Subject: Re: Xilinx Spartan II - PQ208 Orcad symbols
From: eteam <eteam@aracnet.com>
Date: Wed, 10 Jan 2001 17:00:17 -0800
Links: << >>  << T >>  << A >>
Orcad capture v9.2 (and possibly even 9.1) has a Xilinx "import"
facility to do most of the tedious work of building symbols.

The command is under the TOOLS/GENERATE PART menu, and accepts
either a Xilinx PIN file or a .XNF netlist.

-- Bob Elkind, eteam@aracnet.com

Gil Golov wrote:
> 
> Does anybody have a symbol library for Xilinx chips for Orcad capture.
> I'm specially looking for the PQ208 package for the Spartan II
> and VX44 package for the 18Vxx ISP Prom
> 
> Many thanks for your help
> 
> Gil Golov.

Article: 28381
Subject: Re: Alliance for Linux
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Wed, 10 Jan 2001 17:20:14 -0800
Links: << >>  << T >>  << A >>
See the response by Dennis McCrohan.
He is not the official Xilinx spokesman, neither am I, but he brought up some
valid points. Quality assurance and support can be an enormous burden, that
must be weighed against the potential total benefit, i.e. additional chip
sales.

Peter Alfke
==========================
Simon Gornall wrote:

> Peter Alfke wrote:
> >
> >
> > I have forwarded these request to the appropriate party (and also to the
> > highest level) within Xilinx. I will let them come up with the right
> > response.
> > We are aware of the problem and the opportunity.
> >
> > Peter Alfke, Xilinx Applications
>
> Is there any benefit in a larger number of requests ? If so, count me :-)
>
> Simon.
>
> --
> Physicists get hadrons!


Article: 28382
Subject: Re: Alliance for Linux
From: murray@pa.dec.com (Hal Murray)
Date: 11 Jan 2001 03:01:01 GMT
Links: << >>  << T >>  << A >>

> patches.... If I build our tools on my box, how do I warranty that they will
> run (correctly) on any other Linux machine in the world? In the Windows
> world, we have SP's from MS that we can specify on our product requirements
> and build and test against (oh yeah, we also have to test against many
> localized versions of Windows). A lot of combinations, but at least finite.

I don't know much about the Windows world, but I've heard enough
stories about things breaking because some add-on software installed
something that broke something else ....

The major Linux distributions come on CDs with version numbers.  I don't
see why that isn't as well specified as an SP from MS.  All you have
to do is pick a few to support.

In case anybody is wondering, I'm also interested in having tools that
run on Linux.

-- 
These are my opinions, not necessarily my employers.  I hate spam.

Article: 28383
Subject: Re: Alliance for Linux
From: Duane <junkmail@junkmail.com>
Date: Wed, 10 Jan 2001 20:08:28 -0800
Links: << >>  << T >>  << A >>
Dennis McCrohan wrote:
> 
> I probably shouldn't, but I can't resist commenting on this thread...
> 
> Let's preface this by saying that the following in no way, shape, or form
> expresses the opinion of Xilinx, Inc.
> 
> Linux presents some real challenges from a s/w business point-of-view (as
> opposed to looking at it as a programmer's toy). Think of it from the
> perspective of a software quality assurance manager, or support manager. The
> reality of Linux is that there are no two Linux installations alike. I have
> Linux on one of my machines, originally RH 6.0. But now I can claim no
> version for it, since I've rebuilt the kernel several times with various
> patches.... If I build our tools on my box, how do I warranty that they will
> run (correctly) on any other Linux machine in the world? In the Windows
> world, we have SP's from MS that we can specify on our product requirements
> and build and test against (oh yeah, we also have to test against many
> localized versions of Windows). A lot of combinations, but at least finite.

To quote Josh Rosen:
> The issue of
> which distribution to support is also easy, it's Redhat. Redhat is the
> defacto standard, it's what Synopsys and Cadence support so that's what
> Xilinx should support also.

And I completely agree. Support stock Redhat, everyone else is on their
own. 

> So supporting any new OS, even one that doesn't come in infinite
> permutations like Linux, involves very significant $$$. I, as a developer,
> see almost none of those costs, they are born primarily by the folks who
> supply our development tools/platforms, test, support, and documentation
> people. For all of this, we would see very little incremental revenue (how
> much do we charge for our tools?). Not surprisingly, I suspect that most of
> my fellow developers would like to support Linux, and most of the rest of
> the company would like to have our heads for even muttering the word.
> 
> FYI, I am a s/w developer for Xilinx, working primarily on the
> Webpack/Webfitter stuff. In previous lives I was a ASIC/board designer. I've
> also done web programming, network admin, etc. on several Linux systems.

I would at least like to see the basic command line tools ported to
Linux (since I currently run them under Linux/Wine anyway). As Georg
Acher mentioned, they are unlikely to require any changes at all to work
in Linux. And because of that they are unlikely to require any more
support than they currently require on any other platform. Though I
realize that a partial Linux release may be an even harder sell to the
managers.

--
My real email is akamail.com@dclark (or something like that).

Article: 28384
Subject: Re: grey code counters
From: "Kevin Neilson" <kmneilson@earthlink.net>
Date: Thu, 11 Jan 2001 05:10:35 GMT
Links: << >>  << T >>  << A >>
Using the D-inputs would probably be a bit slower, since the combinational
path would include the adder logic in addition to the XORs.


Peter Alfke wrote in message <3A5CB7A4.EC07468@xilinx.com>...
>XAPP131 is just a straightforward binary-to-gray converter, as described in
>the 1972 Fairchild applications handbook ( by yours truly).
>The trick of using the XOR of the binary D-inputs is smarter, if I may say
>so.
>Same brain, just 29 years additional experience.  :-)
>Peter Alfke
>======================================




Article: 28385
Subject: Re: grey code counters
From: Peter Alfke <palfke@earthlink.net>
Date: Thu, 11 Jan 2001 05:32:57 GMT
Links: << >>  << T >>  << A >>
Interesting, but hard to understand.
And in my case, there was no need to make the counter faster than the FIFO data
storage in BlockRAM, which limits the cycle time to about 4 ns ( 200 MHz was my
usual conservatism, I could have said 250 MHZ, but that would be bragging  :-)
I would also feel a bit queasy using 256 shifting bits to implement what is
really a 12-bit counter. What if one bit ever goes wrong? It will never
straighten itself out. Maybe this is heresy in a digital world, but the
reliability of a fast-clocked shift register bit may perhaps not be as good as
that of a static configuration bit. I always feel uneasy when there are lots of
redundant flip-flops sloshing around.
Call me chicken...
Peter Alfke

Kevin Neilson wrote:

> SRL Johson Rings:
>
> Provided one is using a Virtex architecture, a smaller and faster
> implementation would be to use the SRL (shift-register LUTs) as 16-bit
> Johnson rings.  A 4-bit Gray counter would use only 4 LUTs and no CLB flops.
> You just configure the LSB SRL as a 16-bit Johnson ring with the initial
> pattern 01100110_01100110, the next bit as an SRL loaded with
> 00111100_00111100, and so on.  After 4 bits, it gets a little harder.  To do
> an 8-bit counter, you would need 10 SRLs (10 LUTs).  Bit 3 would need 2
> SRLs, since it repeats after 32 ticks.  Then you would need a "terminal
> count" SRL which is a Johnson ring with one '1' so the output goes hi every
> 16th cycle.  This would be used at the clock enable to another 4-SRL Johnson
> Ring Gray counter.  You could keep stringing them together like this.  A
> 12-bit counter would have 3 quad-Johnson-rings and the third would have a
> clock enable of the AND of the terminal counts of the lower 2.  So that's
> about 16 LUTs for a 12-bit Gray counter.  Which is better than the 24 flops
> and 24 luts you would normally need.  Of course this only works for Virtex
> and Spartan-II.  But this would be the fastest and smallest implementation
> for that family.  It only counts forward, though, and can't be reset, which
> is a big drawback.
>
> -Kevin
>
> Peter Alfke wrote in message <3A5C99C5.6B1A0CBC@xilinx.com>...
> >I recently had reason to investigate this for the design of an asynchronous
> >BlockRAM-based FIFO in Virtex and Virtex-II. ( BTW: I got it to run at 200
> >MHz, with proper FULL and EMPTY handshake, while running with with two
> >independent unrelated clocks)
> >Here are my notes:
> >
> >Grey-Coded Addresses
> >Only one bit/address changes at any time
> >Therefore no glitches from the identity comparator
> >
> >Implementation:
> >Build binary counter
> >Generate XOR of two adjacent D-inputs
> >(that is the trick ! Don't use the binary Q, use the binary D)
> >Feed these XORs to a register = Grey !
> >MSB binary = MSB Grey
> >Advantage: very fast and easily epandable.
> >
> >Please excuse the terse (PowerPoint) notation.
> >Yes, it wastes flip-flops. But I think it is still the most compact
> >(cheapest) solution in Virtex, where one CLB implements two bits, since it
> >has 4 flip-flops.
> >I tried various other ways, and -while they did not waste flip-flops- they
> >were no cheaper.
> >BTW: You can of course use the simultaneous binary output "for free".
> >You can also run the counter in both directions "for free".
> >I will gladly accept a more compact solution.
> >
> >Peter Alfke, Xilinx Applications
> >
> >
> >Bill Lenihan wrote:
> >
> >> I know how to make binary up/down counters and LFSR-based counters in
> >> verilog, but does anyone know of an algorithmic/equation-based way to
> >> make grey-code counters?
> >>
> >> The only examples I've seen are from old PAL application notes, and they
> >> are for 4-bit grey counters that are described as 16-state state
> >> machines, which is ok if you are keeping the counter at 4-bits, but
> >> impractical if you are going to much wider bit widths.
> >>
> >> --
> >> ==============================
> >> William Lenihan
> >> lenihan3weNOSPAM@earthlink.net
> >> .... remove "NOSPAM" when replying
> >> ==============================
> >
> >


Article: 28386
Subject: Need some help on beginning
From: Ed Ngai <engai@sprintmail.com>
Date: Thu, 11 Jan 2001 05:35:14 GMT
Links: << >>  << T >>  << A >>
Hi All,  I want to make a switching IC, decimal to binary idea.
I've made a PAL before using Palasm. Made the 16V8/16L8 PLDs
and it works.  Now I need to expand the small PLD.

1. what do I do next?
2. I have my Palasm code below ;
;PALASM Design Description

;---------------------------- Declaration Segment ------------
TITLE    VGAL-3 for GAL16V8 using PALCE16V8
PATTERN  A
REVISION 1.0
AUTHOR   Ed Ngai
COMPANY  tbd
DATE     7/26/00

;The design file has extension *.PDS
CHIP  DECBIN MUX  PAL16V8

;---------------------------- PIN Declarations ---------------
;ASSIGNED pin numbers to match I/O.
;Address and LEDs.
PIN  2          SW1        COMBINATORIAL             ; INPUT
PIN  3          SW2        COMBINATORIAL             ; INPUT
PIN  4          SW3        COMBINATORIAL             ; INPUT 
PIN  5          SW4        COMBINATORIAL             ; INPUT 
PIN  10         GND                                  ; INPUT
PIN  12         L1         COMBINATORIAL             ; OUTPUT
PIN  13         L2         COMBINATORIAL             ; OUTPUT
PIN  14         L3         COMBINATORIAL             ; OUTPUT
PIN  15         L4         COMBINATORIAL             ; OUTPUT
PIN  16         A3         COMBINATORIAL             ; OUTPUT
PIN  17         A2         COMBINATORIAL             ; OUTPUT
PIN  18         A1         COMBINATORIAL             ; OUTPUT
PIN  19         A0         COMBINATORIAL             ; OUTPUT
PIN  20         VCC                                  ; INPUT

;---------------------------- Boolean Equation Segment ------
EQUATIONS

A0 = /SW2 + /SW4 + A0 * /(/SW1 + /SW3)
A1 = /SW3 + /SW4 + A1 * /(/SW1 + /SW2)
A2 = /SW2 + /SW4 + A0 * /(/SW1 + /SW3)
A3 = /SW3 + /SW4 + A1 * /(/SW1 + /SW2)
L1 = /(A1 + A0)
L2 = /(A1 + /A0)
L3 = /(/A1 + A0)
L4 = /(/A1 + /A0)

;---------------------------- Simulation Segment ------------
SIMULATION
; 1. Try asserting each of the switches once
; 2. Negate all switches
; 3. Check that the outputs are holding the correct address
TRACE_ON SW1 SW2 SW3 SW4 A0 A1 A2 A3 L1 L2 L3 L4
SETF  /SW1 SW2 SW3 SW4
SETF   SW1 SW2 SW3 SW4
CHECK  /A0 /A1 /A2 /A3 L1 /L2 /L3 /L4
SETF   SW1 /SW2 SW3 SW4
SETF   SW1 SW2 SW3 SW4
CHECK  A0 /A1 A2 /A3 /L1 L2 /L3 /L4
SETF   SW1 SW2 /SW3 SW4
SETF   SW1 SW2 SW3 SW4
CHECK  /A0 A1 /A2 A3 /L1 /L2 L3 /L4
SETF   SW1 SW2 SW3 /SW4
SETF   SW1 SW2 SW3 SW4
CHECK  A0 A1 A2 A3 /L1 /L2 /L3 L4
TRACE_OFF
;-------------------------------------------------------------------

3. I'd like to use Xilinx , but now what ?

If I was to do this w/ a PLD,
1. I get my PDS , design code right.
2. I get a PLD programmer
3. I burn the PLD
4. I test it on a breadboard

What are the steps to make a FPGA?
FPGA's are like $20.00 from Digi-key, ok I can buy that.
Xilinx ISE Foundation I can d/l.
I have to solder some small QFP, I can do SMD, 0.050" to
wire-wrap
wire is not bad.

Can some fill in the steps ?
thanks
Ed

Article: 28387
Subject: Re: grey code counters
From: "John L. Smith" <jsmith@visicom.com>
Date: Wed, 10 Jan 2001 21:49:17 -0800
Links: << >>  << T >>  << A >>
Here is some direct logic for a 4 bit Gray code counter:

G0 <- !( G3 @ G2 @ G1 )
G1 <- G0 !( G3 @ G2 ) + !G0 G1
G2 <- !G3 G1 !G0 + G2 ( !G3 + !G1 + G0 )
G3 <- G2 !G1 !G0 + G3 ( G2 + G1 + G0 )

( + = or, @ = xor, ! = not, and is implied) 

Generally, the reflected code is logic intensive,
because _every_ bit depends _every_ other bit
(except G0 does not depend on itself!)

Here's the reverse conversion as well:

                G(N) = B(N)
G[n] = B[n] @ B[n+1]   B[n] = G[N] @ G[N-1] @ G[N-2] ... @ G[n]
(N = MS bit, n = any smaller bit)

Kevin Neilson wrote:
> 
> You are right that the design wouldn't work if you just read the
> unregistered XOR outputs in another domain.  The second set of flops are
> required.  That is, you clock the conventional counter and the Gray pipeline
> registers on clock A,  and then you can read the Gray registers from domain
> B safely.  The XOR outputs can glitch so they need to be registered.
> 
> Eric Smith wrote in message ...
> >If you're using Gray counters because you have counters in two clock
> >domains (e.g., for a FIFO), doesn't implmenting them as binary counters
> >with converters defeat the purpose?  With that implementation you can
> >have glitches where multiple bits change simultaneously.
> >

Article: 28388
Subject: Re: Alliance for Linux
From: bjrosen <bjrosen@polybus.com>
Date: Thu, 11 Jan 2001 06:16:09 GMT
Links: << >>  << T >>  << A >>
Supporting Linux would be an order of magnitude cheaper than supporting
Windows. Things like kernal versions don't matter to programs like the
Xilinx tools. I've just installed the 2.4 kernel on one of my machines
and it didn't break anything and going from a 2.2x kernel to 2.4 is as
big a step as you can make. The important thing is that Linux is stable,
whereas Windows isn't. Windows systems suffer from DLL hell, there is no
equivalent on Linux. When you install a new program on Linux you never
have to worry that it will stomp on some other program. On Windows you
have a 50/50 chance of mangling your system every time you install
something. Even when you're not adding new software to a Windows system,
it's quietly corrupting itself. Linux doesn't do that, if you want to
break a Linux system you have to work at it, it doesn't break itself. As
a result you never see strange behavior on Linux systems like you do on
Windows.

The other advantage of Linux/Unix is that you can keep multiple revs of
the software on a system. I have 2.2i, 3.1i, 3.2i and 3.3i on my Linux
systems, try doing that with Windows. If there is a problem with a new
rev all I have to do change a symbolic link and I'm back to the old rev.
This is not just a theoretical advantage, in my earlier post I said that
there was a problem with 3.3i under WINE. It turns out that it wasn't a
WINE problem, it was a problem with the NT version of map, the Unix
version works fine. Xilinx has a fix that they are including in SP7.
Because I'm using Linux I was able to go back to 3.2i with a simple link
change. If I had been using NT I would have been forced to do a complete
reinstall.


In article <3A5CC4BE.D0CE4EF9@xilinx.com>,
  Dennis McCrohan <mccrohan@xilinx.com> wrote:
> I probably shouldn't, but I can't resist commenting on this thread...
>
> Let's preface this by saying that the following in no way, shape, or
form
> expresses the opinion of Xilinx, Inc.
>
> Linux presents some real challenges from a s/w business point-of-view
(as
> opposed to looking at it as a programmer's toy). Think of it from the
> perspective of a software quality assurance manager, or support
manager. The
> reality of Linux is that there are no two Linux installations alike. I
have
> Linux on one of my machines, originally RH 6.0. But now I can claim no
> version for it, since I've rebuilt the kernel several times with
various
> patches.... If I build our tools on my box, how do I warranty that
they will
> run (correctly) on any other Linux machine in the world? In the
Windows
> world, we have SP's from MS that we can specify on our product
requirements
> and build and test against (oh yeah, we also have to test against many
> localized versions of Windows). A lot of combinations, but at least
finite.
>
> So supporting any new OS, even one that doesn't come in infinite
> permutations like Linux, involves very significant $$$. I, as a
developer,
> see almost none of those costs, they are born primarily by the folks
who
> supply our development tools/platforms, test, support, and
documentation
> people. For all of this, we would see very little incremental revenue
(how
> much do we charge for our tools?). Not surprisingly, I suspect that
most of
> my fellow developers would like to support Linux, and most of the rest
of
> the company would like to have our heads for even muttering the word.
>
> FYI, I am a s/w developer for Xilinx, working primarily on the
> Webpack/Webfitter stuff. In previous lives I was a ASIC/board
designer. I've
> also done web programming, network admin, etc. on several Linux
systems.
>
> -dm
>
>


Sent via Deja.com
http://www.deja.com/

Article: 28389
Subject: Re: grey code counters
From: "Jaan Sirp" <jaan.sirp@liewenthal.ee>
Date: Thu, 11 Jan 2001 00:17:20 -0800
Links: << >>  << T >>  << A >>
Here is my algorithm:
<BR>For big counters replace function in parentheses with fast carry chain (at least Xilinx FPGAs have such components). For small counters parentheses are excessives. 

QZ = ~QZ;
<BR>Q[0] = QZ ^ Q0;
<BR>Q[1] = (~QZ) & Q0 ^ Q1;
<BR>Q[2] = (~QZ & ~Q0) & Q1 ^ Q2;
<BR>Q[3] = (~QZ & ~Q0 & ~Q1) & Q2 ^ Q3;
<BR>...
<BR>Q[N-1] = (~QZ & ~Q0 & ~Q1 &..& ~Q[N-3]) & Q[N-2] ^ Q[N-1];
<BR>Q[N] = (~QZ & ~Q0 &..& ~Q[N-2]) ^ Q[N];

^ is XOR.

Jaan Sirp.

<I have made grey-code counter, it has N + 1 T-type FFs, where N is number of output bits. I <have used ALDEC schematics capture, but converting it to Verilog is very simple. Let me <know, if you are interested.

Article: 28390
Subject: Re: grey code counters
From: "Jaan Sirp" <jaan.sirp@mail.ee>
Date: Thu, 11 Jan 2001 01:19:56 -0800
Links: << >>  << T >>  << A >>
I FORGOT A LITTLE, BUT IMPORTANT REMARK:
<BR>When resetting the counter, QZ must be set to logic one.

< Here is my algorithm:
<BR>< For big counters replace function in parentheses with fast carry chain
<BR>< (at least Xilinx FPGAs have such components).
<BR>< For small counters parentheses are excessives. 
<BR><
<BR>< QZ = ~QZ;
<BR>< Q[0] = QZ ^ Q0;
<BR>< Q[1] = (~QZ) & Q0 ^ Q1;
<BR>< Q[2] = (~QZ & ~Q0) & Q1 ^ Q2;
<BR>< Q[3] = (~QZ & ~Q0 & ~Q1) & Q2 ^ Q3;
<BR>< ...
<BR>< Q[N-1] = (~QZ & ~Q0 & ~Q1 &..& ~Q[N-3]) & Q[N-2] ^ Q[N-1];
<BR>< Q[N] = (~QZ & ~Q0 &..& ~Q[N-2]) ^ Q[N];
<BR><
<BR>< ^ is XOR,
<BR>< ~ is inversion.
<BR><
<BR>< Jaan Sirp.

Article: 28391
Subject: Re: grey code counters
From: Petter Gustad <spam@gustad.com>
Date: 11 Jan 2001 10:42:53 +0100
Links: << >>  << T >>  << A >>
Bill Lenihan <lenihan3weNOSPAM@earthlink.net> writes:

> I know how to make binary up/down counters and LFSR-based counters in
> verilog, but does anyone know of an algorithmic/equation-based way to
> make grey-code counters?
> 
> The only examples I've seen are from old PAL application notes, and they
> are for 4-bit grey counters that are described as 16-state state
> machines, which is ok if you are keeping the counter at 4-bits, but
> impractical if you are going to much wider bit widths.

I've done this the brute force way - 6-7 years ago I wrote a program
to generate the verilog case statements for grey code counters (or
Johnson counters). I've uploaded the program at

ftp://ftp.gustad.com/pub/eda/jc.tgz

./jct 4 will generate the following table:

case 10'b0000: ns = 10'b0001;
case 10'b0001: ns = 10'b0011;
case 10'b0011: ns = 10'b0010;
case 10'b0010: ns = 10'b0110;
case 10'b0110: ns = 10'b0111;
case 10'b0111: ns = 10'b0101;
case 10'b0101: ns = 10'b0100;
case 10'b0100: ns = 10'b1100;
case 10'b1100: ns = 10'b1101;
case 10'b1101: ns = 10'b1111;
case 10'b1111: ns = 10'b1110;
case 10'b1110: ns = 10'b1010;
case 10'b1010: ns = 10'b1011;
case 10'b1011: ns = 10'b1001;
case 10'b1001: ns = 10'b1000;
case 10'b1000: ns = 10'b0000;

You'll have to update the bit size manually before you include it in
your code. The jc program will find all possible sequences which
changes in only a single bit:

0 1 3 2 6 4 5 7
0 1 3 2 6 7 5 4 circular
0 1 3 7 5 4 6 2 circular
0 1 5 4 6 2 3 7
0 1 5 4 6 7 3 2 circular
0 1 5 7 3 2 6 4 circular
0 2 3 1 5 4 6 7
0 2 3 1 5 7 6 4 circular
0 2 3 7 6 4 5 1 circular
0 2 6 4 5 1 3 7
0 2 6 4 5 7 3 1 circular
0 2 6 7 3 1 5 4 circular
...

Sequences which wraps around with only a single bit change are marked
circular. 

Please note that this is not production code (simply I hack I used
myself). Use at your own risk. If you use and like the program, please
tell Xilinx that you would like their tools ported to Linux :-)

Petter
-- 
________________________________________________________________________
Petter Gustad       8'h2B | (~8'h2B) - Hamlet      http://www.gustad.com
#include <stdio.h>/* compile/run this program to get my email address */
int main(void) {printf ("petter\100gustad\056com\nmy opinions only\n");}

Article: 28392
Subject: Re: Alliance for Linux
From: Thomas Reinemann <thomas.reinemann@mb.uni-magdeburg.de>
Date: Thu, 11 Jan 2001 10:47:43 +0100
Links: << >>  << T >>  << A >>


Dennis McCrohan wrote:
> 
> 
> Linux presents some real challenges from a s/w business point-of-view (as
> opposed to looking at it as a programmer's toy). Think of it from the
> perspective of a software quality assurance manager, or support manager. The
> reality of Linux is that there are no two Linux installations alike. I have
> Linux on one of my machines, originally RH 6.0. But now I can claim no
> version for it, since I've rebuilt the kernel several times with various
> patches.... If I build our tools on my box, how do I warranty that they will
> run (correctly) on any other Linux machine in the world? In the Windows
> world, we have SP's from MS that we can specify on our product requirements
> and build and test against (oh yeah, we also have to test against many
> localized versions of Windows). A lot of combinations, but at least finite.
> 
I can't reproduce your arguments. E.g., I'm using Modelsim on a Suse
Linux box, whether Modeltech recommend Red Hat it works fine (Suse is
the preferred distribution in german speaking countries). If such a
incompatibility would exist, Linux' market share would not increase.
There is not only the EDA market, for example Borland is now supporting
Linux with it famous s/w development tools. How about the experience of
other companies now supporting Linux? 


-- 
Dipl.-Ing. Thomas Reinemann
IMAT
Otto-von-Guericke-Universität Magdeburg
Universitätsplatz 2
39106 Magdeburg
Germany

Article: 28393
Subject: Re: Alliance for Linux
From: Petter Gustad <spam@gustad.com>
Date: 11 Jan 2001 10:58:42 +0100
Links: << >>  << T >>  << A >>
Peter Alfke <peter.alfke@xilinx.com> writes:

>I have forwarded these request to the appropriate party (and also to the
>highest level) within Xilinx. I will let them come up with the right
>response.
>We are aware of the problem and the opportunity.

Thank you Peter,

I personally think you will get more requests for Linux as the Xilinx
devices gets bigger. Lately I've been retargeting some of our earlier
ASIC (LSI G10) designs into a Virtex. The time it takes to run through
synthesis and par is quite long (27+ hours on a SUN).

Almost every night I log in from home to check my simulation and
synthesis (or par) jobs. Every now and then I'll have to install or
upgrade software while the machine is running (e.g. new Alliance
service pack while FPGA Compiler 2 is running, or vice versa, or
verilog simulations running for weeks). Doing this under Windows is
quite cumbersome as I have explained earlier.

I could of course buy the fastest SUN machine I can get, but I would
rather get a farm of cheap PC's and run Linux...

Petter
-- 
________________________________________________________________________
Petter Gustad       8'h2B | (~8'h2B) - Hamlet      http://www.gustad.com
#include <stdio.h>/* compile/run this program to get my email address */
int main(void) {printf ("petter\100gustad\056com\nmy opinions only\n");}

Article: 28394
Subject: Re: Alliance for Linux
From: Petter Gustad <spam@gustad.com>
Date: 11 Jan 2001 11:03:18 +0100
Links: << >>  << T >>  << A >>
Dennis McCrohan <mccrohan@xilinx.com> writes:


>I probably shouldn't, but I can't resist commenting on this thread...
>Let's preface this by saying that the following in no way, shape, or form
>expresses the opinion of Xilinx, Inc.

Thank you for your comments.

>Linux presents some real challenges from a s/w business point-of-view (as
>opposed to looking at it as a programmer's toy). Think of it from the

I've been doing ASIC design for 10+ years and I've been a Linux user
for the past 7 years (since kernel version 0.99.13). During this time
I've used Linux for production type work and and I would not look at
Linux as a programmers toy...

I'm aware of the vast distribution and library space space under
Linux. I've been running Slackware (and SLS) distributions of Linux. I
too don't know what to call my Linux (other than it used to be a
Slackware release, but now is running kernel 2.4.0).

However, this does not prevent me from running EDA tools from
Synopsys, Cadence and Fintronic. Cadence and Synopsys are actually
facing more difficult problems than Xilinx since they distribute
object files (e.g. for signalscan) and the user links the objects
together to build the executable simulator. Some of objects might be
based upon different libc versions which might cause problems.

Some vendors say that they support a finite set of popular releases
(e.g. Red Hat 6.2/x86). Others say that they will give you Linux
binaries and you're on own if you get problems. I can't see why Xilinx
would have to support all possible releases and patches out there.

Petter
-- 
________________________________________________________________________
Petter Gustad       8'h2B | (~8'h2B) - Hamlet      http://www.gustad.com
#include <stdio.h>/* compile/run this program to get my email address */
int main(void) {printf ("petter\100gustad\056com\nmy opinions only\n");}

Article: 28395
Subject: Re: VIRTEX : pad location
From: Michael Boehnel <boehnel@iti.tu-graz.ac.at>
Date: Thu, 11 Jan 2001 11:34:33 +0100
Links: << >>  << T >>  << A >>
Maybe you have the same problem as I (See posting: "Foundation P&R + location constraint" from Monday). The optimizer (synthesis tool or P&R) cancels one of your signals and the P&R tool results in an error because of the invalid pin assignment in the constraint
file (location constraint for non existent signal).

Why can't the P&R tool just generate a warning instead of an error and assign this pin prohibited for the actual implementation?

To come to an ad hoc solution for your problem:
You could assign this input signal directly to an unused output pin -> no removing of the optimizer possible.

Maybe there are some expert's who know how to tell the synthesis tool not to remove single signals via attributes?

Michael

diei-unipg-it wrote:

> We are implementing a fir filter using VIRTEX FPGA XCV1000-6-BG560.We got a problem during the implementation.Does anybody know how to avoid a signal to be removed during the implementation?For a better understanding of the question a part of the report text
> of map.mrp file follows:
>
> The signal "N_ControlPortPins<7>" is unused and has been removed.
>  Unused block "C_ControlPortPins<7>" (IBUF) removed.
>   The signal "ControlPortPins<7>" is unused and has been removed.
>    Unused block "ControlPortPins<7>.PAD" (X_IPAD) removed.




Article: 28396
Subject: Re: grey code counters
From: Wolfgang Friedrich <wolfgang.friedrich@heitec.de>
Date: Thu, 11 Jan 2001 11:52:06 +0100
Links: << >>  << T >>  << A >>
Hello,

Peter Alfke schrieb:
> 
> I suggested a slight twist to this design:
> Same logic, but feed the XOR from the D-inputs of the binary counter, not their
> Q outputs. This way the binary and grey counters are "in step".
> Peter Alfke

How do I get access to the D-inputs of the binary counter in VHDL?

> 
> Kevin Neilson wrote:
> 
> > Bill,
> > Making a Gray counter is surprisingly simple.  I have some code, which I
> > can't  give out, but it is basically just a conventional counter and some
> > XORs.  Say you have an N-bit counter, CNT, and want an N-bit Gray counter.
> > Gray[0] is (CNT[1] ^ CNT[0]), Gray[1] is (CNT[2] ^CNT[1]), ... Gray[N-2] =
> > (CNT[N-1] ^ CNT[N-2]), and finally, the last bit, Gray[N-1] = CNT[N-1].
> > "Gray" can just be the output of the flipflops, or you can pipeline the
> > output for extra speed.  In that case the Gray counter would run at whatever
> > speed the convential counter ran.
> >
> > You may hardcode this or use a loop to make Gray counters of N size.
> >
> > -Kevin Neilson, IDS
> >

-- 
Wolfgang Friedrich       wolfgang.friedrich@heitec.de         /\ /\
Heitec AG                                                  __/  \\ \__
91052 Erlangen, Schuhstr. 30, Germany                        \  // /
Tel: +49(0)9131/877-237 Fax: +49(0)9131/877-222               \/ \/

Article: 28397
Subject: Re: Methodology
From: Petter Gustad <dev.null@dev.null.org>
Date: 11 Jan 2001 11:54:28 +0100
Links: << >>  << T >>  << A >>
murray@pa.dec.com (Hal Murray) writes:

> > (3) Do builds from the command line. Learning how to use ``make'' will
> > vastly repay the effort.
> 
> How many other people would be happier if Xilinx "supported" make style
> development?

I almost never use the interactive tools (except the floorplanner).
Here's roughly the flow through my scripts (for a virtex device):

partgen
ngdbuild
map
par
trce
bitgen
promgen
ngdanno
ngd2ver

The last two steps are to generate a gate level verilog netlist and
standard delay file.

Petter
-- 
________________________________________________________________________
Petter Gustad       8'h2B | (~8'h2B) - Hamlet      http://www.gustad.com
#include <stdio.h>/* compile/run this program to get my email address */
int main(void) {printf ("petter\100gustad\056com\nmy opinions only\n");}
Article: 28398
Subject: Re: Alliance for Linux
From: Petter Gustad <dev.null@dev.null.org>
Date: 11 Jan 2001 12:05:40 +0100
Links: << >>  << T >>  << A >>
acher@in.tum.de (Georg Acher) writes:

> I spoke about this topic to a FAE of the Xilinx booth at the electronica last
> year. He said roughly the following:
> 
> "The Xilinx SW-developers already have Linux versions, since the development  
> of the core tools (map/par etc.) is faster than on Solaris and not as 
> reboot-prone as on Windows. The reason for the non-availability on the

IIRC this was the case with Design Acceleration as well (before they
were acquired by Cadence), they used Linux as an internal development
tool to develop Solaris, HP and IBM binaries. After a while they
released the Linux/x86 version too.

Petter
-- 
________________________________________________________________________
Petter Gustad       8'h2B | (~8'h2B) - Hamlet      http://www.gustad.com
#include <stdio.h>/* compile/run this program to get my email address */
int main(void) {printf ("petter\100gustad\056com\nmy opinions only\n");}

Article: 28399
Subject: Re: Alliance for Linux
From: eml@riverside-machines.com.NOSPAM
Date: Thu, 11 Jan 2001 11:13:21 GMT
Links: << >>  << T >>  << A >>
On Wed, 10 Jan 2001 12:23:26 -0800, Dennis McCrohan
<mccrohan@xilinx.com> wrote:

<snipped>

I hate to say it, but I agree. On the other hand, if you released Red
Hat tools, and specified that anyone who messed around with their
kernels/libs/whatever was on their own, then I'd dump Debian today and
install RH.

And even if you released an unsupported Linux version, I'd probably
still use it.

Evan 



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