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

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

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

Custom Search

Messages from 14225

Article: 14225
Subject: Re: Free max+plus ll simulator on win95
From: Brett George <b.george@clarityeq.com>
Date: Thu, 21 Jan 1999 14:51:50 +1000
Links: << >>  << T >>  << A >>
> kim tae-chang wrote:
> >
> > Is there any site from where I can down load a free max+plus ll(ALTEAR
> > COMPANY) simulator and runs on Windows 95 environment.
> > This simulator must handle big projects (up to 10k gates) in timing
> > simulation.
>
> There is only one _free_ MAX+plus II software. It's available at
> http://www.altera.com
>
> For big projects and with timing, the software is $$$.

about US$2k,also, you cant simulate on the demo.

Brett


Article: 14226
Subject: Re: Can we get back to DSP again? Was Re: Who cares what DSP programmers think?
From: Ray Andraka <randraka@ids.net>
Date: Thu, 21 Jan 1999 00:37:57 -0500
Links: << >>  << T >>  << A >>
John, welcome to comp.dsp!

Well, you already know that I am a strong proponent for schematic based design
for FPGAs, so you might be a little surprised by the following response.

The way I see it, HDLs do have real advantages, however there are some serious
disadvantages when applied to high performance FPGA designs.  As I see it, the
two real advantages that HDLs have over schematics for FPGA design are:

a)  Access to archived designs.  A schematic design requires a compatible
viewer or hardcopy to read an archived design.  As schematic entry tools
evolve, some of the older formats get dropped, so some legacy designs may no
longer be readable, and all designs are inaccessible to someone without the
correct reader.  On the other hand a text based design can be read by any text
editor capable of accessing a file the size of the design file (notepad will
probably not cut it for more complicated designs).

b) Significantly enhanced simulation capabilities.  VHDL brings with it the
ability to simulate using behavioral models in place of a detailed circuit
simulation using the same toolset as used with the detail design simulation.
This provides the ability to simulate a design or design fragment before the
detail design is done (helps to avoid getting to far down the wrong path).
Verified portions of the design can also be aliased to behavioral models to
cut down on the computational power required to do the simulation.

There are several other "benefits" bandied about by the marketing types,
which, depending on the context have some degree of truth:

a)  Design readability.  A well done hierarchical schematic is generally more
readable than HDL code...its the picture is worth a thousand words thing.
However, in my experience, the average engineer does not do a very good
schematic.  The number one crime is the lack of or improper use of a
hierarchy.  Schematic based design does not naturally impose hierarchy, so the
temptation is to create a flat schematic.  Sixty plus pages of flat schematic
are next to impossible to read.  Almost as bad are the hierarchical designs
that have not been logically partitioned.  To keep schematics readable, the
schematic at each hierarchical level should be limited to one page, the page
should be fairly sparse (probably no more than 10 symbols) and the hierachical
blocks should be logically partitioned so that each is a complete function to
itself.  All this takes some time to do, but there are rewards for following a
strict discipline.  It can be difficult to resist the urge to squeeze one more
thing (many times over) onto a page.  HDLs on the other hand, naturally
encourage hierarchy in the design which leads to legibility.  Also, certain
circuit elements lend themselves to a textual description; examples are state
machines and combinatorial decoders.  We've all seen examples of both that
wind up being a jumbled mess of AND and OR gates wired in some
incomprehensible manner.  <I do use a schematic methodology for one-hot state
machines that makes the schematic look like a flow chart to make schematic
statemachines easy to construct and understand>

b) Design reuse.  This is more of an issue of properly using hierarchy.  A
design that is hierarchically broken down into successivly smaller complete
functional units lends itself to reuse regardless of the capture methodology.
The fact that HDLs encourage good hierarchical breakdown makes  HDL design
fragments natural for reuse.  In schematics, you need to work at it.

c) Design portability.  This again is partly a hierarchy issue.  If the design
is properly broken into a hierarchy, it can be retargeted at a different
technology by simply changing the library for the lowest levels of the
hierarchy.  This requires libraries for the different technologies to have the
same interfaces to the upper levels: for schematics it means the same symbol
names, shapes, sizes, pin locations etc.  For HDLs it means pretty much the
same thing.  Where the different vendors have really not standardized in this
area, the user needs to create a translation library to smoothly transition
from one technology to another.  Developing unified library elements is a
sizable task, and one I don't think the one FPGA design a year crowd wants to
embark upon.  Now the translation is a little easier in HDLs, because the
graphic elements (pin locations and symbol size) are no longer in the
equation.  This is a small consolation.  Where HDLs have the big advantage is
when synthesis is used to infer the low level structure of the design.  If
that is the case, there is little the user needs to do to port the
design...assuming he did not go to low level construction.  The problem with
synthesizing from a higher level description is that you give up the control
of the design implementation and placement.  The cell granualarity in most
FPGAs is not handled well with current synthesis, although significant
improvements have been made mostly with libraries of primitive functions
targeted at specific devices.  In high performance/density designs you usually
lose to much when you relinquish control of the implementation to the
synthesizer.

d) Ease of entry.  Proponents of VHDL often state that a design can be entered
faster in textual form.  IMHO, it really depends on the design and your design
objectives.  State machines, for example can be easily entered and later
grokked in a textual format.  The state machine implementation can be
controlled do some degree with the coding style and with synthesis option
switches.  On the other-hand dataflow and memory intensive designs tend to be
easier to do with a schematic.  A true advantage textual descriptions have
over schematics is the ability to easily accommodate parameterized elements
(for instance data path elements whose implemented bit width is dependent on
context), something that is quite difficult to do with schematics.  Generally
for schematics, some macro generator is used to produce a symbol and an
optimized implementation.

For schematic entry, there is usually no synthesis (Altera MaxPlus II is an
exception), so the implementation is explicit.  The place and route tools will
do some boolean minimization and such to improve the design.  In schematics,
this is easily overridden if there is a reason for a particular implementation
using mapping constructs and placement attributes.  These are applied directly
to the affected schematic symbol.  Applying similar implementation and design
constraints in VHDL is tedious (akin to writing a textual netlist of the
circuit).  Applying placement constraints is inconsistent from tool to tool,
and those constraints in some cases are not hierarchical.  For low level
design control, the schematic entry method is considerably easier to do.

So the bottom line is  HDLs do give significant advantages for simulation and
archiving, and depending on the project, may also provide advantages by
synthesizing the design details.  For FPGA designs other than low performance
ones, the cost of synthesis is currently too high in terms of lost performance
and density to achieve the advantages from high level (RTL) synthesis.  That
cost can be circumvented by low level instantiation, but it is currently more
painful than doing the same low level designs in schematic form.  Keep in
mind, that the designs I do are typically DSP data path designs with sample
rates between 40 and 100 MHz, and often in slower speed grade devices.
--
-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: 14227
Subject: Re: Foundation Express Problem
From: Rickman <spamgoeshere4@yahoo.com>
Date: Thu, 21 Jan 1999 00:39:42 -0500
Links: << >>  << T >>  << A >>
I don't know for sure, but I assume that if you don't specify one of
those options, the default is to NOT pack FFs into the IOBs. 


Dominic Reitman wrote:
> 
> I've only done functional simulation and it operates ok, it's when I
> download the bit file to the FPGA that I physically test an expensive wire.
> Also, is there anyway to make that IOB setting from the DOS prompt? the
> syntax for the "map" command shows settings to pack FF/latches into input,
> output, or both types of IOB's (map -pr i|o|b ...).
> 
> Thanks
> Nick
> 
> Rickman wrote:
> 
> > Here is my guess as to what is happening. I think your circuit is being
> > synthesized correctly. But the FF is being pushed into the IOB of the
> > input port. The messages above indicate this. The warning may be from
> > the fact that the input and output IOB are now connected by a wire.
> >
> > If you go to the project manager and select "Implementation" and
> > "Implementation Option" you will get the options dialog box. On the line
> > that says "Implementation" click the "Edit Template" button and a new
> > dialog box will come up. Find the "Pack I/O Registers/Latches into IOBs
> > for:" control. Select "OFF". Now click OK and OK again. Now redo your
> > Implementation. and you should get a good result.
> >
> > When you say that the output follows the input without waiting for the
> > clock, are you running a simulation, or testing a chip? If a simulation,
> > is it a functional simulation or timing (after place and route)?
> 
> > Rick Collins

-- 

Rick Collins

redsp@XYusa.net

remove the XY to email me.
Article: 14228
Subject: Re: Hard porting to FPGA Express
From: Rickman <spamgoeshere4@yahoo.com>
Date: Thu, 21 Jan 1999 00:45:43 -0500
Links: << >>  << T >>  << A >>
Synopsys, are you listening???

VHDL-93 NOW!




Andy Peters wrote:
> 
> Ido Kleinman wrote in message <77lek9$5mo$1@news2.inter.net.il>...
> 
> >I've been using Foundation 1.4 with it's Metamor synthesis for a while now,
> >and I've got a few working designs.
> >I recently moved to Foundation 1.5 and it's FPGA Express synthesis -
> 
> In case it wasn't clear from Evan's post: Metamor is a VHDL'93-compliant
> tool, FPGA Express is VHDL'87-compliant (with a couple of '93 things thrown
> in).  The problems you're having are a result of Synopsys still living in
> the Reagan era.
> 
> >1. FPGAEXP won't accept:
> >if (LowerAddressBus > X"01F0") then
> 
> >LowerAddressBus is just a std_logic_vector(15 downto 0).
> 
> >it yells about type mismatch between left/right binary operand. The X seems
> >to be disturbing - it would only accept Binary notation without any prefix
> >to the " character so I have to write:
> 
> The X"xxxx" construct is valid only for bit vectors in '87. (See Evan's
> comments.) SLVs are fine with it with '93.  That's why Metamor was happy and
> FPGA Express was not.
> 
> >I tried using based literals such as 16#01F0# and variations - and it won't
> >work. Any solution, or I will have to do all my comparisons in Binary?
> 
> Make sure you've included ieee.std_logic_arith.all and
> ieee.std_logic_unsigned (or signed) and do a conversion:
> 
>     if (LowerAddressBus > CONV_STD_LOGIC_VECTOR(X"01F0", 16) then
> 
> which of course is a Synopsys work-around.
> 
> >2. My inhibit_buf attribute on my global Clk signal wasn't accepted! What's
> >the attribute for inhibiting insertion of IBUFs/OBUFs/etc on FPGAEXP? I
> >don't want my clock signal buffered with a standard IBUF, that why I
> usually
> >instanciate a BUFG/BUFGS for it and inhibit other buffers on the pad in the
> >code.
> 
> FPGA Express is smart enough to recognize a clock as a clock (based on
> sensitivity lists and how the signals are used in processes), so you don't
> need to inhibit the IBUF on your clock signal.  A BUFG is automagically
> instantiated for you.
> 
> >3. After I made the annoying adjustments to my code, my previously working
> >simulation files yielded strange new results in which some output signals
> >were defined as "????" - what's this? I thought std_logic "only" has 9
> >states...
> 
> Sounds like a VHDL'87 vs '93 problem.  What simulator are you using?  Make
> sure you compile all of your sources as VHDL'87 now!
> 
> >4. What about my two-dimensional arrays? I am not trying to synthesize
> >anything special - just some better-looking-VHDL multi-bit look-up
> tables...
> > FPGAEXP won't support it?
> >Forever?
> 
> With Synopsys, who knows?  Maybe when VHDL'2K comes out.  Then they'll be at
> the '93 level.
> 
> -- andy
> ------------------------------------------
> Andy Peters
> Sr. Electrical Engineer
> National Optical Astronomy Observatories
> 950 N Cherry Ave
> Tucson, AZ 85719
> apeters@noao.edu
> 
> "In the beginning, there was darkness.  And it was without form, and void.
> And there was also me!"
> -- Bomb #20, John Carpenter's "Dark Star"

-- 

Rick Collins

redsp@XYusa.net

remove the XY to email me.
Article: 14229
Subject: Re: help w/ broken xilinx dongle
From: Rickman <spamgoeshere4@yahoo.com>
Date: Thu, 21 Jan 1999 00:54:44 -0500
Links: << >>  << T >>  << A >>
C Kuethe wrote:
> 
> In a dusty old storage closet here, I dug up an XACT XC-DS21 evaluation
> kit, complete with demo board and dongle. I installed XACT on an IBM box,
> 486 w/ 16M ram. Unfortunately, when I try to run the software, I get an
> error to the effect of "can't find the key." Xkey reports no valid keys. I
> checked the key on other machines and check my bios settings to make sure
> that it wasn't the parallel port failing, but no machine found any keys.
> 
> Does anyone have any idea on where to go from here?
> 
> Be Well,
> Chris
> 
> --
>   Chris Kuethe: System Administrator - U of A Math Dept
>       http://www.[math.]ualberta.ca/~ckuethe/
> pager: 403.917.6448             office: CAB553, x1704   cell: 903.9475
> wargames@edmc.net               ckuethe@ualberta.ca
> ckuethe@math.ualberta.ca        ckuethe@gecko.math.ualberta.ca

I seem to remember that the old keys were nothing but a downcounter that
was reset to its internal value, then clocked until the output changed.
The number of clocks was the key "value". I don't know for sure, but I
think the number 157 might have some magical properties in this context.
I will try to find my old notes. If you hav e the number and know which
pins are toggling, you can make a new key from a PAL. 


-- 

Rick Collins

redsp@XYusa.net

remove the XY to email me.
Article: 14230
Subject: Re: Can we get back to DSP again? Was Re: Who cares what DSP programmers think?
From: murray@pa.dec.com (Hal Murray)
Date: 21 Jan 1999 07:10:59 GMT
Links: << >>  << T >>  << A >>
In article <36A6BD35.52386799@ids.net>, Ray Andraka <randraka@ids.net> writes:

Nice info.  Thanks.

> a)  Access to archived designs.  A schematic design requires a compatible
> viewer or hardcopy to read an archived design.  As schematic entry tools
> evolve, some of the older formats get dropped, so some legacy designs may no
> longer be readable, and all designs are inaccessible to someone without the
> correct reader.  On the other hand a text based design can be read by any text
> editor capable of accessing a file the size of the design file (notepad will
> probably not cut it for more complicated designs).

I consider collecting up postscript/pdf versions of the schematics to be
part of the archive-and-release process.

For PCBs, I assume the layout system makes a text format wirelist of the board.
I want two versions.  One is sorted by signal name showing all the parts and
their pins where each signal goes.  The other is sorted by part showing the
signals connected to each pin.

I'm not quite sure what part of an FPGA design corresponds
to the "wirelist".  I usually save various intermediate files
as part of the archive-and-release process.  For FPGAs up to the
size of a 3090, printing things on 11*17 paper is often useful.

-- 
These are my opinions, not necessarily my employers.
Article: 14231
Subject: Re: Can we get back to DSP again? Was Re: Who cares what DSP programmers think?
From: ems@riverside-machines.com.NOSPAM
Date: Thu, 21 Jan 1999 11:22:00 GMT
Links: << >>  << T >>  << A >>
I don't want to get into an argument here, but it's time that someone
actually explained why people use VHDL. There are a lot of people in
this newsgroup (.fpga) who will defend the use of schematics, but few
who will bother to argue the case for VHDL.

There are only two significant reasons to make the large investment
required to convert to the xHDL flow: simulation, and synthesis.

Ray has covered the simulation advantage. However, there are two
points he didn't explicitly mention. The first is that you can
simulate the system around your device, and the interaction with your
device, as well as simulating the device itself. It would be foolish
for anyone developing a large-NRE device not to carry out a
system-level simulation. The second is that you can use the same
testbench to carry out a simulation at any stage of the design:
behavioural (during device definition and analysis), RTL (after
coding), post-synthesis, and post-PAR.

The second reason is, of course, synthesis. If you have a large
device, limited manpower, a limited budget, and a tight schedule, then
you need a synthesiser. If you quantify these 4 parameters for your
own circumstances, then you may well decide that synthesis is not
appropriate for you. There are other circumstances in which synthesis
may not be appropriate. If you only produce DSP designs, for example,
and your devices simply reuse existing technology blocks, then a
synthesiser is unnecessary. 

By the way, the PAR tool is absolutely *not* the appropriate place to
carry out synthesis or optimisation. A synthesiser must have knowledge
of the low-level architecture, and must have the ability to iterate
between boolean and gate-level optimisations in order to meet
constraints. An 'optimising' PAR tool will simply break this cycle.
It's true that first-generation FPGA synthesis tools may have relied
on an optimising back end, but this isn't normally the case now. If
you discover that your synthesiser is producing a gate-level
representation, and is then relying on the PAR tool to translate this
into CLBs, or whatever, then you should get new tools or silicon.

As an aside, it's occasionally said here that the VHDL flow produces
designs that are slow or inefficient (it's obviously true that
synthesis may occasionally produce non-optimal results; this is what
constraints are for. If the constraints fail, try something else).
However, this now seems to have been replaced with the statement 'Ok,
you can do exactly what you want with VHDL, but you have to write a
netlist'. I guess that I'm the source of this statement, so perhaps I
can clarify it: you can do exactly what you want with VHDL, by writing
a structural description, which is precisely what you're doing with a
schematic. Both are equivalent to netlists, and both will require
additional attributes for precise placement and routing. The VHDL
looks like VHDL, and nothing like an EDIF or XNF netlist.

Whether you choose schematics or VHDL depends on your individual
circumstances. There's a large learning curve and significant expense
in the VHDL route, so it shouldn't be undertaken lightly.

Evan


Article: 14232
Subject: Re: Free max+plus ll simulator on win95
From: Hamish Moffatt <hamish@rising.com.au>
Date: 21 Jan 1999 11:51:04 GMT
Links: << >>  << T >>  << A >>
Armin Mueller <ual6@rz.uni-karlsruhe.de> wrote:
> kim tae-chang wrote:
>> Is there any site from where I can down load a free max+plus ll(ALTEAR
>> COMPANY) simulator and runs on Windows 95 environment.
>> This simulator must handle big projects (up to 10k gates) in timing
>> simulation.

> There is only one _free_ MAX+plus II software. It's available at 
> http://www.altera.com

> For big projects and with timing, the software is $$$.

So is there ANY way to do free FPGA work yet? Like little projects for home?

There's a collection of things around, but each have drawbacks.

ActiveVHDL is very nice, but the demo (a) is simulation-time limited,
and (b) expires after 1 month. It also appears to use a LOT of RAM,
but I don't mind that so much. I gather this is pretty expensive.

Synopsis have an FPGA Express demo, for VHDL. But the design size
is limited to something quite small, and then there's no way to route
the output netlist anyway.

Altera have the MAX+PLUS II baseline. It can synthesize and compile AHDL
or schematics. It can't do VHDL, but I can live with AHDL (although the
help doesn't really make a very good tutorial). But you can't simulate it,
and the device range is reasonably limited.

So what other options are there? I want to be able to enter a design,
either in an HDL or schematics (preferably the former), simulate it,
and route it for a device I can get reasonably easily. (Xilinx is the easiest
to get in Melbourne in my experience.)

I've used Mentor, XACT 5.2, XACT M1.4 and Synopsis at uni and at work,
and it's frustrating not to be able to get this stuff for home.

If the manufacturers concentrated on selling chips and gave the software
away, they might just sell a few more chips! I imagine that for a startup
company, the cost of software tools could be quite important. For a home
user it is obviously crucial.


Hamish
-- 
Hamish Moffatt       Mobile: +61 412 011 176       hamish@rising.com.au

Rising Software Australia Pty. Ltd. 
Developers of music education software including Auralia & Musition.
31 Elmhurst Road, Blackburn, Victoria Australia, 3130
Phone: +61 3 9894 4788  Fax: +61 3 9894 3362  USA Toll Free: 1-888-667-7839
Internet: http://www.rising.com.au/
Article: 14233
Subject: Re: help w/ broken xilinx dongle
From: kfalser@durst.it
Date: Thu, 21 Jan 1999 12:36:24 GMT
Links: << >>  << T >>  << A >>
In article <783359$ds2$1@pulp.ucs.ualberta.ca>,
  C Kuethe <ckuethe@gpu.srv.ualberta.ca> wrote:
> In a dusty old storage closet here, I dug up an XACT XC-DS21 evaluation
> kit, complete with demo board and dongle. I installed XACT on an IBM box,
> 486 w/ 16M ram. Unfortunately, when I try to run the software, I get an
> error to the effect of "can't find the key." Xkey reports no valid keys. I
> checked the key on other machines and check my bios settings to make sure
> that it wasn't the parallel port failing, but no machine found any keys.
>
> Does anyone have any idea on where to go from here?
>
> Be Well,
> Chris
>
> --
>   Chris Kuethe: System Administrator - U of A Math Dept
>       http://www.[math.]ualberta.ca/~ckuethe/
> pager: 403.917.6448             office: CAB553, x1704	cell: 903.9475
> wargames@edmc.net               ckuethe@ualberta.ca
> ckuethe@math.ualberta.ca        ckuethe@gecko.math.ualberta.ca
>
>
Another idea may be to install the newest drivers for the Sentinel or
Rainbow dongle.
Xkey is a DOS program, when running under Windows NT it requires a driver to
access the dongle, maybe under Win95/98 too.

Hope this helps
   Klaus

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    
Article: 14234
Subject: Re: Ratings for Synplicity Synplify
From: Utku Ozcan <ozcan@netas.com.tr>
Date: Thu, 21 Jan 1999 14:38:54 +0200
Links: << >>  << T >>  << A >>
Please forgive me the terms in this e-mail, since I am using
  "synthesis" and "compilation" interchangeably.

> I used synplicity on a Xilinx 40150. The versions I used were:
> 5.0.6, 5.0.7 and 5.0.8. Before getting to know synplicity, I
> used Synopsys's FPGA Compilor on a Xilinx 4036. All works were
> done on SUN workstations. Here is a summary of problems that
> I have seen:
> 
> 1. Crashing the WS from 5.0.6 to 5.0.7 when browsing the design
> under technology view. 5.0.8 seemed to fix the problem although
> there exist a Solaris patch to fix the a video card bug.
> 
> 2. Running out of memory on 5.0.7. There is a memory leakage
> problem that eats up all 1Gbytes of RAM in our Ultra. 5.0.8
> fixed this problem.
> 
> 3. Doing mapping forever on 5.0.6. The design ran for 20 hours
> and still not done! 5.0.8 fixed this problem.

  We got the same problem with a Sun sparcSTATION 4. I think it is
  something like "compilation deadlock", since we have seen for hours
  long harddisk is running away. We tried to fix this problem by
  exiting and rerunning the program and it worked 60%.

> 4. Misleading CLB usage count. In the beginning, I used the stats
> reported in the .srr file to estimate how big the device would be.
> Big mistake, as a lot of CLBs are used as route through and
> the final size is 20% bigger (roughly).

  Exactly. The number of CLB's used in Design Manager are given
  ca 1.2 - 1.5 times the number of CLB in Synplify. This is a very
  important issue, and must be fixed somehow. 

> 5. Timing estimation is way off. At one time, we have hundreds
> of timing violation from par. The par figure reported was like
> 19 nanosecong worst than that estimated by synplicity. Overall
> synplicity's estimate is always too optimistic.

  I agree. Timing estimations are sometimes unbelievable, for example
  if there are multiple clocks in the design, and if there are slack
  information for one of external clocks, output logs show slacks of
  a very different region of the chip which is not running at that
  clock. We got an 8.192 MHz external PCM clock and slack information
  related to this clock include regions running at 25 MHz!!!

> These are the worst problem that I have. There are many more. On the
> plus side, the compile speed is very high compare to the FPGA
> compiler. On the 4036 design, it was like 180 seconds vs 3.5 hours.
> As well, the support is excellent. Every call is answered very
> quickly with work around that works. The tool has improved a lot
> since the beginning but is still being developed. At the end,
> we decided to stay with synplicity inspite of its many problems.

  We have used 3.0c, 5.0.7 and 5.0.8 version of Synplify. I must say
  that the compilation speed is very fast. Our target technology
  was XC40110XV. FPGA Express compiled the chip in 1.5 hours whilst
  Synplify 5.0.7 compiled in 4 minutes and 5.0.8 in 2 minutes!!
  It is a promising time to make Tcl-base algorithmic iterations.

  In addition, you must pay attention to design with multiple clocks
  when synthesizing Synplify. You can define a constraints file
  which include constraints of the clocks. But synthesizer wants
  to enter a global clock frequency value. Our examinations show
  that the fastest result of synthesizer are around the frequency region
  where most of logic are running. For example, if you have 25 MHz
  and 10 MHz external clocks are if the regions running at 10 MHz
  are 80% of the chip, then the global frequency around 10 MHz gives
  best results. But not always ;-)

  Utku
Article: 14235
Subject: Re: Can we get back to DSP again? Was Re: Who cares what DSP programmers think?
From: Marius Vollmer <mvo@dt.e-technik.uni-dortmund.de>
Date: 21 Jan 1999 13:53:05 +0100
Links: << >>  << T >>  << A >>
ems@riverside-machines.com.NOSPAM writes:

> I don't want to get into an argument here, but it's time that someone
> actually explained why people use VHDL. There are a lot of people in
> this newsgroup (.fpga) who will defend the use of schematics, but few
> who will bother to argue the case for VHDL.

Intuitively, I would like to argue for VHDL or other text-based
description formats, too, but I find it hard to find really convincing
arguments.  I think you can currently do _more_ with text based
`languages' because they are better understood from a language design
point of view.  But I see no fundamental reason why graphical tools
could not catch up.

With textual languages, you can specify the grammar and formal rules
for what each construct means, for example.  They allow for much more
powerful abstraction mechanisms, because they do not pretend to be
intuitive to begin with.  With schematic layout things, I think we
still haven't a really good separation between the `format' and the
tool used to edit it, like we have for text languages.  And the tools
for working with text are just plain better and more mature than the
ones for graphical descriptions.

I do not think the old saying "a picture is worth a thousand words"
can really be used as an argument here.  The other way around is just
as true: "a word is worth a thousand pictures".  We should and can
have both.

Schematic tools produce static, declarative descriptions, AFAICS,
while textual languages allow for a more active, procedural
descriptions.  Take the GENERATE statement in VHDL.  How many
schematic capture tools support such a thing?  Would it be useful?  I
think yes. [Note, I know next to nothing about the current state of
the art in schematic capture, so these are actually not rhetoric
questions.]

What is really needed is a way to combine the best of both worlds, as
always.  Allow the intuitive design of structural relationships via
graphical nets, just like you would use them on a white board when
reasoning about them with your colleagues.  Allow for more abstract
notions like parameterized repetition of subnets, conditionals, and
support for `higher order schematics'.  Allow for the seamless
integration of things that are better described textually, like actual
pieces of software that runs on your hardware or high-level
algorithmic signal munching.

> There are only two significant reasons to make the large investment
> required to convert to the xHDL flow: simulation, and synthesis.

Insofar as schematic descriptions are `inferior' to textual ones, you
can certainly convert your schematic into the textual form and then
simulate and synthesize that.  What's more important, IMO, are the
thoughts you can't think and teh things you can't say in your
schematic.

- Marius

-- 
Go Meta!
Article: 14236
Subject: CORDIC (was: Best way to digitally synth. stable frequencies?)
From: Erik Widding <widding@ieee.org>
Date: 21 Jan 1999 13:14:14 GMT
Links: << >>  << T >>  << A >>
Peter wrote:
> 
> The CMOS Cookbook, by Don Lancaster, ISBN 0-672-21398-2, mine is 1977!

Mine is actually early 90's.  This series, i.e. "Op-Amp Cookbook", etc.,
is right up there with the bible, "Art of Electronics".
 
> There is also an algorithm called Cordic. I have no info but a post in
> comp.arch.fpga should elicit a response from one of the very helpful
> contributors there.

I did a quick net search, and turned up a few papers by Ray Andraka,
that give a very good introduction.  As such, I would like a few of the
CORDIC experts out there to recommend a good reference text on CORDIC
specifically, and distributed math, or atleast a hardware oriented
algorithm book more generally.

I have some great texts in my library that are "software oriented". 
Seems the computer science world likes to assume that a register
oriented or traditional DSP architecture, with a multiplier, is being
used.  Xilinx apnotes, and other papers have always been where I have
needed this sort of information, but a good general text on the matter
would be nice.

Any suggestions?


Regards,
Erik Widding
Birger Engineering, Inc.


> 
> >Peter wrote:
> >> There is a way to get
> >> digital-precision sinewaves from a feedback shift register arrangement
> >> - email me if you need more info; I have a book. Get the whole thing
> >> into a small FPGA.
> >
> >What is the name of the book?
> 
> --
> Peter.
Article: 14237
Subject: Q: Counting GHz pulses - ?
From: Alexander Sherstuk <Sherstuk@amsd.com>
Date: Thu, 21 Jan 1999 16:29:50 +0300
Links: << >>  << T >>  << A >>
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BE4542.1F6D51EE
Content-Type: text/plain;
	charset="koi8-r"

Dear colleagues,

  I am considering using FPGA for 1ns-accurate measurements.
As well as I understand, it is hardly possible to feed 1GHz clock
frequency into FPGA.
My questions are:
1)	Has anybody used some kind of frequency prescaler in connection
with FPGA?
		What prescalers are suitable for such purpose? Does
anybody know VHF counters with internal stages accessible (which is
necessary to obtain lowest bits of the counter)?
2)	Is it possible for XILINX Virtex to generate 1 GHz internally,
through it's on-chip PLL? 
3)	Is Altera's on-chip PLL capable of such frequencies?

Thanks,
   Alex Sherstuk
     sherstuk@amsd.com <mailto:Sherstuk@amsd.com> 
     AMSD Company




------_=_NextPart_001_01BE4542.1F6D51EE
Content-Type: text/html;
	charset="koi8-r"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dkoi8-r">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2448.0">
<TITLE>Q: Counting GHz pulses - ?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Dear colleagues,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp; I am considering using FPGA for =
1ns-accurate measurements.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">As well as I understand, it is hardly =
possible to feed 1GHz clock frequency into FPGA.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">My questions are:</FONT>

<OL TYPE=3D1><LI><FONT SIZE=3D2 FACE=3D"Arial">Has anybody used some =
kind of frequency prescaler in connection with FPGA?</FONT></LI>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">What prescalers are suitable for such =
purpose? Does anybody know VHF counters with internal stages accessible =
(which is necessary to obtain lowest bits of the counter)?</FONT></P>
</UL><LI><FONT SIZE=3D2 FACE=3D"Arial">Is it possible for XILINX Virtex =
to generate 1 GHz internally, through it's on-chip PLL? </FONT></LI>
<LI><FONT SIZE=3D2 FACE=3D"Arial">Is Altera's on-chip PLL capable of =
such frequencies?</FONT></LI>
<BR>
</OL>
<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; Alex Sherstuk</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;</FONT> <A =
HREF=3D"mailto:Sherstuk@amsd.com"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">sherstuk@amsd.com</FONT></U></A>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; AMSD =
Company</FONT>
</P>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01BE4542.1F6D51EE--

Article: 14238
Subject: Re: The development of a free FPGA synthesis tool
From: Emeka MOSANYA <Emeka.Mosanya@epfl.ch>
Date: Thu, 21 Jan 1999 14:31:10 +0100
Links: << >>  << T >>  << A >>


>   C to Netlist Compiler (nlc):
>     Given a program written in a ``small subset of C++ with a few extensions,''
>     nlc compiles the program into an FPGA configuration. ftp://lslsun5.epfl.ch/pub/

nlc, the work of Christian Iseli, is located at ftp://lslsun.epfl.ch/pub/

E.

-- 
Emeka MOSANYA
Ecole Polytechnique Fédérale de Lausanne
Laboratoire de Systèmes Logiques
Email: Emeka.Mosanya@epfl.ch
-------------------------------------
"Au premier jour, l'homme créa Dieu"
Article: 14239
Subject: Re: Synthesis tools for Xilinx FPGAs (an apology to Synplify)
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Thu, 21 Jan 1999 13:34:11 +0000
Links: << >>  << T >>  << A >>
I have an apology to Synplify users. I have found out why PAR was taking 5x
as long. Even though I thought that there were no timing constraints in fact
the PAR run from Synplicity was using constrains. This relates to a  Xilinx
MAP problem. In both cases the tools produced this situation:

A clock buffer:

 CLK ---> <BUFG> ---> CLK_int

Related timespec:

NET "CLK  " PERIOD = 1000 nS HIGH 50%;

The problem is that without doing something the MAP program won't propagate
this timespec through the clock buffer.  You need to put either a TNM_NET
spec on CLK or do  what synplicity does and add
the constraint

NET CLK_int TNM CLK

i.e. give the internal net a timegroup name the same as the pin name. In the
XNF file this comes out as

SIG,CLK_int,TNM=CLK.

Spectrum  does neither of these things.

The result is that the pcf file induced by Spectrum has no BEL list for the
timespec but that from Synpliciity does!

The question arises as to why putting 1 MHz timespec puts the P&R time up by
a factor of 5! I would have thought that in this case a purely random
placement would almost certainly  meet the spec. Looking at the results of
PAR I get  something like 50 MHz. I susspect I'll need to play with some PAR
options to stop it working itself to death unnecessarily.



Article: 14240
Subject: Re: CORDIC (was: Best way to digitally synth. stable frequencies?)
From: rbmccammon@mmm.com (Roy McCammon)
Date: Thu, 21 Jan 1999 08:01:44 -0600
Links: << >>  << T >>  << A >>
have a look at:

http://devil.ece.utexas.edu/



Erik Widding wrote:
> 
> Peter wrote:
> >
> > The CMOS Cookbook, by Don Lancaster, ISBN 0-672-21398-2, mine is 1977!
> 
> Mine is actually early 90's.  This series, i.e. "Op-Amp Cookbook", etc.,
> is right up there with the bible, "Art of Electronics".
> 
> > There is also an algorithm called Cordic. I have no info but a post in
> > comp.arch.fpga should elicit a response from one of the very helpful
> > contributors there.
> 
> I did a quick net search, and turned up a few papers by Ray Andraka,
> that give a very good introduction.  As such, I would like a few of the
> CORDIC experts out there to recommend a good reference text on CORDIC
> specifically, and distributed math, or atleast a hardware oriented
> algorithm book more generally.
> 
> I have some great texts in my library that are "software oriented".
> Seems the computer science world likes to assume that a register
> oriented or traditional DSP architecture, with a multiplier, is being
> used.  Xilinx apnotes, and other papers have always been where I have
> needed this sort of information, but a good general text on the matter
> would be nice.
> 
> Any suggestions?
> 
> Regards,
> Erik Widding
> Birger Engineering, Inc.
> 
> >
> > >Peter wrote:
> > >> There is a way to get
> > >> digital-precision sinewaves from a feedback shift register arrangement
> > >> - email me if you need more info; I have a book. Get the whole thing
> > >> into a small FPGA.
> > >
> > >What is the name of the book?
> >
> > --
> > Peter.



Opinions expressed herein are my own and may not represent those of my employer.

Article: 14241
Subject: Re: CORDIC (was: Best way to digitally synth. stable frequencies?)
From: Ray Andraka <randraka@ids.net>
Date: Thu, 21 Jan 1999 10:24:29 -0500
Links: << >>  << T >>  << A >>
Unfortunately, I have also found very little in the way of texts that emphasize
hardware algorithms rather than software ones.  One text I have found useful,
is EE Swartzlander's computer arithmetic.  It can be difficult to obtain, as it
is out of print.  That text can also be a little hard to read as it is a
collection of key papers on algorithms such as Volder's original CORDIC paper,
Walther's CORDIC extensions etc.

As far as CORDIC goes, I've seen mention of the CORDIC algorithm in one or two
texts, but that is usually only a page or two, and in at least one case the
information was not entirely accurate.  The lack of tutorial information on the
CORDIC algorithm was one of the motivators for writing the CORDIC paper (which
can be obtained from my website).  So far, I have not seen anything that even
comes close for explaining the CORDIC algorithm.  There is an on-line
bibliography at utexas which lists over 200 CORDIC papers.  I have a link to
that bibliography on the CORDIC page on my website (I'm too lazy to go look up
the url, and besides that will get you to my website).   While the page is
accessible, I don't think it is being maintained anymore, as I have recieved no
replies to suggestions for additional papers or updates to urls from Shaoyun in
the past two years.  If I could get permission (Shaoyun are you out there?) I'd
be happy to transfer the bibliography to my site and maintain it.

Now for the Don Lancaster books... I can't speak for the Op-Amp Cookbook, but I
did have copies of the TTL and CMOS cookbooks back in the mid 70's.  As I
became more experienced, I found that many of the design tips he espoused in
his books are actually pretty poor design practice.  The books are fine for the
hobbyist, but should not be relied on as a 'bible' for stuff that is going into
production.  If nothing else, his books did prompt me to understand the
internals of chips to a degree that I might not have otherwise.  For example,
it is simply amazing what you can do with a 555 timer aside from the obvious
timing applications.

Erik Widding wrote:

> Peter wrote:
> >
> > The CMOS Cookbook, by Don Lancaster, ISBN 0-672-21398-2, mine is 1977!
>
> Mine is actually early 90's.  This series, i.e. "Op-Amp Cookbook", etc.,
> is right up there with the bible, "Art of Electronics".
>
> > There is also an algorithm called Cordic. I have no info but a post in
> > comp.arch.fpga should elicit a response from one of the very helpful
> > contributors there.
>
> I did a quick net search, and turned up a few papers by Ray Andraka,
> that give a very good introduction.  As such, I would like a few of the
> CORDIC experts out there to recommend a good reference text on CORDIC
> specifically, and distributed math, or atleast a hardware oriented
> algorithm book more generally.
>
> I have some great texts in my library that are "software oriented".
> Seems the computer science world likes to assume that a register
> oriented or traditional DSP architecture, with a multiplier, is being
> used.  Xilinx apnotes, and other papers have always been where I have
> needed this sort of information, but a good general text on the matter
> would be nice.
>
> Any suggestions?
>
> Regards,
> Erik Widding
> Birger Engineering, Inc.
>
> >
> > >Peter wrote:
> > >> There is a way to get
> > >> digital-precision sinewaves from a feedback shift register arrangement
> > >> - email me if you need more info; I have a book. Get the whole thing
> > >> into a small FPGA.
> > >
> > >What is the name of the book?
> >
> > --
> > Peter.



--
-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: 14242
Subject: Power Consumption in FPGAs
From: Andres Garcia <garcia@enst.fr>
Date: Thu, 21 Jan 1999 17:50:26 +0100
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------F22A00F97E223914A03120CE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


If anyone knows something about power consumption in FPGAs
or if you want to discuss about it, please, send me an e-mail.

Thank you.


--------------F22A00F97E223914A03120CE
Content-Type: text/x-vcard; charset=us-ascii;
 name="garcia.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Andres Garcia
Content-Disposition: attachment;
 filename="garcia.vcf"

begin:vcard 
n:Andres David;GARCIA GARCIA
tel;pager:http://www-elec.enst.fr/~garcia/index.html
tel;fax:(33-1)45-80-40-36
tel;home:(33-1)40-78-68-32
tel;work:(33-1)45-81-78-03
x-mozilla-html:FALSE
org:E.N.S.T.;Communications and Electronics Department
version:2.1
email;internet:garcia@elec.enst.fr
title:PhD Student
adr;quoted-printable:;;46, Rue Barrault=0D=0A75634, Paris 13 Cedex.=0D=0AFrance.;;;;
fn:Garcia G. Andres D.
end:vcard

--------------F22A00F97E223914A03120CE--

Article: 14243
Subject: Re: CORDIC (was: Best way to digitally synth. stable frequencies?)
From: "E. Kappos" <asekappos@ntu.edu.sg>
Date: 21 Jan 1999 17:09:12 GMT
Links: << >>  << T >>  << A >>


Erik Widding <widding@ieee.org> wrote in article
<36A72744.79B17423@ieee.org>...

> I did a quick net search, and turned up a few papers by Ray Andraka,
> that give a very good introduction.  As such, I would like a few of the
> CORDIC experts out there to recommend a good reference text on CORDIC
> specifically, and distributed math, or atleast a hardware oriented
> algorithm book more generally.

Kai Hwang's book on Computer Arithmetic, published in late 70's
has a reasonable exposition, and references to the original 
publications - CORDIC was invented in the 50's.

For more references, look any recent Proceedings of the IEEE Int. Conf.
on Computer Aritmetic - there are always articles on CORDIC which
will help you trace more recent publications.

Euthymios Kappos
Article: 14244
Subject: Re: Free max+plus ll simulator on win95
From: Brian Boorman <XZY.bboorman@harris.com>
Date: Thu, 21 Jan 1999 12:41:03 -0500
Links: << >>  << T >>  << A >>


Hamish Moffatt wrote:<...snip...>

> So is there ANY way to do free FPGA work yet? Like little projects for home?
>

<...snip...>

> So what other options are there? I want to be able to enter a design,
> either in an HDL or schematics (preferably the former), simulate it,
> and route it for a device I can get reasonably easily. (Xilinx is the easiest
> to get in Melbourne in my experience.)
>
>

<...snip...>

> Hamish
> --
> Hamish Moffatt       Mobile: +61 412 011 176       hamish@rising.com.au
>
> Rising Software Australia Pty. Ltd.
> Developers of music education software including Auralia & Musition.
> 31 Elmhurst Road, Blackburn, Victoria Australia, 3130
> Phone: +61 3 9894 4788  Fax: +61 3 9894 3362  USA Toll Free: 1-888-667-7839
> Internet: http://www.rising.com.au/


Get the Xilinx Student Edition Tools. They are about $75 (US). About as close to
free as they come. You will get support for CPLD's and small FPGA's

--
Brian C. Boorman
Harris RF Communications
Rochester, NY 14610
XYZ.bboorman@harris.com
<Remove the XYZ. for valid address>


Article: 14245
Subject: Re: CORDIC (was: Best way to digitally synth. stable frequencies?)
From: Ray Andraka <randraka@ids.net>
Date: Thu, 21 Jan 1999 13:15:28 -0500
Links: << >>  << T >>  << A >>
Shaoyun is still there, and continues to maintain the site.  I heard from him
today.

Ray Andraka wrote:

>  I have a link to
> that bibliography on the CORDIC page on my website (I'm too lazy to go look up
> the url, and besides that will get you to my website).   While the page is
> accessible, I don't think it is being maintained anymore, as I have recieved no
> replies to suggestions for additional papers or updates to urls from Shaoyun in
> the past two years.  If I could get permission (Shaoyun are you out there?) I'd
> be happy to transfer the bibliography to my site and maintain it.



--
-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: 14246
Subject: Re: Q: Counting GHz pulses - ?
From: Tom Burgess <tom.burgess@hia.nrc.ca>
Date: Thu, 21 Jan 1999 10:47:08 -0800
Links: << >>  << T >>  << A >>
If you haven't already considered using ECL,
here are some components that should do the job:

SY89424 - 60MHz to 1 GHz frequency synthesiser for your reference clock
SY100E137 - 8 bit 1.8 Ghz (min) ripple counter for time interval count

from the Synergy Semiconductor online databook at
http://www.synergysemi.com/databook/ (under ClockWorks and ECLinPS)
Also Motorola is good for ECL parts, data and app notes, but
the data is a bit less easy to browse:
http://www.mot-sps.com/logic

You will also need PECL/TTL translators, if, as is likely, you
want to run the ECL from +5 and Ground. The Motorola ECL databooks and
app. notes will be very helpful if ECL is new to you.

I doubt that you will find a GHz PLL/VCO on an FPGA anytime soon,
though this could have some interesting applications. Maybe as an
embedded block in an FPGA destined for RF comm?

regards, 
Tom Burgess
-- 
Digital Engineer
National Research Council of Canada
Herzberg Institute of Astrophysics
Dominion Radio Astrophysical Observatory
P.O. Box 248, Penticton, B.C.
Canada V2A 6K3

Email:        tom.burgess@hia.nrc.ca
Office:       (250) 490-4360 
Switch Board: (250) 493-2277
Fax:          (250) 493-7767
Article: 14247
Subject: Re: Hard porting to FPGA Express
From: "Andy Peters" <apeters@noao.edu.NOSPAM>
Date: Thu, 21 Jan 1999 13:51:58 -0700
Links: << >>  << T >>  << A >>
Rickman wrote in message <36A6BF07.BCAE24B0@yahoo.com>...
>Synopsys, are you listening???
>
>VHDL-93 NOW!


Aww, Rick, they're not listening.  Bastids.


-- a
------------------------------------------
Andy Peters
Sr. Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters@noao.edu

"In the beginning, there was darkness.  And it was without form, and void.
And there was also me!"
-- Bomb #20, John Carpenter's "Dark Star"



Article: 14248
Subject: Re: FPGA express warning
From: "Andy Peters" <apeters@noao.edu.NOSPAM>
Date: Thu, 21 Jan 1999 14:02:21 -0700
Links: << >>  << T >>  << A >>
Khaled benkrid wrote in message <36A8CAB1.8011E8FD@qub.ac.uk>...
>Hi All!
>
>I am using FPGA express 1.2 (comes with Foundation 1.3 Student edition).
>
>I have the following warning when optimizing my designs:
>" Port XX has no net attached to it-no pad cell inserted in this port
>FE-PADMAP-2". These ports are inputs in my design, so it is a problem
>for me. I want to know how to work around this.


Assuming schematic entry.  Make sure the wire's actually attached to the
port.  (Trust me.  Been there, done that.)

Make sure you've put an IBUF on the schematic after the port.


-- a
------------------------------------------
Andy Peters
Sr. Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters@noao.edu

"In the beginning, there was darkness.  And it was without form, and void.
And there was also me!"
-- Bomb #20, John Carpenter's "Dark Star"



Article: 14249
Subject: hdl vs. schematics - was <snip>
From: "Bruce Nepple" <brucen@imagenation.extra.com>
Date: Thu, 21 Jan 1999 13:34:37 -0800
Links: << >>  << T >>  << A >>
OF course, schematics are of no use at all in the design of complex state
machines.  And, I'd hate to have to draw schematics to determine whether to
use 1-hot or binary coded for size and/or speed in a particular application.
It is extremely easy to whip out implementation experiments with an HDL.

My rule of thumb is that any design above about 5K gates will get to market
faster with an hdl (assuming a working design flow than you understand).

And, what about multiple designers working together on 1 design.  Schematics
can get real messy (just getting the interface names correct is a pain).

Also, Schematics are much more difficult to modify and maintain as the
project moves forward and inevitably changes.

The art of drawing a good schematic is *much* more time consuming than
cranking out well commented hdl.

But, my favorite aspect of hdl's is the  "print on error only" test bench.

bruce

Ray Andraka wrote in message <36A6BD35.52386799@ids.net>...
>John, welcome to comp.dsp!
>
>Well, you already know that I am a strong proponent for schematic based
design
>for FPGAs, so you might be a little surprised by the following response.
>
>The way I see it, HDLs do have real advantages, however there are some
serious
>disadvantages when applied to high performance FPGA designs.  As I see it,
the
>two real advantages that HDLs have over schematics for FPGA design are:
>
>a)  Access to archived designs.  A schematic design requires a compatible
>viewer or hardcopy to read an archived design.  As schematic entry tools
>evolve, some of the older formats get dropped, so some legacy designs may
no
>longer be readable, and all designs are inaccessible to someone without the
>correct reader.  On the other hand a text based design can be read by any
text
>editor capable of accessing a file the size of the design file (notepad
will
>probably not cut it for more complicated designs).
>
>b) Significantly enhanced simulation capabilities.  VHDL brings with it the
>ability to simulate using behavioral models in place of a detailed circuit
>simulation using the same toolset as used with the detail design
simulation.
>This provides the ability to simulate a design or design fragment before
the
>detail design is done (helps to avoid getting to far down the wrong path).
>Verified portions of the design can also be aliased to behavioral models to
>cut down on the computational power required to do the simulation.
>
>There are several other "benefits" bandied about by the marketing types,
>which, depending on the context have some degree of truth:
>
>a)  Design readability.  A well done hierarchical schematic is generally
more
>readable than HDL code...its the picture is worth a thousand words thing.
>However, in my experience, the average engineer does not do a very good
>schematic.  The number one crime is the lack of or improper use of a
>hierarchy.  Schematic based design does not naturally impose hierarchy, so
the
>temptation is to create a flat schematic.  Sixty plus pages of flat
schematic
>are next to impossible to read.  Almost as bad are the hierarchical designs
>that have not been logically partitioned.  To keep schematics readable, the
>schematic at each hierarchical level should be limited to one page, the
page
>should be fairly sparse (probably no more than 10 symbols) and the
hierachical
>blocks should be logically partitioned so that each is a complete function
to
>itself.  All this takes some time to do, but there are rewards for
following a
>strict discipline.  It can be difficult to resist the urge to squeeze one
more
>thing (many times over) onto a page.  HDLs on the other hand, naturally
>encourage hierarchy in the design which leads to legibility.  Also, certain
>circuit elements lend themselves to a textual description; examples are
state
>machines and combinatorial decoders.  We've all seen examples of both that
>wind up being a jumbled mess of AND and OR gates wired in some
>incomprehensible manner.  <I do use a schematic methodology for one-hot
state
>machines that makes the schematic look like a flow chart to make schematic
>statemachines easy to construct and understand>
>
>b) Design reuse.  This is more of an issue of properly using hierarchy.  A
>design that is hierarchically broken down into successivly smaller complete
>functional units lends itself to reuse regardless of the capture
methodology.
>The fact that HDLs encourage good hierarchical breakdown makes  HDL design
>fragments natural for reuse.  In schematics, you need to work at it.
>
>c) Design portability.  This again is partly a hierarchy issue.  If the
design
>is properly broken into a hierarchy, it can be retargeted at a different
>technology by simply changing the library for the lowest levels of the
>hierarchy.  This requires libraries for the different technologies to have
the
>same interfaces to the upper levels: for schematics it means the same
symbol
>names, shapes, sizes, pin locations etc.  For HDLs it means pretty much the
>same thing.  Where the different vendors have really not standardized in
this
>area, the user needs to create a translation library to smoothly transition
>from one technology to another.  Developing unified library elements is a
>sizable task, and one I don't think the one FPGA design a year crowd wants
to
>embark upon.  Now the translation is a little easier in HDLs, because the
>graphic elements (pin locations and symbol size) are no longer in the
>equation.  This is a small consolation.  Where HDLs have the big advantage
is
>when synthesis is used to infer the low level structure of the design.  If
>that is the case, there is little the user needs to do to port the
>design...assuming he did not go to low level construction.  The problem
with
>synthesizing from a higher level description is that you give up the
control
>of the design implementation and placement.  The cell granualarity in most
>FPGAs is not handled well with current synthesis, although significant
>improvements have been made mostly with libraries of primitive functions
>targeted at specific devices.  In high performance/density designs you
usually
>lose to much when you relinquish control of the implementation to the
>synthesizer.
>
>d) Ease of entry.  Proponents of VHDL often state that a design can be
entered
>faster in textual form.  IMHO, it really depends on the design and your
design
>objectives.  State machines, for example can be easily entered and later
>grokked in a textual format.  The state machine implementation can be
>controlled do some degree with the coding style and with synthesis option
>switches.  On the other-hand dataflow and memory intensive designs tend to
be
>easier to do with a schematic.  A true advantage textual descriptions have
>over schematics is the ability to easily accommodate parameterized elements
>(for instance data path elements whose implemented bit width is dependent
on
>context), something that is quite difficult to do with schematics.
Generally
>for schematics, some macro generator is used to produce a symbol and an
>optimized implementation.
>
>For schematic entry, there is usually no synthesis (Altera MaxPlus II is an
>exception), so the implementation is explicit.  The place and route tools
will
>do some boolean minimization and such to improve the design.  In
schematics,
>this is easily overridden if there is a reason for a particular
implementation
>using mapping constructs and placement attributes.  These are applied
directly
>to the affected schematic symbol.  Applying similar implementation and
design
>constraints in VHDL is tedious (akin to writing a textual netlist of the
>circuit).  Applying placement constraints is inconsistent from tool to
tool,
>and those constraints in some cases are not hierarchical.  For low level
>design control, the schematic entry method is considerably easier to do.
>
>So the bottom line is  HDLs do give significant advantages for simulation
and
>archiving, and depending on the project, may also provide advantages by
>synthesizing the design details.  For FPGA designs other than low
performance
>ones, the cost of synthesis is currently too high in terms of lost
performance
>and density to achieve the advantages from high level (RTL) synthesis.
That
>cost can be circumvented by low level instantiation, but it is currently
more
>painful than doing the same low level designs in schematic form.  Keep in
>mind, that the designs I do are typically DSP data path designs with sample
>rates between 40 and 100 MHz, and often in slower speed grade devices.
>--
>-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
>
>




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

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

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

Custom Search