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
rickman wrote: > People say that strong typing catches bugs, but I've never seen any > real proof of that. There are all sorts of anecdotal evidence, but > nothing concrete. My practical experience is that strong typing creates another class of bugs, simply by making things more complicated. I've last seen VHDL in use more than 10 years ago, but the typical pattern was that a designer wanted a bit vector, and created a subranged integer instead. Seems to be identical, but isn't. If you increment the subranged integer, it will stop simulation on overflow, if you increment the bit vector, it will wrap around. My coworker who did this subranged integer stuff quite a lot ended up with code like if foo = 15 then foo <= 0 else foo <= foo + 1 endif; And certainly, all those lines had started out as foo <= foo + 1; and were only "fixed" later when the simulation crashed. The good news is that the synthesis tool really generates the bitvector logic for both, so all those simulator crashes were only false alarms. -- Bernd Paysan "If you want it done right, you have to do it yourself!" http://www.jwdt.com/~paysan/Article: 147176
On Apr 15, 5:48=A0pm, Patrick Maupin <pmau...@gmail.com> wrote: > On Apr 15, 4:31=A0pm, Muzaffer Kal <k...@dspia.com> wrote: > > > > > On Thu, 15 Apr 2010 14:21:37 -0700 (PDT), Patrick Maupin > > > <pmau...@gmail.com> wrote: > > >On Apr 15, 3:12=A0pm, David Brown <da...@westcontrol.removethisbit.com= > > > >wrote: > > > >> Another famous contest involved a C and Ada comparison. =A0It took t= he Ada > > >> more than twice as long as the C team to write their code, but it to= ok > > >> the C team more than ten times as long to debug their code. > > > >Well, this isn't at all the same then. =A0The Verilog teams got workin= g > > >designs, and the VHDL teams didn't. > > > There are two issues to consider. One is the relative times of writing > > the codes vs debugging ie if writing took 5 hours and debugging 10 > > minutes (unlikely) then C still wins. Which brings the second issue: > > it is very likely that the programming contest involved a "larger" > > design to be finished. If I am remembering correctly RTL was =A0an asyn= c > > reset, synchronously loadable up-down counter which is a "smallish" > > project. If programming contest involved something more "involved" it > > still points to the benefit of strong typing and other features of > > Ada/VHDL etc. > > But it's mostly academic and FPGA people who think that VHDL might > have any future at all. =A0See, for example: > > http://www.eetimes.com/news/design/columns/industry_gadfly/showArticl... > > Regards, > Pat Hmmm... The date on that article is 04/07/2003 11:28 AM EDT. Seven years later I still don't see any sign that VHDL is going away... or did I miss something? RickArticle: 147177
In comp.arch.fpga rickman <gnuarm@gmail.com> wrote: (snip, I wrote) >> Seatbelts may save lives, but statistically many other safety >> improvements don't. ?When people know that their car has air bags, >> they compensate and drive less safely. ?(Corner a little faster, etc.) >> Enough to mostly remove the life saving effect of the air bags. > Are you making this up? I have never heard that any of the other > added safety features don't save lives overall. I have heard that > driving a sportier car does allow you to drive more aggressively, but > this is likely not actually the result of any real analysis, but just > an urban myth. Where did you hear that air bags don't save lives > after considering all? I believe that they still do save lives, but by a smaller factor than one might expect. I believe the one that I saw was not quoting air bags, but anti-lock brakes. The case for air bags was mentioned by someone else -- that some believe that they don't need seat belts if they have air bags. Without seat belts, though, you can be too close to the air bag when it deploys, and get hurt by the air bag itself. For that reason, they now use slower air bags than they used to. The action of anti-lock breaks has a more immediate feel while driving, and it seems likely that many will take that into account while driving. I believe that there is still a net gain, but much smaller than would be expected. -- glenArticle: 147178
On Apr 16, 5:38=A0am, David Brown <da...@westcontrol.removethisbit.com> wrote: > Secondly, a testbench does not check everything. =A0It is only as good as > the work put into it, and can be flawed in the same way as the code > itself. =A0 I was listening to a lecture by a college once who indicated that you don't need to use static timing analysis since you can use a timing based simulation! I queried him on this a bit and he seemed to think that you just needed to have a "good enough" test bench. I was incredulous about this for a long time. Now I realize he was just a moron^H^H^H^H^H^H^H ill informed! RickArticle: 147179
In comp.arch.fpga rickman <gnuarm@gmail.com> wrote: (snip) > I was listening to a lecture by a college once who indicated that you > don't need to use static timing analysis since you can use a timing > based simulation! I queried him on this a bit and he seemed to think > that you just needed to have a "good enough" test bench. I was > incredulous about this for a long time. Now I realize he was just a > moron^H^H^H^H^H^H^H ill informed! I suppose so, but consider it the other way around. If your test bench is good enough then it will catch all static timing failures (eventually). With static timing analysis, there are many things that you don't need to check with the test bench. Also, you can't do static timing analysis on the implemented logic. (That is, given an actual built circuit and a logic analyzer.) Now, setup and hold violations are easy to test with static analysis, but much harder to check in actual logic. Among others, you would want to check all possible clock skew failures, which is normally not possible. With the right test bench and logic implementation (including programmable delays on each FF clock) it might be possible, though. -- glenArticle: 147180
Andy wrote: > IMHO, they missed the point. Any design that can be completed in a > couple of hours will necessarily favor the language with the least > overhead. Unfortunately, two-hour-solvable designs are not > representative of real life designs, and neither was the contest's > declared winner. Well, we pretty much know that the number of errors people make in programming languages basically depends on how much code they have to write - a language which has less overhead and is more terse is being written faster and has less bugs. And it goes non-linear, i.e. a program with 10k lines of code will have less bugs per 1000 lines than a program with 100k lines of code. So the larger the project, the better the more terse language is. -- Bernd Paysan "If you want it done right, you have to do it yourself!" http://www.jwdt.com/~paysan/Article: 147181
Hi all, Is there anyway to modify bit file just to change I/O slew rate & drive strength without re-run ISE processes ? TIA & TGIFArticle: 147182
On Apr 16, 3:16=A0pm, Mawa_fugo <cco...@netscape.net> wrote: > Hi all, > Is there anyway to modify bit file just to change I/O slew rate & > drive strength without re-run ISE processes ? > > TIA & TGIF The easiest way is to use the FPGA editor to modify the settings (find your IOB in the "components" list and then use "editblock"). Then save the file and just re-run bitgen. Regards, GaborArticle: 147183
On Apr 16, 12:58=A0pm, rickman <gnu...@gmail.com> wrote: > That is certainly a great way to prove a theory. =A0Toss out every data > point that disagrees with your theory! Well, I don't really need others to agree with my theory, so if that's how it's viewed, so be it. Nonetheless, I view it as tossing out data that was taken under different conditions than the ones I live under. Although the basics don't change (C, C++, Java, Verilog, VHDL are all turing-complete, as are my workstation and the embedded systems I sometimes program on), the details can make things qualitatively enough different that they actually appear to be quantatively different. It's like quantum mechanics vs. Newtonian physics. For example, on my desktop, if I'm solving an engineering problem, I might throw Python and numpy, or matlab, and gobs of RAM and CPU at it. On a 20 MIPS, fixed point, low-precision embedded system with a total of 128K memory, I don't handle the problem the same way. I find the same with language differences. I assumed your complaint when you started this thread was that a particular language was *forcing* you into a paradigm you felt might be sub-optimal. My opinion is that, even when languages don't *force* you into a particular paradigm, there is an impedance match between coding style and language that you ignore at the peril of your own frustration. So when somebody says " I don't change the way I code when I code in Verilog vs. VHDL or C vs. Java, the compiler just does a better job of catching my stupid mistakes, allowing me to get things done faster." I just can't even *relate* to that viewpoint. It is that of an alien from a different universe, so has no bearing on my day to day existence. Regards, PatArticle: 147184
On Apr 16, 1:25=A0pm, rickman <gnu...@gmail.com> wrote: > Hmmm... =A0The date on that article is 04/07/2003 11:28 AM EDT. =A0Seven > years later I still don't see any sign that VHDL is going away... or > did I miss something? True, but you also have to remember in the early 90s that all the industry pundits thought verilog was dead...Article: 147185
glen herrmannsfeldt wrote: > If your test bench is good enough then it will catch all static > timing failures (eventually). With static timing analysis, there > are many things that you don't need to check with the test bench. And then there are some corner cases where neither static timing analysis nor digital simulation helps - like signals crossing asynchronous clock boundaries (there *will* be a setup or hold violation, but a robust clock boundary crossing circuit will work in practice). Example: We had a counter running on a different clock (actually a VCO, where the voltage was an analog input), and to sample it robust in the normal digital clock domain, I grey-encoded it. There will be one bit which is either this or that when sampling at a setup or hold violation condition, but this is only just one bit, and it's either in the state before the increment or after. -- Bernd Paysan "If you want it done right, you have to do it yourself!" http://www.jwdt.com/~paysan/Article: 147186
> For example, with MyHDL you will also have to learn about latch > inference and how to avoid "unwanted latches". However, just like in > VHDL/Verilog there is a much better solution for this than using a > limited HDL: use a clocked process template by default. > I don't agree with this. Why provide such a general framework when all you really want is the "clocked process" anyway. VHDL, Verilog and MyHDL all let you make the same mistake over and over again. Cheers, AndyArticle: 147187
On 17 Apr, 04:40, "evilkid...@googlemail.com" <evilkid...@googlemail.com> wrote: > > For example, with MyHDL you will also have to learn about latch > > inference and how to avoid "unwanted latches". However, just like in > > VHDL/Verilog there is a much better solution for this than using a > > limited HDL: use a clocked process template by default. > > I don't agree with this. =A0Why provide such a general framework when > all you really want is the "clocked process" anyway. =A0VHDL, Verilog > and MyHDL all let you make the same mistake over and over again. AFAIK, to avoid latch inference you need a non-sequential language, and most don't want that.Article: 147188
On Apr 17, 5:40=A0am, "evilkid...@googlemail.com" <evilkid...@googlemail.com> wrote: > > For example, with MyHDL you will also have to learn about latch > > inference and how to avoid "unwanted latches". However, just like in > > VHDL/Verilog there is a much better solution for this than using a > > limited HDL: use a clocked process template by default. > > I don't agree with this. =A0Why provide such a general framework when > all you really want is the "clocked process" anyway. =A0VHDL, Verilog > and MyHDL all let you make the same mistake over and over again. The context of the "clocked process" paradigm is synthesizable RTL code. For many engineers working on complex projects, writing such code is only a fraction of their work. For high-level modeling and verification, you can use the power of the language in its full generality. For powerful HDLs such as VHDL/Verilog/MyHDL, the synthesis coding constraints are imposed by synthesis technology, not by the language. It is easy to design a "fully synthesizable" HDL that incorporates such constraints in the language definition itself. It just seems that the market doesn't want those. I certainly don't. You are of course free to ignore that observation. Jan P.S not all latches are "unwanted" :-)Article: 147189
On Apr 16, 2:45=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > In comp.arch.fpga rickman <gnu...@gmail.com> wrote: > (snip) > > > I was listening to a lecture by a college once who indicated that you > > don't need to use static timing analysis since you can use a timing > > based simulation! =A0I queried him on this a bit and he seemed to think > > that you just needed to have a "good enough" test bench. =A0I was > > incredulous about this for a long time. =A0Now I realize he was just a > > moron^H^H^H^H^H^H^H ill informed! > > I suppose so, but consider it the other way around. > > If your test bench is good enough then it will catch all static > timing failures (eventually). =A0With static timing analysis, there > are many things that you don't need to check with the test bench. I don't follow what you are saying. This first sentence seems to be saying that a timing simulation *is* a good place to find timing problems, or are you talking about real world test benches? The point is that static timing is enough to catch all timing failures given that your timing constraints cover the design properly... and I agree that is a big given. Your second sentence seems to be agreeing with my previous statement. > Also, you can't do static timing analysis on the implemented logic. > (That is, given an actual built circuit and a logic analyzer.) So? > Now, setup and hold violations are easy to test with static > analysis, but much harder to check in actual logic. =A0Among others, > you would want to check all possible clock skew failures, which is > normally not possible. =A0With the right test bench and logic > implementation (including programmable delays on each FF clock) > it might be possible, though. In twenty years of designing with FPGAs I have never found a clock skew problem. I always write my code to allow the clock trees to deliver the clocks and I believe the tools guaranty that there will not be a skew problem. Static timing actually does cover clock skew, at least the tools I use. BTW, how do you design a "right test bench"? Static timing analysis will at least give you the coverage level although one of my complaints is that they don't provide any tools for analyzing if your constraints are correct. But I have no idea how to verify that my test bench is testing the timing adequately. RickArticle: 147190
I am trying to integrate my own DDR2 controller into a Microblaze processor. I have created a board support package file with the ports defined and have added an IOTYPE attribute of XIL_MEMORY_V1. However when I run the bsb it thinks that I want to use the Xilinx MPMC. Maybe I shouldnt be adding this attribute, but I need EDK to know that this is a memory controller so that it will let me change the memory type in the generate linker script dialog. Thanks Jon --------------------------------------- Posted through http://www.FPGARelated.comArticle: 147191
On Apr 17, 2:21=A0am, Paul <pault...@googlemail.com> wrote: > On 17 Apr, 04:40, "evilkid...@googlemail.com" > > <evilkid...@googlemail.com> wrote: > > > For example, with MyHDL you will also have to learn about latch > > > inference and how to avoid "unwanted latches". However, just like in > > > VHDL/Verilog there is a much better solution for this than using a > > > limited HDL: use a clocked process template by default. > > > I don't agree with this. =A0Why provide such a general framework when > > all you really want is the "clocked process" anyway. =A0VHDL, Verilog > > and MyHDL all let you make the same mistake over and over again. > > AFAIK, to avoid latch inference you need a non-sequential language, > and most don't want that. I'm not clear on what either of you are saying. I don't seem to have a problem with latch inferrence mainly because I know what causes inferred latches. It has nothing to do with sequential or non- sequential languages. VHDL has non-sequential capabilities and I can infer a latch using that. a <=3D b when (c =3D '1'); -- use "c" as a latch enable What am I missing? RickArticle: 147192
On Apr 16, 4:32=A0pm, Gabor <ga...@alacron.com> wrote: > On Apr 16, 3:16=A0pm, Mawa_fugo <cco...@netscape.net> wrote: > > > Hi all, > > Is there anyway to modify bit file just to change I/O slew rate & > > drive strength without re-run ISE processes ? > > > TIA & TGIF > > The easiest way is to use the FPGA editor to modify the > settings (find your IOB in the "components" list and > then use "editblock"). =A0Then save the file and just > re-run bitgen. > > Regards, > Gabor I have done this when I needed a quick and dirty change to a file rather than to rerun the entire synthesis. In fact, I needed a series of variations because I couldn't get Lattice to tell me what the rise time specs of their parts are. They just kept saying it depends on the state of the rest of the universe. Certainly they could have picked a state and spec'd the values the same way other logic parts do. I just wanted to get a feel for how the rise time varies with the two output controls, FAST/SLOW and drive current. Turns out it is not as you might expect. RickArticle: 147193
My customer was talking about running PC Linux on a CPU in an FPGA. I believe the one big requirement is that there has to be a MMU. Which of the three FPGA vendor's cores are available with a Linux supported MMU? I cores I know about from vendors are uBlaze, NIOS and LM32. I don't think Actel has one, they seem to be using ARM. Then of course there are the gazillion open source cores at all levels of functioning and support, everything from commercial grade to "What, me worry?" Which of these are practical for a commercial project? RickArticle: 147194
rickman wrote: > My customer was talking about running PC Linux on a CPU in an FPGA. I > believe the one big requirement is that there has to be a MMU. Which > of the three FPGA vendor's cores are available with a Linux supported > MMU? I cores I know about from vendors are uBlaze, NIOS and LM32. I > don't think Actel has one, they seem to be using ARM. Then of course > there are the gazillion open source cores at all levels of functioning > and support, everything from commercial grade to "What, me worry?" > > Which of these are practical for a commercial project? AFAIK, MICO32 seems to work (Seb bourdeauduc could confirm) but he has switched to another Xilinx-hosted core clone that is a bit faster for his taste (IIRC), still with Linux. OTOH, it's not clear : does you client want a PC or Linux ? because there are (quite) cheap embedded x86 modules around. I use to play with ETX and PC104, there are new and even smaller full-featured modules from several manufacturers (like Qseven form factor, ask me so I send you pictures of the real stuff) don't waste a FPGA and your time for Linux. Use existing standard plugable modules... > Rick yg -- http://ygdes.com / http://yasep.orgArticle: 147195
On Apr 17, 9:58=A0am, rickman <gnu...@gmail.com> wrote: > My customer was talking about running PC Linux on a CPU in an FPGA. =A0I > believe the one big requirement is that there has to be a MMU. =A0Which > of the three FPGA vendor's cores are available with a Linux supported > MMU? =A0I cores I know about from vendors are uBlaze, NIOS and LM32. =A0I > don't think Actel has one, they seem to be using ARM. =A0Then of course > there are the gazillion open source cores at all levels of functioning > and support, everything from commercial grade to "What, me worry?" > > Which of these are practical for a commercial project? > > Rick Hello Rick, Starting with version 7, the MicroBlaze processor can have an MMU included. Prior to that, you could use the uC version of Linux, which is designed for processors without an MMU. That support has been merged into the 2.6.? version of the kernel. Take a look at http://www.petalogix.com/ for more information about a supported distribution of Linux for the MicroBlaze. Regards, John McCaskill www.FasterTechnology.comArticle: 147196
On Apr 17, 9:48=A0am, "maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> wrote: > I am trying to integrate my own DDR2 controller into a Microblaze > processor. I have created a board support package file with the ports > defined and have added an IOTYPE attribute of XIL_MEMORY_V1. However when= I > run the bsb it thinks that I want to use the Xilinx MPMC. Maybe I shouldn= t > be adding this attribute, but I need EDK to know that this is a memory > controller so that it will let me change the memory type in the generate > linker script dialog. > > Thanks > > Jon =A0 =A0 =A0 =A0 > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com You do not need to specify the IOTYPE as XIL_MEMORY_V1. I set it to something else in our XBD file. In the MPD file for your memory controller, you want to add: OPTION IP_GROUP =3D Memory Controller See psf_rm.pdf in the doc directory of the EDK install for more information on its syntax. Regards, John McCaskill www.FasterTechnology.comArticle: 147197
rickman wrote: > My customer was talking about running PC Linux on a CPU in an FPGA. I > believe the one big requirement is that there has to be a MMU. Which > of the three FPGA vendor's cores are available with a Linux supported > MMU? I cores I know about from vendors are uBlaze, NIOS and LM32. I > don't think Actel has one, they seem to be using ARM. Then of course > there are the gazillion open source cores at all levels of functioning > and support, everything from commercial grade to "What, me worry?" > > Which of these are practical for a commercial project? > > Rick Hi, Altera do have a demo of linux on Nios on the NEEK kit, it includes a an LCD display and other peripherals.Article: 147198
Thanks John that worked although I had to add ADDR_TYPE = MEMORY to the C_BASEADDR and C_HIGHADDR parameters. Jon --------------------------------------- Posted through http://www.FPGARelated.comArticle: 147199
In comp.arch.fpga rickman <gnuarm@gmail.com> wrote: (snip on test benches) >> I suppose so, but consider it the other way around. >> If your test bench is good enough then it will catch all static >> timing failures (eventually). ?With static timing analysis, there >> are many things that you don't need to check with the test bench. > I don't follow what you are saying. This first sentence seems to be > saying that a timing simulation *is* a good place to find timing > problems, or are you talking about real world test benches? The point > is that static timing is enough to catch all timing failures given > that your timing constraints cover the design properly... and I agree > that is a big given. Your second sentence seems to be agreeing with > my previous statement. Yes, I was describing real world (hardware) test benches. Depending on how close you are to a setup/hold violation, it may take a long time for a failure to actually occur. >> Also, you can't do static timing analysis on the implemented logic. >> (That is, given an actual built circuit and a logic analyzer.) > So? >> Now, setup and hold violations are easy to test with static >> analysis, but much harder to check in actual logic. ?Among others, >> you would want to check all possible clock skew failures, which is >> normally not possible. ?With the right test bench and logic >> implementation (including programmable delays on each FF clock) >> it might be possible, though. > In twenty years of designing with FPGAs I have never found a clock > skew problem. I always write my code to allow the clock trees to > deliver the clocks and I believe the tools guaranty that there will > not be a skew problem. Static timing actually does cover clock skew, > at least the tools I use. Yes, I was trying to cover the case of not using static timing analysis but only testing actual hardware. For ASICs, it is usually necessary to test the actual chips, though they should have already passed static timing. > BTW, how do you design a "right test bench"? Static timing analysis > will at least give you the coverage level although one of my > complaints is that they don't provide any tools for analyzing if your > constraints are correct. But I have no idea how to verify that my > test bench is testing the timing adequately. If you only have one clock, it isn't so hard. As you add more, with different frequencies and/or phases, it gets much harder, I agree. It would be nice to get as much help as possible from the tools. -- glen
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