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

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

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

Custom Search

Messages from 14450

Article: 14450
Subject: Re: No. of CLBs in Xilinx nearly 100% can't implement.
From: "Austin Franklin" <aus3tin@darkroom.com>
Date: 30 Jan 1999 02:19:12 GMT
Links: << >>  << T >>  << A >>
> My design passed a simulation

I assume it was a static simulation, with no back annotated timing
information?

> When I use HardWare Debugger,I wonder why it didn't work.

If you don't have TIMESPECs, or aren't really using them, you need to. 
And, as Ray said, with a design that full, you really need to do
floorplanning if you expect to have a prayer of a chance of it working,
unless it is a design that doesn't have to run fast.  Aside from
floorplanning, you may have to do some logic mapping (using FMAPs and
HMAPs) and also re-write code to get the logic to be compiled into less
levels of logic, or even duplicate signals so you make timing.

I would suggest you spend some time getting to understand the architecture
of the FPGA, and how much routing and resource utilization can affect
timing...  Any time you use an HDL with an FPGA you decouple your self from
this, and, unfortunately, the results can be disastrous.  You can, of
course, instantiate everything and write a net list in HDL ;-)  Probably a
lot more work than you bargained for.

If you really want your design to run as fast as it can, and use the least
amount of resources, you may best be served by implementing parts/all of
your design in schematics with logic mapping and floorplanning in place
from the start.  Personally, I start by doing this to the data path, and
keep the control logic in HDL....then after I get the data path placed and
timing optimized, I can get a truer picture of how much my control logic
needs to be optimized.

It has been said to not lock your pinouts and let the router place them
where they fall...I think this is a bad practice, and believe that if you
understand the architecture of the FPGA, you can do MUCH better hand
placement of the I/O, which will facilitate your making timing, and using
less resources, if done right.

Austin Franklin
austin@darkroom.com



Article: 14451
Subject: Re: Benchmarks: Schematic vs Synthesis (Exemplar vs Synplicity)
From: "Austin Franklin" <aus3tin@darkroom.com>
Date: 30 Jan 1999 02:32:56 GMT
Links: << >>  << T >>  << A >>
>                   Area (PFU)     Speed (MHz)
> Schematic          21            95.2
> Exemplar           30            75.6
> Synplicity(1)      33            57.4
> Synplicity(2)      32            67.2

Thank you very much for doing the test, and writing up the results! (er,
not that they are a surprise to me ;-)

Austin

P.S. Would anyone be able to try this with FPGA Express????

Article: 14452
Subject: Re: The development of a free FPGA synthesis tool
From: Zoltan Kocsi <root@127.0.0.1>
Date: 30 Jan 1999 14:03:34 +1100
Links: << >>  << T >>  << A >>
Jamie Lokier <spamfilter.jan1999@tantalophile.demon.co.uk> writes:

> Be careful with this.  GCC treats main() specially even for a
> free-standing target.  Your function main() does not compile to a
> function called main(), but is instead renamed __main() by the compiler.

Yes, I'm aware of that. Mind you, I have a 2.7.2 crosscompiling for
m68k-elf and it doesn't do that, it calls main simply main. I know 
gcc used to do it but this version doesn't:

[tade]~>cat > lo.c
extern void foo( int );

main()
{
	foo( 13 );	
}
^D
[tade]~>cc68 -g -O2 -c lo.c
[tade]~>objdump68 --disassemble lo.o

lo.o:     file format elf32-m68k

Disassembly of section .text:

00000000 <main>:
   0:   4e56 0000       linkw %fp,#0
   4:   4878 000d       pea d <main+0xd>
   8:   61ff 0000 0000  bsrl a <main+0xa>
   e:   4e5e            unlk %fp
  10:   4e75            rts

On the target my assembly reset code calls main() and finds it, 
I don't use any libs at all (other than what I've written).

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: 14453
Subject: Re: Ratings for Synplicity Synplify
From: Phil Hays <spampostmaster@sprynet.com>
Date: Fri, 29 Jan 1999 21:35:43 -0800
Links: << >>  << T >>  << A >>
Rick Filipkiewicz wrote:
 
> I've been watching the comments on Synplicity with interest as we have
> just bought  it.  It looks like
>  I'll have to be careful with CLB  and timing estimates.

I'm a mostly happy Synplify on NT user (currently mostly aimed at
Xilinx).  In general the tool does a fairly good job starting with a
reasonably "pure" and readable source file.  There are some code changes
that can improve timing, and for the paths that are really messy there
is no substitute for putting in the exact logic you want as "black
boxes".

Some general comments on timing numbers:  Xilinx par does not try very
hard with no timing constraints.  Your numbers may (and may not!) change
a lot when you put realistic timing requirements on your design. 
Secondly, none of the current lot of HDL tools have any idea as to the
physical relationships between various parts of your design.  While the
estimated timings from Synplify (or other HDL tools) are usually not a
bad estimate, some paths will be rather slower and some will be rather
faster than the estimates because of the physical shape of the design.

A couple of minor warnings and hints:  If you intend to design for high
speed and/or need multiple clocks, I'd suggest using the Synplicity
constraint ".sdc" file only for pushing Synplify to work harder/less
hard on various paths, deleting the Xilinx ".ncf" file that Synplify
creates by default based on the .sdc file, and putting the real timing
specification in the the Xilinx User Constraint ".ucf" file.  If you
don't plan on pushing the parts hard and have one clock, using the .sdc
file used as suggested (with -improve and -route where needed) works
fine.  As comments are NOT preserved by "Scope", make any changes to the
.sdc file with a text editor.  "Twenty two dot four!!??"  Why did this
timing value get set to 22.4?  Err.. Never mind.  I guess you had to be
there.  A comment in the .ucf file something like:

# clk to out from foo     15.8 ns
# routing @200ps/inch       .6 ns
# clock period            40.0 ns
# Clock skew budget        1.2 ns
# Setup spec into bar = clock - skew - routing - output = 22.4 ns

can go a long ways to reducing late project stress and strain... (I
almost wrote "stain".  Hmmm.)


HDL analyst can be useful for understanding why a path is too slow, and
for understanding what the tool built.  It is not a requirement for
doing either.  If you don't have HDL analyst, I'd suggest that you set
your device options result output to .xnf, I find it a more human
readable format than .edif.


-- 
Phil Hays
"Irritatingly,  science claims to set limits on what 
we can do,  even in principle."   Carl Sagan
Article: 14454
Subject: Re: No. of CLBs in Xilinx nearly 100% can't implement.
From: "ram" <rmcbain@istar.ca>
Date: Sat, 30 Jan 1999 01:00:00 -0800
Links: << >>  << T >>  << A >>
Austin Franklin wrote in message <01be4bf6$c4dd7b80$7aab15d1@drt1>...

<snip>

Read the following words slowly and absorb from a Jedi...

>I would suggest you spend some time getting to understand the architecture
>of the FPGA, and how much routing and resource utilization can affect
>timing...


>Any time you use an HDL with an FPGA you decouple your self from
>this, and, unfortunately, the results can be disastrous.  You can, of
>course, instantiate everything and write a net list in HDL ;-)  Probably a
>lot more work than you bargained for.

>If you really want your design to run as fast as it can, and use the least
>amount of resources, you may best be served by implementing parts/all of
>your design in schematics with logic mapping and floorplanning in place
>from the start.

>Personally, I start by doing this to the data path, and
>keep the control logic in HDL

....then after I get the data path placed and
>timing optimized, I can get a truer picture of how much my control logic
>needs to be optimized.

>It has been said to not lock your pinouts and let the router place them
>where they fall...I think this is a bad practice, and believe that if you
>understand the architecture of the FPGA, you can do MUCH better hand
>placement of the I/O, which will facilitate your making timing, and using
>less resources, if done right.


Spoken by a craftsman.  If, in case you didn't read between the lines, a
(schematic) picture is worth a thousand (HDL) words. ...sometimes, anyways.
Although I still prefer a state diagram over an HDL.

Regards, Rick


Article: 14455
Subject: Q:Installing Xilinx F1.4 license server
From: Lim Sung-taek <totohero@poppy.snu.ac.kr>
Date: Sat, 30 Jan 1999 18:39:07 +0900
Links: << >>  << T >>  << A >>
 Hello, I'm installing Xilinx F1.4 to several PCs. And my newly updated
license.dat indicates  an ethernet card number of an NT server. I think
that
I should install so-called 'license server' but I have no information
about
it. I can't even figure out what should I start with. Can anyone advice
me what to do or where can I  get the related information?
Thank you for reading this.

Sung-taek Lim (totohero@poppy.snu.ac.kr)

Article: 14456
Subject: Announce: Stackable XILINX FPGA Modules PC104 or standalone
From: APS <resp@associatedpro.com>
Date: Sat, 30 Jan 1999 08:20:26 -0500
Links: << >>  << T >>  << A >>
Announcement:

The APS X240 is a stackable FPGA card which supports XILINX SPARTAN,
4000, 4000XL, 4000XLA , 5200 series FPGAs in the 240QFP package. The
boards support up to a 4085 FPGA. The boards also support up to 512K
SRAM on each module, an on board oscillator (socketed), and PLENTY of
accessible IO connectors. The boards are in the 8 or 16 PC104 format,
support DMA, IRQ, and MEM or IO type access. Because of the small size
and mounting holes, the boards are also ideal for stand alone
applications where a high powered FPGA is needed in an embedded system.
The FPGAs can be downloaded via the PC104 bus, or via EPROM, or via on
board XCHECKER cable port. The board is also available with the XILINX
Foundation series software. A complete development kit with Foundation
VHDL/VERILOG , router and SPARTAN  XCS40 FPGA on the X240 board  can be
purchased for as little as $1300.00!! A schematic entry only version
with a SPARTAN XCS30 can be had for as little as 500.00!!!   . Also ask
about our network enabled embedded options which allow the board to be
controlled and downloaded via 10 base T ethernet!!!

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

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

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


Article: 14457
Subject: Re: Q:Installing Xilinx F1.4 license server
From: Ray Andraka <randraka@ids.net>
Date: Sat, 30 Jan 1999 10:51:09 -0500
Links: << >>  << T >>  << A >>
1.4 used the ethernet address or c drive serial in place of a dongle.  To
install it on multiple machines you either need unique license files for
each machine, or you need to make all the machine IDs the same.  If your
key were the c drive serial number, you could get into Norton or similar to
alter the c drive serial numbers so they all match.  Where your key is the
ethernet tag, you are stuck using it only on the machine with the matching
tag unless you can get an update license file from Xilinx.

It may be time to upgrade to 1.5.  Xilinx wound up with a huge customer
support problem by requiring every user to obtain a customized license file
from customer service.  In 1.5, you have a CD key number provided in the
distribution packet that unlocks the CD, similar to the setup microsoft
uses.  1.5 also put the floorplanner back in and made some rather large
improvements to PAR.  1.5 is finally almost as usable as the old Xact6 was.

Lim Sung-taek wrote:

>  Hello, I'm installing Xilinx F1.4 to several PCs. And my newly updated
> license.dat indicates  an ethernet card number of an NT server. I think
> that
> I should install so-called 'license server' but I have no information
> about
> it. I can't even figure out what should I start with. Can anyone advice
> me what to do or where can I  get the related information?
> Thank you for reading this.
>
> Sung-taek Lim (totohero@poppy.snu.ac.kr)



--
-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: 14458
Subject: Re: Help for the scientifically-challenged
From: tcoonan@mindspring.com (Thomas A. Coonan)
Date: Sat, 30 Jan 1999 16:15:45 GMT
Links: << >>  << T >>  << A >>
But, of course, the absolute premise that reconfigurable is "better"
is misleading, isn't it?  The price paid for reconfigurabiliy surely
must be increased silicon, power and overal system complexity.  When
does the benifit adaptability justify its cost?  Hopefully, your
analogy can help capture this as well.

How 'bout the whole microcoded processors of the 70-80s, versus
the hardwired control of our current RISCs?  Perhaps, this is the
counter-analogy where flexibity was rejected in favor of a more
streamlined, targeted design..
>Hi, I've been researching reconfigurable computing for an article, and I
>have found some good explanations of how it works. What I lack is a
>solid analogy to give to other people to help them understand how it
>works and how it's an improvement over what we had before. Something
>like general purpose computing is like a Yugo, and reconfigurable
>computing like a 'Vette -- something that explains why it's better. Has
>anyone heard such an analogy that explains this concept to people like
>me who use computers but don't know how to make them? Any help would be
>appreciated. Thanks!
>

Article: 14459
Subject: Re: The development of a free FPGA synthesis tool
From: ian@airs.com (Ian Lance Taylor)
Date: 30 Jan 99 17:55:07 GMT
Links: << >>  << T >>  << A >>
spamfilter.jan1999@tantalophile.demon.co.uk (Jamie Lokier) writes:

>Zoltan Kocsi writes:
>> In a free-standing environment main() is just a function like any other.
>> There's nothing special about it.

>Be careful with this.  GCC treats main() specially even for a
>free-standing target.  Your function main() does not compile to a
>function called main(), but is instead renamed __main() by the compiler.

>libgcc.a supplies a function called main() which calls your __main(),
>after calling any static constructors it can find.  Often there aren't
>any in C.  libgcc.a's main() also calls atexit() on some targets before
>calling your __main().

That's not precisely correct.

When gcc compiles for some targets, if it sees a function named
`main', it automatically inserts a call to `__main' at the start of
the function.  The function __main is provided in libgcc.a.  It runs
any global constructors, and arranges to run global destructors when
the program exits.

However, for other targets, gcc does not behave in this fashion.  For
example, for most hosted ELF environments, gcc simply arranges to put
code in the .init section which runs the global constructors, and
relies on the ELF environment to run that code before main is invoked.

There are even a couple of other mechanisms in use for specific
targets.

>What I'm saying here is that unless you make special arrangements, even
>in a free-standing environment, a standalone GCC-compiled program will
>do stuff before reaching what you thought was called main().

This is normally true, but not always--for some free-standing
environments gcc will fail to run the global constructors if the
program is not invoked in the right way.
-- 
Ian Taylor | ian@airs.com | First to identify quote wins free e-mail message:
Latin etymology: ``The cat (musio) is so called because it is a foe to mice
(muribus).  Common people call it cat (cattus) because it catches.  Others
say because it sees (catat).''
Article: 14460
Subject: Re: C to Hardware translators [was: The development of a free FPGA synthesis tool]
From: Jamie Lokier <spamfilter.jan1999@tantalophile.demon.co.uk>
Date: 30 Jan 1999 19:00:08 +0000
Links: << >>  << T >>  << A >>
Jonathan Bromley writes:
> ems@riverside-machines.com.NOSPAM wrote:
>> i hadn't realised that you could actually *do* anything with Handel-C.
>> is there a practical mechanism for targetting xilinx? does it work,
>> how do you do it, how much??

> 1) yes, Xilinx and nothing else AFAIK

It does Altera too.

> 2) yes
> 3) there's a good user manual, you just write the code and
>    submit it to the compiler :-) and get ?XNF out of it;
>    not sure about that last bit, but in any case you need the
>    Xilinx P&R tools to do the physical stuff

As well as XNF, You can get a Xilinx- or Altera-compatible EDIF out.

> 4) about UKP 2K, but see the website, I think there is a demo version
> Handel-C website: http://www.embedded-solutions.ltd.uk/

Called "try-before-buy", feature and size restricted.

> I have no commercial/financial interest in the company

I do, though it's a minor affiliation.

-- Jamie
Article: 14461
Subject: Re: Off topic DRAM/SIMM question....
From: Lasse Langwadt Christensen <fuz@kom.auc.dk>
Date: Sat, 30 Jan 1999 19:21:34 GMT
Links: << >>  << T >>  << A >>
Austin Franklin wrote:
> 
> > > The DRAMs are probably 16Mx3 (partially bad 16Mx4 chips) !
> 
> You were right!  I buzzed out the SIMM.  The parity bits aren't connected,
> all the chips only use 3 bits, and four of the chips have two data pins
> tied together (which I think is weird...), so if 8 chips are using 3 bits,
> and 4 are using 2 bits, that makes 32 bits!
> 
> Hum.
> 
> Austin

coould be that on some of the chips only some of the bits work at
certain
addresses, tieing two bits together migth result in thoose two bits 
working on all addresses? (hope it's not used for serious work :) 
  
--Lasse                 
--___--_-_-_-____--_-_--__---_-_--__---_-_-_-__--_----
Lasse Langwadt Christensen, MSEE (to be in 1999) 
Aalborg University, Department of communication tech.    
Applied Signal Processing and Implementation (ASPI)      
http://www.kom.auc.dk/~fuz , mailto:langwadt@ieee.org
Article: 14462
Subject: Re: Off topic DRAM/SIMM question....
From: Lasse Langwadt Christensen <fuz@kom.auc.dk>
Date: Sat, 30 Jan 1999 19:23:35 GMT
Links: << >>  << T >>  << A >>
Austin Franklin wrote:
> 
> > The DRAMs are probably 16Mx3 (partially bad 16Mx4 chips) !
> 
> That could be so, but then they would not be true parity SIMMs, because you
> need to do parity on a byte by byte basis....unless they are ECC, in which
> case, it doesn't matter, because the ECC has to be calculated across all 32
> bits...
> 
> I tried them in my Tyan 1662D 440FX chip set system board, and they pass
> the power up memory test but NT won't boot, so I changed back to my 32M
> SIMMs, and it boots fine.  Something is different with these chips...
> 
> Also, they are the only chips installed in the memory sockets...
> 
> Thanks,
> 
> Austin

NT is picky about RAM, it may work with win9x

(maybe thats some of the reason why NT more stable then win9x? :))

--Lasse                 
--___--_-_-_-____--_-_--__---_-_--__---_-_-_-__--_----
Lasse Langwadt Christensen, MSEE (to be in 1999) 
Aalborg University, Department of communication tech.    
Applied Signal Processing and Implementation (ASPI)      
http://www.kom.auc.dk/~fuz , mailto:langwadt@ieee.org
Article: 14463
Subject: Re: C to Hardware translators [was: The development of a free FPGA synthesis tool]
From: Jamie Lokier <spamfilter.jan1999@tantalophile.demon.co.uk>
Date: 30 Jan 1999 19:27:00 +0000
Links: << >>  << T >>  << A >>
Jonathan Bromley writes:
> All I meant was that it is sometimes handy to be able to express 
> certain types of logic as a sequence of intermediate calculations
> even though the result will NOT be pipelined.

`shared expr' gets close to what you want.  I.e.:

shared expr value1 = f1 (value);
shared expr value2 = f2 (value);
shared expr value3 = f3 (value1, value2);

etc.  All combinational.

> I know that this sort of thing is open to abuse and
> can give the synthesis tool a serious headache, but I still think it
> would be a nice extension for those who needed it.

The synthesiser is quite happy with it.

> OK, I'll take you up on that.  Can you please show me some kind of timing
> diagram which would allow me to check that I am right in my beliefs about
> what happens when you communicate over a Handel-C channel?  For the
> three different scenarios:  sender gets there first, target gets there
> first, both arrive in the same clock cycle.  This is something that 
> is rather skated-over in the published documentation.

1.  Sender waits until a target is ready.  Goto 3.
2.  Target waits until a sender is ready.  Goto 3.
3.  Expression on sender side is assigned to variable on target side.
    Takes 1 cycle, as all assignments.

Easy :-)

> What's so deep or so magic about prialt?  It just sounds sensible to me.
> I 100% concur with your comment about modularity and scalability.

Well I know nobody used `prialt' because I found tons of bugs a few
months ago :-)  (All fixed now).

prialt makes perfect sense and there's nothing deep really.  But there
are some really useful tricks you can pull.  E.g., this pipeline does
not work if the send blocks (spot the bug):

  while (1)
    par {
      input ? var1;
      var2 = var1 * 10;    // Some misc. calculation step 1.
      var3 = var2 * var2;  // Step 2.
      output ! var3 - 1;   // Step 3.
    }

But this pipeline does work all the time (assuming no typos).  The logic
is small too, despite the code size.  Note: code does not normally have
to look like this.  Good use of macros etc...

  while (1)
    par {
      input ? var1;
      var2 = var1 * 10;    // Some misc. calculation step 1.
      var3 = var2 * var2;  // Step 2.

      // Note: Normally this is a one or two line macro call.
      // Expanded here for illustration.
      par {
        shared expr outval = var3 - 1; // Step 3.
        static unsigned 1 status0, status1;
        shared expr full = status1 ^ status0;
        int buffer;

        buffer = outval;
        do {
          par {
            status1 = status0;
            prialt {
              case output ! (full ? buffer : outval):
                break;
              default:
                status0 = ~status0;
                break;
            }
          }
        } while (full);
      }
    }

Enjoy, <ahem>
-- Jamie
Article: 14464
Subject: Re: Off topic DRAM/SIMM question....
From: z80@ds2.com (Peter)
Date: Sat, 30 Jan 1999 20:20:39 GMT
Links: << >>  << T >>  << A >>
Could you please be more precise?

The way a CPU interfaces to RAM is determined by the hardware, not the
O/S. But lots of people say what you say.

>NT is picky about RAM, it may work with win9x


--
Peter.

Return address is invalid to help stop junk mail.
E-mail replies to zX80@digiYserve.com but remove the X and the Y.
Please do NOT copy usenet posts to email - it is NOT necessary.
Article: 14465
Subject: Re: PLL in FPGA
From: Steve@s-deweynospam.demon.co.uk (Steve Dewey)
Date: Sat, 30 Jan 99 20:33:48 GMT
Links: << >>  << T >>  << A >>
In Maxplus, Altera have a library function called 74297. A look at the texas 
data book reveals that this is a Digital PLL. Texas also do an app note, I 
forget the location. The schematic is viewable in maxplus, probably even in the 
free version.

It can only generate a pulse train that _ON AVERAGE_ is a multiple of the signal
input frequency. It cannot produce the steady locked frequency an analogue PLL
can.

Guess who found that out the hard way :-(


-- 
Steve Dewey
Steve@s-deweynospam.demon.co.uk
Too boring to have an interesting or witty .sig file.

Article: 14466
Subject: Re: Benchmarks: Schematic vs Synthesis (Exemplar vs Synplicity)
From: "Alex M" <alex@yellowhouse.force9.net>
Date: Sat, 30 Jan 1999 21:24:35 -0000
Links: << >>  << T >>  << A >>
What benchmarks do you get for different vendors silicon ? How about Altera
and Xilinx ?

This is not objective as Exemplar have had a long term OEM relationship with
Lucent and so have had more access to the internal workings of the Lucent
parts. You would expect they would do a better job because of this.

What versions of Exemplar and Synplicty were you using ?


Don Husby wrote in message <78tbba$iaa$1@info3.fnal.gov>...
>
>I ported a small schematic-based design to VHDL in order to benchmark
>two synthesizers.  Here is a summary of the results:
>
>                  Area (PFU)     Speed (MHz)
>Schematic          21            95.2
>Exemplar           30            75.6
>Synplicity(1)      33            57.4
>Synplicity(2)      32            67.2
>
>The circuit is a serial link transmitter macro that transmits 33-bit
>data words.  It has an 8-word input FIFO, 4B/5B encoder, shifter,
>and frame synchronizer.
>
>The circuit was targeted for a Lucent Orca 2T04A-3.  This is their
>"medium" speed grade.  It was designed to run at 50MHz (12.5 MHz
>serial bit rate).
>
>The VHDL code was simulated using Aldec Active-VHDL before sythesis.
>The schematic was entered using Workview Office with my custom "xfunc"
>extensions.
>
>You can get Schematic (.pdf), VHDL code, and disassembled (and annotated)
>chip files (*.eqn) at
>  http://www-ese.fnal.gov/eseproj/trigger/synth_ben.zip
>
>Some notes:
>(1)(2) One of the strong points of HDL coding is the ability to use
>higher-level constructs, and leave the optimization to the software.
>This was tested by implementing the FIFO word counter in two different
>ways.  This is a 3-bit up/down counter that saturates at Count==7.
>A 4th bit is used to indicate an overflow- one count past saturation.
>
>Expressed as "high level" concepts this is:
>  if (Write = '1') then
>    if (Wc(2 downto 0) < 7) then
>      Wc(2 downto 0) <= Wc(2 downto 0) + 1;
>    end if;
>  else Wc(2 downto 0) <= Wc(2 downto 0) - 1;
>  end if;
>  Wc(3) <= Write and Wc(2) and Wc(1) and Wc(0);
>
>Expressed as logic equations this is:
>Wc(0) <= (Write and Wc(2) and Wc(1)) or not Wc(0);
>Wc(1) <= (Write and Wc(2) and Wc(1))
>          or (not Write xor Wc(1) xor Wc(0));
>Wc(2) <= (Write and Wc(1) and Wc(0))
>          or (Wc(2) and(Write or Wc(1) or Wc(0)));
>Wc(3) <= Write and Wc(2) and Wc(1) and Wc(0);
>
>This should fit in a single Orca PFU and run very fast.
>Both Synplicity and Exemplar attempted to implement the high-level
>version using Orca carry logic, and this turned out to be the speed
>bottleneck for the circuit.  Exemplar had a switch to turn off this
>"optimization" and produced a pretty good implementation for the circuit.
>
>Synplicity had no such switch.  In addition to using the carry logic,
>it put the flip-flops in a separate PFU, increasing the delay as well
>as size of the circuit.  Using the re-coded equations resulted in the
>faster time for Synplicity(2).
>
>(3) Synplicity extracted some clock-enables correctly, and extracted
>some synchronous set/reset signals, but did this poorly, resulting
>in some related functions being spread across multiple PFU when they
>should have been grouped together.  It did not attempt to use the
>Orca FE-Mux feature, which would have made a significant improvement.
>
>(4) Exemplar used the FE-mux feature well, but in some cases it
>substituted it for clock-enable, resulting in some extra routing
>resources being used, but no measurable size or performance penalty.
>It also used CE correctly most of the time, however it botched it
>where several signals should have used the same CE, but the signals
>were aliased, causing related functions to not be mapped to the
>same PFU.
>
>(5) Both synthesizers inferred memory, however, Synplicity
>put useless tristate buffers between the memory outputs and
>flip-flops resulting in 5 extra PFUs and extra delay.  This
>was the timing bottleneck for the faster synplicity version.
>
>(6) Exemplar preserved many signal names.  On others it added
>some extra postfixes like "_int" or "_dup".  Synplicity also
>preservered some signal names, but added "Z0Z" to most signal
>names.  This made many signal names difficult to recognize.
>
>See the disassembled chip files for examples.
>
>


Article: 14467
Subject: Re: Off topic DRAM/SIMM question....
From: "Austin Franklin" <aus3tin@darkroom.com>
Date: 31 Jan 1999 02:21:58 GMT
Links: << >>  << T >>  << A >>
> 
> NT is picky about RAM, it may work with win9x
> 

I have experienced the exact same thing.  It is even fussy about DIFFERENT
manufacturers SIMMs/chips in the same system....

Austin

Article: 14468
Subject: Re: Help for the scientifically-challenged
From: Tom Kean <tom@algotronix.com>
Date: Sun, 31 Jan 1999 03:52:23 +0000
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------E74B6B2DE4E69BB7550C73BB
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

How about:
General purpose computing is like a family saloon: safe and reliable and
easy to drive

ASIC's are like an open top sports car: high performance but dangerous and
difficult to drive

Reconfigurable is like a convertible because you get into a lot of trouble
if you try
and reconfigure while its running :-)

Dave Fuhriman wrote:

> Hi, I've been researching reconfigurable computing for an article, and I
> have found some good explanations of how it works. What I lack is a
> solid analogy to give to other people to help them understand how it
> works and how it's an improvement over what we had before. Something
> like general purpose computing is like a Yugo, and reconfigurable
> computing like a 'Vette -- something that explains why it's better. Has
> anyone heard such an analogy that explains this concept to people like
> me who use computers but don't know how to make them? Any help would be
> appreciated. Thanks!

--------------E74B6B2DE4E69BB7550C73BB
Content-Type: text/x-vcard; charset=us-ascii;
 name="tom.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Tom Kean
Content-Disposition: attachment;
 filename="tom.vcf"

begin:vcard 
n:Kean;Tom
tel;fax:UK +44 131 556 9247
tel;work:UK +44 131 556 9242
x-mozilla-html:TRUE
org:Algotronix Ltd.
adr:;;P.O. Box 23116;Edinburgh;;EH8 8YB;Scotland
version:2.1
email;internet:tom@algotronix.com
title:Director
note:Web Site: www.algotronix.com
x-mozilla-cpt:;4768
fn:Tom Kean
end:vcard

--------------E74B6B2DE4E69BB7550C73BB--

Article: 14469
Subject: Re: Benchmarks: Schematic vs Synthesis (Exemplar vs Synplicity)
From: Phil Hays <spampostmaster@sprynet.com>
Date: Sun, 31 Jan 1999 00:26:48 -0800
Links: << >>  << T >>  << A >>
Don Husby wrote:

>                   Area (PFU)     Speed (MHz)
> Schematic          21            95.2
> Exemplar           30            75.6
> Synplicity(1)      33            57.4
> Synplicity(2)      32            67.2
 
Synplify(3)          38 clb(par)  142.8 +


(3) Suppose that 95.2 MHz isn't fast enough.  I took the VHDL and
retargeted it to Xilinx 4002XL-09 in a 84 pin package, using Synplify
5.08 and M1.5I.  One change was needed to the VHDL, gsr is a reserved
name for Xilinx so I changed it to rst.  Looked at the output, looked
like 7 ns period was a reasonable answer.  Wrote a .ucf file asking for
that.  Did not write a .sdc file, Synplify can produce better answers if
pushed right.  Did not do any floorplanning, floorplanning can often
speed up designs, even the most basic form of floorplanning, selecting a
reasonable pinout.  Did not write any physical VHDL, which can be needed
for the critical path of a design, and/or to take advantage of special
features of a part and/or to work around gacks in the toolset.  

Result was a period shorter than 7 ns.  Par reports using 38 clbs. 
Clock time was about an hour and a half, mostly for running 100 passes
of place and route (:-)) to improve the result from 7.48 ns to better
than 7 ns.  I did not check to see how much better I could get it.  My
time was ~10 minutes.  I suspect I can make it run faster.  How much, I
don't know.  I don't know enough about Orca parts to know how much
faster it would run in the fastest speed grade.

I have a trial copy of Exemplar, and I'm going to try to get results out
of it next.

Any one care to retarget this with schematic entry to Xilinx to see how
much faster they can get this design to run?  I'd be interested in the
results, and how long it takes to do.


-- 
Phil Hays
"Irritatingly,  science claims to set limits on what 
we can do,  even in principle."   Carl Sagan
Article: 14470
Subject: Re: Benchmarks: Schematic vs Synthesis (Exemplar vs Synplicity)
From: Phil Hays <spampostmaster@sprynet.com>
Date: Sun, 31 Jan 1999 00:42:14 -0800
Links: << >>  << T >>  << A >>
Alex M wrote:

> What benchmarks do you get for different vendors silicon ?

Warning: every design is slightly different.  Some designs just fit
better on some types of FPGAs, and that DOES NOT mean that a different
design will fit better on the same type of FPGA.  Also, not every tool
does the same quality of job with every type of FPGA.  Fair benchmarks
are not easy to setup.

I may have a current copy of Altera software around, and may try it from
the VHDL.  Schematics I'll leave for someone else.


-- 
Phil Hays
"Irritatingly,  science claims to set limits on what 
we can do,  even in principle."   Carl Sagan
Article: 14471
Subject: Re: Benchmarks: Schematic vs Synthesis (Exemplar vs Synplicity)
From: husby@fnal.gov (Don Husby)
Date: Sun, 31 Jan 1999 17:02:02 GMT
Links: << >>  << T >>  << A >>
 thor@sm.luth.se (Jonas Thor) wrote:
> On Fri, 29 Jan 1999 22:05:42 GMT, husby@fnal.gov (Don Husby) wrote:
> Does really the synthesizer provide any information about where to
> place the flip-flops? From my experience the synthesizer only produces
> a netlist with primitives or macros. Then it is up to the placer to
> place the primitives/macros. 

You're right. Apparently what happened is that Synpicity generated
"replicated logic" and so had two flip-flops per signal.  The Lucent
mapper had to place both flip flops in separate blocks.  Replicated
logic was clearly uncalled for here, since the fanout was only 2-3
loads.

Article: 14472
Subject: Re: Benchmarks: Schematic vs Synthesis (Exemplar vs Synplicity)
From: husby@fnal.gov (Don Husby)
Date: Sun, 31 Jan 1999 17:07:33 GMT
Links: << >>  << T >>  << A >>
Phil Hays <spampostmaster@sprynet.com> wrote:
> Synplify(3)          38 clb(par)  142.8 +
> 
> (3) Suppose that 95.2 MHz isn't fast enough.  I took the VHDL and
> retargeted it to Xilinx 4002XL-09 in a 84 pin package, using Synplify
> 5.08 and M1.5I.

As I mentioned in my notes, I used a "medium" -3 speed grade.  Lucent
also has speed grades ranging to -7 which appear to be better than twice
as fast as the -3 parts.

Article: 14473
Subject: Re: Benchmarks: Schematic vs Synthesis (Exemplar vs Synplicity)
From: husby@fnal.gov (Don Husby)
Date: Sun, 31 Jan 1999 17:15:27 GMT
Links: << >>  << T >>  << A >>
"Alex M" <alex@yellowhouse.force9.net> wrote:
> This is not objective as Exemplar have had a long term OEM relationship with
> Lucent and so have had more access to the internal workings of the Lucent
> parts. You would expect they would do a better job because of this.

I was looking for a tool specifically for Orca development.  I don't have
Altera or Xilinx tools intstalled right now.

Besides, the two tools were not that far apart in performance.  It's possible that
a few hacks at the Synplicity tool would remove the tristate buffers, and bring
its size and speed performance up to that of schematics.

Article: 14474
Subject: Re: Benchmarks: Schematic vs Synthesis (Exemplar vs Synplicity)
From: "Austin Franklin" <aus3tin@darkroom.com>
Date: 31 Jan 1999 20:15:56 GMT
Links: << >>  << T >>  << A >>


Don Husby <husby@fnal.gov> wrote in article
<7922k8$dqg$2@info3.fnal.gov>...
> Phil Hays <spampostmaster@sprynet.com> wrote:
> > Synplify(3)          38 clb(par)  142.8 +
> > 
> > (3) Suppose that 95.2 MHz isn't fast enough.  I took the VHDL and
> > retargeted it to Xilinx 4002XL-09 in a 84 pin package, using Synplify
> > 5.08 and M1.5I.
> 
> As I mentioned in my notes, I used a "medium" -3 speed grade.  Lucent
> also has speed grades ranging to -7 which appear to be better than twice
> as fast as the -3 parts.

I am curious what the cost difference is between the two parts. 
Personally, that is how I compare parts...since it is difficult to
establish comparative parameters between two different vendors, I just look
for comparably priced parts that the design will work in....and choose the
cheaper part...  It is silly to take a design that can work in a $14 part,
and implement it in a $45 part...unless you REALLY need the room for future
upgrades...or you really insist on using an HDL ;-)  (that was intended as
somewhat of a joke, for those of you humor impaired HDLers...although there
is some truth to that statement...)

So, if you want to compare Xilinx to Orca to Altera etc. how about setting
a number of price points, and seeing how each one competes on that basis? 
Schematics would probably be the only fair tool to use here, just because
you can never tell how the HDL compiler is going to 'embellish' your design
;-)

Austin



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

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

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

Custom Search