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 14950

Article: 14950
Subject: Re: Xilinx ABEL?
From: "Joel Kolstad" <JKolstad@Electroglas.Com>
Date: Fri, 26 Feb 1999 11:31:45 -0800
Links: << >>  << T >>  << A >>
ibaggett@bagotronix.com wrote in message
<36d5f498.70312347@news.nettally.com>...
> I have yet to find a good
>tutorial on VHDL - the textbooks I've seen are written by people who
>are gurus but obviously have never designed actual hardware to fit
>into real FPGAs to go into real products.

It is difficult to learn VHDL from many textbooks.  There are some decent
textbooks aimed at VHDL for beginers, and then there are some decent
textbooks aimed at experts, but briding the gap can be difficult if you
don't already know some VHDL expert or have some format instruction.

>Supposedly VHDL has applicability to other areas besides digital
>logic, so is touted as the "holy grail" of description languages.

Some people would tout Verilog as the holy grail. :-)

> All I want to do is synthesize digital logic for real parts.

How complex are those parts?  One of the really significant benefits of VHDL
is that you can write very sophisticated test benches within VHDL itself.
It is far more powerful than the simple "test vector" facility that ABEL
provides.  (I realize that most vendors can provide some other means more
sophisticated than this for testing, but do you really want to learn another
tool to do it?)

I can't begin to imagine doing something like a PCI master in ABEL --
testing it would be a nightmare.

>Just remember, market forces are bigger than you are, and the market
>forces say "VHDL" :-(

I really think this is because designers are being asked to design more and
more complex designs, and ABEL just can't handle those "million gate
designs" that the trade magazines like to reference.

---Joel Kolstad



Article: 14951
Subject: Virtex multiplication
From: ldoolitt@recycle.jlab.org (Larry Doolittle)
Date: 26 Feb 1999 20:28:57 GMT
Links: << >>  << T >>  << A >>
I stared at the data sheet [1] for the Virtex long enough to figure out
how the Carry Chain works on the Logic Cell (hint for anyone who has as
much trouble as I did: configure the LUT as an XOR of F1 and F2, then
look carefully at the mux labelled "CY" in figure 5).

Now I'd like to understand how this part is supposed to do multiplications
effectively.  They say it several times.
On page 1:
"* Flexible architecture that balances speed and density
   - Dedicated carry logic for high-speed arithmetic
   - Dedicated multiplier support
   - Cascade chain for wide-input functions"
On page 2 (Table 2):
"Pipelined Multiplier        8 x 8            5.1 ns
                            16 x 16           6.0 ns"
On page 8:
"The arithmetic logic includes an XOR gate that allows a
 1-bit full adder to be implemented within an LC. In addition,
 a dedicated AND gate improves the efficiency of multiplier
 implementation."
On page 30:
"Multiplier Operation                         TBYP     0.1  0.2  0.2 ns, max
 F1/2 operand inputs to XB output via AND     TFANDXB  0.4  0.5  0.6 ns, max
 F1/2 operand inputs to YB output via AND     TFANDYB  0.5  0.6  0.6 ns, max
 F1/2 operand inputs to COUT output via AND   TFANDCY  0.5  0.5  0.6 ns, max
 G1/2 operand inputs to YB output via AND     TGANDYB  0.4  0.4  0.5 ns, max
 G1/2 operand inputs to COUT output via AND   TGANDCY  0.4  0.4  0.5 ns, max"

That last section give some clues, but I don't have the big picture yet.
Has anyone else looked at this?

       - Larry Doolittle   <ldoolitt@jlab.org>

[1] http://www.xilinx.com/partinfo/virtex.pdf, January 27, 1999 (Version 1.2)
Article: 14952
Subject: Re: JTAG HANG UP......
From: ying@soda.CSUA.Berkeley.EDU (Ying C.)
Date: 26 Feb 1999 21:17:23 GMT
Links: << >>  << T >>  << A >>


I have heard that for some reason, pulling both TMS and TCK low can also
cause a problem (not sure why or how). If I remember correctly, it's best
to pull TCK low and TMS high to prevent false clocking.

Ying


In article <36D5EEBD.EEC7DCA@erols.com>, Jim  <jok@erols.com> wrote:
>I think in this particular glitch the part relied on a 
>power up reset based on ramp voltage of the Vdd. I will not mention
>vendor, but it appears to save pins they neglected to provide
>a specific reset pin, but recomend pulling both clk and data high.
>But, if race between clk and data... and clk wins we get 0 into
>jtag controller. The solution was to pull them low during power
>up.
>
>Mike H. wrote:
>> 
>> Jim wrote in message <36D4AA69.E95CB74@erols.com>...
>> >Any folks run into any JTAG gotchas with pulling up the
>> >tdi and tclk pins?
>> 
>> The only problems I've experienced have been with the
>> /TRST pin, which seems to be interpreted differently
>> by different devices. Some like it pulled up when the
>> JTAG port isn't being used, some like it pulled down.
>> Can lead to operational inconsistencies.
>> 
>> Mike H.


Article: 14953
Subject: Re: Xilinx 9500XL
From: Stephanie Tapp <stapp@xilinx.com>
Date: Fri, 26 Feb 1999 13:34:23 -0800
Links: << >>  << T >>  << A >>



Bill wrote:

> I'm using 95144XLTQ100 and have found that 1.5i+sp1+cpld_020799 still don't
> produce correct jedec files. Simulation and verification produce OK results.
>
> The main problem is that FDCE is now a primitive in XL (it wasn't in the 5V
> parts)and when loaded into an XL produces a 1 on the ouput continuously.
> Implementing FDCE using an FD and M2_1 is OK.
>
> Anybody else got this problem and are there any more I don't know about ?
>
> Bill

 Bill,

There is currently a fix being tested that will have what you need for the
95144XL jedec
creation.  This will be available by the end of next week.  The known issue
addressed
with this upcoming patch as you mentioned affects only the new 9500XLs and not
the 9500
family.  M2_1 also has these changes.

Best Regards,
Stephanie

--
 _____________________________________________________________
|  _                                                          |
| / /\/   Stephanie Tapp (stapp@xilinx.com)                   |
| \ \  /  Xilinx                                              |
| / /  \  2100 Logic Drive                                    |
| \_\/\   San Jose, California 95124-3450 USA                 |
|         phone:408-559-7778                                  |
|         fax:408-879-4442                                    |
|_____________________________________________________________|





Article: 14954
Subject: Re: Xilinx ABEL?
From: "Austin Franklin" <austin@8darkroom.com>
Date: 26 Feb 1999 22:31:20 GMT
Links: << >>  << T >>  << A >>
> I can't begin to imagine doing something like a PCI master in ABEL --
> testing it would be a nightmare.

Why do you say that?  The state machines are very simple, in fact, I've
done it with no problem at all in  ABEL, VHDL, and schematic.   It is the
timing of the PCI input signals that makes ANY PCI master difficult...and
you will have that same problem no matter what the design tool you choose. 
That may be a bad example.

> I really think this is because designers are being asked to design more
and
> more complex designs, and ABEL just can't handle those "million gate
> designs" that the trade magazines like to reference.

I don't know about you, but no matter WHAT tool I am using, I try to break
down the task in to smaller pieces, so they are less complex and easier to
implement.  I think 100 pages of VHDL is easily as obtuse (if not more so
;-) than 100 pages of ABEL.  VHDL is tremendously more powerful than ABEL,
but that doesn't mean you can't do a very good job with ABEL, if you use
the tool appropriately.

Austin Franklin
austin@darkroom.com

Article: 14955
Subject: Re: Virtex multiplication
From: Ray Andraka <randraka@ids.net>
Date: Fri, 26 Feb 1999 18:19:34 -0500
Links: << >>  << T >>  << A >>
If you look at the carry chain, that little AND gate that can be selected for the
carry is not needed for addition/subtraction and increment/decrement.  Program
the LUT with A xor B.  That provides the partial bit sum, which is then summed
with the carry in by the dedicated XOR.  The partial sum also operates the carry
mux: if it is a 1 it selects the carry chain input (if the partial sum is 1 then
one and only one of the A and B inputs are 1, so the carry out is the same as
carry in).  If the partial sum is zero, then either both A and B are 0 or both A
and B are 1, so one of them (it doesn't matter which) is fed to the carry out so
that if it is one there is a carry out generated.  So that little AND gate is not
needed for regular operations.

Now, that AND gate is added to 'make multiplication more efficient'.  It does
that if you are implementing an array multiplier in row ripple form (which is
probably what you will get if you give a synthesizer A*B).  In that case, the LUT
should be programmed with (X&Y)^S where X and Y are the bit inputs to be
multiplied and S is the partial sum from the previous row.  If that gate were not
there, then it would have to be implemented in another LUT, which would be quite
inefficient.

OK, so that is how a multiplier is supposed to be more efficient in virtex.  You
can still improve on that multiplier's area and performance by going with a
computed partial product multiplier implemented as shown on my web-site.  Funny
thing, is last time I looked at the LogicCore output for 4K, the tool generates
the computed partial product multiplier.  That means that someone in Xilinx
understands the efficiencies.  Whoever designed the Virtex carry chain probably
didn't though.  The pipelined partial product multiplier has similar speed
characteristics and a log(n) clock latency instead of an n-clock latency.  The
fact of the matter is either type of multiplier can be constructed in xilinx
4K...The array multiplier uses a conditional adder that either adds the row or
passes the partial sum unchanged instead of an adder with an AND gate on the
input.  This still only requires a logic depth of 1 CLB per row!

The worst part, is Xilinx apparently rearranged the carry chain in order to be
able "support efficient multipliers".  Unfortunately, they lost a lot of
non-arithmetic capability in the process (see my previous post), including a very
compact bargraph circuit (used in priority encoding and framing logic).  The new
carry architecture also forces you to use the LUT if you want to use the carry
chain.  The 4K carry chain can be used independently of the LUT, which is handy
for a compare like that used in doing a limiter or 2's complement.


Larry Doolittle wrote:

> I stared at the data sheet [1] for the Virtex long enough to figure out
> how the Carry Chain works on the Logic Cell (hint for anyone who has as
> much trouble as I did: configure the LUT as an XOR of F1 and F2, then
> look carefully at the mux labelled "CY" in figure 5).
>
> Now I'd like to understand how this part is supposed to do multiplications
> effectively.  They say it several times.
> On page 1:
> "* Flexible architecture that balances speed and density
>    - Dedicated carry logic for high-speed arithmetic
>    - Dedicated multiplier support
>    - Cascade chain for wide-input functions"
> On page 2 (Table 2):
> "Pipelined Multiplier        8 x 8            5.1 ns
>                             16 x 16           6.0 ns"
> On page 8:
> "The arithmetic logic includes an XOR gate that allows a
>  1-bit full adder to be implemented within an LC. In addition,
>  a dedicated AND gate improves the efficiency of multiplier
>  implementation."
> On page 30:
> "Multiplier Operation                         TBYP     0.1  0.2  0.2 ns, max
>  F1/2 operand inputs to XB output via AND     TFANDXB  0.4  0.5  0.6 ns, max
>  F1/2 operand inputs to YB output via AND     TFANDYB  0.5  0.6  0.6 ns, max
>  F1/2 operand inputs to COUT output via AND   TFANDCY  0.5  0.5  0.6 ns, max
>  G1/2 operand inputs to YB output via AND     TGANDYB  0.4  0.4  0.5 ns, max
>  G1/2 operand inputs to COUT output via AND   TGANDCY  0.4  0.4  0.5 ns, max"
>
> That last section give some clues, but I don't have the big picture yet.
> Has anyone else looked at this?
>
>        - Larry Doolittle   <ldoolitt@jlab.org>
>
> [1] http://www.xilinx.com/partinfo/virtex.pdf, January 27, 1999 (Version 1.2)



--
-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: 14956
Subject: Re: JTAG HANG UP......
From: Ray Andraka <randraka@ids.net>
Date: Fri, 26 Feb 1999 18:21:48 -0500
Links: << >>  << T >>  << A >>
Holding either one high during configuration prevents the JTAG controller
being accidentally activated.  If TMS is low and TCK is toggled, the
controller could activate and screw up the configuration.

Ying C. wrote:

> I have heard that for some reason, pulling both TMS and TCK low can also
> cause a problem (not sure why or how). If I remember correctly, it's best
> to pull TCK low and TMS high to prevent false clocking.
>
> Ying
>



--
-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: 14957
Subject: Re: Virtex multiplication
From: Ray Andraka <randraka@ids.net>
Date: Sat, 27 Feb 1999 00:35:11 -0500
Links: << >>  << T >>  << A >>
Well, Looks like I was all wet on this one!

The AND gate doesn't buy you anything in the row ripple form except on the first
row.  In the row ripple form, each full adder has an AND gate on one input.  If you
put that on the A input and feed the B input to the carry MUX, the AND gate is not
needed.

So why is it there?  Well, it turns out (which I finally realized after a gentle prod
from a person polite enough not to flame me here) that if you use the AND in the
carry logic, you can sum two bit products in half a slice.  The first product's AND
is buried in the LUT as mentioned above.  The second has to go on the B input.  If
the AND weren't there, then the second AND would have to be in another LUT.  With it
there, the LUT should be programmed with (X1&Y1)^(X0&Y0) so that the column of LUTs
sums two 1xN partial products (rows) to arrive at a 2xN partial product.  These
partials are then combined in an adder tree the same way I do for the computed
partial product multiplier I described previously.  The efficiency comes in when you
realize that the mux in my  computed partial product design requires a 5 LUT to
implement, which means that it takes up more than half a slice (or 4K CLB).  The
little AND gate and the new carry architecture allow you to compute each bit of the
2xN partial product in a 4LUT, so the size of the partial products is halved.
Computing the partial products is a little more than  half the multiplier's overall
size in the 4K, so cutting the PP size in half is worth quite a bit.

So there is the real truth about the efficient multiplier.  Mrrmmph.  I hear crow
might taste good cooked like buffalo wings.  I still will miss the flexibility of the
4K carry chain though (whining mode).

Ray Andraka wrote:

> A major rant about the virtex carry chain with a hastily drawn conclusion.

--
-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: 14958
Subject: Foundation V1.5 Crash
From: "David Langmann" <david@dalanco.com>
Date: Sat, 27 Feb 1999 11:36:57 -0500
Links: << >>  << T >>  << A >>
Hello,

I am new to this program, so maybe you can tell me
what I'm doing wrong.

Each and every time I run the MAP program
(by hitting the Implementaton button) I get the GPF
error. See log excerpt below. It doesn't matter which
project I'm running.

The PC is a Pentium 166 with 128 Meg.

Many thanks,
David Langmann
david@dalanco.com



NGDBUILD Design Results Summary:
  Number of errors:     0
  Number of warnings:   4

Writing NGD file "filter.ngd" ...

Writing NGDBUILD log file "filter.bld"...

NGDBUILD done.

==================================================

map -p xc4003e-4-pc84 -o map.ncd filter.ngd filter.pcf
map:  version M1.5.25
Copyright (c) 1995-1998 Xilinx, Inc.  All rights reserved.

PROGRAM ABNORMALLY TERMINATED


Article: 14959
Subject: newbie questions
From: francesco l spadini <spadini@students.uiuc.edu>
Date: Sat, 27 Feb 1999 15:45:52 -0600
Links: << >>  << T >>  << A >>
	OK, here are some REALLY basic questions I have about programmable
logic.  What is the difference between an FPGA and a CPLD?  I know that
with schematic capture or VHDL software, one can compile code and  
download it into a programmable logic device through a parallel port, but
what sort of additional hardware is needed to interface between the port
and chip?  Lastly, what other good sources (urls or book titles would be
much appreciated) would you recommend for learning more about programmable
logic and VHDL.  Thanks in advance...


---------------------------------------------
Francesco Spadini
Department of Electrical and Computer Engineering
University of IIlinois at Urbana Champaign
spadini@uiuc.edu

"Nec vitia nostra nec remedia pati possumus"
---------------------------------------------

Article: 14960
Subject: Re: Problem with xilinx M1
From: Andy Peters <apeters@noao.edu>
Date: 27 Feb 1999 16:45:21 PST
Links: << >>  << T >>  << A >>
Sergio A. Cuenca Asensi wrote:
 
> Yes, I've synthesized all three as top-level modules.  I want three independent
> modules but without starpup blocks, the problem is that I can't find any option
> in FPGA express to avoid startup adding to them. Do you know where is it?

I'm not sure you can have a chip with more than one top-level module!

Why would you want to do that????

-andy
Article: 14961
Subject: Re: Where do I connect my reset pins to?
From: Andy Peters <apeters@noao.edu>
Date: 27 Feb 1999 16:57:51 PST
Links: << >>  << T >>  << A >>
Joel Kolstad wrote:

> From what you say, it sounds safe to do any of the following:
> 
> -- Ground the reset pin on the macro
> -- Leave it floating (probably a bad practice, though, from the
> documentation point of view)
> -- Connect it to the reset output of the startup block
> 
> In the first two instances, nothing will get routed to the 'flops reset/set
> line and only GSR will be able to reset/set it.  In the last instance, PAR
> should be smart enough to figure out that resetting/setting a flop from GSR
> itself is redundant and realize that actually consuming routing resources to
> connect to the reset/set on the 'flop is unnecessary.

Connecting the macro's reset line to the GSR output tells PAR to use the
global reset nets for all flops connected to that reset line.
 
> If I did have an external reset, I believe the correct thing to do would be
> to connect it to the startup block.  The wrong thing to do would be to
> connect it directly to the macros' reset inputs, since then the reset
> connections would consume routing resources.
> 
> Is that correct?

that is correct.

a
Article: 14962
Subject: Re: Foundation V1.5 Crash
From: Andy Peters <apeters@noao.edu.nospam>
Date: 27 Feb 1999 17:02:26 PST
Links: << >>  << T >>  << A >>
David Langmann wrote:
> 
> Hello,
> 
> I am new to this program, so maybe you can tell me
> what I'm doing wrong.
> 
> Each and every time I run the MAP program
> (by hitting the Implementaton button) I get the GPF
> error. See log excerpt below. It doesn't matter which
> project I'm running.


A-ha!  I've had the same problem.  There's a bug somewhere.  Once I got
ahold of the right tech support person at Xilinx, I was able to get a
patch.  If you can wait until Monday, I will e-mail the patch to you.

I was able to find a workaround, which was simply changing the order of
parameters passed to the map program.  The patch fixes it.

-andy
Article: 14963
Subject: Re: Your view on this article?
From: Nick Hartl <nickhartl@earthlink.net>
Date: Sat, 27 Feb 1999 18:18:33 -0800
Links: << >>  << T >>  << A >>
This particular article has really made the rounds!  I have received it from
several sources now, so there must be something here that everyone feels
important.

What is the message in this article, the imminent demise of the FPGA
industry?  I think not.  The fact one person from one customer, Cisco,
thinks that in the future
Cisco will use a higher ratio of ASICs to FPGAs then it does at present does
not spell the end of an industry.  It only stands to reason and should not
come as a great surprise that Cisco is projecting this change.  Cisco is a
classic Silicon Valley success story.  When the market was small but very
dynamic FPGAs were the best answer to the problem of how to get new
innovative solutions out the door quickly.  As Cisco develops more of it's
products will be very high volume standard products, a natural ASIC
situation.

So because one very high volume FPGA customer is going to be buying ASICs in
the future does this mean the end of programables?  What about the other
start-ups?  Will Cisco be the last Silicon Valley start up?  Will these
start-ups open their shops and immediately have the kind of volumes and
product sophistication to go to market with ASICs?  No they won't, rather
they will follow the same path as others to very high volume, they will
start with programables.  So there are new customers coming every day, the
fact that one matured to ASICs is not a bad thing for the industry rather it
should be taken as a fantastic example of how using FPGAs can lead to
industry domination.

For that matter while Cisco will have a higher percentage of very
established standard products built from ASICs in their product mix, I do
not see them giving up on attempts to innovate within the industry and what
technologies will they first test out their innovations with???
Programables.  My personal bet is that Cisco will be a high volume buyer of
programmable logic for a long time.  In the future it is possible that as a
percentage of Cisco’s total semi conductor purchases the ratio could change
more to ASICs, Cisco will still buy a whole lot of programables.

The article also brings up the possibility that in the future programmable
logic will have different and improved functionality then it does now?  Of
course it will!  The I/C industry is the fastest changing most dynamic
industry ever seen in this world, as part of the IC industry programmable
logic has lead even this dynamic industry in innovation.  So to say that
there is change on the horizon in the FPGA market is equivalent to making an
announcement that the sun will come up in the east tomorrow.  It is correct
statement but with enough past history that this should not come as a
surprise to even the most casual observer.

The only real question of interest in the whole article is the projections
of the future of programables.  Programables has gotten to the point where
past practice of product innovation, adding more logic then the last
generation of the product, is not enough to maintain industry leadership.
Features such as clock control circuits and embedded memories are becoming
standard in the latest programables.  This trend of increasing features as
well as increasing speed and density is bound to continue.

Many companies are talking about hard microprocessor cores within an FPGA
part; Lucent is all ready offering a hard PCI core with their FPGAs.  What
is the right mix?  A little bit of hard logic and a lot of programmable
logic on a chip, or the alternative that is mentioned in this article mostly
custom hard ASIC with a small programmable core on the die?  Is this even
practical?  Process technology drives everything in the semiconductor
industry; I have seen comments stating that from a process point of view
hard ASICs with FPGA blocks on board could be a non-cost effective solution.

I am sure I can find some proponent to argue each and every side of this
technology debate, as the future of the industry is something that will
effect us all and future is very hard to be sure of in something as dynamic
as the high tech biz.

I still have not figured out why this particular story went around like it
did.  Maybe we all just like to hear that the superstar has something bad in
their future.  Doom and gloom sells a lot of TV time after all.

Have FUN!!!!
Nick

Zhen Luo wrote:

> Hi,
>
> I read the following article on EE times today. What do you think about
> it? I think the problems they mention in this article have always been
> there, but it seems that this is the first time people really use the
> word "dark future" for programmable logic. What do you think?
>
> -- Zhen
>
>                    FPGA'99: Panel glimpses dark future for
>                    programmable silicon
>
>                    By Ron Wilson
>                    EE Times
>                    (02/23/99, 11:19 a.m. EDT)
>
>                    MONTEREY, Calif. — A panel at FPGA'99 here Monday
> (Feb. 22)
>                    peered into the future of FPGAs in the era of
> system-level ICs and saw
>                    deep shadows. While FPGA-vendor panel members touted
> the ability of
>                    huge new FPGAs to easily absorb large pieces of
> intellectual property (IP),
>                    or for hard IP macros to be integrated onto FPGA
> dice, panelists from the
>                    research and user communities saw things very
> differently.
>
>                    In opposition to the notion that you can simply put
> an entire system-level
>                    design into an FPGA, University of Washington
> professor Carl Ebeling
>                    warned, "If all you have is a hammer, everything
> looks like a nail. But if we
>                    keep thinking that everything looks like it has an
> FPGA solution, we could
>                    get screwed."
>
>                    Beyond the initial levity, Ebeling warned that for
> many applications, it is
>                    simply not good enough for an FPGA to do tomorrow
> what an ASIC can
>                    do today. "The gaps in power consumption and
> performance between
>                    FPGAs and ASICs aren't narrowing, they are growing
> wider," he said.
>                    "And those gaps are pushing more and more high-end
> applications not
>                    toward FPGAs, but toward ASICs."
>
>                    Admitting that not everything can be done well in an
> FPGA, University of
>                    California Los Angeles professor Jason Cong said even
> adding some
>                    diffused hard cores to a chip doesn't solve the
> problems. Cong, whose
>                    influential work produced some of the first tools
> that could systematically
>                    map logic into the SRAM blocks on Altera Corp.'s Flex
> devices, warned
>                    that "the devil is in the software."
>
>                    "There are very substantial problems in creating
> design software for devices
>                    that include both FPGA and hard blocks," Cong said.
> "Among them, it is
>                    quite difficult to automatically partition an
> algorithm among heterogeneous
>                    resources, even such common resources as programmable
> logic and
>                    SRAM. If you can do the partitioning, it is difficult
> to optimize the
>                    implementation of parts of the algorithm on each kind
> of resource. And if
>                    you solve that problem, there are still very hard
> problems involved in
>                    run-time communication between different kinds of
> blocks, scheduling and
>                    the like."
>
>                    But if the arguments against incorporating either
> soft or hard IP into FPGAs
>                    were strong, the most sobering statements of the
> night came from a
>                    customer — a very influential customer.
>
>                    "We are a major consumer of FPGAs," said Bill Harris
> of Cisco Systems
>                    Inc. And Harris' data showed he was being modest.
> Cisco claims to be
>                    currently the largest single user of programmable
> logic, shipping over one
>                    million PLDs of various sorts per month.
>
>                    Once he had the audience's attention, Harris lowered
> the boom. "Despite
>                    that, I have to say that for large systems our trend
> is to ASICs, not to
>                    programmable-logic devices. On the systems that make
> up our platforms,
>                    we will spin an ASIC rather than use an FPGA."
>
>                    Harris explained that a major phase was over in the
> halcyon relationship
>                    between the networking industry and the FPGA
> business. "In the beginning,
>                    it was a small Cisco competing against other small
> companies.
>                    Time-to-market was everything, and cost wasn't an
> issue. If we could get
>                    the latest speed grade of an FPGA, we'd throw it in
> just so we could start
>                    shipping."
>
>                    But times are very different now in the industry,
> Harris said. "Now, we
>                    have established market share and established
> platforms. Customers aren't
>                    going to pull out our gear just because it takes a
> while for us to support a
>                    new feature. But there is intense price competition.
> We have the luxury of
>                    longer development times, but not the luxury of
> naming our own prices."
>
>                    These factors, Harris said, were gradually weaning
> Cisco from use of
>                    programmable logic in complex or high-volume
> applications. This, if it
>                    proves generally true, could be an enormous challenge
> to the growth of an
>                    FPGA industry that has been feasting at the table of
> the networking and
>                    communications companies for several years.
>
>                    But Harris wasn't through spoiling the evening for
> the FPGA vendors. "We
>                    have the resources and the tools now to do very
> high-performance,
>                    multi-million gate designs on single chips. One
> design we have in progress is
>                    approaching 20 million gates. FPGAs have neither the
> speed nor the
>                    density to approach this level.
>
>                    "When we need field programmability, what we would
> prefer is not to have
>                    a huge programmable device, or even a programmable
> device with a huge
>                    piece of hardware set down beside it. We would prefer
> to have an FPGA
>                    core to drop into our ASIC. We typically need small
> amounts of
>                    reconfigurable logic beside the fixed hardware.
>
>                    "Unfortunately, that doesn't seem to be the way the
> industry is moving,"
>                    Harris said. "I think first we will see FPGA vendors
> try to provide IP on
>                    their devices. But that's not what we'd like. If we
> could get an FPGA core
>                    for use in our ASICs today, we would be doing that
> already."
>
>                    The sum of the university and industry inputs from
> this very small but
>                    undeniably influential sample suggested bad news for
> the FPGA business.
>                    The strongest high-volume customers for FPGAs appear
> to be changing
>                    their buying habits. Increasingly, they are using
> ASICs instead of FPGAs.
>                    And when they need programmable logic, they intend to
> get it, if not from
>                    their ASIC vendor, at least as third-party IP, not as
> silicon. If this
>                    foreshadowing becomes a trend, it could force a major
> shift in business
>                    models for the largest programmable-logic vendors.


Article: 14964
Subject: Re: Foundation V1.5 Crash
From: Jeff Hunsinger <huns@mediaone.net>
Date: Sat, 27 Feb 1999 20:20:35 -0600
Links: << >>  << T >>  << A >>
I had the same problem. The order of operators following 'map' is what's
doing it.

Instead of:
map -p xc4003e-4-pc84 -o map.ncd filter.ngd filter.pcf

Use:
map -p xc4003e-4-pc84 filter.ngd filter.pcf -o map.ncd 

In other words, just move the -o outfile.ncd to the end of the
statement. I'm not sure how to do this under the GUI, since I quickly
gave up on it and just run the whole thing from the command line with a
make file.

--

Jeff
Article: 14965
Subject: MAXPlus Muti-chain JTAG problem
From: Bill Moffitt <compass@connect.net>
Date: Sun, 28 Feb 1999 10:15:18 -0600
Links: << >>  << T >>  << A >>
Hello,

I have two altera devices on a board, one MAX7000S and one 10K50E.

Both are on the JTAG chain (max7000 tdo feeds 10k tdi - ie the MAX7000
is the first device in the chain).

I'm using the JAM language to program the 10k upon power-up.

What I can't figure out is how to creat the jam byte code file to do
this.  Do I have to create a Multi-jtag chain file and if so, then how
do I insert instructions into the file so as NOT to program the
MAX7000S?

All help at this point is greatly appreciated!


--
Bill Moffitt

Article: 14966
Subject: Over 1400 semiconductor links!
From: Webmaster <webmaster@boin-gmbh.com>
Date: Sun, 28 Feb 1999 11:23:30 -0800
Links: << >>  << T >>  << A >>
Please visit http://www.boin-gmbh.com/linkpage/linkpage.htm
Article: 14967
Subject: Re: newbie questions
From: "Sergio A. Cuenca Asensi" <sergio@dtic.ua.es>
Date: Mon, 01 Mar 1999 09:22:32 +0100
Links: << >>  << T >>  << A >>


francesco l spadini wrote:

>         OK, here are some REALLY basic questions I have about programmable
> logic.  What is the difference between an FPGA and a CPLD?  I know that
> with schematic capture or VHDL software, one can compile code and
> download it into a programmable logic device through a parallel port, but
> what sort of additional hardware is needed to interface between the port
> and chip?  Lastly, what other good sources (urls or book titles would be
> much appreciated) would you recommend for learning more about programmable
> logic and VHDL.  Thanks in advance...
>
> ---------------------------------------------
> Francesco Spadini
> Department of Electrical and Computer Engineering
> University of IIlinois at Urbana Champaign
> spadini@uiuc.edu
>
> "Nec vitia nostra nec remedia pati possumus"
> ---------------------------------------------

VHDL for programmable logic. Kevin Skahill (Addison Wesley)
The practical Xilinx designer handbook. Dave Vanden Bout (Prentice Hall)
Very good books for beginners.



--
===================================================================
Sergio A. Cuenca Asensi
Dept. Tecnologia Informatica y Computacion (TIC)
Escuela Politecnica Superior, Campus de San Vicente
Universidad de Alicante
Ap. Correos 99, E-03080 ALICANTE
ESPAÑA (SPAIN)
email   : sergio@dtic.ua.es
Phone : +34 96 590 39 34
Fax     : +34 96 590 39 02
===================================================================


Article: 14968
Subject: Re: Problem with xilinx M1
From: "Sergio A. Cuenca Asensi" <sergio@dtic.ua.es>
Date: Mon, 01 Mar 1999 11:14:36 +0100
Links: << >>  << T >>  << A >>


Andy Peters wrote:

> Sergio A. Cuenca Asensi wrote:
>
> > Yes, I've synthesized all three as top-level modules.  I want three independent
> > modules but without starpup blocks, the problem is that I can't find any option
> > in FPGA express to avoid startup adding to them. Do you know where is it?
>
> I'm not sure you can have a chip with more than one top-level module!
>
> Why would you want to do that????
>
> -andy

I am using FPGA Express v2.0 and Xilinx Foundationv1.4. We use mixed mode entry
(schematic+vhdl), really I don't want three top-level modules but it is the only way
to synthetize an independent module in Express. The idea is create a "library" of
synthesized vhdl modules, then I could instantiate the macros like a component from
the schematic.
But the problem is that every module synthetized include a startup, so I only can
instatiate a module. I have to integrate all vhdl files of the design in a top-level
module and sinthesize again.
Regards

===================================================================
Sergio A. Cuenca Asensi
Dept. Tecnologia Informatica y Computacion (TIC)
Escuela Politecnica Superior, Campus de San Vicente
Universidad de Alicante
Ap. Correos 99, E-03080 ALICANTE
ESPAÑA (SPAIN)
email   : sergio@dtic.ua.es
Phone : +34 96 590 39 34
Fax     : +34 96 590 39 02
===================================================================


Article: 14969
Subject: Re: synlibs for XC40150XV Synopsys fpga_shell
From: Robert Ayre <rayre@nortelnetworks.com>
Date: Mon, 01 Mar 1999 13:06:58 +0000
Links: << >>  << T >>  << A >>
Brian Schott wrote:

>SNIP
> What's up?  I can target a 4085, but can't target anything bigger?  What's
> the trick?  I've been all over the Xilinx and Synopsys pages with no luck.
 

I had a similar problem, the Xilinx FAE told me to use the 4085
libraries, I've been doing this, and have produced real chips which are
working on the bench - so give that a shot.

I'm also using the Synopsys/Alliance route, and targetting an
XC40150XV-09.

Robert

Article: 14970
Subject: Re: JTAG HANG UP......
From: Brian Boorman <XZY.bboorman@harris.com>
Date: Mon, 01 Mar 1999 09:02:11 -0500
Links: << >>  << T >>  << A >>
The IEEE spec for JTAG (1149) says that devices should pull up the JTAG
pins internally (to be compliant). Pulling them down externally could
cause problems if you are not carefull.

Shame on the vendor for not holding the TAP in reset until after power
is stable!

Ying C. wrote:
> 
> I have heard that for some reason, pulling both TMS and TCK low can also
> cause a problem (not sure why or how). If I remember correctly, it's best
> to pull TCK low and TMS high to prevent false clocking.
> 
> Ying
-- 
Brian C. Boorman
Harris RF Communications
Rochester, NY 14610
XYZ.bboorman@harris.com
<Remove the XYZ. for valid address>
Article: 14971
Subject: Re: JTAG HANG UP......
From: Ray Andraka <randraka@ids.net>
Date: Mon, 01 Mar 1999 10:12:32 -0500
Links: << >>  << T >>  << A >>
The problem is not during the powerup sequence, it is after the power is stable
while the device is re/configuring.  Xilinx correctly holds the TAP in reset
until the power is stable.  The devices are designed to allow the configuration
to be done in the conventional manner or through the JTAG controller.  The
problem comes in if you allow the TMS and TCK pins to toggle during a
conventional  configuration, you could trigger the JTAG controller and end up
corrupting the bit stream.  Those pins are internally pulled up in the Xilinx
device, but they can be used as general purpose I/O after the device is
configured.  It is incumbent upon the user to make sure that if these pins are
used for general I/O in the design, that they are held at a logic 1 during
configuration to avoid activating the internal JTAG controller.  Note that the
xilinx parts are often used in applications with no JTAG, and even (or
especially) in those cases the levels on these two pins need to be accounted
for.

Brian Boorman wrote:

> The IEEE spec for JTAG (1149) says that devices should pull up the JTAG
> pins internally (to be compliant). Pulling them down externally could
> cause problems if you are not carefull.
>
> Shame on the vendor for not holding the TAP in reset until after power
> is stable!



--
-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: 14972
Subject: Re: newbie questions
From: "Steven K. Knapp" <sknapp@optimagic.com>
Date: Mon, 1 Mar 1999 07:27:20 -0800
Links: << >>  << T >>  << A >>
You might find the links on The Programmable Logic Jump Station useful at
http://www.optimagic.com.

For example:
===========

CPLD/FPGA Comparison:  http://www.optimagic.com/comparison.html

General overview of architectures:
http://www.optimagic.com/faq.html#What_Kinds

Books:  http://www.optimagic.com/books.html

-----------------------------------------------------------
Steven K. Knapp
OptiMagic, Inc. -- "Great Designs Happen 'OptiMagic'-ally"
E-mail:  sknapp@optimagic.com
   Web:  http://www.optimagic.com
-----------------------------------------------------------



francesco l spadini wrote in message ...
> OK, here are some REALLY basic questions I have about programmable
>logic.  What is the difference between an FPGA and a CPLD?  I know that
>with schematic capture or VHDL software, one can compile code and
>download it into a programmable logic device through a parallel port, but
>what sort of additional hardware is needed to interface between the port
>and chip?  Lastly, what other good sources (urls or book titles would be
>much appreciated) would you recommend for learning more about programmable
>logic and VHDL.  Thanks in advance...
>
>
>---------------------------------------------
>Francesco Spadini
>Department of Electrical and Computer Engineering
>University of IIlinois at Urbana Champaign
>spadini@uiuc.edu
>
>"Nec vitia nostra nec remedia pati possumus"
>---------------------------------------------
>


Article: 14973
Subject: Virtex development boards
From: Daryl Bradley <dwb105@ohm.york.ac.uk>
Date: Mon, 01 Mar 1999 15:56:03 +0000
Links: << >>  << T >>  << A >>
Has anyone in the UK purchased Virtex development boards + associasted
software, under educational purchase terms?

Does anyone have any suggestinos of companies that will supply the
products in the UK?

Many thanks

Daryl Bradley

Dept. Electronics
University of York

Article: 14974
Subject: Verilog FAQ
From: rajesh52@hotmail.com
Date: Mon, 01 Mar 1999 17:04:37 GMT
Links: << >>  << T >>  << A >>
Greetings
This is semimonthly announcement of Verilog FAQ.

Verilog FAQ is located at
http://www.angelfire.com/in/verilogfaq/

Alternate Verilog FAQ is an attempt to gather the answers to most
Frequently Asked Questions about Verilog HDL in one place. It also
contains list of publications, services, and products.

Alternate Verilog FAQ is divided into three logical parts.

Part 1 : Introduction and misc. questions
Part 2 : Technical Topics
Part 3 : Tools and Services

What's New section outlines the changes in different versions and
announcements.
Links connects you to related informative links in internet.


Rajesh Bawankule
(Also Visit Verilog & EDA Page :
http://www.angelfire.com/in/rajesh52/verilog.html )

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    


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