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
Thanks, Andy. Right on! I didn't want to fuel these fires, and upset some highly emotional people. But you explained it so well, and it has more credibility, coming from a user. There is simply no way any one person in his or her lifetime can write software that can even remotely compete in quality and performance with what Xilinx ( and Altera etc. ) have spent and are spending hundreds of thousands of man-hours on. Always with the sole intent to make it easier to design with the chips, because that's where we all make our money from. Peter Alke ================================== 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)? > > 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. > > > 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? > > -- 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 StevensArticle: 21451
David Neely wrote: > > Hey all, > > Just wanted to ask the newsgroup for a little help. I need to select a part > for a very small FPGA (or CPLD as the case may be) with about 20-25 pins > max. > > The big gimmick is speed - The part needs to be able to handle ~200 MHz on > the pins and internally. So far, the GAL22V10 from Lattice seems to be a > good choice....can anyone make any further recommendations? > Altera/Xilinx/Alcatel for example?? > > I wonder if I am forgetting something :Þ > > Thanks, > David Neely > Junior Engineer Based on your requirements for package size, you won't find an FPGA to fit. The smallest FPGA package I have found is a 100 pin TQFP. So you should concentrate on the CPLDs. But 200 MHz is fast even for CPLDs. I am not so familiar with these devices so I can't recommend anything. -- Rick Collins rick.collins@XYarius.com remove the XY to email me. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 21452
That assumes that all devices have pretty much the same architecture, doesn't it? Ben Franchuk wrote: > Hobson Frater wrote: > > > > Greg, > > > > I'm not familiar with your level of knowledge about Xilinx and our products, > > so please forgive me if the following is not what you're looking for. > > > > The bitstream specs for Xilinx devices, indeed most programmable devices from > > most companies, are proprietary. This is done to ensure that our customers' > > designs aren't copied or reverse-engineered (well at least not without a lot > > of trouble) by our customers' competitors. > > > I still can see how it would prevent reverse engineering, but I am lost > on how that prevents designs from being copied if a simple Rom is being > used to hold the bit stream. The disadvantage of the closed information > is that one is tied to the manufacturer to provide the ONLY source of > software for programing the device. A better idea would have standard > bit stream format, and have the manufactures supply a conversion program > to their encrypted format. This would provide hopefully more FPGA > software > and more people using FPGA's > > -- > "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: 21453
This would creat a skew between the two clocks if you are using both at the same time at any point - so you'd probably be better to use a and gate for both of them to give a similar delay. eg clk1 <= mast_clk and '1' ; clk2 <= mast_clk and enable ; Then define clk1 and clk2 as being clock nets which should go through the process of clock tree synthesis which your asic vendor may do for you. of course then you could have separate enables for each clock if oyu wanted as well. You'd probably want to make sure that the enable was fixed in a certain position to avoid glitches from switching the clock on and off - but then based on the initial problem you probably wouldn't want to turn one of them on and off anyway. jc <boniolopez@my-deja.com> wrote in message news:8batsh$7pk$1@nnrp1.deja.com... > > > Hi Nicolas, > Im not sure if it would good solution and would be glad if Mr. Peter > Alfke and other expert comments following: > Why not make 2 clock domains one with clk1 and one with clk2. > Clk2<=clk1 and enable_from_external_pin; > If you make ASIC this should not cause problem, in FPGA place clk2 on > secondary buffer (BufG). > Correct me, if I am wrong. > > remove_this_bonio.lopez@gmx.ch_remove_this > In article <38D63858.2A94786B@dotcom.fr>, > Nicolas Matringe <nicolas@dotcom.fr> wrote: > > Hi all > > I am working on a design which may be used in two products, one of > which > > won't need some functions of the design. I don't want to have 2 > designs > > (we won't make 2 ASICs). > > I was wondering if it was possible to have 2 clock domains (same > > frequency) with the possibility to turn one of them off to reduce > power > > consumption (this would be done by pulling a pin high or low for > > example) > > -- > > Nicolas MATRINGE DotCom S.A. > > Conception electronique 16 rue du Moulin des Bruyeres > > Tel 00 33 1 46 67 51 11 92400 COURBEVOIE > > Fax 00 33 1 46 67 51 01 FRANCE > > > > > Sent via Deja.com http://www.deja.com/ > Before you buy.Article: 21454
Andy Peters (apeters.Nospam@nospam.noao.edu.nospam) wrote:
: [ chop ] you think that you're just going to be able to, in your spare
: time, write a synthesis tool,
http://icarus.com/eda/verilog/
(needs some work, I know, but the core is there)
: a placement engine, a router,
http://www.eecg.toronto.edu/~vaughn/vpr/vpr.html
: and a timing analyzer?
Someone would have to volunteer for this one, probably based on
ACS or one of the libre VHDL/Verilog simulators.
: Is your background in writing code for synthesis tools?
See Icarus, above, or http://www-asim.lip6.fr/alliance/
: Logic minimization?
Classical logic minimization isn't terribly relevant for today's
FPGA architecture. The vpr code above handles some of what's left.
: All the other stuff that's under the hood of these tools?
Such as "project managers" and other GUI bits I don't want?
: And do you think that your stuff, starting from scratch, will somehow be
: "better" than, say, Xilinx', who've had a ten-year head start on you (and a
: lot more resources to throw at the problem)?
Quoting from the original post:
>> Every single time I"ve purchased hardware tied to
>> proprietary software the proprietary software, no matter how good, sucked
>> ass in the end and never ever did what I really wanted. No matter how
>> good, bug free, and featureful your proprietary software is and how naive,
>> buggy, and underfeatured the software I write will be, I ALWAYS prefer my
>> own.
So no, he doesn't think he can do "better". But he (and I) _would_ be
happier, because we understand what the limitations are, and can
address them as _we_ need, independent of someone else's market research.
: I would imagine that most of us who design with FPGAs for a living would
: much rather have the silicon vendors do the hard stuff -- the design
: software -- so we can get on with our jobs, which is building hardware.
... and wrestling with license managers, and begging for more money
to pay for continued use of the software.
Peter Alfke (peter@xilinx.com) wrote:
: There is simply no way any one person in his or her lifetime can write
^^^^^^^^^^
: software that can even remotely compete in quality and performance with what
: Xilinx ( and Altera etc. ) have spent and are spending hundreds of thousands
: of man-hours on.
OK, but how about a whole Internet full of people? That mindset
belongs in the 1980's. Essentially, you are telling your customers
to "shut up and get back on the couch."
: Always with the sole intent to make it easier to design with the chips,
: because that's where we all make our money from.
So release the bloody bitstream format already! Peter, I respect you
technically, but I also know who gives you your paycheck, and I know
the rules that corporations are legally obliged to follow. Those rules
have everything to do with money, and nothing to do with customer's
control over their design. In particular, the intent of Xilinx's
software is to lock their customers into Xilinx's chips. Ditto for
Altera.
I'm about to shell out some taxpayers' money for a commercial package,
because the free stuff isn't there yet, and never will be if Xilinx
has its way. That doesn't mean I'm happy.
I know this question gets hashed over in c.a.f every six months or so,
and I guarantee that pattern will continue until the problem is fixed.
Here's a scenario for how that will happen: some startup puts together
an FPGA, tries to sell it, goes belly up. Rather than selling the
charred remains to Xilinx, it releases the tested and functional (but
not profitable) chip design to the world.
Sorry for the interruption. You can now return to the usual fare of
"Why can't I make the stoopid software tools do what I want" questions.
- Larry Doolittle <LRDoolittle@lbl.gov>
Article: 21455In article <8bb5r9$27bv$1@noao.edu>, 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)? Nope. By reinventing the problem we can avoid all that. First off, I have little interest in a complete synthesis tool. I also have little interest in a complete placement engine or even a complete router. The timing analyzer worries me but I'm certain that if I could find timing specs for the chips (which I haven't been able to do so far -- anyone have any ideas?) that I'd be able to tackle the problem. At worst case I may find that the thing is undebuggable without the purchase of a pricey logic analyzer -- spending $300 for a low-end logic analyzer makes me a lot happier than spending $100 for software that doesn't do what I want. 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 (listing the inputs for each MUX and the logic functions for each of the three function generators; or the setup info if the FLB is to be used for RAM), something directly analogous to the bitstream with just the slightest abstraction for routing (perhaps naming the blocks and using block/output names -- i.e. "f1=1,1.yq" or even "f1=stackbit1.yq" instead of being so aware about the actual routing capabilities of the chip. Hopefully a converter to/from the bitstream and the simple text format would take me a couple weekends...nothing too special...for example, if the routing resources don't allow a connection between 1,1.yq and f1, it will just barf and exit and I'll be forced to go back to the datasheet and manually re-place the blocks involved. Probably I'll find that setup just a step or two too cumbersome to work with directly in vi, so I'll probably start work on over-simplified GUI where I can drag around named FLBs and it'll highlight connections that I've specified to other named FLBs that aren't allowed in that placement. Because it would be a bidirectional converter, I'd look at a lot of the preexisting bitstreams I have to look for how automated software uses the resources provided on the things to give me some ideas...but even the obvious capabilities of the FLBs on such a device seem sufficient for me to implement the processor I'm after, so I'm not betting too much on being able to use existing designs as inspiration. I am inexperienced but I hope to be able to have the chip mostly asynchronous and timing worked out by a combination between trial and error and eyeballing how I think it ought to work. I would be surprised if I don't develop an intuitive feel for it after a few months of messing around on weekends, esp. for such a small FPGA. I'm certainly not ruling out the possibility that I'll never get anything to work right at all on it, though. I don't need synthesis because I'll be laying it out like legos: a stack here, an adder there -- "oh damn no way to route that, let's scoot the adder over" (you /have/ played with legos enough to know the creative process, right? -- you don't really get a functional or heirarchical view, if you don't have pieces that fit you have to figure out how to do it with the pieces you have and if it turns out that you need something to be two blocks tall instead of three blocks tall you may well end up rebuilding the rest of your lego contraption -- directly analogous to a lack of synthesis and place&route software, methinks) -- and attempting to just build one processor, not a whole bunch of little things where I need the ultimate in flexibility. 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. 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. If there isn't a version of the chip suitable for a kid to mess around with then odds are there won't be any adults who really know what they're doing when they mess around with it. >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. Don't confuse using a tool for doing work. At any rate, I agree that any vendor who doesn't sell synthesis and P&R tools would be doing a disservice to a lot of its customer base...but any vendor who makes their hardware impossible to use without a specific set of P&R tools is also doing a disservice. Perhaps I have a hcoice between Brand A and Brand B, but that isn't any choice at all compared to homegrown. Probably most people who design with FPGAs for a living use them simply as limited programmable ASICs. That's a fine use for them. I want to use them as FPGAs, though. I have been given the knowledge of what the FLBs do and to use them as if they were something else would be intolerable for me, at least to start out. In other words, when I say AND gate, I expect an AND gate, but if I say AND gate and I know that it'll cleverly transform that into a lookup table in an FLB while attempting to cleverly take advantage of the 2 other inputs that the function generator affords...that's a lot of work going down behind my back, a lot of exciting things happening that I want to be involved in. Maybe in the end my answer isn't nearly as ingenius as what Xilinx's software would have come up with...but on the other hand, what if it's 100x better than what Xilinx's software would've come up with? What if it's just as good? 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. Related work: www.ultratechnology.com is the page for a company financed by a single individual (some might call him crazy) attempting to finish prototyping the F21 Minimal Instruction Set Computing (MISC) microprocessor. Chuck Moore designed the chip from the ground up. His CAD and simulation software were all written by him. I can't find the figures right now but IIRC the object code of his CAD+simulation environment was well under 32k. He didn't do automated layout (though I assume that since his CAD software is at basically the same level as his programming language that when he had to do repetitive tasks he didn't do them by hand) at all. I think he draws each transistor one at a time. He has working silicon. You can buy the MuP21 which was developed with the same software (I think), and the F21 is most likely only one prototyping stage away from working perfectly. Now you're thinking that Chuck Moore is an established professional (I think ShBoom/Patriot Scientific 1000 were his work in more traditional technology) who spent the last 15 (or more) years of his life full time developing that software and those chips -- obviously not a valid comparison to me. However, if I'm working on FPGA then my prototyping rounds will take just a few minutes and cost me nothing whereas each prototype he developed took months to get back from fab and packaging then took all sorts of time to analyze and each and every fab run (at least for the f21) was itself an economic crisis for the owner of ultratechnology (which is why F21e prototype isn't being fabbed right now). It's apparently a well-established fact that software development productivity increases more than linearly as compile/link time decreases (eXtreme Programming). In addition, I won't be starting over totally from scratch -- my object code will probably be much larger than 25k and it won't be hand-crafted (Chuck Moore invented Forth and his CAD/sim software runs on an extremely unique and low-level derivative). I think these advantages should simplify my task by several orders of magnitude and bring it into the range of what's feasible for me to complete eventually. At any rate, I'd much rather spend my next month banging my head on timing issues than trying to reverse-engineer their bitstream, something they can be confident their competitors have already done if there's any point to it (it's not a very difficult task). >> 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. So do I. I bet I'll be paid more (no cash involved) than your salary affords you if I ever boot up my own little toy processor on FPGA. I dare you to buy that type of satisfaction with your 6-figure salary. Money is not the ends, money is the means. At any rate, hardcore Linux hackers are, almost without exception, paid extremely well. If you can make fantastic technological toys for your own edutainment, it shows a lot to a potential employer. If you would do the stuff for the love of doing it, it usually implies greater competence than just the random Joe with a degree. My point in asking the question was actually to discover if you had seen "the light." Many programmers can remember the first day they allocated more than 64k (or 640k) of RAM without hassling with segments or an extended memory manager -- the first time they wrote a program for a real 32-bit OS. Not many of them willingly went back to DOS after that. Well I can remember the first time I was exposed to software that was broken but that, for the first time, I could fix because I had the knowledge and the source code to do so. I, for one, am not going back. Once you realize how much more can be accomplished by cooperation than by secrecy and attacks (suing over Patent violations, for example), I can't imagine anyone who really loves their art would go back. If you don't love your art then by some measures you're already dead. I'm not going to give up the love. 10 year old closed source software that crashes when you try to run it you have no choice but to throw away. 10 year old open source software that crashes when you try to run it you can recompile with -g (debugging symbols) and load up in gdb (GNU DeBugger) and fix. Do you want to contribute to the trashcan or to someone else's debugging nightmare? I'd prefer my progeny be a cursed debugging nightmare rather than a completely useless bitbucket filler. >Have you gone on tour and mixed live rock bands? Should you? If I had the opportunity and the opportunity cost were low (if I could do it for just a summer, for example), I would certainly consider doing it. If one of my larger goals were to make a better mixer, I'd certainly take the opportunity to go out and see how the things are used. Since your goal is to make intellectual property, it seems like you kind of have an obligation to yourself to learn how successful people work with intellectual property: by sharing.Article: 21456
Rickman wrote: > There are a lot of reasons for not giving out the bit stream format > details. Some have to do with preventing reverse engineering, but most > have to do with the interests of the company making the hardware. But > they are valid reasons nonetheless. > > One big reason is that the software can give an FPGA vendor a > competitive edge. For quite a while Altera was touted as having much > more user friendly software as compared to Xilinx. I can't say if this > was really true since I am not an Altera user. But I know people who > chose them as their FPGA vendor for this reason. I also don't think that > users perceive such a significance in the tools today. > My favorite tools are pencils and spell checkers. How ever the market for FPGA's is not for the one time computer hobbist ,or student but rather well funded companies, thus a few grand for software is small change when the IC's are few $100 each, so I can under stand the way the software tools are. Does any one use simple PAL's any more for $.79 each? > The existance of third party tools can be seen as a threat to an FPGA > vendor for this reason. About 10 years ago a third party FPGA tools > vendor, Neocad, came out with a set of tools that was not targeted to > any one vendor. One big selling advantage was that they would allow you > to port your designs between different vendors if you decided to change. > Combine that with the improved operation of the place and route portion > of the tools and now the FPGA vendors were looking at reduced software > sales. In fact more than one FPGA vendor dropped their own tools and > offered Neocad as their sole source of tools. Are they selling HARDWARE or SOFTWARE?, I thought it was hardware. > Xilinx decided that they needed the Neocad as an inhouse product and > bought the company. After a couple of years, they came out with a new > set of Xilinx tools based on the old Neocad tools. I can't say exactly > why Xilinx did this, but it did take the Neocad tools off the market. > > In any event, if you feel you can produce better FPGA tools than can the > vendors, why don't you feel that you can produce better chips? There are > projects which will allow you to share a wafer and produce a very small > quantity of chips at a reasonable price. Likely the cost of the chips > are less than the cost of the designer to lay them out. Why not go for > it and do an open source FPGA? I have no desire to go into the FPGA market, as I was not the one wanting to do software rewrite? As for a open source FPGA, I don't think one can do that cause most likely the FPGA's internal designs at patented. > > BTW, Neocad initially met with resistance from Xilinx, but after they > persisted and started shipping tools in spite of the Xilinx policy, > Xilinx changed course and assisted them with detailed internal > information on even the new chips. Maybe you will get this kind of > support once you have reached a point of credibility in the FPGA > community. > Who knows. > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design > Hmm I wonder if the next generation of FPGA's could have tiny leds on the outside, to show the data flowing like on star trek's enginering console. -- "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: 21457
In article <38D93BB6.65D94188@yahoo.com>, Rickman wrote: >Ben Franchuk wrote: >> >> I still can see how it would prevent reverse engineering, but I am lost >> on how that prevents designs from being copied if a simple Rom is being >> used to hold the bit stream. The disadvantage of the closed information >> is that one is tied to the manufacturer to provide the ONLY source of >> software for programing the device. A better idea would have standard >> bit stream format, and have the manufactures supply a conversion program >> to their encrypted format. This would provide hopefully more FPGA >> software >> and more people using FPGA's >> >> -- >> "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 > >There are a lot of reasons for not giving out the bit stream format >details. Some have to do with preventing reverse engineering, but most >have to do with the interests of the company making the hardware. But >they are valid reasons nonetheless. > >One big reason is that the software can give an FPGA vendor a >competitive edge. For quite a while Altera was touted as having much >more user friendly software as compared to Xilinx. I can't say if this >was really true since I am not an Altera user. But I know people who >chose them as their FPGA vendor for this reason. I also don't think that >users perceive such a significance in the tools today. It seems like adding more software to the pool of programs that support Xilinx FPGAs would be a good thing (esp. open source programs hwich are likely supported by a large and rabbid group of hackers and which likely support operating systems and features that no commercial software would ever bother with). The best that could happen would be that said hackers find specs for the XC4005XL and can afford an XS40 board and develop all of their software for Xilinx and this software is something that Xilinx could brag about. The worst that could happen would be if the hackers got specs for all FPGAs and made a really phenomenal development environment for all FPGAs that is better than any out by any vendor: neither changes the balance -- both can only make Xilinx more attractive. If instead a whole bunch of hackers just make crappy useless software and they only make it for Xilinx...WHO CARES? Yet another piece of crap sitting in some far corner of an overcrowded Linux archive. Big whoop. The software vendors can gain from the FPGA specs being proprietary, but the FPGA vendors (unless they are maintaining a monopoly on software, which at least Xilinx does not appear to) have nothing to lose by opening it up unless they get some kickbacks from the software vendors. Unless, of course, their software totally sucks and they know that opening up their specs would immediately result in a dozen smaller, faster, better route&place engines being released, a possibility I will not rule out. >The existance of third party tools can be seen as a threat to an FPGA >vendor for this reason. About 10 years ago a third party FPGA tools >vendor, Neocad, came out with a set of tools that was not targeted to >any one vendor. One big selling advantage was that they would allow you >to port your designs between different vendors if you decided to change. >Combine that with the improved operation of the place and route portion >of the tools and now the FPGA vendors were looking at reduced software >sales. In fact more than one FPGA vendor dropped their own tools and >offered Neocad as their sole source of tools. > >Xilinx decided that they needed the Neocad as an inhouse product and >bought the company. After a couple of years, they came out with a new >set of Xilinx tools based on the old Neocad tools. I can't say exactly >why Xilinx did this, but it did take the Neocad tools off the market. See, if Neocad really did up the ante in the routing game, then Neocad tremendously helped FPGA. Rather than redesigning their interconnect, probably a very expensive operation, it was shown that simply redesigning the software can make a huge difference, something they'd apparently not taken into account if some third party software was actually capable of beating them. Upping the standards may have cost them a little bit in the short term but I'm sure it helped increase people's respect for FPGAs. Also once the software is respected as having evolved for a while and being the result of 10 years of work, as you've observed, fewer people in your shoes will have trouble believing that it's really worth as much as the pricetag is. Back when Neocad was an issue, I get the impression that Linux wasn't, and Neocad also apparently wasn't an issue because Xilinx et al were sharing everything with everyone -- in other words, is anything stopping Neocad from happening again? Neocad was a company with resources, they would get the specs if they tried hard enough, probably direct from Xilinx... Nobody has apparently done the gamble to see what resources are available if you really open it up to just let random Joe Blow mess around with the things. >I won't say that I miss the Neocad tools. They were written by a group >of Unix hackers that understood little about hardware design. The user >interface on the tools was case sensitive so that users had to mix case >on nearly every command typed. The tools were written to control what >you did instead of helping. For example, if after placement, the tools >guestimated incorrectly that your paths would not meet your timing >constrains with routing delays added, you would not be allowed to try to >route the design. This did not work well for tristate busses where the >guestimated delays were about twice the actual delays. Had it been open source, you could have quick-fixed the guesstimates and you'd never be sitting there "I KNOW YOU THINK THIS WON'T WORK, BUT IT WILL, JUST ROUTE THE !#$!@#$ING THING !#$!@#!!!" because the author will always have respected the users (or is at least easily correctable :)). Misapplied Unix hackers doing a bad job doesn't mean Unix hackers are all stupid, you know. I've had almost no exposure to commercial engineering tools, but even in my limited exposure I can point you to high-priced engineering software that was obviously written by idiots...therefore you shouldn't use any high-priced engineering software? >So all in all, I feel that the Unix hackers did a very poor job of >writing an FPGA tool set. I think the only part that was better than the >proprietary tools was the router which could be run on a network of Sun >workstations overnight or the weekend to give you a lot more compute >time to solve the routing problem. > >In any event, if you feel you can produce better FPGA tools than can the >vendors, why don't you feel that you can produce better chips? There are >projects which will allow you to share a wafer and produce a very small >quantity of chips at a reasonable price. Likely the cost of the chips >are less than the cost of the designer to lay them out. Why not go for >it and do an open source FPGA? I can produce better FPGA tools /FOR ME/. I certainly don't have the expertise to design real chips (it seems like you'd start with the easy development environment then go on to the Real Thing, rather than vice versa). There are good odds that if a couple linux hackers make cheap little overspecified tools, that will encourage someone else to buy an FPGA without worrying about whether or not they'll be able to get it to work. Look at xess.com, their question/answer section has two separate postings about Linux. Their bitstream-upload software (xstools) has been ported to Linux at least twice. There is obviously interest. But when I say "I want Linux Software", I don't mean I want a port of the crappy Windows software...I want something that meets the standards for being Linux Software (with an upper-case S) -- open-source, targetted at people who could understand everything if they had the time, and runs on Linux. The last requirement is the least important one. I'm sure there are some lurkers here and if I find teh specs I'm after and I come back in 4 months saying "HOORAY, IT BOOTED!!" I know for certain after the impression I'm making here that any lurkers who aren't already designing FPGAs will say "hey wow! If that kid can do it, anyone can" and they'll go out and buy FPGAs without even the slightest hesitation. >BTW, Neocad initially met with resistance from Xilinx, but after they >persisted and started shipping tools in spite of the Xilinx policy, >Xilinx changed course and assisted them with detailed internal >information on even the new chips. Maybe you will get this kind of >support once you have reached a point of credibility in the FPGA >community. And how do you propose I get there? I'm not Foosoft, I'm a kid trying to write his own software to design his own processor. I have no interest in being part of a mass-market. I have no interest in other people using my software -- I'll share it because other people shared their little hacks and I've found them useful, but not because I expect to have market influence individually. I want to design a processor in FPGA. I don't want to be a politician or a vendor or otherwise spend my entire time fighting Xilinx. I want to provide them money and in return receive a chip that I can use.Article: 21458
In article <38D931FE.4239F0F2@hia.nrc.ca>, Tom Burgess wrote: >Just wondered if anyone else has seen the same problem >- namely that when I run bitgen with tie enabled it seems to bog >down toward the end tying down single nodes. When it finally completes, the >bitgen report says that some nodes are still untied - I've seen as many as >1023 untied nodes on a 70% utilized 4013XLA. I don't remember >makebits being this bad with 90% utilized plain old 4000 parts. The -u option >makes no difference, since no nets are flagged critical. I'm running >Fndtn 2.1i SP5 (128M RAM). The support database and hotline were not particularly >helpful on this issue. > >Is the untied nodes number bogus, and if not, should I be concerned? If I had source I'd tell you. :PArticle: 21459
In article <38D93E81.1EA5522D@xilinx.com>, Peter Alfke wrote: >Thanks, Andy. Right on! >I didn't want to fuel these fires, and upset some highly emotional people. >But you explained it so well, and it has more credibility, coming from a user. > >There is simply no way any one person in his or her lifetime can write >software that can even remotely compete in quality and performance with what >Xilinx ( and Altera etc. ) have spent and are spending hundreds of thousands >of man-hours on. >Always with the sole intent to make it easier to design with the chips, >because that's where we all make our money from. I can't design with the chips at all since I can't run your software. More importantly, it's patently absurd that 100000 people with $1000000000 will do a better job than 1 person with pennies in his pocket at software design or engineering. Compare and contrast: FrameMaker's justify and hyphenation engines vs. TeX's justify and hyphenation engines. Adobe made FrameMaker, they're one of the most respected names in desktop publishing, and they doubtless had a huge and well-funded team working on FrameMaker, yet its hyphenation and justification sucks compared to TeX's, which, so far as I know, was written just by Donald Knuth. Ultima 9 vs. Quake. Ultima 9 was written by an established and presumably large team of well-funded developers in a big company and is known for crashing constantly. The various versions of Quake have had programming input from less than 4 people and almost all of the work is just by John Carmack -- idsoftware reliably releases games that are faster, more stable, and less delayed than other companies despite being such a small team. In a weird way: Linux vs. Windows. I've read the linux-0.01 source, pretty much entirely Linus's work, and I tell you that if Windows had started out anything like that and maintained that spirit, it wouldn't be well known for crashing during screensavers. If there aren't any glaring examples in ya'll's lives, it's probably only because you deal primarily in such proprietary software. Even more importantly, I have no intention of making better synthesis, route, and place tools than Xilinx did. I don't even want those tools. I want different tools. You sell an expensive hammer when what I want is a screwdriver. Maybe I'll never make a decent hammer for the rest of my life -- that wouldn't surprise me...at least today I don't have any ideas forming in my head about how to design R&P software and I know nothing of synthesis. But I'll be damned if my screwdriver isn't 100x better at turning screws than your hammer is. I guess a better analogy would be that most people want a hammer and you make a screw that is a lot better than nails for some uses. Your customers still want to make hammer motions so your software is great at converting that swinging motion into something that will turn your revolutionary *grin* screws. I, however, want to make turning motions to use your screws but your hammer is glued to the screws (in the way) so I can't figure out if it's Philips or some bizarre Torx screw. Of course, your hammer would work equally well if you made it so that I could still see the screw, but you guys have decided not to make that so.Article: 21460
In article <38D95B1F.9B3E2A6@jetnet.ab.ca>, Ben Franchuk wrote: >Rickman wrote: > >> There are a lot of reasons for not giving out the bit stream format >> details. Some have to do with preventing reverse engineering, but most >> have to do with the interests of the company making the hardware. But >> they are valid reasons nonetheless. >> >> One big reason is that the software can give an FPGA vendor a >> competitive edge. For quite a while Altera was touted as having much >> more user friendly software as compared to Xilinx. I can't say if this >> was really true since I am not an Altera user. But I know people who >> chose them as their FPGA vendor for this reason. I also don't think that >> users perceive such a significance in the tools today. >> > >My favorite tools are pencils and spell checkers. >How ever the market for FPGA's is not for the one time >computer hobbist ,or student but rather well funded companies, >thus a few grand for software is small change when the IC's are few >$100 each, so I can under stand the way the software tools are. >Does any one use simple PAL's any more for $.79 each? 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. :)Article: 21461
I have an application which uses up to 16 4028xla's. I would like each part to have a unique ID so I can write to that part's registers over common address & data buses. One way to do this is to daisy chain a 4bit ID value. The 1st device gets "0000" using pulldowns. It adds 1 to this and sends it to the next part, etc. This takes very little logic but does require 8 pins. Is there a better way to do this? Can something be done during configuration without having to generate many unique bit files? Les Sent via Deja.com http://www.deja.com/ Before you buy.Article: 21462
Ya know Greg, you can get as close to the hardware as you want with the current tools and you'll get up to speed on the gory details of the FPGA a heck of a lot faster using the stuff that is already out there, even if it has a few bugs. You have a choice: you can spend all your time figuring out how to connect two CLBs together, or you can spend your time actually working with the FPGA and doing something with it. What you are describing is pretty much the way the first XC2000 software worked (and the way the Epic chip editor in the current tools works). If you want to, you can write the equation for every CLB, and manually route the signals between them using this tool. In fact, using it you bypass the entire schematic/synthesis, translate, map, and place and route flow. Why, I'll bet the guys at NeoCad spent a great deal of time playing with XDE (the chip editor in the old XACT tools) before they every wrote their first line of code. Entering a design this way is not for the faint of heart though: it is tedious and error prone. Moving to the capture side, you can still get pretty close to the hardware though, all the way down to instantiating exactly the primitive you want and where you want it placed. Granted, that doesn't help you much if you are looking for the abiltiy to generate new configurations on the fly. Fortunately, many of the applications for reconfigurability can work with a relatively small set of configurations, perhaps with some LUTs twiddled (something that J-Bits is good for). I think before you tried to write your own tools, you'd be wise to understand the gory details of the PFGA architecture. As it is, you seem to feel you grok the CLBs well. It is apparent in you post though, that you don't have any understanding of the routing architecture. The fact of the matter is the lion's share of the bits in the bitstream are for setting up the routing resources, not for setting the CLB functions. If you are really serious about writing your own tools, I would suggest you work in the chip editor using a long series of simple configurations, generate bitstreams for each one and examine the differences in the generated bit streams. With alot of hard work you can get something close enough to write bitstreams directly (that's pretty much how Neocad got their tool up). For the $100 bucks (and just one weekend is worth a heck of a lot more than $100 to me), I think buying the student edition would be worth it, if for nothing more than an investigative tool. It also gives you the advantage of being able to work at a higher level to figure out what works well and doesn't work well in the FPGA architecture without getting lost in the low level detail. I for one, have done the pip pushing, and I can tell you that it is something I avoid like the plague. BTW, getting the bitstream format under NDA is not exactly unheard of, even for graduate students. Greg Alexander wrote: > In article <8bb5r9$27bv$1@noao.edu>, 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)? > > Nope. By reinventing the problem we can avoid all that. First off, I > have little interest in a complete synthesis tool. I also have little > interest in a complete placement engine or even a complete router. The > timing analyzer worries me but I'm certain that if I could find timing > specs for the chips (which I haven't been able to do so far -- anyone > have any ideas?) that I'd be able to tackle the problem. At worst case I > may find that the thing is undebuggable without the purchase of a pricey > logic analyzer -- spending $300 for a low-end logic analyzer makes me a > lot happier than spending $100 for software that doesn't do what I want. > 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 > (listing the inputs for each MUX and the logic functions for each of the > three function generators; or the setup info if the FLB is to be used for > RAM), something directly analogous to the bitstream with just the slightest > abstraction for routing (perhaps naming the blocks and using block/output > names -- i.e. "f1=1,1.yq" or even "f1=stackbit1.yq" instead of being so aware > about the actual routing capabilities of the chip. Hopefully a converter > to/from the bitstream and the simple text format would take me a couple > weekends...nothing too special...for example, if the routing resources > don't allow a connection between 1,1.yq and f1, it will just barf and exit > and I'll be forced to go back to the datasheet and manually re-place the > blocks involved. Probably I'll find that setup just a step or two too > cumbersome to work with directly in vi, so I'll probably start work on > over-simplified GUI where I can drag around named FLBs and it'll highlight > connections that I've specified to other named FLBs that aren't allowed in > that placement. > Because it would be a bidirectional converter, I'd look at a lot > of the preexisting bitstreams I have to look for how automated software > uses the resources provided on the things to give me some ideas...but even > the obvious capabilities of the FLBs on such a device seem sufficient for > me to implement the processor I'm after, so I'm not betting too much on > being able to use existing designs as inspiration. > I am inexperienced but I hope to be able to have the chip mostly > asynchronous and timing worked out by a combination between trial and > error and eyeballing how I think it ought to work. I would be surprised > if I don't develop an intuitive feel for it after a few months of messing > around on weekends, esp. for such a small FPGA. I'm certainly not ruling > out the possibility that I'll never get anything to work right at all on > it, though. > I don't need synthesis because I'll be laying it out like legos: a > stack here, an adder there -- "oh damn no way to route that, let's scoot > the adder over" (you /have/ played with legos enough to know the creative > process, right? -- you don't really get a functional or heirarchical view, > if you don't have pieces that fit you have to figure out how to do it with > the pieces you have and if it turns out that you need something to be two > blocks tall instead of three blocks tall you may well end up rebuilding > the rest of your lego contraption -- directly analogous to a lack of > synthesis and place&route software, methinks) -- and attempting to just > build one processor, not a whole bunch of little things where I need the > ultimate in flexibility. > 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. > 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. If there isn't a version of the chip > suitable for a kid to mess around with then odds are there won't be any > adults who really know what they're doing when they mess around with it. > > >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. > > Don't confuse using a tool for doing work. At any rate, I agree that any > vendor who doesn't sell synthesis and P&R tools would be doing a > disservice to a lot of its customer base...but any vendor who makes their > hardware impossible to use without a specific set of P&R tools is also > doing a disservice. Perhaps I have a hcoice between Brand A and Brand B, > but that isn't any choice at all compared to homegrown. > Probably most people who design with FPGAs for a living use them > simply as limited programmable ASICs. That's a fine use for them. I want > to use them as FPGAs, though. I have been given the knowledge of what the > FLBs do and to use them as if they were something else would be > intolerable for me, at least to start out. In other words, when I say AND > gate, I expect an AND gate, but if I say AND gate and I know that it'll > cleverly transform that into a lookup table in an FLB while attempting to > cleverly take advantage of the 2 other inputs that the function generator > affords...that's a lot of work going down behind my back, a lot of > exciting things happening that I want to be involved in. Maybe in the end > my answer isn't nearly as ingenius as what Xilinx's software would have > come up with...but on the other hand, what if it's 100x better than what > Xilinx's software would've come up with? What if it's just as good? > 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. > > Related work: > www.ultratechnology.com is the page for a company financed by a > single individual (some might call him crazy) attempting to finish > prototyping the F21 Minimal Instruction Set Computing (MISC) > microprocessor. Chuck Moore designed the chip from the ground up. His > CAD and simulation software were all written by him. I can't find the > figures right now but IIRC the object code of his CAD+simulation > environment was well under 32k. He didn't do automated layout (though I > assume that since his CAD software is at basically the same level as his > programming language that when he had to do repetitive tasks he didn't do > them by hand) at all. I think he draws each transistor one at a time. He > has working silicon. You can buy the MuP21 which was developed with the > same software (I think), and the F21 is most likely only one prototyping > stage away from working perfectly. > Now you're thinking that Chuck Moore is an established > professional (I think ShBoom/Patriot Scientific 1000 were his work in more > traditional technology) who spent the last 15 (or more) years of his life > full time developing that software and those chips -- obviously not a > valid comparison to me. However, if I'm working on FPGA then my > prototyping rounds will take just a few minutes and cost me nothing > whereas each prototype he developed took months to get back from fab > and packaging then took all sorts of time to analyze and each and every > fab run (at least for the f21) was itself an economic crisis for the owner > of ultratechnology (which is why F21e prototype isn't being fabbed right > now). It's apparently a well-established fact that software development > productivity increases more than linearly as compile/link time decreases > (eXtreme Programming). In addition, I won't be starting over totally from > scratch -- my object code will probably be much larger than 25k and it > won't be hand-crafted (Chuck Moore invented Forth and his CAD/sim software > runs on an extremely unique and low-level derivative). I think these > advantages should simplify my task by several orders of magnitude and bring > it into the range of what's feasible for me to complete eventually. > > At any rate, I'd much rather spend my next month banging my head > on timing issues than trying to reverse-engineer their bitstream, > something they can be confident their competitors have already done if > there's any point to it (it's not a very difficult task). > > >> 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. > > So do I. I bet I'll be paid more (no cash involved) than your salary > affords you if I ever boot up my own little toy processor on FPGA. I dare > you to buy that type of satisfaction with your 6-figure salary. Money is > not the ends, money is the means. > At any rate, hardcore Linux hackers are, almost without exception, > paid extremely well. If you can make fantastic technological toys for your > own edutainment, it shows a lot to a potential employer. If you would do > the stuff for the love of doing it, it usually implies greater competence > than just the random Joe with a degree. > My point in asking the question was actually to discover if you > had seen "the light." Many programmers can remember the first day they > allocated more than 64k (or 640k) of RAM without hassling with segments > or an extended memory manager -- the first time they wrote a program for a > real 32-bit OS. Not many of them willingly went back to DOS after that. > Well I can remember the first time I was exposed to software that was > broken but that, for the first time, I could fix because I had the > knowledge and the source code to do so. I, for one, am not going back. > Once you realize how much more can be accomplished by cooperation than by > secrecy and attacks (suing over Patent violations, for example), I can't > imagine anyone who really loves their art would go back. If you don't > love your art then by some measures you're already dead. I'm not going to > give up the love. > 10 year old closed source software that crashes when you try to > run it you have no choice but to throw away. 10 year old open source > software that crashes when you try to run it you can recompile with -g > (debugging symbols) and load up in gdb (GNU DeBugger) and fix. Do you > want to contribute to the trashcan or to someone else's debugging > nightmare? I'd prefer my progeny be a cursed debugging nightmare rather > than a completely useless bitbucket filler. > > >Have you gone on tour and mixed live rock bands? Should you? > > If I had the opportunity and the opportunity cost were low (if I could do > it for just a summer, for example), I would certainly consider doing it. > If one of my larger goals were to make a better mixer, I'd certainly take > the opportunity to go out and see how the things are used. Since your > goal is to make intellectual property, it seems like you kind of have an > obligation to yourself to learn how successful people work with > intellectual property: by sharing. -- -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: 21463
Hi, try the following: Run timing analyzer and load your design. Under the "Path Filter" menu select "Custom Filters" and then select either "Select sources" or "Select destination" A pop-up menu will appear. Under Source Element Type, select "Clocks" You will get all signals in your design the tools had identified as clocks. Hope this help, Gerard Auclair Marconi Communications <boniolopez@my-deja.com> wrote in message news:8b5mrk$k76$1@nnrp1.deja.com... > Hi all, > I'm not very new in FPGA design but I can't find the issue of following > problem: > > > WARNING:Timing:33 - Clock nets using non-dedicated resources were found > in this > design. Clock skew on these resources will not be automatically > addressed > during path analysis. To create a timing report that analyzes clock > skew for > these paths, run trce with the '-skew' option. > > > > I'm quite sure to use in my design the deducted clock resources only > (and connected to BufG or Buf GP). I think the syntheses tool can' > recognise some part in my design and form it so, that clock some FF > with the gated signal. But I cant find where. > > THE QUESTION: How I can find out where the Alliance 2.1i found the non- > dedicated resources(which signal is such clock)? > > Any help will be appreciated, > Bonio > Remove_this_Bonio.lopez@gmx.ch_remove_this > > > > Sent via Deja.com http://www.deja.com/ > Before you buy.Article: 21464
This will not work very well in an FPGA. First of all the AND gate using a 1 input will be optimized out. Secondly the routing delays will likely be at least as large as the gate delay, so you will still not be able to match the delays. If you are planning on using this chip in two different board designs, you can use two separate clock input pins. Then one clock can be disabled by connecting it to ground on the board. No gate needed and you will have much more closely matched clock routing delays. Jared Church wrote: > > This would creat a skew between the two clocks if you are using both at the > same time at any point - so you'd probably be better to use a and gate for > both of them to give a similar delay. > > eg > > clk1 <= mast_clk and '1' ; > clk2 <= mast_clk and enable ; > > Then define clk1 and clk2 as being clock nets which should go through the > process of clock tree synthesis which your asic vendor may do for you. > > of course then you could have separate enables for each clock if oyu wanted > as well. > > You'd probably want to make sure that the enable was fixed in a certain > position to avoid glitches from switching the clock on and off - but then > based on the initial problem you probably wouldn't want to turn one of them > on and off anyway. > > jc > > <boniolopez@my-deja.com> wrote in message > news:8batsh$7pk$1@nnrp1.deja.com... > > > > > > Hi Nicolas, > > Im not sure if it would good solution and would be glad if Mr. Peter > > Alfke and other expert comments following: > > Why not make 2 clock domains one with clk1 and one with clk2. > > Clk2<=clk1 and enable_from_external_pin; > > If you make ASIC this should not cause problem, in FPGA place clk2 on > > secondary buffer (BufG). > > Correct me, if I am wrong. > > > > remove_this_bonio.lopez@gmx.ch_remove_this > > In article <38D63858.2A94786B@dotcom.fr>, > > Nicolas Matringe <nicolas@dotcom.fr> wrote: > > > Hi all > > > I am working on a design which may be used in two products, one of > > which > > > won't need some functions of the design. I don't want to have 2 > > designs > > > (we won't make 2 ASICs). > > > I was wondering if it was possible to have 2 clock domains (same > > > frequency) with the possibility to turn one of them off to reduce > > power > > > consumption (this would be done by pulling a pin high or low for > > > example) > > > -- > > > Nicolas MATRINGE DotCom S.A. > > > Conception electronique 16 rue du Moulin des Bruyeres > > > Tel 00 33 1 46 67 51 11 92400 COURBEVOIE > > > Fax 00 33 1 46 67 51 01 FRANCE > > > > > > > > > Sent via Deja.com http://www.deja.com/ > > Before you buy. -- Rick Collins rick.collins@XYarius.com remove the XY to email me. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 21465
...interesting but long rant snipped... > Sorry for the interruption. You can now return to the usual fare of > "Why can't I make the stoopid software tools do what I want" questions. > > - Larry Doolittle <LRDoolittle@lbl.gov> LOL, I like your style, Larry. You have converted me and I now agree that the bitstream specs should be released to the world so that the greater community can try to make better screwdrivers and hammers and other tools that have not been thought of yet. And of course the FPGA vendors can not be blamed for any problems from using these tools, but that is one of the reasons that they don't want to see third party tools. They are afraid of the support questions from it. FPGA vendors not releasing the bitstream info is a little like a microprocessor vendor not releasing the binary instruction information. It's not like any of those freeware compiliers are very good anyway. Gnu what I mean? ;) BTW, why can't I make my FPGA tools do what I want? -- Rick Collins rick.collins@XYarius.com remove the XY to email me. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 21466
Hi, Let's run trce with -v 1 option. trce -v 1 -skew design.ncd design.pcf one detail path will be reported in .twr file. see around "TS_gpp1_dup0" constraint. and check the source and destination clock name.Article: 21467
In article <38D97E76.2DD0F61D@ids.net>, Ray Andraka wrote: >Ya know Greg, you can get as close to the hardware as you want with the current >tools and you'll get up to speed on the gory details of the FPGA a heck of a lot >faster using the stuff that is already out there, even if it has a few bugs. You >have a choice: you can spend all your time figuring out how to connect two CLBs >together, or you can spend your time actually working with the FPGA and doing >something with it. One way to look at it is that I want to drill a single hole in a single piece of wood and you are pointing out to me how great a drill press is. Why would I pay the cost of a large featureful system if I don't want the features? I don't just mean financial cost, I mean in terms of complexity and disk space and flexibility. The other way is that no matter how good, fast, fully-featured, clever, and bug free that software is and no matter how bad, slow, under-featured, naive, and buggy my software is (and by "my software" I refer to any software that I really understand -- it need not be written by me, but I do need the source), I would much prefer to have my software. >What you are describing is pretty much the way the first XC2000 software worked >(and the way the Epic chip editor in the current tools works). If you want to, >you can write the equation for every CLB, and manually route the signals between >them using this tool. In fact, using it you bypass the entire >schematic/synthesis, translate, map, and place and route flow. Why, I'll bet the >guys at NeoCad spent a great deal of time playing with XDE (the chip editor in >the old XACT tools) before they every wrote their first line of code. Entering a >design this way is not for the faint of heart though: it is tedious and error >prone. Moving to the capture side, you can still get pretty close to the >hardware though, all the way down to instantiating exactly the primitive you want >and where you want it placed. Granted, that doesn't help you much if you are >looking for the abiltiy to generate new configurations on the fly. Fortunately, >many of the applications for reconfigurability can work with a relatively small >set of configurations, perhaps with some LUTs twiddled (something that J-Bits is >good for). I think before you tried to write your own tools, you'd be wise to >understand the gory details of the PFGA architecture. As it is, you seem to feel >you grok the CLBs well. It is apparent in you post though, that you don't have >any understanding of the routing architecture. The fact of the matter is the >lion's share of the bits in the bitstream are for setting up the routing >resources, not for setting the CLB functions. If you are really serious about >writing your own tools, I would suggest you work in the chip editor using a long >series of simple configurations, generate bitstreams for each one and examine the >differences in the generated bit streams. With alot of hard work you can get >something close enough to write bitstreams directly (that's pretty much how >Neocad got their tool up). You mean I should reverse-engineer it? If it's so reasonably trivial to reverse-engineer it then obviously competitors already have so there's no point in even trying to keep it proprietary, so they should save me a little time and just give me the specs. After all, keeping it closed is only useful if it never gets reverse-engineered at all, but it's harmful even if it gets reverse-engineered often. > For the $100 bucks (and just one weekend is worth a >heck of a lot more than $100 to me), I think buying the student edition would be >worth it, if for nothing more than an investigative tool. It also gives you the >advantage of being able to work at a higher level to figure out what works well >and doesn't work well in the FPGA architecture without getting lost in the low >level detail. I for one, have done the pip pushing, and I can tell you that it >is something I avoid like the plague. BTW, getting the bitstream format under >NDA is not exactly unheard of, even for graduate students. Why should I sign away parts of my future just to get information I should get for free?Article: 21468
Greg Alexander wrote: > 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. :) After reading the excellent post by Larry Doolittle, I have to apologize to the people requesting the programming information for FPGAs. I think I was a bit arrogant like many designers who feel that the tools may not be good, but what could a few individuals do about it? I understand that you are not trying to show the FPGA companies how to write better software, although I think that could be done. But rather you are just trying to get enough information so that you can "play" with the software and see what kind of ideas you could develop on your own. I don't see any reason why this should not be supported. At this point I don't see why any of the vendors would want to keep their programming information secret. I think the only reason that they do it is because the greater FPGA user community does not care enough about it to make an impact. -- Rick Collins rick.collins@XYarius.com remove the XY to email me. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 21469
kgbee@my-deja.com wrote: > > I have an application which uses up to 16 4028xla's. I would > like each part to have a unique ID so I can write to that > part's registers over common address & data buses. One > way to do this is to daisy chain a 4bit ID value. The 1st > device gets "0000" using pulldowns. It adds 1 to this > and sends it to the next part, etc. This takes very little > logic but does require 8 pins. > Is there a better way to do this? Can something be done during > configuration without having to generate many unique bit files? > Les > > Sent via Deja.com http://www.deja.com/ > Before you buy. Yes, just have four inputs on each chip. Then hardwire the inputs on your board. Or you can use a single wire in and one out as a serial version of the read, increment and output that you have suggested. A single wire can be used if you indicate a one and a zero with pulse widths and you have a timing reference in each chip. -- Rick Collins rick.collins@XYarius.com remove the XY to email me. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 21470
<kgbee@my-deja.com> wrote in message news:8bbtji$bok$1@nnrp1.deja.com... > I have an application which uses up to 16 4028xla's. I would > like each part to have a unique ID so I can write to that > part's registers over common address & data buses. One > way to do this is to daisy chain a 4bit ID value. The 1st > device gets "0000" using pulldowns. It adds 1 to this > and sends it to the next part, etc. This takes very little > logic but does require 8 pins. > Is there a better way to do this? I'm not sure this counts as better, but it's different. Given that you have a CPU around anyway, you can have a single bit in and a single bit out (of each FPGA). You have the CPU attempt to write "0" to some register in the FPGAs. Only the FPGA that has its single bit input set active registers the write and then sets its address decoders to the "0" you just wrote. All FPGAs then shuft the single bit input to their outputs. The CPU next writes "1" to the same register, and the 2nd FPGA in the chain picks up this decode address, the CPU writes "2" for the 3rd FPGA, etc. You do need software control of the first single bit input, however. I don't know how you're configuring these FPGAs, but if possible I'd be tempted to use something like CClk or DIn for this bit. Heck, you can cheat even more and use the FPGA's configuration data output pin as your single bit output, since there's some fixed number of clocks been the serial data input and output. (And then you run the serial data input to a general purpose I/O pin on the FPGA, since I don't believe the FPGA can read that pin directly, although I could be wrong here. Someone should correct me if so.) ---Joel KolstadArticle: 21471
kgbee@my-deja.com wrote:
> Is there a better way to do this? Can something be done during
> configuration without having to generate many unique bit files?
> Les
You can use a boundary-scan user register.
If you instantiate the BSCAN hard macro you get SEL and TDO1/TDO2 and so
forth.
This allows you to implement a custom shift register which can be filled
by the normal BSCAN chain.
If you have BSCAN anyway on your board you need no additional
pins at all.
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: 21472-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 "Ben Franchuk" <bfranchuk@jetnet.ab.ca> wrote in message news:38D95B1F.9B3E2A6@jetnet.ab.ca... > Does any one use simple PAL's any more for $.79 each? Yup - the zero power series from Atmel and the Xilinx nee Philips Cool Runners are great where you need some logic, save some power, and minimize board space. Just because PALs don't get much press any more doesn't mean that no one is using them. Kind of like diodes, I guess. Kelly -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.2 for non-commercial use <http://www.pgp.com> iQA/AwUBONnKq+O3tORmHE48EQJE6wCg3+AmF9oFIzWiOsvbtNNhMDpxX4gAoN9O 7OB/EilMrGpMbPcDCgJ8Yo0r =nE+z -----END PGP SIGNATURE-----Article: 21473
I've got a problem with a space mission payload system. I want to use a FPGA as a clue point of a payload electronic unit. Can anybody clarify me how do I manage the concept of "single point failure tolerant" in the system, If I cannot redound the board where this FPGA is included. Do I redound the FPGA itself inside the board? Is it possible? And is it normally foreseen? Or is there anything else that I have to take into account? Or other good solutions that you can suggest me? Thanks for any advice and suggestion you can give me -- edemarchi@hotmail.comArticle: 21474
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
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