Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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 ApplicationsArticle: 37126
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
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 ApplicationsArticle: 37128
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’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: 37129I 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’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’s tools, or even one revision of a vendor’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
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 RobberyArticle: 37131
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 RobberyArticle: 37132
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 RobberyArticle: 37133
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 AlfkeArticle: 37134
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-4473Article: 37135
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 TreselerArticle: 37136
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
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. -- glenArticle: 37138
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. -- glenArticle: 37139
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 thisArticle: 37140
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
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’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’s tools, or even >one revision of a vendor’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
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? KellyArticle: 37144
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
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 FAXArticle: 37146
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 FAXArticle: 37147
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 RobberyArticle: 37148
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 RobberyArticle: 37149
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:
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