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

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

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

Custom Search

Messages from 27575

Article: 27575
Subject: Virtex bitstream generation
From: adam_hawes@dingoblue.net.au
Date: Wed, 29 Nov 2000 17:11:43 +1030
Links: << >>  << T >>  << A >>
Hi all.

I'm currently in the final stages of getting a design we have developed
at uni as a group to load into our FPGA.  We can load the Virtex
(XCV150) using JTAG, and now require a bitstream file in a format
suitable for slave serial programming.

Are there any special requirements in programming using slave serial, or
will the bitstream that comes out of Foundation 2.1 work with minimal
hassle?  Do I need to run bitgen with any special options.  I have been
doing some reading on this and most of the material I have found has
left me somewhat confused as to what exactly is going on.

Thanks in advance for your help.
Adam

-- 
Adam Hawes

Web:       http://overfiend.iwarp.com
Email:     adam_hawes@dingoblue.com.au
ICQ:       2492016

Voicemail: +61 (08) 8219-3238
Fax:       +61 (08) 8219-3238

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GAT dpu s+: a-- C++++ UL++ P+ L+++ E W- N+++ o+ K- w--- 
O- M V-- PS+ PE Y++ PGP++ t 5- X+++ R* tv b+ DI+ D---- 
G e* h! r--- y** 
------END GEEK CODE BLOCK------

Article: 27576
Subject: Re: Fifo design problem
From: "Joel Kolstad" <JoelKolstad@Earthlink.Net>
Date: Wed, 29 Nov 2000 07:19:35 GMT
Links: << >>  << T >>  << A >>
"Jean Nicolle" <jeann17@home.com> wrote in message
news:H10V5.482363$i5.8584346@news1.frmt1.sfba.home.com...
> why not use an already debugged FIFO core?
> Altera has a FIFO wizard/megafunctions, while Xilinx had CoreGen (I
> believe).

It was/is a Xilinx-provided FIFO.  From one of the other poster's comments,
however, it appears that discrete component FIFOs occasionally suffer from
this same problem, and I also recall reading on John Cooley's ESNUG list
that some of the Synospys FIFO cores targeted at ASICs have problems as
well.  Hence I'm convinced it is slightly non-trivial to design a robust,
bullet-proof asynchronous FIFO.

One other note to Andy -- as far as simulation vs. reality goes, we actually
did go so far as to route the internal "full" signal out to a pin with FPGA
editor and, indeed, it would sit there and go active, well before it should
have.  While we were debugging this (a better part of a month ago, now), our
only other arguably reasonable thought was that we weren't covering some
timing path; we could take the _exact same design_, and re-PAR it using
different _only different cost tables_, and sometimes overflow would work,
and sometimes it wouldn't.  We eventually covered every last timing path
possible (trce -u didn't report any unconstrained paths), and that left us
with, "well, I guess GSR isn't really covered by a timing constraint, is
it?" and the theory of the pipelined counters misstepping when the FPGA is
reset.

---Joel Kolstad




Article: 27577
Subject: Gates in a typical small MPU
From: "Akito" <..@no.com>
Date: Wed, 29 Nov 2000 07:29:06 GMT
Links: << >>  << T >>  << A >>
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.)

Is it seriously conceivable to use a XC4005? if not, would an XC4010
be closer to appropriate?



Article: 27578
Subject: Re: ACEX1K vs FLEX10K
From: "C.Schlehaus" <carlhermann.schlehaus@t-online.de>
Date: Wed, 29 Nov 2000 09:04:06 +0100
Links: << >>  << T >>  << A >>
Hi Nick,

"Nick Bruty" <nick.bruty@easynet.co.uk> schrieb im Newsbeitrag
news:ZNVU5.104202$K64.1294531@monolith.news.easynet.net...
> Yes the power pins are different from the outside the reason being not to
> force a board spin but to force a re compile as the internal pad bondings
> are different so your expected IO's would appear on different pins.
>

I'd do a re-compile any time I would change the device. I would not
use the 10KE compiler output with the ACEX 1K, as it's another
family. That doesn't seems for me a good explanation to switch the
Power Pins to prevent users to replace the 10K by a 1K or vice versa
to prevent problems with switched I/Os.
I still believe, that the 1K family was designed with the goal to
prevent users replace the 10K by the 1K without re-design of the PCB.


CU, Carlhermann

BTW: I'm stil a fan of ALTERA.




Article: 27579
Subject: Re: Xess - XS40-005XL question
From: longwayhome@my-deja.com
Date: Wed, 29 Nov 2000 09:44:22 GMT
Links: << >>  << T >>  << A >>
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' which i want to try to use in the same
way that i read in
http://www.newscientist.com/nsplus/insight/ai/primordial.html since it
seems like a very interesting subject to learn about (and i want to try
using it for a very cunning idea i have :)

Suggestions about existing setups used by people for similar things
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))

Thanks

David


Sent via Deja.com http://www.deja.com/
Before you buy.

Article: 27580
Subject: Re: Gates in a typical small MPU
From: kolja@prowokulta.org
Date: Wed, 29 Nov 2000 09:52:23 GMT
Links: << >>  << T >>  << A >>
I recommend www.fpgacpu.org on this topic.

FPGA CPUs start as low as 35 CLBs for a minimalistic 8-Bit processor
with 256 Byte address range and go up to 100KGates full fledged
32-Bit Sparc and MIPS implementations.

It is often easier and more accurate to count CLBs instead of gates.
This way it is easy to see, that for a 16-Bit CPU Datapath a PC costs
about 8 CLBs, a Register file 8 to 16 CLBs, a simple ALU 8 CLBs, a
data Mux 8 CLBs, and so on.
Beware that a a regular Mux is as expensive as an ALU.
Try to use a Tristate Bus for the result Bus.

CU,
	Kolja

For your own design, to quote Jan Gray: "smaller ist better"

CU,
	Kolja

In article <6f2V5.16069$nh5.1534936@newsread1.prod.itd.earthlink.net>,
  "Akito" <..@no.com> wrote:
> 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.)
>
> Is it seriously conceivable to use a XC4005? if not, would an XC4010
> be closer to appropriate?
>
>


Sent via Deja.com http://www.deja.com/
Before you buy.

Article: 27581
Subject: Synplify Benchmarks
From: Richard Wilkinson <richard.wilkinson@csr.com>
Date: Wed, 29 Nov 2000 10:20:31 +0000
Links: << >>  << T >>  << A >>
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.

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? Does anyone know if there are any benchmarks anywhere that
don't show up on Google or any other search engine that may show this
sort of thing?

Has anyone run Synplify on a Pentium 4 based system yet? ;)

Cheers,

Rich

Article: 27582
Subject: Selfmade Cores or something similar (Xilinx)
From: Marc Reinert <reinert@tu-harburg.de>
Date: Wed, 29 Nov 2000 11:44:05 +0100
Links: << >>  << T >>  << A >>
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                   |
|_________________________________________________________________|

Article: 27583
Subject: Re: hard or soft core for FPGA?
From: Nial Stewart <nials@sqf.hp.com>
Date: Wed, 29 Nov 2000 10:49:24 +0000
Links: << >>  << T >>  << A >>
Wolfgang Loewer wrote:
> 

> When you implement NIOS in an ACEX 1K device, which we successfully did, the
> silicon cost for the processor core is only about US-$ 5,- and the complete
> development environment is only US-$ 995,-.
> 
> Best regards
> Wolfgang Loewer

Wolfgang,

What are the software development/emulation tools like for the NIOS
core? 

Nial.

Article: 27584
Subject: Re: Synthesis & Routing speed
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Wed, 29 Nov 2000 11:00:43 +0000
Links: << >>  << T >>  << A >>


Phil Martin wrote:

> Hi Rick,
>
> Why not upgrade to a Athlon 1.2GHz, with 133MHz DDR?
>
> Then you can tell me whether or not I should do the same!
>
> Cheers,
>
> Phil Martin
>

That's what I'd do if I had the opportunity but we're building an office in
Cambridge so all £££ decisions are subject to questions. That said the DDR
Athlon boards are very much cheaper now than they were even 6 month ago & I
expect a bread&butter 900/133DDR would do almost as well.





Article: 27585
Subject: Re: Wide AND function.
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Wed, 29 Nov 2000 11:22:01 +0000
Links: << >>  << T >>  << A >>


Kent Orthner wrote:

> > Kent Orthner wrote:
> > >
> > > Seeing as I want to do this in one clock cycle,
> > > and *really* don't want to pipeline it, is
> > > there a fancy way of implementing a wide
> <snip>
> > > nothing like this on the inside of a Virtex/SpartanII
> > > FPGA.
> >
>
> Duane <junkmail@junkmail.com> writes:
> > Actually, there is. For clues, take a look in the Libraries guide at the
> <snip>
> > the way through and the result is a high.
>
> Duane,
>
> Thanks.  This is exactly the kind of "Fancy way" that I was looking for.
> In the data book it shown Cin to Cout delay to be 0.2ns max, which should
> give me 6.4 ns for the entire thing.  I'm hoping for 9.6ns for everything,
> including the compare, but maybe I'm being too optimistic.  (I'm stuck
> with the cheapest speed grade, after all.)
>
> Maybe I'll run it as a tree of CinCout chains or something; we'll see.
>
> Thanks for the advice.
>
> On a side note, when I look at the CY Muxes, do you know what the 'BX'
> input is, and what it's for?
>
> -Kent

You might be able to do even better if you split the thing into 2 16 bit
chains using the left & right slices of a CLB column. Use local routing in the
last CLB to and them togther via an LUT (or MULT_AND ?) and the result might
come in under 5ns.


Article: 27586
Subject: Re: Synplify Benchmarks
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Wed, 29 Nov 2000 11:34:01 +0000
Links: << >>  << T >>  << A >>


Richard Wilkinson wrote:

> 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.
>
> 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? Does anyone know if there are any benchmarks anywhere that
> don't show up on Google or any other search engine that may show this
> sort of thing?
>
> Has anyone run Synplify on a Pentium 4 based system yet? ;)
>
> Cheers,
>
> Rich

Of all the tools in the EDA chain Synplify is the fastest. At the moment I'm
synthesising a 75% used XCV400 in < 9 minutes on a vanilla 600MHz PIII/PC100
M'brd. As to memory the max useage is about 70MB if I synthesise everything
together and < 25MB if I do my normal approach of synthesising the top and
level 1 modules separately. In the second case [for Xilinx parts] the
ngdbuild linking takes another 2 min or so.

Note that the big memory burners - again for Xilinx - are MAP & PAR that in
my case are using 150MB. PAR is taking just under an hour for a place&route
with 10 router iterations.



Article: 27587
Subject: FPGA Express warning
From: "Daio" <ds@NOSPAM.pixelfusion.com>
Date: Wed, 29 Nov 2000 11:53:15 -0000
Links: << >>  << T >>  << A >>
Can anyone shed some light on this FGPA Express warning?

Cheers in advance,
Dave

Warning: Duplicate cells '/FPGA1-Optimized/DIN_reg31' and
'/FPGA1-Optimized/MICRO_reg31' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg1' and
'/FPGA1-Optimized/DOUT_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg2' and
'/FPGA1-Optimized/DOUT_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg3' and
'/FPGA1-Optimized/DOUT_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg4' and
'/FPGA1-Optimized/DOUT_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg5' and
'/FPGA1-Optimized/DOUT_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg6' and
'/FPGA1-Optimized/DOUT_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg7' and
'/FPGA1-Optimized/DOUT_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg8' and
'/FPGA1-Optimized/DOUT_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg9' and
'/FPGA1-Optimized/DOUT_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg10' and
'/FPGA1-Optimized/DOUT_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg11' and
'/FPGA1-Optimized/DOUT_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg12' and
'/FPGA1-Optimized/DOUT_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg13' and
'/FPGA1-Optimized/DOUT_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg14' and
'/FPGA1-Optimized/DOUT_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg15' and
'/FPGA1-Optimized/DOUT_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg16' and
'/FPGA1-Optimized/DOUT_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg17' and
'/FPGA1-Optimized/DOUT_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg18' and
'/FPGA1-Optimized/DOUT_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg19' and
'/FPGA1-Optimized/DOUT_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg20' and
'/FPGA1-Optimized/DOUT_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg21' and
'/FPGA1-Optimized/DOUT_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg22' and
'/FPGA1-Optimized/DOUT_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg23' and
'/FPGA1-Optimized/DOUT_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg24' and
'/FPGA1-Optimized/DOUT_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg25' and
'/FPGA1-Optimized/DOUT_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg26' and
'/FPGA1-Optimized/DOUT_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg27' and
'/FPGA1-Optimized/DOUT_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg28' and
'/FPGA1-Optimized/DOUT_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg29' and
'/FPGA1-Optimized/DOUT_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DOUT_reg30' and
'/FPGA1-Optimized/DOUT_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg1' and
'/FPGA1-Optimized/DIO501_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg2' and
'/FPGA1-Optimized/DIO501_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg3' and
'/FPGA1-Optimized/DIO501_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg4' and
'/FPGA1-Optimized/DIO501_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg5' and
'/FPGA1-Optimized/DIO501_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg6' and
'/FPGA1-Optimized/DIO501_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg7' and
'/FPGA1-Optimized/DIO501_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg8' and
'/FPGA1-Optimized/DIO501_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg9' and
'/FPGA1-Optimized/DIO501_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg10' and
'/FPGA1-Optimized/DIO501_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg11' and
'/FPGA1-Optimized/DIO501_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg12' and
'/FPGA1-Optimized/DIO501_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg13' and
'/FPGA1-Optimized/DIO501_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg14' and
'/FPGA1-Optimized/DIO501_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg15' and
'/FPGA1-Optimized/DIO501_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg16' and
'/FPGA1-Optimized/DIO501_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg17' and
'/FPGA1-Optimized/DIO501_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg18' and
'/FPGA1-Optimized/DIO501_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg19' and
'/FPGA1-Optimized/DIO501_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg20' and
'/FPGA1-Optimized/DIO501_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg21' and
'/FPGA1-Optimized/DIO501_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg22' and
'/FPGA1-Optimized/DIO501_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg23' and
'/FPGA1-Optimized/DIO501_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg24' and
'/FPGA1-Optimized/DIO501_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg25' and
'/FPGA1-Optimized/DIO501_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg26' and
'/FPGA1-Optimized/DIO501_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg27' and
'/FPGA1-Optimized/DIO501_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg28' and
'/FPGA1-Optimized/DIO501_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg29' and
'/FPGA1-Optimized/DIO501_reg0' merged.  (FPGA-CLEAN-2)
Warning: Duplicate cells '/FPGA1-Optimized/DIO501_reg30' and
'/FPGA1-Optimized/DIO501_reg0' merged.  (FPGA-CLEAN-2)




Article: 27588
Subject: Re: NGDBUILD/UCF Problem
From: eml@riverside-machines.com.NOSPAM
Date: Wed, 29 Nov 2000 12:19:31 GMT
Links: << >>  << T >>  << A >>
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

Article: 27589
Subject: Re: PLL vs DLL
From: Javier SERRANO <Javier.Serrano@cern.ch>
Date: Wed, 29 Nov 2000 13:42:36 +0100
Links: << >>  << T >>  << A >>
Austin, could you give those figures? I am planning to use the 20KE for
an application where I need low jitter. Can you compare jitter on an
Apex PLL to that obtained using a Virtex DLL?

Thanks,

	Javier

Austin Lesea wrote:
> 
> Nick,
> 
> Measuring the jitter on the NIOS pcb coming out of the PLL clock out pin of
> the 20KE had us smiling all around,
> 
> If you are going to mess with analog PLL's on the same chip as the digital
> stuff: caveat emptor!
> 
> Austin

Article: 27590
Subject: Re: Clock Skew : Does Xilinx know what they're doing?
From: Newsbrowser@Newsbrowser.com (Newsbrowser)
Date: Wed, 29 Nov 2000 13:29:03 GMT
Links: << >>  << T >>  << A >>
On Tue, 28 Nov 2000 09:36:02 -0800, "Walter Haas"
<walter_haas@pmc-sierra.com> wrote:

>Hi everybody <Hi Dr. Nick> :)
>
>I didn't mean to imply that I'd use the 50MHz clock as a clock enable. I would actually just have a data_valid register, that was essentially just a flop with an inverter between it's Q->D data path, and that signal would be the clock enable. The rest of my design would consist of multi-cycle paths (2 cycles), because the FFs couldn't change on the odd cycle, and I'd still get the nice combinatorial buffer.
>
>Cheers,
>
>Wally

Hey Wally, 

I would like to really read your posts. 
I think they are informative. 

But, I am really annoyed with your lack of <CR> 
in the message. Think you can hit that enter key every once in a while

Ralph Watson 
Return Email Address is: 
ralphwat dot home at excite dot com 

Article: 27591
Subject: Re: Virtex bitstream generation
From: Nicolas Matringe <nicolas.matringe@IPricot.com>
Date: Wed, 29 Nov 2000 16:03:55 +0100
Links: << >>  << T >>  << A >>
adam_hawes@dingoblue.net.au wrote:
> 
> Hi all.
> 
> I'm currently in the final stages of getting a design we have
> developed at uni as a group to load into our FPGA.  We can load
> the Virtex (XCV150) using JTAG, and now require a bitstream file
> in a format suitable for slave serial programming.
> 
> Are there any special requirements in programming using slave
> serial, or will the bitstream that comes out of Foundation 2.1
> work with minimal hassle?  Do I need to run bitgen with any
> special options.

Hi
The only thing you need to do is re-run bitgen with the option -g
StartupClock:CCclk instead of -g StartupClock:JtagClock
If you use the GUI, find where the startup clock is specified (I don't
remember) and change from JTAg to CClk.

-- 
Nicolas MATRINGE           IPricot European Headquarters
Conception electronique    10-12 Avenue de Verdun
Tel +33 1 46 52 53 00      F-92250 LA GARENNE-COLOMBES - FRANCE
Fax +33 1 46 52 53 01      http://www.IPricot.com/

Article: 27592
Subject: Re: Synplify Benchmarks
From: "Joel Kolstad" <JoelKolstad@Earthlink.Net>
Date: Wed, 29 Nov 2000 15:41:54 GMT
Links: << >>  << T >>  << A >>
"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: 27593
Subject: Re: Synplify Benchmarks
From: Richard Wilkinson <richard.wilkinson@csr.com>
Date: Wed, 29 Nov 2000 16:12:16 +0000
Links: << >>  << T >>  << A >>
Joel Kolstad 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.

Yes, that seems to be the limiting factor.

> 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.

That was my intention. A good, solid machine from a well-known supplier.

> 
> > 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.)

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

Article: 27594
Subject: Re: PLL vs DLL
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Wed, 29 Nov 2000 08:21:14 -0800
Links: << >>  << T >>  << A >>
Javier,

I have sent the FPGA Lab measurement results to you directly.  For a complete
discussion of jitter, we are preparing a techincal note.  There are many elements
of jitter measurement that require careful attention.

First: signal integrity must be perfect (reflections add jitter).

Second:  the clock source must have extremely low intrinsic jitter.

Third:  the measurement should be made of just going in, and coming out of an IO,
as a calibration of the contribution to jitter of the IO's alone.

Fourth:  the measurement equipment should gather at least a few hundred thousand
samples, when the jitter stops increasing.  We typically take a million samples,
or more.  Curve fitting will also add to the accuracy of the prediction.

Fifth:  output pins should be toggled, logic should be clocked, and other
elements should be exercised to discover the influence of their operation on the
DLL/PLL under test.

Sixth:  power supplies must be perfectly clean for the baseline measurements.
Actual supplies are then used to see the influence of power supply noise on the
results.  We also inject 1 V spikes into the Vccint and Vcco to judge the
resistance of the DLL to outside noise in our testing (simulates the ground
bounce and ringing in a poor design).

Austin

Javier SERRANO wrote:

> Austin, could you give those figures? I am planning to use the 20KE for
> an application where I need low jitter. Can you compare jitter on an
> Apex PLL to that obtained using a Virtex DLL?
>
> Thanks,
>
>         Javier
>
> Austin Lesea wrote:
> >
> > Nick,
> >
> > Measuring the jitter on the NIOS pcb coming out of the PLL clock out pin of
> > the 20KE had us smiling all around,
> >
> > If you are going to mess with analog PLL's on the same chip as the digital
> > stuff: caveat emptor!
> >
> > Austin


Article: 27595
Subject: Re: question on initial states of FFs and GSR in Virtex
From: Muzaffer Kal <muzaffer@dspia.com>
Date: Wed, 29 Nov 2000 17:07:23 GMT
Links: << >>  << T >>  << A >>
On Tue, 28 Nov 2000 22:51:32 -0500, rickman <spamgoeshere4@yahoo.com>
wrote:

>...But this signal is replaced by the GSR net in
>the FPGA. The GSR net is what puts all the FFs in a defined state when
>coming out of configuration. If you wish, you can use this as an
>external reset as well by bringing it to a pin. But that is not
>required. 

I am confused about this. Is it possible to use both GSR and an
external reset ? IOW, If you use an external reset how does the
internal configuration done signal get to the FFs ? Who does the "and"
of external reset with GSR so that one or the other is functional ?

Muzaffer

FPGA DSP Consulting
http://www.dspia.com

Article: 27596
Subject: Re: Fifo design problem
From: Andy Peters <"apeters <"@> n o a o [.] e d u>
Date: Wed, 29 Nov 2000 10:14:13 -0700
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!

That's what I mean: the simulation is fine, the real hardware isn't. 
I'd aim a beady eye on that there simulation model.

Actually, no, I'd write my own damn FIFO.

-- a
----------------------------
Andy Peters
Sr. Electrical Engineer
National Optical Astronomy Observatory
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) n o a o [dot] e d u

"It is better to be silent and thought a fool, 
 than to send an e-mail to the entire company
 and remove all doubt."

Article: 27597
Subject: Re: Fifo design problem
From: Andy Peters <"apeters <"@> n o a o [.] e d u>
Date: Wed, 29 Nov 2000 10:16:05 -0700
Links: << >>  << T >>  << A >>
Jean Nicolle wrote:
> 
> why not use an already debugged FIFO core?
> Altera has a FIFO wizard/megafunctions, while Xilinx had CoreGen (I
> believe).

I've gotten better results speed-wise by rolling my own FIFOs.  For some
reason, every design I do requires a little tweak here or there and the
generic CORE functions just won't fill the bill.

And I still don't trust the simulation models.

-- a
----------------------------
Andy Peters
Sr. Electrical Engineer
National Optical Astronomy Observatory
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) n o a o [dot] e d u

"It is better to be silent and thought a fool, 
 than to send an e-mail to the entire company
 and remove all doubt."

Article: 27598
Subject: Re: question on initial states of FFs and GSR in Virtex
From: Andy Peters <"apeters <"@> n o a o [.] e d u>
Date: Wed, 29 Nov 2000 10:25:15 -0700
Links: << >>  << T >>  << A >>
Muzaffer Kal wrote:
> 
> On Tue, 28 Nov 2000 22:51:32 -0500, rickman <spamgoeshere4@yahoo.com>
> wrote:
> 
> >...But this signal is replaced by the GSR net in
> >the FPGA. The GSR net is what puts all the FFs in a defined state when
> >coming out of configuration. If you wish, you can use this as an
> >external reset as well by bringing it to a pin. But that is not
> >required.
> 
> I am confused about this. Is it possible to use both GSR and an
> external reset ? IOW, If you use an external reset how does the
> internal configuration done signal get to the FFs ? Who does the "and"
> of external reset with GSR so that one or the other is functional ?

The external reset signal is an input to the STARTUP block (in
4K/Spartan, at least) which is where the ORing occurs.

The GSR output of the STARTUP block is distributed to all of the flops
via the GSR nets.

-- a
----------------------------
Andy Peters
Sr. Electrical Engineer
National Optical Astronomy Observatory
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) n o a o [dot] e d u

"It is better to be silent and thought a fool, 
 than to send an e-mail to the entire company
 and remove all doubt."

Article: 27599
Subject: Re: Synplify Benchmarks
From: Muzaffer Kal <muzaffer@dspia.com>
Date: Wed, 29 Nov 2000 17:38:18 GMT
Links: << >>  << T >>  << A >>
On Wed, 29 Nov 2000 16:12:16 +0000, Richard Wilkinson
<richard.wilkinson@csr.com> wrote:
>considerably. SpecFP2000 and SpecInt2000 give pretty favourable results
>- significantly faster than Athlon 1.2GHz machines for example. But they

one problem with deciding on a P4 after looking at SpecInt and SpecFP
is that the program you're running has not been compiled with the same
compiler. P4 has changed a lot of optimization guidelines and "legacy"
(this is what Intel is calling the programs we are running now)
programs may run slower than their newly compiled versions.

Anyone knows what compiler Xilinx is using  for PC versions of their
tools ? It might be upto a year before MSFT comes up with P4 optimized
toolset and I am curious whether Xilinx is using Intel's VC plug-in.

Muzaffer

FPGA DSP Consulting
http://www.dspia.com



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

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

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

Custom Search