Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
does someone know, where to get some vhdl code or a description of working code for a DCF 77 - clock. thanks azeArticle: 21476
I'm all in favour of open source, and I've done more than my share of GNU hacking, but it's time for a reality check. When I last tried Alliance, it was completely unusable for any real work. I haven't tried Icarus, but imagine how a commercial product would fare on this NG if all that could be said for it was "needs some work, I know, but the core is there". FreeHDL seems to be alive, just, but I'm not holding my breath. The general problems of placement and routing have been done to death, but they're no use by themselves. Timing analysis is completely different, is non-trivial, and requires a detailed understanding of the silicon. You need a parasitic extractor, a good propagation delay model, knowledge of the effects of voltage, process, and temperature variations, and probably lots of other things I've never even heard of, before you can even start on the 'easy' bits. The people who understand this sort of stuff are unlikely to have enough free time to give away all their knowledge for nothing. And how do you test a timing analyser? You need a lot of people, a lot of money, several years, and a lot of angry users. By comparison, writing a kernel or a compiler, or most of the other bits you find in GNU (aka Linux, more-or-less), is kid's stuff, and can be done (and has, many times) by a clever college student. They're self-contained problems; anyone can test a compiler. However, some guy sitting in his bedroom on a rainy weekend is never going to be able to test or fix a timing analyser, however clever he is. That's why we have commercial software. Evan On 22 Mar 2000 23:07:20 GMT, ldoolitt@recycle (Larry Doolittle) wrote: >Andy Peters (apeters.Nospam@nospam.noao.edu.nospam) wrote: > >: [ chop ] you think that you're just going to be able to, in your spare >: time, write a synthesis tool, > >http://icarus.com/eda/verilog/ > (needs some work, I know, but the core is there) > >: a placement engine, a router, > >http://www.eecg.toronto.edu/~vaughn/vpr/vpr.html > >: and a timing analyzer? > >Someone would have to volunteer for this one, probably based on >ACS or one of the libre VHDL/Verilog simulators. > >: Is your background in writing code for synthesis tools? > >See Icarus, above, or http://www-asim.lip6.fr/alliance/ > >: Logic minimization? > >Classical logic minimization isn't terribly relevant for today's >FPGA architecture. The vpr code above handles some of what's left. > >: All the other stuff that's under the hood of these tools? > >Such as "project managers" and other GUI bits I don't want? > >: And do you think that your stuff, starting from scratch, will somehow be >: "better" than, say, Xilinx', who've had a ten-year head start on you (and a >: lot more resources to throw at the problem)? > >Quoting from the original post: >>> Every single time I"ve purchased hardware tied to >>> proprietary software the proprietary software, no matter how good, sucked >>> ass in the end and never ever did what I really wanted. No matter how >>> good, bug free, and featureful your proprietary software is and how naive, >>> buggy, and underfeatured the software I write will be, I ALWAYS prefer my >>> own. > >So no, he doesn't think he can do "better". But he (and I) _would_ be >happier, because we understand what the limitations are, and can >address them as _we_ need, independent of someone else's market research. > >: I would imagine that most of us who design with FPGAs for a living would >: much rather have the silicon vendors do the hard stuff -- the design >: software -- so we can get on with our jobs, which is building hardware. > >... and wrestling with license managers, and begging for more money >to pay for continued use of the software. > >Peter Alfke (peter@xilinx.com) wrote: > >: There is simply no way any one person in his or her lifetime can write > ^^^^^^^^^^ >: software that can even remotely compete in quality and performance with what >: Xilinx ( and Altera etc. ) have spent and are spending hundreds of thousands >: of man-hours on. > >OK, but how about a whole Internet full of people? That mindset >belongs in the 1980's. Essentially, you are telling your customers >to "shut up and get back on the couch." > >: Always with the sole intent to make it easier to design with the chips, >: because that's where we all make our money from. > >So release the bloody bitstream format already! Peter, I respect you >technically, but I also know who gives you your paycheck, and I know >the rules that corporations are legally obliged to follow. Those rules >have everything to do with money, and nothing to do with customer's >control over their design. In particular, the intent of Xilinx's >software is to lock their customers into Xilinx's chips. Ditto for >Altera. > >I'm about to shell out some taxpayers' money for a commercial package, >because the free stuff isn't there yet, and never will be if Xilinx >has its way. That doesn't mean I'm happy. > >I know this question gets hashed over in c.a.f every six months or so, >and I guarantee that pattern will continue until the problem is fixed. >Here's a scenario for how that will happen: some startup puts together >an FPGA, tries to sell it, goes belly up. Rather than selling the >charred remains to Xilinx, it releases the tested and functional (but >not profitable) chip design to the world. > >Sorry for the interruption. You can now return to the usual fare of >"Why can't I make the stoopid software tools do what I want" questions. > > - Larry Doolittle <LRDoolittle@lbl.gov>Article: 21477
Si quieres comprar o vender tu coche has venido al sitio ideal, desde aqui podras insertar anuncios gratis e informarte de todas las novedades del mundo del motor... y mucho mas. Visitanos en www.autovitrina.comArticle: 21478
In article <38d9f2b2.97616300@news.dial.pipex.com>, eml@riverside-machines.com.NOSPAM wrote: >I'm all in favour of open source, and I've done more than my share of >GNU hacking, but it's time for a reality check. When I last tried >Alliance, it was completely unusable for any real work. I haven't >tried Icarus, but imagine how a commercial product would fare on this >NG if all that could be said for it was "needs some work, I know, but >the core is there". FreeHDL seems to be alive, just, but I'm not >holding my breath. The general problems of placement and routing have >been done to death, but they're no use by themselves. You haven't even followed the conversation. I say again: If there exists closed-source software that is good, fast, bug-free, clever, etc., and open-source software that is bad, slow, buggy, naive, etc...I will still prefer the open-source program for my own entertainment. Perhaps if I were working somewhere and getting the product out the door were a lot more important than the experience of getting it there, I would chose differently. >Timing analysis is completely different, is non-trivial, and requires >a detailed understanding of the silicon. You need a parasitic >extractor, a good propagation delay model, knowledge of the effects of >voltage, process, and temperature variations, and probably lots of >other things I've never even heard of, before you can even start on >the 'easy' bits. The people who understand this sort of stuff are >unlikely to have enough free time to give away all their knowledge for >nothing. And how do you test a timing analyser? You need a lot of >people, a lot of money, several years, and a lot of angry users. > >By comparison, writing a kernel or a compiler, or most of the other >bits you find in GNU (aka Linux, more-or-less), is kid's stuff, and >can be done (and has, many times) by a clever college student. They're >self-contained problems; anyone can test a compiler. However, some guy >sitting in his bedroom on a rainy weekend is never going to be able to >test or fix a timing analyser, however clever he is. That's why we >have commercial software. Xilinx goes to lengths to make Xilinx-FPGA-oriented tools NOT doable by a college student, so your entire statement is rendered meaningless. If Intel went that far to make it so only MS could make protected mode OSs, you can bet your ass that Linux wouldn't be where it is. I'm certain that timing analysis is a more complex task than putting together the heart of a kernel, but that is not the same as saying that it is an untouchable problem.Article: 21479
Holger Azenhofer wrote in message <8bcos7$5cm@newsserv.vs.dasa.de>... >does someone know, where to get some vhdl code or a description of working >code for a DCF 77 - clock. Hi Holger, Not exactly VHDL, but you may have a look at my DCF77 decoder in C. http://home3.inet.tele.dk/kro/ Karl OlsenArticle: 21480
Greg Alexander <galexand@sietch.bloomington.in.us> wrote in message news:8bca7r$k50$1@jetsam.uits.indiana.edu... > In article <38D97E76.2DD0F61D@ids.net>, Ray Andraka wrote: > >Ya know Greg, you can get as close to the hardware as you want with the current > >tools and you'll get up to speed on the gory details of the FPGA a heck of a lot > >faster using the stuff that is already out there, even if it has a few bugs. You > >have a choice: you can spend all your time figuring out how to connect two CLBs > >together, or you can spend your time actually working with the FPGA and doing > >something with it. > > One way to look at it is that I want to drill a single hole in a single > piece of wood and you are pointing out to me how great a drill press is. > Why would I pay the cost of a large featureful system if I don't want the > features? I don't just mean financial cost, I mean in terms of complexity > and disk space and flexibility. > > The other way is that no matter how good, fast, fully-featured, clever, > and bug free that software is and no matter how bad, slow, under-featured, > naive, and buggy my software is (and by "my software" I refer to any > software that I really understand -- it need not be written by me, but I > do need the source), I would much prefer to have my software. I had a similar discussion with Xilinx back in 1988 or thereabouts, when they wanted me to pay $5000 for a piece of software so I could see if the Xilinx parts would be suitable for my application. I said to the Xilinx guy that they should give me the software for free like MMI did with Palasm, and if it worked they would make their money by selling me chips (after all, the tools only work with Xilinx chips). The Xilinx salesman explained that Xilinx is a *software* company, not a chip company. They only make chips so they can sell their development tools. I decided that I would ignore Xilinx for ten years, and revisit the issue. Twelve years on, I've decided to give them another chance, and so I'm looking at the Xilinx parts again. I'm sure they don't realize that they lost out on selling millions of Xilinx parts to go into my designs because they wouldn't give me their tools. I've been making do with PALs all these years... [As a side note, the issue in 1988 was whether you could really fit my intended design into their parts. I had an existing design, drawn by hand onto a bunch of C size sheets of vellum. The Xilinx guy was unwilling to refund my $5000 if the design didn't fit into the target part, even though a rough gate count made us think it should fit easily. He offered us a 30 day eval, but we judged that this would not be long enough.] -- Gary Watson gary@nexsan.sex (Change dot sex to dot com to reply!!!) Nexsan Technologies Ltd. Derby DE21 7BF ENGLAND http://www.nexsan.comArticle: 21481
A promising new telecommunications company in Portland, Oregon, needs IC designers and validation engineers at all levels--entry to management. Very competitive pay and benefits. Please respond with your resume, or call Margaret at 503-291-5250. All replies held in strict confidence. Sent via Deja.com http://www.deja.com/ Before you buy.Article: 21482
I understand your point. However, I think there are two things here. Either you want to play with what can the FPGA do, or you want to play with tools for the FPGA. If you really want to play with the FPGA to see what you can do with it, you'll get there much faster using the tools that are out there instead of rolling your own. When you need to run out to the store, I doubt you start by building the car to go in. Rather, you probably drive a mass produced car that fits your needs reasonably well but not perfectly. On the otherhand, if your desire is to learn how to make the tools then don't expect to use them to make useful things in the FPGA for quite a long time, especially if you only do it on weekends. That said, it would be nice to have more openness with respect to the bitstream, but I also understand the reluctance to do so. First, opening the bitstream gives considerably more visibility into the phsyical construction of the FPGA, something the FPGA vendors would understandably not want to give away to the competition. Second is the issue of support. The support for just the sanctioned tools flow is already a huge burden, and I think much more than a software only package. For software only support, you have a fairly well defined platform, so realistically the environment the software runs in is pretty well controlled. Now add to that mix the fact that with FPGA designs, people are also creating hardware. There are plenty of designs out there that, well how should we put this delicately...are not implemented very well for an FPGA. The support space is exponentially larger than the software only one. Now, if you start opening up to other tools, the support is even less constrained. Finally there is the issue of percieved design security. Granted a bitstream can be copied directly for a blatant rippoff, but at least the reverse engineering is made more difficult (not impossible) if the bitstream format and function is not disclosed. As I hinted in my previous post, it is possible to get a fairly good handle on the bitstream with alot of tedious work, but that is onerous enough that it represents more work than doing an original design. Greg Alexander wrote: > In article <38d9f2b2.97616300@news.dial.pipex.com>, > eml@riverside-machines.com.NOSPAM wrote: > >I'm all in favour of open source, and I've done more than my share of > >GNU hacking, but it's time for a reality check. When I last tried > >Alliance, it was completely unusable for any real work. I haven't > >tried Icarus, but imagine how a commercial product would fare on this > >NG if all that could be said for it was "needs some work, I know, but > >the core is there". FreeHDL seems to be alive, just, but I'm not > >holding my breath. The general problems of placement and routing have > >been done to death, but they're no use by themselves. > > You haven't even followed the conversation. I say again: > If there exists closed-source software that is good, fast, > bug-free, clever, etc., and open-source software that is bad, slow, buggy, > naive, etc...I will still prefer the open-source program for my own > entertainment. Perhaps if I were working somewhere and getting the > product out the door were a lot more important than the experience of > getting it there, I would chose differently. > > >Timing analysis is completely different, is non-trivial, and requires > >a detailed understanding of the silicon. You need a parasitic > >extractor, a good propagation delay model, knowledge of the effects of > >voltage, process, and temperature variations, and probably lots of > >other things I've never even heard of, before you can even start on > >the 'easy' bits. The people who understand this sort of stuff are > >unlikely to have enough free time to give away all their knowledge for > >nothing. And how do you test a timing analyser? You need a lot of > >people, a lot of money, several years, and a lot of angry users. > > > >By comparison, writing a kernel or a compiler, or most of the other > >bits you find in GNU (aka Linux, more-or-less), is kid's stuff, and > >can be done (and has, many times) by a clever college student. They're > >self-contained problems; anyone can test a compiler. However, some guy > >sitting in his bedroom on a rainy weekend is never going to be able to > >test or fix a timing analyser, however clever he is. That's why we > >have commercial software. > > Xilinx goes to lengths to make Xilinx-FPGA-oriented tools NOT doable > by a college student, so your entire statement is rendered meaningless. > If Intel went that far to make it so only MS could make protected mode > OSs, you can bet your ass that Linux wouldn't be where it is. I'm certain > that timing analysis is a more complex task than putting together the > heart of a kernel, but that is not the same as saying that it is an > untouchable problem. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 21483
On 22 Mar 2000 23:26:45 GMT, galexand@sietch.bloomington.in.us (Greg Alexander) wrote: > Here, I'll explain my complete gameplan so far: > I'm looking at the XS40 board with an XC4005XL on it, which is a >Xilinx FPGA with a 14x14 grid of FLBs. A quick browse of the datasheet >shows what attributes must be associated with each FLB, so I'd start out >by making something that takes a textual input description of each FLB [...] Hopefully a converter >to/from the bitstream and the simple text format would take me a couple >weekends...nothing too special.. There is no way... however a couple of weekends could see you hack together an interface between your textual format, whatever it is, and (say) the EDIF format input to the Xilinx tools. > At any rate, I'd be doing it for my own fun. I would enjoy failing >at designing a processor in FPGA from the ground up a lot more than I would >enjoy succeeding at performing the task with the use of tools that piss me >off. I'm very picky about my tools, and I can guarantee you that any >Windows software targetted at "students" would piss me off at every step >of the way. You needn't use them via the Windows interface if you don't want to, they work equally well from the command line. (and I believe, work under Linux?) > I don't need synthesis because I'll be laying it out like legos: a >stack here, an adder there -- ok... one of the major back-end tasks is placement. Given a really good placement, most of the other back-end tasks run pretty smoothly... routing can be an order of magnitude faster, and the finished design can be 30% faster... Currently the best way of placing logic is to use the floorplanner, which is a graphical tool to allow you to place logic by hand, using the hierarchy derived from the EDIF input file as a guide. Yet the Xilinx floorplanner is relatively weak. Someone could add a LOT of value by writing a decent placement tool that reads the input to the floorplanner (.fnf) file, performs an intelligent placement, and writes a file in floorplanner output format (.mfp). Both these files are pure ASCII (last time I looked ... in search of a MAP/floorplanner bug! ) and the floorplanner or your replacement can be seamlessly integrated into the design flow from a script or a batch file. This is a significant part of the whole process, with (it looks to me) an easy way in for an open source effort. That is ... an easy interface, which makes the task a self-contained problem. I'm not saying the task itself is easy! It's a classic problem that will soak up all the ingenuity you can throw at it. If your tool can't place all the logic, the PAR tool will happily place the rest, so you don't have to solve the whole problem at once. And the benefits of using your tool (or otherwise) are easily measured by comparing both place&route times, and the speed of the finished device, with an un-floorplanned place and route. Now there's a challenge to the open-source folks! An open-source router would be more difficult, unless Xilinx documented the .NCD file format. They go some way toward this by providing an NCD to ASCII file reader ncdread.exe (but no tool that does the reverse). Maybe they could be persuaded to document this format if (say) the open source community showed they were serious by cracking the placement problem? Peter? Which would only leave the relatively small Bitgen as a proprietary tool. I could live with that! > I fully expect for someone to reply that I'm stupid to expect the >commercial world doing all their Important Engineering for Real World >Tasks involving Large Salaries and Deadlines and all tehse other things >much too important for a mere college student to understand to give a darn >about some kid who just wants to fool around...but, well...where did you >start? If we couldn't have fun with this stuff, none of us that are any >good at it would even bother. You're right! Get yourself a TTL Data Book, a soldering iron (or wire-wrap gun), a bag of 74LSTTL, a good scope and get busy. Good experience, nothing secretive or inaccessible there, and precious little investment either. (hey you did ask .... only it was straight 74TTL back then!) >Unless you know exactly how Xilinx's software works, which I assume >you don't -- apparently it's not widely published information -- you >can't have absolute faith in it. I've been burned by prepackaged software >often enough that I'm reflexively mistrusting of it -- perhaps you >reflexively trust it because you've had good experiences with similar >software or perhaps you just don't care much about how efficient it is >since you know you don't have the time to do it all by hand so even if it >does badly, at least it gets the job done. The point is that neither your >trust nor my mistrust are justified unless we get the source or at least >some strong understanding of what's possible, and that's what I'm after. > Now if THAT's the issue then I think you can use Xilinx software and sleep a little more easily. Because everything up to the final bit file is visible in excruciating detail, if you really _want_ to look at it. e.g. using FPGA Editor or ncdread... The only step between the .ncd file and the bitstream is a 6k program called bitgen.exe. In every other step, at least you can inspect the results and see what it's doing. But you rarely need to... - BrianArticle: 21484
Larry Doolittle <ldoolitt@recycle> wrote: : So no, he doesn't think he can do "better". But he (and I) _would_ be : happier, because we understand what the limitations are, and can : address them as _we_ need, independent of someone else's market research. I would be a LOT happier too. :) I already said this in the opencores mailing list but nobody answered so here it goes again: I am willing to help reverse engineer the FPGA bitstreams and help to write placing/routing software. I don't have all the necessary skills myself but I truly believe that this is not an impossible task if enough people join the effort. If there is enough interest I can setup a mailing list so that we can start working on it. First thing to do is look for existing tools. Larry's post has very promising links. Later we will need the existing vendor tools to reverse engineer the tools themselves and/or the bitstreams they generate. I have access to several tools from different vendors (Xilinx, Altera, Cypress, ...) in my university. Of course it would be much better if they released the information and we didn't need to waste time reverse engineering it but I am not going to sit and wait. So if you are crazy enough to try it then send me an email or followup in this posting. Ruben - etruben@ua.ptArticle: 21485
Brian Drummond wrote: > > You're right! Get yourself a TTL Data Book, a soldering iron (or > wire-wrap gun), a bag of 74LSTTL, a good scope and get busy. Good > experience, nothing secretive or inaccessible there, and precious little > investment either. (hey you did ask .... only it was straight 74TTL back > then!) > Well DAMIT they don't make TTL any more. Well not the more complex stuff anymore as that is being phased out. Soon all that will be left are a few buffers and latches. The one thing I find funny is sales of the tiny logic devices - the single gate suff, used to patch chips up. Fuse pals are still around, but programers still cost a bit yet, with little software for linux. I really wonder how long eprom/flash devices last? Ben. -- "We do not inherit our time on this planet from our parents... We borrow it from our children." The Lagging edge of technology: http://www.jetnet.ab.ca/users/bfranchuk/woodelf/index.htmlArticle: 21486
Greg Alexander wrote in message <8bbqci$jdq$1@jetsam.uits.indiana.edu>...
>If I knew how to make PC boards without screwing myself over with
>capacitance at high frequencies, I certainly would buy simple PALs, now
>that I know that the FPGA development world doesn't have any interest in
>being my friend. :) Too bad I don't think I could quite implement an
>entire Forth processor in a single PAL. :)
Hey, you hit on something there that you probably don't even realize.
Assume you were able to code your own FPGA development tools, and you've got
a bit-stream for your nifty Forth processor, and it fits easily into one of
the Xilinx Spartan devices.
But, an FPGA sitting in space by itself is fairly useless. So, you need a
PC board. Are you going to write your own board-layout software, too? In
that arena, you've got some advantages, because all of the relevant file
formats (gerber, edif, etc) are documented.
But how much money do you want to burn through when you design your board,
and it doesn't work, and you don't know whether it's your FPGA design, or
your board design, or the tools? One-off four-layer PCBs ain't cheap. The
design I'm working on now has an eight-layer board.
Good board-design tools aren't cheap. Signal integrity analysis tools that
can back-annotate to your board layout aren't cheap. Multiple board revs
REALLY aren't cheap. I didn't even mention the fact that high-speed board
design is, in itself, an art and it's something you just don't "pick up."
If you're a student and your time is 'free,' then have at it. If you've got
a schedule and a boss, your perspective changes.
-- andy
ps: I looked at that freeware VHDL simulator, Symphony. No graphical
waveform display. That limits its usefulness, eh?
-----------------------------------------
Andy Peters
Sr Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) noao \dot\ edu
"Money is property; it is not speech."
-- Justice John Paul Stevens
Article: 21487In article <8bca7r$k50$1@jetsam.uits.indiana.edu>, Greg Alexander <galexand@sietch.bloomington.in.us> wrote: >One way to look at it is that I want to drill a single hole in a single >piece of wood and you are pointing out to me how great a drill press is. >Why would I pay the cost of a large featureful system if I don't want the >features? I don't just mean financial cost, I mean in terms of complexity >and disk space and flexibility. I don't think your analogy is reasonable. Even to do a very simple thing on a modern FPGA, you are GOING to want to use the tools provided. So it's not like "I have to drill a single hole in a block of wood", it's more like "I have to mill away this, this, and this", even for a very simple operation. So you wolud want to use a milling machine, not just a hand drill. And do you realize what the cost is for a set of tools for ASIC development? Custom VLSI development? FPGA tools are cheap, you can often get a free set of the student tools included in textbooks on logic design. >The other way is that no matter how good, fast, fully-featured, clever, >and bug free that software is and no matter how bad, slow, under-featured, >naive, and buggy my software is (and by "my software" I refer to any >software that I really understand -- it need not be written by me, but I >do need the source), I would much prefer to have my software. It seems that this is a political and moral issue for you, not just a practical issue. Practically, the complexity of modern FPGAs and modern tools are such that you won't be able to write the software yourself, or even debug the software. Finally, athough buggy, most of the bugs show up when you REALLY push the tools. >>is something I avoid like the plague. BTW, getting the bitstream >>format under NDA is not exactly unheard of, even for graduate >>students. >Why should I sign away parts of my future just to get information I should >get for free? A) You aren't really signing away much/any of your future. You really can't operate at the bleeding edge of research without being willing to sign the occasional NDA. B) Why do you think this information should be free? Xilinx is in the business of selling FPGAs, and there is a fair amount of interesting intellectual property stuck away in those bitfiles. The tools are close enough to free for a hobbyiest-level project, considering the complexity of the tools and the parts. C) As the LogicBlox people at xilinx (their Java based module generator system) told us a couple years ago, "Java decompilers are really good. Nudge nudge, wink wink". -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 21488
Hi, My recommendation is the "HDL Chip Design" it have examples in verilog as well as in Vhdl, also you should consider also buying one referance book in Verilog or Vhdl. (if you have openbook you can save the verilog book, and maybe Vhdl have something similar) have a nice day Illan In article <qJWB4.19073$YU2.424590@typhoon.ne.mediaone.net>, pratipm@yahoo.com (Pratip Mukherjee) wrote: > I want learn about FPGA and VHDL or Verilog programming. I am planning to buy > the kit from XESS Corp. along with their book and software. Is that sufficient > for learning or should I also buy a standard book on the subject? In that case > which book has good practical examples for the starters to try (which are not > too simple like blink a LED nor too difficult like design of a 16bit RISC > processor, as in the recent Circuit Cellar article? > Thanks. > > Pratip Mukherjee > Sent via Deja.com http://www.deja.com/ Before you buy.Article: 21489
In article <38DA3B17.EF5C5E80@ids.net>, Ray Andraka wrote: >I understand your point. However, I think there are two things here. Either >you want to play with what can the FPGA do, or you want to play with tools for >the FPGA. If you really want to play with the FPGA to see what you can do >with it, you'll get there much faster using the tools that are out there >instead of rolling your own. When you need to run out to the store, I doubt >you start by building the car to go in. Rather, you probably drive a mass >produced car that fits your needs reasonably well but not perfectly. On the >otherhand, if your desire is to learn how to make the tools then don't expect >to use them to make useful things in the FPGA for quite a long time, >especially if you only do it on weekends. No, I totally disagree. Without specs, I know that I will always be LIMITED to their software, so it's not a training wheels situation. Also, I'm not going to go to extreme lengths (installing Windows) just to make their software run since their software doesn't do what I want. Also, I don't want to learn VHDL and all these high level lanugages and interfaces, I simply want to do the thing by hand. I don't want to build a car from pieces. This is simply a preference, and one that Xilinx shouldn't be disallowing. >That said, it would be nice to have more openness with respect to the >bitstream, but I also understand the reluctance to do so. First, opening the >bitstream gives considerably more visibility into the phsyical construction of >the FPGA, something the FPGA vendors would understandably not want to give >away to the competition. Second is the issue of support. The support for It's a well-known industry fact that everything that can be reverse-engineered has already been reverse-engineered by the competition so all they're hurting is their customers. >just the sanctioned tools flow is already a huge burden, and I think much more >than a software only package. For software only support, you have a fairly >well defined platform, so realistically the environment the software runs in >is pretty well controlled. Now add to that mix the fact that with FPGA >designs, people are also creating hardware. There are plenty of designs out >there that, well how should we put this delicately...are not implemented very >well for an FPGA. The support space is exponentially larger than the software >only one. Now, if you start opening up to other tools, the support is even >less constrained. Finally there is the issue of percieved design security. I don't see why Xilinx would have any obligation to support Joe Blow Linux Hacker trying to use his cheap obviously unsupported homegrown bitstream generation software. >Granted a bitstream can be copied directly for a blatant rippoff, but at least >the reverse engineering is made more difficult (not impossible) if the >bitstream format and function is not disclosed. As I hinted in my previous >post, it is possible to get a fairly good handle on the bitstream with alot of >tedious work, but that is onerous enough that it represents more work than >doing an original design. They sell FPGAs that are given a command and then they disable read back until reprogramming. Anyone willing to go to the lengths to get around that would also be willing to go to the lengths to reverse-engineer the bitstream.Article: 21490
I'm interested in finding out if anybody has published data or estimates for HDL/RTL-based FPGA design productivity, e.g. something in person hours per logic cell, per line of HDL code, etc. Obviously we're talking about _massive_ generalization here, since there are so many variables: - Nature of design ... data flow, state machine, etc. - Experience of the designers - Use of macros, cores, etc. - Aggressiveness of clock rate, device utilization, etc. - ... So, it may be virtually impossible to create anything meaningful. Still, I'd be interested to see if anybody has tried. Thanks, Bruce. -- -------------------------------------------------------- Bruce Oakley [ oakley@amirix.com ] Principal Hardware Designer AMIRIX Systems, Inc. PH: (902)450-1700 x 245 Halifax, Nova Scotia, CANADA FX: (902)450-1704 --------------------------------------------------------Article: 21491
In article <9nfkdssa8jmmqgecu3kad1p4f5625pnjvg@4ax.com>, Brian Drummond wrote: >On 22 Mar 2000 23:26:45 GMT, galexand@sietch.bloomington.in.us (Greg >Alexander) wrote: > >> Here, I'll explain my complete gameplan so far: >> I'm looking at the XS40 board with an XC4005XL on it, which is a >>Xilinx FPGA with a 14x14 grid of FLBs. A quick browse of the datasheet >>shows what attributes must be associated with each FLB, so I'd start out >>by making something that takes a textual input description of each FLB >[...] Hopefully a converter >>to/from the bitstream and the simple text format would take me a couple >>weekends...nothing too special.. > >There is no way... Oh bullshit. Don't be telling me what I can and cannot do unless you're also going to tell me how to do what you don't think I can do without your help. Otherwise you're exercising arrogance or ignorance or similar, and certainly not contributing anything useful. If you stop me from trying, what will you have accomplished? >> At any rate, I'd be doing it for my own fun. I would enjoy failing >>at designing a processor in FPGA from the ground up a lot more than I would >>enjoy succeeding at performing the task with the use of tools that piss me >>off. I'm very picky about my tools, and I can guarantee you that any >>Windows software targetted at "students" would piss me off at every step >>of the way. > >You needn't use them via the Windows interface if you don't want to, >they work equally well from the command line. (and I believe, work >under Linux?) Not officially, at least. You can get them to run under Wine apparently but why pay for software that I will only be able to run sketchily at best that I blatantly DO NOT WANT? >> I don't need synthesis because I'll be laying it out like legos: a >>stack here, an adder there -- > >ok... > >one of the major back-end tasks is placement. Given a really good >placement, most of the other back-end tasks run pretty smoothly... >routing can be an order of magnitude faster, and the finished design can >be 30% faster... Currently the best way of placing logic is to use the >floorplanner, which is a graphical tool to allow you to place logic by >hand, using the hierarchy derived from the EDIF input file as a guide. >Yet the Xilinx floorplanner is relatively weak. > >Someone could add a LOT of value by writing a decent placement tool that >reads the input to the floorplanner (.fnf) file, performs an intelligent >placement, and writes a file in floorplanner output format (.mfp). >Both these files are pure ASCII (last time I looked ... in search of a >MAP/floorplanner bug! ) and the floorplanner or your replacement can be >seamlessly integrated into the design flow from a script or a batch >file. > >This is a significant part of the whole process, with (it looks to me) >an easy way in for an open source effort. That is ... an easy interface, >which makes the task a self-contained problem. I'm not saying the task >itself is easy! > >It's a classic problem that will soak up all the ingenuity you can throw >at it. If your tool can't place all the logic, the PAR tool will happily >place the rest, so you don't have to solve the whole problem at once. > >And the benefits of using your tool (or otherwise) are easily measured >by comparing both place&route times, and the speed of the finished >device, with an un-floorplanned place and route. I have no interest in making software for other people as part of this project. I want to write the software necessary to do my own work and no more or less. I'm not looking for weaknesses in existing software to let me get my foot in the door, I simply have no interest at all in the existing software (unless it's open source,t hen I could understand it and make it my own). >Now there's a challenge to the open-source folks! > >An open-source router would be more difficult, unless Xilinx documented >the .NCD file format. They go some way toward this by providing an NCD >to ASCII file reader ncdread.exe (but no tool that does the reverse). >Maybe they could be persuaded to document this format if (say) the open >source community showed they were serious by cracking the placement >problem? Peter? No, I stand firmly by my current judgement that Xilinx doesn't give a hoot about product quality, they just want to sell 'em. >Which would only leave the relatively small Bitgen as a proprietary >tool. I could live with that! No, becasue bitgen is small and simple and I could write something vageuly similar in a few weekends, yet i'd be paying significant money for it and keeping around significant bloat on my disk for it. No thanks. >> I fully expect for someone to reply that I'm stupid to expect the >>commercial world doing all their Important Engineering for Real World >>Tasks involving Large Salaries and Deadlines and all tehse other things >>much too important for a mere college student to understand to give a darn >>about some kid who just wants to fool around...but, well...where did you >>start? If we couldn't have fun with this stuff, none of us that are any >>good at it would even bother. > >You're right! Get yourself a TTL Data Book, a soldering iron (or >wire-wrap gun), a bag of 74LSTTL, a good scope and get busy. Good >experience, nothing secretive or inaccessible there, and precious little >investment either. (hey you did ask .... only it was straight 74TTL back >then!) heh. I was going for FPGA because it's convenient: relatively inexpensive, relatively high speed (so I can drive video, for example...I'm not sure what the limiters with discrete logic are, but I'm not confident you can drive video like that easily), much easier to prototype, etc. I only looked into FPGAs recently because a browse of a Xilinx datasheet revealed how convenient the things should be to program. >>Unless you know exactly how Xilinx's software works, which I assume >>you don't -- apparently it's not widely published information -- you >>can't have absolute faith in it. I've been burned by prepackaged software >>often enough that I'm reflexively mistrusting of it -- perhaps you >>reflexively trust it because you've had good experiences with similar >>software or perhaps you just don't care much about how efficient it is >>since you know you don't have the time to do it all by hand so even if it >>does badly, at least it gets the job done. The point is that neither your >>trust nor my mistrust are justified unless we get the source or at least >>some strong understanding of what's possible, and that's what I'm after. > >Now if THAT's the issue then I think you can use Xilinx software and >sleep a little more easily. > >Because everything up to the final bit file is visible in excruciating >detail, if you really _want_ to look at it. e.g. using FPGA Editor or >ncdread... Why would I waste my time second-checking their work when I could waste my time second-checking my own? >The only step between the .ncd file and the bitstream is a 6k program >called bitgen.exe. In every other step, at least you can inspect the >results and see what it's doing. But you rarely need to... If it's really only 6k then I could probably reverse-engineer it with DEBUG.EXE :)Article: 21492
In article <8bdifm$22iu$1@noao.edu>, Andy Peters wrote: >Greg Alexander wrote in message <8bbqci$jdq$1@jetsam.uits.indiana.edu>... >>If I knew how to make PC boards without screwing myself over with >>capacitance at high frequencies, I certainly would buy simple PALs, now >>that I know that the FPGA development world doesn't have any interest in >>being my friend. :) Too bad I don't think I could quite implement an >>entire Forth processor in a single PAL. :) > >Hey, you hit on something there that you probably don't even realize. >Assume you were able to code your own FPGA development tools, and you've got >a bit-stream for your nifty Forth processor, and it fits easily into one of >the Xilinx Spartan devices. <snip "why don't you design your own board" section> Designing my own board is more out of my reach than designing my own FPGA configuration. Also, it's not as interesting to me. I don't want to design a board, I want to design a chip. I don't want to fight existing software, I want to write my own. I'm not even too interested in learning from the past because I learned the fun way that it's often a lot of fun to reinvent the wheel without even realizing it ever rolled before.Article: 21493
You don't need to use VHDL to enter your design. You can do it as a schematic, even using primitives at the tool front end, or if you go into the EPIC editor, you can directly edit (or create) the CLBs and routes without using any of the front end tools. The only thing between the epic output and the bitstream is the bitstream converter. In the old tools (XACT6), you also had an option of writing an XNF file directly as an alternative to mainstream design entry tools. The XNF is an ascii text netlist of the CLB cell primitives. The new tools use a binary file instead, so that option is not as available. Older versions of the new tools would read xnf files, but I'm not sure the latest one does. With these hooks, there really isn't anything that the device can do that you can't get to (although some of the device features are only available through the editor, like the tristate registers in the 4000XLA parts). Greg Alexander wrote: > In article <38DA3B17.EF5C5E80@ids.net>, Ray Andraka wrote: > >I understand your point. However, I think there are two things here. Either > >you want to play with what can the FPGA do, or you want to play with tools for > >the FPGA. If you really want to play with the FPGA to see what you can do > >with it, you'll get there much faster using the tools that are out there > >instead of rolling your own. When you need to run out to the store, I doubt > >you start by building the car to go in. Rather, you probably drive a mass > >produced car that fits your needs reasonably well but not perfectly. On the > >otherhand, if your desire is to learn how to make the tools then don't expect > >to use them to make useful things in the FPGA for quite a long time, > >especially if you only do it on weekends. > > No, I totally disagree. Without specs, I know that I will always be > LIMITED to their software, so it's not a training wheels situation. Also, > I'm not going to go to extreme lengths (installing Windows) just to make > their software run since their software doesn't do what I want. Also, I > don't want to learn VHDL and all these high level lanugages and > interfaces, I simply want to do the thing by hand. I don't want to build > a car from pieces. This is simply a preference, and one that Xilinx > shouldn't be disallowing. > > >That said, it would be nice to have more openness with respect to the > >bitstream, but I also understand the reluctance to do so. First, opening the > >bitstream gives considerably more visibility into the phsyical construction of > >the FPGA, something the FPGA vendors would understandably not want to give > >away to the competition. Second is the issue of support. The support for > > It's a well-known industry fact that everything that can be > reverse-engineered has already been reverse-engineered by the competition > so all they're hurting is their customers. > > >just the sanctioned tools flow is already a huge burden, and I think much more > >than a software only package. For software only support, you have a fairly > >well defined platform, so realistically the environment the software runs in > >is pretty well controlled. Now add to that mix the fact that with FPGA > >designs, people are also creating hardware. There are plenty of designs out > >there that, well how should we put this delicately...are not implemented very > >well for an FPGA. The support space is exponentially larger than the software > >only one. Now, if you start opening up to other tools, the support is even > >less constrained. Finally there is the issue of percieved design security. > > I don't see why Xilinx would have any obligation to support Joe Blow Linux > Hacker trying to use his cheap obviously unsupported homegrown bitstream > generation software. > > >Granted a bitstream can be copied directly for a blatant rippoff, but at least > >the reverse engineering is made more difficult (not impossible) if the > >bitstream format and function is not disclosed. As I hinted in my previous > >post, it is possible to get a fairly good handle on the bitstream with alot of > >tedious work, but that is onerous enough that it represents more work than > >doing an original design. > > They sell FPGAs that are given a command and then they disable read back > until reprogramming. Anyone willing to go to the lengths to get around > that would also be willing to go to the lengths to reverse-engineer the > bitstream. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 21494
Greg Alexander wrote in message <8bdlam$n6g$2@jetsam.uits.indiana.edu>...
>In article <8bdifm$22iu$1@noao.edu>, Andy Peters wrote:
>>Greg Alexander wrote in message <8bbqci$jdq$1@jetsam.uits.indiana.edu>...
>>>If I knew how to make PC boards without screwing myself over with
>>>capacitance at high frequencies, I certainly would buy simple PALs, now
>>>that I know that the FPGA development world doesn't have any interest in
>>>being my friend. :) Too bad I don't think I could quite implement an
>>>entire Forth processor in a single PAL. :)
>>
>>Hey, you hit on something there that you probably don't even realize.
>>Assume you were able to code your own FPGA development tools, and you've
got
>>a bit-stream for your nifty Forth processor, and it fits easily into one
of
>>the Xilinx Spartan devices.
><snip "why don't you design your own board" section>
>
>Designing my own board is more out of my reach than designing my own FPGA
>configuration. Also, it's not as interesting to me. I don't want to
>design a board, I want to design a chip. I don't want to fight existing
>software, I want to write my own. I'm not even too interested in learning
>from the past because I learned the fun way that it's often a lot of fun
>to reinvent the wheel without even realizing it ever rolled before.
Well, perhaps you should re-read my post. Summary: if you don't put the
FPGA onto a circuit board (and with the edge-rates involved, it won't work
if done in wire-wrap - been there, done that), the FPGA is useless.
Unless, of course, your design effort is intended as nothing more than an
exercise in academic masturbation. In which case, you'll never really know
if any of your hard work was worthwhile without building and verifying
hardware.
Excuse me, a quick rev of one of my FPGAs has finished routing. I have to
reprogram the config EEPROM so I can continue testing my actual hardware in
a real system so we can ship the board to our paying customer who will give
us real money.
-- a
-----------------------------------------
Andy Peters
Sr Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) noao \dot\ edu
"Money is property; it is not speech."
-- Justice John Paul Stevens
Article: 21495
This is an interesting entry level brain teaser... The final solution
is heavily dependent on the context-specific constraints and requirements;
practically every such design has *some* such "gotchas" that add complexity
to the simple, generic orginal problem statement.
So here's my run at the problem...
________ ________
clk A ____| |________| |________
________ ________
clk B ______| |________| |______
clk B is generated from clk A, through an AND gate.
There is some (positive) delay between clk A (leading edge) and clk B (leading edge).
When transitioning between logic in clk A domain to clk B domain, there will be
a 2-register interface through which all signals are passed. The first register
will be clocked on clk A (leading edge). This establishes the "valid time" of the
signal. The 2nd register is clocked on clk B (trailing edge). Because of the
clock cycle time, it is *known* that clk B (trailing edge) is positioned properly
between occurrences of clk A (leading edge). The output of the 2nd register now
has adequate setup/hold time to any of the clk B domain registers.
In the opposite direction (from B domain to A domain), a single register stage
is needed. This register is clocked on clk B (leading edge). Because of the
known clock period and positive (and bounded) delay between clk A and clk B,
the output of the single register has adequate setup/hold time to any of the
clk A domain registers.
Of course, all bets are off if the clock period is too short, or if the AND
gate delay is too long. In this example, there is an inherent advantage in
*knowing* that there is a positive skew between the two clocks.
For extra credit, come up with a circuit that will drive the AND gate which will
enable/disable clk B, without any "runt" pulses or clock glitches.
-- Bob Elkind
Nicolas Matringe wrote:
>
> Hi all
> I am working on a design which may be used in two products, one of which
> won't need some functions of the design. I don't want to have 2 designs
> (we won't make 2 ASICs).
> I was wondering if it was possible to have 2 clock domains (same
> frequency) with the possibility to turn one of them off to reduce power
> consumption (this would be done by pulling a pin high or low for
> example)
> --
> Nicolas MATRINGE DotCom S.A.
Article: 21496Andy Peters wrote: > Well, perhaps you should re-read my post. Summary: if you don't put the > FPGA onto a circuit board (and with the edge-rates involved, it won't work > if done in wire-wrap - been there, done that), the FPGA is useless. > That really depends on the amount of lines with high-speed edge rates. If the only line at a high frequency is the master clock wire wrap design would be as ok.It really boils down to layout and PCB is better at that. I really don't see all the advantage of pipe lining cpu's if you still have wait for memory as the cpu is now faster than memory, and buffering of data and address will give you access time of 1/2 the memory speed. I like forth,but not as a cpu, because some data access is still better the standard way, like data records. --- "We do not inherit our time on this planet from our parents... We borrow it from our children." The Lagging edge of technology: http://www.jetnet.ab.ca/users/bfranchuk/woodelf/index.htmlArticle: 21497
Given a system with an embedded processor to do the work, what are the pros and cons of the classic Xilinx Slave serial mode vs the newer JTAG approach. Do the SpartanXL (and the SpartanII) parts support both approaches equally well? SteveArticle: 21498
In article <8bdj9g$kdi$1@agate.berkeley.edu>, Nicholas C. Weaver wrote: >In article <8bca7r$k50$1@jetsam.uits.indiana.edu>, >Greg Alexander <galexand@sietch.bloomington.in.us> wrote: > >>One way to look at it is that I want to drill a single hole in a single >>piece of wood and you are pointing out to me how great a drill press is. >>Why would I pay the cost of a large featureful system if I don't want the >>features? I don't just mean financial cost, I mean in terms of complexity >>and disk space and flexibility. > > I don't think your analogy is reasonable. Even to do a very >simple thing on a modern FPGA, you are GOING to want to use the tools >provided. So it's not like "I have to drill a single hole in a block >of wood", it's more like "I have to mill away this, this, and this", >even for a very simple operation. So you wolud want to use a milling >machine, not just a hand drill. It's bad enough that Xilinx thinks it knows what tools I want. Who are you? > And do you realize what the cost is for a set of tools for >ASIC development? Custom VLSI development? FPGA tools are cheap, you >can often get a free set of the student tools included in textbooks on >logic design. If it were free it would only just barely be good enough, and then only because there would be less overhead to reverse-engineering it. >>The other way is that no matter how good, fast, fully-featured, clever, >>and bug free that software is and no matter how bad, slow, under-featured, >>naive, and buggy my software is (and by "my software" I refer to any >>software that I really understand -- it need not be written by me, but I >>do need the source), I would much prefer to have my software. > > It seems that this is a political and moral issue for you, not >just a practical issue. Practically, the complexity of modern FPGAs >and modern tools are such that you won't be able to write the software >yourself, or even debug the software. You seem to think I want to make complex software. More importantly, it's a proven fact that one person can accomplish as much as a team. Since I'm redefining the problem, not just the solution, I can take significant shortcuts. I'm not interested in making a full-featured development environment to sell. > Finally, athough buggy, most of the bugs show up when you >REALLY push the tools. As a Forth fan I believe in the power of simplicity. You aren't one, but your inexperience with the field doesn't make you qualified to state what is possible in another paradigm. >>>is something I avoid like the plague. BTW, getting the bitstream >>>format under NDA is not exactly unheard of, even for graduate >>>students. > >>Why should I sign away parts of my future just to get information I should >>get for free? > > A) You aren't really signing away much/any of your future. >You really can't operate at the bleeding edge of research without >being willing to sign the occasional NDA. I'd be signing away my right to share the software. That's a right to die for. > B) Why do you think this information should be free? Xilinx >is in the business of selling FPGAs, and there is a fair amount of >interesting intellectual property stuck away in those bitfiles. The >tools are close enough to free for a hobbyiest-level project, >considering the complexity of the tools and the parts. Their competitors have already reverse-engineered Xilinx's products. Isn't that obvious to everyone? > C) As the LogicBlox people at xilinx (their Java based >module generator system) told us a couple years ago, "Java decompilers >are really good. Nudge nudge, wink wink". Thanks, I'm looking into the JBits thing when I get a chance.Article: 21499
Seems as I recall a paper on this at HDLCON in either 98 or 99. Likely 98. I think it may have been a group from NC State. Sort of an academic paper about academics making code - as you said, very generalized, but it may be a start toward what you were after. Cheers, Gary "Bruce Oakley" <oakley@amirix.com> wrote in message news:38DA55B3.2A5FA0BB@amirix.com... > I'm interested in finding out if anybody has published data or estimates > for HDL/RTL-based FPGA design productivity, e.g. something in person > hours per logic cell, per line of HDL code, etc. > > Obviously we're talking about _massive_ generalization here, since there > are so many variables: > - Nature of design ... data flow, state machine, etc. > - Experience of the designers > - Use of macros, cores, etc. > - Aggressiveness of clock rate, device utilization, etc. > - ... > > So, it may be virtually impossible to create anything meaningful. > Still, I'd be interested to see if anybody has tried. > > Thanks, > Bruce. > > -- > -------------------------------------------------------- > Bruce Oakley [ oakley@amirix.com ] > Principal Hardware Designer > AMIRIX Systems, Inc. PH: (902)450-1700 x 245 > Halifax, Nova Scotia, CANADA FX: (902)450-1704 > -------------------------------------------------------- > >
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z