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 36425

Article: 36425
Subject: Re: Xilinx machine readable package info
From: Petter Gustad <newsmailcomp1@gustad.com>
Date: 08 Nov 2001 19:59:31 +0100
Links: << >>  << T >>  << A >>
"Leon Heller" <leon_heller@hotmail.com> writes:

> "Petter Gustad" <newsmailcomp1@gustad.com> wrote in message
> news:87zo5yp87r.fsf@filestore.home.gustad.com...
> >
> > I'm working on a program to aid me in the tedious allocation of pins
> > for a Virtex-II device. But I need to obtain package information,
> > presumably in machine readable form. I can use partgen to generate a
> > plain ASCII file, but this does not contain any information regarding
> > the bank number for each pin. Is there an ASCII (or documented binary
> > file) file where I can find this information?
> 
> http://www.xilinx.com/products/virtex/vpackages.htm

Thanks, great. I'll just have to locate the same file for virtex2. So
far I've only found PDF files.

Petter
-- 
________________________________________________________________________
Petter Gustad   8'h2B | (~8'h2B) - Hamlet in Verilog   http://gustad.com

Article: 36426
Subject: Re: Xilinx machine readable package info
From: Petter Gustad <newsmailcomp1@gustad.com>
Date: 08 Nov 2001 20:01:46 +0100
Links: << >>  << T >>  << A >>
Rick Filipkiewicz <rick@algor.co.uk> writes:

> A trick I use, given that the idea of  publishing simple ASCII text
> pinout/function files has escaped the attention of the chip industry since
> its inception, is to fake a design that uses every pin of the device (incl.
> clocks). Then a perl script can extract all the info you need from the post
> P&R .pad and .par files. The only non-simple thing you need to do is make
> sure there's at least one non-LVTTL IO standard so that the .par file has
> the banking info.

Smart. 
I'll look into that if I can't find any other easily readable files.

Petter
-- 
________________________________________________________________________
Petter Gustad   8'h2B | (~8'h2B) - Hamlet in Verilog   http://gustad.com

Article: 36427
Subject: Re: FPGA Wish list
From: nweaver@CSUA.Berkeley.EDU (Nicholas Weaver)
Date: Thu, 8 Nov 2001 19:25:42 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <3BE9A84C.EAF321C4@xilinx.com>,
Peter Alfke  <peter.alfke@xilinx.com> wrote:
>I see three good reasons why FPGA manufacturers do not incorporate DRAMs on
>their chips:

>Technical: DRAMs require different processing steps ( trench
>capacitors, etc ), which would increase the cost of the composite
>die.

Not only that, but it does tend to slow down the logic processes a bit
as well, as the transistors are optimized for lower leakage.  There
are talk of processes which use effectively different transistors for
the DRAM cells as the rest of it, but that adds even more processing
steps.

Also, the real benefit of embedded DRAM is very high bandwidth by
throwing lots of wires at the problem with independant banks with wide
interfaces.  How many FPGA applications can use 512 bit memory busses?

>We have introduced many non-homogeneous features that are (almost) universally
>appreciated:
>Carry, LUT-RAM, BlockRAM, multipliers, digital clock management,
>digitally-controlled output impedance, etc.

And my favorite, the properly-paranoid bitfile encryption features on
the Virtex II. :)
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 36428
Subject: Re: "Illegal assignment" message, NEED HELP, PLEASE!!!
From: jaime.aranguren@ieee.org (Jaime Andres Aranguren Cardona)
Date: 8 Nov 2001 11:58:55 -0800
Links: << >>  << T >>  << A >>
Hi Nicolas,

Well, what I am trying to do is to rise high the clk_rb_int signal
when there is a rising edge on the we_intern or the re_intern signals.

OK, it should be like the system clock signal (inverted), but
shouldn't rise before we_intern or re_intern rise high as well.

Please help me with this stuff.

Best regards,
Jaime.

Nicolas Matringe <nicolas.matringe@ipricot.com> wrote in message news:<3BEA51A2.3A9FEDF9@ipricot.com>...
> Tim Hubberstey a écrit :
> > 
> > What it's complaining about in this rather confusing error
> > message is that you have two different processes assigning to
> > the same signal, clk_rb_inter. While this appears to be legal
> > VHDL (assuming clk_rb_inter is of type std_logic) it is not
> > synthesizable. You need to rewrite your code to combine the two
> > rb_clock processes into one process.
> > 
> > Further, you need to think about whether you really want to
> > generate a clock using combinational processes like this.
> 
> What puzzles me is the purpose of this description. clk_rb_inter should go high
> only when there is an event on we_inter or re_inter and go low when nothing
> happens? I can't find any sense in that, this would mean that it's high during
> the event (which, ideally, takes no time).

Article: 36429
Subject: Re: Xilinx dedicated IO pins
From: Jens-Christian Lache <lache@tuhhN0ZPAM.de>
Date: Thu, 08 Nov 2001 21:04:27 +0100
Links: << >>  << T >>  << A >>
jakab tanko wrote:

> Hi all,
>
> Could somebody please tell me how to prevent the xlnx P&R
> tool (Alliance 3.1i) from assigning the dedicated pins on a spartan2
> (D0/DIN,
> BUSY/DOUT ..etc) to user IO, I want to keep the dedicated
> pins dedicated...I spent the better part of the day searching the
> xlnx site but got nowhere
> Thanks,
> jakab

I'm not sure if I understood the question right. According to
ds_001_4.pdf
these pins are I/O pins, so there is no reason why not to use them.
Did you lock the pins in the ucf file? If not, you should do it.
If you don't care about a specific locking, you can just go to the
project manager, under "Tools"->"Implementation" you'll find
"Lock Device Pins". Propably you noticed that the IDE is working
with two ucf files, one in the root directory of your project and one
in "xproj/ver1/rev". The file in the root directory is only copied once
to "xproj/ver1/rev", after the project data was cleared. The constraints

editor and "Translate" work on the digged version. You can edit the
pad locations by hand, the floorplanner is a great help, just move
the cursor over a pad and it tells you the name of the pad. Hope that
helps,wfr -jc-


Article: 36430
Subject: Re: FPGA Wish list
From: "Tim" <tim@rockylogic.com.nospam.com>
Date: Thu, 8 Nov 2001 20:20:57 -0000
Links: << >>  << T >>  << A >>

"Nicholas Weaver" <nweaver@.........eley.EDU> wrote
> Also, the real benefit of embedded DRAM is very high bandwidth by
> throwing lots of wires at the problem with independant banks with wide
> interfaces.  How many FPGA applications can use 512 bit memory busses?

Lots.  512-bit good, 32x1024 better, 1M even better.  It a parallel
world - ask your brain.




Article: 36431
Subject: Re: FPGA Wish list
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Thu, 8 Nov 2001 21:37:02 +0100
Links: << >>  << T >>  << A >>

"Nicholas Weaver" <nweaver@CSUA.Berkeley.EDU> schrieb im Newsbeitrag
news:9sem7m$1d5f$1@agate.berkeley.edu...

> >Technical: DRAMs require different processing steps ( trench
> >capacitors, etc ), which would increase the cost of the composite
> >die.
>
> Not only that, but it does tend to slow down the logic processes a bit
> as well, as the transistors are optimized for lower leakage.  There
> are talk of processes which use effectively different transistors for
> the DRAM cells as the rest of it, but that adds even more processing
> steps.

Right, but how about a multichip package? Just move two dies into one
package, add a hardmacro for the DRAM interface, maybe with some kind of
FIFO and other luxury stuff. Taataaa, your FPGA fabric can right access damm
fast DRAM. An since the connections are only some mm of bonding wire (or
even just bonding pads if you stack the dies), you will get BIG improvements
in HF properties.

> Also, the real benefit of embedded DRAM is very high bandwidth by
> throwing lots of wires at the problem with independant banks with wide
> interfaces.  How many FPGA applications can use 512 bit memory busses?

;-)) Are you kidding. As far as I can see, memorie bandwidth demand grows
daily.

--
MfG
Falk




Article: 36432
Subject: Re: FPGA Wish list
From: nweaver@CSUA.Berkeley.EDU (Nicholas Weaver)
Date: Thu, 8 Nov 2001 20:48:33 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <1005251212.18406.0.nnrp-13.9e9832fa@news.demon.co.uk>,
Tim <tim@rockylogic.com.nospam.com> wrote:
>
>"Nicholas Weaver" <nweaver@.........eley.EDU> wrote
>> Also, the real benefit of embedded DRAM is very high bandwidth by
>> throwing lots of wires at the problem with independant banks with wide
>> interfaces.  How many FPGA applications can use 512 bit memory busses?
>
>Lots.  512-bit good, 32x1024 better, 1M even better.  It a parallel
>world - ask your brain.

The problem is that the benefits of embedded DRAM only really occur
when you have really wide busses for single accesses, and you have a
pretty low level interface (you want to take advantage of the
Sense-amps and column-caches and banking and the like).

With an FPGA, it has to either be, A) A very small amount of silicon
real estate (EG, the Virtex II bitfile cryptography, the multipliers)
or B) useable by a huge number of customers (BlockRAMs) for it to be
worth implementing.

What percentage of the customers would rather have a single 2 Mbit (or
maby 8 Mbit) memory with a 64-512 bit interface, with higher latency
and (probably) single ported access, over say, 8 8kbit dual ported
SRAMS with faster access and 1-16 bit flexible interfaces?  This is
the sort of tradeoff we are talking about.

Instead, if you want Xilinx to spend silicon area and cost, probably a
better thing to advocate would be a good DDR SDRAM interface as a hard
macro combined with specialized circuits.  It doesn't give you quite
the memory bandwidth of the embedded DRAM solution, but it doesn't
require special processing steps and it is useable by more people
(since you can have MUCH larger memories).
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 36433
Subject: Re: FPGA Wish list
From: nweaver@CSUA.Berkeley.EDU (Nicholas Weaver)
Date: Thu, 8 Nov 2001 20:53:28 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <9seqq0$131o71$1@ID-84877.news.dfncis.de>,
Falk Brunner <Falk.Brunner@gmx.de> wrote:

>Right, but how about a multichip package? Just move two dies into one
>package, add a hardmacro for the DRAM interface, maybe with some kind of
>FIFO and other luxury stuff. Taataaa, your FPGA fabric can right access damm
>fast DRAM. An since the connections are only some mm of bonding wire (or
>even just bonding pads if you stack the dies), you will get BIG improvements
>in HF properties.

Hmm, the problem is, MCMs are PRIIICEY.  Also, I'd expect we will
start seeing area pads on FPGAs really-soon-now, if not already, as
they have several advantages, but which makes MCMs even more annoying.

Perhaps a memory techonogy with area pads and vias, so you could
sandwitch together two chips with area pads?  But it does sound
funky/expensive.

>;-)) Are you kidding. As far as I can see, memorie bandwidth demand grows
>daily.

Except that it is fairly specialized memory bandwidth that process
embedding gains.


-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 36434
Subject: Re: Xilinx machine readable package info
From: Petter Gustad <newsmailcomp1@gustad.com>
Date: 08 Nov 2001 22:08:46 +0100
Links: << >>  << T >>  << A >>
Mike Treseler <mike.treseler@flukenetworks.com> writes:

> Petter Gustad wrote:
> > 
> > I'm working on a program to aid me in the tedious allocation of pins
> > for a Virtex-II device. But I need to obtain package information,
> > presumably in machine readable form.
> 
> bsdl files include the pin names and designations.

But they don't contain information about the banks...

Petter
-- 
________________________________________________________________________
Petter Gustad   8'h2B | (~8'h2B) - Hamlet in Verilog   http://gustad.com

Article: 36435
Subject: Re: Xilinx dedicated IO pins
From: "jakab tanko" <jtanko@ics-ltd.com>
Date: Thu, 8 Nov 2001 16:41:42 -0500
Links: << >>  << T >>  << A >>
I don't have a problem with all dedicated pins, just the JTAG and master
serial
configuration pins; suppose one of your JTAG pins ends up shared with a data
pin driven from a RAM (no tri-state RAM outputs); there will be a
conflict
on that pin with multiple drivers ....
Anyway, the suggestion from Magnus with the .UCF file worked with a little
twist:
I also had to go and manualy delete the .map file then P&R again, othervise
the map file would not reflect the changes

Thanks for the answers,
jakab

Jens-Christian Lache <lache@tuhhN0ZPAM.de> wrote in message
news:3BEAE54B.E04D79DF@tuhhN0ZPAM.de...
> jakab tanko wrote:
>
> > Hi all,
> >
> > Could somebody please tell me how to prevent the xlnx P&R
> > tool (Alliance 3.1i) from assigning the dedicated pins on a spartan2
> > (D0/DIN,
> > BUSY/DOUT ..etc) to user IO, I want to keep the dedicated
> > pins dedicated...I spent the better part of the day searching the
> > xlnx site but got nowhere
> > Thanks,
> > jakab
>
> I'm not sure if I understood the question right. According to
> ds_001_4.pdf
> these pins are I/O pins, so there is no reason why not to use them.
> Did you lock the pins in the ucf file? If not, you should do it.
> If you don't care about a specific locking, you can just go to the
> project manager, under "Tools"->"Implementation" you'll find
> "Lock Device Pins". Propably you noticed that the IDE is working
> with two ucf files, one in the root directory of your project and one
> in "xproj/ver1/rev". The file in the root directory is only copied once
> to "xproj/ver1/rev", after the project data was cleared. The constraints
>
> editor and "Translate" work on the digged version. You can edit the
> pad locations by hand, the floorplanner is a great help, just move
> the cursor over a pad and it tells you the name of the pad. Hope that
> helps,wfr -jc-
>



Article: 36436
Subject: Re: Quadrature Encoder Sampling Time
From: John_H <johnhandwork@mail.com>
Date: Thu, 08 Nov 2001 21:43:21 GMT
Links: << >>  << T >>  << A >>
Rather than sampling the quadrature signal to extract a count pulse,
consider using the quadrature signals to directly drive a counter scheme.
While there might be some uncertainty of an edge of one of the two
quadrature signals, a gray code style counter will only have one bit
changing at any one time.

By driving an internal up/down counter, the full rotation position can be
captured.  You then just need to sample this counter before you're 180
degrees out of phase with the count value;  a 6 bit counter (0-63) gives
you +/- 2 turns to work with before the value's ambiguous.


anon7864 wrote:

> I was wondering if anyone would like to share their experience in
> doing quadrature encoder decoding in programmable logic.
>
> I am trying to deduce the minimal sampling rate for a hand-turned knob
> that is a 2 channel, 16 position device. Currently I use a 12 state
> Finite State Machine running at 6MHz to decode the encoders. I am
> trying to reduce this to a more reasonable level to reduce power
> consumption/heat.
>
> The spec sheet on the encoders we use says that the maximum RPM is
> 100. A call to the factory reveals that: "Encoder section - 300 RPM
> max, average manual operation is in the range of 1 to 16 RPM max.
> ...tested (Per MIL-3786/39) @rate of 10 cycles per miv, which is 20
> RPM (One cycle is a rotation thru all positions and full return.)"
>
> I would like to design for worst case of 300RPM.
>
> position_time=200ms/16positions=13msec
>
> Shannon's theorem says that scan_rate=13msec/2=6msec (round down)
>
> This scan rate is not what I expected. I would have expected to scan
> at around 1msec or less. I have proven this empirically on the
> o-scope.
>
> So why in the encoder world, is the emperical to calculated comparison
> so bad? What am I missing in my analysis? Am I just starting out with
> a bogus initial RPM? What has your experience been on this problem??
>
> Thanks in advance!


Article: 36437
Subject: Re: Xilinx machine readable package info
From: Neil Franklin <neil@franklin.ch.remove>
Date: 08 Nov 2001 23:21:19 +0100
Links: << >>  << T >>  << A >>
"Leon Heller" <leon_heller@hotmail.com> writes:

> "Petter Gustad" <newsmailcomp1@gustad.com> wrote in message
> news:87zo5yp87r.fsf@filestore.home.gustad.com...
> >
> > plain ASCII file, but this does not contain any information regarding
> > the bank number for each pin. Is there an ASCII (or documented binary
> > file) file where I can find this information?
>
> I found pinouts for the Spartan-II chips in the form of an Excel spreadsheet
> somewhere on the Xilinx web site. It should be available for the Virtex
> chips as well.

After seeing the Virtex data in one of the other posts, I got a bit of
hope, and went searching the Xilinx site for Spartan-II (which is what
I need, more precise XC2S200-PQ208).

This seems to be your Excel file(s), in .zip archive:

http://www.xilinx.com/products/spartan2/s2_pin.zip


Unfortunately(?) I have no Windows and no Excel, so I need ASCII or
HTML. I am not aware of some anti-word like program for Excel.

Could one of the @xilinx.com people here on this group get someone to
do and excel-ectomy on these files and put the raw data on the site,
like it is for Virtex?


--
Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/
Hacker, Unix Guru, El Eng HTL/BSc, Sysadmin, Archer, Roleplayer
- Intellectual Property is Intellectual Robbery

Article: 36438
Subject: Re: Question about pipelining a design
From: Russell Shaw <rjshaw@iprimus.com.au>
Date: Fri, 09 Nov 2001 10:54:40 +1100
Links: << >>  << T >>  << A >>
What i really meant was:


  reg1_in<=func1(data_in);
  reg2_in<=func2(reg1_out);
  reg3_in<=func2(reg2_out);
  data_out<=func3(reg3_out);

process 
begin
wait until rising_edge(clk);
  reg1_out<=reg1_in;
  reg2_out<=reg2_in;
  reg3_out<=reg3_in;
end process;


Russell Shaw wrote:
> 
> The Ashendon vhdl book describes pipelining, and others would too.
> 
> In a process, you have:
> 
> process
> begin
>   reg1_in<=func1(data_in);
>   reg2_in<=func2(reg1_out);
>   reg3_in<=func2(reg2_out);
>   data_out<=func3(reg3_out);
> 
> wait until rising_edge(clk);
>   reg1_out<=reg1_in;
>   reg2_out<=reg2_in;
>   reg3_out<=reg3_in;
> end process;
> 
> Marty wrote:
> >
> > I am working on a waveform generator that gets data from a dual-port RAM,
> > and outputs it. It also has timing and jump instructions in the RAM data.
> > The goal is to run at 50 MHz.  The RAM, is 64K deep, and 15 nS access time.
> >
> > I can get the machine to simulate at 33 MHz, but not at 50 MHz.  I think the
> > way to solve this is to redesign the machine in a pipelined form.
> > I have fit the non pipelined design into an Altera 7512AE.
> > Some of the problems are getting the machine to do relative jumps - absolute
> > jumps work.
> >
> > Does anyone know of any tools to help visualize or design a project like this?
> >
> > Marty

Article: 36439
Subject: Re: How dense are FPGA/CPLD's
From: Russell Shaw <rjshaw@iprimus.com.au>
Date: Fri, 09 Nov 2001 10:55:27 +1100
Links: << >>  << T >>  << A >>


Peter Alfke wrote:
> 
> Russell Shaw wrote:
> 
> >
> > There's a .pdf on the altera site that categorizes FPGAs as things
> > with segmented interconnects, whereas CPLDs don't have segments,
> > making routing easier.
> 
> Beware of marketing fluff.
> They just wanted to indicate a distinction from Xilinx, while the two companies were embroiled in a
> patent war.
> "If it looks like an FPGA, behaves like an FPGA, is generally considered to be an FPGA", then they
> might as well call it an FPGA, and admit that they copied the Xilinx concept.
> Well, the patent fight is settled. Altera paid up, and perhaps they will now use a more reasonable
> nomenclature.

What was the patent over?

Article: 36440
Subject: Re: Maxplus error
From: Russell Shaw <rjshaw@iprimus.com.au>
Date: Fri, 09 Nov 2001 11:02:15 +1100
Links: << >>  << T >>  << A >>


Andrew Gray wrote:
> 
> Hi I declared a VHDL array in Maxplus as follows:
> 
> type nik_table_i  is array (0 to 63) of std_logic_vector(23 downto 0);
> 
> constant Ni0 : nik_table_i :=
> ("000010110101000001001111","000010101011111010110100","00001010001001100111
> 1001","000010011000011111111011",...
> 
> when I tried to compile I got the following error:
> 
> Unsupported feature error: aggregates are supported only for types that map
> to an array of bits.
> 
> Does any one know how to fix this

Obviously it wants bits. Other than trying another tool, maybe you
could use:

type nik_table_i is array (0 to 63) of bit_vector(23 downto 0);

Article: 36441
Subject: Multiple levels of reset in CPLD
From: Dean Armstrong <daa1@cs.waikato.ac.nz>
Date: Fri, 09 Nov 2001 13:23:47 +1300
Links: << >>  << T >>  << A >>
Hi All,

I am designing a system which contains a Xilinx XC95288XL CPLD.

This CPLD has two functions. It must act as an FPGA loader, reading an
FPGA image from ROM and writing it to a Xilinx Spartan II. The second
function is for it to act as an I/O device for the Spartan (which is
configured as a CPU). It is always in only one of these two modes.

There are two possible reset levels on the board.

A hard reset (equivalent to power cycling the board, but also possible
via a button) should cause the CPLD to configure the Spartan II.

A CPU reset (normal reset button) should cause the CPLDs I/O mode to
reset itself (clear status and control registers).

I would like to know if this is possible to do using the XC95288XL.
On this chip there is only one GSR input. I would probably use this for
the board reset input. Can I use a normal I/O pin for the second reset
signal?

Thanks very much,
Dean Armstrong


Article: 36442
Subject: Re: How dense are FPGA/CPLD's
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Thu, 08 Nov 2001 17:10:56 -0800
Links: << >>  << T >>  << A >>


Russell Shaw wrote:

> What was the patent over? (This refers to the Xilinx vs Altera lawsuit.)

I refuse to go into the merits and demerits of the case. But the main bone of contention was the Xilinx
( Ross Freeman ) patent #4 870 302 and its re-issue RE 34,363.  I bet Altera would give you a different
answer.
Thank God it's over. Xilinx received a (token) $20M settlement from Altera. Only the lawyers got rich...

Peter Alfke



Article: 36443
Subject: A Quadrature Encoder to binary counter
From: John_H <johnhandwork@mail.com>
Date: Fri, 09 Nov 2001 02:26:49 GMT
Links: << >>  << T >>  << A >>
Please forgive me if the formatting comes out strange due to line wraps...
The code below is Verilog compiled on Synplify, targeted to a Xilinx
Spartan-II device (latches are primitives in this device), and simulated with
Verilog-XL.

This approach should simplify quadrature encoder interface so you grap a
number only when you need the number.  The width can be extended to very
large numbers if one likes, the delays simply increase.  The number of CLBs
to implement the function is comfortably small.

Comments are appreciated.



module Quad ( QuadratureIn   // This module takes in a quadrature signal
            , Clk            //  and, upon receiving the sampling clock,
            , BinaryOut      //  produces a 6 bit binary count.
            );               // (no reset or load is included in this code)

input  [1:0] QuadratureIn;  // Assuming up count is binary 0-1-3-2-0
input        Clk;           // Only used to sample the count
output [5:0] BinaryOut;     // Combinatorial output of gray-to-binary

wire [5:0] BitEna;    // Build latches where one MSB can change at a time
wire [5:0] Polarity;  // [5:1] bits mirror QuadratureIn[1] or its inverse
reg  [5:0] GrayCnt;
reg  [5:0] GraySample;
integer i;

assign BitEna = { GrayCnt[3:0]==4'b0000  // MSbit enables different than
lower bits
                , GrayCnt[3:0]==4'b1000  //
                , GrayCnt[2:0]==3'b100   // Middle bits are enabled by the
                , GrayCnt[1:0]==2'b10    //  n lower bits equalling 1<<(n-1)
                , GrayCnt[  0]==1'b1     //
                , 1'b1               };  // LSbit always tracks
QuadratureIn[0]

assign Polarity = {   GrayCnt[4]       // MSbit changes different from lower
bits
                  ,  ~GrayCnt[5]       //
                  , ^~GrayCnt[5:4]     // Middle bits depend only on the
                  , ~^GrayCnt[5:3]     //  polarity of the bits above them
                  ,  ^GrayCnt[5:2]     //    (be careful of the non-invert on
[1])
                  ,   1'b0         };  // LSbit tracks QuadratureIn[0]

always @(QuadratureIn or BitEna or Polarity or GrayCnt)
  for( i=0; i<6; i=i+1 )
    GrayCnt[i] = BitEna[i] ? QuadratureIn[i>0?1:0] ^ Polarity[i] :
GrayCnt[i];

always @(posedge Clk)     // Gray counters are inherently free of
metastability
  GraySample <= GrayCnt;  //  allowing the BinaryOut to be a stable value

assign BinaryOut = GraySample ^ BinaryOut>>1;  // gray-to-binary == xor
cascade

endmodule



Article: 36444
Subject: How to set timing constraint in Xilinx VirtexII device when using DCM
From: Kenneth <small__lee@hotmail.com>
Date: Fri, 09 Nov 2001 12:08:15 +0800
Links: << >>  << T >>  << A >>
Dear All,

I am not clear about how to set the timing constraint in VirtexII 
device when using the build-in DCM.

Currently I am using Synplify Pro 6.2 for synthesis and Xilinx ISE
3.308i for implementation.  My Design use an external 40MHz clock,
and is fed into a DCM.  Within the design,  I use both the 2x(clk2x)
and 4x(clkfx) clock output of the DCM to clock the internal logics.

In the Synplify Pro, there is a field for me to specify the required
operating frequency.  However no matter what value(e.g. 40MHz) I set, 
the implementation will treat all the clock(1x, 2x and 4x) have the 
same timing constraint of 40MHz(this is shown in the Place and Route
Report after the implementation).    As a result, I got a poor 
implementation result.

Even I add the the following constraints in the UCF file,

NET "CLOCK/dcm0_clk1x" TNM_NET = "CLOCK/dcm0_clk1x";
TIMESPEC "TS_CLOCK_dcm0_clk1x" = PERIOD "CLOCK/dcm0_clk1x" 25 ns HIGH 50
%;
NET "CLOCK/dcm0_clk2x" TNM_NET = "CLOCK/dcm0_clk2x";
TIMESPEC "TS_CLOCK_dcm0_clk2x" = PERIOD "CLOCK/dcm0_clk2x" 12.5 ns HIGH
50 %;
NET "CLOCK/dcm0_clkfx" TNM_NET = "CLOCK/dcm0_clkfx";
TIMESPEC "TS_CLOCK_dcm0_clkfx" = PERIOD "CLOCK/dcm0_clkfx" 12.5 ns HIGH
50 %;
(the hierarchy is Top_level -> CLOCK ->DCM)

the Place and Route Report still shown that the required frequency
for all clock are 40Mhz.

So, what should be the correct method to set the timing in my case?

Thanks in advance.

Regards,
Kenneth

Article: 36445
Subject: Re: How to set timing constraint in Xilinx VirtexII device when using
From: Kenneth <small__lee@hotmail.com>
Date: Fri, 09 Nov 2001 12:13:12 +0800
Links: << >>  << T >>  << A >>
Dear all,

Sorry, I added the following line to UCF file(I typed wrongly in my
previous post)

NET "CLOCK/dcm0_clk1x" TNM_NET = "CLOCK/dcm0_clk1x";
TIMESPEC "TS_CLOCK_dcm0_clk1x" = PERIOD "CLOCK/dcm0_clk1x" 25 ns HIGH
50%;
NET "CLOCK/dcm0_clk2x" TNM_NET = "CLOCK/dcm0_clk2x";
TIMESPEC "TS_CLOCK_dcm0_clk2x" = PERIOD "CLOCK/dcm0_clk2x" 12.5 ns HIGH
50%;
NET "CLOCK/dcm0_clkfx" TNM_NET = "CLOCK/dcm0_clkfx";
TIMESPEC "TS_CLOCK_dcm0_clkfx" = PERIOD "CLOCK/dcm0_clkfx" 6.25 ns HIGH
50%;
(the hierarchy is Top_level -> CLOCK -> DCM0,
and the net name of the 1x output is dcm0_clk1x, 
                        2x output is dcm0_clk2x, 
                        4x output is dcm0_clk4x)

Thanks again.

Regards,
Kenneth


Kenneth wrote:
> 
> Dear All,
> 
> I am not clear about how to set the timing constraint in VirtexII
> device when using the build-in DCM.
> 
> Currently I am using Synplify Pro 6.2 for synthesis and Xilinx ISE
> 3.308i for implementation.  My Design use an external 40MHz clock,
> and is fed into a DCM.  Within the design,  I use both the 2x(clk2x)
> and 4x(clkfx) clock output of the DCM to clock the internal logics.
> 
> In the Synplify Pro, there is a field for me to specify the required
> operating frequency.  However no matter what value(e.g. 40MHz) I set,
> the implementation will treat all the clock(1x, 2x and 4x) have the
> same timing constraint of 40MHz(this is shown in the Place and Route
> Report after the implementation).    As a result, I got a poor
> implementation result.
> 
> Even I add the the following constraints in the UCF file,
> 
> NET "CLOCK/dcm0_clk1x" TNM_NET = "CLOCK/dcm0_clk1x";
> TIMESPEC "TS_CLOCK_dcm0_clk1x" = PERIOD "CLOCK/dcm0_clk1x" 25 ns HIGH 50
> %;
> NET "CLOCK/dcm0_clk2x" TNM_NET = "CLOCK/dcm0_clk2x";
> TIMESPEC "TS_CLOCK_dcm0_clk2x" = PERIOD "CLOCK/dcm0_clk2x" 12.5 ns HIGH
> 50 %;
> NET "CLOCK/dcm0_clkfx" TNM_NET = "CLOCK/dcm0_clkfx";
> TIMESPEC "TS_CLOCK_dcm0_clkfx" = PERIOD "CLOCK/dcm0_clkfx" 12.5 ns HIGH
> 50 %;
> (the hierarchy is Top_level -> CLOCK ->DCM)
> 
> the Place and Route Report still shown that the required frequency
> for all clock are 40Mhz.
> 
> So, what should be the correct method to set the timing in my case?
> 
> Thanks in advance.
> 
> Regards,
> Kenneth

Article: 36446
Subject: Re: Maxplus error
From: "Srinivasan Venkataramanan" <srinivasan@siliconsystems.co.in>
Date: Fri, 9 Nov 2001 09:57:23 +0530
Links: << >>  << T >>  << A >>
Hi,

"Russell Shaw" <rjshaw@iprimus.com.au> wrote in message
news:3BEB1D07.290AE5EF@iprimus.com.au...
>
>
> Andrew Gray wrote:
> >
> > Hi I declared a VHDL array in Maxplus as follows:
> >
> > type nik_table_i  is array (0 to 63) of std_logic_vector(23 downto
0);
> >
> > constant Ni0 : nik_table_i :=
> >
("000010110101000001001111","000010101011111010110100","00001010001001
100111
> > 1001","000010011000011111111011",...
> >
> > when I tried to compile I got the following error:
> >
> > Unsupported feature error: aggregates are supported only for types
that map
> > to an array of bits.
> >
> > Does any one know how to fix this
>
> Obviously it wants bits. Other than trying another tool, maybe you
> could use:
>
> type nik_table_i is array (0 to 63) of bit_vector(23 downto 0);

  I don't use this tool, but my guess is that it is unable to "handle"
array of "bit_vector" (or array of "std_logic_vector").

--
Srinivasan Venkataramanan
ASIC Design Engineer
Software & Silicon Systems India Pvt. Ltd. (An Intel company)
Bangalore, India, Visit: http://www.simputer.org)




Article: 36447
Subject: Re: FPGA Wish list
From: Luke Roth <roth@narn.cse.psu.edu>
Date: Thu, 8 Nov 2001 23:31:14 -0500
Links: << >>  << T >>  << A >>
Actually, I don't think it's a dumb idea at all.  If processes keep
scaling as they have been, we're going to keep seeing more and more things
on-chip that previously wouldn't have been possible.  Back when
"programmable logic" meant PAL's, it would have been hard to convince me
that we'd be putting 36Kb SRAMs, integrated 18-bit multipliers, etc. on a
programmable logic chip, and next year they'll be integrating a full CPU
core.  Admittedly, integrated DRAM poses some interesting problems, but I
think it's just a matter of time.  I can already think of some fun
applications...
	Luke Roth


On Wed, 7 Nov 2001, Rob Finch wrote:

> > Are there any fpga's containing high capacity dram's on chip ? There seem
> to
> > be quite a few people interfacing to external drams.
> >
> I've have thought it through more carefully and realized it just doesn't
> make sense to provide on chip dram. Once again I have posted something and
> regretted it. I've managed to prevent myself from posting most of my dumb
> ideas, but this one escaped me. Sorry.
>
> >
>
>
>
>


Article: 36448
Subject: Re: Xilinx machine readable package info
From: Petter Gustad <newsmailcomp1@gustad.com>
Date: 09 Nov 2001 07:41:08 +0100
Links: << >>  << T >>  << A >>
Neil Franklin <neil@franklin.ch.remove> writes:

> "Leon Heller" <leon_heller@hotmail.com> writes:
> 
> > "Petter Gustad" <newsmailcomp1@gustad.com> wrote in message
> > news:87zo5yp87r.fsf@filestore.home.gustad.com...
> > >
> > > plain ASCII file, but this does not contain any information regarding
> > > the bank number for each pin. Is there an ASCII (or documented binary
> > > file) file where I can find this information?
> >
> > I found pinouts for the Spartan-II chips in the form of an Excel spreadsheet
> > somewhere on the Xilinx web site. It should be available for the Virtex
> > chips as well.
> 
> After seeing the Virtex data in one of the other posts, I got a bit of
> hope, and went searching the Xilinx site for Spartan-II (which is what
> I need, more precise XC2S200-PQ208).
> 
> This seems to be your Excel file(s), in .zip archive:
> 
> http://www.xilinx.com/products/spartan2/s2_pin.zip
> 
> 
> Unfortunately(?) I have no Windows and no Excel, so I need ASCII or

I don't use Windows either. Personally I can't see how people can
consider an OS where a reboot is a part of the typical installation
procedure as a serious EDA platform...

> HTML. I am not aware of some anti-word like program for Excel.

gnumeric, even though I've never actually used it myself.

> Could one of the @xilinx.com people here on this group get someone to
> do and excel-ectomy on these files and put the raw data on the site,
> like it is for Virtex?

It would be great if partinfo (or a similar) could generate most of
the information found in the NPH file in a well documented and easily
parsed ASCII format.

Petter
-- 
________________________________________________________________________
Petter Gustad   8'h2B | (~8'h2B) - Hamlet in Verilog   http://gustad.com

Article: 36449
Subject: Re: Fifo books
From: Peter Alfke <palfke@earthlink.net>
Date: Fri, 09 Nov 2001 07:25:20 GMT
Links: << >>  << T >>  << A >>

--------------FB7271C5E57BD5D3B6691747
Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353"
Content-Transfer-Encoding: 7bit



Russell Shaw wrote:
I found some other interesting things too:

>
> http://www.geocities.com/deepakgeorge2000/vlsi_book/Asynch1.pdf
> http://www.geocities.com/deepakgeorge2000/vlsi_book/async_fifo2.pdf

I looke at it and found it quite wordy. The author belabors
metastability, and does not understand that the leading edge of Full
and Empty is always a synchronous signal in the time domain of
interest. Only the trailing edge is asynchronous, but there
double-synchronizing is easy. Also, the generation of Grey addresses
is described in an unnecessarily complicated way.
I find my design so much simpler and less cluttered, if I may say so
:-)
See
http://www.xilinx.com/support/techxclusives/fifo-techX18.htm

Peter Alfke ( >30 years of FIFO experience, starting with the
Fairchild 3341 )


--------------FB7271C5E57BD5D3B6691747
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<p>Russell Shaw wrote:
<br>I found some other interesting things too:
<blockquote TYPE=CITE>&nbsp;
<br><a href="http://www.geocities.com/deepakgeorge2000/vlsi_book/Asynch1.pdf">http://www.geocities.com/deepakgeorge2000/vlsi_book/Asynch1.pdf</a>
<br><a href="http://www.geocities.com/deepakgeorge2000/vlsi_book/async_fifo2.pdf">http://www.geocities.com/deepakgeorge2000/vlsi_book/async_fifo2.pdf</a></blockquote>
I looke at it and found it quite wordy. The author belabors metastability,
and does not understand that the leading edge of Full and Empty is always
a synchronous signal in the time domain of interest. Only the trailing
edge is asynchronous, but there double-synchronizing is easy. Also, the
generation of Grey addresses is described in an unnecessarily complicated
way.
<br>I find my design so much simpler and less cluttered, if I may say so&nbsp;
:-)
<br>See
<br><u><A HREF="http://www.xilinx.com/support/techxclusives/fifo-techX18.htm">http://www.xilinx.com/support/techxclusives/fifo-techX18.htm</A></u><u></u>
<p>Peter Alfke ( >30 years of FIFO experience, starting with the Fairchild
3341 )
<br>&nbsp;</html>

--------------FB7271C5E57BD5D3B6691747--




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