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 27600

Article: 27600
Subject: I am trying to instantiate ROM with a parameterized width
From: "Robert K. Anderson" <robert.k.anderson@tellabs.com>
Date: Wed, 29 Nov 2000 11:45:27 -0600
Links: << >>  << T >>  << A >>

Hello, I am trying to create a 16 address rom table where the data width
is parameterizable.
I am using VHDL and Synplify 6.0.0, and I am targeting Xilinx Virtex e
Architecture.
I want to be able to read in an external file to initialize the ROM in
VHDL source, not in
a ucf file.
(of course, the initialization file would match whatever data width I
want the ROM to be).

I am attempting to use the VHDL Generate statement to generate a
variable number of ROM16X1 
instances.

However, if I want to use the INIT attribute to initialize a particular
instance of ROM16X1
to some value, I can not do that , because I the synthesizer appeares to
pre-pend
the number onto the instance name, and this  is not correct VHDL syntax.
(I am again
assuming that I will know how the synthesizer will synthesize generated
name instances).

Anyone have any input into this

Thanks,

Bob

Article: 27601
Subject: Re: Gates in a typical small MPU
From: klee@mistress.informatik.unibw-muenchen.de (Herbert Kleebauer)
Date: Wed, 29 Nov 2000 12:29:39
Links: << >>  << T >>  << A >>
In article <6f2V5.16069$nh5.1534936@newsread1.prod.itd.earthlink.net> "Akito" <..@no.com> writes:
>From: "Akito" <..@no.com>
>Subject: Gates in a typical small MPU
>Date: Wed, 29 Nov 2000 07:29:06 GMT

>Greetings,

>    I've been curious about how many gates it takes to achieve
>a simple & small MPU, (such as a Z80 for example).

>Essentially, I have an XC4005XL FPGA, and am writing the pieces of this pie
>out, and they come up 500 gates a piece (Program Counter,
>Address Registers, Data Registers.)

As an exercise for our students we have developed and implemented a 
16 bit minimal processor. The processor can address 64 kByte and 
supports hardware interrupts. It is built with 65 flip-flops and 
about 250 gates. The documentation and schematics can be found at 

ftp://137.193.64.130/pub/mproz/


Article: 27602
Subject: Re: NGDBUILD/UCF Problem
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Wed, 29 Nov 2000 20:46:54 +0000
Links: << >>  << T >>  << A >>


eml@riverside-machines.com.NOSPAM wrote:

> What were the reg names in the EDIF?
>
> On Sat, 25 Nov 2000 12:26:08 +0000, Rick Filipkiewicz
> <rick@algor.co.uk> wrote:
>
> >For me this is not really too dangerous most of the time since the majority
> >of the timespecs are multi-cycled easing up of the basic period one. However
> >if the timespec's job is to tighten the timing  then there's potential for
> >trouble. The one place I *do* tighten specs is on clock domain changing FFs!
>
> A great example of why you can't rely on static timing analysis.
>
> Evan

Yeah. I think it justifies my approach of always doing a post-route sim at least
as a cross check against tool bugs - if nothing else. My favourite so far has
been the point at which Xilinx changed the default setting of the set/reset
setup/hold check flag from enabled to disabled, completely forgetting that this
check covers sync set/reset as well as async.

NB Running post-route simulation has suffered until recently from rather poor
Verilog models. I don't know if the same is true of VHDL but I had to hack in
some ``reduce paranoia'' changes into the 2.1i FF models to get them to work
right. As for 1.5i, the LUT models were a joke. It looks like the 3.1 stuff is
much better - maybe, like the FloorPlanner, Xilinx are coming around to the idea
that ``push the friendly green STA button'' doesn't cut it for timing either. Now
if I could just get those Virtex-E min timings ...

Rick


Article: 27603
Subject: Re: Xilinx Coolrunner going on last time buy?
From: Richard Dungan <postmaster@127.0.0.1>
Date: Wed, 29 Nov 2000 21:00:57 +0000
Links: << >>  << T >>  << A >>
betsy thibault <betsyt@xilinx.com> wrote:

>Nick,
>
>It is true that Xilinx has had to shorten the lifecycle of the 'legacy' Philips
>parts due to lack of fab capacity.  As you probably know, Xilinx has strategic
>partnerships with a couple of fabs, but unfortunately not with the fabs where
>these devices are manufactured.  Hence the end of life notice.  It has always
>been in the plans to move the newest CoolRunner XPLA3 family to a strategic fab
>partner, and that is in the works now.  The XPLA3 family is the next generation
>CoolRunner, sporting even lower power consumption than the legacy products, and
>a full PLA structure that allows for more logic flexibility and excellent
>pin-locking capability. The XPLA3 family is also pin compatible with the parts
>going end of life.
>
>If anyone would like more information on the legacy devices, your local Xilinx
>sales representative or hotline support personnel would be happy to help you
>convert to an even lower power CoolRunner XPLA3 device.
>
>Regards
>
>Betsy Thibault
>Xilinx Product Manager

Thanks for that, Betsy. Could you explain how I drop an XPLA3 into a
slot previously occupied by a PZ5032CS? The system is all 5 volt...

Richard

------------Richard Dungan-------------
Radix Electronic Designs, Orpington, UK
   richardATradix-designDOTcoDOTuk
---------------------------------------

Article: 27604
Subject: Re: Fifo design problem
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Wed, 29 Nov 2000 21:02:49 +0000
Links: << >>  << T >>  << A >>


Joel Kolstad wrote:

> "Andy Peters n o a o [.] e d u>" <"apeters <"@> wrote in message
> news:901ckf$2h1q$1@noao.edu...
> > Are you sure you weren't being screwed by the simulation model?
>
> No, it worked fine in simulation, it was the real design PARed on the real
> live PCB that had problems!
>
> ---Joel

This doesn't surprise me in the least given the average Vendor's attitude to
async problems in simulation

[brief pause while hobby horse is saddled & mounted]

The Vendor's standard lib models either:

o make no attempt at all to deal with async events with the clocked result
being perfectly defined as the input value in the previous timestep. The only
uncertainty comes from the order of event execution in the case where the data
changes at exactly the same time as the clock ... or

o In the Verilog case they use the set/hold check system tasks to set the FF
output to `x'. The problem is it then stays as `x' for the whole clock period
which will just trash the simulation.

This attitude makes a complete nonsense of post synth/route simulation. I
don't know what we're supposed to do here. I got fed up with this & wrote my
own model but was then faced with the problem of getting it through Vendor
sign-off.


Article: 27605
Subject: Reverse-engineering FPGA's
From: Isabelle <isabelle.todescato@libertysurf.fr>
Date: Wed, 29 Nov 2000 22:03:47 +0100
Links: << >>  << T >>  << A >>
Hello, I am a newbie in FPGAs and am interested especially in
test-vector synthesis.

My - naive - questions are :

1.Is it possible from the program file of some FPGA to deduce a gate or
functional block model for the internals of that FPGA ?
2.Do the FPGA manufacturers pusblish the mapping from program files to
FPGA internals ?

Thanks a lot for reading this

Fabien TODESCATO



Article: 27606
Subject: Re: Synplify Benchmarks
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Wed, 29 Nov 2000 21:10:05 +0000
Links: << >>  << T >>  << A >>


Richard Wilkinson wrote:

> The benchmarks I have looked at for P4 machines seems to differ
> considerably. SpecFP2000 and SpecInt2000 give pretty favourable results
> - significantly faster than Athlon 1.2GHz machines for example. But they
> may take the much higher memory bandwidth into account as well. The
> other processor-based benchmarks, as you say, point to the Athlon being
> pretty good in comparison. Does the place and route take so long because
> of memory bottlenecks? Or just a lack of number-crunching power?
>
> >
> > ---Joel Kolstad
>
> Cheers,
>
> Rich

Basically its memory. My upgrade from a 450MHz PI -> 600MHz PIII gained a measly
16% improvement in PAR. This points to using DDR Athlon boards as the way to go.



Article: 27607
Subject: Re: Fifo design problem
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Wed, 29 Nov 2000 21:32:13 +0000
Links: << >>  << T >>  << A >>


Joel Kolstad wrote:

> "Andy Peters n o a o [.] e d u>" <"apeters <"@> wrote in message
> news:901ckf$2h1q$1@noao.edu...
> > Are you sure you weren't being screwed by the simulation model?
>
> No, it worked fine in simulation, it was the real design PARed on the real
> live PCB that had problems!
>
> ---Joel

BTW What level of simulation did you use ? i.e. did it pass HDL, post synth,
post PAR?


Article: 27608
Subject: S: Exaclibur Kit
From: "C.Schlehaus" <carlhermann.schlehaus@t-online.de>
Date: Wed, 29 Nov 2000 22:44:20 +0100
Links: << >>  << T >>  << A >>
Hi,
I'm currently thinking about building a new board with a seperate
processor and FPGA or to use the Excalibur Kit with NIOS processor.
As both would fit my needs, I just struggle for the $990 of the
Excalibur Kit, as it is for my own (not my boss) boards...
Perhaps anyone would get rid of his Excalibur Kit (including
the Updates if possible) ?

CU, Carlhermann



Article: 27609
Subject: Re: Xess - XS40-005XL question
From: Neil Franklin <neil@franklin.ch.remove>
Date: 29 Nov 2000 22:59:05 +0100
Links: << >>  << T >>  << A >>
longwayhome@my-deja.com writes:

> In article <6uk89nh9k6.fsf@chonsp.franklin.ch>,
>   Neil Franklin <neil@franklin.ch.remove> wrote:
> > Jonas Thor <thor@NOSPAMsm.luth.se> writes:
> >
> > > On Mon, 27 Nov 2000 22:22:32 GMT, longwayhome@my-deja.com wrote:
> > >
> > > >Is a XS40-005XL ( http://www.xess.com/prod004.html ) board
> suitable for
> > > >hardware evolution, has anyone actually used it for that purpose ?
> >
> > What do you exactly mean with "hardware evolution". Improving hardware
> > for some project? Or are you trying to used genetic algorithms to
> > generate FPGA configurations? Or using FPGAs as co-processors to
> > compute GAs for something else? Or?
> >
> > Perhaps if you tried to describe what you are trying to do, people
> > here could help you in selecting.
>
> What i'm wanting to do is (i suppose) the 'genetic algoriths to
> generate FPGA configurations'

OK.

> would be great, I agree (but I posted a few weeks back asking pretty
> much for that kind of info and didn't really get many replies of "I use
> board X" variety (in fact none iirc))

Most likely because no one else is doing genetic algorithms.


But this time your timing was more lucky. I just today installed the
JBits software from Xilinx and on its intro page about what tools are
in the package I saw this bit:

------------
GeneticFPGA, is a Java-based tool for evolving circuits on
Xilinx Virtex FPGAs or on the JBits Device Simulator.  Using an
evolutionary algorithm, the system mutates a bitstream to create a
circuit.  The user specifies a fitness function that measures how
well the circuit performs, along with some stimulus and expected
output.  The system mutates the bitstream to reduce the error between
the actual output and the expected output. The design process is a
bit non-traditional.  Whereas a designer typically creates a circuit
by assembling known structures, here a designer specifies desired
behavior and lets the system construct the solution.
-----------

So that may be what you are looking for.

To get the JBits software (no download from their web page) send a
mail to: jbits@xilinx.com, they then send you back an URL and
password. It is free of cost, no NDA or anything. Is written in Java,
I have installed it on Linux (which they do no support for, but say it
works and other customers use it).

JBits has an software simulator DeviceSimulator to experiment on. To
then run JBits generated bitfiles on actual hardware you will need
an Virtex based board, either the XSV from Xess (www.xess.com), or
something like the V240 from APS (www.associatedpro.com), the WV-300
from VCC (www.vcc.com) is also Virtex based.

The XS40 (any version of it) will NOT do, as that is XC4000 based.

Note that the null*.bits files included in JBits only support XCV300,
XCV800 and XCV1000 chips, for others you will need to get an null*.bits
file by some other means. Both Xess and APS offer XCV300 and XCV800
variants, and I am not cash limited, so not being able to use the
cheaper XCV50/100/150/200 chips is no problem for me.


--
Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/
Nerd, Geek, Hacker, Unix Guru, Sysadmin, Roleplayer, LARPer, Mystic

Article: 27610
Subject: Re: Xilinx Coolrunner going on last time buy?
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Thu, 30 Nov 2000 12:12:35 +1300
Links: << >>  << T >>  << A >>
Richard Dungan wrote:
> 
> betsy thibault <betsyt@xilinx.com> wrote:
> 
> >Nick,
> >
> >It is true that Xilinx has had to shorten the lifecycle of the 'legacy' Philips
> >parts due to lack of fab capacity.  As you probably know, Xilinx has strategic
> >partnerships with a couple of fabs, but unfortunately not with the fabs where
> >these devices are manufactured.  Hence the end of life notice.  It has always
> >been in the plans to move the newest CoolRunner XPLA3 family to a strategic fab
> >partner, and that is in the works now.  The XPLA3 family is the next generation
> >CoolRunner, sporting even lower power consumption than the legacy products, and
> >a full PLA structure that allows for more logic flexibility and excellent
> >pin-locking capability. The XPLA3 family is also pin compatible with the parts
> >going end of life.
> >
> >If anyone would like more information on the legacy devices, your local Xilinx
> >sales representative or hotline support personnel would be happy to help you
> >convert to an even lower power CoolRunner XPLA3 device.
> >
> >Regards
> >
> >Betsy Thibault
> >Xilinx Product Manager
> 
> Thanks for that, Betsy. Could you explain how I drop an XPLA3 into a
> slot previously occupied by a PZ5032CS? The system is all 5 volt...

 The best port device, from 5V coolrunner, is Atmels ATF150x family,
(or the ATF22V10CQZ / ATF750CL for the P?Z22V10 phase out).
 We have ported designs already for customers.

 The ATF15xx actually have lower static Idd than XPLA2 ( but higher
mA/MHz ), 
and porting is relatively easy, with a choice of levels : PLA, PH0, PHD.
 Altera have much higher Idd, and a more difficult SW porting path.

 We are investigating writing SW that automates conversion of 
the XPLA pla files, to FIT15xx PLA files.

 - jg


-- 
======= 80x51 Tools & PLD IP Specialists  =========
= http://www.DesignTools.co.nz

Article: 27611
Subject: Re: Reverse-engineering FPGA's
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Wed, 29 Nov 2000 23:41:49 +0000
Links: << >>  << T >>  << A >>


Isabelle wrote:

> Hello, I am a newbie in FPGAs and am interested especially in
> test-vector synthesis.
>
> My - naive - questions are :
>
> 1.Is it possible from the program file of some FPGA to deduce a gate or
> functional block model for the internals of that FPGA ?
> 2.Do the FPGA manufacturers pusblish the mapping from program files to
> FPGA internals ?
>
> Thanks a lot for reading this
>
> Fabien TODESCATO

This is a question that comes up regularly on this NG. To review the state
of play I'd take a look at dejanews for the last few threads on this topic.
I think the last one or the last but one was pretty exhaustive.

Basically the conclusion is that there's no way to protect an SRAM based
FPGA from being cloned or even reverse engineered until the manufacturers -
basically Xilinx/Altera - decide to add some sort of non-volatile
``signature'' to their devices. Xilinx's response to this is that the
technology required for this increases the number of mask steps needed and
the process used is slower => increased cost + slower devices.


Article: 27612
Subject: Re: Selfmade Cores or something similar (Xilinx)
From: Ray Andraka <ray@andraka.com>
Date: Thu, 30 Nov 2000 00:45:55 GMT
Links: << >>  << T >>  << A >>
Marc,

I still get the impression that Xilinx would like you to believe that
floorplanning and other optimization is unnecessary.  Frankly, I find it as
necessary as ever.  You can create RPMs in VHDL as well as the way we do in
schematics as long as your synthesizer will pass user attributes.  To do that,
you need to instantiate the flip-flops and carry chain elements (you can let the
LUTs go if you want, they'll usually end up correctly anyway) and put RLOC=
attributes on them, attached to the instance label.

Marc Reinert wrote:
> 
> What can I do if I want to integrate some functional units (tested and
> optimized on different small FPGA's) into one large FPGA.
> 
> We are using Xilinx Virtex-E FPGAs and the Foundation Express software
> with VHDL.
> 
> I think we need a kind of self-programmed cores with optimized placement
> and routing that can be coalesced in the top-level VHDL-design. I think
> it'll get to complex to hand optimize the whole project afterwards.
> 
> I can't find any information about that in the Xilinx literature.
> 
> Thanks for some hints.
> 
> --
>  _________________________________________________________________
> |                                                                 |
> |  Dipl.-Ing. Marc Reinert                                        |
> |                                                                 |
> |  Technical University of Hamburg-Harburg                        |
> |  Department of Telecommunications                               |
> |  Eissendorfer Strasse 40                                        |
> |  D-21073 Hamburg / Germany                                      |
> |                                                                 |
> |  Telefon/ Phone: (+49) (0)40 4 28 78 - 20 63                    |
> |  Fax/          : (+49) (0)40 4 28 78 - 22 81                    |
> |  E-Mail:         mailto:reinert@tu-harburg.de                   |
> |  WWW:            http://www.et2.tu-harburg.de                   |
> |_________________________________________________________________|

-- 
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com  or http://www.fpga-guru.com

Article: 27613
Subject: Re: Reverse-engineering FPGA's
From: "Jan Gray" <jsgray@acm.org>
Date: Thu, 30 Nov 2000 01:21:42 GMT
Links: << >>  << T >>  << A >>
"Rick Filipkiewicz" <rick@algor.co.uk> wrote in message
news:3A25943D.EB7DCAFC@algor.co.uk...
> Basically the conclusion is that there's no way to protect an SRAM based
> FPGA from being cloned or even reverse engineered until the
manufacturers -
> basically Xilinx/Altera - decide to add some sort of non-volatile
> ``signature'' to their devices. Xilinx's response to this is that the
> technology required for this increases the number of mask steps needed and
> the process used is slower => increased cost + slower devices.

See Brian Dipert, EDN: "Cunning circuits confound crooks",
http://www.ednmag.com/ednmag/reg/2000/10122000/21df2.htm:

"... With otherwise-SRAM-based FPGAs, for example, adding nonvolatile memory
for unique device identifiers might be cost-prohibitive. Instead, Xilinx is
including a hard-wired Triple-DES decryption block, along with two sets of
56-bit key registers and dedicated battery-backup supply-voltage inputs for
only those registers, on its upcoming Virtex-II FPGAs. ..."

Jan Gray, Gray Research LLC




Article: 27614
Subject: how to constaint a design without inserting pad?
From: Oh Sheau Pyng <ASSPOh@ntu.edu.sg>
Date: Thu, 30 Nov 2000 10:13:22 +0800
Links: << >>  << T >>  << A >>
hi, I am trying to do a bottom up synthesize, but when I use foundation
( fpga Expres) to synthesize individual sub modele without inserting
pad, most of the timing constaint setting is gone. ( I can't set
constraint). fpga express basically just convert VHDL to netlist. and
the result is no good, I think with proper constaint setting the result
of the synthesize will be much better.

any one know how to constaint a design without inserting pad?
I do have access to Leonardo Spectrum, it is possible with Spectrum?

anyone know why timing constaint setting is not possible without
inserting pad?

thanks
Sheau Pyng
Project Officer
Center for High Performance Embedded System (ChiPES)
Nanyang Technological University

Blk N4, #B3b-06, Nanyang Avenue
Singapore 639798
Tel  : (65) 7906967
Fax : (65) 7920774



Article: 27615
Subject: Re: Virtex ROM ques.
From: A person <person@earth.planet>
Date: Wed, 29 Nov 2000 19:18:49 -0800
Links: << >>  << T >>  << A >>
Question 1a: I have not tried this entire flow yet, but this may work in 
theory (I also think there is a better way).  I have used FPGA editor to 
change the initial value of RAMs (ROMs are just RAMs without write 
capabilities).  If memory serves me right, fpga_editor makes a playback 
file (this is the part I have never tried).  You can write a script to 
change the playback file to change the content of the RAM and rerun 
fpga_editor.  Write ncd file and re-run bitgen.

Question 1b: Another possible solution is the following, but I have had 
some problems with guide files in bigger designs (works awesome in 
smaller designs).  The .edf file for the RAMs have the initial contents 
that are pretty human readable.  Write a script to change these values.  
Rerun par with guide files.  Since only the initial contents are 
changed, it should run quite fast.  

Question 2: If I understand correctly, you can write a .coe file and use 
coregen to make the ROM.

Just some ideas, I hope they help. 

Remove capital letters for email eApBaCrDk@EtFi.GcHoIm.

-Edwin Park

In article <3A2360E0.B62C21B7@earthlink.net>, 
lenihan3weNOSPAM@earthlink.net wrote:

>Question 1:
>
>How can I take a Xilinx Virtex FPGA design that contains instance-unique
>ROM (ROM values unique to each module/unit manufactured) and keep my
>core logic the same, but update the ROM for each SPROM/board
>manufactured, preferably without having to re-synthesize, re-place &
>route, re-verify, etc.,? Ideally, the designer would have a generic
>logic bitstream (with anything in the ROM) and be able to
>merge/append/over-write the ROM with the desired-ROM-contents file that
>is unique to each board. Note: whether the ROM is truly ROM or really
>RAM that can be further written over by the mission logic is irrelevent,
>the key is that at power-on the memory is ROM and has the desired unique
>values. I'm thinking specifically about building the ROM with BlockRAM,
>but the problem may be equally relevent to ROM built with the
>distributed, LUT-based RAM, too.
>
>Question 2:
>
>Suppose I want to build a 4kx8 ROM from instantiated BlockRAM (8
>instances of 4kx1 aspect ratio RAMs), as opposed to inferred ROM via a
>big case statement. The required INIT statements (in the HDL code) to
>provide the right values for simulation & synthesis require a
>non-trivial bit-slicing & parsing operation to assemble the INIT
>statements from the ideal representation of values (i.e., one text file
>of 4k lines, where each line is a 8-bit binary or hex value). Are there
>any programs (shareware or $$) to do this bit-slicing & parsing or does
>everyone have to write their own C programs to do it?
>
>==============================
>William Lenihan
>lenihan3weNOSPAM@earthlink.net
>.... remove "NOSPAM" when replying
>==============================
>
>

Article: 27616
Subject: Re: Synplify Benchmarks
From: A person <person@earth.planet>
Date: Wed, 29 Nov 2000 19:27:00 -0800
Links: << >>  << T >>  << A >>
I have not run on P4, but I have run large designs (from 30-98% of 
V2000Es) on a PIII Xeon 550MHz (1M cache, 1.5GRAM PC100ECC) and PIII 
Xeon 1.08GHz (256K cache, 2GRAM Rambus).  The punch line is that the 
550MHz box is about 10-15% faster on the same design.  The bigger cache 
is a better investment over faster clock/RAM.

I also noticed that 6.xx runs faster than 5.3x, but takes a lot more 
memory (ranging from 10% to 100% more memory).  

In article <6t9V5.27538$nh5.1625653@newsread1.prod.itd.earthlink.net>, 
"Joel Kolstad" <JoelKolstad@Earthlink.Net> wrote:

>"Richard Wilkinson" <richard.wilkinson@csr.com> wrote in message
>news:3A24D86F.3AA3208@csr.com...
>> I am trying to decide between machine specs for running Synplify on with
>> a design size of around 200-300k gates and have a question or two for
>> those having Synplify experience.
>
>Place and route is going to take you significantly longer than Synplify's
>synthesis.
>
>> What is a typical machine spec for running Synplify on? What do people
>> generally use for designs of around 200k gates? Sun machines? Or fast
>> PCs with reasonable amounts of memory and disk? What make of CPU is
>> prevalent?
>
>Our current PAR machine is a 700MHz Athlon with half a gig of memory.  
>Soon
>it'll be replaced by a gigaHerttz Athlon; I'm curious to see what the PAR
>speedup is, although I'm not expecting a lot.  For an XCV400 desigin 
>that's
>85% full, PAR takes about an hour.  Synplify takes, I don't know, 
>somewhere
>between 5 minutes and ten minutes -- it's quite fast.
>
>Whatever you do, get yourself a PC with high quality components; leave the
>CPU overclocking and cheap no-name SDRAM for some other computer that you
>don't do "real work" on.  Where I work in general they purchase Dell's, 
>and
>from what I can tell they're pretty solidly designed.
>
>> Has anyone run Synplify on a Pentium 4 based system yet? ;)
>
>No, but from looking at the Pentium IV's benchmarks I'd bet a nickel that 
>at
>the same clock speeds it's be slower than a Pentium III or an Athlon.
>(Granted, P-IV's are only available at 1.4GHz and 1.5GHz at the moment, 
>but
>check out the benchmarks -- often a 1.5GHz P-IV can't even keep up with a
>1GHz P-III/Athlon, depending on the benchmark you look at.)  Objectively, 
>a
>Pentium IV isn't the right choice for very darn many applications -- yet.
>I'd wait until Intel gets the faster P-IV's out (with the 487? pin 
>footprint
>instead of the 423? pin footprint that they're going to obsolete in the 
>next
>six months!).
>
>---Joel Kolstad
>
>
>

Article: 27617
Subject: Re: Fifo design problem
From: "Joel Kolstad" <JoelKolstad@Earthlink.Net>
Date: Thu, 30 Nov 2000 06:46:17 GMT
Links: << >>  << T >>  << A >>
"Rick Filipkiewicz" <rick@algor.co.uk> wrote in message
news:3A2575DD.B7DF129A@algor.co.uk...
> Joel Kolstad wrote:
>
> > "Andy Peters n o a o [.] e d u>" <"apeters <"@> wrote in message
> > news:901ckf$2h1q$1@noao.edu...
> > > Are you sure you weren't being screwed by the simulation model?
> >
> > No, it worked fine in simulation, it was the real design PARed on the
real
> > live PCB that had problems!
> >
> BTW What level of simulation did you use ? i.e. did it pass HDL, post
synth,
> post PAR?

I didn't do a post-synthesis simulation, but it did pass HDL and post-PAR.
Of course, with post-PAR you have to use whichever the magic switch is with
ngd2vhdl to tell it to not create 'X's for events that fail to meet the
correct setup and hold times (instead it just holds the previous value of
the 'flop), since with two asynchronous clocks obviously at some point the
(gray coded) counters that are feeding the full/empty flags clocked off the
opposite clock domain will fail to meet the flags' setup or hold
requirements.

At this point I'm reasonably convinced it's a "GSR going inactive while REn
or WEn were active" problem; I've yet to see any evidence that would tend to
rule this explanation out.

---Joel Kolstad




Article: 27618
Subject: Re: Fifo design problem
From: murray@pa.dec.com (Hal Murray)
Date: 30 Nov 2000 08:02:45 GMT
Links: << >>  << T >>  << A >>

> At this point I'm reasonably convinced it's a "GSR going inactive while REn
> or WEn were active" problem; I've yet to see any evidence that would tend to
> rule this explanation out.

GSR is well known to be slow.  I just scanned the data sheet but didn't
find the spec.

There have been a lot of discussions in this group on this topic.  My
memory is that consensus was to do it yourself so that you could get
it right.

I wouldn't be surprised if you had troubles if you were doing reads
or writes near the time when GSR was going away.

-- 
These are my opinions, not necessarily my employers.  I hate spam.

Article: 27619
Subject: Orca 3t sram gsr question
From: "jj" <jj@rad.com>
Date: Thu, 30 Nov 2000 08:31:57 -0000
Links: << >>  << T >>  << A >>
Hi
     I am instantiating DCE32x4 dual port srams in a 3T125, when you look at
the srams in EPIC there in a GSR Enable/ Disable option, neither have been
highlighted.
How do you select this option within the HDL, I have instantiated a GSR
component but these does not solve the problem.



J



Article: 27620
Subject: Re: 150MHz LVDS vs. 75MHz TTL
From: murray@pa.dec.com (Hal Murray)
Date: 30 Nov 2000 11:36:42 GMT
Links: << >>  << T >>  << A >>

LVDS needs 2.5 V Vcco.  That's another power plane (pair) if you
don't already need it for something else, and a power supply too.

LVPECL uses 3.3 V Vcco which you probably already have for LVTTL signals.

I'm not a wizard at analog stuff, but they look pretty similar to me.

Anybody know any good reason not to use LVPECL instead of LVDS if
you get to design both ends?

-- 
These are my opinions, not necessarily my employers.  I hate spam.

Article: 27621
Subject: Job opportunities
From: "korg" <korg_01@yahoo.de>
Date: 30 Nov 2000 11:51:37 GMT
Links: << >>  << T >>  << A >>
Hi. I would like to look for a joc possibility in the USA like FPGA
designer. Where can I search for?

tx

korg

contact:korg_01@yahoo.de

Article: 27622
Subject: high level timing by C generated VHDL?
From: nospam@notarealaddress.de (Robert S.)
Date: Thu, 30 Nov 2000 13:22:45 GMT
Links: << >>  << T >>  << A >>
Hi Group,
the high level timing is getting terribly 
complicated in one of my designs (for an XCS20), 
not to speak of the approaching maintenance horror: 
floor covered with manually drawn timing diagrams 
the sort of 'here that input gate is open, now here 
5 clocks before the ADC has to be started, then at 
this particular point in time the CORDIC is finished 
with that task and must take over the ADC data at 
the next clock, there, while..'. And everything 
irregularly intertwined on the next higher timing 
level, but fortunately repeating forever in all. 
(All that plus dependent on inputs, would have 
killed me..)

So, had the idea to try another approach:
- Write a timing dependency simulation in C++ 
  or Delphi, producing timing diagrams output.
- Modify it until everthing looks fine.
- Replace the graphics output by functions
  which produce the VHDL to create my timing 
  generator.

Any advice, suggestions, other ideas (preferable ones 
which dont lead into a budgetary desaster instead)?

 Robert 
robertDschoerghuberAhomeDinsDde

P.S. Thorough experience in HW/SW/FPGA can be 
assumed, but just about to learn VHDL.

Article: 27623
Subject: Re: 150MHz LVDS vs. 75MHz TTL
From: Magnus Homann <d0asta@mis.dtek.chalmers.se>
Date: 30 Nov 2000 14:25:34 +0100
Links: << >>  << T >>  << A >>
murray@pa.dec.com (Hal Murray) writes:

> LVDS needs 2.5 V Vcco.  That's another power plane (pair) if you
> don't already need it for something else, and a power supply too.
> 
> LVPECL uses 3.3 V Vcco which you probably already have for LVTTL signals.
> 
> I'm not a wizard at analog stuff, but they look pretty similar to me.
> 
> Anybody know any good reason not to use LVPECL instead of LVDS if
> you get to design both ends?

Power consumption and possibly emitted interference.

Homann
-- 
Magnus Homann, M.Sc. CS & E
d0asta@dtek.chalmers.se

Article: 27624
Subject: FC II & Xilinx libraries macros
From: "Tim Gordon" <t.gordon@cs.ucl.ac.uk>
Date: Thu, 30 Nov 2000 13:57:00 -0000
Links: << >>  << T >>  << A >>
I'm using Synopsys FCII for Virtex synthesis. When I instantiate macros
listed in the Xilinx Unified Libraries, synthesis fails with a link error.
I've found XNFs for 3000 and 5200 macros amongst the files installed, but
not for Virtex. Can anyone tell me how to resolve this problem?





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