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
Hi,
look at xilinx application note xapp 137: "configuring virtex fpgas
from parallel eproms with a cpld". There you find a kind of schematic,
you can use.
Chih-Zong Lin schrieb:
>
> Dear sir:
> I am using Virtex XCV600 + CPLD 9536 + EPROM in my design.
> The design of Virtex has been finished.
> The CPLD+EPROM is used for downloading program image into FPGA.
>
> I am wondering is there any source code/binary for CPLD
> so that I can use in my design?
>
> Thanks.
>
> Miller
best regards
--
Thomas //\\\\
| ~ ~ |
( O O )
___________________________oOOo______( )_____oOOo________
| ____ __ __ . |
| / \_/ / \ Thomas Hellerforth (hellerforth@amo.de)|
| / /| | AMO GmbH (241) 8867-115 |
| / __ |\_/| | Huyskensweg 25 |
|/_/ |_| |_\__/ 52074 Aachen, Germany |
| |
| Oooo |
|_________________________________oooO______( )__________|
( ) ) /
\ ( (_/
\_)
Article: 21526Hi Greg, If I would come on a software newsgroup and claim I prefer to develop software in machine language and write my own compiler, assembler and OS because the existing tools are not open source and might have bugs that I cannot control, and tweak the bits by trial and error until my application works you could then call me a pompous ass. I and others here have already pointed to the place you should look at if you really want to go your way and that is XDL. However, I begin to think that you are here only to promote your Linux/open source agenda - not that I have something against it but this is not relevant to the subject we discuss here, FPGA design. I also tried to point out that hardware and software design are different things and your chance of success at hardware design with a software approach is very slim. If you felt hurt by the way I said it I am sorry, I had no intention to do that. You want to do everything your own way from scratch and that is OK for me. You also want to convince us that this is the right way to do it and I do not agree with that. This is my last post to this thread, Catalin Baetoniu Greg Alexander wrote: > 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: 21527
Depends on how amny iobs are switching at once. I had a customer last year who insisted on a wirewrap prototype. It had lots of memory around it, and needed to run internally at 96 MHz. The memory speeds limited memory access to 16 MHz. In that case, I was able to stagger memory access to the 5 memory banks to limit the number wires switching at a time. I also set all the IOBs to slow slew rate. The device, in case you were wondering was an XC4036XLA-09 in a BGA package mounted on a BGA to wirewrap adapter. Worked just fine (and the power/ground was surprisingly clean at the FPGA pins). If I had run all the memory access on the same cycle it probably would not have worked. So yes, you can do FPGAs with wire wrap IF you are very careful about the design. 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. > > 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 -- -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: 21528
Greg Alexander wrote: > 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). I thought part of the reason you wanted to roll your own was because you didn't want to pollute your PC with windoze. > > > >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. That's fine for simple PLDs. FPGAs have somewhat limited routing resources compared with the logic. Its the routing resource you are paying for, and its the place and route that make the FPGA tools. I think you are lumping the FPGA tool with the design entry/synthesis tools, yet they are two distinctly different pieces. I feel your pain WRT not getting what you want out of the synthesis. However, the FPGA tool (from translate to bit stream) really is quite deterministic, and you can easily work it to gt out exactly what you put in. Heck, that's why I have a preference for schematic entry. You may find it alot easier to do what you want by making a front end tool to generate the primitives and netlist, including placement if that's what you like and then feeding that output to the FPGA tool -- -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: 21529
Not at all. It's just that I think it makes more sense to first work with what is out there before condemning it. By working with the existing tools for a while, you'll get a) a real good feel for the FPGA architecture, what works, what's fast and whats not, b) an understanding of what the strengths and weaknesses of the current tools are, and c) some focus for your improvement efforts. You previously mentioned you are using one of the smaller 4000 series parts on an XESS board. That part is supported by the student edition of the software. Why, XESS sells a bundled package with their board, the student edition software (without VHDL, mind you) and a lab text book for about $200. I think that package is one of the best values for someone starting out with FPGAs. Learn the basics in a proven framework, then venture outside the box to fix the problems you find. The tools really are pretty robust. Where they break is when you start pushing the corners. Most of the problems I've encountered are related to detailed placement in the design. My point is, I don't think the tools are nearly as limiting as you percieve them to be. How can you know what the limits are if you've never touched the tools or the devices???? Greg Alexander wrote: > 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? -- -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: 21530
You just have to design your logic with the FPGA structure in mind :-). Look for Jan Gray's series of articles on implementing a RISC in an FPGA. As for testing, true you can't stick a probe in the chip, but then there are few chips these days that you can do that too. Instead, there are other techniques including simulation, test vectors, dedicated test points, and my favorite, using reconfiguration to modify the circuit to get at the data you want to observe. Ben Franchuk wrote: > 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.html -- -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: 21531
In article <38DB7064.6019191A@z.com>, a@z.com wrote: >Hi Greg, > >If I would come on a software newsgroup and claim I prefer to develop software >in machine language and write my own compiler, assembler and OS because the >existing tools are not open source and might have bugs that I cannot control, >and tweak the bits by trial and error until my application works you could >then call me a pompous ass. No I wouldn't. I'm a strong proponent of knowing the whole system as far down as you can stomach. My views are probably among the minority for MicroSoft-oriented software professionals, but I would be surprised if you'd find many competent and experienced software engineers who don't agree with me that, if you have the time, there's no reason not to build a system from bits. I happen to have an open source assembler, compiler, and OS, so I don't need to write them to understand them...but even so, I've written a compiler and have done serious investigations into the internals of other compilers. Also there is a level of complexity here. The compiler I wrote was 69 lines of C code but gave me a very comfortable level of abstraction compared to ASM. A compiler written to be used by other people and written to support complex features (such as gcc) would of course be much larger and would not be a weekend project for me -- it would require a year or more of dedicated work most likely. Similarly, I am not trying to make generalized route&place software. I don't need to spend that 90% of the time adding 10% of the features and I don't even need many of the remaining 90% of the features. I'm not trying to implement a very complex chip -- it's not like I'm trying to clone the x86 or anything. >I and others here have already pointed to the place you should look at if you >really want to go your way and that is XDL. However, I begin to think that you >are here only to promote your Linux/open source agenda - not that I have >something against it but this is not relevant to the subject we discuss here, >FPGA design. No, /my way/ does not include any choices made by other people except in the actual hardware. I don't want to work with the OS that Xilinx has chosen, I do not want to pay for an oversized toolset when all that I want is makebits. I do not want to read manuals describing how to use makebits when I could instead be reading a manual describing the actual format output by makebits. Allowing someone else to make the choices about the actual hardware is a choice forced by economic reality (as much as I'd love to build my own chip or even fab, I know that's not going to happen), but allowing someone else to make choices about the software is not anything forced by natural laws. You're right that XDL or similar low-level use of Xilinx's software is the closest compromise I'm likely to get without a bunch of time and resources wasted on reverse-engineering, but that doesn't make it what I'm after. >I also tried to point out that hardware and software design are different >things and your chance of success at hardware design with a software approach >is very slim. If you felt hurt by the way I said it I am sorry, I had no I never said what approach I would use. The only thing I'm borrowing from the software approach is a "can do" attitude. My own ideas for design were more like the lego approach. I certainly didn't learn programming through a "software approach" -- the useful methods of approaching problems relating to software were things I figured out well after I learned how to code. I do not believe that because I can write software I can design chips, I think that because I can LEARN to write software that I can also LEARN to design chips. I didn't learn software from the ASM level up, but at the same time I didn't have an ASM manual until after I already knew how to program (and when I got one, you can be sure I crashed that 286 a-plenty learning ASM in DEBUG.EXE). Some may think that my knowledge of software engineering will prove disadvantageous as I try to move on to other things because I may have assumptions that aren't justified in other fields, but perhaps your knowledge of hardware engineering handicaps your abilities to assess what is possible. At the very least, Chuck Moore (designer of Forth, SH-Boom, MuP21, F21, i21) has proven that the minimalist philosophy that he has found works so well for software can also work for hardware. Jeff Fox (the guy financing the F21 and in general informing people of the wonders of Chuck Moore's minimal ideas -- www.ultratechnology.com) often tells anecdotes of how he finds hardware engineers constantly in disbelief of what Chuck's done and has developed a short patience because of the many times he's seen engineers be blatantly rude to Chuck when Chuck is trying to explain what he's accomplished. I figured that Jeff Fox was talking about some small group of engineers, but I see from here that the "can't do" and "only can be done my way" attitudes /are/ prevelant among hardware engineers. Thanks to those of you who pointed out that Xilinx's software does allow low-level interfacing through command-line DOS programs. It does open up another option that I may eventualy decide to use. >intention to do that. You want to do everything your own way from scratch and >that is OK for me. You also want to convince us that this is the right way to >do it and I do not agree with that. No, I have no interest in convincing you that this is the right way to do it. Unfortunately, Xilinx has interest in convincing me that this is the wrong way! I wish to be allowed to go my own route without paying gobs of money to support people going different routes. I expect and prefer that other people go different routes because what I'm doing isn't much good for producing chips as a day job.Article: 21532
In article <38DB78BD.CD29A0F3@ids.net>, Ray Andraka wrote: > > >Greg Alexander wrote: > >> 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). > >I thought part of the reason you wanted to roll your own was because you didn't >want to pollute your PC with windoze. They released source. I can read source, even Windows source, without using Windows. Their release of source directly aided the several individuals who have written Linux programs to use their boards. >> 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. > >That's fine for simple PLDs. FPGAs have somewhat limited routing resources >compared with the logic. Its the routing resource you are paying for, and its >the place and route that make the FPGA tools. I think you are lumping the FPGA >tool with the design entry/synthesis tools, yet they are two distinctly >different pieces. I feel your pain WRT not getting what you want out of the >synthesis. However, the FPGA tool (from translate to bit stream) really is >quite deterministic, and you can easily work it to gt out exactly what you put >in. Heck, that's why I have a preference for schematic entry. You may find it >alot easier to do what you want by making a front end tool to generate the >primitives and netlist, including placement if that's what you like and then >feeding that output to the FPGA tool In the end I would be surprised if I would stick to manual place&route (i.e., if I get myself into a position where I'm making chips more for the result than for the experience, I would not be looking for software based on open sourceness but on quality and I may well chose Xilinx's software), but I definitely need to understand it for now. I don't care so much about the end product (though if I ever get a working processor going I sure will be happy), but I demand to understand all steps. The last step of generating the bitstream is simple enough I don't need source to understand it, so it's only practical issues keeping me from just accepting my fate and getting ahold of makebits/bitgen/whatever it's called.Article: 21533
In article <38DB7BC3.889F0994@ids.net>, Ray Andraka wrote: >Not at all. It's just that I think it makes more sense to first work with >what is out there before condemning it. By working with the existing tools >for a while, you'll get a) a real good feel for the FPGA architecture, what >works, what's fast and whats not, b) an understanding of what the strengths >and weaknesses of the current tools are, and c) some focus for your >improvement efforts. You previously mentioned you are using one of the >smaller 4000 series parts on an XESS board. That part is supported by the >student edition of the software. Why, XESS sells a bundled package with >their board, the student edition software (without VHDL, mind you) and a >lab text book for about $200. I think that package is one of the best >values for someone starting out with FPGAs. Learn the basics in a proven >framework, then venture outside the box to fix the problems you find. The >tools really are pretty robust. Where they break is when you start pushing >the corners. Most of the problems I've encountered are related to detailed >placement in the design. $209 for board+book+foundation 1.5 (student edition), of which I only want board+makebits/bitgen/whatever $109 for board So for $100 I could basically buy something I could write if Xilinx released full specs. What's $100 to you? To me it's about 14 hours of mostly paper-shuffling work involving framemaker. Alternatively, it's about a third of a month's rent or most of a month's food. Sure, I /could/ get a job using more of my "qualifications" (easier to do some places than here, but still possible here) and I /could/ be earning 2 or 3 times my current hourly rate and I /could/ be working full time and all that crap...but what I have now is comfortable, affords me a lot of free time, and works for me. If you think $100 should be worth it to me so that I can use makebits, then you should think that $100 is worth it just to get me something better to do than post here. :) Think of how much time Xilinx would have saved you if they'd just released bitstream specs. :) >My point is, I don't think the tools are nearly as limiting as you percieve >them to be. How can you know what the limits are if you've never touched >the tools or the devices???? It would be nice if they'd let me try to do it the cheap way before forcing me to buy the tools rather than vice versa.Article: 21534
On Fri, 24 Mar 2000 09:58:04 +0100, Andreas Doering <doering@iti.mu-luebeck.de> 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 Good suggestion. I *knew* I'd seen something about an ASCII format yesterday but I couldn't find it... searching the online documentation for XDL doesn't help at all either! - Brian "Logic: Not recommended for new designs."Article: 21535
On 23 Mar 2000 23:03:28 GMT, gah@ugcs.caltech.edu (glen herrmannsfeldt) wrote: >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? The same applies to some extent in the software world... in the days of 64K machines you could reasonably expect to understand what they did. You had to, because installing a new printer could involve re-writing the BIOS! I'm not sure that even Linux encourages people to learn quite that much... >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. > Maybe we can approach this through JBits... As I understand it you can't control the routing, only the logic. But it ought to be quite easy to generate a "raw" bitstream with predetermined interconnect, which can be customised by logic. Treat the FPGA as a very large PAL for example, or as a set of PALs interconnected in a well-defined manner. For example, some connected to input pins, some to output pins, some connected as feedback structures to build state machines, and some as registers or memory. Or several "raw" bitstreams, specialised for different purposes (e.g. 2-layer or more neural net type topologies) Timing analysis would have to be along the lines of "count the logic levels, add the route delay and multiply by the speed grade" ... suboptimal for sure, but better than nothing. Routing delays could be a table of constants since the routing is fixed. Then folks like Greg could choose one of these bitstreams and "program" it by inserting the contents of the logic blocks with whatever tools he wanted. There would have to be a verifier to compare the "don't touch" parts of the bitstream (routing etc) with the original... - Brian "Logic: Not recommended for new designs."Article: 21536
On 23 Mar 2000 17:44:11 GMT, galexand@sietch.bloomington.in.us (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: >>>[...] 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? Well I gotta admire the attitude! >>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. > >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), Heh, don't be telling me what you can't do with LSTTL... (actually it's pretty useful up to broadcast quality, but high res starts stretching its capabilities. And as Evan pointed out, you'll learn a lot by real hardware hacking, that you'll never learn by merely programming an FPGA) >>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 :) Alas... if only ... I must apologise for misleading you by accident. I went hunting for a bitgen that I could download without paying any money. Found one right away. BUT though it's only 6K, it uses a number of rather large DLL's, not all of which were available from the same place. So reverse engineering with DEBUG ... well if I said it wasn't an option you'd cry bullshit ... so I'll just say it's only for the eXtreme masochist. On the other hand if you're really thinking of buying the Xess board, notice that they'll throw in the Xilinx tools at a substantial discount. I agree that XDL/Bitgen are about as close to what you want as you can get without a _lot_ of work. Best of luck whichever route you take. - Brian "Logic: Not recommended for new designs."Article: 21537
Greetings; There are a few things I'd like to do with Xilinx FPGA's (xc4000 or xcv/e). However, I think they could both be implemented in similar ways. First of all, I'd like to have a version/revision value within the FPGA which would automatically track the one used in the Design Manager. The second thing I want is to generate multiple bit files from a single one, each of those files containing a unique identifier. JBits seems like a potential candidate, but it's not particularly available. Another possibility is the FPGA editor, but I don't believe you can run it non-interactively. Any ideas? For the first case, what I'd envision would be a black box which could be instantiated into your code. It would have version and revision outputs which match what is given in Design Manager. I wouldn't expect it to simulate properly, but that's a minor issue. In the second case, the same black box could be manipulated by an executable which you run on your bit file, and which you provide the identifiers you require. Thanks for reading this! Cheers, JamieArticle: 21538
Sigh. galexand@sietch.bloomington.in.us (Greg Alexander) wrote: > 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. So, the problem isn't really with the commercial software, the problem is that you're paranoid and think the bugs are out to get you? Somehow a piece of software used by thousands of people to do real designs has a bug with your name on it? And when you discover this bug, you will be stopped dead in your tracks because Xilinx will never be able to fix it? But if YOU had the bitstream format, you'd have anal-retentive control over your destiny and can spend hundreds of man-hours writing and debugging code to solve this problem that would otherwise cost you ~$100 for the commercial software, a few megabytes of disk space, and a .001% chance that you might discover a bug that will take Xilinx a day or two to fix? You sound like my ex-wife, who fancied herself an artiste and kept whining about how her life was too easy and how a real artist has to struggle with the "human condition" before she can be creative. She didn't buy Isaac Newton's theory about standing on the shoulders of giants, because it's safer to be wallowing around in the giant's toe-cheese with the illusion that with "a couple of weekends of work" and you will be soaring high over his head. (Last I heard, she was applying her artistic talents as a janitor in a health club.) Well, it's a nice dream, Greg, and maybe it's sometimes true for real artists and geniuses, but it's clear from your posts that you barely have a clue. That you haven't even seen the commercial tools that you fear so much. That you haven't ever done an FPGA design. As has been mentioned by others, there are many places to hack into the FPGA design flow. You would do yourself, and possibly the rest of the world a service by looking into this (although I wouldn't dare suggest that you are motivated to do something useful for the rest of the world.) If you came to comp.arch.fpga for advice, this is it: trying to hack the bitstream is a waste of your time. Even if someone gave you the bitstream format, it would be a waste of your time. Buy the student edition of the Xilinx tools. If it upsets you to put $100 into the corrupt kapitalistic software-industrial complex, then steal it. If it upsets your tummy to use a program for which you have no source code, take a pill and get over it. If you find your 13 Gigabyte disk is running out of space, you can probably afford to delete your Captain Kirk .gif files. Use the software. Find out what it can and cannot do. Get back to us in a couple of weeks and maybe we can have an intelligent discussion about FPGAs. > 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 ... > No, I won't have, because I have no interest in making tools useful for > anyone else. .. and ... > I'd be signing away my right to share the software. That's a right to > die for. -- Don Husby <husby@fnal.gov> http://www-ese.fnal.gov/people/husby Fermi National Accelerator Lab Phone: 630-840-3668 Batavia, IL 60510 Fax: 630-840-5406Article: 21539
In article <8bg2qr$cqp$1@info3.fnal.gov>, Don Husby wrote: >Sigh. > >galexand@sietch.bloomington.in.us (Greg Alexander) wrote: >> 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. > >So, the problem isn't really with the commercial software, the problem is >that you're paranoid and think the bugs are out to get you? Somehow >a piece of software used by thousands of people to do real designs has >a bug with your name on it? And when you discover this bug, you will No, I mean that every time my design doesn't work, I'll be fairly certain it's my fault, but I won't be 100% certain. Bugs are only a tiny part of the joy of understanding the software. They are a part of it and worth mentioning it, but even if I knew their code was 100% bug free, which I couldn't, I wouldn't want their code. As it is, from reading this group for just a few days I know that there are bugs in their code that have got real engineers working on real problems that they have declined to publicize in a notable manner. >be stopped dead in your tracks because Xilinx will never be able to fix >it? But if YOU had the bitstream format, you'd have anal-retentive >control over your destiny and can spend hundreds of man-hours writing >and debugging code to solve this problem that would otherwise cost >you ~$100 for the commercial software, a few megabytes of disk space, >and a .001% chance that you might discover a bug that will take Xilinx >a day or two to fix? Getting rid of the bugs is small compared to the peace of mind of understanding the software. If all I cared about was the bug, that would be one thing, but I don't even want the software, let alone its bugs! >You sound like my ex-wife, who fancied herself an artiste and kept >whining about how her life was too easy and how a real artist has >to struggle with the "human condition" before she can be creative. >She didn't buy Isaac Newton's theory about standing on the shoulders >of giants, because it's safer to be wallowing around in the giant's >toe-cheese with the illusion that with "a couple of weekends of work" >and you will be soaring high over his head. (Last I heard, she >was applying her artistic talents as a janitor in a health club.) Newton stood on the shoulders of giants because the giants were scientists and a natural law I learned long ago is "scientists like to publish." If Xilinx PUBLISHED I'd gladly stand on their shoulders. But instead they've constructed a platform and asked me to purchase some room on the platform but requested that I not look over the edge to see what's holding it up. I'm somewhat worried that it will fall down (bugs), but more importantly I want to understand what's holding it up. I'm not trying to make a chip to sell it, I'm trying to make a chip to have the experience of making a chip, and if I'm just after the experience, I'm going to understand as much of it as I can if I have the choice. >Well, it's a nice dream, Greg, and maybe it's sometimes true for real >artists and geniuses, but it's clear from your posts that you barely >have a clue. That you haven't even seen the commercial tools that you >fear so much. That you haven't ever done an FPGA design. I have no clue about FPGA, and at one time, neither did you. >As has been mentioned by others, there are many places to hack into >the FPGA design flow. You would do yourself, and possibly the rest of >the world a service by looking into this (although I wouldn't dare >suggest that you are motivated to do something useful for the rest of >the world.) If you came to comp.arch.fpga for advice, this is it: >trying to hack the bitstream is a waste of your time. Even if someone >gave you the bitstream format, it would be a waste of your time. That's why she's your ex-wife. Your judging of activities by OTHER people as complete wastes of time is stupid. I don't mind if you don't have any intention to do what I'm doing, but I don't see why you mind that I do it. Your ex-wife may have an idea there, working as a janitor. If you approach it right, a janitorial job can be great: You're a slave to no one. The vast majority of the time most janitors are unsupervised and, more importantly, once you're "just a janitor" you can quit and go anywhere else you want. You don't have anyone demanding that your mind be doing any particular thing, conforming to anything, only that your body go through the motions. I'd rather be a janitor than a lot of other things, that's for sure. (of course, a lot of janitors don't realize their freedom and are, as such, slaves) >Buy the student edition of the Xilinx tools. If it upsets you to >put $100 into the corrupt kapitalistic software-industrial complex, >then steal it. If it upsets your tummy to use a program for which >you have no source code, take a pill and get over it. If you find "take a pill and get over it." I was recently making fun of the uncoived opinion of the unwashed masses that aesthetic sense should be dealt with so trivially. Nice to see the same stupid viewpoint in here. Perhaps your ex-wife should have taken her drugs to make her boring and more like what you wanted? >your 13 Gigabyte disk is running out of space, you can probably >afford to delete your Captain Kirk .gif files. Use the software. I don't know what the fuck that's all about, I assume you're just comparing me too much to your ex-wife, since none of that has any basis in any reasonable argument. >Find out what it can and cannot do. Get back to us in a couple of >weeks and maybe we can have an intelligent discussion about FPGAs. No we can't because I bet pennies to dollars (you're the high-paid professional) that you don't know shit about what really goes on inside that software because all you're concerned about is the fact that it works.Article: 21540
No cigars or miracle cures - just some ideas !
"bob elkind" <eteam@aracnet.com> wrote in message
news:38DA7546.4BC6E0BC@aracnet.com...
> This is an interesting entry level brain teaser...
> 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).
Clocks can be generated in a number of ways . For example (This isn't a
recommendation - just starting a discussion !)
_______
Main Clock | |
------------------------| | Clock A
| | and |-----------------
| '1' --| 1 |
| |_____|
|
| _______
| | |
--------------| | Clock B
| and |-----------------
Control --| 2 |
|_____|
With this scheme the delay through 'and-1' will equal the delay through
'and-2' when control is '1' - which is when the clock is generated - so the
skew is minimised ! The delay is different when the control is '0' but as
Clock B is disabled - who cares !
Ofcourse the control for the and gate needs to be synchronous so ...
________________________ ______
| ______ | | |
Clock A | | | |--O| | Control
--------------| | | FF
|-------------------buf---
| FF |------------------| |
Cont --| | |____|
|____|
The two flops here use clock A (it would be hard to re-enable clock B is
they used that clock !), they'd also need to be floorplanned quite tightly.
The buffer shown may be needed to ensure that the clock is reenabled during
the low period of clock A to avoid glitches !
> 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 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.
I'd stick with enabled flops and accept that the clock will be driven
throughout the chip.
A.
Article: 21541eml@riverside-machines.com.NOSPAM wrote: > 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. > What is FSM? > > 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? > As a hobbyist, I looked at what little there was on HDL's and went back to drawing schematics. I have yet to a nice small RTL compiler and simulator. FPGA's also don't decompose to normal logic, that also make things harder,and FPGA's can have too much over head for the logic used. Take carries in ADDERS, carry propagation takes a lot of CLB's unless you use ripple carry ( a long time ) or a chip with fast ripple carry.(A faster long time). A ripple carry is two-gate delays, and that speed 1/3 (see note) that of the CLB logic. That implies for simple logic,a FPGA is 1/3 slower than real gates. Note: I am guessing at the 1/3 figure as I don't have a data sheet handy. 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: 21542
galexand@sietch.bloomington.in.us (Greg Alexander) wrote: > 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. Usually, comp.arch.fpga is helpful to newbies. If you want to have a sensible discussion about hacking FPGAs, there are many here who could participate. There are many of us who have hacked at the FPGA tools and can speak from experience. You are not one of them. We stare at you in disbeleif because it's warranted. That you seem to think you understand the problem without ever having done an FPGA design is a measure of how clueless you really are. "There's no other way around it." This is not pomposity. This is reality. Pomposity is you taking the position that we are the ones who are clueless. > Everyone here takes the title professional too seriously. In the > software movement we've learned .... You guys don't own guns do you? At least we professionals don't take ourselves so seriously as to call ourselves a "movement". -- Don Husby <husby@fnal.gov> http://www-ese.fnal.gov/people/husby Fermi National Accelerator Lab Phone: 630-840-3668 Batavia, IL 60510 Fax: 630-840-5406Article: 21543
This is a multi-part message in MIME format. --------------D2703B39D9682F6AFFDE603A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > improvement efforts. You previously mentioned you are using one of the > smaller 4000 series parts on an XESS board. That part is supported by the > student edition of the software. Why, XESS sells a bundled package with > their board, the student edition software (without VHDL, mind you) and a > lab text book for about $200. I think that package is one of the best > values for someone starting out with FPGAs. Learn the basics in a proven I've stayed out of this religious war on purpose, but I do need to correct this statement just a bit. The Xilinx Student Edition software version 1.5 does have VHDL and Verilog capabilities. (The older version 1.3 only had ABEL and schematics.) But thank you for the complimentary statements about our products. Now you can all go back to the jihad. -- || Dr. Dave Van den Bout XESS Corp. (919) 387-0076 || || devb@xess.com 2608 Sweetgum Dr. (800) 549-9377 || || http://www.xess.com Apex, NC 27502 USA FAX:(919) 387-1302 || --------------D2703B39D9682F6AFFDE603A Content-Type: text/x-vcard; charset=us-ascii; name="devb.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dave Vanden Bout Content-Disposition: attachment; filename="devb.vcf" begin:vcard n:Vanden Bout;Dave tel;fax:(919) 387-1302 tel;work:(919) 387-0076 x-mozilla-html:FALSE url:http://www.xess.com org:XESS Corp. adr:;;2608 Sweetgum Drive;Apex;NC;27502;USA version:2.1 email;internet:devb@xess.com title:FPGA Product Manager x-mozilla-cpt:;-16464 fn:Dave Vanden Bout end:vcard --------------D2703B39D9682F6AFFDE603A--Article: 21544
"Greg Alexander" <galexand@sietch.bloomington.in.us> wrote in message news:8bfvke$rkd$1@jetsam.uits.indiana.edu... > In article <38DB7BC3.889F0994@ids.net>, Ray Andraka wrote: > >Not at all. It's just that I think it makes more sense to first work with > >what is out there before condemning it. To be fair - i haven't seen him condem it. Sure, he thinks it's crap and won't install it - but i reckon thats more of a preference for him than a bitch at the tools. I agree he'd learn a lot about the architecture by doing it but there's nothing wrong with learning the hard way if thats what he wants. Greg - As for FPGA vendors releasing specs for things they consider trade secrets - forget it. Sure, the competition MAY have cracked it already, but that doesn't mean that the vendors are going to make it easy for them (they may have missed something). You wouldn't expect Intel to hand AMD the source code for the Xeon just because AMD have something compatable ! If they released the specs they would be telling us a lot more about the internal architecure of the chip than an API would say about the algorithms used in a software library. So, if your going to do this i'm afraid it's time to reverse engineer the bit-stream. But be careful - and invalid bit stream can physically damage the chip, and that's going to cost you more than buying the software. > Think of how much time Xilinx would have saved you if they'd just > released bitstream specs. :) Actually it wouldn't save them time. As a (commercial) user, i'd still expect Xilinx to produce the tools - even if they produce the specs. So they have to publish more. > >My point is, I don't think the tools are nearly as limiting as you percieve > >them to be. How can you know what the limits are if you've never touched > >the tools or the devices???? > > It would be nice if they'd let me try to do it the cheap way before > forcing me to buy the tools rather than vice versa. I'd be interested out of curiosity ... but it'll never happen ... A.Article: 21545
I've come to the conclusion that you are a flamer and a troll, your posts are becoming more ridiculous and deliberately inflamative, george. You have asked for the advice of the experts, and ignored the advice. You accuse people of not "bothering to understand what's going on", when those in this group are intimatly concerned with how the tools operate and the architectures being targeted. If I send you a free copy of the student edition Xilinx tools, will you go away? We have a couple of textbook evaluation copies with CDs in the back, sitting in our office. I could also toss you a copy of the Altera student tools, same thing there. To everyone else, let us no longer respond to this thread of george's. Ignore it, and it should go away. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 21546
Ray Andraka wrote: > > You just have to design your logic with the FPGA structure in mind :-). Look > for Jan Gray's series of articles on implementing a RISC in an FPGA. > > As for testing, true you can't stick a probe in the chip, but then there are few > chips these days that you can do that too. Instead, there are other techniques > including simulation, test vectors, dedicated test points, and my favorite, using > reconfiguration to modify the circuit to get at the data you want to observe. > Most of all that is done simulating, the design in software, a good feature of FPGA's. In hardware with the EXCESS amount of programmability FPGA's do have the advantage of being able to provide test points and logic checks that are often ignored do to lack of gates on simpler designs. A traditional front panel, now can make a come back along with state checking the machine with a long shift register taking a snapshot of the machine. -- "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: 21547
A quick & dirty solution: Use a 2x clock as an input. Have clock A be the output of a divide-by-two clock divider. Have clock B be the output of a divide-by-two clock divider with a clock enable on the flip flop, both driving out to bufgs to the rest of the chip. Also, gives you a nice clean duty cycle in the process, if you ever need the falling edge. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 21548
Ben Franchuk wrote: > Andy Peters wrote: > > > > 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)? > > True they have had more resources, and time to develop the code,but you > can bet marketing pressure to get the product out the door. This is a PC > vs Mac > type problem we have here. Both people have valid view points, but OPEN > is generaly a lot better than closed, look at LINUX vs WINDOWS. Perhaps you should use a different model. Compare linux or windows against Mac. I am not a fan of apple but the fact is that they do not have a buggy op system. The reason is that the whole system is _closed_. Similarily the Xilinx system is closed in the sense that they do ALL the hardware and in a sense, all the software. (i.e. the FPGA programming software, not _unfortunately_, the PC op system on which I am running.) Thus the system seems to work quite well. I am a new Xilinx customer but frankly I am impressed. The software works as designed (mostly). The hardware works as designed (mostly). The customer support is good. They take the time to make sure that my questions are answered fully. The only problem I see at present is in the documentation. All the stuff is there but it is somewhat disorganized. (perhaps this is due to the fact that it covers so many devices.) The only serious problem I had with my first design was in getting the bitstream to properly activate the FPGA from a serial EEPROM. (master serial mode. They claim that slave serial is the most popular. Not for a single FPGA system.... A little more frustrating, for my master serial system I needed to have done activate at clock 4 not clock 1. The software has that option but it was buried a little deep and I didn't know that I needed to be concerned about it. All in all a pretty decent product that does what it is intended to do. The target market is not the few hackers out there but the millions of potential applications in industry. Think about it, do you want to waste your support money on the 1 or 2 unit customer or the 10,000 to ??? unit customer. I'll go with the quantity any day and so did Xilinx apparently. > > > > > > 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. > > > I agree let the COMPUTER grid away at the problems,but lets not > hide information. Well software XYZ has a bug that generates the wrong > routing table in the final output format. How can you find such a bug > if nobody but the vender can read the format and they don't time to > modify > the software? > > -- > "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: 21549
eml@riverside-machines.com.NOSPAM wrote: > On 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 take it you can really see the electrons flowing. OK.. The scope is roughly equivalent to a timing analyser. > > > 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? > > Evan
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