myhdl-list

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

[Keerthan JC <jck...@gm...>]

VHDL records are not isomorphic to python objects or SV interfaces. A
VHDL record is similar to a SV struct.
There is no general way to convert MyHDL interfaces to VHDL records.
The way conversion currently works, you can think of attribute
references as pointers to Signals rather than Interface objects being
special datatypes.

wrt qsys, I don't understand how records simplify qsys components.
Could you share some example code with me?

On Tue, Jan 20, 2015 at 5:11 PM, Josy Boelen <jos...@gm...> wrote:
> Jan Decaluwe <jan <at> jandecaluwe.com> writes:
>
>>
>> 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
>>
>
> Obviously I conveyed my message wrong, but then I'm not that good a
> writer.
> First of all I'm big fan of MyHDL (I know you know.) I have mentally
> switched to MyHDL and started using it for our in-house
> projects/modules.
> But I see ways of improving MyHDL, some of them may perhaps be me-
> centered, but some of them will improve MyHDL's adoption.
>
> In one of the other messages I make my case for 2D (and even more-D)
> support. Python, and thus MyHDL's simulator, handles this perfectly but
> it doesn't convert. I assumed this was a limitation because it cannot be
> converted to Verilog because it is not handled (well) by Verilog as VHDL
> has no issue with this. If a true 2D-type cannot be converted to Verilog
> then there would be a case to expand the to_VHDL functionality, and a
> case for a to_SystemVerilog() module. Yes, that may leave Verilog users
> behind, but they would not loose any features. If I suggested on
> dropping Verilog (did I?) please accept my apologies.
>
> The other 'thread' is that interfaces certainly are what we want to use,
> but the FPGA tools only handle 'simple' types. So it would be nice if we
> could arrange the mapping when converting a top-level MyHDL module for
> use with those FPGA tools (saving us from writing wrappers to do this,
> as we currently have to). Maybe I'll have to accommodate that in another
> MyHDL support utility?
>
> Once again, I'm not a good writer, and this kind of 'thinking aloud'
> doesn't go well on paper. Perhaps we should find a reason to meet and
> enjoy a 'Mort Subite'?
>
> Best regards,
>
> Josy
>
>
>
>
>
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list



-- 
have a nice day
-jck

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

[Josy B. <jos...@gm...>]

Keerthan JC <jckeerthan <at> gmail.com> writes:

> 
> VHDL records are not isomorphic to python objects or SV interfaces. A
> VHDL record is similar to a SV struct.
> There is no general way to convert MyHDL interfaces to VHDL records.
> The way conversion currently works, you can think of attribute
> references as pointers to Signals rather than Interface objects being
> special datatypes.
> 
> wrt qsys, I don't understand how records simplify qsys components.
> Could you share some example code with me?
> <snip>

I'm *not* looking to convert MyHDL interfaces into VHDL records. You keep 
hanging on to that idea, but I never said so. My original question was:
Say we have used an interface in MyHDL to model a structured type in a 
module. The module will have to be usable both for import in other MyHDL 
modules, but also as a standalone component in Qsys. The interface works 
fine inside MyHDL. But we need to flatten this interface to a 
std_logic_vector for Qsys. Similar what a I do when using VHDL records: I 
write to_std_logic_vector( record_type_x r) and to_record_type_x( 
std_logic_vector v) functions. That was essentially my question in my first 
follow-up in this thread. I repeat it here:
<quote>
It would be nice if we also had a 'magic' way to export / import the 
interfaces as a std_logic_vector. As this is what Altera's Qsys 
understand. I doubt that Xilinx' IP Integrator will be any smarter.
</quote>
Perhaps I should have specified that it was about the *data* signal proper, 
not the global Sink or Source.
I have written several dozen Qsys components in VHDL and MyHDL and have 
done a mid-size MyHDL project using a Support Vector Machine (6700 lines of 
generated VHDL).

I'll post code on Github, later ...

Best regards,

Josy

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

[Christopher F. <chr...@gm...>]

<snip>
>
> I'll post code on Github, later ...

@Josy, the VHDL code you posted on github is
the hand generated version, correct?  Where in
the code is the example/situation being discussed?

Read a quote from Conway the other day: "to be
a great Mathematician one should be thinking
about six (at least) things at a time" (summarized).

Not so sure about that, because I should benefit
more from my lack of attention to any one thing :)

Regard,
Chris

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

[Josy B. <jos...@gm...>]

Christopher Felton <chris.felton <at> gmail.com> writes:


>  <at> Josy, the VHDL code you posted on github is
> the hand generated version, correct?  Where in
> the code is the example/situation being discussed?
> 
> Read a quote from Conway the other day: "to be
> a great Mathematician one should be thinking
> about six (at least) things at a time" (summarized).
> 
> Not so sure about that, because I should benefit
> more from my lack of attention to any one thing :)
> 
> Regard,
> Chris
><snip>

The posted code is indeed the hand-crafted one. I re-started on the 
MyHDL translation, but I got stuck on one VHDL construct I cannot 
emulate in MyHDL, so I had to rethink the strategy.
I've added the 'unpolished' MyHDL version to Github.
One note already: I made a few conversion functions, and MyHDL 
duplicates one of them 8 times for every cell, making for a very large 
VHDL IR (18000 lines for a 16 by 9 cell array).
Second note: this is an excellent example to show Henry Gomersall's 
concern for expanding the *enum* functionality. The *pygol* code will 
not convert because: to convert the following
    def to_gol_states( l ):
        if l:
            return  gol_states.ALIVE
        else:
           return gol_states.DEAD

MyHDl has to write:
    function to_gol_states( l : stdLogic ) return **gol_states** is
        ...
but breaks away with:
    AttributeError: 'vhd_enum' object has no attribute 'toStr'

Compare the VHDL and the MyHDL source, and tell me what you think?

Best regards,

Josy