Chisel as alternative HDL

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

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.

Stick with VHDL.  

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

  Pete  

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

"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 extr=
emely productive) on larger, more complex projects. If these principles and=
 techniques are not taught to HW students, any productivity increases obser=
ved 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 registe=
r; these are some gates.' approach to HDL-based design, or it does not matt=
er what language you use.

"My thoughts about risk: yes, there is a risk with using a new not yet esta=
blished 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 plan=
s, 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 lift=
ing 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-gen=
erated, intermediate language code, which is cross-referenced to the origin=
al 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 "elabor=
ated" before the conversion to the supported HDLs, which means that if you =
have a parameterizable source module (that could have been kept parameteriz=
ed in VHDL), you get a separate version of the HDL for every unique paramet=
erization, thus further stretching the already tenuous connection between t=
he source that is written, reviewed and maintained, and the HDL your synthe=
sis 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 sur=
vive, although OS project forking is a bad idea. Cheers, Martin"

The tool vendors are unlikely to support an HDL that has no controlled stan=
dard; it's too fluid a target to hit. Until it is controlled and tool-suppo=
rted, its real-world productivity gains are practically zero, if not negati=
ve.

Andy

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

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

"I have not found this to be an issue, mainly because I have no synthesis e=
rrors 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 co=
mpared 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.=20

But I get lots of synthesis "warnings" and "notes" about what is getting op=
timized out, what is being retimed, replicated, etc., even after a design s=
imulates correctly.

Simulating correctly and resulting in reliable hardware are not synonymous.

If you have no synthesis notes/warnings about signals/registers getting opt=
imized away, you are likely designing at an unproductively low level of abs=
traction.=20

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

Andy

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

Chris,

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

There are precious few efficient ways to confirm "completeness" of the desi=
gn verification effort.

I cross-check my synthesis warnings as a secondary confirmation that someth=
ing is not missed either in the design or in the verification. I can usuall=
y tell from the warning, and knowledge of the design, whether it is a poten=
tial problem or is acceptable/expected. I do not modify the design to elimi=
nate 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.=20

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 offse=
t by any improvmement in productivity provided by the alternative language.=
=20

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

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

Andy