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 37125

Article: 37125
Subject: Re: SpartanIIE
From: Marc Baker <marc.baker@xilinx.com>
Date: Fri, 30 Nov 2001 10:42:09 -0800
Links: << >>  << T >>  << A >>
Xilinx pad and via layout info is at
http://www.xilinx.com/partinfo/pkgs_pdf/pkgs1.pdf .  The recommendations for the
FT256 are identical to those for the FG256.

rickman wrote:

> Speaking of routing... Anyone know where I can get guidelines for pad
> and via layout on these parts? I thought Xilinx had a document
> somewhere, but I can't find it on their web site.

--
Marc Baker
Xilinx Applications



Article: 37126
Subject: WebPack Experience
From: Nick Macias <nmacias@cellmatrix.com>
Date: Fri, 30 Nov 2001 11:47:04 -0700
Links: << >>  << T >>  << A >>
Wanted to share this with everyone FWIW...

I started using WebPack on a design targeted to the Spartan-II. Pretty
quickly, I encountered the semi famous XST error:

FATAL_ERROR:Xst:Portability/export/Port_Main.h:116:1.9 - This
application has discovered an exceptional condition from which it cannot
recover.

(gotta love the non-dangling participle)

I clicked on the red "WEB" icon in the margin and went to Xilinx's web
page, where I found no useful help. Annoyed, I clicked the "Was This
Useful? Not At All" button and fired off a quick, frustrated message.

I wsa contacted by a Xilinx engineer (Steve Elzinga) the next morning,
who offered to look at my design (100,000+ gates) and try to fix the
problem! I wasn't even expecting a reply to my original message (which
was as much a rant as a bug report). 24 hours and four rounds of email
later, my design is synthesized! (trick was disabling Slick Packing in
the Xilinx Specific Options for Synthesize).

This is better support than I receive for most SW/HW which I pay good
money for. To me, it's an amazing level of support for a free tool! It
has certainly had a positive effect on my opinion of Xilinx.

Just thought I'd pass on the experience, for what it's worth.

	Cheers,
		Nick Macias
		(No relationship to Xilinx other than buying a few of their parts and
using their free software).

Article: 37127
Subject: Re: SpartanIIE
From: Marc Baker <marc.baker@xilinx.com>
Date: Fri, 30 Nov 2001 10:53:17 -0800
Links: << >>  << T >>  << A >>
Magnus Homann wrote:

> My understanding is that the FT is thinner because it is. Fewer layers
> in the package substrate (2 instead of 4).

You are right.  The main motivation for the FT package is lower cost, with
the thinner dimensions being a side benefit and the reason it had to be
called something besides FG.  This is described in the Spartan-IIE FAQ on
xilinx.com
( http://www.xilinx.com/products/spartan2e/faq100_sp2e.pdf ).

--
Marc Baker
Xilinx Applications




Article: 37128
Subject: Re: Is there a full open-source synthesis path for any FPGA?
From: mrgs1000@yahoo.com (Mark)
Date: 30 Nov 2001 11:10:06 -0800
Links: << >>  << T >>  << A >>
Kees van Reeuwijk <C.vanReeuwijk@twi.tudelft.nl> wrote in message news:<c9hd0uoiu5rad849hcpuv1j9qsnhtdc75p@4ax.com>...
> On Thu, 29 Nov 2001 10:21:10 -0500, rickman <spamgoeshere4@yahoo.com>
> wrote:
> 
> >Neil Franklin wrote:
> >> 
> >> mrgs1000@yahoo.com (Mark) writes:
> >> 
> >> > Kees van Reeuwijk <C.vanReeuwijk@twi.tudelft.nl> wrote in message news:<3fl90u
>  k0l3mmebi1703urlud5e91rou5af@4ax.com>...
> >> > >
> >> > > I understand that the scarcity of such software is partly because
> >> > > vendors do not release enough information. Are there any modern devices
> >> >
> >> > I would venture to say that the primary road block to open-source
> >> > tools is that they are too dificult to support and keep current for
> >> > people to do for free.
> >> 
> >> As opposed to tons of video and ethernet chips that the Linux people
> >> seem to have no great problem with?
> >> 
> >> Just simply support those chips that members of the open source group
> >> use. And the software users then buy those parts.
> >> 
> >> Hint to vendors: if your part has open source support, it gets more
> >> recommendations ("take that one, it works"), and you get to sell more
> >> of them. I principially buy video and ethernet cards after consultion
> >> the on-line support databases.
> >
> >I think this is where the analogy between standard hardware support
> >under a standard OS and FPGA support under a standard tool fails.
> >Designers don't EVER want to compromize their choice of chip based on
> >the tools. That would be more like vacationing in Newark because the bus
> >is cheaper than taking a plane to the Bahamas! 
> >
> >The idea that open source tool support will significantly impact the
> >sales of FPGA chips is weak at best. The customers who buy lots of chips
> >from the FPGA vendors get free tools and often have an FAE parked in
> >their facility. I worked at one place where they still used brand Z
> >chips in SPITE of the awful toolset they had to use. This was because
> >the chip was $10 cheaper than the other brand. It ended up costing them
> >a lot when they had to make revisions, but this was still the best
> >solution in terms of PROFIT!!!  (brand Z is not meant to be any
> >particular company!)
> 
> 
> Fair enough, for a volume application.
> 
> However, if the FPGA is used for reconfigurable computing, the situation
> is different. I'm convinced that the first vendor with both a PCI FPGA
> board and an open-source toolset will become extremely popular in hacker
> circles. And who knows, it may even become popular in mainstream
> computing. 
> 
> The big FPGA vendors may not be interested in this market, but I'm
> surprised that none of the smaller ones has tried this. (Hint, hint :-)
> 

PCI FPGA cards exist already from 3rd parties. FPGA vendors suck at
board design.  You don&#8217;t want them doing it themselves.

Why does the toolset need to be open source for reconfigurable
computing? People are doing this now with existing tools.



> >> > There are lots of flows for design entry and
> >> > simulation,
> >> 
> >> Just support those that the present maintainers use. And use those
> >> that are supported.
> >> 
> >> > and new devices are released on a weekly basis. I
> >> 
> >> Huh? As far as I see it Xilinx has so far created about 9 families
> >> (2000 3000 4000/Sparten 4000XL/SpartanXL 5200 6200 Virtex/SpartenII
> >> VirtexE/SpartanIIE Virtex2) in 15 years. Altera has 8 families
> >> (MAX3000 MAX7000 MAX9000 FLEX6K FLEX8K FLEX10K/ACEX APEX Mercury)
> >> in over 10 years. Lucent has IIRC 4 families of ORCA. Atmel 2
> >> families (4000 6000). Actel I do not know, as I can not read their
> >> website (damn Flash and not HTML alternative). And a few other
> >> irrelevant manufacturers.
> >> 
> >> So that makes about 2 falimies per year industrywide to support. Or
> >> simply only support a few of them and only use those.
> >
> >But a familiy has some 10 different parts in it. Each of those parts has
> >many packages and several speeds. Just getting the speed info (critical)
> >is not an easy problem to solve. Without vendor support, you would be
> >very hard pressed for anyone to trust your data. 
> >
> >It certainly could be done, but the fact that it has not happened yet is
> >a good indicator that it is harder than you seem to believe. 
> 
> I consider timing info as just another part of the now-secret device
> programming info.
> 
> However, for reconfigurable computing applications one *could*
> characterize each individual device and use that (with a safety margin,
> of course).

Dude, there is no secret conspiracy, search the archives, the info is
out there. Vendors just dont make it easy to find because they dont
want to have to support it.

If you think it is such a good idea, then go write it yourself. I have
no doubt that I could do it, and if I become independantly wealthy I
just might. In the mean time, I gota devote most of my time to paying
the bills.

Article: 37129
Subject: What do you like/dislike about place and route tools?
From: mrgs1000@yahoo.com (Mark)
Date: 30 Nov 2001 11:24:36 -0800
Links: << >>  << T >>  << A >>
I am doing some research on place and route tools. I would like to
collect as much information as possible about them. My primary focus
is on Xilinx, but I would like to know if there are particular
features on other vendors tools that you like or dislike.

To be more specific, here are some examples of the kind of information
I am looking for:
What features do you think are lacking?
What types of circuits or conditions do you think the tools fail to
handle properly?
(if you can send me source for the circuit that would be cool, but I
will understand if you cant or don&#8217;t want to)
What features do you think are really nice?
What kinds of controls do you like or wish you had over the place and
route process?

Please try to be specific about circuits, vendors, and parts since
many issues may only be relevant to one vendor&#8217;s tools, or even
one revision of a vendor&#8217;s tools.

Thanks,

Mark

Feel free to email me; my email address is valid (for now anyway).

Thanks in advance for any info you can give me.

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

> Neil Franklin wrote:
> >
> > > > The idea that open source tool support will significantly impact the
> > > > sales of FPGA chips is weak at best.
> >
> > Short term they may not. Think long term: they pull in more beginners,
> > and so in time grow the population of FPGA developers, and so allow
> > firms to emply more and so make more FPA projects and that sells more
> > chips.
>
> That sounds great, but you missed the significance of my example below.
> If a high volume user can make $10 more profit on brand R than on brand

High volume yes. But beginners are not high volume.


> The small volume customers don't count. The high volume customers will

At present. But they are the source that tomorrows high volume people
come from. So why hinder them? It is not as if publishing the formats
were an large expensive to avoid.


> > > > But a familiy has some 10 different parts in it.
> >
> > And a Virtex CLB is a Virtex CLB, whether in XCV50, XCV1000 or XC2S200.
>
> Now you are showing that you have a lot to learn about the problem. I
> first heard about 10 years ago that the FPGA companies sell you routing
> and throw in the logic for FREE. The point is that way more than half
> the chip is routing.

That is well known here. For Virtex one CLB has 18x48=864 config bits
of which well over 700 are routing PIPs according to the JBits docs.
So that makes ca 80% routing, as far as config volume goes.


> minimization and such. The real trick is to efficiently place and route
> a part. This is not software you can write in your spare time.

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.


> > So long non-availability of information makes it impossible, any "not
> > happened" is 100% explained. Everything else remains speculation until
> > that barrier falls.
>
> Only a small part of the process is not documented. That would be the
> final step of generating the bit file. As has been pointed out here
> before, one of the smaller tasks in designing this sort of software
> would be reverse engineering the bit file format.

Perhaps I will have to try it. But having official docs from the horses
mouth would be a lot better.


> If someone would sign
> up to writing a complete, end to end development system,

Sorry, no chance here. More likely the typical open-source piecemeal
production of the next part I (or other participants) want to use.


> > > This brings up another point, in addition to the place and route
> > > tools, you have to also provide the timing analysis tools.
> >
> > You know how many home/edu people overclock CPUs? Raise frequency until
> > crash, than drop by 10% is the sort of algorithm. It is "good enough"
> > for the target audience.
>
> Tell me again who is the target audience, hobbiest?

If I do something definitely, as I am a hobbyist. But there again
Linux also started as hobbyist project. It grew out of it.


> > Nope. Non-existance comes from non-information. Proof for your
> > argument will only be available after the information has been
> > available for some time and not being used.
>
> I think you have not really looked at the problem to be solved. As I
> said above, only the final bit file generation is not disclosed. That
> can be reverse engineered. So if anyone were serious about this, it
> could be attempted.

I think it will be. FPGAs are just entering the spotlight of
hackers. They are about where microprocessors were 1975. I expect the
next 5 years to be similarly furious as the 75-80 was for micros.

And yes that is a prediction, we will see if it turns out.


--
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: 37131
Subject: Re: Is there a full open-source synthesis path for any FPGA?
From: Neil Franklin <neil@franklin.ch.remove>
Date: 30 Nov 2001 22:08:53 +0100
Links: << >>  << T >>  << A >>
Kelly Hall <hall@priest.com> writes:

> The vendors are giving away decent tools for the low-end FPGAs and
> CPLDs these days.

Sort of. As far any closed-source tool they can not be user-extended
can be called decent.


> No excuse for a hobbiest to not be able to make fun
> stuff in the basement for almost nothing beyond the part price
> anymore.
>
> Or were you merely complaining that there's no free tool for the
> newest parts?

Open source is not about free as in free beer. It is about free as in
no limitations, as in being able to take any idea and realise it,
subject only to ones own limits such as skill or time limits. Not being
limited by externally imposed limits such as vendor tools OS/language
platform selection, and only those features which interest enough users
getting the vendor to allocate programmers to them, etc.

Just look at the millions who are fleeing the (payed for with the PC)
Microsoft OSes to Linux or BSD. That is not about cost (you pay anyway,
unless you belong to the few who put together their own PCs).

It is about getting software that was made by users, for themselves,
with their understanding of what it should do and what has priority to
them. As opposed to some vendors marketing department and project
managments ideas of what is profitable for the vendor.

And people who are used to such software regard vendor-make tools as
clunky. So they would prefer open source ones.


It is about a large amount of user-brains being better than an small
amount of vendor-brains. Same thing as with science vs dogma a few 100
years ago.

And yes, such ideas are new to most people, and like anything new they
look strange. Until you get used to them, and then they become obvious.


--
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: 37132
Subject: Re: Is there a full open-source synthesis path for any FPGA?
From: Neil Franklin <neil@franklin.ch.remove>
Date: 30 Nov 2001 22:17:02 +0100
Links: << >>  << T >>  << A >>
Kees van Reeuwijk <C.vanReeuwijk@twi.tudelft.nl> writes:

> On 28 Nov 2001 19:37:56 +0100, Neil Franklin <neil@franklin.ch.remove>
> wrote:
>
> >P.S. to the @xilinx.com readers here: the often given reason for
> >bitstream secrecy was that the PROM->FPGA link allows it to be grabbed
>
> Ah, at last a motivation for this secrecy.

Note: that is an somewhat widely spread speculation. I am not aware
of an official pronounciation. Problem with above it that anti-fuse
FPGA and EEPROM CPLD makers also do not publish, and above does not
apply to them.


> they didn't document it. The best I could think of was to make cloning
> more difficult.

Anyone willing to clone, read: set up an manufacturing and sales
process, will definitely not be stopped by reverse engineering. For
that sort of stopping competition there exists patent law.


Third motivation could be cost of documenting. But I do not regard
that as large enough to be noticable.


So the motivation question is really still open. Anyone @xilinx.com
who wants to comment of this?


> >The nearest I have found is to use Virtex/Spartan-II. For these there
> >exists JBits. This is an API+library to modify/generate bitsreams. It
>
> Thanks for the pointer. It sounds like the next best thing.

At least I manged to help someone with this thread.


--
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: 37133
Subject: Re: Is there a full open-source synthesis path for any FPGA?
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Fri, 30 Nov 2001 13:47:11 -0800
Links: << >>  << T >>  << A >>


Neil Franklin wrote:

> So the motivation question is really still open. Anyone @xilinx.com
> who wants to comment of this?

This is a recurring subject, so the answers are also recurring.

We do not encourage or support open-source place-and-route tools for a variety
of reasons. The strongest is:

We understand the difficulty of the task ( believe me, we do! ), and we do not
want to be dragged into a support quagmire. Since we sell the devices, our users
will inevitably demand support from us, and we cannot provide that for an
unlimited number of homebrew solutions.

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


Article: 37134
Subject: PCI card - 2 layers versus four layers
From: "Dan" <daniel.deconinck@sympatico.ca>
Date: Fri, 30 Nov 2001 16:53:08 -0500
Links: << >>  << T >>  << A >>
Hello,

I am shipping a 2 layer PCI card (33mhz-32bit). It uses a Xilinx with a 2.5V
core and 5Volt tolerant IOs.  ( XC2S50-5PQ208C)

I laid out the board with as much ground plane on the bottom and as much
routing on the top as was possible. Its 90% ground plane. I believe that
this works OK on many PCs but I think I still need to improve the electrical
characteristics of the board for proper operation across all PCs.

I currently use through hole by pass caps all around the perimeter of the
Xilinx chip.

I am sure things will get better by switching to both surface mount caps and
a four layer PCB. My question is how important is each of these two
improvements when compared to one another ? For example X% of the
improvement will come by switching from  through hole caps to surface mount
and (100-X) % of the improvment will come from switching from two layers to
four layers.

I am wondering if simply switching to surace mount caps will give enough of
a boost in performance.


Sincerely
Daniel DeConinck
www.PixelSmart.com
TEL: 416-248-4473




Article: 37135
Subject: Re: PCI card - 2 layers versus four layers
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Fri, 30 Nov 2001 15:30:50 -0800
Links: << >>  << T >>  << A >>
Dan wrote:
> 
> Hello,
> 
> I am shipping a 2 layer PCI card (33mhz-32bit). 

Really. Two layers? No noise problems?

> I laid out the board with as much ground plane on the bottom and as much
> routing on the top as was possible. Its 90% ground plane. I believe that
> this works OK on many PCs but I think I still need to improve the electrical
> characteristics of the board for proper operation across all PCs.

I would say "for proper operation in any PC"

> My question is how important is each of these two
> improvements when compared to one another ?

Type of caps won't make much difference.
A real ground and power plane will make a big difference.

 --Mike Treseler

Article: 37136
Subject: Re: Is there a full open-source synthesis path for any FPGA?
From: Russell Shaw <rjshaw@iprimus.com.au>
Date: Sat, 01 Dec 2001 11:29:39 +1100
Links: << >>  << T >>  << A >>


Neil Franklin wrote:
> 
> rickman <spamgoeshere4@yahoo.com> writes:
> 
> > Neil Franklin wrote:
> > >
> > > > > The idea that open source tool support will significantly impact the
> > > > > sales of FPGA chips is weak at best.
> > >
> > > Short term they may not. Think long term: they pull in more beginners,
> > > and so in time grow the population of FPGA developers, and so allow
> > > firms to emply more and so make more FPA projects and that sells more
> > > chips.
> >
> > That sounds great, but you missed the significance of my example below.
> > If a high volume user can make $10 more profit on brand R than on brand
> 
> High volume yes. But beginners are not high volume.
> 
> > The small volume customers don't count. The high volume customers will
> 
> At present. But they are the source that tomorrows high volume people
> come from. So why hinder them? It is not as if publishing the formats
> were an large expensive to avoid.

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.

Article: 37137
Subject: Re: 128-bit scrambling and CRC computations
From: gah@ugcs.caltech.edu (glen herrmannsfeldt)
Date: 1 Dec 2001 01:16:04 GMT
Links: << >>  << T >>  << A >>
allan_herriman.hates.spam@agilent.com (Allan Herriman) writes:
>(Nicholas Weaver) wrote:
>>Ovidiu Lupas <olupas@opencores.org> wrote:
>>>
>>>In my current project I have to implement scrambling and CRCs over a
>>>128-bit data bus at a clock rate of 100 MHz. My combinatorial areas
>>>are huge and I am having problems meeting the speed requirements.
>>>
>>>Could someone give me an hint how to overcome this problem ? 
>>>Any hints will be appreciated.
>>
>>What exactly are your scrambling requirements?

>One would guess that as 128 bits x 100MHz = 12.8Gbps, this would be
>either RFC 2615 POS over OC192, or 10G Ethernet.

>From http://www.ietf.org/rfc/rfc2615.txt?number=2615

>"4.  X**43 + 1 Scrambler Description

>   The X**43 + 1 scrambler transmitter and receiver operation are as
>   follows:

>   Transmitter schematic:

>                                              Unscrambled Data
>                                                     |
>                                                     v
>        +-------------------------------------+    +---+
>     +->|     --> 43 bit shift register -->   |--->|xor|
>     |  +-------------------------------------+    +---+
>     |                                               |
>     +-----------------------------------------------+
>                                                     |
>                                                     v
>                                               Scrambled Data
>"

>Please note that this is the 'serial prototype' and doesn't look
>anything like the parallel version that the OP requires.

That is neat.  x**43+1 is not in the table in 'Numerical Recipes',
but it is real convenient not to have many 1's in it.

I believe that makes the parallel implementation much easier.

I once did a software implementation of x**64+x**4+x**3+x+1,
using 32 bit math.  It is convenient in not having any terms
from x**63 down to x**32, so it is easy to do in 32 bit int's.

It should then take one or two 256x44 lookup tables, a
small number of XOR gates, and enough latches to make the
pipeline work.  Much easier than I was expecting for a CRC
with more terms in it.  Doing it 8 bits at a time is convenient
for software implementations.  In this case, the optimal number
may be different depending on memory cost and latch cost.

The 8 bit parallel C macro looks like:

#define UPDC32(x,y) (crc_32_tab[((x)^(y))&0xff]^((y>>8)&0xffffff))

Where x is the new byte, and y is the accumulated CRC value.

Any book on pipelined processor architecture should help you 
understand how to arrange the latches to pipeline the computation.

-- glen

Article: 37138
Subject: Re: Is there a full open-source synthesis path for any FPGA?
From: gah@ugcs.caltech.edu (glen herrmannsfeldt)
Date: 1 Dec 2001 01:42:33 GMT
Links: << >>  << T >>  << A >>
Peter Alfke <peter.alfke@xilinx.com> writes:

>This is a recurring subject, so the answers are also recurring.

>We do not encourage or support open-source place-and-route tools 
>for a variety of reasons. The strongest is:

>We understand the difficulty of the task ( believe me, we do! ), 
>and we do not want to be dragged into a support quagmire. 
>Since we sell the devices, our users will inevitably demand support 
>from us, and we cannot provide that for an unlimited number of 
>homebrew solutions.

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

The big computer companies could have said the same thing about
OS development not so many years ago, and now we have Linux
being supported on IBM mainframes.  Many companies are now seeing
the advantages of open-source software.  

Linux users know where to go for support and where not to go.
I do agree that you must tell people early where their support 
will come from, and where it won't.


-- glen

Article: 37139
Subject: quartus do not support parameter value assignment in module instantation
From: shengyu_shen@hotmail.com (ssy)
Date: 30 Nov 2001 19:01:34 -0800
Links: << >>  << T >>  << A >>
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: 37140
(removed)


Article: 37141
Subject: XNF file is rewritten and rendered useless
From: "Don Teeter" <don.teeter@intel.com>
Date: Fri, 30 Nov 2001 21:48:58 -0800
Links: << >>  << T >>  << A >>
Please help if you can.  My VHDL design in Xilinx Foundation 2.1i uses
library macro FDC.  To instantiate I include the provided file FDC.XNF as a
source file.  At some point during synthesis the XNF file changes, losing
some ports.  Then when attempt to implement, I get error messages:

Error: The pin 'D' of the cell 'cmdproc/U1' does not have an associated
signal in the XNF design 'fdc'. (FPGA-LINK-17)

One of these messages for each of three now-missing ports.  If I look in the
XNF file I see it has changed and the ports are missing from it.  What
gives?  How to prevent?  Thank you,

Don T.




Article: 37142
Subject: Re: What do you like/dislike about place and route tools?
From: allan_herriman.hates.spam@agilent.com (Allan Herriman)
Date: Sat, 01 Dec 2001 09:23:56 GMT
Links: << >>  << T >>  << A >>
On 30 Nov 2001 11:24:36 -0800, mrgs1000@yahoo.com (Mark) wrote:

>I am doing some research on place and route tools. I would like to
>collect as much information as possible about them. My primary focus
>is on Xilinx, but I would like to know if there are particular
>features on other vendors tools that you like or dislike.
>
>To be more specific, here are some examples of the kind of information
>I am looking for:
>What features do you think are lacking?
>What types of circuits or conditions do you think the tools fail to
>handle properly?
>(if you can send me source for the circuit that would be cool, but I
>will understand if you cant or don&#8217;t want to)
>What features do you think are really nice?
>What kinds of controls do you like or wish you had over the place and
>route process?
>
>Please try to be specific about circuits, vendors, and parts since
>many issues may only be relevant to one vendor&#8217;s tools, or even
>one revision of a vendor&#8217;s tools.

My primary gripe about the Xilinx tools (apart from the bugs and
crashes and the way you can route the same design on multiple PCs with
the same version of software and they all route to speed but don't
produce identical results even though the source was identical and
then some of them don't work when downloaded) is that there is no
feedback from placement to Map.  Mapping occurs before placement, so
the mapper has to make some guesses about how to group logic into
slices; where to insert buffers, etc.

Most of the time it does a good job.  But I sometimes find that I have
to change my source code to work around the register ordering feature,
for example.  (This feature can be disabled, but not on a signal by
signal basis.  If it's disabled for the whole chip the results are
usually really bad.)
Register ordering causes Map to group logic into slices according to
the labels on the logic.  E.g. sig_0 and sig_1 will end up in the same
slice.  This is great for arithmetic (essential, actually, unless
you're hand placing everything) but not so good if two flip flops from
completely unrelated parts of the design end up in the same slice,
which really fouls up your floorplan.
Once Map has done the damage, there is nothing PAR can do to fix it.

Workarounds (for VHDL) include:

- Changing std_logic_vectors to arrays of single element
std_logic_vectors.  This makes the generated labels all end in "_0"
which prevents Register Ordering.  (Thanks to Hamish Moffatt for this
one.)

- Applying placement attributes in the source code.

These comments apply to VirtexE parts, 60-80% utilised, 100-170MHz-ish
clocks.  3.x & 4.x tools.

That said, I think the quality of the back end tools is much better
than the quality of the front end tools.

I tried my current design (several tens of thousands of lines of VHDL)
with some different versions of a leading VHDL synthesiser:

version   result
6.0.0     Dr. Watson
6.2.0     works when downloaded to fpga
6.2.3     doesn't work when downloaded
6.2.4     doesn't work when downloaded
7.0.1     doesn't compile (parser bug)
7.0.2     doesn't compile (parser bug)

1 out of 6 ain't bad!  (Better than 0 out of 6.)

Regards,
Allan.

Article: 37143
Subject: Re: Is there a full open-source synthesis path for any FPGA?
From: Kelly Hall <hall@priest.com>
Date: Sat, 01 Dec 2001 11:41:40 GMT
Links: << >>  << T >>  << A >>
Neil Franklin <neil@franklin.ch.remove> writes:

> Kelly Hall <hall@priest.com> writes:
> 
> > The vendors are giving away decent tools for the low-end FPGAs and
> > CPLDs these days.
> 
> Sort of. As far any closed-source tool they can not be user-extended
> can be called decent.

No argument from me.  But my primary concern is finding cheap/free
software to support my configurable hardware hobby.  I don't care
whether the software I don't pay for is free because the part vendor
gives it away or because some geeks decided to write some EDA tool in
their spare time.  I just want to download my HDL into some chip.

Although vendor supplied tools are not user-extendable, they seem to
work pretty well.  Certainly they are better than the open-source
alternatives at this point in time.

> Open source is not about free as in free beer. It is about free as in
> no limitations, as in being able to take any idea and realise it,
> subject only to ones own limits such as skill or time limits.

It seems to me that you want open-source software for configurable
hardware for some political or philosophical agenda.  Personally, I
want free software for configurable hardware to be able to write VHDL
and Verilog and AHDL and ABEL for my small projects at home.  If there
was no free software for this purpose, I'd find some other project to
work on, or return to designing circuits out of 74xx series ICs and
PALs.

Your needs are sufficient to satisfy my needs, but not necessary to
satisfy mine.

I wonder if the open-source versus vendor-supplied argument as applied
to EDA tools mirrors the situation with professional-quality machinist
tools.  It's certainly annoying that a good quality Bridgeport milling
machine is too expensive for me to put in my garage; and yet, I've
worked a several companies that have purchased them and not given it a
second thought.  Any mill I can afford to own myself is of much lower
quality than the Bridgeport.  There are several published designs for
making your own milling machine at home for little or no cost;
however, the quality is highly inferior to that of high- or mid-range
commercial equipment.

Are you annoyed that high-end EDA tools cost so much, or that the
open-source tools are so inferior to the commercial ones?

Kelly

Article: 37144
Subject: New book: Real Chip DSGN and Verification, Verilog/VHDL
From: vhdlcohen@aol.com (VhdlCohen)
Date: 01 Dec 2001 17:36:58 GMT
Links: << >>  << T >>  << A >>
I am pleased to announce the release of the new book a new book "Real Chip
Design and Verification Using Verilog and VHDL".  You'll find this book very
interesting and applicable to current users and as a training book.  This is a
book that I wished I had when I was doing designs and training.  I found during
my consulting and training experiences that students of HDLs had more trouble
with design concepts than with the HDLs.  That book is targeted for current
design engineers because it addresses design issues, with HDL as a vehicle for
implementation.  Book is also intended for users who want to transition into
the "other" HDL,  and for students of HDLs.  

>From foreword: "Ben bridges the gaps in a designer's knowledge, he covers the
gaps left by other texts ... bridges simulation and synthesis, and this
acknowledges that implementation and verification must both be done in design"
Synplicity.  
"This book is one of the best investments that a logic designer can make"
Cadence. 

"Real Chip Design and Verification Using Verilog and VHDL", ISBN 0-9705394-2-8 
VhdlCohen Publishing, November 2001, 420 pages. 
This book addresses the practical and real aspects of logic design, processes,
and verification. It incorporates a collection of FPGA and ASIC design
practices expressed in Verilog and VHDL. Topics: 1. Architectural decomposition
process; 2. Fundamental elements including synchronous edge detector, counter
styles (e.g., Binary, One-Hot, Gray, Johnson), memories (ROM. RAM, FIFO), EDAC,
cell primitives and impact on architecture, clocking schemes and PLL; 3.
Asynchronous world, metastability, asynchronous FIFO, crossing clock domains;
4. Transaction-based verification methodology, forcing errors, counter and EDAC
verification models; 5. Control machines and implementation methodologies with
FSM and microprogrammed solutions; 6. Arithmetic machines, HDL Signed and
Unsigned types; 7. Mixed mode simulations and synthesis; 8. Minimizing design
errors; 9. Verilog/VHDL comparison, Verilog for VHDL users, Verilog coding
style guidelines.    CD included with lots of goodies.  
For book information/purchase see http://www.vhdlcohen.com/ 
----------------------------------------------------------------------------
Ben Cohen     Publisher, Trainer, Consultant    (310) 721-4830  
http://www.vhdlcohen.com/                 vhdlcohen@aol.com  
Author of following textbooks: 
* Real Chip Design and Verification Using Verilog and VHDL, 2002 isbn
0-9705394-2-8 
* Component Design by Example ",  2001 isbn  0-9705394-0-1
* VHDL Coding Styles and Methodologies, 2nd Edition, 1999 isbn 0-7923-8474-1
* VHDL Answers to Frequently Asked Questions, 2nd Edition, isbn 0-7923-8115
------------------------------------------------------------------------------

Article: 37145
Subject: Re: 128-bit scrambling and CRC computations
From: rickman <spamgoeshere4@yahoo.com>
Date: Sat, 01 Dec 2001 13:10:53 -0500
Links: << >>  << T >>  << A >>
Ovidiu Lupas 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.
> 
> Thanks,
> Ovidiu

That is exactly where we were doing it. I belive this is CRC-16, right?
If you can't do pipelining at all because you need to match delays with
other cell processing, then you will have about 128 inputs to the XOR
tree. This will take four levels of logic (4 input LUTs) if you can
force the synthesizer to keep the tree balanced. 

The Altera parts can use a fast cascade which is much faster than a LUT,
but is serial much like a carry bit. Four levels of cascade should work
pretty well to eliminate a LUT and keep the speed up. You will need to
play with the sythesis controls a bit to get this working or instantiate
it. 

In the Xilinx parts you can't use the Block RAM unless you can pipeline.
the RAM is synchronous and requires a clock. But it will take much more
RAMs than are on a chip, so this won't work regardless. With no
minimization, this is a BIG hunk of logic at about 5,500 LUTs!!!

Take a good look at your architecture. You should be able to pipeline
this. One way is to delay the data in parallel paths by one register. It
only uses 128 FFs and may save you a lot of grief when you make changes
to the design and the timing breaks. Also keep in mind that logic can be
shared between bits. 

Good luck!

-- 

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: 37146
Subject: Re: Is there a full open-source synthesis path for any FPGA?
From: rickman <spamgoeshere4@yahoo.com>
Date: Sat, 01 Dec 2001 13:40:56 -0500
Links: << >>  << T >>  << A >>
Nial Stewart wrote:
> 
> rickman wrote:
> >
> 
> > 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.
> 
> I've never liked Maxplus2 much, I never really got the feeling that
> I had control of what's going on, but then I never had to push any
> designs _really_ hard with it.
> 
> >  Or is ACEX supported by the (non free?) Quartus tools
> > now?
> 
> Yes, and it seems a much better tool.
> 
> Nial.

I learned a few things about the tools and software. The tools don't
really show you the routing. They just give you a rat's nest of here to
there. The 10K chip architecture is supposed to give you predictable
delays via a heirarchy of routing. But when push comes to shove, if "you
can't get there from here, go somewhere else first and start from
there". I think this is what prevented the chip from meeting timing both
in analysis and even when we passed analysis, it would fail in
temperature testing. 

ACEX is supported by the paid Quartus tools, but oddly enough, not in
the free version. You HAVE to use the MaxPlus+II Baseline if you want
free ACEX tools. Too bad. ACEX would be a good solution to the Spartan
II startup current problem. :(  But I need for my customers to be able
to get free tools that work. 

-- 

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: 37147
Subject: Re: Is there a full open-source synthesis path for any FPGA?
From: Neil Franklin <neil@franklin.ch.remove>
Date: 01 Dec 2001 19:49:38 +0100
Links: << >>  << T >>  << A >>
rickman <spamgoeshere4@yahoo.com> writes:

> Neil Franklin wrote:
> >
> > rickman <spamgoeshere4@yahoo.com> writes:
> >
> > > The small volume customers don't count. The high volume customers will
> >
> > At present. But they are the source that tomorrows high volume people
> > come from. So why hinder them? It is not as if publishing the formats
> > were an large expensive to avoid.
>
> You are completely missing my point. If you start as a low volume user
> and move to a company that spends BIG bucks on FPGAs, your approach to
> FPGA selection and design will change to match the model of the BIG
> company. You could have been a loyal Ralph's FPGAs customer for the last

If one goes to an big-user company, yes.

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.

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.


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


> > I think it will be. FPGAs are just entering the spotlight of
> > hackers. They are about where microprocessors were 1975. I expect the
> > next 5 years to be similarly furious as the 75-80 was for micros.
> >
> > And yes that is a prediction, we will see if it turns out.
>
> If you want to do something useful, find a way to support design for
> partial reconfiguration.

Not of much use to me, at present, as I am aiming for an fixed board spec.
First learn to walk, then to run.


> As it stands, the last several generations of
> Xilinx, Lucent, Atmel and perhaps Altera chips have all supported
> partial reconfiguration. This lets you download just part of an FPGA
> without affecting the rest.

Yup. With Virtex single config frames (of which 48 give an column of CLBs).


> save a lot of bucks on the next design if I could use one large FPGA and
> use partial reconfiguration for this same result.

Sounds like it would.


> suggested that I take a look at JBITs, but I would still have to do all
> the mapping/partitioning myself. Way too much work.

For an commercial outfit that could be a problem.


> Care to take a look at this?

Is not on my forseeable path.


--
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: 37148
Subject: Re: Is there a full open-source synthesis path for any FPGA?
From: Neil Franklin <neil@franklin.ch.remove>
Date: 01 Dec 2001 20:03:41 +0100
Links: << >>  << T >>  << A >>
Kelly Hall <hall@priest.com> writes:

> Neil Franklin <neil@franklin.ch.remove> writes:
>
> > Sort of. As far any closed-source tool they can not be user-extended
> > can be called decent.
>
> No argument from me.  But my primary concern is finding cheap/free
> software to support my configurable hardware hobby.  I don't care
>
> > Open source is not about free as in free beer. It is about free as in
> > no limitations, as in being able to take any idea and realise it,
> > subject only to ones own limits such as skill or time limits.
>
> It seems to me that you want open-source software for configurable
> hardware for some political or philosophical agenda.

More philosophical. I just prefer being unlimited.


> want free software for configurable hardware to be able to write VHDL
> and Verilog and AHDL and ABEL for my small projects at home.

Which is what I (for forseeable future) will be doing.


> was no free software for this purpose, I'd find some other project to
> work on, or return to designing circuits out of 74xx series ICs and
> PALs.

There is one difference. I want to do this project I have (computer
system cloning), which requires either an FPGA or lots of space/cost
using small chips.


> I wonder if the open-source versus vendor-supplied argument as applied
> to EDA tools mirrors the situation with professional-quality machinist
> tools.  It's certainly annoying that a good quality Bridgeport milling
> machine is too expensive for me to put in my garage;

Difference here: the Bridgeport has an high per-issue (manufacturing)
cost, making hardware consists of mining/shaping/assembling atoms,
that just is expensive. 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.


> Are you annoyed that high-end EDA tools cost so much,

No, they have authors to pay. Let those pay them, who want their tools.


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


--
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: 37149
Subject: Re: 128-bit scrambling and CRC computations
From: nweaver@CSUA.Berkeley.EDU (Nicholas Weaver)
Date: Sat, 1 Dec 2001 19:10:12 +0000 (UTC)
Links: << >>  << T >>  << A >>
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



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