Chisel as alternative HDL

(snip, I wrote)

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.

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.

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

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:

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

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

language

wouldn't

example.

where

very

along

repository.

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.

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

- open source software seldom dies completely.

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

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.

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

MIPS

language

wouldn't

example.

where

very

along

repository.

FIFO

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.

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.

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

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?

Agreed.

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

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.

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:

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

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.

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

m

ures,

rs

e

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.

n

We

FPGA

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.

ge

nce,

ed)

sions

are

ly to

nt

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

ign

. We

e

n FPGA

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.

rage

tance,

ng

ined)

visions

mpare

pply to

ment

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

bad graphical tool, but if done well then the graphical one will be more u sable.

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

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.

Agreed.

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.

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

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.

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.

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