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 25050

Article: 25050
Subject: Re: largest fpga in the industry
From: Ray Andraka <ray@andraka.com>
Date: Thu, 24 Aug 2000 22:40:31 GMT
Links: << >>  << T >>  << A >>
Hear, Hear!

I'm biased towards Xilinx not because of any allegiance or ties to the company,
but because it is the best silicon for the applications I deal with.  I'd love
to see more postings by those who find other architectures more suitable for
their applications.  Perhaps the lack of other proponents is indicative of the
ability of the other architectures ;-O

"S. Ramirez" wrote:
> 
> Yoram,
>      This is a side note to your question.  Earlier, someone claimed that
> this newsgroup is dominated by Xilinx.  Since it is an FPGA newsgroup, I
> would like to see Altera, Actel, Lucent, Quicklogic, Atmel, Lattice and
> others post what they have to answer Yoram's question.  There is nothing
> stopping these vendors from posting various messages explaining what they
> have or answering questions and offering clarification.  And there is
> nothing stopping engineers from posting problems and questions related to
> these other vendors.
>      Please post and add more information wealth to this newsgroup.
> -Simon Ramirez, Consultant
>  Synchronous Design, Inc.
> 
> <yorams70@my-deja.com> wrote in message news:8o3ld7$185$1@nnrp1.deja.com...
> > Hi.
> > I would like to know what is the largest fpga in the industry in
> > terms of internal RAM. (and I mean RAM that it's usage will not
> > come on the cost of logic cells use).
> >
> > ThankX,
> > Yoram.

-- 
-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: 25051
Subject: Re: largest fpga in the industry
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Thu, 24 Aug 2000 15:40:40 -0700
Links: << >>  << T >>  << A >>


"S. Ramirez" wrote:

> Yoram,
>      This is a side note to your question.  Earlier, someone claimed that
> this newsgroup is dominated by Xilinx.  Since it is an FPGA newsgroup, I
> would like to see Altera, Actel, Lucent, Quicklogic, Atmel, Lattice and
> others post what they have to answer Yoram's question.  There is nothing
> stopping these vendors from posting various messages explaining what they
> have or answering questions and offering clarification.

Well, Altera has a little self-inflicted problem.
They claim that even their big parts are not FPGAs, but rather CPLDs.
My theory is that they therefore think they need to ignore us here.
I agree that the newsgroup would be better off with a free exchange of ideas
and comments.
As long as we avoid breast-beating and advertising...

Peter

Article: 25052
Subject: Re: create a RAM in a Virtex
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Thu, 24 Aug 2000 15:50:55 -0700
Links: << >>  << T >>  << A >>


Steve Oldridge wrote:

> I think the real problem you're gonna face is processing those 200 bits...  Routing
> those 200 lines from the block Rams to the CLBs for processing is going to be no
> mean feat.

It's not so bad. each BlockRAM has a "vertical" height of 4 CLBs, so the 13 BlockRAMs
have a height of 52 CLBs, of course normally, (in XCV300E or smaller), broken down
into two banks.
Anyhow, there is (nowadays) enough routing for the data.
"This is not your father's XC4025 anymore..."

Peter Alfke, Xilinx Applications

Article: 25053
Subject: Re: create a RAM in a Virtex
From: nweaver@boom.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: 24 Aug 2000 22:57:52 GMT
Links: << >>  << T >>  << A >>
In article <39A5A6CE.F3529E88@xilinx.com>,
Peter Alfke  <peter.alfke@xilinx.com> wrote:
>"This is not your father's XC4025 anymore..."

	4025?  Bah, such a huge waste of silicon.  Back when I was an
undergraduate, we had 4003s and we LIKED them.  (We didn't like the 1+
hour compile times, however.  :)
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu
Article: 25054
Subject: Re: create a RAM in a Virtex
From: Ray Andraka <ray@andraka.com>
Date: Fri, 25 Aug 2000 00:53:21 GMT
Links: << >>  << T >>  << A >>
That shouldn't be a problem.  There's plenty of routing to get in and out of
them pretty efficiently, and with a little care you can even do it faster than
most people think "real designs" can be clocked.

Steve Oldridge wrote:
> 
> I think the real problem you're gonna face is processing those 200 bits...  Routing
> those 200 lines from the block Rams to the CLBs for processing is going to be no
> mean feat.  What are you doing that you need all 200 bits at once?  That said, I
> can't really think of a way around the problem unless you can do with accessing the
> data in chunks (in which case you don't really need a 200 bit wide RAM in the first
> place).  Just something to consider...
>   Steve
> 
> > Gerhard Griessnig wrote:
> > >
> > > I need to create a RAM in a XILINX-Virtex V300 with the XILINX Foundationtool.
> > >
> > > My problem is that my RAM has a width of  200 bits.
> > >
> > > Can i use the ONBOARD-RAM (only in Virtex-Series? max width is 16?) without a
> > > complex addressing.

-- 
-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: 25055
Subject: Re: Metastability and antifuze
From: murray@pa.dec.com (Hal Murray)
Date: 25 Aug 2000 01:54:03 GMT
Links: << >>  << T >>  << A >>

> [1] "Metastability Report for FPGAs," Quicklogic Data
>     Book, 1994, pp. 523-526.
            ^^^^

> [2] Actel Data Book, 1992, pp. 5-1 to 5-2.
                       ^^^^

Ugh.  Maybe it's a conspiracy to make Xilinx look good.  :)

-- 
These are my opinions, not necessarily my employers.  I hate spam.
Article: 25056
Subject: Re: Non-disclosures in job interviews, Round Two
From: Zoltan Kocsi <root@127.0.0.1>
Date: 25 Aug 2000 12:07:14 +1000
Links: << >>  << T >>  << A >>
rickman <spamgoeshere4@yahoo.com> writes:

> [...]
> A completed application,
> 
> A "consumer report" (otherwise known as a credit check) authorization,
> 
> A Background questionnaire release form,
> 
> Then they want me to leave behind a urine sample for drug testing.
> [...]

It ain't gonna be too long until you'll have to go through genetic
screening to get the job. A brave, new world, it is ...

Zoltan

-- 
+------------------------------------------------------------------+
| ** To reach me write to zoltan in the domain of bendor com au ** |
+--------------------------------+---------------------------------+
| Zoltan Kocsi                   |   I don't believe in miracles   |  
| Bendor Research Pty. Ltd.      |   but I rely on them.           |
+--------------------------------+---------------------------------+
Article: 25057
Subject: Re: Metastability and antifuze
From: rk <stellare@nospamplease.erols.com>
Date: Thu, 24 Aug 2000 22:08:44 -0400
Links: << >>  << T >>  << A >>
Hal Murray wrote:

> > [1] "Metastability Report for FPGAs," Quicklogic Data
> >     Book, 1994, pp. 523-526.
>             ^^^^
>
> > [2] Actel Data Book, 1992, pp. 5-1 to 5-2.
>                        ^^^^
>
> Ugh.  Maybe it's a conspiracy to make Xilinx look good.  :)

While I am almost alway a believer in conspiracy theories, I can't say
that I know of one here.  I just had some old books laying around the
study.  Now, I don't recall any of the newer books having any more
update to date information.  Perhaps Dan or John can chime in.

I did try and hunt for more information on various www sites to update
things but couldn't find anything relevant.  Help, anyone?

Have a nice evening,

rk

Article: 25058
Subject: Re: largest fpga in the industry
From: "S. Ramirez" <sramirez@cfl.rr.com>
Date: Fri, 25 Aug 2000 02:10:29 GMT
Links: << >>  << T >>  << A >>

"Peter Alfke" <peter.alfke@xilinx.com> wrote in message
news:39A5A2AB.2D5797B0@xilinx.com...
> It's around 25 mm square, or an inch for you non-metric folks.
>
> Bragging about large chip size always gives me a creepy feeling.
> Here we have a bunch of engineers and layout designers who sacrificed
their
> lunch, their sleep, and their family life to squeeze the design as small
as
> they possibly could do it.
> And then somebody brags about how BIG the chip is.  :-(
> I wish it were smaller, then it would be both faster and cheaper. But this
> size was the smallest we could make it, of course only until we shrink it
> next year....
> But, hats off to the fab ( in Taiwan ) who can produce such monster chips
> without any defect, and to the guys who can stuff it into a package and
bond
> more than a thousand wires..
>
> Isn't it almost a miracle ?
> Peter Alfke

They said the same thing about the 22V10 (except for the die-size of
course)!
-Simon Ramirez, Consultant
 Synchronous Design, Inc.



Article: 25059
Subject: Re: largest fpga in the industry
From: Ben Franchuk <bfranchuk@jetnet.ab.ca>
Date: Fri, 25 Aug 2000 02:16:28 +0000
Links: << >>  << T >>  << A >>
"S. Ramirez" wrote:
> > It's around 25 mm square, or an inch for you non-metric folks.
> > Bragging about large chip size always gives me a creepy feeling.
> > Here we have a bunch of engineers and layout designers who sacrificed their
> > lunch, their sleep, and their family life to squeeze the design as small as
> > they possibly could do it.
> > And then somebody brags about how BIG the chip is.  :-(

But the real question is what is the best cost / performance ratio.
Big chips cost TOO much. Small chips do TOO little. Plus the price
of Sockets (What you want fix a computer board by replacing a defective
chip - ha ha ha !) and the PCB complexity and clock speed all are factors.
Ben.
-- 
"We do not inherit our time on this planet from our parents...
 We borrow it from our children."
"24 bit CPU's R us" http://www.jetnet.ab.ca/users/bfranchuk/index.html
Article: 25060
Subject: Re: help -- of RAMs, FFs, latches, inverted clocks, and other curiosities
From: brian_m_davis@my-deja.com
Date: Fri, 25 Aug 2000 03:00:27 GMT
Links: << >>  << T >>  << A >>
on 8/6/00, Jan Gray wrote:

>I am working on optimized processor cores for Virtex
>and I have a strange result, perhaps a bug in the tools.
>This problem is with F2.1i SP6.

<snip description of latch/write clock polarity problems>

  I hadn't used Virtex/Spartan-II CLB latches before;
after experimenting with them for a while, I'd say it's
definitely a bug.

Problem Summary:

   The problem occurs in both 3.1i SP2 and 2.1i SP6.

   MAP and PAR have their clock polarity packing rules
 backwards: when packing latches with clocked memory
 elements, they reject the valid combinations and
 allow the invalid ones.

   In the resulting hardware, the latches have the
 polarity that was specified, but the clock sense of
 the RAM or SRL16 elements is inverted. ( Verified
 both by simulation and in hardware using a XC2S100 ).

More Info:

 ftp://members.aol.com/fpgastuff/

   latch_bug1.txt  more info on problem and test cases

   latch_bug1.zip:
       latch_bug1.txt
       ram_test\       design using RAM's
       srl_test\       design using SRL16's

Brian Davis


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 25061
Subject: Xilinx 3.1i ISE
From: korthner@hotmail.nospam.com (K. Orthner)
Date: 25 Aug 2000 03:42:32 GMT
Links: << >>  << T >>  << A >>
Hi, everyone.

I've received my copy of the Xilinx 3.1i software, and installed it this 
morning.

It seems to me that it doesn't support multiple entities in a single file!

I just want to check to see if anyone's run into the same thing.  This is 
what I did:

1. Installed it.
2. Created new project (Since it doesn't seem to read 2.1i projects)
3. Added all my source files from an old project.  this includes "Ram.vhd", 
which has a bunch'o'entities for different RAM constructs.
4. Looked at the "Modules" window, where I found only the last entity in 
any given file was displayed.

Any ideas, anyone?

-Kent
Article: 25062
Subject: Re: Xilinx 3.1i ISE
From: korthner@hotmail.nospam.com (K. Orthner)
Date: 25 Aug 2000 06:15:46 GMT
Links: << >>  << T >>  << A >>
Ot further my explanation a bit more:

When I add the files, I'm given an option to add the file as a VHDL module, 
or as a Package.  Perhaps I can have only one entity per module file, and 
if what I really want is a collection of entities, like RAM structures, 
then maybe it should be a Package?

-Kent

korthner@hotmail.nospam.com (K. Orthner) wrote in
<8F9B82AFEkorthnerhotmailcom@158.202.232.7>: 

>Hi, everyone.
>
>I've received my copy of the Xilinx 3.1i software, and installed it this
>morning.
>
>It seems to me that it doesn't support multiple entities in a single
>file! 
>
>I just want to check to see if anyone's run into the same thing.  This
>is what I did:
>
>1. Installed it.
>2. Created new project (Since it doesn't seem to read 2.1i projects)
>3. Added all my source files from an old project.  this includes
>"Ram.vhd", which has a bunch'o'entities for different RAM constructs.
>4. Looked at the "Modules" window, where I found only the last entity in
>any given file was displayed.
>
>Any ideas, anyone?
>
>-Kent

Article: 25063
Subject: Re: largest fpga in the industry
From: "Simon" <simonb@tile.demon.co.cuthis.uk>
Date: Fri, 25 Aug 2000 07:17:07 +0100
Links: << >>  << T >>  << A >>
I am told that referring to the the Xilinx BlockRAM as RAMB4 is
a clue that a higher density embedded RAM (RAMB8?) may be on the way.
But if I knew anything ...

Peter Alfke wrote in message <39A58E60.5054A94B@xilinx.com>...
>Let me describe the biggest FPGA that Xilinx is shipping now ( and I mean
shipping
>today to paying customers ):
>
>The Virtex XCV3200E has a 104 x 156 array of CLBs. That makes it 16,224
CLBs, each
>with four Logic Cells. That means there are 64,896 Logic Cells, each
consisting of
>a 4-input look-up table plus a flip-flop.
>You can use each LUT as either logic (ROM), as 16-bit RAM, or as 16-bit
shift
>register. ( Altera can use the LUT only as logic (ROM).
>
>Independent of these CLBs, there are 208  BlockRAMs, each with 4096 bits
and two
>completely independent access mechanisms ( true dual-ported). That makes it
>851,968 bits of RAM, not counting the RAMs in the LUTs.
>
snip


Article: 25064
Subject: DLL Properties on Xilinx Virtex/VirtexE
From: Markus Michel <mmichel@kontronmedical.ch>
Date: Fri, 25 Aug 2000 08:38:41 +0200
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------1809166CFA9E31CE13276557
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello all,

The DLL's on Virtex and VirtexE have the three properties
- DUTY_CYCLE_CORRECTION
- CLKDV_DIVIDE
- STARTUP_WAIT.
There is no problem for simulation in VHDL of the units
unisim.CLKDLL or unisim.CLKDLLHF; the properties are defined
here by means of generics.

Questions:
1. How get the properties defined for implementation?
2. Can this be done in the VHDL source code?
3. Or is this done with the Design Manager?

Thanks for your immediate help, best regards
Markus

--------------1809166CFA9E31CE13276557
Content-Type: text/x-vcard; charset=us-ascii;
 name="mmichel.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Markus Michel
Content-Disposition: attachment;
 filename="mmichel.vcf"

begin:vcard 
n:Michel;Markus
tel;fax:+41 (0)61 336 22 00
tel;work:+41 (0)61 336 22 22
x-mozilla-html:FALSE
org:Kontron Medical AG
version:2.1
email;internet:mmichel@kontronmedical.ch
title:dipl. El'Ing. ETH
adr;quoted-printable:;;Reinacherstr. 131=0D=0AP.O. Box;CH- 4002 Basel;;;Switzerland
x-mozilla-cpt:;5808
fn:Markus Michel
end:vcard

--------------1809166CFA9E31CE13276557--

Article: 25065
Subject: Re: help -- of RAMs, FFs, latches, inverted clocks, and other curiosities
From: "Jan Gray" <jsgray@acm.org>
Date: Fri, 25 Aug 2000 06:39:52 GMT
Links: << >>  << T >>  << A >>
<brian_m_davis@my-deja.com> wrote in message
news:8o4ng2$8rs$1@nnrp1.deja.com...
> on 8/6/00, Jan Gray wrote:
>
> >I am working on optimized processor cores for Virtex
> >and I have a strange result, perhaps a bug in the tools.
> >This problem is with F2.1i SP6.
>
> <snip description of latch/write clock polarity problems>
>
>   I hadn't used Virtex/Spartan-II CLB latches before;
> after experimenting with them for a while, I'd say it's
> definitely a bug.
>
> Problem Summary:
>
>    The problem occurs in both 3.1i SP2 and 2.1i SP6.
>
>    MAP and PAR have their clock polarity packing rules
>  backwards: when packing latches with clocked memory
>  elements, they reject the valid combinations and
>  allow the invalid ones.
>
>    In the resulting hardware, the latches have the
>  polarity that was specified, but the clock sense of
>  the RAM or SRL16 elements is inverted. ( Verified
>  both by simulation and in hardware using a XC2S100 ).

My thanks to Brian for picking up the ball and running with this, and
verifying in several ways that map/par are wrong here.  It is astonishing
that this problem was not found, reported, and fixed by 3.1i, but I suppose
no one is using RAM near latches.  This is a "good thing" -- I wouldn't do
so either except this was a last-ditch effort to avoid wasting area in my
designs.

Brian's legwork confirms there is no way to do what I was hoping to do.

I went down this path because in XC4000s I made compact, read/write per
clock register files using single-port select RAM, driving a write address
and clocking the write on the rising edge, then driving a read address and
capturing read data in the same CLBs' flip-flops on the falling edge.  Alas
in Virtex the slice architecture does not permit the flip-flop clock to be
inverted with respect to the RAM clock.  So I had tried to use positive
enabled latches instead, and the tools erroneously let me do so, but now
Brian confirms that the only configuration the hardware supports has the
latch closed when I need it to be open and vice versa.

Workarounds: I could...

* clock the reg file twice as fast, perhaps via a separate 2X clock from a
DLL, but this constrains the min cycle time of the register file, hence the
pipeline, to be twice the min cycle time of the select RAMs, e.g. 2xTwc =
~12 ns in S2-5 = ~ 80 MHz, not fast enough.

* move the register file output register flops (that are clocked on the
clock falling edge) to other CLBs (and invert the clock to those FFs), but
this use of local interconnect is slower, and this structure makes
floorplanning more awkward.

* use dual-port RAMs, but these are half as area efficient at best.
(Sometimes worse -- for n x 32 reg files from 16x1 dprams, I also need
output muxes (but perhaps F6MUXs work).)

* use dual-port block RAMs, but these are slower and are spoken for.

So I am using dual-port RAMs, and have filed this next to "PAR won't do
H-muxes" in the "missed opportunities to save area" file.

Jan Gray
Gray Research LLC



Article: 25066
Subject: Re: Non-disclosures in job interviews, Round Two
From: rickman <spamgoeshere4@yahoo.com>
Date: Fri, 25 Aug 2000 03:03:56 -0400
Links: << >>  << T >>  << A >>
I am not disclosing the name of the companies I have dealt with for
several reasons. 

1) I don't feel this adds anything to the discussion. If I tell you it
was IBM (it wasn't) how does that add to any of the points being
discussed? I can give you all the details of the incident without
telling you the name of the company. 

2) I don't want to violate any agreement that they feel was implied,
even though I did not sign. Actually I did sign with an addendum
requiring a written indication of the sensitive information which was
not to be revealed. Since they did not provide any information to me on
what was sensitive, I don't feel any of the conversations was sensitive,
but they might.

3) I do have a very low level of fear that I will feel repercussions of
several forms. The company named may sue me. Other people may have less
respect for me (as I could be considered a snitch). Other companies may
view me as a trouble maker (the same snitch thing). 

4) I don't feel the need to warn anyone of a company pushing a paper in
front of you to sign. Each of us should be able to recognize this
happening at the time it happens. It is then up to them to do what they
feel is right. It is not my place to tell them what is "correct". 

Can you explain in clear concise language why you feel a company name is
important to this conversation? Which many have stopped reading, BTW...
guess why!



Neil Nelson wrote:
> You ask me why I wanted names.  I can go with (A) and (B) and the
> several other reasons I have been giving.  But however confusing
> I am, it is not that confusing that no one has given an argument
> as to why they are not giving the names of the companies they
> say are not behaving appropriately.  I.e., you may wish me to
> explain my reason for asking and say that it is confusing, but
> still no names have been given and no reason has been given for
> not giving names.  The original topic was one that dealt with not
> disclosing.  Why are we not disclosing names?  Which it would seem
> we must know if we say there is in fact a company behaving poorly?
> 
> Regards,
> 
> Neil Nelson
> 

-- 

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: 25067
Subject: Re: make for design flow (was: Deterministic FPGA routing?)
From: Andreas Doering <doering@iti.mu-luebeck.de>
Date: Fri, 25 Aug 2000 09:14:49 +0200
Links: << >>  << T >>  << A >>
Hal Murray wrote:
> 
> > Please, Altera and Xilinx, never give up the command line interface to
> > your tools.
> 
> I'd like to second that.  Good documentation is important too.
> 
> What I really want is something that cooperates with make.
> Aside from all the options that I can specify on the command
> line, I need to understand the sequence of steps to go through
> and I need to know what files each step produces.
> 
> I consider the Makefile to be a critical part of the documentation.

For larger designs "make" does not fit very well, unless you build 
wrappers around the tools. It is very design specific what is 
considered a severe problem (with the consequence, make should stop) 
and what is ok. Just yesterday someone complaint that certain IOs
were not put into the IOBs. Hence, the number of "IOB FFs" reported 
by make is crucial for this design. The same number will be irrelevant
for 
other designs. 

What I loved to have is a more detailed control over the individual 
actions performed. 
In the same style synopsys dc_shell lets you perform individual steps. 
This would allow to apply different optimization styles and 
optimization goals for design parts, e.g. in map.
Or imagine a floorplanner where you could perform all those 
steps by a script. The situation has been improved, see for instance 
fpga editor. 
But I still miss a lot of output stuff there. 
Something like: 

sort routed nets by selection, 
print the top 20 lines. to a file 
call a perl script 
include script xyz 

or par with something like: 
select all nets which match a given pattern.
deselct those where not all pins are placed. 
Route the remaining. 
mark these routed nets "dont touch" 

and so forth.
If the million gates barrier is crossed, such advanced methods are
needed. 

And when I am already dreaming: 
I would like to have larger hard macros,
they were  limited by  the number of nets. 
(or did that improve in 3.1i)

Andreas

-----------------------------------------------------------------
                        Andreas C. Doering
                        Medizinische Universitaet zu Luebeck
                        Institut fuer Technische Informatik
                        Ratzeburger Allee 160
                        D-23538 Luebeck Germany
		        Tel.: +49 451 500-3741, Fax: -3687
		        Email: doering@iti.mu-luebeck.de
                        Home: http://www.iti.mu-luebeck.de/~doering 
"The fear of the LORD is the beginning of ... science" (Proverbs 1.7)
----------------------------------------------------------------
Article: 25068
Subject: Re: help -- of RAMs, FFs, latches, inverted clocks, and other
From: Ben Franchuk <bfranchuk@jetnet.ab.ca>
Date: Fri, 25 Aug 2000 08:07:50 +0000
Links: << >>  << T >>  << A >>
Jan Gray wrote:

> However, in this case, it is neither obvious, nor documented, whether the
> slice latches are open when clk is high or when clk is low (independent of
> whether said clock is inverted).
> 
I wonder how much sleep the FPGA device engineers lose at 
night from reading how pushed to the limit his designs are.
If he ever decided to form his own company and build FPGA's
his would be a very hot product.
Ben.
-- 
"We do not inherit our time on this planet from our parents...
 We borrow it from our children."
"24 bit CPU's R us" http://www.jetnet.ab.ca/users/bfranchuk/index.html
Article: 25069
Subject: "generate" and instance name indexes in Synopsys
From: Jens Hildebrandt <hil@e-technik.uni-rostock.de>
Date: Fri, 25 Aug 2000 12:24:38 +0200
Links: << >>  << T >>  << A >>
Hello,

I have a problem with the names Synopsys_1999.10 uses for multiple
instances of a component created using the VHDL "generate" construct.
For instance, when using a construct like

for i in 0 to 7 generate
  instance_name: component_name port map (
					...
					  );
end generate;

eight instances of component_name would be created. Synopsys adds a
suffix to the instance_names to get different names for all instances.
Up to now I was used to this suffixes being sequential numbers (in most
cases equal i), but since updating to Synopsys_1999.10 these numbers
seem to have no relation to i but instead choosen according to some
hidden rule known only by Synopsys.
Does anyone out there know how to force Synopsys to use sequential
numbers as suffixes or a VHDL construct to define instance names as a
function of i?

TIA

Jens
Article: 25070
Subject: Re: create a RAM in a Virtex
From: Gerhard Griessnig <grie@sbox.tu-graz.ac.at>
Date: Fri, 25 Aug 2000 12:50:05 +0200
Links: << >>  << T >>  << A >>


Gerhard Griessnig wrote:

I need a RAM with a deep of 480 (impossible with virtex V300 - so i use for my project the half :240) and a width of 200 bits for implementing a switch for a realtime LAN.
The LAN is developed by us and has a special protokol which requiers 200 bits width packages.

Is it  possible to get all 200 bits  into a 200 bit shift register in one Cycle (timing)?

THANKS Gerhard

Vhdlcode ?

> I need to create a RAM in a XILINX-Virtex V300 with the XILINX Foundationtool.
>
> My problem is that my RAM has a width of  200 bits.
>
> Can i use the ONBOARD-RAM (only in Virtex-Series? max width is 16?) without a complex addressing.



Article: 25071
Subject: Re: largest fpga in the industry
From: "S. Ramirez" <sramirez@cfl.rr.com>
Date: Fri, 25 Aug 2000 11:22:38 GMT
Links: << >>  << T >>  << A >>
Ben,
     First of all, I didn't write what's below.  Peter Alfke of Xilinx wrote
that.
     Second, your question "what is the best cost/performance ratio?" is a
good question, but there is still a fringe need for costly chips that do a
lot.  I guarantee you that someone is going to use those chips.  It may not
be their best seller, but it will sell and it will help drive Xilinx's
technology down the road to even bigger chips that cost less per gate.  As
Peter said, die shrinks will ensure that this happens.
-Simon Ramirez, Consultant
 Synchronous Design, Inc.


"Ben Franchuk" <bfranchuk@jetnet.ab.ca> wrote in message
news:39A5D6FC.2D7D3286@jetnet.ab.ca...
> "S. Ramirez" wrote:
> > > It's around 25 mm square, or an inch for you non-metric folks.
> > > Bragging about large chip size always gives me a creepy feeling.
> > > Here we have a bunch of engineers and layout designers who sacrificed
their
> > > lunch, their sleep, and their family life to squeeze the design as
small as
> > > they possibly could do it.
> > > And then somebody brags about how BIG the chip is.  :-(
>
> But the real question is what is the best cost / performance ratio.
> Big chips cost TOO much. Small chips do TOO little. Plus the price
> of Sockets (What you want fix a computer board by replacing a defective
> chip - ha ha ha !) and the PCB complexity and clock speed all are factors.
> Ben.
> --
> "We do not inherit our time on this planet from our parents...
>  We borrow it from our children."
> "24 bit CPU's R us" http://www.jetnet.ab.ca/users/bfranchuk/index.html
>


Article: 25072
Subject: Re: help -- of RAMs, FFs, latches, inverted clocks, and other
From: Ray Andraka <ray@andraka.com>
Date: Fri, 25 Aug 2000 12:13:27 GMT
Links: << >>  << T >>  << A >>
Jan,

For this type of inquiry, I use the FPGA editor to see if something will work in
the architecture before I even start to code it.  If you had done so, it would
have become immediately obvious that the silicon doesn't support what you were
trying to do.  SImilarly, I think that if you look at it, you'll find the F5 and
F6 mux controls are shared with the RAM write strobes, so there's a good shot
you won't have access to them either.  Basically, if you are using the RAM or
SRL16 modes, the registers are only usable to register the RAM output on the
same edge as the ram clock, and the S/R is not available.  THe FF CE is still
available.  This is one of those things I miss fromthe 4K architecture.

Perhaps the SRL16E can be useful to you.  You can get pseudo 2 port access if
the input is not random by shifting data in and then using the address lines to
access the data randomly.

Jan Gray wrote:
> 
> <brian_m_davis@my-deja.com> wrote in message
> news:8o4ng2$8rs$1@nnrp1.deja.com...
> > on 8/6/00, Jan Gray wrote:
> >
> > >I am working on optimized processor cores for Virtex
> > >and I have a strange result, perhaps a bug in the tools.
> > >This problem is with F2.1i SP6.
> >
> > <snip description of latch/write clock polarity problems>
> >
> >   I hadn't used Virtex/Spartan-II CLB latches before;
> > after experimenting with them for a while, I'd say it's
> > definitely a bug.
> >
> > Problem Summary:
> >
> >    The problem occurs in both 3.1i SP2 and 2.1i SP6.
> >
> >    MAP and PAR have their clock polarity packing rules
> >  backwards: when packing latches with clocked memory
> >  elements, they reject the valid combinations and
> >  allow the invalid ones.
> >
> >    In the resulting hardware, the latches have the
> >  polarity that was specified, but the clock sense of
> >  the RAM or SRL16 elements is inverted. ( Verified
> >  both by simulation and in hardware using a XC2S100 ).
> 
> My thanks to Brian for picking up the ball and running with this, and
> verifying in several ways that map/par are wrong here.  It is astonishing
> that this problem was not found, reported, and fixed by 3.1i, but I suppose
> no one is using RAM near latches.  This is a "good thing" -- I wouldn't do
> so either except this was a last-ditch effort to avoid wasting area in my
> designs.
> 
> Brian's legwork confirms there is no way to do what I was hoping to do.
> 
> I went down this path because in XC4000s I made compact, read/write per
> clock register files using single-port select RAM, driving a write address
> and clocking the write on the rising edge, then driving a read address and
> capturing read data in the same CLBs' flip-flops on the falling edge.  Alas
> in Virtex the slice architecture does not permit the flip-flop clock to be
> inverted with respect to the RAM clock.  So I had tried to use positive
> enabled latches instead, and the tools erroneously let me do so, but now
> Brian confirms that the only configuration the hardware supports has the
> latch closed when I need it to be open and vice versa.
> 
> Workarounds: I could...
> 
> * clock the reg file twice as fast, perhaps via a separate 2X clock from a
> DLL, but this constrains the min cycle time of the register file, hence the
> pipeline, to be twice the min cycle time of the select RAMs, e.g. 2xTwc =
> ~12 ns in S2-5 = ~ 80 MHz, not fast enough.
> 
> * move the register file output register flops (that are clocked on the
> clock falling edge) to other CLBs (and invert the clock to those FFs), but
> this use of local interconnect is slower, and this structure makes
> floorplanning more awkward.
> 
> * use dual-port RAMs, but these are half as area efficient at best.
> (Sometimes worse -- for n x 32 reg files from 16x1 dprams, I also need
> output muxes (but perhaps F6MUXs work).)
> 
> * use dual-port block RAMs, but these are slower and are spoken for.
> 
> So I am using dual-port RAMs, and have filed this next to "PAR won't do
> H-muxes" in the "missed opportunities to save area" file.
> 
> Jan Gray
> Gray Research LLC

-- 
-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: 25073
Subject: Re: DLL Properties on Xilinx Virtex/VirtexE
From: Ray Andraka <ray@andraka.com>
Date: Fri, 25 Aug 2000 12:16:40 GMT
Links: << >>  << T >>  << A >>


Markus Michel wrote:
> 
> Hello all,
> 
> The DLL's on Virtex and VirtexE have the three properties
> - DUTY_CYCLE_CORRECTION
> - CLKDV_DIVIDE
> - STARTUP_WAIT.
> There is no problem for simulation in VHDL of the units
> unisim.CLKDLL or unisim.CLKDLLHF; the properties are defined
> here by means of generics.
> 
> Questions:
> 1. How get the properties defined for implementation?
	UCF file entries or attributes on the instances in the source
> 2. Can this be done in the VHDL source code?
	Yes, if the synthesis passes user attributes through to the netlist.  I believe
xilinx has an appnote on-line concerning instantiation of DLLs and setting up
the parameters.  
> 3. Or is this done with the Design Manager?
> 
> Thanks for your immediate help, best regards
> Markus

-- 
-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: 25074
Subject: Re: create a RAM in a Virtex
From: Ray Andraka <ray@andraka.com>
Date: Fri, 25 Aug 2000 12:29:01 GMT
Links: << >>  << T >>  << A >>
No, you won't get 200*480 in block RAM in a V300, but you might be able to use
CLB RAM or SRL16's to make up the deficit.  at 68 bits per CLB, this is quite
reasonable.  If you need speed, the best bet is to use the CLB RAM as a shift
register buffer rather than random access, provided you can come up with a
scheme that works for your design.  You'd need about a third of the array (448
CLBs minimum) to make up the deficit.  If your logic is not too intense, then
you could probably make that work.  If logic an memroy combined is too much,
then you need to go to a bigger device...you can't shove 10 lbs of manure in a 5
lb sack.

As to the getting all the bits into a shift register at once, sure you can.  The
shift register will take up 200 luts though.  You don't mention what your clock
cycle is.  Often, you can use a multiplied clock to take better advantage of the
architecture and thereby shrink the design.

Gerhard Griessnig wrote:
> 
> Gerhard Griessnig wrote:
> 
> I need a RAM with a deep of 480 (impossible with virtex V300 - so i use for my project the half :240) and a width of 200 bits for implementing a switch for a realtime LAN.
> The LAN is developed by us and has a special protokol which requiers 200 bits width packages.
> 
> Is it  possible to get all 200 bits  into a 200 bit shift register in one Cycle (timing)?
> 
> THANKS Gerhard
> 
> Vhdlcode ?
> 
> > I need to create a RAM in a XILINX-Virtex V300 with the XILINX Foundationtool.
> >
> > My problem is that my RAM has a width of  200 bits.
> >
> > Can i use the ONBOARD-RAM (only in Virtex-Series? max width is 16?) without a complex addressing.

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


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