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
galexand@sietch.bloomington.in.us (Greg Alexander) wrote: > In article <8bg2qr$cqp$1@info3.fnal.gov>, Don Husby wrote: > >galexand@sietch.bloomington.in.us (Greg Alexander) wrote: > Getting rid of the bugs is small compared to the peace of mind of > understanding the software. Right, I got it from your first few posts. This is a spiritual thing for you. Nothing is stopping you from understanding. I'm just saying you'd get a little more credibilty on that point if you took the time to do some of that unsderstanding before shooting your mouth off. And, like the religous fanatics, if you feel you have to flog yourself in order to unsderstand it, be my guest. (I'll leave a break here for you to point out how intolerant I am. It's my spiriual quest to make fun of people who flog themselves. I hope you have no problem with that.) > >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. When I had no clue about FPGAs, I had the sense not to go spouting off about it. > That's why she's your ex-wife. Your judging of activities by OTHER people > as complete wastes of time is stupid. Stupid? That sounds pretty judgemental. Pot, kettle, black. I reserve the right to make any judgements I want. I stick by them. She was a kook. She did hard time in the nut house to prove it. I thank my lucky stars that she's my ex wife. > 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. I don't mind. But I have an opinion. Is this a problem? > Your ex-wife may have an idea there, working as a janitor. I don't think she'd agree with that. > "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. I'll stack my aesthetic sense against yours any day. Let's do lunch. > >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. Yes you do. It's an ad-hominem attack for the purpose of pointing out how silly your disk-space worries are. That you chose to respond in kind *without* apparent purpose allows me you use the "pot,kettle,black" rule again. > >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. I'll stack my knowledge of the FPGA and the software internals against yours any day. You'll lose your pennies, but you might learn something. Let's do lunch. -- 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: 21551
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'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. > Evan, Where are you hiring? 1. I can draw a gate level 2:1 MUX 2. I do know what a JK is and how to use it. ( I would have to look up how to build one from gates.) 3. Gate level counter... Once I got a gated D flip-flop then I could do it. (Or anything higher level.) But why would you want to for most real world applications? (posible exceptions high speed or low noise.. Or special count sequence. Then see FSM.) 4. FSM... No problem. 5. Line termination.. No problem here. Series, Thevenin, or whatever. 6. How about line impedances of a PCB trace? 7. How about ground planes? Now to be fair... 1. What are you paying? 2. How about job security? 3. How about unpaid overtime? 4. How about fringes? Please do not misunderstand me but, do you see my point? Perhaps you cannot draw the best candidates because your company is not the best employer? I really don't know so please do not be offended. I just know that some companies and some engineers deserve each other. When the two match up its great. Unfortunately that does not always happen. > > But then, if you just use FPGAs with an HDL, or even with schematics > to some extent, how are you ever going to learn these things? > > EvanArticle: 21552
On Fri, 24 Mar 2000 12:23:22 -0500, Theron Hicks <hicksthe@egr.msu.edu> wrote: >[snip] > 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. > I've always used master serial for the first device in a chain. But, I've usually also included the option to do "slave serial" to use the download cable. (My current design uses in-circuit programmable EEPROMs, so "master serial" is the only mode used.) Jason T. Wright Cygnion CorpArticle: 21553
On Fri, 24 Mar 2000 12:23:22 -0500, Theron Hicks <hicksthe@egr.msu.edu> wrote: >[snip] > 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. > I've always used master serial for the first device in a chain. But, I've usually also included the option to do "slave serial" to use the download cable. (My current design uses in-circuit programmable EEPROMs, so "master serial" is the only mode used.) Jason T. Wright Cygnion Corporation Jason T. Wright Cygnion CorpArticle: 21554
Due to the absence of any useful replies, let me rephrase the question: For medium density designs (~50% CLB utilization), is it unusual to see bitgen -t -u reporting untied nodes as seen in the console output and the .bgn report in the lowest level (verx/revx) design directory? I note that the flow now defaults to continuing as if nothing untoward was happening, whereas it used to be regarded as something of a sin to leave floating nodes in a production CMOS design. regards, tom 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? > Tom Burgess -- Digital Engineer Dominion Radio Astrophysical Observatory P.O. Box 248, Penticton, B.C. Canada V2A 6K3 Email: tom.burgess@hia.nrc.caArticle: 21555
Ray Andraka <randraka@ids.net> wrote in message news:38DB7BC3.889F0994@ids.net... > 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. I think an analogy would be if Microsoft and Intel introduce a new PC which is pretty attractive, but all the opcodes are secret and the only supplied programming language is Visual Basic. No opportunity to write assembly, or c, or lisp, or anything else. Microsoft would argue that you can do virtually any legitimate task under Visual Basic, and that ought to be good enough for you. If you don't like it, buy somebody else's PC. Microsoft and Intel might argue that this is the only way that they can guarantee a crash-free environment. I suspect that most people would simply shrug their shoulders, buy a copy of MS Office, and get on with using the system, particularly if the crash-free promise turned out to be mostly true. What Greg is proposing is breaking the seals on the PC, reverse engineering the machine language, working out a little assembler, maybe writing a c compiler, etc etc until he's got it running Linux. Depending upon the eventual goal, it isn't an unrealistic idea. A number of people have completely reverse-engineered games consoles and wrote PC simulators for them. Is it wrong to learn how to be a computer scientist by starting with 6502 machine language and then working up? Must people start at Visual C++ and work their way down? Philosophically, I think issuing the bits to a Xilinx is an excellent way to get a detailed understanding of how the CLBs work. Now to throw cold water on what I just said: There's no way in hell that Xilinx wants Greg or anybody else making their tools unnecessary. As they told me back in 1988, Xilinx is first and foremost a software company. They want to license you their intellectual property in bite-size, 12 month, chunks. Their corporate strategy implies that it would be suicidal to help people circumvent their profitable tools. What I think Greg wants is a FPGA equivalent of PIC. They virtually give away the development tools so that you will use their (sucky) microprocessors. Works for them, apparently. It's just another way of doing business. What I don't understand is why Xilinx doesn't publish the bitstream format for the low-end parts, which only require the $100 software package (which I have recently discovered is often given away to prospective customers). It doesn't seem that they stand to lose much revenue. What would be even more amusing is if Altera published the Xilinx bitstream (which no doubt they reverse-engineered long ago), and in retaliation, Xilinx published the Altera bitstream.... -- Gary Watson gary@nexsan.sex (Change dot sex to dot com to reply!!!) Nexsan Technologies Ltd. Derby DE21 7BF ENGLAND http://www.nexsan.comArticle: 21556
On Fri, 24 Mar 2000 12:49:39 -0500, Theron Hicks <hicksthe@egr.msu.edu> wrote: >Now to be fair... >1. What are you paying? >2. How about job security? >3. How about unpaid overtime? >4. How about fringes? > >Please do not misunderstand me but, do you see my point? Perhaps you cannot >draw the best candidates because your company is not the best employer? I >really don't know so please do not be offended. I just know that some companies >and some engineers deserve each other. When the two match up its great. >Unfortunately that does not always happen. It's not my company - they're just currently paying my bills. They're good employers, cubicles notwithstanding, pay well, they're leading-edge (3G wireless), and they've got an IPO on the way. The problem is simply that it's very difficult to find *any* engineers in the UK at the moment. If anyone wants to relocate to Cambridge mail me, and I'll give you details. They've got positions in FPGA/ASIC, DSP, and algorithm development. EvanArticle: 21557
"Gary Watson" <gary@nexsan.sex> wrote: > What would be even more > amusing is if Altera published the Xilinx bitstream (which no doubt they > reverse-engineered long ago), I'm curious to know why you think Altera would spend the effort do decode Xilinx's bitstream format. What could they possibly do with it? The data sheets pretty-much tell you what the internal architecture does. They know that somewhere in the bit stream, there's a bit that controls switch X, why would they care which particular bit it is? -- 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: 21558
--------------8AB2FDE5D90CEDA832C4B37C Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Gary Watson wrote: > Now to throw cold water on what I just said: There's no way in hell that > Xilinx wants Greg or anybody else making their tools unnecessary. As they > told me back in 1988, Xilinx is first and foremost a software company. No way! We make 95% of our revenue from chips. We say that we are a "solutions company" offering tools, cores, chips, and support. But our revenue comes from chip sales. > They > want to license you their intellectual property in bite-size, 12 month, > chunks. Their corporate strategy implies that it would be suicidal to help > people circumvent their profitable tools. Wrong again! The tools are hardly profitable, and need not be profitable. They are expensive in R&D, and they are vital to our chip sales. But they are not a major stream of revenue. > What I don't understand is why Xilinx doesn't publish the bitstream format > for the low-end parts, which only require the $100 software package (which I > have recently discovered is often given away to prospective customers). It > doesn't seem that they stand to lose much revenue. What would be even more > amusing is if Altera published the Xilinx bitstream (which no doubt they > reverse-engineered long ago), and in retaliation, Xilinx published the > Altera bitstream.... Everything we give out, we have to support. We are, therefore, reluctant to give out "unnecessary" details: NOT to keep them secret from Altera, NOT to make more money on the software sale, but fundamentally to limit our support cost. If a designers hangs himself in the gory details of the architecture, routing, and the bitstream generation, we cannot say: "Sorry, Charly, your fault". Since he is our customer, with perhaps substantial hardware purchases, we would have to bail him out. We would have not only a moral, but also a financial incentive to do that. This kind of support could become a nightmare. It's complicated enough, the way it is. We do have a feel for how much time and effort our customers invest in their designs that, ultimately, get implemented in our parts. And we even understand how much depends on the proper and trouble-free operation of our chips, often completely out of proportion to the chip price. Therefore, we have to, and we want to, provide good support. Just my opinion Peter Alfke --------------8AB2FDE5D90CEDA832C4B37C Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> <p>Gary Watson wrote: <blockquote TYPE=CITE>Now to throw cold water on what I just said: There's no way in hell that <br>Xilinx wants Greg or anybody else making their tools unnecessary. As they <br>told me back in 1988, Xilinx is first and foremost a software company.</blockquote> No way! We make 95% of our revenue from chips. We say that we are a "solutions company" offering tools, cores, chips, and support. But our revenue comes from chip sales. <blockquote TYPE=CITE>They <br>want to license you their intellectual property in bite-size, 12 month, <br>chunks. Their corporate strategy implies that it would be suicidal to help <br>people circumvent their profitable tools.</blockquote> Wrong again! The tools are hardly profitable, and need not be profitable. They are expensive in R&D, and they are vital to our chip sales. But they are not a major stream of revenue. <blockquote TYPE=CITE>What I don't understand is why Xilinx doesn't publish the bitstream format <br>for the low-end parts, which only require the $100 software package (which I <br>have recently discovered is often given away to prospective customers). It <br>doesn't seem that they stand to lose much revenue. What would be even more <br>amusing is if Altera published the Xilinx bitstream (which no doubt they <br>reverse-engineered long ago), and in retaliation, Xilinx published the <br>Altera bitstream....</blockquote> <b>Everything we give out, we have to support. </b>We are, therefore, reluctant to give out "unnecessary" details: NOT to keep them secret from Altera, NOT to make more money on the software sale, but fundamentally to limit our support cost. <p>If a designers hangs himself in the gory details of the architecture, routing, and the bitstream generation, we cannot say: "Sorry, Charly, your fault". Since he is our customer, with perhaps substantial hardware purchases, we would have to bail him out. We would have not only a moral, but also a financial incentive to do that. <p>This kind of support could become a nightmare. It's complicated enough, the way it is. <br>We do have a feel for how much time and effort our customers invest in their designs that, ultimately, get implemented in our parts. And we even understand how much depends on the proper and trouble-free operation of our chips, often completely out of proportion to the chip price. <br>Therefore, we have to, and we want to, provide good support. <p>Just my opinion <br>Peter Alfke <br> </html> --------------8AB2FDE5D90CEDA832C4B37C--Article: 21559
Catalin Baetoniu <starnet@home.com> wrote: >FPGA Hardware design is _hard_ and the >software tools quality is not the main problem. When the program you are >developing does not work the way you expect it you use a debugger, >set-up breakpoints, step trough your code and whatever else you software >people do when you hunt bugs. Normally you cannot stop an FPGA and you >cannot look inside it to see what went wrong. I'd say this is a problem related to software tools quality. Is there any reason why anyone can't design a built in test tool to capture the running state of an FPGA, set triggers for start and stop of the capture, even stop execution etc.? What makes you thing that any software which controls realtime events can be stopped more easily than an FPGA? One can design great debugging tools for FPGAs and very recently FPGA vendors are waking up to this too. > Another major difference >is that software is usually sequential while inside the FPGA everything >happens in parallel. There are systems with multiple processors controlling realtime events. Things happen in parallel there too. What I am trying to say is that there is not much difference between debugging sopthisticad systems, whethere they are hardware or software systems.Article: 21560
Theron Hicks <hicksthe@egr.msu.edu> 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. this reminds me the dilbert cartoon where a couple of bearded, bald guys talk about having to code only with ones and zeros and dilbert tops them off with "then you are lucky, we didn't even have ones. We had to write code only with zeros". Most people these days are not designing with ones and zeros. With million gate SoC designs, you can't fill a chip by desiging at the level of 2x1 muxes or JK flip-flops. You have to use HDLs and behavioral compilers etc.Article: 21561
Anyone have an example of driving a 32- or 64-bit wide bus between 2 FPGAs at 100MHz or better? -- 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: 21562
I can't believe the hostility I am seeing here. This guy (Greg, not George) is just saying that he wants to get enough information from Xilinx so that he can develope his own basic, crude, but effective tools to design FPGAs in the way he wants and without being dependant on anyone who won't share the source for the software. That's it, end of request. As a result, dozens of people (including myself initially) try to talk him out of this "silly" idea and tell him he should conform to doing FPGA design the way that we do it. Some of us even go so far as to adopt hostile tones and make posts asking others to ignore this person and his request. If that is not intolerance, then I don't know what is. Don seems to have a lot of issues because this guy reminds him of his ex-wife and her eccentric behavior. Fine, but you divorced the ex-wife because you didn't want to deal with her anymore, I assume. Why not just ignore Greg and consider you two to be divorced? Nicholas goes so far as to call Gred "a flamer and a troll". I don't see any of this. I see a person who has very specific ideas of what he wants to do and is asking for help or support in doing them. Perhaps he is a little harsh in his criticism of Xilinx and the users who tolerate the supposed offences by them. But he is far from inflammatory in my opinion. In fact this whole thread is opening my eyes to see how defensive and narrow minded we seem to be as a group. I have been a reader of a mailing list of Forth users which includes a few people who have worked with Charles Moore on Forth chips. I don't know that any of these chips will become mainstream commercial sucesses, but they are very interesting from an academic sense and show what can be done by a single person or a small team starting from nothing an attacking a huge problem from scratch. As someone posted in an earlier message, they succeeded in producing several chips while relying on almost no tools from the outside. That is saying a lot! So why do you (in the plural sense) need to feel so hostile toward someone who wants to walk a different path and persue different goals than your own? How about if we "all just learn to get along?" BTW, on the suggestion of some others that bitgen is the only part of the tools that contain the "secret" bitstream information. If that was all there was to hiding the info, then it would be a weekend task to reverse-engineer bitgen and role your own. It would be especially easy to test since you can run both your own and the Xilinx one side by side on a number of test cases. But I would be willing to bet that much of the details of the file format that goes into bitgen are not explained anywhere. So even if you figure out bitgen, you still have to figure out what all the control points are and what they do. Don Husby wrote: > > galexand@sietch.bloomington.in.us (Greg Alexander) wrote: > > In article <8bg2qr$cqp$1@info3.fnal.gov>, Don Husby wrote: > > > >galexand@sietch.bloomington.in.us (Greg Alexander) wrote: > > Getting rid of the bugs is small compared to the peace of mind of > > understanding the software. > > Right, I got it from your first few posts. This is a spiritual thing > for you. Nothing is stopping you from understanding. I'm just saying > you'd get a little more credibilty on that point if you took the time > to do some of that unsderstanding before shooting your mouth off. > And, like the religous fanatics, if you feel you have to flog yourself > in order to unsderstand it, be my guest. > (I'll leave a break here for you to point out how intolerant I am. It's > my spiriual quest to make fun of people who flog themselves. I hope > you have no problem with that.) > > > >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. > > When I had no clue about FPGAs, I had the sense not to go spouting > off about it. > > > That's why she's your ex-wife. Your judging of activities by OTHER people > > as complete wastes of time is stupid. > > Stupid? That sounds pretty judgemental. Pot, kettle, black. > I reserve the right to make any judgements I want. I stick by them. > She was a kook. She did hard time in the nut house to prove it. > I thank my lucky stars that she's my ex wife. > > > 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. > > I don't mind. But I have an opinion. Is this a problem? > > > Your ex-wife may have an idea there, working as a janitor. > I don't think she'd agree with that. > > > "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. > > I'll stack my aesthetic sense against yours any day. Let's do lunch. > > > >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. > > Yes you do. It's an ad-hominem attack for the purpose of pointing out > how silly your disk-space worries are. That you chose to respond in > kind *without* apparent purpose allows me you use the "pot,kettle,black" > rule again. > > > >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. > > I'll stack my knowledge of the FPGA and the software internals against > yours any day. You'll lose your pennies, but you might learn something. > Let's do lunch. > > -- > 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-5406 -- 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: 21563
> I had a similar discussion with Xilinx back in 1988 or thereabouts, when > they wanted me to pay $5000 for a piece of software so I could see if the > Xilinx parts would be suitable for my application. I said to the Xilinx guy > that they should give me the software for free like MMI did with Palasm, and > if it worked they would make their money by selling me chips (after all, the > tools only work with Xilinx chips). The Xilinx salesman explained that > Xilinx is a *software* company, not a chip company. They only make chips so > they can sell their development tools. > > I decided that I would ignore Xilinx for ten years, and revisit the issue. > Twelve years on, I've decided to give them another chance, and so I'm > looking at the Xilinx parts again. I'm sure they don't realize that they > lost out on selling millions of Xilinx parts to go into my designs because > they wouldn't give me their tools. I've been making do with PALs all > these years... > > [As a side note, the issue in 1988 was whether you could really fit my > intended design into their parts. I had an existing design, drawn by hand > onto a bunch of C size sheets of vellum. The Xilinx guy was unwilling to > refund my $5000 if the design didn't fit into the target part, even though a > rough gate count made us think it should fit easily. He offered us a 30 day > eval, but we judged that this would not be long enough.] > > -- > > Gary Watson > gary@nexsan.sex (Change dot sex to dot com to reply!!!) > Nexsan Technologies Ltd. > Derby DE21 7BF ENGLAND > http://www.nexsan.com I have the same problem with paying for the software. But you should try to distinguish between a lousy salesman and a lousy company. I don't think Xilinx has ever considered themselves to be a software company. They charge for the tools just because they need to balance the revenue against the costs of providing each the hardware and the software. The software costs are so large that if they just absorbed that cost into the hardware revenue stream, they would have to charge enough more for the chips that they would lose some of the high volume sales and their competition would gain. So instead they will give away tools if a customer is likely to be a high volume user of parts. This is why I think you got a lousy salesman. He should have reconized the potential gain and gotten you a free copy. The only companies that don't charge for their tools are the ones that can't compete directly on an equal footing. They get their sales by being novel in some way, like Atmel. They have a hard time competing with Xilinx or Altera if you just look at the parts. There are a few niche applications which they do well, but for the most part if they did not give away their tools, they would not get many customers. -- 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: 21564
Peter Alfke wrote: > Everything we give out, we have to support. We are, therefore, > reluctant to give out "unnecessary" details: NOT to keep them secret > from Altera, NOT to make more money on the software sale, but > fundamentally to limit our support cost. > > If a designers hangs himself in the gory details of the architecture, > routing, and the bitstream generation, we cannot say: "Sorry, Charly, > your fault". Since he is our customer, with perhaps substantial > hardware purchases, we would have to bail him out. We would have not > only a moral, but also a financial incentive to do that. > > This kind of support could become a nightmare. It's complicated > enough, the way it is. > We do have a feel for how much time and effort our customers invest in > their designs that, ultimately, get implemented in our parts. And we > even understand how much depends on the proper and trouble-free > operation of our chips, often completely out of proportion to the chip > price. > Therefore, we have to, and we want to, provide good support. > > Just my opinion > Peter Alfke > Peter, I want to understand this line of reasoning since I really don't see the rational behind keeping the bitstream secret. Are you saying that if Xilinx gave out the bitstream format and a customer of the chips bought a third party toolset or rolled his own tools that Xilinx would offer some form of support for issues related to loading the chips from these tools? I can't see the basis for that. Some others have posted analogies to microprocessors and the binary instruction formats. I don't think that Intel or anyone else feels the need to support any third party code generators in any way. If the chip executes the instructions the way it is documented, then they are done. Likewise, if a given bitsteam generated from third party tools does not work in a Xilinx part, why would anyone expect Xilinx to even take a look at the generated bitstream? As I see it, that is the main reason that a user buys a Xilinx toolset. You get support directly from the source. I looked at buying Neocad software years ago and one of the many reasons that I didn't was because they were "third party" and would never be able to supply a complete support package. They never made any indication that Xilinx would support their products in any way. In fact they said that Xilinx initially was very uncooperative in providing any info on the bitstream or chip designs. But they worked around that and Xilinx ultimately decided that it was in their own interests to provide information to Neocad, very much like what Greg is asking for. Information without obligation for support. -- 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: 21565
Jamie Sanderson wrote: > > 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, > Jamie Jamie, I would have loved to have had such a capability in my FPGA. Instead I settled for putting the bitfile into the flash PROM including the header with the date and file name information. This does a lot to achieve the goal of being able to distinguish FPGA versions. As to the unique identifier, otherwise known as a serial number (SN), I figured this was just too tricky to bother with and added a Dallas one wire part to the board. They make many different types of parts which will actually communicate over a single wire (plus ground) by using an open collector IO with pulse width distinguishing a 1 from a 0. We implemented the one wire protocol in our DSP and the DS2430 gives us a 48 bit unique SN, 64 bits of PROM and 256 bits of EEPROM. We use the PROM to store board revision info and the EEPROM to store configuration details like default baud rate and load options. Just a thought... -- 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: 21566
hi, other than GCK0-3, is there anyway to have a clock signal without using dedicate Pin? I need to input two external clock to my FPGA board, but unfortunately the board is design such that only one external clock is possible. So, i am trying to inject the second external clock to a I/O, but the design refuse to map. skew of the second clock is not important to me, I just want a clock in a normal I/O pin! thanks spyng Sent via Deja.com http://www.deja.com/ Before you buy.Article: 21567
muzo wrote: > ... > designing with ones and zeros. With million gate SoC designs, you > can't fill a chip by desiging at the level of 2x1 muxes or JK > flip-flops. You have to use HDLs and behavioral compilers etc. Not so! I think it is much more important to make heavy use of hierarchy so that you can reuse design pieces. Even where I am using HDLs, I'm still doing alot of low level design (down at the primitives level). And yes, I am doing million gate designs. I'm just finishing one now that reports 999,376 equivalent gates at the tools output in the fuller chip of the two chip design - it runs at 134MHz in a 70 % full Virtex1000 -4. Guess what? A good deal of the design was done at the primitive level complete with floorplanning in the VHDL source. How long did it take? about 600 hours including design verification. About 20% of that time was algorithm development in Matlab. -- -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: 21568
Hi Don, check out Xilinx's application note 234, SelectLink. http://www.xilinx.com/applications/slcv/selectlink.htm It's up to 256 bits wide, up to 311 MHz per pin. Quite a lot of bandwidth. It's also only for Virtex and Virtex-E devices. Stefan In article <8bgkvp$iu3$1@info3.fnal.gov>, husby@fnal.gov (Don Husby) wrote: > > Anyone have an example of driving a 32- or 64-bit wide bus > between 2 FPGAs at 100MHz or better? > > -- > 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-5406 Sent via Deja.com http://www.deja.com/ Before you buy.Article: 21569
On 24 Mar 2000 15:33:09 EST, muzo <muzok@nospam.pacbell.net> wrote: >Theron Hicks <hicksthe@egr.msu.edu> 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. > >this reminds me the dilbert cartoon where a couple of bearded, bald >guys talk about having to code only with ones and zeros and dilbert >tops them off with "then you are lucky, we didn't even have ones. We >had to write code only with zeros". Most people these days are not >designing with ones and zeros. With million gate SoC designs, you >can't fill a chip by desiging at the level of 2x1 muxes or JK >flip-flops. You have to use HDLs and behavioral compilers etc. I can't agree. I use HDLs all the time, to fill "million gate" devices. HDLs and behavioural compilers are just tools. You can have the best chisel in the world, but it's not going to turn you into Michelangelo. EvanArticle: 21570
On Fri, 24 Mar 2000 10:29:18 -0500, "Jamie Sanderson" <jamie@nortelnetworks.com> wrote: >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, >Jamie I'd like to do this as well, so it would be interesting to hear how you get on. I can't see that you'll get the GUI version/revision info though, since this is just private to the GUI. Why don't you just maintain a revision register in your device? Your problem then is just identifying this register, or the serial number register, in the bitfile. I haven't looked at Jbits but, if it doesn't do the job, this procedure might work. Have a 16-bit revision number implemented as a CLB ROM element, and locate this ROM at a known CLB location. Generate an 'll' file from Bitgen ('-l' option). Search the ll file for lines containing your known CLB location (the ll format is documented in the file). This will give you the bit number, frame number, and frame offset for all 16 bits in your ID. The trick now is to identify these bits in your bitfile; see xapps 138 and/or 151. As an aside, this is what I do to get around the Xilinx GUI revision/version structure. My rebuild makefile always builds in a fixed directory (xproj/current in my setup), and you rely on a source control system to retrieve the important files (only) from previous builds. You then don't need multiple directories to keep a huge amount of redundant information. EvanArticle: 21571
Seeing the lack of responses, I can guess that many were mystified by your use of the unfamiliar terms "clue point" and "redound". The context is not sufficient to make them clear, to me at least. What's disconcerting is that the rest of the message appears to be mostly coherent English. regards, tom EDM wrote: > > 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: 21572
What is the type of your FPGA device and what tools do you use? Regards, Jarek spyng@my-deja.com wrote: > hi, > > other than GCK0-3, is there anyway to have a clock signal without > using dedicate Pin? > > I need to input two external clock to my FPGA board, but unfortunately > the board is design such that only one external clock is possible. > So, i am trying to inject the second external clock to a I/O, but the > design refuse to map. > > skew of the second clock is not important to me, I just want a clock > in a normal I/O pin! > > thanks > spyng > > Sent via Deja.com http://www.deja.com/ > Before you buy.Article: 21573
husby@fnal.gov (Don Husby) writes: > 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. He has never said that. He asked for the bitstream info and he was told that if he needed that info, he was an ass. > We stare at you in disbeleif because it's warranted. IMHO, you stare at him at disbelief because you don't get his point. > 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. I've done FPGA design, using the usual tools. I still would like to know the bitstream. What is my level of cluelessness ? I'd be interested to hand craft bitstreams, for fun. Does it degrade me a lot ? > "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. Well, he is right in the sense that a lot of people here does not seem to have a clue about what he's talking about. He does not want to start a one-man project to write open source FPGA toolchain (although I'm sure he would join such a project as would I). He doesn't want to hack an FPGA that can do video morphing in real-time. He wants to play with that damned chip and do something which he would not be paid for but from what he would learn a lot, plus it would be fun. I remember when I built a 7-bit Johnson counter from germanium transistors. It occupied most of my desk and drove 14 miniature lamps - a lit semicircle running around on a circle (except when any FF went the wrong way :-). It had absolutely no use whatsoever apart from me learning a lot about flip-flops, counters, shift registers and so on. Today you have FPGAs instead of Ge transistors. Ge transistors were fully documented and you did not have to buy tools to use them. You could use them even in reverse mode (C and E exchanged, was sometimes useful in perverse designs) because you got all the info. FPGAs you can't use, even if you bought them, for the company reserves the right to render them operable. It is like buying a radio but not being able to tune it without buying the TunePack (tm) (available for both Windows'95 (tm) and WindowsNT (tm)) software, great discounts for educational institutes and bulk buyers. Back to his unorthodox way of designing the FPGA: The fact that he does not want to follow the traditional way of designing an FPGA does not make him clueless. New things usually coming out from people who don't follow the road. 99.99% of them makes a long sidetrack and comes back to the road where all the others are marching. The 0.01% is the one who is worth of not building a concrete fence on the roadside. Give them a chance, let them try. If you ar right and the only way of designing a chip is using the tools, or if Peter Afke is right and making an FPGA tool is impossible without pouring millions of dollars into a project like that, he'll buy the tools or give up and learn plumbing. Why not give him the opportunity to try ? > You guys don't own guns do you? At least we professionals don't take ourselves > so seriously as to call ourselves a "movement". He probably left out the word "free". Free software believers have an agenda and goal and they are numerous enough so the "movement" is warranted. They also are taken quite seriously by some big companies because they smell big money. All the above, however, has not much to do with Greg's original request about the bitstream. He is not the first one and will not be the last one to request it and then being told to piss off. While I understand the vendors' coming up with all sorts of stuff about why keeping the bitstream info secret will help us design better chips and will also help to make the world a better place, I can't really grasp why some of the "we professionals" mentioned above jump on him for asking and stating that he does not want to buy the Xilinx tools nor Windows to run them on ? I, by the way, am quite curious why exactly the FPGA vendors keep the bitstream info closed ? Both the "protecting the customers' designs" and the "so that we don't have to support it" are quite fishy PR-talk, as has been shown in the thread. Obviously they're not going to tell but it's still an interesting question (well, to me, at least). Zoltan -- +------------------------------------------------------------------+ | ** To reach me write to zoltan in the domain of bendor com au ** | +--------------------------------+---------------------------------+ | Zoltan Kocsi | I don't believe in miracles | | Bendor Research Pty. Ltd. | but I rely on them. | +--------------------------------+---------------------------------+Article: 21574
Rickman <spamgoeshere4@yahoo.com> wrote in message news:38DBF184.C9FEFA10@yahoo.com... > > I had a similar discussion with Xilinx back in 1988 or thereabouts, when > > they wanted me to pay $5000 for a piece of software so I could see if the > > Xilinx parts would be suitable for my application. I said to the Xilinx guy > > that they should give me the software for free like MMI did with Palasm, and > > if it worked they would make their money by selling me chips (after all, the > > tools only work with Xilinx chips). The Xilinx salesman explained that > > Xilinx is a *software* company, not a chip company. They only make chips so > > they can sell their development tools. > > > > I decided that I would ignore Xilinx for ten years, and revisit the issue. > > Twelve years on, I've decided to give them another chance, and so I'm > > looking at the Xilinx parts again. I'm sure they don't realize that they > > lost out on selling millions of Xilinx parts to go into my designs because > > they wouldn't give me their tools. I've been making do with PALs all > > these years... > I have the same problem with paying for the software. But you should try > to distinguish between a lousy salesman and a lousy company. I don't > think Xilinx has ever considered themselves to be a software company. > They charge for the tools just because they need to balance the revenue > against the costs of providing each the hardware and the software. The > software costs are so large that if they just absorbed that cost into > the hardware revenue stream, they would have to charge enough more for > the chips that they would lose some of the high volume sales and their > competition would gain. So instead they will give away tools if a > customer is likely to be a high volume user of parts. This is why I > think you got a lousy salesman. He should have reconized the potential > gain and gotten you a free copy. In 1988 I worked for a very small company. They weren't going to give me a free copy of the development tools. My next job, though, was for a large company where 100,000 piece production runs were not uncommon, and we once did $1M in a year just on AMD PALs. Since I didn't know Xilinx I simply didn't use them. I guess I was also still mad about the earlier experience, so I didn't bother to learn. At the small company in 1988, we weren't insisting on getting the software for free. We simply wanted to be sure that our project would fit in one part, and that it would run at the necessary speed. If after entering the design and running the simulation the part didn't achieve our goals, we wanted our $5000 back (more precisely, we wouldn't pay the five grand until the simulation yielded the desired results). At that moment in history, Xilinx represented a new and largely unproven idea and it was not obvious at all to me that a real-world design would work well in the parts available at that time, and we didn't have $5000 extra to throw away. An ASIC would have only cost us $40k, because that's what we had been quoted, and would have been several times faster I'm sure (the project was a minicomputer emulator). I guess the boss was afraid of being ripped off, and was doubly concerned when it appeared that Xilinx didn't have enough confidence in their parts to let us have the software for the three or four months it would have taken to learn the package, enter the design, and conduct the simulation. If it worked, we would have paid the invoice, and started to order modest quantities of FPGAs. The Xilinx sales guy said that he would find us a service bureau who would quote us on typing in our paper schematics and running the simulation. This never happened, but even if it did, I doubt that it would have been cheaper than buying the Xilinx software. I don't want to leave the impression that I'm still torqued at Xilinx, in fact, to the contrary, they seem to be making all the right noises. A Xilinx FAE is coming to see me next week, and I'm going to go ahead and order the tools that I need. It's just a shame the $100 package wasn't around back in 1988. -- Gary Watson gary@nexsan.sex (Change dot sex to dot com to reply!!!) Nexsan Technologies Ltd. Derby DE21 7BF ENGLAND http://www.nexsan.com
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