Thread: Re: [myhdl-list] TypeError: Unexpected type with toVerilog (Page 2)
Brought to you by:
jandecaluwe
Menu
▾
▴
myhdl-list
|
From: Christopher F. <chr...@gm...> - 2012-05-30 04:20:56
Attachments:
test_enums.py
|
>>
>>> 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
|
|
From: Jan C. <jan...@mu...> - 2012-05-30 09:59:04
|
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.
|
|
From: Jan D. <ja...@ja...> - 2012-05-30 21:01:16
|
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 |
|
From: Christopher F. <chr...@gm...> - 2012-05-25 22:20:17
|
On 5/25/2012 4:45 PM, Jan Coombs wrote:
> On 25/05/12 22:22, Christopher Felton wrote:
>> On 5/25/2012 3:58 PM, Jan Decaluwe wrote:
>>> On 05/25/2012 02:54 PM, Christopher Felton wrote:
>> <snip>
>>
>>>
>>> How can key be defined, if the enum is defined inside the module?
>>
>> Good question, in the original example the enum was being used as
>> "constant" values. And "key" was of type intbv. The quick answer might
>> have been don't mix types?
>
> I didn't notice that until today, so fixed that, and posted two
> more samples.
>
> The original problem with enums was in some other code, so I will
> recheck that, and post a sample if the error has not been fixed.
>
I don't know if if is really an incorrect use of the enums. I believe
most examples are to define an enum and then create a signal with the
enum type.
tEnum = enum('One', 'Two', 'Three')
x = Signal(tEnum.One)
The question is, should it be valid (convertible) to use enums as basic
constants?
tEnum = enum('One', 'Two', 'Three')
b = intbv(1, min=0, max=10)
b == tEnum.One
Regards,
Chris
|
|
From: Jan D. <ja...@ja...> - 2012-05-28 10:16:13
|
On 05/26/2012 12:19 AM, Christopher Felton wrote:
>
> I don't know if if is really an incorrect use of the enums. I believe
> most examples are to define an enum and then create a signal with the
> enum type.
>
> tEnum = enum('One', 'Two', 'Three')
> x = Signal(tEnum.One)
>
> The question is, should it be valid (convertible) to use enums as basic
> constants?
No, enum is in principle an abstract type for which the encoding
could be chosen as part of later optimization. Note that you
can choose between an number of encodings from myhdl (when
defining the enum) or you can leave it to synthesis later (at
least in VHDL where the enum is mapped to a VHDL enum).
--
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
|
|
From: Jan D. <ja...@ja...> - 2012-05-28 10:25:24
|
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 |
|
From: Christopher F. <chr...@gm...> - 2012-05-29 11:59:43
|
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 |
|
From: Jan C. <jan...@mu...> - 2012-05-25 11:48:07
Attachments:
SnL_58_ConvTest01.tar.gz
|
On 25/05/12 12:09, Jan Decaluwe wrote: > On 05/24/2012 10:53 PM, Christopher Felton wrote: >> On 5/24/2012 3:23 PM, Thoma HAUC wrote: >>> @always_comb >>> def outputenable(): >>> if ((state == StateEnum.HSYNC) or (state == StateEnum.SYNC) >> >> I believe this is the issue. There was a recent thread on this. It >> looks like enums fail in an always_comb. A simple test case was >> submitted recently. > > No, it was something else. Can you point me to the > post/author of the other problem(s). I lost track a little > but I will look into it with priority. Have attached short code sample. There was a problem using enums in @always_comb Chris F has also sample code to demo problem. > Also, I propose to start using the bug tracker again, for > formal bug reporting (after discussing it here preferably). > Note that you can attach files to bug reports. I have > done this for the bug that was just reported. That sounds good. BTW, could you advise me if I should use reply/reply-all for posting. Jan Coombs |
|
From: Jan D. <ja...@ja...> - 2012-05-25 20:38:24
|
On 05/25/2012 01:47 PM, Jan Coombs wrote: > > BTW, could you advise me if I should use reply/reply-all for posting. reply -- 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 |
|
From: Jan D. <ja...@ja...> - 2012-05-25 20:56:01
|
On 05/25/2012 01:47 PM, Jan Coombs wrote: >> >> No, it was something else. Can you point me to the >> post/author of the other problem(s). I lost track a little >> but I will look into it with priority. > > Have attached short code sample. There was a problem using enums in @always_comb Not short, and example fails with ImportError. -- 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 |
|
From: Jan C. <jan...@mu...> - 2012-05-25 21:21:54
Attachments:
test_case_bug.py
test_enum_bug.py
|
On 25/05/12 21:55, Jan Decaluwe wrote: > On 05/25/2012 01:47 PM, Jan Coombs wrote: > >>> >>> No, it was something else. Can you point me to the >>> post/author of the other problem(s). I lost track a little >>> but I will look into it with priority. >> >> Have attached short code sample. There was a problem using enums in @always_comb > > Not short, and example fails with ImportError. > Sorry for that, I am slowly getting quicker at stripping code. These two are self-contained and small. It seems to show irregularity in case generation, but does not show the problem where use of enum seemed illegal. Thanks for the reply advice. Jan Coombs. -- |
|
From: Jan C. <jan...@mu...> - 2012-05-25 21:45:57
|
On 25/05/12 22:22, Christopher Felton wrote: > On 5/25/2012 3:58 PM, Jan Decaluwe wrote: >> On 05/25/2012 02:54 PM, Christopher Felton wrote: > <snip> > >> >> How can key be defined, if the enum is defined inside the module? > > Good question, in the original example the enum was being used as > "constant" values. And "key" was of type intbv. The quick answer might > have been don't mix types? I didn't notice that until today, so fixed that, and posted two more samples. The original problem with enums was in some other code, so I will recheck that, and post a sample if the error has not been fixed. Jan Coombs -- |
|
From: Christopher F. <chr...@gm...> - 2012-05-24 19:18:18
|
On 5/24/2012 1:43 PM, Thoma HAUC wrote:
> Hi Tom,
>
> I already simulated the design without any issue.
> The exception raises only during verilog generation process.
>
> Thoma
>
>> Not sure but have you simulated it in MyHDL? Usually that will help
>> expose problems better than trying to go directly to Verilog.
>>
>> On 05/21/2012 03:54 PM, Thoma HAUC wrote:
>>> Hi,
>>>
>>> I am new to myHDL and it seems to be a powerful tool.
>>> Today, I need some help to locate the reason of the below exception.
>>> Because there are no clue to indicate the line of the issue, I am
>>> currently blocked in my evaluation of myHDL.
>>>
>>> Thank you in advance.
>>>
>>> Thoma
>>>
<snip>
>>> "/usr/lib/python2.7/site-packages/myhdl/conversion/_analyze.py",
>>> line 407, in _getNritems
>>> raise TypeError("Unexpected type")
>>> TypeError: Unexpected type
>
This will be hard to assist with out an example, either the code you are
trying to convert or a code example. It possibly looks like an invalid
type is being converted?
Regards,
Chris
|
|
From: Thoma H. <tho...@gm...> - 2012-05-25 04:52:09
|
Hi Jan,
The function name has evolved.
I found the issue but I am not able to explain the reason.
In fact, when I replace:
elif (state == StateEnum.SEND):
if (run == INACTIVE):
state.next = StateEnum.SEND3
with:
elif (state == StateEnum.SEND):
if (run != ACTIVE):
state.next = StateEnum.SEND3
the exception will not longer raise and the verilog description seems
correct.
Here are the source for the missing calls (visible in the traceback):
def convert(converter, architecture):
clr = Signal(ACTIVE)
clk = Signal(INACTIVE)
run, ack = [Signal(INACTIVE) for i in range(2)]
serialin = Signal(HIGH)
datain = Signal(intbv(0)[8:])
rdy = Signal(INACTIVE)
oe = Signal(INACTIVE)
serialout = Signal(HIGH)
dataout = Signal(intbv(0)[8:])
converter(architecture, clr, clk, run, ack, serialin, datain, rdy,
oe, serialout, dataout)
def convert2verilog(architecture):
convert(toVerilog, architecture)
convert2verilog(bidir_serial_master)
Thoma
>
> If Chris is right, that it is a top level interface problem, then you
> will need to show the definitions for these: (clr, clk, run,
> ack, serialin, datain, rdy, oe, serialout, dataout) in order for anyone
> to re-create the problem, or to guesstimate it.
>
> Niggle: the name of this source does not seem to match the one shown in
> your error messages. (convert2verilog(bidir_serial))
>
> I am also struggling with this type of problem, so am very interested to
> understand yours, and would like to try techniques that have sometimes
> worked for me.
>
> For anyone to have a quick look they will need source that demonstrates
> the problem with out having to re-create whatever might be missing.
>
> Jan Coombs
|
|
From: Jan C. <jan...@mu...> - 2012-05-25 05:05:05
|
On 25/05/12 05:51, Thoma HAUC wrote: > Hi Jan, > > The function name has evolved. > I found the issue but I am not able to explain the reason. . . . Chris is correct; there is a problem using enums in @always_comb decorators which I missed when reading through your code. I also have this problem, and have temporarily switched to using constants. Jan Coombs |
|
From: Thoma H. <tho...@gm...> - 2012-05-24 20:31:21
|
Hi Jan,
Are you able to print out the line number that raises the exception?
Could you explain me what I did wrong?
In advance many thanks
Here is the python source:
LOW, HIGH = bool(0), bool(1)
INACTIVE, ACTIVE = LOW, HIGH
StateEnum = enum('IDLE', 'HSYNC', 'SYNC', 'SYNC2', 'HADDR', 'ADDR',
'ADDR2', 'ADDR3', 'HSEND', 'SEND', 'SEND2', 'SEND3', 'HRECV', 'RECV',
'HRECV2', 'RECV2')
def bidir_serial_master(clr, clk, run, ack, serialin, datain, rdy, oe,
serialout, dataout):
state = Signal(StateEnum.IDLE)
timeout = Signal(INACTIVE)
count = Signal(intbv(0)[3:])
inputreg = Signal(intbv(0)[8:])
internaldata = Signal(intbv(0)[8:])
int_rdy = Signal(INACTIVE)
int_serialout = Signal(HIGH)
@always_comb
def copy():
rdy.next = int_rdy
serialout.next = int_serialout
@always_comb
def outputenable():
if ((state == StateEnum.HSYNC) or (state == StateEnum.SYNC) or
(state == StateEnum.SYNC2) or (state == StateEnum.HADDR) or (state ==
StateEnum.ADDR) or (state == StateEnum.ADDR2) or (state ==
StateEnum.ADDR3) or (state == StateEnum.HSEND) or (state ==
StateEnum.SEND) or (state == StateEnum.SEND2) or (state ==
StateEnum.SEND3)):
oe.next = ACTIVE
else:
oe.next = INACTIVE
@always_comb
def ready():
if ((state == StateEnum.IDLE) or (state == StateEnum.SYNC) or
(state == StateEnum.ADDR) or (state == StateEnum.RECV2)):
int_rdy.next = ACTIVE
elif (state == StateEnum.SEND):
int_rdy.next = run
else:
int_rdy.next = INACTIVE
@always_comb
def send_data():
if ((state == StateEnum.ADDR) or (state == StateEnum.ADDR2) or
(state == StateEnum.ADDR3) or (state == StateEnum.SEND) or (state ==
StateEnum.SEND2) or (state == StateEnum.SEND3)):
int_serialout.next = internaldata[count]
elif ((state == StateEnum.HADDR) or (state == StateEnum.HSEND) or
(state == StateEnum.HRECV)):
int_serialout.next = LOW
else:
int_serialout.next = HIGH
@always(clk.posedge, clr.posedge)
def storage():
if (clr == ACTIVE):
inputreg.next = 0
internaldata.next = 0
else:
if ((ack == ACTIVE) and (int_rdy == ACTIVE)):
inputreg.next = datain
elif ((count == 7) and ((state == StateEnum.SYNC2) or (state
== StateEnum.ADDR3) or (state == StateEnum.SEND2))):
internaldata.next = inputreg
if ((state == StateEnum.RECV) or (state == StateEnum.RECV2)):
if (count == 7):
dataout.next[7:] = internaldata[7:]
dataout.next[7] = serialin
else:
internaldata.next[count] = serialin
@always(clk.posedge, clr.posedge)
def counter():
if (clr == ACTIVE):
count.next = 0
timeout.next = INACTIVE
else:
if ((state == StateEnum.SYNC) or (state == StateEnum.SYNC2)
or (state == StateEnum.ADDR) or (state == StateEnum.ADDR2) or (state ==
StateEnum.ADDR3) or (state == StateEnum.SEND) or (state ==
StateEnum.SEND2) or (state == StateEnum.SEND3) or (state ==
StateEnum.RECV) or (state == StateEnum.RECV2)):
count.next = (count + 1) % 8
if (count == 6):
timeout.next = ACTIVE
if (count == 7):
timeout.next = INACTIVE
@always(clk.posedge, clr.posedge)
def fsm():
if (clr == ACTIVE):
state.next = StateEnum.IDLE
else:
if (state == StateEnum.IDLE):
if (run == ACTIVE):
state.next = StateEnum.SYNC
elif (state == StateEnum.SYNC):
if (ack == ACTIVE):
state.next = StateEnum.HSYNC
elif (state == StateEnum.HSYNC):
state.next = StateEnum.SYNC2
elif (state == StateEnum.SYNC2):
if (timeout == ACTIVE):
state.next = StateEnum.HADDR
elif (state == StateEnum.HADDR):
state.next = StateEnum.ADDR
elif (state == StateEnum.ADDR):
if (internaldata[0] == LOW):
state.next = StateEnum.ADDR2
elif (ack == ACTIVE):
state.next = StateEnum.ADDR3
elif (state == StateEnum.ADDR2):
if (timeout == ACTIVE):
state.next = StateEnum.HRECV
elif (state == StateEnum.ADDR3):
if (timeout == ACTIVE):
state.next = StateEnum.HSEND
elif (state == StateEnum.HSEND):
state.next = StateEnum.SEND
elif (state == StateEnum.SEND):
if (run == INACTIVE):
state.next = StateEnum.SEND3
elif (ack == ACTIVE):
state.next = StateEnum.SEND2
elif (state == StateEnum.SEND2):
if (timeout == ACTIVE):
state.next = StateEnum.HSEND
elif (state == StateEnum.SEND3):
if (timeout == ACTIVE):
state.next = StateEnum.IDLE
elif (state == StateEnum.HRECV):
state.next = StateEnum.RECV
elif (state == StateEnum.RECV):
if (timeout == ACTIVE):
if (run == ACTIVE):
state.next = StateEnum.HRECV2
else:
state.next = StateEnum.IDLE
elif (state == StateEnum.HRECV2):
state.next = StateEnum.RECV2
elif (state == StateEnum.RECV2):
if (ack == ACTIVE):
state.next = StateEnum.RECV
else:
state.next = StateEnum.IDLE
return instances()
Thoma
> [texte cité caché]
_toVerilog.py",
> [texte cité caché]
------------------------------------------------------------------------------
> [texte cité caché]
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
|
|
From: Jan C. <jan...@mu...> - 2012-05-24 21:06:05
|
On 24/05/12 21:30, Thoma HAUC wrote:
. . .
> Here is the python source:
. . .
> def bidir_serial_master(clr, clk, run, ack, serialin, datain, rdy, oe,
> serialout, dataout):
If Chris is right, that it is a top level interface problem, then
you will need to show the definitions for these: (clr, clk, run,
ack, serialin, datain, rdy, oe, serialout, dataout) in order for
anyone to re-create the problem, or to guesstimate it.
Niggle: the name of this source does not seem to match the one
shown in your error messages. (convert2verilog(bidir_serial))
I am also struggling with this type of problem, so am very
interested to understand yours, and would like to try techniques
that have sometimes worked for me.
For anyone to have a quick look they will need source that
demonstrates the problem with out having to re-create whatever
might be missing.
Jan Coombs
|
|
From: Jan D. <ja...@ja...> - 2012-05-25 11:07:04
|
On 05/24/2012 10:30 PM, Thoma HAUC wrote: > Hi Jan, > > Are you able to print out the line number that raises the exception? > Could you explain me what I did wrong? I debugged this. You did nothing wrong - there was a bug in case statement inference. Workaround: use boolean tests on boolean variables (if run, if not ack) for the moment. Alternatively, I have fixed this in development, both in the default maintenance branch as in 0.8-dev. As a matter of style, it may be clearer to do all the combinatorial decodes from a single always_comb, and use default assignments in the begining, to specify the most common value of a signal. -- 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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X