Re: [myhdl-list] reusable blocks with different interfaces

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

On 01/19/2015 10:23 PM, Josy Boelen wrote:
> Christopher Felton <chris.felton <at> gmail.com> writes:
>
>>
>> <snip>
>>> Henry is talking about extending the interfaces concept of MyHDL.
> When
>>> converted to VHDL this would result in having structured types (e.g.
> a
>>> record) as ports.
>>
>> I don't think supporting conversion to VHDL records
>> would be a good idea.  Then the Verilog and VHDL
>> conversions would diverge.
>>
>> I don't believe I understand the use case?  Is this
>> intended to simplify wiring up modules (components)
>> after conversion?
>>
>> Regards,
>> Chris
>> <snip>
>
> Apparently I have a problem explaining things (and may now mess it up
> even more):
>
> If we elaborate on the interfaces concept, we can have interfaces (which
> I see as kind of records in records) nicely connecting up in MyHDL.
> Eventually we have to convert into VHDL and integrate it in our top
> level project. Now, in the Altera-world some we have Qsys to make live
> easy. Except that Qsys only understands std_logic and std_logic_vector.
> Say we now define an interface in MyHDL to represent a structured type
> we have to write a to_std_logic_vector() and a to_myinterface() (as I
> now do in VHDL whenever a define a record)  function to 'map' the one to
> the other and back. My expectation is that this could be handled
> automagically. This would save us from writing those 'wrapper modules'
> to use MyHDL originated modules with 'interfaces' in order to use them
> with Qsys (or Xilinx' IP Integrator?).
>
> Keeping VHDL on a leash to please Verilog is, IMHO, hampering MyHDL's
> progress and adoption. Maybe it is time to start a to_SystemVerilog() at
> the same time expanding to_VHDL()?

First, I am not following the logic in this post, and second, I don't
agree at all.

You say we "keep VHDL on a leash to please Verilog". But in the
paragraph before, you seem to ask for a MyHDL solution to work around
a VHDL, or at least a VHDL tool, limitation. That seems "pleasing VHDL"
to me.

Second, I don't see how MyHDL is limited by Verilog. It definitely is
limited by development time, that is for sure. But what you seem to
forget is that there are significant points where it improves both
on VHDL and Verilog. Integer handling, of course. Embedded scripting
can be just great.

It is not necessarily a good idea to support "more advanced" concepts
in the target language directly. For example:
VDHL has records, Verilog does not. Does this limit MyHDL? No - records
are themselves too limited, e.g. you cannot mix in/out in with the
same record. A more general concept, such as interfaces in MyHDL 0.9,
is much better I believe. And we can support that without requiring
something similar in the target language! How can that be bad?

How can assuming as little as possible from Verilog/VHDL hamper adoption?
The contrary must be true. Suppose we drop Verilog. The possible user
base drops immediately with more than half, and it is the half that
needs a more sensible solution most, and also the half that makes
the biggest chips and has most money. How can that be a good idea?

Let me be clear and honest: "adoption" for me means commericial
adoption. The kind of adoption that pays the bills. That has not
happened yet, at least not on the scale that satisfies me. (I am
jealous on everyone who can use MyHDL in current projects, but
lately that has not been my case. Doing interesting projects
though.) I cannot understand how limiting the target language
or putting constraints on it can bring me close to that goal -
I am not going to attract Google or Apple's interest by
concentrating on VHDL.

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