Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 13350

Article: 13350
Subject: Re: Will XILINX survive?
From: gavin@cypher.co.nz (Gavin Melville)
Date: Mon, 30 Nov 1998 00:11:03 GMT
Links: << >>  << T >>  << A >>
On 29 Nov 1998 09:40:31 +0100, Anonymous <nobody@replay.com> wrote:

>This thought should be worrying not only XILINX shareholders, 
>but also, - XILINX users, who have invested a lot of efforts 
>and money into mastering XILINX tools.
===snip======
>Good bye XILINX ...

And this from a company whose CEO stated, in print, "Software is a
core competancy of Xilinx".  Mind you he was new to the job then.....
--
Gavin Melville
gavin@cypher.co.nz

Article: 13351
Subject: Re: Example of clock circuit needed !
From: "craig domeny" <craig.domeny@worldnet.att.net>
Date: 30 Nov 1998 01:29:38 GMT
Links: << >>  << T >>  << A >>

Le mer Michel wrote in message <364FE560.77003750@ago.fr>...
>ovilup wrote:
>
>> Hello !
>>
>> I am working on an I2C controller. Now, I am designing the
>> internal clock generator. I have an 1.5 MHz internal clock,
>> from which I have to generate the 100 KHz, 90 KHz, 44 KHz
>> 1.5 KHz SCL clocks.
>>
>> Any examples of such an clock generator would be appreciated !
>>
>> Thank you in advance.
>> OL
>
>Hello
>
>I do not know exactly what it is but I heard about the direct numeric
>synthesis. It is use in the signal generators to privide a wave of a
>specific frequency.
>
>Bye.
>Michel.
>

I did an i2c controller and used the "programmble counter" approach. The
logic around it was kind of messy, partly because (at least for a full i2c
implementation) you need to be able to run at *any* frequency depending on
the mode e.g. master xmit/rcv, slave xmit/rcv. I am not very familiar with
the approach using the accumulator, but depending on the application you may
not have the luxury of using processor resources for the i2c port. Good
luck.


Article: 13352
Subject: Re: Will XILINX survive?
From: "alpha" <alpha3.1@ix.netcom.com>
Date: Sun, 29 Nov 1998 22:18:08 -0500
Links: << >>  << T >>  << A >>
    I was wondering if someone could provide an objective comparison between
Altera and Xilinx. Not just from a technical standpoint (regarding their
products),  but also from a business standpoint. Which company (Altera or
Xilinx) from the viewpoint of the readers of this news group is a
superior/better company with the brightest future. (I thought this might be
an interesting topic to discuss. After all, we all want to use the chips of
the company that will be around the longest, or in other words is long-term
viable.)

-EKC


Article: 13353
Subject: Re: Will XILINX survive?
From: Bob Sefton <nobody@home.com>
Date: Mon, 30 Nov 1998 05:08:32 GMT
Links: << >>  << T >>  << A >>
What an absolute crock of shit. Save this crap for
misc.invest.stocks where somebody might buy into it.

By the way, Marshall doesn't sell Altera either. Do you think
that's by choice you moron?

Anonymous wrote:
> 
> This thought should be worrying not only XILINX shareholders,
> but also, - XILINX users, who have invested a lot of efforts
> and money into mastering XILINX tools.
> 
> Why should we expect XILINX shutdown in the foreseeable future?
> 
> 1) XILINX has started as successful innovative company and won
> essential part of the market. But that's in the past ...
> Recent history of XILINX is a sequence of disastrous failures
> to deliver satisfactory quality at reasonable price.
> Remind heart-breaking stories with 8000, 6200, 5200 series!
> Lacking new ideas, XILINX is trying to sell their old 4000
> series wrapped into Spartan envelope. And now Virtex becomes
> too late answer on Altera designs.
> 
> 2) XILINX applies tremendous efforts to reduce the price and ...
> the quality of its development tools.
> It was reported by many customers in this particular newsgroup
> that XILINX Foundation is worse than XACT, and each subsequent
> version of Foundation is worse than previous.
> Currently the quality of development tools is so bad that XILINX
> almost gave up any attempts to fix endless stream of bugs.
> The bugs are just stored until next version of Foundation :
> 
> 3) XILINX support service became some sort of psychoanalyst to
> keep users calm and to avoid bodily damage (and chip damage)
> caused by desperate customers. XILINX is afraid to reveal
> an obvious thing: there is no support for ALDEC software
> that constitutes the principal part of Foundation (design flow,
> schematics and simulation).
> 
> 4) And now the last news:
> MARSHALL does not sell XILINX chips any more.
> Obviously, they are feeling where the things go.
> 
> Good bye XILINX ...
> 
> *************

-- 

---------------------------
 real addr:
  rsefton_@_home.com
  (remove the underscores)
---------------------------

Article: 13354
Subject: Re: Will XILINX survive?
From: Rickman <spamgoeshere4@yahoo.com>
Date: Mon, 30 Nov 1998 01:54:24 -0500
Links: << >>  << T >>  << A >>
It is somewhat interesting to note that the revenue of both companies
has been relatively flat at about $150 mil/Q for nearly the last 2
years. Could this indicate that the programmable logic market has topped
out? It would make some sense that much of the growth of the
programmable logic market over the last ten years has been due to the
consolidation of designs from smaller discrete logic chips to larger
programmable logic chips. If this process has reached saturation, then
the question is, from where will further growth in this market to come? 

FPGAs are moving up into ASIC territory while designs themselves are
growing. So the growth in size of the FPGA parts may not result in a
larger market. At the same time, the cost per gate of FPGAs is dropping
which will offset any increase in revenue due to the larger parts. 

It would seem that just moving to ever larger FPGAs will not provide
future growth. Anyone have any insight into where these companies are
headed? 

Personally, I don't agree with the original poster at all in the
evaluation of Xilinx support and tools. I have had very good results
with the Foundation tools while I failed terribly with third party
tools. 


alpha wrote:
> 
>     I was wondering if someone could provide an objective comparison between
> Altera and Xilinx. Not just from a technical standpoint (regarding their
> products),  but also from a business standpoint. Which company (Altera or
> Xilinx) from the viewpoint of the readers of this news group is a
> superior/better company with the brightest future. (I thought this might be
> an interesting topic to discuss. After all, we all want to use the chips of
> the company that will be around the longest, or in other words is long-term
> viable.)
> 
> -EKC

-- 

Rick Collins

redsp@XYusa.net

remove the XY to email me.

Article: 13355
Subject: PCB rules for Xilinx ICs
From: Tim Forcer <tmf@ecs.soton.ac.uk.nojunk>
Date: Mon, 30 Nov 1998 10:33:43 +0000
Links: << >>  << T >>  << A >>
According to Xilinx, their latest and greatest CPLDs and FPGAs are
delicate flowers which should not be socketed so as to avoid the
consequential extra inductance in signal lines, and decoupling should be
extensive - surface-mount 0.1uF AND 0.01uF at EVERY power pin is stated
to be essential, along with 10uF per IC.

However, the XS40 (FPGA) and XS95 (CPLD) boards produced by XESS Corp
(see <http://www.xess.com/fpga/ho02000.html>) use socketed ICs with
relatively sparse decoupling.

Similarly, the Xilinx documentation on in-system programming implies
that one should use the Xilinx download systems.  These have
sophisticated line driving/terminating circuitry in their active "pods",
and are not as simple to clone as, say, the straightforward and
well-documented Lattice isp system.  Once again, the XESS Corp boards
use simple drive and termination arrangements and plain cables - no
slew-limiting capacitors, no padder resistors, not even pullups on most
lines, and some have no buffer.

Does anyone have experience of producing an isp system who can advise
whether to be very careful and precise (as per Xilinx) or take a more
relaxed approach (as per XESS) in designing the environment for these
ICs?

-- 
Tim Forcer               tmf@ecs.soton.ac.uk
Department of Electronics & Computer Science
The University of Southampton, UK

The University is not responsible for my opinions

Article: 13356
Subject: serial arbitration
From: htytus@shell1.iglou.com (Hul Tytus)
Date: 30 Nov 1998 05:42:14 -0500
Links: << >>  << T >>  << A >>

	Anyone know of an arbitration scheme that can use the "serial 
numbers" of devices on a master-less 2 wire (clock & data) serial bus? The 
objective is to avoid the complexity of a formal two pass give-to-next-
higher setup. Any selection sequence will work as long as each device is 
chosen equally. 
	
	The devices will be implemented on a board holding both an MCU and 
a CPLD. Consequently, there is a variey of tools, but not much free room on 
either.
	
	Suggestions on texts that deal with arbitration of this type would 
be a help also.

Thanks, Hul           htytus@iglou.com
Article: 13357
Subject: Re: Verilog Simulators
From: peter Lin <cmlin@topro.com.tw>
Date: Mon, 30 Nov 1998 19:37:45 +0800
Links: << >>  << T >>  << A >>
Rick Filipkiewicz wrote:
> 
> I'm looking for a reasonably priced Verilog simulator to add to our
> Xilinx Foundation+Express package.
> So far I can see VeriWell, Chronologic,  QuickTurn. Anybody have any
> comments on these or others. We could go to $5000 which  I assume writes
> off Cadence.
> 
> Also looking for a Verilog PCI testbench suite.
try  another tools 
www.dolphin.fr    smash free download , support verilog,vhdl,spice
-- 
peterLin                        林春敏
cmlin@topro.com.tw          www.topro.com.tw
130,Szewei rd,Hsin-chu,Taiwan
Fax 886-3-5251596
<< 人生就是無止境的追求真理 >>

Article: 13358
Subject: Re: serial arbitration
From: Jonathan Bromley <jsebromley@brookes.ac.uk>
Date: Mon, 30 Nov 1998 12:15:38 +0000
Links: << >>  << T >>  << A >>
Hul Tytus wrote:
>         Anyone know of an arbitration scheme that can use the "serial
> numbers" of devices on a master-less 2 wire (clock & data) serial bus? The
> objective is to avoid the complexity of a formal two pass give-to-next-
> higher setup. Any selection sequence will work as long as each device is
> chosen equally.

CANbus uses a neat arbitration scheme (there's no clock line, but that
doesn't affect the method) based on sending an arbitration priority most-
significant-bit-first, using any signalling scheme which has "wire-or"
behaviour:
- multiple drivers are OK
- N drivers sending identical levels gives that level
- N drivers sending different levels, the dominant level
  wins (dominant=0 in CANbus, but that's a matter of taste)

Each node tries to send by first sending a dominant-level start bit.
Any other node seeing the start bit will accept that it lost the
race and will back off until the current message has completed.

But if two nodes send start bits simultaneously, each believes it
was successful! So the next thing you send is an arbitration number,
MSB first.  As long as the two nodes send identical arbitration
numbers, both think they are alone and successful.  But as soon
as you come to a bit where the arbitration numbers differ,
the node sending the dominant level succeeds (and carries on,
ignorant of the other node) and the node attempting to send a
recessive level sees that it has failed (dominant level appears
on the line) and immediately ceases its attempt - and retries later.

This technique gives zero-cost arbitration (the winner doesn't even
know he was involved in an arbitration contest) and is very easy to 
implement on a bus with an explicit clock line, but of course it
calls for:
(1) unique arbitration numbers per node
(2) EITHER acceptance of fixed arbitration priority among nodes
    (as used by CANbus) OR some devilish cunning method of
    rotating priorities to ensure fairness in a heavily-
    loaded system

IIRC this MSB-first wire-OR arbitration trick first saw the light of
day in part of the Futurebus spec, bus grant arbitration or something - 
but maybe I'm wrong?

I suspect that your stipulation "each device chosen equally" is 
incompatible with an entirely symmetrical peer-to-peer network
which arbitrates without negotiation.  Anything that guarantees
perfect symmetry in the choice process will lead to deadlock
in some situations.  You have to break the symmetry somehow;
fixed-per-node arbitration numbers is just the easiest way
to do it.  See Dijkstra's dining-philosophers problem for more
info!

Jonathan Bromley

Article: 13359
Subject: Logical Devices ALLPRO diagnostics
From: "Ellis Easley" <ehowell.easley@worldnet.att.net>
Date: 30 Nov 1998 13:00:51 GMT
Links: << >>  << T >>  << A >>
This question is not exactly FPGA related, but this is the only newsgroup I
can find that deals with programmable logic. I am looking for the diagnostic
programs for the Logical Devices AllPro (40) or AllPro 88 programmer. The
diagnostic programs provided with the AllPro 88 are called DIAG1, DIAG3, and
DIAG4.EXE and are located in directories named DIAG1, 3, and 4, according to
the service manual.

I am trying to use an AllPro programmer that I found in an internet auction.
Before I bid on it I contacted Logical Devices about support. They told me I
could get a service manual from them that would provide all the information
I would need to verify the machine was working before buying the programming
software. I understood this to mean it would contain either program listings
or programming information which I could use to exercise the hardware. I
ordered the manual and find it does not contain the details I need. It
covers a newer model (AllPro 88) and while the schematics it contains are
similar to the hardware in my unit, there are no PAL equations and no
schematics of the pindriver circuits. I have figured out the circuitry up to
the pindrivers but don't want to go further till I know whether it is
possible to turn on more than one source in a pindriver. I don't want to
accidentally connect 25V at 1A to a TTL output or a FET to ground!

Logical Devices says the AllPro 88 software recognizes the older AllPro
model and will do all devices up to 40 pins (the 88 has 88 pindrivers, the
old model has 40).

Ellis Easley Jr.
ehowell.easley@worldnet.att.net



Article: 13360
Subject: Re: Xilinx 5.2/6 tools v M1.5 tools for an XC4013E part.....
From: "Austin Franklin" <dark4room@ix.netcom.com>
Date: 30 Nov 1998 13:34:12 GMT
Links: << >>  << T >>  << A >>
> 1. My implementation times now are only a few minutes, ten or twenty
times
> faster than in the "good old days".  Thanks .....  Microsoft.

Microsoft?  Why Microsoft?  They haven't made their software (that does
nothing but get in the way, I call it a virus, they call it an OS) any
faster, in fact, it's nothing but VASTLY SLOWER.  Their saving grace has
been faster processors....

If you want to thank anyone for the GUI, for which Microsoft did nothing
but copy, thank Xerox and Apple.  Microsoft just copied it.

Austin Franklin
darkroom@ix.netcom.com

Article: 13361
Subject: Re: Will XILINX survive?
From: Bob Sefton <nobody@home.com>
Date: Mon, 30 Nov 1998 13:48:18 GMT
Links: << >>  << T >>  << A >>
Rickman wrote:
> 
> It is somewhat interesting to note that the revenue of both companies
> has been relatively flat at about $150 mil/Q for nearly the last 2
> years. Could this indicate that the programmable logic market has topped
> out?

The entire semiconductor market has been soft for the last two
years. It's a cyclic business. Programmable logic is projected to
be the fastest growing segment of the semiconductor market for
years to come.

It would make some sense that much of the growth of the
> programmable logic market over the last ten years has been due to the
> consolidation of designs from smaller discrete logic chips to larger
> programmable logic chips. If this process has reached saturation, then
> the question is, from where will further growth in this market to come?
> 

As size and speed increase and the development tools get better
these parts will find plenty of new applications. Use you
imagination.

> 
> FPGAs are moving up into ASIC territory while designs themselves are
> growing. So the growth in size of the FPGA parts may not result in a
> larger market. At the same time, the cost per gate of FPGAs is dropping
> which will offset any increase in revenue due to the larger parts.

The cost per gate of ALL semiconductors goes down as processes
shrink. Look at microprocessors. Intel has managed to stay afloat
under these market conditions, and Xilinx and Altera combined
probably have a more dominant position in the programmable logic
market than Intel does in the microprocessor market.

> It would seem that just moving to ever larger FPGAs will not provide
> future growth. Anyone have any insight into where these companies are
> headed?
> 

IMHO they'll both thrive for many years to come.

> Personally, I don't agree with the original poster at all in the
> evaluation of Xilinx support and tools. I have had very good results
> with the Foundation tools while I failed terribly with third party
> tools.

I agree. The tools have come a long way, but of course they still
have some shortcomings. The diversity in the target applications
of the parts and of the customer base (and design environments)
that these companies have to serve makes it impossible to please
everyone.


---------------------------
 real addr:
  rsefton_@_home.com
  (remove the underscores)
---------------------------

Article: 13362
Subject: Re: serial arbitration
From: Rickman <spamgoeshere4@yahoo.com>
Date: Mon, 30 Nov 1998 09:06:33 -0500
Links: << >>  << T >>  << A >>
Jonathan Bromley wrote:
> 
> Hul Tytus wrote:
> >         Anyone know of an arbitration scheme that can use the "serial
> > numbers" of devices on a master-less 2 wire (clock & data) serial bus? The
> > objective is to avoid the complexity of a formal two pass give-to-next-
> > higher setup. Any selection sequence will work as long as each device is
> > chosen equally.
> 
> CANbus uses a neat arbitration scheme (there's no clock line, but that
> doesn't affect the method) based on sending an arbitration priority most-
> significant-bit-first, using any signalling scheme which has "wire-or"
> behaviour:
> - multiple drivers are OK
> - N drivers sending identical levels gives that level
> - N drivers sending different levels, the dominant level
>   wins (dominant=0 in CANbus, but that's a matter of taste)
> 
> Each node tries to send by first sending a dominant-level start bit.
> Any other node seeing the start bit will accept that it lost the
> race and will back off until the current message has completed.
...snip...

This sounds much like the "arbitration" scheme used in ISA bus
Plug-N-Play device identification. They use the same, "everybody reply"
with an ID number, one bit at a time, with one polarity dominating. This
process continues with "losers" dropping off the bus until only one guy
is left standing at the end where you have received his ID number and he
is ready to receive configuration instructions. 

I am not sure, but I believe PCI also works this way. 

Sounds like a good way to go if you can afford the time to shift out the
ID number. But then if you are on a serial bus, it is a moot point. 


-- 

Rick Collins

redsp@XYusa.net

remove the XY to email me.

Article: 13363
Subject: Re: Will XILINX survive?
From: tom_curran@memecdesign_dot_com (tom curran)
Date: Mon, 30 Nov 1998 14:23:35 GMT
Links: << >>  << T >>  << A >>
Only a PUTZ posts such an opinion wtih an anonymous signature.

I wouldn't give this guy two cents of credibility.
---
Tom Curran
Memec Design Services -- Boston
url:    www.memecdesign.com
email:  tom_curran@memecdesign_dot_com

Article: 13364
Subject: Re: Will XILINX survive?
From: husby@fnal.gov (Don Husby)
Date: Mon, 30 Nov 1998 14:49:09 GMT
Links: << >>  << T >>  << A >>
Anonymous <nobody@replay.com> wrote:
> This thought should be worrying not only XILINX shareholders, 
> but also, - XILINX users, who have invested a lot of efforts 
> and money into mastering XILINX tools.

Translation:  "I just sold short on Xilinx stock and I'm
under the illusion that real investors will take my
dimwitted reasoning seriously.

> 4) And now the last news: 
> MARSHALL does not sell XILINX chips any more. 
> Obviously, they are feeling where the things go.

Xilinx dumped Marshall.
Obviously, they are feeling where the things go?

Article: 13365
Subject: Re: Will XILINX survive?
From: z80@ds2.com (Peter)
Date: Mon, 30 Nov 1998 15:04:35 GMT
Links: << >>  << T >>  << A >>

This is probably exactly what Intel are trying to do - maintain
pressure on the competition by introducing lots of different products.
This strategy should be successful, in the short term at least, but
only if the company pushing it is big enough to start with.

>Remind heart-breaking stories with 8000, 6200, 5200 series! 
>Lacking new ideas, XILINX is trying to sell their old 4000 
>series wrapped into Spartan envelope. And now Virtex becomes 
>too late answer on Altera designs.


--
Peter.

Return address is invalid to help stop junk mail.
E-mail replies to zX80@digiYserve.com but
remove the X and the Y.

Article: 13366
Subject: Re: Will XILINX survive?
From: z80@ds2.com (Peter)
Date: Mon, 30 Nov 1998 15:04:38 GMT
Links: << >>  << T >>  << A >>

>It is somewhat interesting to note that the revenue of both companies
>has been relatively flat at about $150 mil/Q for nearly the last 2
>years. Could this indicate that the programmable logic market has topped
>out? It would make some sense that much of the growth of the
>programmable logic market over the last ten years has been due to the
>consolidation of designs from smaller discrete logic chips to larger
>programmable logic chips. If this process has reached saturation, then
>the question is, from where will further growth in this market to come? 
>
>FPGAs are moving up into ASIC territory while designs themselves are
>growing. So the growth in size of the FPGA parts may not result in a
>larger market. At the same time, the cost per gate of FPGAs is dropping
>which will offset any increase in revenue due to the larger parts. 
>
>It would seem that just moving to ever larger FPGAs will not provide
>future growth. Anyone have any insight into where these companies are
>headed? 

I cannot see how the continued push towards ever larger FPGAs matches
with what people actually design. I can see why the vendors do this:
they have absolutely nowhere else to go, except keep reducing prices
on existing parts until they all go bust.

But very few designs are 100k+ gates. Sure, the newsletters are full
of such examples, but those are invariably very high cost low volume
products where the device cost was almost immaterial. I know quite a
few people who design FPGAs for a living, and several firms who use X.
devices in very large numbers, and most of the designs are under 10k
gates. Anything in the 100k-1M gate region would represent a massive
project (in man-years), unless the device is stuffed with RAM or some
other regular structure.

I don't know what the sales breakdown of FPGAs is but I would bet that
bulk of X's profits come from their sub-10k-gate parts, mostly the old
XC3000 and XC4000. These, especially 4K, represent probably the most
futureproof family around. If your firm uses these in fairly large
numbers, say 1k-10k/month, you get such low prices (via a direct
account) that it makes no sense to change to another family - one
which will probably vanish at the next whim of the X. Marketing Dept.

I don't think Xilinx will go bust. They have had a damn good
near-monopoly run for 10-15 years, selling silicon at nice high prices
and devt s/w at totally exorbitant prices (nipping the "problem"
company Neocad in the bud) and every good thing has to come to an end.
They will just have to share the market with others, rather more than
has been the case.


--
Peter.

Return address is invalid to help stop junk mail.
E-mail replies to zX80@digiYserve.com but
remove the X and the Y.

Article: 13367
Subject: Re: PCB rules for Xilinx ICs
From: Ray Andraka <no_spam_randraka@ids.net>
Date: Mon, 30 Nov 1998 10:10:16 -0500
Links: << >>  << T >>  << A >>
It depends mostly on how many outputs you plan to be switching at once.  If
you are switching many fast slew rate outputs together, you better have good
decoupling or you're going to have a bear of a time getting it all working.
If you are socketing it, or worse doing a wirewrapped design with an adapter
and are thus forced to have poor bypassing, then extraordinary efforts
should be made to reduce the number of outputs switching simultaneously (it
can be done, but it ain't pretty).  For the download, the critical thing is
to have a clean clock.  The CCLK is not very tolerant of ringing and other
garbage.

Tim Forcer wrote:

> According to Xilinx, their latest and greatest CPLDs and FPGAs are
> delicate flowers which should not be socketed so as to avoid the
> consequential extra inductance in signal lines, and decoupling should be
> extensive - surface-mount 0.1uF AND 0.01uF at EVERY power pin is stated
> to be essential, along with 10uF per IC.
>
> However, the XS40 (FPGA) and XS95 (CPLD) boards produced by XESS Corp
> (see <http://www.xess.com/fpga/ho02000.html>) use socketed ICs with
> relatively sparse decoupling.
>
> Similarly, the Xilinx documentation on in-system programming implies
> that one should use the Xilinx download systems.  These have
> sophisticated line driving/terminating circuitry in their active "pods",
> and are not as simple to clone as, say, the straightforward and
> well-documented Lattice isp system.  Once again, the XESS Corp boards
> use simple drive and termination arrangements and plain cables - no
> slew-limiting capacitors, no padder resistors, not even pullups on most
> lines, and some have no buffer.
>
> Does anyone have experience of producing an isp system who can advise
> whether to be very careful and precise (as per Xilinx) or take a more
> relaxed approach (as per XESS) in designing the environment for these
> ICs?
>
> --
> Tim Forcer               tmf@ecs.soton.ac.uk
> Department of Electronics & Computer Science
> The University of Southampton, UK
>
> The University is not responsible for my opinions



--
-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: 13368
Subject: Re: Xilinx 5.2/6 tools v M1.5 tools for an XC4013E part.....
From: Ray Andraka <no_spam_randraka@ids.net>
Date: Mon, 30 Nov 1998 10:15:50 -0500
Links: << >>  << T >>  << A >>
I still think that M1 is a serious backwards step for power users.  The only
thing it buys is a faster compile time.  However, floorplanning is broken when
compared to floorplanning in Xact6; Certain valid CLB mappings are not handled
by M1 so designs compiled successfully under xact6 may not compile or fit under
M1.  When possible, I still use Xact6.  Unfortunately, that is becoming less and
less often, as Xact6 does not handle any of the newer. larger devices.

Jan Gray wrote:

> Complaints:
>
> 1. If I recall correctly, XACT 5.2 could map 2 FMAPs + 1 (independent
> 3-input) HMAP driving a FDCE, RLOC constrained, into a single CLB.  Today a
> tech support call confirmed that M1.x does not support this.
>
> In my current XC4005E design, I have had to scrap four "free" columns of
> HMAP 2-1 multiplexor+registers, sharing CLBs with other FMAP logic, and
> replace them with two expensive columns of FMAP ones.  The absence of M1 map
> support for independent 3-input HMAPs renders my datapath 28% larger than
> otherwise necessary and reduces remaining area for other stuff by 33%.
>
> (I know, I could make four different hard macros using EPIC...no thank you.)
>
> 2. EPIC can't print!?
>
> Praise:
>
> 1. My implementation times now are only a few minutes, ten or twenty times
> faster than in the "good old days".  Thanks Intel, Xilinx, and Microsoft.
>
> 2. M1, just as XACT before it, provides convenient, explicit control over
> technology mapping and placement (FMAPs, RLOCs), and timing driven
> optimization, and, for now, it still accepts XNF!
>
> Count your blessings.  Let us give thanks.
>
> Jan Gray



--
-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: 13369
Subject: VHDL simulation of exported schematics..?
From: thor@sm.luth.se.NoSpam (Jonas Thor)
Date: Mon, 30 Nov 1998 15:25:12 GMT
Links: << >>  << T >>  << A >>
Hej,

I have a Xilinx Foundation schematic based design which I need to
simulate with a VHDL simulator (ModelSim). The schematic design has no
Reset port. So when the schematics is exported to VHDL I can't
simulate the the reset on configuration. One way to get around this is
to change all the schematic sheets and wire the reset to the top-level
and then export to VHDL. Before mapping I can then tie the reset pin
to ground. However since I am lazy I would prefer not to do this.

It should be possible to drive a global signal in VHDL testbench...?
Any ideas?

Thanks,

Jonas Thor
thor@sm.luth.se.NoSpam
(remove NoSpam, when replying)

Article: 13370
Subject: Re: PCB rules for Xilinx ICs
From: Bertram Geiger <bgeiger@eunet.at>
Date: Mon, 30 Nov 1998 16:44:28 +0100
Links: << >>  << T >>  << A >>
> Similarly, the Xilinx documentation on in-system programming implies
> that one should use the Xilinx download systems.  These have
> sophisticated line driving/terminating circuitry in their active "pods",
> and are not as simple to clone as, say, the straightforward and
> well-documented Lattice isp system.
The parallel Cable is nearly as simple as Atmel's ISP cable, we
duplicated them without any Problems.
Worked also fine in a breadboard approach.
I agree with serial cable - but parallel cables would fail with NT ?
-- 
Bertram Geiger,  bgeiger@EUnet.at
HTL Bulme Graz-Goesting - AUSTRIA

Article: 13371
Subject: Re: Will XILINX survive?
From: "Austin Franklin" <dark4room@ix.netcom.com>
Date: 30 Nov 1998 16:17:09 GMT
Links: << >>  << T >>  << A >>
>... and the development tools get better

Hum.  Any idea when that's gonna happen?

There is a 'perception' that the tools 'may' have gotten better, but when
comparing apples to apples, they are far worse.

If you compare the old tools with an old part, and the new tools with a new
part, the new tools/new part win.  Changing two variables in an equation
hardly provides a valid test.  In fact, it is misleading....

But....it does provide a data point, none the less, when used with the next
test:

When you take old tools/old part, and new tools/old part, old tools/old
part win by a wide margin.  I don't know about you, but to me, this is not
better tools.

I believe the conclusion is, the parts are better, the tools are worse.

Austin

Article: 13372
Subject: Re: Will XILINX survive?
From: "Austin Franklin" <dark4room@ix.netcom.com>
Date: 30 Nov 1998 16:31:03 GMT
Links: << >>  << T >>  << A >>
(nipping the "problem"
> company Neocad in the bud) 

I disagree that NeoCAD was a problem.  They (again) created a perception of
making a better router.  Well, it really was only better under certain
circumstances....but when used with a design that was floorplanned, it was
NO better, in fact, sometimes worse.  They designed it to handle regular
structures, and the Xilinx router did not handle them at all.

All the rest of the NeoCAD tools were not really very good (say, the EPIC
editor.....).  The NeoCAD 'vision' was to make a universal set of tools for
all programmable logic, NOT just 'another' tool for the Xilinx parts.  I
don't believe their 'vision' was ever going to materialize, and the
acquisition of NeoCAD by Xilinx was most fortunate for NeoCAD.

I believe it was a most unfortunate move for the Xilinx users, since, now,
we are stuck with this set of inferior tools, at least for the foreseeable
future....

Damn.

Austin

As a note, in no way am I meaning to demean or belittle NeoCAD, they have
some excellent engineering talent, and probably could have a great product,
BUT the fact is, the current tools ARE inferior to the previous Xilinx
5.2/6 tool set.  They, and Xilinx, need to own up to that.

Article: 13373
Subject: SLIP'99 CFP (Workshop on System-Level Interconnect Prediction)
From: Dirk Stroobandt <dstr@elis.rug.ac.be>
Date: Mon, 30 Nov 1998 17:39:59 +0100
Links: << >>  << T >>  << A >>
Call for position statements and complete papers

SLIP'99: workshop on System-Level Interconnect Prediction

The workshop on System-Level Interconnect Prediction (SLIP'99) is a new
forum for the exchange of ideas related to estimation of interconnect
design parameters in VLSI CAD applications. The workshop will take place
April 10 and 11, 1999 in Monterey (the weekend before the International
Symposium on Physical Design).

You are all invited to submit a position statement for informal
discussion and/or complete paper.
The call for papers follows at the end of this message.


SLIP web page: http://www.elis.rug.ac.be/~dstr/SLIP.html

More information: dstr@elis.rug.ac.be

---------------------------------------------------------------------------

SLIP'99: Workshop on System-Level Interconnect Prediction

April 10-11, 1999, Embassy Suites Hotel, Monterey, CA

The Workshop on System-Level Interconnect Prediction is a new
forum for the exchange of ideas related to estimation of
interconnect design parameters in VLSI CAD applications.
All aspects of interconnect design parameter estimations
and their applications to CAD and computer architecture evaluation
are in the scope of the workshop.   This year, special interest
goes to Rent's rule.   Also, while most research on interconnection
length and topology estimations has been performed in the
a posteriori (i.e., post-layout) regime, this workshop seeks to
promote research on a priori and on-line (i.e., pre-layout and
during layout) estimations since these will be fundamental to
the development of future convergent design methodologies.
Interconnection length estimates also provide deeper insight in
the placement properties of circuits on different carriers, e.g.
three-dimensional architectures with optical channels used for
the third dimension of interconnect.

The 1999 SLIP workshop will provide an informal context for
discussions of key new directions in the field, as well as an
opportunity to present leading-edge theoretical and experimental
contributions.   Contributed papers will be printed as
unpublished workshop notes, and will also be invited for
submission to an edited volume and/or a journal special issue
devoted to interconnect parameter estimation in VLSI CAD.
Other elements of the workshop include invited presentations
that provide attendees with reviews of background and leading-edge
research;   a tutorial review of Rent's rule and interconnection
length estimations will also be organized.   Sponsorship by
DA-related organizations is anticipated.

Two types of contributions are solicited for the workshop notes:

    - position statements, and
    - complete papers.

Topics of interest include but are not limited to:

    Rent's rule and its applications in VLSI CAD
    A priori, on-line, or a posteriori estimation of interconnect
        design parameters such as interconnection length,
        area occupancy, signal delay, power dissipation, etc.
    Theoretical estimation techniques
    Estimation algorithms
    Applications of interconnect parameter estimations in CAD, e.g.,
       floorplanning, placement, routing
    Applications of interconnect parameter estimations for system
       architecture evaluation
    Interconnect parameter estimations for ASIC's, MCM's, and FPGA's

IMPORTANT DATES

    Submission of position statements -- January 15, 1999
    Submission of complete (camera-ready) papers -- January 15, 1999
    Acceptance notification for complete papers -- February 15, 1999

SUBMISSION OF POSITION STATEMENTS

Anyone seeking to contribute to informal discussions on topics
related to the workshop theme may submit a position statement
(1 page up to a maximum of 3 pages). The position statements
will be used as a basis for round-table discussions.

SUBMISSION OF COMPLETE PAPERS

Authors should submit full-length, original papers (CAMERA-READY,
maximum 6 pages double-column format, 10pt font) containing

    Title of the paper
    Author names, affiliations and contact information
    Abstract of at most 200 words
    Paper text

High-quality papers that are concurrently submitted for publication
in conferences/journals may be considered by SLIP provided that
the concurrent submission is clearly indicated.

SUBMISSION INSTRUCTIONS

Electronic submission via uuencoded e-mail is encouraged and is the
preferred submission mode. Please email a single postscript file,
formatted for a 8 1/2" x 11" or A4 paper size, compressed with Unix
"compress" or "gzip" to

                      dstr@elis.rug.ac.be

Alternatively, you may send four (4) hardcopies of the paper to:

                      Dr. Dirk Stroobandt
                            SLIP'99
                       RUG-ELIS, room S6
                   Sint-Pietersnieuwstraat 41
                          B-9000 Gent
                            Belgium

WORKSHOP INFORMATION

To obtain information regarding the Workshop or to be added to the
Workshop mailing list, please send e-mail to
   dstr@elis.rug.ac.be
The SLIP web page is at http://www.elis.rug.ac.be/~dstr/SLIP.html

WORKSHOP ORGANIZATION

Prof. Andrew B. Kahng (University of California at Los Angeles, USA)
Dr. Dirk Stroobandt (University of Ghent, Belgium)

WORKSHOP TIP

Combine your participation to this workshop with the ISPD symposium
(same place, next day).


Mail your comments to: dstr@elis.rug.ac.be.



--
************************************************************

Dr. Dirk Stroobandt

Postdoctoral Fellow of the Fund for Scientific Research
(F.W.O.) at the University of Ghent, ELIS Department

RUG-ELIS Room S6                Phone:  +32 (0)9 264 34 01
St.-Pietersnieuwstraat 41       Fax:    +32 (0)9 264 35 94
B-9000 Gent, Belgium            E-mail: dstr@elis.rug.ac.be

URL: http://www.elis.rug.ac.be/~dstr/dstr.html

***********************************************************



Article: 13374
Subject: Re: Will XILINX survive?
From: Bob Sefton <nobody@home.com>
Date: Mon, 30 Nov 1998 16:43:10 GMT
Links: << >>  << T >>  << A >>
This was taken a little out of context, Austin. I never said the
tools were great. But I've been using Xilinx tools for a long time
now and the period of time after ppr replaced apr (the start of
the XACT series tools I guess) was pretty grim. The XACT tools
have had 5-6 years to mature now. I have to admit I haven't run
into a major problems with the M1 tools yet and all in all I like
them much better than XACT. The thing that HAS burned me to some
extent is the recent tendency of Xilinx to release optimistic
speed files which degrade with each release. I saw a post here
recently that claimed the opposite (that Xilinx is conservative),
but that wasn't my experience when the XL family was first
released.

I think the M1 tools with steadily improve and will become as
stable and much more usable than the XACT tools. The conversion
was something Xilinx had to do because, despite your (and my)
affinity for ppr, the old tools could never have supported the new
larger devices.

Bob

Austin Franklin wrote:
> 
> >... and the development tools get better
> 
> Hum.  Any idea when that's gonna happen?
> 
> There is a 'perception' that the tools 'may' have gotten better, but when
> comparing apples to apples, they are far worse.
> 
> If you compare the old tools with an old part, and the new tools with a new
> part, the new tools/new part win.  Changing two variables in an equation
> hardly provides a valid test.  In fact, it is misleading....
> 
> But....it does provide a data point, none the less, when used with the next
> test:
> 
> When you take old tools/old part, and new tools/old part, old tools/old
> part win by a wide margin.  I don't know about you, but to me, this is not
> better tools.
> 
> I believe the conclusion is, the parts are better, the tools are worse.
> 
> Austin

-- 

---------------------------
 real addr:
  rsefton_@_home.com
  (remove the underscores)
---------------------------



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search