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

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

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

Custom Search

Messages from 7000

Article: 7000
Subject: Re: PCI burst transfers
From: wen-king@myri.com (Wen-King Su)
Date: 21 Jul 1997 11:06:12 -0700
Links: << >>  << T >>  << A >>
In a previous article jhallen@world.std.com (Joseph H Allen) writes:
:
;Suppose I'm doing a read burst.  The target must watch the IRDY# line from
:the initiator to determine whether to hold the current read data or to send
;out the next word.  IRDY# can arrive as late as 7ns before the clock edge,
:and the data must be out by 11ns after to the clock edge- thus you have 18ns
;for this decision to occur, including pad propagation delays and big routing
:delays between IRDY# and (perhaps) an output mux.  Is this correct or am I
;missing something here?

You are correct.  PCI is very hard to do with FPGA if you want high
throughput.  Althought it this may not be true, I often get a feeling
that the spec is designed to keep little guys who can't afford to do gate
arrays off the market.  Instead of output muxes, have you thought about
possibly feeding IRDY to flip-flops' enable input?  Or was that what you
were talking about?  In most cases, that will give you the best timing.
Whether you can sustain the burst internally is another story. 

If you are doing it for a research project, you may be interested in
Lucent's plan to incoporate a hard wired PCI section on some of their
ORCA3C family of FPGAs.  Right now it looks like they may be too expensive
for commercial use because PCI products are very cost sensitive.
Article: 7001
Subject: Re: Production testing of Design with CPLD's
From: Kayvon Irani <kirani@cinenet.net>
Date: Mon, 21 Jul 1997 22:10:10 -0700
Links: << >>  << T >>  << A >>
Klaus Falser wrote:
> 
> Hello,
> can anybody recommend me some literature about production testing when
> using CPLD's?
> Is it really true, that the design inside the CPLD must not be tested an
> can be assumed as working correctly (apart from design errors)? Does it
> make sense to have test pins where internal signals can be monitored?
> 
> I'm very gratefull for every hint I can get.
> Thank you very much
>     K. Falser	
	I have been searching for that, too. We design flight critical boards and 
	would like to be able to test the final design implemented in CPLD/FPGAs. Some
	FPGAs give you the capablity to probe internal nets without taking them out
	to the I/O boundary (check Xilinx and Actel FPGAs). One thing that one can
	do is to MUX the desired nodes and clock them out on an output node. Another
	trick is explained on XAPP076 "Embedded Instrumentation Using XC9500 CPLDs"
	on Xilinx web site. You are right that these devices are tested in factory, that
	includes the flash and eeprom ( but not the Anti-fuse elements) programming 
	elements on the silicon.

	Regards,
	Kayvon Irani
	Los Angeles
Article: 7002
Subject: Re: PCI burst transfers
From: jhallen@world.std.com (Joseph H Allen)
Date: Tue, 22 Jul 1997 06:13:06 GMT
Links: << >>  << T >>  << A >>
In article <5r08ek$fke@neptune.myri.com>,
Wen-King Su <wen-king@myri.com> wrote:
>In a previous article jhallen@world.std.com (Joseph H Allen) writes:

>;Suppose I'm doing a read burst.  The target must watch the IRDY# line from
>:the initiator to determine whether to hold the current read data or to send
>;out the next word.  IRDY# can arrive as late as 7ns before the clock edge,
>:and the data must be out by 11ns after to the clock edge- thus you have 18ns
>;for this decision to occur, including pad propagation delays and big routing
>:delays between IRDY# and (perhaps) an output mux.  Is this correct or am I
>;missing something here?

>You are correct.  PCI is very hard to do with FPGA if you want high
>throughput.  Althought it this may not be true, I often get a feeling
>that the spec is designed to keep little guys who can't afford to do gate
>arrays off the market.  Instead of output muxes, have you thought about
>possibly feeding IRDY to flip-flops' enable input?  Or was that what you
>were talking about?  In most cases, that will give you the best timing.

For example for a Xilinx XC4010E-3:

The clock pad to output pad delay is 11ns, so you can't delay the clock to
fix anything. Thus the required IRDY# setup time is:

                                   Input delay:  2.5ns
                          Inverter (clb) delay:  2ns
Routing delay (clb output to 32 clock enables):  9ns
             Output FF clock enable setup time:  2.5ns
                                         Total: 16ns

                 Subtract minimum clock pad to
                         output ff clock delay: less than 6.8ns- I guess 4ns

                              IRDY# setup time: 12ns

but PCI only gives you 7ns.

The routing delay is as returned by xact when used to place and route the
design with only the IRDY# line and output flip-flops.

>Whether you can sustain the burst internally is another story. 

But there you have the full 30ns cycle time to play with and can use
pipelining.  I can't imagine how they deal with this problem, even in ASICs,
for 66MHz PCI.  Why coundn't they have just made the IRDY# and TRDY# lines
pipelined?
-- 
/*  jhallen@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 7003
Subject: Altera and Synopsys
From: kschen@vlsi.ee.hwh.edu.tw (Casper K. Chen)
Date: 22 Jul 1997 11:37:16 GMT
Links: << >>  << T >>  << A >>

I wrote my project in VHDL for Altera 10k. I hope use Synopsys to do logic
systhesis. In my VHDL file, I have use lpm_megafunction and lots of a_74XX
component. How to setup synopsys environment to work well?
Thanks.

Casper Chen
-- 
NAMES Casper K. Chen kschen@vlsi.ee.hwh.edu.tw
SNAIL No. 111, HwaHsin St., ChungHo City, Taipei, Taiwan
PHONE +886-2-9426424Ext301
FAX   +886-2-9426424Ext203
Article: 7004
Subject: Re: PCI burst transfers
From: wen-king@myri.com (Wen-King Su)
Date: 22 Jul 1997 11:03:58 -0700
Links: << >>  << T >>  << A >>
In a previous article jhallen@world.std.com (Joseph H Allen) writes:

:For example for a Xilinx XC4010E-3:
;
:The clock pad to output pad delay is 11ns, so you can't delay the clock to
;fix anything. Thus the required IRDY# setup time is:
:
;                                   Input delay:  2.5ns
:                          Inverter (clb) delay:  2ns
;Routing delay (clb output to 32 clock enables):  9ns
:             Output FF clock enable setup time:  2.5ns
;                                         Total: 16ns
:
;                 Subtract minimum clock pad to
:                         output ff clock delay: less than 6.8ns- I guess 4ns
;
:                              IRDY# setup time: 12ns
;
:but PCI only gives you 7ns.
;
:The routing delay is as returned by xact when used to place and route the
;design with only the IRDY# line and output flip-flops.

It would be a surprise if the clock delay is only 4ns.  But in any case I
agree XC4010E-3 isn't fast enough for what you need.  Try Lucent ORCA,
which has a selectable FF enable polarity.

;>Whether you can sustain the burst internally is another story. 
:
;But there you have the full 30ns cycle time to play with and can use
:pipelining.  I can't imagine how they deal with this problem, even in ASICs,
;for 66MHz PCI.  Why coundn't they have just made the IRDY# and TRDY# lines
:pipelined?

If we can build processors that run at 200-300 MHz, I don't see why a
66MHz point-to-point link will be difficult for ASIC.  However, I agree
with you about PCI protocol's deficiency.  The sad thing is there is
nothing one can do about it.  With proper pipelining in the bus protocol,
we should be able to achieve 66MHz with FPGA currently available.
Article: 7005
Subject: Re: VHDL Synthesis in Xilinx Foundation Series
From: "A.C.Rochat" <arjan.rochat@pi.net>
Date: Tue, 22 Jul 1997 20:19:06 +0200
Links: << >>  << T >>  << A >>
If you are planning to use version 2.2 or earlier, forget it.

The Foundation package contains software by Xilinx and Aldec.

The Aldec part (VHDL, Schematic capture, simulation) has a very fancy
GUI and fancy functionality, but it simply does not work.

The Aldec software performed so bad that we decided to halt the project
altogether.

Now, a jear later i am planning to take the project up again, if there
is goed software
available and Xilinx is willing to give it to mee free. (Yes _FREE_!
Xilinx owes me one!)

Positive notes:
The software written by Xilinx themselves is OK.
The support from the Xilinx distributor here in Holland is realy
exelent!!

----------
Arjan
 

Navneet S Yadav wrote:
> 
> hi,
> 
>         if anyone has used the VHDL synthesizer available with
> Xilinx Foundation series could they summarize their experience ?
> especially how does it compare to viewlogic's vhdl synthesizer
> and to Synopsys FPGA Express for PCs.
> 
>         is the Synopsys FPGA Express for PCs synthesizer as good
> as the one which they offer on unix workstations ?
> 
>         i would appreciate an email reply besides the news posting.
> news delivery at our site is rather unreliable.
> 
>         thanks in advance.
> 
> cheers,
> yadav
> 
> email:yadav@cse.iitb.ernet.in
Article: 7006
Subject: tech. report available
From: sds@cardinal.cs.wustl.edu (Stephen D. Scott)
Date: 22 Jul 1997 13:41:11 -0500
Links: << >>  << T >>  << A >>

Now available is a technical report that summarizes our work in
hardware-based GAs (the abstract is appended to this message).  It
includes a detailed description of the design (called the HGA),
analytical and empirical studies of the design to identify the
pipeline's bottlenecks, results from simulations and our prototype, a
description of several problems that the HGA is applicable to, and a
comparison with other hardware implementations of GAs.  It can be
obtained from

http://www.cs.wustl.edu/~sds/research/r-area.html#hga

Also available at that URL are the design's (VHDL) source code, our
conference paper of two years ago, and my M.S. thesis of three years ago.

Later,
Stephen

--
Stephen D. Scott                                     sds@cs.wustl.edu
Department of Computer Science                        535 Jolley Hall
Washington University, Campus Box 1045          phone: (314) 935-4425
One Brookings Drive                               fax: (314) 935-7302
St. Louis, MO  63130-4899          URL: http://www.cs.wustl.edu/~sds/

================================= CUT HERE ================================= 

                                 Abstract 

A genetic algorithm (GA) is an optimization method based on natural
selection.  Genetic algorithms have been applied to many hard
optimization problems including VLSI layout optimization, boolean
satisfiability, power system control, fault detection, control systems,
and signal processing. GAs have been recognized as a robust
general-purpose optimization technique. But application of GAs to
increasingly complex problems can overwhelm software implementations of
GAs, causing unacceptable delays in the optimization process. This is
true of any non-trivial application of GAs if the search space is large
or if real-time performance is necessary. It follows that a hardware
implementation of a GA is desirable for application to problems too
complex for software-based GAs.

Hardware's speed advantage and its ability to parallelize offer great
rewards to genetic algorithms.  Speedups of 1-2 orders of magnitude
have been observed when frequently used software routines were
implemented in hardware by way of field-programmable gate arrays
(FPGAs).  Since most of the GA's operations are simple, a hardware
implementation is feasible.  Reprogrammability is essential in a
general-purpose GA engine because certain GA modules require
changeability (e.g. the function to be optimized by the GA). In
hardware, reprogrammability is possible with FPGAs.  Thus an FPGA-based
GA is both feasible and desirable.

A fully functional self-contained hardware-based genetic algorithm (the
HGA) is presented here as a proof-of-concept system. It was designed
using VHDL to allow for easy scalability. It is designed to act as a
coprocessor with the CPU of a PC. The user programs the FPGAs which
implement the function to be optimized. Other GA parameters may also be
specified by the user. An analysis of the design is given that
identifies the bottleneck of the HGA's pipeline under varying
conditions.  Simulation results of the HGA are also presented. A
prototype HGA is described and compared to a similar GA implemented in
software. In our tests, the prototype and simulations took two to five
percent as many clock cycles to run as the software-based GA. Suggested
design improvements could dramatically increase the HGA's speed even
further. Finally, we give other potential applications of the HGA which
are feasible with current FPGA technology.
Article: 7007
Subject: Re: PCI burst transfers
From: z80@dserve.com (Peter)
Date: Tue, 22 Jul 1997 20:20:04 GMT
Links: << >>  << T >>  << A >>

>If you are doing it for a research project, you may be interested in
>Lucent's plan to incoporate a hard wired PCI section on some of their
>ORCA3C family of FPGAs.

Using such a part would make a subsequent ASIC version a lot of work
:)


Peter.

Return address is invalid to help stop junk mail.
E-mail replies to z80@digiserve.com.
Article: 7008
Subject: Re: Clock generator
From: Andre Powell <Andre@firkle.demon.co.uk>
Date: Tue, 22 Jul 1997 21:57:37 +0100
Links: << >>  << T >>  << A >>
In article <33cf25b0.1138643@news.unipg.it>, Gianpaolo Scassellati
<tivpc@geocities.com> writes
>How can I implement a clock generator in a Altera device ?
>(Vhdl or Ahdl)
>I need to specify clock frequency, so I cannot make a simple feedback
>chain.
>
>Thanks.

Hi,
IMHO you can't, the only thing you can do is to get a frequency source
and then scale it down via a counter. Don't be fooled by the 'after
Nns', this comes from the modelling concept of VHDL.

You would need to create a down counter which can be set that will
toggle a flip flop etc. You could have your frequency select lines (if
you have a discrete set)  select the down count. See if your compiler
has a model for a 74HC40103.
-- 
Andre Powell
Article: 7009
Subject: Re: PCI burst transfers
From: "Austin Franklin" <dark4room@ix.netcom.com>
Date: 22 Jul 1997 23:10:04 GMT
Links: << >>  << T >>  << A >>
Joseph,

> Suppose I'm doing a read burst.  The target must watch the IRDY# line
from
> the initiator to determine whether to hold the current read data or to
send
> out the next word.  IRDY# can arrive as late as 7ns before the clock
edge,
> and the data must be out by 11ns after to the clock edge- thus you have
18ns
> for this decision to occur, including pad propagation delays and big
routing
> delays between IRDY# and (perhaps) an output mux.  Is this correct or am
I
> missing something here?

Assuming a Xilinx...but still true for most FPGAs....  You are correct that
you have to react to IRDY within the next cycle.  Since there is also clock
input delay, you can add a few ns to the 7ns setup time.  Therefore you do
have enough time to go through one FMAP to a flop to control the CE of the
IOBs.  If you use the CE's in the IOB FFs, then the next data is waiting on
the internal tri-state bus (correct implementation of a PCI in an FPGA is
to use the internal tri-state bus for all the registers...do not use a
logic mux...that implementation uses more resources and timing is worse)
and can be clocked in when needed, and the data in the IOB FFs can be held
if needed.

> This sucks big time, if true.  It means you can't use pad output
flip-flops
> for the bus (once IRDY is received it's too late to change the data in
any
> output flip-flops).

In a Xilinx, you have to use the PAD I/O flops, and their CEs...it's the
only way to make PCI timing, and it is good resource utilization.

<snip>

> So (assuming I'm not missing something here), what moron designed PCI
> without thinking about pipeline delays?

PCI was designed to be implemented in ASICs.  But I don't disagree that
there are some things that could have been done to make implementation more
'palatible', but it would have been at a performance sacrifice.

To implement PCI in an FPGA, it takes a lot of understanding of the PCI
spec, the architecture/features of the FPGA being used, deterministic logic
design and mapping, and a lot of hand placement...  It's not that easy, but
it isn't that hard if you know the above...

Austin Franklin
darkroom@ix.netcom.com

Article: 7010
Subject: Re: PCI burst transfers
From: "Austin Franklin" <dark4room@ix.netcom.com>
Date: 22 Jul 1997 23:17:51 GMT
Links: << >>  << T >>  << A >>
See the Xilinx Data Book for the I/O timing.  The 4013E-3 makes PCI I/O
timing just fine.

> It would be a surprise if the clock delay is only 4ns.  But in any case I
> agree XC4010E-3 isn't fast enough for what you need.  Try Lucent ORCA,
> which has a selectable FF enable polarity.

I completely disagree.  I have done many PCI interfaces in Xilinx 4013E-3
parts, and it makes PCI timing just fine.  You need to use a -2 to do
master mode, but -3 is fine for target.  Master mode requires you to route
the raw PCI control signals to more destinations than a target requires,
and therefore requires the faster part.

Also, the FF enable polarity is not a problem.  IRDY is inverted in the
logic that is used to drive the flop that drives the IOB CE line, so this
is not a problem.  You have time to go through one FMAP to one flop and
still make PCI timing.

Austin Franklin
darkroom@ix.netcom.com

Article: 7011
Subject: Re: PCI burst transfers
From: wen-king@myri.com (Wen-King Su)
Date: 22 Jul 1997 17:35:16 -0700
Links: << >>  << T >>  << A >>
In a previous article z80@dserve.com (Peter) writes:
:
;
:>If you are doing it for a research project, you may be interested in
;>Lucent's plan to incoporate a hard wired PCI section on some of their
:>ORCA3C family of FPGAs.
;
:Using such a part would make a subsequent ASIC version a lot of work
;:)

If you are going commercial with a moderate volume ( ~10K units),
and you do not have enough resources to use ASIC as if it is FPGA,
this approach actually makes a lot of sense.  Lucent can do ASIC
conversion for you, and they are not exactly asking for an arm and
a leg at that volume.

What I would really like to see happen is a union of antifuse and SRAM
based FPGA technology.  One of the things that will make the PCI equipped
ORCA expensive is the small size of its market.  Instead, if we can add
superfast antifuse connected links to a conventional SRAM based FPGA, we
can implement the same speed sensitive logic core with antifuse, and leave
the rest of the chip reconfigurable.  No need to fragment the market by
incorporating different custom ASIC cores into the same family of products.
Article: 7012
Subject: Re: PCI burst transfers
From: gherbert@crl3.crl.com (George Herbert)
Date: 22 Jul 1997 17:47:19 -0700
Links: << >>  << T >>  << A >>
Peter <z80@dserve.com> wrote:
>>If you are doing it for a research project, you may be interested in
>>Lucent's plan to incoporate a hard wired PCI section on some of their
>>ORCA3C family of FPGAs.
>
>Using such a part would make a subsequent ASIC version a lot of work
>:)

Don't know why... their ASIC data books all have PCI interface macrocell
units in the "System Level Cores" section.  Presumably even the same
one as on their ASICS, if they're thinking...

-george william herbert
gherbert@crl.com

Article: 7013
Subject: Re: PCI burst transfers
From: gherbert@crl3.crl.com (George Herbert)
Date: 22 Jul 1997 18:13:08 -0700
Links: << >>  << T >>  << A >>
Peter <z80@dserve.com> wrote:
>>If you are doing it for a research project, you may be interested in
>>Lucent's plan to incoporate a hard wired PCI section on some of their
>>ORCA3C family of FPGAs.
>
>Using such a part would make a subsequent ASIC version a lot of work
>:)

Don't know why... their ASIC data books all have PCI interface macrocell
units in the "System Level Cores" section.  Presumably even the same
one as on their FPGAs, if they're thinking...

-george william herbert
gherbert@crl.com



Article: 7014
Subject: Re: VHDL Synthesis in Xilinx Foundation Series
From: Richard Schwarz <aaps@erols.com>
Date: Tue, 22 Jul 1997 23:13:53 -0400
Links: << >>  << T >>  << A >>
George Noten wrote:

> A.C.Rochat (arjan.rochat@pi.net) wrote:
> : If you are planning to use version 2.2 or earlier, forget it.
>
> : The Foundation package contains software by Xilinx and Aldec.
>
> : The Aldec part (VHDL, Schematic capture, simulation) has a very
> fancy
> : GUI and fancy functionality, but it simply does not work.
>
> : The Aldec software performed so bad that we decided to halt the
> project
> : altogether.
>
> : Now, a jear later i am planning to take the project up again, if
> there
> : is goed software
> : available and Xilinx is willing to give it to mee free. (Yes _FREE_!
>
> : Xilinx owes me one!)
>
> : Positive notes:
> : The software written by Xilinx themselves is OK.
> : The support from the Xilinx distributor here in Holland is realy
> : exelent!!
>
> This reminds me very much of my own experience with Viewlogic
> PROseries.
> The only good part of it was the beta-test version of Speedwave
> simulator.
> The synthesis just did not work.  Now I know that PRO-/View- synthesis
>
> tools are not to be trusted.  You are telling me that neither is
> Aldec.
> Can anybody recommend something that is good enough and does not cost
> you your life savings?  What about the new VHDL synthesis tool from
> MINC?
>
>         George.

I have used the Foundation Tools from XILINX and they indeed do work.
And they are very cost effective. I also own Exemplar, Model Tech and
have used many other VHDL packages. By far the most cost effective are
the Foundation tools. You can get the whole package with an FPGA
development board from APS for $2800.00. The MINC VHDL compiler does not
come with ROUTER software and is size limited. XILINX would package the
ALDEC tools, and continue to (yes the new M1 Foundation will have ALDEC
and FPGA Express[only for large parts]). If you are having problems you
should check the XILINX app notes or ALDEC. Perhaps you are doing
something wrong. You can see the APS kits at
http://www.associatedpro.com

--
----------------------------------------------------------------
Richard Schwarz,     President
Associated Professional Systems (APS)
EDA and Communications Tools
http://www.associatedpro.com
richard@associatedpro.com
410.569.5897  fx:410.661.2760


Article: 7015
Subject: Re: free FPGA software from actel
From: Gerald Coe <devantech@devantech.demon.co.uk>
Date: Wed, 23 Jul 1997 10:04:41 +0100
Links: << >>  << T >>  << A >>
In article <5qqf36$r1r@thorgal.et.tudelft.nl>, "L. Kumpa"
<LKumpa@nonet.net> writes
>
>
>The "Try Actel Software / Free Software!" link is STALE...  (19/7/97)
>
>
No it isn't. I downloaded the package on sunday 20/7/97, No problems.
>
>Herbert Kleebauer <klee@mistress.informatik.unibw-muenchen.de> wrote in
>article <5qklqc$s9h@thorgal.et.tudelft.nl>...
>> Has somebody tested the free actel software? Is it worth to download?
>> Is programmer support included? Is the ACTIVATOR needed or is there
>> a free design for a simple programming hardware.
>> 
>> If Vielogic would release the old DOS Workview as freeware this maybe
>> could be a good system for homberew chips.
>> 
>> -------------------------------------------------------------------------
>

-- 
Kindest Regards, Gerry             |  We manufacture processor modules
gerry@devantech.demon.co.uk        |  using PIC, 80C31, 80C188EB, 68302
http://www.devantech.demon.co.uk   |  also assemblers & C compilers.
Article: 7016
Subject: Epitaxial Layer on EPLD
From: Mike Kelly <cogent@cogcomp.com>
Date: Wed, 23 Jul 1997 08:58:40 -0400
Links: << >>  << T >>  << A >>
Hi,

We are doing a project with NASA for an airborne measuring system.  We
will be providing the system cpu board.  The engineers at NASA would
like us to use programmable logic (I prefer EPLDs) that have an
epitaxial layer.  They say this provides better resistance to radiation
induced lockup.  What I want to know is what chips out there have this
epitaxial layer.  I gather it is not common.  Any help is most
appreciated.

Please email me your ideas as well as posting them.  I don't check this
group as often as I should. :)


Michael J. Kelly
tel: (508) 278-9400
fax: (508) 278-9500
web: http://www.cogcomp.com
Article: 7017
Subject: Re: PCI burst transfers
From: z80@dserve.com (Peter)
Date: Wed, 23 Jul 1997 13:05:02 GMT
Links: << >>  << T >>  << A >>

>Don't know why..

Normally, when going FPGA -> ASIC, one does a netlist transfer. Since
one would not have the netlist for the PCI portion, one would then
have to design this from scratch.

OTOH if the FPGA vendor offers a hardwire version of the device, that
would represent a viable halfway stage. But still much more costly
than an ASIC. I have done a few FPGA -> ASIC conversions, and on say
10k+ quantity there is no comparison. One can get straight ASICs (i.e.
all digital, single supply rail, no fancy business) done with very low
NREs.


Peter.

Return address is invalid to help stop junk mail.
E-mail replies to z80@digiserve.com.
Article: 7018
Subject: Re: Production testing of Design with CPLD's
From: Tim Forcer <tmf@ecs.soton.ac.uk.nojunk>
Date: Wed, 23 Jul 1997 17:33:26 +0100
Links: << >>  << T >>  << A >>
Klaus Falser wrote:
> 
>can anybody recommend me some literature about production testing when
>using CPLD's?

Suggestions:

1.  Contact the relevant CPLD manufacturer (Vantis, Lattice, Altera
etc).

2.  Contact companies in the automated test equipment game, for example
JTAG Technologies are on http://www.jtag.com/ and have some useful free
literature (I'm NOT on commission, and have been neither customer nor
supplier).

>Is it really true, that the design inside the CPLD must not be tested an
>can be assumed as working correctly (apart from design errors)? Does it
>make sense to have test pins where internal signals can be monitored?

3.  No, it certainly isn't true!!!  I always ensure I have some sort of
test regime.  You may not need to bring internal signals out to pins
(waste of pins, so normally means you are using a larger package than is
appropriate) if the test regime is carefully designed and the design is
not too complex (ie internal states can be inferred from external
signals).

4.  Although it can introduce various complications, including a
liability to new failure modes, in-system programmability (isp) of CPLDs
ensures that the IC behaviour can't change between programming and being
fixed to the board.  Also allows a "self-test" configuration to be
loaded first and proved OK before "operational" configuration is
programmed - this may be a useful approach, depends on what else is on
the board.

5.  Many (most?) isp CPLDs have JTAG or similar boundary-scan
test/validation circuitry.  This is not a trivial subject, but can be
extremely worthwhile - especially if you want to be able to give your
customer a reasonable guarantee of functionality.

6.  Remember that PCB layout needs to be tester-friendly.  For
bed-of-nails testing this often means that all test points must be on a
0.1" grid.

7.  A small, low-current LED that is permanently on or flashes happily
when system is in good order can be a great confidence boost - even if
all it tells you is that the clock is running.

Good luck

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: 7019
Subject: Should Xiling have more local clock nets?
From: z80@dserve.com (Peter)
Date: Wed, 23 Jul 1997 18:12:08 GMT
Links: << >>  << T >>  << A >>
Hello,

I have just read in the Xilinx newsletter that one of the problems
with *large* FPGAs is the dynamic dissipation. This is fairly obvious
I suppose. The move to 3.3V is offered as the cure, for the time
being, but this gives only some 50% drop.

I also know, having done a few FPGA -> ASIC conversions where the
target had to be low-power, that the bulk of an ASIC's *dynamic* Icc
can be avoided by clock gating (i.e. local clocks, rather than a
global clock going all over the place, and using clock enables). I saw
drops of up to 5x by using heavy clock gating in the FPGA version, and
much more (10x-100x easily) in an ASIC.

Should Xilinx therefore not provide some local clocking?

Years ago, on the XC3064 etc, one could use a Long Line as a local
clock net. This was recommended by Xilinx app engineers at the time,
as being the next best "proper" thing to using the global clock net.
It worked perfectly. I did many designs, which were not only simulated
but also actually tested over temperature, without any problems.

But this no longer works in the newer devices, when building e.g. long
counters or shift registers. In fact it stopped working rather
suddenly about 2 years ago, with the new 3064 devices (can't remember
more details, since I have not used Xilinx parts much since then).

Presumably this is because the speed improvement has improved the
clock-Q timing by a larger factor than it has improved the worst-case
interconnect delays. This would break any shift-reg sort of circuit.
So we are now right back to routing ACLK/GCLK to *every* D-type, and
using clock enables, together with what is sometimes silly extra logic
to generate the clock-enable at the right time. Lots of milliwatts!


Peter.

Return address is invalid to help stop junk mail.
E-mail replies to z80@digiserve.com.
Article: 7020
Subject: Re: VHDL Synthesis in Xilinx Foundation Series
From: garyk@svpal.svpal.org (George Noten)
Date: 23 Jul 1997 20:18:02 GMT
Links: << >>  << T >>  << A >>
A.C.Rochat (arjan.rochat@pi.net) wrote:
: If you are planning to use version 2.2 or earlier, forget it.

: The Foundation package contains software by Xilinx and Aldec.

: The Aldec part (VHDL, Schematic capture, simulation) has a very fancy
: GUI and fancy functionality, but it simply does not work.

: The Aldec software performed so bad that we decided to halt the project
: altogether.

: Now, a jear later i am planning to take the project up again, if there
: is goed software
: available and Xilinx is willing to give it to mee free. (Yes _FREE_!
: Xilinx owes me one!)

: Positive notes:
: The software written by Xilinx themselves is OK.
: The support from the Xilinx distributor here in Holland is realy
: exelent!!

This reminds me very much of my own experience with Viewlogic PROseries.
The only good part of it was the beta-test version of Speedwave simulator.
The synthesis just did not work.  Now I know that PRO-/View- synthesis
tools are not to be trusted.  You are telling me that neither is Aldec.
Can anybody recommend something that is good enough and does not cost
you your life savings?  What about the new VHDL synthesis tool from MINC?

	George.  
Article: 7021
Subject: Why fast message delete in this group?
From: "Peter Welten" <welten@miles.nl>
Date: 23 Jul 1997 20:24:53 GMT
Links: << >>  << T >>  << A >>
Hello fellow newsgroup users,

On 16-7-97 I posted a question in this newsgroup about selection criteria
for FPGA's and CPLD's.

Some of you kindly responded on 16 and 17-7-97 (Philip Freidin, Brian
Dipert (twice), L. Kumpa).

When I came to see if any answers were there (23/7/97, I'm a busy guy), all
these messages were apparantly deleted from the server, that is, I could
still see what messages had been posted, but the messages themselves were
gone.

Why?

Peter Welten
Article: 7022
Subject: Re: Why fast message delete in this group?
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 23 Jul 1997 17:40:36 -0700
Links: << >>  << T >>  << A >>
There is something strange going on here. 
I see only five postings in the whole week between July 9 and July 16.
Where is the killer ?

Peter Alfke
Article: 7023
Subject: Re: Why fast message delete in this group?
From: fliptron@netcom.com (Philip Freidin)
Date: Thu, 24 Jul 1997 05:36:15 GMT
Links: << >>  << T >>  << A >>
> why do articles dissapear so fast?
>Peter Welten

The life of articles in a news group is a function of you news
administration at your ISP. There is no central site for all news, it is
distributed and duplicated at thousands of sites. (the usenet news group
system was invented by disk drive manufacturers). There is an archive
of articles for this news group at:

  http://www.super.org:8000/FPGA/

where you can read my replies over and over again.

Philip  :-)

Article: 7024
Subject: Re: Why fast message delete in this group?
From: Tim Forcer <tmf@ecs.soton.ac.uk.nojunk>
Date: Thu, 24 Jul 1997 08:47:21 +0100
Links: << >>  << T >>  << A >>
Peter Welten wrote about being unable to see responses to his July 16
post "Selection Criteria for CPLD's/FPGA's"

Have a word with your service provider (NLnet?).  All news servers
retire posts after a given duration.  The duration will vary between
newsgroups and servers.  For instance, alt.binaries.* will expire
rapidly, but "local interest" (eg nl.* in your case) may be kept for
weeks or months.  The providers aren't trying to make the net ephemeral,
it's just they have to manage a vast number of bytes represented by up
to hundreds of posts per day on a quite enormous number of newsgroups.

Try to convince your service provider that comp.* groups are
responsible, don't get binaries posted to them, and don't contain porn
(although we seem to get as much spam porn adverts as most - but that's
another problem).  They may then increase the hold time.

For more info on things like this, look at
<news:news.announce.newusers>.

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


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

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

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

Custom Search