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 15350

Article: 15350
Subject: Xilinx Makefile?
From: "Bruce Nepple" <brucen@imagenation.extra.com>
Date: Fri, 19 Mar 1999 13:00:15 -0800
Links: << >>  << T >>  << A >>
I miss the old makefile days.  Type one command and come back later.  No
fear as to whether the software will decide to consider your latest changes
or not!

I would really like a sample makefile if someone is willing to share one
that worked for them.

bruce


Thomas LeMense wrote in message <36f25a84.990037@tnn-wan.trw.com>...
>On Fri, 05 Mar 1999 16:21:00 -0500, Brian Boorman
><XZY.bboorman@harris.com> wrote:
>>Since I also scrapped the gui in favor of an automatic batch file, I am
>>beginning to wonder how many others have done the same thing. Since I
>
>>Jeff Hunsinger wrote:
>><snip>
>>> .....I quickly
>>> gave up on it and just run the whole thing from the command line with a
>>> make file.
>>>
>
>I wish I knew enough about make to write a good, robust makefile.
>(Yes, as a matter of fact I *DO* live in the stone age!)  Any chance
>of either of you sharing what you've created with other c.a.fpga
>readers?  I wholeheartedly agree that the GUI can be a real pain, and
>the version control is a bit ...er... strange at times.
>
>-tom
>
>Tom LeMense
>TRW Automotive Electronics
>Farmington Hills, MI facility
>lemenst@fhsmtp.fh.trw.com


Article: 15351
Subject: Re: Xilinx Vhdl "'event" synthesis problem
From: Jamie Morken <foster@uvic.ca>
Date: Fri, 19 Mar 1999 13:01:34 -0800
Links: << >>  << T >>  << A >>
Hi,

Thanks for the help!  When read_write = 0  b_bus_out is set to high
impedance.

Jamie Morken

Article: 15352
Subject: Re: Placement control in ALtera devices
From: Tom&Janet Engel <engel.tom.janet@sympatico.ca>
Date: Sat, 20 Mar 1999 00:12:57 GMT
Links: << >>  << T >>  << A >>
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
You can force as placement at the routing stage. It may or may not route
though. The bit stream is protected and only ALtera has info and will not
tell anybody anything about it.
<br>&nbsp;
<p>"Sebastia A. Bota" wrote:
<blockquote TYPE=CITE>Is possible to control the placement in Altera devices
(8282 or 10K10
<br>devices) In order to implement a logic circuit at an specific logic
<br>module of the FPGA ?
<p>Where can I find information about the format of the bitstream used
to
<br>program the device ?
<p>Thanks
<p>Sebastia</blockquote>
</html>

Article: 15353
Subject: Re: Power Estimiation - report.zip (0/1)
From: Tom Burgess <tom.burgess@hia.nrc.ca>
Date: Fri, 19 Mar 1999 16:49:14 -0800
Links: << >>  << T >>  << A >>
Stuart Clubb wrote:
<snipped>
> How about it Xilinx and Altera? Let's see a new slogan on those web
> sites: "Mines smaller than yours" (power consumption that is).
> 
They have already claimed as much in their marketing bumf.
I would rather see tools that allow me to accurately estimate how MY
designs would fare with their parts. Maybe the slogan could be
"I shoulda used the brand with the best power tools", accompanied
by a gritty image of a domicile-challenged person sleeping in
a cardboard box (Maybe a famous heavy-duty battery or laptop
computer brand on the box). I don't know if the recent depressing
Xilinx ad series went international or not, so the joke may be
lost on Europeans if they were lucky enough to have missed it.

> (Tom, whining about the cost of ModelSim Elite)
>
> >this exceeds my nonexistent tools budget by a couple of orders
> >of magnitude, but it does serve as an existence proof.
> 
> My condolences.
> 
> Cheers
> Stuart

I laughed out loud. In hindsight, I should have said "this exceeds
what I sometimes jokingly refer to as my 'tools budget' by at
least an order of magnitude", but the result is the same. 

regards, 
Tom Burgess

Article: 15354
Subject: Re: Bit Error Rate Test
From: "Juan-Luis Lopez" <jl.lopez@REMOVETHIS.ieee.org>
Date: Sat, 20 Mar 1999 02:03:14 +0100
Links: << >>  << T >>  << A >>
Dan escribió en mensaje ...

>I am looking for information on building a small Bit Error Rate Tester
>inside a Xilinx. [...]
>
>It would be simple to generate a pseudo-random pattern to transmit down the
>link, but I cannot think of an easy way to sync back up to the received
>data, and count errors.  I know this has been done before, I am just trying
>to avoid reinventing the wheel.

Hi, Dan

Take two identical PRBS generators, with a n bits long shift register each
(2^n-1 will be the total length of the PRBS). Put the first to work as a
generator of a PRBS. The output bitstream will be the test signal. Now lets
go to the second generator.

Disconnect the signal going to the D input of the first flip flop in the
chain, usually the output of an XOR gate. Lets call the XOR output the "next
bit prediction".

Feed the bitstream to the D input. Look the open output of the XOR and
compare it with the stream.

If the stream is a PRBS (or an all zeros signal) and there are no errors,
after n bits, both the XOR output and the stream will become identical.

If there is a single error in the bitstream, the XOR output and the
bitstream will become diferent. This is an error indication.

But for each single input error, you will get several error indications. The
first one belongs to a true error, but the remaining ones correspond to the
shift register being "contaminated" with the input error. There is an
aditional error for each tap in the shift register(error multiplication).

To avoid that the usual strategy is to begin with the receiver in such "open
loop" configuration, then wait until the input stream has a long secuence of
bits (m bits) without error and then close the feedback loop, avoiding the
"contamination" of the receiver shift register. When the loop is closed, the
receiver is said "on sync" and the measurement can start, comparing the XOR
output with the input stream and counting errors.

You have to put a 2 input mux in front of your first D input, to select from
the bitstream or from the XOR output. The control signal can be derived from
a counter that resets when there is an error and stops (and never again
reseting) after m bits without error. The same control signal can gate the
error counting.

How long has to be m depends on the probability you want of a false "sync"
in presence of a random signal. Any n bit long secuence (except the "all
zeros" one) can be found within the total 2^n-1 PRBS. But adding a single
bit, the odds of finding the new n+1 secuence in a PRBS will be 0.5, for two
bits will be 0.25 and so on. If you wait 32 aditional bits before declaring
"sync", the odds of a false trigger will be 1/(2^32), small enough for many
purposes, and your counter will only be 5 bit long.

To complete the state machine, you have to go from "sync" to "off sync" when
the stream is not anymore a PRBS. The usual criteria is a slip condition
(more on that later) or a very high bit error rate (0.2) for a long period
(1s). This is better a software implemented decision.

You also have to deal with the "all zeros" exception to the rule. The
easiest way is to put a n-wide NOR gate with its inputs connected to the n
outputs of the FFs, and adding an extra or gate to combine its output with
the XOR output. The new "next bit prediction" will say that after n
consecutive bits at zero, the next one should have to be a logical one. And
with an "all zeros" input, it will not be, and sync will not be gained.

And lastly, you can also detect a slip condition (extra o missing bits due
to false clocking) by looking at the error output. If a slip happened, the
error itself will be a PRBS again!, and as such, a second receiver connected
to it will say "sync". This bases on a property of PRBSs: The XOR
(comparison) of two PRBS delayed any number of bits (same polynomial, of
course) is again a PRBS with the same polynomial (or the "all zeros"
signal).

Hope this helps, Dan.

Juan-Luis Lopez Rodriguez
jl.lopez@REMOVETHIS.ieee.org
Spain



Article: 15355
Subject: Re: ALTERA pin assignment
From: sxyzamos@fake.com
Date: 20 Mar 1999 01:05:59 GMT
Links: << >>  << T >>  << A >>
Brett George <b.george@clarityeq.com> wrote:
> hi all,

> I'm sure this topic has come up before, and I assure you I know about
> deja-news.
> I have just finished an altera design (MAX7000), and about to layout the
> design in
> the schematic. I am quickly learning that I cannot assign the pins
> exactly where I
> would like, so I am forced to ask should I be assigning pins at all?
> If I desire some grouping, should I just specify the LAB I would like
> some
> outputs/inputs to be in?
> Does such decisions radically affect the timing of operation (and make
> it
> less reliable), or is it simply more difficult for the compiler to route
> a sol'n.

I used some 10k's for quite some time, and as long as the utilization 
wasn't very high (40% - 60%)  pins could be locked into place without 
any adverse effect.    With higher utilization (80%+) compile times 
tend to increase and the resulting code was sometimes running slower.
There were cases when the normally 1 - 2 hours long compilation took 
over several days.  (That could've been caused by a bug in Max+Plus II)
Above 90%+ occasional routing errors made life not so boring....  ;-)

My advice would be to postpone locking the pins as much as possible, 
and if you need to lock them in, make sure you have enough headroom. 
Depending on the complexity of your design, it may handle certain 
constraints reasonably well.   You can actually test the sensitivity 
of your design by trying different "pinouts" and see how it effects 
Max+Plus II.    

Another thing you may do (depending on volume and other constraints) 
is using the next bigger device if your utilization with the original 
FPGA is too high.   

> I foresee that if I do wish to have a consistent pin layout, I will have
> to lock
> all the pins into place, even if it is in the positions the compiler
> chooses.

> If some one can identify a question in this babble, or has any comments
> I would
> be interested to hear them.

Article: 15356
Subject: Re: FPGA vendor comparison
From: Ray Andraka <randraka@ids.net>
Date: Fri, 19 Mar 1999 20:56:25 -0500
Links: << >>  << T >>  << A >>
There is some of that available on the web at www.optimagic.com.  I've got
plans to put technical comparisons up, but so far haven't had the time.  The
best device depends on your application and other factors (not the least of
which is access to tools).

The following are my observations, so take them for what they are worth.  I
find that Xilinx 4K, and now virtex are hands down winners for DSP
applications because of architectural features that only xilinx offers.
Right now, the 4K is a better choice unless you need the new features in
Virtex.  That is only because the tools support and libraries are still not
as mature as those for the 4K.  The features that make xilinx better in DSP
applications are: 1) invoking the altera carry chain breaks the LUT in the
LE into a pair of 3LUTs, one for the carry and one for the 'sum'.  Both LUTs
share the same inputs and one of those inputs is the carry from the previous
LE.  That means that arithmetic elements are limited to 2 inputs.
Adder/subtractors, accumulators with clear or load and so on need two levels
of logic to implement in Altera's architecture.  2) There is no local
connection between adjacent LABs, so alll signals that cross LAB boundaries
have to go on the pseudo-global row routing, including the second level of
logic needed in more than 2 input arithmetic functions.  The wide
distribution of these wires slow them down compared with the speed that
could be achieved with local interconnect.  There is also not enough routing
in the row to support a datapath structure that utilizes a significant
portion of the row logic.  3) Xilinx offers the ability to use the CLB LUTs
as small synchronous RAMs.   This provides a very fast and area efficient
implementation of the delay queues and register files that occur frequently
in hardware DSP designs.  Altera has no equivalent, so word wide delays and
register files chew up lots of real estate quickly.  Altera's EABs are
occasionally convenient in DSP designs for register files and for function
generation as long as you can fit in the rather limited number of EABs.
Virtex offers a similar capability with the block RAM.

For so-called random logic designs, Altera is often a better choice because
the global routing makes its performance considerably less sensitive to
placement.  This relative insensitivity to placement also makes Altera
handle synthesized designs better than the Xilinx competition.  Altera's
tools are a little easier for the novice to pick up and use effectively.  On
the other hand, Altera's tools don't give the power user enough control over
the design to get in and get more out of the device.  This is especially
evident in creating macros with tight timing for others to use in their
designs.  Xilinx tools provide all the hooks for the expert user to really
get into the design as deep as he wants to.  The penalty is that it takes a
little longer for the novice to figure out how to get the timing he needs
for an average design.

Often, the choice comes down to the tools and knowledge available in house
more than the technical merits of one family over another.  Hope this is
helpful.


Pierre Langlois wrote:

> Hello,
>
> apologies in advance if this question has been asked a thousand times.
>
> I am looking for a "concise" comparison document of the current FPGAs on
> the market.  The comparison would include such things as typical maximum
> internal speeds, volatility, size in blocks and/or gates, prices,
> strengths (i.e. fast I/Os, fast arithmetic, best for DSP, most routing
> resources, easy-to-use tools, etc.).  It is probably impossible to say
> "in general, FPGA X is better than FPGA Y", but it is probably correct
> to say such a thing for a particular application.
>
> The question I am trying to answer is:
> given a particular application, which FPGA from which manufacturer
> should a designer use?
>
> Is there such a document on the Web?  In a FAQ, maybe?  If not, I would
> appreciate comments based on personal experience.
>



--
-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: 15357
Subject: Re: Placement control in ALtera devices
From: Ray Andraka <randraka@ids.net>
Date: Fri, 19 Mar 1999 21:04:41 -0500
Links: << >>  << T >>  << A >>
The placement controls for Altera are crude at best.  The only control
offered from the design entry environment is a suggestion to the place and
route tool that logic belongs together through the use of  'cliques'.  The
only other control you have ovr placement is the floorplanner tool, but
the results only apply to the current compilation.  It doesn't help at all
for generating a macro that needs to be implemented a certain way to meet
timing.  Part of the problem is that the Altera tools were designed
specifically for synthesized designs.  The tool wrongly assumes that since
the design is synthesized, the designer is not interested in the
floorplanning.

I also have not found a way to explicitly assign cliques from synplicity
rather than letting the synthesis engine do it.  That makes it hard to
even give the PAR tools a hint as to what needs to be grouped in a LAB or
row.  Has anybody else found a way?

Sebastia A. Bota wrote:

> Is possible to control the placement in Altera devices (8282 or 10K10
> devices) In order to implement a logic circuit at an specific logic
> module of the FPGA ?
>
> Where can I find information about the format of the bitstream used to
> program the device ?
>
> Thanks
>
> Sebastia



--
-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: 15358
Subject: Re: Power Estimiation
From: Ray Andraka <randraka@ids.net>
Date: Fri, 19 Mar 1999 21:13:29 -0500
Links: << >>  << T >>  << A >>
Xilinx does give you teh detailed information to accurately compute the power in the data sheets (at least
for the older devices...I haven't looked for it for the newer families).  Problem is, computing the power
from that information requires you to get into EPIC or formerly into XDE and tabulate the design by hand,
including toggle rates.  I've done it for a small design, and have no desire to ever do that again.  It is
tedious, but the results were pretty good.  It would be nice to see a tool that could extract that info
somehow.  If the designer could put a toggle attribute on each node of the design, then the power could be
computed fairly accurately.  Keep in mind, that even an accurate computation may have a +/- 6dB or more
error due to process, temperature and voltage variations.  Somehow, the effort to compute the toggle
frequency of each node seems like too much work for such a variable spec.

Andres David Garcia Garcia wrote:

> I think that this subjet of power estimation is becoming so pasionated,
> that surpriseme, cause I thaught that only me was interested in this subjet.
> I'm agree with Peter, the K factor and the Altera's model has no good
> bases and it was madden only to provide an idea of the power consumption
> of Altera's products in some circunstances, after months of measurements, I
> can tell you that the model is wrong wrong and wrong.
>
> I'm agree with Bob also, xilinx didn't and don't make efforts to estimate
> and/or
> to optimize power, and reducin VCC is not a good solution, designers wants to
> run more and more fasters. I don't work with xilinx or Altera neither, I'm
> trying
> to analize both and to understand how, why, when and where they consumes.
>
> I'll take the Bob's contribution and I'll try to make a contribution
>
> bob elkind wrote:
>
> > Here's a designer's perspective:
> >
> > Suggestion:  Provide a spreadsheet type of tool that
> >
> > a. groups power consumption "factors" (e.g. gross net capacitance, gross
> > gate capacitance) by clock net "driving" the power consuming components.
> >
>
> I divided the FPGA architecture in the following big pieces :
> -LUTs
> -DFFs
> -Clock Tree
> -Interconnect
> -I/Os
> -Memory blocks (or CLBs configured as memory).
>
> The interconnect can me divided in more pieces (half fast track, full fast
> track, columns, or simple, double, long lines)
>
> Here we have groups with similar (or the same) capacitance.
>
> >
> > b. provides parameters for each group (each group is driven by a different
> > clock!) for
> >
> >   i.  clock frequency
> >  ii.  average toggle factor (# clock cycles between state changes)
> >
>
> For each defined group we can provide parameters, like the average toggling
> rate of each one
> and the power supply of each group (some FPGAs uses 3.3 for internal logic and
> 5 volts for I/Os).
> Here it's important to defines what the toggling rate is.
>
> >
> > c. multiplies the right correction factors by the entered parameters and
> > the derived gate count/capacitance numbers, and adds the products to an
> > estimated power consumption number, taking into account the process
> > parameters (or range of parameters) for the fpga in use.
> >
> > It won't be perfect, its results won't be guaranteed, but it would
> > still be a *big* help.  And my guess is that the data required to "code"
> > this is already lying around in the engineering dept.
> >
> > Does anyone agree that this would help ?  Does anyone agree that this
> > is worth doing ?   Does anyone have any better solutions, or improvements ?
> >
>
>  Here we have a model that permits us to estimate power with a certain % of
> error,
> now the problem is, the toggling rate, first at all, we need REELS test
> vectors,
> to estimate the toggling rate, and second, a knlowledge of internal glitches in
> FPGAs,
> in asics power caused by glitches can represents the 15% of the total power
> consumption.
>
> For me, estimate power is important but it's not the MOST important, with a
> tool that allows
> to estimate it with a 5% or error is fine (maybe by now it's a dream). The most
> important
> thing of a knowledge of power consumption in FPGAs is to optimize algoritms
> using the
> existing FPGAs and to optimize FPGA's architectures for futures families.
>
> Anyway who has the truth in his hand?
>
>   ------------------------------------------------------------------------
>
>   Andres David Garcia Garcia <garcia@elec.enst.fr>
>   PhD Student on Electronics and Communications
>   Ecole Nationale Superieure des Telecommunications
>   Dept. Communications et Electronique
>
>   Andres David Garcia Garcia
>   PhD Student on Electronics and Communications      <garcia@elec.enst.fr>
>   Ecole Nationale Superieure des Telecommunications  HTML Mail
>   Dept. Communications et Electronique
>   46, rue Barrault ;Paris;;75634;France              Pager: http://www-elec.enst.fr/~garcia/index.html
>                                                      Fax: (33-1)-45-80-40-36
>                                                      Home: (33-1)-44-16-18-90
>                                                      Work: (33-1)-45-81-78-03
>   Additional Information:
>   Last Name Garcia Garcia
>   First NameAndres David
>   Version   2.1



--
-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: 15359
Subject: ISSS99 Second Call for Papers
From: Fadi J Kurdahi <kurdahi@ece.uci.edu>
Date: Fri, 19 Mar 1999 18:32:46 -0800
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------7B6C6674CDA508135B4E04D5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

ISSS'99 SECOND CALL FOR PAPERS
12th INTERNATIONAL SYMPOSIUM ON SYSTEM SYNTHESIS
DoubleTree Hotel, San Jose, CA, USA    November 10-12, 1999
Sponsored by IEEE Computer Society and ACM SIGDA (Approval Pending)
http://www.eng.uci.edu/~isss99

Author's Schedule
-----------------
Submission deadline: April 24, 1999
Notification of Acceptance: June 30, 1999
Camera-ready copies: July 30, 1999

ISSS'99 is the 12th in a very successful series of symposia oriented
towards professionals in design automation and system level design. The
symposium provides the ideal forum for discussions on the latest
technologies and results in areas of system level design and synthesis.
This year's ISSS will be co-located with ICCAD in the same hotel.
ICCAD's technical sessions will be Nov. 7-10 while ISSS's technical
sessions will start on the afternoon of Wed.  Nov. 10. The Wednesday
(Nov. 10) afternoon sessions of ISSS will be integrated in the ICCAD
afternoon program (in one of the ICCAD tracks) and will contain special
topics. Registrants for either ICCAD or ISSS will be allowed to attend
the joint Wednesday afternoon sessions. Thursday and Friday (Nov. 11-12)
will be devoted  to the normal ISSS paper presentations (for ISSS
registrants only) separately of ICCAD. Original technical papers on, but
not limited to, the following topics are invited:

 1 System-level synthesis: Partitioning, transformations, design reuse,
core/IP-based design,   quality measure, estimation, specification
languages and models, intermediate forms,   embedded processor
synthesis.

 2 Hardware-software co-design: Hardware/software tradeoffs, interfaces
and communications,   co-simulation, co-emulation and co-synthesis,
embedded system architectures, system   exploration, system testbench
development, design automation for rapid system prototyping.

 3 Programmable (multi-) processor-based design and synthesis: ASIPs,
reconfigurable and adaptive architectures, code generation,
instruction-set specification, design and simulation,  high-level code
transformations.

 4 System design experience and methodologies: Application-specific
parallel/distributed   systems, industrial telecom, robotics, vision,
video, audio and speech processing systems,   formalized design
methodology, process management.

 5 Embedded and real-time system software: Software development,
constraint specification,   process scheduling, real-time operating
systems, distributed systems.

 6 High-level and architectural synthesis: Datapath, control, memory,
and interface synthesis   from behavioral specifications,
clocking/timing optimization, physical design models for   high-level
tradeoffs, hardware accelerators/coprocessors.

 7 Synthesis for low power, testability and verifiability in the above
areas.

     Submitted papers should be 6 pages or less in IEEE 2-column style
(10pt), as close as possible to the final content. They should clearly
specify contributions and results, and include a separate cover page
with the following: paper title, complete name, address, telephone, fax,
and email address of each author, identification of the corresponding
author, and the category (numbered 1-7 above) most closely matching the
paper's content. Papers will be reviewed anonymously so please make sure
that only the cover paper contains identifying information on the
authors. Papers exceeding the page limit will be returned to the
authors. Previously published work or submissions simultaneously sent to
other forums will not be considered.

     Manuscripts (paper and cover page) must be submitted
electronically. Email the core manuscript file in Postscript format
(either attached as is or uuencoded/gzipped) and separate cover page (in
ASCII format) to the email address "isss99@ece.uci.edu". More details on
the submission will be added to the web page. Other correspondence may
be addressed to  the Program Chair at the following address:

Fadi J. Kurdahi, Program Chair ISSS'99
Electrical & Computer Engineering Department,
Engineering Tower, Room 516C
University of California, Irvine, CA 92697-2625 U.S.A.
Tel: +1 (949) 824-8104 ;  Fax: +1 (949) 824-2321
Email: kurdahi@ece.uci.edu, isss99@ece.uci.edu

Steering Committee
------------------

General Chair: Allen C.-H. Wu, Tsing Hua U.
Program Chair: Fadi J. Kurdahi, U.C. Irvine
Special Sessions Chair: Reinaldo Bergamaschi, IBM
Publicity/Publications Chair: Loganath Ramachandran, Synopsys
Liaison with ICCAD: Nikil Dutt, U.C. Irvine
Finance Chair: Sanjiv Narayan, Cadence
Local Arr.  Chair: David Ku, Escalade
Past Chair: Francky Catthoor, IMEC

Technical Program Committee
---------------------------

Gaetano Borriello, U. Washington
Raul Camposano, Synopsys
Rolf Ernst, Tech. U. Braunschweig
Masahiro Fujita, Fujitsu
Daniel Gajski, U.C. Irvine
Ahmed A. Jerraya, TIMA
Kayhan Kucukcakar, Escalade
Steve Y.L. Lin, Tsing Hua U.
Paul Lippens, Philips
Jan Madsen, Tech. U. Denmark
Gjalt de Jong, Alcatel
Lev Markov, Mentor Graphics
Peter Marwedel, U. Dortmund
Vijay Nagasamy, VSIS Inc.
Walid Najjar, Colorado State U.
Yukihiro Nakamura, Kyoto Univ.
B. Ramakrishna (Bob) Rau, HP Labs.
Wolfgang Rosenstiel, U. Tubingen, FZI
Leon Stok, IBM
Donald Thomas, CMU
Frank Vahid, U.C. Riverside
Diederik Verkest, IMEC
Kazutoshi Wakabayashi, NEC
Robert Walker, Kent State U.
Wayne Wolf, Princeton U.
Hiroto Yasuura, Kyushu U.
--------------7B6C6674CDA508135B4E04D5
Content-Type: text/x-vcard; charset=us-ascii;
 name="kurdahi.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Fadi J Kurdahi
Content-Disposition: attachment;
 filename="kurdahi.vcf"

begin:vcard 
n:Kurdahi;Fadi J.
tel;fax:+1 (949) 824-2321
tel;work:+1 (949) 824-8104
x-mozilla-html:TRUE
url:http://www.eng.uci.edu/~kurdahi
org:University of California at Irvine;Electrical & Computer Engineering
version:2.1
email;internet:kurdahi@ece.uci.edu
title:Professor of ECE and (by Courtesy) of ICS
note:Please note new area code for UCI (949)!
adr;quoted-printable:;;Engineering Tower=0D=0ARoom 516C;Irvine;CA;92697-2625;USA
x-mozilla-cpt:;0
fn:Fadi J. Kurdahi
end:vcard

--------------7B6C6674CDA508135B4E04D5--

Article: 15360
Subject: Re: FPGA Express FSM Synthesis Concern
From: Tim Davis <timdavis@tdcon.com>
Date: Fri, 19 Mar 1999 20:47:22 -0700
Links: << >>  << T >>  << A >>
Mike,

I've heard of this before. Contact Synopsys for the exact fix but I believe you have to combine the
state flip flops and the next state logic into one process. Then it will work.

michaellewis@my-dejanews.com wrote:

> Hi:
>
> I have a concern about the synthesis of a state machine.  I
> am implementing a 16-bit mealy state machine using the
> "One Hot" and "fastest & smallest" options for compliling
> in FPGA Express. It turns out that one of the outputs of
> the state machine is functionally set when one of two
> (logical OR) of these states is set.  However, the EDIF
> netlist out of the tool gives 6 levels of logic to implement
> this 2-input OR gate. In fact, it is a function of nearly all
> (14 to be precise) state signals, as opposed to the 2 I would
> expect.

--

Tim Davis
Timothy Davis Consulting

TimDavis@TDCon.com - +1 (303) 426-0800 - Fax +1 (303) 426-1023



Article: 15361
Subject: Re: FPGA vendor comparison
From: Richard Guerin <guerin2@home.com>
Date: Sat, 20 Mar 1999 03:56:08 GMT
Links: << >>  << T >>  << A >>
Sounds like a comparison of Xilinx vs Altera !

Ray Andraka wrote:
> 
> There is some of that available on the web at www.optimagic.com.  I've got
> plans to put technical comparisons up, but so far haven't had the time.  The
> best device depends on your application and other factors (not the least of
> which is access to tools).
> 
> The following are my observations, so take them for what they are worth.  I
> find that Xilinx 4K, and now virtex are hands down winners for DSP
> applications because of architectural features that only xilinx offers.
> Right now, the 4K is a better choice unless you need the new features in
> Virtex.  That is only because the tools support and libraries are still not
> as mature as those for the 4K.  The features that make xilinx better in DSP
> applications are: 1) invoking the altera carry chain breaks the LUT in the
> LE into a pair of 3LUTs, one for the carry and one for the 'sum'.  Both LUTs
> share the same inputs and one of those inputs is the carry from the previous
> LE.  That means that arithmetic elements are limited to 2 inputs.
> Adder/subtractors, accumulators with clear or load and so on need two levels
> of logic to implement in Altera's architecture.  2) There is no local
> connection between adjacent LABs, so alll signals that cross LAB boundaries
> have to go on the pseudo-global row routing, including the second level of
> logic needed in more than 2 input arithmetic functions.  The wide
> distribution of these wires slow them down compared with the speed that
> could be achieved with local interconnect.  There is also not enough routing
> in the row to support a datapath structure that utilizes a significant
> portion of the row logic.  3) Xilinx offers the ability to use the CLB LUTs
> as small synchronous RAMs.   This provides a very fast and area efficient
> implementation of the delay queues and register files that occur frequently
> in hardware DSP designs.  Altera has no equivalent, so word wide delays and
> register files chew up lots of real estate quickly.  Altera's EABs are
> occasionally convenient in DSP designs for register files and for function
> generation as long as you can fit in the rather limited number of EABs.
> Virtex offers a similar capability with the block RAM.
> 
> For so-called random logic designs, Altera is often a better choice because
> the global routing makes its performance considerably less sensitive to
> placement.  This relative insensitivity to placement also makes Altera
> handle synthesized designs better than the Xilinx competition.  Altera's
> tools are a little easier for the novice to pick up and use effectively.  On
> the other hand, Altera's tools don't give the power user enough control over
> the design to get in and get more out of the device.  This is especially
> evident in creating macros with tight timing for others to use in their
> designs.  Xilinx tools provide all the hooks for the expert user to really
> get into the design as deep as he wants to.  The penalty is that it takes a
> little longer for the novice to figure out how to get the timing he needs
> for an average design.
> 
> Often, the choice comes down to the tools and knowledge available in house
> more than the technical merits of one family over another.  Hope this is
> helpful.
> 
> Pierre Langlois wrote:
> 
> > Hello,
> >
> > apologies in advance if this question has been asked a thousand times.
> >
> > I am looking for a "concise" comparison document of the current FPGAs on
> > the market.  The comparison would include such things as typical maximum
> > internal speeds, volatility, size in blocks and/or gates, prices,
> > strengths (i.e. fast I/Os, fast arithmetic, best for DSP, most routing
> > resources, easy-to-use tools, etc.).  It is probably impossible to say
> > "in general, FPGA X is better than FPGA Y", but it is probably correct
> > to say such a thing for a particular application.
> >
> > The question I am trying to answer is:
> > given a particular application, which FPGA from which manufacturer
> > should a designer use?
> >
> > Is there such a document on the Web?  In a FAQ, maybe?  If not, I would
> > appreciate comments based on personal experience.
> >
> 
> --
> -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: 15362
Subject: From VHDL to FPGA?
From: (NO-SPAM)md7114@mclink.it (damiano)
Date: 20 Mar 1999 07:13:57 GMT
Links: << >>  << T >>  << A >>
Ok, I started looking at VHDL. Having a lot of experience with 
programming languages it does not seem too hard to manage.
Now I need to know a few things.

Is there a free or low cost tool for circuit simulation starting from 
VHDL code?

Are there VHDL examples, expecially of RISC CPU cores availble for 
free, just to learn how they are coded.

Starting from VHDL, which tools a and passes do I need to have a FPGA 
working chip (I plan to use one of the low cost PC programmers to 
begin).

(A question about FPGA, is it one time programmable or can it be 
re.programmed?)
Having VHDL what changes do I need to go from FPGA to ASIC?
I heard that Orbit accepts low volume orders, does someone know which 
is the minimal order and costs?

Thanks in advance,

Damiano Rullo
Trezzano S/N
Milan, Italy
http://members.it.tripod.de/Damianoux/index.html
mailto: dmn@cheerful.com
mailto: damiano@mclink.it

Article: 15363
Subject: Affordable and reliable IrDA infrared communications for 8/16/32/64 bit CPU's
From: info@embednet.com
Date: Sat, 20 Mar 1999 08:20:11 GMT
Links: << >>  << T >>  << A >>
IrPro(Tm) is An IrDA compliant software protocol stack that supports
reliable infrared communications for portable devices.

For more information check out:
http://www.embednet.com

Our customers have successfully used our stack on popular
8 bit CPU's like: 8051 derivatives, PIC.  

We also support Atmel's AVR CPU's .

This software stack is: 
. modular and written in "clean" C.
. small (<11K bytes) 
. efficient ( Zero copy buffer management )
. able to support speeds from 9.6Kbps to 4Mbps
. able  interface to any commercial RTOS  or a custom OS
. has direct support for popular CPU's or is simple to port to your 
  custom CPU.
. robust and mature.
. reliable, and provides inexpensive data transfers
. supported on all popular platforms: MIPS, ARM, Motorola, Intel,
Hitachi SH, etc ... 
. affordable (<$6k, no royalties, all source code)

Advantages of using IrDA infrared:
. requires no connectors
. is low power and low cost.
. infrared is not regulated like RF and requires no certification
. data transfers are reliable and robust
. IrDA is supported by MS Windows operating systems.

Article: 15364
Subject: Re: From VHDL to FPGA?
From: "Austin Franklin" <austin@dark8room.com>
Date: 20 Mar 1999 17:03:23 GMT
Links: << >>  << T >>  << A >>
Hi,

> Ok, I started looking at VHDL. Having a lot of experience with 
> programming languages it does not seem too hard to manage.
> Now I need to know a few things.

Please don't take this as a criticism, but do you have any hardware design
experience?  I ask because you said you have a lot of programming
experience.  With hardware, the mindset and engineering disciplines are
very different.

Austin Franklin
austin@darkroom.com



Article: 15365
Subject: Re: Bit Error Rate Test
From: janovetz@uiuc.edu (Jake Janovetz)
Date: 20 Mar 1999 18:52:32 GMT
Links: << >>  << T >>  << A >>

Dan,

  In many cases, it is unnecessary to sync back up to the
pattern.  If you build a PN generator at one end and duplicate
the polynomial at the other end, you can send received data 
into the receiver's polynomial and count errors that way.
Depending on how things are setup, you will get a multiple of
the number of errors, but that can easily be dealt with.
  This technique works very well for low BER (like < 10^-3).
The problem with higher BER is that you don't always get a 
clean multiple of the number of errors anymore.

    If you want more details on this method, contact me.
I'll try to find a reference.  (this is a common method)

    Cheers,
    Jake


In <qAwI2.361$UK6.4862@news.connectnet.com> "Dan" <dan@kvdco.com> writes:

>I am looking for information on building a small Bit Error Rate Tester
>inside a Xilinx.
>
>I have a Xilinx FPGA controlling a communications channel between a PCI card
>and an external cage.  I am thinking it would be useful to place a Bit Error
>Rate Tester in the Xilinx to test the link and to determine its maximum
>transfer rate.
>
>It would be simple to generate a pseudo-random pattern to transmit down the
>link, but I cannot think of an easy way to sync back up to the received
>data, and count errors.  I know this has been done before, I am just trying
>to avoid reinventing the wheel.
>
>
>Thanks
>
>Dan
--
   janovetz@uiuc.edu    | Once you have flown, you will walk the earth with
 University of Illinois | your eyes turned skyward, for there you have been,
                        | there you long to return.     -- da Vinci
        PP-ASEL         | http://www.ews.uiuc.edu/~janovetz/index.html
Article: 15366
Subject: Re: Xilinx Makefile?
From: z80@ds2.com (Peter)
Date: Sat, 20 Mar 1999 18:55:44 GMT
Links: << >>  << T >>  << A >>
I can't agree more, especially for projects which one needs to revisit
years later.

However, most of the time-advantage of a makefile is that it rebuilds
only the parts that need it. With the Xilinx tools I have used, 90+%
of the time is spent in place&route. So a simple batch file is just as
good.

>I miss the old makefile days.  Type one command and come back later.  No
>fear as to whether the software will decide to consider your latest changes
>or not!


--
Peter.

Return address is invalid to help stop junk mail.
E-mail replies to zX80@digiYserve.com but remove the X and the Y.
Please do NOT copy usenet posts to email - it is NOT necessary.
Article: 15367
Subject: i2c specification
From: rk <stellare@erols.com.NOSPAM>
Date: Sat, 20 Mar 1999 21:58:06 -0500
Links: << >>  << T >>  << A >>
hi,

i'm looking for an i2c specification and couldn't find one with a www
search.  any pointers?

thanks in advance,

rk

Article: 15368
Subject: quicklogic w/ pci interface
From: rk <stellare@erols.com.NOSPAM>
Date: Sat, 20 Mar 1999 22:20:52 -0500
Links: << >>  << T >>  << A >>
hi,

does anyone have any thoughts or experience on the pci core built into
the quicklogic fpga's?  i'm looking for an easy to use pci solution to
make boards for some test equipment and want to spend the absolute
minimum time fussing with pci.

thanks in advance,

rk

Article: 15369
Subject: Free Xilinx Vendor Tools ... NOT :-(
From: Richard Guerin <guerin2@home.com>
Date: Sun, 21 Mar 1999 04:45:44 GMT
Links: << >>  << T >>  << A >>
Would anyone care comment on why Xilinx doesn't offer some type of free
PC based vendor tools  ? ... it seems like every other FPGA/CPLD vendor
does :-)
Article: 15370
Subject: Re: i2c specification
From: brogle@worldnet.att.net (Richard Brogle)
Date: 21 Mar 1999 05:06:05 GMT
Links: << >>  << T >>  << A >>
On Sat, 20 Mar 1999 21:58:06 -0500, rk <stellare@erols.com.NOSPAM>
wrote:

>hi,
>
>i'm looking for an i2c specification and couldn't find one with a www
>search.  any pointers?
>
>thanks in advance,
>
>rk
>

Try the Philips website (www.philips.com),  after all, they invented
it.

Rick


Article: 15371
Subject: Re: Bit Error Rate Test
From: APS <resp@associatedpro.com>
Date: Sun, 21 Mar 1999 09:31:09 -0500
Links: << >>  << T >>  << A >>
Dan,

You would need a programmable correlator to accomplish this. You can use the
core generator to generate ram based correlators. I have done this, and it works
well. You may also want to examine the dallas semiconductor bert chip. It is
very small, and had the entire bert function built in. We have tied it to FPGAs
in some designs, and it works well.

Dan wrote:

> I am looking for information on building a small Bit Error Rate Tester
> inside a Xilinx.
>
> I have a Xilinx FPGA controlling a communications channel between a PCI card
> and an external cage.  I am thinking it would be useful to place a Bit Error
> Rate Tester in the Xilinx to test the link and to determine its maximum
> transfer rate.
>
> It would be simple to generate a pseudo-random pattern to transmit down the
> link, but I cannot think of an easy way to sync back up to the received
> data, and count errors.  I know this has been done before, I am just trying
> to avoid reinventing the wheel.
>
> Thanks
>
> Dan

--
__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/

Richard Schwarz, President              EDA & Engineering Tools
Associated Professional Systems (APS)   http://www.associatedpro.com
3003 Latrobe Court                      richard@associatedpro.com
Abingdon, Maryland 21009
Phone: 410.569.5897                     Fax:410.661.2760

__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/


Article: 15372
Subject: Re: From VHDL to FPGA?
From: APS <resp@associatedpro.com>
Date: Sun, 21 Mar 1999 09:35:25 -0500
Links: << >>  << T >>  << A >>
Take a look at our website. We have a lot of good tools and tutorials for
the new user. To answer your question, FPGAs come in several flavors.
SRAM based FPGAs are loaded from eproms or microcontoller buses, while
anti-fuse based FPGAs are programmed once only. You may want to start out
with SRAM based FPGAs. The two biggest vendors of these FPGAs are XILINX
and Altera.

NO-SPAM damiano wrote:

> Ok, I started looking at VHDL. Having a lot of experience with
> programming languages it does not seem too hard to manage.
> Now I need to know a few things.
>
> Is there a free or low cost tool for circuit simulation starting from
> VHDL code?
>
> Are there VHDL examples, expecially of RISC CPU cores availble for
> free, just to learn how they are coded.
>
> Starting from VHDL, which tools a and passes do I need to have a FPGA
> working chip (I plan to use one of the low cost PC programmers to
> begin).
>
> (A question about FPGA, is it one time programmable or can it be
> re.programmed?)
> Having VHDL what changes do I need to go from FPGA to ASIC?
> I heard that Orbit accepts low volume orders, does someone know which
> is the minimal order and costs?
>
> Thanks in advance,
>
> Damiano Rullo
> Trezzano S/N
> Milan, Italy
> http://members.it.tripod.de/Damianoux/index.html
> mailto: dmn@cheerful.com
> mailto: damiano@mclink.it

--
__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/

Richard Schwarz, President              EDA & Engineering Tools
Associated Professional Systems (APS)   http://www.associatedpro.com
3003 Latrobe Court                      richard@associatedpro.com
Abingdon, Maryland 21009
Phone: 410.569.5897                     Fax:410.661.2760

__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/


Article: 15373
Subject: Re: Free Xilinx Vendor Tools ... NOT :-(
From: APS <resp@associatedpro.com>
Date: Sun, 21 Mar 1999 09:40:42 -0500
Links: << >>  << T >>  << A >>
They get pretty close with the Foundation Base Tools at $99.00. But
remember these tools are costly to keep up and keep current. I think Xilinx
has done a pretty good job of getting low cost tools out there while
maintaining the quality and functionality of the tools.

Richard Guerin wrote:

> Would anyone care comment on why Xilinx doesn't offer some type of free
> PC based vendor tools  ? ... it seems like every other FPGA/CPLD vendor
> does :-)

--
__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/

Richard Schwarz, President              EDA & Engineering Tools
Associated Professional Systems (APS)   http://www.associatedpro.com
3003 Latrobe Court                      richard@associatedpro.com
Abingdon, Maryland 21009
Phone: 410.569.5897                     Fax:410.661.2760

__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/


Article: 15374
Subject: Re: Free Xilinx Vendor Tools ... NOT :-(
From: Richard Guerin <guerin2@home.com>
Date: Sun, 21 Mar 1999 18:05:31 GMT
Links: << >>  << T >>  << A >>
APS wrote:
> 
> They get pretty close with the Foundation Base Tools at $99.00. 
	
That's not FREE !

> remember these tools are costly to keep up and keep current. 

IMHO that goes with the territory .... all FPGA/CPLD vendors face the
same issue. 	

>I think Xilinx has done a pretty good job of getting low cost tools out there while
> maintaining the quality and functionality of the tools.

Personally, I don't need low cost tools for design entry, simulation, or
synthesis (I'm fortunate enough to have access to excellent 3rd party
tools). However, I do need a way to layout, back-annnotate (i.e.
netlist, SDF ...), and program a specific vendor's parts. 

Again, IMHO, an example of one vendor (out of several) that has done an
exemplary job in offering FREE tools is QuickLogic.  Their QuickChip
product is a comprehensive & quality vendor specific tool (I really love
SpDE's colorful post layout physical view) .... and it is totally FREE
... no licensing ... no limitations ... free updates avail from their
web site. Why do the do this when "these tools are costly to keep up and
keep current" ?  Simple .... they want you to use their products and
providing FREE tools helps enable designers to do so ... in fact, for
some, the FREE tools could become the differentiator in selecting their
products over a competitor's.  

That's enough for now < stepping off my soap box >  ;-)


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