myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] Setting of enum values

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

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.

Cheers,
Henry

Re: [myhdl-list] Setting of enum values

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

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.

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

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

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

On 12/28/2014 12:24 PM, Henry Gomersall wrote:
> Is there a way to set an enum to have a specific value?

The enumeration values of an abstract enum type are set
at construction time.

If you mean an integer value - that is not the purpose
of enums. Use a symbolic constant.


>
> 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.
>
> The use case is to interface with a library block that has the states
> already defined, and I don't really want to implement every enumeration
> for my usage.
>
> I suppose the simple workaround is to wrap the library with the state
> logic and let the synthesis tools worry about any optimisations.
>
> Cheers,
>
> Henry
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
>


-- 
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] Some name mangling on the constants needed for VHDL

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

On 09/01/15 17:10, Christopher Felton wrote:
> <snip>
>> >
>> >It's interesting that it shows up as a "constant" though. I don't see
>> >how that fits with interfaces.
>> >
> You might be correct, I probably jump to the
> conclusion that the Interface code that walks
> objects and their attributes might of caused
> the problem.  Looks like I have some homework.

The relevant magic seems to be
for VHDL: 
https://bitbucket.org/jandecaluwe/myhdl/src/f7a6b2ef05bbf418349d8b0021d81b4fc83b8ce0/myhdl/conversion/_toVHDL.py?at=0.9-dev#cl-1273
(interestingly it's a line number offset from my local code)

for Verilog: 
https://bitbucket.org/jandecaluwe/myhdl/src/f7a6b2ef05bbf418349d8b0021d81b4fc83b8ce0/myhdl/conversion/_toVerilog.py?at=0.9-dev#cl-991

which are just walked to during the ast traversal at write out. It seems 
objects which are recognized as integers are simply assumed to be 
constant, which seems sensible.

The issue only then is the name is not necessarily valid, so some 
mangling is necessary.

The signal name mangling is done here:
https://bitbucket.org/jandecaluwe/myhdl/src/f7a6b2ef05bbf418349d8b0021d81b4fc83b8ce0/myhdl/conversion/_analyze.py?at=0.9-dev#cl-118

which calls a function defined in that file. It would be simple to call 
that function in the toVHDL getNames function to perform necessary name 
mangling.

Cheers,

Henry

Is the

Cheers,

Henry

Re: [myhdl-list] Some name mangling on the constants needed for VHDL

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

<snip>
>
> It's interesting that it shows up as a "constant" though. I don't see
> how that fits with interfaces.
>

You might be correct, I probably jump to the
conclusion that the Interface code that walks
objects and their attributes might of caused
the problem.  Looks like I have some homework.

Regards,
Chris

Re: [myhdl-list] Some name mangling on the constants needed for VHDL

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

On 09/01/15 16:43, Christopher Felton wrote:
> On 1/9/2015 10:27 AM, Henry Gomersall wrote:
>> >I was pleased to find that now constants are allowed in 0.9.
>> >
>> >The problem is if the constant name is simply dumped passed in as the
>> >constant name in VHDL. So the following happens:
>> >
>> >class Bleh(object):
>> >       meh = 12
>> >
>> >eep = Bleh()
>> >
> <snip>
>> >
>> >constant eep.meh: integer := 12;
>> >
>> >I understand some name mangling is probably required here to make the
>> >name acceptable to the standard.
>> >
> This isn't officially supported and the above
> is a manifestation of the "Interface" support.
>
> Note, this doesn't mean it is not a good idea
> to support this but for now it is not.  A work
> around is to dereference constants and variables
> (i.e. non Signals) locally.
>
>       meh = eep.meh
>       @always_seq(clock.posedge ...)
>       def inclogic():
>       # ...
>               foo.next = meh

Yeah, I thought of that solution. The problem is that I actually want to 
use an IntEnum class in place of loads of constants being defined.

It's not a major issue, but something that it would be nice if it worked.

> I posted another example that had a similar
> side effect.
> http://article.gmane.org/gmane.comp.python.myhdl/3716/match=interesting
I saw your post, but wasn't at the time able to grasp the significance. 
Now I am :)

It's interesting that it shows up as a "constant" though. I don't see 
how that fits with interfaces.

Cheers,

Henry

Re: [myhdl-list] Some name mangling on the constants needed for VHDL

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

On 1/9/2015 10:27 AM, Henry Gomersall wrote:
> I was pleased to find that now constants are allowed in 0.9.
>
> The problem is if the constant name is simply dumped passed in as the
> constant name in VHDL. So the following happens:
>
> class Bleh(object):
>       meh = 12
>
> eep = Bleh()
>
<snip>
>
> constant eep.meh: integer := 12;
>
> I understand some name mangling is probably required here to make the
> name acceptable to the standard.
>

This isn't officially supported and the above
is a manifestation of the "Interface" support.

Note, this doesn't mean it is not a good idea
to support this but for now it is not.  A work
around is to dereference constants and variables
(i.e. non Signals) locally.

     meh = eep.meh
     @always_seq(clock.posedge ...)
     def inclogic():
     # ...
             foo.next = meh

I posted another example that had a similar
side effect.
http://article.gmane.org/gmane.comp.python.myhdl/3716/match=interesting

In my opinion, the correct action will be to
add some code in 0.9 to detect this and not
convert the code and then create a new MEP
for constants and variables.  I tried to contact
"jck" on IRC and describe the problem but I
haven't heard back.  "jck" implemented the
Interfaces MEP.

Regards,
Chris

Re: [myhdl-list] fixbv resize MEP

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

On 09/01/15 12:02, Christopher Felton wrote:
> On 1/9/15, 4:42 AM, Henry Gomersall wrote:
>> >I noticed in MEP 111 the comment that a resize function MEP is in the
>> >works. I'm keen on such a feature, and keen to discuss it. Are there
>> >some initial ideas?
>> >
> At the end of this article I have an example
> how I envisioned it would work
>
> http://www.dsprelated.com/showarticle/580.php
>
> I envision a "funcmod" will need to be added.

My apologies, I don't quite understand - a funcmod?

I understand how to do this in general, I'm just not au fait with the 
specifics of doing it well in HDL.

Cheers,

Henry

[myhdl-list] Some name mangling on the constants needed for VHDL

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

I was pleased to find that now constants are allowed in 0.9.

The problem is if the constant name is simply dumped passed in as the 
constant name in VHDL. So the following happens:

class Bleh(object):
     meh = 12

eep = Bleh()

def Inc(count, enable, foo, clock, reset):

     """ Incrementer with enable.

     count -- output
     enable -- control input, increment when 1
     clock -- clock input
     reset -- asynchronous reset input
     """

     @always_seq(clock.posedge, reset=reset)
     def incLogic():
         if enable:
             if foo == MyEnum.a:
                 foo.next = eep.meh

     return incLogic

yields

constant eep.meh: integer := 12;

I understand some name mangling is probably required here to make the 
name acceptable to the standard.

I expect it is a pretty simple tweak to this code:
https://bitbucket.org/jandecaluwe/myhdl/src/823dbd6643997bc92a2a92a34486eb0e42de1ace/myhdl/conversion/_toVHDL.py?at=default#cl-330

The question is, how should the name mangling be performed? This strikes 
me as a similar problem to defining the names in interfaces.

It's not clear to me that the potential problem of name collision is 
actually solved in the interfaces, though I'm happy with something 
similar. Is there a name mangling class for future improvements in this?

Cheers,

Henry

Re: [myhdl-list] Conversion tests failing

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

On 1/9/2015 9:23 AM, Henry Gomersall wrote:
> It seems that the conversion of interfaces stuff is failing on
> interfaces with more than one level.
>
> Specifically, test_two_analyze() and test_two_verify() in
> test/conversion/general/test_interfaces3.py are failing.
>
> I don't know if this is meant to be supported, but it's certainly
> failing at the analyze stage:
> myhdl.ConversionError: File
> /home/whg21/Projects/bitbucket/myhdl/myhdl/test/conversion/general/test_interfaces3.py,
> line 70: Object type is not supported in this context: z
>

Yes, definitely intended to be supported in 0.9-dev
and I thought these were all passing at one point.

Regards,
Chris

[myhdl-list] Conversion tests failing

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

It seems that the conversion of interfaces stuff is failing on 
interfaces with more than one level.

Specifically, test_two_analyze() and test_two_verify() in 
test/conversion/general/test_interfaces3.py are failing.

I don't know if this is meant to be supported, but it's certainly 
failing at the analyze stage:
myhdl.ConversionError: File 
/home/whg21/Projects/bitbucket/myhdl/myhdl/test/conversion/general/test_interfaces3.py, 
line 70: Object type is not supported in this context: z

The problem seems to be that it's expecting a list of suitable arguments 
(Signals etc) and it encounters a class that itself contains the 
relevant type.

Cheers,

Henry

Re: [myhdl-list] fixbv resize MEP

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

On 1/9/15, 4:42 AM, Henry Gomersall wrote:
> I noticed in MEP 111 the comment that a resize function MEP is in the
> works. I'm keen on such a feature, and keen to discuss it. Are there
> some initial ideas?
>

At the end of this article I have an example
how I envisioned it would work

http://www.dsprelated.com/showarticle/580.php

I envision a "funcmod" will need to be added.

Regards,
Chris

Re: [myhdl-list] Another typo in docs

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

On 09/01/15 04:30, Christopher Felton wrote:
> On 1/8/15, 10:26 AM, Henry Gomersall wrote:
>> >On 08/01/15 15:54, Christopher Felton wrote:
>>> >>On 1/8/2015 9:07 AM, Henry Gomersall wrote:
>>>>> >>>>On 08/01/15 15:01, Christopher Felton wrote:
>>>>>>> >>>>>>On 1/8/2015 8:44 AM, Henry Gomersall wrote:
>>>>>>>>>>> >>>>>>>>>>On 08/01/15 14:00, Christopher Felton wrote:
> <snip>
>>>>>>> >>>>>>Is this what you currently have in your repo?
>>>>> >>>>Yup
>>>>> >>>>
>>>>> >>>>https://bitbucket.org/heng/myhdl/raw/641c450dac65cfa16edd42c45a43c101f3aa2db1/doc/source/manual/rtl.rst
>>>>> >>>>
>>> >>A quick look this looks good for a PR.  I will fork
>>> >>tonight and test on my system(s) as well.  I am a
>>> >>little confused why one of the expected output tables
>>> >>had to be changed (worried it is system dependent
>>> >>based on the random values even though it is seeded).
>> >
>> >Do you mean changed from the original source you had up? Yeah, that
>> >concerned me slightly too - sorry, I should have noted that.
>> >
>> >This would suggest it should be stable...
>> >https://docs.python.org/3/library/random.html#notes-on-reproducibility
>> >
>> >though this is worth noting too...
>> >http://stackoverflow.com/questions/11929701/why-is-seeding-the-random-generator-not-stable-between-versions-of-python
>> >
>> >Note that the always_comb code is replicated as it stands.
>> >
> I forked and tested and no errors.  I think the
> duplicate code should be removed and change to
> the other test.

I think the problem is the introspection method done in always_comb.

func.func_globals.items() just returns the wrong thing under doctest 
when there is a break in the code and no amount of playing around seems 
to solve this.

I've implemented a workaround in which mux_1 and the signals are created 
directly below the Mux code, these are then used in the test bench. I 
think it's pretty good and doesn't substantially detract from the 
information presentation.

Cheers,

Henry

[myhdl-list] fixbv resize MEP

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

I noticed in MEP 111 the comment that a resize function MEP is in the 
works. I'm keen on such a feature, and keen to discuss it. Are there 
some initial ideas?

Cheers,

Henry

Re: [myhdl-list] Another typo in docs

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

On 1/8/15, 10:26 AM, Henry Gomersall wrote:
> On 08/01/15 15:54, Christopher Felton wrote:
>> On 1/8/2015 9:07 AM, Henry Gomersall wrote:
>>>> On 08/01/15 15:01, Christopher Felton wrote:
>>>>>> On 1/8/2015 8:44 AM, Henry Gomersall wrote:
>>>>>>>>>> On 08/01/15 14:00, Christopher Felton wrote:
<snip>
>>>>>> Is this what you currently have in your repo?
>>>> Yup
>>>>
>>>> https://bitbucket.org/heng/myhdl/raw/641c450dac65cfa16edd42c45a43c101f3aa2db1/doc/source/manual/rtl.rst
>>>>
>> A quick look this looks good for a PR.  I will fork
>> tonight and test on my system(s) as well.  I am a
>> little confused why one of the expected output tables
>> had to be changed (worried it is system dependent
>> based on the random values even though it is seeded).
>
> Do you mean changed from the original source you had up? Yeah, that
> concerned me slightly too - sorry, I should have noted that.
>
> This would suggest it should be stable...
> https://docs.python.org/3/library/random.html#notes-on-reproducibility
>
> though this is worth noting too...
> http://stackoverflow.com/questions/11929701/why-is-seeding-the-random-generator-not-stable-between-versions-of-python
>
> Note that the always_comb code is replicated as it stands.
>

I forked and tested and no errors.  I think the
duplicate code should be removed and change to
the other test.

Regards,
Chris

[myhdl-list] Initial values of signals

[Edward V. <dev...@sb...>]

Hello all,

How do you set signals values to the initial value in myhdl?

After adding the last 3 values to the package pck_xess_jpeg_top  that is generated
with the a python file.
I started getting the following 2 errors (see below)
Line 85: Formal <y_u> has no actual or default value.
Line 86: Formal <eog> has no actual or default value.
This can be corrected by changing the lines 91 and 92 as shown below
        y_u: in unsigned(15 downto 0);
        eog: in std_logic:= '0'
to
        y_u: in unsigned(15 downto 0):= (others => '0');
        eog: in std_logic
I was already needing to change signal instance_1_reset_ctn: unsigned(3 downto 0);
signal instance_1_reset_ctn: unsigned(3 downto 0):= "0000"; to get my simulation to work
correctly.
All help is welcomed.
Thanks
entity xess_jpeg_top is
    port (
        clk_fast: in std_logic;
        addr_r: out unsigned(22 downto 0);
        addr_x: inout unsigned(22 downto 0);
        state_r: inout t_enum_t_State_1;
        state_x: inout t_enum_t_State_1;
        dataToRam_r: inout unsigned(15 downto 0);
        dataToRam_x: inout unsigned(15 downto 0);
        dataFromRam_r: out unsigned(15 downto 0);
        dataFromRam_x: inout unsigned(15 downto 0);
        sig_in: inout unsigned(51 downto 0);
        noupdate_s: out std_logic;
        res_s: inout signed (15 downto 0);
        res_u: out unsigned(15 downto 0);
        jp_lf: in unsigned(15 downto 0);
        jp_sa: inout unsigned(15 downto 0);
        jp_rh: in unsigned(15 downto 0);
        jp_flgs: inout unsigned(3 downto 0);
        reset_col: out std_logic;
        rdy: in std_logic;
        addr_not_reached: in std_logic;
        offset_r: inout unsigned(22 downto 0);
        offset_x: inout unsigned(22 downto 0);
        dataFromRam_s: in unsigned(15 downto 0);
        done_s: in std_logic;
        wr_s: out std_logic;
        rd_s: out std_logic;
        sum_r: inout unsigned(15 downto 0);
        sum_x: inout unsigned(15 downto 0);
        empty_r: out std_logic;
        full_r: out std_logic;
        enr_r: inout std_logic;
        enw_r: inout std_logic;
        dataout_r: inout unsigned(15 downto 0);
        datain_r: inout unsigned(15 downto 0);
        empty_x: inout std_logic;
        full_x: inout std_logic;
        enr_x: inout std_logic;
        enw_x: inout std_logic;
        dataout_x: inout unsigned(15 downto 0);
        datain_x: inout unsigned(15 downto 0);
        col_r: inout unsigned(7 downto 0);
        col_x: inout unsigned(7 downto 0);
        row_r: inout unsigned(7 downto 0);
        row_x: inout unsigned(7 downto 0);
        rst: out std_logic;
        y_u: in unsigned(15 downto 0);
        eog: in std_logic
    );

 





 
Edward Vidal Jr.
e-mail dev...@sb...
915-595-1613

Re: [myhdl-list] Another typo in docs

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

On 08/01/15 15:54, Christopher Felton wrote:
> On 1/8/2015 9:07 AM, Henry Gomersall wrote:
>> >On 08/01/15 15:01, Christopher Felton wrote:
>>> >>On 1/8/2015 8:44 AM, Henry Gomersall wrote:
>>>>> >>>>On 08/01/15 14:00, Christopher Felton wrote:
>>>>>>> >>>>>>This means that the doctest in the sphinx documentation
>>>>>>> >>>>>>might not be possible depending if the issue can be
>>>>>>> >>>>>>resolved.  Because there are multiple systems etc. not
>>>>>>> >>>>>>sure where/how to start debugging the issue.
>>>>>>> >>>>>>
>>>>>>> >>>>>>If more regression tests are desired it would be easier
>>>>>>> >>>>>>to create more tests than try and enable tests embedded
>>>>>>> >>>>>>in the documentation.
>>>>> >>>>
>>>>> >>>>I agree with this. However, as seems to be the case, it is possible to
>>>>> >>>>have a version of the code which has a test bench function rather than
>>>>> >>>>is a set of global operations which seems to work as desired (see the
>>>>> >>>>FSM code further down). If this is the case we can just change the
>>>>> >>>>structure of the code to fit that model.
>>>>> >>>>
>>> >>Is this what you currently have in your repo?
>> >Yup
>> >
>> >https://bitbucket.org/heng/myhdl/raw/641c450dac65cfa16edd42c45a43c101f3aa2db1/doc/source/manual/rtl.rst
>> >
> A quick look this looks good for a PR.  I will fork
> tonight and test on my system(s) as well.  I am a
> little confused why one of the expected output tables
> had to be changed (worried it is system dependent
> based on the random values even though it is seeded).

Do you mean changed from the original source you had up? Yeah, that 
concerned me slightly too - sorry, I should have noted that.

This would suggest it should be stable...
https://docs.python.org/3/library/random.html#notes-on-reproducibility

though this is worth noting too...
http://stackoverflow.com/questions/11929701/why-is-seeding-the-random-generator-not-stable-between-versions-of-python

Note that the always_comb code is replicated as it stands.

Henry

Re: [myhdl-list] Another typo in docs

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

On 1/8/2015 9:07 AM, Henry Gomersall wrote:
> On 08/01/15 15:01, Christopher Felton wrote:
>> On 1/8/2015 8:44 AM, Henry Gomersall wrote:
>>>> On 08/01/15 14:00, Christopher Felton wrote:
>>>>>> This means that the doctest in the sphinx documentation
>>>>>> might not be possible depending if the issue can be
>>>>>> resolved.  Because there are multiple systems etc. not
>>>>>> sure where/how to start debugging the issue.
>>>>>>
>>>>>> If more regression tests are desired it would be easier
>>>>>> to create more tests than try and enable tests embedded
>>>>>> in the documentation.
>>>>
>>>> I agree with this. However, as seems to be the case, it is possible to
>>>> have a version of the code which has a test bench function rather than
>>>> is a set of global operations which seems to work as desired (see the
>>>> FSM code further down). If this is the case we can just change the
>>>> structure of the code to fit that model.
>>>>
>> Is this what you currently have in your repo?
> Yup
>
> https://bitbucket.org/heng/myhdl/raw/641c450dac65cfa16edd42c45a43c101f3aa2db1/doc/source/manual/rtl.rst
>

A quick look this looks good for a PR.  I will fork
tonight and test on my system(s) as well.  I am a
little confused why one of the expected output tables
had to be changed (worried it is system dependent
based on the random values even though it is seeded).

Regards,
Chris

Re: [myhdl-list] Another typo in docs

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

On 08/01/15 15:01, Christopher Felton wrote:
> On 1/8/2015 8:44 AM, Henry Gomersall wrote:
>> >On 08/01/15 14:00, Christopher Felton wrote:
>>> >>This means that the doctest in the sphinx documentation
>>> >>might not be possible depending if the issue can be
>>> >>resolved.  Because there are multiple systems etc. not
>>> >>sure where/how to start debugging the issue.
>>> >>
>>> >>If more regression tests are desired it would be easier
>>> >>to create more tests than try and enable tests embedded
>>> >>in the documentation.
>> >
>> >I agree with this. However, as seems to be the case, it is possible to
>> >have a version of the code which has a test bench function rather than
>> >is a set of global operations which seems to work as desired (see the
>> >FSM code further down). If this is the case we can just change the
>> >structure of the code to fit that model.
>> >
> Is this what you currently have in your repo?
Yup

https://bitbucket.org/heng/myhdl/raw/641c450dac65cfa16edd42c45a43c101f3aa2db1/doc/source/manual/rtl.rst

Cheers,

Henry

Re: [myhdl-list] Another typo in docs

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

On 1/8/2015 8:44 AM, Henry Gomersall wrote:
> On 08/01/15 14:00, Christopher Felton wrote:
>> This means that the doctest in the sphinx documentation
>> might not be possible depending if the issue can be
>> resolved.  Because there are multiple systems etc. not
>> sure where/how to start debugging the issue.
>>
>> If more regression tests are desired it would be easier
>> to create more tests than try and enable tests embedded
>> in the documentation.
>
> I agree with this. However, as seems to be the case, it is possible to
> have a version of the code which has a test bench function rather than
> is a set of global operations which seems to work as desired (see the
> FSM code further down). If this is the case we can just change the
> structure of the code to fit that model.
>

Is this what you currently have in your repo?

Regards,
Chris

Re: [myhdl-list] Another typo in docs

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

On 08/01/15 14:00, Christopher Felton wrote:
> This means that the doctest in the sphinx documentation
> might not be possible depending if the issue can be
> resolved.  Because there are multiple systems etc. not
> sure where/how to start debugging the issue.
>
> If more regression tests are desired it would be easier
> to create more tests than try and enable tests embedded
> in the documentation.

I agree with this. However, as seems to be the case, it is possible to 
have a version of the code which has a test bench function rather than 
is a set of global operations which seems to work as desired (see the 
FSM code further down). If this is the case we can just change the 
structure of the code to fit that model.

Cheers,

Henry

Re: [myhdl-list] Setting of enum values

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

On 1/7/2015 6:23 AM, Henry Gomersall wrote:
> On 06/01/15 20:50, Henry Gomersall wrote:
>> On 29/12/14 18:26, Christopher Felton wrote:
>>>>>>>> AFAICT it doesn't acquire any state from the enum function so it could
>>>>>>>> just as easily be at the module level, allowing more flexible usage when
>>>>>>>> needing to fit the enum to an existing definition.
>>>> I am sure there are many ways to implement it, this may
>>>> not have been a use case envision or desired.  We can
>>>> propose a modification to have the "Enum" class public
>>>> and then various custom functions can be created to
>>>> implement the codedicts, etc.  I think this would provide
>>>> flexibility but also maintain a minimal / logical enum.
>> I'm keen on this. I don't see any reason why Enum should be so hard to
>> access. I agree enum should be kept as is.
> Further to this, why not just extend the existing python Enum:
>
> https://pypi.python.org/pypi/enum34
>
> Cheers,
>
> Henry
>

I think this is a reasonable request, I think the next
steps would be to create a feature request in the main
bitbucket repository [1].

For the near term, create a fork and move the Enum
object(s) outside of the function, add Enum to
__init__ (so it can be imported), and see how it
works ...

Regards,
Chris

[1] https://bitbucket.org/jandecaluwe/myhdl/issues?status=new&status=open

Re: [myhdl-list] Another typo in docs

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

On 1/6/2015 2:31 PM, Ben wrote:
<snip>
>>>
>>> Further to this, I've got a working doctest suite for rtl.rst. This is at:
>>>
>>> https://bitbucket.org/heng/myhdl/branch/0.9-dev
>>>
>>> I had to replicate some code in the documentation for doctest to work
>>> (which just makes it easier to copy and paste, though potentially open
>>> to replication errors down the line). The issue seemed to be related to
>>> globals in the doctest string, though I've not tried to hard to get to
>>> the bottom of it.
>>>
>>
>> I did not find a work around for this.  Your approach is nice
>> to enable doctest but I am worried the maintenance will be a
>> pain (double code snips).
>
> Maybe there is a way using the ``doctest_global_setup`` config value
> [0]. The conf.py file is python so it should be possible to read (part
> of) another python file to populate that variable. That code would be
> automatically 'duplicated' on top of each file ...
>
> Just my 2c.
>
> Ben.

I think there are a couple different approaches to
workaround the issue.  But I don't know if it helps
achieve the overall goal of doctest, which is (in
my mind):

    1. verify the code snips are correct in the
       documentation with automated and regression
       testings

I think for this to be useful it really needs to test
the code that is eventually displayed.

This means that the doctest in the sphinx documentation
might not be possible depending if the issue can be
resolved.  Because there are multiple systems etc. not
sure where/how to start debugging the issue.

If more regression tests are desired it would be easier
to create more tests than try and enable tests embedded
in the documentation.

Regards,
Chris

Re: [myhdl-list] std_logic_vector

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

Edward Vidal <develone <at> sbcglobal.net> writes:
> Is there a way to have mix of unsigned and std_logic_vector?I have a 
top_level that has only 1 toVHDL statement. 

No, all ports of the module will be std_logic_vector in stead of unsigned.

> For now only 1 signal needs to be std_logic_vector to match someone else 
code.  When I break it up to 7 toVHDL 1 statement fails since a
>  variable is _enumPortTypeSet AssertionError.I am correct in thinking 
that toVHDL.numeric_ports = False is only for the next toVHDL statement.

I don't think you can break up the toVHDL() call. I guess the best idea is 
to accept either the all-unsigned (or all-std_logic_vector) ports and 
write a small VHDL wrapper around either the MyHDL module or around the 
'someone else's' module.

>Also did not understand the Qsys comment I am using a Xilinx product 
spartan 6.  Web search appears to be for Altera product.

Indeed Qsys is for Altera products. It is GUI to connect Building Blocks. 
Saving a lot of typing.

Regards,

Josy