myhdl-list

[myhdl-list] reusable blocks with different interfaces

[Henry G. <he...@ca...>]

At risk of asking an XY problem (in which I describe a different problem 
to the more fundamental one), I would like to know if it is possible 
with MyHDL 0.9 to define a reusable convertible block that does 
something like the following:

from myhdl import *

class Interface(object):
     def __init__(self):
         self.a = Signal(intbv(0)[5:])
         self.b = Signal(intbv(0)[7:])

def block_factory(input_interface, output_interface, clock, reset):

     @always_seq(clock.posedge, reset)
     def block():
         output_interface.next = input_interface

     return block

foo = Interface()
bar = Interface()
clock = Signal(bool(1))
reset = ResetSignal(bool(0), active=1, async=False)

toVerilog(block_factory, foo, bar, clock, reset)

Running this yields "Object type is not supported in this context: 
output_interface".

Now, my use case for this is to create a block that takes an interface 
as its argument, and from which I can create a buffer (or a small FIFO) 
of the attributes defined by the interface. The point is to match the 
propagation of state information alongside data processing inside a 
pipeline.

The problem is that although the interface for every instantiation is 
known at conversion time, it is not necessarily known when I create the 
factory. Short of creating an uber-interface with every possible state 
signal in there, I can't see how to do this.

Obviously, I could create a different block for every interface, but I 
was wondering if I could avoid that.

I've considered other options like creating a single bit vector 
containing all the same info as the Interface, but this seems rather 
backwards.

I feel there must be a solution here!

Cheers,

Henry

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

[Henry G. <he...@ca...>]

On 15/01/15 19:15, Henry Gomersall wrote:
>       @always_seq(clock.posedge, reset)
>       def block():
>           output_interface.next = input_interface

To be clear the important line is above. I want to assign a whole 
interface at once, without reference to its attributes.

Henry

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

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

<resending ???>
On 1/15/2015 1:17 PM, Henry Gomersall wrote:
> On 15/01/15 19:15, Henry Gomersall wrote:
>>        @always_seq(clock.posedge, reset)
>>        def block():
>>            output_interface.next = input_interface
>
> To be clear the important line is above. I want to assign a whole
> interface at once, without reference to its attributes.
>

But there are other ways to achieve this, the elaboration
phase (outside the generator).  The following is an example.
*NOTE*, I did this extremely quick as an example what could
be done.  May or may not be desirable or fit your actual use.
Also note, this will work fine inside a design but not so
good for top-level ports.

Regards,
Chris

##############################
Example
##############################

from myhdl import *

class Interface(object):
     def __init__(self):
         self.a = Signal(intbv(0)[5:])
         self.b = Signal(intbv(0)[7:])

def m_copy(clock, reset, x,y):
     @always_seq(clock.posedge, reset=reset)
     def rtl():
         y.next = x
     return rtl

def m_interface_copy(input_interface, output_interface, clock, reset):

     gc = []
     for k,v in input_interface.__dict__.iteritems():
         if isinstance(v, SignalType):
             print(k,v)
             gc.append(m_copy(clock, reset, input_interface.__dict__[k], 
output_interface.__dict__[k]))

     return gc

foo = Interface()
bar = Interface()
clock = Signal(bool(1))
reset = ResetSignal(bool(0), active=1, async=False)
toVerilog(m_interface_copy, foo, bar, clock, reset)

('a', Signal(intbv(0L)))
('b', Signal(intbv(0L)))
Out[14]:
[<myhdl._always_seq._AlwaysSeq at 0x9ecaac8>,
  <myhdl._always_seq._AlwaysSeq at 0x9a026d8>]

%less m_interface_copy.v
// File: m_interface_copy.v
// Generated by MyHDL 0.9dev
// Date: Thu Jan 15 13:39:12 2015


`timescale 1ns/10ps

module m_interface_copy (
     clock,
     reset,
     gc_0_x,
     v,
     gc_0_y,
     gc_1_y
);


input clock;
input reset;
input [4:0] gc_0_x;
input [6:0] v;
output [4:0] gc_0_y;
reg [4:0] gc_0_y;
output [6:0] gc_1_y;
reg [6:0] gc_1_y;






always @(posedge clock) begin: M_INTERFACE_COPY_GC_0_RTL
     if (reset == 1) begin
         gc_0_y <= 0;
     end
     else begin
         gc_0_y <= gc_0_x;
     end
end


always @(posedge clock) begin: M_INTERFACE_COPY_GC_1_RTL
     if (reset == 1) begin
         gc_1_y <= 0;
     end
     else begin
         gc_1_y <= v;
     end
end

endmodule

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

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

On 1/15/2015 1:15 PM, Henry Gomersall wrote:
> At risk of asking an XY problem (in which I describe a different problem
> to the more fundamental one), I would like to know if it is possible
> with MyHDL 0.9 to define a reusable convertible block that does
> something like the following:
>
> from myhdl import *
>
> class Interface(object):
>       def __init__(self):
>           self.a = Signal(intbv(0)[5:])
>           self.b = Signal(intbv(0)[7:])
>
> def block_factory(input_interface, output_interface, clock, reset):
>
>       @always_seq(clock.posedge, reset)
>       def block():
>           output_interface.next = input_interface
>
>       return block
>

No this is not supported.  I probably is possible
but would need to follow the normal enhance (MEP)
proposal.

Regards,
Chris

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

[Henry G. <he...@ca...>]

On 15/01/15 19:25, Christopher Felton wrote:
> On 1/15/2015 1:15 PM, Henry Gomersall wrote:
>> >At risk of asking an XY problem (in which I describe a different problem
>> >to the more fundamental one), I would like to know if it is possible
>> >with MyHDL 0.9 to define a reusable convertible block that does
>> >something like the following:
>> >
>> >from myhdl import *
>> >
>> >class Interface(object):
>> >       def __init__(self):
>> >           self.a = Signal(intbv(0)[5:])
>> >           self.b = Signal(intbv(0)[7:])
>> >
>> >def block_factory(input_interface, output_interface, clock, reset):
>> >
>> >       @always_seq(clock.posedge, reset)
>> >       def block():
>> >           output_interface.next = input_interface
>> >
>> >       return block
>> >
> No this is not supported.  I probably is possible
> but would need to follow the normal enhance (MEP)
> proposal.

Okey dokey. I would like to initiate the discussion :)

Does it seem like a crap idea, or something that might be useful?

Shall I put together a tentative MEP?

Cheers,

Henry

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

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

On 1/15/2015 1:38 PM, Henry Gomersall wrote:
> On 15/01/15 19:25, Christopher Felton wrote:
>> On 1/15/2015 1:15 PM, Henry Gomersall wrote:
>>>> At risk of asking an XY problem (in which I describe a different problem
>>>> to the more fundamental one), I would like to know if it is possible
>>>> with MyHDL 0.9 to define a reusable convertible block that does
>>>> something like the following:
>>>>
>>> >from myhdl import *
>>>>
>>>> class Interface(object):
>>>>        def __init__(self):
>>>>            self.a = Signal(intbv(0)[5:])
>>>>            self.b = Signal(intbv(0)[7:])
>>>>
>>>> def block_factory(input_interface, output_interface, clock, reset):
>>>>
>>>>        @always_seq(clock.posedge, reset)
>>>>        def block():
>>>>            output_interface.next = input_interface
>>>>
>>>>        return block
>>>>
>> No this is not supported.  I probably is possible
>> but would need to follow the normal enhance (MEP)
>> proposal.
>
> Okey dokey. I would like to initiate the discussion :)
>
> Does it seem like a crap idea, or something that might be useful?
>
> Shall I put together a tentative MEP?
>

 From my perspective it seems reasonable.  The idea
and uses cases are straight-forward but implementation
might need some batting around.

Example, should there be a factory function to copy,
kinda like the previous example.  Or should the user
have to defined a "next" method so that it can be a
customizable copy ...

Regards,
Chris

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

[Henry G. <he...@ca...>]

On 15/01/15 20:26, Christopher Felton wrote:
<snip>
>   From my perspective it seems reasonable.  The idea
> and uses cases are straight-forward but implementation
> might need some batting around.
>
> Example, should there be a factory function to copy,
> kinda like the previous example.  Or should the user
> have to defined a "next" method so that it can be a
> customizable copy ...

Right.

Something like, if the class contains the next attribute with a defined 
setter, it is used, otherwise nothing happens.

It would be a simple case then to define library functions, the obvious 
one being to assign all the signals:

from myhdl import interface_setter, interface_getter

class MyInterface(object):

     def __init__(self):
         self.a = Signal(intbv(0)[5:])
         self.b = Signal(intbv(0)[5:])

     next = property(interface_getter, interface_setter)

This could obviously be done in a parent class.

Henry

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

[Henry G. <he...@ca...>]

On 15/01/15 20:26, Christopher Felton wrote:
> On 1/15/2015 1:38 PM, Henry Gomersall wrote:
>> >On 15/01/15 19:25, Christopher Felton wrote:
>>> >>On 1/15/2015 1:15 PM, Henry Gomersall wrote:
>>>>> >>>>At risk of asking an XY problem (in which I describe a different problem
>>>>> >>>>to the more fundamental one), I would like to know if it is possible
>>>>> >>>>with MyHDL 0.9 to define a reusable convertible block that does
>>>>> >>>>something like the following:
>>>>> >>>>
>>>> >>>>from myhdl import *
>>>>> >>>>
>>>>> >>>>class Interface(object):
>>>>> >>>>        def __init__(self):
>>>>> >>>>            self.a = Signal(intbv(0)[5:])
>>>>> >>>>            self.b = Signal(intbv(0)[7:])
>>>>> >>>>
>>>>> >>>>def block_factory(input_interface, output_interface, clock, reset):
>>>>> >>>>
>>>>> >>>>        @always_seq(clock.posedge, reset)
>>>>> >>>>        def block():
>>>>> >>>>            output_interface.next = input_interface
>>>>> >>>>
>>>>> >>>>        return block
>>>>> >>>>
>>> >>No this is not supported.  I probably is possible
>>> >>but would need to follow the normal enhance (MEP)
>>> >>proposal.
>> >
>> >Okey dokey. I would like to initiate the discussion:)
>> >
>> >Does it seem like a crap idea, or something that might be useful?
>> >
>> >Shall I put together a tentative MEP?
>> >
>   From my perspective it seems reasonable.  The idea
> and uses cases are straight-forward but implementation
> might need some batting around.
>
> Example, should there be a factory function to copy,
> kinda like the previous example.  Or should the user
> have to defined a "next" method so that it can be a
> customizable copy ...

Another solution might be to support iterators more generally. Instead 
of the interface having a next property, it can implement the __iter__ 
method that returns the signals to iterate over.

This would have the nice property of also then supporting any iterables, 
not just interfaces.

I appreciate there isn't the equivalent in v*, but one approach that 
could work would be for the convertor to unroll the loop. A configurable 
parameter could set a maximum unroll length if that is desired.

I actually prefer this a solution - it's quite neat and powerful.

Henry

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

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

<snip>
>
> I appreciate there isn't the equivalent in v*, but one approach that
> could work would be for the convertor to unroll the loop. A configurable
> parameter could set a maximum unroll length if that is desired.

I think this would be out of scope, keep it
simple at first.  Unrolling of loops would
be large feature to tackle and would involve
deeper consideration and development.

Regards,
Chris

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

[Henry G. <he...@ca...>]

On 16/01/15 02:59, Christopher Felton wrote:
> <snip>
>> >
>> >I appreciate there isn't the equivalent in v*, but one approach that
>> >could work would be for the convertor to unroll the loop. A configurable
>> >parameter could set a maximum unroll length if that is desired.
> I think this would be out of scope, keep it
> simple at first.  Unrolling of loops would
> be large feature to tackle and would involve
> deeper consideration and development.

I think this would actually have a smaller impact on the code base and 
would be clean to implement. The main question I see would be naming 
considerations - in the case of interfaces a solution has already been 
implemented, but in the case of a simple list there is not the internal 
names to draw on.

What are the main issues you would be concerned with?

Implementing a .next strategy has the problem of adding another special 
case. I think it can be done pretty neatly though.

Cheers,
Henry

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

[Henry G. <he...@ca...>]

On 15/01/15 19:15, Henry Gomersall wrote:
> At risk of asking an XY problem (in which I describe a different problem
> to the more fundamental one), I would like to know if it is possible
> with MyHDL 0.9 to define a reusable convertible block that does
> something like the following:
>
> from myhdl import *
>
> class Interface(object):
>       def __init__(self):
>           self.a = Signal(intbv(0)[5:])
>           self.b = Signal(intbv(0)[7:])
>
> def block_factory(input_interface, output_interface, clock, reset):
>
>       @always_seq(clock.posedge, reset)
>       def block():
>           output_interface.next = input_interface
>
>       return block
>
> foo = Interface()
> bar = Interface()
> clock = Signal(bool(1))
> reset = ResetSignal(bool(0), active=1, async=False)
>
> toVerilog(block_factory, foo, bar, clock, reset)
>
> Running this yields "Object type is not supported in this context:
> output_interface".
>
> Now, my use case for this is to create a block that takes an interface
> as its argument, and from which I can create a buffer (or a small FIFO)
> of the attributes defined by the interface. The point is to match the
> propagation of state information alongside data processing inside a
> pipeline.
<snip>

So, the way this can be done in my situation is by instantiating a new 
block for each signal in the interface. If each element of the interface 
can be considered independently (which is sort of the point, otherwise 
I'm not sure how my question is meaningful), then I suspect the below 
would be about as good as I could get.

It produces pretty sensible looking v*. The names within the converted 
files are kept in line with the interface by accessing the locals() dict 
directly. If one creates an intermediate variable, the output names are 
created at conversion time and are a bit non-helpful (also, they are not 
all consistent with one another).

Cheers,

Henry

from myhdl import *
import myhdl

class Interface(object):
     def __init__(self):
         self.a = Signal(intbv(0)[5:])
         self.b = Signal(intbv(0)[7:])
         self.c = Signal(bool(0))

def single_signal_processor(input_signal, output_signal, clock, reset):

     @always_seq(clock.posedge, reset)
     def block():
         output_signal.next = input_signal

     return block

def interface_processor(input_interface, output_interface, clock, reset):

     process_blocks = []
     for attr_name in input_interface.__dict__:
         locals()['input_' + attr_name] = getattr(input_interface, 
attr_name)
         locals()['output_' + attr_name] = getattr(output_interface, 
attr_name)

         if isinstance(locals()['input_' + attr_name], 
myhdl._Signal._Signal):

             process_blocks.append(
                 single_signal_processor(
                     locals()['input_' + attr_name],
                     locals()['output_' + attr_name], clock, reset))

     return process_blocks

foo = Interface()
bar = Interface()
clock = Signal(bool(1))
reset = ResetSignal(bool(0), active=1, async=False)

toVerilog(interface_processor, foo, bar, clock, reset)
toVHDL(interface_processor, foo, bar, clock, reset)

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

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

Henry Gomersall <heng <at> cantab.net> writes:

><snip>
> def interface_processor(input_interface, output_interface, clock, 
reset):
> 
>      process_blocks = []
>      for attr_name in input_interface.__dict__:
>          locals()['input_' + attr_name] = getattr(input_interface, 
> attr_name)
>          locals()['output_' + attr_name] = getattr(output_interface, 
> attr_name)
> 
>          if isinstance(locals()['input_' + attr_name], 
> myhdl._Signal._Signal):
> 
>              process_blocks.append(
>                  single_signal_processor(
>                      locals()['input_' + attr_name],
>                      locals()['output_' + attr_name], clock, reset))
> 
>      return process_blocks
><snip>

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.

Regards,

Josy

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

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

Interfaces signals are converted with dots replaced to underscores. If you
follow the qsys naming conversions(aso,asi,avm,avs), qsys will
automatically detect the interfaces.

On Fri, Jan 16, 2015 at 2:23 PM, Josy Boelen <jos...@gm...> wrote:

> Henry Gomersall <heng <at> cantab.net> writes:
>
> ><snip>
> > def interface_processor(input_interface, output_interface, clock,
> reset):
> >
> >      process_blocks = []
> >      for attr_name in input_interface.__dict__:
> >          locals()['input_' + attr_name] = getattr(input_interface,
> > attr_name)
> >          locals()['output_' + attr_name] = getattr(output_interface,
> > attr_name)
> >
> >          if isinstance(locals()['input_' + attr_name],
> > myhdl._Signal._Signal):
> >
> >              process_blocks.append(
> >                  single_signal_processor(
> >                      locals()['input_' + attr_name],
> >                      locals()['output_' + attr_name], clock, reset))
> >
> >      return process_blocks
> ><snip>
>
> 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.
>
> 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:

> 
> 
> Interfaces signals are converted with dots replaced to underscores. If 
you follow the qsys naming conversions(aso,asi,avm,avs), qsys will 
automatically detect the interfaces.
> 
> 

That's not what I meant: I'm currently working on a Python/MyHDL 
extension to generate the xx_hw.tcl files from within MyHDL (this would 
not have to use that ugly, perfectly useful for automated recognition 
but still ugly, naming convention). The xx_hw.tcl will not only guide 
the elaboartion, but also call back on the MyHDL module to generate the 
bespoke VHDL code.

My 'wish' is the following:
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. My 'sigh' is that Qsys only handles std_logic_vector 
as the data type. So it would be great if we could automate the 
conversion between the required std_logic_vector port in VHDL (or even 
Verilog) and the inherently more useful interface object in MyHDL. See 
it as an interface within an interface (or in VHDL: a record in a 
record)

Regards,

Josy

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

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

<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

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

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

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()?

Best regards,

Josy



Best 

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

[Henry G. <he...@ca...>]

On 19/01/15 21:23, Josy Boelen wrote:
> 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()?

Given Python is a fully featured language, it would be perfectly 
possible to write _anything_ into VHDL/Verilog, it's just developer time 
to make this possible. The correct way IMO is to do the translation in 
python and not try to match the features of some intermediate language 
at all. Still, targetting VHDL and Verilog is very sensible.

Henry

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

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

Henry Gomersall <heng <at> cantab.net> writes:

> 
> On 19/01/15 21:23, Josy Boelen wrote:
> > 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()?
> 
> Given Python is a fully featured language, it would be perfectly 
> possible to write _anything_ into VHDL/Verilog, it's just developer time 
> to make this possible. The correct way IMO is to do the translation in 
> python and not try to match the features of some intermediate language 
> at all. Still, targetting VHDL and Verilog is very sensible.
> 
> Henry
> 

I'm a VHDL-guy (wouldn't touch Verilog with a bargepole).
VHDL has a few extras Verilog doesn't have, aside from Verilog's ugly 
blocking and non-blocking'. 
A practical example: Once there was this site 'All Programmable Planet'. A 
blog/thread was about the 'Game Of Life'. Out of curiosity I coded a VHDL 
version of it. I used, of course, a (true) 2D array to represent the cells. 
I later re-coded this in MyHDL and as MyHDL suffers from Verilogitis (I 
deliberately make it sound like a disease) I had to recode it into a 1D 
array, otherwise it would not convert. 

Now I couldn't care less that how the converted (VHDL or even Verilog) code 
looks, as long as it works but it is a not a step forward to 'advance by 
using Python, but limit yourself to Verilog-able constructs'.
So in my (not so humble anymore) opinion there is a brighter future for 
MyHDL, if only we manage to lift it above the Verilog coding rules. 

Regards,

Josy

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

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

<snip>
> A practical example: Once there was this site 'All Programmable Planet'. A
> blog/thread was about the 'Game Of Life'. Out of curiosity I coded a VHDL
> version of it. I used, of course, a (true) 2D array to represent the cells.
> I later re-coded this in MyHDL and as MyHDL suffers from Verilogitis (I
> deliberately make it sound like a disease) I had to recode it into a 1D
> array, otherwise it would not convert.

This is an important (IMO) topic, that is multidimensional
array representation and abstractions.  A separate thread
just on this topic might be useful - especially given your
experience and example.

Regards,
Chris

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

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

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

> 
> <snip>
> > A practical example: Once there was this site 'All Programmable 
Planet'. A
> > blog/thread was about the 'Game Of Life'. Out of curiosity I coded a 
VHDL
> > version of it. I used, of course, a (true) 2D array to represent the 
cells.
> > I later re-coded this in MyHDL and as MyHDL suffers from Verilogitis 
(I
> > deliberately make it sound like a disease) I had to recode it into a 
1D
> > array, otherwise it would not convert.
> 
> This is an important (IMO) topic, that is multidimensional
> array representation and abstractions.  A separate thread
> just on this topic might be useful - especially given your
> experience and example.
> 
> Regards,
> Chris
> 
> <snip>
I'll start by publishing the VHDL code on github (which I do not seem to 
succeed, syncing via Dropbox seems a lot easier to me).
Unfortunately I lost my 'pygol' project when clearing out Eclipse 
workspaces. But I'll redo that when we move further.

Best regards,

Josy

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

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

> <snip>

I managed to publish the VHDL code (and Quartus project) on Github. Enjoy ;)

Regards,

Josy

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

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

On 1/19/2015 3: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?
<snip>
> 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 we need to define (review) the purpose of the
generated Verilog and VHDL.  Is it a convenient
intermediate representation or is MyHDL intended to be
a V* generator (i.e. is the generated V* modified by
the user - bootstrap)?

The V* are convenient IRs [1] and although MyHDL has
readable converted code (etc.), the converted V* are
akin to an IR more than a usable standalone piece of
code (e.g. parameters are not preserved).

But, in my opinion, interoperability is important and in
this case I think it is better supported by tools/plugins
than conversion support.  As @jck mentioned there are
some processes (naming conventions) that can be used.  If
I get time in the near future I will try and but together
an example using @jck suggestion.

Regards,
Chris
(as usual my 2 cents with normal disclaimers :)

[1] Things change over time and I see to have many false memories,
     best of my knowledge this is Jan's goal/vision with V*.

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

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

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

Christopher Felton <chris.felton <at> gmail.com> writes:
> <snip> 
> First we need to define (review) the purpose of the
> generated Verilog and VHDL.  Is it a convenient
> intermediate representation or is MyHDL intended to be
> a V* generator (i.e. is the generated V* modified by
> the user - bootstrap)?
> 
> The V* are convenient IRs [1] and although MyHDL has
> readable converted code (etc.), the converted V* are
> akin to an IR more than a usable standalone piece of
> code (e.g. parameters are not preserved).
> 
> But, in my opinion, interoperability is important and in
> this case I think it is better supported by tools/plugins
> than conversion support.  As  <at> jck mentioned there are
> some processes (naming conventions) that can be used.  If
> I get time in the near future I will try and but together
> an example using  <at> jck suggestion.
> 
> Regards,
> Chris
> (as usual my 2 cents with normal disclaimers :)
> 
> [1] Things change over time and I see to have many false memories,
>      best of my knowledge this is Jan's goal/vision with V*.
> 
> <snip>
You are right, I too see the generated V* as just a convenient 
intermediate representation. This is exactly my point of 'converting' 
MyHDL interfaces into std_logic_vectors (and back) for use in other 
tools. Same reason I am currently (after hours ...) writing a Python 
utility to generate the necessary supporting files, so we can almost 
forget the IR completely and treat is an an opaque something (a black 
box). My utility does away with those (ugly) (Altera) naming conventions 
as it works with ST- and MM- interfaces directly. I hope I can post some 
debugged code soon now. I have an example module working for ST-
interfaces and am now working on an example that also has a MM-Slave 
interface. 
I haven't used interfaces to model Avalon ST-interfaces, yet. We looked 
into them for a project and tried to enhanced this further, but stumbled 
a few times, so I decide to write the project (as it was a fixed-price 
offer from our side) using the 'standard' interconnection method. 
Now an ST-module with MyHDL interfaces may/will conflict with my 
utility, but I'll learn ...

Best regards,

Josy

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

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

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