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 24050

Article: 24050
Subject: Re: New Xilinx Student Edition
From: Dave Vanden Bout <devb@xess.com>
Date: Mon, 24 Jul 2000 17:55:49 -0400
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------F121DD58A9540E134A83E3F5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ray Andraka wrote:

> Yep, just about when the full-up foundation hits v3.1.  Coincidence?  I don't think
> so.

Actually, Xilinx has to transfer the Student Edition CDROM contents to Prentice Hall months before the books are released so there is time to replicate and package them (remember that these are book publishers who think in timescales of years).  Xilinx has to base the Student Edition version on the current production release at the time.  I think that's why the release is 2.1 and not 3.1.

>
>
> Anna Acevedo wrote:
>
> > The 2.1i Xilinx Student Edition will be available for the start of the Fall
> > semester
> > You should be able to order it from www.amazon.com or www.xess.com by
> > mid August.

--
|| Dr. Dave Van den Bout   XESS Corp.               (919) 387-0076 ||
|| devb@xess.com           2608 Sweetgum Dr.        (800) 549-9377 ||
|| http://www.xess.com     Apex, NC 27502 USA   FAX:(919) 387-1302 ||


--------------F121DD58A9540E134A83E3F5
Content-Type: text/x-vcard; charset=us-ascii;
 name="devb.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dave Vanden Bout
Content-Disposition: attachment;
 filename="devb.vcf"

begin:vcard 
n:Vanden Bout;Dave
tel;fax:(919) 387-1302
tel;work:(919) 387-0076
x-mozilla-html:FALSE
url:http://www.xess.com
org:XESS Corp.
adr:;;2608 Sweetgum Drive;Apex;NC;27502;USA
version:2.1
email;internet:devb@xess.com
title:FPGA Product Manager
x-mozilla-cpt:;-16464
fn:Dave Vanden Bout
end:vcard

--------------F121DD58A9540E134A83E3F5--

Article: 24051
Subject: Re: Q: PAL22V10 JEDEC file-toVHDL translators?
From: Greg Neff <gregneff@my-deja.com>
Date: Mon, 24 Jul 2000 22:59:34 GMT
Links: << >>  << T >>  << A >>
In article <397BD337.648F@designtools.co.nz>,
  jim.granville@designtools.co.nz wrote:
> Tom Vrankar wrote:
> >
> > Does any JEDEC to VHDL converter exist to allow me to quickly
migrate old
> > circuit card designs based on rafts of 22V10s in DIPs to a single
large FPGA?
> > Either freeware or from a FPGA vendor? I've researched it enough to
know I
> > could do it, but figured it was so obvious someone else must've
already done
> > it, though I don't see it mentioned in any FAQs I've found.
>
> How many 22V10's ?
>
> There are two things you'll need :
> - The Equations for each 22V10, ideally source, or rev-eng
>   there are various older pgms that do JED2EQN


National Semiconductor's Opal Jr. (discontinued in 1995), which
contains the JED2EQN utility, can be found at:

ftp://ftp.armory.com/pub/user/rstevew/GAL/opaljr21.zip


> - The PCB netlist(s), for interconnect of the 22V10.
>
> If there are a lot of 22V10's ( dozens ), the PCB netlist may be
> more of a problem :-)
>
> Conversion to Altera AHDL, or ABEL might be easier, as they are closer
> to the equation formats that come out of the jed 'dis-assemblers'.

Also CUPL

>
> As a 22V10 is closer to a CPLD block, ( typ 36V16) than a FPGA, you
> might also look at CPLD targets - it does depend on total register
> count, over 25-50 22V10's and you are more into FPGA territory.
>
> - jg
>

I agree. We like the Xilinx XC9500 family.

--
Greg Neff
VP Engineering
*Microsym* Computers Inc.
greg@guesswhichwordgoeshere.com


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 24052
Subject: Re: New Xilinx Student Edition
From: pratipm@yahoo.com (Pratip Mukherjee)
Date: Mon, 24 Jul 2000 23:08:17 GMT
Links: << >>  << T >>  << A >>
I doubt that can be the only reason. Why can't they put in a coupon and accept 
some shipping and handling charge to upgrade the included software  to a 
version which will be available before the book actually gets published?

Pratip Mukherjee
pratipm@hotmail.com

In article <397CBB64.7FA65C2C@xess.com>, Dave Vanden Bout <devb@xess.com> 
wrote:
>This is a multi-part message in MIME format.
>--------------F121DD58A9540E134A83E3F5
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
>Ray Andraka wrote:
>
>> Yep, just about when the full-up foundation hits v3.1.  Coincidence?  I don't
> think
>> so.
>
>Actually, Xilinx has to transfer the Student Edition CDROM contents to Prentice
> Hall months before the books are released so there is time to replicate and
> package them (remember that these are book publishers who think in timescales
> of years).  Xilinx has to base the Student Edition version on the current
> production release at the time.  I think that's why the release is 2.1 and not
> 3.1.
>
>>
>>
>> Anna Acevedo wrote:
>>
>> > The 2.1i Xilinx Student Edition will be available for the start of the Fall
>> > semester
>> > You should be able to order it from www.amazon.com or www.xess.com by
>> > mid August.
>
Article: 24053
Subject: Re: 17 clocks in a Virtex
From: Ray Andraka <ray@andraka.com>
Date: Tue, 25 Jul 2000 00:10:06 GMT
Links: << >>  << T >>  << A >>
Virtex is quite capable of higher clock rates.  Perhaps a faster master
clock may make more sense: First you can get pretty close to the individual
clocks using a simple DPLL.  That alone probably justify a higer rate
clock.  By running at the higher clock you might also have the opportunity
for sharing logic between ports or decreasing the widths of your data paths
(actually, I guess they are serial already, aren't they).  A high rate clock
lets you transfer the data at each port into the FPGA whilst synchronizing
it.

A simpler implementation, since you are using Virtex would be to take
advantage of the dual port block RAMs for the FIFOs.  If you use a virtex
EM, you got lots of them to work with.

Michael Schmid wrote:

> Jonas Thor wrote:
> ?
> ? Hi,
> ?
> ? Hello!
> ?
> ? We have an interesting problem, 17 clocks that are not synchronized.
> ? We are going to prototype an 8 port Ethernet (10 Mbit) switch in a
> ? Virtex 1000. There's one tx-clock and one rx-clock for each interface
> ? and there is a global clock which we will set to 10Mhz. The tx are rx
> ? clocks are 2.5 MHz. The reason why the global clock will only be at 10
> ? MHz is simply because we want to make the design more challenging,
> ? since a low clock rate makes the queing and buffering handling more
> ? difficult. I should say that I work at a university, so we are allowed
> ? to make things more difficult than they really are ;)
> ?
> ? Anyway our first problem is to synch the data from the 8 ports to the
> ? global clock. Since we have 17 clocks we are out of global clock
> ? routing. My first idea would be to have 16 16-bit deep asynch fifos
> ? implemented in CLBs. Each port would have one rx fifo and one tx fifo
> ? and the fifos should be placed as close to the port as possible. The
> ? fifo would be based on Peter Alfkes appnote (XAPP051 I believe).
> ?
> ? However the problem here, as I see it, is to make sure that the skew
> ? between the port data rx and tx clocks are minimal.
> ?
> ? Any comments about the suggested solution? Some other approach that
> ? migth be better? I have never worked with a Virtex device before.
> ? Previous work has been with the XC4000 and these have different clock
> ? distributing resources compared the Virtex series.
> ?
> ? Jonas Thor
> ? NoSpamthor@sm.luth.seNoSpam - remove the obvious when replying
> ? Lulea University of Technology
> ? Sweden
>
> Hi Jonas,
>
> What about this:
>
> 2.5MHz is not very fast, so You can use
> your 10MHz clock as the one and only
> global clock for all the things you do.
> I.e. if an input signal is high, you
> have 4 cycles to get it. All of your
> rx_clock's are 2 cycles long high (they
> should be???), this allows you following
> code:
>
> process ...
>         if(clk'EVENT) and (clk='1') then
>                 if(rx_clk='1') then
>                         reg_input ?= rx_data;
>                 else
>                         reg_input ?= reg_input;
>                 end if;
>         end if;
> ...
>
> Look in the 10Mbit-PHY Databook. There
> You will find exakt specifications about
> the timings (i.e. high/low-times of your
> rx_clocks). They will help you to find a
> suitable global clock. Maybe 20MHz are
> better, I don't know.
> So You have one global clock clk and a
> registered input reg_input.
>
> Michael
>
> mlschmid@iis.fhg.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: 24054
Subject: Re: Real time sims with NC-Verilog
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Tue, 25 Jul 2000 01:21:48 +0100
Links: << >>  << T >>  << A >>


Stephen Lohning wrote:

> Yes create your self a small sdf file with the particular instances  that are known
> to
> exibit async behaviour and change them to have 0 setup hold.
> Carry this out after your first annatotion has been done. If you have a lot of them
> you can even write a perl program to create the sdf for you.
> If you are really sensible you will append _Meta or something similar so you can
> find
> them all at one. If not it is just an iterative process to find all the async flops.
>
> Then go and give the designer/coders a big kick up the behind because on large
> design it makes verification really difficult.
> Stephen
>
> PS. This process works with NC-verilog

I'm guessing here but I assume that the X's are being triggered in the FF modules whan a
violation causes the notifier output of the timing checks to toggle. This is normally
used by a simulation model to set FF outputs to `X' where they will stay until the next
clock edge. Therefore the crudest trick is to disable the all notifiers. In Verilog-XL
type simulators there's a command line flag something like +no_notifier. The next level
is to turn them off in the FF's concerned by using a ``force'' statement in the top
level testbench:

initial begin
    force <hierarch inst name>.notifier = 0;
end

I combine this with modifying the SDF to increase the delays on these FFs. The final
trick is to use a special model for async FFs. Its here that the various FPGA & ASIC
vendors need a kick up the !!! This situation is so common that they should provide such
models as a standard  part of their sim libraries. Its a little tricky to do since such
a model has to behave normally until there's a violation. When there is one it should go
to `X' for a while and then randomly settle to 1 or 0. Its awkward since it breaks the
simple-minded SDF backannotation used in most model libs.


Article: 24055
Subject: Re: Routing Resources for Xilinx BlockRAM
From: channing@my-deja.com
Date: Tue, 25 Jul 2000 02:38:21 GMT
Links: << >>  << T >>  << A >>
Hi, Ray,

Thanks for your reply.

I was read the Xilinx Virtex databook again, all I can found about the
routing for BlockRAM is a simply description "The Virtex Block
SelectRAM also includes dedicated routing to provide an efficient
interface with both CLBs and other Block SelectRAMs.", and there are
not any detail information can be found to these word.  I'm really care
that if I don't use any BlockRAM, should the "dedicated routing" can be
used by others CLBs as a pass routing interconnect.

In the other word, are there some GRM around the BlockRAM?  If so, does
their still enabled while BlockRAM don't used?


Regards,

Channing


In article <397C7F43.D2CED34F@andraka.com>,
  Ray Andraka <ray@andraka.com> wrote:
> The routing is not really shared.  You should look carefully at the
VIrtex
> routing structure to understand it.  It can't be adequately described
in
> the number of words appropriate for a ng post.  If you have the xilinx
> tools, open up the chip editor for a new design using a virtex 50.
From
> there you will be able to see how the routing, and in particular the
BRAM
> routing is done.  The BRAMs can be found on the right and left edges
of
> the die image.
>
> channing@21cn.com wrote:
>
> > Hi, all,
> >
> > Does anyone know if the BlockRAMs in Xilinx Spartan
II/Virtex/Virtex-E
> > series have their dedicate routing resources, or their share the
> > routing resources with other CLBs ?
> >
> > Any help will be appreciated.
> >
> > Channing
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
>
> --
> -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
>
>


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 24056
Subject: Spartan II Pin
From: Leumann Robert <robert.leumann@3vision.com>
Date: Tue, 25 Jul 2000 08:35:49 +0200
Links: << >>  << T >>  << A >>
Hi
I started with a new project with a Spartan-II from Xilinx. I can't
understand
the functionality of these two pins:
I/O, IRDY
I/O, TRDY
I didn't find any explanation in the datasheet about this two pins.
can anybody help me.

thanks

Leumann Robert


Article: 24057
Subject: Xilinx "MUX_OP not inferred" error.
From: "K.Orthner" <nospam@ihatespam.com>
Date: Tue, 25 Jul 2000 16:49:34 +0900
Links: << >>  << T >>  << A >>
Hey.

I'm getting the following error using Foundation Express:

--
Dpm :Warning: A MUX_OP was not inferred for the case
Dpm:     in routine LARA line 155 in file "<filename" because it's branching
factor of 1048576 is greater than hdlin_mux_size_limit. (HDL-383)
--

I couldn't find this in the Xilinx Support web page anywhere.

Any guesses?  Thanks!
-Kent


------------
Kent Orthner
korthner at hotmal dot com


Article: 24058
Subject: Re: EASY MONEY- NOT A SCAM!!!!!!!!!!!!!!
From: rob_dickinson@my-deja.com
Date: Tue, 25 Jul 2000 09:46:18 GMT
Links: << >>  << T >>  << A >>
I don't understand, why is every newsgroup on the net not completely
swamped with everyone on the planet posting, after all were not fools
this clearly isn't a scam!.


Hang on a minute, why haven't I done it?


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 24059
Subject: Re: Spartan II Pin
From: rickman <spamgoeshere4@yahoo.com>
Date: Tue, 25 Jul 2000 10:05:50 -0400
Links: << >>  << T >>  << A >>
Yes, you are right. I don't know what they are for. I assumed that they
were a hold over from either the Spartan or the Virtex chips, but they
don't appear in the documentation for either. I guess you may need to
contact Xilinx about these. 


Leumann Robert wrote:
> 
> Hi
> I started with a new project with a Spartan-II from Xilinx. I can't
> understand
> the functionality of these two pins:
> I/O, IRDY
> I/O, TRDY
> I didn't find any explanation in the datasheet about this two pins.
> can anybody help me.
> 
> thanks
> 
> Leumann Robert

-- 

Rick Collins

rick.collins@XYarius.com

Ignore the reply address. To email me use the above address with the XY
removed.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 24060
Subject: Re: phase lock different frequencies
From: "Fred Skalka" <fskalka@freewwweb.com>
Date: Tue, 25 Jul 2000 07:39:22 -0700
Links: << >>  << T >>  << A >>
In a Xilinx FPGA, you have the luxury of internal tristate busses.  From this you can buid a delay locked loop. I will e-mail you a block diagram separately.  I have never had the chance to implement this, but have been thinking about it for years.
Article: 24061
Subject: Category : Fndtn 3.1 compatability
From: "Fred Skalka" <fskalka@freewwweb.com>
Date: Tue, 25 Jul 2000 08:09:36 -0700
Links: << >>  << T >>  << A >>
Has anyone had any problems moving from Fndtn 2.1i to Fndtn 3.1i?
Article: 24062
Subject: Re: Spartan II Pin
From: "darrell mcginnis" <darrellm@yahoo.com>
Date: Tue, 25 Jul 2000 17:04:46 GMT
Links: << >>  << T >>  << A >>
IRDY and TRDY happen to also be names for PCI handshake lines.
Specifically the lines that typically have trouble with timing.

I'd assume that there is  some dedicated logic to help implement PCI
and the xilinxCore PCI implementation uses them specifically.

"rickman" <spamgoeshere4@yahoo.com> wrote in message
news:397D9EBE.54B27115@yahoo.com...
> Yes, you are right. I don't know what they are for. I assumed that they
> were a hold over from either the Spartan or the Virtex chips, but they
> don't appear in the documentation for either. I guess you may need to
> contact Xilinx about these.
>
>
> Leumann Robert wrote:
> >
> > Hi
> > I started with a new project with a Spartan-II from Xilinx. I can't
> > understand
> > the functionality of these two pins:
> > I/O, IRDY
> > I/O, TRDY
> > I didn't find any explanation in the datasheet about this two pins.
> > can anybody help me.
> >
> > thanks
> >
> > Leumann Robert
>
> --
>
> Rick Collins
>
> rick.collins@XYarius.com
>
> Ignore the reply address. To email me use the above address with the XY
> removed.
>
>
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design
>
> Arius
> 4 King Ave
> Frederick, MD 21701-3110
> 301-682-7772 Voice
> 301-682-7666 FAX
>
> Internet URL http://www.arius.com


Article: 24063
Subject: Re: Silicon Valley Housing Nightmare?
From: jhallen@world.std.com (Joseph H Allen)
Date: Tue, 25 Jul 2000 17:16:37 GMT
Links: << >>  << T >>  << A >>
In article <8lhv84$hou$1@noao.edu>,
Andy Peters <apeters.Nospam@nospam.noao.edu.nospam> wrote:

>So, who's gonna work in the Starbucks where you get your $5 latte every
>morning?

Your teenage kids of course.

-- 
/*  jhallen@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 24064
Subject: Re: Spartan II Pin
From: fliptron@netcom.com (Philip Freidin)
Date: 25 Jul 2000 18:49:14 GMT
Links: << >>  << T >>  << A >>
These pins are general purpose I/O pins, and you can use them like any
other I/O pin. They also connect to some dedicated logic that is used to
support a PCI interface, if you are using Xilinx's PCI IP core. These PCI
signals are very difficult to meet timing, and the dedicated logic (just a
few gates worth) helps the IP core over that problem. If you are not 
using the core, the pins become available as general I/O.

You can see the dedicated logic in the Xilinx chip editor, where most 
architectural mysteries are revealed.

Philip Freidin

Leumann Robert  <robert.leumann@3vision.com> wrote:
>I started with a new project with a Spartan-II from Xilinx. I can't
>understand
>the functionality of these two pins:
>I/O, IRDY
>I/O, TRDY
Article: 24065
Subject: Re: Xilinx "MUX_OP not inferred" error.
From: winzker@aol.com (Winzker)
Date: 25 Jul 2000 21:58:21 GMT
Links: << >>  << T >>  << A >>
K.Orthner writes:
>I'm getting the following error using Foundation Express:
>
>Dpm :Warning: A MUX_OP was not inferred for the case
>Dpm:     in routine LARA line 155 in file "<filename" because it's branching
>factor of 1048576 is greater than hdlin_mux_size_limit. (HDL-383)

It is a warning (not an error!) from Synopsys FPGA-Express.
It tells you that a certain logic is not implemented as a multiplexer
but as 'normal' logic. You can ignore this statement. 
If you are a 'power-user' you might want to optimize the
structure of your VHDL-code.

What surprises me is the factor of 1048576. Do you have a _huge_ 
combinational block there ???

Regards,    Marco

-----------------------------------------------------------------
Marco Winzker, Liesegang electronics
www.liesegang-electronics.com
As always speaking only for myself

Article: 24066
Subject: Re: Xilinx Logic Cell counts and carry chains
From: gah@ugcs.caltech.edu (glen herrmannsfeldt)
Date: 25 Jul 2000 22:05:06 GMT
Links: << >>  << T >>  << A >>
rickman <spamgoeshere4@yahoo.com> writes:

(snip about counting CLB in different FPGAs)

>Gate counts are the most worthless numbers I know of. It is alot like
>the MHz rating of processors. I have *NO* idea of how to compare a
>PowerPC processor at 600 MHz to a Pentium at 600 MHz. The one thing I am
>sure of is that they are not the same! So I am also sure that a 50 K
>gate Xilinx part is nothing like a 50 K gate Lucent part. But if I am
>not using block RAM, I do know that I can get the same design to fit in
>two parts that have the same number of LUTs (or at least close). 

But at least gate count have a standard meaning.  I don't know the details
of Lucent, but I would expect different CLB to fit different problems
differently.  If someone has an ASIC or other design with a certain 
number of 'gates' and wants to know which FPGA it might fit in, gates
are it.  But again, different designs will fit a different number of
'gates'  in a given FPGA.  The Xilinx carry logic adds to the difficulty,
when comparing against FPGA that doesn't have it, for arithmetic based
logic.  

The added complication is marketing departments that want as large a
number as they can possibly justify.  It is likely that they use a 
different design than yours when computing the numbers.  I don't think
CLB count is any better than gate count.

-- glen

Article: 24067
Subject: Power PC with Xilinx - what do you think?
From: "peter dudley" <padudle@spinn.net>
Date: Tue, 25 Jul 2000 16:31:54 -0600
Links: << >>  << T >>  << A >>
Hello All,

Does anyone have a strong opinion about the IBM/Xilinx alliance to put
Virtex II logic on the same die with an IBM PPC core? Are a lot of you guys
putting high performance microcontrollers on the same board as big fpga
designs? Just curious.

http://www.xilinx.com/prs_rls/ibmpartner.htm

--
Pete Dudley

Arroyo Grande Systems







Article: 24068
Subject: Re: Xilinx "MUX_OP not inferred" error.
From: "K.Orthner" <nospam@ihatespam.com>
Date: Wed, 26 Jul 2000 10:02:44 +0900
Links: << >>  << T >>  << A >>
I stand (sit) corrected.  I should have made myself more clear.

Yes, it's a warning, not an error.  Yes, my design place-and-routes fine, it
seems. (Havent tested it yet.)

And, no, I don't have a huge combinational block, which is the odd thing.  I
have about 20 fairly simple states, with about half of them doig nothing but
cusking up a clock cycle before going on to the next state.

Which makes me wonder what Synopsys *thinks* I have there?

-Kent


> >Dpm :Warning: A MUX_OP was not inferred for the case
> >Dpm:     in routine LARA line 155 in file "<filename" because it's
branching
> >factor of 1048576 is greater than hdlin_mux_size_limit. (HDL-383)
>
> It is a warning (not an error!) from Synopsys FPGA-Express.
> It tells you that a certain logic is not implemented as a multiplexer
> but as 'normal' logic. You can ignore this statement.
> If you are a 'power-user' you might want to optimize the
> structure of your VHDL-code.
>
> What surprises me is the factor of 1048576. Do you have a _huge_
> combinational block there ???

------------
Kent Orthner


Article: 24069
Subject: Re: Routing Resources for Xilinx BlockRAM
From: Ray Andraka <ray@andraka.com>
Date: Wed, 26 Jul 2000 03:21:17 GMT
Links: << >>  << T >>  << A >>
No.  The block RAMs connect to a set of vertical lines that are separate
from the ones used by the adjacent column.  Those long lines have pips that
allow it to connect to the horizontal single length lines of the adjacent
column that would normally connect to the next column, as well as to the
horizontal hex and long lines.  This should give you plenty of flexibility
in routing them, and it doesn't take anything away from the CLBs.

channing@my-deja.com wrote:

> Hi, Ray,
>
> Thanks for your reply.
>
> I was read the Xilinx Virtex databook again, all I can found about the
> routing for BlockRAM is a simply description "The Virtex Block
> SelectRAM also includes dedicated routing to provide an efficient
> interface with both CLBs and other Block SelectRAMs.", and there are
> not any detail information can be found to these word.  I'm really care
> that if I don't use any BlockRAM, should the "dedicated routing" can be
> used by others CLBs as a pass routing interconnect.
>
> In the other word, are there some GRM around the BlockRAM?  If so, does
> their still enabled while BlockRAM don't used?
>
> Regards,
>
> Channing
>
> In article ?397C7F43.D2CED34F@andraka.com?,
>   Ray Andraka ?ray@andraka.com? wrote:
> ? The routing is not really shared.  You should look carefully at the
> VIrtex
> ? routing structure to understand it.  It can't be adequately described
> in
> ? the number of words appropriate for a ng post.  If you have the xilinx
> ? tools, open up the chip editor for a new design using a virtex 50.
> From
> ? there you will be able to see how the routing, and in particular the
> BRAM
> ? routing is done.  The BRAMs can be found on the right and left edges
> of
> ? the die image.
> ?
> ? channing@21cn.com wrote:
> ?
> ? ? Hi, all,
> ? ?
> ? ? Does anyone know if the BlockRAMs in Xilinx Spartan
> II/Virtex/Virtex-E
> ? ? series have their dedicate routing resources, or their share the
> ? ? routing resources with other CLBs ?
> ? ?
> ? ? Any help will be appreciated.
> ? ?
> ? ? Channing
> ? ?
> ? ? Sent via Deja.com http://www.deja.com/
> ? ? Before you buy.
> ?
> ? --
> ? -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
> ?
> ?
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

--
-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: 24070
Subject: Re: Spartan II Pin
From: Ray Andraka <ray@andraka.com>
Date: Wed, 26 Jul 2000 03:25:09 GMT
Links: << >>  << T >>  << A >>
For practical purposes these are just regular I/O.  They happen to have
a few gates of dedicated logic attached to them to support the xilinx
PCI core, as the IRDY and TRDY signals have very stringent timing
requirements that are difficult to meet with the regular logic.  You can
see them in the editor.  You can't get to them using the regular tool
flow; you can only use them by creating an EPIC macro and instantiating
it.  Unless you are doing a PCI interface, you don't need to concern
yourself with the special mode (it is essentially not accessible
anyway).

Leumann Robert wrote:

> Hi
> I started with a new project with a Spartan-II from Xilinx. I can't
> understand
> the functionality of these two pins:
> I/O, IRDY
> I/O, TRDY
> I didn't find any explanation in the datasheet about this two pins.
> can anybody help me.
>
> thanks
>
> Leumann Robert

--
-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: 24071
Subject: Re: Silicon Valley Housing Nightmare?
From: Ray Andraka <ray@andraka.com>
Date: Wed, 26 Jul 2000 03:27:28 GMT
Links: << >>  << T >>  << A >>
Ex Fry's employees?

Joseph H Allen wrote:

> In article ?8lhv84$hou$1@noao.edu?,
> Andy Peters ?apeters.Nospam@nospam.noao.edu.nospam? wrote:
>
> ?So, who's gonna work in the Starbucks where you get your $5 latte every
> ?morning?
>
> Your teenage kids of course.
>
> --
> /*  jhallen@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
> int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3?(r=time(0)
> +r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p?1659?79:0:p?158?-79:0,q?!a[p+q*2
> ]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

--
-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: 24072
Subject: Re: Xilinx Logic Cell counts and carry chains
From: Ray Andraka <ray@andraka.com>
Date: Wed, 26 Jul 2000 03:32:57 GMT
Links: << >>  << T >>  << A >>
Gates depends on implementation.  If your design is an adder implemented
entirely of nand gates and implemented that way in the FPGA, it's going to
take a bunch more resources than one that uses the dedicated carry chain.
ASIC designs generally do not map well into FPGAs without extensive changes.
That is part of the reason FPGAs have gotten a rap for being "slow".  LUTs is
an accurate measure of the raw logic resource, but you need to take into
account how the extra features will fit into your design.  For DSP designs,
the carry chain implementation and the ability to create compact delay queues
figures prominently in favor of the Xilinx architectures even though the
Altera parts might have a larger number of LUTs.

glen herrmannsfeldt wrote:

> rickman ?spamgoeshere4@yahoo.com? writes:
>
> (snip about counting CLB in different FPGAs)
>
> ?Gate counts are the most worthless numbers I know of. It is alot like
> ?the MHz rating of processors. I have *NO* idea of how to compare a
> ?PowerPC processor at 600 MHz to a Pentium at 600 MHz. The one thing I am
> ?sure of is that they are not the same! So I am also sure that a 50 K
> ?gate Xilinx part is nothing like a 50 K gate Lucent part. But if I am
> ?not using block RAM, I do know that I can get the same design to fit in
> ?two parts that have the same number of LUTs (or at least close).
>
> But at least gate count have a standard meaning.  I don't know the details
> of Lucent, but I would expect different CLB to fit different problems
> differently.  If someone has an ASIC or other design with a certain
> number of 'gates' and wants to know which FPGA it might fit in, gates
> are it.  But again, different designs will fit a different number of
> 'gates'  in a given FPGA.  The Xilinx carry logic adds to the difficulty,
> when comparing against FPGA that doesn't have it, for arithmetic based
> logic.
>
> The added complication is marketing departments that want as large a
> number as they can possibly justify.  It is likely that they use a
> different design than yours when computing the numbers.  I don't think
> CLB count is any better than gate count.
>
> -- glen

--
-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: 24073
Subject: Re: Xilinx Logic Cell counts and carry chains
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 26 Jul 2000 01:29:28 -0400
Links: << >>  << T >>  << A >>
glen herrmannsfeldt wrote:
> 
> rickman <spamgoeshere4@yahoo.com> writes:
> 
> (snip about counting CLB in different FPGAs)
> 
> >Gate counts are the most worthless numbers I know of. It is alot like
> >the MHz rating of processors. I have *NO* idea of how to compare a
> >PowerPC processor at 600 MHz to a Pentium at 600 MHz. The one thing I am
> >sure of is that they are not the same! So I am also sure that a 50 K
> >gate Xilinx part is nothing like a 50 K gate Lucent part. But if I am
> >not using block RAM, I do know that I can get the same design to fit in
> >two parts that have the same number of LUTs (or at least close).
> 
> But at least gate count have a standard meaning.  I don't know the details
> of Lucent, but I would expect different CLB to fit different problems
> differently.  If someone has an ASIC or other design with a certain
> number of 'gates' and wants to know which FPGA it might fit in, gates
> are it.  But again, different designs will fit a different number of
> 'gates'  in a given FPGA.  The Xilinx carry logic adds to the difficulty,
> when comparing against FPGA that doesn't have it, for arithmetic based
> logic.
> 
> The added complication is marketing departments that want as large a
> number as they can possibly justify.  It is likely that they use a
> different design than yours when computing the numbers.  I don't think
> CLB count is any better than gate count.
> 
> -- glen

If I can be somewhat flippant at the risk of being rude... what have you
been smoking????

Gate counts have virtually no meaning at all in evaluating the fit of a
design into a part. Even within a single vendor's product line the gate
count has very little meaning. When a part consists of a single
homogenious sea of CLB's or gate or whatever the FPGA is composed of,
then you can make at least some guess of how useful the design units
translate into gates. But the newer parts contain a multitude of
different types of units which may or may not be useful in any given
design. Even if you can use all of the different functional blocks, you
are not likely to use them in the fixed ratio that you find in a given
part. 

The Xilinx Virtex parts contain CLBs with LUTs and FFs along with block
RAM. What are the chances that you will use exactly 1 FF per 4 input
LUT? What are the chances that you will use all 4 inputs on every LUT?
What are the chances that you will use all of the block RAM as well? The
gate count depends on you using all of these diverse entities in the
correct ratio. 

This does not even take into account the inflation figure that is
applied to punch up the gate counts for marketing purposes. 

This is why I want to use something that I understand, the 4 input LUT.
This is the basic unit of logic that I have learned to think of when I
do my logic design. If they start using a 5 input LUT as the basic logic
element I will have to go back to school! 


-- 

Rick Collins

rick.collins@XYarius.com

Ignore the reply address. To email me use the above address with the XY
removed.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 24074
Subject: Re: Xilinx "MUX_OP not inferred" error.
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 26 Jul 2000 01:43:12 -0400
Links: << >>  << T >>  << A >>
Any chance that you are using one-hot encoding? I found that Express
will use all of your FF outputs to decode each state even when you tell
it you are one-hot encoded. I forget how I got around the problem, but
it generated a huge amount of logic in my FSM. 

Pick a simple state, like one of the ones where you are just waiting one
clock cycle and moving on. In the EDIF file, analyze the logic feeding
this FF. I bet you find an N input AND function being implemented where
N is the number of states in your one-hot FSM. In one case I got N-1 FFs
as it used the all zeros case as a state!!! 

If you look at one of your more complex states with multiple transtions
into it, that you get such a mess of logic that you have a hard time
analyzing it! 

I seem to remember that I had to separate the FFs generated from the
logic by putting them in separate processes. But this was a year ago and
I am not sure. 



"K.Orthner" wrote:
> 
> I stand (sit) corrected.  I should have made myself more clear.
> 
> Yes, it's a warning, not an error.  Yes, my design place-and-routes fine, it
> seems. (Havent tested it yet.)
> 
> And, no, I don't have a huge combinational block, which is the odd thing.  I
> have about 20 fairly simple states, with about half of them doig nothing but
> cusking up a clock cycle before going on to the next state.
> 
> Which makes me wonder what Synopsys *thinks* I have there?
> 
> -Kent
> 
> > >Dpm :Warning: A MUX_OP was not inferred for the case
> > >Dpm:     in routine LARA line 155 in file "<filename" because it's
> branching
> > >factor of 1048576 is greater than hdlin_mux_size_limit. (HDL-383)
> >
> > It is a warning (not an error!) from Synopsys FPGA-Express.
> > It tells you that a certain logic is not implemented as a multiplexer
> > but as 'normal' logic. You can ignore this statement.
> > If you are a 'power-user' you might want to optimize the
> > structure of your VHDL-code.
> >
> > What surprises me is the factor of 1048576. Do you have a _huge_
> > combinational block there ???
> 
> ------------
> Kent Orthner

-- 

Rick Collins

rick.collins@XYarius.com

Ignore the reply address. To email me use the above address with the XY
removed.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.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
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