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
Le 29/12/2012 01:20, glen herrmannsfeldt a écrit : > For even more fun, use both in the same project. Even more, add in some > AHDL and schematic capture at the same time. (Yes, I did that once.) You need to spend more money on the tools so that you can simulate this lot. That's expensive fun ;o) Nicolas (who will probably very shortly need to learn Verilog)Article: 154726
Martin Schoeberl wrote: > A good comparison would be to do one HW design, e.g. a standard MIPS > pipeline, in all languages and compare the efficiency of the language and > the efficiency of the resulting HW implementation. MAN, that would be a landmark achievement! You might even go down in history as the author of "the Schoeberl paper". Even if it wouldn't change the (horrible) way I do designs now, it would sure be an interesting read. JonArticle: 154727
On 12/28/12 11:25 PM, Martin Schoeberl wrote: > "garyr" <garyr@fidalgo.net> wrote: >> "Martin Schoeberl" <martin@jopdesign.com> wrote in message >> news:1621424063378432030.694310martin-jopdesign.com@reader.albasani.net... >>> Hi all, >>> >>> started to look into alternatives to Verilog and VHDL and >>> stumbled over chisel from UCB: >>> http://chisel.eecs.berkeley.edu/ >>> >>> Any experiences and comment on this language? >>> >>> Looks like some challenge for me as it involves practically >>> learning 3 new languages at once: chisel itself, Scala on which >>> it is based, and Verilog, which is produced (I'm used to VHDL). >>> >>> Cheers, >>> Martin >>> >>> PS: I was *very* long absent from this group ;-) >>> >> >> You might find this interesting: http://www.myhdl.org > > Thanks for pointing this out, although it was not the 'real' answer to > my question ;-) > > I'm already looking at MyHDL and some other projects. chisel just lookes > most promising at the moment. Maybe I change my mind. > > A good comparison would be to do one HW design, e.g. a standard MIPS > pipeline, in all languages and compare the efficiency of the language and > the efficiency of the resulting HW implementation. > > Martin > Typically to do a comparison you have to have an example/project fairly limited in scope. It is hard to realize the benefits with such small examples. A language might have a /nice/ description for example "A" but is horrible at parametrization or it can be difficult to connect many modules or fails miserably at example "B" and "C". I am not familiar with Chisel and Scala and cannot comment directly. I am familiar with MyHDL and I have used MyHDL successfully for commercial and independent projects. Regards, ChrisArticle: 154728
On Dec 29, 6:29=A0pm, Nicolas Matringe <nicolas.matri...@fre.fre> wrote: > Le 29/12/2012 01:20, glen herrmannsfeldt a =E9crit : > > > For even more fun, use both in the same project. Even more, add in some > > AHDL and schematic capture at the same time. (Yes, I did that once.) > > You need to spend more money on the tools so that you can simulate this > lot. That's expensive fun ;o) > For small simulation of synthesizable design written in that wild mix, you can simulate in internal simulator of QuartusII 9.1 Web edition. Costs exactly 0 USD. > Nicolas (who will probably very shortly need to learn Verilog)Article: 154729
Jon Elson <elson@pico-systems.com> wrote: > Martin Schoeberl wrote: > > >> A good comparison would be to do one HW design, e.g. a standard MIPS >> pipeline, in all languages and compare the efficiency of the language and >> the efficiency of the resulting HW implementation. > > MAN, that would be a landmark achievement! You might even go down > in history as the author of "the Schoeberl paper". Even if it wouldn't > change the (horrible) way I do designs now, it would sure be an > interesting read. > > Jon Maybe I should tone this done. Yes, it would be nice to have this example. It would also be nice to have this comparison in a paper. Let's see where this leads. I will start on a smaller scale with simpler examples. Maybe up to a very simple processor that I already have in VHDL. Will keep you informed along the path. If anybody would like to join this effort we can setup a repository. MartinArticle: 154730
Martin Schoeberl wrote: > Jon Elson <elson@pico-systems.com> wrote: >> Martin Schoeberl wrote: >> >> >>> A good comparison would be to do one HW design, e.g. a standard MIPS >>> pipeline, in all languages and compare the efficiency of the language >>> and the efficiency of the resulting HW implementation. >> >> MAN, that would be a landmark achievement! You might even go down >> in history as the author of "the Schoeberl paper". Even if it wouldn't >> change the (horrible) way I do designs now, it would sure be an >> interesting read. >> >> Jon > > Maybe I should tone this done. Yes, it would be nice to have this example. > It would also be nice to have this comparison in a paper. Let's see where > this leads. > > I will start on a smaller scale with simpler examples. Maybe up to a very > simple processor that I already have in VHDL. Will keep you informed along > the > path. If anybody would like to join this effort we can setup a repository. Great, and thanks for putting in the effort! Even a VERY simple example of the same function in several languages could be quite instructive. But, a somewhat larger project would be more likely to expose some of the deficiencies of this or that language. JonArticle: 154731
You could get memory mapped I/O if you customized the program instruction code in VHDL manually by making certain addresses output values from registers that were connected to I/O directly. The picoblaze assembler wouldn't be aware of this modification, of course, so you'd introduce a whole new way of shooting yourself in the foot, but it could be done right? Any thoughts? On Tuesday, September 18, 2012 11:46:01 PM UTC-7, goou...@gmail.com wrote: > Am Dienstag, 18. September 2012 16:43:14 UTC+2 schrieb rvm....@gmail.com: > > > hello all, > > > > > > I am new in the field of soft core processor. > > > > > > I want to implement multiple picoblaze on spartan 3E. > > > > > > > > > > > > I had gone through doc available on xilinx website. > > > > > > All demo available on web is working fine with me. > > > > > > I am trying to interface a seven segment with picoblaze but somehow i am not able to make my own design. > > > > > > > > > > > > Please guide me for same. > > > > Hi, > > do you have some knowledge/experience with HDLs or digital design? > > > > The PicoBlaze documentation shows very well how to add ports to the core and how to access these ports from the software. (Sorry Tim, there's no memory mapped I/O for the picoblaze. But the real solution is quite similar.) > > > > Many beginners questions regarding the Picoblaze have already been answered and can be found here: > > http://forums.xilinx.com/t5/PicoBlaze/bd-p/PicoBlaze > > > > If there are still things unclear you should explain them in more detail. > > - What board are you using? > > - What is your design method (schematic, verilog, VHDL)? > > - Where exactly are you haveing problems with your design? > > (Error messages etc.) > > > > The above mentioned subforum might be a better place for this, since it is specialized on Picoblaze related topics. > > > > Have a nice synthesis > > EilertArticle: 154732
"rickman" wrote in message news:kbl7n3$c81$1@dont-email.me... > I think if you learn VHDL first, Verilog will feel like a breath of fresh > air... lol VHDL plays ADA to Verilog's "C"Article: 154733
On Mon, 31 Dec 2012 10:50:08 +0000, Andrew Holme wrote: > "rickman" wrote in message news:kbl7n3$c81$1@dont-email.me... >> I think if you learn VHDL first, Verilog will feel like a breath of >> fresh air... lol > > VHDL plays ADA to Verilog's "C" Yes, which is seriously one of VHDL's strong points. (btw it's Ada not ADA, since it's a name not an acronym) I am increasingly finding the synergy between Ada and VHDL to be very useful. I can now use a high level language on both sides of the HW/SW divide, even for low-level programming on AVR or MSP430 processors, and (unless a customer specifically asks for C) no longer bother with the tedious debugging and poor productivity that a low level language like C used to give. I have experimentally called Ada code from VHDL, and vice versa, using the minimal VHPIDirect interface available in GHDL. The fact that GHDL uses GCC, which has very good Ada support, makes this easy. The link works both ways, but I haven't tried it with any other simulator. This ought to allow me (when I get back to that project) to use the very clean object-oriented facilities of Ada-2005 to give the sort of constrained random test methodology that Janick Bergeron talks about in his "Writing Testbenches" book. It's not that I don't appreciate the OSVVM approach of doing it all in VHDL, but I believe that using inheritance and class extension allow much more reuse and faster test development. - BrianArticle: 154734
On 12/30/12 4:42 PM, Jon Elson wrote: > Martin Schoeberl wrote: > >> Jon Elson <elson@pico-systems.com> wrote: >>> Martin Schoeberl wrote: >>> >>> >>>> A good comparison would be to do one HW design, e.g. a standard MIPS >>>> pipeline, in all languages and compare the efficiency of the language >>>> and the efficiency of the resulting HW implementation. >>> >>> MAN, that would be a landmark achievement! You might even go down >>> in history as the author of "the Schoeberl paper". Even if it wouldn't >>> change the (horrible) way I do designs now, it would sure be an >>> interesting read. >>> >>> Jon >> >> Maybe I should tone this done. Yes, it would be nice to have this example. >> It would also be nice to have this comparison in a paper. Let's see where >> this leads. >> >> I will start on a smaller scale with simpler examples. Maybe up to a very >> simple processor that I already have in VHDL. Will keep you informed along >> the >> path. If anybody would like to join this effort we can setup a repository. > Great, and thanks for putting in the effort! > Even a VERY simple example of the same function in several languages > could be quite instructive. But, a somewhat larger project would > be more likely to expose some of the deficiencies of this or that > language. > > Jon > You might be interested in this rebuttal to a paper that compared a couple non-traditional HDLs. http://thread.gmane.org/gmane.comp.python.myhdl/2701 Regards, ChrisArticle: 154735
On 12/31/2012 4:26 AM, Travis Ayres wrote: > You could get memory mapped I/O if you customized the program instruction code in VHDL manually by making certain addresses output values from registers that were connected to I/O directly. > > The picoblaze assembler wouldn't be aware of this modification, of course, so you'd introduce a whole new way of shooting yourself in the foot, but it could be done right? > > Any thoughts? > The PicoBlaze doesn't really have a data "memory" address other than the INPUT and OUTPUT instructions. You could bring a register directly to a port (I've done this for IO expansion) or perhaps on pB versions that have a scratchpad bring that bus out to a port (mine, KCPSM2 predated the scratchpad, but had more registers). Instruction memory is a different beast, and of course you can't write to it unless you modify the core (probably best not to allow this). -- GaborArticle: 154736
Hi
I have created a controller for DDR3 with the MIG. The MIG output folders
are example_design and user_design. according to MIG report :
"
- example_design:
This folder includes the design with synthesizable test bench.
- user_design:
This folder includes the design without test bench modules.
"
But actually i don't see any important difference between these folders
except the name of some files! The top module of both folders have
instantiated the controller and the traffic generator for testing. So which
module is appropriate for start of my design?! Both are too complicated
that i can't use in my design!
Any hint please?
Thanks in advance
---------------------------------------
Posted through http://www.FPGARelated.com
Article: 154737On Fri, 28 Dec 2012 17:50:10 -0500 rickman <gnuarm@gmail.com> wrote: > > That's my advice. Meanwhile I am working with VHDL and have never put > much effort into learning Verilog because I can't find a good book to > use as a reference and learning guide. I'm told none of the Verilog > books are all that good. > What Verilog I know I got from "Verilog by Example" by Blaine C. Readler, which I thought was pretty good. Then again, I write VHDL pretty exclusively, and really only needed enough Verilog to be able to suss out what other people were doing. In terms of which language is "better", one of the things I've been finding lately while I'm neck deep in Altera's tools is that, for Altera at least, Verilog support is a given whereas VHDL support is marginal at best. A lot of their fancier tools are only available in Verilog, or have glaring bugs in VHDL mode. This means that, if you write VHDL like I do, you're absolutely up a creek without a mixed language simulator. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.Article: 154738
Christopher Felton <abc@def.org> wrote: > On 12/30/12 4:42 PM, Jon Elson wrote: >> Martin Schoeberl wrote: >> >>> Jon Elson <elson@pico-systems.com> wrote: >>>> Martin Schoeberl wrote: >>>> >>>> >>>>> A good comparison would be to do one HW design, e.g. a standard MIPS >>>>> pipeline, in all languages and compare the efficiency of the language >>>>> and the efficiency of the resulting HW implementation. >>>> >>>> MAN, that would be a landmark achievement! You might even go down >>>> in history as the author of "the Schoeberl paper". Even if it wouldn't >>>> change the (horrible) way I do designs now, it would sure be an >>>> interesting read. >>>> >>>> Jon >>> >>> Maybe I should tone this done. Yes, it would be nice to have this example. >>> It would also be nice to have this comparison in a paper. Let's see where >>> this leads. >>> >>> I will start on a smaller scale with simpler examples. Maybe up to a very >>> simple processor that I already have in VHDL. Will keep you informed along >>> the >>> path. If anybody would like to join this effort we can setup a repository. >> Great, and thanks for putting in the effort! >> Even a VERY simple example of the same function in several languages >> could be quite instructive. But, a somewhat larger project would >> be more likely to expose some of the deficiencies of this or that >> language. >> >> Jon >> > > You might be interested in this rebuttal to a > paper that compared a couple non-traditional HDLs. > > http://thread.gmane.org/gmane.comp.python.myhdl/2701 > > Regards, > Chris This is definitely interesting, but the link is dead :-( Do you have the title of that paper so I can try to Google it. Cheers, MartinArticle: 154739
On 1/2/13 8:35 PM, Martin Schoeberl wrote: > Christopher Felton <abc@def.org> wrote: >> On 12/30/12 4:42 PM, Jon Elson wrote: >>> Martin Schoeberl wrote: >>> >>>> Jon Elson <elson@pico-systems.com> wrote: >>>>> Martin Schoeberl wrote: >>>>> >>>>> >>>>>> A good comparison would be to do one HW design, e.g. a standard MIPS >>>>>> pipeline, in all languages and compare the efficiency of the language >>>>>> and the efficiency of the resulting HW implementation. >>>>> >>>>> MAN, that would be a landmark achievement! You might even go down >>>>> in history as the author of "the Schoeberl paper". Even if it wouldn't >>>>> change the (horrible) way I do designs now, it would sure be an >>>>> interesting read. >>>>> >>>>> Jon >>>> >>>> Maybe I should tone this done. Yes, it would be nice to have this example. >>>> It would also be nice to have this comparison in a paper. Let's see where >>>> this leads. >>>> >>>> I will start on a smaller scale with simpler examples. Maybe up to a very >>>> simple processor that I already have in VHDL. Will keep you informed along >>>> the >>>> path. If anybody would like to join this effort we can setup a repository. >>> Great, and thanks for putting in the effort! >>> Even a VERY simple example of the same function in several languages >>> could be quite instructive. But, a somewhat larger project would >>> be more likely to expose some of the deficiencies of this or that >>> language. >>> >>> Jon >>> >> >> You might be interested in this rebuttal to a >> paper that compared a couple non-traditional HDLs. >> >> http://thread.gmane.org/gmane.comp.python.myhdl/2701 >> >> Regards, >> Chris > > This is definitely interesting, but the link is dead :-( > > Do you have the title of that paper so I can try to Google it. > > Cheers, > Martin > I believe this is the original paper: http://referaat.cs.utwente.nl/conference/17/paper/7344/comparing-hardware-description-languages.pdf But note the objections in the previous thread I posted. The comparisons are incomplete (comparing non-working HDL, the author(s) didn't learn enough of the languages). Regards, ChrisArticle: 154740
On Tuesday, April 15, 2008 8:01:58 PM UTC-5, Eric Smith wrote: > lm317t wrote: > > The syntax for Verilog will be a bit more familiar to you if you > > program in C/C++. >=20 > Which is a drawback, not a benefit, since the actual langauge semantics > are almost nothing like C. The superficial similarity of the syntax > seems to cause a lot of confusion for new Verilog designers. I kinda agree with that statement, but it is relatively easy to get over th= at hump. I started with Verilog a year ago after much experience with C. I = was able to get up and running with Verilog in a short time (with the help = of useful sample code that was close to what I was trying to do) while afte= r about the same time spent with VHDL, I am nowhere as far along. There is something with VHDL that makes it appear unfriendly to people with= C background. I started completely on my own with nobody to help me along,= but I found Verilog really friendly. I do not have enough experience to say if one is superior to the other, but= since at some point you will probably have to know both, start with Verilo= g, it is less off-putting. For a plug (no financial interest, just a satisfied customer), look at the = knjn.com kits and the related fpga4fun.com site.Article: 154741
On Thursday, January 3, 2013 9:55:10 AM UTC-6, 4rt.dw...@gmail.com wrote: > On Tuesday, April 15, 2008 8:01:58 PM UTC-5, Eric Smith wrote: >=20 > > lm317t wrote: >=20 > > > The syntax for Verilog will be a bit more familiar to you if you >=20 > > > program in C/C++. >=20 > >=20 >=20 > > Which is a drawback, not a benefit, since the actual langauge semantics >=20 > > are almost nothing like C. The superficial similarity of the syntax >=20 > > seems to cause a lot of confusion for new Verilog designers. >=20 >=20 >=20 > I kinda agree with that statement, but it is relatively easy to get over = that hump. I started with Verilog a year ago after much experience with C. = I was able to get up and running with Verilog in a short time (with the hel= p of useful sample code that was close to what I was trying to do) while af= ter about the same time spent with VHDL, I am nowhere as far along. >=20 > There is something with VHDL that makes it appear unfriendly to people wi= th C background. I started completely on my own with nobody to help me alon= g, but I found Verilog really friendly. >=20 > I do not have enough experience to say if one is superior to the other, b= ut since at some point you will probably have to know both, start with Veri= log, it is less off-putting. >=20 > For a plug (no financial interest, just a satisfied customer), look at th= e knjn.com kits and the related fpga4fun.com site.Article: 154742
On Thu, 3 Jan 2013 07:55:10 -0800 (PST)
4rt.dw8.5t4wr@gmail.com wrote:
> There is something with VHDL that makes it appear unfriendly to people with C background. I started completely on my own with nobody to help me along, but I found Verilog really friendly.
I think that "something" is verbosity. C allows you to, and C
programmers seem to thrive on, writing extremely terse code.
while (!(c = *cptr++)) {...}
sorts of things abound, and are considered to be both clever and
canonical. VHDL doesn't want you to, and doesn't encourage you to, and
considers verbose code with lots of very explicit description of
what's going on, to be an asset rather than a waste of keystrokes.
--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.
Article: 1547434rt.dw8.5t4wr@gmail.com wrote: > On Tuesday, April 15, 2008 8:01:58 PM UTC-5, Eric Smith wrote: >> lm317t wrote: >> > The syntax for Verilog will be a bit more familiar to you if you >> > program in C/C++. >> Which is a drawback, not a benefit, since the actual langauge semantics >> are almost nothing like C. The superficial similarity of the syntax >> seems to cause a lot of confusion for new Verilog designers. No, that isn't it. For one, there are people using C as an HDL, which I don't find an especially good idea. (At least for the kinds of things I want to do, you can't port an algorithm from C code to HDL code.) But VHDL seems to be verbose, especially in its declarations, in ways that both C and verilog are not. Both C and verilog use &, |, and ^ for and, or, and xor operators. Maybe VHDL does, too. It is, though, fairly simple to learn to write verilog expressions, that is, the right hand side of continuous assignment statements, if you know C. > I kinda agree with that statement, but it is relatively easy to > get over that hump. I started with Verilog a year ago after much > experience with C. I was able to get up and running with Verilog > in a short time (with the help of useful sample code that was > close to what I was trying to do) while after about the same time > spent with VHDL, I am nowhere as far along. I don't know about others, but I generally write structural verilog with continuous assignment, and mostly not behavioral verilog, except for FF's (and state machines). Verilog has some operators that C doesn't have, but it isn't so hard to learn those, and they usually look like you might expect them to look like if C did have them. As well as I remember them, the VHDL operators are somewhat different, and not easy for C programmers to remember. > There is something with VHDL that makes it appear unfriendly to > people with C background. I started completely on my own with > nobody to help me along, but I found Verilog really friendly. > I do not have enough experience to say if one is superior to the > other, but since at some point you will probably have to know both, > start with Verilog, it is less off-putting. Yes. I bought two books (about 20 years ago, so there weren't all that many choices) and with some synthesis tools and just started writing. Maybe it wouldn't have taken so much longer with VHDL, but it was pretty easy with verilog. > For a plug (no financial interest, just a satisfied customer), > look at the knjn.com kits and the related fpga4fun.com site. -- glenArticle: 154744
On Thu, 03 Jan 2013 17:27:14 +0000, glen herrmannsfeldt wrote: > 4rt.dw8.5t4wr@gmail.com wrote: >> On Tuesday, April 15, 2008 8:01:58 PM UTC-5, Eric Smith wrote: >>> lm317t wrote: >>> > The syntax for Verilog will be a bit more familiar to you if you >>> > program in C/C++. > >>> Which is a drawback, not a benefit, since the actual langauge >>> semantics are almost nothing like C. The superficial similarity of >>> the syntax seems to cause a lot of confusion for new Verilog >>> designers. > > No, that isn't it. > > For one, there are people using C as an HDL, which I don't find an > especially good idea. (At least for the kinds of things I want to do, > you can't port an algorithm from C code to HDL code.) > > But VHDL seems to be verbose, especially in its declarations, in ways > that both C and verilog are not. > > Both C and verilog use &, |, and ^ for and, or, and xor operators. Maybe > VHDL does, too. It is, though, fairly simple to learn to write verilog > expressions, that is, the right hand side of continuous assignment > statements, if you know C. > >> I kinda agree with that statement, but it is relatively easy to get >> over that hump. I started with Verilog a year ago after much experience >> with C. I was able to get up and running with Verilog in a short time >> (with the help of useful sample code that was close to what I was >> trying to do) while after about the same time spent with VHDL, I am >> nowhere as far along. > > I don't know about others, but I generally write structural verilog with > continuous assignment, and mostly not behavioral verilog, except for > FF's (and state machines). Verilog has some operators that C doesn't > have, but it isn't so hard to learn those, and they usually look like > you might expect them to look like if C did have them. > > As well as I remember them, the VHDL operators are somewhat different, > and not easy for C programmers to remember. > >> There is something with VHDL that makes it appear unfriendly to people >> with C background. I started completely on my own with nobody to help >> me along, but I found Verilog really friendly. I do not have enough >> experience to say if one is superior to the other, but since at some >> point you will probably have to know both, start with Verilog, it is >> less off-putting. > > Yes. I bought two books (about 20 years ago, so there weren't all that > many choices) and with some synthesis tools and just started writing. > Maybe it wouldn't have taken so much longer with VHDL, but it was pretty > easy with verilog. > >> For a plug (no financial interest, just a satisfied customer), look at >> the knjn.com kits and the related fpga4fun.com site. I have to admit, the biggest problem that I have as a C++ programmer when writing in either VHDL or Verilog is envy: in both (IIRC) VHDL or Verilog, when you have a module with a bazzilion input and output signals, you can invoke it with a syntax something like module_name(module_signal_name = local_signal_name, ...) In C++, when, for reasons of utility, you are forced to design a class whose constructor has a bazzilion inputs, you have to hold your breath, close your eyes, cross your fingers, and hope that whoever uses that constructor call gets all the right things in all the right places: I'd Much Rather be able to invoke the syntax above and have it all self- document. -- My liberal friends think I'm a conservative kook. My conservative friends think I'm a liberal kook. Why am I not happy that they have found common ground? Tim Wescott, Communications, Control, Circuits & Software http://www.wescottdesign.comArticle: 154745
Tim Wescott <tim@seemywebsite.com> wrote: (big snip on verilog, VHDL, C, and the differences between them) > I have to admit, the biggest problem that I have as a C++ programmer when > writing in either VHDL or Verilog is envy: in both (IIRC) VHDL or Verilog, > when you have a module with a bazzilion input and output signals, you can > invoke it with a syntax something like > module_name(module_signal_name = local_signal_name, ...) > In C++, when, for reasons of utility, you are forced to design a class > whose constructor has a bazzilion inputs, you have to hold your breath, > close your eyes, cross your fingers, and hope that whoever uses that > constructor call gets all the right things in all the right places: I'd > Much Rather be able to invoke the syntax above and have it all self- > document. Fortran now has the keywork form as an option. Also, optional arguments so that the called routine can figure out which options are needed. I do remember once mixing verilog and schematic capture. In that case, you have to use the keyword form, as there is no ordering to the ports in the schematic. (I tried to find one, but there isn't one.) Also, some port names started with digits, which it turns out verilog allows, though I forget how you write them. -- glenArticle: 154746
Christopher Felton <abc@def.org> wrote: > On 1/2/13 8:35 PM, Martin Schoeberl wrote: >> Christopher Felton <abc@def.org> wrote: >>> On 12/30/12 4:42 PM, Jon Elson wrote: >>>> Martin Schoeberl wrote: >>>> >>>>> Jon Elson <elson@pico-systems.com> wrote: >>>>>> Martin Schoeberl wrote: >>>>>> >>>>>> >>>>>>> A good comparison would be to do one HW design, e.g. a standard MIPS >>>>>>> pipeline, in all languages and compare the efficiency of the language >>>>>>> and the efficiency of the resulting HW implementation. >>>>>> >>>>>> MAN, that would be a landmark achievement! You might even go down >>>>>> in history as the author of "the Schoeberl paper". Even if it wouldn't >>>>>> change the (horrible) way I do designs now, it would sure be an >>>>>> interesting read. >>>>>> >>>>>> Jon >>>>> >>>>> Maybe I should tone this done. Yes, it would be nice to have this example. >>>>> It would also be nice to have this comparison in a paper. Let's see where >>>>> this leads. >>>>> >>>>> I will start on a smaller scale with simpler examples. Maybe up to a very >>>>> simple processor that I already have in VHDL. Will keep you informed along >>>>> the >>>>> path. If anybody would like to join this effort we can setup a repository. >>>> Great, and thanks for putting in the effort! >>>> Even a VERY simple example of the same function in several languages >>>> could be quite instructive. But, a somewhat larger project would >>>> be more likely to expose some of the deficiencies of this or that >>>> language. >>>> >>>> Jon >>>> >>> >>> You might be interested in this rebuttal to a >>> paper that compared a couple non-traditional HDLs. >>> >>> http://thread.gmane.org/gmane.comp.python.myhdl/2701 >>> >>> Regards, >>> Chris >> >> This is definitely interesting, but the link is dead :-( >> >> Do you have the title of that paper so I can try to Google it. >> >> Cheers, >> Martin >> > > I believe this is the original paper: > http://referaat.cs.utwente.nl/conference/17/paper/7344/comparing-hardware-description-languages.pdf > > But note the objections in the previous thread I posted. The comparisons > are incomplete (comparing non-working HDL, the author(s) didn't learn > enough of the languages). > > Regards, > Chris Thanks for pointing me to the paper. It is not a very exciting one and I agree on all critics. I did not look into all details, but I think the FIFO example is also broken. There is only one pointer, but one would need a read and a write pointer. Untested code and no synthesis results. Ok, it is just a student conference. With this paper as reference it should be easy to do better ;-) Cheers, MartinArticle: 154747
On Thu, 03 Jan 2013 17:27:14 +0000, glen herrmannsfeldt wrote: > But VHDL seems to be verbose, especially in its declarations, in ways > that both C and verilog are not. > > Both C and verilog use &, |, and ^ for and, or, and xor operators. Maybe > VHDL does, too. ... > As well as I remember them, the VHDL operators are somewhat different, > and not easy for C programmers to remember. Not so easy? When you wanted to communicate the meaning of &, |, ^ above, I see you called them and, or, xor. Well, so does VHDL. I find it a whole lot easier to read. And sufficiently more powerful that if you learn to use it (e.g. the type system) instead of fighting it, you can do things a lot more concisely. Using records for ports and hierarchical signals, for example, rather than passing lots of wires around. Not that you could tell that concise VHDL was possible from any of the tutorial examples floating around, let alone an FPGA vendor's own code... - BrianArticle: 154748
On Thu, 03 Jan 2013 11:42:29 -0600, Tim Wescott wrote: > On Thu, 03 Jan 2013 17:27:14 +0000, glen herrmannsfeldt wrote: > I have to admit, the biggest problem that I have as a C++ programmer > when writing in either VHDL or Verilog is envy: in both (IIRC) VHDL or > Verilog, > when you have a module with a bazzilion input and output signals, you > can invoke it with a syntax something like > > module_name(module_signal_name = local_signal_name, ...) > > In C++, when, for reasons of utility, you are forced to design a class > whose constructor has a bazzilion inputs, you have to hold your breath, > close your eyes, cross your fingers, and hope that whoever uses that > constructor call gets all the right things in all the right places: I'd > Much Rather be able to invoke the syntax above and have it all self- > document. You mean named association? If you want the option of named association in your object oriented software, that's easy : take a look at Ada-2005 (or now, Ada-2012). It gives you a lot of other good stuff too - including a remarkably sane object-oriented programming model (where everything ISN'T a pointer), and spookily accurate reports from runtime faults that would just say "segfault" in a C++ program. The one positive thing C++ has given us: you can't say Ada is too complex any more! - Brian.Article: 154749
Tim Wescott wrote: > I have to admit, the biggest problem that I have as a C++ programmer when > writing in either VHDL or Verilog is envy: in both (IIRC) VHDL or Verilog, > when you have a module with a bazzilion input and output signals, you can > invoke it with a syntax something like > > module_name(module_signal_name = local_signal_name, ...) > > In C++, when, for reasons of utility, you are forced to design a class > whose constructor has a bazzilion inputs, you have to hold your breath, > close your eyes, cross your fingers, and hope that whoever uses that > constructor call gets all the right things in all the right places: I'd > Much Rather be able to invoke the syntax above and have it all self- > document. There's no need to hold your breath. You can still do that, and more, with C++, by employing the named parameter idiom. http://www.parashift.com/c++-faq/named-parameter-idiom.html Rui Maciel
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