myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] Conversion error to vhdl

[Norbo <Nor...@gm...>]

On Mon, 21 Nov 2011 17:28:05 +0100, Christopher Felton
<chr...@gm...> wrote:

> On 11/21/2011 8:52 AM, Oscar Diaz wrote:
>> 2011/11/19 Norbo<Nor...@gm...>:
>>> I have played a bit with myhdl and created the following:
>>>
>>> ----------------------------------------------------------
>>>   from myhdl import *
>>>
>>> def bin2gray(A,B, C, width):
>>>
>>>      """ Gray encoder.
>>>
>>>      B -- input intbv signal, binary encoded
>>>      G -- output intbv signal, gray encoded
>>>      width -- bit width
>>>
>>>      """
>>>      @always_comb
>>>      def logic():
>>>          C[0].next = A + B
>>
>> It seems that you have a bug here. Why you assign the result of a sum
>> to a single bit? that's the reason why the converter tried to use
>> "to_std_logic" for the output. If you want a normal sum, it should be
>>
>> C.next = A + B
>>
>> and the VHDL converter will put synthesizable code:
>>
>> C<= (A + B);
>>
>
> Good eye Oscar!
>
> Yes, there are a couple issues with the bin2gray that was provided (I
> assumed the bin2gray was an example for conversion means and not an
> actual bin2gray?).  I didn't notice at first glance but if you want to
> assign a single bit of a bit-vector you need to do:
>
>    C.next[0] = A + B
>
>
> If you assign the bit correctly the conversion works (even though it
> functional doesn't work).  Simulation will not work!.  Not sure why the
> converter didn't flag this?  Possible error detection enhancement.
>
> Also using the "+" operator instead of the bitwise "^" will cause
> problems in simulation.  The "+" will overflow the range for a single  
> bit.
>
> My previous reply can be ignored and should be ignored.  If any changes
> need to be made they would be in the error catching/reporting and not
> modifications to the conversion.
>
> Regards,
> Chris
>
>> Or, if you want a binary to gray encoder, just use the example from
>> the documentation
>>
>> http://www.myhdl.org/doc/current/manual/conversion_examples.html#a-small-combinatorial-design
>>
>>
>> Best Regards
>>

Well the thing is:

If i write:

C[4:0].next = A+B    in vhdl it gets ->  C(4-1 downto 0) <= resize(A +  
B,4);

or:

C[1:0].next = A+B   in vhdl it gets ->  C(1-1 downto 0) <= resize(A + B,1);
which in  in my understanding this makes kind of sense because the result
is cropped to the output size. (maybe a warning would be nice, but it
could be difficult if the calculation gets longer)


but when i write :

C[0].next = A+B
(which is actually the same as the above C[1:0].next = A+B)
     in vhdl it gets ->  C(0) <= to_std_logic(A + B);
and is not synthesisable.

Re: [myhdl-list] Third-party modules?

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

On 11/20/2011 11:43 AM, garyr wrote:
> ----- Original Message -----
> From: "Christopher Felton"<chr...@gm...>
> To:<myh...@li...>
> Sent: Saturday, November 19, 2011 8:50 PM
> Subject: Re: [myhdl-list] Third-party modules?
>
>
>> On 11/19/11 8:41 PM, garyr wrote:
>>> Thanks for the information. Can this type of code be tested with the
>>> MyHDL
>>> simulator? I have tried something very similar to that but it appeared to
>>> have no effect during simulation.
>>
>> If you do CoSimulation you can test the 3rd party IP (presumed to be
>> Verilog or VHDL).  If you want to do MyHDL simulation only, you have to
>> create a model for the IP (or better yet request the IP vendor to create
>> a MyHDL/Python model :) ).
>>
>> Hope that helps,
>> Chris
>
> I should have described my problem in more detail. I'm not actually dealing
> with a third-party module, just modules I have written. I have a utility
> module that I wish to use (not concurrently) with two other modules . I
> wrote some test code and followed the procedure described in Section 8.8
> of the MyHDL manual (which you also described) and inserted a bit of Verilog
> code in the primary module that I thought would instantiate the utility
> module. But when I run the simulation it appears that the utility module is
> not instantiated. Here is a bit of my test code:
>
> def test(overflow, count):
>     @always(overflow.negedge)
>     def logic():
>         pass
>   count.driven = "wire"
>   return logic
> test.verilog_code =\
> """overflowCounter inst_1(.ovfl($overflow), .overflowCount($count));"""
>
> def simpleCounter(reset, signal, gate, count, ofCount):
>     overflow = Signal(intbv(0)[5:])
>     instTest = test(overflow, ofCount)
>     instCounter = counter(reset, signal, gate, count, overflow)
>   return instTest, instCounter
>
> The module counter (not shown) is a gated counter; the signal overflow is
> toggled when the counter overflows. The function of the module
> overflowCounter (also not shown) is to count the number of times overflow
> occurred. These two modules when instantiated together as in section 8.4 of
> the manual or in a test bench function correctly. I know very little about
> HDL so the bit of Verilog code above may be incorrect - please comment on
> that. Assuming the Verilog code is correct, if I instantiate the module
> simpleCounter in a test bench will all of the code, overflowCounter
> included, be simulated?
>
> Many thanks,
> Gary Richardson


If you simply want to test Verilog/VHDL code with MyHDL the above 
(previous reply) might not be the approach you want.

You should look at the cosimulation sections of the manual if you simply 
want to test Verilog modules.

The previous response would be for mixing MyHDL/Verilog for the final 
HDL that will be synthesized.  The above is like a "black box" 
definition.  Where the logic will be filled in at some later period.

Regards,
Chris

>
>>
>>>
>>> ----- Original Message -----
>>> From: "Christopher Felton"<chr...@gm...>
>>> To:<myh...@li...>
>>> Sent: Saturday, November 19, 2011 3:00 PM
>>> Subject: Re: [myhdl-list] Third-party modules?
>>>
>>>
>>>> On 11/19/11 12:57 PM, garyr wrote:
>>>>> One of the entries in the MyHDL Frequently Asked Questions states that
>>>>> third-party modules may be instantiated by using "user-defined code to
>>>>> replace a MyHDL module by a corresponding instantiation".  My attempts
>>>>> at this have not been successful. Could someone point me to an example?
>>>>>
>>>>> Thanks in advance for your replies.
>>>>>
>>>>>
>>>>
>>>> Here is a reply from a earlier, similar, inquiry.  You might want to
>>>> refer to the old thread, http://bit.ly/uHcVZi.
>>>>
>>>> Regards,
>>>> Chris
>>>>
>>>>> Here is a small example to achieve what (I think) you are describing.
>>>>> More information can be found here,
>>>>> http://www.myhdl.org/doc/current/manual/conversion_examples.html#conv-usage-custom
>>>>>
>>>>> from myhdl import *
>>>>>
>>>>> def BurriedInstance(clk, rst, data_in, data_out):
>>>>>
>>>>>        # ... Some Code
>>>>>        bi = nativeInstance(clk, rst, data_in, data_out)
>>>>>        # ... Some More Code
>>>>>
>>>>>        return bi  #other generators
>>>>>
>>>>> def nativeInstance(clk, rst, data_in, data_out):
>>>>>
>>>>>        @always(clk, rst, data_in)
>>>>>        def pass_thru():
>>>>>            pass
>>>>>        data_out.driven = "wire"
>>>>>
>>>>>        nativeInstance.vhdl_code = """
>>>>>        P1:ppc port map($clk, $rst, $data_in, $data_out);
>>>>>        """
>>>>>
>>>>>        return pass_thru
>>>>>
>>>>>
>>>>> if __name__ == '__main__':
>>>>>        clk = Signal(False)
>>>>>        rst = Signal(False)
>>>>>        data_in  = Signal(intbv(0)[8:])
>>>>>        data_out = Signal(intbv(0)[8:])
>>>>>        toVHDL(BurriedInstance, clk, rst, data_in, data_out)
>>>>>
>>>>>
>>>>
>>>>
>>>>

Re: [myhdl-list] MEP : Signal Containers

[Oscar D. <osc...@gm...>]

2011/11/21 Christopher Felton <chr...@gm...>:
> On 11/21/2011 9:39 AM, Oscar Diaz wrote:
>> 2011/11/15 Christopher Felton<chr...@gm...>:
>>> The following is a *start* to a MEP that describes the conversion
>>> support for classes, lists, and dictionaries.  This is just a start of
>>> the enhancement description and does not include some of the mechanical
>>> (code changes) items worth identifying in a MEP.
>>
>> Thanks for making this draft. I'm mostly agree this MEP, I'll just add
>> some thoughts:
>>
>> * Since a class could be more powerful than a list or a dict,
>> container classes should allow enhanced features i.e. custom naming
>> scheme. We can propose hidden methods to support that features, in a
>> similar way of the special methods from the python data model:
>>
>> http://docs.python.org/reference/datamodel.html#special-method-names
>
> If we do this we would need to define a base class, something like
> SignalStruct, that would contain these features.  Past feedback indicate
> they would like general class/objects to be convertible without defining
> a special base class.
>
> I think general class/objects would need to be supported but having an
> additional MyHDL ojbect to help guide conversion would be useful.  Also,
> defining a SignalStruct object would make things easier (my guess) for a
> first implementation.  It might be a good spot to start with and explore
> the conversion routines.
>
>>
>> Right now I'm thinking about
>>
>> * It's not explicitly mentioned, but I guess the conversion step will
>> "flatten" the signal container. Although I agree on that, maybe we
>> could think about support to conversion to arrays or records (I speak
>> mainly for VHDL, I'm not that expert of Verilog).
>
> The argument against using VHDL records is to keep a similar conversion
> for Verilog and VHDL, IMO.  We don't want to use the SystemVerilog
> struct unless it is supported by the open-source compiler/simulators.
> Since we need to flatten it for Verilog I think flattening it VHDL is
> reasonable, least common denominator.
>
> My thought, if we have a special case for VHDL it would be more work to
> develop, maintain, and test.  Personally I like limiting the use of the
> underlying HDL as minimal as possible and maximum overlap between HDLs.
>
>>
>> * About the conversion of class methods, I think that should be in
>> another MEP, this one is to define signal containers. We should make
>> another MEP to add support for conversion of classes (not just class
>> methods). However, I do agree that the class methods must have support
>> for conversion, as you explained here, and I think it is easy to fix
>> the self argument issue in the conversion code.
>
> That is reasonable but I don't follow what you mean by the conversion of
> classes?  In my mind, once you have a mechanism to dig down and find the
> signal, I call them primitives (which is the main purpose of this mep).
>  And generator conversion is already supported (other than a generator
> that is defined in a class).

What I mean is a "standard" way to use classes. In my projects, I make
heavy use of inheritance to add generators on base components. Right
now I'm using a list of generators inside the classes, and just append
generators at __init__ or by calling methods from the extended
classes. On simulation, I make a big list with all the generators from
all objects instantiated' list of generators. It works nice on
simulation, but I wanted to do the same for conversion (I haven't
researched this last issue yet).

>
>>
>> That's all for now.
>>
>> Best regards.
>>
>> P.D.: Perhaps I can help with the VHDL code snippet:
>>
>> VHDL example conversion.
>> .. code-block :: vhdl
>>
>> entity foo is
>>      port (
>>          clk: in std_logic;
>>          MyObj_x: in unsigned(7 downto 0);
>>          MyObj_y: in unsigned(3 downto 0);
>>          MyObj_z: out unsigned(8 downto 0)
>>      );
>> end entity foo;
>>
>> architecture MyHDL of foo is
>>
>> begin
>>
>>      RTL: process(clk) is
>>      begin
>>          if rising_edge(clk) then
>>              MyObj_z<= MyObj_x + MyObj_y
>>          end if;
>>      end process RTL;
>>
>> end architecture MyHDL;
>>
>>
>
> Thanks for the code snip.
>
>> Right now I'm thinking about:
>> * custom naming scheme: something like "_names_iter(self)" method that
>> returns the desired names for each signal.
> I believe an object would need to be provided, that has special hooks
> and methods.  But the use of the object (e.g. SignalStruct) is optional.
>  Converting objects with Signal members should be convertible.  I will
> add this MyHDL object, SignalStruct, to the MEP and outline what you
> have suggested.
>
>> * late signal creation: suppose that I need to calculate the width of
>> a signal, but I already create the container object. A method that
>> create (or update) the signal objects just before simulation or
>> conversion can be defined.
> Late/dynamic signal creation is not an issue as long as it is done
> during elaboration.
>
>> * classes with special method names: what happen if I define the
>> __slot__ list? or if I define a custom __getattr__ or another methods?
>
> No methods would be used/inspected for conversion (ignoring generators
> for now), special methods shouldn't cause a problem.  A member of an
> object, if it is a convertible Signal or a convertible constant will be
> considered for conversion and flattened.
>
> Thanks for the feedback,
> Chris

Best regards
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>



-- 
Oscar Díaz
Key Fingerprint = 904B 306C C3C2 7487 650B  BFAC EDA2 B702 90E9 9964
gpg --keyserver subkeys.pgp.net --recv-keys 90E99964

I recommend using OpenDocument Format
for daily use and exchange of documents.

http://www.fsf.org/campaigns/opendocument

Re: [myhdl-list] MEP : Signal Containers

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

On 11/21/2011 9:39 AM, Oscar Diaz wrote:
> 2011/11/15 Christopher Felton<chr...@gm...>:
>> The following is a *start* to a MEP that describes the conversion
>> support for classes, lists, and dictionaries.  This is just a start of
>> the enhancement description and does not include some of the mechanical
>> (code changes) items worth identifying in a MEP.
>
> Thanks for making this draft. I'm mostly agree this MEP, I'll just add
> some thoughts:
>
> * Since a class could be more powerful than a list or a dict,
> container classes should allow enhanced features i.e. custom naming
> scheme. We can propose hidden methods to support that features, in a
> similar way of the special methods from the python data model:
>
> http://docs.python.org/reference/datamodel.html#special-method-names

If we do this we would need to define a base class, something like 
SignalStruct, that would contain these features.  Past feedback indicate 
they would like general class/objects to be convertible without defining 
a special base class.

I think general class/objects would need to be supported but having an 
additional MyHDL ojbect to help guide conversion would be useful.  Also, 
defining a SignalStruct object would make things easier (my guess) for a 
first implementation.  It might be a good spot to start with and explore 
the conversion routines.

>
> Right now I'm thinking about
>
> * It's not explicitly mentioned, but I guess the conversion step will
> "flatten" the signal container. Although I agree on that, maybe we
> could think about support to conversion to arrays or records (I speak
> mainly for VHDL, I'm not that expert of Verilog).

The argument against using VHDL records is to keep a similar conversion 
for Verilog and VHDL, IMO.  We don't want to use the SystemVerilog 
struct unless it is supported by the open-source compiler/simulators. 
Since we need to flatten it for Verilog I think flattening it VHDL is 
reasonable, least common denominator.

My thought, if we have a special case for VHDL it would be more work to 
develop, maintain, and test.  Personally I like limiting the use of the 
underlying HDL as minimal as possible and maximum overlap between HDLs.

>
> * About the conversion of class methods, I think that should be in
> another MEP, this one is to define signal containers. We should make
> another MEP to add support for conversion of classes (not just class
> methods). However, I do agree that the class methods must have support
> for conversion, as you explained here, and I think it is easy to fix
> the self argument issue in the conversion code.

That is reasonable but I don't follow what you mean by the conversion of 
classes?  In my mind, once you have a mechanism to dig down and find the 
signal, I call them primitives (which is the main purpose of this mep). 
  And generator conversion is already supported (other than a generator 
that is defined in a class).

>
> That's all for now.
>
> Best regards.
>
> P.D.: Perhaps I can help with the VHDL code snippet:
>
> VHDL example conversion.
> .. code-block :: vhdl
>
> entity foo is
>      port (
>          clk: in std_logic;
>          MyObj_x: in unsigned(7 downto 0);
>          MyObj_y: in unsigned(3 downto 0);
>          MyObj_z: out unsigned(8 downto 0)
>      );
> end entity foo;
>
> architecture MyHDL of foo is
>
> begin
>
>      RTL: process(clk) is
>      begin
>          if rising_edge(clk) then
>              MyObj_z<= MyObj_x + MyObj_y
>          end if;
>      end process RTL;
>
> end architecture MyHDL;
>
>

Thanks for the code snip.

> Right now I'm thinking about:
> * custom naming scheme: something like "_names_iter(self)" method that
> returns the desired names for each signal.
I believe an object would need to be provided, that has special hooks 
and methods.  But the use of the object (e.g. SignalStruct) is optional. 
  Converting objects with Signal members should be convertible.  I will 
add this MyHDL object, SignalStruct, to the MEP and outline what you 
have suggested.

> * late signal creation: suppose that I need to calculate the width of
> a signal, but I already create the container object. A method that
> create (or update) the signal objects just before simulation or
> conversion can be defined.
Late/dynamic signal creation is not an issue as long as it is done 
during elaboration.

> * classes with special method names: what happen if I define the
> __slot__ list? or if I define a custom __getattr__ or another methods?

No methods would be used/inspected for conversion (ignoring generators 
for now), special methods shouldn't cause a problem.  A member of an 
object, if it is a convertible Signal or a convertible constant will be 
considered for conversion and flattened.

Thanks for the feedback,
Chris

Re: [myhdl-list] Conversion error to vhdl

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

On 11/21/2011 8:52 AM, Oscar Diaz wrote:
> 2011/11/19 Norbo<Nor...@gm...>:
>> I have played a bit with myhdl and created the following:
>>
>> ----------------------------------------------------------
>>   from myhdl import *
>>
>> def bin2gray(A,B, C, width):
>>
>>      """ Gray encoder.
>>
>>      B -- input intbv signal, binary encoded
>>      G -- output intbv signal, gray encoded
>>      width -- bit width
>>
>>      """
>>      @always_comb
>>      def logic():
>>          C[0].next = A + B
>
> It seems that you have a bug here. Why you assign the result of a sum
> to a single bit? that's the reason why the converter tried to use
> "to_std_logic" for the output. If you want a normal sum, it should be
>
> C.next = A + B
>
> and the VHDL converter will put synthesizable code:
>
> C<= (A + B);
>

Good eye Oscar!

Yes, there are a couple issues with the bin2gray that was provided (I 
assumed the bin2gray was an example for conversion means and not an 
actual bin2gray?).  I didn't notice at first glance but if you want to 
assign a single bit of a bit-vector you need to do:

   C.next[0] = A + B


If you assign the bit correctly the conversion works (even though it 
functional doesn't work).  Simulation will not work!.  Not sure why the 
converter didn't flag this?  Possible error detection enhancement.

Also using the "+" operator instead of the bitwise "^" will cause 
problems in simulation.  The "+" will overflow the range for a single bit.

My previous reply can be ignored and should be ignored.  If any changes 
need to be made they would be in the error catching/reporting and not 
modifications to the conversion.

Regards,
Chris

> Or, if you want a binary to gray encoder, just use the example from
> the documentation
>
> http://www.myhdl.org/doc/current/manual/conversion_examples.html#a-small-combinatorial-design
>
>
> Best Regards
>

Re: [myhdl-list] MEP : Signal Containers

[Oscar D. <osc...@gm...>]

2011/11/21 Oscar Diaz <osc...@gm...>:
> 2011/11/15 Christopher Felton <chr...@gm...>:
>> The following is a *start* to a MEP that describes the conversion
>> support for classes, lists, and dictionaries.  This is just a start of
>> the enhancement description and does not include some of the mechanical
>> (code changes) items worth identifying in a MEP.
>
> Thanks for making this draft. I'm mostly agree this MEP, I'll just add
> some thoughts:
>
> * Since a class could be more powerful than a list or a dict,
> container classes should allow enhanced features i.e. custom naming
> scheme. We can propose hidden methods to support that features, in a
> similar way of the special methods from the python data model:
>
> http://docs.python.org/reference/datamodel.html#special-method-names
>
> Right now I'm thinking about
Sorry, I press Enter too quick :p

Right now I'm thinking about:
* custom naming scheme: something like "_names_iter(self)" method that
returns the desired names for each signal.
* late signal creation: suppose that I need to calculate the width of
a signal, but I already create the container object. A method that
create (or update) the signal objects just before simulation or
conversion can be defined.
* classes with special method names: what happen if I define the
__slot__ list? or if I define a custom __getattr__ or another methods?

-- 
Oscar Díaz
Key Fingerprint = 904B 306C C3C2 7487 650B  BFAC EDA2 B702 90E9 9964
gpg --keyserver subkeys.pgp.net --recv-keys 90E99964

I recommend using OpenDocument Format
for daily use and exchange of documents.

http://www.fsf.org/campaigns/opendocument

Re: [myhdl-list] MEP : Signal Containers

[Oscar D. <osc...@gm...>]

2011/11/15 Christopher Felton <chr...@gm...>:
> The following is a *start* to a MEP that describes the conversion
> support for classes, lists, and dictionaries.  This is just a start of
> the enhancement description and does not include some of the mechanical
> (code changes) items worth identifying in a MEP.

Thanks for making this draft. I'm mostly agree this MEP, I'll just add
some thoughts:

* Since a class could be more powerful than a list or a dict,
container classes should allow enhanced features i.e. custom naming
scheme. We can propose hidden methods to support that features, in a
similar way of the special methods from the python data model:

http://docs.python.org/reference/datamodel.html#special-method-names

Right now I'm thinking about

* It's not explicitly mentioned, but I guess the conversion step will
"flatten" the signal container. Although I agree on that, maybe we
could think about support to conversion to arrays or records (I speak
mainly for VHDL, I'm not that expert of Verilog).

* About the conversion of class methods, I think that should be in
another MEP, this one is to define signal containers. We should make
another MEP to add support for conversion of classes (not just class
methods). However, I do agree that the class methods must have support
for conversion, as you explained here, and I think it is easy to fix
the self argument issue in the conversion code.

That's all for now.

Best regards.

P.D.: Perhaps I can help with the VHDL code snippet:

VHDL example conversion.
.. code-block :: vhdl

entity foo is
    port (
        clk: in std_logic;
        MyObj_x: in unsigned(7 downto 0);
        MyObj_y: in unsigned(3 downto 0);
        MyObj_z: out unsigned(8 downto 0)
    );
end entity foo;

architecture MyHDL of foo is

begin

    RTL: process(clk) is
    begin
        if rising_edge(clk) then
            MyObj_z <= MyObj_x + MyObj_y
        end if;
    end process RTL;

end architecture MyHDL;


-- 
Oscar Díaz
Key Fingerprint = 904B 306C C3C2 7487 650B  BFAC EDA2 B702 90E9 9964
gpg --keyserver subkeys.pgp.net --recv-keys 90E99964

I recommend using OpenDocument Format
for daily use and exchange of documents.

http://www.fsf.org/campaigns/opendocument

Re: [myhdl-list] Conversion error to vhdl

[Oscar D. <osc...@gm...>]

2011/11/19 Norbo <Nor...@gm...>:
> I have played a bit with myhdl and created the following:
>
> ----------------------------------------------------------
>  from myhdl import *
>
> def bin2gray(A,B, C, width):
>
>     """ Gray encoder.
>
>     B -- input intbv signal, binary encoded
>     G -- output intbv signal, gray encoded
>     width -- bit width
>
>     """
>     @always_comb
>     def logic():
>         C[0].next = A + B

It seems that you have a bug here. Why you assign the result of a sum
to a single bit? that's the reason why the converter tried to use
"to_std_logic" for the output. If you want a normal sum, it should be

C.next = A + B

and the VHDL converter will put synthesizable code:

C <= (A + B);

Or, if you want a binary to gray encoder, just use the example from
the documentation

http://www.myhdl.org/doc/current/manual/conversion_examples.html#a-small-combinatorial-design


Best Regards

-- 
Oscar Díaz
Key Fingerprint = 904B 306C C3C2 7487 650B  BFAC EDA2 B702 90E9 9964
gpg --keyserver subkeys.pgp.net --recv-keys 90E99964

I recommend using OpenDocument Format
for daily use and exchange of documents.

http://www.fsf.org/campaigns/opendocument

Re: [myhdl-list] Third-party modules?

[Wesley N. <we...@sk...>]

Hi Gary,

We are doing a similar thing, we are "wrapping" verilog module
instantiations in MyHDL and then writing simulation models for them.

We are instantiating the verilog like such:

 #model
   @always(clk.posedge)
   def logic():
      if (rst == 0 and out < COUNT_TO):
         if (en == 1):
            out == out + STEP
      else:
         out = COUNT_FROM

 #verilog instantiation
   __verilog__ = \
   """
   counter
   #(
      .ARCHITECTURE (%(ARCHITECTURE)s),
      .DATA_WIDTH   (%(DATA_WIDTH)s),
      .COUNT_FROM   (%(COUNT_FROM)s),
      .COUNT_TO     (%(COUNT_TO)s),
      .STEP         (%(STEP)s)
   ) counter_%(block_name)s (
      .clk  (%(clk)s),
      .en   (%(en)s),
      .rst  (%(rst)s),
      .out  (%(out)s)
   );
   """


You can see what we are doing at:  https://github.com/casper-astro/hdl_devel
.

An good example would be the counter module at:
https://github.com/casper-astro/hdl_devel/tree/master/libraries/primitives/counter

Hope this helps.

Wes

On Sun, Nov 20, 2011 at 7:43 PM, garyr <ga...@fi...> wrote:

> ----- Original Message -----
> From: "Christopher Felton" <chr...@gm...>
> To: <myh...@li...>
> Sent: Saturday, November 19, 2011 8:50 PM
> Subject: Re: [myhdl-list] Third-party modules?
>
>
> > On 11/19/11 8:41 PM, garyr wrote:
> >> Thanks for the information. Can this type of code be tested with the
> >> MyHDL
> >> simulator? I have tried something very similar to that but it appeared
> to
> >> have no effect during simulation.
> >
> > If you do CoSimulation you can test the 3rd party IP (presumed to be
> > Verilog or VHDL).  If you want to do MyHDL simulation only, you have to
> > create a model for the IP (or better yet request the IP vendor to create
> > a MyHDL/Python model :) ).
> >
> > Hope that helps,
> > Chris
>
> I should have described my problem in more detail. I'm not actually dealing
> with a third-party module, just modules I have written. I have a utility
> module that I wish to use (not concurrently) with two other modules . I
> wrote some test code and followed the procedure described in Section 8.8
> of the MyHDL manual (which you also described) and inserted a bit of
> Verilog
> code in the primary module that I thought would instantiate the utility
> module. But when I run the simulation it appears that the utility module is
> not instantiated. Here is a bit of my test code:
>
> def test(overflow, count):
>   @always(overflow.negedge)
>   def logic():
>       pass
>  count.driven = "wire"
>  return logic
> test.verilog_code =\
> """overflowCounter inst_1(.ovfl($overflow), .overflowCount($count));"""
>
> def simpleCounter(reset, signal, gate, count, ofCount):
>   overflow = Signal(intbv(0)[5:])
>   instTest = test(overflow, ofCount)
>   instCounter = counter(reset, signal, gate, count, overflow)
>  return instTest, instCounter
>
> The module counter (not shown) is a gated counter; the signal overflow is
> toggled when the counter overflows. The function of the module
> overflowCounter (also not shown) is to count the number of times overflow
> occurred. These two modules when instantiated together as in section 8.4 of
> the manual or in a test bench function correctly. I know very little about
> HDL so the bit of Verilog code above may be incorrect - please comment on
> that. Assuming the Verilog code is correct, if I instantiate the module
> simpleCounter in a test bench will all of the code, overflowCounter
> included, be simulated?
>
> Many thanks,
> Gary Richardson
>
> >
> >>
> >> ----- Original Message -----
> >> From: "Christopher Felton"<chr...@gm...>
> >> To:<myh...@li...>
> >> Sent: Saturday, November 19, 2011 3:00 PM
> >> Subject: Re: [myhdl-list] Third-party modules?
> >>
> >>
> >>> On 11/19/11 12:57 PM, garyr wrote:
> >>>> One of the entries in the MyHDL Frequently Asked Questions states that
> >>>> third-party modules may be instantiated by using "user-defined code to
> >>>> replace a MyHDL module by a corresponding instantiation".  My attempts
> >>>> at this have not been successful. Could someone point me to an
> example?
> >>>>
> >>>> Thanks in advance for your replies.
> >>>>
> >>>>
> >>>
> >>> Here is a reply from a earlier, similar, inquiry.  You might want to
> >>> refer to the old thread, http://bit.ly/uHcVZi.
> >>>
> >>> Regards,
> >>> Chris
> >>>
> >>>> Here is a small example to achieve what (I think) you are describing.
> >>>> More information can be found here,
> >>>>
> http://www.myhdl.org/doc/current/manual/conversion_examples.html#conv-usage-custom
> >>>>
> >>>> from myhdl import *
> >>>>
> >>>> def BurriedInstance(clk, rst, data_in, data_out):
> >>>>
> >>>>       # ... Some Code
> >>>>       bi = nativeInstance(clk, rst, data_in, data_out)
> >>>>       # ... Some More Code
> >>>>
> >>>>       return bi  #other generators
> >>>>
> >>>> def nativeInstance(clk, rst, data_in, data_out):
> >>>>
> >>>>       @always(clk, rst, data_in)
> >>>>       def pass_thru():
> >>>>           pass
> >>>>       data_out.driven = "wire"
> >>>>
> >>>>       nativeInstance.vhdl_code = """
> >>>>       P1:ppc port map($clk, $rst, $data_in, $data_out);
> >>>>       """
> >>>>
> >>>>       return pass_thru
> >>>>
> >>>>
> >>>> if __name__ == '__main__':
> >>>>       clk = Signal(False)
> >>>>       rst = Signal(False)
> >>>>       data_in  = Signal(intbv(0)[8:])
> >>>>       data_out = Signal(intbv(0)[8:])
> >>>>       toVHDL(BurriedInstance, clk, rst, data_in, data_out)
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> ------------------------------------------------------------------------------
> >>> All the data continuously generated in your IT infrastructure
> >>> contains a definitive record of customers, application performance,
> >>> security threats, fraudulent activity, and more. Splunk takes this
> >>> data and makes sense of it. IT sense. And common sense.
> >>> http://p.sf.net/sfu/splunk-novd2d
> >>> _______________________________________________
> >>> myhdl-list mailing list
> >>> myh...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/myhdl-list
> >>>
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> All the data continuously generated in your IT infrastructure
> >> contains a definitive record of customers, application performance,
> >> security threats, fraudulent activity, and more. Splunk takes this
> >> data and makes sense of it. IT sense. And common sense.
> >> http://p.sf.net/sfu/splunk-novd2d
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > All the data continuously generated in your IT infrastructure
> > contains a definitive record of customers, application performance,
> > security threats, fraudulent activity, and more. Splunk takes this
> > data and makes sense of it. IT sense. And common sense.
> > http://p.sf.net/sfu/splunk-novd2d
> > _______________________________________________
> > myhdl-list mailing list
> > myh...@li...
> > https://lists.sourceforge.net/lists/listinfo/myhdl-list
> >
>
>
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] Third-party modules?

[garyr <ga...@fi...>]

----- Original Message ----- 
From: "Christopher Felton" <chr...@gm...>
To: <myh...@li...>
Sent: Saturday, November 19, 2011 8:50 PM
Subject: Re: [myhdl-list] Third-party modules?


> On 11/19/11 8:41 PM, garyr wrote:
>> Thanks for the information. Can this type of code be tested with the
>> MyHDL
>> simulator? I have tried something very similar to that but it appeared to
>> have no effect during simulation.
>
> If you do CoSimulation you can test the 3rd party IP (presumed to be
> Verilog or VHDL).  If you want to do MyHDL simulation only, you have to
> create a model for the IP (or better yet request the IP vendor to create
> a MyHDL/Python model :) ).
>
> Hope that helps,
> Chris

I should have described my problem in more detail. I'm not actually dealing
with a third-party module, just modules I have written. I have a utility
module that I wish to use (not concurrently) with two other modules . I
wrote some test code and followed the procedure described in Section 8.8
of the MyHDL manual (which you also described) and inserted a bit of Verilog
code in the primary module that I thought would instantiate the utility
module. But when I run the simulation it appears that the utility module is
not instantiated. Here is a bit of my test code:

def test(overflow, count):
   @always(overflow.negedge)
   def logic():
       pass
 count.driven = "wire"
 return logic
test.verilog_code =\
"""overflowCounter inst_1(.ovfl($overflow), .overflowCount($count));"""

def simpleCounter(reset, signal, gate, count, ofCount):
   overflow = Signal(intbv(0)[5:])
   instTest = test(overflow, ofCount)
   instCounter = counter(reset, signal, gate, count, overflow)
 return instTest, instCounter

The module counter (not shown) is a gated counter; the signal overflow is
toggled when the counter overflows. The function of the module
overflowCounter (also not shown) is to count the number of times overflow
occurred. These two modules when instantiated together as in section 8.4 of
the manual or in a test bench function correctly. I know very little about
HDL so the bit of Verilog code above may be incorrect - please comment on
that. Assuming the Verilog code is correct, if I instantiate the module
simpleCounter in a test bench will all of the code, overflowCounter
included, be simulated?

Many thanks,
Gary Richardson

>
>>
>> ----- Original Message -----
>> From: "Christopher Felton"<chr...@gm...>
>> To:<myh...@li...>
>> Sent: Saturday, November 19, 2011 3:00 PM
>> Subject: Re: [myhdl-list] Third-party modules?
>>
>>
>>> On 11/19/11 12:57 PM, garyr wrote:
>>>> One of the entries in the MyHDL Frequently Asked Questions states that
>>>> third-party modules may be instantiated by using "user-defined code to
>>>> replace a MyHDL module by a corresponding instantiation".  My attempts
>>>> at this have not been successful. Could someone point me to an example?
>>>>
>>>> Thanks in advance for your replies.
>>>>
>>>>
>>>
>>> Here is a reply from a earlier, similar, inquiry.  You might want to
>>> refer to the old thread, http://bit.ly/uHcVZi.
>>>
>>> Regards,
>>> Chris
>>>
>>>> Here is a small example to achieve what (I think) you are describing.
>>>> More information can be found here,
>>>> http://www.myhdl.org/doc/current/manual/conversion_examples.html#conv-usage-custom
>>>>
>>>> from myhdl import *
>>>>
>>>> def BurriedInstance(clk, rst, data_in, data_out):
>>>>
>>>>       # ... Some Code
>>>>       bi = nativeInstance(clk, rst, data_in, data_out)
>>>>       # ... Some More Code
>>>>
>>>>       return bi  #other generators
>>>>
>>>> def nativeInstance(clk, rst, data_in, data_out):
>>>>
>>>>       @always(clk, rst, data_in)
>>>>       def pass_thru():
>>>>           pass
>>>>       data_out.driven = "wire"
>>>>
>>>>       nativeInstance.vhdl_code = """
>>>>       P1:ppc port map($clk, $rst, $data_in, $data_out);
>>>>       """
>>>>
>>>>       return pass_thru
>>>>
>>>>
>>>> if __name__ == '__main__':
>>>>       clk = Signal(False)
>>>>       rst = Signal(False)
>>>>       data_in  = Signal(intbv(0)[8:])
>>>>       data_out = Signal(intbv(0)[8:])
>>>>       toVHDL(BurriedInstance, clk, rst, data_in, data_out)
>>>>
>>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> All the data continuously generated in your IT infrastructure
>>> contains a definitive record of customers, application performance,
>>> security threats, fraudulent activity, and more. Splunk takes this
>>> data and makes sense of it. IT sense. And common sense.
>>> http://p.sf.net/sfu/splunk-novd2d
>>> _______________________________________________
>>> myhdl-list mailing list
>>> myh...@li...
>>> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure
>> contains a definitive record of customers, application performance,
>> security threats, fraudulent activity, and more. Splunk takes this
>> data and makes sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-novd2d
>
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] Conversion error to vhdl

[Norbo <Nor...@gm...>]

On Sun, 20 Nov 2011 15:37:29 +0100, Christopher Felton  
<chr...@gm...> wrote:

> On 11/19/11 4:22 PM, Norbo wrote:
>> I have played a bit with myhdl and created the following:
> [snip]
>> --------------------------------------------------
>> -- File: bin2gray.vhd
>> -- Generated by MyHDL 0.7
>> -- Date: Sat Nov 19 22:54:16 2011
>>
>>
>> library IEEE;
>> use IEEE.std_logic_1164.all;
>> use IEEE.numeric_std.all;
>> use std.textio.all;
>>
>> use work.pck_myhdl_07.all;
>>
>> entity bin2gray is
>>       port (
>>           A: in unsigned(7 downto 0);
>>           B: in unsigned(7 downto 0);
>>           C: out unsigned(7 downto 0)
>>       );
>> end entity bin2gray;
>> -- Gray encoder.
>
> If you notice the generated VHDL uses a library, pck_myhdl_07.  This is
> an additional VHDL file that is generated with the conversion.  You need
> to include this file (pck_myhdl07.vhd) in your synthesis tools.
>
> If it looks like the file did not generate correctly, delete the
> pck_myhdl_07 and rerun the conversion.  If you have to do this let use  
> know.
>
> Hope that helps,
> Chris
>
>


I deleted the file  (pck_myhdl07.vhd) and it  successfully regenerated,  
after including this file
in the synthesis tool (lattice diamond) i had the same error (No matching  
overload for to_std_logic). There seems to be no function to_std_logic in  
the (pck_myhdl07.vhd).
The only "to_std_logic" functions in the generated pck_myhdl07.vhd pack  
are:

     function to_std_logic (arg: boolean) return std_logic;

     function to_std_logic (arg: integer) return std_logic;

an version which takes an unsigned is missing. I also couldn't find such  
an version of the "to_std_logic" function in the ieee library s

greetings,
Norbert

Re: [myhdl-list] Conversion error to vhdl

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

On 11/19/11 4:22 PM, Norbo wrote:
> I have played a bit with myhdl and created the following:
[snip]
> --------------------------------------------------
> -- File: bin2gray.vhd
> -- Generated by MyHDL 0.7
> -- Date: Sat Nov 19 22:54:16 2011
>
>
> library IEEE;
> use IEEE.std_logic_1164.all;
> use IEEE.numeric_std.all;
> use std.textio.all;
>
> use work.pck_myhdl_07.all;
>
> entity bin2gray is
>       port (
>           A: in unsigned(7 downto 0);
>           B: in unsigned(7 downto 0);
>           C: out unsigned(7 downto 0)
>       );
> end entity bin2gray;
> -- Gray encoder.

If you notice the generated VHDL uses a library, pck_myhdl_07.  This is 
an additional VHDL file that is generated with the conversion.  You need 
to include this file (pck_myhdl07.vhd) in your synthesis tools.

If it looks like the file did not generate correctly, delete the 
pck_myhdl_07 and rerun the conversion.  If you have to do this let use know.

Hope that helps,
Chris

[myhdl-list] Conversion error to vhdl

[Norbo <Nor...@gm...>]

I have played a bit with myhdl and created the following:

----------------------------------------------------------
 from myhdl import *

def bin2gray(A,B, C, width):

     """ Gray encoder.

     B -- input intbv signal, binary encoded
     G -- output intbv signal, gray encoded
     width -- bit width

     """
     @always_comb
     def logic():
         C[0].next = A + B
		
     return logic


def main():
     width = 8

     A = Signal(intbv(0)[width:])
     B = Signal(intbv(0)[width:])
     C = Signal(intbv(0)[width:])
	
     toVHDL(bin2gray, A, B,C, width)

if __name__ == '__main__':
     main()
---------------------------------------------


after conversion it gives me the following .vhd file:

--------------------------------------------------
-- File: bin2gray.vhd
-- Generated by MyHDL 0.7
-- Date: Sat Nov 19 22:54:16 2011


library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.numeric_std.all;
use std.textio.all;

use work.pck_myhdl_07.all;

entity bin2gray is
     port (
         A: in unsigned(7 downto 0);
         B: in unsigned(7 downto 0);
         C: out unsigned(7 downto 0)
     );
end entity bin2gray;
-- Gray encoder.
-- 
-- B -- input intbv signal, binary encoded
-- G -- output intbv signal, gray encoded
-- width -- bit width

architecture MyHDL of bin2gray is


begin





C(0) <= to_std_logic(A + B);

end architecture MyHDL;
--------------------------------------

this seems not to be synthesisable because there is no "to_std_logic"  
function for unsigned type
do i miss something?

Re: [myhdl-list] Third-party modules?

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

On 11/19/11 8:41 PM, garyr wrote:
> Thanks for the information. Can this type of code be tested with the MyHDL
> simulator? I have tried something very similar to that but it appeared to
> have no effect during simulation.

If you do CoSimulation you can test the 3rd party IP (presumed to be 
Verilog or VHDL).  If you want to do MyHDL simulation only, you have to 
create a model for the IP (or better yet request the IP vendor to create 
a MyHDL/Python model :) ).

Hope that helps,
Chris

>
> ----- Original Message -----
> From: "Christopher Felton"<chr...@gm...>
> To:<myh...@li...>
> Sent: Saturday, November 19, 2011 3:00 PM
> Subject: Re: [myhdl-list] Third-party modules?
>
>
>> On 11/19/11 12:57 PM, garyr wrote:
>>> One of the entries in the MyHDL Frequently Asked Questions states that
>>> third-party modules may be instantiated by using "user-defined code to
>>> replace a MyHDL module by a corresponding instantiation".  My attempts
>>> at this have not been successful. Could someone point me to an example?
>>>
>>> Thanks in advance for your replies.
>>>
>>>
>>
>> Here is a reply from a earlier, similar, inquiry.  You might want to
>> refer to the old thread, http://bit.ly/uHcVZi.
>>
>> Regards,
>> Chris
>>
>>> Here is a small example to achieve what (I think) you are describing.
>>> More information can be found here,
>>> http://www.myhdl.org/doc/current/manual/conversion_examples.html#conv-usage-custom
>>>
>>> from myhdl import *
>>>
>>> def BurriedInstance(clk, rst, data_in, data_out):
>>>
>>>       # ... Some Code
>>>       bi = nativeInstance(clk, rst, data_in, data_out)
>>>       # ... Some More Code
>>>
>>>       return bi  #other generators
>>>
>>> def nativeInstance(clk, rst, data_in, data_out):
>>>
>>>       @always(clk, rst, data_in)
>>>       def pass_thru():
>>>           pass
>>>       data_out.driven = "wire"
>>>
>>>       nativeInstance.vhdl_code = """
>>>       P1:ppc port map($clk, $rst, $data_in, $data_out);
>>>       """
>>>
>>>       return pass_thru
>>>
>>>
>>> if __name__ == '__main__':
>>>       clk = Signal(False)
>>>       rst = Signal(False)
>>>       data_in  = Signal(intbv(0)[8:])
>>>       data_out = Signal(intbv(0)[8:])
>>>       toVHDL(BurriedInstance, clk, rst, data_in, data_out)
>>>
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure
>> contains a definitive record of customers, application performance,
>> security threats, fraudulent activity, and more. Splunk takes this
>> data and makes sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-novd2d
>> _______________________________________________
>> myhdl-list mailing list
>> myh...@li...
>> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>>
>
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d

Re: [myhdl-list] Third-party modules?

[garyr <ga...@fi...>]

Thanks for the information. Can this type of code be tested with the MyHDL 
simulator? I have tried something very similar to that but it appeared to 
have no effect during simulation.

----- Original Message ----- 
From: "Christopher Felton" <chr...@gm...>
To: <myh...@li...>
Sent: Saturday, November 19, 2011 3:00 PM
Subject: Re: [myhdl-list] Third-party modules?


> On 11/19/11 12:57 PM, garyr wrote:
>> One of the entries in the MyHDL Frequently Asked Questions states that
>> third-party modules may be instantiated by using "user-defined code to
>> replace a MyHDL module by a corresponding instantiation".  My attempts
>> at this have not been successful. Could someone point me to an example?
>>
>> Thanks in advance for your replies.
>>
>>
>
> Here is a reply from a earlier, similar, inquiry.  You might want to
> refer to the old thread, http://bit.ly/uHcVZi.
>
> Regards,
> Chris
>
>> Here is a small example to achieve what (I think) you are describing.
>> More information can be found here,
>> http://www.myhdl.org/doc/current/manual/conversion_examples.html#conv-usage-custom
>>
>> from myhdl import *
>>
>> def BurriedInstance(clk, rst, data_in, data_out):
>>
>>      # ... Some Code
>>      bi = nativeInstance(clk, rst, data_in, data_out)
>>      # ... Some More Code
>>
>>      return bi  #other generators
>>
>> def nativeInstance(clk, rst, data_in, data_out):
>>
>>      @always(clk, rst, data_in)
>>      def pass_thru():
>>          pass
>>      data_out.driven = "wire"
>>
>>      nativeInstance.vhdl_code = """
>>      P1:ppc port map($clk, $rst, $data_in, $data_out);
>>      """
>>
>>      return pass_thru
>>
>>
>> if __name__ == '__main__':
>>      clk = Signal(False)
>>      rst = Signal(False)
>>      data_in  = Signal(intbv(0)[8:])
>>      data_out = Signal(intbv(0)[8:])
>>      toVHDL(BurriedInstance, clk, rst, data_in, data_out)
>>
>>
>
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
> 

Re: [myhdl-list] Third-party modules?

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

On 11/19/11 12:57 PM, garyr wrote:
> One of the entries in the MyHDL Frequently Asked Questions states that
> third-party modules may be instantiated by using "user-defined code to
> replace a MyHDL module by a corresponding instantiation".  My attempts
> at this have not been successful. Could someone point me to an example?
>
> Thanks in advance for your replies.
>
>

Here is a reply from a earlier, similar, inquiry.  You might want to 
refer to the old thread, http://bit.ly/uHcVZi.

Regards,
Chris

> Here is a small example to achieve what (I think) you are describing.
> More information can be found here,
> http://www.myhdl.org/doc/current/manual/conversion_examples.html#conv-usage-custom
>
> from myhdl import *
>
> def BurriedInstance(clk, rst, data_in, data_out):
>
>      # ... Some Code
>      bi = nativeInstance(clk, rst, data_in, data_out)
>      # ... Some More Code
>
>      return bi  #other generators
>
> def nativeInstance(clk, rst, data_in, data_out):
>
>      @always(clk, rst, data_in)
>      def pass_thru():
>          pass
>      data_out.driven = "wire"
>
>      nativeInstance.vhdl_code = """
>      P1:ppc port map($clk, $rst, $data_in, $data_out);
>      """
>
>      return pass_thru
>
>
> if __name__ == '__main__':
>      clk = Signal(False)
>      rst = Signal(False)
>      data_in  = Signal(intbv(0)[8:])
>      data_out = Signal(intbv(0)[8:])
>      toVHDL(BurriedInstance, clk, rst, data_in, data_out)
>
>

[myhdl-list] Third-party modules?

[garyr <ga...@fi...>]

One of the entries in the MyHDL Frequently Asked Questions states that
third-party modules may be instantiated by using "user-defined code to
replace a MyHDL module by a corresponding instantiation".  My attempts
at this have not been successful. Could someone point me to an example?

Thanks in advance for your replies. 

[myhdl-list] MEP : Signal Containers

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

The following is a *start* to a MEP that describes the conversion 
support for classes, lists, and dictionaries.  This is just a start of 
the enhancement description and does not include some of the mechanical 
(code changes) items worth identifying in a MEP.

I am posting the rough draft of the enhancement because there was 
interest in this enhancement and others might want to contribute to the 
MEP and code changes.  Also, some initial development might occur before 
Jan returns but finalization will await his review.

All feedback welcome.  After some time (initial feedback) this will be 
moved to the wiki.

Regards,
Chris

******************
Signal Containers
******************

Introduction
=============
The following is a proposal to add conversion support for Signal 
containers.  Signal containers are; classes, lists, and dictionaries 
that contain a Signal type.  Lists, and dictionaries are built-in data 
structures in the Python programming language.  A class is the common 
method to define objects.  For more information on Python classes, 
lists, and dictionaries see `[1]`_, `[2]`_, `[3]`_ and `[4]`_.

Another native data structure in the Python programming language is the 
tuple.  Tuples are non-mutable and not usable in this case.  Tuples are 
useful when defining `ROMS`_ and currently supported.  The rest of this
enhancement proposal will outline the addition of classes, lists, and
dictionaries to the MyHDL convertible subset of the Python programming 
language.  Through the rest of this document the term "container(s)" 
will be used to refer to data structures and objects that contains 
Signals and other convertible types.

.. _[1] : http://docs.python.org/tutorial/classes.html
.. _[2] : http://docs.python.org/tutorial/introduction.html#lists
.. _[3] : http://docs.python.org/tutorial/datastructures.html
.. _[4] : http://docs.python.org/tutorial/datastructures.html#dictionaries
.. _ROMS : 
http://www.myhdl.org/doc/0.6/manual/conversion_examples.html#rom-inference


The desired approach is to generate a unique name for a Signal that is 
part of a container.  If an expression includes a "container" a net name 
will be generate for the Signal, example ::

   myObject.x.next = ListOfSignal[10] + DictOfSignal['fred']

The above example has all three container types; a class, a list with 
signals and a dictionary with signals.  The conversion utilities would 
determine if the type referenced is a Signal and then create a unique 
name for the Signal. ::

   myObject_x = ListOfSignal_10 + DictOfSignal_fred

The converter will simply use the container's instance name as part of 
the net name.  The same rules that apply to hierarchy naming will be 
included.  The above might be converted to something like the following 
to avoid name collisions. ::

   mod1_mod2_myObject_x = mod1_mod2_ListOfSignal_10 + 
mod1_mod2_DictOfSignal_fred

In other cases a data structure might not contain a Signal but a 
constant (literals).  In this case the conversion methods will dig down 
to find the constant and use the constant value.

Required support:

  * Expansion of Signal container names
  * Containers as ports
  * Containers as sensitivity lists
  * Resolution of data in data structures



In general, containers can be used, as long as the final
referenced object is a convertible type (Signal, int, long, bool, 
intbv).  All of the above is supported for modeling in MyHDL 0.7, except 
for "containers as sensitivity lists" as discussed in the mailing-list.

This feature is similar to the VHDL record and SystemVerilog struct. 
The idea is that signals can be logically grouped.  This can be very 
useful to a designer to logically group signals.

Variables in containers
------------------------
Variables should be supported as well.  When variables are used, if 
needed, the variable should be converted to a long net name.  Variables 
in containers will follow the same rules as outlined for signals in a 
container.

Classes
========
Classes that contain Signals or a hierarchy of classes that eventually
contain a Signal should be converted.  Classes should be converted
according to the following rules:

   #. The object attribute referenced is a convertible type

      #. Left hand side : Signal of type intbv or bool
      #. Right hand side : int, long, bool, intbv or a Signal of type
         int, long, bool, intbv

   #. The object being referenced will be represented in the
      converted code as a long-net-name.  Long-net-names are
      derived by:

      #. Hierarchy name rules (which are?)
      #. Class path name, example ::
           class.refObj = class_refObj
           class1.class2.refObj = class1_class2_refObj


Example
--------
.. code-block :: python

   class MyObj(object):
      def __init__(self):
         x = Signal(intbv(0)[8:])
         y = Signal(intbv(0)[4:])
         z = Signal(intbv(0)[9:])

   def foo(clk, srst, xyz):

      @always(clk.posedge)
      def rtl():
	xyz.z.next = xyz.x + xyz.y

      return rtl

   if __name__ == '__main__':
      clk = Signal(False)
      xyz = MyObj()
      toVerilog(foo, clk, xyz)

Verilog example conversion for the above.

.. code-block :: verilog

    module foo
    (
      input  wire  clk,
      input  wire  [7:0] MyObj_x,
      input  wire  [3:0] MyObj_y,
      output wire  [8:0] MyObj_z
   ):

      always @(posedge clk) begin
         MyObj_z <= MyObj_x + MyObj_y
      end

   endmodule

VHDL example conversion.
.. code-block :: vhdl

    -- TBC

Conversion of class methods
----------------------------
Generally speaking, the conversion of a class method that is a generator 
(yields not returns) is convertible.  But it is not supported because 
the first argument to a class method is the object instance that 
contains the method (usually self).  In conversion this is converted as 
a port.  Another change proposed in this MEP is to ignore the first 
parameter of a class method so that class methods can be converted 
directly.  This makes the conversion of classes more complete.

For class methods, the only exception (difference) to the converter 
compared to a standard function is to ignore the first argument of the 
class method.  The rest of the conversion would functionally be 
equivalent to the function conversion.


Heterogeneous List Of Signals
==============================
Here heterogeneous is used to differentiate a list of signals that 
contain different signal types versus list of signals that is 
homogeneous, all the same type of signals.  Homogeneous list of signals 
are currently supported and convert to the underlying HDL as an array of 
bit-vectors.  This is useful for defining `memories`_.

The functions that determines a memory object will need to be enhanced 
to differentiate a homogeneous list of signals from a heterogeneous list 
of signals.

.. _memories : 
http://www.myhdl.org/doc/0.6/manual/conversion_examples.html#ram-inference


Dictionaries
============
Similar to the class conversion dictionaries should be convertible as
well.  The same rules that applied to class conversion should be applied
to dictionaries.

Re: [myhdl-list] Pythonic Test frameworks

[Uri N. <ur...@gm...>]

On 9 November 2011 05:14, Christopher Felton <chr...@gm...> wrote:

> On 11/8/11 9:01 PM, Christopher Felton wrote:
> > On 11/8/11 7:04 PM, Bob Cunningham wrote:
> >> On 11/07/2011 08:07 PM, Christopher Felton wrote:
> >>> On 11/7/11 7:21 PM, Bob Cunningham wrote:
> >>>> FWIW, py.test seems to be the way MyHDL itself is going...
> >>>>
> >>>> -BobC
> >>> ...
> >>
> >>> The following, http://bit.ly/sc3vrI, is a brief mention of py.test
> used
> >>> instead of unittest (from a couple years ago) from the myhdl-list.
> >>>
> >>> But I do believe py.test is limited.  If you are ok writing with only
> >>> simple asserts, I believe py.test is ok.  But unittest supports more
> >>> advanced features, automatically verify raised exceptions (continue if
> >>> raised fail if not).
> >>>
> >>> I guess an argument against py.test, is that it is another package that
> >>> needs to be installed.  Where as, unittest is part of the standard
> >>> Python library, hmmm.
> >>>
> >>> Regards,
> >>> Chris
> >>
> >> Well, MyHDL is, itself, "another package that needs to be installed"!
> >>
> >> See the end of this page:
> http://www.myhdl.org/doku.php/cookbook:stopwatch
> >
> > Thanks for the reminder, this is a good commentary on py.test versus
> > unittest.  This is a good read for anyone trying to determine which test
> > framework to use.
>
> I think this is the important quote from the py.test commentary at the
> end of the stopwatch example.
>
> """
> However, I believe that the benefits are far more important than the
> disadvantages. Moreover, some disadvantages may disappear over time.
> Consequently, I plan to promote py.test as the unit testing framework of
> choice for MyHDL in the future.
> """
>
> I don't think anything has changed since this was posted.
>
> Regards,
> Chris
>
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Hi,

Since I kind of started this py.test vs unittest discussion, I might as
well add my own take :)
IMO a non-standard library should have some really compelling feature to be
required as a project's dependency, and unittest had fulfills all my needs:
from regression framework for external (black box) testing, to pure Python
and of course myHDL projects.
A beneficial feature of py.test would appear to be its scalability across
multiple processors. A remarkable feature of Nose (another popular
framework, used by numpy) is the ability to generate tests using
generators. Both however are a bit overkill for my purposes.
Regarding the requirement of testing for exceptions - I would recommend
checking the latest enhancements in 2.7, which made unittest even more
comprehensive.

Cheers,
Uri

Re: [myhdl-list] State machine modeling

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

On 11/9/2011 9:29 AM, Oscar Diaz wrote:
> 2011/11/9 Christopher Felton<chr...@gm...>:
>> On 11/9/2011 6:36 AM, Oscar Diaz wrote:
>>> Hi
>>>
>>> Recently I had some problems converting state machines to VHDL. In my
>>> models I use two generators: one with the state sequence and another
>>> with the output based on the states. For this second generator I use
>>> @always_comb, since its just combinatorial logic. Works perfect in
>>> simulation but fails on conversion. Then I did a workaround: put
>>> manually a sensitivity list with @always(list_of_signals) and then the
>>> conversion step worked fine.
>>>
>>> I wonder if it's a bug in conversion, or if there's a better way to
>>> model a state machine. I attach a small example to show my dilemma.
>>>
>>> Best regards
>>>
>>>
>>
>>
>> I believe the converter is limited at this point.  The converter
>> verifies that only basic types are used in the always_comb.  I do not
>> know if this was intentional or not.  This is kinda similar to "Signals"
>> that are part of a class.  Complex types are not really supported.  You
>> would have the same problem if you did something like this:
>>
>> ~~~ [Code Snip] ~~~
>> def mycode(x, y):
>>
>>     class Structure():
>>        def __init__(self):
>>           self.SomeNumber = 2
>>           self.SomeOtherNumber = 3
>>
>>     A = Structure()
>>
>>     @always_comb
>>     def outputs():
>>        if x == A.SomeNumber:
>>           y.next = 99
>>        elif x == A.SomeOtherNumber:
>>           y.next = 34
>>        else:
>>           y.next = 0
>>
>>     return outputs
>>
>> ~~~ [End Code Snip] ~~~
>>
>> In the above code example, the class is being used as a fancy container
>> for some information.  And the information is just an int.  But the
>> converter will analyze A.<class member>  as an instance of "Structure"
>> and not one of the primitives int, long, Signal ...
>>
>> I think this is simply a limitation right now but it isn't a trivial
>> modification (at least I don't think so).  There has to be some thought
>> and conversation around how this is resolved.
>
> I had the same problems with classes that are signal containers in
> other designs; in fact I think we need to find an elegant way to use
> complex types for conversion, and that would be a big enhancement for
> myhdl. I find particularly annoying to keep two equivalent models just
> for conversion.
>
> Right now I use a generic class based on dict, when additional
> information can be added (Signal name on the key, description,
> complement signal on case of a bus interconnect, etc). Designs can use
> this class or subclass it for its own needs. There's nothing to be
> done on simulation, that works perfectly in my projects. Changes must
> be made in the conversion, I think that object can "unroll" to a
> signal list on the generated code.
>
>>
>> This has come up in other contexts as well.  It is a reasonable
>> enhancement to be added.  But it will take some time to spec out the
>> modification and make the changes.  Right now I would consider it a
>> limitation and an item that might be addressed in the future.
>
> I agree, Can this issue be a MEP or just reported as a bug?
>>
>> If your current work around works, I would use that for the time being.
>>   I don't see any issues with the @always(<Signal(enum)>).
>
> Just what I feared :p
>

This is definitely a MEP, it is not advertised that the complex data 
structures are supported.  The MEP should cover, as you mention, 
classes, dicts, and heterogeneous list of signals (any others?).

A month (or more) ago I started to write a draft of a MEP on this topic 
and there have been some incomplete contributions.  I can post the 
(rough-de-rough) draft of the MEP here, we can refine some and then 
create a MEP on the wiki.  I didn't post it because I don't have much 
understanding of the back-end conversion (the Python.ast etc.) and time 
is a scarce commodity.

Regards,
Chris

Re: [myhdl-list] State machine modeling

[Oscar D. <osc...@gm...>]

2011/11/9 Christopher Felton <chr...@gm...>:
> On 11/9/2011 6:36 AM, Oscar Diaz wrote:
>> Hi
>>
>> Recently I had some problems converting state machines to VHDL. In my
>> models I use two generators: one with the state sequence and another
>> with the output based on the states. For this second generator I use
>> @always_comb, since its just combinatorial logic. Works perfect in
>> simulation but fails on conversion. Then I did a workaround: put
>> manually a sensitivity list with @always(list_of_signals) and then the
>> conversion step worked fine.
>>
>> I wonder if it's a bug in conversion, or if there's a better way to
>> model a state machine. I attach a small example to show my dilemma.
>>
>> Best regards
>>
>>
>
>
> I believe the converter is limited at this point.  The converter
> verifies that only basic types are used in the always_comb.  I do not
> know if this was intentional or not.  This is kinda similar to "Signals"
> that are part of a class.  Complex types are not really supported.  You
> would have the same problem if you did something like this:
>
> ~~~ [Code Snip] ~~~
> def mycode(x, y):
>
>    class Structure():
>       def __init__(self):
>          self.SomeNumber = 2
>          self.SomeOtherNumber = 3
>
>    A = Structure()
>
>    @always_comb
>    def outputs():
>       if x == A.SomeNumber:
>          y.next = 99
>       elif x == A.SomeOtherNumber:
>          y.next = 34
>       else:
>          y.next = 0
>
>    return outputs
>
> ~~~ [End Code Snip] ~~~
>
> In the above code example, the class is being used as a fancy container
> for some information.  And the information is just an int.  But the
> converter will analyze A.<class member> as an instance of "Structure"
> and not one of the primitives int, long, Signal ...
>
> I think this is simply a limitation right now but it isn't a trivial
> modification (at least I don't think so).  There has to be some thought
> and conversation around how this is resolved.

I had the same problems with classes that are signal containers in
other designs; in fact I think we need to find an elegant way to use
complex types for conversion, and that would be a big enhancement for
myhdl. I find particularly annoying to keep two equivalent models just
for conversion.

Right now I use a generic class based on dict, when additional
information can be added (Signal name on the key, description,
complement signal on case of a bus interconnect, etc). Designs can use
this class or subclass it for its own needs. There's nothing to be
done on simulation, that works perfectly in my projects. Changes must
be made in the conversion, I think that object can "unroll" to a
signal list on the generated code.

>
> This has come up in other contexts as well.  It is a reasonable
> enhancement to be added.  But it will take some time to spec out the
> modification and make the changes.  Right now I would consider it a
> limitation and an item that might be addressed in the future.

I agree, Can this issue be a MEP or just reported as a bug?
>
> If your current work around works, I would use that for the time being.
>  I don't see any issues with the @always(<Signal(enum)>).

Just what I feared :p

>
> Regards,
> Chris
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Best regards

--
Oscar Díaz
Key Fingerprint = 904B 306C C3C2 7487 650B  BFAC EDA2 B702 90E9 9964
gpg --keyserver subkeys.pgp.net --recv-keys 90E99964

I recommend using OpenDocument Format
for daily use and exchange of documents.

http://www.spreadopendocument.org/

Re: [myhdl-list] State machine modeling

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

On 11/9/2011 6:36 AM, Oscar Diaz wrote:
> Hi
>
> Recently I had some problems converting state machines to VHDL. In my
> models I use two generators: one with the state sequence and another
> with the output based on the states. For this second generator I use
> @always_comb, since its just combinatorial logic. Works perfect in
> simulation but fails on conversion. Then I did a workaround: put
> manually a sensitivity list with @always(list_of_signals) and then the
> conversion step worked fine.
>
> I wonder if it's a bug in conversion, or if there's a better way to
> model a state machine. I attach a small example to show my dilemma.
>
> Best regards
>
>


I believe the converter is limited at this point.  The converter 
verifies that only basic types are used in the always_comb.  I do not 
know if this was intentional or not.  This is kinda similar to "Signals" 
that are part of a class.  Complex types are not really supported.  You 
would have the same problem if you did something like this:

~~~ [Code Snip] ~~~
def mycode(x, y):

    class Structure():
       def __init__(self):
          self.SomeNumber = 2
          self.SomeOtherNumber = 3

    A = Structure()

    @always_comb
    def outputs():
       if x == A.SomeNumber:
          y.next = 99
       elif x == A.SomeOtherNumber:
          y.next = 34
       else:
          y.next = 0

    return outputs

~~~ [End Code Snip] ~~~

In the above code example, the class is being used as a fancy container 
for some information.  And the information is just an int.  But the 
converter will analyze A.<class member> as an instance of "Structure" 
and not one of the primitives int, long, Signal ...

I think this is simply a limitation right now but it isn't a trivial 
modification (at least I don't think so).  There has to be some thought 
and conversation around how this is resolved.

This has come up in other contexts as well.  It is a reasonable 
enhancement to be added.  But it will take some time to spec out the 
modification and make the changes.  Right now I would consider it a 
limitation and an item that might be addressed in the future.

If your current work around works, I would use that for the time being. 
  I don't see any issues with the @always(<Signal(enum)>).

Regards,
Chris

[myhdl-list] State machine modeling

[Oscar D. <osc...@gm...>]

Hi

Recently I had some problems converting state machines to VHDL. In my
models I use two generators: one with the state sequence and another
with the output based on the states. For this second generator I use
@always_comb, since its just combinatorial logic. Works perfect in
simulation but fails on conversion. Then I did a workaround: put
manually a sensitivity list with @always(list_of_signals) and then the
conversion step worked fine.

I wonder if it's a bug in conversion, or if there's a better way to
model a state machine. I attach a small example to show my dilemma.

Best regards

-- 
Oscar Díaz
Key Fingerprint = 904B 306C C3C2 7487 650B  BFAC EDA2 B702 90E9 9964
gpg --keyserver subkeys.pgp.net --recv-keys 90E99964

I recommend using OpenDocument Format
for daily use and exchange of documents.

http://www.spreadopendocument.org/

Re: [myhdl-list] Pythonic Test frameworks

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

On 11/8/11 9:01 PM, Christopher Felton wrote:
> On 11/8/11 7:04 PM, Bob Cunningham wrote:
>> On 11/07/2011 08:07 PM, Christopher Felton wrote:
>>> On 11/7/11 7:21 PM, Bob Cunningham wrote:
>>>> FWIW, py.test seems to be the way MyHDL itself is going...
>>>>
>>>> -BobC
>>> ...
>>>
>>> The following, http://bit.ly/sc3vrI, is a brief mention of py.test used
>>> instead of unittest (from a couple years ago) from the myhdl-list.
>>>
>>> But I do believe py.test is limited.  If you are ok writing with only
>>> simple asserts, I believe py.test is ok.  But unittest supports more
>>> advanced features, automatically verify raised exceptions (continue if
>>> raised fail if not).
>>>
>>> I guess an argument against py.test, is that it is another package that
>>> needs to be installed.  Where as, unittest is part of the standard
>>> Python library, hmmm.
>>>
>>> Regards,
>>> Chris
>>
>> Well, MyHDL is, itself, "another package that needs to be installed"!
>>
>> See the end of this page: http://www.myhdl.org/doku.php/cookbook:stopwatch
>
> Thanks for the reminder, this is a good commentary on py.test versus
> unittest.  This is a good read for anyone trying to determine which test
> framework to use.

I think this is the important quote from the py.test commentary at the 
end of the stopwatch example.

"""
However, I believe that the benefits are far more important than the 
disadvantages. Moreover, some disadvantages may disappear over time. 
Consequently, I plan to promote py.test as the unit testing framework of 
choice for MyHDL in the future.
"""

I don't think anything has changed since this was posted.

Regards,
Chris

Re: [myhdl-list] Pythonic Test frameworks

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

On 11/8/11 7:04 PM, Bob Cunningham wrote:
> On 11/07/2011 08:07 PM, Christopher Felton wrote:
>> On 11/7/11 7:21 PM, Bob Cunningham wrote:
>>> FWIW, py.test seems to be the way MyHDL itself is going...
>>>
>>> -BobC
>> ...
>>
>> The following, http://bit.ly/sc3vrI, is a brief mention of py.test used
>> instead of unittest (from a couple years ago) from the myhdl-list.
>>
>> But I do believe py.test is limited.  If you are ok writing with only
>> simple asserts, I believe py.test is ok.  But unittest supports more
>> advanced features, automatically verify raised exceptions (continue if
>> raised fail if not).
>>
>> I guess an argument against py.test, is that it is another package that
>> needs to be installed.  Where as, unittest is part of the standard
>> Python library, hmmm.
>>
>> Regards,
>> Chris
>
> Well, MyHDL is, itself, "another package that needs to be installed"!
>
> See the end of this page: http://www.myhdl.org/doku.php/cookbook:stopwatch

Thanks for the reminder, this is a good commentary on py.test versus 
unittest.  This is a good read for anyone trying to determine which test 
framework to use.

>
> And py.test does handle *expected* exceptions: Unexpected exceptions will crash the test with a suitable dump.  See http://pytest.org/latest/getting-started.html#asserting-that-a-certain-exception-is-raised
>

I came across similar information while refreshing on py.test.  It does 
not seem as limited as I first thought.  Also, the setup (and teardown) 
have been enhance.  The "setup_method" is not used anymore but rather 
the funcarg.

> FWIW, py.test is faster and easier, and doesn't much care about the structure of your MyHDL code, but it has limitations.  Unittest is more powerful, but is harder to use.
>
I believe you mean faster to develop, faster to come up to speed.  Not 
necessarily faster execution.

> As a true newbie to both digital design and MyHDL, I've been coding and testing in the smallest increments possible, with tiny blocks glued together.  For this specific development path, py.test seems ideal.  At this point, I have no idea if it will work as well with more complex designs.
>
I think it will scale nicely with complex designs.  But only time and 
experience will prove if it does.

> However, I am quite biased: In my embedded/real-time software systems I often used "programming by contract" (PBC), which is extensively assert-based (to validate the contracts), so py.test seems quite natural to me.  It is also a form of 'white-box' testing.
>
> The complementary approach, test-driven design (TDD), puts more burden on the test harness, which means the test tools must be more powerful and sophisticated.  This is generally a form of 'black-box' testing.
>
> In the software world, the two test methods work well together in practice:  If you use PBC at the low level, the higher-level tests can be simpler.
>
> Has anyone tried to see if py.test and unittest can play nice together (at different levels of abstraction) within a single MyHDL project?
No I have not, I guess in theory you could have both.  I am not sure why 
you would.  I think once you go through the trouble of using unittest 
might as well stay in that framework.  But I guess, if you started with 
py.test, defined a bunch of tests.  Then found something that was not 
supported nicely in py.test, unittest could be added separately.  I 
think they would, essentially, be separate but testing the same entity.

Regards,
Chris