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 37150

Article: 37150
Subject: problem with manual floorplanner
From: Theron Hicks <hicksthe@egr.msu.edu>
Date: Sat, 01 Dec 2001 14:34:39 -0500
Links: << >>  << T >>  << A >>
Hi,
    I have a problem with the manual floorplanner in ise4.1.  I have a
design which I know will place and route but the system will not quite
make it if I use all coregen parts.  If I use mostly inferred counters
and adders it will work OK.  If I try to manually place the parts then
they get screwed up.  I woulkd like to use the absolute simplest method
to located the coregen parts using the UCF file.  Can anyone give me a
SIMPLE solution?  I really don't want to learn all about RLOC, etc. as I
really prefer to use the floorplanner when I can.  I would  like to just
place the coregen part at a particular position in the FPGA.  BTW this
is using the virtex2 parts and has been reported to XILINX and confirmed
as a new bug.

Thanks,
Theron


Article: 37151
Subject: Re: Is there a full open-source synthesis path for any FPGA?
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 01 Dec 2001 13:48:47 -0800
Links: << >>  << T >>  << A >>
Neil Franklin <neil@franklin.ch.remove> writes:
> So such a design will end up with quite a large amount of sold boards
> (and so FPGA chips), but sold to many different users/groups/teams, who
> will each be designing an different design to run on it.

Maybe a thousand of them if you're really lucky.  But even 10,000
isn't enough to attract the attention of an FPGA vendor, given what
the support cost would be.

I don't like it either, but it's a fact.

If there was a real market for FPGAs with documented bitstreams, there
would be a company selling into that market.  As I recall, Xilinx actually
did try that, and it apparently wasn't sufficiently successful.

Article: 37152
Subject: Re: Is there a full open-source synthesis path for any FPGA?
From: Russell Shaw <rjshaw@iprimus.com.au>
Date: Sun, 02 Dec 2001 10:35:05 +1100
Links: << >>  << T >>  << A >>


rickman wrote:
> 
> Russell Shaw wrote:
> > I was engineering in analog/rf, and got interested in doing dsp in fpgas
> > a couple of years ago (before web-packs etc). After being p*ssed off
> > by brand @$#! vendors because i wanted cheap/free tools to learn, i went
> > with brand A. Haven't regretted since. Acex devices are wonderful for
> > doing the dsp that i'm doing, and there's no hassles with hand-routing
> > etc. I'll only use X now if there's a very compelling reason, as there's
> > no point in learning new tools when the ones i'm using work ok.
> 
> As long as you are mentioning names, I had a very bad experience with
> brand A in my last design. We had to use about 80% of the chip and found
> that we could not trust the timing analyzer to give us good data. It was
> hard enough to meet our target of 80 MHz, but when we DID meet that
> number in the analyzer and tested on the bench at temperature, we found
> that the design failed badly, sometimes even at room temp. This was not
> a logic error, but a timing failure. We chased this so hard that I
> learned way more about running the tools than I ever wanted to know. It
> delayed the project schedule by about 3 months as well.
> 
> The bottom line was that the MaxPlus+II tool appears to be fataly
> broken. The last I heard, you had to use MaxPlus+II for ACEX designs. Is
> that still true? Or is ACEX supported by the (non free?) Quartus tools
> now?
> 
> I took a hard look at ACEX parts. They don't have the startup current
> limitation that Spartan II parts do and the price is right. But I am not
> using that @$#! MaxPlus+II tool again!

Luckily, my main use of cplds doesn't involve complicated protocol
shuffling, so i develop using crash-and-burn (or burn-and crash?)
procedure by testing with an oscilloscope after adding onto or
modifying the code. The speeds are way slower than the device,
and i make sure the vhdl is clean, invoking lpm blocks where
possible. I've always got more done using crash-and-burn, than
spending hours getting the same things to work in a simulator
(hard to interact with external hardware in a vhdl simulator).
I've got up to 80% EAB usage, and 40% LC usage so far.

Article: 37153
Subject: Re: Is there a full open-source synthesis path for any FPGA?
From: Kelly Hall <hall@priest.com>
Date: Sun, 02 Dec 2001 00:13:49 GMT
Links: << >>  << T >>  << A >>
Neil Franklin <neil@franklin.ch.remove> writes:

> More philosophical. I just prefer being unlimited.

Who doesn't?  Today, you are limited by the reality of no useful
open-source EDA tools being available anywhere.  There are some
excellent closed-source EDA tools available, though, and you can
obtain them at costs ranging from free to tens of thousands of
dollars.

> > or that the
> > open-source tools are so inferior to the commercial ones?
> 
> Problem presently is not inferior, but simply non existant.
> Once they start they will grow. Linux was also primitive when I
> entered it, 6 years ago. I can put up with primitive tools.

Sounds like a nice idea - it will be interesting to see if it pans
out.  So far it hasn't, and FPGAs and open-source aren't exactly brand
new ideas.

I don't mind primitive tools if there's nothing else available.
Today, there are excellent tools available that don't cost much.

Kelly

Article: 37154
Subject: Re: Is there a full open-source synthesis path for any FPGA?
From: Peter Alfke <palfke@earthlink.net>
Date: Sun, 02 Dec 2001 02:02:12 GMT
Links: << >>  << T >>  << A >>

Neil Franklin wrote:

>  An open source EDA tool can grow in time (may
> be 10 or more years, Linux OS took 10, the Linux GUIs are not quite
> there at 5 years) to be professional quality, without having any
> per-issue costs (as download = replication).
>
> That is what makes open source capable of working: reproduction is
> free, cost is only authoring cost, which is what make professional
> EDA tools expensive, and open source slow to grow.

Maybe this is the root cause of our difference of opinion:
5 years is an eternity in this industry. Today, you would (should!) not even
consider starting a design with parts that everybody hailed as the newest
and greatest just 5 years ago ( XC4000XL, any takers? )
Of course these parts stay in production for many more years, but they are
no match for the newer generations. I have publicly used the analogy that 1
year in the evolution of FPGAs is equivalent to 15 years in the aging of a
human being. A 4-year old FPGA is like a 60-year old human, competent, but
not up to the most demanding assignments.

We use Moore's law to come up with ever better, faster, more capable, and
effectively much cheaper devices, and the tools have to hang onto ( or lead
) that pace...
Peter Alfke


Article: 37155
(removed)


Article: 37156
Subject: XNF file gets corrupted
From: Hippolyte Lizard <euphoniusSPAMBLOCK@iname.com>
Date: Sat, 01 Dec 2001 21:21:27 -0800
Links: << >>  << T >>  << A >>
Often when I synthesize (Foundation 2.1i) the XNF files of macros I use
from the XC4000E library get corrupted, and ports disappear.  Driving me
crazy!  How do I prevent?

Thanks

HL

Article: 37157
(removed)


Article: 37158
Subject: Re: Is there a full open-source synthesis path for any FPGA?
From: rickman <spamgoeshere4@yahoo.com>
Date: Sun, 02 Dec 2001 00:59:50 -0500
Links: << >>  << T >>  << A >>
Neil Franklin wrote:
> I suppose I should describe the stuff I am doing a bit: I am presently
> working on using FPGAs for cloning historic/EOLed computer architectures.
> My intention is at some time (perhaps in 2 years) to design an generic
> FPGA-PC board (that is, an PC motherboard format, uses PC case and power,
> has standard PC interface connectors and RAM sockets, but FPGA instead
> of CPU), that will run mine and anyone elses system clones. Should allow
> any user to just get an board, plug in RAM, put in case, add HD, connect
> peripherals, download an compiled design, run. A bit like
> standard PC hardware running multiple OSes.
> 
> So such a design will end up with quite a large amount of sold boards
> (and so FPGA chips), but sold to many different users/groups/teams, who
> will each be designing an different design to run on it.
> 
> Of course such a system will require any user who wants to take part
> in one of the designs to get the tools. That will be a large amount of
> users entering the FPGA place. And each teams founder will be free to
> chose what tools they want for their individual design. So no Cisco
> dictates "our standard tool".
> 
> There are actually a few FPGA CPU and SoC projects, but all seem to be
> using prototyping boards and then hand-wiring IO. So a standard board
> could be quite successfull. And have the advantage that one can buy
> one board and then use multiple designs on it, saving space and cost.

To the best of my knowledge, there is not much demand for an FPGA based
SOC. The main purpose of SOC is to allow complex embedded systems to
made at low cost. Doing it on an FPGA will not keep the cost down. There
may be some advantage to having a "universal" hardware platform for
initial development, but I think you have vastly overestimated the
market for the FPGA motherboard you are describing. As you have defined
it, it would be a PC that runs slower, requires that you put massive
effort into NRE and will likely cost much more than a top end PC. FPGAs
of any size are much more expensive than a PC CPU. Unless the user needs
to solve a very special purpose application, there will be no
performance gain. Ask Ray A. As far as I am aware, most if not all of
his designs run at very high processing rates that Intel would envy. But
they are specially designed to solve only one problem. Even if you have
a "universal" hardware platform, you still only have a small target
audience with problems that can't be done on standard hardware. Besides,
having a "standard" board will be limited by the standard. Many
applications that need FPGA horsepower have little or no need for PCI or
other PC busses, they are just too slow. 

Earlier this year I bid on a DSP application using a small (but pricey)
FPGA to do FFTs at a rate that was difficult in DSP chips. But the added
NRE of the FPGA development made me the high bidder. FPGAs are typically
used for processing where nothing else will work, not because they are
inherently cheap to build. 

Hey, if users wanted to do processing on FPGAs, they would be buying
some of my DSP boards by the droves. My boards have Flash, fast SRAM and
IO which can all be controlled by the FPGA if you want. "Just" design
your own downloads! I will even leave the DSP off the board if you want
to save $50 on the price. 
 

> http://neil.franklin.ch/Projects/PDP-10/Hardware
> 
> And no, that is not the traditional FPGA user. But it is going to be
> part of the FPGA future. PCs were not the traditional microprocessor
> user in 1975 either, before the microcomputer revolution started.
> 
> > > Well, as I am hand routing every single LUT/FF (JBits requires that),
> > > so that part is not foreign to me. As for routing, I have not tried
> > > that (using JRoute), but it looks doable.
> >
> > Hand routing is not a program.
> 
> But good enough for me. And if someone else wants more, it is open
> source, user expandable, so they can add that.

I think this is where we are missing each other. You are asking for open
source tools. If you don't need routing, then you can write what you
need for everything but the bit file generation which is given to you.
So where is the problem?

 
> > > Perhaps I will have to try it. But having official docs from the horses
> > > mouth would be a lot better.
> >
> > Please let us know how it goes. JBITs should isolate you from the bit
> > file format issue, no?
> 
> So long I stay with JBits. But it has some drawbacks I would like to
> be able to avoid. Java being one of them.

If this is the only drawback, then let me know and I will be happy to
suppliment your tools with my open source bit file generator. That will
be the easy part. 

I don't want to rain on your parade, but we have heard from posters here
before about open source tools. But it is a bit like the weather,
everybody talks about it...  It sounds to me like your real application
is the design of a universal FPGA based motherboard. This does not
require the use of open source tools. I suggest that you consider your
real goal and find the best path to it. 

Now that I think about it, you can build what you want without designing
a mother board. Many PCs still support the Slot 1 (or is it Slot A?)
architecture. You can design a Slot 1 module that interfaces to a
standard PC motherboard as if it were a Pentium (or Athlon), have a bus
to memory etc. at up to 266 MHz, and not have to deal with any of the
groady stuff like emulating the North or South bridges. You even get to
control the power voltage from the module! Sounds like the simple
approach to me! :)

-- 

Rick "rickman" 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      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 37159
Subject: Re: Is there a full open-source synthesis path for any FPGA?
From: rickman <spamgoeshere4@yahoo.com>
Date: Sun, 02 Dec 2001 01:03:37 -0500
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> 
> Neil Franklin wrote:
> 
> >  An open source EDA tool can grow in time (may
> > be 10 or more years, Linux OS took 10, the Linux GUIs are not quite
> > there at 5 years) to be professional quality, without having any
> > per-issue costs (as download = replication).
> >
> > That is what makes open source capable of working: reproduction is
> > free, cost is only authoring cost, which is what make professional
> > EDA tools expensive, and open source slow to grow.
> 
> Maybe this is the root cause of our difference of opinion:
> 5 years is an eternity in this industry. Today, you would (should!) not even
> consider starting a design with parts that everybody hailed as the newest
> and greatest just 5 years ago ( XC4000XL, any takers? )
> Of course these parts stay in production for many more years, but they are
> no match for the newer generations. I have publicly used the analogy that 1
> year in the evolution of FPGAs is equivalent to 15 years in the aging of a
> human being. A 4-year old FPGA is like a 60-year old human, competent, but
> not up to the most demanding assignments.

Peter, you should be careful in your analogies... ;)


> We use Moore's law to come up with ever better, faster, more capable, and
> effectively much cheaper devices, and the tools have to hang onto ( or lead
> ) that pace...
> Peter Alfke

-- 

Rick "rickman" 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      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 37160
Subject: Re: Is there a full open-source synthesis path for any FPGA?
From: hamish@cloud.net.au
Date: 02 Dec 2001 10:29:43 GMT
Links: << >>  << T >>  << A >>
Peter Alfke <peter.alfke@xilinx.com> wrote:
> We have put many hundreds of man-years into the development of these tools, and
> we are (now) proud of their performance. We are not afraid of competition from
> smart hackers, we just know that they will never be able to generate a
> comprehensive quality solution and keep up with the fast-paced FPGA development.
> No matter how smart they are.  And we cannot afford to clean up after them.

> My opinion, yours may differ...

(My opinion (only) follows. You touched a raw nerve of mine here.)

Keeping up with the hardware is difficult, yes. But I wouldn't be so bold
as to say that open source developers will _never_ be able to produce
a comprehensive, quality solution. A few years ago you may have said
the same about operating systems, but look where Linux is now. So
after Linux became popular, people said that there would never be
a good graphical desktop for it because that wasn't something hackers
were interested in, but two such desktops now exist (KDE and GNOME).

On the subject of Linux, let me put you on the spot Peter :-) and
ask you when Xilinx will get serious about Linux. EDA tools for
Linux are already available from Synplicity, Synopsys, Mentor/ModelTech
and others. Apart from Xilinx tools (and perhaps ClearCase), I could
work all day on Linux now.


regards,
Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

Article: 37161
Subject: Re: What do you like/dislike about place and route tools?
From: hamish@cloud.net.au
Date: 02 Dec 2001 10:53:06 GMT
Links: << >>  << T >>  << A >>
Mark <mrgs1000@yahoo.com> wrote:
> To be more specific, here are some examples of the kind of information
> I am looking for:
> What features do you think are lacking?

I agree with everything Allan said. To add to that, I think the place
and the route stages are too separate (or at least they appear to be).

Last week I was helping someone route an update to an existing design.
For some reason, PAR (3.3i SP8 or 4.1i SP2, tried both) was placing one
large block of logic a long way from its source signals. There was no
area constraint, RLOCs, LOCs etc which would cause it do that; the
placer just decided. Then the router spent 11-15 hours trying to route
it unsuccessfully. We got net delays of 8 ns, on flip-flop to flip-flop
paths with a 5.5ns constraint.

In this case, the placer picked a completely stupid placement for this
block and the router spent the next half day trying to fix it. It never
realised that no amount of rerouting was going to halve the net delay.
A simple area_group constraint for this block fixed the problem and
got the PAR time down to the usual 2-3 hours for this design.

Some other things I would like: multipass PAR should learn from previous
iterations. Right now, multipass just varies the cost table (random
number seeds) and there is nothing learnt from previous iterations.

Also, the place and route tool should be multi-threaded to make use
of multiple CPU systems. Surely some part of the process can be
done in parallel? We have dual CPU systems everywhere now. Maybe
if it helped the runtime enough we could justify a 4 CPU system.

Repeatability is essential, as Allan said. Unfortunately, current
Xilinx PAR seems to have some issues in this area.

Here's another design flow wishlist. MAP has a feature called
register ordering, which tries to group my_vector[0] and my_vector[1]
etc into the same slice. There urgently needs to be a constraint which 
can be put in to disable this behaviour for individual signals. If
you expand a signal into a vector manually to lower the fan out,
you can end up with your signals grouped into pairs, which is
often completely useless. I have started using arrays of
std_logic_vector(0 to 0) (VHDL) to get around this problem!

Finally, the tools should never crash :-) 4.1i (any service pack)
leaks memory in a multipass run, and after a few iterations will
eventually chew up all the memory on your PC and crash. This
has been confirmed by Xilinx.

Just a few thoughts. I must say that in my experience, 4.1i
is a dramatic improvement on 3.3i. I'm very happy with the
4.1i results in a nice fast Virtex-II part.

regards,
Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

Article: 37162
Subject: Re: Is there a full open-source synthesis path for any FPGA?
From: Neil Franklin <neil@franklin.ch.remove>
Date: 02 Dec 2001 16:56:07 +0100
Links: << >>  << T >>  << A >>
rickman <spamgoeshere4@yahoo.com> writes:

> Neil Franklin wrote:
> > working on using FPGAs for cloning historic/EOLed computer architectures.
>
> SOC. The main purpose of SOC is to allow complex embedded systems to
> made at low cost.

Traditional use of SoCs yes.


> Doing it on an FPGA will not keep the cost down.

A lot cheaper (and a lot less work per copy) than using 100s or 1000s
of 74xx(x) plus needed board/case/powersupply. Not to mention assembly
costs.


> may be some advantage to having a "universal" hardware platform for
> initial development, but I think you have vastly overestimated the
> market for the FPGA motherboard you are describing.

There exists lots of people who can download an bitfile (if download
tools are provided with it. Quite a few that can learn coding. And far
less are prepared to go ordering/assembling parts and wiring them.

Look at the ratio of homebrew vs premade (altair, apple) computers
around 1975/6/7.


> As you have defined
> it, it would be a PC that runs slower, requires that you put massive
> effort into NRE and will likely cost much more than a top end PC.

Note the "historic/EOLed" in my above text. Implementing 386/later in
FPGA would be inferior (by about 6 years) to Intels current offerings.
But for systems that are EOLed, i.e. not buyable unless you try to get
one second hand, FPGA SoC can be very cheap. And the originals are
seldom (few made, many lost), large, guzzle electricity, require
cooling, break down often, no spares.


> FPGAs of any size are much more expensive than a PC CPU.

Yes, but easier to get than something not any more existant.


> > So long I stay with JBits. But it has some drawbacks I would like to
> > be able to avoid. Java being one of them.
>
> If this is the only drawback,

Nope. Just the the one that came to mind yesterday evening. There are
others: no Virtex-E (faster and cheaper) support, can not be freely
copied (give copy to every user who wants one), bug I run into (small
but annoying) has not got enough priority to have Xilinx fix it (with
o s I could fix it), etc. Just the typical mix of small stuff that
adds up to make any closed source frustrating to anyone who has once
tasted the fruits of open source.


> then let me know and I will be happy to
> suppliment your tools with my open source bit file generator. That will
> be the easy part.

Well if it is easy, I can do it myself :-).


> I don't want to rain on your parade, but we have heard from posters here
> before about open source tools. But it is a bit like the weather,
> everybody talks about it...

So it was also with OSes until Linux happend. EDA tools will happen.
Just give them time.


>  It sounds to me like your real application
> is the design of a universal FPGA based motherboard.

Presently my real application is my design for running on such an
board (and being developed on an normal prototype board). Custom board
will follow after, to let more users use the design with less hassle.


> Now that I think about it, you can build what you want without designing
> a mother board. Many PCs still support the Slot 1 (or is it Slot A?)
> architecture.

Slot 1 is Intel, Slot A is AMD. Implementing any chip or circuit using
Slot 1 signalling is illegal per patent law. Intel ist just at the
moment active at suing VIA for doing that (making an chipset for P4
motherboards).


> standard PC motherboard as if it were a Pentium (or Athlon), have a bus

They seem to be all 32/64bit, which is a bad match for 36/72bit stuff.


> to memory etc. at up to 266 MHz, and not have to deal with any of the
> groady stuff like emulating the North or South bridges.

Directly drive SDRAM off of the FPGA. There exist XAPPs on that.


> You even get to
> control the power voltage from the module! Sounds like the simple
> approach to me! :)

More hassle than use, IMHO.


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

Article: 37163
Subject: Phase noise (jitter) of XILINX logic elements - ?
From: "Alex Sherstuk" <sherstuk@iname.com>
Date: Sun, 02 Dec 2001 17:24:36 GMT
Links: << >>  << T >>  << A >>
Dear colleagues,

Some time ago there was discussion about phase noise (jitter) introduced by
XILINX FPGA DLL's

Here is an other question:

What phase noise (jitter) is introduced by a regular logic element of XILINX
FPGA (e.g. SPARTAN2)?
What is the timing uncertainty introduced by XILINX CLB trigger?

Thanks,
   Alex




Article: 37164
Subject: Re: Is there a full open-source synthesis path for any FPGA?
From: rickman <spamgoeshere4@yahoo.com>
Date: Sun, 02 Dec 2001 12:38:09 -0500
Links: << >>  << T >>  << A >>
hamish@cloud.net.au wrote:
> 
> Peter Alfke <peter.alfke@xilinx.com> wrote:
> > We have put many hundreds of man-years into the development of these tools, and
> > we are (now) proud of their performance. We are not afraid of competition from
> > smart hackers, we just know that they will never be able to generate a
> > comprehensive quality solution and keep up with the fast-paced FPGA development.
> > No matter how smart they are.  And we cannot afford to clean up after them.
> 
> > My opinion, yours may differ...
> 
> (My opinion (only) follows. You touched a raw nerve of mine here.)
> 
> Keeping up with the hardware is difficult, yes. But I wouldn't be so bold
> as to say that open source developers will _never_ be able to produce
> a comprehensive, quality solution. A few years ago you may have said
> the same about operating systems, but look where Linux is now. So
> after Linux became popular, people said that there would never be
> a good graphical desktop for it because that wasn't something hackers
> were interested in, but two such desktops now exist (KDE and GNOME).
> 
> On the subject of Linux, let me put you on the spot Peter :-) and
> ask you when Xilinx will get serious about Linux. EDA tools for
> Linux are already available from Synplicity, Synopsys, Mentor/ModelTech
> and others. Apart from Xilinx tools (and perhaps ClearCase), I could
> work all day on Linux now.
> 
> regards,
> Hamish
> --
> Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

We keep hearing about how Linux is a great example of how open source
tools are practical. But the two problems are so different. Designing
and maintaining an OS or even a compiler is much less impacted by the
base product changes than would be FPGA development tools. If I
understand these tools correctly, the changes required to port from a
Pentium III to an Athlon or a P4 are minimal. But consider the changes
required to port a P&R tool between the XC4000 family and an Altera
APEX20K!!! 

Perhaps I am overstating the problem. But so far we are only talking
about it (every six months or so). Until someone makes an effort and
writes such a tool, we will never know. I believe there are some open
source efforts to write front end tools for HDLs. This is very
comparible to the stuff being done in the OS domain. How many of us are
using these tools?


-- 

Rick "rickman" 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      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 37165
Subject: Re: Is there a full open-source synthesis path for any FPGA?
From: rickman <spamgoeshere4@yahoo.com>
Date: Sun, 02 Dec 2001 12:41:59 -0500
Links: << >>  << T >>  << A >>
hamish@cloud.net.au wrote:
> 
> Peter Alfke <peter.alfke@xilinx.com> wrote:
> > We have put many hundreds of man-years into the development of these tools, and
> > we are (now) proud of their performance. We are not afraid of competition from
> > smart hackers, we just know that they will never be able to generate a
> > comprehensive quality solution and keep up with the fast-paced FPGA development.
> > No matter how smart they are.  And we cannot afford to clean up after them.
> 
> > My opinion, yours may differ...
> 
> (My opinion (only) follows. You touched a raw nerve of mine here.)
> 
> Keeping up with the hardware is difficult, yes. But I wouldn't be so bold
> as to say that open source developers will _never_ be able to produce
> a comprehensive, quality solution. A few years ago you may have said
> the same about operating systems, but look where Linux is now. So
> after Linux became popular, people said that there would never be
> a good graphical desktop for it because that wasn't something hackers
> were interested in, but two such desktops now exist (KDE and GNOME).
> 
> On the subject of Linux, let me put you on the spot Peter :-) and
> ask you when Xilinx will get serious about Linux. EDA tools for
> Linux are already available from Synplicity, Synopsys, Mentor/ModelTech
> and others. Apart from Xilinx tools (and perhaps ClearCase), I could
> work all day on Linux now.
> 
> regards,
> Hamish
> --
> Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

I forgot to mention that I second the vote to use Linux for EDA. I
currently have to deal with Windows crashes some 3 or 4 times a day with
some of the software I am using. I may be at the point of wanting to
start over and reinstall Windows from scratch. I just wish I had a
second option. 

-- 

Rick "rickman" 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      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 37166
Subject: Re: Is there a full open-source synthesis path for any FPGA?
From: rickman <spamgoeshere4@yahoo.com>
Date: Sun, 02 Dec 2001 12:57:04 -0500
Links: << >>  << T >>  << A >>
Neil Franklin wrote:
> 
> rickman <spamgoeshere4@yahoo.com> writes:
> > then let me know and I will be happy to
> > suppliment your tools with my open source bit file generator. That will
> > be the easy part.
> 
> Well if it is easy, I can do it myself :-).

Well then, end of discussion. Let us know when you are done. I would be
interested in seeing how it went.

 
> > I don't want to rain on your parade, but we have heard from posters here
> > before about open source tools. But it is a bit like the weather,
> > everybody talks about it...
> 
> So it was also with OSes until Linux happend. EDA tools will happen.
> Just give them time.

Just give who time? I thought YOU were going to do it?

 
> > Now that I think about it, you can build what you want without designing
> > a mother board. Many PCs still support the Slot 1 (or is it Slot A?)
> > architecture.
> 
> Slot 1 is Intel, Slot A is AMD. Implementing any chip or circuit using
> Slot 1 signalling is illegal per patent law. Intel ist just at the
> moment active at suing VIA for doing that (making an chipset for P4
> motherboards).

And Via has a defence of having bought a company that HAS a licence for
this. I don't know why Intel thinks this is not valid. Mostly it is
chest thumping and an effort to scare off the Via customers. Your boards
would most likely be flying under Intel's radar. I don't think they
would spend the money to take you to court for using their patents to
emulate a PDP-10. 

 
> > standard PC motherboard as if it were a Pentium (or Athlon), have a bus
> 
> They seem to be all 32/64bit, which is a bad match for 36/72bit stuff.

Just curious, who would want an emulation of EOL'd computers and how
large is the market? Also don't you have the same issues with emulating
a VAX instruction set as duplicating the Slot I interface?


> > to memory etc. at up to 266 MHz, and not have to deal with any of the
> > groady stuff like emulating the North or South bridges.
> 
> Directly drive SDRAM off of the FPGA. There exist XAPPs on that.

That is what is done on the North Bridge. The CPU interface runs at the
speed of the SDRAM and the North Bridge is just electrical/arbitration
to connect the two. It also matches speed to the other high speed busses
such as AGP. But if you want, you can bring this inside the FPGA. But
this is more work. My point was to try to minimize the work to get
SOMETHING out sooner. But then I think in terms of commerciallizing
things, not as a hobbiest. 

 
> > You even get to
> > control the power voltage from the module! Sounds like the simple
> > approach to me! :)
> 
> More hassle than use, IMHO.

Didn't you see the grin?

Good luck with your project. Let us know how it goes!!!


-- 

Rick "rickman" 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      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 37167
Subject: Re: What do you like/dislike about place and route tools?
From: Ray Andraka <ray@andraka.com>
Date: Sun, 02 Dec 2001 19:08:37 GMT
Links: << >>  << T >>  << A >>
My biggest beef with the Xilinx placer is when there is more than one level
of logic, the placer puts the second level a long distance away regardless
of timing constraints.  The first level gets placed with the associated
flip-flop (I'm numbering in reverse order so that the output of the first
outputs to the flipflop) as it should.  If you place the flip-=flops, then
as long as the combinatorial logic is only one level you wind up with a good
placement.  Go to a second level, and you'll have to place the LUTs too
(which is a pain compared with using a regular expression).  I think that is
the most greivous of the placer sins, but there are others.


hamish@cloud.net.au wrote:

> Mark <mrgs1000@yahoo.com> wrote:
> > To be more specific, here are some examples of the kind of information
> > I am looking for:
> > What features do you think are lacking?
>
> I agree with everything Allan said. To add to that, I think the place
> and the route stages are too separate (or at least they appear to be).
>
> Last week I was helping someone route an update to an existing design.
> For some reason, PAR (3.3i SP8 or 4.1i SP2, tried both) was placing one
> large block of logic a long way from its source signals. There was no
> area constraint, RLOCs, LOCs etc which would cause it do that; the
> placer just decided. Then the router spent 11-15 hours trying to route
> it unsuccessfully. We got net delays of 8 ns, on flip-flop to flip-flop
> paths with a 5.5ns constraint.
>
> In this case, the placer picked a completely stupid placement for this
> block and the router spent the next half day trying to fix it. It never
> realised that no amount of rerouting was going to halve the net delay.
> A simple area_group constraint for this block fixed the problem and
> got the PAR time down to the usual 2-3 hours for this design.
>
> Some other things I would like: multipass PAR should learn from previous
> iterations. Right now, multipass just varies the cost table (random
> number seeds) and there is nothing learnt from previous iterations.

Yes that would be really good.  Even if it could infer the next cost table
instead of just walking through (I know that is probably harder than
iterating on the placement).

>
>
> Also, the place and route tool should be multi-threaded to make use
> of multiple CPU systems. Surely some part of the process can be
> done in parallel? We have dual CPU systems everywhere now. Maybe
> if it helped the runtime enough we could justify a 4 CPU system.
>
> Repeatability is essential, as Allan said. Unfortunately, current
> Xilinx PAR seems to have some issues in this area.
>
> Here's another design flow wishlist. MAP has a feature called
> register ordering, which tries to group my_vector[0] and my_vector[1]
> etc into the same slice. There urgently needs to be a constraint which
> can be put in to disable this behaviour for individual signals. If
> you expand a signal into a vector manually to lower the fan out,
> you can end up with your signals grouped into pairs, which is
> often completely useless. I have started using arrays of
> std_logic_vector(0 to 0) (VHDL) to get around this problem!
>
> Finally, the tools should never crash :-) 4.1i (any service pack)
> leaks memory in a multipass run, and after a few iterations will
> eventually chew up all the memory on your PC and crash. This
> has been confirmed by Xilinx.
>
> Just a few thoughts. I must say that in my experience, 4.1i
> is a dramatic improvement on 3.3i. I'm very happy with the
> 4.1i results in a nice fast Virtex-II part.
>
> regards,
> Hamish
> --
> Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

--
--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: 37168
Subject: Re: 128-bit scrambling and CRC computations
From: Ray Andraka <ray@andraka.com>
Date: Sun, 02 Dec 2001 19:33:31 GMT
Links: << >>  << T >>  << A >>
The CRC is a bit of a pain for speed because the feedback has to happen in a
single sample time, and it usually winds up consisting of 3 or 4 levels of
logic.  When the clock rate is high (such as your 100 MHz 128 bit parallel),
you run into the limitations of the FPGA architecture.  You can sometimes gain
a little bit by fixing non-optimal trees, but from what I've seen the synthesis
already does a decent job with building the tree.  Floorplanning will help
tremendously in Xilinx; the Xilinx placer does wonderfully putting the levle of
logic closest to the flip-flop with the associated flip-flop, but the level
feeding that usually gets placed much farther away than is necessary or
sensible.  The floorplanning of the combinatorial stuf can be a royal pain,
since it is dependent on the naming of the synthesized logic or requires LUT
instantiation of the whole tree.

I've found the easiest way to deal with it is to double your word width so that
you can halve the clock.  Doubling the word width typically adds one level of
logic, but you get twice the time to traverse the tree.  There is a pretty good
CRC VHDL code generator available on the web (I forget the address at the
moment, but there is a link to it from the links page on my website) which will
generate RTL VHDL code for arbitrary word widths and polynomials (combinatorial
description only).  Doubling the word width requires a second rank of registers
at the input to convert from single to double word at half rate.


Nicholas Weaver wrote:

> In article <c2088d4a.0111300833.18666c80@posting.google.com>,
> Ovidiu Lupas <olupas@opencores.org> wrote:
> >> I bet this is a CRC-32 (or CRC-16) being done on an OC-192 at 10 Gbps.
> >> That is where I saw this done before. The initial signal is bit serial,
> >> but the payload is being processed in an FPGA at about 80 or so MHz in a
> >> 128 bit wide word. Just a guess.
> >>
> >Exactly, OC-192 data that has to be processed 128-bit wide at 90 MHz.
> >Actually, it is an ATM O.191 Test Cell processor, and I cannot afford
> >pipelining at this point.
>
> Definatly look at unrolling and specializing the CRC calculation.
> CRC's are normally serial, but the N'th CRC is always a function of
> the XOR of a set of bits of the current state and of the input.
>
> Often the easiest way to do this is to write a little C program which
> spits out the Xor equations for each output CRC bit and just implement
> that.  You can even have your C-program spit out HDL and just cut &
> paste it.
>
> Each bit of the output will be dependant on approximatly 1/2 the input
> bits, so it will mostly be on the order of ~64 bit XORs (some slightly
> more).  As a balanced tree of 4-luts, this is 4 levels of logic.  A
> bit much to run at 80 MHz in most FPGAs, but may be possible if you
> are careful on the packing.  Adding a pipeline stage (EASY, cheap,
> etc) and it becomes nice and straightforward if you don't have
> feedback between your 128b data blocks.
>
> --
> 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: 37169
Subject: Re: 128-bit scrambling and CRC computations
From: rickman <spamgoeshere4@yahoo.com>
Date: Sun, 02 Dec 2001 15:25:30 -0500
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
> 
> The CRC is a bit of a pain for speed because the feedback has to happen in a
> single sample time, and it usually winds up consisting of 3 or 4 levels of
> logic.  When the clock rate is high (such as your 100 MHz 128 bit parallel),
> you run into the limitations of the FPGA architecture.  You can sometimes gain
> a little bit by fixing non-optimal trees, but from what I've seen the synthesis
> already does a decent job with building the tree.  Floorplanning will help
> tremendously in Xilinx; the Xilinx placer does wonderfully putting the levle of
> logic closest to the flip-flop with the associated flip-flop, but the level
> feeding that usually gets placed much farther away than is necessary or
> sensible.  The floorplanning of the combinatorial stuf can be a royal pain,
> since it is dependent on the naming of the synthesized logic or requires LUT
> instantiation of the whole tree.

I deal with the floorplanning not by instantiating, but by constructing
my logic to fit 4 input LUTs and then putting a "keep" on the
interconnecting signals. It does not always force a known name, but
normally it does. This is much easier than instantiation and is also
portable between different targets. 

 
> I've found the easiest way to deal with it is to double your word width so that
> you can halve the clock.  Doubling the word width typically adds one level of
> logic, but you get twice the time to traverse the tree.  There is a pretty good
> CRC VHDL code generator available on the web (I forget the address at the
> moment, but there is a link to it from the links page on my website) which will
> generate RTL VHDL code for arbitrary word widths and polynomials (combinatorial
> description only).  Doubling the word width requires a second rank of registers
> at the input to convert from single to double word at half rate.

Doubling the word width is a good idea! But I am pretty sure that most
designs will work at about 100 MHz in today's parts. 

Be careful with the CRC code generator. There are several ways to use
CRC and I think it only supports one of them. We had an engineer use it
to design his equations only to find out a week later, on the bench,
that he had built the wrong type of CRC! In simulation the two ends
matched, so no error. CRC sounds like a nice simple concept, but in
practice there are many pitfalls in many areas.


-- 

Rick "rickman" 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      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 37170
Subject: Re: Is there a full open-source synthesis path for any FPGA?
From: Simon Gornall <simon@gornall.net>
Date: Sun, 02 Dec 2001 20:38:47 +0000
Links: << >>  << T >>  << A >>
rickman wrote:
> 
> We keep hearing about how Linux is a great example of how open source
> tools are practical. But the two problems are so different. Designing
> and maintaining an OS or even a compiler is much less impacted by the
> base product changes than would be FPGA development tools. If I
> understand these tools correctly, the changes required to port from a
> Pentium III to an Athlon or a P4 are minimal. But consider the changes
> required to port a P&R tool between the XC4000 family and an Altera
> APEX20K!!!

You may or may not be correct in your general view, but the above 
argument is not sufficiently valid to help your point. Comparing 
the (P3 -> P4 or Athlon changes) vs the (XC4000 -> Apex20k changes)
is comparing apples to oranges.

A better illustration would be that Gcc can compile code for a 
wider variety of architecture types: ix86, avr (8-bit micro), arm
(branch predication within most instructions), i860, hp 9000 'Snakes'
mips rx000, ppc, m68k, m88k, ns32k, sparc (windowed regs), vax(!),
etc.

Not only does it cope with lots of weirdo architectures, each with
their own best-way of doing things, but it does it well, in a well-
defined manner (machine descriptions). It defines a many-one-many
architecture for the source-intermediate-object states which 
allowed it to become both truly portable and an automatic cross-
compiler.

GNU then developed the gnu super-optimiser. This is a tool that
tries every way the compiler can code basic ops, given the machine
description of a new machine type, and the best compiled code ends
up as a template for the compiler.

So:
  o It handles lots of (very) different architecture types
  o It optimises the operations for each architecture
  o It is completely open
  o It is (on some platforms) better than the vendor's compiler

I would say the compiler analogy is a pretty good one, as far as it
goes. Substitute FPGA families for machines and resource descriptions
(CLBs, carry chains, blockrams, long paths, 4-luts, 3-luts  etc.)
for machine descriptions and I think it clicks into place quite well.

I also think it'd be a very hard project to undertake. It would take a
braver man than I to say it would be "impossible" or "will never happen"
though...

> Perhaps I am overstating the problem. But so far we are only talking
> about it (every six months or so). Until someone makes an effort and
> writes such a tool, we will never know. I believe there are some open
> source efforts to write front end tools for HDLs. This is very
> comparible to the stuff being done in the OS domain. How many of us are
> using these tools?

One could look at:

  http://www.eecg.toronto.edu/~vaughn/vpr/vpr.html
  http://www.eecg.toronto.edu/~vaughn/vpr/e64.html (routing images)

as a darn good start. I mailed the guy who wrote the package about a
year ago though, and he said specifying the 'resource descriptions' 
as I refer to them above is by far the hardest problem, because of 
course you have to specify the constraints under which the resources
operate as well as the method by which you instantiate the constraint
on the resource.


FPGA's are the new 80's PC's
----------------------------

I do feel there is some merit in the statement that FPGA's are now at
the point where PC's were at 15 years ago. I would have never thought
I could design my own CPU at home, on a PC. Now though, it's pretty 
darn cheap, and the effort-level isn't that high to start getting 
results. I'm (painfully :-) aware that the black voodoo that all you 
experts know (about the internals of the CLB's etc) is required to  
squeeze the very last performance out of an FPGA, but I have a 32-bit   
CPU running at 50MHz+ in a spartan-2 which I'm quite proud of for a
first project :-))

I have a (much more ambitious) longer-term project in mind, which (if
I ever finish it) will be quite a useful little device in my industry.
Perhaps even commercially viable, although that's a loong way away. My
point is that I can play and learn, whereas 2 years ago, I would have
(a) not tried, and (b) paid a fortune for a dedicated piece of hardware
to do the same job...

All my designs will use Xilinx parts, because they're cheap to work with
(Thankyou BurchEd :-) and the s/w is downloadable. I would *really* like
to not have to reboot into Win2k to run the tools though - in fact the
main obstacle to the development of my "project" is that my Linux box
is usually busy doing things, and I don't want to interrupt it to play
on the FPGA stuff. Guess I should buy another computer ...

ATB,
	Simon.

Article: 37171
Subject: Re: Is there a full open-source synthesis path for any FPGA?
From: Neil Franklin <neil@franklin.ch.remove>
Date: 02 Dec 2001 22:30:51 +0100
Links: << >>  << T >>  << A >>
rickman <spamgoeshere4@yahoo.com> writes:

> Neil Franklin wrote:
> >
> > rickman <spamgoeshere4@yahoo.com> writes:
> > > then let me know and I will be happy to
> > > suppliment your tools with my open source bit file generator. That will
> > > be the easy part.
> >
> > Well if it is easy, I can do it myself :-).
>
> Well then, end of discussion. Let us know when you are done. I would be
> interested in seeing how it went.

Will take a bit of time. But I will sure report it here.


> > > I don't want to rain on your parade, but we have heard from posters here
> > > before about open source tools. But it is a bit like the weather,
> > > everybody talks about it...
> >
> > So it was also with OSes until Linux happend. EDA tools will happen.
> > Just give them time.
>
> Just give who time? I thought YOU were going to do it?

Oops s/them/us/. Like in all open source I will be one of multiple doing it.


> > Slot 1 is Intel, Slot A is AMD. Implementing any chip or circuit using
> > Slot 1 signalling is illegal per patent law. Intel ist just at the
> > moment active at suing VIA for doing that (making an chipset for P4
> > motherboards).
>
> And Via has a defence of having bought a company that HAS a licence for
> this.

Ah? I never heard that bit. Most likely the journalist I read did not
either. Good news. I rather like VIA (this computer and my previous one
have/had their chipsets).


> I don't know why Intel thinks this is not valid. Mostly it is
> chest thumping and an effort to scare off the Via customers.

Could be. They have got a reputation of using dirty tricks.


> would most likely be flying under Intel's radar. I don't think they
> would spend the money to take you to court for using their patents to
> emulate a PDP-10.

Most likely. I am peanuts for them. :-)


> > > standard PC motherboard as if it were a Pentium (or Athlon), have a bus
> >
> > They seem to be all 32/64bit, which is a bad match for 36/72bit stuff.
>
> Just curious, who would want an emulation of EOL'd computers

Because todays commercially available choice of systems (PC/Windows,
Mac/MacOS, PC-or-Mac/Linux-or-BSD) is not exactly large. There exist
quite a few old systems which I and others would like to revive and
add new featires and see what we can make out of them. Think of it as
experimenting in alternative evolutions.


> large is the market?

I expect about 10 systems times each 1000-3000 machines.


> Also don't you have the same issues with emulating
> a VAX instruction set as duplicating the Slot I interface?

Instruction sets are not patentable (not even copyrightable). A few
sets are not implementable without breaking patents on particular
features (MIPS non aligned data handling instructions come to mind,
dito PDP-11 instruction pointer as last arithmetic register), but
most have no such limits, or the patents have recieved their 17 year
death. No trouble there.


> > > to memory etc. at up to 266 MHz, and not have to deal with any of the
> > > groady stuff like emulating the North or South bridges.
> >
> such as AGP. But if you want, you can bring this inside the FPGA. But
> this is more work. My point was to try to minimize the work to get
> SOMETHING out sooner. But then I think in terms of commerciallizing
> things, not as a hobbiest.

My method to save time is to actually have no bus at all. Rather
SDRAM sockets and set of standard IO connectors driven directly
(or with only a bit of analog stuff between) from the FPGA. "Bus"
is only internal, longlines or even user multiplexers. Also gives
maximal flexibility to different architectures.


> > > You even get to
> > > control the power voltage from the module! Sounds like the simple
> > > approach to me! :)
> >
> > More hassle than use, IMHO.
>
> Didn't you see the grin?

I overlooked it.


> Good luck with your project. Let us know how it goes!!!

I will. Promise.


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

Article: 37172
Subject: Re: quartus do not support parameter value assignment in module instantation
From: "Peter Ormsby" <faepete.deletethis@mediaone.net>
Date: Mon, 03 Dec 2001 02:26:49 GMT
Links: << >>  << T >>  << A >>
I'm assuming you're refering to the Quartus native verilog synthesis?  I
would suggest using the free Leonardo Spectrum verilog synthesis tool that
comes with Quartus.  It has better verilog language support and it's free
off the Altera web site:

http://www.altera.com/products/software/download/dnl-download.html

-Pete-

ssy <shengyu_shen@hotmail.com> wrote in message
news:f4a5f64f.0111301901.2b45760e@posting.google.com...
> Hi everyone
>
> quartus do not support parameter value assignment in module
> instantation, but some module of my design come from other
> designer,and contain parameter,so I do not want to modify these
> module,how to deal with this



Article: 37173
Subject: Re: Is there a full open-source synthesis path for any FPGA?
From: rickman <spamgoeshere4@yahoo.com>
Date: Sun, 02 Dec 2001 23:15:41 -0500
Links: << >>  << T >>  << A >>
Simon Gornall wrote:
> 
> rickman wrote:
> >
> > We keep hearing about how Linux is a great example of how open source
> > tools are practical. But the two problems are so different. Designing
> > and maintaining an OS or even a compiler is much less impacted by the
> > base product changes than would be FPGA development tools. If I
> > understand these tools correctly, the changes required to port from a
> > Pentium III to an Athlon or a P4 are minimal. But consider the changes
> > required to port a P&R tool between the XC4000 family and an Altera
> > APEX20K!!!
> 
> You may or may not be correct in your general view, but the above
> argument is not sufficiently valid to help your point. Comparing
> the (P3 -> P4 or Athlon changes) vs the (XC4000 -> Apex20k changes)
> is comparing apples to oranges.
> 
> A better illustration would be that Gcc can compile code for a
> wider variety of architecture types: ix86, avr (8-bit micro), arm
> (branch predication within most instructions), i860, hp 9000 'Snakes'
> mips rx000, ppc, m68k, m88k, ns32k, sparc (windowed regs), vax(!),
> etc.
> 
> Not only does it cope with lots of weirdo architectures, each with
> their own best-way of doing things, but it does it well, in a well-
> defined manner (machine descriptions). It defines a many-one-many
> architecture for the source-intermediate-object states which
> allowed it to become both truly portable and an automatic cross-
> compiler.
> 
> GNU then developed the gnu super-optimiser. This is a tool that
> tries every way the compiler can code basic ops, given the machine
> description of a new machine type, and the best compiled code ends
> up as a template for the compiler.
> 
> So:
>   o It handles lots of (very) different architecture types
>   o It optimises the operations for each architecture
>   o It is completely open
>   o It is (on some platforms) better than the vendor's compiler
> 
> I would say the compiler analogy is a pretty good one, as far as it
> goes. Substitute FPGA families for machines and resource descriptions
> (CLBs, carry chains, blockrams, long paths, 4-luts, 3-luts  etc.)
> for machine descriptions and I think it clicks into place quite well.
> 
> I also think it'd be a very hard project to undertake. It would take a
> braver man than I to say it would be "impossible" or "will never happen"
> though...

That may all be true. But I still maintain that place and route software
is inherently more complex than complilers. The tasks required to
convert C language instructions to machine code for a given, well
defined architecture is conceptually straight forward and well
understood by nearly anyone graduating with a computer science degree.
On the other hand, place and route algorithms are in a class of problems
known as NP complete if my schooling has not failed me (or my memory).
This means essentially that you can NEVER deterministically find the
best solution to the problem for a realistic application given the state
of technology in the foreseeable future. At least this is true until we
are using Quantum computing which can explore all solution sets
simultaneously. 

The difference in problem statment means that the algorithms for solving
them and the means of developing them are very, very different. The
suboptimal solution hunt will always require custom algorithms and
special tuning that are far more device specific than what is done to
write a code optimizer for a processor. 

You obviously understand compliers pretty well. But what do you know
about designing place and route software? I don't profess to be an
expert, but this is a very different animal than writing a compiler. 

 
> > Perhaps I am overstating the problem. But so far we are only talking
> > about it (every six months or so). Until someone makes an effort and
> > writes such a tool, we will never know. I believe there are some open
> > source efforts to write front end tools for HDLs. This is very
> > comparible to the stuff being done in the OS domain. How many of us are
> > using these tools?
> 
> One could look at:
> 
>   http://www.eecg.toronto.edu/~vaughn/vpr/vpr.html
>   http://www.eecg.toronto.edu/~vaughn/vpr/e64.html (routing images)
> 
> as a darn good start. I mailed the guy who wrote the package about a
> year ago though, and he said specifying the 'resource descriptions'
> as I refer to them above is by far the hardest problem, because of
> course you have to specify the constraints under which the resources
> operate as well as the method by which you instantiate the constraint
> on the resource.

This is encouraging. But how does it compare to the commercial tools?
They don't say what the "chip" is. I assume it is an imaginary one, the
routing appears to be very, very simplistic. Most FPGAs have multiple
levels of routing and important limitations on how you can use that
routing. I expect this would greatly complicate routing algorithms. 

But then maybe I am overstating the complexity of P&R algorithms. But
they have been the bane of FPGA design for as long as there have been
FPGAs. If you have a chip that runs 20% slower and have tools that
optimize the P&R to give 20% better results, you will be able to meet or
beat your competition. I am sure that every FPGA company works very hard
to improve the P&R tools. 


> FPGA's are the new 80's PC's
> ----------------------------
> 
> I do feel there is some merit in the statement that FPGA's are now at
> the point where PC's were at 15 years ago. I would have never thought
> I could design my own CPU at home, on a PC. Now though, it's pretty
> darn cheap, and the effort-level isn't that high to start getting
> results. I'm (painfully :-) aware that the black voodoo that all you
> experts know (about the internals of the CLB's etc) is required to
> squeeze the very last performance out of an FPGA, but I have a 32-bit
> CPU running at 50MHz+ in a spartan-2 which I'm quite proud of for a
> first project :-))

Congrats, that is impressive indeed. I don't even like to think about
the "black voodoo" that some designers know. The last project I worked
on for a company required lots of BV to overcome the poor toolset. It
almost made me quit the FPGA game. 

 
> I have a (much more ambitious) longer-term project in mind, which (if
> I ever finish it) will be quite a useful little device in my industry.
> Perhaps even commercially viable, although that's a loong way away. My
> point is that I can play and learn, whereas 2 years ago, I would have
> (a) not tried, and (b) paid a fortune for a dedicated piece of hardware
> to do the same job...

I am glad that FPGAs have allowed you to design your own hardware. 
 

> All my designs will use Xilinx parts, because they're cheap to work with
> (Thankyou BurchEd :-) and the s/w is downloadable. I would *really* like
> to not have to reboot into Win2k to run the tools though - in fact the
> main obstacle to the development of my "project" is that my Linux box
> is usually busy doing things, and I don't want to interrupt it to play
> on the FPGA stuff. Guess I should buy another computer ...
> 
> ATB,
>         Simon.

I would love to run something other than Windows myself. I have booted
my machine four times today and I am shopping for a new laptop partly so
I won't have to reinstall everything to get around this problem. 

But none of that changes the viability of open source tools for FPGA
design. Perhaps the availability of free (as in beer) tools and low cost
hardware will encourage more "amature" work in the tool area and we will
start to see some open source tools. But I don't expect to see them
being used much professionally during my career. I have about 10 - 15
years left. We will see if anything changes my mind by then. 


-- 

Rick "rickman" 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      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 37174
Subject: Re: Is there a full open-source synthesis path for any FPGA?
From: rickman <spamgoeshere4@yahoo.com>
Date: Sun, 02 Dec 2001 23:21:23 -0500
Links: << >>  << T >>  << A >>
Neil Franklin wrote:
> 
> rickman <spamgoeshere4@yahoo.com> writes:
> > such as AGP. But if you want, you can bring this inside the FPGA. But
> > this is more work. My point was to try to minimize the work to get
> > SOMETHING out sooner. But then I think in terms of commerciallizing
> > things, not as a hobbiest.
> 
> My method to save time is to actually have no bus at all. Rather
> SDRAM sockets and set of standard IO connectors driven directly
> (or with only a bit of analog stuff between) from the FPGA. "Bus"
> is only internal, longlines or even user multiplexers. Also gives
> maximal flexibility to different architectures.

Exactly what do you consider to be a "standard" IO connector? I assumed
that you meant PCI, ISA, IDE ect. If you want to put all that interface
inside of the FPGA that will require more work on your part to design
the interfaces. If you use an existing MB, you only have to design your
CPU with a single bus interface. 

-- 

Rick "rickman" 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      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX



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