Chisel as alternative HDL

[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 <jonesandy@comcast.net> wrote:

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

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

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

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

Andy

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

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

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]

peter dudley <padudle@gmail.com> wrote:

Stick with VHDL.

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

Pete

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

 

[Christopher Felton]

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

"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

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, jonesandy@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

 

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

On 2/13/2013 3:43 PM, jonesandy@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

 

"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

 

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, jonesandy@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.

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

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

 

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



On 07/24/2014 10:07 AM, jgbreezer@gmail.com wrote:

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.

 

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