1994 Jul Aug Sep Oct Nov Dec 1994 1995 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1995 1996 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1996 1997 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1997 1998 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1998 1999 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1999 2000 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2000 2001 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2001 2002 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2002 2003 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2003 2004 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2004 2005 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2005 2006 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2006 2007 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2007 2008 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2008 2009 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2009 2010 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2010 2011 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2011 2012 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2012 2013 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2013 2014 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2014 2015 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2015 2016 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2016 2017 Jan Feb Mar Apr 2017

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 17800

Article: 17800
Subject: Re: What's meaning of "Partial Evaluation"
From: Mike Thyer <mjt@cs.york.ac.uk>
Date: Mon, 06 Sep 1999 04:28:45 +0100
Links: << >>  << T >>  << A >>
wudong99_1998@my-deja.com writes:
> I read the phase "Partial Evaluation" from many papers but I don't know
> the exact meaning of it. Who can tell me the meaning or where I can
> find the meaning. Thanks!

I'd be interested to know in which papers you've come across
this term. I wasn't aware much work had been done on applying
partial evaluation in the context of FPGAs, although I know
that someone at Xilinx has been working on it, (they presented
work at the Partial Evaluation Summer School in 1998).

technique, applicable to pretty much any programming language,
where you supply some input to the program earlier than other
input. An example would be a cryptographic encoder, where you
supply the encryption key and the data to encode.  A general
purpose algorithm will work slowly as it repeatedly consults
the key to figure out what it needs to do.  Partial evaluation
takes the general purpose program and a key but not the data
to encrypt and "partially evaluates" it, that is it evaluates
the expressions it can and leaves the expressions it cannot.
The left over expressions, known as the residual code, then
constitutes a program that is dedicated to encrypting data
with just that key.  This code is thus hard wired to the key
that was given to the partial evaluator, many "if" expressions
will have already been evaluated during partial evaluation
and will not exist in the residual code and the residual code
may run many times faster.

Partial evaluation can be applied to more complicated programs
such as interpreters.  Partially evaluating an interpreter
with respect to some program can effectively compile that
program thus eliminating the interpretive overhead without
a compiler ever having been written.

FPGAs can also be seen as removing interpretive layers in that
they remove the need to have a microprocessor repeatedly interpret
its instructions when in a loop.

Combining these two ideas together makes it possible to make
very much faster solutions to things like encryption where the
gates being used in the FPGA will vary dynamically depending on
the key being used.

I should perhaps mention I don't know very much about FPGAs past
the general concept, but as I understand it the length of time
taken by the place+route algorithm hinders the application of
partial evaluation.  The work at Xilinx involved eliminating
gates and reducing the number of hops in connecting wires after
the place+route algorithm had been applied, thus the resulting
circuit may be faster but wouldn't occupy any less space.
Perhaps a cheap'n'cheerful place+route strategy would be useful
for such dynamically generated circuits. It needn't be as optimal
as existing strategies to outperform them, as existing strategies
would only be applied to the general solution to the encryption
circuit, the cheap'n'cheerful one could be applied dynamically to
the residual circuit. Given my relative lack of knowledge of FPGAs
you shouldn't construe this paragraph as comming from someone who
entirely knows what they are talking about.

Mike

ps. this book [1] is a good introduction to partial evaluation,
I don't believe it mentions FPGAs once though.

[1] Partial Evaluation and Automatic Program Generation,
Neil Jones, Carsten Gomard and Peter Sestoft, Prentice Hall 1993.

Article: 17801
Subject: Re: Newbie question: Reading FPGA programming?
From: bureauc@hotmail.com (X)
Date: Mon, 06 Sep 1999 04:10:16 GMT
Links: << >>  << T >>  << A >>

I was afraid of that. Can this bitstream at least be used to recreate
the original in case something happens to this part?  I.e. can I read
this data (assuming the part is not protected) and program it into
another part, or is it in the wrong format at that point?

smith

On Sun, 05 Sep 1999 13:27:49 -0400, Ray Andraka <randraka@ids.net>
wrote:

>If the protection fuse is 'unblown' then you won't be able to read it
>back no matter what.  If not, then you could read back the bitstream, but
>it is not going to mean much to you.  The translation from logic to
>bitstream is not generally published, and it is a monumental effort to
>reverse engineer.  So the short answer is: you're out of luck.
>

>--
>-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: 17802
Subject: Re: Newbie question: Reading FPGA programming?
From: Steve Rencontre <Steve@XXX_REMOVE_XXXrsn-tech.demon.co.uk>
Date: Mon, 06 Sep 1999 07:53:58 +0100
Links: << >>  << T >>  << A >>
On Sun, 05 Sep 1999 14:06:51 GMT, in
<37d278ab.211317103@news.pompano.net> bureauc@hotmail.com (X) wrote:

>Here's a question that may or may not be an ignorant one (if it is,
>just point me to a FAQ that explains it). I have a circuit of unknown
>orign containing an Actel A1010B.  This is an anti-fuse based part, I
>believe, set up to do address decoding.

As others have said, even if you can get the fuse map, turning it back
into logic is well-nigh impossible. However, if you're correct that
this thing is just doing address decoding, why not just cycle the
inputs and monitor the outputs?

In the general case with sequential logic, this approach is
unworkable, but an address decoder is very simple to reverse-engineer
as a black box.
--
Steve Rencontre, Design Consultant
http://www.rsn-tech.demon.co.uk/  --  remember to despam return address

Article: 17803
Subject: Re: Newbie question: Reading FPGA programming?
From: Jonathan Bromley <oxfordbromley@u-net.com>
Date: Mon, 06 Sep 1999 10:15:12 +0000
Links: << >>  << T >>  << A >>
X wrote:
>
> Can this bitstream at least be used to recreate
> the original in case something happens to this part?

If the FPGA architecture allows you to reconstruct the programming
bitstream (not possible in all types!) then you could of course
re-use it to make another copy of the device **in an identical
part**.  A different part, even from the same manufacturer,
would map bitstream bits onto logic elements in a different way
and you would get chutney.

> this data (assuming the part is not protected) and program it into
> another part, or is it in the wrong format at that point?

As I said above - only if you can get another, blank part
of the same type as your original.   And only if the original
actually allows you to read back the bitstream, of course.
Ray Andraka said you can do this with Actel 1010 and I'm sure
he's right, but there are some families (QuickLogic for
example) in which it's in principle impossible to read back the
bitstream after complete programming, because of the way the
programming is done.

In general, copying any programmable device from one part to
another is fairly iffy practice.  EPROMs are perhaps an exception
(just about).  The design files that generated the bitstream
are likely to contain all kinds of information (device
identification, test vectors, version tracking stuff) that can't
reasonably go into the device itself, but are important for
reliable (quality-controlled) programming.  I can understand
your wish to protect future supply of a legacy product where
the design files are lost, but you need to be aware that the
FPGA makers have put a fair amount of effort into making it
as hard as possible for people to rip-off FPGA designs by
chip copying!

Jonathan Bromley

Article: 17804
Subject: Re: What's meaning of "Partial Evaluation"
From: Mike Thyer <mjt@cs.york.ac.uk>
Date: Mon, 06 Sep 1999 13:33:44 +0100
Links: << >>  << T >>  << A >>
I wrote:
> [blah blah blah]

Doing a quick search I found the following URLs which describe
work to dynamically generate circuits for FPGAs by partial
evaluation, just thought I'd mention them if anyone else is
interested.

Reconfigurable Architecture Group
http://www.dcs.gla.ac.uk/research/fpga/papers.html

Dynamic Synthesis of Correct Hardware
(including a link to some nice slides)
http://www.dcs.gla.ac.uk/~tfm/dynhw/

Mike

Article: 17805
Subject: differences between ALTERA-XILINX
From: Yannis Mitsos <gmitsos@duth.gr>
Date: Mon, 06 Sep 1999 15:54:31 +0300
Links: << >>  << T >>  << A >>
I would like to know which are the major differences between the PLD's
of the above companies. I have worked with ALTERA FLEX series.

Thanks

Yannis


Article: 17806
Subject: Re: synthesis comparion between Synplify and FPGA express
From: David Kessner <davidk@free-ip.com>
Date: Mon, 06 Sep 1999 08:21:46 -0600
Links: << >>  << T >>  << A >>
Bruce Nepple wrote:

> I just went through a synthesis round with an Insight FAE.  He took my
> design (fit in Virtex XCV50-4 and xc4020XLA-09 when compiled by FPGA
> Express) and compiled it with Synplicity.  It would not fit in the Virtex
> part (112%), and completely used up the 4020XLA (100%).  I'm not sure if it
> met speed with Synplicity.  Synopsys used 78% of the Virtex, and about 62%
> of the 4020 (which is interesting in itself, since the Virtex supposedly has
> more gates - HA!).
>
> It was a pure "logic" design with lots of registers, state machines and a
> few 16 bit ram register arrays. (about 20Kgates, running at 40Mhz with up to
> 10 or more levels of logic).
>
> In the process, he uncovered several Synplicity bugs that were no problem
> for Synopsys.
>
> I believed the "Synplicity is better" stuff, and had it do better on a few
> state machine test cases (where I had problems with Synopsys), but for the
> "big" design, it went south big time.  I'll stick with Synopsys, thank you.
>
> Bruce

The mainstream tools are all about the same.  One tool
might be better at one application than another, but on
average they are all about the same.  It's best to try them
and use the one that gives you the best results.  Synplicity
seems to be slightly better than the others but it is by no
means the best at everything.

In my work, I've found that Synplicity has been consistently
better-- but not so much better that I'd give a blanket statement
like "Synplicity is the absolute best".

As for your trial application, I would not trust the Insight FAE.
It's not that they are bad, they aren't, but they don't know your
design and don't have the time to really play with it.  There are
many options that can give a significant difference in logic size.

As someone else pointed out, I've found at least one application
that Synopsis FPGA Express totally died on.  Assuming that
your Insight FAE was correct, then that just goes to show
you that your mileage may vary...

David Kessner
davidk@free-ip.com        http://www.free-ip.com/


Article: 17807
Subject: Re: What's meaning of "Partial Evaluation"
From: "Alvin E. Toda" <aet@lava.net>
Date: Mon, 6 Sep 1999 09:30:40 -1000
Links: << >>  << T >>  << A >>
On Mon, 6 Sep 1999, Mike Thyer wrote:

> I wrote:
> > [blah blah blah]
>
> Doing a quick search I found the following URLs which describe
> work to dynamically generate circuits for FPGAs by partial
> evaluation, just thought I'd mention them if anyone else is
> interested.
>
> Reconfigurable Architecture Group
> http://www.dcs.gla.ac.uk/research/fpga/papers.html
>
> Dynamic Synthesis of Correct Hardware
> (including a link to some nice slides)
> http://www.dcs.gla.ac.uk/~tfm/dynhw/
>
> Mike
>
>

Thanx, had some problems accessing the sites but did find
out something for the second. It seems that this is a good
idea because FPGA's do not have such enormous capacity as
a gate array might have, and by putting routing in during
the hardware runtime some efficiencies could be obtained.
The article pointed out that the same software algorightms
used to partially evaluate a program at runtime would be
used in a hardware compile to lay out the basic logic.

But it seems that some performance is lost in the
re-routing time that the FPGA must (?) shut down to
re-program. But perhaps another part of the board
or system might be in operation at that time? BTW,
it would seem that a fault modeling of the FPGA
would be difficult because it would depend on the
system input at the time of the fault. Perhaps a type
of structual test of the un-oberserved logic is
more feasible, while the system test will verify the
dynamic routing.

-al toda

###########################################################
Alvin E. Toda              aet@lava.net
sr. engineer               Phone: 1-808-455-1331
2-Sigma          WEB: http://www.lava.net/~aet/2-sigma.html
1363-A Hoowali St.
Pearl City, Hawaii, USA


Article: 17808
Subject: Re: QuickLogic FPGAs
From: Lukose Ninan <lukose@gte.net>
Date: Mon, 06 Sep 1999 21:52:18 GMT
Links: << >>  << T >>  << A >>
Mostly Good experiences especially with support from Quicklogic. I
actually liked the 6.3 version of their software tool as compared to the
present 8.0 mainly in the area of post layout simulations and cross
probing. Also the highest part they have is the 4090 (90,000 gates).
Hope that helps!

Wayne Miller wrote:

> Anyone have any experience (good or bad) with FPGAs from QuickLogic?


Article: 17809
Subject: TI C30 DSP core in FPGA?
From: Lukose Ninan <lukose@gte.net>
Date: Mon, 06 Sep 1999 21:55:23 GMT
Links: << >>  << T >>  << A >>
Could anyone point me to some websites for people who make TI compatible
Really appreciate the help and your time.


Article: 17810
Subject: xilinx software
From: wannarat <wannarat@fivedots.coe.psu.ac.th>
Date: Tue, 07 Sep 1999 07:41:03 +0700
Links: << >>  << T >>  << A >>
Hello
I can't load to CPLD how can I solve  this problem
Regard
Wannarat Suntiamorntut
ksuwanna@kmitl.ac.th


Article: 17811
Subject: Re: QuickLogic FPGAs
From: Assaf Sarfati <azarfati@bioil.jnj.com>
Date: Tue, 07 Sep 1999 09:19:23 +0300
Links: << >>  << T >>  << A >>
Wayne Miller wrote:
>
> Anyone have any experience (good or bad) with FPGAs from QuickLogic?

I've used them in the past (last design: approx. 2 yrs) for several
small designs (less than 4 K-gates). I've started with schematic,
changed to their included Verilog tools and then to 3rd-party VHDL
synthesis and simulation tools with the QL P&R.

The chips were fast and easily routable; you could get high utilization
and high speed without having to fiddle with cell locations and routing
like other chips (IIRC, you couldn't change routing manually except for
changing pinout or rerunning the P&R). You could normally assign any
pinout without P&R problem, which made PCB design much easier.

The tools were pretty good, though when I switched to 3rd-party tools
I've lost the cross-probing capability of the QL tools.

One problem was the manufacturablity of boards with QL chips: these
chips are OTP and can't be programmed on board; you must remove them
from the tray to program them and then return them to the tray for the
the PCB assembly. This caused a high percentage of bad boards which had
to be reworked manually, because the fine-pitch pins are bent easily by
this programming method. I haven't been using them for a while so I
can't tell you if they've added an ISP capability; if not, PCB yield may
be a problem.

Another problem: their PC-based programmed was very slow (approx. 5
minutes for a 2-K chip). This problem may have been fixed by better
programmers and faster PCs.

Regards
Assaf Sarfati

Article: 17812
Subject: Re: xilinx software
From: Klaus Falser <kfalser@durst.it>
Date: Tue, 07 Sep 1999 06:50:28 GMT
Links: << >>  << T >>  << A >>
In article <37D45F1F.FA0FBF59@fivedots.coe.psu.ac.th>,
wannarat <wannarat@fivedots.coe.psu.ac.th> wrote:
> Hello
> I can't load to CPLD how can I solve  this problem
> Regard
> Wannarat Suntiamorntut
> ksuwanna@kmitl.ac.th
>
>

The bsd-files are usually in a directory <Xilinx-Dir>\xc9500\data,
where <Xilinx-Dir> is the directory you have installed the developement
tools into.
I would also check if the environment variable XILINX is set correctly.

Best regards

--
Klaus Falser
Durst Phototechnik AG
I-39042 Brixen

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Article: 17813
Subject: xilinx placer score?
From: Jeff Streznetcky <jeff.streznetcky@lmco.nospam.com>
Date: Tue, 07 Sep 1999 06:15:20 -0400
Links: << >>  << T >>  << A >>
I know that the PAR score is the total amount of time (in ps) that the
design is missing its timing constraints.

What is the placer score?

-Jeff


Article: 17814
Subject: Re: VHDL 200x Survey Participation Request
From: mench@mench.com
Date: 7 Sep 1999 15:39:19 -0400
Links: << >>  << T >>  << A >>
Folks,

Sorry for following up to my own posting, but I wanted to both remind
you to please fill out our survey and to announce that we've extended
the deadline to 15 September.  So, please take a few minutes and visit
http://www.vhdl200x.org/survey/surveyPart1.html.

Thanks,

Paul

On 1 Sep 1999 17:02:04 -0400, in comp.lang.vhdl mench@mench.com wrote
in article <7qk48c$13l$1@mench.mench.com>:

> Dear Colleague,

> You can provide an important impetus to the enhancement of VHDL by spending
> a few minutes of your valuable time completing a survey.  The data
> collected by this survey will guide the VHDL 200x team in proposing the
> next round of extensions and modifications to VHDL.  To participate, please
> visit http://www.vhdl200x.org/survey/surveyPart1.html.

> As you know, the IEEE requires that the VHDL standard be recertified at
> least every five years.  There is currently underway a recertification and
> language refinement as a "maintenance release," which will conclude late
> this year or early next.  The VHDL standards community is already working
> on the subsequent revision, a significant enhancement, entitled VHDL 200x.
> The VHDL 200x revision will dramatically reduce the impact of electronic
> system obsolescence and pave the way for future generations of CAD/EDA
> systems that support rapid and cost-effective development.

> The VHDL 200x team is sponsored and supported by the Air Force Research
> Laboratory.  The work is being done in cooperation with the IEEE DASC VHDL
> Analysis and Standards Group (VASG). Team members include University of
> Virginia, Virginia Commonwealth University, Menchini & Associates, EDA
> Standards Consulting, and the Advanced Technology Institute.

> requesting that the survey be completed by SEPTEMBER 10th.  Initial results
> will be presented at the 1999 Fall VIUF Workshop.  (The Workshop's
> preliminary program is at http://www.vhdl.org/viuf/conf/viuf99/index.html.)

> Again, the survey web address is:
> http://www.vhdl200x.org/survey/surveyPart1.html.

> Thanks in advance for participating.

> Sincerely,
> The VHDL-200x team

--
Paul Menchini          | mench@mench.com |"The last thing I want to do is
P.O. Box 71767         | 919-479-1670[v] | doubt in the users' minds."
Durham, NC  27722-1767 | 919-479-1671[f] |  --Don Jones, MS's Y2K Product Mgr

Article: 17815
Subject: Re: Flex8000 trouble
From: tronsmith@my-deja.com
Date: Tue, 07 Sep 1999 20:31:39 GMT
Links: << >>  << T >>  << A >>
Armin,

[I posted this from my regular server, but am not sure everything
I send out of there makes it to the rest of the world, so am
posting via deja as well.]

I am not familiar with the language of the partial code
you've included, but there are applicable comments for
FIFOs in video application that go beyond implementation details:

If the FIFO is asynchronous, i.e., the input clock writing
data into it is not in any way synchronous to the output clock
the output _while the input is active_. To do so is an invitation
to problems arising from metastability and/or timing divergence.
A typical EF will go active synchronous to the FIFO output circuit,
and the EF goes inactive synchronous to the FIFO input circuit.

The metastability problem arises when the output
(read) circuit samples the EF, looking for it to be inactive.
Because the EF inactive transition happens anywhere relative
to the output clock, the circuit sampling the flag will at
some point go metastable. At video rates, this is likely
to occur with significant probability, enough to mess
up the output circuit operation to the extent of making
a very poor image (missed or duplicated pixels).

Another problem is what I've called timing divergence,
by which I mean that the EF is sampled in more than
one point. Due to the routing of the FPGA, the timing delay
is going to be different to the two different sampling points.
This timing divergence will eventually cause the EF to be
sampled true at one point and false at the other point. Depending
on what the circuits do, this will lead to varying degrees
of trouble.

So, how can FIFOs be successfully used in video? The answer
is simple: Never look at the EF unless the input is not active,
only look at the EF when in a known video blank period. To avoid
overflowing the FIFO during active video periods, construct
a Half Full flag (HF), double (or even triple) sample it in only
one spot to avoid metastability and timing divergence, and design
the FIFO output circuit to work in burst mode when video input is
active.

Four words may be too shallow a FIFO. Sixteen words is a
convenient size, the HF indicates to the output circuit
to burst 8 words out of the FIFO during video active period.

This may seem like a lot of work, but it is necessary. I've
seen (commercially released!) IC's with video ports where
is is obvious that someone didn't correctly handle the video
FIFO flags.

Examining your partial code, I'd suggest looking for a
problem in the value of word[].q at the time the case
statement is evaluated. If word[] is a two-bit counter
which increments dependent upon an EF being inactive,
that is most likely the problem.

Hope this helps,

- John

In article <37D13395.93321611@rz.uni-karlsruhe.de>,
Armin Mueller <ual6@rz.uni-karlsruhe.de> wrote:
> Hello,
>
> I'm just implementing some video stuff on an Altera Flex8000.
> At some points the chip behaves unexpected:
>
> I have a 4 word FIFO. "dblbuf" is the DMA input and has a
> constant value for testing pupose, "word" is the FIFO counter,
> "buffer" is the FIFO memory. All pins are fixed, but the device
> usage is below 50%. "dllc2" is about 7 Mhz.
>
> When simulating, everything works fine. In practice, the buffer
> sometimes drops information which should be static and constant!!!
>
> Worse, when I shift the buffer contents by 16 bits fixed,
> it drops information even during simulation (routing dependent).
>
> What's wrong? Is the chip so prone to routing? Is the compiler
> reducing something to asynchrone logic? Are the LPM modules
> more stable?
>
> Armin
>
> dblbuf[15..0]	: dff;		-- constant
> buffer[63..0]	: dff;
> word  [1..0]	: dff;
>
> buffer[].clk	= dllc2;
> case word[].q is
> 	when  0 =>	buffer[15.. 0].d = dblbuf[];
> 			buffer[63..16].d = buffer[63..16].q;
> 	when  1 =>	buffer[15.. 0].d = buffer[15.. 0].q;
> 			buffer[31..16].d = dblbuf[];
> 			buffer[63..32].d = buffer[63..32].q;
> 	when  2 =>	buffer[31.. 0].d = buffer[31.. 0].q;
> 			buffer[47..32].d = dblbuf[];
> 			buffer[63..48].d = buffer[63..48].q;
> 	when  3 =>	buffer[47.. 0].d = buffer[47.. 0].q;
> 			buffer[63..48].d = dblbuf[];
> end case;
>
>

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Article: 17816
Subject: Re: synthesis comparion between Synplify and FPGA express
From: "Bruce Nepple" <brucen@imagenation.extra.com>
Date: Tue, 7 Sep 1999 14:51:06 -0700
Links: << >>  << T >>  << A >>

a@z.com wrote in message <37D15566.571C649D@z.com>...
>Can you share your design with the group so we can have an independent
>verification of your reports? If it is true than a huge leap forward has
been
>made by FPGA Express which until now was trailing badly both Synplicity and
>Exemplar LS.

I wish I could share the Verilog for the design, but it is pretty
proprietary stuff.

I did not use the FPGA Express timing constraints (through the XNF) .  I put
all pin and timing constraints in a .ucf file.  I only used Synopsys
constraints to assign pullups and to specify the frequency for the 2 clock
domains (50Mhz, compile for speed).  It took about 5 minutes to compile
under Synopsys and the FAE said it took about 5 minutes under Symplicity
(which he thought was strange).  It's about 6K lines of Verilog and comments
in 14 files.

All of the state machines (2 have over 20 states) are one hot and are
compiled with // synopsys parallel_case full_case pragmas (very
important!!).  All states are explicity defines as parameters.  All 107 of
the ram register arrays are instantiated as 16x1 bit cells.

There is a BIG internal 32 bit tri-state bus with about 15 read/write
registers (some are pretty sparse).  It has 167 IO, with 140 IOB Flip flops.
32 pins have input register, output register and input buffer used.

Version wise, I am using FPGA Express 1.5i with all service packs, and I
assume the FAE used the latest and greatest Symplicity.

This is what the FAE told me:
<quote>
I attached the results.  I made the changes we discussed, contacted
Synplicity and let them know what to expect (e.g. some bug reports), and
have decided that I need to look at this again with v5.2 which is in
pre-release now.

I think the issues with this code reside in the Verilog compile engine.
The way Synplify works is that it first compiles the code into a generic
format ready for mapping. The next step is to invoke technology specific
mappers to map and optimize that logic into a specific device family.
There are different mappers for the 4000E, the 4000XL(A), the Spartan, the
Spartan XL, the Virtex, etc. The technology mapping is actually the key to
Synplicity's success, since their mappers are the best in the industry
today. The problem is, if they do not get a good compile on the input
code, there is not much the mapper can do to compensate.

They do not necessarily have the best compiler (yet...), but as we pick
them apart, they improve. FYI, Synopsys has the industry standard Verilog
compiler. All other synthesis engines must comply (resistance is futile).
Synopsys lacks in the technology mapping arena.

<endquote>

I wish there were some simple way to change my code (strip out comments and
rename internal nodes) so no one could infer or determine functionality.  I
don't have the time.

Bruce

>
>On the other hand you could try the FreeDES design at
http://www.free-ip.com.
>The author was not able to use FPGA Express at all (synthesis took over 6
>hours).
>
>What were the versions of the FPGA Express and Synplicity tools you used?
>
>Catalin Baetoniu
>
>Bruce Nepple wrote:
>
>> I just went through a synthesis round with an Insight FAE.  He took my
>> design (fit in Virtex XCV50-4 and xc4020XLA-09 when compiled by FPGA
>> Express) and compiled it with Synplicity.  It would not fit in the Virtex
>> part (112%), and completely used up the 4020XLA (100%).  I'm not sure if
it
>> met speed with Synplicity.  Synopsys used 78% of the Virtex, and about
62%
>> of the 4020 (which is interesting in itself, since the Virtex supposedly
has
>> more gates - HA!).
>>
>> It was a pure "logic" design with lots of registers, state machines and a
>> few 16 bit ram register arrays. (about 20Kgates, running at 40Mhz with up
to
>> 10 or more levels of logic).
>>
>> In the process, he uncovered several Synplicity bugs that were no problem
>> for Synopsys.
>>
>> I believed the "Synplicity is better" stuff, and had it do better on a
few
>> state machine test cases (where I had problems with Synopsys), but for
the
>> "big" design, it went south big time.  I'll stick with Synopsys, thank
you.
>>
>> Bruce
>>
>


Article: 17817
Subject: Re: synthesis comparion between Synplify and FPGA express
From: "Bruce Nepple" <brucen@imagenation.extra.com>
Date: Tue, 7 Sep 1999 15:11:20 -0700
Links: << >>  << T >>  << A >>
Actually, the Insight FAE is good, and spent quite a bit of time tweaking my
code to get it to work with Synplicity.

I agree with your conclusion..... My whole point in posting is BE CAREFUL
"Your Mileage May Vary".  I really expected Synplicity to do better.

I've been using (and complaining about) Synopsys (Design Compiler and now
FPGA Express) for years, so maybe I unconsciously write "Synopsys
Compatible" code.

Bruce

David Kessner wrote in message <37D3CDFA.7FC48550@free-ip.com>...
>Bruce Nepple wrote:
>
>> I just went through a synthesis round with an Insight FAE.  He took my
>> design (fit in Virtex XCV50-4 and xc4020XLA-09 when compiled by FPGA
>> Express) and compiled it with Synplicity.  It would not fit in the Virtex
>> part (112%), and completely used up the 4020XLA (100%).  I'm not sure if
it
>> met speed with Synplicity.  Synopsys used 78% of the Virtex, and about
62%
>> of the 4020 (which is interesting in itself, since the Virtex supposedly
has
>> more gates - HA!).
>>
>> It was a pure "logic" design with lots of registers, state machines and a
>> few 16 bit ram register arrays. (about 20Kgates, running at 40Mhz with up
to
>> 10 or more levels of logic).
>>
>> In the process, he uncovered several Synplicity bugs that were no problem
>> for Synopsys.
>>
>> I believed the "Synplicity is better" stuff, and had it do better on a
few
>> state machine test cases (where I had problems with Synopsys), but for
the
>> "big" design, it went south big time.  I'll stick with Synopsys, thank
you.
>>
>> Bruce
>
>The mainstream tools are all about the same.  One tool
>might be better at one application than another, but on
>average they are all about the same.  It's best to try them
>and use the one that gives you the best results.  Synplicity
>seems to be slightly better than the others but it is by no
>means the best at everything.
>
>In my work, I've found that Synplicity has been consistently
>better-- but not so much better that I'd give a blanket statement
>like "Synplicity is the absolute best".
>
>As for your trial application, I would not trust the Insight FAE.
>It's not that they are bad, they aren't, but they don't know your
>design and don't have the time to really play with it.  There are
>many options that can give a significant difference in logic size.
>
>As someone else pointed out, I've found at least one application
>that Synopsis FPGA Express totally died on.  Assuming that
>your Insight FAE was correct, then that just goes to show
>you that your mileage may vary...
>
>David Kessner
>davidk@free-ip.com        http://www.free-ip.com/
>
>


Article: 17818
Subject: Re: QuickLogic FPGAs
Date: 7 Sep 1999 22:49:13 GMT
Links: << >>  << T >>  << A >>
Assaf Sarfati <azarfati@bioil.jnj.com> wrote:
: Wayne Miller wrote:
...
: Another problem: their PC-based programmed was very slow (approx. 5
: minutes for a 2-K chip). This problem may have been fixed by better
: programmers and faster PCs.

Also, they insist on people using Windows or HP, but no Linux port
available...

--

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 17819
Subject: Re: QuickLogic FPGAs
From: Zoltan Kocsi <root@127.0.0.1>
Date: 08 Sep 1999 09:42:26 +1000
Links: << >>  << T >>  << A >>
Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de> writes:

> Also, they insist on people using Windows or HP, but no Linux port
> available...

Because they will only " ... consider to support the Linux platform
in the future if such a need becomes strong."

So, until you get stronger you are " ... encouraged to use the
Windows platform ... ".

Regards,

Zoltan

--
+------------------------------------------------------------------+
| ** To reach me write to zoltan in the domain of bendor com au ** |
+--------------------------------+---------------------------------+
| Zoltan Kocsi                   |   I don't believe in miracles   |
| Bendor Research Pty. Ltd.      |   but I rely on them.           |
+--------------------------------+---------------------------------+

Article: 17820
Subject: Re: synthesis comparion between Synplify and FPGA express
From: "Andy Peters" <apeters.nospam@nospam.noao.edu.nospam>
Date: Tue, 7 Sep 1999 18:35:01 -0700
Links: << >>  << T >>  << A >>
Bruce Nepple wrote in message ...
>
>a@z.com wrote in message <37D15566.571C649D@z.com>...
>>Can you share your design with the group so we can have an independent
>>verification of your reports? If it is true than a huge leap forward has
>been
>>made by FPGA Express which until now was trailing badly both Synplicity
and
>>Exemplar LS.
>
>I wish I could share the Verilog for the design, but it is pretty
>proprietary stuff.
>
>I did not use the FPGA Express timing constraints (through the XNF) .  I
put
>all pin and timing constraints in a .ucf file.  I only used Synopsys
>constraints to assign pullups and to specify the frequency for the 2 clock
>domains (50Mhz, compile for speed).  It took about 5 minutes to compile
>under Synopsys and the FAE said it took about 5 minutes under Symplicity
>(which he thought was strange).  It's about 6K lines of Verilog and
>in 14 files.

I've been using the 2.1i tools for a couple of weeks now.  FPGA Express, now
at version 3.2, has improved, tho' it's hard to say whether or not some of
the improvements are due to the synthesis tool, or the place and route
tools, or (as the Insight rep told me), the speed files have changed.

My simple example was a 32-bit added.  I saw a blurb on the xilinx web site
that an XLA part could do a 32-bit adder @ 108 MHz.  With the 1.5i SP2
tools, I couldn't get it to go much faster than about 70 MHz if I
instantiated a CORE adder.  A vhdl

sum <= a + b;

wouldn't go faster than about 35 MHz.

I sent a note pointing this out to the Xilinx hotline, and went back and
forth a couple of times (the tech support told me to use a .ucf, etc. etc.).
He finally sent me his results with my code, and it turns out he was using
the 2.1i tools.

well, a couple of weeks later, the 2.1 tools arrive, and I try the sum <= a
+ b adder, and whaddaya know, over 100 MHz.  Go Figure.  As I said, it's
hard to say what really improved.

-- a
-----------------------------------------
Andy Peters
Sr Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) noao \dot\ edu

The Republican Party: "We've upped our standards. Now, up yours!"


Article: 17821
Subject: Re: synthesis comparion between Synplify and FPGA express
From: "B. Joshua Rosen" <bjrosen@polybus.com>
Date: Tue, 07 Sep 1999 22:31:30 -0400
Links: << >>  << T >>  << A >>
Are you sure that Synopsis didn't throw out half of your design. In my
experience when one synthesis tool gets results that are twice as good
as another it's because of a bug that causes the tool to throw out logic
that it shouldn't. I've never seen this happen in Verilog, but I've seen
happen several times with VHDL.

Josh Rosen, Polybus Systems

David Kessner wrote:
>
> Bruce Nepple wrote:
>
> > I just went through a synthesis round with an Insight FAE.  He took my
> > design (fit in Virtex XCV50-4 and xc4020XLA-09 when compiled by FPGA
> > Express) and compiled it with Synplicity.  It would not fit in the Virtex
> > part (112%), and completely used up the 4020XLA (100%).  I'm not sure if it
> > met speed with Synplicity.  Synopsys used 78% of the Virtex, and about 62%
> > of the 4020 (which is interesting in itself, since the Virtex supposedly has
> > more gates - HA!).
> >
> > It was a pure "logic" design with lots of registers, state machines and a
> > few 16 bit ram register arrays. (about 20Kgates, running at 40Mhz with up to
> > 10 or more levels of logic).
> >
> > In the process, he uncovered several Synplicity bugs that were no problem
> > for Synopsys.
> >
> > I believed the "Synplicity is better" stuff, and had it do better on a few
> > state machine test cases (where I had problems with Synopsys), but for the
> > "big" design, it went south big time.  I'll stick with Synopsys, thank you.
> >
> > Bruce
>
> The mainstream tools are all about the same.  One tool
> might be better at one application than another, but on
> average they are all about the same.  It's best to try them
> and use the one that gives you the best results.  Synplicity
> seems to be slightly better than the others but it is by no
> means the best at everything.
>
> In my work, I've found that Synplicity has been consistently
> better-- but not so much better that I'd give a blanket statement
> like "Synplicity is the absolute best".
>
> As for your trial application, I would not trust the Insight FAE.
> It's not that they are bad, they aren't, but they don't know your
> design and don't have the time to really play with it.  There are
> many options that can give a significant difference in logic size.
>
> As someone else pointed out, I've found at least one application
> that Synopsis FPGA Express totally died on.  Assuming that
> your Insight FAE was correct, then that just goes to show
> you that your mileage may vary...
>
> David Kessner
> davidk@free-ip.com        http://www.free-ip.com/


Article: 17822
Subject: The Embedded Web
From: Chris Stephens <sales@computer-solutions.co.uk>
Date: Wed, 8 Sep 1999 08:18:12 +0100
Links: << >>  << T >>  << A >>
             Visit the Embedded Web
======================

A major new resource for designers, programmers and developers of
Embedded 8/16 and 32 bit microprocessors has just been launched.

COMSOL provide Europe's widest range of development tools and our site
now includes support for most microprocessors from PIC to PPC's.

To that we have now added hundreds of useful links creating the
"Embedded Web",  the best jumping off point for European designers
searching the web.

Our range of ICE, C, C++, RTOS and TCP/IP tools has recently been
enhanced with JTAG & BDM debuggers, Flash programmers and Embedded
Windows GUI's.

Visit us at     http://www.computer-solutions.co.uk

<<<<<<     If you are UK based              >>>>>>
<<<<<<         you might even win           >>>>>>
<<<<<<           a bottle of champagne.     >>>>>>

Regards,  Chris

-----------------------------
Chris Stephens                         E-mail: sales@computer-solutions.co.uk
Computer Solutions Ltd.                Phone & Fax: +44  (0)1 932 829 460
Surrey, KT15 2BZ  England              http://www.Computer-Solutions.co.uk

For the largest range of embedded microprocessor development tools in the UK

Article: 17823
Subject: PROBLEMS WITH ORCA
From: "José" Luis Ayala <jayala@etsit.upm.es>
Date: Wed, 8 Sep 1999 11:11:30 +0200 (CEST)
Links: << >>  << T >>  << A >>
	Hi,
Anyone have any experience with FPGAs from Lucent (ORCA FPGA)?
I have a problem with the mapping process because the ORCA's software
clips and removes all my output ports, giving error messages like:
'<output_register_name>/NEOBUF (NEOINV) undriven or does not drive
anything', '<output_register_name>/NEOLATCH (NEOLATCH) undriven or does
anything'.
Thanks a lot

Jose Luis Ayala
Electronic Engineering Department
Spain

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Article: 17824
Subject: SynaptiCAD Timing Analysis & HDL Test Bench Generation Tools
From: info <info@euro-eda.com>
Date: Wed, 8 Sep 1999 13:17:18 +0100
Links: << >>  << T >>  << A >>
SynaptiCAD timing diagram analysis, HDL test bench generation and
Verilog simulation tools are now available direct in the UK and
Scandinavia from EuroEDA Limited.

http://www.euro-eda.com
--
EuroEDA Limited

Phone: +44 (0)1933 676373
Fax:   +44 (0)1933 676372
Email: info@euro-eda.com
Web:   http://www.euro-eda.com