Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
In comp.arch.fpga rickman <gnuarm@gmail.com> wrote: (snip) > Without starting a major argument, anyone care to share their feelings > on the differences in the two languages? I started with verilog, as that is what others I was working with were doing, and was also told that it was a better choice for previous C programmers. (Not that I believe that HDL should be related to a software language.) At some point, I learned to read VHDL, at least enough to convert an module to verilog when needed, or to understand why something didn't work the way I thought it should. (I had one project with schematic capture, VHDL, and AHDL, and then I started adding verilog to it.) It seems to me that verilog, similar to C, gets the ideas across without being excessively wordy. In comparison to some other languages, I find the convenience in C of converting between char and int without the need for any special conversion operation (such as the Fortran CHAR function) convenient. Well, I write my verilog mostly using continuous assignment, with a fairly small amount of behavioral verilog. For those who prefer behavioral coding, the recommendation might be different. -- glenArticle: 147026
On Apr 9, 3:07=A0pm, rickman <gnu...@gmail.com> wrote: > I think I have about had it with VHDL. =A0I've been using the > numeric_std library and eventually learned how to get around the > issues created by strong typing although it can be very arcane at > times. =A0I have read about a few suggestions people are making to help > with some aspects of the language, like a selection operator like > Verilog has. =A0But it just seems like I am always fighting some aspect > of the VHDL language. > > I guess part of my frustration is that I have yet to see where strong > typing has made a real difference in my work... at least an > improvement. I think Andy has it about right. If you think signed arithmetic was a tad messy in VHDL, wait until you find how successfully you can be screwed by Verilog. The really cool thing is that Verilog is polite, and doesn't tell you when it's screwing you. At least VHDL is up-front about it. How many times have you created a design in VHDL that got through compilation, but was broken in a surprising way that was directly related to a quirk of the language? Betcha you can count the occurrences on one hand. Verilog does that to you all the time; it has startlingly weak compile-time checking, and only slightly stronger elaboration-time checking. How comfortable are you with most-significant bits being silently lost when you copy a wide vector into a narrow one? How about signed values being silently zero-filled to the width of a wider target? >=A0My customer uses Verilog and has mentioned several times > how he had tried using VHDL and found it too arcane to bother with. > He works on a much more practical level than I often do and it seems > to work well for him. Is "practical" here a euphemism? > One of my goals over the summer is to teach myself Verilog so that I > can use it as well as I currently use VHDL. =A0Then I can make a fully > informed decision about which I will continue to use. =A0I'd appreciate > pointers on good references, web or printed. Good luck. As I've pointed out on many occasions, the textbook situation is much less satisfactory for Verilog than it is for VHDL. Whatever you do, PLEASE get yourself a copy of Sutherland's Verilog Gotchas book (much of it is available free online). You may not understand all of it at first, but you sure will want to revisit it later. It's just a pity that it's incomplete and doesn't cover ALL the many ways in which Verilog can silently mess you up. To be serious for a moment: a training class from a reputable independent provider will save you a ton of money in the long run. Your time is valuable. > Without starting a major argument, anyone care to share their feelings > on the differences in the two languages? Errrrm, I think I just did. -- Jonathan BromleyArticle: 147027
rickman <gnuarm@gmail.com> wrote: >I think I have about had it with VHDL. I've been using the >numeric_std library and eventually learned how to get around the >issues created by strong typing although it can be very arcane at >times. I have read about a few suggestions people are making to help >with some aspects of the language, like a selection operator like >Verilog has. But it just seems like I am always fighting some aspect >of the VHDL language. > >I guess part of my frustration is that I have yet to see where strong >typing has made a real difference in my work... at least an I also write a lot of C. Over the past years I've noticed that C compilers (GCC to be exact) have become much more strict when it comes to type checking. No more automatic casting. I'm sure this is done for a good reason! -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 147028
On Apr 9, 2:07=A0pm, Jonathan Bromley <s...@oxfordbromley.plus.com> wrote: > > I guess part of my frustration is that I have yet to see where strong > > typing has made a real difference in my work... at least an > > improvement. > > I think Andy has it about right. =A0If you think signed arithmetic > was a tad messy in VHDL, wait until you find how successfully you > can be screwed by Verilog. =A0The really cool thing is that Verilog > is polite, and doesn't tell you when it's screwing you. =A0At least > VHDL is up-front about it. =A0How many times have you created a > design in VHDL that got through compilation, but was broken in > a surprising way that was directly related to a quirk of the > language? =A0Betcha you can count the occurrences on one hand. > Verilog does that to you all the time; it has startlingly > weak compile-time checking, and only slightly stronger > elaboration-time checking. > > How comfortable are you with most-significant bits being > silently lost when you copy a wide vector into a narrow > one? =A0How about signed values being silently zero-filled > to the width of a wider target? Personally? Very. As the proponents of agile programming languages (I love Python) will point out, the sort of typing errors that you are describing are but a small subset of the ways you can screw up your design. Any reasonable testbench will find these issues. And BTW, (IMO) it's *much* easier to code a reasonable testbench in verilog than in VHDL. But, obviously, your mileage varies. Regards, PatArticle: 147029
On Apr 9, 2:31=A0pm, n...@puntnl.niks (Nico Coesel) wrote: > I also write a lot of C. Over the past years I've noticed that C > compilers (GCC to be exact) have become much more strict when it comes > to type checking. No more automatic casting. I'm sure this is done for > a good reason! I used to write a lot of Modula-2. It was much better than (pre-ANSI) C (and in fact was one of the contenders for the language the DOD uses as ADA now, which is what VHDL was based on). IMO, Modula-2 was at a sweet spot on verbosity vs. checking. But then ANSI C came along, and was "good enough". Combine that with the compilers getting smart enough to let you know about potential pitfalls, and there wasn't much room for another language in the ecological niche that C fills, and, for example, the Modula-2 ecosystem dwindled to nothing, and the Ada ecosystem limped along, primarily propped up by the DOD and educational institutions. I think there really is a good corollary with HDLs there -- Verilog synthesizers and simulators have a lot of options for telling you about warnings and things, and Verilog occupies the same sort of sweet spot as C, with only a few people preferring Ada or VHDL over C or Verilog. Regards, PatArticle: 147030
On Apr 9, 6:51=A0am, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > On Apr 7, 6:50=A0pm, Yan <yan.li...@gmail.com> wrote: > > > > > On Mar 31, 10:04=A0am, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > > > > On Mar 31, 1:51=A0am, luudee <rudolf.usselm...@gmail.com> wrote: > > > > > Does anybody else, besides xilinx, make FMC boards for ml605 & sp60= 5 ? > > > > > HW-FMC-XM105-G =A0FMC XM105 DEBUG CARD > > > > HW-FMC-XM104-G =A0FMC CONNECTIVITY MEZZANINE CARD > > > > > Buying Xilinx products now means going through Avnet, which is a > > > > nightmare and HUGE lead times ... > > > > > Thanks, > > > > rudi > > > > While the XM104 is listed with a 8 week lead time on the Avnet site, = I > > > know that we have these available in inventory and they will ship > > > promptly after the order is placed. =A0The XM105 is listed with a 2 w= eek > > > lead time. > > > > There are a number of other companies releasing FMC cards, just be > > > sure that the cards support a VADJ of 2.5V and there shouldn't be a > > > problem. > > > > 4DSP recently announced a FMC familyhttp://www.przoom.com/news/66794/ > > > > Curtiss-Wright also has a number of boards.http://www.cwcembedded.com= /0/62/651.html > > > > And Xilinx has a number of other boards in pipeline to be released > > > next quarter.http://www.xilinx.com/fmc > > > > Ed McGettigan > > > -- > > > Xilinx Inc. > > > Ed, > > > I just board a ML605 kit and is shopping FMC daughter board. I > > understand that Xilinx worked with Analog Device on a multi-mode radio > > demo platform. Analog Devices provided a RF board called Mixed Signal > > Digital Pre-Distortion (MSDPD) board. I wonder if that board is > > available for purchase. I got the information from: > > >http://www.xilinx.com/publications/prod_mktg/Radio-TDP-SellSheet.pdf Many thanks. > > > Yan- Hide quoted text - > > > - Show quoted text - > > This FMC board was developed by Analog Devices and while I had some > involvement in the initial design phase I'm not sure what the go-to- > market strategy was for the board. =A0I would suggest that you use the > "Contact Wireless" team link on this page to get further information > on availability.http://www.xilinx.com/esp/wireless.htm > > Ed McGettigan > -- > Xilinx Inc.Article: 147031
Hello, We are trying to determine the number of slices that a specific module in the design consumes upon synthesis. Is there a way to generate a report that shows resource utilization per module using Xilinx ISE Webpack v11.5 ? Thanks and Regards, Vikram. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 147032
RK, >By having a synthesize-time flag, one could create two different >codes, and "if-def" according to which version of XST is being used. > >eg: > >`ifdef L.70 // this is 11.5 >foo <=3D ~bar; >`else >foo <=3D !bar; >`endif Thank you for your response. Your understanding of our requirement is correct. What is L.70 ? Is it something that is predefined in ISE to indicate XST v11.5 ? Thanks and Regards, Vikram. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 147033
Hi, I am working on moving an ASIC design to FPGA. For this i am using synplify pro synthesis tool. But, the tool does not seem to recognise all the gated clocks [sometimes because it cant recognise the base clock]. is there any alternative method to declare the base clock for the gated design other than using the create_clock contraint in the sdc file. Thanks in advance vdt153Article: 147034
On Apr 9, 6:57=A0pm, "vragukumar" <vragukumar@n_o_s_p_a_m.n_o_s_p_a_m.signalogic.com> wrote: > Hello, > > We are trying to determine the number of slices that a specific module in > the design consumes upon synthesis. Is there a way to generate a report > that shows resource utilization per module using Xilinx ISE Webpack v11.5 > ? > > Thanks and Regards, > Vikram. =A0 =A0 > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com The synthesis log/report file should contain the amount of LUT, Registers, RAM and IO were used. The number of slices that this will ultimately be used is very dependent on the entire design, the utilization of the device and mapping options. Ed McGettigan -- Xilinx Inc.Article: 147035
On Apr 10, 2:07=A0am, rickman <gnu...@gmail.com> wrote: > One of my goals over the summer is to teach myself Verilog so that I > can use it as well as I currently use VHDL. =A0Then I can make a fully > informed decision about which I will continue to use. =A0I'd appreciate > pointers on good references, web or printed. You could also look at Jan Decaluwe's MyHDL ? http://www.myhdl.org/doku.php and a case example here : http://www.jandecaluwe.com/hdldesign/digmac.html this allows you to go in either direction, to VHDL to Verilog, and to 'test early'. -jgArticle: 147036
On Apr 9, 10:05=A0pm, Patrick Maupin <pmau...@gmail.com> wrote: > On Apr 9, 2:07=A0pm, Jonathan Bromley <s...@oxfordbromley.plus.com> > wrote: > > > > > > I guess part of my frustration is that I have yet to see where strong > > > typing has made a real difference in my work... at least an > > > improvement. > > > I think Andy has it about right. =A0If you think signed arithmetic > > was a tad messy in VHDL, wait until you find how successfully you > > can be screwed by Verilog. =A0The really cool thing is that Verilog > > is polite, and doesn't tell you when it's screwing you. =A0At least > > VHDL is up-front about it. =A0How many times have you created a > > design in VHDL that got through compilation, but was broken in > > a surprising way that was directly related to a quirk of the > > language? =A0Betcha you can count the occurrences on one hand. > > Verilog does that to you all the time; it has startlingly > > weak compile-time checking, and only slightly stronger > > elaboration-time checking. > > > How comfortable are you with most-significant bits being > > silently lost when you copy a wide vector into a narrow > > one? =A0How about signed values being silently zero-filled > > to the width of a wider target? > > Personally? =A0Very. > > As the proponents of agile programming languages (I love Python) will > point out, the sort of typing errors that you are describing are but a > small subset of the ways you can screw up your design. =A0Any reasonable > testbench will find these issues. I believe you are mixing up dynamic typing (Python) with weak typing (Verilog). Python is dynamically but strongly typed. The silent Verilog-like behavior as Jonathan was describing is extremely un-pythonic. In Python, you would get a traceback immediately. Jan -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com Analog design automation: http://www.mephisto-da.com World-class digital design: http://www.easics.comArticle: 147037
On Apr 9, 6:53=A0pm, Patrick Maupin <pmau...@gmail.com> wrote: > On Apr 9, 9:07=A0am, rickman <gnu...@gmail.com> wrote: > > > > > I think I have about had it with VHDL. =A0I've been using the > > numeric_std library and eventually learned how to get around the > > issues created by strong typing although it can be very arcane at > > times. =A0I have read about a few suggestions people are making to help > > with some aspects of the language, like a selection operator like > > Verilog has. =A0But it just seems like I am always fighting some aspect > > of the VHDL language. > > > I guess part of my frustration is that I have yet to see where strong > > typing has made a real difference in my work... at least an > > improvement. =A0My customer uses Verilog and has mentioned several time= s > > how he had tried using VHDL and found it too arcane to bother with. > > He works on a much more practical level than I often do and it seems > > to work well for him. > > > One of my goals over the summer is to teach myself Verilog so that I > > can use it as well as I currently use VHDL. =A0Then I can make a fully > > informed decision about which I will continue to use. =A0I'd appreciate > > pointers on good references, web or printed. > > > Without starting a major argument, anyone care to share their feelings > > on the differences in the two languages? > > > Rick > > The best online references are the Sutherland Verilog references. > There is an online HTML reference for Verilog 95 (excellent), and a > PDF for Verilog 2001 (good): > > http://www.sutherland-hdl.com/online_verilog_ref_guide/vlog_ref_top.htmlh= ttp://sutherland-hdl.com/online_verilog_ref_guide/verilog_2001_ref_g... > > Cliff Cummings has a lot of good papers on Verilog at his site: > > http://sunburst-design.com/papers/ > > In particular, if you read and carefully grok his paper about non- > blocking vs. blocking assignments, you will be well on your way to > being a Verilog wizard: > > http://sunburst-design.com/papers/CummingsSNUG2000SJ_NBA.pdf The infamous Guideline #5 bans variable semantics from always blocks with sequential logic. It must be the Worst Guideline ever for RTL designers. The result is not wizardry but ignorance. How are we supposed to "raise the abstraction level" if Verilog RTL designers can't even use variables? Jan -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com Analog design automation: http://www.mephisto-da.com World-class digital design: http://www.easics.comArticle: 147038
Why do people keep comparing the checking that is inherent in VHDL with what is done in Verilog? There is a whole class of tools called rtl checkers that are designed to catch these language gotches before you run simulation. Yes there are lots of ways to make mistakes in verilog. That simply means that you need to add a tool that can catch them. John --------------------------------------- Posted through http://www.FPGARelated.comArticle: 147039
On Apr 10, 8:04=A0pm, Jan Decaluwe <jandecal...@gmail.com> wrote: > > As the proponents of agile programming languages (I love Python) will > > point out, the sort of typing errors that you are describing are but a > > small subset of the ways you can screw up your design. =A0Any reasonabl= e > > testbench will find these issues. > > I believe you are mixing up dynamic typing (Python) with > weak typing (Verilog). No, not at all. Sure, Python will give you an error, if, for example, you add an int to a string: >>> 1 + '1' Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: unsupported operand type(s) for +: 'int' and 'str' But, Python will quite happily let you add an int to a float: >>> 1 + 1.0 2.0 And, of course, it has no concept of unsigned numbers, etc. Now, you can use some modules that know about a few of these things, like the array module. Also, Verilog understands a few things about its types, such as the fact that you can't do a continuous assignment to a register, for example. SO, while in principle I *agree* that Python is "dynamically" typed instead of "weakly" typed, that doesn't alter the fact that in Python I can bind anything to any identifier. >>> x =3D 'a' >>> x =3D 1 >>> x =3D 2.0 Oh, sure I can build my own objects to restrict this, but people who do that are usually called "static typing weenies" by the Python community. So, no, I don't think I'm confused at all (I can't speak for my readers; I often leave those confused, I'm sure) and I stand by my assertion that one of the key principles of programming in Python is that typing errors are typically the least of the possible errors in a real program. Regards, PatArticle: 147040
d_s_klein <d_s_klein@yahoo.com> writes: > It's part of Altera's 'check for updates'. > > Just install rpm and be done with it; that's what I did. Isn't it easier to just symlink rpm to /bin/true?Article: 147041
Gabor wrote: > On Apr 9, 11:45 am, "Fredxx" <fre...@spam.com> wrote: >> "austin" <aus...@xilinx.com> wrote in message >> >> news:fc92c4bb-3a00-4990-b2f5-3767c15c41c9@x20g2000yqb.googlegroups.com... >> >> >> >>> f, >> >>> This is your lucky day: >> >>> Go read my new blog post: >> >>> http://forums.xilinx.com/t5/PLD-Blog/Timing-Constraints-Part-4-of-5/b... >> >>> where TIG is discussed, and an example given how it can be used in a >>> FROM-TO. >> >>> Since this design is completely synchronous to the 25 MHz clock, if >>> properly constrained (and designed) there will be metastability >>> issues at all. >> >>> Your Gray code and synchronizers may not be necessary at all. >>> However, if you don't have the time (or knowledge) to do this >>> properly, then having a two clocks that are almost (but not quite) >>> synchronous can be a nightmare, and no amount of Gary coded >>> counters, nor synchronizers will save you: you will be "almost >>> always at the wrong point" so frequently that you have created the >>> perfect storm for looking at metastable events. >> >>> The built in BRAM FIFO in V5 and V6 is the obvious solution to cross >>> boundaries, or the use of a FIFO from the core generator, is >>> suggested: do not try to spin your own solution unless you are an >>> expert in clock domain crossing -- this is not for "newbies" to try >>> (unless they are trying to develop the skills to do it right). >> >>> You would be better off using the 125 MHz clock domain everywhere, >>> and creating a clock enable that disables one 125 clock out of >>> every five 125 clocks (for the 100 MHz domain processing). Then you >>> will have no need to cross any clock boundaries, the design is >>> simpler, more robust, and will likely just work. >> >>> If you then need to transfer data out at 100 MHz, that is where the >>> FIFO is best used: once, at this boundary. The same is not true for >>> transferring 100 MHz data into the 125 MHz domain, that is >>> accomplished by just sampling at the right time (the four clocks not >>> dropped every 5). >> >>> Austin >> >> Many thanks, I had made a syntax error where I wrote >> >> TIMESPEC "my_fromto" = FROM "my_from_grp" TO "my_to_grp" TIG; >> >> and when changed ito >> >> TIMESPEC TS_my_fromto = FROM "my_from_grp" TO "my_to_grp" TIG; >> >> it all worked. >> >> I'm sure in my past designs I haven't had this problem, but I guess >> using clocks which have a common sourse means that the timing >> analyser has founf something to analyse! >> >> I take your point about the sourcing of clocks. For various reasons >> I want the design to be flexible as possible, and willing to accept >> the consequences. Also missing a clock every 5 will require a >> tighter design in terms of timing. > > It always bothered me that time specs needed to start with "TS". This > is the syntax problem in the first version, not the quotes. Thanks for pointing that out. To be honest I don't dislike being forced to use a meaningful prefix, but I would have liked ISE to have warned me where I hadn't conformed.Article: 147042
Is it possible to define an internal reset for a microblaze system. Idealy I would like it to come from the DCM locked signal. Do I need to define it in the XBD file or is that just for external ports? Thanks Jon --------------------------------------- Posted through http://www.FPGARelated.comArticle: 147043
On Apr 10, 9:42=A0pm, "jt_eaton" <z3qmtr45@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote: > Why do people keep comparing the checking that is inherent in VHDL with > what is done in Verilog? Are you suggesting that it is not a fair comparison of two things that purport to fulfill the same need? Just like any other competing products, boosters of one will claim advantage over the weakness of the other. > There is a whole class of tools called rtl > checkers that are designed to catch these language gotches before you run > simulation. There are almost always new products that pop up to fulfill any shortcoming. That's the marketplace in action. While this will most likely be a misinterpreted analogy, the existence of an additional tool such as a crutch is not a reason to prefer a broken leg over an unbroken one. > Yes there are lots of ways to make mistakes in verilog. That > simply means that you need to add a tool that can catch =A0them. > Or ask yourself if the hassle of yet another tool (and possible licensing costs) is worth it? Maybe it is, maybe it's not, but that 'worth it' decision will most likely be an individual one unless the tool is very, very good and near zero cost (product cost and learning curve cost). Generally speaking, most people would not prefer to use 'yet another' tool in the tool chain unless they feel it adds real value...and dislike additional tools that fundamentally are there to catch shortcomings...even if the tool is really good at what it does and is free, open source. Rickman's original point is that he thinks he can be more productive using Verilog than VHDL. Whether or not *he* can be more productive or not depends a lot on Rickman, his usage and frequency of usage of any language, the types of design errors that he tends to make, etc. In the end, Rickman learning Verilog likely increases his marketability since he may master yet another skill that could be of use in his career. The actual increased or decreased productivity that prompted him will in the end will probably be found to be very low...probably much lower than the ability to work with both languages (assuming that he can achieve relatively high skill in both languages, rather than only be marginally skilled in either). Kevin JenningsArticle: 147044
On Apr 11, 2:13=A0pm, KJ <kkjenni...@sbcglobal.net> wrote: > On Apr 10, 9:42=A0pm, "jt_eaton" > > <z3qmtr45@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote: > > Why do people keep comparing the checking that is inherent in VHDL with > > what is done in Verilog? > > Are you suggesting that it is not a fair comparison of two things that > purport to fulfill the same need? =A0Just like any other competing > products, boosters of one will claim advantage over the weakness of > the other. Well, as you point out, comparisons will be made. Then again, as I tried to explain in an earlier post, typing errors are but a tiny class of potential errors that can be made. > > There is a whole class of tools called rtl > > checkers that are designed to catch these language gotches before you r= un > > simulation. > > There are almost always new products that pop up to fulfill any > shortcoming. =A0That's the marketplace in action. <MeaninglessGoogleExample> When I google for "vhdl rtl checker" I actually get more hits than when I google for "verilog rtl checker". What does it mean? Who knows? </MeaninglessGoogleExample> > While this will most likely be a misinterpreted analogy, the existence > of an additional tool such as a crutch is not a reason to prefer a > broken leg over an unbroken one. While this will most likely be a misinterpreted analogy, the potential existence of a car that will drive for you and automatically encase you in foam in the event of an accident (like in "Demolition Man") is not a reason to prefer cars over motorcycles. > > Yes there are lots of ways to make mistakes in verilog. That > > simply means that you need to add a tool that can catch =A0them. > > Or ask yourself if the hassle of yet another tool (and possible > licensing costs) is worth it? =A0Maybe it is, maybe it's not, but that > 'worth it' decision will most likely be an individual one unless the > tool is very, very good and near zero cost (product cost and learning > curve cost). =A0Generally speaking, most people would not prefer to use > 'yet another' tool in the tool chain unless they feel it adds real > value...and dislike additional tools that fundamentally are there to > catch shortcomings...even if the tool is really good at what it does > and is free, open source. These are good points, but at least *some* people believe in the Unix mindset of small, great, tools with a laser focus, instead of some big monolithic black box that you shove code in one side and get a bit file out the other side. And the nice thing about (Verilog and VHDL) RTL checkers is that most of them are quite configurable to a given company's design rules. Having said all that, it is true that a lone developer might prefer a cheap, all-in-one solution, and it might be that VHDL is closer to that than Verilog, but it is certainly not a panacea, and as Rickman is finding out, the cost of having the additional "safety" features (in terms of difficulties trying to coax VHDL into letting you do a few things that Verilog would let you do quite easily) might in some cases outweigh the cost of not having those same safety features. > Rickman's original point is that he thinks he can be =A0more productive > using Verilog than VHDL. =A0Whether or not *he* can be more productive > or not depends a lot on Rickman, his usage and frequency of usage of > any language, the types of design errors that he tends to make, etc. Absolutely agreed. > In the end, Rickman learning Verilog likely increases his > marketability since he may master yet another skill that could be of > use in his career. Also agreed. Learning tools that can be useful for your job is always a great thing. >=A0The actual increased or decreased productivity > that prompted him will in the end will probably be found to be very > low...probably much lower than the ability to work with both languages > (assuming that he can achieve relatively high skill in both languages, > rather than only be marginally skilled in either). We will have to see his anniversary report this time next year ;-) BTW, slashdot had a verilog/vhdl question awhile back -- which one should be taught as a first HDL? http://ask.slashdot.org/article.pl?sid=3D09/05/31/187208 One of the commenters noted that the all the anecdotal evidence provided by the other comments indicated that people who learned VHDL first had no problem subsequently learning and working with Verilog, but that the converse was not true, so *obviously* teaching VHDL was the correct answer. http://ask.slashdot.org/comments.pl?sid=3D1251483&cid=3D28160801 I agree with his observation of the provided anecdotes, but the conclusion seems a bit stretched to me. If I am allowed one more bad analogy, it would be as if a study showed that people who learned how to do basic math with Roman numerals had no problem adapting to Arabic numerals, but people taught with Arabic numerals struggled with basic math when they were later expected to use Roman numerals (so *obviously* we should teach math with Roman numerals first). Regards, PatArticle: 147045
On Apr 9, 9:55=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
> On Apr 8, 11:57=A0pm, Speed <speedboy1...@gmail.com> wrote:
>
> > Dear All,
> > =A0 We are planning to design a board with four FPGAs to emulate X86
> > CPU. The FPGA=92s JTAG ports are serially chained together. My problem
> > is that whether the Xilinx=92s ChipScope can support debugging multiple
> > FPGAs via a single JTAG chain at the same time? So we can set
> > different trigger conditions to different FPGA chips at the same time
> > and watch the sampled data from ChipScope.
>
> > Thanks in advance,
> > Speed.
>
> Yes, ChipScope can handle debugging in multiple FPGAs in the same
> chain. =A0Each of the ILA cores will be independent of each other.
>
> Ed McGettigan
> --
> Xilinx Inc.
Dear Ed
Thanks for your replay
Article: 147046> "Speed" <speedboy1211@gmail.com> wrote in message > news:faa559c2-2ef8-440c-b9bc-3ccd212528fd@u31g2000yqb.googlegroups.com... > Dear All, > We are planning to design a board with four FPGAs to emulate X86 > CPU. The FPGA’s JTAG ports are serially chained together. My problem > is that whether the Xilinx’s ChipScope can support debugging multiple > FPGAs via a single JTAG chain at the same time? So we can set > different trigger conditions to different FPGA chips at the same time > and watch the sampled data from ChipScope. Speed, I hope you'll forgive the 'advert' but depending on what you're trying to look at in each of the FPGA's you might find my 1 Pin Interface useful... http://www.1pin-interface.com/ There are five IO ports, the active one can be set on the fly so you could use one module to access your 4 FPGAs. This gives high level register access to the devices using just one unused user IO per device. It might be easier to get up and running than 4 instances of chipscope. NialArticle: 147047
On Apr 11, 5:03=A0am, Patrick Maupin <pmau...@gmail.com> wrote: > So, no, I don't think I'm confused at all (I can't speak for my > readers; I often leave those confused, I'm sure) and I stand by my > assertion that one of the key principles of programming in Python is > that typing errors are typically the least of the possible errors in a > real program. As a thought experiment, imagine a Verilog revision based on a pythonic mindset. Here's what would likely happen to Jonathan's examples: Issue: Most-significant bits silently lost when you copy a wide vector into a narrow one. New behavior: run-time or compile-time error. Rationale: "Errors should never pass silently". (Python zen) Issue: Signed values silently zero-filled to the width of a wider target. New behavior: Use sign bit extension instead. Rationale: Obvious language design errors should be fixed. Verilog designers are surprizingly tolerant to those, but a Python language designer would never get away with this. As a conclusion, your reference to Python to justify Verilog's current behavior is rather unconvincing. JanArticle: 147048
On Apr 9, 9:05=A0pm, Patrick Maupin <pmau...@gmail.com> wrote: > And BTW, (IMO) it's *much* easier to code a reasonable testbench in > verilog than in VHDL. =A0But, obviously, your mileage varies. I fail to understand why people don't code testbenches in a nice dynamic language like python. Limit the use of HDLs to describing the hardware and make use of a high-level scripting language to read in files/generate stimuli, check results and introduce errors/modify state dynamically. It's time to move on from the immensely limited HDL fileIO testbench model. Thanks, ChrisArticle: 147049
On Apr 12, 6:49=A0am, Chris Higgs <chiggs...@googlemail.com> wrote: > On Apr 9, 9:05=A0pm, Patrick Maupin <pmau...@gmail.com> wrote: > > > I fail to understand why people don't code testbenches in a nice > dynamic language like python. > Because it's just as productive to code models and deal with only one language. > Limit the use of HDLs to describing the hardware and make use of a > high-level scripting language to read in files/generate stimuli, check > results and introduce errors/modify state dynamically. It's time to > move on from the immensely limited HDL fileIO testbench model. > Perhaps you should adjust your mindset and consider that testbench models are in no way limited to 'fileIO testbench models'. Testbenches can use real models of real devices, it's not that hard. Error injection handled easily as well. 'High level' scripting languages don't necessarily have any inherent advantages, they're just different languages. KJ
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