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 41675

Article: 41675
Subject: Re: powerpc in virtex2pro
From: Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com>
Date: Thu, 04 Apr 2002 18:35:27 -0600
Links: << >>  << T >>  << A >>
I have seen a patent issued to Xilinx that describes an FPGA with a
dedicated bus controller.
The bus controller the patent described was a PCI interface.
Peter, is this patent related to what you just said?



Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)



Peter Alfke wrote:
> 
> 
> There is a long list of potential candidates that were rejected ( I was in favor
> of adding a dedicated PCI interface, the the XC4000, which luckily was
> rejected).
>

Article: 41676
Subject: Re: powerpc in virtex2pro
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Thu, 04 Apr 2002 16:39:10 -0800
Links: << >>  << T >>  << A >>
There is no clear relationship between patents and product planning.
Sometimes things get patented, but still don't make it through the product planning
process. A clever idea is one thing, a successful product something else. Sometimes
they come together :-)
I do not know about this particular patent. It is not in my name...
Peter Alfke
======================
Kevin Brace wrote:

> I have seen a patent issued to Xilinx that describes an FPGA with a
> dedicated bus controller.
> The bus controller the patent described was a PCI interface.
> Peter, is this patent related to what you just said?
>
> Kevin Brace (In general, don't respond to me directly, and respond
> within the newsgroup.)
>
> Peter Alfke wrote:
> >
> >
> > There is a long list of potential candidates that were rejected ( I was in favor
> > of adding a dedicated PCI interface, the the XC4000, which luckily was
> > rejected).
> >


Article: 41677
Subject: Re: hand placement
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Fri, 05 Apr 2002 13:19:47 +1200
Links: << >>  << T >>  << A >>
Steve Casselman wrote:
> 
> I took the cost function put it in hardware and ran the database past it
> several times. The cost function accounted for 30% of the placer
> performance. That part of the placer took about 1/3 of a xc4010. From my
> analysis I concluded that ppr could be speed up by 10x and would take about
> 50K gates. This holds to the normal 90/10 rule. Of course Xilinx was moving
> over to par at the time and they concluded that they didn't need the
> speedup. After spending a lot of time with the code I'm convinced that  P&R
> is a sure bet for acceleration. Now with the PPC and Virtex II I'm sure that
> over all speedups of 8-10x would be pretty straight forward. I estimate
> about 2 man years of work and a design with 4-8 gig on board would do it.
> 
> Steve

 If I have this right, you are talking about using a VirtexPRO as an 
engine to route VirtexPRO (et al) ?.

This becomes the silicon equivalent of the 'compiler bootstrap' :-)

Maybe it's also a problem, the 'solution of 4 PPCs' is looking for ? 

Xilinx could sell route-boxes, and it would make a pretty impressive
product demonstrator...

-jg

Article: 41678
Subject: Re: powerpc in virtex2pro
From: Ray Andraka <ray@andraka.com>
Date: Fri, 05 Apr 2002 01:24:13 GMT
Links: << >>  << T >>  << A >>
Well, no it wasn't me this time.  Actually the multipliers can be used as a shifter
but... consider that to build a 16 bit rotator or shifter only requires 64 luts,
and if pipelined to the maximum 4 stages can be clocked at more than twice the
speed of the multiplier.  Even then, the speed of the multiplier assumes that the
multiplier has its input and outputs registered in the adjacent CLBs with no LUTs
between (the multiplier has fairly long setup and clock to out times compared to
the CLBs, so you need to keep the routes to/from the multiplier very short and with
no LUTs).    Adding those registers, you have 16 in, 16 out on top of the registes
and logic for the shift decode (that can actually be done with the BRAM rather than
with CLBs).

In any event, you can see that using the multiplier as a shifter winds up costing
more than half the CLB resources needed to do the same function in the fabric, and
you only get half the speed or less if you are not careful about placement.  The
in-the-fabric version also gives you freedom of placement anywhere on the die
instead of being constrained to the multiplier sites.  The time-hardware product in
this case actually favors the shifter implemented in the fabric even if the
multipliers themselves are free and not counted in the comparison.

Sorry to rain on your parade there, but you know not everyone can see the emperor's
new clothes.

Nicholas Weaver wrote:

> And, as Ray Andraka has pointed out, a multiplier makes a great
> shifter as well.  A variable shift is suprisingly expensive in an FPGA
> fabric: there are a lot of muxes, but it is an operation that is
> suprisingly common.
>
> An 18x18 multiplier can implement an 18 bit variable rotation with
> just 18 LUTs worth of logic to deincode the shift amount, and an
> additional 18 LUTs worth of logic if you want to make it a left
> shift/rotate, an additional 36 LUTs worth if you want to make a
> variable left/right shift.
>

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

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 41679
Subject: Re: hand placement
From: Russell Shaw <rjshaw@iprimus.com.au>
Date: Fri, 05 Apr 2002 01:24:38 GMT
Links: << >>  << T >>  << A >>


Ray Andraka wrote:
> 
> We've heard the "place and route is good enough you don't need to
> do floorplanning unless you are doing the 1% designs from hell" line for as far back
> as I can remember from Xilinx...

From what i can tell, quartus2 doesn't even have
a way of doing manual routing.

Article: 41680
Subject: Re: Monostable multivibrator
From: Ray Andraka <ray@andraka.com>
Date: Fri, 05 Apr 2002 01:30:33 GMT
Links: << >>  << T >>  << A >>


JB wrote:

> I am new come in the FPGA business.
>
> I guess that to implement a monostable multivibrator using a Xilinx FPGA
> should be pretty common.

Not in good FPGA designs.  FPGAs are optimized for SYNCHRONOUS logic, which
means most everything should be clocked by a common clock or two.
Monostable multivibrators in the classic sense are not only aysync logic,
but they are also part analog.  The better solution in FPGAs is to use a
counter triggered by an event and decoded some number of clocks later for
the delayed output.  The faster your master clock, the finer your
resolution.

>
>
> Maybe somebody provide me with a hint or an example?
>
> Thanks

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

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 41681
Subject: Re: hand placement
From: "Kelvin Xu Qijun" <qijun@okigrp.com.sg>
Date: Fri, 5 Apr 2002 09:33:10 +0800
Links: << >>  << T >>  << A >>
Nicholas, pls stop laugh since they have made it possible that you stay on
your job for a while...
I feel the laziness of CAD companies has saved many jobs in IC design
area...:-)




Email: qijun@okigrp.com.sg
"Nicholas Weaver" <nweaver@CSUA.Berkeley.EDU> wrote in message
news:a8i8mh$n57$1@agate.berkeley.edu...
> In article <a8i7t9$c1b$1@newsreader.mailgate.org>,
> Kevin Brace  <ihatespam84kevinbraceusenet@ihatespam84hotmail.com> wrote:
> >        I have seen one Xilinx employee in this newsgroup saying that
> >automatic P&R is getting better, so low level tools like floorplanner or
> >FPGA Editor is getting less important.
>
> Everytime Xilinx/Altera/Tool people say this, I have to laugh.
>
> There is so much low hanging fruit in datapath recognition, which the
> tools fail MISERABLY to recognise.  A simple first order pass, align
> up the datapath, can be such a win.
> --
> Nicholas C. Weaver                                 nweaver@cs.berkeley.edu



Article: 41682
Subject: Re: hand placement
From: Ray Andraka <ray@andraka.com>
Date: Fri, 05 Apr 2002 01:47:50 GMT
Links: << >>  << T >>  << A >>
My point exactly a little later in the post.  (Although I am told there is a real
floorplanner capability in Quartus now...I haven't seen it.  In Maxplus, the floorplanner
was really only useful as a viewer since you couldn't apply your 'floorplan' to a future
iteration.).  I can sort of see Xilinx's point.  A potential customer could point at
ALtera's tools and say why should I buy yours that I need to floorplan when I can buy
ALtera's that doesn't even have a floorplanner (so it must not be needed).

Fact is, there is much more than meets the eye here.  There is a fundamental difference in
the routing structure.  The altera routing structure happens to be less sensitive to
placement, but as a result you don't have the capability of using very short high speed
routes (outside of a LAB that is).  Xilinx has shorter interconnects that permit a higher
top speed in data flow designs, but in order to gain that benefit you need to exercise
more care in the design and layout.  Unfortunately, these types of distinctions seem to be
lost on the marketing folks.

Russell Shaw wrote:

> Ray Andraka wrote:
> >
> > We've heard the "place and route is good enough you don't need to
> > do floorplanning unless you are doing the 1% designs from hell" line for as far back
> > as I can remember from Xilinx...
>
> From what i can tell, quartus2 doesn't even have
> a way of doing manual routing.

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

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 41683
Subject: Re: Schematic Stuff
From: "Kelvin Xu Qijun" <qijun@okigrp.com.sg>
Date: Fri, 5 Apr 2002 09:48:27 +0800
Links: << >>  << T >>  << A >>
Hi Eric:

I have two questions:
1: Does Viewlogic output designs to Xilinx ISE? I am using ISE to synthesize
and program FPGA boards.
2: How much learning does it mean to those engineers who is never willing to
learn new stuff, for example
those above 30 years old?

I tried to introduce to somebody the schematic entry in ISE 4.1 that was not
adopted, I thought it's because
that they are difficult to learn.

Thanks.

"Eric Crabill" <eric.crabill@xilinx.com> wrote in message
news:3CAC97FD.D2749E3C@xilinx.com...
>
> Hi,
>
> What follows below is my personal opinion.
>
> I think Viewdraw by Viewlogic (Innoveda) is the best
> schematic entry tool I have ever used.  I've used the
> Viewdraw 6.1 on Solaris and also Workview Office 7.5
> on WindowsNT.
>
> This tool does have a bit of a learning curve.  After
> using it for a while, though, it now seems natural and
> the keyboard shortcuts and command line really let you
> fly through your work...
>
> Hope that helps,
> Eric
>
> Christopher Saunter wrote:
> >
> > Greetings All,
> >
> > I have always found it more natural to work with schematics than an HDL
> > (although learnign vhdl is proving very usefull in some areas...)
> >
> > I have used the Aldec schematic capture program from Xilinx Foundation
3/4
> > and ECS from Webpack.
> >
> > Thus far, I am somewhat underwhelmed by these tools - I have always felt
> > that a good tool (eg text editor, ide etc.) should allow you to work
about
> > as fast as you can enter data, and this is just not the case with the
> > schematic capture tools I have used.
> >
> > So my question is:  Does anyone know of a powerfull, flexible schematic
> > editor with decent (preferably configurable) key bindings, rock like
> > stability, a nice user interface, highly intuitive, that is fast and a
> > pleasure to use etc?
> >
> > One that uses an HDL description of each schematic behind the scenes ECS
> > style is probably a plus.
> >
> > Or should I just be gratefull I'm not directly entering netlists... ;-)
> >
> > Cheers,
> > Chris Saunter



Article: 41684
Subject: Re: Schematic Stuff
From: Eric Crabill <eric.crabill@xilinx.com>
Date: Thu, 04 Apr 2002 17:57:14 -0800
Links: << >>  << T >>  << A >>

Hi,

> 1: Does Viewlogic output designs to Xilinx ISE?
> I am using ISE to synthesize and program FPGA boards.

You can use Viewdraw to generate EDIF netlists.  With
an EDIF netlist, you should be able to use the ISE
software to place and route your design.

However, to use Viewdraw properly, you also need to
have access to the Viewdraw libraries for the FPGA
primitives.  I don't know if ISE comes with these;
I think the libraries come with the "Alliance" version
of the ISE tools.  If you have the "Foundation" version
you may not have the libraries.

If you do schematic entry, typically you do not need
to synthesize anything.  However, you do need to place
and route the design in the target FPGA device.

> 2: How much learning does it mean to those engineers
> who is never willing to learn new stuff, for example
> those above 30 years old?

I find this a setup for some very good jokes...

I don't see where age has anything to do with it.
Anyone can have a bad attitiude.  Or a good attitude,
and put the required effort into learning something
new.

Eric

Article: 41685
Subject: Re: hand placement
From: Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com>
Date: Thu, 04 Apr 2002 20:15:11 -0600
Links: << >>  << T >>  << A >>


Ray Andraka wrote:
> 
> We've heard the "place and route is good enough you don't need to do 
> floorplanning unless you are doing the 1% designs from hell" line for as far back
> as I can remember from Xilinx.


       Ray, I thought it was, "5% designs from hell."

http://www.eetimes.com/story/OEG20000211S0011



Although my PCI IP core didn't used to meet Tsu < 7ns without
floorplanning it in Spartan-II XC2S150-5 a few months ago, with
improvements in the logic design, I got it to a point where I only have
to route it once at the highest routing effort to meet the setup time
requirement.
So, I guess my design is no longer a "5% designs from hell," but I have
to admit for a 66MHz PCI, Floorplanning is a must. (I already figured
out how that secret PCILOGIC thing works, and I only now need to know
how Bitgen's /Gclkdel option works to insert more delay on the global
clock buffer . . . )




> Fact is, floorplanning seems to be getting larger gains, 
> not smaller, with the new devices.  I typically see 50-70%
> performance improvement over a automatic placement.
> 


        I guess Spartan-II is not really a new device, but in my case, I
have seen 20% to 30% improvement in setup time when I manually
floorplanned timing critical unregistered input control signals of PCI.
(i.e., FRAME#, IRDY#, DEVSEL#, etc.)




> Routing multiple times without running placement is not going get much in the way of performance gains.  The router does a pretty decent job if the
> placement is good, and can't do much to salvage a poor placement.
> 


        The idea of routing the design multiple times came from an
article I read in Xcell magazine a while ago where a guy from Lucent
said he sometimes routes the design over the weekend multiple times, and
picks the one that's useful.
I believe it was for a network router or something like that which
utilized an XCV800 and an XCV150.
So, I tried it, and once I ran it for about 10 hours while I was
sleeping, and what I saw was that the improvement in timing score hit a
plateau after 10 to 15 iterations.
After that disappointment, I think that's when I started use
Floorplanner to look at how the design was getting mapped, and I quickly
realized why the timings weren't improving at all.
It was because the relevant LUTs were getting spread all over the place
that no matter how many times I routed the design, things weren't going
to get better.





> Xilinx, as a company, promotes not using the floorplanner probably 
> to avoid a feeling that the devices are more difficult to design 
> in (which is not
> the case, in fact the ability to improve performance and density
> through floorplanning is a big plus).


        My conspiracy theory of Xilinx attitude will be that the more
waste there is in a design because manual floorplanning wasn't done, the
users will have to use larger and faster speed grades which costs more,
and that will certainly make Xilinx richer.
I used to think a Spartan-II-5 was too slow for 33MHz PCI, and preferred
if Insight Electronics put in a faster speed grade -6 part for
Spartan-II PCI card even though Xilinx can get it right with speed grade
-5.
It turns out, my logic design was bad, and I can really easily meet Tsu
< 7ns now with only automatic P&R.




>  Floorplanning has always been the closet case,
> and from the looks of it will continue to be.  Therefore you get poor documentation, lots of bugs, and very low priority on getting the bugs fixed
> compared with the rest of the software package.


        I posted a question about a floorplanner tutorial in this
newsgroup several months ago, but no one posted a reply for that
posting.
It turns out, no such thing exists, so I just decided to just place LUTs
relevant to where I felt like it should belong to, and I saw huge
improvement in setup time.




> Until floorplanning becomes a mainstream design event, I doubt it
> will ever be anything more than the
> poor cousin no one will admit to having.


        I personally doubt that floorplanning will ever become a
mainstream tool, but it still has to exist because the automatic P&R
tool is soooo bad.
However, each time I click on a LUT of a path violating timing
requirements in Timing Analyzer, the floorplanner suddenly zooms in, and
each time I will have to manually zoom out to get a view of where the
thing is located on the chip.
Is there a way to disable this?
It is really annoying, and killing my productivity.




>   Unfortunately, the mainstream doesn't use it because a) they 
> are told they don't need it*, that it is only
> there for the FAEs to get you out of trouble in special cases,


        Another conspiracy theory I came up with will be that more the
users are discouraged from doing manual floorplanning, more likely they
will rely on Xilinx for engineering services when something goes wrong
(i.e., The design doesn't meet timings or doesn't fit inside a specific
chip.), but I guess that creates more opportunity (?) for consultants to
make some bucks, too.
However, this "It's an FAE's tool" mentality seems to create a myth that
only Xilinx or really experienced users can use it, and that myth seems
to be similar to a PCILOGIC myth people talk about when a question comes
up about  "The special IRDY and TRDY pin for PCI in Virtex."
People always say only Xilinx knows how PCILOGIC works, but should I
shatter the PCILOGIC myth for once and for all by posting a sample code,
and some explanation on how to instantiate it and actually use it?




> b) They don't know the benefits because those are not told to 
> them and the tool is not
> easy to learn without doing it alot (and living with numerous bugs), > and


        My conspiracy theory seems to hold that the dumber the users,
the more they will have to pay for chips, tools, and services.




> c) Even if someone convinces them to use it, the documentation 
> is next to
> useless as far as learning how to floorplan.


        I think Xilinx has to release a tutorial on how to use a
floorplanner, and I will also like to see more information on what the
routing is like inside a Virtex architecture chip (Altera documentation
is slightly better since it has more figures about the routing structure
in their datasheets.)
Although, I suppose if I had access to FPGA Editor, I won't complain
about it . . .




>  Part of the problem is that floorplanning is sort of like 
> putting together a puzzle with many acceptable
> solutions.  Some people have the knack for it, some don't and if you don't you will probably not inherit it ever.
> 
> 
> --


        At least, I am glad that Xilinx didn't remove Floorplanner from
ISE WebPACK.
Without Floorplanner, the design wouldn't have met the timings a couple
of months ago.
However, I don't appreciate the fact that FPGA Editor doesn't come with
ISE WebPACK.



Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)

Article: 41686
Subject: Re: hand placement
From: Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com>
Date: Thu, 04 Apr 2002 21:03:13 -0600
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
> 
> My point exactly a little later in the post.  (Although I am told there is a real
> floorplanner capability in Quartus now...I haven't seen it.
>  In Maxplus, the floorplanner
> was really only useful as a viewer since you couldn't apply your 'floorplan' to a future
> iteration.).


        Quartus II got the floorplanner, but I think it is broken unless
I am doing something wrong.
For example, recently, I was able to assign several (two FFs) to a
single LE.
Of course, that's a no-no considering that only one FF exists for one
LE.
But the floorplanner doesn't stop me from doing that, and only at
fitting stage (P&R stage) the tool will complain.
That doesn't happen in Xilinx Floorplanner because you cannot place a FF
to a location where already a FF was assigned to.
Another problem which I don't know what to do is when I assign multiple
FFs (up to four) to a LAB (not talking a single LE here, a single LAB),
I have seen fitter failing to place my design.
If I cannot constrain certain timing critical FFs to a certain LAB,
that's really bad because I am at the mercy of the horrible automatic
fitter.




>  I can sort of see Xilinx's point.  A potential customer could point
> at
> ALtera's tools and say why should I buy yours that I need to floorplan when I can buy
> ALtera's that doesn't even have a floorplanner (so it must not be needed).
> 


        I just hate marketers who bend the truth.
Not having a floorplanner can really make life miserable when the
automatic P&R tool does a poor job.
        Because my PCI IP core is written in Verilog without using any
vendor specific (device specific or synthesis tool specific) features, I
often target FLEX10KE in Quartus II 2.0 Web Edition to see how it does.
I am an Altera nay-sayer in general from my bad experiences with their
tools (Altera tools seem to be less reliable than Xilinx tools. Sure,
Xilinx tools have their own bugs, but I haven't seen too many of them,
but I have seen Quartus II 2.0 WE's router crash several times when
routing my design.), and to make the matter worse, Altera's P&R tool's
placement seems much worse than Xilinx's P&R tool. (Pretty slow, too.)
One of the reason I think the placement is bad is because of lack of
multiple IOE FFs, and not letting active low output FFs reside inside an
IOE (That seems to have been fixed in APEX20KE, but I am still targeting
FLEX10KE here.), so output and OE (Output Enable) FFs can get placed
anywhere in the chip, and the P&R tool seems to place it at really bad
locations (Locations really far away from the pin.) compared to Xilinx
tools which tries to place the thing close to the pin.
Of course, Spartan-II's IOBs are much better than FLEX10KE's, so I
always use IOB FFs, and that probably makes the timings more
predictable.
Another weakness of FLEX10KE in PCI I think is the fact that FLEX10KE
IOE FF doesn't have an asynchronous preset input, almost all of the PCI
control signals are active low (i.e., FRAME#, IRDY#, DEVSEL#, etc.), and
that makes my life very hard when I target FLEX10KE.
Why do I care about FLEX10KE/ACEX1K?
That's because that's the last Altera chip that officially support 5V
PCI, and most desktops still use 5V PCI.




> Fact is, there is much more than meets the eye here.  There is a fundamental difference in
> the routing structure.  The altera routing structure happens to be less sensitive to
> placement, but as a result you don't have the capability of using very short high speed
> routes (outside of a LAB that is).  Xilinx has shorter interconnects that permit a higher
> top speed in data flow designs, but in order to gain that benefit you need to exercise
> more care in the design and layout.  Unfortunately, these types of distinctions seem to be
> lost on the marketing folks.
> 



        Ray, I thought you said in the past that Altera's chips are good
in random logic, but from my experience dealing with Spartan-II and
FLEX10KE, Spartan-II seems better even in random logic and setup time.
Altera's device seems to be better in fmax (Okay, maybe that's random
logic.), but for 33MHz PCI, frequency above 33MHz is not too important.
I believe Altera claims in their datasheets that their LUT-based PLDs
(Please, just call it FPGAs.) have more predictable routing delays than
FPGAs (Probably means Xilinx.), but I find Spartan-II's routing delays
far more predictable.
With the stuff I wrote, I am sure I will get firestorm of criticism from
die-hard Altera fans now (I have gotten an unprofessional personal
attack recently.), but I stand behind what I said here. (Unless I
misunderstood something.)




Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)

Article: 41687
Subject: Re: hand placement
From: Phil Hays <SpamPostmaster@attbi.com>
Date: Fri, 05 Apr 2002 03:10:43 GMT
Links: << >>  << T >>  << A >>
Jimmy Zhang wrote:

> Just keep hearing about this hand placement thing, don't know how it
> is done in reality. Does someone actually use their hands to do the
> placement as opposed to CAD based P&R. Any hints?

The first way I learned to do this was with a paper diagram of the
target chip, writing the constraints with a text editor, and coloring on
the paper to indicate what had been put where.  I didn't do the best of
jobs (had an register reversed, with the msb where the lsb should be),
but it was still ~30% faster resulting clock speed than the automatic
placement.  Made place and route times drop nicely as well.  It was even
better than that once I got the twist removed.  But this is as close to
"by hand" as I can picture.


The floorplanner that Xilinx provides is just a nicely automated way of
doing the same sort of puzzle.  Do the data path(s) first, fit things
together in a "logical" fashion, and for the first one floor plan at
least plan on spending some time fiddling.  Some people seem to get this
skill right away, and some take longer.


A slightly "higher level" way of gaining much of the benefit from
floorplanning with potentially rather less effort is to use a "physical
design" tool.  Synplicity had the first ("Amplify") aimed at FPGA design
(and I'm not sure if Mentor, Synopsys or anyone else have anything in
this space yet), however there were physical design tools for ASIC
design long before Amplify.  These work by putting large chunks of the
design into subsections of the target chip.


Synopsys's ASIC physical design tool set:

http://www.synopsys.com/products/phy_syn/phy_syn.html


Amplify is at:

http://www.synplicity.com/products/amplify.html


-- 
Phil Hays

Article: 41688
Subject: Re: hand placement
From: nweaver@CSUA.Berkeley.EDU (Nicholas Weaver)
Date: Fri, 5 Apr 2002 03:13:21 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <3CACEF37.DCA68151@andraka.com>,
Ray Andraka  <ray@andraka.com> wrote:
>We've heard the "place and route is good enough you don't need to do
>floorplanning unless you are doing the 1% designs from hell" line for
>as far back as I can remember from Xilinx.  Fact is, floorplanning
>seems to be getting larger gains, not smaller, with the new devices.
>I typically see 50-70% performance improvement over a automatic
>placement.

I actually assert that a lot of the problem is right in the synthesis,
not in the P&R: There has been a lot of work which has been done on
work which, given a datapath, constructs an orderly layout.  Yet none
of this seems to have found its way into the commercial synthesis
toolflows.  So much informtion is thrown away.

>Routing multiple times without running placement is not going get
>much in the way of performance gains.  The router does a pretty
>decent job if the placement is good, and can't do much to salvage a
>poor placement.

This is especially true when you consider just how rich the modern
FPGA interconnects are:  Compare the number of wires/LUT in an XC4000
with a 4000XL with a Virtex.

-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 41689
Subject: Re: hand placement
From: Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com>
Date: Thu, 04 Apr 2002 21:13:24 -0600
Links: << >>  << T >>  << A >>
Quartus II 2.0 Web Edition has a floorplanner, although I think it has
more problems than Xilinx's one. (I am not saying Xilinx's floorplanner
is perfect. I just think Altera's one has more problems. Refer to the
reply I made to Ray Andraka.)
To open QII floorplanner, click Processing -> Open Current Assignments
Floorplan.
You should open the P&Red current design too (Processing -> Open Last
Compilation Floorplan), and drag and drop the currently placed LEs to
the new floorplan.
That's all you have to do, and things seem to get constrained to certain
locations, but I have seen routing fail during Fitting several times, so
it is not very reliable.
When I say fail, what I mean is Fitter displaying error messages during
Fitting.



Kevin Brace (In general, don't respond to me directly, and respond 
within the newsgroup.)



Russell Shaw wrote:
> 
>
> 
> From what i can tell, quartus2 doesn't even have
> a way of doing manual routing.

Article: 41690
Subject: Re: hand placement
From: Ray Andraka <ray@andraka.com>
Date: Fri, 05 Apr 2002 04:58:05 GMT
Links: << >>  << T >>  << A >>


Kevin Brace wrote:

>        Ray, I thought it was, "5% designs from hell."

What's a few percent between friends ;-)  Xilinx used to call it the 5% designs from hell, but at the current volume that is still a significant number
of designs, so I took the liberty of toning it down to reflect the prevailing attitude toward floorplanning.  That article underlines the fact that
floorplanning has always been the unwanted baby.  The floorplanner has suffered in every major release since XACT6, and the new one in 4.2 is no
exception (try placing an RPM in virtexE using the floorplanner in 4.2).

>
>
> http://www.eetimes.com/story/OEG20000211S0011
>
>
> So, I guess my design is no longer a "5% designs from hell," but I have
> to admit for a 66MHz PCI, Floorplanning is a must. (I already figured
> out how that secret PCILOGIC thing works, and I only now need to know
> how Bitgen's /Gclkdel option works to insert more delay on the global
> clock buffer . . . )

Fact is lots of folks are having a hard time making VIrtexE and VIrtexII designs run at 50 MHz, as evidenced by many posts on this group.  A combination
of floorplanning and good pipelined synchronous design practices make designs at 3-4 times that clock rate quite doable in the same parts.  Our DSP
designs typically are running at between 160 and 180 MHz in VirtexE-6 parts, in fact I have one on the bench right now with a pair of 2000e-6's running
at 160 MHz...that one has pentium heatsinks with fans on the FPGAs.  The point is these designs are very doable with floorplanning, will meet timing
every time through the tools with margin, and route within an hour or two.  Without floorplanning, PAR gives up after about a day and a half, and
automatic placement of some of the partitions small enough to fit after automatic PAR are limited to around 100 MHz.

Some of the floorplanning gains are a function of the design.  Our designs are DSP, so they naturally include data path with lots of arithmetic.  That is
precisely what PAR does so lousy a job at.  In order to get the best speed out of the carry chains,you need to precede the carry chain with a reigster
located in an adjacent slice and limit fanouts.  The PAR seems to go out of its way to avoid putting the driving register next to the carry chain, and it
does an exceptionally poor job at lining up data paths.  This is low hanging fruit that gives big gains, which is why we see the gains we do with
floorplanning.

>
> > Fact is, floorplanning seems to be getting larger gains,
> > not smaller, with the new devices.  I typically see 50-70%
> > performance improvement over a automatic placement.
> >

I'm willing to bet he was running multipass PLACE and route.  The multipass placement often times will find a better placement.  It is not an incremental
improvement, rather it is just doing the placement several times with different cost tables.  Usually one or two cost tables will do better than others
for a particular design.  If you don't get a good layout in the first 5 or 6 tables, you are not likely to get one at all.


>         The idea of routing the design multiple times came from an
> article I read in Xcell magazine a while ago where a guy from Lucent
> said he sometimes routes the design over the weekend multiple times, and
> picks the one that's useful.  Yada yada yada...

No conspiracy that I can see.  Believe it or not, it is in their best interest to get you n a smaller device too...why do you think the marketing gate
numbers are the way they are (BTW, the equivalent gate count that comes out of the tools is typically a little more than double the marketing gate count
in our designs, which is an indication of the density we are getting by doing floorplanning).  There is not much worse than fixing someone else's design
that isn't meeting timing.  The worse the design, the more defensive the designer/manager responsible for it.  I can't imagine a company purposely making
this happen to create or protect work. Yikes.


>
>         My conspiracy theory of Xilinx attitude will be that the more
> waste there is in a design because manual floorplanning wasn't done, the
> users will have to use larger and faster speed grades which costs more,
> and that will certainly make Xilinx richer.

and later:
       Another conspiracy theory I came up with will be that more the
users are discouraged from doing manual floorplanning, more likely they
will rely on Xilinx for engineering services when something goes wrong
(i.e., The design doesn't meet timings or doesn't fit inside a specific
chip.), but I guess that creates more opportunity (?) for consultants to
make some bucks, too.

>
> >   Unfortunately, the mainstream doesn't use it because a) they
> > are told they don't need it*, that it is only
> > there for the FAEs to get you out of trouble in special cases,

The *, which I forgot to add the foot note was supposed to be a comment that the Xilinx design courses, specifically the one by Avnet, come right out and
say (paraphrased) don't floorplan the design.  It is beyond the scope of the class, and is not necessary except in extenuating circumstances in which
case your FAE should be involved.  --A travesty if you ask me.

>         I think Xilinx has to release a tutorial on how to use a
> floorplanner, and I will also like to see more information on what the
> routing is like inside a Virtex architecture chip (Altera documentation
> is slightly better since it has more figures about the routing structure
> in their datasheets.)
> Although, I suppose if I had access to FPGA Editor, I won't complain
> about it . . .

Problem is, I don't think there is anybody there at Xilinx that has done much floorplanning in real designs.  As I alluded earlier, it really is more an
art than an science at this point.  In my experience, some people are naturals at it, some just can't seem to do it no matter how much coaching they
get.  It is one thing to show you how to work the tool, quite another to explain how to come up with a good floorplan.  For those who get the knack, it
is pretty much sufficient to just say "keep the routes as short and as rectangular as possible. Place the logic to meet that goal".  You can pretty much
tell who wil get it and who won't in the first 5 minutes of showing them the tool.

The xilinx has fairly complete information not only in the tools but in the data books, enough to know what routing resources you have and the connection
pattern.  Altera, at least last time I checked, leaves you in the dark as to the routing connectivity.  With the 10K, doing hand placement could make
your design worse because there is *no* information available as to the connection pattern of the LABs on the row (only a limited set of row routes goes
to any particular lab. If you put logic in two LABs in one row, without that information, your route may have to go through a 3rd LAB to make the
connection).  Fortunately for Altera, the performance is not as sensitive to layout because the delay is the same to any connected LAB in the row, so
floorplanning there is not as important.  I think for the newer devices, starting with the 20K that have direct connects to adjacent LABs,however,
floorplanning becomes a lot more important for a data-flow design.  In those cases, it would be nice to have the detail on the row route connection
matrix.

>
>
> >  Part of the problem is that floorplanning is sort of like
> > putting together a puzzle with many acceptable
> > solutions.  Some people have the knack for it, some don't and if you don't you will probably not inherit it ever.
> >
> >
> > --
>

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

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 41691
Subject: Re: hand placement
From: Ray Andraka <ray@andraka.com>
Date: Fri, 05 Apr 2002 05:04:30 GMT
Links: << >>  << T >>  << A >>


Nicholas Weaver wrote:

> In article <3CACEF37.DCA68151@andraka.com>,
> Ray Andraka  <ray@andraka.com> wrote:
> >We've heard the "place and route is good enough you don't need to do
> >floorplanning unless you are doing the 1% designs from hell" line for
> >as far back as I can remember from Xilinx.  Fact is, floorplanning
> >seems to be getting larger gains, not smaller, with the new devices.
> >I typically see 50-70% performance improvement over a automatic
> >placement.
>
> I actually assert that a lot of the problem is right in the synthesis,
> not in the P&R: There has been a lot of work which has been done on
> work which, given a datapath, constructs an orderly layout.  Yet none
> of this seems to have found its way into the commercial synthesis
> toolflows.  So much informtion is thrown away.

I don't buy this.  The information is there in the form of the netlist. The
fact that we get the gains we do out of floorplanning indicates that the
synthesis is doing fine.  Perhaps you mean the synthesis needs to infer
placement and add the placement info to the primitives?

>
>
> >Routing multiple times without running placement is not going get
> >much in the way of performance gains.  The router does a pretty
> >decent job if the placement is good, and can't do much to salvage a
> >poor placement.
>
> This is especially true when you consider just how rich the modern
> FPGA interconnects are:  Compare the number of wires/LUT in an XC4000
> with a 4000XL with a Virtex.

I think more the inverse.  The new parts have enough routing resources that
even a poor placement will route.  The older 4K devices would route well, and
with consistent results if the placement was good.  It was there I first
learned the importance of floorplanning.  The reason the floorplanning seems
to be getting bigger gains in the new devices is mostly due to the size of the
device giving the automatic placement more placement options with which to
hang itself.

>
>
> --
> Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

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

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 41692
Subject: Re: hand placement
From: Ray Andraka <ray@andraka.com>
Date: Fri, 05 Apr 2002 05:09:24 GMT
Links: << >>  << T >>  << A >>
Frankly, I don't see the cost justified by the marginal added value with
amplify.  You can do almost* everything it does with the area constraints in
the floorplanner, plus with the floorplanner you can lock down some and area
constrain other logic.

*The one thing it does buy you is to take into consideration the layout
while doing the synthesis.

Like you mention, there was a time when we did floorplanning with graph
paper.  The GUI makes it easier, but I still use the graph paper method for
doing placement in the source.


Phil Hays wrote:

> Jimmy Zhang wrote:
>
> > Just keep hearing about this hand placement thing, don't know how it
> > is done in reality. Does someone actually use their hands to do the
> > placement as opposed to CAD based P&R. Any hints?
>
> The first way I learned to do this was with a paper diagram of the
> target chip, writing the constraints with a text editor, and coloring on
> the paper to indicate what had been put where.  I didn't do the best of
> jobs (had an register reversed, with the msb where the lsb should be),
> but it was still ~30% faster resulting clock speed than the automatic
> placement.  Made place and route times drop nicely as well.  It was even
> better than that once I got the twist removed.  But this is as close to
> "by hand" as I can picture.
>
> The floorplanner that Xilinx provides is just a nicely automated way of
> doing the same sort of puzzle.  Do the data path(s) first, fit things
> together in a "logical" fashion, and for the first one floor plan at
> least plan on spending some time fiddling.  Some people seem to get this
> skill right away, and some take longer.
>
> A slightly "higher level" way of gaining much of the benefit from
> floorplanning with potentially rather less effort is to use a "physical
> design" tool.  Synplicity had the first ("Amplify") aimed at FPGA design
> (and I'm not sure if Mentor, Synopsys or anyone else have anything in
> this space yet), however there were physical design tools for ASIC
> design long before Amplify.  These work by putting large chunks of the
> design into subsections of the target chip.
>
> Synopsys's ASIC physical design tool set:
>
> http://www.synopsys.com/products/phy_syn/phy_syn.html
>
> Amplify is at:
>
> http://www.synplicity.com/products/amplify.html
>
> --
> Phil Hays

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

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 41693
Subject: Re: Schematic Stuff
From: Ray Andraka <ray@andraka.com>
Date: Fri, 05 Apr 2002 05:17:40 GMT
Links: << >>  << T >>  << A >>


Kelvin Xu Qijun wrote:

> Hi Eric:
>
> I have two questions:
> 1: Does Viewlogic output designs to Xilinx ISE? I am using ISE to synthesize
> and program FPGA boards.

Viewlogic output is edif netlists, which is the same as the third party HDL
synthesizers such as Synplicity.

>
> 2: How much learning does it mean to those engineers who is never willing to
> learn new stuff, for example
> those above 30 years old?

Those engineers aren't going to last long anyway.  If they aren't willing to
learn they can't hope to keep up with technology.  Put them away in the closet
and find someone who will breath some life into your organization.  What a
dreary way to live!

>
>
> I tried to introduce to somebody the schematic entry in ISE 4.1 that was not
> adopted, I thought it's because
> that they are difficult to learn.

More likely because they didn't want to learn at all or  because the schematic
tool there is clumsy, and most places have adopted an HDL flow by now.  If you
are serious about schematics, look at the Innoveda (formerly viewlogic) tools.


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

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 41694
Subject: Re: hand placement
From: nweaver@CSUA.Berkeley.EDU (Nicholas Weaver)
Date: Fri, 5 Apr 2002 05:31:31 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <3CAD3083.D2EA0B0C@andraka.com>,
Ray Andraka  <ray@andraka.com> wrote:
>> I actually assert that a lot of the problem is right in the synthesis,
>> not in the P&R: There has been a lot of work which has been done on
>> work which, given a datapath, constructs an orderly layout.  Yet none
>> of this seems to have found its way into the commercial synthesis
>> toolflows.  So much informtion is thrown away.
>
>I don't buy this.  The information is there in the form of the netlist. The
>fact that we get the gains we do out of floorplanning indicates that the
>synthesis is doing fine.  Perhaps you mean the synthesis needs to infer
>placement and add the placement info to the primitives?

That there is convenient structure which the synthesis tool can easily
exploit, as the high level information is there, while the P&R tool
would have to infer and recover.  

It is much the same way where, yes, you can do all the compiler
optimizations at the assembly level, but it is MUCH more
straightforward to do alot of it earler in the process, in the
intermediate form.

>> This is especially true when you consider just how rich the modern
>> FPGA interconnects are:  Compare the number of wires/LUT in an XC4000
>> with a 4000XL with a Virtex.
>
>I think more the inverse.  The new parts have enough routing resources that
>even a poor placement will route.

I think we are trying to say the same thing:  Interconnects are much
richer than they used to be, so the router has more freedom and an
easier time of things.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 41695
Subject: Re: hand placement
From: "Jimmy Zhang" <zhengyu@attbi.com>
Date: Fri, 05 Apr 2002 05:42:17 GMT
Links: << >>  << T >>  << A >>
Well, since I know Nick personally, I can say for sure that Nick doesn't
have to worry about jobs simply because he is on the other side of this
whole
job thing.
--
-----------------------------------------------------
Click here for Free Video!!
http://www.gohip.com/freevideo/

"Kelvin Xu Qijun" <qijun@okigrp.com.sg> wrote in message
news:3cacff43@news.starhub.net.sg...
> Nicholas, pls stop laugh since they have made it possible that you stay on
> your job for a while...
> I feel the laziness of CAD companies has saved many jobs in IC design
> area...:-)
>
>
>
>
> Email: qijun@okigrp.com.sg
> "Nicholas Weaver" <nweaver@CSUA.Berkeley.EDU> wrote in message
> news:a8i8mh$n57$1@agate.berkeley.edu...
> > In article <a8i7t9$c1b$1@newsreader.mailgate.org>,
> > Kevin Brace  <ihatespam84kevinbraceusenet@ihatespam84hotmail.com> wrote:
> > >        I have seen one Xilinx employee in this newsgroup saying that
> > >automatic P&R is getting better, so low level tools like floorplanner
or
> > >FPGA Editor is getting less important.
> >
> > Everytime Xilinx/Altera/Tool people say this, I have to laugh.
> >
> > There is so much low hanging fruit in datapath recognition, which the
> > tools fail MISERABLY to recognise.  A simple first order pass, align
> > up the datapath, can be such a win.
> > --
> > Nicholas C. Weaver
nweaver@cs.berkeley.edu
>
>



Article: 41696
Subject: Re: hand placement
From: Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com>
Date: Thu, 04 Apr 2002 23:59:12 -0600
Links: << >>  << T >>  << A >>


Ray Andraka wrote:
> 
> 
> I'm willing to bet he was running multipass PLACE and route. 
>  The multipass placement often times will find a better placement.
>  It is not an incremental improvement, rather it is just doing the placement
> several times with different cost tables.  Usually one or two cost tables will 
> do better than others
> for a particular design.  If you don't get a good layout in the first 5 or 6 tables, you are not likely to get one at all.
> 


        Yes, in that article, I think Lucent used multi-pass P&R. (It is
coming back to me.)



> 
> The *, which I forgot to add the foot note was supposed to be a comment that the Xilinx design courses, specifically the one by Avnet, come right out and
> say (paraphrased) don't floorplan the design.  It is beyond the scope of the class, and is not necessary except in extenuating circumstances in which
> case your FAE should be involved.  --A travesty if you ask me.
> 


         Sounds to me Avnet is recommending ordinary users not to use
the Floorplanner to get more consulting work.



> 
> Problem is, I don't think there is anybody there at Xilinx that has done 
> much floorplanning in real designs.


        Didn't Xilinx have to resort to Floorplanner/FPGA Editor to get
Virtex/Spartan-II-6 to meet 66MHz PCI's Tsu < 3ns?
In practice, their design should have a little more time than 3ns
because of a global clock buffer delay (I am not 100% sure if it is safe
to assume global clock buffer delay is going to be there.) which is
about 1.5ns (in Spartan-II XC2S150-6).
I personally doubt from my own experience that they can handle
unregistered signal paths (a signal coming in from a pin, going through
several levels of 4-input LUT, and eventually reaching IOB FFs.) in only
4.5ns, and they do admit that the user has to add additional delay on
the global clock buffer in Bitgen.
It is called a /Gclkdel option, but it is a guard secret, and I have no
idea how it works.



Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)

Article: 41697
Subject: again this hand placement thing
From: "Jimmy Zhang" <zhengyu@attbi.com>
Date: Fri, 05 Apr 2002 06:00:56 GMT
Links: << >>  << T >>  << A >>
Well, I think I can say hand placement certainly make the design run faster,
what about the resource utilization? If my dirty pair of hands scatter the
blocks
all over the real estate, does that mean I am wasting LUTs?

--
-----------------------------------------------------
Click here for Free Video!!
http://www.gohip.com/freevideo/




Article: 41698
Subject: Re: Marquis of Queensbury Rules
From: Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com>
Date: Fri, 05 Apr 2002 00:50:30 -0600
Links: << >>  << T >>  << A >>


Nial Stewart wrote:
> 
> 
> Kevin, that's rubbish (unless you were getting private emails we don't
> know about).
> 

        No, I haven't received any hateful E-mail like that yet, but I
will consider this posting a personal attack.

http://groups.google.com/groups?hl=en&selm=ee759aa.4%40WebX.sUN8CHnE



        Being called a "troll" by a likely Altera employee isn't nice
either.

http://groups.google.com/groups?hl=en&selm=6zeh8.12912%24Or3.1429369%40typhoon.mn.ipsvc.net


       Especially, in the above posting, all I wanted to say was, is a
fast fit option of Quartus II 2.0 a big deal considering that an option
to route the design faster with some performance penalty existed in
Xilinx tools I believe for years?
However, the answer I got was I am a troll, but the guy who wrote that
doesn't even mention that his paycheck comes from Altera.
At least the Xilinx guys who post at this newsgroup say they work for
Xilinx, so I know where their opinions are coming from. (Yes, there are
biased.)




> A few people, myself included, queried your assesment of Altera's
> free tools compared with Xilinx tools. Disagreeing and argueing a
> point isn't the same as a personal attack. I don't even know you.
> 


         You criticism, although I don't agree with it, was a legitimate
one, and I don't mind that, but some angry die-hard Altera fan calling
me "Could it be that you have a big mouth but not the brains to be
successful enough to spend some money on the right tools?", is a
personal attack.
If I go back to what I said a month ago, most free tools distributed by
Altera seems to have more stability problems compared to free tools
offered by Xilinx, and my negative comments about Altera tools come from
actually using those free tools.
You brought up people having problems with Xilinx's MicroBlaze, but I
don't believe I ever said Xilinx tools were perfect, and I don't use
MicroBlaze in my design.
All I said was, Xilinx's free tools were more generous (Especially, the
free ModelSim-XE Starter.) and has less stability problems compared to
free tools distributed by Altera, but I never said Xilinx's tools were
perfect.
Yes, I have seen some small problems in Xilinx tools, but overall
quality seems to be better than Altera's.




> > Not everyone is professional in this newsgroup.
> 
> Not everyone's got a very thick skin :-).
> 
> I for one recognise your contribution to the newsgroup, especially
> with respect to PCI core implementations, I just didn't agree
> with what I considered to an unbalanced opinion.
> 
> Nial.


        I believe what I said were balanced, and even you don't think it
was balanced, I hope you will recognize that it comes from my actual
experience using Xilinx and Altera's free tools.
Okay, thanks for noticing about the PCI stuff, and even though I am not
a huge fan of Altera tools, I do often synthesize my PCI IP core
targeting FLEX10KE100K-1 to see how it does.



Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)

Article: 41699
Subject: Re: Simulator for xilinx Cores?
From: maxedman3503@yahoo.com (Max Edmand)
Date: 4 Apr 2002 23:02:29 -0800
Links: << >>  << T >>  << A >>
Thanks a lot Ray,

I am going to use Synopsys VHDL simulator,
but not sure how to link xilinxcorelib 
library with synopsys. In other words how to
"compile corelib library" ? does this compilation
need to be done only once ?? 

Ray Andraka <ray@andraka.com> wrote in message news:<3CAA5443.F119802C@andraka.com>...
> Use any simulator you want.  You just have to compile the
> xilinxcorelib before you try using it.  The corelib is VHDL
> files, and can be found under the xilinx install directory.
> Keep in mind the coregen simulation uses behavioral models,
> not the primitives or even the synthesized code.
> Nevertheless, as long as you compile the library, it doesn't
> matter which sim you use.
> 
> Max Edmand wrote:
> 
> > Hi everybody,
> >
> > I'm wondering which simulation tool can be used
> > to do behavioral simulation of a VHDL circuit which
> > contains Cores from Xilinx Coregen. Porbably the first
> > option is Xilinx ModelSim but we do not have the Unix
> > version of it (if it exists at all !).
> >
> > So, could I use Synopsys Simulation tool? I think that's
> > the most available tool for me right now. does any body
> > have experience of linking Xilinx cores with Synopsys
> > simulation tool on Unix platform? I would assume i need to
> > add the xilinx core library path somewhere in synopsys...
> >
> > Any kinds of hint are highly appreciated,
> >
> > Thanks a lot,
> > Max Edmand
> 
> --
> --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
> 
>  "They that give up essential liberty to obtain a little
>   temporary safety deserve neither liberty nor safety."
>                                           -Benjamin Franklin,
> 1759

Max Edmand



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