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 22750

Article: 22750
Subject: Re: US-IL-In desperate need of FPGA engineer
From: Ray Andraka <ray@andraka.com>
Date: Mon, 22 May 2000 22:49:04 GMT
Links: << >>  << T >>  << A >>
Good luck!  Good FPGA designers for permanent positions seem to be scarcer than
hen's teeth right now.

"Technisource Inc." wrote:

> Hi Everyone,
>     I don't mean to interrupt, but I know that you are all experts in
> digital design and I would like to ask for a little of your help.  I
> currently have a couple of openings for a FPGA designer for a company in the
> suburbs of Chicago.  This position is looking for someone to do the design,
> simulation and timing of a digital design, a FPGA with a high number of
> gates, approaching 1 million.
>     I would appreciate it if you would help me in any way in filling these
> positions.  We currently have 3 available so if you know of anyone that
> or at 1-800-330-3308 et 209.  Also, any help in other places to look for
> qualified individuals would be appreciated.
>     Once again, I apologize for the interruption, but this is a great
> opportunity with a growing company.  Thank you all for your time.
>
> Erin Nolan
> Technisource
> enolan@tsrc.net
> 800-330-3308 ext 209

--

-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com  or http://www.fpga-guru.com


Article: 22751
Subject: Re: Xilinx tools
From: "Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam>
Date: Mon, 22 May 2000 17:28:43 -0700
Links: << >>  << T >>  << A >>
Rickman wrote in message <3929635C.6FAFE01C@yahoo.com>...
>I was just looking at the Xilinx web site to get info on their current
>tools and I now see that they no longer sell the tools. Rather Xilinx
>rents the tools to you for 1 year at a time. At the end of the year you
>can no longer use the tool for new designs.
>
>I have heard of some of the ASIC tool vendors doing this as a means to
>enhance their revenue. They are constantly trying to adjust their
>business model to maximize revenue since this is what they make money
>on.
>
>So now it looks like Xilinx is not happy with customers buying a given
>version of the tools and using that one version for new designs as long
>as they are happy with the known bugs in it. After a year, the tools
>will no longer let you start any new designs unless you pay the licence
>fee again.
>
>I don't get it. Xilinx keeps telling us that they want to make money
>from their chips and not the software. But this sure looks to me like
>they are trying to maximize the revenue from the tool sets.
>

I had to root around their website to find this little detail, since it's
not in any of the materials that Xilinx sent along with the initial release
of 2.1i.

quoting the blurb on the web page (that I can't link to because they use
Intershop's storefront cgi crap) (question: am I violating a copyright here,
much like the slashdot guys did by posting microsoft stuff?):

_____________________________________________________________
Introducing Time-Based Licensing

As of version 2.1i, Xilinx time-based licensing is in effect for all Xilinx
sold software solutions. This
includes all configurations of the Xilinx Alliance Series, Xilinx
Foundation Series and ModelSim
Xilinx Edition (XE) software products.

A Time-Based License is a 1-year license to use the software for building
new designs. At the end
of the 1-year license, the user can purchase a 1-year “extension”. The
1-year extension is offered
at the same price as the initial 1-year license. If the user of the
software does not purchase the
extension, he can still use the then-current version of the software to:

Finish any designs that were started while the 1-year license was in
effect
Fix any bugs in designs that were started while the 1-year license was
in effect

However, the time-based license does not allow a user to start a new design
after the initial 1-year
_____________________________________________________________

"The 1-year extension is offered at the same price as the initial 1-year

That means that we actually ARE buying a new copy of the software every
year, rather than paying a "maintenance" fee (of what, 50%?).

Funny.  I think we were sent a bill for maintenance.  It didn't say that we

"Finish any designs that were started while the 1-year license was in effect
Fix any bugs in designs that were started while the 1-year license was in
effect"

So, who's to know if, in fact, I start a new design after the first year?
What if I write three dozen top-level bits of VHDL this month that (vaguely)
describe the pin-outs of three dozen chips?  Have I "started" those designs,
even though there's no way I could do three dozen designs in a year?  So, if
it takes me three dozen years to do these three dozen designs, I don't have
to pay for the software for the next thirty-six years?

Less glibly, what counts as a "design"?  My current project has three FPGAs
on it.  does that count as one design, or three?  What happens when the
parts I've chosen (xilinx or otherwise) get obsoleted and the board has to
be revved in a year and a half?  Is the design considered done, or is this
rework that counts as the first design?

"However, the time-based license does not allow a user to start a new design
after the initial 1-year license has expired."

What mechanism prevents me from starting a new design after the first year?

What happens when the machine I'm designing on gets upgraded/replaced with
something else?

Who comes up with these licensing schemes, anyways?

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

"A sufficiently advanced technology is indistinguishable from magic"
--Arthur C. Clarke


Article: 22752
Subject: Re: Xilinx tools
From: Rickman <spamgoeshere4@yahoo.com>
Date: Mon, 22 May 2000 21:34:16 -0400
Links: << >>  << T >>  << A >>
Andy Peters wrote:
> Who comes up with these licensing schemes, anyways?

The same people who design the web sites with enough graphics to clog
56K modems. The same people who spend millions of dollars sending out
full color glossies that say little or nothing. The same people who give
every product a meaningless and confusing name that helps no one
understand what the product is...

marketing people.

--

Rick Collins

rick.collins@XYarius.com

removed.

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: 22753
Subject: % use of schematic vs VHDL ???
From: "Dan" <daniel.deconinck@sympatico.ca>
Date: Tue, 23 May 2000 03:14:02 GMT
Links: << >>  << T >>  << A >>
eom


Article: 22754
Subject: Re: Xilinx tools
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Tue, 23 May 2000 15:41:06 +1200
Links: << >>  << T >>  << A >>
Rickman wrote:
>
> I was just looking at the Xilinx web site to get info on their current
> tools and I now see that they no longer sell the tools. Rather Xilinx
> rents the tools to you for 1 year at a time. At the end of the year you
> can no longer use the tool for new designs.

So, start a hundred or so design templates within the first year ? :-)

> I have heard of some of the ASIC tool vendors doing this as a means to
> enhance their revenue. They are constantly trying to adjust their
> business model to maximize revenue since this is what they make money
> on.
>
> So now it looks like Xilinx is not happy with customers buying a given
> version of the tools and using that one version for new designs as long
> as they are happy with the known bugs in it. After a year, the tools
> will no longer let you start any new designs unless you pay the licence
> fee again.

> I don't get it. Xilinx keeps telling us that they want to make money
> from their chips and not the software. But this sure looks to me like
> they are trying to maximize the revenue from the tool sets.
>

It seems a clumsy, poorly thought through, variant of Altera's policy.
With Altera, you subscribe to updates & support, not usage.
Altera also has a free version, the SAME as the  version, but device
size limited. So, you can train/evaluate easily.

If you are an active design house, then update/usage is
almost the same thing, but it will cause problems for

o Teachers, students and casual / evaluation users
o Those with strict version control policies
o Project planners

And what about a revision to a existing design, that you want to keep
separate for version control reasons ?. ( Last time I looked, the FPGA
tools were very poor on conditional compile controls. )
How can they tell a renamed/edit project from a new one ?

Imagine the FPGA designer, with a std RED TAPE purchasing/management
stream, that you time with a calendar..
" We need it NOW !!"
" Oh, err, well just use the original file name then " " Yes I am sure
"
" What do you mean YOU _LOST_ the original version"
" No, don't do that, those files with the same name are actually
different"
" But it compiled OK last week "

They also try this one on : ( no, there was no smiley... )
# You may not publish any data or information that compares the
# performance of the Software with software created or distributed by
others.

Sooo, be very carefull what you say in a news group, lest Xilinx decide
it

The FPGA market is showing elements of the PC market, with short design
lives, accelerated obsolescence, and stinging price 'tails'.
Certainly, backward compatability is way down the list, and this policy
seems to follow the short life cycle mindset.

- jg

Article: 22755
Subject: Re: Error with Quartus for Altera APEX20K device: clock skew is greater then data delay
From: Michel Le Mer <michel.lemerNOmiSPAM@sta.fr.invalid>
Date: Tue, 23 May 2000 01:56:16 -0700
Links: << >>  << T >>  << A >>
Hello

How many clock do you have in your design? Is your in
question clock supply directly from an I/O or built inside
the fpga? Do you use ESB ram without clocking the ESB
input / output?
In the Quartus software the Auto Global is ON by default,
what about an equivalent option with Leonardo?

Good luck

* 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: 22756
Subject: Xilinx Virtex E
From: "Simon Zhang" <zhangyuc@online.sh.cn>
Date: Tue, 23 May 2000 19:16:49 +0800
Links: << >>  << T >>  << A >>
Hi, all,

I am in a project of DSP embedded ASIC, hope to utilize a FPGA with large
gatecount volumn and IO pins, as well as internal SRAM.  Seems that Xilinx
Virtex E is superior in these fields, do I have any other choice?  So as to
Xilinx VirtexE, any larger types than XCV2000E, such as 3200E?   And is
XCV2000E available(on North America market) in FG860 and FG1156?

Thanx!

SimonZh


Article: 22757
Subject: Actel Pro Asic ?
From: "jon" <rew@wer.fwsf>
Date: Tue, 23 May 2000 12:21:48 +0100
Links: << >>  << T >>  << A >>

Hi,

Has anybody had experience with Actel Pro Asic FPGA's ?, if so have you had
any problems with the design tools /FPGA's ?

Thanks
jon


Article: 22758
Subject: Actel Pro Asic ?
From: "jon" <rew@wer.fwsf>
Date: Tue, 23 May 2000 12:32:26 +0100
Links: << >>  << T >>  << A >>
Hi,

Has anybody experience in designing with Actel Pro ASIC FPGA's, if so
have you had any problems with the design tools / FPGA's   ?

Thanks

Jon


Article: 22759
Subject: Re: Xilinx tools becoming "RentWare"
Date: Tue, 23 May 2000 11:38:48 GMT
Links: << >>  << T >>  << A >>
I heavily dislike this new "feature" for the tools too.

The whole principle of "rentware" is wrong, and the way Xilinx does it
(that is hiding the facts as much as possible) make it worse.

Since I first new about them (was in the times of the XC2064), I always
liked both the products, the support, the tools, and (the little that I know)
about how they do business. This is the first time that I see them using
such dirty tricks.

The main problem with "rentware" is the uncertainty that it creates for
the user.
I might be willing to use a "time limited" shareware gadget since if I lose it,
that's no big deal.
I can't say the same with a development tool, and, even if the new license
says that it will allow me to keep updating existent project after the year is
over that's not big relief.

What more, if the policy changed once, it can change again, restricting to
a shorter period, or to a limited number of designs, it could even become
metered and charged by the minute. The only reason they might decide
not to do so is the reaction of their paying users base (that is us !).

As for now, I still use the Foundation Base 1.4 version to develop
Spartan based projects, and I'm quite happy with it.

I first sought about upgrading to 2.1, but did not because of the
"rentware" nature of it.
As long as I don't *need* it (that is as long as I do not design with
makes sense, I will stay out of it.

With me at least, the rentware scheme actually make them loose money.

Experience in different domains always proved users squarely hate
this way of doing business. Latest try (and failure) was the ill
conceived Div-X system (DVD players that required you to pay
each time you watch the content after a 48H period). As Circuit
City (that was part of the project) soon discovered, to sell Div-X
"enhanced" DVD players the only way was through lies and deceit
with a fair percentage of consumers returning the player for a
standard model as soon as they discovered how the whole thing
worked. Need I say a law firm imagined (and patented) this ?

If Xilinx wants us to regularly buy new software, the best way
to do it is to keep enhancing the tools on a regular basis as
they successfully did from the start and stay out of the fine print

Eric

Rickman wrote:

> I was just looking at the Xilinx web site to get info on their current
> tools and I now see that they no longer sell the tools. Rather Xilinx
> rents the tools to you for 1 year at a time. At the end of the year you
> can no longer use the tool for new designs.
>
> I have heard of some of the ASIC tool vendors doing this as a means to
> enhance their revenue. They are constantly trying to adjust their
> business model to maximize revenue since this is what they make money
> on.
>
> So now it looks like Xilinx is not happy with customers buying a given
> version of the tools and using that one version for new designs as long
> as they are happy with the known bugs in it. After a year, the tools
> will no longer let you start any new designs unless you pay the licence
> fee again.
>
> I don't get it. Xilinx keeps telling us that they want to make money
> from their chips and not the software. But this sure looks to me like
> they are trying to maximize the revenue from the tool sets.
>
>
> --
>
> Rick Collins
>
> rick.collins@XYarius.com
>
> removed.
>
> 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: 22760
Subject: Re: Xilinx tools
From: Nial Stewart <nials@sqf.hp.com>
Date: Tue, 23 May 2000 12:51:38 +0100
Links: << >>  << T >>  << A >>
Christian Mautner wrote:
>

>
> I think that this is not good idea, not for the customers and not for
> Xilinx. Especially if you consider that Altera is giving away a (not
> 100% but useful) version of their tools (including a decent synthesis

all over theor site saying "Available at the start of May", but I can't
find them anywhere yet.

Nial Stewart.

Article: 22761
Subject: Re: Xilinx tools
From: "Simon" <simonb@tile.demon.co.cuthis.uk>
Date: Tue, 23 May 2000 12:58:18 +0100
Links: << >>  << T >>  << A >>

Rickman wrote in message <3929E018.92584D73@yahoo.com>...
>Andy Peters wrote:
>> Who comes up with these licensing schemes, anyways?
>
>The same people who design the web sites with enough graphics to clog
>56K modems. The same people who spend millions of dollars sending out
>full color glossies that say little or nothing. The same people who give
>every product a meaningless and confusing name that helps no one
>understand what the product is...
>
>marketing people.

The same people who call the (Spartan-II) XC2S15 chip
the XC2515 and the XC2915 in Xilinx publications.
Great products and technology...


Article: 22762
Subject: Re: Xilinx tools
From: "Simon Ramirez" <s_ramirez@email.msn.com>
Date: Tue, 23 May 2000 07:59:03 -0400
Links: << >>  << T >>  << A >>
Rick,
I have long argued with Xilinx about the cost of their software.  I
proposed to a visiting Xilinx software manager several years ago that Xilinx
should give away what is essentially Alliance.  He almost fell over backward
in his chair when I said this.  At the time, the tools cost money and the
licensing procedure was relatively hard.  I remember once that a Xilinx FAE
had to come in and install the tools.  After about 30 mintues, he couldn't
do it either, and he called the factory.  After some collaboration, the
tools came up.  This was my main motivation to tell the Xilinx manager that
the tools should be free -- make Xilinx software as easy as Altera software
Well, they did that by stamping the CD Key on the Alliance package.
But now they are going to make it more difficult to do Xilinx designs by
having it "time out" in a year?  They are apparently under a lot of pressure
to drum up some money really fast at the expense of making it harder to do
designs.  Any time you have to involve an outside source to fire up the
tools, it is a BIG inconvenience to me!
Oh, well, their stock is up, the marketing department must know what
they're doing, at least for a very short while.
-Simon

Rickman <spamgoeshere4@yahoo.com> wrote in message
news:3929635C.6FAFE01C@yahoo.com...
> I was just looking at the Xilinx web site to get info on their current
> tools and I now see that they no longer sell the tools. Rather Xilinx
> rents the tools to you for 1 year at a time. At the end of the year you
> can no longer use the tool for new designs.
>
> I have heard of some of the ASIC tool vendors doing this as a means to
> enhance their revenue. They are constantly trying to adjust their
> business model to maximize revenue since this is what they make money
> on.
>
> So now it looks like Xilinx is not happy with customers buying a given
> version of the tools and using that one version for new designs as long
> as they are happy with the known bugs in it. After a year, the tools
> will no longer let you start any new designs unless you pay the licence
> fee again.
>
> I don't get it. Xilinx keeps telling us that they want to make money
> from their chips and not the software. But this sure looks to me like
> they are trying to maximize the revenue from the tool sets.
>
>
>
> --
>
> Rick Collins
>
> rick.collins@XYarius.com
>
> removed.
>
>
>
> 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: 22763
Subject: Virtex: Verify and Readback; Capture_Virtex
From: "Christian Habermann" <habermann.christian@gmx.de>
Date: Tue, 23 May 2000 11:29:07 -0400
Links: << >>  << T >>  << A >>
Hello,

I have some Problems using the Verify and Readback function.
I'm using Xilinx Alliance Tools
So here are my questions:

Verify should be possible without any design preperation, right?

But although I have enabled Readback and Reconfiguration in the
bitgen-process, the Hardware-Debugger tells me:
Any suggestions on that point?

Anyhow, I then instantiated a Capture_Virtex into my design and the hardware
debugger didn't disable Readback and verify this time but it didn't worked.
So I think I need some help with this.

Do I need to instantiate any other components? Is there an example I can
learn from?


Article: 22764
Subject: A Question on XILINX Configuration PROM
From: "Ben" <ejhong@future.co.kr>
Date: Tue, 23 May 2000 15:29:34 GMT
Links: << >>  << T >>  << A >>
Hi all,

I am using a virtex device, and having a problem in programming the
configuration PROM, XC1702L.

Through so many hours of struggle with the design and XILINX tools, I just
obtained a bit file (*.bit) that is successfully configured through Hardware
Debugger. And I could use the PROM File Formatter to make an mcs file(*.mcs)
out of the bit file.

My questions are
1) I'm not sure if my universal programmer will support mcs format

Do you know which format of PROM file I should use with the universal
programmer named "ALL-11"? It's from "Hi-Lo Systems".

2) what if my universal programmer does support one of XILINX formats, how
does it support?

format for the image. I could find two tempting choices, "Binary", and
"Intel Hex". Others looked completely strange. Once I selected "Binary", and
the programmed PROM didn't configure my virtex right. Then the answer may be
"Intel Hex", or may be not. I haven't tried "Intel Hex" yet. But before I
just waste another OTP ROM, somebody please give me a clue.

TIA,

Ben


Article: 22765
Subject: Re: CLKing external RAM from FPGA (Virtex E)
From: "Marc K." <>
Date: Tue, 23 May 2000 08:31:35 -0700
Links: << >>  << T >>  << A >>
Peter,

Thanks for the phone call. I'm glad we were able to straighten it out. Again, please accept my apology for castigating you in public. Also, sorry for the delay getting this post in.

All,

Please accept my apology for the flame email thread. Peter has posted many good ideas, and didn't deserve my cutting remarks. We're working together to resolve the discrepancies between the Xilinx forum site (the comp.arch.fpga "mirror" at
support.xilinx.com->forums->comp.arch.fpga) and accesses through various news servers, for example deja and news1.sfba.home.net.

Marc

Article: 22766
Subject: Re: Xilinx tools becoming "RentWare"
From: Dave Vanden Bout <devb@xess.com>
Date: Tue, 23 May 2000 11:39:02 -0400
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------ED717E9927E28E24F507E668
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I agree with Eric and Rick that this is a bad move (from the user's point of view).  I wouldn't mind it so much if they offered rent-ware as an option and we could still buy the tools out-right if we wanted.  Then Xilinx would get some feedback from the market as to the value of rent-ware by seeing how many people purchased it compared to the whole.

And since Xilinx has time to build the marketing and support infrastructure for rent-ware, why can't they find time to do a simple port of their non-GUI Alliance software to Linux?  I think more designers want this and would happily pay for it versus the black-eye Xilinx is going to get with rent-ware.

Eric wrote:

> I heavily dislike this new "feature" for the tools too.
>
> The whole principle of "rentware" is wrong, and the way Xilinx does it
> (that is hiding the facts as much as possible) make it worse.
>
> Since I first new about them (was in the times of the XC2064), I always
> liked both the products, the support, the tools, and (the little that I know)
> about how they do business. This is the first time that I see them using
> such dirty tricks.
>
> The main problem with "rentware" is the uncertainty that it creates for
> the user.
> I might be willing to use a "time limited" shareware gadget since if I lose it,
> that's no big deal.
> I can't say the same with a development tool, and, even if the new license
> says that it will allow me to keep updating existent project after the year is
> over that's not big relief.
>
> What more, if the policy changed once, it can change again, restricting to
> a shorter period, or to a limited number of designs, it could even become
> metered and charged by the minute. The only reason they might decide
> not to do so is the reaction of their paying users base (that is us !).
>
> As for now, I still use the Foundation Base 1.4 version to develop
> Spartan based projects, and I'm quite happy with it.
>
> I first sought about upgrading to 2.1, but did not because of the
> "rentware" nature of it.
> As long as I don't *need* it (that is as long as I do not design with
> makes sense, I will stay out of it.
>
> With me at least, the rentware scheme actually make them loose money.
>
> Experience in different domains always proved users squarely hate
> this way of doing business. Latest try (and failure) was the ill
> conceived Div-X system (DVD players that required you to pay
> each time you watch the content after a 48H period). As Circuit
> City (that was part of the project) soon discovered, to sell Div-X
> "enhanced" DVD players the only way was through lies and deceit
> with a fair percentage of consumers returning the player for a
> standard model as soon as they discovered how the whole thing
> worked. Need I say a law firm imagined (and patented) this ?
>
> If Xilinx wants us to regularly buy new software, the best way
> to do it is to keep enhancing the tools on a regular basis as
> they successfully did from the start and stay out of the fine print
>
> Eric
>
> Rickman wrote:
>
> > I was just looking at the Xilinx web site to get info on their current
> > tools and I now see that they no longer sell the tools. Rather Xilinx
> > rents the tools to you for 1 year at a time. At the end of the year you
> > can no longer use the tool for new designs.
> >
> > I have heard of some of the ASIC tool vendors doing this as a means to
> > enhance their revenue. They are constantly trying to adjust their
> > business model to maximize revenue since this is what they make money
> > on.
> >
> > So now it looks like Xilinx is not happy with customers buying a given
> > version of the tools and using that one version for new designs as long
> > as they are happy with the known bugs in it. After a year, the tools
> > will no longer let you start any new designs unless you pay the licence
> > fee again.
> >
> > I don't get it. Xilinx keeps telling us that they want to make money
> > from their chips and not the software. But this sure looks to me like
> > they are trying to maximize the revenue from the tool sets.
> >
> >
> > --
> >
> > Rick Collins
> >
> > rick.collins@XYarius.com
> >
> > removed.
> >
> > 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

--
|| Dr. Dave Van den Bout   XESS Corp.               (919) 387-0076 ||
|| devb@xess.com           2608 Sweetgum Dr.        (800) 549-9377 ||
|| http://www.xess.com     Apex, NC 27502 USA   FAX:(919) 387-1302 ||

--------------ED717E9927E28E24F507E668
Content-Type: text/x-vcard; charset=us-ascii;
name="devb.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dave Vanden Bout
Content-Disposition: attachment;
filename="devb.vcf"

begin:vcard
n:Vanden Bout;Dave
tel;fax:(919) 387-1302
tel;work:(919) 387-0076
x-mozilla-html:FALSE
url:http://www.xess.com
org:XESS Corp.
version:2.1
email;internet:devb@xess.com
title:FPGA Product Manager
x-mozilla-cpt:;-16464
fn:Dave Vanden Bout
end:vcard

--------------ED717E9927E28E24F507E668--


Article: 22767
Subject: Re: Actel Pro Asic ?
From: johne@vcd.hp.com (John Eaton)
Date: 23 May 2000 16:03:05 GMT
Links: << >>  << T >>  << A >>
jon (rew@wer.fwsf) wrote:
: Hi,
:
:     Has anybody experience in designing with Actel Pro ASIC FPGA's, if so
: have you had any problems with the design tools / FPGA's   ?
:
: Thanks
:
:
:         Jon
:

I did some routes of some asic sections to see how well the gates would
map. Actel claimed something like 16 gates per tile best case and 8 gates
per tile nominal. My actual numbers from some 17K -60K chunks were between
2.31 and 2.51 gates per tile. FPGA vendors for some strange reason always
seem to multiply their specs by 4 or 5.

John Eaton


Article: 22768
Subject: Xilinx Logic Cell counts and carry chains
From: Rickman <spamgoeshere4@yahoo.com>
Date: Tue, 23 May 2000 12:28:52 -0400
Links: << >>  << T >>  << A >>
First let me say that I am not trying to pick on Xilinx by asking so
many questions about their devices and practices. But I am looking at
switching to their parts for my next design and want to discuss some of
the things I don't understand.

With that said, can anyone tell me how Xilinx comes up with their "Logic
Cell" counts? In the XC4000 line of parts, they seem to have 2.375 Logic
Cells per CLB. I can understand this since they have the two 4 input
LUTs and a 3 input LUT which they must be counting as .375 Logic Cells.

But in the Spartan II line they get 4.5 Logic Cells per CLB. But if I
understand the architechture correctly, there is no extra 3 input LUT in
these devices. Although they have extra logic to combine the outputs of
the four LUTs in a CLB, this logic can not be used independantly as can
the 3 input LUT in the XC4000 series. So the maximum number of logic
outputs you can have is determined by the number of LUTs you have, not
the number of "Logic Cells".

So how can they count this as .5 Logic Cells per CLB? Is Logic Cell
count the same as gate count and should be ignored?

I guess this is not really a significant issue, but it does make their
documentation a bit harder to interpret since I have to calculate the
LUT count myself for every device I want to consider.

On a more significant note, I can't say that I understand the carry
chain description in the Spartan II datasheet. I can't seem to cut and
paste from the document (odd, I can do that with most other PDF
files...) but the text says, "The Spartan-II CLB supports two separate
carry chains, one per Slice. The height of the carry chains is two bits
per CLB." The Virtex carry chain is described the same way so that sheds
no additional light on the matter.

Is this saying that the two slices are separate and only one carry chain
can be used at a time? Or are the two cascadable to produce a four bit
slice of a counter/adder? I checked the timing data and there is no
indication of a fast connect from Cout to Cin on the same CLB or to
adjacent CLBs. Has this gone away with the Virtex/Spartan II parts?

--

Rick Collins

rick.collins@XYarius.com

removed.

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: 22769
Subject: FPGA implementation of LCD controller
From: "Jann" <jannkaminski@hotmail.com>
Date: Tue, 23 May 2000 10:20:55 -0700
Links: << >>  << T >>  << A >>
The company I work for develops polymer light emitting matrix displays (not
7-segment or alphanumeric). We use passive addressing to light up columns
and rows on the 128x64 displays . Currently I use LCD graphics controllers
to generate the timing signals for monochrome (1 bit) voltage drivers but
there are some severe limitations.

I would like to develop a custom controller that utilizes the features of
our displays for monochrome and gray-scale applications. Are there any
public libraries, app notes, public implementation of FPGA devices used as
Display Timing Controllers. The searches I have done only bring up
'captured' applications in embedded products.

TIA for any information,

Jann
jann(at)uniax(dot)com


Article: 22770
Subject: Re: Xilinx Logic Cell counts and carry chains
From: nweaver@boom.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: 23 May 2000 17:23:49 GMT
Links: << >>  << T >>  << A >>
In article <392AB1C4.556B80FC@yahoo.com>,
Rickman  <spamgoeshere4@yahoo.com> wrote:
>With that said, can anyone tell me how Xilinx comes up with their "Logic
>Cell" counts?

The marketing people drag the numbers out of their rectum, in
a continuing competition with the altera marketing folks who are doing
the same thing.

:)

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

Article: 22771
Subject: Re: Xilinx Logic Cell counts and carry chains
From: ldoolitt@recycle (Larry Doolittle)
Date: 23 May 2000 17:55:43 GMT
Links: << >>  << T >>  << A >>
Rickman (spamgoeshere4@yahoo.com) wrote:

: But in the Spartan II line they get 4.5 Logic Cells per CLB. But if I
: understand the architecture correctly, there is no extra 3 input LUT in
: these devices. Although they have extra logic to combine the outputs of
: the four LUTs in a CLB, this logic can not be used independently as can
: the 3 input LUT in the XC4000 series. So the maximum number of logic
: outputs you can have is determined by the number of LUTs you have, not
: the number of "Logic Cells".
: So how can they count this as .5 Logic Cells per CLB? Is Logic Cell
: count the same as gate count and should be ignored?

: I guess this is not really a significant issue, but it does make their
: documentation a bit harder to interpret since I have to calculate the
: LUT count myself for every device I want to consider.

For a while I was counting CLB's, but Xilinx changed the architecture
enough from 40xx and Spartan to Virtex and Spartan-II that you have to
watch factors of two.  I guess (for now) you can use "Slices" as a
meaningful comparison, where 1 Slice = 1 40xx CLB = 1/2 Virtex CLB.

: On a more significant note, I can't say that I understand the carry
: chain description in the Spartan II datasheet. I can't seem to cut and
: paste from the document (odd, I can do that with most other PDF
: files...) but the text says, "The Spartan-II CLB supports two separate
: carry chains, one per Slice. The height of the carry chains is two bits
: per CLB." The Virtex carry chain is described the same way so that sheds
: no additional light on the matter.

The point is that they have not rearranged the carry chain (much) from
the 40xx and Spartan line.  You still have one chain for each vertical
column of LUT's.  What's different (see above) is how those LUT's are
routed and named -- there are now 4 LUT's in one CLB.  A CLB is apparently
defined by Xilinx this month as "that set of LUT's and associated logic
that are completely routable independent of the global routing resources".
One half of the new CLB, which they call a slice, has a pair of vertically
arranged LUT's and a single carry chain.  The carry logic for the two
slices are independent in operation and configuration.

: Is this saying that the two slices are separate and only one carry chain
: can be used at a time?

They are separate, and can both be used independently.

: Or are the two cascadable to produce a four bit

No, the two chains can't interact.

: I checked the timing data and there is no
: indication of a fast connect from Cout to Cin on the same CLB or to
: adjacent CLBs. Has this gone away with the Virtex/Spartan II parts?

I didn't know there was ever a horizontal connection between carry chains.
Note that they improved the routability of the ends of the carry chains
in the Virtex.  It no longer takes a whole LUT to set up the carry input
to a chain.  Otherwise, you couldn't conceive of doing 32-bit arithmetic
in an XCV50/XC2S50, which is only 16 Slices high.

- Larry Doolittle   <LRDoolittle@lbl.gov>

Article: 22772
Subject: Re: Xilinx Logic Cell counts and carry chains
From: Ray Andraka <ray@andraka.com>
Date: Tue, 23 May 2000 18:51:20 GMT
Links: << >>  << T >>  << A >>

Rickman,

Those are marketing logic cells, not to be confused with the actual logic.
The way they get the numbers is by figuring how many 4 LUTs would be
required to get the same logic.  Nonsense as far as I'm concerned.  It is
much better, IMHO to understand what the CLB/slice is capable of, then count
the CLBs.

Now as far as the slice/CLB confusion, the two slices in a CLB are for the
most part independent of one another.  Pretty much the only time the two
slices get considered together is when you use the F6 mux, which lets you
implement any 6 input logic function in a CLB.  I think things would have
been alot clearer (and some problems in the mapper would have gone away) if
they did away with the notion of a SLICE and called what is now called a
slice a CLB.  Also, the delay between slices within a CLB is shorter than
delay between slices in adjacent CLBs.

That said, treat the two slices indpenedently when considering the carry
chain.  The carry chain for each slice is two bits, and connects in a chain
to the same slice in the CLB neighbors above and below.  You can't connect
the carry from one slice to the other, at least not and stay on the carry
chain.  The carry chain structure is on the output side of the LUT, rather
than on the input side like it was in the 4K /spartan parts.  Figure 5 on
page 7 of the databook at http://www.xilinx.com/partinfo/ds003.pdf is a
pretty accurate depiction of the logic inside the slice.  As an adder, the
carry chain mux selects the previous carry chain output if the A and B
inputs to the LUT don't match (the LUT is programmed as an XOR for a simple
adder), so that if there is one '1 in the input at this bit, the carry in is
propagated.  If there is not just one '1' input, then the value of an input
to the LUT is propagated, essentially propagating a '1' if both inputs are
'1's or '0' if both inputs are '0's.  The and gate allows you to gate the
carry input parallel to a gate added into the LUT so you can do a 2xN
partial product for a multiplier in one column of slices.

Since the two slices are independent you can have two carry chains running
up a column of CLBs.  The carry chains aren't meant to be combined to make
one carry chain.  There are fast connects dedicated to carry chain running
vertically from one slice to the same slice in the neighboring CLB above.
Additionally there are fast connections from the CLB output to each of the E
and W neighbors, but that one is not related to the carry chain.

Rickman wrote:

> First let me say that I am not trying to pick on Xilinx by asking so
> many questions about their devices and practices. But I am looking at
> switching to their parts for my next design and want to discuss some of
> the things I don't understand.
>
> With that said, can anyone tell me how Xilinx comes up with their "Logic
> Cell" counts? In the XC4000 line of parts, they seem to have 2.375 Logic
> Cells per CLB. I can understand this since they have the two 4 input
> LUTs and a 3 input LUT which they must be counting as .375 Logic Cells.
>
> But in the Spartan II line they get 4.5 Logic Cells per CLB. But if I
> understand the architechture correctly, there is no extra 3 input LUT in
> these devices. Although they have extra logic to combine the outputs of
> the four LUTs in a CLB, this logic can not be used independantly as can
> the 3 input LUT in the XC4000 series. So the maximum number of logic
> outputs you can have is determined by the number of LUTs you have, not
> the number of "Logic Cells".
>
> So how can they count this as .5 Logic Cells per CLB? Is Logic Cell
> count the same as gate count and should be ignored?
>
> I guess this is not really a significant issue, but it does make their
> documentation a bit harder to interpret since I have to calculate the
> LUT count myself for every device I want to consider.
>
> On a more significant note, I can't say that I understand the carry
> chain description in the Spartan II datasheet. I can't seem to cut and
> paste from the document (odd, I can do that with most other PDF
> files...) but the text says, "The Spartan-II CLB supports two separate
> carry chains, one per Slice. The height of the carry chains is two bits
> per CLB." The Virtex carry chain is described the same way so that sheds
> no additional light on the matter.
>
> Is this saying that the two slices are separate and only one carry chain
> can be used at a time? Or are the two cascadable to produce a four bit
> slice of a counter/adder? I checked the timing data and there is no
> indication of a fast connect from Cout to Cin on the same CLB or to
> adjacent CLBs. Has this gone away with the Virtex/Spartan II parts?
>
> --
>
> Rick Collins
>
> rick.collins@XYarius.com
>
> removed.
>
> 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

--

-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com  or http://www.fpga-guru.com


Article: 22773
Subject: Re: Xilinx Virtex E
From: Utku Ozcan <ozcan@netas.com.tr>
Date: Tue, 23 May 2000 22:19:54 +0300
Links: << >>  << T >>  << A >>
Simon Zhang wrote:
>
> Hi, all,
>
> I am in a project of DSP embedded ASIC, hope to utilize a FPGA with large
> gatecount volumn and IO pins, as well as internal SRAM.  Seems that Xilinx
> Virtex E is superior in these fields, do I have any other choice?  So as to
> Xilinx VirtexE, any larger types than XCV2000E, such as 3200E?   And is
> XCV2000E available(on North America market) in FG860 and FG1156?
>
> Thanx!
>
> SimonZh

Simon,

The technical information of XCV2000E or higher devices are
still TBD (To Be Done), for example Xilinx has not announced
Bit Stream file sizes of these devices yet. But you should trace
these Xilinx devices very frequently in Xilinx homepage.
These devices are very very new.

Utku

--
I feel better than James Brown.

Article: 22774
Subject: ISA interface on FPGA or CPLD
From: Suttipan Limanond <limanond@ksc.th.com>
Date: Tue, 23 May 2000 21:42:55 -0500
Links: << >>  << T >>  << A >>
Hi:

I'm trying to find a ref. design for ISA interface on FPGA or CPLD for
motorola processors. I can't seem to find one on the internet. Any
suggestion is appreciated.

Thank you very much,

Suttipan Limanond.