Chisel as alternative HDL

Hi all,

started to look into alternatives to Verilog and VHDL and stumbled over chisel from UCB:

formatting link

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 ;-)

Reply to
Martin Schoeberl
Loading thread data ...

You might find this interesting:

formatting link

Reply to
garyr

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

Reply to
Martin Schoeberl

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

Reply to
Jon Elson

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, Chris

Reply to
Christopher Felton

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.

Martin

Reply to
Martin Schoeberl

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

Reply to
Jon Elson

You might be interested in this rebuttal to a paper that compared a couple non-traditional HDLs.

formatting link

Regards, Chris

Reply to
Christopher Felton

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

Reply to
Martin Schoeberl

I believe this is the original paper:

formatting link

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

Reply to
Christopher Felton

formatting link

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, Martin

Reply to
Martin Schoeberl

example.

along

repository.

formatting link

It is also worth noting that this "paper" seems to be just a student exercise that has somehow "escaped" into public domain - it makes no claims about trying to compare a realistic choice of languages. A HDL language comparison that doesn't even include Verilog cannot be taken seriously. I'm sure the student gave a good answer to the question his teacher posed, but don't read more into it than that.

Reply to
David Brown

example.

where

very

along

repository.

formatting link

As you note, student paper escaped. But I do think it would be reasonable to use only VHDL or Verilog when comparing the plethora of alternative HDLs. I believe the author was trying to explore non-traditional HDLs (i.e. other than V*).

I don't think many would simply accept the conclusions but it is a starting point for a conversation: how to compare HDLs? How would one objectively quantify different HDLs. What is being determined: speed of design entry, maintenance, QoR, testabilty, ... ?

Regards, Chris

Reply to
Christopher Felton

The problem with that approach is that you need to be proficient in all the languages you try. Usually this isn't the case so language comparisons are mostly useless. I'd stick to VHDL and learn how to use it more efficiently. IMHO very few people are using the full potential VHDL is offering. A lot of people still think in gates and counters and produce netlists instead of an abstract description of what they want to implement.

My prediction: The only HDL which will replace VDHL and Verilog has to be based on a C style syntax. Look at C#, Java, PHP. All these languages have gained a lot of popularity because it is based on what people already know.

--
Failure does not prove something is impossible, failure simply 
indicates you are not using the right tools... 
 Click to see the full signature
Reply to
Nico Coesel

I always struggle with the "C" HDL replacements. It seems like you are going the wrong direction in abstraction and ease of use language.

But your argument is: There are many "C" programmers and/or folks that feel comfortable with "C" style programming. If someone can create a magical "C" like HDL language many will jump aboard ... hmmmmm

Regards, Chris

Reply to
Christopher Felton

(snip)

My belief for some time has been that you have to think in terms of gates and counters or you write lousy HDL code.

I suppose it depends somewhat on what type of designs you are working on.

For most of what I am interested in, making it look too much like C might give people the idea that you could port a C algorithm without any thought, but the algorithms that I am interested in are completely different in systolic array hardware than in loops over arrays.

-- glen

Reply to
glen herrmannsfeldt

(snip)

Verilog isn't quite as C-like as I might think it could be.

I learned many years ago the difference between Pascal (semicolon is a statement separator) and most other languages such as PL/I and C (semicolon is a statement terminator).

Seems to me that verilog could have done its semicolon rules a little differently to make it more obvious to C programmers.

-- glen

Reply to
glen herrmannsfeldt

wouldn't

example.

where

very

along

repository.

formatting link

Yes, this is not an easy question. However, this is also a reason to attack this question. Maybe by some discussions here.

I personally want to explore alternatives ti VHDL and Verilog. I think it is time for new languages, now. We still use V*, but now as intermediate language to feed the design tools.

Cheers, Martin

Reply to
Martin Schoeberl

some snips

Some status update: having now the BeMicro FPGA board up and running for comparison in HW. It does blink nicely in VHDL ;-)

Next step MyHDL. Don't know jet if I like this dynamic typing. Hello world simulation was a very quick start! Getting MyHdL in to HW was always tricky, However, using V* as an intermediate language might be a quite good idea.

Cheers, Martin

Reply to
Martin Schoeberl

That sounds like an assembly versus C discussion. In reality designs get so big these days that hand optimising the last gate from a design costs way more than using a bigger FPGA or ASIC. Besides that a high level language usually offers a more structured approach which should result in better maintainability, platform independance, re-usability, etc. Just let the synthesizer deal with platform specifics and optimisation.

--
Failure does not prove something is impossible, failure simply 
indicates you are not using the right tools... 
 Click to see the full signature
Reply to
Nico Coesel

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.