myhdl-list — Mailing list for discussions on MyHDL

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...>]

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

[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

[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] Setting of enum values

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

On 16/01/15 03:07, Christopher Felton wrote:
> On 1/10/2015 5:44 AM, Jan Decaluwe wrote:
>> >On 01/10/2015 11:41 AM, Henry Gomersall wrote:
>> >
>>> >>
>>> >>There is an argument to be made (which I'm trying to make:)  ) that
>>> >>enums should be handled and enforced at the MyHDL level, and converted
>>> >>to whatever types make sense at the HDL level. Requiring that MyHDL
>>> >>enums map to VHDL enums rather limits their scope.
>> >
>> >That is not the requirement.
>> >
>> >The enum was modeled after the VHDL enums because
>> >I consider that a better model than alternatives in
>> >other languages that I know of.
>> >
>> >The fact that they map naturally to VHDL enums is simply
>> >a consequence of that modeling decision.
>> >
> I understand Jan's point with keeping the enum but
> I would like to explore the options to solve the
> original issue - third party interfacing.
>
> I imagine, you would be stuck with an explicit
> variable definition, e.g.
>
>       # third-party state definitions
>       S_S1,S_S2,S_S3 = range(3)
>
> Considering, third-party interfaces (might) be limited
> this is a reasonable approach(?).

I think this can be done with a explicit support of something akin to 
the IntEnum class. This makes a clean separation between the existing 
enum and areas where the enum/Int boundary is blurry.

Henry

Re: [myhdl-list] Setting of enum values

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

On 1/10/2015 5:44 AM, Jan Decaluwe wrote:
> On 01/10/2015 11:41 AM, Henry Gomersall wrote:
>
>>
>> There is an argument to be made (which I'm trying to make :) ) that
>> enums should be handled and enforced at the MyHDL level, and converted
>> to whatever types make sense at the HDL level. Requiring that MyHDL
>> enums map to VHDL enums rather limits their scope.
>
> That is not the requirement.
>
> The enum was modeled after the VHDL enums because
> I consider that a better model than alternatives in
> other languages that I know of.
>
> The fact that they map naturally to VHDL enums is simply
> a consequence of that modeling decision.
>

I understand Jan's point with keeping the enum but
I would like to explore the options to solve the
original issue - third party interfacing.

I imagine, you would be stuck with an explicit
variable definition, e.g.

     # third-party state definitions
     S_S1,S_S2,S_S3 = range(3)

Considering, third-party interfaces (might) be limited
this is a reasonable approach(?).

Regards,
Chris

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...>]

<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 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

[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

[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 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: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: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

[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] calls with mismatched arguments being passed quietly

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

On 11/01/15 21:46, Jan Decaluwe wrote:
> On 01/11/2015 08:00 PM, Henry Gomersall wrote:
>> >Should a call to a function with mismatched arguments be passed quietly
>> >as it sometimes is currently?
> http://docs.myhdl.org/en/latest/manual/conversion.html#simulate-first

Except that there are warnings currently in there for perfectly 
acceptable code. Indeed, as Josy points out, there are warnings about 
top level argument issues.

I'm happy with the general concept, but it seems like something that is 
pretty easy to pick up at the conversion stage and warn about, rather 
than trying to diagnose test fails down the line - the VHDL would likely 
compile just fine.

Cheers,

Henry

Re: [myhdl-list] calls with mismatched arguments being passed quietly

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

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

> The warning you highlight is a red herring as it's referring to the 
> outer-most closure.
> 
> Consider the following change:
> 
> def Test(an_arg, clock, reset):
> 
>       <at> always_seq(clock.posedge, reset=reset)
>      def test_case():
>          if an_arg:
>              bleh()
> 
>      return test_case
> 
> This converts with no warnings but the same symptoms.
> 
> You're quite right this should be picked up by testing, but I don't 
> think it should pass quite so quietly as it does.
> 
> Cheers,
> 
> Henry
> 
> -------------------------------------------------------------------------

Henry,

I posted two follow-up messages detailing my further investigations, but 
Gmane seems to have eaten them ...
I don't have access to my 'home' machine, so I try to recall what I did 
yesterday evening.

It doesn't pass quietly though:
MyHDL gives a warning that the argument is not used. Another Red Herring. I 
have a rule that my code must be warning free. 'A Warning is an Error 
Waiting to Happen' is a quote a picked up in the eighties.

I ran it through Quartus II 14.1's Synthesis and this complains about 
a 'assignment error' as MyHDL generated in the procedure code (not a 
function as it doesn't return a value) a '<=' for what apparently is 
a 'variable'. So this seems to be another bug in MyHDL.

I then further modified the Python code and 'corrected' the missing 
argument.
It will then convert again, but with another warning: that the top level 
port test_arg is an 'inout'. Again 'inout' ports are a Red Red Herring. 

Running it through the Synthesis yields another error as now the conversion 
is missing the 'signal' argument.
If we correct that in the VHDL code it will synthesize but the RTL 
schematic doesn't look pretty, which it can't be as we now have TriState 
signals.

All in all, this now contrived example has taken us from Scylla to 
Charybdis :)

Regards,

Josy

Re: [myhdl-list] calls with mismatched arguments being passed quietly

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

On 01/11/2015 08:00 PM, Henry Gomersall wrote:
> Should a call to a function with mismatched arguments be passed quietly
> as it sometimes is currently?

http://docs.myhdl.org/en/latest/manual/conversion.html#simulate-first

-- 
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] calls with mismatched arguments being passed quietly

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

On 11/01/15 19:42, Josy Boelen wrote:
<snip>
> If we write a self-checking test-bench the 'error' will be flagged too
> as the simulation will fail.(I'm not going to do this exercise as I
> would solve the problem early on by correcting the warning given by
> Pydev in Eclipse)

The warning you highlight is a red herring as it's referring to the 
outer-most closure.

Consider the following change:

def Test(an_arg, clock, reset):

     @always_seq(clock.posedge, reset=reset)
     def test_case():
         if an_arg:
             bleh()

     return test_case

This converts with no warnings but the same symptoms.

You're quite right this should be picked up by testing, but I don't 
think it should pass quite so quietly as it does.

Cheers,

Henry

Re: [myhdl-list] calls with mismatched arguments being passed quietly

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

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

> 
> Should a call to a function with mismatched arguments be passed 
quietly 
> as it sometimes is currently?
> 
> consider:
> 
> from myhdl import *
> 
> def bleh(test_arg):
>      test_arg.next = not test_arg
> 
> def Test(an_arg, clock, reset):
> 
>       <at> always_seq(clock.posedge, reset=reset)
>      def test_case():
>          bleh()
> 
>      return test_case
> 
> test_arg = Signal(bool(0))
> clock  = Signal(bool(0))
> reset = ResetSignal(0, active=0, async=True)
> 
> inc_inst = toVHDL(Test, test_arg, clock, reset)
> 
> The python parser has no problem with this because test_arg is in the 
> global namespace. However, the converted code just completely ignores 
> the function call (putting only ';' ) :
> 
> TEST_TEST_CASE: process (clock, reset) is
> begin
>      if (reset = '0') then
>      elsif rising_edge(clock) then
>          ;
>      end if;
> end process TEST_TEST_CASE;
> 
> toVerilog similarly misses out the argument list (though it has the 
> function name).
> 
> I would suggest this can be picked up at the end of the FunctionType 
> case in visit_Call with a test of equality between len(node.args) and 
> len(tree.argnames) here:
> 
https://bitbucket.org/jandecaluwe/myhdl/src/f7a6b2ef05bbf418349d8b0021d8
1b4fc83b8ce0/myhdl/conversion/_analyze.py?at=0.9-dev#cl-657
> 
> I can do this and raise a pull request, but am I missing something 
about 
> the handling of function calls?
> 
> Cheers,
> 
> Henry
> 
> ----------------------------------------------------------------------
When I copy/paste the code in PyDev/Eclispe I get a warning of unused 
argument ...

MyHDL will convert the code as is, beit with a warning: '** 
ToVHDLWarning: Port is not used: an_arg'
---
TEST_TEST_CASE: process (clock, reset) is
begin
    if (reset = '0') then
    elsif rising_edge(clock) then
        MYHDL2_bleh;
    end if;
end process TEST_TEST_CASE;

end architecture MyHDL;
----
Notice that in MyHDL 0.9 the procedure (as there is nothing to be 
returned) all is also in the converted VHDL (as you say there is in the 
Verilog code)

If we are careful and use different declaration and instantiating names 
to avoid the global namespace pitfalss e.g.:
from myhdl import *
 
def bleh(test_arg):
    test_arg.next = not test_arg

def Test(an_arg, clock, reset):

    @always_seq(clock.posedge, reset=reset)
    def test_case():
        bleh()

    return test_case

arg = Signal(bool(0))
clock  = Signal(bool(0))
reset = ResetSignal(0, active=0, async=True)

inc_inst = toVHDL(Test, arg, clock, reset)

MyHDL will come up with an exception: 'myhdl.ConversionError: in file 
C:\qdesigns\MyHDL\Source\thg.py, line 4:
    Local variable may be referenced before assignment: test_arg
' 
If we write a self-checking test-bench the 'error' will be flagged too 
as the simulation will fail.(I'm not going to do this exercise as I 
would solve the problem early on by correcting the warning given by 
Pydev in Eclipse)

Regards,

Josy

[myhdl-list] calls with mismatched arguments being passed quietly

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

Should a call to a function with mismatched arguments be passed quietly 
as it sometimes is currently?

consider:

from myhdl import *

def bleh(test_arg):
     test_arg.next = not test_arg

def Test(an_arg, clock, reset):

     @always_seq(clock.posedge, reset=reset)
     def test_case():
         bleh()

     return test_case

test_arg = Signal(bool(0))
clock  = Signal(bool(0))
reset = ResetSignal(0, active=0, async=True)

inc_inst = toVHDL(Test, test_arg, clock, reset)

The python parser has no problem with this because test_arg is in the 
global namespace. However, the converted code just completely ignores 
the function call (putting only ';' ) :

TEST_TEST_CASE: process (clock, reset) is
begin
     if (reset = '0') then
     elsif rising_edge(clock) then
         ;
     end if;
end process TEST_TEST_CASE;

toVerilog similarly misses out the argument list (though it has the 
function name).

I would suggest this can be picked up at the end of the FunctionType 
case in visit_Call with a test of equality between len(node.args) and 
len(tree.argnames) here:
https://bitbucket.org/jandecaluwe/myhdl/src/f7a6b2ef05bbf418349d8b0021d81b4fc83b8ce0/myhdl/conversion/_analyze.py?at=0.9-dev#cl-657

I can do this and raise a pull request, but am I missing something about 
the handling of function calls?

Cheers,

Henry

Re: [myhdl-list] Setting of enum values

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

On 11/01/15 08:33, Jan Decaluwe wrote:
> The whole blurring of integers with enum items comes from
> languages that unlike VHDL don't have a good enum model.
>
> The whole point of a enum is to have an abstract type
> where nothing matters but the item name. The MyHDL enum makes
> that very clear - no integers in sight.

You make a reasonable case that the normal Enum is fine as-is except for 
the fact that it doesn't really work with external libraries (not least 
because the Verilog support for enums is missing).

Given that, I still think that there is a use case for something like 
the IntEnum - if only as a namespace encapsulation device. One usage of 
enums is to remove the reliance on magic numbers. Of course it's 
possible to have your own naming convention, but it quickly gets mucky 
with lots of FOO_X, FOO_Y, BAR_X, BAR_Y floating around.

If it was a supported concept, then useful things like bit length could 
be inferred.

At a very minimum, it would be useful to have namespace mangling that 
allows integer class attributes to be supported, as suggested in another 
post. This would a provide a similar feature for other types as 
interfaces do for Signals.

To be clear, I think MyHDL is fantastic - the neat mapping of HDL 
concepts into standard python constructs is rather beautiful. I thank 
and congratulate your for it.

Henry

Re: [myhdl-list] Setting of enum values

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

On 01/10/2015 10:55 AM, Henry Gomersall wrote:
> On 10/01/15 08:50, Jan Decaluwe wrote:
>> On 12/28/2014 06:44 PM, Henry Gomersall wrote:
>>>> On 28/12/14 11:24, Henry Gomersall wrote:
>>>>>> Looking at the code, it seems the enum value is set by the argument
>>>>>> order, so I can't see how to do it trivially.
>>>>
>>>> It strikes me that the problem is that the class definition is inside
>>>> the enum factory function. Is there a reason for this?
>> Sure - the enum factory function is intended to create
>> a brand new type, like in VHDL.
>
> Right, that makes sense in light of the view that enum should more than
> just a symbolic representation of an int down to the HDL level.
>
> This is handled rather differently in the standard enum that allows
> quite a bit more flexibility in the design - the uniqueness of the items
> is enforced through the Enum metaclass.

In MyHDL uniquness is enforced by the factory function.

I have briefly looked at the Python enum, and I don't like it.
It seems incredibably complicated with metaclasses and
full of magic.

Confusing also. To construct an enum, you have to assign
integers to names. Those integers don't really have a meaning,
but you can still use them to access items. Ugly.
The class is "strongly recommended", but then they still provide
an IntEnum that further blurs the distinction betweens integers
and enum items.

The whole blurring of integers with enum items comes from
languages that unlike VHDL don't have a good enum model.

The whole point of a enum is to have an abstract type
where nothing matters but the item name. The MyHDL enum makes
that very clear - no integers in sight.

Therefore, I'll stick to MyHDL's enum, clean and to the point.

-- 
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] Setting of enum values

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

On 01/10/2015 11:41 AM, Henry Gomersall wrote:

>
> There is an argument to be made (which I'm trying to make :) ) that
> enums should be handled and enforced at the MyHDL level, and converted
> to whatever types make sense at the HDL level. Requiring that MyHDL
> enums map to VHDL enums rather limits their scope.

That is not the requirement.

The enum was modeled after the VHDL enums because
I consider that a better model than alternatives in
other languages that I know of.

The fact that they map naturally to VHDL enums is simply
a consequence of that modeling decision.

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] Setting of enum values

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

On 10/01/15 08:53, Jan Decaluwe wrote:
> On 01/07/2015 01:23 PM, Henry Gomersall wrote:
>
>> >Further to this, why not just extend the existing python Enum:
> MyHDL's enum was needed and implemented long before a
> python Enum proposal emerged.
>
> It may be useful to review the python Enum and reuse
> if possible. I have not done that.
>
> However - MyHDL's enum is intended to be modeled
> after VHDL, not C or C++ which blur the distinction
> between abstract enum types and integers.

There is an argument to be made (which I'm trying to make :) ) that 
enums should be handled and enforced at the MyHDL level, and converted 
to whatever types make sense at the HDL level. Requiring that MyHDL 
enums map to VHDL enums rather limits their scope (isn't the point of 
MyHDL to surpass the existing languages?).

The python enum has two parts:
i) The genuine symbolic enum class Enum, which distinctly removes the 
blurring between ints and enums, and is analogous to the VHDL enum 
(though it does allow explicit numbering of the symbols).
ii) The IntEnum class which makes the relationship with ints quite explicit.

I think there is room and use cases for both types in MyHDL:
* Interfacing with libraries that have certain enumerations defined 
would naturally fit with an IntEnum (even if it's only at the level of a 
sane, well-constrained namespace). This would map to an intbv at conversion.
* Defining new e.g. states would do well to use a proper Enum. This 
could map to VHDL enum if the numbering made sense (or was ignored).

Some of the benefit of IntEnum can _almost_ be had in 0.9 - with values 
mapping to constants, the only problem there being the conversion issue 
of integer attributes on an object being transcribed with the dot 
notation included - the same issue that is discussed in MEP 107 for 
interfaces. The other issue is that it is up to the user to specify the 
bit vector length for the values.

There is clearly a nod to different encoding schemes in the enum class 
as it stands (with the encoding kw arg).

Cheers,

Henry