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 10000

Article: 10000
Subject: Re: Xilinx RPMs for DSP (16-tap 8-bit FIR)
From: Carl Christensen <carl@philipsdvs.com>
Date: Tue, 21 Apr 1998 17:55:46 -0600
Links: << >>  << T >>  << A >>
You might want to look at Xilinx's cor-gen.  It's a relatively new tool that
will give you the RPM, a VHDL fragment to cut and paste into your code, and a
behavior model.  Use the behavior model for simulation, then treat the entity as
a "black box" for synthesis.  The cor-gen online docs to a reasonably job at
explaining the flow.

Good Luck
Carl Christensen

Jacob W Janovetz wrote:

> Hi...
>
>    I'm interested in using something like the 16-tap 8-bit FIR
> described in Xilinx's app note.  I'm using Leonardo for
> VHDL synthesis and, perhaps I'm missing something obvious,
> but it seems that I should be able to just invoke this RPM
> somehow and not do a whole lotta work.  Is my intuition
> wrong?  How do I go about doing this?  A pointer to a document
> would be fine if there is one out there.
>
>     Cheers,
>     Jake
>
> --
>    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: 10001
Subject: C++, C, Java to hardware compiler
From: William Jones <wbjones@msn.com>
Date: Tue, 21 Apr 1998 22:06:15 -0400
Links: << >>  << T >>  << A >>
Hello,
   I was wondering if there are any 'good' high-level language to
hardware compiler's in existence.




Bill J.

Article: 10002
Subject: Arbiter help !!!
From: channing-wen@usa.net
Date: Tue, 21 Apr 1998 20:22:52 -0600
Links: << >>  << T >>  << A >>


I'd like to designs a arbiter which process two, four and
more interrupt request cause the controller can acknowledg-
ing with no priority -- just "first come, first serve",
how to implement it with less cell ?

Any help would be greatly appreciated.


Regards,

Channing Wen

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading
Article: 10003
Subject: Re: Compression for 10K20
From: lemieux@eecg.toronto.edu (Guy Lemieux)
Date: 22 Apr 98 04:49:25 GMT
Links: << >>  << T >>  << A >>
Billy Bagshaw wrote:
>     Is there a good way to compress the data for a 10K20. I have a board
> wich does not have JTAG wired up so I can not use JAM. Any ideas ?

a simple run-length encoding should work fine and cheaply.
FPGA programming data tends to have lots of zeros or ones in
a row.  you simply count up the number of zeros, for instance,
then output a special code that says "N zeros are here".

the tricky part is those small areas where there are many
short strings of zeros and ones.  saying "1 zero here, 2 ones
here, 1 zero here, 1 one here, ..." then becomes inefficient.

more details follow....

an efficient way to handle this is to use a bit-stuffing algorithm
and/or an escape codes.  at this point i must also ask are you
using software or hardware for the decompression?  software works
nicer with bytes and hardware works better with bits.  the
exact details of the scheme you choose will depend on this.

let's say you are using software... it's easier to talk about.
what you do is choose a data size to work with (say 8 bits)
and then an escape code which you expect to be uncommon
in the data stream, say 10000001.  to compress, you read the
FPGA data one byte at a time, looking ahead at the next byte.
if you notice that the input byte is not repeated as the next
byte, then output the input byte.  EXCEPTION:  if the input
byte is the same as your escape code, you must output the
escape code twice followed a count value of 1 (see the next step
in case the escape code is repeated multiple times in the input).
if the input byte is repeated in the next byte, then count
how many more times it is repeated.  then you output the
escape code, the byte value, and the count (also an 8-bit
value).  this will compress up to 256 bytes with the same
value down to just three bytes.

notice that this increases the size of your data if the escape
code occurs frequently in the input.  that's the drawback, so you
must choose an escape code that is uncommon.

decompression should be obvious.  read the compressed data one
byte at a time.  if the byte equals the escape code, then read
the next two bytes as the value to output and the count, otherwise
just output the read byte.

this compression scheme can also be implemented in hardware
but you have to work on byte data, which may be awkward.
you can do a nice bit-serial version of this in hardware,
which may be more efficient.   but it is more complex to explain,
so bear with me as i give it a try:

i'll assume you are getting your input data in a bit-serial fashion.
choose a data size for your escape code (can be 5 bits, 9 bits,
anything!).  larger escape codes are good because they are less common
in the input data, however they also increase the size of the hardware
FSMs and increase the length of a bit-run you need to get an advantage
out of compression.  during compression, you need to do bit-stuffing to
make sure your escape code never occurs in the output stream except when
you want it to.

suppose your escape code is 0001.  now you should never
allow 00010 or 00011 to appear in the output stream unless you do so
intentionally!  whenever you see 0001z in the input stream, you
output the value 00010z instead (where the z holds the same bit value
between input and output).

now to do compression, you read the input one bit-at-a-time, and you
output almost every bit you input (but slightly delayed).  you
have an FSM that is watching the history of bit values and does the bit
stuffing to make sure the escape codes are treated as discussed above.
as well, you are looking for long strings of ones or zeros to compress.
when you find a sufficiently long string, you output the special code
00011
followed by the string value (1 or 0), followed by the count (how many
bits do you want to make the counter?  choose some appropriate value,
say 6 bits).  this will compress a bit string of up to 2^6=64 bits
down to 5+1+6=12 bits.  if you notice that strings of zeros or ones
tend to be longer than 64, increase the count size accordingly.

notice your bit stream will increase in size if 0001z occurs often.
assuming it occurs 1/16 of the time, then your overall increase
will be limited to one bit per 16*4=64 bits, a modest amount.

decompression is easier.  just read the values bit-at-time.
whenever you detect 00010z, output 0001z instead.  if you
detect 00011, then get the next set of bits (zCCCCCC) and
output the value z specified by the count in CCCCCC.

most of this stuff is taken from my (aging) memory.
i may have overlooked something in the hardware bit-stuffing,
but i think it will work.  the design of the FSMs to detect
the escape codes can be a bit tricky (it's a common question
given on undergrad tests!), but you can probably manage.

guy lemieux
Article: 10004
Subject: Re: Could you help me save CLB's?
From: lemieux@eecg.toronto.edu (Guy Lemieux)
Date: 22 Apr 98 05:27:51 GMT
Links: << >>  << T >>  << A >>
G. Herrmannsfeldt wrote:
> The Altera FPGA uses a lookup table for both sum and carry, and may
> be able to do what you want.

the problem with most architectures (including Altera) is the carry
output does not go to the general interconnect, only to the
next adjacent LUT.

why not?  because an extra output would require a rather largish
output driver and a handful of programming bits and connecting
elements (eg, SRAM bits and pass transistors).  this would increase
the size of the layout for the FPGA.  this increase in layout area
must be *balanced* against the increase in the # of CLBs for the (few?)
subcircuits which would benefit from the extra output.

designing an area-efficient FPGA is a tricky task because there
are many demands to consider and balance.  as spock said, "the
need of the many outweigh the needs of the few".

guy lemieux
Article: 10005
Subject: Re: Could you help me save CLB's?
From: lemieux@eecg.toronto.edu (Guy Lemieux)
Date: 22 Apr 98 05:45:55 GMT
Links: << >>  << T >>  << A >>
Vitit Kantabutra wrote:
> Thanks a lot for your extensive reply.  The reason I'm struggling with
> carry-save adders is because I'm trying to do the X & Y iterations for my
> radix-4 CORDIC algorithm.  A Xilinx application engineer responded by
> suggesting reducing 4 operands to 3, instead of 3 to 2.  (He's done carry-save
> adders himself.)  But it seems to me that this would take 3 CLB's for every 2
> bit positions.  Is it possible to do better?

yes, there are a few other possibilities.

it seems your ultimate goal is to get circuit speed.
have you considered pipelining your design instead?
you can even pipeline the carry chains if you must (ie,
delay the upper bits by an extra cycle if the carry-propogate
is on the critical path).

also, you are concentrating on having 17 3:2 carry-save FAs.
why not group the bits into threes (or larger) and use a ripple carry
in the middle?  one CLB can implement 2 bits of FAs using ripple
carry to another CLB, which can implement the 3rd bit and a final
carry out.  this uses 2 CLBs to produce 3 sum bits and 1 carry-out.
the final 17-bit hybrid/carry-save adder would use 11.5 CLBs.
since you will have only one carry-save bit per 3 input bits, the
design will probably route easier.

your 3:2 FA design used 17 CLBs, or 34 CLBs to do a 4:2.
the FAE's suggestion sounds like it will use 17/2*3 = 27 CLBs to do a
4:3.
my design should use 11.5+11.5 = 23 CLBs to do a 4:2.  only 15% larger
than your desired 10 CLB 3:2 :-)

guy lemieux
Article: 10006
Subject: Re: Could you help me save CLB's?
From: "Martin Mason" <mtmason@ix.netcom.com>
Date: Tue, 21 Apr 1998 22:59:44 -0700
Links: << >>  << T >>  << A >>


Rickman wrote in article <353D2639.EF0614AC@yahoo.com>...

>Prof. Vitit Kantabutra wrote

...snip..
>
>--
>Another alternative would be to use an Atmel part. I believe they can
>implement a full adder in a single cell (with a rather minimalist
>architechture). The big advantage is that you get so many more cells
>than you do in a comparable sized Xilinx part. I forget the numbers, but
>I believe there are about 6 or 8 times as many cells for a part of a
>given size rating. The limitation in the Atmel FPGA is the limited
>interconnect. It is based on adjacent cell connections with few and
>rather limited interconnect otherwise. But they have a new line coming
>out that sounds like it gets around this somewhat.

We have two architectures that are both well suited to this problem - you
are talking about AT6K  above  and also mention the new AT40K devices.  The
AT40K architecture has a full adder in a core cell, two outputs and enough
routing resources for the most demanding designs.  The FREE AT40K
development software is available at
(http://www.atmel.com/fpga_software.html)  and includes our parameterised
macro generators and our **OPEN** Macro Generator Language (MGL) - if you
don't like what we have done on a macro it is very easy for you to change it
to what you want - or just create your own from scratch - all the
documentation and examples are on the CD.


Martin Mason
Atmel Corp.


>
>But then I use Xilinx for everything I do. ;-)
>
>
>
>Rick Collins
>
>rickman@XYwriteme.com
>
>remove the X and Y to email me.


Article: 10007
Subject: Cyberromance survey
From: Lillian Chow <lchow@wahoo.sjsu.edu>
Date: Tue, 21 Apr 1998 23:57:55 -0700
Links: << >>  << T >>  << A >>
Hello,

I am a library science student at San Jose State University who is
conducting a study on the development of romantic relationships that
began (and perhaps ended) through online communication.

If you or someone you know has had experience in this area and would
be willing to spend a few minutes responding to a confidential
survey, please email me at lchow@wahoo.sjsu.edu.

Thanks,

Lillian Chow
Article: 10008
Subject: Re: Xilinx Timing Constraints
From: ems@see_sig.com (ems)
Date: Wed, 22 Apr 1998 08:08:07 GMT
Links: << >>  << T >>  << A >>
On Sat, 18 Apr 1998 19:06:22 -0400, Rickman <spamgoeshere1@yahoo.com>
wrote:

>I have a partial copy of class handouts labled "Timing & Constraints". I
>have 24 pages, starting with slide 3 and runing to slide 59, missing
>many slides here and there. 

thanks - i got this from xilinx tech support. there are 64 pages,
dated jan 98, containing some very useful stuff that i haven't seen
anywhere else (and i've spent a lot of time looking!)

i've uploaded the whole presentation to:

http://www.riverside-machines.com/pub/timingcsts.htm

for anyone else who's interested.

evan (ems@nospam.riverside-machines.com)

Article: 10009
Subject: Ask for / Discuss which FPGA & ASIC tools best buy
From: leslie.yip@asmpt.com
Date: Wed, 22 Apr 1998 04:03:08 -0600
Links: << >>  << T >>  << A >>
In fact this idea raises when I answer the e-mail from the person below. As I
come to a new company doing ASIC & FPGA design. I would like to seek advice
from different people for the company to buy a new tool for synthesis,
simulation and implementation.

Xilinx - very popular vendor. Good FPGA tool. Excellent for moderate design
like joystick, Gun for playing TV games (PS, .....). But it seems quite
difficult for trouble shooting on a large design about 30,000 gates on PC
environment. I have used to design a video ASIC chip with DRAM & SDRAM
controller. Another problem is the cost. It is quite expensive, probablity
because its name is commonly known.


Epson - Auklet. SLAx000 series. This tool is a Gate-level design. You can draw
schematic diagram and simulate. Its cost is low for small quantity. Besides,
it has some embedded chip for FPGAs.

Exemplar Leonardo -

ModelSim (V-system) - Fast simulation even for large design

Viewlogic - ViewLogic consists of ViewDraw,ViewSim and ViewTrace which allows
us to draw schematic diagrams with connections of module blocks such that each
blocks can be formulated from the library or based on VHDL codes (compiled by
Designer Series etc.). We would then checked out the whether if the VHDL codes
or connections are correct by simulation through ViewSim. One can execute the
command file which contains all the input signals (to test all the blocks). Or
you may compile & execute the Testbench file. Actually I use ViewLogic for
small design, as it takes long time to compile. Someone may like the schematic
generating, perhaps for easy trouble shooting.




----------
From: 	Yip Yiu Man
Sent: 	Wednesday, April 22, 1998 8:39 AM
To: 	'engp6396@leonis.nus.edu.sg'
Subject: 	RE: Exemplar Leonardo Experiences; Many bugs in ViewLogic &
MAX

Siew Kuok,

Actually I use ViewLogic for small design, as it takes long time to compile.
Someone may like the schematic generating, perhaps for easy trouble shooting.

In the past, I simulate the result like Xilinx command tool, ViewSim,
executing the command file. It seems to me that this one costs a lot of time
to do synthesis and sometimes some unexpected results occur.

Perhaps these are the most important factors that people concern.


Best regards,

YM Yip
Yip Yiu Man, Leslie
5/F ES
Phone:	+852 26912 835		FAX:	+852 26192 159
E-mail:	leslie.yip@asmpt.com

----------
From: 	engp6396@leonis.nus.edu.sg[SMTP:engp6396@leonis.nus.edu.sg]
Sent: 	Monday, April 20, 1998 5:14PM
To: 	leslie.yip@asmpt.com
Subject: 	Re: Exemplar Leonardo Experiences; Many bugs in ViewLogic &
MAX

Hi Leslie,
  While reading the newsgroup, I came across your message posting and I
would like to seek advice from you on this  :

Software programs like ViewLogic consists of ViewDraw,ViewSim and
ViewTrace which allows us to draw schematic diagrams with connections of
module blocks such that each blocks can be formulated from the library
or based on VHDL codes (compiled by Designer Series etc.). We would then
checked out the whether if the VHDL codes or connections are correct by
simulation through ViewSim. I suppose by executing the command file
which contains all the input signals (to test all the blocks), it is
like compiling & executing the Testbench file ? It seems that with the
ViewDraw & ViewSim, we can more or less elminate the need for writing
test benches, why would people still stick to using test benches sort of
thing ?

  Is the ViewSynthesis, the application to compile & link Test Benches &
programs of VHDL codes ?

  Hope you don't mind these simple questions as I am still a novice in
VHDL & ViewLogic.

Thanks,
Siew Kuok



-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading
Article: 10010
Subject: Ask for / Discuss which FPGA & ASIC tools best buy
From: leslie.yip@asmpt.com
Date: Wed, 22 Apr 1998 04:03:57 -0600
Links: << >>  << T >>  << A >>
In fact this idea raises when I answer the e-mail from the person below. As I
come to a new company doing ASIC & FPGA design. I would like to seek advice
from different people for the company to buy a new tool for synthesis,
simulation and implementation.

Xilinx - very popular vendor. Good FPGA tool. Excellent for moderate design
like joystick, Gun for playing TV games (PS, .....). But it seems quite
difficult for trouble shooting on a large design about 30,000 gates on PC
environment. I have used to design a video ASIC chip with DRAM & SDRAM
controller. Another problem is the cost. It is quite expensive, probablity
because its name is commonly known.


Epson - Auklet. SLAx000 series. This tool is a Gate-level design. You can draw
schematic diagram and simulate. Its cost is low for small quantity. Besides,
it has some embedded chip for FPGAs.

Exemplar Leonardo -

ModelSim (V-system) - Fast simulation even for large design

Viewlogic - ViewLogic consists of ViewDraw,ViewSim and ViewTrace which allows
us to draw schematic diagrams with connections of module blocks such that each
blocks can be formulated from the library or based on VHDL codes (compiled by
Designer Series etc.). We would then checked out the whether if the VHDL codes
or connections are correct by simulation through ViewSim. One can execute the
command file which contains all the input signals (to test all the blocks). Or
you may compile & execute the Testbench file. Actually I use ViewLogic for
small design, as it takes long time to compile. Someone may like the schematic
generating, perhaps for easy trouble shooting.




----------
From: 	Yip Yiu Man
Sent: 	Wednesday, April 22, 1998 8:39 AM
To: 	'engp6396@leonis.nus.edu.sg'
Subject: 	RE: Exemplar Leonardo Experiences; Many bugs in ViewLogic &
MAX

Siew Kuok,

Actually I use ViewLogic for small design, as it takes long time to compile.
Someone may like the schematic generating, perhaps for easy trouble shooting.

In the past, I simulate the result like Xilinx command tool, ViewSim,
executing the command file. It seems to me that this one costs a lot of time
to do synthesis and sometimes some unexpected results occur.

Perhaps these are the most important factors that people concern.


Best regards,

YM Yip
Yip Yiu Man, Leslie
5/F ES
Phone:	+852 26912 835		FAX:	+852 26192 159
E-mail:	leslie.yip@asmpt.com

----------
From: 	engp6396@leonis.nus.edu.sg[SMTP:engp6396@leonis.nus.edu.sg]
Sent: 	Monday, April 20, 1998 5:14PM
To: 	leslie.yip@asmpt.com
Subject: 	Re: Exemplar Leonardo Experiences; Many bugs in ViewLogic &
MAX

Hi Leslie,
  While reading the newsgroup, I came across your message posting and I
would like to seek advice from you on this  :

Software programs like ViewLogic consists of ViewDraw,ViewSim and
ViewTrace which allows us to draw schematic diagrams with connections of
module blocks such that each blocks can be formulated from the library
or based on VHDL codes (compiled by Designer Series etc.). We would then
checked out the whether if the VHDL codes or connections are correct by
simulation through ViewSim. I suppose by executing the command file
which contains all the input signals (to test all the blocks), it is
like compiling & executing the Testbench file ? It seems that with the
ViewDraw & ViewSim, we can more or less elminate the need for writing
test benches, why would people still stick to using test benches sort of
thing ?

  Is the ViewSynthesis, the application to compile & link Test Benches &
programs of VHDL codes ?

  Hope you don't mind these simple questions as I am still a novice in
VHDL & ViewLogic.

Thanks,
Siew Kuok



-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading
Article: 10011
Subject: Re: C++, C, Java to hardware compiler
From: Matthias Sauer <masa@pierrot.comlab>
Date: 22 Apr 1998 12:05:21 +0100
Links: << >>  << T >>  << A >>
William Jones <wbjones@msn.com> writes:

> 
> Hello,
>    I was wondering if there are any 'good' high-level language to
> hardware compiler's in existence.
> 
> 
> 
> 
> Bill J.
> 

You may want to have a look at our web site
(http://www.comlab.ox.ac.uk/oucl/hwcomp.html)
and the Handel-C pages
(http://www.comlab.ox.ac.uk/oucl/users/ian.page/handel/handel.html)

A quote from this page:
"Handel-C is a programming language designed for compiling programs into
hardware implementations. It is a subset of the C language extended with a few
powerful extra features. However, Handel-C is definitely not a hardware
description language. Indeed it is our aim to develop a single programming
language which can be used effectively for creating complete systems which
have both hardware and software components. We believe that Handel-C is a
significant step along this road."



We have so far been quite successful in compiling to FPGAs and people seem to
like the programming approach to hardware design (some endorsements can be
found on:
http://www.comlab.ox.ac.uk/oucl/users/ian.page/hwcomp/endorsements.html)

For mor info you can contact Ian Page (Ian.Page@comlab.ox.ac.uk) who leads the
Hardware Compilation Group here

Cheers

Matthias

-- 
Matthias Sauer				Tel +44-1865-283549
Oxford University Computing Laboratory  Fax +44-1865-273839
Wolfson Bldg., Parks Road		email masa@comlab.ox.ac.uk
Oxford OX1 3QD, U.K.
URL: http://www.comlab.ox.ac.uk/oucl/users/matthias.sauer/
Article: 10012
Subject: Xilinx Serial Proms
From: "Michael W. Ellis" <in@the.text>
Date: Wed, 22 Apr 1998 08:58:54 -0500
Links: << >>  << T >>  << A >>
I am involved in a design using Xilinx FPGAs, using the Foundation 1.4
package.  I am configuring the part from a Xilinx 17128D serial PROM.  To
make the PROM work, I must change the polarity of the RESET/OE pin by
writing data to 4 locations in the part.  For the life of me, I can't seem
to find a way to automate this using the Foundation toolset.  Currently I
must edit the MCS file or manually edit the data on the programmer.  Surely
this has been addressed many times and an easy solution is available, or the
solution is within the toolset and I'm just missing it.  Any help in solving
this problem will be greatly appreciated.

--
Michael Ellis
first initial last name at pesa dot you know what


Article: 10013
Subject: Re: Problem with Minc Fitter - MACH
From: Mike Kelly <mike@cogcomp.com>
Date: Wed, 22 Apr 1998 10:01:54 -0400
Links: << >>  << T >>  << A >>
Mike Kelly wrote:
> 
> Hey all,
> 
> I am getting strange problem with my Minc fitter for Synario.  I have
> a single clock pin assigned for a MACH466.  I am using about 180
> macrocells out of 256.  When the Minc fitter runs, it assigns another
> non-clock pin for my clock!  I don't use the clock as an input in any
> equations, just for clock.  Why the heck would the fitter decide I
> needed this clock as an input signal?  When I run the static timing
> analyzer it shows several of my output signals as being asyncronous,
> which indicates that the clock for that output is coming from the I/O
> pin, not the clock pin!  I have tried Synario support, and they just
> pointed the finger at Minc.  I am inclined to believe them since the
> pre-fit equations (and the post fit for that matter) show this clock
> input as being used as a clock only, not as a signal.  I left a
> message for Minc, but I don't know when they will get back to me.
> 
> Any ideas would be greatly appreciated.
> 
> Mike


Thanks for the responses.  It turns out that for the MACH4 if you use a
reset signal in a block that does not go to all the flops in that block,
the ones that do get the reset will be put into async mode.  When this
happens, the flops in async mode can only use global clocks 0 and 1.
Clocks 2 and 3 must be brought in through a product term.  So thats
why the fitter assigns an external i/o pin, assuming that you will know
enough to tie the clock signal to that pin.  

It would be real nice if a fitter gave you a message that it had to do
something outside of your original assignments in order to accomodate
a need of the underlying architecture.  Something like what I went 
through is very subtle and not easy to spot when you are new to the
chip and/or the design tool.

Mike


P.S.  I must say I received excellent support from MINC.  The guy there
tracked down this problem for me and came back with an answer in less
than 4 hours.  How often does that happen!


-- 
*******************************************************
* Michael J. Kelly              tel: (508) 278-9400   *
* Cogent Computer Systems, Inc. fax: (508) 278-9500   *
* 10 River Rd., Suite 205       web: www.cogcomp.com  *
* Uxbridge, MA 01569          email: mike@cogcomp.com *
*                                                     *
* CMA - Universal Target Platform for 32/64-Bit RISC  *
*******************************************************
Article: 10014
Subject: Synopsys FPGA compiler
From: Per Fremrot <pft@sam-ask.tde.lth.se>
Date: 22 Apr 1998 16:56:57 +0200
Links: << >>  << T >>  << A >>

I have just started to use Synopsys FPGA compiler and I am slightly
confused regarding the difference in optimization between DC and
FPGA-compiler libraries. I am trying to port a standard cell design to
FPGA (Xilinx) and have (not suprisingly) run into some performance
problems.

If I use the design compiler libraries for Xilinx the compilation
looks like when I'm using an ordinary standard cell library. If I
instead use the libraries for the FPGA compiler the optimization looks
like this:

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

compile -map_effort high

-cut-
 
                                              OPTIMIZATION   DESIGN RULE
            TRIALS      AREA     DELTA DELAY      COST          COST
           --------    ------    -----------     ------        ------
                 0
           --------
                 0
 
 
  Optimization complete
  ---------------------

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

No optimization at all here ! Is this the correct behavior ? I can
imaginge that it is pretty difficult to do optimization on CLBs, but
the performance I get is not very impressive. Is this step skipped on
purpose or could this be Synopsys way of saying "it's no use trying, I
give up..." ?


/Per Fremrot
Per.Fremrot@tde.lth.se
Article: 10015
Subject: Re: Problem with Minc Fitter - MACH
From: Barry Brown <barry@sr.hp.nospam.com>
Date: Wed, 22 Apr 1998 09:05:29 -0700
Links: << >>  << T >>  << A >>
Mike Kelly wrote:
> 
> Hey all,
> 
> I am getting strange problem with my Minc fitter for Synario.  I have
> a single clock pin assigned for a MACH466.  I am using about 180
> macrocells out of 256.  When the Minc fitter runs, it assigns another
> non-clock pin for my clock!  I don't use the clock as an input in any
> equations, just for clock.  Why the heck would the fitter decide I
> needed this clock as an input signal?  When I run the static timing
> analyzer it shows several of my output signals as being asyncronous,
> which indicates that the clock for that output is coming from the I/O
> pin, not the clock pin!  I have tried Synario support, and they just
> pointed the finger at Minc.  I am inclined to believe them since the

Of course, they are now the same company - Minc bought Synario.  Have
you checked the Vantis and Synario web sites to make sure you have the
latest version of the fitter?  Otherwise, try Vantis tech support
(techsupport@vantis.com).  On one occasion, they solved a fitter problem
I was having by providing me with beta code for the next release.

-- 
Barry A. Brown
Microwave Instruments Division
Hewlett-Packard Company
****  Remove the "nospam" from my email address  *****
Article: 10016
Subject: Re: Ask for / Discuss which FPGA & ASIC tools best buy
From: "Steven K. Knapp" <sknapp@optimagic.com>
Date: Wed, 22 Apr 1998 10:00:27 -0700
Links: << >>  << T >>  << A >>

leslie.yip@asmpt.com wrote in message <6hkboc$k6o$1@nnrp1.dejanews.com>...
[snip]
>Xilinx - very popular vendor. Good FPGA tool. Excellent for moderate design
>like joystick, Gun for playing TV games (PS, .....). But it seems quite
>difficult for trouble shooting on a large design about 30,000 gates on PC
>environment. I have used to design a video ASIC chip with DRAM & SDRAM
>controller. Another problem is the cost. It is quite expensive, probablity
>because its name is commonly known.
[snip]

Various programmable logic vendors and related software vendors provide
their tools at little or no cost for evaluation purposes.  The Programmable
Logic Jump Station maintains a list of available options at
http://www.optimagic.com/lowcost.html.

Also, as most of the programmable logic vendors are using advanced
processing technology (0.35u, three-layer metal CMOS and beyond), FPGA
prices will be coming down dramatically.  There will always be some
expensive FPGA, but at the upper end of performance or density.  In some
ways, the FPGA market is like the PC market.  You can buy a high-end PC
today, but the same machine will be much cheaper next year.  Or, for the
same amount of money as today's high-end PC, you could buy an even
higher-performance machine next year.

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




Article: 10017
Subject: Re: carry-save adder
From: Vitit Kantabutra <vkantabu@computer.org>
Date: Wed, 22 Apr 1998 11:11:07 -0600
Links: << >>  << T >>  << A >>
In terms of using other companies' FPGA's, the only suggestion I got was to
try Altera's ....... (I think it was the 8K series).  But if I want to stick
to Xilinx 4000's, then Lemieux post contains an excellent idea.  One of
Andraka's posts also contains the same idea, perhaps in a little less detail.

Xilinx does appear to think they are the immutable gods of this kind of
design. If your design doesn't fit well in a Xilinx, then it's your problem,
not theirs.  I think they should learn from IBM about what could happen years
down the road when they don't listen to suggestions!

> I would be curious to hear what other people tell you about
> other companies FPGA architectures that are more suited for
> carry-save work.  Maybe you could post a summary?
>
>    - Larry Doolittle   <ldoolitt@jlab.org>



Article: 10018
Subject: Re: Could you help me save CLB's?
From: Vitit Kantabutra <vkantabu@computer.org>
Date: Wed, 22 Apr 1998 11:41:49 -0600
Links: << >>  << T >>  << A >>
Guy Lemieux wrote:

> why not group the bits into threes (or larger) and use a ripple carry
> in the middle?  one CLB can implement 2 bits of FAs using ripple
> carry to another CLB, which can implement the 3rd bit and a final
> carry out.  this uses 2 CLBs to produce 3 sum bits and 1 carry-out.
> the final 17-bit hybrid/carry-save adder would use 11.5 CLBs.
> since you will have only one carry-save bit per 3 input bits, the
> design will probably route easier.
>

 Actually, your scheme doesn't reduce the number of operands, so I'm not sure how to
use it.  That is, from what I understand, both the inputs and the outputs are two
numbers.  Granted, one of your output numbers (the carries) has fewer bits than the
input operands, so the output will route more easily.

Article: 10019
Subject: Re: Could you help me save CLB's?
From: Vitit Kantabutra <vkantabu@computer.org>
Date: Wed, 22 Apr 1998 11:45:35 -0600
Links: << >>  << T >>  << A >>
So why not have several "flavor" of CLB's?  There are certainly enough
models of FPGA's out there to support that.

Guy Lemieux wrote:

> designing an area-efficient FPGA is a tricky task because there
> are many demands to consider and balance.  as spock said, "the
> need of the many outweigh the needs of the few".



Article: 10020
Subject: Re: Could you help me save CLB's?
From: Vitit Kantabutra <vkantabu@computer.org>
Date: Wed, 22 Apr 1998 11:49:07 -0600
Links: << >>  << T >>  << A >>
Great!  How large a circuit can the software handle?

Martin Mason wrote:
We have two architectures that are both well suited to this problem....


Article: 10021
Subject: Re: carry-save adder
From: Vitit Kantabutra <vkantabu@computer.org>
Date: Wed, 22 Apr 1998 11:57:52 -0600
Links: << >>  << T >>  << A >>
Someone from Atmel also suggested their AT6K and AT40K devices.
(mtmason@ix.netcom.com)

Vitit Kantabutra wrote:

> In terms of using other companies' FPGA's, the only suggestion I got was to
> try Altera's ....... (I think it was the 8K series).  But if I want to stick
> to Xilinx 4000's, then Lemieux post contains an excellent idea.  One of
> Andraka's posts also contains the same idea, perhaps in a little less detail.
>
> Xilinx does appear to think they are the immutable gods of this kind of
> design. If your design doesn't fit well in a Xilinx, then it's your problem,
> not theirs.  I think they should learn from IBM about what could happen years
> down the road when they don't listen to suggestions!
>
> > I would be curious to hear what other people tell you about
> > other companies FPGA architectures that are more suited for
> > carry-save work.  Maybe you could post a summary?
> >
> >    - Larry Doolittle   <ldoolitt@jlab.org>



Article: 10022
Subject: Re: Could you help me save CLB's?
From: staylor@dspsystems.com
Date: Wed, 22 Apr 1998 12:44:50 -0600
Links: << >>  << T >>  << A >>
Vitit,

Even the smallest FGPA has many CLBs. Why is it so important to use 10 instead
of 17 when you have hundreds or thousands?

In article <353CC1BC.3FB6@isu.edu>,
  kantviti@isu.edu wrote:
>
> Frank Gilbert wrote:
> > As far as I remember, a full-adder-cell has three inputs (a, b,
> > carry-in) and two outputs (sum, carry-out). To generate two outputs, you
> > will always need both function generators of one CLB (XC4K). This will
> > lead to n CLB's for n full-adders.
> >
> > The only reason why the n-bit ripple-carry-adders generated by LogiBlox
> > use less than n CLB's is by using dedicated carry-logic included in
> > every CLB. It is difficult or nearly impossible to use this carry-logic
> > for your own purpose. The dedicated carry-logic is explained in
> > http://www.xilinx.com/xapp/xapp013.pdf .
>
> Thanks.  That makes sense.  But now I wish CLB's were designed in a more
> carry-free-operations-friendly manner.  Aren't there FPGA's out there
> that are better suited to carry-free arithmetic?
>


-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading
Article: 10023
Subject: Re: Xilinx Serial Proms
From: z80@ds2.com (Peter)
Date: Wed, 22 Apr 1998 19:08:51 GMT
Links: << >>  << T >>  << A >>
I had to do this manually too, on my Data I/O Chiplab programmer.

One could develop a little awk program which would run, in e.g. a
batch file, and edit the .mcs file as required.

>I am involved in a design using Xilinx FPGAs, using the Foundation 1.4
>package.  I am configuring the part from a Xilinx 17128D serial PROM.  To
>make the PROM work, I must change the polarity of the RESET/OE pin by
>writing data to 4 locations in the part.  For the life of me, I can't seem
>to find a way to automate this using the Foundation toolset.  Currently I
>must edit the MCS file or manually edit the data on the programmer.  Surely
>this has been addressed many times and an easy solution is available, or the
>solution is within the toolset and I'm just missing it.  Any help in solving
>this problem will be greatly appreciated.


Peter.

Return address is invalid to help stop junk mail.
E-mail replies to zX80@digiYserve.com but
remove the X and the Y.
Article: 10024
Subject: Re: Could you help me save CLB's?
From: lemieux@eecg.toronto.edu (Guy G. Lemieux)
Date: 22 Apr 98 19:54:48 GMT
Links: << >>  << T >>  << A >>
> Guy Lemieux wrote:
> > why not group the bits into threes (or larger) and use a ripple carry
> > in the middle?  one CLB can implement 2 bits of FAs using ripple
> > carry to another CLB, which can implement the 3rd bit and a final
> > carry out.  this uses 2 CLBs to produce 3 sum bits and 1 carry-out.
> > the final 17-bit hybrid/carry-save adder would use 11.5 CLBs.
> > since you will have only one carry-save bit per 3 input bits, the
> > design will probably route easier.
> >
> 
>  Actually, your scheme doesn't reduce the number of operands, so I'm
> not sure how to
> use it.  That is, from what I understand, both the inputs and the
> outputs are two
> numbers.  Granted, one of your output numbers (the carries) has fewer
> bits than the
> input operands, so the output will route more easily.

hmmm...  i think what i was suggesting was really
a pipelined carry, with the carry being propogated
forward in time/space along with the data... sort of a
lazy evaluation of the carry.  this is not exactly
a carry-save adder, it is more like a hybrid
carry-save / ripple-carry adder.

in my mind i saw it reducing roughly 2.5 operands
down to 1.5 operands.  i realize now tha the area
savings may not be as significant as i stated before,
because there may be some up-front penalty (see the
discussion below).

also, my xilinx knowledge is weak (i use Altera mostly),
so please forgive my mistakes in estimating CLB usage.
i imagined using 2 CLBs as follows:

       ____
a0 -- |    |
b0 -- | FA |--->  S0
c0 -- |    |
       ----
         |
         |carry
       __v_
a1 -- |    |
b1 -- | FA |--->  S1
   -- |    |
       ----
         |
  ---CLB_boundary---
         |carry
       __v_
a2 -- |    |
b2 -- | FA |--->  S2
   -- |    |
       ----
         |
         |carry
       __v_
   -- |    |
   -- |    |--->  C, weight(C)==weight(S2)+1
   -- |    |
       ----

the input numbers are a0,b0.
the outputs (S0,S1,S2,C) can all be registered
for pipelining.  the C can be forwarded to the
next stage in the pipeline and used as the c0
input of the next stage.  this is the 'saved carry'
and represents the .5 of an operand in my 2.5:1.5
reduction estimate above.

my estimate was that 5 of the above CLB-pairs
are needed to add 15 (of 17) bits, and the
final 2 bits can be done in 1.5 CLBs (?).
thus, the # of CLBs needed would
be 11.5 * (#_of_operands - 1).  we can probably
round this to 12 * (#_of_operands - 1)

how exactly are you using these adders?

if they are being used as accumulators, then you can
feed back the S outputs to the b inputs, and the
carries can get wrapped accordingly too.  you get
immediate area savings (17 CLBs for the 3:2, vs 12 CLBs
for this method).

if you have a bunch of numbers to add, and you are trying
to pipeline the addition without worrying about carry chain
prop delay, then this structure is not as area efficient
for small numbers of operands (break-even point is about 4).
if you only need to add 3 operands, your 3:2 compressor
(plus a final adder) will be smaller than two of these
compressors (with the same final adder) (17 CLBs
versus 2*12=24).  but if you need to add four
or more operands, this structure starts to become
more area efficient. with four operands, your 3:2 compressors
require 34 CLBs and my suggestion requires 3*12=36 CLBs.
with five operands, it's 51 vs 48 CLBs.
with eleven operands, it's 170 vs 120 CLBs.

guy



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