Chisel as alternative HDL

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

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

On Tuesday, January 8, 2013 6:15:30 AM UTC-2, David Brown wrote:
> On 08/01/13 03:06, Martin Schoeberl wrote:=20
> > MyHDL
> > Chisel
> > Lava
> > Gezel
> > JHDL
> > Confluence
> > HDCamel
>=20
> 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 Visual=
Works 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 t=
ext 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 > > Geze=
l > > JHDL > > Confluence > > HDCamel > > Be careful that both Confluence a=
nd 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 VisualWork=
s 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 dens=
e compared to text, but that just means we need better zooming and scrollin=
g. -- 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 t=
o my boss; "Software is moving forward from writing code to drawing picture=
s, why are we hell-bent for leather, moving in the opposite direction?!" Ye=
ars 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, implement=
ation, 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 t=
o productivity, reliability and maintainability in FPGA and ASIC developmen=
t.=20

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

Andy

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 fro=
m
> schematic entry to HDL based design entry for FPGAs. I ignorantly quipped
> to my boss; "Software is moving forward from writing code to drawing pict=
ures,
> why are we hell-bent for leather, moving in the opposite direction?!" Yea=
rs
> later, he handed me a copy of a page from one of his notebooks on which h=
e
> had written it down, much to my chagrin.

Schematics which could be unfolded on top of large desks were one thing, bu=
t schematics broken up into A4/letter sized pages with one block per page a=
nd 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 (ha=
ve you ever seen a good visual programming language?) and then we replaced =
the result with text.
=20
> 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 desig=
n
> 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.=20

As a Smalltalker, I have always considered these software tools an unfortun=
ate joke. But they are better than nothing and I have created my own system=
s (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 levera=
ge
> these same (or equivalently robust) technologies and practices? For insta=
nce,
> can a revision management system intelligently assist the user in merging
> multiple changes to a module, if that module was entered (and is maintain=
ed)
> in graphical form? Can it intelligently (and thoroughly) compare two revi=
sions
> of the design to see what changed, ignoring cosmetic changes? Can it comp=
are
> two modified revisions to their common ancester? These three examples app=
ly to
> only one of the several activities/technologies employed in the developme=
nt
> 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 complicat=
ions. Changing a pin in a library component which has both a schematic symb=
ol and a PCB layout, for example, is something a lot of tools don't get qui=
te right.

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

-- Jecel

On Jan 14, 11:25=A0pm, 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 des=
ign
> > entry for SW (though SW considers coding as implementation, not design)=
. We
> > (HW) have been able to leverage these SW technology/practices to immens=
e
> > benefit with regards to productivity, reliability and maintainability i=
n FPGA
> > and ASIC development.
>
> As a Smalltalker, I have always considered these software tools an unfort=
unate joke. But they are better than nothing and I have created my own syst=
ems (just because CVS, GIT and friends didn't exist when I did this) for th=
e C side.
>
> > Back to the subject at hand: How do graphical design entry methods leve=
rage
> > these same (or equivalently robust) technologies and practices? For ins=
tance,
> > can a revision management system intelligently assist the user in mergi=
ng
> > multiple changes to a module, if that module was entered (and is mainta=
ined)
> > in graphical form? Can it intelligently (and thoroughly) compare two re=
visions
> > of the design to see what changed, ignoring cosmetic changes? Can it co=
mpare
> > two modified revisions to their common ancester? These three examples a=
pply to
> > only one of the several activities/technologies employed in the develop=
ment
> > 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 complic=
ations. Changing a pin in a library component which has both a schematic sy=
mbol and a PCB layout, for example, is something a lot of tools don't get q=
uite 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 u=
sable.
>
> -- 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

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 Li=
nux. 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-o=
nly Verilog, they are essentially a netlist of very low level primitives th=
at they defined themselves. I found this very hard to understand compared t=
o a more behavioral and higher level description. It might have evolved fro=
m 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

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.

On Jan 16, 6:30=A0am, 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

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

> On Jan 16, 6:30=C2=A0am, 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.
>=20
> Thanks for the pointers on linux tools. Did you mean "RabbitVCS"?
>=20
> 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).
>=20
> Meld looks really good, and appears a little more mature.
>=20
> 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.

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