Chisel as alternative HDL

[Martin Schoeberl]

some snips

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, ... ?


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.

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

 

[Michael S]

On Dec 29 2012, 10:55 pm, Christopher Felton <a...@def.org> wrote:

On 12/28/12 11:25 PM, Martin Schoeberl wrote:









"garyr" <ga...@fidalgo.net> wrote:
"Martin Schoeberl" <mar...@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,
Chris

Can you list 2-3 most important productivity enhancements that MyHDL
gave you over VHDL?

 

[glen herrmannsfeldt]

Nico Coesel <nico@puntnl.niks> wrote:

(snip, I wrote)

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

That sounds like an assembly versus C discussion.

Maybe. But note that I said think. I believe that C programmers who
have previously written in assembler write better C than those who
haven't. (Well, maybe on average.)

Assembler programmers are more used to thinking in terms of addresses,
and so make better use of C pointers.

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.

Yes you don't need to optimize the last gate from a design, just
as you don't need to optimize the last instruction in assembler
or C programming. In a modular design, the lowest level modules
might need to be gate optimized, though likely not to the last gate.

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.

You still have to write something that the synthesizer can recognize.

As far as I know, there still aren't any C compilers that will optimize
a bubble-sort algorithm to quicksort, and there are definitely limits
to what the synthesizer can figure out.

But if you write verilog like you would C, it is likely that you
get lousy hardware.

-- glen

 

[Christopher Felton]

On 1/6/13 10:42 AM, Michael S wrote:

On Dec 29 2012, 10:55 pm, Christopher Felton <a...@def.org> wrote:
On 12/28/12 11:25 PM, Martin Schoeberl wrote:

"garyr" <ga...@fidalgo.net> wrote:
"Martin Schoeberl" <mar...@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,
Chris

Can you list 2-3 most important productivity enhancements that MyHDL
gave you over VHDL?

From my perspective, probably, the number one productivity
gain is access to the rich Python ecosystem. And this
theme will be repeated throughout this conversation.

_Ecosystem_. In my past, present, and future work I am
often developing algorithms and then implementing them
in digital circuits. Previously, before adopting the
Python/MyHDL methodology I would constantly be moving
from Matlab to the HDL of my employer (VHDL or Verilog).
I was always looking for ways to leverage the work I
did in the Matlab environment in the HDL environment
(i.e use the models and analysis with the HDLs). With
Python and MyHDL I can work in one environment and reuse
the algorithm, modeling, and analysis in the HDL development.
A simple example and some background described here:
http://www.fpgarelated.com/showarticle/7.php

Note, MyHDL is not an HLS it would be considered the same
level of modeling/abstraction as Verilog/VHDL.

_Verification_. For any decent size design this is always
an area of active interest. I have found verifying designs
with Python and MyHDL to be everything I want and need.
Also, in my experience when I need to find additional resources
for verification. In the cases where I have implemented my verification
environment in Python I have an easier time
getting SW or HW designers quickly proficient and contributing
without loss of quality.

_Modularity_. I have had fun and success, more so than the
V* in creating highly modular IP (modules, blocks, whatever
you want to call them). When doing this in Verilog/VHDL we
would always use another language in tandem to create the IP.
A customer would first use the Matlab/tcl/perl, whatever, to
first configure the IP and then the HDL would pop out. Now,
it is all simply done in Python with MyHDL.


Regards,
Chris

 

[Christopher Felton]

On 1/5/13 2:40 PM, Martin Schoeberl wrote:

some snips

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, ... ?


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.

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

I think one of the tricks, is you really want to have
a testbench/simulation to verify the design. Watching
folks over the years, it has mainly been those that
did not verify that had trouble in conversion.

For simple designs this might seem silly but it is
how you flush out, efficiently, simple errors when
learning.

Regards,
Chris

 

[David Brown]

On 04/01/13 19:25, Martin Schoeberl wrote:

Christopher Felton <nospam@nowhere.com> wrote:
On 1/4/2013 2:56 AM, David Brown wrote:
On 03/01/13 23:50, Martin Schoeberl wrote:
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,
Martin


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.



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, ... ?

I can agree with that. The paper is certainly enough to be an
inspiration that there are alternative languages, and that it is worth
looking at them - along with some ideas on how to do such a comparison.
But it is not a valid comparative paper on its own.

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

The biggest reason for it being hard, is that the question is not clear.
Ultimately, the question is "what is the best language for /me/, or
/my/ company, for /this/ project?". But it is quite possible to have
more general discussions, as long as no one expects /the/ answer to
/the/ question.

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.

I believe this is quite common. Many people use some sort of generator
- either more complete HDL's like MyHDL or Lava, or ad-hoc mixes of
perl, tcl, and other scripts to put together the VHDL or Verilog that is
used for the actual synthesis.


Many years ago, I used Confluence which was a functional programming
language for HDL development. I found it very natural to work with - it
was a lot more compact than either V*, and much easier to make sure
everything was correct (properly synchronise, registers exactly when I
wanted them, etc.), and good for testing. But it was very much a
one-man project - and when that man moved on, development and progress
stopped. It still exists (see the bottom of <http://tomahawkins.org/&gt
- open source software seldom dies completely.

 

[Martin Schoeberl]

Christopher Felton <abc@def.org> wrote:

On 1/5/13 2:40 PM, Martin Schoeberl wrote:
some snips

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, ... ?


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.

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


I think one of the tricks, is you really want to have
a testbench/simulation to verify the design. Watching
folks over the years, it has mainly been those that
did not verify that had trouble in conversion.

For simple designs this might seem silly but it is
how you flush out, efficiently, simple errors when
learning.

Regards,
Chris

Without a testbench I have the blinking LED running
in MyHDL now. Just some quirks of a beginner to fight
with. Don't know how one could do a decent testbench
for a blinking LED.

Now I will invest some more time on Phyton/MyHDL
learning and more interesting examples. I realise that
the MyHDL development is strongly based on test cases.
Which is quite good. In my impression it is also way
easier to do test benches in Python than in VHDL.

Cheers,
Martin

 

[Christopher Felton]

<snip>

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, ... ?


I can agree with that. The paper is certainly enough to be an
inspiration that there are alternative languages, and that it is worth
looking at them - along with some ideas on how to do such a comparison.
But it is not a valid comparative paper on its own.


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

The biggest reason for it being hard, is that the question is not clear.
Ultimately, the question is "what is the best language for /me/, or
/my/ company, for /this/ project?". But it is quite possible to have
more general discussions, as long as no one expects /the/ answer to
/the/ question.

Think most are agreeing, comparing languages is hard because it
typically is subjective by the user. And there hasn't been
many good examples of language comparisons. I think one good
thing the paper did was try to break it down to three, possibly,
objective points: /Conciseness/, /Comprehensibility/, and
/Reusability/. The paper did fail in the execution, that is,
defining a quantifiable approach for each of the defined
metrics. And it would have been better off getting examples
from each of the different gurus/communities.

A comparison study shouldn't say if language X, Y, or Z is
better but given a set of defined metrics how each language
measures. And this wouldn't be perfect either, this would
be similar to existing benchmarks. You need a suite of
benchmarks and try to flush out the ones that are tailored
for a specific design.

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.


I believe this is quite common. Many people use some sort of generator
- either more complete HDL's like MyHDL or Lava, or ad-hoc mixes of
perl, tcl, and other scripts to put together the VHDL or Verilog that is
used for the actual synthesis.

I don't know if I would call it a generator. You have
an HDL language and its goal is not to generate V* but it
is pragmatic to leverage existing tools so *converting*
to V* makes sense. I try to differentiate because, some
of the earlier tcl, perl, etc were intended to be generators
they were not intended to be an HDL. But things like MyHDL,
Lava, etc are HDLs and convert because it is practical.

Regards,
Chris

 

[Christopher Felton]

On 1/7/2013 1:59 AM, Martin Schoeberl wrote:

Christopher Felton <abc@def.org> wrote:
On 1/5/13 2:40 PM, Martin Schoeberl wrote:
some snips

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, ... ?


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.

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


I think one of the tricks, is you really want to have
a testbench/simulation to verify the design. Watching
folks over the years, it has mainly been those that
did not verify that had trouble in conversion.

For simple designs this might seem silly but it is
how you flush out, efficiently, simple errors when
learning.

Regards,
Chris

Without a testbench I have the blinking LED running
in MyHDL now. Just some quirks of a beginner to fight
with. Don't know how one could do a decent testbench
for a blinking LED.

Now I will invest some more time on Phyton/MyHDL
learning and more interesting examples. I realise that
the MyHDL development is strongly based on test cases.
Which is quite good. In my impression it is also way
easier to do test benches in Python than in VHDL.

Cheers,
Martin

I know it might seem silly to create a testbench
(or toggle bench) for a simple design. But while
learning it can give a lot of insight and help
avoid simple mistakes. Here is an example for
a simple LED toggle based off a counter.

http://pastebin.com/qPueFcsY

The test wasn't difficult to write and didn't
take a whole lot of time. But if I made a
simple typo or a mistake with a concept I didn't
quite understand it would help flush out those
issues in MyHDL sim rather than working through the
conversion then to the FPGA tools and hitting an
error somewhere along the process.

In addition you could also open up the waveform
in a waveform viewer and see things are working as
expected.

And yes, I realize you indicated you have the
blinky LED working with MyHDL and this is a moot
point for this particular instance but nonetheless
important.

Regards,
Chris

 

[Martin Schoeberl]

David Brown <david@westcontrol.removethisbit.com> wrote:

On 04/01/13 19:25, Martin Schoeberl wrote:
Christopher Felton <nospam@nowhere.com> wrote:
On 1/4/2013 2:56 AM, David Brown wrote:
On 03/01/13 23:50, Martin Schoeberl wrote:
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,
Martin


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.



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, ... ?


I can agree with that. The paper is certainly enough to be an
inspiration that there are alternative languages, and that it is worth
looking at them - along with some ideas on how to do such a comparison.
But it is not a valid comparative paper on its own.

Maybe we should also add how easy it is to learn the language.
Or if the language can be used to teach digital design at the
University.

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

The biggest reason for it being hard, is that the question is not clear.
Ultimately, the question is "what is the best language for /me/, or
/my/ company, for /this/ project?". But it is quite possible to have
more general discussions, as long as no one expects /the/ answer to
/the/ question.

Agree that there will probably be no /the/ language. But I don't want to
explore them to just find a language that fits just me.

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.


I believe this is quite common. Many people use some sort of generator
- either more complete HDL's like MyHDL or Lava, or ad-hoc mixes of
perl, tcl, and other scripts to put together the VHDL or Verilog that is
used for the actual synthesis.


Many years ago, I used Confluence which was a functional programming
language for HDL development. I found it very natural to work with - it
was a lot more compact than either V*, and much easier to make sure
everything was correct (properly synchronise, registers exactly when I
wanted them, etc.), and good for testing. But it was very much a
one-man project - and when that man moved on, development and progress
stopped. It still exists (see the bottom of <http://tomahawkins.org/&gt
- open source software seldom dies completely.

Wow, that adds another tow languages to my list. This little exploration
project looks like becoming a longer journey. Currently I have:

MyHDL
Chisel
Lava
Gezel
JHDL
Confluence
HDCamel

I think that would also mean I have to look at Python, Scala, Haskel, and
OCaml.

Cheers,
Martin

 

[David Brown]

On 07/01/13 14:12, Christopher Felton wrote:

snip

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, ... ?


I can agree with that. The paper is certainly enough to be an
inspiration that there are alternative languages, and that it is worth
looking at them - along with some ideas on how to do such a comparison.
But it is not a valid comparative paper on its own.


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

The biggest reason for it being hard, is that the question is not clear.
Ultimately, the question is "what is the best language for /me/, or
/my/ company, for /this/ project?". But it is quite possible to have
more general discussions, as long as no one expects /the/ answer to
/the/ question.

Think most are agreeing, comparing languages is hard because it
typically is subjective by the user. And there hasn't been
many good examples of language comparisons. I think one good
thing the paper did was try to break it down to three, possibly,
objective points: /Conciseness/, /Comprehensibility/, and
/Reusability/. The paper did fail in the execution, that is,
defining a quantifiable approach for each of the defined
metrics. And it would have been better off getting examples
from each of the different gurus/communities.

Breaking it down into objective points is good - but I think there are a
few other points that are perhaps equally important to the three
mentioned here.

One is "how easy is it to write correct code?", covering things like
ease of learning, syntax, etc., as well as how helpful it is in
encouraging good design (a language that takes a dozen lines to standard
features like clocking, async reset, and sync enable for a simple
register would fail here).

A second point is "how hard is it to write incorrect code?". This might
seem redundant giving the previous point, but it covers things like
warning messages and error reporting, syntax that avoids confusing
operators or syntax (hands up those who have never confused assignment
types in Verilog), and language features that make it difficult to write
code that is unlikely to be correct (it should be hard - but not
impossible - to code a latch, for example).

A third point is "how well can you test the code?" - including
simulation or testbenches within the tool itself.


Since any such languages work by generating a mainstream HDL (usually
Verilog and/or VHDL, but theoretically also others like System Verilog,
AHDL, etc.), it is also important to consider the way this is done. How
efficient is the generated code - do you end up using the same FPGA
resources at the same speed as hand-written V* ? How comprehensible is
the generated code - is it easy to relate to the source code, or is it a
single incomprehensible mess?

A comparison study shouldn't say if language X, Y, or Z is
better but given a set of defined metrics how each language
measures. And this wouldn't be perfect either, this would
be similar to existing benchmarks. You need a suite of
benchmarks and try to flush out the ones that are tailored
for a specific design.

Agreed.

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.


I believe this is quite common. Many people use some sort of generator
- either more complete HDL's like MyHDL or Lava, or ad-hoc mixes of
perl, tcl, and other scripts to put together the VHDL or Verilog that is
used for the actual synthesis.

I don't know if I would call it a generator. You have
an HDL language and its goal is not to generate V* but it
is pragmatic to leverage existing tools so *converting*
to V* makes sense. I try to differentiate because, some
of the earlier tcl, perl, etc were intended to be generators
they were not intended to be an HDL. But things like MyHDL,
Lava, etc are HDLs and convert because it is practical.

Fair enough - your terminology here is more accurate than mine.

Regards,
Chris

 

[David Brown]

On 08/01/13 03:06, Martin Schoeberl wrote:

David Brown <david@westcontrol.removethisbit.com> wrote:
On 04/01/13 19:25, Martin Schoeberl wrote:
snip

Many years ago, I used Confluence which was a functional programming
language for HDL development. I found it very natural to work with - it
was a lot more compact than either V*, and much easier to make sure
everything was correct (properly synchronise, registers exactly when I
wanted them, etc.), and good for testing. But it was very much a
one-man project - and when that man moved on, development and progress
stopped. It still exists (see the bottom of <http://tomahawkins.org/&gt
- open source software seldom dies completely.

Wow, that adds another tow languages to my list. This little exploration
project looks like becoming a longer journey. Currently I have:

MyHDL
Chisel
Lava
Gezel
JHDL
Confluence
HDCamel

I think that would also mean I have to look at Python, Scala, Haskel, and
OCaml.

Cheers,
Martin

OCaml and Haskel are both on my list of languages to learn. I already
use Python, but Scala hasn't made it to my list yet...

Be careful that both Confluence and HDCamel are "dead" languages - the
single developer has moved on. With enough enthusiasm, they could be
resurrected - the tools are all open source, so you can download the
code and use it, and you can build on them and improve them, and build a
new community around the development and use of the tools. But since
there is no longer an existing community, that would be no small job.
Of course, you can also consider them as finished tools - they do the
job they were supposed to do, and you can just use them like that.

 

[Jecel]

On Tuesday, January 8, 2013 6:15:30 AM UTC-2, David Brown wrote:

On 08/01/13 03:06, Martin Schoeberl wrote:
MyHDL
Chisel
Lava
Gezel
JHDL
Confluence
HDCamel

Be careful that both Confluence and HDCamel are "dead" languages - the
single developer has moved on.

I am not sure if this is also the case of IDaSS, which is written in VisualWorks Smalltalk and can generate VHDL and Verilog:

http://averschu.home.xs4all.nl/idass/

I am planning to do something very similar. I don't like to have to write text for things I understand more easily visually, like schematics and state machines. I know that graphical representations aren't very dense compared to text, but that just means we need better zooming and scrolling.

-- Jecel

 

On Sunday, January 13, 2013 4:58:07 PM UTC-6, Jecel wrote:

On Tuesday, January 8, 2013 6:15:30 AM UTC-2, David Brown wrote: > On 08/01/13 03:06, Martin Schoeberl wrote: > > MyHDL > > Chisel > > Lava > > Gezel > > JHDL > > Confluence > > HDCamel > > Be careful that both Confluence and HDCamel are "dead" languages - the > single developer has moved on. I am not sure if this is also the case of IDaSS, which is written in VisualWorks Smalltalk and can generate VHDL and Verilog: http://averschu.home.xs4all.nl/idass/ I am planning to do something very similar. I don't like to have to write text for things I understand more easily visually, like schematics and state machines. I know that graphical representations aren't very dense compared to text, but that just means we need better zooming and scrolling. -- Jecel

I remember way too many years ago when I was faced with transitioning from schematic entry to HDL based design entry for FPGAs. I ignorantly quipped to my boss; "Software is moving forward from writing code to drawing pictures, why are we hell-bent for leather, moving in the opposite direction?!" Years later, he handed me a copy of a page from one of his notebooks on which he had written it down, much to my chagrin.

The answer lies in the decades of developement of the all design, implementation, analysis, review, test and revision management technology/practices that have been developed to support code-based design entry for SW (though SW considers coding as implementation, not design). We (HW) have been able to leverage these SW technology/practices to immense benefit with regards to productivity, reliability and maintainability in FPGA and ASIC development.

Back to the subject at hand: How do graphical design entry methods leverage these same (or equivalently robust) technologies and practices? For instance, can a revision management system intelligently assist the user in merging multiple changes to a module, if that module was entered (and is maintained) in graphical form? Can it intelligently (and thoroughly) compare two revisions of the design to see what changed, ignoring cosmetic changes? Can it compare two modified revisions to their common ancester? These three examples apply to only one of the several activities/technologies employed in the development and mainenance of a product.

Andy

 

[Jecel]

On Monday, January 14, 2013 1:41:02 PM UTC-2, Andy wrote:

I remember way too many years ago when I was faced with transitioning from
schematic entry to HDL based design entry for FPGAs. I ignorantly quipped
to my boss; "Software is moving forward from writing code to drawing pictures,
why are we hell-bent for leather, moving in the opposite direction?!" Years
later, he handed me a copy of a page from one of his notebooks on which he
had written it down, much to my chagrin.

Schematics which could be unfolded on top of large desks were one thing, but schematics broken up into A4/letter sized pages with one block per page and labeled signals going to/from other pages are just very awkward netlists.. So I see it as a two step process - we first made drawings really bad (have you ever seen a good visual programming language?) and then we replaced the result with text.

The answer lies in the decades of developement of the all design,
implementation, analysis, review, test and revision management
technology/practices that have been developed to support code-based design
entry for SW (though SW considers coding as implementation, not design). We
(HW) have been able to leverage these SW technology/practices to immense
benefit with regards to productivity, reliability and maintainability in FPGA
and ASIC development.

As a Smalltalker, I have always considered these software tools an unfortunate joke. But they are better than nothing and I have created my own systems (just because CVS, GIT and friends didn't exist when I did this) for the C side.

Back to the subject at hand: How do graphical design entry methods leverage
these same (or equivalently robust) technologies and practices? For instance,
can a revision management system intelligently assist the user in merging
multiple changes to a module, if that module was entered (and is maintained)
in graphical form? Can it intelligently (and thoroughly) compare two revisions
of the design to see what changed, ignoring cosmetic changes? Can it compare
two modified revisions to their common ancester? These three examples apply to
only one of the several activities/technologies employed in the development
and mainenance of a product.

I don't think diff does such a good job of ignoring cosmetic differences in two text files. But you are correct that graphics add a level of complications. Changing a pin in a library component which has both a schematic symbol and a PCB layout, for example, is something a lot of tools don't get quite right.

So I think you can get further with a bad text implementation than with a bad graphical tool, but if done well then the graphical one will be more usable.

-- Jecel

 

[Andy]

On Jan 14, 11:25 pm, Jecel <je...@merlintec.com> wrote:

On Monday, January 14, 2013 1:41:02 PM UTC-2, Andy wrote:
The answer lies in the decades of developement of the all design,
implementation, analysis, review, test and revision management
technology/practices that have been developed to support code-based design
entry for SW (though SW considers coding as implementation, not design).. We
(HW) have been able to leverage these SW technology/practices to immense
benefit with regards to productivity, reliability and maintainability in FPGA
and ASIC development.

As a Smalltalker, I have always considered these software tools an unfortunate joke. But they are better than nothing and I have created my own systems (just because CVS, GIT and friends didn't exist when I did this) for the C side.

Back to the subject at hand: How do graphical design entry methods leverage
these same (or equivalently robust) technologies and practices? For instance,
can a revision management system intelligently assist the user in merging
multiple changes to a module, if that module was entered (and is maintained)
in graphical form? Can it intelligently (and thoroughly) compare two revisions
of the design to see what changed, ignoring cosmetic changes? Can it compare
two modified revisions to their common ancester? These three examples apply to
only one of the several activities/technologies employed in the development
and mainenance of a product.

I don't think diff does such a good job of ignoring cosmetic differences in two text files. But you are correct that graphics add a level of complications. Changing a pin in a library component which has both a schematic symbol and a PCB layout, for example, is something a lot of tools don't get quite right.

Diff (in CVS) does a horrible job! Try something capable like
BeyondCompare. Even the comparison capapilities in TortoiseSVN are
better than CVS/diff (I have not tried tortoiseCVS, it may be very
similar to tortoiseSVN).

So I think you can get further with a bad text implementation than with a bad graphical tool, but if done well then the graphical one will be more usable.

-- Jecel

Generally, if you work on a lot of small, one-man, one-off projects,
these capabilities may not interest you or make you more productive.
But when you work on large projects with several developers and a long
product life-cycles, these capabilities rise to the top.

Also, I think the relative preference of graphical/textual design
entry has a lot to do with your design style. If you tend to be a very
structural, concrete HW designer (e.g. if you think in terms of
circuit elements that will do what you want), the schematic paradigm
probably works great.

If on the other hand, you prefer designing at higher levels of
abstraction, and focus on the intended behavior of the design, along
with throughput and latency, then a textual paradigm works better.
Sure, there is still plenty of structure in even an abstract,
behavioral (yet synthesizeable) design of any size/complexity, but
abstracting interfaces using custom, aggregate data types (records,
arrays, arrays of arrays, arrays of records, etc.) reduces the
tediousness of the coding, and improves readability and
maintainability.

Andy

 

[Jecel]

On Tuesday, January 15, 2013 8:30:10 PM UTC-2, Andy wrote:

Diff (in CVS) does a horrible job! Try something capable like
BeyondCompare. Even the comparison capapilities in TortoiseSVN are
better than CVS/diff (I have not tried tortoiseCVS, it may be very
similar to tortoiseSVN).

Thanks for the tip. I was talking about the diff tools normally found in Linux. But my point was that while it is an easier problem to solve for text than for graphics, it isn't always well done for text and I hope I can get good results for graphics.

Generally, if you work on a lot of small, one-man, one-off projects,
these capabilities may not interest you or make you more productive.
But when you work on large projects with several developers and a long
product life-cycles, these capabilities rise to the top.

Agreed.

Also, I think the relative preference of graphical/textual design
entry has a lot to do with your design style. If you tend to be a very
structural, concrete HW designer (e.g. if you think in terms of
circuit elements that will do what you want), the schematic paradigm
probably works great.

Though the sources that Sun released for its various processors were text-only Verilog, they are essentially a netlist of very low level primitives that they defined themselves. I found this very hard to understand compared to a more behavioral and higher level description. It might have evolved from a previous visual development method, as you said.

If on the other hand, you prefer designing at higher levels of
abstraction, and focus on the intended behavior of the design, along
with throughput and latency, then a textual paradigm works better.
Sure, there is still plenty of structure in even an abstract,
behavioral (yet synthesizeable) design of any size/complexity, but
abstracting interfaces using custom, aggregate data types (records,
arrays, arrays of arrays, arrays of records, etc.) reduces the
tediousness of the coding, and improves readability and
maintainability.

While generators (parameterized IP in general, actually) are really awkward to represent visually, I don't think any of the things you mentioned is a problem that only text can solve.

-- Jecel

 

[David Brown]

On 16/01/13 06:35, Jecel wrote:

On Tuesday, January 15, 2013 8:30:10 PM UTC-2, Andy wrote:
Diff (in CVS) does a horrible job! Try something capable like
BeyondCompare. Even the comparison capapilities in TortoiseSVN are
better than CVS/diff (I have not tried tortoiseCVS, it may be very
similar to tortoiseSVN).

Thanks for the tip. I was talking about the diff tools normally found
in Linux. But my point was that while it is an easier problem to
solve for text than for graphics, it isn't always well done for text
and I hope I can get good results for graphics.

For graphics or other binary files, you are entirely dependent on
external programs. I know that Altium Designer has support for
subversion, and can show differences between schematic versions quite
well. And LibreOffice can be used to show differences between
documents. But for many types of graphics there is no good way to show
a difference.

For Linux, you can use RabbitSVN as a plug-in to Nautilus in much the
same way as TortoiseSVN in Windows, and Meld as a good gui for comparing
text files.

 

[Rob Gaddi]

On Wed, 16 Jan 2013 08:30:49 -0800 (PST)
Andy <jonesandy@comcast.net> wrote:

On Jan 16, 6:30 am, David Brown <da...@westcontrol.removethisbit.com
wrote:
For Linux, you can use RabbitSVN as a plug-in to Nautilus in much the
same way as TortoiseSVN in Windows, and Meld as a good gui for comparing
text files.

Thanks for the pointers on linux tools. Did you mean "RabbitVCS"?

RabbitVCS looks promising, but it is still version 0.15.1 (maybe a
little immature yet for professional use, e.g. something we would
deploy and recommend to the development teams).

Meld looks really good, and appears a little more mature.

Andy

Rabbit's definitely a bit immature if you want to compare it to
Tortoise. I find I still do half of my SVN management from the command
line rather than using it; thinks like copying and status checking.

I use meld as my visual diff tool, and it's absolutely great.

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.

 

[Andy]

On Jan 16, 6:30 am, David Brown <da...@westcontrol.removethisbit.com>
wrote:

For Linux, you can use RabbitSVN as a plug-in to Nautilus in much the
same way as TortoiseSVN in Windows, and Meld as a good gui for comparing
text files.

Thanks for the pointers on linux tools. Did you mean "RabbitVCS"?

RabbitVCS looks promising, but it is still version 0.15.1 (maybe a
little immature yet for professional use, e.g. something we would
deploy and recommend to the development teams).

Meld looks really good, and appears a little more mature.

Andy