Re: [myhdl-list] CHIP, a myhdl like project

[Jan D. <ja...@ja...>]

On 10/14/2011 05:25 PM, Martín Gaitán wrote:
> I was randomly browsing PyPi  when I found this project:
> http://dawsonjon.github.com/chips/
>
> Although (in a a not so deep review) it looks inmature compared with
> MyHDL, I wonder if the chip's author knows MyHDL and why not put his
> effort in order to improve this.
>
> Has somebody hear about this project and/or its author?

Yes, and I don't worry too much about it. I don't think
you are correct in saying that this is "MyHDL-like".

Recently, there have also been other sources of confusion
about the nature of MyHDL (and conversion), e.g. how it
relates to beasts like guarded atomic actions.

Let me therefore try to clarify some concepts.

There are several paradigms to construct "hardware
description" languages. One way, and the big winner
to date, is the event-driven paradigm. That is what
VHDL, Verilog and MyHDL have in common.

It is incorrect (although often done) to call such
languages "RTL" languages. Instead, RTL is
a semantic subset of such languages. There are
other ways to do RTL, but I'm convinced that this
is the single way to do it right.

The point to remember is that in MyHDL (and VHDL and
Verilog) events are the name of the game. Trying to
stuff in other paradigms will just lead to confusion.

Consider MyHDL conversion. What it does is to convert
an event-driven model into an equivalent event-driven
model. Conversion is "event accurate". Within this
constraint, it tries to automate as much as possible,
but that doesn't make it a synthesis tool. The goal
of conversion is to make sure that a MyHDL-based
design flow plays well with the mainstream event-driven
HDLs. Nothing more, nothing less.

In contrast, high-level synthesis can be defined as
a tool that creates an equivalent lower-level RTL
model without the constraint of "event accuracy". The
high-level input models may not be based on events at
all. The big difficulty with such tools is to
define clearly what "equivalent" means.

Unlike RTL, there are many potentially meaningful
ways to do high-level modeling/synthesis. For the user,
the most important concept is the modeling paradigm,
as implemented by the input language.

MyHDL could possibly be the input language of a high-level
synthesis tool based on high-level event-driven models.
However, this has been tried before with VHDL and Verilog
without a lot of success. This does not mean that MyHDL
has no role to play in high-level synthesis. On the
contrary: I believe that it is the ideal back-end language
for such tools: with the same effort, one can support
3 RTL back-ends instead of one, thanks to conversion.

Now consider CHIPS. It is clearly a high-level modeling/
synthesis attempt. The paradigm seems to be some kind of
stream-based modeling. No events in sight. Therefore,
it is not "MyHDL-like". The back-end is VHDL RTL, and
as I noticed before, I think MyHDL would have been a
better choice.

Whether this particular approach is useful is something
that everyone should judge for himself. Personally, I
don't see how it could be useful for the kind of
project I am doing. Moreover, in the very first paragraphs
of the rationale behind the project, the author makes
makes a few doubtful statements:

http://dawsonjon.github.com/chips/introduction/index.html#a-new-approach-to-device-design

* "A hardware model written in an imperative style cannot be synthesised"

This is wrong: an imperative style is actually very useful to describe
combinatorial and clocked RTL logic.

* "The primitive elements of an RTL design are clocked memory
   elements (registers) and combinational logic elements."

Actually, those are the primitive elements of a gate level
synthesized from RTL. In my view, the primitive elements in
RTL design are clocked processes (and an occasional combinatorial
process.) In particular, registers are inferred from behavior,
not implied or instantiated.

(Note: the name RTL is historical. For event-driven RTL as
we all are using, it is a misnomer.)

I agreed with the author that RTL is "low-level". However, it  is
definitely not as "low-level" as he suggests. If the starting
point is shaky, I don't have a lot of confidence in the "solution".

Jan

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com