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 31250

Article: 31250
Subject: Re: SRAM fpga cell
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Wed, 16 May 2001 09:12:57 -0700
Links: << >>  << T >>  << A >>
PREP was an unmitigated disaster. It started with the naive idea that the
capacity and speed of any and all programmable devices, from simple CPLDs to big
XC3090s, could be measured by implementing a design consisting of concatenated
MSI blocks. Then we underestimated the power of marketing, and Altera's
"creativity" ( I have a long list of dirtier words for it), who claimed virtual
designs with more than 100% utilization of the existing circuitry. Made me lose
all respect for them.

Different from microprocessors, programmable logic comes in widely different
sizes and flavors, and is being used for widely differing purposes. I stick with
my original story that a single-number measurement for capacity ( or speed ) is
as meaningless as 38-24-36.
That's why the industry still needs smart engineers who can evaluate and select
the right device for the right job. And app notes and newsgroups to explain the
important subtleties.

Peter Alfke
======================================
Allan Herriman wrote:

>
>
> About a decade ago there was a benchmark called "Prep" but it isn't used
> anymore.  I'm not quite sure why, but I think it had something to do
> with Prep not being a realistic measure of the performance of a part.
> IIRC, one of the measures was the number of 16 bit counters that would
> fit.  Obviously, this mapped quite well to one particular vendor's part
> that has groupings of 16 flip flops.
>
> I propose a new benchmark: the number of traffic light or vending
> machine controllers that will fit in the FPGA.  :)
>
> Regards,
> Allan.


Article: 31251
Subject: Re: Comparator
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Wed, 16 May 2001 18:24:43 +0200
Links: << >>  << T >>  << A >>
vi schrieb:
> 
> Can anyone supply me or direct me to a source that has a 24-bit
> comparator(GT or LT output) in schematic format for FPGA?  I use Xilinx.

So use the core generator to get your comparator.

-- 
MFG
Falk



Article: 31252
Subject: Re: PROGRAMMABLE LOGIC SEQUENCER CORRECTIONS
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Wed, 16 May 2001 09:25:41 -0700
Links: << >>  << T >>  << A >>


Harvey Twyman wrote:

> <snip>
>
> The one thing I've learnt from this exercise is that
> if you post to newsgroups you must expect to be
> crucified if you 'do' or 'say' anything slightly
> wrong.
>
> I feel that it's unlikely that good comments are ever
> made through this type of media.

I disagree.
I find this a very helpful, cooperative, and even friendly newsgroup.
It treats sophisticated questions with respect, and newbies even with love.
We may, however, sometimes react negatively to pomposity, and
"know-it-almost-all" statements.
And some of us, present company included, have strong opinions on certain
subjects.

But we do make "good comments".

Peter Alfke


Article: 31253
Subject: Re: XilinxCoreLib with Renoir
From: vaughn@ece.drexel.edu (Vaughn Adams)
Date: 16 May 2001 12:27:43 -0400
Links: << >>  << T >>  << A >>
I did it by generating the VHDL file from coregen.  I compiled it on the
command line.  In renoir, I created a standard library and pointed the 
directory to the one that I compiled.  I also had to do the same with the xul
library. 

The new HDL Designer has some hooks in it to make importing from Coregen
easier.  I haven't tried it yet.  I usually end up using the Moduleware stuff
that comes with it.

Jean-Pierre Gehrig (redbull@netplus.ch) wrote:
: I'm trying to use a dual port RAM generated by the Xilinx Core Generator for
: a Spartan-II.

: Does anybody knows how to create a component from the VHO file with Renoir
: (I use Leonardo for synthesis)?

: Thanks,

: Jean-Pierre Gehrig
: Design Engineer
: HEVs Switzerland



--
Vaughn

Article: 31254
Subject: Re: PCI The Real Hardware
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Wed, 16 May 2001 18:33:03 +0200
Links: << >>  << T >>  << A >>
Iwo Mergler schrieb:
> 

> IIRC, the tracks on your card should be routed above a continuos
> power plane and must be shorter than 1 inch. The PCI clock signal
> must be 1.5 inches long. All signals drive exactly one CMOS input.
> I might be completely wrong.

I think so. I dont have the PCI spec (and never read them :-( but Iam
sure that this wont work. It is called PCI-BUS, so one signal cant drive
only 1 input. Also, the distance between the PCI slots in my PC is
greater than 1 inch.

-- 
MFG
Falk



Article: 31255
Subject: Re: Ideas for Faster XILINX compilations ?
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Wed, 16 May 2001 18:42:46 +0200
Links: << >>  << T >>  << A >>
Andrew Webb schrieb:
> 
> Dear All,
> 
>  I have been asked by the FPGA developers at my company to recommend a
> suitable platform and configuration to minimise the time they have to spend
> waiting for XILINX compilations. They currently have to wait around 8 hours.
> We tried a P4 with RAMBUS memory, but the performance increase over a P3
> wasn't that great. Any ideas ... my boss gave me this brief.

UHHHH, sounds like REALLY BIG designs (and FPGAs). What type is it?
Virtex-E 3200??
Anyway, I think a possible solution is to split the design into small
parts, test and compile them, and then put the modules together WITHOUT
running a Place&Route for the Design at all. DAMIT, I dont know at the
moment how is this called in english.

Peter, HILFE ;-)

-- 
MFG
Falk


Article: 31256
Subject: Re: PCI The Real Hardware
From: steve (Steve Rencontre)
Date: Wed, 16 May 2001 18:45 +0100 (BST)
Links: << >>  << T >>  << A >>
In article <3B019429.3FEE8592@cyberspook.freeserve.co.uk>, 
pjc@cyberspook.freeserve.co.uk (cyber_spook) wrote:

> And lastly - is there somwhere I can find this information?

The PCI spec will tell you what the rules are. If you break them, you will 
get away with it sometimes. The precise proportion of the time 
you will get away with it varies depending on which rules you break, how 
badly you break them, how cleverly you do it, the rest of the system and 
the phase of the moon. Your mother's maiden name may also be a factor.

With experience, you can make a reasonable guess whether some bodge is 
likely to work in a particular instance, but it's not readily 
quantifiable.

--
Steve Rencontre		http://www.rsn-tech.co.uk
//#include <disclaimer.h>


Article: 31257
Subject: Re: Counter problem in Altera AHDL...
From: steve (Steve Rencontre)
Date: Wed, 16 May 2001 18:45 +0100 (BST)
Links: << >>  << T >>  << A >>
In article <ddn3gt074c21a28nbsg67aoisgj2heoq9d@4ax.com>, 
mhkohne@discordia.org (Michael Kohne) wrote:

> I've got a stupid problem with a counter. The code is written in
> Altera's AHDL language,

> [...description of glitches...]

> IF (XMTN_R63) THEN	-- XMTN_R63 is a registered copy of an input
>    FADCNT[18..0].d = 0;
> ELSE
>    FADCNT[18..0].d = FADCNT[18..0].q + 1;
> END IF;

First thought - scrap that code and use LPM instead. Second thought - 
redesign to be fully synchronous and therefore tolerant of glitches. 

If you /really/ can't tolerate any glitches on your counter output, you 
have no alternative but to use a Gray code.

--
Steve Rencontre		http://www.rsn-tech.co.uk
//#include <disclaimer.h>


Article: 31258
Subject: Re: Bizarre PAR phenomenon
From: Newsbrowser@Newsbrowser.com (Newsbrowser)
Date: Wed, 16 May 2001 17:46:25 GMT
Links: << >>  << T >>  << A >>
On Wed, 16 May 2001 13:54:04 +0100, Rick Filipkiewicz
<rick@algor.co.uk> wrote:

>
>
>Utku Ozcan wrote:
>> 
>> Rick Filipkiewicz wrote:
>> 
>> > For some time now I've noticed that every now & again PAR would hang up
>> > in the ``route PWR/GND'' phase of iteration 2. Or, at least, progress
>> > would slow to a crawl. Since I've only got 722 such connections none of
>> > the answers on the web seemed at all relevant.
>> 
>> Rick,
>> 
>> If I remember correctly, there was a discussion on PWR/GND distribution
>> at this newsgroup long ago (I don't know if you can find these postings
>> in http://groups.google.com (formerly http://www.deja.com) since they lost
>> old mails or whatever).
>> 
>> Can it be the problem how PWR/GND is modelled in HDL? Maybe 722 PWR/GND
>> connections is used from only one Verilog assignment. Or, are these
>> potentially unroutable connections centralized within some small region
>> (module) of the chip? Maybe warning/errors of unrouted PWR/GND might
>> inform on it.
>> 
>> Utku
>
>But, Utku, why only on a Sunday ?

Are you using a networked version of the software. On Sundays, the IP
folks may be using the network for backing up drives and such. 


Ralph Watson 
Return Email Address is: 
ralphwat dot home at excite dot com 
just type the address in like it should look like

Article: 31259
Subject: Re: Ideas for Faster XILINX compilations ?
From: Brant Soudan <brant.soudan@xilinx.com>
Date: Wed, 16 May 2001 11:04:58 -0700
Links: << >>  << T >>  << A >>
andrew,

the first thing to check is your memory usage.  i see you only mentioned
available memory on the HP Vectra.  and that was only 0.5 GB.  increasing this
could be an easy way to reduce compile times on all machines.

in my experience, the 2 things that affect compile times the most are memory and
CPU speed.

brant


Andrew Webb wrote:

> Dear All,
>
>  I have been asked by the FPGA developers at my company to recommend a
> suitable platform and configuration to minimise the time they have to spend
> waiting for XILINX compilations. They currently have to wait around 8 hours.
> We tried a P4 with RAMBUS memory, but the performance increase over a P3
> wasn't that great. Any ideas ... my boss gave me this brief.
>
> Thanks,
>
> Andrew Webb
> Thales Defence
>
> ......
> Our Software
> Xilinx Foundation 3.1I with SP7
>
> Devices
> Devices are xcv1000, xcv1600e-6
>
> The Problem
> Our iteration cycles can take up to 8 hours (includes our final timing
> constraints). We currently use Intel PIII 800MHz to 1GHz PCs.
>
> Our Initial Solution
> Part 1
> We purchased a HP Vectra 800VL which is an Intel 1.5GHz P4, 0.5GB RAM
> (400MHz Front Side Bus), SCSI 160 Controller. The initial installation was a
> problem but we found the fix on your Web Site (java error) and then found
> that our expectation of much reduced compilation times was not met. Design 1
> (See Mapping Report File) took 3 hours 18min on a PIII and 2 hours 40min on
> a P4. We were hoping for much more as we were assuming the 400MHz FSB would
> improve CPU to Memory operations during compilation.
> We now understand that you are releasing a new version of Xilinx that will
> be optimised for P4 architectures in August.
>
> Part 2
> We have since been steered towards the AMD processors, which we are testing
> today.
>
> Our Aim
> We need to reduce this iteration time to allow us to make more changes to
> our designs within one day. Currently we are relaxing the timing constraints
> during the initial stages, but having to then place our final constraints
> within the design to meet the overall system requirements. This is where the
> compile time increases to 8 hours.
>
> Our Questions
> Can you advise on the compilation platforms to yield the best performance,
> short and long term.
> Have you any hint or tips on Operating System optimisation or choice of O.S.
> I want to take a more strategic view of this issue and formulate plan for
> when we begin using even bigger gate Arrays.


Article: 31260
Subject: Re: PCI The Real Hardware
From: "Tom Verbeure" <tverbeure@globespan.net>
Date: Wed, 16 May 2001 14:11:59 -0400
Links: << >>  << T >>  << A >>
> It should reay have a short bus with minimal stubs to each card / device
> as you see in a standard pc, with good grouding and tracks layed
> correctly. corret?

Absolutely.

As has already been mentioned: having a look at the PCI spec might give you
some clues.:-)
 Still since I am not a PCB designer, it is quite hard to understand how all
the requirements mentioned in there interact.

Anyway, here are some restrictions from the spec, for the 66 Mhz case:
- maximum clock skew between any 2 components (irrespective whether this is
on the motherboard or on an expansion board) is 1 ns (2 ns for 33 MHz).
This will require very balanced routing of the clock signal (or the use of a
PLL to align the edges?)

- Tprop, the maximum roundtrip delay on the bus between any 2 components,
should be < 5 ns (10 ns for 33 MHz). This is probably even a bigger
constraint than the one above.

- total load should be limited, thus putting limits on the number of
compents on a signal bus.

> How long can the bus be at 66Mhz?

Not specified. Timing and load are important. The corresponding length will
probably vary with the quality of the material used to make the PCB, the
width of the wires, capacitance etc.

> How much veriation in track length can I have? (1 inch, 5 inch, 10inch
> difference?)  How long can a stub be? (1 inch, 5 inch?)

Same thing. The only limitations for tracks are those for the lengths from
the PCI connector the IO of a component on the PCI extension board. 1.5 inch
for all signals except for the clock, where it should be 2.5 inch.

> What problems am I ligthy to see? bit errors, parity etc?

Yes. And dead systems also. :-)

> also... If I have one device that is 32bit and three that are 64bit -
> should the 32bit device sit in the middle or can it sit off one end (ie
> extending the lower part of the bus beond the top 32bits)?

My feeling is that this should be OK. As long as you meet the timing specs.

> And lastly - is there somwhere I can find this information?

It's all in the PCI spec that you can buy at www.pcisig.org. Chapters 5 and
7.

Tom




Article: 31261
Subject: Re: PCI The Real Hardware
From: krw@btv.ibm.com (Keith R. Williams)
Date: Wed, 16 May 2001 18:21:59 GMT
Links: << >>  << T >>  << A >>
On Wed, 16 May 2001 18:33:03 +0200, Falk Brunner <Falk.Brunner@gmx.de>
wrote:

>Iwo Mergler schrieb:
>> 
>
>> IIRC, the tracks on your card should be routed above a continuos
>> power plane and must be shorter than 1 inch. The PCI clock signal
>> must be 1.5 inches long. All signals drive exactly one CMOS input.
>> I might be completely wrong.
>
>I think so. I dont have the PCI spec (and never read them :-( but Iam
>sure that this wont work. It is called PCI-BUS, so one signal cant drive
>only 1 input. Also, the distance between the PCI slots in my PC is
>greater than 1 inch.

I think he meant the on-card stub.  Anyway, I happen to be debugging a
PCI board right now (hangs the system on boot - hate that!) and have
open my copy of _PCI_System_Architecture_ (MindShare).  According to
Shanley and Anderson:

Maximum Card Trace Lengths:


- All signals on the 32bit portion of the bus must be no longer than
1.5".

- All 64-bit extension signals must be no more than 2".

- PCI CLK signal trace length must be 2.5" +/- .1" (hmm) and connected
to only one load.


----
  Keith

Article: 31262
Subject: Re: Xilinx and Actel
From: Chris Eilbeck <chris@yordas.demon.co.uk>
Date: 16 May 2001 20:00:28 +0100
Links: << >>  << T >>  << A >>
Tom <tomcip@concentric.net> writes:

> Ask some questions of your customer. What is so important about
> using the Actel Anti-fuse technology? What is so iimportant about
> using ANY technology.

Paranoia.

> The objective of design engineering is to design that which the
> customer requires within their cost and functionality
> constraints. What difference does it make which technology is used
> if the technology works and is affordable? Does the customer have a
> predjudice?

Most certainly yes.

> Did the customer read some kind of markting blurb from Actel? Do
> they own stock in Actel? Never believe the marketing hype.

I think it's a design security thing.  $DIETY knows why because there
won't be many units and they'll all be in access controlled areas.

I've been playing with the free Actel Desktop software the last couple
of days and in some respects it's a big step backwards from the Xilinx
stuff, especially when it comes down to revision control.  I hope the
higher end software is somewhat better than this.

Chris
-- 
Chris Eilbeck                             mailto:chris@yordas.demon.co.uk
MARS Flight Crew                                  http://www.mars.org.uk/
UKRA #1108 Level 1                                                   BSMR

Article: 31263
Subject: Re: Xilinx and Actel
From: Chris Eilbeck <chris@yordas.demon.co.uk>
Date: 16 May 2001 20:02:50 +0100
Links: << >>  << T >>  << A >>
rk <stellare@nospamplease.erols.com> writes:

**snip**

Thanks all.

Chris
-- 
Chris Eilbeck                             mailto:chris@yordas.demon.co.uk
MARS Flight Crew                                  http://www.mars.org.uk/
UKRA #1108 Level 1                                                   BSMR

Article: 31264
Subject: Re: Finally, an FPGA tool chain for Linux (Altera Quartus II)
From: Neil Franklin <neil@franklin.ch.remove>
Date: 16 May 2001 21:05:51 +0200
Links: << >>  << T >>  << A >>
gah@ugcs.caltech.edu (glen herrmannsfeldt) writes:

> Neil Franklin <neil@franklin.ch.remove> writes:
>
> >Eric Smith <eric-no-spam-for-me@brouhaha.com> writes:
>
> >> Bzzzt!  No longer commercially available.
>
> >Not any more? Bummer.
>
> >All the more reason for me to get on with my clone then. :-)
>
> There is now a software emulator that runs under most unix
> systems.  The remaining bugs are rapidly being worked out.

Actually multiple of them: TS-10, E-10 and simh2.6

But emulators are not quite the same thing as real hardware. :-)


> I forget if they have TOPS-20 running yet.  Maybe only TOPS-10.

AFAIK theye are all on TOPS-10 7.03, even 7.04 is crashing all of them.


> See the pdp10 newsgroup.

alt.sys.pdp10, which I read.


--
Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/
Hacker, Unix Guru, El Eng HTL/BSc, Sysadmin, Archer, Roleplayer
- Intellectual Property is Intellectual Robbery

Article: 31265
Subject: Re: SRAM fpga cell
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Wed, 16 May 2001 20:36:12 +0100
Links: << >>  << T >>  << A >>


Peter Alfke wrote:
> 
> PREP was an unmitigated disaster. It started with the naive idea that the
> capacity and speed of any and all programmable devices, from simple CPLDs to big
> XC3090s, could be measured by implementing a design consisting of concatenated
> MSI blocks. Then we underestimated the power of marketing, and Altera's
> "creativity" ( I have a long list of dirtier words for it), who claimed virtual
> designs with more than 100% utilization of the existing circuitry. Made me lose
> all respect for them.
> 
> Different from microprocessors, programmable logic comes in widely different
> sizes and flavors, and is being used for widely differing purposes. I stick with
> my original story that a single-number measurement for capacity ( or speed ) is
> as meaningless as 38-24-36.
> That's why the industry still needs smart engineers who can evaluate and select
> the right device for the right job. And app notes and newsgroups to explain the
> important subtleties.
> 
> 

And someone like you to act as our collective memory & keep us honest.

Article: 31266
Subject: Re: Bizarre PAR phenomenon
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Wed, 16 May 2001 20:46:02 +0100
Links: << >>  << T >>  << A >>


Newsbrowser wrote:
> 
> On Wed, 16 May 2001 13:54:04 +0100, Rick Filipkiewicz
> <rick@algor.co.uk> wrote:
> 
> >
> >
> >Utku Ozcan wrote:
> >>
> >> Rick Filipkiewicz wrote:
> >>
> >> > For some time now I've noticed that every now & again PAR would hang up
> >> > in the ``route PWR/GND'' phase of iteration 2. Or, at least, progress
> >> > would slow to a crawl. Since I've only got 722 such connections none of
> >> > the answers on the web seemed at all relevant.
> >>
> >> Rick,
> >>
> >> If I remember correctly, there was a discussion on PWR/GND distribution
> >> at this newsgroup long ago (I don't know if you can find these postings
> >> in http://groups.google.com (formerly http://www.deja.com) since they lost
> >> old mails or whatever).
> >>
> >> Can it be the problem how PWR/GND is modelled in HDL? Maybe 722 PWR/GND
> >> connections is used from only one Verilog assignment. Or, are these
> >> potentially unroutable connections centralized within some small region
> >> (module) of the chip? Maybe warning/errors of unrouted PWR/GND might
> >> inform on it.
> >>
> >> Utku
> >
> >But, Utku, why only on a Sunday ?
> 
> Are you using a networked version of the software. On Sundays, the IP
> folks may be using the network for backing up drives and such.
> 
> Ralph Watson
> Return Email Address is:
> ralphwat dot home at excite dot com
> just type the address in like it should look like

It could be but its unlikely since the Athlon wonderbox I use for this
is my home machine & only really functions as a compute server under
control of makefiles on my ca. 1996 PI-150 running BSDI Unix. I don't do
any local backups but periodically rsync to the main office servers.

I've run task manager to look at what PAR's doing during these strange
events & I see it using 99% of the CPU time. This is not in itself
decisive since who knows how NT calculates this & there maybe something
in the BG that's using all the memory bandwidth.

However if it were to be some other process then I would expect, on
probabilistic grounds, to get hang-ups in different places & not the
PWR/GND phase every time.

Article: 31267
Subject: Re: PROGRAMMABLE LOGIC SEQUENCER CORRECTIONS
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Wed, 16 May 2001 21:01:55 +0100
Links: << >>  << T >>  << A >>


Peter Alfke wrote:
> 
> Harvey Twyman wrote:
> 
> > <snip>
> >
> > The one thing I've learnt from this exercise is that
> > if you post to newsgroups you must expect to be
> > crucified if you 'do' or 'say' anything slightly
> > wrong.
> >
> > I feel that it's unlikely that good comments are ever
> > made through this type of media.
> 
> I disagree.
> I find this a very helpful, cooperative, and even friendly newsgroup.
> It treats sophisticated questions with respect, and newbies even with love.
> We may, however, sometimes react negatively to pomposity, and
> "know-it-almost-all" statements.
> And some of us, present company included, have strong opinions on certain
> subjects.
> 
> But we do make "good comments".
> 
> Peter Alfke

Harvey,

If you want to see how even the grown ups can get a bit of GBH-with-love
have a look at all the Spartan2 threads of some time ago. Xilinx, Peter
A. included, got a pretty good hammering over that but are still with
us.

As to ``good comments'' - I've lost count of the number times I've been
saved hours of work by some comment on this NG. I think there *are* are
number of things that will be treated with a certain amount of disdain &
maybe outright abuse:

o Job adverts from recruitment agencies.

o Anything that smacks of marketing voodoo.

o Someone trying to get their homework assignments done.

and possibly:

o Those who don't understand Shannon.

Article: 31268
Subject: Re: Ideas for Faster XILINX compilations ?
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Wed, 16 May 2001 13:04:04 -0700
Links: << >>  << T >>  << A >>

--------------3E12C21E4EB12141A1EA123A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

 http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=10632

Austin

Andrew Webb wrote:

> Dear All,
>
>  I have been asked by the FPGA developers at my company to recommend a
> suitable platform and configuration to minimise the time they have to spend
> waiting for XILINX compilations. They currently have to wait around 8 hours.
> We tried a P4 with RAMBUS memory, but the performance increase over a P3
> wasn't that great. Any ideas ... my boss gave me this brief.
>
> Thanks,
>
> Andrew Webb
> Thales Defence
>
> ......
> Our Software
> Xilinx Foundation 3.1I with SP7
>
> Devices
> Devices are xcv1000, xcv1600e-6
>
> The Problem
> Our iteration cycles can take up to 8 hours (includes our final timing
> constraints). We currently use Intel PIII 800MHz to 1GHz PCs.
>
> Our Initial Solution
> Part 1
> We purchased a HP Vectra 800VL which is an Intel 1.5GHz P4, 0.5GB RAM
> (400MHz Front Side Bus), SCSI 160 Controller. The initial installation was a
> problem but we found the fix on your Web Site (java error) and then found
> that our expectation of much reduced compilation times was not met. Design 1
> (See Mapping Report File) took 3 hours 18min on a PIII and 2 hours 40min on
> a P4. We were hoping for much more as we were assuming the 400MHz FSB would
> improve CPU to Memory operations during compilation.
> We now understand that you are releasing a new version of Xilinx that will
> be optimised for P4 architectures in August.
>
> Part 2
> We have since been steered towards the AMD processors, which we are testing
> today.
>
> Our Aim
> We need to reduce this iteration time to allow us to make more changes to
> our designs within one day. Currently we are relaxing the timing constraints
> during the initial stages, but having to then place our final constraints
> within the design to meet the overall system requirements. This is where the
> compile time increases to 8 hours.
>
> Our Questions
> Can you advise on the compilation platforms to yield the best performance,
> short and long term.
> Have you any hint or tips on Operating System optimisation or choice of O.S.
> I want to take a more strategic view of this issue and formulate plan for
> when we begin using even bigger gate Arrays.

--------------3E12C21E4EB12141A1EA123A
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;<a href="http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=10632">http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&amp;iCountryID=1&amp;getPagePath=10632</a>
<p>Austin
<p>Andrew Webb wrote:
<blockquote TYPE=CITE>Dear All,
<p>&nbsp;I have been asked by the FPGA developers at my company to recommend
a
<br>suitable platform and configuration to minimise the time they have
to spend
<br>waiting for XILINX compilations. They currently have to wait around
8 hours.
<br>We tried a P4 with RAMBUS memory, but the performance increase over
a P3
<br>wasn't that great. Any ideas ... my boss gave me this brief.
<p>Thanks,
<p>Andrew Webb
<br>Thales Defence
<p>......
<br>Our Software
<br>Xilinx Foundation 3.1I with SP7
<p>Devices
<br>Devices are xcv1000, xcv1600e-6
<p>The Problem
<br>Our iteration cycles can take up to 8 hours (includes our final timing
<br>constraints). We currently use Intel PIII 800MHz to 1GHz PCs.
<p>Our Initial Solution
<br>Part 1
<br>We purchased a HP Vectra 800VL which is an Intel 1.5GHz P4, 0.5GB RAM
<br>(400MHz Front Side Bus), SCSI 160 Controller. The initial installation
was a
<br>problem but we found the fix on your Web Site (java error) and then
found
<br>that our expectation of much reduced compilation times was not met.
Design 1
<br>(See Mapping Report File) took 3 hours 18min on a PIII and 2 hours
40min on
<br>a P4. We were hoping for much more as we were assuming the 400MHz FSB
would
<br>improve CPU to Memory operations during compilation.
<br>We now understand that you are releasing a new version of Xilinx that
will
<br>be optimised for P4 architectures in August.
<p>Part 2
<br>We have since been steered towards the AMD processors, which we are
testing
<br>today.
<p>Our Aim
<br>We need to reduce this iteration time to allow us to make more changes
to
<br>our designs within one day. Currently we are relaxing the timing constraints
<br>during the initial stages, but having to then place our final constraints
<br>within the design to meet the overall system requirements. This is
where the
<br>compile time increases to 8 hours.
<p>Our Questions
<br>Can you advise on the compilation platforms to yield the best performance,
<br>short and long term.
<br>Have you any hint or tips on Operating System optimisation or choice
of O.S.
<br>I want to take a more strategic view of this issue and formulate plan
for
<br>when we begin using even bigger gate Arrays.</blockquote>
</html>

--------------3E12C21E4EB12141A1EA123A--


Article: 31269
Subject: Re: Ideas for Faster XILINX compilations ?
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Wed, 16 May 2001 21:12:20 +0100
Links: << >>  << T >>  << A >>


Andrew Webb wrote:
> 
> Dear All,
> 
>  I have been asked by the FPGA developers at my company to recommend a
> suitable platform and configuration to minimise the time they have to spend
> waiting for XILINX compilations. They currently have to wait around 8 hours.
> We tried a P4 with RAMBUS memory, but the performance increase over a P3
> wasn't that great. Any ideas ... my boss gave me this brief.
> 
> Thanks,
> 
> Andrew Webb
> Thales Defence
> 
> ......
> Our Software
> Xilinx Foundation 3.1I with SP7
> 
> Devices
> Devices are xcv1000, xcv1600e-6
> 
> 

<snip>

> Part 2
> We have since been steered towards the AMD processors, which we are testing
> today.
> 

I can give you one data point here. Changing from a PIII-600-PC100 to an
Athlon-1G3-DDR266 has speeded up PAR by 52% and post-synth/post-PAR
simulations by ~45% [ModelSim-PE].

The designs aren't as big as yours but that's more a question of memory
size. If you are using WinNT/Win2K then the main rule is: Never, ever,
ever, let it start swapping. If you do the performance plummets to i286
levels - if you're lucky.



> Our Aim

Article: 31270
Subject: Re: PCI The Real Hardware
From: "Austin Franklin" <austin@dar87kroom.com>
Date: Wed, 16 May 2001 16:34:32 -0400
Links: << >>  << T >>  << A >>

"cyber_spook" <pjc@cyberspook.freeserve.co.uk> wrote in message
news:3B019429.3FEE8592@cyberspook.freeserve.co.uk...
> I have a question regarding the bit of PCI outside the chip - the bus!?
>
> I know that running at 33/66 Mhz is entering the RF range of problems -
> but how far can I push it, and it still work?
>
> It should reay have a short bus with minimal stubs to each card / device
> as you see in a standard pc, with good grouding and tracks layed
> correctly. corret?
>
> But.....
>
> and here are my questions:-
>
> How long can the bus be at 66Mhz?
> How much veriation in track length can I have? (1 inch, 5 inch, 10inch
> difference?)
> How long can a stub be? (1 inch, 5 inch?)
> How close can I lay tracks to each other or other data lines without
> cross talk?
> What problems am I ligthy to see? bit errors, parity etc?
>
> also... If I have one device that is 32bit and three that are 64bit -
> should the 32bit device sit in the middle or can it sit off one end (ie
> extending the lower part of the bus beond the top 32bits)?
>
> And lastly - is there somwhere I can find this information?
>
> Many - Many thanks

There are three scenarios here, and from what you wrote, I can't tell which
one you are trying to figure out.  If you elaborate, I might be able to
help.  Also, as suggested, get the PCI spec, at a minimum.

1) PCI plug in card?
2) PCI motherboard?
3) Embedded PCI (no connectors)?

Which one are you trying to understand?




Article: 31271
Subject: Re: PCI The Real Hardware
From: cyber_spook <pjc@cyberspook.freeserve.co.uk>
Date: Wed, 16 May 2001 21:46:09 +0100
Links: << >>  << T >>  << A >>
Hi to all...

Thanks for the answers...!

You all quote the PCI spec - whats the latest vertion? 2.2?

PS: this is for an embeded system with plug in cards.

many thanks Cyber_Spook_Man!

> It's all in the PCI spec that you can buy at www.pcisig.org. Chapters 5 and
> 7.
>
> Tom


Article: 31272
Subject: Xilinx Service Pack 8 Now Available
From: Roy White <whiter@xilinx.com>
Date: Wed, 16 May 2001 14:58:34 -0600
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------1DC00080AA50FF8DECD1B4F1
Content-Type: multipart/alternative;
 boundary="------------08EA70B04C1377D45238FA57"


--------------08EA70B04C1377D45238FA57
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello Xilinx Software users,

Service Pack 8 is now available for all Platforms.  To keep you software
up to date with the latest features I encourage you to visit our service
pack download center
at support.xilinx.com.

Thank you for designing with Xilinx!

Roy White


--------------08EA70B04C1377D45238FA57
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hello Xilinx Software users,
<p>Service Pack 8 is now available for all Platforms.&nbsp; To keep you
software up to date with the latest features I encourage you to visit our
service pack download center
<br>at <a href="http://support.xilinx.com/support/techsup/sw_updates/">support.xilinx.com</a>.
<p>Thank you for designing with Xilinx!
<p>Roy White
<br>&nbsp;</html>

--------------08EA70B04C1377D45238FA57--

--------------1DC00080AA50FF8DECD1B4F1
Content-Type: text/x-vcard; charset=us-ascii;
 name="whiter.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Roy White
Content-Disposition: attachment;
 filename="whiter.vcf"

begin:vcard 
n:White;Roy
tel;fax:303-442-3561
tel;work:720-652-3412
x-mozilla-html:FALSE
org:Xilinx, Inc.;Global Services Division
adr:;;1951 S. Fordham St.;Longmont;CO;80503;US
version:2.1
email;internet:roy.white@xilinx.com
title:Product Applications Engineer
fn:Roy White
end:vcard

--------------1DC00080AA50FF8DECD1B4F1--


Article: 31273
Subject: Re: Xilinx Service Pack 8 Now Available
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Wed, 16 May 2001 14:25:46 -0700
Links: << >>  << T >>  << A >>
Now we all know, but I told Roy already to tone down  the commercials.
Let's keep this ng friendly and informative, without blatant propaganda.
Peter Alfke




Article: 31274
Subject: Re: PCI The Real Hardware
From: "Tom Verbeure" <tverbeure@globespan.net>
Date: Wed, 16 May 2001 18:00:07 -0400
Links: << >>  << T >>  << A >>

Latest version is indeed 2.2. But check on the PCI website to see if there
are updates expected. (Not that it will really matter for your system...)

Tom


> You all quote the PCI spec - whats the latest vertion? 2.2?
>
> PS: this is for an embeded system with plug in cards.






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