Threads starting:
 1994 Jul Aug Sep Oct Nov Dec 1994 1995 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1995 1996 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1996 1997 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1997 1998 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1998 1999 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1999 2000 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2000 2001 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2001 2002 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2002 2003 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2003 2004 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2004 2005 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2005 2006 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2006 2007 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2007 2008 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2008 2009 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2009 2010 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2010 2011 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2011 2012 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2012 2013 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2013 2014 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2014 2015 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2015 2016 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2016 2017 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2017 2018 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2018 2019 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2019 2020 Jan Feb Mar Apr May 2020

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 18550

Article: 18550
Subject: Re: Comparison between Altera and Xilinx
From: u8713501@cc.nctu.edu.tw (Child K.L. Sun)
Date: Sat, 30 Oct 1999 08:40:02 GMT
Links: << >>  << T >>  << A >>
On Thu, 28 Oct 1999 17:23:00 -0400, Ray Andraka <randraka@ids.net> wrote:

>Oops... I was about to yell back to say I didn't say altera was better in all
>other apps, but reading my post that is what my fingers typed.  I would by no
>means say that Altera is best for everything else---it just plain isn't.  Those of
>you who know me know that what I meant to type was "For other applications, the
>Altera is sometimes better".   Altera tends to do better at collecting "random"
>logic, especially for the user who isn't willing to do placement.  (Again, this is
>not meant to be a blanket statement by any means).  Xilinx is better in the vast
>majority of datapath designs, and is a hands down winner in arithmetic designs or
>designs requiring delay queues.  When it comes down to it, the best device depends
>on the application, and might even include non-technical considerations such as
>tools ownership, designer experience etc.

For the "random" logic performance issue, doesn't it merely related to
the synthesis tool??

Child :~{}

Article: 18551
Subject: Re: Comparison between Altera and Xilinx
From: Ray Andraka <randraka@ids.net>
Date: Sat, 30 Oct 1999 08:56:16 -0400
Links: << >>  << T >>  << A >>
NO.

Assuming reasonable synthesis, the routing delays and ability to handle wide fanins
have a large impact on performance.  Altera's routing delays are relatively independent
of placement, so having not-so-local routing does not degrade performance
significantly.  Connections within a LAB in Altera are quite fast, and the altera
compiler does a fairly good job at keeping stuff within a LAB when the stuff is
reasonably small (provided carry chains don't prevent that).  In xilinx, routing delay
is much more dependent on placement, and the auto-place tools really don't do a very
good job.  Local routing in the xilinx is very fast, and very structured.  As you move
away from the structured placement there is a significant degradation of maximum clock
rate.  Random logic takes longer to hand place than a structured data path.

Child K.L. Sun wrote:

>         For the "random" logic performance issue, doesn't it merely related to
> the synthesis tool??
>
> Child :~{}

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


Article: 18552
Subject: Re: need reference to first paper on FPGA
From: Tom Kean <tom@algotronix.com>
Date: Sat, 30 Oct 1999 14:01:30 +0100
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------BB51596145F9BE5180CC1A9E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

Arrigo Benedetti wrote:

> does anyone have the reference to the paper where the FPGA
> was first introduced?
>

The question is bit more complex than it sounds:
- as far as I know the term FPGA was created by Actel's marketing people
but there were many programmable architectures around before the term
was coined.
- assuming you take the essential requirements of 'FPGA' as being general
purpose routing (not PAL like arrays) and electrical field reprogrammability
(i.e. not patch panels, laser cutting of links etc) then I'd recommend reading the   following
references and making your own mind up:

S.E. Wahlstrom 'Programmable Logic Arrays' Electronics Vol 40, No 25, Dec. 11 1967.

R.C. Minnick 'Survey of Microcellular Research', J. ACM, Vol 14, No. 2, April 1967.

Note, before I get flamed I am not claiming that either of these are definitively
the first paper about FPGA's.  The first document on the modern FPGA is probably
the famous Freeman patent US 4,870,302 (re-issued as Re. 34,363).

Tom Kean.

Tom
> Thanks in advance,
>
> -Arrigo
> --
> Dr. Arrigo Benedetti                e-mail: arrigo@vision.caltech.edu
> Caltech, MS 136-93                              phone: (626) 395-3695
> Pasadena, CA 91125                              fax:   (626) 795-8649
--------------BB51596145F9BE5180CC1A9E
Content-Type: text/x-vcard; charset=us-ascii;
name="tom.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Tom Kean
Content-Disposition: attachment;
filename="tom.vcf"

begin:vcard
n:Kean;Tom
tel;fax:UK +44 131 556 9247
tel;work:UK +44 131 556 9242
x-mozilla-html:TRUE
org:Algotronix Ltd.
adr:;;P.O. Box 23116;Edinburgh;;EH8 8YB;Scotland
version:2.1
email;internet:tom@algotronix.com
title:Director
note:Web Site: www.algotronix.com
x-mozilla-cpt:;4768
fn:Tom Kean
end:vcard

--------------BB51596145F9BE5180CC1A9E--


Article: 18553
Subject: Re: Comparison between Altera and Xilinx
From: martin@the-thompsons.freeserve.co.uk
Date: Sat, 30 Oct 1999 15:57:02 GMT
Links: << >>  << T >>  << A >>
If I can put a different point of view.

I'm new to the game, but I just implemented a signal processing type
design, which I wrote as 'behavioural-ish' (ie not aimed directly at
being synthesisable) VHDL.  It isn't huge, but it has a collection of
multipliers/adders/comparators.  I thought I'd just see how far off a
usefully synthesizable design it was so I ran it through FPGA Express.

It runs at 4MHz in a Virtex, and 14MHz in Flex10K (and 7MHz in a
Flex6016 - just to see).  4MHz is just fast enough, but the Altera
device gives me plenty of spare time to play with.  The big plus for
me is that I can get the performance I want without having to mess
around hand-tuning the algorithm to the architecture, and at the
moment, all I'm (or my boss is :-) looking for it proof of concept.

It appears from what I've gathered so far - and as I say I am new to
this - that Xilinx will perform better, given the up front investment.
However, the Altera devices may well perform *well enough* straight
out of the box with very 'ordinary' VHDL.

So there's another view: The choice may depend on how much
time/inclination you have to tweak your implementation.

Which brings me to a question...  This design fits in a 10K20, which
is nominally a 20K gates device, so clearly its not a huge design.  Am
I going to find the Altera architecture limits me, and will also
require hand-tuning, as the design size goes up?

Martin

On Thu, 28 Oct 1999 10:45:39 -0400, Ray Andraka <randraka@ids.net>
wrote:

>Big architectural differences.  Which is best depends on your
>application.  For signal processing, Xilinx is a hands down winner.  For
>other apps, the Altera is better.  Look for my previous posts on this
>subject in deja-news for more details.
>
>Child K.L. Sun wrote:
>
>>         Have you tried both of the chips/software from these two
>>         companies?
>>         What's the difference between them?
>>
>>                                                         Child
>
>
>
>--
>-Ray Andraka, P.E.
>President, the Andraka Consulting Group, Inc.
>401/884-7930     Fax 401/884-7950
>email randraka@ids.net
>http://users.ids.net/~randraka
>
>

Martin Thompson
martin@the-thompsons.freeserve.co.uk
http://www.the-thompsons.freeserve.co.uk/

Article: 18554
Subject: Re: Comparison between Altera and Xilinx
From: Ray Andraka <randraka@ids.net>
Date: Sat, 30 Oct 1999 16:27:50 -0400
Links: << >>  << T >>  << A >>
At only 4 MHz, you are leaving alot of the FPGA's potential performance on
the table.   If your sample rate only needs 4 MHz, you ought to consider bit
serial design so that you can get into a smaller and cheaper part, for
example the Xilinx spartan series.  Bit serial hardware is typically about
1/nth the hardware for an n bit wide process, although it also requires an n
times bit clock.  you can use a hybrid digit-serial approach if the clock is
too high.

Altera does tend to do better with uninspired synthesis.  That is mostly a
consequence of the global routing structure which makes placement
considerably less critical than xilinx.  However, that is a double edged
sword: that same global routing limits how fast you can make a design go if
you are willing to put in the extra effort.  For signal processing
applications, Altera is handicapped by the carry arithmetic structure which
limits you to a two input arithmetic function in one level of logic (compared
to 3 inputs in Xilinx 4K and 4 inputs in Virtex).  That means an add/subtract
or accumulator with clear is forced to two levels of logic in ALtera.  Also,
and probably more significant, Xilinx lets you use the LUTs in the array as
RAM or as shift registers, so that a 16 clock by 1 bit delay fits into the
space of one LUT.  ALtera has nothing similar, so you wind up using an LE for
each clock delay for each bit.  It gets rather expensive when you are dealing
with word wide, multiple clock delay queues of the type you find frequently
in filters etc.

So, if your application uses delay queues or arithmetic with more than two
inputs, you are going to use up alot of your logic in ALtera, where you
wouldn't in xilinx.  Thus, you need a device with more "marketing gates" to
fulfill the same function.  Also, the inability to use the LUTs as RAM is a
handicap if you are doing adaptive filtering, as it keeps you out of some
significant algorithmic optizations.

For low data rate stuff, I would prefer to use a smaller device and go with a
bit serial or digit serial design to keep unit costs down.  The exception is
where the higher clock rates might cause you problems.  The extra design
effort required for that type of architectural optimization is pretty small.

martin@the-thompsons.freeserve.co.uk wrote:

> If I can put a different point of view.
>
> I'm new to the game, but I just implemented a signal processing type
> design, which I wrote as 'behavioural-ish' (ie not aimed directly at
> being synthesisable) VHDL.  It isn't huge, but it has a collection of
> multipliers/adders/comparators.  I thought I'd just see how far off a
> usefully synthesizable design it was so I ran it through FPGA Express.
>
> It runs at 4MHz in a Virtex, and 14MHz in Flex10K (and 7MHz in a
> Flex6016 - just to see).  4MHz is just fast enough, but the Altera
> device gives me plenty of spare time to play with.  The big plus for
> me is that I can get the performance I want without having to mess
> around hand-tuning the algorithm to the architecture, and at the
> moment, all I'm (or my boss is :-) looking for it proof of concept.
>
> It appears from what I've gathered so far - and as I say I am new to
> this - that Xilinx will perform better, given the up front investment.
> However, the Altera devices may well perform *well enough* straight
> out of the box with very 'ordinary' VHDL.
>
> So there's another view: The choice may depend on how much
> time/inclination you have to tweak your implementation.
>
> Which brings me to a question...  This design fits in a 10K20, which
> is nominally a 20K gates device, so clearly its not a huge design.  Am
> I going to find the Altera architecture limits me, and will also
> require hand-tuning, as the design size goes up?
>

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


Article: 18555
Subject: which Xilinx package for Virtex ?
From: muzo <muzok@nospam.pacbell.net>
Date: 30 Oct 1999 16:44:54 PDT
Links: << >>  << T >>  << A >>
hi,
I looked at Xilinx web page and the choices there confused me a little
bit. I am trying to decide on an FPGA family for a very aggresive DSP
design with Verilog. I already have synthesis and Altera P&R tools.
What is the least expensive package I can use from Xilinx to P&R the
output of the synthesis for Virtex(-E) and see the performance ? I
don't need to program any parts yet and I don't need any design entry
in the Xilinx tool. I need at least the 400K part.

thanks

muzo

Verilog, ASIC/FPGA and NT Driver Development Consulting (remove nospam from email)

Article: 18556
Subject: Re: Comparison between Altera and Xilinx
From: murray@pa.dec.com (Hal Murray)
Date: 31 Oct 1999 01:53:43 GMT
Links: << >>  << T >>  << A >>

Suppose I had a design that was written without any
particular hardware in mind.  Maybe it was written
by a software guy who didn't know about fan-in or routing.

How much can I gain in speed or density by rewriting
it to be more friendly to a paritcular architecture?

Are there a tricks that an experienced designer would
use from the beginning if he knew the target architecture?

Is there a list of that sort of tricks someplace?  Maybe
a web page for each architecture?  Or are they all so "obvious"
that nobody bothers to write them down?

How hard would it be to teach the compiler about those tricks?
Would hints from the programmer/designer help the compiler?
Or should it be able to figure all that out since it knows
all about the target architecture?

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


Article: 18557
Subject: VPR for FPGAs
From: G.S. Vigneault <z180@hotmail.DOT.com>
Date: Sun, 31 Oct 1999 01:38:21 -0400
Links: << >>  << T >>  << A >>
If you missed the article in the October 18, 1999, issue of the
Electronic Engineering Times (page 73) -- you can read about the
Versatile Placement and Routing (VPR) package for FPGAs, and
download the software (free for noncommercial use) at the University
of Toronto at http://www.eecg.toronto.edu/~vaughn/vpr/vpr.html

Greg_
October 31, 1999.

{}{}{} Posted via Uncensored-News.Com, http://www.uncensored-news.com {}{}{}
{}{}{}{} Only $8.95 A Month, - The Worlds Uncensored News Source {}{}{}{} {}{}{}{}{} Five News Servers with a BINARIES ONLY Server {}{}{}{}{}  Article: 18558 Subject: Re: Comparison between Altera and Xilinx From: martin@the-thompsons.freeserve.co.uk Date: Sun, 31 Oct 1999 14:00:33 GMT Links: << >> << T >> << A >> On Sat, 30 Oct 1999 16:27:50 -0400, Ray Andraka <randraka@ids.net> wrote: >At only 4 MHz, you are leaving alot of the FPGA's potential performance on >the table. If your sample rate only needs 4 MHz, you ought to consider bit >serial design so that you can get into a smaller and cheaper part, for >example the Xilinx spartan series. Bit serial hardware is typically about >1/nth the hardware for an n bit wide process, although it also requires an n >times bit clock. you can use a hybrid digit-serial approach if the clock is >too high. > My point was that smaller/cheaper is not the issue for me at the moment, once smaller/cheaper becomes important, we'll be in ASIC territory anyway. >Altera does tend to do better with uninspired synthesis. That is mostly a >consequence of the global routing structure which makes placement >considerably less critical than xilinx. However, that is a double edged >sword: that same global routing limits how fast you can make a design go if >you are willing to put in the extra effort. Presumably also a double edged sword in that if you can't/don't want to put in the extra effort it makes life harder in 'Xilinx-land' <snip lots of useful comparison of architectures> > >So, if your application uses delay queues or arithmetic with more than two >inputs, you are going to use up alot of your logic in ALtera, where you >wouldn't in xilinx. Thus, you need a device with more "marketing gates" to >fulfill the same function. Also, the inability to use the LUTs as RAM is a >handicap if you are doing adaptive filtering, as it keeps you out of some >significant algorithmic optizations. > I haven't looked hard enough at the architectures to work it out, but are they not both LUT based? What extras do the Xilinx arch. have that enables all these other features? And why aren't Altera interested in copying them :) >For low data rate stuff, I would prefer to use a smaller device and go with a >bit serial or digit serial design to keep unit costs down. The exception is >where the higher clock rates might cause you problems. The extra design >effort required for that type of architectural optimization is pretty small. > Again, units costs aren't really the issue, although if I can get an order of magnitude difference in price ... :) I have to say that I am torn, in that we already use Altera devices (7K's) for a number of applications, but everything I read here implies that we need to look at Xilinx for these new applications. Most of our applications so far have been glue-logic type things rather than arithmetic based work. My other problem is that I'm not au fait enough with either the Altera 10K's or the Xilinx devices to really know how far I could push my example design if I put the effort in (without actually doing it, which will involve a significant investment in terms of time and needing to buy Xilinx tools we may not need). Anyway, thanks for the input, Martin >martin@the-thompsons.freeserve.co.uk wrote: > >> If I can put a different point of view. >> >> I'm new to the game, but I just implemented a signal processing type >> design, which I wrote as 'behavioural-ish' (ie not aimed directly at >> being synthesisable) VHDL. It isn't huge, but it has a collection of >> multipliers/adders/comparators. I thought I'd just see how far off a >> usefully synthesizable design it was so I ran it through FPGA Express. >> >> It runs at 4MHz in a Virtex, and 14MHz in Flex10K (and 7MHz in a >> Flex6016 - just to see). 4MHz is just fast enough, but the Altera >> device gives me plenty of spare time to play with. The big plus for >> me is that I can get the performance I want without having to mess >> around hand-tuning the algorithm to the architecture, and at the >> moment, all I'm (or my boss is :-) looking for it proof of concept. >> >> It appears from what I've gathered so far - and as I say I am new to >> this - that Xilinx will perform better, given the up front investment. >> However, the Altera devices may well perform *well enough* straight >> out of the box with very 'ordinary' VHDL. >> >> So there's another view: The choice may depend on how much >> time/inclination you have to tweak your implementation. >> >> Which brings me to a question... This design fits in a 10K20, which >> is nominally a 20K gates device, so clearly its not a huge design. Am >> I going to find the Altera architecture limits me, and will also >> require hand-tuning, as the design size goes up? >> > > > >-- >-Ray Andraka, P.E. >President, the Andraka Consulting Group, Inc. >401/884-7930 Fax 401/884-7950 >email randraka@ids.net >http://users.ids.net/~randraka > > Martin Thompson martin@the-thompsons.freeserve.co.uk http://www.the-thompsons.freeserve.co.uk/  Article: 18559 Subject: Re: Comparison between Altera and Xilinx From: eml@riverside-machines.com.NOSPAM Date: Sun, 31 Oct 1999 17:19:36 GMT Links: << >> << T >> << A >> On Sun, 31 Oct 1999 14:00:33 GMT, martin@the-thompsons.freeserve.co.uk wrote: >My other problem is that I'm not au fait enough with either the Altera >10K's or the Xilinx devices to really know how far I could push my >example design if I put the effort in (without actually doing it, >which will involve a significant investment in terms of time and >needing to buy Xilinx tools we may not need). does this mean that you haven't got any xilinx tools? if so, how are you doing your performance comparisons - are you relying on figures reported by FPGA express? if you are: 1) forget it. you can't compare two designs unless they're both routed, and the vendor's timing analyser has given you a max frequency. it's not unusual to get at least a factor of two speed difference between the synth's estimate and the real device. 2) FPGA express seems to have been slow to catch up with virtex. i believe that you should be on v3.3 to get useful results. 3) i went through the 10k v. virtex exercise with a customer who was already using 10Ks, with no xilinx experience, about 9 months ago, for a DSP application. virtex was the no-brainer then, even though the virtex tools were poor at that stage. the altera FAE didn't even bother trying to change their minds. 20K vs. virtex might be a different matter, if it ever happens. evan  Article: 18560 Subject: Re: Xilinx TPSYNC constraint From: Phil Hays <spampostmaster@sprynet.com> Date: Sun, 31 Oct 1999 11:02:03 -0800 Links: << >> << T >> << A >> Andy Peters wrote: > I'm using an XC4KE part, I have a 32-bit bidirectional bus that comes out to > the pins and I'd like to constrain the tristate enable so that it's faster. > ... I have a signal called dataoe, which is a flip-flop output, and > that signal is used as the tri-state enable for the outputs, which are > called ramdata[31:0]. I have usually not had very good luck getting the Xilinx tools to improve timing in a case like this by adding timing constraints. What I would suggest is that you floorplan the dataoe flip-flop to the middle of the tristate bus. If that's not fast enough, you might duplicate the dataoe flip-flop and floorplan the copies. Another way would be to add a gclk buffer, floorplan it the buffer that gives the best drive to the data bus pins and floorplan the dataoe flip-flop to be in that corner of the die. -- Phil Hays "Irritatingly, science claims to set limits on what we can do, even in principle." Carl Sagan  Article: 18561 Subject: Re: Comparison between Altera and Xilinx From: Ray Andraka <randraka@ids.net> Date: Sun, 31 Oct 1999 15:30:12 -0500 Links: << >> << T >> << A >>  martin@the-thompsons.freeserve.co.uk wrote: > On Sat, 30 Oct 1999 16:27:50 -0400, Ray Andraka <randraka@ids.net> > wrote: > > >At only 4 MHz, you are leaving alot of the FPGA's potential performance on > >the table. If your sample rate only needs 4 MHz, you ought to consider bit > >serial design so that you can get into a smaller and cheaper part, for > >example the Xilinx spartan series. Bit serial hardware is typically about > >1/nth the hardware for an n bit wide process, although it also requires an n > >times bit clock. you can use a hybrid digit-serial approach if the clock is > >too high. > > > > My point was that smaller/cheaper is not the issue for me at the > moment, once smaller/cheaper becomes important, we'll be in ASIC > territory anyway. At the prices of the spartan devices, I think you may be pleasantly surprised as to the cost compared with an ASIC. At under$10 in quantity, it requires a fairly
large production run with an ASIC to break even.  Nice thing with an FPGA solution
is that is a lot easier and cheaper to make changes later if you need/want to.

>
>
> >Altera does tend to do better with uninspired synthesis.  That is mostly a
> >consequence of the global routing structure which makes placement
> >considerably less critical than xilinx.  However, that is a double edged
> >sword: that same global routing limits how fast you can make a design go if
> >you are willing to put in the extra effort.
>
> Presumably also a double edged sword in that if you can't/don't want
> to put in the extra effort it makes life harder in 'Xilinx-land'

As always. It depends.

> <snip lots of useful comparison of architectures>
> >
> >So, if your application uses delay queues or arithmetic with more than two
> >inputs, you are going to use up alot of your logic in ALtera, where you
> >wouldn't in xilinx.  Thus, you need a device with more "marketing gates" to
> >fulfill the same function.  Also, the inability to use the LUTs as RAM is a
> >handicap if you are doing adaptive filtering, as it keeps you out of some
> >significant algorithmic optizations.
> >
>
> I haven't looked hard enough at the architectures to work it out, but
> are they not both LUT based?  What extras do the Xilinx arch. have
> that enables all these other features?  And why aren't Altera
> interested in copying them :)

They are both LUT based, but the xilinx devices allow you to use the LUT as a 16x1
RAM (ie you can change the LUT contents from within the FPGA).  That feature,
which xilinx holds a patent on, allows you to use the LUT as a 16 bit shift
register or as re-writable lookups.  There is nothing equivalent in Altera.  Most
DSP applications have filtering or something similar going on, which in turn
implies the fairly extensive use of delay queues.  The xilinx LUT ram capability
gives you a compact way of doing the delays, where Altera uses up an LE for each
clock delay on each bit.

For arithmetic circuits, the altera breaks the 4 input LUT into a pair of 3 input
LUTs, one for the carry function and one for the 'sum' function.  That means if
your arithmetic function is more than 2 inputs (an adder-subtractor or an
accumulator with clear for example), the altera design is forced to a second level
of logic (slower and twice the area).  The xilinx carry chain uses additional
dedicated logic, which in the case of the 4K/spartan architecture is in front of
the 4 input LUT.  That leaves you with a 4 input function at each bit whether or
not the carry is used.  Thus you can realize a 3 input arithmetic function (like
ALtera, one input is used for the carry in) in one level of logic.  Xilinx Virtex
puts the dedicated carry logic after the LUT, so the carry in does not feed the
LUT.  In that case you can have arithmetic functions with four inputs.
Additionally, if you need to use a clock enable, the Altera architecture (10K, not
Apex), steals one of the LUT inputs for the clock enable, which reduces the
effective size of a LUT to 3 input or in the case of an arithmetic function a one
input arithmetic function (let's see - that would be a 2's complement or add a
fixed number and not much else).  The Xilinx clock enable does not steal a LUT
input, so there is no logic penalty for using it.

An efficient method for filtering is distributed arithmetic, which essentially
puts all the possible 1xn sums for a 4 tap filter into a look-up table.  That way
you get a serial 4 tap filter in n LUTs (n is the width of your coefficient plus 2
bits).  You can combine them both for longer filters and for processing more than
one bit of the input per clock.  See the latest paper on my website (FPGAs make
radar signal processor on a chip a reality) for more detail about how that is
done.  This same method could be used in adaptive filters if you could reprogram
the LUTs to change the coefficients on demand.  The xilinx architecture gives you
a method to do this since you can use the LUTs as RAM.

> >For low data rate stuff, I would prefer to use a smaller device and go with a
> >bit serial or digit serial design to keep unit costs down.  The exception is
> >where the higher clock rates might cause you problems.  The extra design
> >effort required for that type of architectural optimization is pretty small.
> >
>
> Again, units costs aren't really the issue, although if I can get an
> order of magnitude difference in price ... :)
>

I think you're close to an order of magnitude in required area.  The pricing at
the lower end is a little compressed, but I think you'll still see a half a
magnitude price reduction.  Again, we're not talking an absolutely tailored design
here, just a change from a bit-parallel to a bit serial solution.

> I have to say that I am torn, in that we already use Altera devices
> (7K's) for a number of applications, but everything I read here
> implies that we need to look at Xilinx for these new applications.
> Most of our applications so far have been glue-logic type things
> rather than arithmetic based work.

Ownership and familiarity of a particular vendor's tool set is a compelling reason
to stay with that vendor.  Unless you find yourself hitting the wall because of
architectural differences, I'd probably stick with the Altera if I were in your
shoes (without knowing much about your design).  On the other hand, you should at
least be aware of what can be done in other architectures so that you have an idea
of how much the altera solution is costing you in your system context.  Also, it
might be worth comparing the cost of ownership of the Xilinx Spartan chips with an
Asic for your application.

>
>
> My other problem is that I'm not au fait enough with either the Altera
> 10K's or the Xilinx devices to really know how far I could push my
> example design if I put the effort in (without actually doing it,
> which will involve a significant investment in terms of time and
> needing to buy Xilinx tools we may not need).
>
> Anyway, thanks for the input,
>         Martin
>
> >martin@the-thompsons.freeserve.co.uk wrote:
> >
> >> If I can put a different point of view.
> >>
> >> I'm new to the game, but I just implemented a signal processing type
> >> design, which I wrote as 'behavioural-ish' (ie not aimed directly at
> >> being synthesisable) VHDL.  It isn't huge, but it has a collection of
> >> multipliers/adders/comparators.  I thought I'd just see how far off a
> >> usefully synthesizable design it was so I ran it through FPGA Express.
> >>
> >> It runs at 4MHz in a Virtex, and 14MHz in Flex10K (and 7MHz in a
> >> Flex6016 - just to see).  4MHz is just fast enough, but the Altera
> >> device gives me plenty of spare time to play with.  The big plus for
> >> me is that I can get the performance I want without having to mess
> >> around hand-tuning the algorithm to the architecture, and at the
> >> moment, all I'm (or my boss is :-) looking for it proof of concept.
> >>
> >> It appears from what I've gathered so far - and as I say I am new to
> >> this - that Xilinx will perform better, given the up front investment.
> >> However, the Altera devices may well perform *well enough* straight
> >> out of the box with very 'ordinary' VHDL.
> >>
> >> So there's another view: The choice may depend on how much
> >> time/inclination you have to tweak your implementation.
> >>
> >> Which brings me to a question...  This design fits in a 10K20, which
> >> is nominally a 20K gates device, so clearly its not a huge design.  Am
> >> I going to find the Altera architecture limits me, and will also
> >> require hand-tuning, as the design size goes up?
> >>
> >
> >
> >
> >--
> >-Ray Andraka, P.E.
> >President, the Andraka Consulting Group, Inc.
> >401/884-7930     Fax 401/884-7950
> >email randraka@ids.net
> >http://users.ids.net/~randraka
> >
> >
>
> Martin Thompson
> martin@the-thompsons.freeserve.co.uk
> http://www.the-thompsons.freeserve.co.uk/

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


Article: 18562
Subject: Re: Xilinx TPSYNC constraint
From: Rickman <spamgoeshere4@yahoo.com>
Date: Sun, 31 Oct 1999 16:39:00 -0500
Links: << >>  << T >>  << A >>
To be honest, I find the whole constraint thing to be very, very
confusing. I think that the way they are set up and more so the way they
are documented makes them very, very hard to understand. I find this
doubly painful when it seems that the concept of constraints is so
simple.

But now that my beef is out of the way I will say that I have dealt with
this sort of thing using the OFFSET command. In my last Xilinx design
(which is starting to grow whiskers) I had a clock, LCLK and a bidir bus
LAD. I spec'ed using the statements below to assure that the outputs
were stable 5 nS before the rising edge of LCLK and could tolerate
changes on LAD up to 20 nS after LCLK. I did it this way because it
seemed easier to relate these numbers to the devices I was connecting to
(setup = 5 nS and output delay = 20 nS).

NET LAD<*   OFFSET = IN  20   AFTER  LCLK;
NET LAD<*   OFFSET = OUT  5   BEFORE LCLK;

To the best of my knowledge this also took into account the path through
the enable on the tristate buffers. I did not need to place any special
constraints on that signal.

The data book does not show OFFSET being used with IN and AFTER or OUT
and BEFORE. Rather they show them used in the opposite combination. But
this did what I wanted and seemed to work.

Andy Peters wrote:
>
> I'm using an XC4KE part, I have a 32-bit bidirectional bus that comes out to
> the pins and I'd like to constrain the tristate enable so that it's faster.
>
> There's a constraint called TPSYNC, which "allows defintion of synchronous
> points that are <i>not</i> FFS, RAMS, PADS or LATCHES" and they are
> "commonly used with three-state buffers."
>
> The example given in the Xilinx "timing and constraints" presentation is a
> bit weak.   I have a signal called dataoe, which is a flip-flop output, and
> that signal is used as the tri-state enable for the outputs, which are
> called ramdata[31:0].  Any hints as to how to write this constraint?  Assume
> that I want to constrain it to be 10 ns.
>
> thanx,
>
> a
>
> --
> -----------------------------------------
> Andy Peters
> Sr Electrical Engineer
> National Optical Astronomy Observatories
> 950 N Cherry Ave
> Tucson, AZ 85719
> apeters (at) noao \dot\ edu
>
> "Creation Science" is oxymoronic.

--

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com

Article: 18563
Subject: Re: Comparison between Altera and Xilinx
From: murray@pa.dec.com (Hal Murray)
Date: 1 Nov 1999 01:01:54 GMT
Links: << >>  << T >>  << A >>

[snip bit-serial suggestions]

> My point was that smaller/cheaper is not the issue for me at the
> moment, once smaller/cheaper becomes important, we'll be in ASIC
> territory anyway.

Won't the same techniques help you get a smaller/cheaper ASIC?

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


Article: 18564
Subject: Re: Announcing Free VHDL Simulator for Windows
From: "Haneef D. Mohammed" <haneef@mindspring.com>
Date: Sun, 31 Oct 1999 20:51:53 -0800
Links: << >>  << T >>  << A >>
An update is now available for download
at www.symphonyeda.com that fixes this problem.
The fix is contained in Build#11

Thanx
Haneef

Allan Herriman <allan.herriman.hates.spam@fujitsu.com.au> wrote in message
news:3816b2cb.1582367@newshost.fujitsu.com.au...
> On Sat, 23 Oct 1999 10:19:41 -0700, "Haneef D. Mohammed"
> <haneef@mindspring.com> wrote:
>
>
> I tried it on an old project (which I had previously compiled with a
> few different tools), and it gave an internal error on the very first
> file I tried to compile.
>
> >vhdlp ..\src\ex_1164\ex_1164.vhd
> Symphony EDA (R) VHDL Compiler/Simulator Module VhdlP, Version 1.4,
> Build#10.
> Copyright(C) Symphony EDA 1997-1999. All rights reserved.
> Reading C:\Program Files\Symphony EDA\VHDL Simili\bin\symphony.ini ...
> Library 'ieee'          ==> $SYMPHONY/Lib/Ieee/Ieee.sym > Library 'work' ==> work.sym > Reading$SYMPHONY\Lib\Ieee\Ieee.sym\std_logic_1164\std_logic_1164.var
> Parsing Package:exemplar_1164 @ line ..\src\ex_1164\ex_1164.vhd:31
> Writing  work.sym\exemplar_1164\exemplar_1164.var
> Parsing Package Body:exemplar_1164 @ line
> .\src\ex_1164\ex_1164.vhd:297
> Internal Error: D:\home\proj\SimVHDL\VhdlExpr\CSTypeConversion.cpp:
> (line 79): E
> xpecting Aggregate here
>
> And the source around line 297 was:
>
> 290: signal q : out std_ulogic_vector);
> 291:
> 292:end exemplar_1164;
> 293:
> 294:library ieee ;
> 295:use ieee.std_logic_1164.all ;
> 296:
> 297:package body exemplar_1164 is
> 298:
> 299: ---
>
>
> Any idea what is wrong?
>
> Regards,
> Allan.


Article: 18565
Subject: Inkjets 4 you!
From: aoui0r93809@asadszlkjaslkjz.net
Date: Mon, 01 Nov 1999 06:38:34 GMT
Links: << >>  << T >>  << A >>
				The Inkjet Company has the following inkjet specials:
All Prices Include Free Shipping and Free Sales Tax

EPSON

Epson -  $8.00 - Black or 10 for$65.00 - All Models*
Epson -  $12.00 - Color or 10 for$100.00 - All Models*
*Epson - $16.00 - Black or 10 for$135.00 - 900/3000
*Epson - $19.00 - Color or 10 for$165.00 - 750/900/1200/3000

CANON

Canon BCI-21B - $5.00 - Black BJC-2500/4000/4400/5000 Canon BCI-21C -$8.00 - Color BJC-2500/4000/4400/5000
Canon BC-20 - $18.00 - Black BJC-2500/4000/4300/4400/ Canon BC-02 -$16.50 - Black BJC-210/230/BJ-200
Canon BC-05 - $28.00 - Tri-Color BJC-210/240 Canon BX-3 -$28.00 - Black B-540/550/640

(See Below For Apple & H.P. Products)

The Inkjet Company

1-310-517-9999
1-503-905-6652 Fax

APPLE

M8041G/C - $17.00 - Black Styler Writer 1500 M4609G/C -$30.00 - Tri-Color Styler Writer 1500
M3240G/A - $19.00 - Large "Double" Black Style Writer 2400 M3330G/A -$5.00 - Black Style Writer 2400
M3329G/A - $9.00 - Tri-Color Style Writer 2400 M1949G/A -$3.75 - Cyan Color Style Writer Pro
M1950G/A - $3.75 - Magenta Color Style Writer Pro M1951G/A -$3.75 - Yellow Color Style Writer Pro
M1952G/A - $3.75 - Black High Capcity Color Style Writer Pro HEWLETT PACKARD 51625A -$19.00 - Tri-Color Deskjet 500c/550 Series
51626A - $16.50 - Black Deskjet Series / OfficeJet 300 / HP Fax 51629A -$16.50 - Black Deskjet 600 Series / OfficeJet 500 Series
51649A - $19.00 - Tri-Color Deskjet 600 Series / OfficeJet 500 Series 51645A -$16.50 - Black Deskjet 700/800/1000/1600
51640A - $16.50 - Black Deskjet 1200 / CopyJet The Inkjet Company 1-310-517-9999 1-503-905-6652 Fax Visa, Mastercard, Amex, Discover Fast Free Delivery - usually in two days or less!  Article: 18566 Subject: Altera Reset Strategy? From: Gary Cook <gc@sonyoxford.co.uk> Date: Mon, 01 Nov 1999 09:38:31 +0000 Links: << >> << T >> << A >> Hi, Using a Flex10K and have some code which has a bunch of FF's that reset, and a few that preset. Now I understand that the Flex will power up it's FF's in a low state, and it's up to a reset input to perform a functional reset once the device has configured. I also have a processor connected to the device and want to hold it in reset until the FPGA has configured. I have looked at using either INIT_DONE or CONF_DONE, but one de-actives before the end of config, and the other is inactive for a period at the start of config. I could also set a pin on the FPGA permanently high in the verilog, and us a pull-down externally so that during configuration it goes low, and when the user i/o is enabled, it gets driven high ... this could be my processor reset. I then connect a separate reset line from the processor to the fpga as the functional reset .... ... sounds abit clunky though ... is there a more elegant way of doing this? Thanks, Gary Cook, Sony Oxford, UK.  Article: 18567 Subject: 16 bit counter in Abel From: "Luigi Funes" <fuzzy8888@hotmail.com> Date: Mon, 1 Nov 1999 12:20:56 +0100 Links: << >> << T >> << A >> I have a problem with Lattice ispExpert 7.1. I wrote this very simple 16 bit counter in ABEL-HDL MODULE counter16 count0..count15 pin istype 'reg'; countck pin; EQUATIONS [count0..count15].clk = countck; [count0..count15] := [count0..count15] + 1; END Someone can explain me why it requires 18 macrocells instead 16? I have to set some option in the compiler? Besides, if I write [count0..count15] := [count0..count15] + extpin; where extpin is a input pin assuming 0 or 1 values, this requires only 17 macrocells!!! Thanks in advance. Luigi  Article: 18568 Subject: *Latest Inkjetz for Sale* From: 304830983@098340938.org Date: Mon, 01 Nov 1999 11:29:21 GMT Links: << >> << T >> << A >>  The Inkjet Company has the following inkjet specials: All Prices Include Free Shipping and Free Sales Tax EPSON Epson -$8.00 - Black  or 10 for $65.00 - All Models* Epson -$12.00 - Color or 10 for $100.00 - All Models* *Epson -$16.00 - Black or 10 for $135.00 - 900/3000 *Epson -$19.00 - Color or 10 for $165.00 - 750/900/1200/3000 CANON Canon BCI-21B -$5.00 - Black BJC-2500/4000/4400/5000
Canon BCI-21C - $8.00 - Color BJC-2500/4000/4400/5000 Canon BC-20 -$18.00 - Black BJC-2500/4000/4300/4400/
Canon BC-02 - $16.50 - Black BJC-210/230/BJ-200 Canon BC-05 -$28.00 - Tri-Color BJC-210/240
Canon BX-3 - $28.00 - Black B-540/550/640 (See Below For Apple & H.P. Products) The Inkjet Company 1-310-517-9999 1-503-905-6652 Fax APPLE M8041G/C -$17.00 - Black Styler Writer 1500
M4609G/C - $30.00 - Tri-Color Styler Writer 1500 M3240G/A -$19.00 - Large "Double" Black Style Writer 2400
M3330G/A - $5.00 - Black Style Writer 2400 M3329G/A -$9.00 - Tri-Color Style Writer 2400
M1949G/A - $3.75 - Cyan Color Style Writer Pro M1950G/A -$3.75 - Magenta Color Style Writer Pro
M1951G/A - $3.75 - Yellow Color Style Writer Pro M1952G/A -$3.75 - Black High Capcity Color Style Writer Pro

HEWLETT PACKARD

51625A - $19.00 - Tri-Color Deskjet 500c/550 Series 51626A -$16.50 - Black Deskjet Series / OfficeJet 300 / HP Fax
51629A - $16.50 - Black Deskjet 600 Series / OfficeJet 500 Series 51649A -$19.00 - Tri-Color Deskjet 600 Series / OfficeJet 500 Series
51645A - $16.50 - Black Deskjet 700/800/1000/1600 51640A -$16.50 - Black Deskjet 1200 / CopyJet

The Inkjet Company

1-310-517-9999
1-503-905-6652 Fax

Visa, Mastercard, Amex, Discover
Fast Free Delivery - usually in two days or less!

Article: 18569
Subject: Virtex hardware debugging - help needed
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Mon, 01 Nov 1999 13:02:48 +0000
Links: << >>  << T >>  << A >>
Can anybody tell me how to do capture and readback though a Virtex's
JTAG port ? As far as I can see this is possible but is not supported by
either the Xilinx JTAG programmer or the H/W debugger. I don't have
access to the SelectMAP port so I probably need some s/w to drive the
JTAG port via e.g a parallel cable. I'm also very confused as to how to
define and get at the user definable internal scan chains.

One possible route seems to be through the JAVA based B-scan API.
Anybody tried this ?


Article: 18570
Subject: Re: Xilinx TPSYNC constraint
From: "Andrey Ushenin" <uab@novsu.ac.ru>
Date: Mon, 1 Nov 1999 17:21:53 +0300
Links: << >>  << T >>  << A >>
Hi Andy,

try to write in the your ucf file something like this:

NET ramdata(*  TPSYNC=TRI_STATE_OUTPUTS;
TIMESPEC TS_OE_signal=FROM:FFS(dataoe):TO:TRI_STATE_OUTPUTS=10ns;

It will constrain path time from OE signal driver to your tri-state bus
outputs. If you want constrain path time from dataoe flip-flop to output
enable pin of OBUFE then you shoul attach TPSYNC attribute on these pins
directly.
Hope it will be small help for you.

Andrey Ushenin,
--------------------------
DSP laboratory,
Novgorod State University,
Russia

Andy Peters <apeters.nospam@nospam.noao.edu.nospam> wrote in message
news:7vdc8m$1uij$1@noao.edu...
> I'm using an XC4KE part, I have a 32-bit bidirectional bus that comes out
to
> the pins and I'd like to constrain the tristate enable so that it's
faster.
>
> There's a constraint called TPSYNC, which "allows defintion of synchronous
> points that are <i>not</i> FFS, RAMS, PADS or LATCHES" and they are
> "commonly used with three-state buffers."
>
> The example given in the Xilinx "timing and constraints" presentation is a
> bit weak.   I have a signal called dataoe, which is a flip-flop output,
and
> that signal is used as the tri-state enable for the outputs, which are
> called ramdata[31:0].  Any hints as to how to write this constraint?
Assume
> that I want to constrain it to be 10 ns.
>
> thanx,
>
> a
>
> --
> -----------------------------------------
> Andy Peters
> Sr Electrical Engineer
> National Optical Astronomy Observatories
> 950 N Cherry Ave
> Tucson, AZ 85719
> apeters (at) noao \dot\ edu
>
> "Creation Science" is oxymoronic.
>
>


Article: 18571
Subject: Re: Announcing Free VHDL Simulator for Windows
From: allan.herriman.hates.spam@fujitsu.com.au (Allan Herriman)
Date: Mon, 01 Nov 1999 15:46:01 GMT
Links: << >>  << T >>  << A >>
On Sun, 31 Oct 1999 20:51:53 -0800, "Haneef D. Mohammed"
<haneef@mindspring.com> wrote:

>An update is now available for download
>at www.symphonyeda.com that fixes this problem.
>The fix is contained in Build#11

Thanks, it fixed that bug, but now there's another...

BTW, int2evec returns a 32 element slv if the second argument isn't
given.
(This is based on old code.  I wouldn't use this function now.)

library  ieee;
use  ieee.std_logic_1164.all;

library work;
use work.exemplar_1164.all;  -- you already have this

entity foobar is
end foobar;

architecture snafu of foobar is

signal  foo : std_logic_vector(7 downto 0);
signal bar : integer;

begin

foo <= int2evec(bar, 8);  -- this line is ok

foo <= int2evec(bar)(7 downto 0);  -- this line gives an error

end snafu;

C:\>vhdlp tmp.vhd
Symphony EDA (R) VHDL Compiler/Simulator Module VhdlP, Version 1.4,
Build#11.
Copyright(C) Symphony EDA 1997-1999. All rights reserved.
Reading C:\tools\Symphony EDA\VHDL Simili\bin\symphony.ini ...
Library 'ieee'          ==> $SYMPHONY/Lib/Ieee/Ieee.sym Library 'work' ==> work.sym Reading$SYMPHONY\Lib\Ieee\Ieee.sym\std_logic_1164\std_logic_1164.var
Reading  work.sym\exemplar_1164\exemplar_1164.var
Parsing Entity:foobar @ line tmp.vhd:8
Writing  work.sym\foobar\foobar.var
Parsing Architecture:foobar(snafu) @ line tmp.vhd:11
Error: CSVHDL0149: tmp.vhd: (line 20): Bad assignment. Expression on
RHS is not
of type ''std_logic_vector(7 DOWNTO 0)''
Errors: 1, Warnings: 0, Elapsed Time: 00h:00m:00s:736ms

C:\>

FYI,
Allan.


Article: 18572
Subject: Re: Xilinx TPSYNC constraint
From: "Andy Peters" <apeters.nospam@nospam.noao.edu.nospam>
Date: Mon, 1 Nov 1999 10:07:28 -0700
Links: << >>  << T >>  << A >>
Phil Hays wrote in message <381C922B.3603C633@sprynet.com>...
>Andy Peters wrote:
>
>> I'm using an XC4KE part, I have a 32-bit bidirectional bus that comes out
to
>> the pins and I'd like to constrain the tristate enable so that it's
faster.
>> ...  I have a signal called dataoe, which is a flip-flop output, and
>> that signal is used as the tri-state enable for the outputs, which are
>> called ramdata[31:0].
>
>I have usually not had very good luck getting the Xilinx tools to improve
timing
>in a case like this by adding timing constraints.  What I would suggest is
that
>you floorplan the dataoe flip-flop to the middle of the tristate bus.  If
that's
>not fast enough, you might duplicate the dataoe flip-flop and floorplan the
>copies.  Another way would be to add a gclk buffer, floorplan it the buffer
that
>gives the best drive to the data bus pins and floorplan the dataoe
flip-flop to
>be in that corner of the die.

Unfortunately, the pins are fixed, but I'll try floorplanning the dataoe
flop as you say.

I added a BUFGS to dataoe, and for some reason, it got slower!  i think I
screwed something up, though, since it was 6:30 pm on a Friday...

-- a
-----------------------------------------
Andy Peters
Sr Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) noao \dot\ edu

"Creation Science" is oxymoronic.


Article: 18573
Subject: Roots of development of FPGA's
From: project <projectdspNOprSPAM@yahoo.com.invalid>
Date: Mon, 01 Nov 1999 09:12:23 -0800
Links: << >>  << T >>  << A >>
Where can I find information about the roots of development
of FPGA's and evolution untill nowadays? Diferences between
others systems? ....

* Sent from AltaVista http://www.altavista.com Where you can also find related Web Pages, Images, Audios, Videos, News, and Shopping.  Smart is Beautiful

Article: 18574
Subject: Re: Xilinx TPSYNC constraint
From: "Andy Peters" <apeters.nospam@nospam.noao.edu.nospam>
Date: Mon, 1 Nov 1999 10:26:40 -0700
Links: << >>  << T >>  << A >>
Rickman wrote in message <381CB6F4.1F6908AF@yahoo.com>...
>To be honest, I find the whole constraint thing to be very, very
>confusing. I think that the way they are set up and more so the way they
>are documented makes them very, very hard to understand. I find this
>doubly painful when it seems that the concept of constraints is so
>simple.

and the constraints editor GUI, which is supposed to make life easier, still
has problems: it dies with an access fault every time you exit, it screws up
the text file so you any kind of neat ordering you'd created gets blown
away, and it doesn't have a way to add all the possible constraints.  I've
stopped using it.

>But now that my beef is out of the way I will say that I have dealt with
>this sort of thing using the OFFSET command. In my last Xilinx design
>(which is starting to grow whiskers) I had a clock, LCLK and a bidir bus
>LAD. I spec'ed using the statements below to assure that the outputs
>were stable 5 nS before the rising edge of LCLK and could tolerate
>changes on LAD up to 20 nS after LCLK. I did it this way because it
>seemed easier to relate these numbers to the devices I was connecting to
>(setup = 5 nS and output delay = 20 nS).
>
>NET LAD<*   OFFSET = IN  20   AFTER  LCLK;
>NET LAD<*   OFFSET = OUT  5   BEFORE LCLK;
>
>To the best of my knowledge this also took into account the path through
>the enable on the tristate buffers. I did not need to place any special
>constraints on that signal.
>
>The data book does not show OFFSET being used with IN and AFTER or OUT
>and BEFORE. Rather they show them used in the opposite combination. But
>this did what I wanted and seemed to work.

OFFSET IN assumes that the FPGA is getting data from an upstream device.
OFFSET IN BEFORE specifies that the data will be valid at the FPGA input
pins x ns before the clock arrives AT THE FPGA.
OFFSET IN AFTER specifies that the data will be valid at the FPGA input pins
x ns AFTER the clock arrives at the UPSTREAM DEVICE.

OFFSET IN AFTER is probably more useful.  If your FPGA is driven by an octal
flipflop with a clock-to-out time of 5 ns, all you need to do is specify

NET din OFFSET = IN 5 ns AFTER clock;

and the tools should (hopefully) take care of the rest.

OFFSET OUT is similar, 'cept that the FPGA is the data source, rather than
the sync.
OFFSET OUT AFTER specifies that the data will be valid at the FPGA OUTPUT x
ns AFTER the clock arrives at the FPGA INPUT.
OFFSET OUT BEFORE specifies that the data will be valid AT THE FPGA OUTPUT x
ns BEFORE the clock arrives at the DATA SINK (upstream device).

OFFSET OUT BEFORE would be used to specify a setup time for the data sink
(you need to include any board delay).
OFFSET OUT AFTER would be used to constrain the FPGA outputs to get the data
out in a certain time, but you have to make sure that you're still meeting
the data sink's setup requirements.

hope this helps...

-- a
-----------------------------------------
Andy Peters
Sr Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) noao \dot\ edu

"Creation Science" is oxymoronic.



Threads starting:
 1994 Jul Aug Sep Oct Nov Dec 1994 1995 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1995 1996 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1996 1997 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1997 1998 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1998 1999 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1999 2000 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2000 2001 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2001 2002 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2002 2003 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2003 2004 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2004 2005 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2005 2006 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2006 2007 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2007 2008 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2008 2009 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2009 2010 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2010 2011 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2011 2012 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2012 2013 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2013 2014 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2014 2015 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2015 2016 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2016 2017 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2017 2018 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2018 2019 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2019 2020 Jan Feb Mar Apr May 2020

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