Re: [myhdl-list] My take on MyHDL weaknesses - and solutions

[Ben <ben...@gm...>]

On Mon, Apr 4, 2011 at 15:20, Christopher Felton <chr...@gm...> wrote:
> On 4/4/2011 4:10 AM, Ben wrote:
>> On Mon, Apr 4, 2011 at 11:00, Jan Decaluwe<ja...@ja...>  wrote:
>>> Lack of killer features
>>> -----------------------
>>> The benefits of MyHDL are real but they remain somewhat
>>> abstract, e.g. "managing complexity".
>>>
>>> Solution: a strong value proposition would be concrete
>>> features that many hardware designers want but that are not
>>> offered by their current tools. I have two things in mind
>>> currently: a good fixed-point class with transparent support
>>> by the convertor, and SystemVerilog-style interfaces in
>>> MyHDL that could be converted to VHDL and Verilog, that don't
>>> have something similar.
>>>
>>
>> For the records, I have another one for this list: native (as in
>> "integrated in the language") support for asynchronous communication
>> channels. I'm quite certain, this would have its place in MyHDL,
>> however, my way of tackling this beast down is not established yet ...
>> I'd be glad to hear your views on this !
>>
>
> Are you thinking something similar to Balsa or CSP type language?  Like
> many of the other topics (fixed-point, floating-point, etc) I believe
> this can be an add-on module, just like MyHDL is an add-on to Python.
> Or at least these additional "features" should be separated so that the
> focus/goals of MyHDL is crystal clear.  The goals of the add-on features
> is crystal clear.
>
> If you use the MyHDL framework and follow the Python/MyHDL design
> philosophy I think ASYNC decorators can be created.  But it would
> require someone interested in this topic to spearhead the efforts.
>
> Given my limited understanding of ASYNC communication channels, you
> could implemented the standard 2 or 4 rail channels in MyHDL today (as
> you could with Verilog/VHDL).  But to make it a little easier on a ASYNC
> designer you would want to make this transparent.  Using the decorator
> approach you could construct something like
>
> @always_async(ch1)
> ...
>
> I am completely sticking my neck out here.  But I think this is the type
> of support you would be looking for?
>

That's pretty much what I thought of, yes. I would't include it inside
MyHDL core, even if we need some way to advertise those modules (like
the fixed-point or floating-point one, ...). Hidden on a page of the
wiki doesn't sounds enough to me ... Maybe add a chapter about them in
the tutorial so that everyone reading it get an idea of how those
modules work and know where to come back when he fells that he needs
them ...

My interface is pretty much defined: I would introduce a `Channel`
type, call my decorator `@receive` that would take a channel as
parameter and it would wait for the sender to be ready, execute the
function and indicate to the sender that the processing is done. My
channel type would also have a `send` method that would wait for the
receiver to be ready, send the value and wait for the receiver to be
done. The channel value could only be read inside a receive block and
so on ...

As of today, all kinds of tools exists for that, they are pretty much
new languages developed for this purpose. The advantage of using
Python (MyHDL) for such a design is self explanatory !

Regards
Benoit