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
In article <38da513e@news.ua.pt>, Ruben Leote Mendes wrote: >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. I'm not too interested in those tasks (I am not too interested in making tools for general consumption, at least not as an initial goal). However, the job has to some extent already been done: http://www.eecg.toronto.edu/~vaughn/vpr/vpr.html (that link courtesy of Larry Doolittle).Article: 21501
In article <38DA5A87.915F601F@ids.net>, Ray Andraka wrote: >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). First off, even if their software is good and mine is bad, I'd prefer mine. I've explained that several times before. Second off, their software may be capable of doing what I want but my software will be better -- it will be more suited to my environment and, more importantly, I will understand it. Even the most bug-free program has bugs and I would prefer to have the bugs be in source taht I understand rather than in source where I'm constantly second-guessing the author.Article: 21502
In article <8bdqmn$2e6a$1@noao.edu>, Andy Peters wrote: >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. Sorry, I thought you'd read some of my other posts... I've been specifically looking at the XS40 board with an XC4005XL, the board is by XEss and has rather a lot built in and is very inexpensive. The board is as open as anything needs to be (they released source to their Windows tools to upload to/test the board and they released schematics in some form). >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. See, here's an application of eXtreme Programming: the productivity increases MORE THAN LINEARLY as your compile/link time decreases linearly. You're waiting for your FPGA to route. Maybe you aren't even waiting very long. At any rate, with my software, there would be no interrupting wait (i.e., the wait would be less than the time it takes you to type the command, ideally) because it would not be doing intelligent things and would not need to think. I bet the increase in productivity won't make up for the primitiveness of the tools, but it's another thing in my favor. If you abandon complexity, even complexity you think you need to get the job done, you'll be amazed at how much you can do with so little.Article: 21503
In article <38DA7CF3.38971438@jetnet.ab.ca>, Ben Franchuk wrote: >Andy 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. It would be a processor driving VGA and reading SRAM hopefully almost as fast as the SRAM can go (both the VGA coproc and the instruction fetch will be accessing the SRAM). I don't know much about high-frequency digital design, but I suspect that would be enough to plant me firmly in the "you'd better do this on PCB" position. Good thing a cheap PCB has already been located. >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. My CPU would not be pipelined. I don't know enough about the speed of the various components involved to guess whether it'll be I/O bound, but at least the RAM on hte board I'm looking at is SRAM, hopefully fast. >I like forth,but not as a cpu, >because some data access is still better the standard way, >like data records. After writing the below paragraph I'm pretty sure you mean about CPU data access, but I'll leave the paragraph anyways. I don't know exactly what you mean about data records in that case. There are some things that are more awkward in a stack CPU but there are plenty of things that are very awkward in a register CPU too so I consider it a worthwhile tradeoff (though obviously not for everyone). In case you're refering to Forth as a language: Forth allows the most transparent use of data records of any language I've ever seen if I get how you mean the phrase: when you make an array, you typically use CREATE or VARIABLE and then you ALLOT the space after the variable to hold the data. Well another hting you can do is CREATE a word and use DOES> to define what the word does. You can define teh word to pop a value off of the stack, multiply it by the record size, and use it as an offset into the table. You can define separate words for each field in your table. You can make a word look at the incoming text stream and have it automatically do string-based lookups that way. It doesn't have too much built in, but it sure does allow a lot. I wouldn't say that forth is for everyone, but enough things are possible with Forth that don't seem like they should be so easy with such a simple system (a similar effect as with emergent properties, but not really) that I consider it at the very least a worthwhile exercise and at the most a horrible addiction. :) (I won't be throwing away gcc any time soon, though, that's for sure)Article: 21504
In article <8be1re$nn5$1@jetsam.uits.indiana.edu>, Greg Alexander <galexand@sietch.bloomington.in.us> wrote: >> 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? A graduate Student at the University of California at Berkeley, a member of the reconfigurable computing research group at berkeley. I'm currently working on alternate FPGA architectures, as well as architecting a virtex based student project board. >>>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. The modern FPGAs are complex targets, some large level of complexity will be required. And, if you concentrate on just one part of the problem (EG, better placement mechanisms), the available tools are modular ensugh that it is reasonable to start with the existing flows and add in your new passes and operations. Also, there are a fair number of research software which is freely available, such as VPR. However, these are generally oriented towards much simpler, abstracted devices. Oh, and have you read xapp 151? http://www.xilinx.com/xapp/xapp151.pdf It has a lot of information on various parts of the virtex bitstream. Not everything you want (it leaves out a lot of info on what the routing bits do/represent), but it is a good guideline to start with, and includes info about frame organization, CRC coding, etc. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 21505
"Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam> writes: >Greg Alexander wrote in message <8bapci$i0h$1@jetsam.uits.indiana.edu>... >>That's quite a pity. 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, let me get this straight. You're a software guy - a Linux hacker, as >you say - and you think that you're just going to be able to, in your spare >time, write a synthesis tool, a placement engine, a router, and a timing >analyzer? Is your background in writing code for synthesis tools? Logic >minimization? All the other stuff that's under the hood of these tools? >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)? Well, there are other possibilities. One is that he might want to use an available, maybe open-source, synthesis/place/route/timing analyzer tool, and only need to write the final step, converting the result into a bits file. Now, for that case he can probably get away with generating the lca file and running makebits on that. It would be nice to have a linux makebits, though. A project that I was working on before, though since have gone onto other projects, would have needed to know where some bits were. I was working on a systolic array processor, which contained a linear array of Xilinx chips, or would have if we had built it. Each chip would have the same logic, but the constants would change. Some in what xilinx would call ROM, but more like PROM. Each chip would initialize with different values. I also needed to be able to change the bits of an adder. Most of the logic was adding constants and comparing the results. By building constant adders, and changing the constants by changing the LUT values and carry logic bits, I could have built such logic in a much smaller space than most other ways of getting the constants in. A system might have had hundreds of Xilinx chips in an array, so logic minimization was important. (Actually speed/chips, I had to be careful with the routing.) I actually had some results from ppr before the decision to do the project differently (using ASICs) came through. >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. Well, consider Linux and Windows. While many people are happy with Windows, it is nice that some people aren't, and want to work on other operating systems. Consider how it would be if Intel didn't publish the instruction set of their processors, and someone wanted to port Linux to it? You could ask why we weren't happy with the software that Intel provides (they used to actually sell software for their chips) or that Microsoft provides. I actually would be interested in working on place and route software for FPGA's. Xilinx does provide a lot of information about the chips, probably enough to do synthesis, place and route, and timing analysis, so that one could probably write all the way up to, but not including, makebits. >> Have any of you hardware types ever seriously lived a Linux hacker life? >No. Should I? And why? Some of us prefer to be paid for our work. >Have you gone on tour and mixed live rock bands? Should you? I won't argue with this one. -- glenArticle: 21506
In article <8be477$nla$1@agate.berkeley.edu>, Nicholas C. Weaver wrote: >In article <8be1re$nn5$1@jetsam.uits.indiana.edu>, >Greg Alexander <galexand@sietch.bloomington.in.us> wrote: >>> 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? > > A graduate Student at the University of California at >Berkeley, a member of the reconfigurable computing research group at >berkeley. I'm currently working on alternate FPGA architectures, as >well as architecting a virtex based student project board. > >>>>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. > > The modern FPGAs are complex targets, some large level of >complexity will be required. And, if you concentrate on just one part >of the problem (EG, better placement mechanisms), the available tools >are modular ensugh that it is reasonable to start with the existing >flows and add in your new passes and operations. I don't want any form of automatic placement software. More importantly, they aren't modular enough. To really be modular you need to be able to pick them up and take them somewhere else and use them there. In other words, they need to be compiled to machine-independent byte code (i.e. Java) or source needs to be provided. A module that's not portable is not very modular. > Also, there are a fair number of research software which is >freely available, such as VPR. However, these are generally oriented >towards much simpler, abstracted devices. VPR is unusable because it doesn't seem to be possible to use it to generate bitstreams for the FPGAs I want (if any). > Oh, and have you read xapp 151? >http://www.xilinx.com/xapp/xapp151.pdf > It has a lot of information on various parts of the virtex >bitstream. Not everything you want (it leaves out a lot of info on >what the routing bits do/represent), but it is a good guideline to >start with, and includes info about frame organization, CRC coding, >etc. Yes, but without routing I'm kind of screwed. Do you know if any similar documents exist with info about the XC4000XL family?Article: 21507
In article <8be55c$kcl@gap.cco.caltech.edu>, glen herrmannsfeldt wrote: >"Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam> writes: > >>Greg Alexander wrote in message <8bapci$i0h$1@jetsam.uits.indiana.edu>... >>>That's quite a pity. 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, let me get this straight. You're a software guy - a Linux hacker, as >>you say - and you think that you're just going to be able to, in your spare >>time, write a synthesis tool, a placement engine, a router, and a timing >>analyzer? Is your background in writing code for synthesis tools? Logic >>minimization? All the other stuff that's under the hood of these tools? >>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)? > >Well, there are other possibilities. One is that he might want to use >an available, maybe open-source, synthesis/place/route/timing analyzer tool, >and only need to write the final step, converting the result into >a bits file. Now, for that case he can probably get away with generating >the lca file and running makebits on that. It would be nice to have a >linux makebits, though. That wasn't really my intention, but now that I have seen VPR it has been an option I've considered. Is makebits free? If makebits is free and I can get it to work somehow from a Linux comandline (if that's really all I need then I will put up with the hassle of DOSemu or even WinE), I'll buy a chip. :) As I understand it makebits is a tiny tiny program, and is at almost hte same level as I was originally refering to as "write something up in a couple weekends" (reads in some intelligible/standardized format and converts it almost directly into bitstream). Is this correct? <snip> >>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. > >Well, consider Linux and Windows. While many people are happy with >Windows, it is nice that some people aren't, and want to work on other >operating systems. Consider how it would be if Intel didn't publish >the instruction set of their processors, and someone wanted to port Linux >to it? You could ask why we weren't happy with the software that Intel >provides (they used to actually sell software for their chips) or that >Microsoft provides. I actually would be interested in working on >place and route software for FPGA's. Xilinx does provide a lot of >information about the chips, probably enough to do synthesis, place and >route, and timing analysis, so that one could probably write all the >way up to, but not including, makebits. In a quick skim I didn't find enough info for timing analysis. Could you point me in the right direction? It was them providing me with enough information to do manual place and route that made me want to know the bitstream so badly -- once I knew what the FPGA actually was there was just no way that I could even consider programming it in VHDL (at least not for initial entertainment-targetted projects). If I wasn't bothering with VHDL then I really have no interest in their software. Why would I buy and install a huge software package if all I want is a (most likely TINY) makebits program?Article: 21508
Brian Drummond <brian@shapes.demon.co.uk> writes: (snip. If you don't know how we got here, read the other posts.) >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!) A few years ago, I thought about exactly this problem. When I was growing up, and apparently you, too, we had 74xx TTL to play with. The reason we had that, at $0.25/chip, was that computer makers were buying it in large quantities. Now that computers are made with VLSI, and are more and more integrated, will those TTL chips still be available? I remember building things like digital clocks out of TTL. A great way to learn about digital logic. How are our kids going to learn this? They will have to learn starting with FPGA's. Probably small ones, though. An FPGA starter kit equivalent to a bag full of 74xx chips would not be a bad way to learn digital logic design. I was part of a discussion at FCCM95 on just this subject. -- glenArticle: 21509
Greg, Out of curiousity, about how many FPGA designs have you done? Greg Alexander wrote: > 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 :) -- -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: 21510
Hi, What do you think about StateCAD ? Is it worth to spend some time to learn it, and does it pay off ? Is it mostly used for simulation or synthesis ? Thanks. -- ------------------------------------------- - Domagoj - - Domagoj@engineer.com - -------------------------------------------Article: 21511
glen herrmannsfeldt wrote: > I remember building things like digital clocks out of TTL. A great > way to learn about digital logic. How are our kids going to learn this? > > They will have to learn starting with FPGA's. Probably small ones, though. > An FPGA starter kit equivalent to a bag full of 74xx chips would not > be a bad way to learn digital logic design. I was part of a discussion > at FCCM95 on just this subject. > The problem is that a FPGA is not a visible device, You can't stick a logic probe and say why is that not the right logic level. I Don't think the FPGA manufactures have tiny LED's blinking away on the chips with a teany-weeny front panel. I tend to find that for my design work ( very little ) the FPGA logic blocks never quite fit well, with odd sizes ... 6 input nand gate, or ALU block. The logic blocks are too much of a black art... ops black box to flow data flow around. Some day I will design that cpu, but not from FPGA's as find them over kill in use of logic blocks for random logic. 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: 21512
Hi Is there any good tool available for Symbolic debugging of FPGA designs using Readback and clk stepping/stopping and if could co-simulate the Software and the Hardware together using the same tool to debug software and harware simultaneously. ATArticle: 21513
On Thu, 23 Mar 2000 09:38:57 -0700, Ben Franchuk <bfranchuk@jetnet.ab.ca> wrote: >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. > > 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. Good point... I was startled by one manufacturer's linecard a couple of years back which included the following gem... "Logic: Not recommended for new designs." No comment! - BrianArticle: 21514
The side comment below, and others, lead me to ask : - What broad uses are SPLD devices being put to ? - What's the most PLD you have used in 1 system ? Looking back on the last few projects where we used SPLD the solutions were rather more diverse than the 'memory decoder' examples these were targeted at originally. Here are some to start the examples rolling - 24 Pin PLD as TxUART/Buffer. Chained 25 on one PCB. ( Was lower cost than any UART solution ) - 20 Pin 0.67c PLD used as ADC/DAC, alongside 20 pin uC - 24 Pin PLD used as LED drive, and Button Scan. Using saturating counters, this can be squeezed into a 3 wire protocal. Jim G. glen herrmannsfeldt wrote: > > Brian Drummond <brian@shapes.demon.co.uk> writes: > > (snip - openness thread ) > > >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!) > > A few years ago, I thought about exactly this problem. When I was > growing up, and apparently you, too, we had 74xx TTL to play with. > The reason we had that, at $0.25/chip, was that computer makers were > buying it in large quantities. Now that computers are made with VLSI, > and are more and more integrated, will those TTL chips still be available? The 'lowly' logic market remains $2B (!) in size. Certainly some tail end LOGICs are being EOL'd, ( as are tail end FPGA's, many years sooner than their LOGIC counteparts ! ). Interesting new devices are the single gate logics. > I remember building things like digital clocks out of TTL. A great > way to learn about digital logic. How are our kids going to learn this? > > They will have to learn starting with FPGA's. Probably small ones, though. > An FPGA starter kit equivalent to a bag full of 74xx chips would not > be a bad way to learn digital logic design. I was part of a discussion > at FCCM95 on just this subject. Why not start teaching with SPLD ? A DIP package is still very learner friendly, and slip proof. In the days before $3 Flash uC, I recall hearing the problems with students frying the $90US windowed devices. A TQFP FPGA device looks to have the same problem ?Article: 21515
In article <8ba0t1$7u2$1@nnrp1.deja.com>, rob_dickinson@my-deja.com () wrote: [most snipped] > if your > going to build more than a few then get to grips with designing jtag > into your system from the floor up, ie don't finish your design and > then wonder how to add jtag. Tough if you've got something like an Intel 82259 Ethernet chip with a totally useless NAND-tree test mode instead of JTAG :-((( -- Steve Rencontre, Design Consultant http://www.rsn-tech.demon.co.ukArticle: 21516
Hi Greg, I read with interest (and some disbelief too) your posts. You must understand that this is a hardware newsgroup and you look at the problem from a software perspective. FPGA Hardware design is _hard_ and the software tools quality is not the main problem. When the program you are developing does not work the way you expect it you use a debugger, set-up breakpoints, step trough your code and whatever else you software people do when you hunt bugs. Normally you cannot stop an FPGA and you cannot look inside it to see what went wrong. Another major difference is that software is usually sequential while inside the FPGA everything happens in parallel. We are also fighting things like set-up and hold time problems, ground bounce, noise, asynchronous logic glitches, metastability. In the eleven years I spent designing with FPGAs I found my share (a rather large one) of bugs in the software tools but in the end the limiting factor was always my own capacity to design well and not the tools themselves. The fact that the tools are closed/open source or run on Windows/Unix/Linux has no relevance at all for me (and probably for most of the people in this newsgroup). While the Xilinx software has lots of bugs (anybody that knows of any bug free software raise your hand now) the company is making a tremendous effort of documenting and solving them - the Xilinx Online Answers Database is more important to me than any open source effort. The issue of the proprietary nature of the Xilinx bitstream never dies in this newsgroup. Even in this thread offers and ideas of reverse-enginnering the bitstream format were mentioned. However I think this is a false problem (unless you really want to steal somebody else's design). The important data format is not the bit file format (what you download into your FPGA) but the ncd format (the placed and routed FPGA data file). The problem here is not that the bit format is unknown but that you can go from ncd to bit (using bitgen) but not the other way around. And the ncd format is _open_. You can write whatever place and route program you want and you can generate your own ncd files _without_ using Xilinx software. If your problem is you cannot stand Windows then you have to wait until Xilinx ports their tools to Linux - I wouldn't hold my breath until then. If you are really serious about doing FPGA design from scratch you can start right now - all you need is bitgen.exe, xdl.exe and all the relevant data files for your target FPGA. XDL is a tool Xilinx distributes but does not document that enables you to translate ncd format files (binary) to xdl format (ASCII) _and_ also xdl to ncd. You might even be able to run bitgen and xdl in Linux using some DOS emulator and you definitely do not need Windows. Add your vi editor, a couple of years of very hard work and there you are. In the process do not forget to avoid asynchronous design, register all your input and output signals in your IOBs and use at least two FFs in series when you cross a clock domain boundary. And do not rely on eyeballing, in hardware design it doesn't work ;-). And yes, I think that Xilinx should distribute bitgen, xdl and all the required data files free, publish the XDL file format and keep the bitstream format proprietary. Regards, Catalin Baetoniu Greg Alexander wrote: > > In article <8bdqmn$2e6a$1@noao.edu>, Andy Peters wrote: > >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. > > Sorry, I thought you'd read some of my other posts... I've been > specifically looking at the XS40 board with an XC4005XL, the board is by > XEss and has rather a lot built in and is very inexpensive. The board is > as open as anything needs to be (they released source to their Windows > tools to upload to/test the board and they released schematics in some > form). > > >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. > > See, here's an application of eXtreme Programming: the productivity > increases MORE THAN LINEARLY as your compile/link time decreases linearly. > You're waiting for your FPGA to route. Maybe you aren't even waiting very > long. At any rate, with my software, there would be no interrupting wait > (i.e., the wait would be less than the time it takes you to type the > command, ideally) because it would not be doing intelligent things and > would not need to think. I bet the increase in productivity won't > make up for the primitiveness of the tools, but it's another thing in my > favor. > > If you abandon complexity, even complexity you think you need to > get the job done, you'll be amazed at how much you can do with so little.Article: 21517
Hi Folks,
I am using Foundation 2.1i& Synopsys FPGA compiler II.
When I exported the .xnf file of a VHDL design into design manager, I got
the following error:
/***
ERROR:NgdHelpers:312 - logical block "inst11_inst111_inst1113" of type
"BLK_1113" is unexpanded.
**/
This problem occurs for the components in which I used 'generic' in their
VHDL description.
Below is a sample code.
Any help is much appreciated.
/**** SAMPLE CODE ****/
entity BLK_1113 is
generic(Proc_width : integer :=14);
port
IP_S,IN_S,CLK,CLR, MODE_IN: IN std_logic;
DOUT : buffer std_logic_vector(1 to Proc_width);
MODE_OUT : out std_logic
);
end BLK_1113;
architecture Arch_BLK_1113 of BLK_1113 is
signal A,B : std_logic_vector(Proc_width downto 1);
signal IN_EQ_p1 ,IN_EQ_m1 ,A15_IN,B15_IN : std_logic;
begin
process(mode_in,CLK,clr)
begin
if (CLR='1') then
for i in Proc_width downto 1 loop
A(i) <= '0';
B(i) <= '0';
DOUT(i) <='0';
end loop;
else
if(CLK='1' and (not CLK'stable)) then
if(mode_in='1') then
for i in Proc_width downto 1 loop
DOUT(i) <= A(i);
end loop;
else
DOUT(Proc_width)<=A(Proc_width);
for i in 1 to Proc_width-1 loop
DOUT(i) <= DOUT(i+1);
end loop;
end if;
if(IN_EQ_p1='1') then
B(Proc_width)<='0';
for i in 1 to Proc_width-2 loop
B(i) <= A(i+1);
end loop;
else
B(Proc_width)<=B15_IN;
for i in 1 to Proc_width-2 loop
B(i) <= B(i+1);
end loop;
end if;
if(IN_EQ_m1='1') then
A(Proc_width)<='1'; --- CHECK IT OUT
for i in 1 to Proc_width-2 loop
A(i) <= B(i+1);
end loop;
else
A(Proc_width)<=A15_IN;
for i in 1 to Proc_width-2 loop
A(i) <= A(i+1);
end loop;
end if;
MODE_OUT <= MODE_IN;
end if;
end if;
end process;
IN_EQ_p1 <= IP_S and (not IN_S);
IN_EQ_m1 <= IN_S and (not IP_S);
B15_IN <= not(IN_S xor IP_S);
A15_IN <= IN_S xor IP_S;
end Arch_BLK_1113;
/****************************/
Article: 21518On 23 Mar 2000 21:47:20 GMT, galexand@sietch.bloomington.in.us (Greg Alexander) wrote: >Sorry, I thought you'd read some of my other posts... Are you serious? There are a lot of good, professional, engineers in this NG. Sometimes it pays to read, and not write. It also reduces the S/N. EvanArticle: 21519
Ray Andraka wrote:
> The new tools use a binary
> file instead, so that option is not as available.
But the new tools have XDL, which is a low level ASCII
representation of an NCD - including routing
Greg Alexander wrote:
> Even the most bug-free program
> has bugs and I would prefer to have the bugs be in source taht I
> understand rather than in source where I'm constantly second-guessing the
> author.
In my experience the way from XDL - bitgen -> device
is nearly bug free. Greg has all options to start from this point.
I think, you (Greg) should start with that and roll your own tools
down to XDL. If you are there, you can still start looking around
for the bitgen option.
I guess that final step is than not hard anymore.
And maybe you have convinced XILINX by then that free tools
are so superior that it is worth allowing the free tool geniusses to
support their chips.
Andreas
-----------------------------------------------------------------
Andreas C. Doering
Medizinische Universitaet zu Luebeck
Institut fuer Technische Informatik
Ratzeburger Allee 160
D-23538 Luebeck Germany
Tel.: +49 451 500-3741, Fax: -3687
Email: doering@iti.mu-luebeck.de
Home: http://www.iti.mu-luebeck.de/~doering
quiz, papers, VHDL, music
"The fear of the LORD is the beginning of ... science" (Proverbs 1.7)
----------------------------------------------------------------
Article: 21520On 23 Mar 2000 23:03:28 GMT, gah@ugcs.caltech.edu (glen herrmannsfeldt) wrote: >I remember building things like digital clocks out of TTL. A great >way to learn about digital logic. How are our kids going to learn this? > >They will have to learn starting with FPGA's. Probably small ones, though. >An FPGA starter kit equivalent to a bag full of 74xx chips would not >be a bad way to learn digital logic design. I was part of a discussion >at FCCM95 on just this subject. > >-- glen I think it's very hard to learn digital design with FPGAs - much better to have a big PCB, a scope, lots of TTL, a hairdryer and a freezer can. You really need to get in and physically see the signals to understand what's going on. I've been doing some interviewing recently, for VHDL people. All were electronic engineers, and also claimed to know and use VHDL. Out of about 10 or 12 people: (1) about half couldn't draw up a gate-level 2->1 multiplexer (2) most didn't know what a JK was (3) almost nobody could design a gate-level counter, or (4) knew how to create an FSM from scratch, with pencil and paper (5) very few knew anything about line termination and so on. But then, if you just use FPGAs with an HDL, or even with schematics to some extent, how are you ever going to learn these things? EvanArticle: 21521
In article <38DAA773.E8A07BF5@ids.net>, Ray Andraka wrote: >Greg, > >Out of curiousity, about how many FPGA designs have you done? Obviously 0. I'm trying to find the information to get started. Out of curiosity, do you really think that people are all as limited as people who know what the limits are supposed to be?Article: 21522
In article <38DAE9AA.4B3504E9@home.com>, Catalin Baetoniu wrote: >Hi Greg, > >I read with interest (and some disbelief too) your posts. You must >understand that this is a hardware newsgroup and you look at the problem >from a software perspective. FPGA Hardware design is _hard_ and the >software tools quality is not the main problem. When the program you are >developing does not work the way you expect it you use a debugger, >set-up breakpoints, step trough your code and whatever else you software >people do when you hunt bugs. Normally you cannot stop an FPGA and you >cannot look inside it to see what went wrong. Another major difference >is that software is usually sequential while inside the FPGA everything >happens in parallel. We are also fighting things like set-up and hold >time problems, ground bounce, noise, asynchronous logic glitches, >metastability. In the eleven years I spent designing with FPGAs I found This is where eXtreme Programming principles helps me: my compile time will be about 1 second (how long does it take bitgen to run?) so I can try and try again. I can test each part individually directly tied to IOBs then if it breaks when I add an adder to the chip I know where the problem is. >my share (a rather large one) of bugs in the software tools but in the >end the limiting factor was always my own capacity to design well and >not the tools themselves. The fact that the tools are closed/open source >or run on Windows/Unix/Linux has no relevance at all for me (and >probably for most of the people in this newsgroup). While the Xilinx >software has lots of bugs (anybody that knows of any bug free software >raise your hand now) the company is making a tremendous effort of >documenting and solving them - the Xilinx Online Answers Database is >more important to me than any open source effort. > >The issue of the proprietary nature of the Xilinx bitstream never dies >in this newsgroup. Even in this thread offers and ideas of >reverse-enginnering the bitstream format were mentioned. However I think >this is a false problem (unless you really want to steal somebody else's >design). The important data format is not the bit file format (what you >download into your FPGA) but the ncd format (the placed and routed FPGA >data file). The problem here is not that the bit format is unknown but >that you can go from ncd to bit (using bitgen) but not the other way >around. And the ncd format is _open_. You can write whatever place and >route program you want and you can generate your own ncd files _without_ >using Xilinx software. > >If your problem is you cannot stand Windows then you have to wait until >Xilinx ports their tools to Linux - I wouldn't hold my breath until >then. If you are really serious about doing FPGA design from scratch you >can start right now - all you need is bitgen.exe, xdl.exe and all the >relevant data files for your target FPGA. XDL is a tool Xilinx >distributes but does not document that enables you to translate ncd >format files (binary) to xdl format (ASCII) _and_ also xdl to ncd. You >might even be able to run bitgen and xdl in Linux using some DOS >emulator and you definitely do not need Windows. Add your vi editor, a >couple of years of very hard work and there you are. In the process do >not forget to avoid asynchronous design, register all your input and >output signals in your IOBs and use at least two FFs in series when you >cross a clock domain boundary. And do not rely on eyeballing, in >hardware design it doesn't work ;-). > >And yes, I think that Xilinx should distribute bitgen, xdl and all the >required data files free, publish the XDL file format and keep the >bitstream format proprietary. I don't want them to port their tools -- that will never happen because I don't want programs that run in Linux, I want programs written for Linux hackers -- i.e., open programs. But if they just ported bitgen and made it available for free, that would be all that i really need or expect from them. For example, if I could get bitgen (which is the only program I've claimed to be able to write -- it is very simple as I understand it) then I would even be willing to accept the hassle of setting up dosemu to run it from the linux commandline. But why would I want to get some multi-megabyte package just for bitgen?Article: 21523
In article <38db2d65.178191536@news.dial.pipex.com>, eml@riverside-machines.com.NOSPAM wrote: >On 23 Mar 2000 21:47:20 GMT, galexand@sietch.bloomington.in.us (Greg >Alexander) wrote: > >>Sorry, I thought you'd read some of my other posts... > >Are you serious? There are a lot of good, professional, engineers in >this NG. Sometimes it pays to read, and not write. It also reduces the >S/N. There are a lot of pompous asses too. People who stare at disbelief at every newbie constantly insisting that the problems the professionals tackle with on a daily basis are far too difficult for a newbie to even understand are pompous asses and there's no other way around it, no matter how much hardware they've designed. Everyone here takes the title professional too seriously. In the software movement we've learned that professional means that you're managed by someone probably incompetent and that your software is released not when it's done but when the management says it needs to be done -- not a purely positive status (though there are advantages I guess). In the hardware world you guys seem to still think that professional is a bonus just because you can't afford to do chip or PCB fab with your own money.Article: 21524
In article <38DB2E1C.77F3524E@iti.mu-luebeck.de>, Andreas Doering wrote: >Ray Andraka wrote: >> The new tools use a binary >> file instead, so that option is not as available. >But the new tools have XDL, which is a low level ASCII >representation of an NCD - including routing > >Greg Alexander wrote: >> Even the most bug-free program >> has bugs and I would prefer to have the bugs be in source taht I >> understand rather than in source where I'm constantly second-guessing the >> author. >In my experience the way from XDL - bitgen -> device >is nearly bug free. Greg has all options to start from this point. > >I think, you (Greg) should start with that and roll your own tools >down to XDL. If you are there, you can still start looking around >for the bitgen option. >I guess that final step is than not hard anymore. I would agree, but that is a tiny tiny piece of software, why would I pay so much money for it? More importantly, I'll never achieve satisfaction with that software, I'll always be running it through DOSemu and I'll never quite understand how it works. There'll always be a nagging suspicion that perhaps it's buggy or similar. If you work with proprietary software on a daily basis you are completely used to the suspicion, you don't even let t enter your concious mind, but I've known another way and it's really hard to go back. >And maybe you have convinced XILINX by then that free tools >are so superior that it is worth allowing the free tool geniusses to >support their chips. No, I won't have, because I have no interest in making tools useful for anyone else.
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