From: Chris Carlen Newsgroups: comp.arch.fpga Subject: Xilinx Webpack bugs bugs bugs Date: Wed, 25 Jun 2003 11:44:41 -0700 Organization: Sandia National Laboratories, Albuquerque, NM USA Lines: 100 Message-ID: NNTP-Posting-Host: mango.ran.sandia.gov Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sass2141.sandia.gov 1056566606 20229 134.252.41.24 (25 Jun 2003 18:43:26 GMT) X-Complaints-To: usenet@sass2141.sandia.gov NNTP-Posting-Date: Wed, 25 Jun 2003 18:43:26 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!enews.sgi.com!news.sandia.gov!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:29963 Hi: Here's a chronicle of today's headaches. 1. ECS schematic editor can't deal with filenames that contain anything except 0-9 a-z A-Z . 2. I selected a large block of schematic, and when I tried to move it, ECS said "Internal Error: Delete Branch" 3. I guess nobody uses schematic entry because the editor is simply impossible to use. It is an absolute disaster. I try to select a group of objects to move, and it simply won't let me select them. They don't highlight. I try to select everything I have drawn to move it, and I get error mentioned in #2 above. The autorouting is useless. Get rid of it. Hint: humans are smarter than computers. Just let me draw my own wires. 4. Oh good grief, I moved some things, and then I simply cannot select anything anymore. You see folks, when you make software this bad, even if it is free, rather than making me want to pay for the "good" software, it makes me think you simply can't write good software. What evidence do I have that if I pay for your non-free tools, that they will be any better? None. On the contrary, I have volumous evidence that I will simply be paying for the exact same thing, only I will not only be frustrated, but poorer. The end result is the same. I can't use your silicon. So perhaps I have made a big mistake. Perhaps I should have gone with Altera. I just don't know now. Or perhaps analog design would be a way to avoid all this crap altogether. I don't seem to have much trouble with SPICE simulators. Heck even Linear Technology's LTSpice *FREE* simulator is very useable. Argh! 5. I closed the schematic editor hoping that if I re-opened my file it might reset som eof its internal data structures, and start working again. Now I try to reopen my schematic source from Project Navigator, and nothing happens. It simply sits there when I click "open". Nope this is reality. Bummer. Aha! Project Navigator couldn't open my source because it didn't have the same name that I created it with. I created it as "cross32-52" which Project Navigator accepted just fine. But ECS wouldn't save the file with this name, even though it opened it the first time. So I saved it as something else, which of course broke Project Navigator. Well that's certainly my fault. I should have expected ECS to not save filenames with '-' characters. 6. After closing everything an reopening, I can select and move things in ECS again. Oh joy! 7. I wanted to start a new project to develop a modified version of a previous design done from scratch in 5.2i. I copied the .sch and .ucf files to the new project dir. I can edit the schematic, so I deleted some stuff I didn't want in there. Then I can't open the .ucf file because it has nets that aren't in the schematic. I don't know why in the original project, when I would add or remove nets from the schematic, the user constraints file was automatically updated to reflect the nets in the schematic. This doesn't work now, but perhaps it's because there is some file missing. So I will remove the .ucf source and add a new one which I'll set up from scratch. I click "remove" and then I add a new source, a user constraints with the same name as the one that isn't working. Project NAvigator prompts me if I want to overwrite the old file. I click "Ok" and expect that when I open the new .ucf file, it will be a reflection of the nets in my schematic. No such luck, the broken .ucf was not everwritten, so it still complains of errors of missing nets. Well that's all before lunch time. Let's see what happens this afternoon... I guess if there's a point to all this, I should look around on Xilinx's web site some more and find out where to report bugs. But I have reached a point with software in general where I am tired of doing this. That is because, I often wind up spending hours reporting the bugs in the rigorous detail that is needed if there is to be any hope of anyone actually fixing them. Unless of course, the software had been rigorously tested in the first place. -- _______________________________________________________________________ Christopher R. Carlen Principal Laser/Optical Technologist Sandia National Laboratories CA USA crcarle@sandia.gov -- NOTE: Remove "BOGUS" from email address to reply. ###### From: rickman Newsgroups: comp.arch.fpga Subject: Re: Xilinx Webpack bugs bugs bugs Date: Wed, 25 Jun 2003 18:14:44 -0400 Organization: Arius, Inc Lines: 136 Message-ID: <3EFA1ED4.16F6B3C3@yahoo.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVYoMFllrK06AqBLKSmWxaUPJeTfWLZ5UZMA7FY12gMkfp2kshPCTYas X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 25 Jun 2003 22:13:52 GMT X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:29981 Yes, you have discovered the not-so-secret of the lack of bug support for schematic users. I can't say this is unique to Xilinx since I have never tried schematic with Altera parts. But I expect the problem will not get better with time. I can say I am a bit surprised. A few years ago Xilinx was using an editor that was not perfect, but worked ok. I guess this was something they were paying for per license and were eating the cost. To save that fee I assume they switched to something they bought or wrote in house. Regardless, you will be better off using an HDL than schematics. A lot of people fought tooth and nail against HDL, but it is a better solution for large designs and the FPGA vendors really don't want to have to support both. So the support for schematic is not good simply because not many people use it and why spend money supporting something that is little used. I know you are thinking, "why have it if you don't support it?" I can't answer that one, you will need to ask X and A. But I can say you are definitely swimming upstream with schematic capture. I know I did my last schematic design some years ago and will not look back (or look the schematics up :) Keep in mind the number of bugs you have found so far and you only worked for half a day. Wait until you try to place and route your schematic design! You will really be having fun then! Just think of all the newer chip features and how poorly they will be supported via schematic. Chris Carlen wrote: > > Hi: > > Here's a chronicle of today's headaches. > > 1. ECS schematic editor can't deal with filenames that contain anything > except 0-9 a-z A-Z . > > 2. I selected a large block of schematic, and when I tried to move it, > ECS said "Internal Error: Delete Branch" > > 3. I guess nobody uses schematic entry because the editor is simply > impossible to use. It is an absolute disaster. I try to select a group > of objects to move, and it simply won't let me select them. They don't > highlight. I try to select everything I have drawn to move it, and I > get error mentioned in #2 above. The autorouting is useless. Get rid > of it. Hint: humans are smarter than computers. Just let me draw my > own wires. > > 4. Oh good grief, I moved some things, and then I simply cannot select > anything anymore. > > You see folks, when you make software this bad, even if it is free, > rather than making me want to pay for the "good" software, it makes me > think you simply can't write good software. What evidence do I have > that if I pay for your non-free tools, that they will be any better? > None. On the contrary, I have volumous evidence that I will simply be > paying for the exact same thing, only I will not only be frustrated, but > poorer. The end result is the same. I can't use your silicon. > > So perhaps I have made a big mistake. Perhaps I should have gone with > Altera. I just don't know now. > > Or perhaps analog design would be a way to avoid all this crap > altogether. I don't seem to have much trouble with SPICE simulators. > Heck even Linear Technology's LTSpice *FREE* simulator is very useable. > > Argh! > > 5. I closed the schematic editor hoping that if I re-opened my file it > might reset som eof its internal data structures, and start working > again. Now I try to reopen my schematic source from Project Navigator, > and nothing happens. It simply sits there when I click "open". > > > > Nope this is reality. Bummer. > > Aha! Project Navigator couldn't open my source because it didn't have > the same name that I created it with. I created it as "cross32-52" > which Project Navigator accepted just fine. But ECS wouldn't save the > file with this name, even though it opened it the first time. So I > saved it as something else, which of course broke Project Navigator. > Well that's certainly my fault. I should have expected ECS to not save > filenames with '-' characters. > > 6. After closing everything an reopening, I can select and move things > in ECS again. Oh joy! > > 7. I wanted to start a new project to develop a modified version of a > previous design done from scratch in 5.2i. I copied the .sch and .ucf > files to the new project dir. I can edit the schematic, so I deleted > some stuff I didn't want in there. Then I can't open the .ucf file > because it has nets that aren't in the schematic. I don't know why in > the original project, when I would add or remove nets from the > schematic, the user constraints file was automatically updated to > reflect the nets in the schematic. This doesn't work now, but perhaps > it's because there is some file missing. > > So I will remove the .ucf source and add a new one which I'll set up > from scratch. I click "remove" and then I add a new source, a user > constraints with the same name as the one that isn't working. Project > NAvigator prompts me if I want to overwrite the old file. I click "Ok" > and expect that when I open the new .ucf file, it will be a reflection > of the nets in my schematic. > > No such luck, the broken .ucf was not everwritten, so it still complains > of errors of missing nets. > > Well that's all before lunch time. Let's see what happens this afternoon... > > I guess if there's a point to all this, I should look around on Xilinx's > web site some more and find out where to report bugs. But I have > reached a point with software in general where I am tired of doing this. > That is because, I often wind up spending hours reporting the bugs in > the rigorous detail that is needed if there is to be any hope of anyone > actually fixing them. Unless of course, the software had been > rigorously tested in the first place. > > -- > _______________________________________________________________________ > Christopher R. Carlen > Principal Laser/Optical Technologist > Sandia National Laboratories CA USA > crcarle@sandia.gov -- NOTE: Remove "BOGUS" from email address to reply. -- 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 ###### Reply-To: "Martin Euredjian" <0_0_0_0_@pacbell.net> From: "Martin Euredjian" <0_0_0_0_@pacbell.net> Newsgroups: comp.arch.fpga References: <3EFA1ED4.16F6B3C3@yahoo.com> Subject: Re: Xilinx Webpack bugs bugs bugs Lines: 31 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: NNTP-Posting-Host: 64.170.224.250 X-Complaints-To: abuse@prodigy.net X-Trace: newssvr14.news.prodigy.com 1056584845 ST000 64.170.224.250 (Wed, 25 Jun 2003 19:47:25 EDT) NNTP-Posting-Date: Wed, 25 Jun 2003 19:47:25 EDT Organization: SBC http://yahoo.sbc.com X-UserInfo1: T[OYR_CD[JWIRVH]^JKBOW@@YJ_ZTB\MV@B@LWQHBATBTSUBYFWEAE[YJLYPIWKHTFCMZKVMB^[Z^DOBRVVMOSPFHNSYXVDIE@X\BUC@GTSX@DL^GKFFHQCCE\G[JJBMYDYIJCZM@AY]GNGPJD]YNNW\GSX^GSCKHA[]@CCB\[@LATPD\L@J\\PF]VR[QPJN Date: Wed, 25 Jun 2003 23:47:25 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!irazu.switch.ch!switch.ch!news.maxwell.syr.edu!newsfeed-east.nntpserver.com!nntpserver.com!news3.optonline.net!rip!news.webusenet.com!prodigy.com!newsmst01.news.prodigy.com!prodigy.com!postmaster.news.prodigy.com!newssvr14.news.prodigy.com.POSTED!003b42bf!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:29992 Not putting down Xilinx software particularly. Other than not generating instantiation templates from Verilog2001-style port declarations I haven't had many issues --knock on wood. However, it has been my opinion for several years now that the state of EDA/Electronics CAD sofware is absolutely deplorable. I've spent thousands upon thousands of dollars on EDA tools that have bugs and ideosyncracies that would make the software a business failure in any other market ... yet engineers seem to put up with it ... and EDA companies don't seem to give a hoot about getting these things fixed. If you are in the sub-$10K US range they've got you by the gonads because the next strata is up well above $30K and past $100K. So, they almost don't have to worry because the playing field is so limited. I absolutely despise the EDA tool I'm using, but after having put nearly $10k into it, what are you going to do, go spend another $10K? It's high time for some guy in a garage to get excited about this and create something for engineering, by engineers that puts bad software in the proper context. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu" ###### From: Steve Lass Newsgroups: comp.arch.fpga Subject: Re: Xilinx Webpack bugs bugs bugs Date: Wed, 25 Jun 2003 18:06:51 -0600 Organization: Xilinx Lines: 108 Message-ID: <3EFA391B.4000806@xilinx.com> References: Reply-To: lass@xilinx.com NNTP-Posting-Host: 149.199.186.43 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!colt.net!news.tele.dk!news.tele.dk!small.news.tele.dk!enews.sgi.com!nntp.wetware.com!attdv1!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:29982 Chris, What version are you running? It sounds like you may be using an older version and possibly have some misconceptions about how the tools work together. Steve Chris Carlen wrote: > Hi: > > Here's a chronicle of today's headaches. > > 1. ECS schematic editor can't deal with filenames that contain > anything except 0-9 a-z A-Z . > > 2. I selected a large block of schematic, and when I tried to move > it, ECS said "Internal Error: Delete Branch" > > 3. I guess nobody uses schematic entry because the editor is simply > impossible to use. It is an absolute disaster. I try to select a > group of objects to move, and it simply won't let me select them. > They don't highlight. I try to select everything I have drawn to move > it, and I get error mentioned in #2 above. The autorouting is > useless. Get rid of it. Hint: humans are smarter than computers. > Just let me draw my own wires. > > 4. Oh good grief, I moved some things, and then I simply cannot > select anything anymore. > > You see folks, when you make software this bad, even if it is free, > rather than making me want to pay for the "good" software, it makes me > think you simply can't write good software. What evidence do I have > that if I pay for your non-free tools, that they will be any better? > None. On the contrary, I have volumous evidence that I will simply be > paying for the exact same thing, only I will not only be frustrated, > but poorer. The end result is the same. I can't use your silicon. > > So perhaps I have made a big mistake. Perhaps I should have gone with > Altera. I just don't know now. > > Or perhaps analog design would be a way to avoid all this crap > altogether. I don't seem to have much trouble with SPICE simulators. > Heck even Linear Technology's LTSpice *FREE* simulator is very useable. > > Argh! > > > 5. I closed the schematic editor hoping that if I re-opened my file > it might reset som eof its internal data structures, and start working > again. Now I try to reopen my schematic source from Project > Navigator, and nothing happens. It simply sits there when I click > "open". > > dream.> > > Nope this is reality. Bummer. > > Aha! Project Navigator couldn't open my source because it didn't have > the same name that I created it with. I created it as "cross32-52" > which Project Navigator accepted just fine. But ECS wouldn't save the > file with this name, even though it opened it the first time. So I > saved it as something else, which of course broke Project Navigator. > Well that's certainly my fault. I should have expected ECS to not > save filenames with '-' characters. > > 6. After closing everything an reopening, I can select and move > things in ECS again. Oh joy! > > 7. I wanted to start a new project to develop a modified version of a > previous design done from scratch in 5.2i. I copied the .sch and .ucf > files to the new project dir. I can edit the schematic, so I deleted > some stuff I didn't want in there. Then I can't open the .ucf file > because it has nets that aren't in the schematic. I don't know why in > the original project, when I would add or remove nets from the > schematic, the user constraints file was automatically updated to > reflect the nets in the schematic. This doesn't work now, but perhaps > it's because there is some file missing. > > So I will remove the .ucf source and add a new one which I'll set up > from scratch. I click "remove" and then I add a new source, a user > constraints with the same name as the one that isn't working. Project > NAvigator prompts me if I want to overwrite the old file. I click > "Ok" and expect that when I open the new .ucf file, it will be a > reflection of the nets in my schematic. > > No such luck, the broken .ucf was not everwritten, so it still > complains of errors of missing nets. > > > Well that's all before lunch time. Let's see what happens this > afternoon... > > > I guess if there's a point to all this, I should look around on > Xilinx's web site some more and find out where to report bugs. But I > have reached a point with software in general where I am tired of > doing this. That is because, I often wind up spending hours reporting > the bugs in the rigorous detail that is needed if there is to be any > hope of anyone actually fixing them. Unless of course, the software > had been rigorously tested in the first place. > > > ###### NNTP-Posting-Date: Wed, 25 Jun 2003 21:24:07 -0500 From: "Patrick MacGregor" Newsgroups: comp.arch.fpga References: Subject: Re: Xilinx Webpack bugs bugs bugs Date: Wed, 25 Jun 2003 22:23:48 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: Lines: 195 NNTP-Posting-Host: 68.55.246.189 X-Trace: sv3-whGIhXmWqAaoFZZ92V+G0rpH3PorCpDyyQ1TrqAO729zb/AKU3aP8kkSSYQ2vm9N+2fXTWY8axt89ex!ZhohsyfXKMz/+R/53BE4PbgfgQM0wH55q/wwvRBvXBb94xuatYT4MAeoygncMA== X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.1 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!wn14feed!worldnet.att.net!216.166.71.14!border3.nntp.aus1.giganews.com!intern1.nntp.aus1.giganews.com!nntp.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:30019 Amen brother! The "pay" tools are essentially the same, and work just as deplorably. I have a copy of ISE 5.2, and it uses the same sorry excuse for a schematic editor. I invented the "hexplitive", which was swearing in base 16, when working with X schematic tools. Xilinx clearly has no interest in catering to the schematic entry crowd and their tools show it. Their schematic tools are about as good as something like OrCad was -- OrCad from 15 years ago running under DOS that is. I have worked exclusively with Altera tools since the late '80s because their support for schematics was SO MUCH better. There is simply no comparison. I think that for most FPGA designs, X or A parts would work just fine. However, the crap you have to go through to use X tools was never worth it. Still isn't in my book. Their tools can take a one day design and turn it into a week of rebooting and hair pulling. I also can't buy into the HDL argument. The reason is simple. If you were a software developer and you needed your code to be as small as possible and run as fast as possible, what language would you use? Well, every software developer I've ever met answers the same -- native assembly language for the processor in question. No compiled code will be more efficient because of the layers of abstraction that higher level languages impose. The embedded developers I've worked with always got a good chuckle out of their C language counterparts sucking up 100's of kilobytes of memory compared to the few K that their assembly code needed. HDL is the same. You abstract designs (so that non-designers can pretend to be designers I suppose) and pay a penalty by having circuit bloat. If you want the smallest design possible, and want it to run as fast as possible, you need to use the design equivalent of assembly coding -- i.e. schematics. A picture is worth a thousand words, so you can make a picture or type a thousand words. Which one will be easier for someone else to understand, hmm? I recently talked to an FAE for an FPGA vendor. He said that fully 80% of the designs he has seen are done in schematics. You can even read about graphical versions of HDL coming out. Sounds like schematics to me. Except that you add a layer of obfuscation in there that will make for a more bloated design. Why bother? An ironic thing to notice is that if you open many of the X design examples included with the tools, you'll see that they are schematic based. With a schematic it is sooooo simple to identify each and every flop and see what it is doing in a simulation. Something isn't working in HDL? Good luck. Oh yeah, and with schematics, you never have to do all that modeling nonsense. While most "designers" are modeling what their circuit is supposed to do, I've already got it done, simulated, verified on the bench, off my plate and onto the next thing. I was taught the power of schematics and their companion, the timing diagram, when I was a wee engineer pup. My first boss would sit me down and go over the schematics with me, asking me to justify each and every component on the page. If there wasn't a good reason for it, it was gone. Amongst the many invaluable lessons he taught me was that every component in the circuit should have a reason. Try doing that with an HDL abstraction. Most "designers" haven't a clue how that hunk of code they wrote got implemented in actual gates. Scott Adams would probably call them "Duhsigners". So, I'm with you 100%. Schematics rule. Xilinx has no reason whatsoever to support schematics, as the bloated designs that HDLs produce force folks into buying larger, faster speed grade parts that are naturally more costly. Works for them. You can always download the free Altera tools and play with their stuff. Fully integrated schematic capture, compiler and simulator. Very nice. Not perfect or bug free, but then no tool is. It is, however, VASTLY superior to the X garbage schematic tools. When I need to design something in an X part, I do it first in the A tools and use their native simulater. Then I re-enter it in X. Doing the drawings twice is STILL faster than doing the design from scratch in X. Try it. I tend to always push my clients to use A parts simply because the tools are so superior. Design times are radically reduced, and that saves them tangible money. If they insist on X parts, I revert to the paragraph above. Don't buy into the HDL propaganda. Schematics will never do you wrong. "Chris Carlen" wrote in message news:bdcqge$jo5$1@sass2141.sandia.gov... > Hi: > > Here's a chronicle of today's headaches. > > 1. ECS schematic editor can't deal with filenames that contain anything > except 0-9 a-z A-Z . > > 2. I selected a large block of schematic, and when I tried to move it, > ECS said "Internal Error: Delete Branch" > > 3. I guess nobody uses schematic entry because the editor is simply > impossible to use. It is an absolute disaster. I try to select a group > of objects to move, and it simply won't let me select them. They don't > highlight. I try to select everything I have drawn to move it, and I > get error mentioned in #2 above. The autorouting is useless. Get rid > of it. Hint: humans are smarter than computers. Just let me draw my > own wires. > > 4. Oh good grief, I moved some things, and then I simply cannot select > anything anymore. > > You see folks, when you make software this bad, even if it is free, > rather than making me want to pay for the "good" software, it makes me > think you simply can't write good software. What evidence do I have > that if I pay for your non-free tools, that they will be any better? > None. On the contrary, I have volumous evidence that I will simply be > paying for the exact same thing, only I will not only be frustrated, but > poorer. The end result is the same. I can't use your silicon. > > So perhaps I have made a big mistake. Perhaps I should have gone with > Altera. I just don't know now. > > Or perhaps analog design would be a way to avoid all this crap > altogether. I don't seem to have much trouble with SPICE simulators. > Heck even Linear Technology's LTSpice *FREE* simulator is very useable. > > Argh! > > > 5. I closed the schematic editor hoping that if I re-opened my file it > might reset som eof its internal data structures, and start working > again. Now I try to reopen my schematic source from Project Navigator, > and nothing happens. It simply sits there when I click "open". > > > > Nope this is reality. Bummer. > > Aha! Project Navigator couldn't open my source because it didn't have > the same name that I created it with. I created it as "cross32-52" > which Project Navigator accepted just fine. But ECS wouldn't save the > file with this name, even though it opened it the first time. So I > saved it as something else, which of course broke Project Navigator. > Well that's certainly my fault. I should have expected ECS to not save > filenames with '-' characters. > > 6. After closing everything an reopening, I can select and move things > in ECS again. Oh joy! > > 7. I wanted to start a new project to develop a modified version of a > previous design done from scratch in 5.2i. I copied the .sch and .ucf > files to the new project dir. I can edit the schematic, so I deleted > some stuff I didn't want in there. Then I can't open the .ucf file > because it has nets that aren't in the schematic. I don't know why in > the original project, when I would add or remove nets from the > schematic, the user constraints file was automatically updated to > reflect the nets in the schematic. This doesn't work now, but perhaps > it's because there is some file missing. > > So I will remove the .ucf source and add a new one which I'll set up > from scratch. I click "remove" and then I add a new source, a user > constraints with the same name as the one that isn't working. Project > NAvigator prompts me if I want to overwrite the old file. I click "Ok" > and expect that when I open the new .ucf file, it will be a reflection > of the nets in my schematic. > > No such luck, the broken .ucf was not everwritten, so it still complains > of errors of missing nets. > > > Well that's all before lunch time. Let's see what happens this afternoon... > > > I guess if there's a point to all this, I should look around on Xilinx's > web site some more and find out where to report bugs. But I have > reached a point with software in general where I am tired of doing this. > That is because, I often wind up spending hours reporting the bugs in > the rigorous detail that is needed if there is to be any hope of anyone > actually fixing them. Unless of course, the software had been > rigorously tested in the first place. > > > > -- > _______________________________________________________________________ > Christopher R. Carlen > Principal Laser/Optical Technologist > Sandia National Laboratories CA USA > crcarle@sandia.gov -- NOTE: Remove "BOGUS" from email address to reply. > ###### Newsgroups: comp.arch.fpga Subject: Re: Xilinx Webpack bugs bugs bugs Reply-To: tom3@protectedfromreality.com References: Message-ID: Content-Type: text/plain; charset=iso-8859-15; format=flowed From: Thomas Organization: Protected From Reality MIME-Version: 1.0 User-Agent: Opera7.11/Win32 M2 build 2887 Lines: 114 Date: Thu, 26 Jun 2003 04:41:07 GMT NNTP-Posting-Host: 68.66.186.243 X-Complaints-To: abuse@adelphia.net X-Trace: news3.news.adelphia.net 1056602467 68.66.186.243 (Thu, 26 Jun 2003 00:41:07 EDT) NNTP-Posting-Date: Thu, 26 Jun 2003 00:41:07 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!router1.news.adelphia.net!router3.news.adelphia.net!news3.news.adelphia.net.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:30034 can't agree more. I come from a software development background, so maybe I've been a bit more spoiled by the tools, but the xilinx suite is totally ridiculous; this is a totally retarded design (from a software perspective). I can't imagine paying for that; even if the pay version is ten times better, it wouldn't be worth $50. All tools have a lame interface, they are buggy, they have a disfunctional way of communicating and a totally sparse and useless documentation. the vendor question is still up in the air for us, and I think that just for that reason I am going to go against xilinx; no matter how good the chips can be, user support and tools are key; they have neither. On Wed, 25 Jun 2003 11:44:41 -0700, Chris Carlen wrote: > Hi: > > Here's a chronicle of today's headaches. > > 1. ECS schematic editor can't deal with filenames that contain anything > except 0-9 a-z A-Z . > > 2. I selected a large block of schematic, and when I tried to move it, > ECS said "Internal Error: Delete Branch" > > 3. I guess nobody uses schematic entry because the editor is simply > impossible to use. It is an absolute disaster. I try to select a group > of objects to move, and it simply won't let me select them. They don't > highlight. I try to select everything I have drawn to move it, and I get > error mentioned in #2 above. The autorouting is useless. Get rid of it. > Hint: humans are smarter than computers. Just let me draw my own wires. > > 4. Oh good grief, I moved some things, and then I simply cannot select > anything anymore. > > You see folks, when you make software this bad, even if it is free, > rather than making me want to pay for the "good" software, it makes me > think you simply can't write good software. What evidence do I have that > if I pay for your non-free tools, that they will be any better? None. On > the contrary, I have volumous evidence that I will simply be paying for > the exact same thing, only I will not only be frustrated, but poorer. > The end result is the same. I can't use your silicon. > > So perhaps I have made a big mistake. Perhaps I should have gone with > Altera. I just don't know now. > > Or perhaps analog design would be a way to avoid all this crap > altogether. I don't seem to have much trouble with SPICE simulators. > Heck even Linear Technology's LTSpice *FREE* simulator is very useable. > > Argh! > > > 5. I closed the schematic editor hoping that if I re-opened my file it > might reset som eof its internal data structures, and start working > again. Now I try to reopen my schematic source from Project Navigator, > and nothing happens. It simply sits there when I click "open". > > dream.> > > Nope this is reality. Bummer. > > Aha! Project Navigator couldn't open my source because it didn't have > the same name that I created it with. I created it as "cross32-52" which > Project Navigator accepted just fine. But ECS wouldn't save the file > with this name, even though it opened it the first time. So I saved it > as something else, which of course broke Project Navigator. Well that's > certainly my fault. I should have expected ECS to not save filenames > with '-' characters. > > 6. After closing everything an reopening, I can select and move things > in ECS again. Oh joy! > > 7. I wanted to start a new project to develop a modified version of a > previous design done from scratch in 5.2i. I copied the .sch and .ucf > files to the new project dir. I can edit the schematic, so I deleted > some stuff I didn't want in there. Then I can't open the .ucf file > because it has nets that aren't in the schematic. I don't know why in > the original project, when I would add or remove nets from the schematic, > the user constraints file was automatically updated to reflect the nets > in the schematic. This doesn't work now, but perhaps it's because there > is some file missing. > > So I will remove the .ucf source and add a new one which I'll set up from > scratch. I click "remove" and then I add a new source, a user > constraints with the same name as the one that isn't working. Project > NAvigator prompts me if I want to overwrite the old file. I click "Ok" > and expect that when I open the new .ucf file, it will be a reflection of > the nets in my schematic. > > No such luck, the broken .ucf was not everwritten, so it still complains > of errors of missing nets. > > > Well that's all before lunch time. Let's see what happens this > afternoon... > > > I guess if there's a point to all this, I should look around on Xilinx's > web site some more and find out where to report bugs. But I have reached > a point with software in general where I am tired of doing this. That is > because, I often wind up spending hours reporting the bugs in the > rigorous detail that is needed if there is to be any hope of anyone > actually fixing them. Unless of course, the software had been rigorously > tested in the first place. > > > ###### Newsgroups: comp.arch.fpga Subject: Re: Xilinx Webpack bugs bugs bugs Reply-To: tom3@protectedfromreality.com References: Message-ID: Content-Type: text/plain; charset=iso-8859-15; format=flowed From: Thomas Organization: Protected From Reality MIME-Version: 1.0 User-Agent: Opera7.11/Win32 M2 build 2887 Lines: 253 Date: Thu, 26 Jun 2003 04:51:50 GMT NNTP-Posting-Host: 68.66.186.243 X-Complaints-To: abuse@adelphia.net X-Trace: news3.news.adelphia.net 1056603110 68.66.186.243 (Thu, 26 Jun 2003 00:51:50 EDT) NNTP-Posting-Date: Thu, 26 Jun 2003 00:51:50 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!router1.news.adelphia.net!router3.news.adelphia.net!news3.news.adelphia.net.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:30036 I read with interest your thoughts about hdl vs schematics and the parallel with software I've developped software for 14 years and while at heart I agree with you, in my day to day practice I disagree. Assembler will always provide you a most optimized solution, but C/C++ is much faster to develop with and is more accessible; btw, that's assuming you have competent engineers writing assembler, otherwise it turns into a mess very quick. yes, you definetly lower the efficiency of the resource usage with a higher level language, but nowadays it is cheaper to get faster / bigger hardware than more engineers / time. the days where we used to build things right are over; now the key is how fast you can put something on the market; it's sad, but the tech industry is not what it used to be. I have never been too much in touch with the hardware industry, but lately it has changed and I realize that you guys have the exact same issues / concerns / problems / etc we have in software; kind of ironic, in a sad way. Thomas. On Wed, 25 Jun 2003 22:23:48 -0400, Patrick MacGregor wrote: > Amen brother! > > The "pay" tools are essentially the same, and work just as deplorably. I > have a copy of ISE 5.2, and it uses the same sorry excuse for a schematic > editor. I invented the "hexplitive", which was swearing in base 16, when > working with X schematic tools. > > Xilinx clearly has no interest in catering to the schematic entry crowd > and > their tools show it. Their schematic tools are about as good as > something > like OrCad was -- OrCad from 15 years ago running under DOS that is. > > I have worked exclusively with Altera tools since the late '80s because > their support for schematics was SO MUCH better. There is simply no > comparison. I think that for most FPGA designs, X or A parts would work > just fine. However, the crap you have to go through to use X tools was > never worth it. Still isn't in my book. Their tools can take a one day > design and turn it into a week of rebooting and hair pulling. > > I also can't buy into the HDL argument. The reason is simple. If you > were > a software developer and you needed your code to be as small as possible > and > run as fast as possible, what language would you use? Well, every > software > developer I've ever met answers the same -- native assembly language for > the > processor in question. No compiled code will be more efficient because > of > the layers of abstraction that higher level languages impose. The > embedded > developers I've worked with always got a good chuckle out of their C > language counterparts sucking up 100's of kilobytes of memory compared to > the few K that their assembly code needed. > > HDL is the same. You abstract designs (so that non-designers can pretend > to > be designers I suppose) and pay a penalty by having circuit bloat. If > you > want the smallest design possible, and want it to run as fast as > possible, > you need to use the design equivalent of assembly coding -- i.e. > schematics. > A picture is worth a thousand words, so you can make a picture or type a > thousand words. Which one will be easier for someone else to understand, > hmm? > > I recently talked to an FAE for an FPGA vendor. He said that fully 80% > of > the designs he has seen are done in schematics. You can even read about > graphical versions of HDL coming out. Sounds like schematics to me. > Except > that you add a layer of obfuscation in there that will make for a more > bloated design. Why bother? > > An ironic thing to notice is that if you open many of the X design > examples > included with the tools, you'll see that they are schematic based. > > With a schematic it is sooooo simple to identify each and every flop and > see > what it is doing in a simulation. Something isn't working in HDL? Good > luck. Oh yeah, and with schematics, you never have to do all that > modeling > nonsense. While most "designers" are modeling what their circuit is > supposed to do, I've already got it done, simulated, verified on the > bench, > off my plate and onto the next thing. > > I was taught the power of schematics and their companion, the timing > diagram, when I was a wee engineer pup. My first boss would sit me down > and > go over the schematics with me, asking me to justify each and every > component on the page. If there wasn't a good reason for it, it was > gone. > Amongst the many invaluable lessons he taught me was that every component > in > the circuit should have a reason. Try doing that with an HDL > abstraction. > Most "designers" haven't a clue how that hunk of code they wrote got > implemented in actual gates. Scott Adams would probably call them > "Duhsigners". > > > > So, I'm with you 100%. Schematics rule. Xilinx has no reason whatsoever > to > support schematics, as the bloated designs that HDLs produce force folks > into buying larger, faster speed grade parts that are naturally more > costly. Works for them. > > You can always download the free Altera tools and play with their stuff. > Fully integrated schematic capture, compiler and simulator. Very nice. > Not > perfect or bug free, but then no tool is. It is, however, VASTLY > superior > to the X garbage schematic tools. > > When I need to design something in an X part, I do it first in the A > tools > and use their native simulater. Then I re-enter it in X. Doing the > drawings twice is STILL faster than doing the design from scratch in X. > Try > it. > > I tend to always push my clients to use A parts simply because the tools > are > so superior. Design times are radically reduced, and that saves them > tangible money. If they insist on X parts, I revert to the paragraph > above. > > Don't buy into the HDL propaganda. Schematics will never do you wrong. > > > > > > > "Chris Carlen" wrote in message > news:bdcqge$jo5$1@sass2141.sandia.gov... >> Hi: >> >> Here's a chronicle of today's headaches. >> >> 1. ECS schematic editor can't deal with filenames that contain anything >> except 0-9 a-z A-Z . >> >> 2. I selected a large block of schematic, and when I tried to move it, >> ECS said "Internal Error: Delete Branch" >> >> 3. I guess nobody uses schematic entry because the editor is simply >> impossible to use. It is an absolute disaster. I try to select a group >> of objects to move, and it simply won't let me select them. They don't >> highlight. I try to select everything I have drawn to move it, and I >> get error mentioned in #2 above. The autorouting is useless. Get rid >> of it. Hint: humans are smarter than computers. Just let me draw my >> own wires. >> >> 4. Oh good grief, I moved some things, and then I simply cannot select >> anything anymore. >> >> You see folks, when you make software this bad, even if it is free, >> rather than making me want to pay for the "good" software, it makes me >> think you simply can't write good software. What evidence do I have >> that if I pay for your non-free tools, that they will be any better? >> None. On the contrary, I have volumous evidence that I will simply be >> paying for the exact same thing, only I will not only be frustrated, but >> poorer. The end result is the same. I can't use your silicon. >> >> So perhaps I have made a big mistake. Perhaps I should have gone with >> Altera. I just don't know now. >> >> Or perhaps analog design would be a way to avoid all this crap >> altogether. I don't seem to have much trouble with SPICE simulators. >> Heck even Linear Technology's LTSpice *FREE* simulator is very useable. >> >> Argh! >> >> >> 5. I closed the schematic editor hoping that if I re-opened my file it >> might reset som eof its internal data structures, and start working >> again. Now I try to reopen my schematic source from Project Navigator, >> and nothing happens. It simply sits there when I click "open". >> >> > dream.> >> >> Nope this is reality. Bummer. >> >> Aha! Project Navigator couldn't open my source because it didn't have >> the same name that I created it with. I created it as "cross32-52" >> which Project Navigator accepted just fine. But ECS wouldn't save the >> file with this name, even though it opened it the first time. So I >> saved it as something else, which of course broke Project Navigator. >> Well that's certainly my fault. I should have expected ECS to not save >> filenames with '-' characters. >> >> 6. After closing everything an reopening, I can select and move things >> in ECS again. Oh joy! >> >> 7. I wanted to start a new project to develop a modified version of a >> previous design done from scratch in 5.2i. I copied the .sch and .ucf >> files to the new project dir. I can edit the schematic, so I deleted >> some stuff I didn't want in there. Then I can't open the .ucf file >> because it has nets that aren't in the schematic. I don't know why in >> the original project, when I would add or remove nets from the >> schematic, the user constraints file was automatically updated to >> reflect the nets in the schematic. This doesn't work now, but perhaps >> it's because there is some file missing. >> >> So I will remove the .ucf source and add a new one which I'll set up >> from scratch. I click "remove" and then I add a new source, a user >> constraints with the same name as the one that isn't working. Project >> NAvigator prompts me if I want to overwrite the old file. I click "Ok" >> and expect that when I open the new .ucf file, it will be a reflection >> of the nets in my schematic. >> >> No such luck, the broken .ucf was not everwritten, so it still complains >> of errors of missing nets. >> >> >> Well that's all before lunch time. Let's see what happens this > afternoon... >> >> >> I guess if there's a point to all this, I should look around on Xilinx's >> web site some more and find out where to report bugs. But I have >> reached a point with software in general where I am tired of doing this. >> That is because, I often wind up spending hours reporting the bugs in >> the rigorous detail that is needed if there is to be any hope of anyone >> actually fixing them. Unless of course, the software had been >> rigorously tested in the first place. >> >> >> >> -- >> _______________________________________________________________________ >> Christopher R. Carlen >> Principal Laser/Optical Technologist >> Sandia National Laboratories CA USA >> crcarle@sandia.gov -- NOTE: Remove "BOGUS" from email address to reply. >> > > > ###### From: Bob Perlman Newsgroups: comp.arch.fpga Subject: Re: Xilinx Webpack bugs bugs bugs Message-ID: <2n1lfvc59946vn6slnetjbb76i6kdljfm7@4ax.com> References: X-Newsreader: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 32 Date: Thu, 26 Jun 2003 06:06:14 GMT NNTP-Posting-Host: 67.123.5.212 X-Complaints-To: abuse@sonic.net X-Trace: typhoon.sonic.net 1056607574 67.123.5.212 (Wed, 25 Jun 2003 23:06:14 PDT) NNTP-Posting-Date: Wed, 25 Jun 2003 23:06:14 PDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!news.maxwell.syr.edu!out.nntp.be!propagator2-sterling!In.nntp.be!feed.news.sonic.net!typhoon.sonic.net!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:30028 Hi - The this-tool-is-no-damn-good thread pops up every few weeks. I don't use the ECS schematic editor, so I can't comment on the its quality or lack thereof. And I certainly don't want to get embroiled in the schematics-vs-HDL debate which, along with cockroaches, will be the only thing to survive a nuclear holocaust. But I will make a couple of observations. First, use tools that have lots of users. Any tool developer will spend more time fixing and maintaining popular tools than those used only by a handful of people. And, the merits of HDLs aside, is there any doubt that even the least popular FPGA HDL synthesis tool has at least ten times as many users as ECS? I know, I know--this isn't fair. But that's the way it is. Unless you're Mr. Cisco, of course. Second, use only those tools that add real value. There are some Xilinx tools--the FPGA editor, PACE, the floorplanner--that have a useful GUI . In fact, these tools wouldn't make much sense without a GUI. But does Project Navigator really add that much value over and above a decent batch file that invokes tools from the command line? Maybe the uber-GUI that ties all the tools together makes sense for some users, but to me it's just one more thing that can break or do inexplicable things. All I'm saying is, don't use a tool just because it's there; the benefit should exceed the pain. And I agree - the Linear Tech SPICE tool is very nice. The fact that it's free doesn't hurt, either. Bob Perlman Cambrian Design Works ###### From: rickman Newsgroups: comp.arch.fpga Subject: Re: Xilinx Webpack bugs bugs bugs Date: Thu, 26 Jun 2003 02:32:23 -0400 Organization: Arius, Inc Lines: 130 Message-ID: <3EFA9377.E87AB5E7@yahoo.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVbMnB7fCkdfYQFm8eNC3+nM3kawBSZ4HUMuuwtuDtH5BRaZSwX6MNPV X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 26 Jun 2003 06:31:18 GMT X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:29985 Patrick MacGregor wrote: > > Amen brother! > > The "pay" tools are essentially the same, and work just as deplorably. I > have a copy of ISE 5.2, and it uses the same sorry excuse for a schematic > editor. I invented the "hexplitive", which was swearing in base 16, when > working with X schematic tools. > ...snip... > I also can't buy into the HDL argument. The reason is simple. If you were > a software developer and you needed your code to be as small as possible and > run as fast as possible, what language would you use? Well, every software > developer I've ever met answers the same -- native assembly language for the > processor in question. No compiled code will be more efficient because of > the layers of abstraction that higher level languages impose. The embedded > developers I've worked with always got a good chuckle out of their C > language counterparts sucking up 100's of kilobytes of memory compared to > the few K that their assembly code needed. But you ignore the fact that very few embedded engineers need their code to be "as small as possible" or "fast as possible". That is because the hardware gives lots of head room for very few bucks. Likewise FPGAs generally are more than fast enough and large enough and cheap enough (did *I* say that?) for 95% of the designs to be done in HDL. Again for the same reason that few designers do an entire project in assembly, I won't be doing any more schematic designs. The last one I did was a PITA to draw the gates needed for FSM design or worse, address decoding. Data path is not bad in schematic, but the random logic is no fun at all and it takes up so much space when you try to view a large design. I don't mean disk space, I mean viewing space. I can view an equivalent project in a text editor much more easily than a schematic editor. > HDL is the same. You abstract designs (so that non-designers can pretend to > be designers I suppose) and pay a penalty by having circuit bloat. If you > want the smallest design possible, and want it to run as fast as possible, > you need to use the design equivalent of assembly coding -- i.e. schematics. > A picture is worth a thousand words, so you can make a picture or type a > thousand words. Which one will be easier for someone else to understand, > hmm? There are lots of reasons to use HDLs, but trying to enable uneducated hardware designers (or worse, software designers) is not one of them. I feel that to properly use an HDL you need to know what you expect for hardware and then describe that in the HDL. But again, very few people have to have the "smallest" or the "fastest" design. Mostly they have goals which include schedules. As to the picture and word analogy, I find the words to suit design better. It takes a large picture and a lot of time to create it, to equal those thousand words. > I recently talked to an FAE for an FPGA vendor. He said that fully 80% of > the designs he has seen are done in schematics. You can even read about > graphical versions of HDL coming out. Sounds like schematics to me. Except > that you add a layer of obfuscation in there that will make for a more > bloated design. Why bother? I don't know where you got this, but this sounds like an exaggeration. I would say he had it backwards, but I bet the schematic usage is less than 20%. > An ironic thing to notice is that if you open many of the X design examples > included with the tools, you'll see that they are schematic based. > > With a schematic it is sooooo simple to identify each and every flop and see > what it is doing in a simulation. Something isn't working in HDL? Good > luck. Oh yeah, and with schematics, you never have to do all that modeling > nonsense. While most "designers" are modeling what their circuit is > supposed to do, I've already got it done, simulated, verified on the bench, > off my plate and onto the next thing. If you don't feel the need to simulate, then you are clearly doing very simple designs. The simulation is to make sure you are solving the problem rather than just knowing what you are creating. These are two different problems. > I was taught the power of schematics and their companion, the timing > diagram, when I was a wee engineer pup. My first boss would sit me down and > go over the schematics with me, asking me to justify each and every > component on the page. If there wasn't a good reason for it, it was gone. > Amongst the many invaluable lessons he taught me was that every component in > the circuit should have a reason. Try doing that with an HDL abstraction. > Most "designers" haven't a clue how that hunk of code they wrote got > implemented in actual gates. Scott Adams would probably call them > "Duhsigners". > > > > So, I'm with you 100%. Schematics rule. Xilinx has no reason whatsoever to > support schematics, as the bloated designs that HDLs produce force folks > into buying larger, faster speed grade parts that are naturally more > costly. Works for them. > > You can always download the free Altera tools and play with their stuff. > Fully integrated schematic capture, compiler and simulator. Very nice. Not > perfect or bug free, but then no tool is. It is, however, VASTLY superior > to the X garbage schematic tools. > > When I need to design something in an X part, I do it first in the A tools > and use their native simulater. Then I re-enter it in X. Doing the > drawings twice is STILL faster than doing the design from scratch in X. Try > it. > > I tend to always push my clients to use A parts simply because the tools are > so superior. Design times are radically reduced, and that saves them > tangible money. If they insist on X parts, I revert to the paragraph above. > > Don't buy into the HDL propaganda. Schematics will never do you wrong. No, but they will take more time and make large jobs nearly impossible. -- 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 ###### From: Martin Thompson Newsgroups: comp.arch.fpga Subject: Re: Xilinx Webpack bugs bugs bugs Date: 26 Jun 2003 08:58:15 +0100 Organization: TRW Conekt Lines: 70 Sender: thompsonmj@1WVMP0J-DT Message-ID: References: NNTP-Posting-Host: 194.74.228.66 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: fu-berlin.de 1056614298 29880774 194.74.228.66 (16 [98603]) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.stueberl.de!fu-berlin.de!uni-berlin.de!194.74.228.66!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:30038 "Patrick MacGregor" writes: > I also can't buy into the HDL argument. The reason is simple. If you were > a software developer and you needed your code to be as small as possible and > run as fast as possible, what language would you use? Well, every software > developer I've ever met answers the same -- native assembly language for the > processor in question. No compiled code will be more efficient because of > the layers of abstraction that higher level languages impose. The embedded > developers I've worked with always got a good chuckle out of their C > language counterparts sucking up 100's of kilobytes of memory compared to > the few K that their assembly code needed. > The point as already been made that very few people write the whole thing in assembly. > HDL is the same. You abstract designs (so that non-designers can pretend to > be designers I suppose) and pay a penalty by having circuit bloat. If you > want the smallest design possible, and want it to run as fast as possible, > you need to use the design equivalent of assembly coding -- i.e. schematics. > A picture is worth a thousand words, so you can make a picture or type a > thousand words. Which one will be easier for someone else to understand, > hmm? > HDL doesn't force abstration - you can write gate-level HDL. There are illustrious people populating this group who frequently do the "design equivalent of assembly coding" in HDL. Come to think of it, last time I did a schematic I used the "abstraction" of a counter block, which hides flops inside it. Only if you know how to make a counter do you know "where every flop is". And that's the same in HDL - I know I've written code that will mean a counter gets built, so I know what flops there are there. > > With a schematic it is sooooo simple to identify each and every flop and see > what it is doing in a simulation. Something isn't working in HDL? Good > luck. Oh yeah, and with schematics, you never have to do all that modeling > nonsense. While most "designers" are modeling what their circuit is > supposed to do, I've already got it done, simulated, verified on the bench, > off my plate and onto the next thing. > What do you do when your two BGA packages aren;t talking to each other and you haven't got the chance (because of signal integrity concerns) to put a probe point on the board? I go back to my simulation, with its models and all that 'waste of time'. Another advantage of this approach is that I can write a testbench that covers all my (many) testcases and reports a pass or fail at the end. That way I can modify any code I like and know I haven't recreated any old bugs. Not quite so easy when staring at waveforms... Just some thoughts from the other side! Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt, Solihull, UK http://www.trw.com/conekt ###### From: mrand@my-deja.com (Marc Randolph) Newsgroups: comp.arch.fpga Subject: Re: Xilinx Webpack bugs bugs bugs Date: 26 Jun 2003 04:59:43 -0700 Organization: http://groups.google.com/ Lines: 33 Message-ID: <15881dde.0306260359.3668e36c@posting.google.com> References: NNTP-Posting-Host: 66.138.72.45 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1056628784 5842 127.0.0.1 (26 Jun 2003 11:59:44 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 26 Jun 2003 11:59:44 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!cyclone.bc.net!newsfeed.stanford.edu!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:30024 "Patrick MacGregor" wrote in message news:... [snip] > HDL is the same. You abstract designs (so that non-designers can pretend to > be designers I suppose) and pay a penalty by having circuit bloat. If you > want the smallest design possible, and want it to run as fast as possible, > you need to use the design equivalent of assembly coding -- i.e. schematics. [snip] > Don't buy into the HDL propaganda. Schematics will never do you wrong. I believe your assumptions and comparisons of HDL are incorrect. HDL is not a normal programming language, and as such, can't be compared to something like C. And it does not cause circuit bloat. Incorrectly coded HDL can, but that's not the fault of the HDL - just like inefficient assembly code (yes, there is such a thing) is not the fault of the assembler. And I'm am certainly not anti-schematic - I've done two decent sized designs recently in Renoir. But the sole reason I do them in schematic form is to help myself and any others get a graphical picture of what is going on because they are somewhat complex designs. It has NOTHING to do with the coding or implementation efficiency - because it is not more efficient - at best, it is on par. And as Rick pointed out, on large designs it is difficult to "see" what is going on because when you zoom out, you can't see details, and when you zoom in, you lose some of the big picture. Lastly, FPGA's don't have many of the things you put in schematics. Do you use ONLY 4 input LUTs and D-FF's on your schematics? If you use much more than that, you are using a form of abstraction as well. Have fun, Marc ###### From: "David Brown" Newsgroups: comp.arch.fpga Subject: Re: Xilinx Webpack bugs bugs bugs Date: Thu, 26 Jun 2003 14:32:49 +0200 Organization: NetPower AS Lines: 77 Message-ID: References: NNTP-Posting-Host: 81.29.36.21 X-Trace: news.netpower.no 1056630044 16905 81.29.36.21 (26 Jun 2003 12:20:44 GMT) X-Complaints-To: abuse@netpower.no NNTP-Posting-Date: Thu, 26 Jun 2003 12:20:44 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.ifi.unizh.ch!news.imp.ch!news.imp.ch!newsfeed.stueberl.de!feed.news.nacamar.de!uio.no!nntp.newmedia.no!newsfeed1.enitel.no!news.netpower.no!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:30008 > > I also can't buy into the HDL argument. The reason is simple. If you were > a software developer and you needed your code to be as small as possible and > run as fast as possible, what language would you use? Well, every software > developer I've ever met answers the same -- native assembly language for the > processor in question. No compiled code will be more efficient because of > the layers of abstraction that higher level languages impose. The embedded > developers I've worked with always got a good chuckle out of their C > language counterparts sucking up 100's of kilobytes of memory compared to > the few K that their assembly code needed. > > HDL is the same. You abstract designs (so that non-designers can pretend to > be designers I suppose) and pay a penalty by having circuit bloat. If you > want the smallest design possible, and want it to run as fast as possible, > you need to use the design equivalent of assembly coding -- i.e. schematics. > A picture is worth a thousand words, so you can make a picture or type a > thousand words. Which one will be easier for someone else to understand, > hmm? > I am an embedded systems programmer, and do a little bit of PLD design. I can't comment on X's schematic software - I have never used it, and I never will. I am expecting to work on a Xilinx fpga design soon, and I will use either VHDL or Verilog. Everyone is entitled to their own opinions, I suppose, but your comments on C and assembly programming just do not match reality. There are plenty of cases where assembly is the appropriate language - I program with small micros, which are wholy unsuited to high-level language. I also program in C on micros that are more suited for C, and I am well-versed in the sort of assembly code the C compilers generate. The reality is that for small, limited micros, assembly can be significantly faster and more compact - say half the size and double the speed for a good assembly programmer as compared to a good embedded C programmer (i.e., one that knows how to get the best out of a small micro), and maybe the same again compared to a good general C programmer. For big micros, especially 32-bitters, a good C programmer and a good C compiler will beat a good assembly programmer every time - bar a few, specialised routines where it is worth highly optomising assembly code. The idea of a compiler producing 100 K of bloat for 1K of program is laughable (or a very badly configured linker...). Now, I know that theoretically an assembly programmer could beat the compiler - after all, there is nothing that the compiler can do that the assembler programmer cannot do. But writing optimal assembly for big micros is a long, hard job, and programmers must balance writing optimal code with writing correct, maintainable, flexible and readible code. As a quick example, if the program requires a divide by a constant, the C compiler may optimise this to multiplying by its reciprical, and (assuming the micro does not have hardware multiplication), it might produce a series of in-line shifts and adds. If the assembler programmer expects that this constant might change, he would write a general divide routine - it is bigger and slower than the compiler-generated code, but far more understandable and more flexible for the future. FPGA design is the same. Some things can be better expressed as schematics, especially for small designs, and some designers will work better with schematics than HDL depending on their background, experiance, and interests. But to suggest that schematics are always easier to understand, or to design, or will always generate faster/smaller circuits, is just silly. And as for a picture being worth a thousand words, please draw me a picture that gives the equivilent information to the sentence "I'm taking my family on holiday to Finland in a couple of weeks, where we will be visiting Mumminland, Helsinki zoo, and a number of other attractions". I'm sure you could draw such a picture, and it would look very nice, but it would take far longer to draw and be much less accurate than the sentence. ###### Message-ID: <3EFAEA24.2246D39F@attbi.com> From: Phil Hays Organization: phil-hays at above domain X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Xilinx Webpack bugs bugs bugs References: <15881dde.0306260359.3668e36c@posting.google.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 16 NNTP-Posting-Host: 12.207.230.186 X-Complaints-To: abuse@attbi.com X-Trace: rwcrnsc51.ops.asp.att.net 1056631287 12.207.230.186 (Thu, 26 Jun 2003 12:41:27 GMT) NNTP-Posting-Date: Thu, 26 Jun 2003 12:41:27 GMT Date: Thu, 26 Jun 2003 12:41:27 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!news.tele.dk!news.tele.dk!small.news.tele.dk!newsfeed.icl.net!newsfeed.fjserv.net!news.stealth.net news.stealth.net!news.stealth.net!204.127.161.6.MISMATCH!wn12feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi.com!rwcrnsc51.ops.asp.att.net.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:29978 Marc Randolph wrote: > Lastly, FPGA's don't have many of the things you put in schematics. > Do you use ONLY 4 input LUTs and D-FF's on your schematics? If you > use much more than that, you are using a form of abstraction as well. A larger abstraction used in schematics is the "wire" connecting between FF's and LUT's. This "wire" is an abstraction for a significant number of switch boxes, muxes and pips. FPGAs are more interconnect logic than user logic. -- Phil Hays ###### NNTP-Posting-Date: Thu, 26 Jun 2003 09:08:37 -0500 From: "Patrick MacGregor" Newsgroups: comp.arch.fpga References: Subject: Re: Xilinx Webpack bugs bugs bugs Date: Thu, 26 Jun 2003 10:08:20 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: Lines: 38 NNTP-Posting-Host: 68.55.246.189 X-Trace: sv3-6bBEpNO3o037qxapfj+GzRAsVPJUGV3ZOwnl6jCU2ymorhtTk2HTEod4uW0V6ka1KvPT+QuLl/4vCIh!QgvPq15UJ0xtZpdzJkvodjxvmHrAKPHUm0tmyI9EC6F1ePEwbnCUKtw8IZOA1A== X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.1 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!small1.nntp.aus1.giganews.com!border1.nntp.aus1.giganews.com!intern1.nntp.aus1.giganews.com!nntp.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:30016 "Thomas" wrote in message news:oprrcygwqomo2d8p@news3.news.adelphia.net... > I read with interest your thoughts about hdl vs schematics and the parallel > with software > I've developped software for 14 years and while at heart I agree with you, > in my day to day practice I disagree. Assembler will always provide you a > most optimized solution, but C/C++ is much faster to develop with and is > more accessible; btw, that's assuming you have competent engineers writing > assembler, otherwise it turns into a mess very quick. yes, you definetly > lower the efficiency of the resource usage with a higher level language, > but nowadays it is cheaper to get faster / bigger hardware than more > engineers / time. > the days where we used to build things right are over; now the key is how > fast you can put something on the market; it's sad, but the tech industry > is not what it used to be. > I have never been too much in touch with the hardware industry, but lately > it has changed and I realize that you guys have the exact same issues / > concerns / problems / etc we have in software; kind of ironic, in a sad > way. > > Thomas. The assembly level guys I've worked with were every bit as fast as their C counterparts when developing code. If you do it a lot, you get good, fast and efficient at it. And as with HW design, you create a bag of tricks you employ to speed the next jobs along, as well as developing a library of previously designed pieces you can employ later. There is just no reason why you can't design quickly and correctly at the same time. That is one key difference between a newbie and someone with a lot of experience. It is then incumbent on the experienced folks to pass along knowledge to the newbies to speed their development into capable, competent designers. Nothing beats experience. ###### NNTP-Posting-Date: Thu, 26 Jun 2003 09:32:38 -0500 From: "Patrick MacGregor" Newsgroups: comp.arch.fpga References: <3EFA9377.E87AB5E7@yahoo.com> Subject: Re: Xilinx Webpack bugs bugs bugs Date: Thu, 26 Jun 2003 10:32:21 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: <0bWdnYD1_eGamWajU-KYvA@comcast.com> Lines: 241 NNTP-Posting-Host: 68.55.246.189 X-Trace: sv3-Y9Nrn8PolMBHEDcMUwEQp4gwfe3UhVU4hnifs1oMuShbmwVDD6lMhev4e3pCZhb39WEOaBtH1GIXNrj!BDO7v5YgNgHr2/eXMrKTCXsZZgnOFXGdYkWrOKXsPhLsz3vkXsH4t1hFrkt4EQ== X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.1 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!news2.euro.net!216.166.71.118.MISMATCH!small1.nntp.aus1.giganews.com!border3.nntp.aus1.giganews.com!intern1.nntp.aus1.giganews.com!nntp.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:30015 "rickman" wrote in message news:3EFA9377.E87AB5E7@yahoo.com... > Patrick MacGregor wrote: > > > > Amen brother! > > > > The "pay" tools are essentially the same, and work just as deplorably. I > > have a copy of ISE 5.2, and it uses the same sorry excuse for a schematic > > editor. I invented the "hexplitive", which was swearing in base 16, when > > working with X schematic tools. > > > ...snip... > > I also can't buy into the HDL argument. The reason is simple. If you were > > a software developer and you needed your code to be as small as possible and > > run as fast as possible, what language would you use? Well, every software > > developer I've ever met answers the same -- native assembly language for the > > processor in question. No compiled code will be more efficient because of > > the layers of abstraction that higher level languages impose. The embedded > > developers I've worked with always got a good chuckle out of their C > > language counterparts sucking up 100's of kilobytes of memory compared to > > the few K that their assembly code needed. > > But you ignore the fact that very few embedded engineers need their code > to be "as small as possible" or "fast as possible". That is because the > hardware gives lots of head room for very few bucks. Likewise FPGAs > generally are more than fast enough and large enough and cheap enough > (did *I* say that?) for 95% of the designs to be done in HDL. > In 20 years in this business (primarily telecom/datacom), I've never once had a situation where bloat was allowed. Bloat = added cost that doesn't go away. You burden every finished product with unecessary cost simply by poor design practices. A few dollars difference in parts doesn't mean much when you build 10. But when you built 100,000 it suddenly means a lot. I've had to sweat R's and C's many times, trying to remove as many as possible, and then try to make the remaining ones use similar values as much as possible -- all to try and minimize costs (cost of parts, cost of time for the person ordering different parts, cost of warehousing -- it all counts if you think about it). Having recently done an OC48 framer design (in a couple of weeks), I could have easily aimed at something like a 1C6 or 1C12 Cyclone part. Instead I aimed for a 1C3 part in the slowest speed grade. Works just fine, using about 1/3 of the LCs. A 1C3 costs 1/2 of a 1C6 roughly, yet the 1C6 is not "expensive". Choosing to design efficiently added exactly zero time penalty but yielded tremendous cost savings. > Again for the same reason that few designers do an entire project in > assembly, I won't be doing any more schematic designs. The last one I > did was a PITA to draw the gates needed for FSM design or worse, address > decoding. Data path is not bad in schematic, but the random logic is no > fun at all and it takes up so much space when you try to view a large > design. I don't mean disk space, I mean viewing space. I can view an > equivalent project in a text editor much more easily than a schematic > editor. > One startup I worked for had an embedded designer assigned to one or more ATM interface cards. These guys wrote in assembly only, and because of this were able to keep up with ATM at OC-3 rates using a very slow, primitive (i.e. inexpensive) micro. The fact that random gate design being "no fun at all" and "taking up a lot of space" suggests a few things to me. First, there are some simple rules for making a clean, legible schematic. Too bad schools never teach them. Also, I firmly believe that nearly anyone can make a functioning design given enough time. This doesn't make it a good design. Some designs are better than others, and one way to get to the "good design" stage is to get your fingers into the gates and learn how to work with them efficiently. I regularly test whether or not an HDL can create logic more efficiently than me. It can't. Not once has it implemented any type of decoding function better than I can. It can match me in terms of resources utilized, but it can't best me. By staying in the gates, I always have an instant grasp of how large a design is getting. I stopped one major piece of that OC48 design simply because it was getting too large. I knew that because I could see it on the page and in the floorplanner. Seeing the size forced me to think about other ways to implement the process. The first way worked, but so what? Not good enough. I needed to reduce the size to stay comfortably in the smaller part. > > > HDL is the same. You abstract designs (so that non-designers can pretend to > > be designers I suppose) and pay a penalty by having circuit bloat. If you > > want the smallest design possible, and want it to run as fast as possible, > > you need to use the design equivalent of assembly coding -- i.e. schematics. > > A picture is worth a thousand words, so you can make a picture or type a > > thousand words. Which one will be easier for someone else to understand, > > hmm? > > There are lots of reasons to use HDLs, but trying to enable uneducated > hardware designers (or worse, software designers) is not one of them. I > feel that to properly use an HDL you need to know what you expect for > hardware and then describe that in the HDL. But again, very few people > have to have the "smallest" or the "fastest" design. Mostly they have > goals which include schedules. > The best HDL folks I know are ones who use it like it was a schematic. So, in my mind, why bother? And again, I've never had the luxury of NOT needing the smallest/fastest design. It's how I push 4 OC48s through a $30 part, saving a client millions on NOT needing to buy a bunch of expensive ASSPs for every board. Size does count, and I can proudly say that "mine is smaller than yours". ;-) > As to the picture and word analogy, I find the words to suit design > better. It takes a large picture and a lot of time to create it, to > equal those thousand words. > Some folks are visual and some folks prefer the written word. I'm obviously visual for circuits and have no problem using the written word, like now, for example. > > > I recently talked to an FAE for an FPGA vendor. He said that fully 80% of > > the designs he has seen are done in schematics. You can even read about > > graphical versions of HDL coming out. Sounds like schematics to me. Except > > that you add a layer of obfuscation in there that will make for a more > > bloated design. Why bother? > > I don't know where you got this, but this sounds like an exaggeration. > I would say he had it backwards, but I bet the schematic usage is less > than 20%. > I got this right from the horse's mouth. I didn't make it up. It was his observation of designs he's seeing. Why would he lie? He has no vested interest in any method his clients use. Simply the stats he sees. > > An ironic thing to notice is that if you open many of the X design examples > > included with the tools, you'll see that they are schematic based. > > > > With a schematic it is sooooo simple to identify each and every flop and see > > what it is doing in a simulation. Something isn't working in HDL? Good > > luck. Oh yeah, and with schematics, you never have to do all that modeling > > nonsense. While most "designers" are modeling what their circuit is > > supposed to do, I've already got it done, simulated, verified on the bench, > > off my plate and onto the next thing. > > If you don't feel the need to simulate, then you are clearly doing very > simple designs. The simulation is to make sure you are solving the > problem rather than just knowing what you are creating. These are two > different problems. > Guess you missed it when I said I simulated the designs, right before testing them on the bench. I never skip simulating. Again though, I prefer the graphical waveform version as I get to see a nice, pretty picture of what is happening and when. It is very simple to pull up any flop in the design and see it relative to anything else. Makes debugging go 10 times faster. And, once I'm happy with it, I can transfer the simulator results back into the input file so that I can compare expected to generated results should I make changes or add new stuff. What could be simpler? > > > I was taught the power of schematics and their companion, the timing > > diagram, when I was a wee engineer pup. My first boss would sit me down and > > go over the schematics with me, asking me to justify each and every > > component on the page. If there wasn't a good reason for it, it was gone. > > Amongst the many invaluable lessons he taught me was that every component in > > the circuit should have a reason. Try doing that with an HDL abstraction. > > Most "designers" haven't a clue how that hunk of code they wrote got > > implemented in actual gates. Scott Adams would probably call them > > "Duhsigners". > > > > > > > > So, I'm with you 100%. Schematics rule. Xilinx has no reason whatsoever to > > support schematics, as the bloated designs that HDLs produce force folks > > into buying larger, faster speed grade parts that are naturally more > > costly. Works for them. > > > > You can always download the free Altera tools and play with their stuff. > > Fully integrated schematic capture, compiler and simulator. Very nice. Not > > perfect or bug free, but then no tool is. It is, however, VASTLY superior > > to the X garbage schematic tools. > > > > When I need to design something in an X part, I do it first in the A tools > > and use their native simulater. Then I re-enter it in X. Doing the > > drawings twice is STILL faster than doing the design from scratch in X. Try > > it. > > > > I tend to always push my clients to use A parts simply because the tools are > > so superior. Design times are radically reduced, and that saves them > > tangible money. If they insist on X parts, I revert to the paragraph above. > > > > Don't buy into the HDL propaganda. Schematics will never do you wrong. > > No, but they will take more time and make large jobs nearly impossible. For the duhsigner, perhaps. Personally, I've never found any job too large for schematics, whether doing ASICs or FPGAs. And, you need schematics to design PCBs, so the extra practice doesn't hurt. > > -- > > 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 ###### NNTP-Posting-Date: Thu, 26 Jun 2003 09:41:58 -0500 From: "Patrick MacGregor" Newsgroups: comp.arch.fpga References: Subject: Re: Xilinx Webpack bugs bugs bugs Date: Thu, 26 Jun 2003 10:41:36 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: Lines: 127 NNTP-Posting-Host: 68.55.246.189 X-Trace: sv3-jd9GPOcV849VAU3ylXRqNK7DHeF+WxkGgiwD0jnaF/CjJjfGS8PSl2JxeeDB0c3NiTrwD/0crQhzkGl!5sm/GBylw76PFdzkf2eRXPSvivvk9rhtmFrM8488re8bokPtgvIgfL5FiGZ4Gg== X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.1 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.ifi.unizh.ch!news.imp.ch!news.imp.ch!newsfeed.vmunix.org!peer02.cox.net!cox.net!newsfeed2.easynews.com!newsfeed1.easynews.com!easynews.com!easynews!border3.nntp.aus1.giganews.com!intern1.nntp.aus1.giganews.com!nntp.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:30018 "Martin Thompson" wrote in message news:uk7b9z2w8.fsf@trw.com... > "Patrick MacGregor" writes: > > > I also can't buy into the HDL argument. The reason is simple. If you were > > a software developer and you needed your code to be as small as possible and > > run as fast as possible, what language would you use? Well, every software > > developer I've ever met answers the same -- native assembly language for the > > processor in question. No compiled code will be more efficient because of > > the layers of abstraction that higher level languages impose. The embedded > > developers I've worked with always got a good chuckle out of their C > > language counterparts sucking up 100's of kilobytes of memory compared to > > the few K that their assembly code needed. > > > > The point as already been made that very few people write the whole > thing in assembly. > > > HDL is the same. You abstract designs (so that non-designers can pretend to > > be designers I suppose) and pay a penalty by having circuit bloat. If you > > want the smallest design possible, and want it to run as fast as possible, > > you need to use the design equivalent of assembly coding -- i.e. schematics. > > A picture is worth a thousand words, so you can make a picture or type a > > thousand words. Which one will be easier for someone else to understand, > > hmm? > > > > HDL doesn't force abstration - you can write gate-level HDL. There > are illustrious people populating this group who frequently do the > "design equivalent of assembly coding" in HDL. HDL by its very nature is abstraction in the same way that C abstracts from assembly. You describe logic and let some piece of software try to figure out what it means. > > Come to think of it, last time I did a schematic I used the > "abstraction" of a counter block, which hides flops inside it. Only > if you know how to make a counter do you know "where every flop is". > And that's the same in HDL - I know I've written code that will mean a > counter gets built, so I know what flops there are there. > Hierarchies are not abstractions. Punch down into the counter to see the design. Sadly, these days it will probably be an HDL, so if a newbie wants to learn about counter design, it won't help any. I've used numerous counter types to solve different prolbems. T-FF based, Johnson counters, D-FF based. Each has a place if you know how they are built and what their tradeoffs are. > > > > > > With a schematic it is sooooo simple to identify each and every flop and see > > what it is doing in a simulation. Something isn't working in HDL? Good > > luck. Oh yeah, and with schematics, you never have to do all that modeling > > nonsense. While most "designers" are modeling what their circuit is > > supposed to do, I've already got it done, simulated, verified on the bench, > > off my plate and onto the next thing. > > > > What do you do when your two BGA packages aren;t talking to each other > and you haven't got the chance (because of signal integrity concerns) > to put a probe point on the board? I use any number of debugging methods to solve board problems. Generally though, I find that if I simulated it properly, it works in circuit (barring fabrication problems or layout errors). If it doesn't work in circuit, usually it means I missed some condition in the simulation. > > I go back to my simulation, with its models and all that 'waste of > time'. > > Another advantage of this approach is that I can write a testbench > that covers all my (many) testcases and reports a pass or fail at the > end. That way I can modify any code I like and know I haven't > recreated any old bugs. Not quite so easy when staring at > waveforms... > Well, I guess we mean different things when we describe "simulations". The Quartus tools allow me to simulate the design without having to "model" anything. I can take the actual design and throw signals at it directly to see if it is doing what it should. If I've built the circuit according to the timing diagrams, I should see resultant waveforms that match what I expect. Very simple to follow visually, and it has the added benefit that you see a lot more about what is going on in the circuit instead of a simple "pass/fail". BTW, with waveforms you can also do pass/fail tests really, really easily and automatically. There is no penalty from using waveforms, but there is a lot to gain. Also, when you debug the board, you should be able to match appropriate I/O signals with ones witnessed in simulation. Seeing a blinky light turn on doesn't mean a circuit worked. You have to know how well it is working, and know what the signal integrity is along the way. This usually means o'scopes, which means, you guessed it, waveforms. > > > Just some thoughts from the other side! > > Cheers, > Martin > > -- > martin.j.thompson@trw.com > TRW Conekt, Solihull, UK > http://www.trw.com/conekt ###### From: rickman Newsgroups: comp.arch.fpga Subject: Re: Xilinx Webpack bugs bugs bugs Date: Thu, 26 Jun 2003 11:01:16 -0400 Organization: Arius, Inc Lines: 301 Message-ID: <3EFB0ABC.850CA688@yahoo.com> References: <3EFA9377.E87AB5E7@yahoo.com> <0bWdnYD1_eGamWajU-KYvA@comcast.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVYepwDcySdswbx4blhhHQMI7XZMsW/wbRTXIQYDAdOpu3HwJFCKV/lB X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 26 Jun 2003 14:59:47 GMT X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:29983 Patrick MacGregor wrote: > > "rickman" wrote in message > news:3EFA9377.E87AB5E7@yahoo.com... > > Patrick MacGregor wrote: > > > > > > Amen brother! > > > > > > The "pay" tools are essentially the same, and work just as deplorably. > I > > > have a copy of ISE 5.2, and it uses the same sorry excuse for a > schematic > > > editor. I invented the "hexplitive", which was swearing in base 16, > when > > > working with X schematic tools. > > > > > ...snip... > > > I also can't buy into the HDL argument. The reason is simple. If you > were > > > a software developer and you needed your code to be as small as possible > and > > > run as fast as possible, what language would you use? Well, every > software > > > developer I've ever met answers the same -- native assembly language for > the > > > processor in question. No compiled code will be more efficient because > of > > > the layers of abstraction that higher level languages impose. The > embedded > > > developers I've worked with always got a good chuckle out of their C > > > language counterparts sucking up 100's of kilobytes of memory compared > to > > > the few K that their assembly code needed. > > > > But you ignore the fact that very few embedded engineers need their code > > to be "as small as possible" or "fast as possible". That is because the > > hardware gives lots of head room for very few bucks. Likewise FPGAs > > generally are more than fast enough and large enough and cheap enough > > (did *I* say that?) for 95% of the designs to be done in HDL. > > > > In 20 years in this business (primarily telecom/datacom), I've never once > had a situation where bloat was allowed. Bloat = added cost that doesn't go > away. You burden every finished product with unecessary cost simply by poor > design practices. A few dollars difference in parts doesn't mean much when > you build 10. But when you built 100,000 it suddenly means a lot. I've had > to sweat R's and C's many times, trying to remove as many as possible, and > then try to make the remaining ones use similar values as much as > possible -- all to try and minimize costs (cost of parts, cost of time for > the person ordering different parts, cost of warehousing -- it all counts if > you think about it). If you are in Telecom then you must have used TTC (now Acterna) test equipment. If so, I can assure you that you have worked with bloated software. This was done to facilitate the modularity of the hardware (which also had to be more complex than actually required) and subsequently was harder to maintain. Not only did they use C, but they used C++. Clearly assembly was not needed, and the C and C++ had advantages in time to market or why would they use it? > Having recently done an OC48 framer design (in a couple of weeks), I could > have easily aimed at something like a 1C6 or 1C12 Cyclone part. Instead I > aimed for a 1C3 part in the slowest speed grade. Works just fine, using > about 1/3 of the LCs. A 1C3 costs 1/2 of a 1C6 roughly, yet the 1C6 is not > "expensive". Choosing to design efficiently added exactly zero time penalty > but yielded tremendous cost savings. If you only used 1/3 of the LCs, then surely it would have fit using an HDL. If you don't know how to use an HDL, then you can produce some pretty poor code that is much larger than needed. It is another animal to learn, but can improve your efficiency. BTW, the fact that you did not even fill half of a 1C3 supports my statement that you most likely do rather small designs. The advantages of HDLs show when you start making larger chips. > > Again for the same reason that few designers do an entire project in > > assembly, I won't be doing any more schematic designs. The last one I > > did was a PITA to draw the gates needed for FSM design or worse, address > > decoding. Data path is not bad in schematic, but the random logic is no > > fun at all and it takes up so much space when you try to view a large > > design. I don't mean disk space, I mean viewing space. I can view an > > equivalent project in a text editor much more easily than a schematic > > editor. > > > One startup I worked for had an embedded designer assigned to one or more > ATM interface cards. These guys wrote in assembly only, and because of this > were able to keep up with ATM at OC-3 rates using a very slow, primitive > (i.e. inexpensive) micro. > > The fact that random gate design being "no fun at all" and "taking up a lot > of space" suggests a few things to me. First, there are some simple rules > for making a clean, legible schematic. Too bad schools never teach them. > Also, I firmly believe that nearly anyone can make a functioning design > given enough time. This doesn't make it a good design. Some designs are > better than others, and one way to get to the "good design" stage is to get > your fingers into the gates and learn how to work with them efficiently. > > I regularly test whether or not an HDL can create logic more efficiently > than me. It can't. Not once has it implemented any type of decoding > function better than I can. It can match me in terms of resources utilized, > but it can't best me. By staying in the gates, I always have an instant > grasp of how large a design is getting. I stopped one major piece of that > OC48 design simply because it was getting too large. I knew that because I > could see it on the page and in the floorplanner. Seeing the size forced me > to think about other ways to implement the process. The first way worked, > but so what? Not good enough. I needed to reduce the size to stay > comfortably in the smaller part. You are missing the point. The HDL tool will not make more efficient logic, but it can do well enough. Engineering is all about doing the job to spec and within schedule. Trying to get your gate count lower is a waste of time. That is the sort of stuff that kids did in school, to make a design run even faster or make it smaller. Sure these are good learning exercises, but in engineering the emphasis is on spec. HDLs do a "good enough" job 99% of the time. > > > HDL is the same. You abstract designs (so that non-designers can > pretend to > > > be designers I suppose) and pay a penalty by having circuit bloat. If > you > > > want the smallest design possible, and want it to run as fast as > possible, > > > you need to use the design equivalent of assembly coding -- i.e. > schematics. > > > A picture is worth a thousand words, so you can make a picture or type a > > > thousand words. Which one will be easier for someone else to > understand, > > > hmm? > > > > There are lots of reasons to use HDLs, but trying to enable uneducated > > hardware designers (or worse, software designers) is not one of them. I > > feel that to properly use an HDL you need to know what you expect for > > hardware and then describe that in the HDL. But again, very few people > > have to have the "smallest" or the "fastest" design. Mostly they have > > goals which include schedules. > > > The best HDL folks I know are ones who use it like it was a schematic. So, > in my mind, why bother? And again, I've never had the luxury of NOT needing > the smallest/fastest design. It's how I push 4 OC48s through a $30 part, > saving a client millions on NOT needing to buy a bunch of expensive ASSPs > for every board. > > Size does count, and I can proudly say that "mine is smaller than yours". > ;-) Interesting idea of what constitutes "good" or "best". I once worked at TRW where I learned one very valuable lesson. An optimized system is more expensive in all areas of design. It is more expensive to design initially since it takes more time. It is more expensive to test since it is more complex. It is more expensive to maintain since a change is harder to make without breaking something else. A smaller design is likely going to be more expensive to engineer over the long haul. Unless you actually get into a smaller chip and save money, you have done nothing useful. > > As to the picture and word analogy, I find the words to suit design > > better. It takes a large picture and a lot of time to create it, to > > equal those thousand words. > > > Some folks are visual and some folks prefer the written word. I'm obviously > visual for circuits and have no problem using the written word, like now, > for example. Seeing and creating are different. Nearly all people can understand a good drawing more easily. That is why all my HDL designs start with block diagrams. But turning that into a complex design in schematic is a PITA. Once you get used to code you will find that it is much easier to work with... or not. Your preference. > > > I recently talked to an FAE for an FPGA vendor. He said that fully 80% > of > > > the designs he has seen are done in schematics. You can even read about > > > graphical versions of HDL coming out. Sounds like schematics to me. > Except > > > that you add a layer of obfuscation in there that will make for a more > > > bloated design. Why bother? > > > > I don't know where you got this, but this sounds like an exaggeration. > > I would say he had it backwards, but I bet the schematic usage is less > > than 20%. > > > I got this right from the horse's mouth. I didn't make it up. It was his > observation of designs he's seeing. Why would he lie? He has no vested > interest in any method his clients use. Simply the stats he sees. I can assure you that this is not true for design starts today. If it were there would be a lot more postings here from people who use schematic. There are virtually none, perhaps what, 1 a month other than threads like this? > > > An ironic thing to notice is that if you open many of the X design > examples > > > included with the tools, you'll see that they are schematic based. > > > > > > With a schematic it is sooooo simple to identify each and every flop and > see > > > what it is doing in a simulation. Something isn't working in HDL? Good > > > luck. Oh yeah, and with schematics, you never have to do all that > modeling > > > nonsense. While most "designers" are modeling what their circuit is > > > supposed to do, I've already got it done, simulated, verified on the > bench, > > > off my plate and onto the next thing. > > > > If you don't feel the need to simulate, then you are clearly doing very > > simple designs. The simulation is to make sure you are solving the > > problem rather than just knowing what you are creating. These are two > > different problems. > > > Guess you missed it when I said I simulated the designs, right before > testing them on the bench. I never skip simulating. Again though, I prefer > the graphical waveform version as I get to see a nice, pretty picture of > what is happening and when. It is very simple to pull up any flop in the > design and see it relative to anything else. Makes debugging go 10 times > faster. And, once I'm happy with it, I can transfer the simulator results > back into the input file so that I can compare expected to generated results > should I make changes or add new stuff. What could be simpler? Then what are you talking about by "modeling"? If you think waveform editing is the way to go in simulation, you are missing the best part of an HDL. Even if I had a design in schematic I would want to simulate it in an HDL simulator. Being able to code the environment makes life so much easier than creating waveforms. That alone is worth using an HDL in my opinion. > > > I was taught the power of schematics and their companion, the timing > > > diagram, when I was a wee engineer pup. My first boss would sit me down > and > > > go over the schematics with me, asking me to justify each and every > > > component on the page. If there wasn't a good reason for it, it was > gone. > > > Amongst the many invaluable lessons he taught me was that every > component in > > > the circuit should have a reason. Try doing that with an HDL > abstraction. > > > Most "designers" haven't a clue how that hunk of code they wrote got > > > implemented in actual gates. Scott Adams would probably call them > > > "Duhsigners". > > > > > > > > > > > > So, I'm with you 100%. Schematics rule. Xilinx has no reason > whatsoever to > > > support schematics, as the bloated designs that HDLs produce force folks > > > into buying larger, faster speed grade parts that are naturally more > > > costly. Works for them. > > > > > > You can always download the free Altera tools and play with their stuff. > > > Fully integrated schematic capture, compiler and simulator. Very nice. > Not > > > perfect or bug free, but then no tool is. It is, however, VASTLY > superior > > > to the X garbage schematic tools. > > > > > > When I need to design something in an X part, I do it first in the A > tools > > > and use their native simulater. Then I re-enter it in X. Doing the > > > drawings twice is STILL faster than doing the design from scratch in X. > Try > > > it. > > > > > > I tend to always push my clients to use A parts simply because the tools > are > > > so superior. Design times are radically reduced, and that saves them > > > tangible money. If they insist on X parts, I revert to the paragraph > above. > > > > > > Don't buy into the HDL propaganda. Schematics will never do you wrong. > > > > No, but they will take more time and make large jobs nearly impossible. > > For the duhsigner, perhaps. Personally, I've never found any job too large > for schematics, whether doing ASICs or FPGAs. And, you need schematics to > design PCBs, so the extra practice doesn't hurt. What ever works for you. But most people have learned to use HDLs efficiently, just as most programmers (even the best ones) have learned to use C effectively. -- 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 ###### Newsgroups: comp.arch.fpga Subject: Re: Xilinx Webpack bugs bugs bugs Reply-To: tom3@protectedfromreality.com References: Message-ID: Content-Type: text/plain; charset=iso-8859-15; format=flowed From: Thomas Organization: Protected From Reality MIME-Version: 1.0 User-Agent: Opera7.11/Win32 M2 build 2887 Lines: 62 Date: Thu, 26 Jun 2003 16:12:04 GMT NNTP-Posting-Host: 68.66.186.243 X-Complaints-To: abuse@adelphia.net X-Trace: news3.news.adelphia.net 1056643924 68.66.186.243 (Thu, 26 Jun 2003 12:12:04 EDT) NNTP-Posting-Date: Thu, 26 Jun 2003 12:12:04 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.imp.ch!news.imp.ch!newsfeed.stueberl.de!in.100proofnews.com!in.100proofnews.com!router3.news.adelphia.net!news3.news.adelphia.net.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:30033 On Thu, 26 Jun 2003 10:08:20 -0400, Patrick MacGregor wrote: > > "Thomas" wrote in message > news:oprrcygwqomo2d8p@news3.news.adelphia.net... >> I read with interest your thoughts about hdl vs schematics and the > parallel >> with software >> I've developped software for 14 years and while at heart I agree with >> you, >> in my day to day practice I disagree. Assembler will always provide you >> a >> most optimized solution, but C/C++ is much faster to develop with and is >> more accessible; btw, that's assuming you have competent engineers >> writing >> assembler, otherwise it turns into a mess very quick. yes, you definetly >> lower the efficiency of the resource usage with a higher level language, >> but nowadays it is cheaper to get faster / bigger hardware than more >> engineers / time. >> the days where we used to build things right are over; now the key is >> how >> fast you can put something on the market; it's sad, but the tech >> industry >> is not what it used to be. >> I have never been too much in touch with the hardware industry, but >> lately >> it has changed and I realize that you guys have the exact same issues / >> concerns / problems / etc we have in software; kind of ironic, in a sad >> way. >> >> Thomas. > > The assembly level guys I've worked with were every bit as fast as their > C > counterparts when developing code. If you do it a lot, you get good, > fast > and efficient at it. And as with HW design, you create a bag of tricks > you > employ to speed the next jobs along, as well as developing a library of > previously designed pieces you can employ later. > > There is just no reason why you can't design quickly and correctly at the > same time. That is one key difference between a newbie and someone with > a > lot of experience. It is then incumbent on the experienced folks to pass > along knowledge to the newbies to speed their development into capable, > competent designers. Nothing beats experience. > > I agree on the experience part, but I disagree about the speed to write code, the difference is massive; just the amount of typing alone is radically different; optimizing assembler by hand is not trivial anymore; if you optimize math for example, it takes a fair amount of time to produce code faster than compilers nowdays; the result will be greater, but will your product be? is it worth the cost? usually not at all. I work in the video game industry, we're still using assembler a lot, but only on very small and select pieces of the products, it is not worth doing it more; it costs too much in time, it requires a more skilled (expensive) team, etc and the end result is not different enough to warrant the costs ###### From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) Newsgroups: comp.arch.fpga Subject: Re: Xilinx Webpack bugs bugs bugs Date: Thu, 26 Jun 2003 16:30:19 +0000 (UTC) Organization: University of California, Berkeley, EECS Department Lines: 35 Message-ID: References: NNTP-Posting-Host: ribbit.cs.berkeley.edu X-Trace: agate.berkeley.edu 1056645019 84234 128.32.112.203 (26 Jun 2003 16:30:19 GMT) X-Complaints-To: usenet@agate.berkeley.edu NNTP-Posting-Date: Thu, 26 Jun 2003 16:30:19 +0000 (UTC) X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Originator: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news-hog.berkeley.edu!ucberkeley!agate.berkeley.edu!agate!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:30012 In article , Thomas wrote: >> The assembly level guys I've worked with were every bit as fast as >> their C counterparts when developing code. If you do it a lot, you >> get good, fast and efficient at it. And as with HW design, you >> create a bag of tricks you employ to speed the next jobs along, as >> well as developing a library of previously designed pieces you can >> employ later. >I agree on the experience part, but I disagree about the speed to write >code, the difference is massive; just the amount of typing alone is >radically different; optimizing assembler by hand is not trivial anymore; >if you optimize math for example, it takes a fair amount of time to produce >code faster than compilers nowdays; the result will be greater, but will >your product be? is it worth the cost? usually not at all. I work in the >video game industry, we're still using assembler a lot, but only on very >small and select pieces of the products, it is not worth doing it more; it >costs too much in time, it requires a more skilled (expensive) team, etc >and the end result is not different enough to warrant the costs It also really depends on your goals and the target. x86 assembly is relatively straightforward, so fairly easy to do OK on. IA64 is an absolute beast of convoluted rules and interlocking requirements. The "preferred" assemble IDE for IA64 is an excell spreadsheet! Also, how much of the assembly "savings" is mostly stripping out preamble/postamble code and similar modularities, which the compiler would mostly do anyway given an -O3 compiler flag? -- Nicholas C. Weaver nweaver@cs.berkeley.edu ###### From: Chris Carlen Newsgroups: comp.arch.fpga Subject: Re: Xilinx Webpack bugs bugs bugs Date: Thu, 26 Jun 2003 09:38:55 -0700 Organization: Sandia National Laboratories, Albuquerque, NM USA Lines: 22 Message-ID: References: <3EFA391B.4000806@xilinx.com> NNTP-Posting-Host: mango.ran.sandia.gov Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sass2141.sandia.gov 1056645462 24535 134.252.41.24 (26 Jun 2003 16:37:42 GMT) X-Complaints-To: usenet@sass2141.sandia.gov NNTP-Posting-Date: Thu, 26 Jun 2003 16:37:42 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en In-Reply-To: <3EFA391B.4000806@xilinx.com> Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!enews.sgi.com!news.sandia.gov!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:30011 Steve Lass wrote: > Chris, > > What version are you running? > > It sounds like you may be using an older version and possibly have some > misconceptions about how the tools work together. > > Steve Oops, I should have stated that it is 5.2i with service pack 3. Pretty up-to-date. -- _______________________________________________________________________ Christopher R. Carlen Principal Laser/Optical Technologist Sandia National Laboratories CA USA crcarle@sandia.gov -- NOTE: Remove "BOGUS" from email address to reply. ###### From: Chris Carlen Newsgroups: comp.arch.fpga Subject: Re: Xilinx Webpack bugs bugs bugs Date: Thu, 26 Jun 2003 09:59:44 -0700 Organization: Sandia National Laboratories, Albuquerque, NM USA Lines: 84 Message-ID: References: <2n1lfvc59946vn6slnetjbb76i6kdljfm7@4ax.com> NNTP-Posting-Host: mango.ran.sandia.gov Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sass2141.sandia.gov 1056646716 25042 134.252.41.24 (26 Jun 2003 16:58:36 GMT) X-Complaints-To: usenet@sass2141.sandia.gov NNTP-Posting-Date: Thu, 26 Jun 2003 16:58:36 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en In-Reply-To: <2n1lfvc59946vn6slnetjbb76i6kdljfm7@4ax.com> Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!enews.sgi.com!news.sandia.gov!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:30010 Bob Perlman wrote: > Hi - > > The this-tool-is-no-damn-good thread pops up every few weeks. I don't > use the ECS schematic editor, so I can't comment on the its quality or > lack thereof. And I certainly don't want to get embroiled in the > schematics-vs-HDL debate which, along with cockroaches, will be the > only thing to survive a nuclear holocaust. But I will make a couple > of observations. > > First, use tools that have lots of users. Any tool developer will > spend more time fixing and maintaining popular tools than those used > only by a handful of people. And, the merits of HDLs aside, is there > any doubt that even the least popular FPGA HDL synthesis tool has at > least ten times as many users as ECS? I know, I know--this isn't > fair. But that's the way it is. Unless you're Mr. Cisco, of course. > > Second, use only those tools that add real value. There are some > Xilinx tools--the FPGA editor, PACE, the floorplanner--that have a > useful GUI . In fact, these tools wouldn't make much sense without a > GUI. But does Project Navigator really add that much value over and > above a decent batch file that invokes tools from the command line? > Maybe the uber-GUI that ties all the tools together makes sense for > some users, but to me it's just one more thing that can break or do > inexplicable things. All I'm saying is, don't use a tool just because > it's there; the benefit should exceed the pain. > > And I agree - the Linear Tech SPICE tool is very nice. The fact that > it's free doesn't hurt, either. Thanks for your input. I think I am interested in the schematic entry for a few reasons: 1. I am a beginner at this PLD stuff, and it is the easiest way to get the chips to do something, without having to first learn HDL. 2. I am using CPLDs not FPGAs, with a heavy combinatorial emphasis, rather than state machine, heavy FF stuff. For this reason I chose Xilinx instead of Altera in the first place, as it seemed Altera didn't have as nice of an offering in the CPLD department as the Coolrunner CPLDs. Also, I want to interface as easily as I can to 5V logic systems, and the Coolrunner XPLA3 can do this directly, without added level translation glue. I just use an HCT14 to convert the 3.3V drive from the CPLD to 5V swings to send to the outside world. My application is somewhat wierd as well. We run engine research laboratories, in which there is a "patch panel" of a whole bunch of BNC connectors connected to a sampling of ANDs, ORs, etc. for gluing the various electronic subsystems of the lab together. The scientists frequently want to change their functionality, and sometimes want to add special functionality that is a bit too complex for a panel with only 20-30 gates. These "special functions" always sent me to the breadboard to prototype something with discrete logic chips that could do it, then I'd make a circuit board and install it somewhere on the rack space. I decided I wanted to build a patch panel that instead consists of a generic matric of BNCs, that interfaces to a CPLD device of moderate size. Then I can program the CPLD to be whatever arrangement of gates the scientist needs, and even more complex special functions can likely be accomodated with a few extra internal resources like a clock generator for making digital delays to replace analog one-shots, etc. 3. The schematic is the only form of circuit design that the scientists will understand, and so using schematic entry is the best way for us to communicate, and makes the circuitry self-documenting. (In the past things were laid out in pencil, then later drawn in a CAD program for the lab documentation.) Good day! -- _______________________________________________________________________ Christopher R. Carlen Principal Laser/Optical Technologist Sandia National Laboratories CA USA crcarle@sandia.gov -- NOTE: Remove "BOGUS" from email address to reply. ###### NNTP-Posting-Date: Thu, 26 Jun 2003 12:25:16 -0500 From: "Patrick MacGregor" Newsgroups: comp.arch.fpga References: <3EFA9377.E87AB5E7@yahoo.com> <0bWdnYD1_eGamWajU-KYvA@comcast.com> <3EFB0ABC.850CA688@yahoo.com> Subject: Re: Xilinx Webpack bugs bugs bugs Date: Thu, 26 Jun 2003 13:24:57 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: Lines: 301 NNTP-Posting-Host: 68.55.246.189 X-Trace: sv3-3VeUAwvH0wgC4tczXQT8a22gShZDeHFOd1C8cqNkJ6LtT1V3H9wHgpL/SdE9ZNszn4GZ5Nzqg75F6GS!IeSDziMv55wxjXPvkvzjD72FegOEM6TFvsRp4hdzWRhQE3nFU2nSEiF1Sfa1QA== X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.1 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!small1.nntp.aus1.giganews.com!border1.nntp.aus1.giganews.com!intern1.nntp.aus1.giganews.com!nntp.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:30021 > > In 20 years in this business (primarily telecom/datacom), I've never once > > had a situation where bloat was allowed. Bloat = added cost that doesn't go > > away. You burden every finished product with unecessary cost simply by poor > > design practices. A few dollars difference in parts doesn't mean much when > > you build 10. But when you built 100,000 it suddenly means a lot. I've had > > to sweat R's and C's many times, trying to remove as many as possible, and > > then try to make the remaining ones use similar values as much as > > possible -- all to try and minimize costs (cost of parts, cost of time for > > the person ordering different parts, cost of warehousing -- it all counts if > > you think about it). > > If you are in Telecom then you must have used TTC (now Acterna) test > equipment. If so, I can assure you that you have worked with bloated > software. This was done to facilitate the modularity of the hardware > (which also had to be more complex than actually required) and > subsequently was harder to maintain. Not only did they use C, but they > used C++. Clearly assembly was not needed, and the C and C++ had > advantages in time to market or why would they use it? > I'm very familiar with TTC and have used many of their products. I'm also good friends with an ex-TTC designer who spent over 10 years there. Somehow he managed to create designs that were efficient in HW and SW/FW. His products were highly successful and enjoyed some of the highest margins (from a COGS perspective) of any in the company. Guess that's why he ultimately didn't fit into the bloat mentality and went on to greener pastures. > > > Having recently done an OC48 framer design (in a couple of weeks), I could > > have easily aimed at something like a 1C6 or 1C12 Cyclone part. Instead I > > aimed for a 1C3 part in the slowest speed grade. Works just fine, using > > about 1/3 of the LCs. A 1C3 costs 1/2 of a 1C6 roughly, yet the 1C6 is not > > "expensive". Choosing to design efficiently added exactly zero time penalty > > but yielded tremendous cost savings. > > If you only used 1/3 of the LCs, then surely it would have fit using an > HDL. If you don't know how to use an HDL, then you can produce some > pretty poor code that is much larger than needed. It is another animal > to learn, but can improve your efficiency. > Just because I could have "made it fit with HDL" doesn't offer any reason to have bothered wasting my time trying. Big deal. The point wasn't to use as many resources in the part as possible. It was to use as few, leaving plenty of room for an embedded soft processor, for example, or for ATM cell delineation. > BTW, the fact that you did not even fill half of a 1C3 supports my > statement that you most likely do rather small designs. The advantages > of HDLs show when you start making larger chips. Again, you missed the point completely. My design is small, well, by design. Don't confuse "small size" with lack of complexity. Not the case at all, especially when you factor in pointer processing. If you go look at any commercially advertised OC48 core (like Altera or Paxonet, for example), they require 5 to 10 times as much logic as mine does to perform the exact same functions. ASSPs are cheaper than the FPGAs required to implement their cores. Oh, and they use HDLs. Now, what was that compelling reason to use HDL again? > > > > Again for the same reason that few designers do an entire project in > > > assembly, I won't be doing any more schematic designs. The last one I > > > did was a PITA to draw the gates needed for FSM design or worse, address > > > decoding. Data path is not bad in schematic, but the random logic is no > > > fun at all and it takes up so much space when you try to view a large > > > design. I don't mean disk space, I mean viewing space. I can view an > > > equivalent project in a text editor much more easily than a schematic > > > editor. > > > > > One startup I worked for had an embedded designer assigned to one or more > > ATM interface cards. These guys wrote in assembly only, and because of this > > were able to keep up with ATM at OC-3 rates using a very slow, primitive > > (i.e. inexpensive) micro. > > > > The fact that random gate design being "no fun at all" and "taking up a lot > > of space" suggests a few things to me. First, there are some simple rules > > for making a clean, legible schematic. Too bad schools never teach them. > > Also, I firmly believe that nearly anyone can make a functioning design > > given enough time. This doesn't make it a good design. Some designs are > > better than others, and one way to get to the "good design" stage is to get > > your fingers into the gates and learn how to work with them efficiently. > > > > I regularly test whether or not an HDL can create logic more efficiently > > than me. It can't. Not once has it implemented any type of decoding > > function better than I can. It can match me in terms of resources utilized, > > but it can't best me. By staying in the gates, I always have an instant > > grasp of how large a design is getting. I stopped one major piece of that > > OC48 design simply because it was getting too large. I knew that because I > > could see it on the page and in the floorplanner. Seeing the size forced me > > to think about other ways to implement the process. The first way worked, > > but so what? Not good enough. I needed to reduce the size to stay > > comfortably in the smaller part. > > You are missing the point. The HDL tool will not make more efficient > logic, but it can do well enough. Engineering is all about doing the > job to spec and within schedule. Trying to get your gate count lower is > a waste of time. That is the sort of stuff that kids did in school, to > make a design run even faster or make it smaller. Sure these are good > learning exercises, but in engineering the emphasis is on spec. HDLs do > a "good enough" job 99% of the time. > "good enough for gov't work", right? I'll agree that a design has to meet the desired specs. I won't agree that just any old implementation will do, especially when you add in cumulative costs of more expensive parts. I also take exception to the thought that doing it fast means sacrificing efficiency. Just not true. Not to me, or the designers I've worked with or hired. Getting gate count lower is never a waste of time as it teaches you, over time, to think efficiently right from the start. That is how you get a fast design time with efficient use of resources. Anybody can build an OC48 framer with a few million gates if they try. But how many can do it with a few thousand, and take less design time in the process? Most of the folks I've worked with can do this, but only because they learned efficient design techniques from the beginning, and honed that skill over time. > > The best HDL folks I know are ones who use it like it was a schematic. So, > > in my mind, why bother? And again, I've never had the luxury of NOT needing > > the smallest/fastest design. It's how I push 4 OC48s through a $30 part, > > saving a client millions on NOT needing to buy a bunch of expensive ASSPs > > for every board. > > > > Size does count, and I can proudly say that "mine is smaller than yours". > > ;-) > > Interesting idea of what constitutes "good" or "best". I once worked at > TRW where I learned one very valuable lesson. An optimized system is > more expensive in all areas of design. It is more expensive to design > initially since it takes more time. It is more expensive to test since > it is more complex. It is more expensive to maintain since a change is > harder to make without breaking something else. One hallmark of a good designer is that a day after finishing the design, they can think of ways to improve it. One hallmark of a great designer is knowing when something is "good enough". The best designs tend to be simple, not complex, as the best designers know how to break complicated things down into simple solutions. In general, it also yields a more efficient design in the process. Also, simpler designs are easier to maintain, as they can be understood by more people. Lastly, you learn to make these designs by learning how to "sweat the gates" and justify every piece in the design, whether it is an R, C, AND gate or FLOP. > > A smaller design is likely going to be more expensive to engineer over > the long haul. Unless you actually get into a smaller chip and save > money, you have done nothing useful. > Not in my experience. My customers have always preferred a smaller, more elegant solution as it is easier to build, test and maintain, and less expensive to boot. At some startups I worked for, that reduced cost was a strategic competitive advantage. > > > As to the picture and word analogy, I find the words to suit design > > > better. It takes a large picture and a lot of time to create it, to > > > equal those thousand words. > > > > > Some folks are visual and some folks prefer the written word. I'm obviously > > visual for circuits and have no problem using the written word, like now, > > for example. > > Seeing and creating are different. Nearly all people can understand a > good drawing more easily. That is why all my HDL designs start with > block diagrams. But turning that into a complex design in schematic is > a PITA. Once you get used to code you will find that it is much easier > to work with... or not. Your preference. > It's not. My preference. I'm like any engineer -- I will use a new tool/technique when it will benefit me or the project. Haven't seen it with HDLs. > > > > I recently talked to an FAE for an FPGA vendor. He said that fully 80% > > of > > > > the designs he has seen are done in schematics. You can even read about > > > > graphical versions of HDL coming out. Sounds like schematics to me. > > Except > > > > that you add a layer of obfuscation in there that will make for a more > > > > bloated design. Why bother? > > > > > > I don't know where you got this, but this sounds like an exaggeration. > > > I would say he had it backwards, but I bet the schematic usage is less > > > than 20%. > > > > > I got this right from the horse's mouth. I didn't make it up. It was his > > observation of designs he's seeing. Why would he lie? He has no vested > > interest in any method his clients use. Simply the stats he sees. > > I can assure you that this is not true for design starts today. If it > were there would be a lot more postings here from people who use > schematic. There are virtually none, perhaps what, 1 a month other than > threads like this? > Not according to that FAE. He sees more design starts than either of us do. He's in a position to know. > > > > An ironic thing to notice is that if you open many of the X design > > examples > > > > included with the tools, you'll see that they are schematic based. > > > > > > > > With a schematic it is sooooo simple to identify each and every flop and > > see > > > > what it is doing in a simulation. Something isn't working in HDL? Good > > > > luck. Oh yeah, and with schematics, you never have to do all that > > modeling > > > > nonsense. While most "designers" are modeling what their circuit is > > > > supposed to do, I've already got it done, simulated, verified on the > > bench, > > > > off my plate and onto the next thing. > > > > > > If you don't feel the need to simulate, then you are clearly doing very > > > simple designs. The simulation is to make sure you are solving the > > > problem rather than just knowing what you are creating. These are two > > > different problems. > > > > > Guess you missed it when I said I simulated the designs, right before > > testing them on the bench. I never skip simulating. Again though, I prefer > > the graphical waveform version as I get to see a nice, pretty picture of > > what is happening and when. It is very simple to pull up any flop in the > > design and see it relative to anything else. Makes debugging go 10 times > > faster. And, once I'm happy with it, I can transfer the simulator results > > back into the input file so that I can compare expected to generated results > > should I make changes or add new stuff. What could be simpler? > > Then what are you talking about by "modeling"? > > If you think waveform editing is the way to go in simulation, you are > missing the best part of an HDL. Even if I had a design in schematic I > would want to simulate it in an HDL simulator. Being able to code the > environment makes life so much easier than creating waveforms. That > alone is worth using an HDL in my opinion. > Sort of like saying it's the best part of a tooth extraction. > What ever works for you. But most people have learned to use HDLs > efficiently, just as most programmers (even the best ones) have learned > to use C effectively. > Perhaps. Personally, I find that while I could type out some address decoding in an HDL quickly, I much prefer keeping my skills honed at doing gate designs just as quickly (and I'm a very fast typist). It forces me to think logically and methodically about a problem and look for the quickest, most efficient way to put the gates together. That skill pays off huge dividends when the circuit gets more complicated. A world-class athlete gets there by constant repetition and training. Same with designers who want to be world class. ###### From: Steve Lass Newsgroups: comp.arch.fpga Subject: Re: Xilinx Webpack bugs bugs bugs Date: Thu, 26 Jun 2003 12:02:27 -0600 Organization: Xilinx Lines: 36 Message-ID: <3EFB3533.9060705@xilinx.com> References: <3EFA391B.4000806@xilinx.com> Reply-To: lass@xilinx.com NNTP-Posting-Host: 149.199.186.43 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!enews.sgi.com!nntp.wetware.com!attdv1!attdv2!ip.att.net!newsgate.xilinx.com!cliff.xsj.xilinx.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:29979 Chris, I have had my experts look into this and they can't reproduce your problem with moving large blocks. This was a problem with earlier releases, but was fixed in 5.1i. You might want to reinstall if you're still running into this on 5.2i. Even though we do put more effort into the HDL flows, we still have engineers working on ECS. It was rewritten a couple of years ago because we plan on keeping it around for a long time. The rewrite did introduce some of the bugs you describe, but we think they are fixed in current releases. Let me know, offline, if you are still having problems. Steve Chris Carlen wrote: > Steve Lass wrote: > >> Chris, >> >> What version are you running? >> >> It sounds like you may be using an older version and possibly have >> some misconceptions about how the tools work together. >> >> Steve > > > > Oops, I should have stated that it is 5.2i with service pack 3. > Pretty up-to-date. > > ###### Message-ID: <3EFB612F.10B@designtools.co.nz> From: Jim Granville Reply-To: jim.granville@designtools.co.nz Organization: Mandeno Granville elect X-Mailer: Mozilla 3.0C-XTRA (Win95; I) MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Xilinx Webpack bugs bugs bugs References: <2n1lfvc59946vn6slnetjbb76i6kdljfm7@4ax.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 105 Date: Fri, 27 Jun 2003 09:13:22 +1200 NNTP-Posting-Host: 210.246.2.225 X-Complaints-To: abuse@tsnz.net X-Trace: news02.tsnz.net 1056661983 210.246.2.225 (Fri, 27 Jun 2003 09:13:03 NZST) NNTP-Posting-Date: Fri, 27 Jun 2003 09:13:03 NZST Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!xmission!news-out.spamkiller.net!propagator2-maxim!news-in-maxim.spamkiller.net!news02.tsnz.net!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:30057 Chris Carlen wrote: > > Bob Perlman wrote: > > Hi - > > > > The this-tool-is-no-damn-good thread pops up every few weeks. I don't > > use the ECS schematic editor, so I can't comment on the its quality or > > lack thereof. And I certainly don't want to get embroiled in the > > schematics-vs-HDL debate which, along with cockroaches, will be the > > only thing to survive a nuclear holocaust. But I will make a couple > > of observations. > > > > First, use tools that have lots of users. Any tool developer will > > spend more time fixing and maintaining popular tools than those used > > only by a handful of people. And, the merits of HDLs aside, is there > > any doubt that even the least popular FPGA HDL synthesis tool has at > > least ten times as many users as ECS? I know, I know--this isn't > > fair. But that's the way it is. Unless you're Mr. Cisco, of course. > > > > Second, use only those tools that add real value. There are some > > Xilinx tools--the FPGA editor, PACE, the floorplanner--that have a > > useful GUI . In fact, these tools wouldn't make much sense without a > > GUI. But does Project Navigator really add that much value over and > > above a decent batch file that invokes tools from the command line? > > Maybe the uber-GUI that ties all the tools together makes sense for > > some users, but to me it's just one more thing that can break or do > > inexplicable things. All I'm saying is, don't use a tool just because > > it's there; the benefit should exceed the pain. > > > > And I agree - the Linear Tech SPICE tool is very nice. The fact that > > it's free doesn't hurt, either. > > Thanks for your input. > > I think I am interested in the schematic entry for a few reasons: > > 1. I am a beginner at this PLD stuff, and it is the easiest way to get > the chips to do something, without having to first learn HDL. > > 2. I am using CPLDs not FPGAs, with a heavy combinatorial emphasis, > rather than state machine, heavy FF stuff. For this reason I chose > Xilinx instead of Altera in the first place, as it seemed Altera didn't > have as nice of an offering in the CPLD department as the Coolrunner CPLDs. > > Also, I want to interface as easily as I can to 5V logic systems, and > the Coolrunner XPLA3 can do this directly, without added level > translation glue. I just use an HCT14 to convert the 3.3V drive from > the CPLD to 5V swings to send to the outside world. > > My application is somewhat wierd as well. We run engine research > laboratories, in which there is a "patch panel" of a whole bunch of BNC > connectors connected to a sampling of ANDs, ORs, etc. for gluing the > various electronic subsystems of the lab together. The scientists > frequently want to change their functionality, and sometimes want to add > special functionality that is a bit too complex for a panel with only > 20-30 gates. These "special functions" always sent me to the breadboard > to prototype something with discrete logic chips that could do it, then > I'd make a circuit board and install it somewhere on the rack space. > > I decided I wanted to build a patch panel that instead consists of a > generic matric of BNCs, that interfaces to a CPLD device of moderate > size. Then I can program the CPLD to be whatever arrangement of gates > the scientist needs, and even more complex special functions can likely > be accomodated with a few extra internal resources like a clock > generator for making digital delays to replace analog one-shots, etc. > > 3. The schematic is the only form of circuit design that the scientists > will understand, and so using schematic entry is the best way for us to > communicate, and makes the circuitry self-documenting. (In the past > things were laid out in pencil, then later drawn in a CAD program for > the lab documentation.) I think you should look at ABEL or CUPL HDL. Xilinx still offer ABEL flows, and have actually improved the handling of details in their latest WebPack. ABEL source is unchanged, but Xilinx changed some of the underlying flows, and that took a while to shake-out. ABEL is 'more direct' (syntax maps more closely to the resource) than VHDL/Verilog, and uses DOT extentions. eg : Reg.D = Sum # Of # Products; Reg.CK = ChooseCLK; Reg.CE = Reg2; Reg2.T = ToggleTerms; If you like schematics, you can think of this as a netlist. This is also very close to the eqn syntax used in the post-fit report files. ( so Source/ActualResult checking is quick) If the scientists can understand & -> AND and # -> OR, :) then they can make their own patch tables, given a template file to start with. A benefit of this, is they can NAME the nodes, with what they actually are/do, and EQN creation becomes less error prone, and easier to read than a schematic, where you have to trace to a net-tag to confirm gated signals. It is also much faster to create 'slight variants' from a commmon template. - jg ###### From: Chris Carlen Newsgroups: comp.arch.fpga Subject: Re: Xilinx Webpack bugs bugs bugs Date: Thu, 26 Jun 2003 17:40:03 -0700 Organization: Sandia National Laboratories, Albuquerque, NM USA Lines: 51 Message-ID: References: <2n1lfvc59946vn6slnetjbb76i6kdljfm7@4ax.com> <3EFB612F.10B@designtools.co.nz> NNTP-Posting-Host: mango.ran.sandia.gov Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sass2141.sandia.gov 1056674332 8097 134.252.41.24 (27 Jun 2003 00:38:52 GMT) X-Complaints-To: usenet@sass2141.sandia.gov NNTP-Posting-Date: Fri, 27 Jun 2003 00:38:52 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en In-Reply-To: <3EFB612F.10B@designtools.co.nz> Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!enews.sgi.com!news.sandia.gov!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:30063 Jim Granville wrote: > I think you should look at ABEL or CUPL HDL. > Xilinx still offer ABEL flows, and have actually improved the > handling of details in their latest WebPack. > ABEL source is unchanged, but Xilinx changed some of the > underlying flows, and that took a while to shake-out. What do you mean by "still offer?" It sounds like this is a dying breed or something. Perhaps you can enlighten me a bit more about the history of ABEL vs. other HDLs, and it's current usage in the PLD world? > ABEL is 'more direct' (syntax maps more closely to the resource) > than VHDL/Verilog, and uses DOT extentions. eg : > > Reg.D = Sum # Of # Products; > Reg.CK = ChooseCLK; > Reg.CE = Reg2; > Reg2.T = ToggleTerms; > > If you like schematics, you can think of this as a netlist. This is interesting. > If the scientists can understand & -> AND and # -> OR, :) then > they can make their own patch tables, given a template file to > start with. Some of them (the ones who don't know anything exists beyond an AND and OR gate) are criticising me for not still doing everything with wire-wrap and TTL. Not a very progressive bunch. Fortunately, most of them are into progress, but others not. I think schematics are really needed for them in general. But if I can produce the time to learn an HDL in the near future, I will consider ABEL. Thanks for the input. Good day! -- _______________________________________________________________________ Christopher R. Carlen Principal Laser/Optical Technologist Sandia National Laboratories CA USA crcarle@sandia.gov -- NOTE: Remove "BOGUS" from email address to reply. ###### Message-ID: <3EFBE0FD.38BAE64C@tellabs.com> From: Kim Enkovaara Organization: Tellabs Oy X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Xilinx Webpack bugs bugs bugs References: <3EFA9377.E87AB5E7@yahoo.com> <0bWdnYD1_eGamWajU-KYvA@comcast.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 65 Date: Fri, 27 Jun 2003 09:15:25 +0300 NNTP-Posting-Host: 193.65.252.100 X-Complaints-To: newsmaster@saunalahti.com X-Trace: reader1.news.jippii.net 1056694525 193.65.252.100 (Fri, 27 Jun 2003 09:15:25 EEST) NNTP-Posting-Date: Fri, 27 Jun 2003 09:15:25 EEST Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!news.tele.dk!news.tele.dk!small.news.tele.dk!newsfeed1!bredband!fi.sn.net!newsfeed2.fi.sn.net!feeder2.news.jippii.net!reader1.news.jippii.net!53ab2750!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:30052 Patrick MacGregor wrote: > > In 20 years in this business (primarily telecom/datacom), I've never once > had a situation where bloat was allowed. Bloat = added cost that doesn't go Bloat is never good, but if you want to get the product really out you need to cut some corners. Especially with ASICs some random logic does not matter, you can fit ~200-300kgates/mm^2 (of course power usage can be a problem). > Having recently done an OC48 framer design (in a couple of weeks), I could > have easily aimed at something like a 1C6 or 1C12 Cyclone part. Instead I > aimed for a 1C3 part in the slowest speed grade. Works just fine, using > about 1/3 of the LCs. A 1C3 costs 1/2 of a 1C6 roughly, yet the 1C6 is not > "expensive". Choosing to design efficiently added exactly zero time penalty > but yielded tremendous cost savings. There shouldn't be any big differences between propely written HDL and schematics. Good high level RTL might even do better results because good synthesizers can do some quite amazing tricks to the design. For example sometimes FSM optimizations are very nice, quite few schematics designers can do those kinds of code transformations in their head. > One startup I worked for had an embedded designer assigned to one or more > ATM interface cards. These guys wrote in assembly only, and because of this > were able to keep up with ATM at OC-3 rates using a very slow, primitive > (i.e. inexpensive) micro. And what was the cost of maintaining that super optimized code after the guys left the company, and someone had to understand the code to fix bugs. And what was the engineering cost of that code compared to very straightforward implementation and little more expensive processor? It's always nice to make optimized code but sometimes it's not worth of it. > I regularly test whether or not an HDL can create logic more efficiently > than me. It can't. Not once has it implemented any type of decoding > function better than I can. It can match me in terms of resources utilized, > but it can't best me. By staying in the gates, I always have an instant Are you sure you can write good HDL? Different HDL coding styles can procude quite different results. > The best HDL folks I know are ones who use it like it was a schematic. So, > in my mind, why bother? And again, I've never had the luxury of NOT needing The best HDL guys I know use it completely differently than schematics. They use advanced datatypes for busses, functions , code generation and other advanced things (yes they are VHDL coders). And the code procuded is very concise, easy to read, produces very good synthesis results and is easy to debug in simulator. They might even use graphical editors for complex state machines because that is the fastest way to do them, and let the machine to optimize the design. > > I don't know where you got this, but this sounds like an exaggeration. > > I would say he had it backwards, but I bet the schematic usage is less > > than 20%. > > > I got this right from the horse's mouth. I didn't make it up. It was his > observation of designs he's seeing. Why would he lie? He has no vested > interest in any method his clients use. Simply the stats he sees. He might have been some schematic FAE :) I haven't heard about any schematics designs for a long time for bigger FPGAs. For some CPLDs schematics is quite common way of doing simple clock dividers etc. > Guess you missed it when I said I simulated the designs, right before > testing them on the bench. I never skip simulating. Again though, I prefer > the graphical waveform version as I get to see a nice, pretty picture of > what is happening and when. It is very simple to pull up any flop in the > design and see it relative to anything else. Makes debugging go 10 times > faster. And, once I'm happy with it, I can transfer the simulator results > back into the input file so that I can compare expected to generated results > should I make changes or add new stuff. What could be simpler? My debugging would be at least 10000 times slower with waves. I have hundreds of simulations all running in the millisecond range at high clockspeeds. Drawing even waveforms for those simulations would take years. In HDL it takes just 50kloc of code that is easy to understand and also checks the results :) How long would it take from you to draw waveforms for 5000 PCI-BUS transactions (single+burst mixed randomly for example). It's alaso quite easy to find problems at RTL level. I just imagine what it would be to find the problem from 5Mgate design in netlist format. > For the duhsigner, perhaps. Personally, I've never found any job too large > for schematics, whether doing ASICs or FPGAs. And, you need schematics to > design PCBs, so the extra practice doesn't hurt. How big designs have you really made and how repetitive have they been? I'd like to see someone do 1Mgate random logic with schematics. And that is quite small FPGA/ASIC nowadays. I have seen schematics for old 50kgate etc. chips and they already are many thick folders of schematics. --Kim ###### From: Martin Thompson Newsgroups: comp.arch.fpga Subject: Re: Xilinx Webpack bugs bugs bugs Date: 27 Jun 2003 09:06:07 +0100 Organization: TRW Conekt Lines: 95 Sender: thompsonmj@1WVMP0J-DT Message-ID: References: NNTP-Posting-Host: 194.74.228.66 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: fu-berlin.de 1056701171 30417066 194.74.228.66 (16 [98603]) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeeder.edisontel.com!fu-berlin.de!uni-berlin.de!194.74.228.66!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:30043 "Patrick MacGregor" writes: > "Martin Thompson" wrote in message > news:uk7b9z2w8.fsf@trw.com... > > HDL doesn't force abstration - you can write gate-level HDL. There > >are illustrious people populating this group who frequently do the > >"design equivalent of assembly coding" in HDL. > > HDL by its very nature is abstraction in the same way that C abstracts > from assembly. You describe logic and let some piece of software try > to figure out what it means. > You *can* write 'at the assembly level' in HDL. In FPGA land, You can go as far as instantiating LUTs and FFs directly wiring them up. Is that assembly enough? > > Come to think of it, last time I did a schematic I used the > >"abstraction" of a counter block, which hides flops inside it. Only > >if you know how to make a counter do you know "where every flop is". > >And that's the same in HDL - I know I've written code that will mean > >a counter gets built, so I know what flops there are there. > > > > Hierarchies are not abstractions. Punch down into the counter to see > the design. Sadly, these days it will probably be an HDL, so if a > newbie wants to learn about counter design, it won't help any. > No, it could easily be a architecture-optimised, target-specific, low (LUT/FF) level description of how to build a counter. Which could be described equally well in HDL or schematic. > I've used numerous counter types to solve different prolbems. T-FF > based, Johnson counters, D-FF based. Each has a place if you know how > they are built and what their tradeoffs are. > And with a decent library (HDL or schematic) you can have any of those. In VHDL you could use a single generic to change the style of a particular counter very quickly - I'm sure you can do the same in schematic. Debugging: > > I go back to my simulation, with its models and all that 'waste of > >time'. > > > > Another advantage of this approach is that I can write a testbench > >that covers all my (many) testcases and reports a pass or fail at the > >end. That way I can modify any code I like and know I haven't > >recreated any old bugs. Not quite so easy when staring at > >waveforms... > > > > Well, I guess we mean different things when we describe "simulations". > The Quartus tools allow me to simulate the design without having to > "model" anything. I can take the actual design and throw signals at > it directly to see if it is doing what it should. If I've built the > circuit according to the timing diagrams, I should see resultant > waveforms that match what I expect. Very simple to follow visually, > and it has the added benefit that you see a lot more about what is > going on in the circuit instead of a simple "pass/fail". BTW, with > waveforms you can also do pass/fail tests really, really easily and > automatically. There is no penalty from using waveforms, but there is > a lot to gain. I'm not opposed to the use of waveforms, just that complex transaction based systems are easier for a machine to check than for *me* to do by eye. YMMV. Describing a complex testbench as a *simple* pass/fail is misleading also - the testbench will have run the UUT through all of its functionality, checking that the outputs do the right thing in all circumstances. Just like you are doing with the waveforms. > Also, when you debug the board, you should be able to > match appropriate I/O signals with ones witnessed in simulation. > Seeing a blinky light turn on doesn't mean a circuit worked. You have > to know how well it is working, and know what the signal integrity is > along the way. This usually means o'scopes, which means, you guessed > it, waveforms. > Indeed - and there's no reason that because you use an HDL and automated testbench that you don't understand how the system should look 'in real life'. I'm quite at home with scope, logic analyser, printout of simulation waveforms and datasheets - never have enough bench space! I just find various other techniques helpful to my methodology as well. Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt, Solihull, UK http://www.trw.com/conekt ###### Message-ID: <3efc3f06$0$23104$5a62ac22@freenews.iinet.net.au> From: hamish@cloud.net.au Subject: Re: Xilinx Webpack bugs bugs bugs Newsgroups: comp.arch.fpga References: User-Agent: tin/1.5.19-20030610 ("Darts") (UNIX) (Linux/2.4.20 (i586)) Date: 27 Jun 2003 12:56:38 GMT Lines: 44 NNTP-Posting-Host: 203.217.48.13 X-Trace: 1056718598 freenews.iinet.net.au 23104 203.217.48.13 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.stueberl.de!fu-berlin.de!newsfeed.iinet.net.au!newsfeed.iinet.net.au!freenews.iinet.net.au!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:30091 David Brown wrote: > FPGA design is the same. Some things can be better expressed as schematics, > especially for small designs, and some designers will work better with > schematics than HDL depending on their background, experiance, and > interests. But to suggest that schematics are always easier to understand, > or to design, or will always generate faster/smaller circuits, is just > silly. Obviously this argument depends on your definition of 'better'. The schematic might produce fewer FFs/LUTs, but that's all. It won't be more extendable, more generic, more reusable, or quicker to design. Unless you're talking about a trivial design - I'm talking about a design which can fill a pair of 2V6000s. For the last nine months I've been working (in a team) on a design where the major components are common to five different PCBs, using a mix of Virtex-E and Virtex-II, speeds from 25 MHz up to 175 MHz, and even different internal bus formats from one board to the next. VHDL lets you parameterise your code so you can do things like this. The final code for this design (synthesisable design plus test benches) appears to run to about 800,000 lines. It's been argued that schematics give you control over the gates and flip-flops that you don't get in VHDL. Firstly, that's wrong; you can instantiate individual FFs and LUTs in your source code and have the synthesiser just pass them through. Or you can code so that the synthesiser infers exactly what you want. It's not always easy and usually requires hints (attributes) to the synthesiser. But more importantly, IMHO the big advantage of HDL is that I don't always have to worry about the exact FFs and LUTs. Sure, some of the time I have to think about every last detail to get the design to run fast. But that's what, 20-30% of the design at most? I don't want to worry about the rest. If it runs fast enough and doesn't take too much space then I've got better ways to use my time, like testing. Often maintainability and reusability are more important than saving every last flip flop, and schematics don't have a chance compared to well-written HDL code. Hamish -- Hamish Moffatt VK3SB ###### From: "Richard Erlacher" Newsgroups: comp.arch.fpga References: <3EFA1ED4.16F6B3C3@yahoo.com> Subject: Re: Xilinx Webpack bugs bugs bugs Date: Sat, 28 Jun 2003 13:34:58 -0600 Lines: 186 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 NNTP-Posting-Host: 216.98.199.156 X-Original-NNTP-Posting-Host: 216.98.199.156 Message-ID: <3efdedc7@mindmeld.idcomm.com> X-Trace: 28 Jun 2003 19:34:31 GMT, 216.98.199.156 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!enews.sgi.com!news-out.superfeed.net!propagator2-maxim!news-in-maxim.spamkiller.net!news.he.net!dimensional.com!pulsar.dimensional.com!207.40.197.76.MISMATCH!mindmeld.idcomm.com Xref: chonsp.franklin.ch comp.arch.fpga:30127 Not all the packages on the market are unuseable in their own right, but, having had similar experience with software from Xilinx, I have to agree that it could be improved. However, it's not always the software alone. The documentation stream available on the support web site could benefit from segregation between classes of problems, particularly between those that have little in common, e.g. CPLD's vs. FPGA's. Part of the original post's complaint is clearly a problem of pilot error/RTFM, since changing the mode of the editor prior to attempting a move will eliminate the "... causes a loop" problem. What I'd find helpful, however, would be that gross failures as are common in the testbench waveform editor were documented such that one couldn't enter the program without the disclaimer: "caution ... you're about to waste weeks of your valuable time on a bit of software that needs a fix, and badly ..." or something on that order. When fixes are scheduled, it should be a policy that unwitting users of the currently flawed versions be warned immediately, or that the module simply be omitted. One unfortunate side effect of the shift to the major HDL's is the increase in volume of paperwork. A design that will fit on a single sheet of schematic often takes dozens if not hundreds of pages of HDL, and that means one's work is vulnerable to all the simple but common "typer-geographical" errors we all make from time to time. A 4-page ABEL design takes dozens of pages of VHDL. Presenting a one-page schematic, or a hierarchy of schematics makes a lot more sense to managers and software types than does a listing of HDL. There will always be a place for schematics, since a picture, still, is worth 1000 words ... perhaps more in VHDL. Now, it's likely that the schematic entry will continue to be poorly supported, and that software, e.g. XILINX' web back (not to pick on them, since they're not alone) but it's a pity that features that can be entered in the schematic tool by means of features specifically provided for that purpose are ignored/overridden by software. Right now, it's possible to specify features in the schematic editor, only to have it ignore them. Additionally, there are somewhat vital features that are established as defaults, that are not overridden by explicit specification of these features in the schematic tool. That can certainly produce frustration. It's necessary to have defaults, but I'd think the defaults would only be of interest if those parameters are not explicity entered somewhere in the process. Having the software impose defaults despite the explicit setting of a given attribute is VERY annoying. Richard Erlacher "rickman" wrote in message news:3EFA1ED4.16F6B3C3@yahoo.com... > Yes, you have discovered the not-so-secret of the lack of bug support > for schematic users. I can't say this is unique to Xilinx since I have > never tried schematic with Altera parts. But I expect the problem will > not get better with time. I can say I am a bit surprised. A few years > ago Xilinx was using an editor that was not perfect, but worked ok. I > guess this was something they were paying for per license and were > eating the cost. To save that fee I assume they switched to something > they bought or wrote in house. > > Regardless, you will be better off using an HDL than schematics. A lot > of people fought tooth and nail against HDL, but it is a better solution > for large designs and the FPGA vendors really don't want to have to > support both. So the support for schematic is not good simply because > not many people use it and why spend money supporting something that is > little used. I know you are thinking, "why have it if you don't support > it?" I can't answer that one, you will need to ask X and A. > > But I can say you are definitely swimming upstream with schematic > capture. I know I did my last schematic design some years ago and will > not look back (or look the schematics up :) Keep in mind the number of > bugs you have found so far and you only worked for half a day. Wait > until you try to place and route your schematic design! You will really > be having fun then! Just think of all the newer chip features and how > poorly they will be supported via schematic. > > > > Chris Carlen wrote: > > > > Hi: > > > > Here's a chronicle of today's headaches. > > > > 1. ECS schematic editor can't deal with filenames that contain anything > > except 0-9 a-z A-Z . > > > > 2. I selected a large block of schematic, and when I tried to move it, > > ECS said "Internal Error: Delete Branch" > > > > 3. I guess nobody uses schematic entry because the editor is simply > > impossible to use. It is an absolute disaster. I try to select a group > > of objects to move, and it simply won't let me select them. They don't > > highlight. I try to select everything I have drawn to move it, and I > > get error mentioned in #2 above. The autorouting is useless. Get rid > > of it. Hint: humans are smarter than computers. Just let me draw my > > own wires. > > > > 4. Oh good grief, I moved some things, and then I simply cannot select > > anything anymore. > > > > You see folks, when you make software this bad, even if it is free, > > rather than making me want to pay for the "good" software, it makes me > > think you simply can't write good software. What evidence do I have > > that if I pay for your non-free tools, that they will be any better? > > None. On the contrary, I have volumous evidence that I will simply be > > paying for the exact same thing, only I will not only be frustrated, but > > poorer. The end result is the same. I can't use your silicon. > > > > So perhaps I have made a big mistake. Perhaps I should have gone with > > Altera. I just don't know now. > > > > Or perhaps analog design would be a way to avoid all this crap > > altogether. I don't seem to have much trouble with SPICE simulators. > > Heck even Linear Technology's LTSpice *FREE* simulator is very useable. > > > > Argh! > > > > 5. I closed the schematic editor hoping that if I re-opened my file it > > might reset som eof its internal data structures, and start working > > again. Now I try to reopen my schematic source from Project Navigator, > > and nothing happens. It simply sits there when I click "open". > > > > > > > > Nope this is reality. Bummer. > > > > Aha! Project Navigator couldn't open my source because it didn't have > > the same name that I created it with. I created it as "cross32-52" > > which Project Navigator accepted just fine. But ECS wouldn't save the > > file with this name, even though it opened it the first time. So I > > saved it as something else, which of course broke Project Navigator. > > Well that's certainly my fault. I should have expected ECS to not save > > filenames with '-' characters. > > > > 6. After closing everything an reopening, I can select and move things > > in ECS again. Oh joy! > > > > 7. I wanted to start a new project to develop a modified version of a > > previous design done from scratch in 5.2i. I copied the .sch and .ucf > > files to the new project dir. I can edit the schematic, so I deleted > > some stuff I didn't want in there. Then I can't open the .ucf file > > because it has nets that aren't in the schematic. I don't know why in > > the original project, when I would add or remove nets from the > > schematic, the user constraints file was automatically updated to > > reflect the nets in the schematic. This doesn't work now, but perhaps > > it's because there is some file missing. > > > > So I will remove the .ucf source and add a new one which I'll set up > > from scratch. I click "remove" and then I add a new source, a user > > constraints with the same name as the one that isn't working. Project > > NAvigator prompts me if I want to overwrite the old file. I click "Ok" > > and expect that when I open the new .ucf file, it will be a reflection > > of the nets in my schematic. > > > > No such luck, the broken .ucf was not everwritten, so it still complains > > of errors of missing nets. > > > > Well that's all before lunch time. Let's see what happens this afternoon... > > > > I guess if there's a point to all this, I should look around on Xilinx's > > web site some more and find out where to report bugs. But I have > > reached a point with software in general where I am tired of doing this. > > That is because, I often wind up spending hours reporting the bugs in > > the rigorous detail that is needed if there is to be any hope of anyone > > actually fixing them. Unless of course, the software had been > > rigorously tested in the first place. > > > > -- > > _______________________________________________________________________ > > Christopher R. Carlen > > Principal Laser/Optical Technologist > > Sandia National Laboratories CA USA > > crcarle@sandia.gov -- NOTE: Remove "BOGUS" from email address to reply. > > -- > > 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 ###### From: rickman Newsgroups: comp.arch.fpga Subject: Re: Xilinx Webpack bugs bugs bugs Date: Sun, 29 Jun 2003 00:22:06 -0400 Organization: Arius, Inc Lines: 45 Message-ID: <3EFE696E.9D679FD6@yahoo.com> References: <3EFA1ED4.16F6B3C3@yahoo.com> <3efdedc7@mindmeld.idcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVYC2EbMW3Dvw8dEE3t/tP5A0P25LjNs3Ve2uApMaZ3mvL0O1TxLuWv5 X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 29 Jun 2003 04:22:16 GMT X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.imp.ch!news.imp.ch!206.252.192.28.MISMATCH!news.stealth.net news.stealth.net!news.stealth.net!news-out.visi.com!petbe.visi.com!dca1-feed2.news.algx.net!allegiance!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:30118 Richard Erlacher wrote: > > One unfortunate side effect of the shift to the major HDL's is the increase > in volume of paperwork. A design that will fit on a single sheet of > schematic often takes dozens if not hundreds of pages of HDL, and that means > one's work is vulnerable to all the simple but common "typer-geographical" > errors we all make from time to time. A 4-page ABEL design takes dozens of > pages of VHDL. Presenting a one-page schematic, or a hierarchy of > schematics makes a lot more sense to managers and software types than does a > listing of HDL. I don't know what designs you do, but I find my HDL is very terse compared to a schematic. Unless the drawing library has some sort of macro generator, a 32 bit wide bus is a lot more work, even with heirarchy, than a single bit data path. In HDL it is normally just a simple notation on the declaration. Random logic is always very hard on schematic. But a 5 schematic page FSM becomes some 20 lines of HDL. Address decoding is just a single line of HDL in most cases, but can be a half a page of gates and wires. > There will always be a place for schematics, since a picture, still, is > worth 1000 words ... perhaps more in VHDL. Only if you have pictures the size of a Greyhound Bus! I use pictures to *document* the HDL since they give a level of clarity to the data path that is not nearly as clear in text. But I don't need schematics, I can use Visio or any other drawing package that works well and is target independant. -- 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 ###### Message-ID: <3EFE6E92.8BE@designtools.co.nz> From: Jim Granville Reply-To: jim.granville@designtools.co.nz Organization: Mandeno Granville elect X-Mailer: Mozilla 3.0C-XTRA (Win95; I) MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Xilinx Webpack bugs bugs bugs References: <3EFA1ED4.16F6B3C3@yahoo.com> <3efdedc7@mindmeld.idcomm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 12 Date: Sun, 29 Jun 2003 16:44:02 +1200 NNTP-Posting-Host: 203.79.102.143 X-Complaints-To: abuse@tsnz.net X-Trace: news02.tsnz.net 1056861820 203.79.102.143 (Sun, 29 Jun 2003 16:43:40 NZST) NNTP-Posting-Date: Sun, 29 Jun 2003 16:43:40 NZST Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.imp.ch!news.imp.ch!newsfeed.stueberl.de!ecngs!feeder.ecngs.de!128.242.171.84.MISMATCH!news-out1.nntp.be!propagator2-sterling!In.nntp.be!newsfeed01.tsnz.net!news02.tsnz.net!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:30122 Richard Erlacher wrote: > > One unfortunate side effect of the shift to the major HDL's is the increase > in volume of paperwork. A design that will fit on a single sheet of > schematic often takes dozens if not hundreds of pages of HDL, and that means > one's work is vulnerable to all the simple but common "typer-geographical" > errors we all make from time to time. A 4-page ABEL design takes dozens of > pages of VHDL. Sounds like a good argument for staying with ABEL ? -jg ###### Reply-To: "Nial Stewart" From: "Nial Stewart" Newsgroups: comp.arch.fpga References: Subject: Re: Xilinx Webpack bugs bugs bugs Date: Mon, 30 Jun 2003 14:20:49 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Lines: 82 Message-ID: <3f003721$0$7741$fa0fcedb@lovejoy.zen.co.uk> Organization: Zen Internet NNTP-Posting-Host: 217.155.72.198 X-Trace: 1056978721 lovejoy.zen.co.uk 7741 217.155.72.198 X-Complaints-To: abuse@zen.co.uk Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.icl.net!newsfeed.fjserv.net!diablo.theplanet.net!zen.net.uk!lovejoy.zen.co.uk.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:30176 Patrick MacGregor wrote in message news:m6qcnRkZZZGrm2ajXTWJig@comcast.com... > > > > HDL doesn't force abstration - you can write gate-level HDL. There > > are illustrious people populating this group who frequently do the > > "design equivalent of assembly coding" in HDL. > > HDL by its very nature is abstraction in the same way that C abstracts from > assembly. You describe logic and let some piece of software try to figure > out what it means. Just the way a schematic editor has to work out what that connection you've drawn between two nodes means. In the following simplest example.... process(clk,reset) begin if(reset = '1') then signal1 <= '0'; signal2 <= '0'; elsif(rising_edge(clk)) then signal1 <= input; signal2 <= signal1; end if; end process; ...signal1 can be nothing but a wire connection between two registers. Don't forget an HDL _is_ a Hardware Description Language. > Well, I guess we mean different things when we describe "simulations". The > Quartus tools allow me to simulate the design without having to "model" > anything. I can take the actual design and throw signals at it directly to > see if it is doing what it should. If I've built the circuit according to > the timing diagrams, I should see resultant waveforms that match what I > expect. Very simple to follow visually, and it has the added benefit that > you see a lot more about what is going on in the circuit instead of a simple > "pass/fail". BTW, with waveforms you can also do pass/fail tests really, > really easily and automatically. There is no penalty from using waveforms, > but there is a lot to gain. Also, when you debug the board, you should be > able to match appropriate I/O signals with ones witnessed in simulation. > Seeing a blinky light turn on doesn't mean a circuit worked. You have to > know how well it is working, and know what the signal integrity is along the > way. This usually means o'scopes, which means, you guessed it, waveforms. In another part of this thread you mentioned an OC-48 framer you'd developed. In the not too distant past I developed a PDH -> STM1 framer capable of all PDH -> STM1 structures. This was for a piece of test equipment and so was very configurable needing significant uP register configuration before anything sensible would happen. In VHDL I wrote a simple model of the uP to drive my FPGA uP interface. This model then read a list of instructions (rd/wr), addresses and values from a text file to allow easy configuration of the device for different modes of operation. Changing the text file allowed the tests to be changed without touching the testbench. I wouldn't like to think about how long this would take trying to set up waveforms to drive the DUT. Nial. ------------------------------------------------ Nial Stewart Developments Ltd FPGA and High Speed Digital Design www.nialstewartdevelopments.co.uk