myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] 0.8 Type mismatch in enum item comparison

[Jan C. <jan...@mu...>]

On 31/05/12 14:26, Christopher Felton wrote:
> On 5/31/2012 8:10 AM, Jan Coombs wrote:
>> $ ./testSdp3o4.py
>> Traceback (most recent call last):
>>      File "./testSdp3o4.py", line 41, in<module>
>>        simulate(240)
>>      File "./testSdp3o4.py", line 37, in simulate
>>        tb = traceSignals(testSdp3o4)
>>      File
>> "/home/jan/work/projects/MyHDL/myhdl/myhdl/_traceSignals.py", line
>> 89, in __call__
>>        _writeVcdSigs(vcdfile, h.hierarchy)
>>      File
>> "/home/jan/work/projects/MyHDL/myhdl/myhdl/_traceSignals.py", line
>> 146, in _writeVcdSigs
>>        if s._val == None:
>>      File "/home/jan/work/projects/MyHDL/myhdl/myhdl/_enum.py", line
>> 117, in __eq__
>>        raise TypeError("Type mismatch in enum item comparison")
>> TypeError: Type mismatch in enum item comparison
>>
>> No problem with 0.7. Should I try to track it down?
>>
>> Jan Coombs
>
> No might be important for you design!  Jan D. added
> some nice features to help debug the use of enums
> (could be your case).  Hopefully, 0.8 is flagging
> (throwing an exception) for incorrect use of an e
> num, where 0.7 will not.
>
> You might want to try and run the test without
> traceSignals and you may get more information.

It has taken me a long time to change the test code, but am now 
running without and with traceSignals.  Surprisingly I did not get 
more information; without traceSignals there is no error.

So the error only appears with latest 0.8 when producing trace.

Jan Coombs.
-- 

###############
print;print"just sim"
sim = Simulation(testSdp3o4())
sim.run(240)
###############

def simulate(timesteps):
     tb = traceSignals(testSdp3o4)
     sim = Simulation(tb)
     sim.run(timesteps)

print;print"sim & trace"
simulate(240)

Re: [myhdl-list] 0.8 Type mismatch in enum item comparison

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

On 05/31/2012 03:10 PM, Jan Coombs wrote:
> $ ./testSdp3o4.py
> Traceback (most recent call last):
>     File "./testSdp3o4.py", line 41, in<module>
>       simulate(240)
>     File "./testSdp3o4.py", line 37, in simulate
>       tb = traceSignals(testSdp3o4)
>     File
> "/home/jan/work/projects/MyHDL/myhdl/myhdl/_traceSignals.py", line
> 89, in __call__
>       _writeVcdSigs(vcdfile, h.hierarchy)
>     File
> "/home/jan/work/projects/MyHDL/myhdl/myhdl/_traceSignals.py", line
> 146, in _writeVcdSigs
>       if s._val == None:
>     File "/home/jan/work/projects/MyHDL/myhdl/myhdl/_enum.py", line
> 117, in __eq__
>       raise TypeError("Type mismatch in enum item comparison")
> TypeError: Type mismatch in enum item comparison
>
> No problem with 0.7. Should I try to track it down?

Mm, this is due to the more restrictive comparisons on EnumItemType.

Now, that 's._val == None' test is wrong also, the idiomatic test
is 'if s._val is None'. Could you check whether things work
when you make that change? (line 146 in _traceSignals.py).


-- 
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] 0.8 Type mismatch in enum item comparison

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

On 5/31/2012 8:10 AM, Jan Coombs wrote:
> $ ./testSdp3o4.py
> Traceback (most recent call last):
>     File "./testSdp3o4.py", line 41, in<module>
>       simulate(240)
>     File "./testSdp3o4.py", line 37, in simulate
>       tb = traceSignals(testSdp3o4)
>     File
> "/home/jan/work/projects/MyHDL/myhdl/myhdl/_traceSignals.py", line
> 89, in __call__
>       _writeVcdSigs(vcdfile, h.hierarchy)
>     File
> "/home/jan/work/projects/MyHDL/myhdl/myhdl/_traceSignals.py", line
> 146, in _writeVcdSigs
>       if s._val == None:
>     File "/home/jan/work/projects/MyHDL/myhdl/myhdl/_enum.py", line
> 117, in __eq__
>       raise TypeError("Type mismatch in enum item comparison")
> TypeError: Type mismatch in enum item comparison
>
> No problem with 0.7. Should I try to track it down?
>
> Jan Coombs

No might be important for you design!  Jan D. added
some nice features to help debug the use of enums
(could be your case).  Hopefully, 0.8 is flagging
(throwing an exception) for incorrect use of an e
num, where 0.7 will not.

You might want to try and run the test without
traceSignals and you may get more information.

Regards,
Chris

[myhdl-list] 0.8 Type mismatch in enum item comparison

[Jan C. <jan...@mu...>]

$ ./testSdp3o4.py
Traceback (most recent call last):
   File "./testSdp3o4.py", line 41, in <module>
     simulate(240)
   File "./testSdp3o4.py", line 37, in simulate
     tb = traceSignals(testSdp3o4)
   File 
"/home/jan/work/projects/MyHDL/myhdl/myhdl/_traceSignals.py", line 
89, in __call__
     _writeVcdSigs(vcdfile, h.hierarchy)
   File 
"/home/jan/work/projects/MyHDL/myhdl/myhdl/_traceSignals.py", line 
146, in _writeVcdSigs
     if s._val == None:
   File "/home/jan/work/projects/MyHDL/myhdl/myhdl/_enum.py", line 
117, in __eq__
     raise TypeError("Type mismatch in enum item comparison")
TypeError: Type mismatch in enum item comparison

No problem with 0.7. Should I try to track it down?

Jan Coombs
-- 

Re: [myhdl-list] MEP-108 Bundle

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

On 5/30/12 9:45 AM, Jan Decaluwe wrote:
> On 05/30/2012 04:25 AM, Christopher Felton wrote:
>> Attached is the MEP-108 patch. This patch is to add support for the conversion of top-level methods.
>
> When I do
>
>       hg in mep_108.hg
>
> I get:
>
>       comparing with /home/jand/mep_108.hg
>       abort: 00changelog.i@d61bf91023b7: unknown parent!
>
> Probably this means that the bundle was created against some
> other repo of yours with changesets not in the public repo.
> In that case, I think the solution is to list the public
> repo explicitly when creating the bundle:
>
>      hg bundle mep_108.hg http://hg.myhdl.org/myhdl
>
> The goals is to bundle all changesets not in the public repo.
>
> Reviewing bundle contents is a little inconvenient but can
> be done within a fresh clone of the public repo:
>
> http://myhdl.org/doku.php/dev:patches#reviewing_bundle_content
>
>
>

It should have the correct parent now.  Clone a fresh from the public 
and reviewed in hg in.  Should work this time.

Thanks,
Chris

Re: [myhdl-list] TypeError: Unexpected type with toVerilog

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

On 05/30/2012 06:20 AM, Christopher Felton wrote:

>
>>> py.test test_enums.py
> ============ test session starts ========== -- Python 2.7.3 --
> pytest-2.2.3 collected 6 items
>
> test_enums.py .F.F.. ... (lots-o-info)
>
> It runs 6 tests on 4 version of a similar design. The first two
> (TrafficOne and TrafficTwo), best of my knowledge, should simulate
> and convert. The second raises an error during conversion.
>
> The second failure is the issue briefly discussed where in a
> synchronous description conversion is successful where it should
> raise a ConversionError (because the converted code simulation will
> not match the MyHDL simulation).\

An interesting case. It is obvious here that the MyHDL is "invalid"
(simulation will certainly fail to prove that the design works).
The resulting VHDL would not even pass compilation, but the Verilog
will, because the abstract enum type is mapped to a low-level type,
resulting in a loss of type information.

In fact I should have spoken about a "valid" MyHDL simulation:
if the MyHDL can be "proven" to be invalid, then the resulting
conversion code is invalid also, even if conversion "works".

What I did in the 0.8-dev branch is to define the comparison
operators on enum items in more detail. Now the MyHDL design
should throw an exception on any meaningful simulation. The
conversion may still "work" but the MyHDL is clearly invalid.
(Although we need the (simulation) run-time to prove this,
as opposed to a static compilation phase.)

The changeset is in the public repo's.

-- 
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] TypeError: Unexpected type with toVerilog

[Jan C. <jan...@mu...>]

On 30/05/12 17:16, Jan Decaluwe wrote:
    . . .
> This is an error I had not seen so far from a failing test.
>
> Cause: a too restrictive test on permitted free var types
> in always_comb blocks. I have solved this in development.

Excellent, thanks, project sims & converts now.

Next I need to finish making sure that my memory model matches the 
Actel Igloo nano on chip block RAM, and find the simplest way to 
convert using a target macro.

Kind regards, Jan Coombs.
-- 

Re: [myhdl-list] TypeError: Unexpected type with toVerilog

[Jan C. <jan...@mu...>]

On 30/05/12 16:04, Jan Decaluwe wrote:
> On 05/30/2012 01:20 AM, Jan Coombs wrote:
>> On 29/05/12 20:53, Jan Decaluwe wrote:
>> . . .
>>> This is the hopefully clearer error message I just created
>>> in both branches.
>> Thanks, I like MyHDL like a long-lost friend, and hope to make much more progress together.
>>
>> Attached is simplified the test code, as there still seems to be a problem.
>
> Same problem: a undriven enum signal, not supported currently.
>
Wat zeg ye?  Looks like double-dutch to me:)

Groenten uit engeland, Jan.

Re: [myhdl-list] TypeError: Unexpected type with toVerilog

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

On 05/30/2012 11:44 AM, Jan Coombs wrote:
> On 30/05/12 05:28, Christopher Felton wrote:
> ...
>> I modified your code so that it does not have the "undriven enum
>> Signals". Once you remove the undriven enum Signals this example
>> converts without throwing and error.
>
> I enthusiastically reverted the project code to use enums, but the error pattern there is still the same:
>
> In the async process which assigns an enum to the execNextState signal I get:
> Object type is not supported in this context: ExST

This is an error I had not seen so far from a failing test.

Cause: a too restrictive test on permitted free var types
in always_comb blocks. I have solved this in development.

Workaround: put enum definitions in the outer scope (outside the def)

Or use the development version, either branch.

-- 
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] TypeError: Unexpected type with toVerilog

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

On 05/30/2012 01:20 AM, Jan Coombs wrote:
> On 29/05/12 20:53, Jan Decaluwe wrote:
> . . .
>> This is the hopefully clearer error message I just created
>> in both branches.
> Thanks, I like MyHDL like a long-lost friend, and hope to make much more progress together.
>
> Attached is simplified the test code, as there still seems to be a problem.

Same problem: a undriven enum signal, not supported currently.

-- 
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] MEP-108 Bundle

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

On 05/30/2012 04:25 AM, Christopher Felton wrote:
> Attached is the MEP-108 patch. This patch is to add support for the conversion of top-level methods.

When I do

     hg in mep_108.hg

I get:

     comparing with /home/jand/mep_108.hg
     abort: 00changelog.i@d61bf91023b7: unknown parent!

Probably this means that the bundle was created against some
other repo of yours with changesets not in the public repo.
In that case, I think the solution is to list the public
repo explicitly when creating the bundle:

    hg bundle mep_108.hg http://hg.myhdl.org/myhdl

The goals is to bundle all changesets not in the public repo.

Reviewing bundle contents is a little inconvenient but can
be done within a fresh clone of the public repo:

http://myhdl.org/doku.php/dev:patches#reviewing_bundle_content



-- 
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] TypeError: Unexpected type with toVerilog

[Jan C. <jan...@mu...>]

On 30/05/12 05:20, Christopher Felton wrote:
    . . .
> The second failure is the issue briefly discussed where in a
> synchronous description conversion is successful where it should
> raise a ConversionError (because the converted code simulation will
> not match the MyHDL simulation).
>
> Unfortunately, this example has quite a bit of code. I didn't have
> the creative bug to generate a short-n-sweet version that covered
> all the items discussed in this thread.

I looked through your tests, and think that the short code I've 
just posted demonstrates a remaining failure mode.

Jan Coombs.

Re: [myhdl-list] TypeError: Unexpected type with toVerilog

[Jan C. <jan...@mu...>]

On 30/05/12 05:28, Christopher Felton wrote:
    ...
> I modified your code so that it does not have the "undriven enum
> Signals". Once you remove the undriven enum Signals this example
> converts without throwing and error.

I enthusiastically reverted the project code to use enums, but the 
error pattern there is still the same:

In the async process which assigns an enum to the execNextState 
signal I get:
   Object type is not supported in this context: ExST

In all other processes in which execNextState or execState are 
referenced I get:
   Unexpected type for constant signal: execState
which probably relates exclusively to referencing enum constants.


What bothers me is that you fixed my code by adding a process which 
appears to have no relation to the enum errors reported.

I further refined this conclusion by making your code asynchronous, 
and only enabling the statements which are needed to avoid 
unassigned signals.  Your fix still converts, although, when 
testing enums, the only difference is that the code does not return 
an unassigned intbv.

Your fix further disturbs me, because the only effective debug 
process for conversion errors I have found is to disable 
simulation, and selectively remove offending code refs from the 
return statements.  This is the opposite of your fix, which adds 
apparently unrelated code.

If your corrected code represents a valid response, then all of my 
debug efforts may be invalid.

In the attached code I have eliminated the problems you corrected, 
and the sample now demonstrates failure to convert in code using 
enums, while matching code using simple constants is ok.

The sandboxed code is now closer to my project, but let me know if 
you want to see the the project - about 13.5kB at present.

Back to you(s), and back to real work now.

Jan Coombs.
-- 

[myhdl-list] Summary of "Intial Values Support" threads

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

We listed a summary a couple time but the initial value support (ivs) 
was embedded in a separate thread.  So, I thought it would be worth 
while to summarize in a new thread.


   1.  Initial value support can be re-enabled.  The Verilog
       support of initial values as verified with the latest
       of Quartus.
       Need to test with (list syn and sim tools)?
         [x] Quartus latest
         [ ] ISE (xst) latest
         [ ] cver
         [ ] icarus

   2.  None will *not* be added to intbv.  An argument will
       be added to the toVerilog and toVHDL to disable
       "plain" Signal init and "memory" (array) init.
       Something like the following.

         toVerilog(... disable_init=False, disable_mem_init=False)
         toVHDL( "" "" )

   3.  toVerilog will only create initial values for Signals
       converted to register types.

   4.  Initial values for memories (list of signals) will be
       generated.  If feasible the synthesizable versions [1]
       of the memory init values will be generated.


Let me know if I missed something or summarized incorrectly.

Regards,
Chris

[1] http://www.altera.com/literature/hb/qts/qts_qii51007.pdf

Re: [myhdl-list] TypeError: Unexpected type with toVerilog

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

On 5/29/12 6:20 PM, Jan Coombs wrote:
> On 29/05/12 20:53, Jan Decaluwe wrote:
> . . .
>> This is the hopefully clearer error message I just created
>> in both branches.
> Thanks, I like MyHDL like a long-lost friend, and hope to make much more
> progress together.
>
> Attached is simplified the test code, as there still seems to be a problem.
>
> Jan Coombs.
> --
>

Jan C.

I modified your code so that it does not have the "undriven enum 
Signals".  Once you remove the undriven enum Signals this example 
converts without throwing and error.

Regards,
Chris

Re: [myhdl-list] TypeError: Unexpected type with toVerilog

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

>>
>>> This is *not* the error that I reported earlier, that the enum cannot be
>>> used in an /always_comb/.
>>
>> To make progress, I need a simple (one-file) test that *fails*
>> when I run it without me having to make any change (which could
>> mask the problem you want address). I'll take it from there.
>>
>
> That was the original intent, it is that time management issue.  I will
> see what I can pull together in the next couple days.
>

Attached is a set of tests for the enum, run using py.test

    >> py.test test_enums.py
    ============ test session starts ==========
    -- Python 2.7.3 -- pytest-2.2.3
    collected 6 items

    test_enums.py .F.F..
    ... (lots-o-info)

It runs 6 tests on 4 version of a similar design.  The first two 
(TrafficOne and TrafficTwo), best of my knowledge, should simulate and 
convert.  The second raises an error during conversion.

The second failure is the issue briefly discussed where in a synchronous 
description conversion is successful where it should raise a 
ConversionError (because the converted code simulation will not match 
the MyHDL simulation).

Unfortunately, this example has quite a bit of code.  I didn't have the 
creative bug to generate a short-n-sweet version that covered all the 
items discussed in this thread.

Regards,
Chris

[myhdl-list] MEP-108 Bundle

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

Attached is the MEP-108 patch.  This patch is to add support for the 
conversion of top-level methods.

Description of the enhancement can be found here,
http://www.myhdl.org/doku.php/meps:mep-108

Regards,
Chris Felton

Re: [myhdl-list] TypeError: Unexpected type with toVerilog

[Jan C. <jan...@mu...>]

On 29/05/12 20:53, Jan Decaluwe wrote:
    . . .
> This is the hopefully clearer error message I just created
> in both branches.
Thanks, I like MyHDL like a long-lost friend, and hope to make much 
more progress together.

Attached is simplified the test code, as there still seems to be a 
problem.

Jan Coombs.
--

Re: [myhdl-list] TypeError: Unexpected type with toVerilog

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

On 05/29/2012 06:34 PM, Jan Coombs wrote:
> On 29/05/12 16:48, Jan Decaluwe wrote:
>      . . .
>> Then I suggest to use the development version (either the default
>> branch, which is the maintenance branch for 0.7, or 0.8-dev)
>> to see if anything changed or becomes clearer.
>
> Have just updated 0.8 and error is the same:
>
> raise ToVerilogError("Unexpected type for constant signal", s._name)
> myhdl.ToVerilogError: Unexpected type for constant signal: execState_E

This is the hopefully clearer error message I just created
in both branches.

For intbv or bool, supporting undriven signals is simple,
by assigning the constant initial value. There may be a
use for this, e.g driving some signals on an external
interface to a constant value if some features are not used.

But for enums it creates some complications in VHDL, and
I don't see how this could be useful. I expect that your
completed design will not have them.

-- 
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] TypeError: Unexpected type with toVerilog

[Jan C. <jan...@mu...>]

On 29/05/12 16:48, Jan Decaluwe wrote:
    . . .
> Then I suggest to use the development version (either the default
> branch, which is the maintenance branch for 0.7, or 0.8-dev)
> to see if anything changed or becomes clearer.

Have just updated 0.8 and error is the same:

raise ToVerilogError("Unexpected type for constant signal", s._name)
myhdl.ToVerilogError: Unexpected type for constant signal: execState_E

Jan Coombs
-- 

Re: [myhdl-list] TypeError: Unexpected type with toVerilog

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

On 05/29/2012 05:34 PM, Jan Coombs wrote:
> On 29/05/12 08:45, Jan Decaluwe wrote:
>
>> Do you really have a need for undriven enum signals?
>
> The code was only for conversion testing, by changing the
> commenting on the return lines.  Perhaps I should have left it in
> error display mode?:)
>
> I could expand the code in order to show simulation as well as
> conversion, but wanted to save us both time.
>
> As far as I could see the enum error returned by this snippet is
> the same as that from building my project, and using enums for the
> state constants.

Then I suggest to use the development version (either the default
branch, which is the maintenance branch for 0.7, or 0.8-dev)
to see if anything changed or becomes clearer.

-- 
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] TypeError: Unexpected type with toVerilog

[Jan C. <jan...@mu...>]

On 29/05/12 08:45, Jan Decaluwe wrote:

> Do you really have a need for undriven enum signals?

The code was only for conversion testing, by changing the 
commenting on the return lines.  Perhaps I should have left it in 
error display mode?:)

I could expand the code in order to show simulation as well as 
conversion, but wanted to save us both time.

As far as I could see the enum error returned by this snippet is 
the same as that from building my project, and using enums for the 
state constants.

Jan Coombs

Re: [myhdl-list] TypeError: Unexpected type with toVerilog

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

On 5/28/2012 5:20 AM, Jan Decaluwe wrote:
> On 05/26/2012 12:19 AM, Christopher Felton wrote:
>
>>
>> Again, the odd behavior is with the /always/ generator conversion.  I
>> believe, it created valid logic.  The converted code should simulate
>> correctly while the MyHDL code doesn't.
>
> That is meaningless. If the converted code doesn't simulate the same
> as the MyHDL code, there is a bug in the convertor, regardless of
> whether the result is deemed "correct" or not. (The same holds for
> synthesis, something almost nobody seems to understand.) The bug
> may be that the convertor did not refuse to convert.

Agree and agree should refuse to convert if possible.  Took me too long 
to realize the issue was an invalid use of the enum, thanks for the 
clarification.

>
>> This is *not* the error that I reported earlier, that the enum cannot be
>> used in an /always_comb/.
>
> To make progress, I need a simple (one-file) test that *fails*
> when I run it without me having to make any change (which could
> mask the problem you want address). I'll take it from there.
>

That was the original intent, it is that time management issue.  I will 
see what I can pull together in the next couple days.

Regards,
Chris

Re: [myhdl-list] TypeError: Unexpected type with toVerilog

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

On 05/26/2012 10:49 AM, Jan Coombs wrote:
> On 26/05/12 00:28, Jan Coombs wrote:
>> The /always_comb/ problem still shows in my processor code when
>> using enums, but converts ok when constants are used:
>
> The attached code shows a problem with using enum for state control
> inside an @always_comb process. I have carefully cut this down from
> my working code to show just my conversion problem.

I would be really surprized if this is your original
problem, because it is related to enum signals which
are not driven, unlikely to be useful in a real design.

Anyway, I have "solved" the problem reported in development
by raising error messages on the use of undriven enum signals.
Supporting this would be easy in Verilog, but not in VHDL,
at least not at the top-level, where enums create some
complications.

Do you really have a need for undriven enum signals?


-- 
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] TypeError: Unexpected type with toVerilog

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

On 05/26/2012 12:19 AM, Christopher Felton wrote:

>
> Again, the odd behavior is with the /always/ generator conversion.  I
> believe, it created valid logic.  The converted code should simulate
> correctly while the MyHDL code doesn't.

That is meaningless. If the converted code doesn't simulate the same
as the MyHDL code, there is a bug in the convertor, regardless of
whether the result is deemed "correct" or not. (The same holds for
synthesis, something almost nobody seems to understand.) The bug
may be that the convertor did not refuse to convert.

> This is *not* the error that I reported earlier, that the enum cannot be
> used in an /always_comb/.

To make progress, I need a simple (one-file) test that *fails*
when I run it without me having to make any change (which could
mask the problem you want address). I'll take it from there.

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