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