Chisel as alternative HDL

[Martin Schoeberl]

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

[garyr]

"Martin Schoeberl" <mar...@jopdesign.com> wrote in message
news:1621424063378432030.694...@reader.albasani.net...

You might find this interesting: http://www.myhdl.org

[Martin Schoeberl]

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

[Jon Elson]

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

[Christopher Felton]

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

[Martin Schoeberl]

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

[Jon Elson]

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

[Christopher Felton]

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

[Martin Schoeberl]

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

[Christopher Felton]

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

[Martin Schoeberl]

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

[David Brown]

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.

[Paul Colin Gloster]

On 2013-01-04, David Brown <da...@westcontrol.removethisbit.com>
sent:
|-----------------------------------------------------------------------|
|"[. . .] |

| |
|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." |

|-----------------------------------------------------------------------|

Verilog is ignored in many publications produced by a lot of so-called
research in Europe.

Yours sincerely,
Colin Paul Gloster

[Christopher Felton]

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

[Nico Coesel]

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...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

[Christopher Felton]

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

[glen herrmannsfeldt]

Nico Coesel <ni...@puntnl.niks> wrote:
> Martin Schoeberl <mar...@jopdesign.com> wrote:

(snip)

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

> 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 belief for some time has been that you have to think in terms of
gates and counters or you write lousy HDL code.

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

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

[glen herrmannsfeldt]

Christopher Felton <nos...@nowhere.com> wrote:

(snip)

> 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

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

[Martin Schoeberl]

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

[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

[Nico Coesel]

glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

>Nico Coesel <ni...@puntnl.niks> wrote:
>> Martin Schoeberl <mar...@jopdesign.com> wrote:
>
>(snip)
>>>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.
>
>> 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 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. 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.

[Michael S]

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

[glen herrmannsfeldt]

Nico Coesel <ni...@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]

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]

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

[Martin Schoeberl]

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

[David Brown]

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/>)
- open source software seldom dies completely.

[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]

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]

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/>)
> - 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]

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 <da...@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/>)
>> - 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

[jone...@comcast.net]

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]

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.

[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

[Rob Gaddi]

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]

I'm not saying there are things you "can't" do in graphical entry, or
that only text entry can do, just that there are lots of things that
are (much) better done in text.

When you are dealing with HDL issues, there is a standard of
compliance (well, at least a workable one with VHDL), whereas there is
no non-proprietary standard for graphical entry representations or
file formats, except at the final output stage (an HDL).

If my "source" is in some proprietary tool's format, and that tool
goes away, it is extremely unlikely that any other tool will be able
to use any of what I had relied upon as my "source". Which means I
would be managing the machine-generated text as the "source" for
successive modifications/versions of the product. I'll put well
written, human-generated code up against machine-generated code
(that's why we have coding standards) for understandability and
maintainability any day of the week and twice on Sundays!

On the other hand, as long at the graphical tool generates standard
HDL, there are a lot of textual analysis tools that can still be
employed on the results. The only difference is, they would not be
dealing with the "source", and finding/translating and fixing issues
found by analyzing the outputs of the graphical entry system is, if
even possible, not usually nearly as straight-forward as when the
analyzed text IS the source.

Perhaps a different approach would be to use text as the source, and
various tools to provide graphical representations (of different
aspects) of the design for documentation to assist human analyses/
review (e.g. a hierarchy viewer, a state machine viewer, etc.) I find
the visualization tools in the Syplify Pro HDL Analyst RTL view,
especially with the ability to filter the output by several different
criteria, to be extremely helpful in understanding how that downstream
tool "sees" various aspects of my design. This is one of the reasons I
prefer behavioral design descriptions rather than highly structural
ones: there are tools that will show me the resulting structure from
my behavioral descriptoin, but there are few tools that will show me
the behavior (as other than simulation waveforms) from a highly
strucural description.

Andy

[David Brown]

On 16/01/13 18:19, Rob Gaddi wrote:
> On Wed, 16 Jan 2013 08:30:49 -0800 (PST)
> Andy <jone...@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.
>

Rabbit does not have as many features as Tortoise, but don't be put off
by the version number. Many programs and projects are fully usable
despite low version numbers - while others use high version numbers for
their initial releases.

I find Rabbit more reliable than Tortoise at getting the overlay icons
correct, but maybe that's just Nautilus being more consistent and
accurate than Windows Explorer. But there is no doubt that Tortoise has
lots more useful subversion features.

I also do much of my subversion stuff from the command line, both in
Windows and Linux - and also some from within programs with svn support
(such as Eclipse). But Rabbit and Tortoise are very good for quickly
viewing the state of files, as well as getting logs and differences.

[peter dudley]

Stick with VHDL.

You will have to type till your fingers go numb but once something is designed, it stays designed.

Pete

[Martin Schoeberl]

Mmh, I'm more and more getting into the chisel thing. I like it and maybe
this gives me (and others, like my students) a productivity boost.

My thoughts about risk: yes, there is a risk with using a new not yet
established language. However, three arguments against being afraid: (1) it
is the design and not the description that counts. If you need to drop a
tool/language, rewriting your design in a new language is not that much
work. (2) it uses Verilog as intermediate language. So the synthesize heavy
lifting is done by the well established tools in a well established
language. (3) it is open source. You can always contribute patches to the
project to fix issues. If they are ignored you can still fork for your
project to survive, although OS project forking is a bad idea.

Cheers,
Martin

[jone...@comcast.net]

"Mmh, I'm more and more getting into the chisel thing. I like it and maybe this gives me (and others, like my students) a productivity boost."

Martin,

I'd rather universities teach students how to get more productivity out of the existing, standard, tool-supported HDLs. The status quo, perhaps due to the required simplicity of class projects, is typically an HDL description written at barely above the netlist level anyway. Very little attention is typically paid to SW engineering principles that become critical (and extremely productive) on larger, more complex projects. If these principles and techniques are not taught to HW students, any productivity increases observed while merely changing languages will be marginal at best. At some point, the level of abstraction has to get beyond the current 'This is a register; these are some gates.' approach to HDL-based design, or it does not matter what language you use.

"My thoughts about risk: yes, there is a risk with using a new not yet established language. However, three arguments against being afraid: (1) it is the design and not the description that counts. If you need to drop a tool/language, rewriting your design in a new language is not that much work."

Does that "not much work" include re-writing your development processes and procedures, coding and review standards, development and verification plans, not to mention test benches? And is this true for most designs, or just the typical class project level designs?

"(2) it uses Verilog as intermediate language. So the synthesize heavy lifting is done by the well established tools in a well established language."

So when you get a synthesis error/warning, it refers you to the machine-generated, intermediate language code, which is cross-referenced to the original source code how?

MyHDL takes this same approach (it actually produces both VHDL and Verilog to support synthesis and other tools). However, the MyHDL source is "elaborated" before the conversion to the supported HDLs, which means that if you have a parameterizable source module (that could have been kept parameterized in VHDL), you get a separate version of the HDL for every unique parameterization, thus further stretching the already tenuous connection between the source that is written, reviewed and maintained, and the HDL your synthesis tool is warning you about.

"(3) it is open source. You can always contribute patches to the project to fix issues. If they are ignored you can still fork for your project to survive, although OS project forking is a bad idea. Cheers, Martin"

The tool vendors are unlikely to support an HDL that has no controlled standard; it's too fluid a target to hit. Until it is controlled and tool-supported, its real-world productivity gains are practically zero, if not negative.

Andy

[Christopher Felton]

No way, if they learn how to design and architect complex
digital systems and are able to implement them successfully,
regardless of the tool, I think the students will be prepared
(this depends a lot on the definition of "successfully").

Of course the students will have a learning curve changing HDLs.
But at this point they should have a good idea what the tools
provide and do not provide. The greater risk is they will be
frustrated not having the power and will quit :)

Regards,
Chris

[Christopher Felton]

On 2/13/2013 1:35 PM, jone...@comcast.net wrote:

<snip>

> MyHDL takes this same approach (it actually produces both VHDL and Verilog to support synthesis and other tools). However, the MyHDL source is "elaborated" before the conversion to the supported HDLs, which means that if you have a parameterizable source module (that could have been kept parameterized in VHDL), you get a separate version of the HDL for every unique parameterization, thus further stretching the already tenuous connection between the source that is written, reviewed and maintained, and the HDL your synthesis tool is warning you about.
>
> "(3) it is open source. You can always contribute patches to the project to fix issues. If they are ignored you can still fork for your project to survive, although OS project forking is a bad idea. Cheers, Martin"
>
> The tool vendors are unlikely to support an HDL that has no controlled standard; it's too fluid a target to hit. Until it is controlled and tool-supported, its real-world productivity gains are practically zero, if not negative.
>
> Andy
>

I have not found this to be an issue, mainly because
I have no synthesis errors after simulating and
cosimulating, the design works as expected. Yes, if
for some reason you had many synthesis error tracing
back would be more work than tracing to the Verilog/
VHDL source but I think it is minimal compared to
the simulation and verification gains.

Regards,
Chris

[jone...@comcast.net]

"I have not found this to be an issue, mainly because I have no synthesis errors after simulating and cosimulating, the design works as expected. Yes, if for some reason you had many synthesis error tracing back would be more work than tracing to the Verilog/ VHDL source but I think it is minimal compared to the simulation and verification gains. Regards, Chris"

Chris,

I get very few synthesis "errors" during synthesis, and none by the time I'm finished.

But I get lots of synthesis "warnings" and "notes" about what is getting optimized out, what is being retimed, replicated, etc., even after a design simulates correctly.

Simulating correctly and resulting in reliable hardware are not synonymous.

If you have no synthesis notes/warnings about signals/registers getting optimized away, you are likely designing at an unproductively low level of abstraction.

When you simulate, are you simulating in the source language, or the intermediate RTL? If at the intermediate RTL level, how are you tracing simulation errors back to your source? If at the source level, how are you simulating post-synthesis/P&R (gate level sims) with the same testbench?

Andy

[Christopher Felton]

On 2/13/2013 3:43 PM, jone...@comcast.net wrote:
> "I have not found this to be an issue, mainly because I have no
> synthesis errors after simulating and cosimulating, the design
> works as expected. Yes, if for some reason you had many synthesis
> error tracing back would be more work than tracing to the
> Verilog/ VHDL source but I think it is minimal compared to the
> simulation and verification gains. Regards, Chris"
>
> Chris,
>
> I get very few synthesis "errors" during synthesis, and none by the time I'm finished.
>
> But I get lots of synthesis "warnings" and "notes" about what is getting optimized out, what is being retimed, replicated, etc., even after a design simulates correctly.

Impossible not to get millions of notes and warnings,
the behavior of my final circuits match the behavior
of my descriptions, they work in the field no complaints
thus far.

>
> Simulating correctly and resulting in reliable hardware are not synonymous.

I agree but two ASICs and a dozen successful FPGAs
says what needs to be checked is checked and attention
where attention is required.

>
> If you have no synthesis notes/warnings about signals/registers getting optimized away,

As stated above, with all FPGA tools it is virtually
impossible not to get numerous warnings and errors.
As long as the tools don't change the behavior they
can optimize away.

> "you are likely designing at an unproductively low level of abstraction."

I doubt that!

>
> When you simulate, are you simulating in the source language, or the intermediate RTL? If at the intermediate RTL level, how are you tracing simulation errors back to your source? If at the source level, how are you simulating post-synthesis/P&R (gate level sims) with the same testbench?

I am simulating the source and cosimulating (meaning
using my high-level HDL with the converted and/or
synthesized HDL) and using the high-level verification
environment to verify the converted matches the source.
Optionally, will verify the post P&R (more so with the
ASIC flow less so with FPGA). I am also able to leverage
the same verification code in the lab, the code that
tested the models also tests the logic in the lab.

>
> Andy
>
>
>

[jone...@comcast.net]

Chris,

Do you ignore synthesis notes and warnings, or do you cross-check at least some of them?

There are precious few efficient ways to confirm "completeness" of the design verification effort.

I cross-check my synthesis warnings as a secondary confirmation that something is not missed either in the design or in the verification. I can usually tell from the warning, and knowledge of the design, whether it is a potential problem or is acceptable/expected. I do not modify the design to eliminate acceptable/expected warnings (that would require designing at too low a level of abstraction). It still takes a lot of time, but it has been very effective, not only as a secondary confirmation of verification, but also as an indication of where/not to improve performance or utilization to meet requirements.

If I used an alternative HDL as source, then I'd have to trace the warnings I could not immediately resolve back through the intermediate code to the source. That takes more time, and from what I have seen, would not be offset by any improvmement in productivity provided by the alternative language.

If I used verilog, I might have a different opinion.

However, where other languages, perhaps including these alternative HDLs, may be more helpful is in the verification of the HDL design, regardless of the HDL used (traditional or alternative).

Andy

[Christopher Felton]

On 2/14/2013 1:14 PM, jone...@comcast.net wrote:
> Chris,
>
> Do you ignore synthesis notes and warnings, or do you cross-check at least some of them?

No I don't ignore them, they are reviewed and certain ones
are interrogated if deemed important. And determining if
they are important is decided by the design engineer,
same as you, they are aware of the design and "no problemo"
referring back to the original source, if needed.

In this case the alternative HDL used is MyHDL, and MyHDL
-in my experience- does not mangle the source enough to
prohibit tracing back. As you indicated, it does have an
"elaboration" phase but this has not been an issue (tracing
back the generated VHDL or Verilog).

I agree, the alternative HDL (because they are typically
based on as general purpose high-level language) are ideal
for modeling and verification. The V*s will always lag the
other languages for general features.

Regards,
Chris

[jgbr...@gmail.com]

On Saturday, 29 December 2012 00:06:20 UTC, Martin Schoeberl wrote (with slightly less compacted blank-lines than this):
> 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 ;-)


I haven't seen mention of PSHDL (pshdl.org) which I have recently come across via a talk at CCC (German conference), is this worthy of consideration also? Seems it is/can be converted into one of (/both?) the V* languages for end-use and is aiming to make it easier to learn for beginners (like myself).

John.

[Stevo Bailey]

Hi all,

I'm a Berkeley PhD student who has worked extensively with Chisel both
in classes and research. I love it, though I did not have much
experience with anything else before starting on it. A common
description for Chisel I use is "hardware at the word level". It allows
for n-dimensional arrays of hardware (wires, gates, modules, whatever).
We call it a hardware construction language because it can generate an
array of different architectures by changing the input parameters.
Another benefit is the cycle-accurate C++ tester, which allows for fast
design verification. You do need to learn Chisel and Scala, though they
have many similarities. Learning Verilog isn't necessary unless you want
to post-process the output for some reason. So maybe it involves only
learning 1.5 new languages! There is no VHDL support, nor talk of
including it.

To attempt remaining unbiased, I'd also like to mention MyHDL, which is
an HDL built on Python (a language people are generally more familiar
with). If your fear is learning new languages, this might be a good
alternative. I know nothing about it save its existence.

Thanks!
Stevo

[charles....@gmail.com]

I have use Chisel for 2 projects with some complexity and a lot of clock domain.

The first is a real time simulator that is able to simulate in real time electrical network. Project has some AD/DA, hundreds of processing core, AXI master/slave, DDR3, multiple clock domain.
The second was a Mandelbrot accelerator with 8 pipelined cores that fill DDR3 frame buffer and have a UART control link.

Good part of Chisel :
- increase productivity
- Genericity unlocked
- Scala possibilities
- Check logic loop and don't allow latch

Bad part of chisel :
- Multi clock support is really not well designed. Usable but very bad
- Don't handle conditional blocks on combinatorial signals correctly
- Don't allow to do ranged assignments on signals: myBits(3 downto 2) <= XX
- Has a poor support of black box, especially with multi clock design
- Integrated simulator is bad because it don't allow serious verification and slow down the global evolution of chisel library
- Enum support is not native and is not well designed
- Generated Verilog is understandable but with pain
- The project has lived and seems stalled (Github) in the fix of his fundamental issue
- You can't use asynchronous reset, only synchronous
- Ram support don't fit very well with FPGA (Write to Read)

To resume, I had lot of fun with Chisel, Chisel is lot better than VHDL/Verilog in lot of aspect, but is not clean, and I think it never become clean. It's realy cool for basic project, but when come multi clock, custom reset and blackbox it's a pain.


It's the reason why, some month ago, i have start the development of a new HDL language (SpinalHDL), inspired by chisel but without his bad parts. The actual state of the development is really good from my point of view. Need more test of course, but has all major part implemented and functional.

The implementation of UART controller, Single and dual clock FIFO was done and tested with success. And I'm now looking to enthusiastic people to test/critic/contribute to this new language :)

The git is here: https://github.com/SpinalHDL/SpinalHDL
There is 2 example in the readme, more into the lib/ and the test/

If you are interested to contribute to SpinalHDL, tell me.

Best regards