myhdl-list

[myhdl-list] Bug in generated code?

[Thomas H. <th...@ct...>]

I believe I have found a bug in the code generator.

Here is the MyHDL code:

     rx = Signal(intbv(0, min=-1024, max=1024)
     a = Signal(intbv(0, min=0, max=256)
     b = Signal(intbv(0, min=0, max=256)
     c = Signal(intbv(0, min=0, max=256)
     d = Signal(intbv(0, min=0, max=256)


     rx.next = a + b - (c + d)

and this is the generated VHDL code:

     a: in unsigned(7 downto 0);
     b: in unsigned(7 downto 0);
     c: in unsigned(7 downto 0);
     d: in unsigned(7 downto 0);

     signal rx: signed (9 downto 0);

     rx <= signed((resize(a, 10) + b) - (c + d));

If I understand the VHDL code correctly, there is data
lost in the (c + d) operation since the intermediate result has only
8 bits instead of the required 10 bits.

Restructuring the MyHDL code like this:
     rx.next = a + b - c - d
generates this VHDL code:
     rx <= signed(((resize(a, 10) + b) - c) - d);
which looks correct to me.

Note that I'm using MyHDL 0.7, have not tried the newer version.

Thomas

Re: [myhdl-list] Bug in generated code?

[Thomas H. <th...@ct...>]

Am 16.01.2013 20:26, schrieb Thomas Heller:
> I believe I have found a bug in the code generator.
>
[...]
>
> Note that I'm using MyHDL 0.7, have not tried the newer version.

Version 0.8-dev as of yesterday night has the same problem.

Thomas

Re: [myhdl-list] Bug in generated code?

[Tom D. <TD...@Di...>]

Hi,

This is interesting but I don't think it would be a bug. I am not sure the
MyHDL specs call for automatic size conversions.


On Wed, Jan 16, 2013 at 1:26 PM, Thomas Heller <th...@ct...> wrote:

> I believe I have found a bug in the code generator.
>
> Here is the MyHDL code:
>
>      rx = Signal(intbv(0, min=-1024, max=1024)
>      a = Signal(intbv(0, min=0, max=256)
>      b = Signal(intbv(0, min=0, max=256)
>      c = Signal(intbv(0, min=0, max=256)
>      d = Signal(intbv(0, min=0, max=256)
>
>
>      rx.next = a + b - (c + d)
>
> and this is the generated VHDL code:
>
>      a: in unsigned(7 downto 0);
>      b: in unsigned(7 downto 0);
>      c: in unsigned(7 downto 0);
>      d: in unsigned(7 downto 0);
>
>      signal rx: signed (9 downto 0);
>
>      rx <= signed((resize(a, 10) + b) - (c + d));
>
> If I understand the VHDL code correctly, there is data
> lost in the (c + d) operation since the intermediate result has only
> 8 bits instead of the required 10 bits.
>

I am most used to Verilog, but if I were coding this in Verilog and didn't
wanted the c+d to grow, I would of forced them into an intermediate signal
that was one bit bigger and then performed the addition to guarantee the
carry was not lost.

I am not sure if this is any different in VHDL.

Also, I would not think that MyHDL would guarantee the growth either. There
are cases where you don't want it as well.

If I were coding this, I would also grow them before the addition if you
wanted the carry to count.

Others may have a better grasp of what MyHDL is supposed to do for this
case.

Yours,

Tom Dillon

Re: [myhdl-list] Bug in generated code?

[Thomas H. <th...@ct...>]

Am 17.01.2013 17:26, schrieb Tom Dillon:
> Hi,
>
> This is interesting but I don't think it would be a bug. I am not sure
> the MyHDL specs call for automatic size conversions.

I'd say it is a bug, because the generated VHDL code behaves differently
than the MyHDL simulation.

Also, IMO it disagrees stronly with the spirit of Jan's article:

http://www.jandecaluwe.com/hdldesign/counting.html

which says:

<quote>
The convertor will generate the required sign extensions, resizings and 
type castings. It therefore automates this tedious and error-prone 
bookkeeping task for you.
<quote/>

Thomas

>
>
> On Wed, Jan 16, 2013 at 1:26 PM, Thomas Heller <th...@ct...
> <mailto:th...@ct...>> wrote:
>
>     I believe I have found a bug in the code generator.
>
>     Here is the MyHDL code:
>
>           rx = Signal(intbv(0, min=-1024, max=1024)
>           a = Signal(intbv(0, min=0, max=256)
>           b = Signal(intbv(0, min=0, max=256)
>           c = Signal(intbv(0, min=0, max=256)
>           d = Signal(intbv(0, min=0, max=256)
>
>
>           rx.next = a + b - (c + d)
>
>     and this is the generated VHDL code:
>
>           a: in unsigned(7 downto 0);
>           b: in unsigned(7 downto 0);
>           c: in unsigned(7 downto 0);
>           d: in unsigned(7 downto 0);
>
>           signal rx: signed (9 downto 0);
>
>           rx <= signed((resize(a, 10) + b) - (c + d));
>
>     If I understand the VHDL code correctly, there is data
>     lost in the (c + d) operation since the intermediate result has only
>     8 bits instead of the required 10 bits.
>
>
> I am most used to Verilog, but if I were coding this in Verilog and
> didn't wanted the c+d to grow, I would of forced them into an
> intermediate signal that was one bit bigger and then performed the
> addition to guarantee the carry was not lost.
>
> I am not sure if this is any different in VHDL.
>
> Also, I would not think that MyHDL would guarantee the growth either.
> There are cases where you don't want it as well.
>
> If I were coding this, I would also grow them before the addition if you
> wanted the carry to count.
>
> Others may have a better grasp of what MyHDL is supposed to do for this
> case.
>
> Yours,
>
> Tom Dillon
>
>
>
>
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. ON SALE this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122712
>
>
>
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] Bug in generated code?

[Tom D. <TD...@Di...>]

Thanks for the education. I would have to say I have been coding with MyHDL
like a "Verilog die-hard". I have been resizing myself never thinking MyHDL
might do that for me.

One question, does MyHDL produce an error in simulation if (c + d) > 255?


On Thu, Jan 17, 2013 at 4:23 PM, Thomas Heller <th...@ct...> wrote:

> Am 17.01.2013 17:26, schrieb Tom Dillon:
> > Hi,
> >
> > This is interesting but I don't think it would be a bug. I am not sure
> > the MyHDL specs call for automatic size conversions.
>
> I'd say it is a bug, because the generated VHDL code behaves differently
> than the MyHDL simulation.
>
> Also, IMO it disagrees stronly with the spirit of Jan's article:
>
> http://www.jandecaluwe.com/hdldesign/counting.html
>
> which says:
>
> <quote>
> The convertor will generate the required sign extensions, resizings and
> type castings. It therefore automates this tedious and error-prone
> bookkeeping task for you.
> <quote/>
>
> Thomas
>
> >
> >
> > On Wed, Jan 16, 2013 at 1:26 PM, Thomas Heller <th...@ct...
> > <mailto:th...@ct...>> wrote:
> >
> >     I believe I have found a bug in the code generator.
> >
> >     Here is the MyHDL code:
> >
> >           rx = Signal(intbv(0, min=-1024, max=1024)
> >           a = Signal(intbv(0, min=0, max=256)
> >           b = Signal(intbv(0, min=0, max=256)
> >           c = Signal(intbv(0, min=0, max=256)
> >           d = Signal(intbv(0, min=0, max=256)
> >
> >
> >           rx.next = a + b - (c + d)
> >
> >     and this is the generated VHDL code:
> >
> >           a: in unsigned(7 downto 0);
> >           b: in unsigned(7 downto 0);
> >           c: in unsigned(7 downto 0);
> >           d: in unsigned(7 downto 0);
> >
> >           signal rx: signed (9 downto 0);
> >
> >           rx <= signed((resize(a, 10) + b) - (c + d));
> >
> >     If I understand the VHDL code correctly, there is data
> >     lost in the (c + d) operation since the intermediate result has only
> >     8 bits instead of the required 10 bits.
> >
> >
> > I am most used to Verilog, but if I were coding this in Verilog and
> > didn't wanted the c+d to grow, I would of forced them into an
> > intermediate signal that was one bit bigger and then performed the
> > addition to guarantee the carry was not lost.
> >
> > I am not sure if this is any different in VHDL.
> >
> > Also, I would not think that MyHDL would guarantee the growth either.
> > There are cases where you don't want it as well.
> >
> > If I were coding this, I would also grow them before the addition if you
> > wanted the carry to count.
> >
> > Others may have a better grasp of what MyHDL is supposed to do for this
> > case.
> >
> > Yours,
> >
> > Tom Dillon
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> > MVPs and experts. ON SALE this month only -- learn more at:
> > http://p.sf.net/sfu/learnmore_122712
> >
> >
> >
> > _______________________________________________
> > myhdl-list mailing list
> > myh...@li...
> > https://lists.sourceforge.net/lists/listinfo/myhdl-list
> >
>
>
>
>
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. ON SALE this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122712
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] Bug in generated code?

[Thomas H. <th...@ct...>]

Am 18.01.2013 21:11, schrieb Tom Dillon:
> Thanks for the education. I would have to say I have been coding with
> MyHDL like a "Verilog die-hard". I have been resizing myself never
> thinking MyHDL might do that for me.
>
> One question, does MyHDL produce an error in simulation if (c + d) > 255?

No, the MyHDL simulation worked perfectly; but the hardware (compiled
from toVHDL and loaded into a FPGA) produced wrong results.  It took
me some time to find the reason.

Maybe I should have simulated the VHDL code also, but I did not.

Let me describe the approach that I took in my work (in case this is
interesting to on this mailing list):

The goal of my FPGA is to find the x/y coordinates of a small light
point on a 4-quadrant photodiode.  The equations for this are:

x = (a+b) - (c+d) / (a+b+c+d)
y = (a+d) - (b+c) / (a+b+c+d)

where a, b, c, d are the digitized currents through the four quadrants
of the photodetector, and x and y are the final coordinates.

First, my fpga read the digitized intensity values and transfers them
to the PC.  The PC calculates the x/y values with the above formulas and
displays the result x1/y1.

Then, I wrote a MyHDL module which (with some pipelining) also
calculates these values.  I constructed a simulation object, and fed
the a,b,c,d values read from the fpga to the instance, simulated a few
timesteps, retrived the values as x2/y2 from the MyHDL instance and
displayed this result also.  They were the same as x1/y1.

Finally, I converted the MyHDL instances to VHDL, compiled and loaded 
into the FPGA, together with code that transferred the values calculated
in the FPGA also to the PC, as x3/y3.

So, all the values x1/y1, x2/y2, x3/y3 should be the same:  The first
calculated by Python code, the second by the MyHDL simulation, the third
by the hardware.

Unfortunately, most of the time x3/y3 (calculated by the FPGA) were
wrong until I fixed the paranthesis in the MyHDL code.

Thomas

Re: [myhdl-list] Bug in generated code?

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

On 1/18/13 2:43 PM, Thomas Heller wrote:
> Am 18.01.2013 21:11, schrieb Tom Dillon:
>> Thanks for the education. I would have to say I have been coding with
>> MyHDL like a "Verilog die-hard". I have been resizing myself never
>> thinking MyHDL might do that for me.
>>
>> One question, does MyHDL produce an error in simulation if (c + d) > 255?
>
> No, the MyHDL simulation worked perfectly; but the hardware (compiled
> from toVHDL and loaded into a FPGA) produced wrong results.  It took
> me some time to find the reason.
>
> Maybe I should have simulated the VHDL code also, but I did not.
>

I put an example that runs the MyHDL, VHDL, and Verilog
simulations here:

https://bitbucket.org/cfelton/examples/src/tip/math/example_math.py

As discussed, the VHDL simulation will fail and the MyHDL
and Verilog do not.  This is a simulation mismatch and it
is an issue that needs to be resolved.

Some thoughts on the correction.  One approach would to
resize all the operands to match the type of the LHS?

Regards,
Chris

Re: [myhdl-list] Bug in generated code?

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

On 1/18/2013 2:43 PM, Thomas Heller wrote:
> Am 18.01.2013 21:11, schrieb Tom Dillon:
>> Thanks for the education. I would have to say I have been coding with
>> MyHDL like a "Verilog die-hard". I have been resizing myself never
>> thinking MyHDL might do that for me.
>>
>> One question, does MyHDL produce an error in simulation if (c + d) > 255?
>
> No, the MyHDL simulation worked perfectly; but the hardware (compiled
> from toVHDL and loaded into a FPGA) produced wrong results.  It took
> me some time to find the reason.
>
> Maybe I should have simulated the VHDL code also, but I did not.
>
<snip>

I started attempting to compare the MyHDL simulation
vs. the VHDL simulation, I put the following together:

     from myhdl import *

     def math_abcd(a,b,c,d,x):
         @always_comb
         def hdl():
             x.next = a + b - (c + d)
         return hdl

     def example_math():
         Omax = 64
         Xmin,Xmax = (-1*(Omax*4), Omax*4)
         x = Signal(intbv(0, min=Xmin, max=Xmax))
         a = Signal(intbv(0, min=0, max=Omax))
         b = Signal(intbv(0, min=0, max=Omax))
         c = Signal(intbv(0, min=0, max=Omax))
         d = Signal(intbv(0, min=0, max=Omax))
         tb_dut = math_abcd(a,b,c,d,x)
         @instance
         def tb_stim():
             print('start')
             for aa in range(a.min, a.max):
                 for bb in range(b.min, b.max):
                     for cc in range (c.min, c.max):
                         for dd in range(d.min, d.max):
                             a.next = aa
                             b.next = bb
                             c.next = cc
                             d.next = dd
                             yield delay(4)
                             assert x == (a+b - (c+d))
             print('end')
             raise StopSimulation

         return tb_dut, tb_stim

     if __name__ == '__main__':
         Simulation(example_math()).run()
         toVHDL(example_math)
         toVerilog(example_math)


The MyHDL simulation works fine (as expected) for
all inputs (I reduced the bit widths so it would
run faster).  I did not get time to run the sims
yet.  The converter will create the above simple
test cases, should be able to run the VHDL and
Verilog directly.  Not sure when I will have time to
complete this ...

Regards,
Chris

Re: [myhdl-list] Bug in generated code?

[Thomas H. <th...@ct...>]

Christopher,

I changed your tb_stim instance slightly so that it produces
more output on mismatch.

     def tb_stim():
         print('start')
         for aa in range(a.min, a.max):
             for bb in range(b.min, b.max):
                 for cc in range (c.min, c.max):
                     for dd in range(d.min, d.max):
                         a.next = aa
                         b.next = bb
                         c.next = cc
                         d.next = dd
                         yield delay(4)
                         if x != (aa+bb - (cc+dd)):
                             print "Error in", aa, bb, cc, dd
                             print "Is", x, "Should be", (aa+bb - (cc+dd))
##                        assert x == (aa+bb - (cc+dd))
         print('end')
         raise StopSimulation

     return tb_dut, tb_stim

The myhdl simulation still runs without any errors or output,
simulating the VHDL code in xilinx isim starts with this output:

Simulator is doing circuit initialization process.
start
Finished circuit initialization process.
Error in 0 0 1 63
Is 0 Should be -64
Error in 0 0 2 62
Is 0 Should be -64
Error in 0 0 2 63
Is -1 Should be -65
ISim>
# run 1.00us
Error in 0 0 3 61
Is 0 Should be -64
Error in 0 0 3 62
Is -1 Should be -65
Error in 0 0 3 63
Is -2 Should be -66
Error in 0 0 4 60
Is 0 Should be -64
Error in 0 0 4 61
Is -1 Should be -65
Error in 0 0 4 62
Is -2 Should be -66
Error in 0 0 4 63
Is -3 Should be -67

So, MyHDL and VHDL disagree.  Changing the expression in math_abcd()
makes isim and myhdl agree:

def math_abcd(a,b,c,d,x):
     @always_comb
     def hdl():
         x.next = a + b - c - d
     return hdl

Thomas

Re: [myhdl-list] Bug in generated code?

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

This Code i think actually shows two glitches in the VHDL converter.
One was already discussed here, but i think it has been forgotten. This is  
just to remember.
Here the link: http://permalink.gmane.org/gmane.comp.python.myhdl/2218


       from myhdl import *
       from random import randrange

       def TOP(outvalue,sel_value):

	  @always_comb
	  def combi_sel():
	    outvalue.next=1
	    if sel_value == bool(0):
	      outvalue.next=8
	    elif sel_value == bool(1):
	      outvalue.next[0]=sel_value[2]*sel_value[0] #8  
#sel_value[0]+sel_value[0]
	
	  return combi_sel
	
	
       def test_bench():
	  outsignal=Signal(intbv(0)[4:])
	  sel_value=Signal(intbv(0)[4:])
	  ###### add the unit too be tested#######
	  instanc_top=TOP(outsignal,sel_value)
	
	  @instance
	  def stimulus():
	    sel_value.next=0
	    yield delay(10)
	    for i in range(sel_value.max):
		sel_value.next=i
		yield delay(10)
		print "sel_value: ",sel_value,"\toutsignal:", outsignal
		
	    raise StopSimulation
	
	
	  return  stimulus,instanc_top

	
       if __name__ == '__main__':
	
	  ############ Simulation ################
	  sim = Simulation(test_bench())
	  print "#"*10+"Simulation Started" + "#"*10
	  sim.run()
	  print "#"*10+"Simulation Finished" + "#"*10
	
	
	
	  ############### Conversion ###############
	  print "Conversion To VHDL Started" + "-"*30
	  outsignal=Signal(intbv(0)[4:])
	  sel_value=Signal(intbv(0)[4:])
	  toVHDL(TOP,outsignal,sel_value)



Conclusion:
Simulation works !!,
VHDL conversion result with 0.8 dev version:


       -- File: TOP.vhd
       -- Generated by MyHDL 0.8dev
       -- Date: Sun Jan 20 12:50:43 2013


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

       use work.pck_myhdl_08.all;

       entity TOP is
	  port (
	      outvalue: out unsigned(3 downto 0);
	      sel_value: in unsigned(3 downto 0)
	  );
       end entity TOP;


       architecture MyHDL of TOP is


       begin




       TOP_COMBI_SEL: process (sel_value) is
       begin
	  outvalue <= "0001";
	  if (sel_value = False) then
	      outvalue <= "1000";
	  elsif (sel_value = True) then
	      outvalue(0) <= stdl(to_unsigned(sel_value(2), 1) *  
to_unsigned(sel_value(0), 1));
	  end if;
       end process TOP_COMBI_SEL;

       end architecture MyHDL;



Issues:
* There is no compare operator for unsigned(x downto 0) with the False.
In Line: "if (sel_value = False) then"
* There is no Function stdl(arg: unsigned) which takes the unsigned in the  
pck_myhdl_08.
In Line: "outvalue(0) <= stdl(to_unsigned(sel_value(2), 1) *  
to_unsigned(sel_value(0), 1));"




greetings

Norbo

[myhdl-list] VHDL Conversion Errors (was: Bug in generated code?)

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

On 1/20/13 6:01 AM, Norbo wrote:
> This Code i think actually shows two glitches in the VHDL converter.
> One was already discussed here, but i think it has been forgotten. This is
> just to remember.
> Here the link: http://permalink.gmane.org/gmane.comp.python.myhdl/2218
>
>
<snip>
>

Let me try and summarize, we believe we have encountered
three different VHDL conversion errors.

    1. bitwise multiplication (there was the wider
    question if the types were correct but since the ops
    were invalid it was a moot point).

    2. An odd intbv(val) == bool(val) comparison error,
    python allows this check (what is the rule?) but when
    converted the mixed types is not a valid comparison?

    3. More than two operand math operations and resizing.

On the #2 issues, since the MyHDL simulation != VHDL
simulation, does this constitute an error, not sure?  I
had a similar issue, I often used:

        if reset:

The myhdl simulation worked and Verilog conversion worked
but the VHDL did not, the fix was to explicitly state:

        if reset == False:

Even though there was a simulation mismatch it was suggested
that the "reset == False", is the desired form.  I am not sure
if the mixed type comparison should be converted?  Instead, we
probably want the converter to raise a conversion exception and
not convert the code.

Now, the best way to keep track of these so we don't loose
track of them?

Regards,
Chris

Re: [myhdl-list] VHDL Conversion Errors (was: Bug in generated code?)

[Angel E. <ang...@gm...>]

On Wed, Jan 23, 2013 at 3:38 AM, Christopher Felton
<chr...@gm...> wrote:
> On 1/20/13 6:01 AM, Norbo wrote:
>> This Code i think actually shows two glitches in the VHDL converter.
>> One was already discussed here, but i think it has been forgotten. This is
>> just to remember.
>> Here the link: http://permalink.gmane.org/gmane.comp.python.myhdl/2218
>>
>>
> <snip>
>>
>
> Let me try and summarize, we believe we have encountered
> three different VHDL conversion errors.
>
>     1. bitwise multiplication (there was the wider
>     question if the types were correct but since the ops
>     were invalid it was a moot point).
>
>     2. An odd intbv(val) == bool(val) comparison error,
>     python allows this check (what is the rule?) but when
>     converted the mixed types is not a valid comparison?
>
>     3. More than two operand math operations and resizing.
>
> On the #2 issues, since the MyHDL simulation != VHDL
> simulation, does this constitute an error, not sure?  I
> had a similar issue, I often used:
>
>         if reset:
>
> The myhdl simulation worked and Verilog conversion worked
> but the VHDL did not, the fix was to explicitly state:
>
>         if reset == False:
>
> Even though there was a simulation mismatch it was suggested
> that the "reset == False", is the desired form.  I am not sure
> if the mixed type comparison should be converted?  Instead, we
> probably want the converter to raise a conversion exception and
> not convert the code.

Personally I would really like if MyHDL was able to understand "if
boolean:" and even "if integer:" (intb, etc) types of "if statements".
That is a very common python coding style and it would be really nice
to be able to write MyHDL code that still feels as python. Besides I
am sure this is a common and easy mistake to make if do any regular
python programming.

Cheers,

Angel

Re: [myhdl-list] VHDL Conversion Errors

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

On 1/22/2013 8:38 PM, Christopher Felton wrote:
> On 1/20/13 6:01 AM, Norbo wrote:
>> This Code i think actually shows two glitches in the VHDL converter.
>> One was already discussed here, but i think it has been forgotten. This is
>> just to remember.
>> Here the link: http://permalink.gmane.org/gmane.comp.python.myhdl/2218
>>
>>
> <snip>
>>
>
> Let me try and summarize, we believe we have encountered
> three different VHDL conversion errors.
>
>      1. bitwise multiplication (there was the wider
>      question if the types were correct but since the ops
>      were invalid it was a moot point).
>
>      2. An odd intbv(val) == bool(val) comparison error,
>      python allows this check (what is the rule?) but when
>      converted the mixed types is not a valid comparison?
>
>      3. More than two operand math operations and resizing.
>
> On the #2 issues, since the MyHDL simulation != VHDL
> simulation, does this constitute an error, not sure?  I
> had a similar issue, I often used:
>
>          if reset:
>
> The myhdl simulation worked and Verilog conversion worked
> but the VHDL did not, the fix was to explicitly state:
>
>          if reset == False:
>
> Even though there was a simulation mismatch it was suggested
> that the "reset == False", is the desired form.  I am not sure
> if the mixed type comparison should be converted?  Instead, we
> probably want the converter to raise a conversion exception and
> not convert the code.
>
> Now, the best way to keep track of these so we don't loose
> track of them?
>
> Regards,
> Chris
>
>

I should back up, I might not be recalling some of this
correctly or it has been modified recently.  I ran a small
test and some of the above worked.  I need some more time
and contemplation to articulate the possible issues.

I will post a follow-up tonight when I, hopefully, have some
time.

Regards,
Chris

Re: [myhdl-list] VHDL Conversion Errors (was: Bug in generated code?)

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

> On the #2 issues, since the MyHDL simulation != VHDL
> simulation, does this constitute an error, not sure?  I
> had a similar issue, I often used:
>
>         if reset:
>
> The myhdl simulation worked and Verilog conversion worked
> but the VHDL did not, the fix was to explicitly state:
>
>         if reset == False:
>
> Even though there was a simulation mismatch it was suggested
> that the "reset == False", is the desired form.  I am not sure
> if the mixed type comparison should be converted?  Instead, we
> probably want the converter to raise a conversion exception and
> not convert the code.

i am a bit confused:
when a negedge event on the reset is inserted in the sensitivity list,  
then it would
look like the following, right?

############## case 1 ###########

     if reset:

-->> conversion to vhdl works but would be the wrong value for the negedge  
event. right?



############## case 2 ###########

     if not reset:

-->> conversion to vhdl fails, with: Error:  No proper edge value test


############## case 3 ###########

     if reset== False:

-->> conversion to vhdl fails, with: Error:    No proper edge value test


############## case 4 ###########

     if reset== bool(0):

-->> conversion to vhdl fails, with: Error:    No proper edge value test


############## case 5 ###########

     if reset==0:

-->> The working version !!


greetings
Norbo

Re: [myhdl-list] VHDL Conversion Errors

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

On 1/23/2013 10:35 AM, Norbo wrote:
>> On the #2 issues, since the MyHDL simulation != VHDL
>> simulation, does this constitute an error, not sure?  I
>> had a similar issue, I often used:
>>
>>          if reset:
>>
>> The myhdl simulation worked and Verilog conversion worked
>> but the VHDL did not, the fix was to explicitly state:
>>
>>          if reset == False:
>>
>> Even though there was a simulation mismatch it was suggested
>> that the "reset == False", is the desired form.  I am not sure
>> if the mixed type comparison should be converted?  Instead, we
>> probably want the converter to raise a conversion exception and
>> not convert the code.
>
> i am a bit confused:
> when a negedge event on the reset is inserted in the sensitivity list,
> then it would
> look like the following, right?
>
> ############## case 1 ###########
>
>       if reset:
>
> -->> conversion to vhdl works but would be the wrong value for the negedge
> event. right?
>
>
>
> ############## case 2 ###########
>
>       if not reset:
>
> -->> conversion to vhdl fails, with: Error:  No proper edge value test
>
>
> ############## case 3 ###########
>
>       if reset== False:
>
> -->> conversion to vhdl fails, with: Error:    No proper edge value test
>
>
> ############## case 4 ###########
>
>       if reset== bool(0):
>
> -->> conversion to vhdl fails, with: Error:    No proper edge value test
>
>
> ############## case 5 ###########
>
>       if reset==0:
>
> -->> The working version !!
>
>
> greetings
> Norbo
>
>

Correct, if we create an example(s):

    @always(clock.posedge, reset.negedge)
    def hdl():
       if reset == False:
       ...

The only version that appears to convert with 0.8 is the
/reset == 0/?  That seems wrong?  I will have to try 0.7
and think about this a little more.  Will need to get a
bunch of caffeine for tonight :)  Unless anyone else has
some insight?

The results from the code snip below (same as Norbo's):

    1 = /if not reset/
    2 = /reset == False/
    3 = /reset == bool(0)
    4 = /reset == 0/

    1 error vhdl in file tb_ifnot.py, line 8:
        No proper edge value test
    2 error vhdl in file tb_ifnot.py, line 17:
        No proper edge value test
    3 error vhdl in file tb_ifnot.py, line 26:
        No proper edge value test
    4 converted vhdl

    1 converted verilog
    2 converted verilog
    3 converted verilog
    4 converted verilog


Regards,
Chris

~~~ Code Snip ~~~
from myhdl import *
import subprocess

def ifnot_1(clock,reset,a,b):
     @always(clock.posedge, reset.negedge)
     def hdl():
         if not reset:
             b.next = False
         else:
             b.next = not a
     return hdl

def ifnot_2(clock,reset,a,b):
     @always(clock.posedge, reset.negedge)
     def hdl():
         if reset == False:
             b.next = False
         else:
             b.next = not a
     return hdl

def ifnot_3(clock,reset,a,b):
     @always(clock.posedge, reset.negedge)
     def hdl():
         if reset == bool(0):
             b.next = False
         else:
             b.next = not a
     return hdl

def ifnot_4(clock,reset,a,b):
     @always(clock.posedge, reset.negedge)
     def hdl():
         if reset == 0:
             b.next = False
         else:
             b.next = not a
     return hdl

def tb_ifnot():
     clock,reset = [Signal(bool(0)) for ii in range(2)]
     a = Signal(bool(0))
     b = [Signal(bool(0)) for ii in range(4)]

     tb_dut = [None for ii in range(4)]
     #b1,b2,b3,b4 = b  # no LoS ports
     tb_dut[0] = ifnot_1(clock,reset,a,b[0])
     tb_dut[1] = ifnot_2(clock,reset,a,b[1])
     tb_dut[2] = ifnot_3(clock,reset,a,b[2])
     tb_dut[3] = ifnot_4(clock,reset,a,b[3])

     @always(delay(2))
     def tb_clk():
         clock.next = not clock

     @instance
     def tb_stim():
         print('start')
         reset.next = False
         yield delay(10)
         for ii in range(4):
             assert b[ii] == False

         reset.next = True
         yield delay(10)
         for ii in range(4):
             assert b[ii] == (not a)
         print('end')

         raise StopSimulation

     return tb_clk, tb_stim, tb_dut

def convert_vhdl():
     clock,reset = [Signal(bool(0)) for ii in range(2)]
     a = Signal(bool(0))
     b = [Signal(bool(0)) for ii in range(4)]
     b1,b2,b3,b4 = b

     try:
         toVHDL(ifnot_1,clock,reset,a,b1)
         print('1 converted vhdl')
     except Exception, err:
         print('1 error vhdl %s' % (err))

     try:
         toVHDL(ifnot_2,clock,reset,a,b2)
         print('2 converted vhdl')
     except Exception, err:
         print('2 error vhdl %s' % (err))

     try:
         toVHDL(ifnot_3,clock,reset,a,b3)
         print('3 converted vhdl')
     except Exception, err:
         print('3 error vhdl %s' % (err))

     try:
         toVHDL(ifnot_4,clock,reset,a,b4)
         print('4 converted vhdl')
     except Exception, err:
         print('4 error vhdl %s' % (err))

def convert_verilog():
     clock,reset = [Signal(bool(0)) for ii in range(2)]
     a = Signal(bool(0))
     b = [Signal(bool(0)) for ii in range(4)]
     b1,b2,b3,b4 = b

     try:
         toVerilog(ifnot_1,clock,reset,a,b1)
         print('1 converted verilog')
     except Exception, err:
         print('1 error verilog %s' % (err))

     try:
         toVerilog(ifnot_2,clock,reset,a,b2)
         print('2 converted verilog')
     except Exception, err:
         print('2 error verilog %s' % (err))

     try:
         toVerilog(ifnot_3,clock,reset,a,b3)
         print('3 converted verilog')
     except Exception, err:
         print('3 error verilog %s' % (err))

     try:
         toVerilog(ifnot_4,clock,reset,a,b4)
         print('4 converted verilog')
     except Exception, err:
         print('4 error verilog %s' % (err))

if __name__ == '__main__':
     Simulation(tb_ifnot()).run()
     convert_vhdl()
     convert_verilog()
     toVHDL(tb_ifnot)
     subprocess.check_call('vcom pck_myhdl_08.vhd tb_ifnot.vhd', shell=True)
     subprocess.check_call('vsim -c -do -t 1ns run.do work.tb_ifnot', 
shell=True)
~~~~~~~~~~~~~~~~~

Re: [myhdl-list] VHDL Conversion Errors

[Thomas H. <th...@ct...>]

Am 23.01.2013 03:38, schrieb Christopher Felton:
>
> Let me try and summarize, we believe we have encountered
> three different VHDL conversion errors.
>
>      1. bitwise multiplication (there was the wider
>      question if the types were correct but since the ops
>      were invalid it was a moot point).
>
>      2. An odd intbv(val) == bool(val) comparison error,
>      python allows this check (what is the rule?) but when
>      converted the mixed types is not a valid comparison?
>
>      3. More than two operand math operations and resizing.
>
> On the #2 issues, since the MyHDL simulation != VHDL
> simulation, does this constitute an error, not sure?

Same for +3.

It would be nice to hear some 'official words' on that from Jan.

>
> Now, the best way to keep track of these so we don't loose
> track of them?

The general answer to this, of course, is to submit an item into
the tracker (after discussion in this newsgroup).

Thomas

Re: [myhdl-list] VHDL Conversion Errors

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

On 1/24/2013 1:58 AM, Thomas Heller wrote:
> Am 23.01.2013 03:38, schrieb Christopher Felton:
>>
>> Let me try and summarize, we believe we have encountered
>> three different VHDL conversion errors.
>>
>>       1. bitwise multiplication (there was the wider
>>       question if the types were correct but since the ops
>>       were invalid it was a moot point).
>>
>>       2. An odd intbv(val) == bool(val) comparison error,
>>       python allows this check (what is the rule?) but when
>>       converted the mixed types is not a valid comparison?
>>
>>       3. More than two operand math operations and resizing.
>>
>> On the #2 issues, since the MyHDL simulation != VHDL
>> simulation, does this constitute an error, not sure?
>
> Same for +3.
>
> It would be nice to hear some 'official words' on that from Jan.
>

Yes of course, but we can help quite a bit by generating
unit tests (I think I have all these) and suggesting possible
fixes and/or reasons whey we think the *issues* we are observing
should be supported.

It is common for most of us, that our responsibilities fluctuate,
hence we are busier at certain times than others.  I think we can
help keep the ball moving forward by organizing these issues.

>>
>> Now, the best way to keep track of these so we don't loose
>> track of them?
>
> The general answer to this, of course, is to submit an item into
> the tracker (after discussion in this newsgroup).

The only question, the sourceforge tracker has never been used
(best of my knowledge).  Do we use the sourceforge tracker or ???

Regards,
Chris Felton

Re: [myhdl-list] VHDL Conversion Errors

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

Am 23.01.2013, 20:15 Uhr, schrieb Christopher Felton
<chr...@gm...>:

> On 1/23/2013 10:35 AM, Norbo wrote:
>>> On the #2 issues, since the MyHDL simulation != VHDL
>>> simulation, does this constitute an error, not sure?  I
>>> had a similar issue, I often used:
>>>
>>>          if reset:
>>>
>>> The myhdl simulation worked and Verilog conversion worked
>>> but the VHDL did not, the fix was to explicitly state:
>>>
>>>          if reset == False:
>>>
>>> Even though there was a simulation mismatch it was suggested
>>> that the "reset == False", is the desired form.  I am not sure
>>> if the mixed type comparison should be converted?  Instead, we
>>> probably want the converter to raise a conversion exception and
>>> not convert the code.
>>
>> i am a bit confused:
>> when a negedge event on the reset is inserted in the sensitivity list,
>> then it would
>> look like the following, right?
>>
>> ############## case 1 ###########
>>
>>       if reset:
>>
>> -->> conversion to vhdl works but would be the wrong value for the  
>> negedge
>> event. right?
>>
>>
>>
>> ############## case 2 ###########
>>
>>       if not reset:
>>
>> -->> conversion to vhdl fails, with: Error:  No proper edge value test
>>
>>
>> ############## case 3 ###########
>>
>>       if reset== False:
>>
>> -->> conversion to vhdl fails, with: Error:    No proper edge value test
>>
>>
>> ############## case 4 ###########
>>
>>       if reset== bool(0):
>>
>> -->> conversion to vhdl fails, with: Error:    No proper edge value test
>>
>>
>> ############## case 5 ###########
>>
>>       if reset==0:
>>
>> -->> The working version !!
>>
>>
>> greetings
>> Norbo
>>
>>
>
> Correct, if we create an example(s):
>
>     @always(clock.posedge, reset.negedge)
>     def hdl():
>        if reset == False:
>        ...
>
> The only version that appears to convert with 0.8 is the
> /reset == 0/?  That seems wrong?  I will have to try 0.7
> and think about this a little more.  Will need to get a
> bunch of caffeine for tonight :)  Unless anyone else has
> some insight?
>
> The results from the code snip below (same as Norbo's):
>
>     1 = /if not reset/
>     2 = /reset == False/
>     3 = /reset == bool(0)
>     4 = /reset == 0/
>
>     1 error vhdl in file tb_ifnot.py, line 8:
>         No proper edge value test
>     2 error vhdl in file tb_ifnot.py, line 17:
>         No proper edge value test
>     3 error vhdl in file tb_ifnot.py, line 26:
>         No proper edge value test
>     4 converted vhdl
>
>     1 converted verilog
>     2 converted verilog
>     3 converted verilog
>     4 converted verilog
>


The following is the result for an example which looks like this (when the
if is used in a combinatorical statement and
not as a reset):

       @always_comb
       def read():
         if reset==False:
	......
         else:
           ....


        1 = /if not reset/
        2 = /reset == False/
        3 = /reset == bool(0)/
        4 = /reset == 0/
        5 = /reset == intbv(0)/

       simulation:
	all pass

       vhdl:
        1 converted vhdl, ok
        2 converted vhdl, ok
        3 converted vhdl, ok
        4 converted vhdl, ok
        5 converted vhdl, no warning given, converted code is not correct.



here is the code:
#####################################

   from myhdl import *
def selecttry_1(reset,dout):
       @always_comb
       def read():
         if not reset:
	dout.next=5
         else:
           dout.next=6
       return read

def selecttry_2(reset,dout):
       @always_comb
       def read():
         if reset==False:
	dout.next=5
         else:
           dout.next=6
       return read

def selecttry_3(reset,dout):
       @always_comb
       def read():
         if reset==bool(0):
	dout.next=5
         else:
           dout.next=6
       return read


def selecttry_4(reset,dout):
       @always_comb
       def read():
         if reset==0:
	dout.next=5
         else:
           dout.next=6
       return read

def selecttry_5(reset,dout):
       @always_comb
       def read():
         if reset==intbv(0):
	dout.next=5
         else:
           dout.next=6
       return read

cases=[globals()[x] for x in dir() if "selecttry_" in x]


### simulating all cases
for func in cases:
     def testbench():
       sel=Signal(bool(0))
       dout=Signal(intbv(0)[8:])
       dut_inst=func(sel,dout)

       @instance
       def tb_stim():
           print 'Start sim of:',func.func_name,
           sel.next = False
           yield delay(10)
           assert dout==5
           sel.next = True
           yield delay(10)
           assert dout==6

           print ' sim completed'

           raise StopSimulation

       return dut_inst, tb_stim

     Simulation(testbench()).run()


## converting to VHDL with bool as select signal
sel=Signal(bool(0))
dout=Signal(intbv(0)[8:])
for index, func in enumerate(cases):
     try:
       toVHDL(func,sel,dout)
       print "Converting ",func.func_name, " completed"
     except:
       print "Error in ", func.func_name


greetings
Norbo

Re: [myhdl-list] VHDL Conversion Errors

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

<snip>
>
>          1 = /if not reset/
>          2 = /reset == False/
>          3 = /reset == bool(0)/
>          4 = /reset == 0/
>          5 = /reset == intbv(0)/
>
>         simulation:
> 	all pass
>
>         vhdl:
>          1 converted vhdl, ok
>          2 converted vhdl, ok
>          3 converted vhdl, ok
>          4 converted vhdl, ok
>          5 converted vhdl, no warning given, converted code is not correct.

Norbo, thanks for posting this.  I think we got
a little off track with this "issue", which I don't
think is an issue.  The errors we were seeing were with
the special case of *reset*.  As you demonstrated the
different conditional statements work fine (except case 5).
It is only the *reset* case that raises some questions with
VHDL conversion or more generally an edge sensitive signal
other than a clock.

In the manual [1] Jan calls out /reset == 0/.  I think this
is ok to require this for the reset cases.  It can be an
enhancement to add /reset == False/ but I don't think it
is a bug and I think it would be low priority enhancement.
Since the four cases work fine in the other uses, I don't
see the *reset* case being much worry, especially since we
can use the /@always_seq/ with the latest 0.8dev.

I had created some tests [2] and added combinatorial and
sequential conditionals.  As discussed all four cases
convert unless used as a reset, reset has to be explicitly
/reset == 0/ or /reset == 1/ (or use @always_seq).

The last case , case 5, I think will fall under the general
mixing of /bool/ and /intbv[1:]/.  I am going to remove the
conditional from the short list of bugs that I am keeping.

Here is the summary from the tests I ran and can be found
at [2].  Like I said, I think we should remove this one
from the "bug" list (low priority and is document how
the modeling is expected).  The biggest issue would be
the mismatch in MyHDL simulation and Verilog conversion.
My cases are the same as you enumerated, we could have
removed case 3 it is the same as 2.

    myhdl   :test_ifnot_comb_1: success
    ghdl    :test_ifnot_comb_1: success
    icarus  :test_ifnot_comb_1: success

    myhdl   :test_ifnot_comb_2: success
    ghdl    :test_ifnot_comb_2: success
    icarus  :test_ifnot_comb_2: success

    myhdl   :test_ifnot_comb_3: success
    ghdl    :test_ifnot_comb_3: success
    icarus  :test_ifnot_comb_3: success

    myhdl   :test_ifnot_comb_4: success
    ghdl    :test_ifnot_comb_4: success
    icarus  :test_ifnot_comb_4: success

    myhdl   :test_ifnot_comb_5: success
    ghdl    :test_ifnot_comb_5: failed
    icarus  :test_ifnot_comb_5: success

    myhdl   :test_ifnot_reset_1: success
    ghdl    :test_ifnot_reset_1: failed
    icarus  :test_ifnot_reset_1: success

    myhdl   :test_ifnot_reset_2: success
    ghdl    :test_ifnot_reset_2: failed
    icarus  :test_ifnot_reset_2: success

    myhdl   :test_ifnot_reset_3: success
    ghdl    :test_ifnot_reset_3: failed
    icarus  :test_ifnot_reset_3: success

    myhdl   :test_ifnot_reset_4: success
    ghdl    :test_ifnot_reset_4: success
    icarus  :test_ifnot_reset_4: success

    myhdl   :test_ifnot_reset_5: success
    ghdl    :test_ifnot_reset_5: failed
    icarus  :test_ifnot_reset_5: success

    myhdl   :test_ifnot_seq_1: success
    ghdl    :test_ifnot_seq_1: success
    icarus  :test_ifnot_seq_1: success

    myhdl   :test_ifnot_seq_2: success
    ghdl    :test_ifnot_seq_2: success
    icarus  :test_ifnot_seq_2: success

    myhdl   :test_ifnot_seq_3: success
    ghdl    :test_ifnot_seq_3: success
    icarus  :test_ifnot_seq_3: success

    myhdl   :test_ifnot_seq_4: success
    ghdl    :test_ifnot_seq_4: success
    icarus  :test_ifnot_seq_4: success

    myhdl   :test_ifnot_seq_5: success
    ghdl    :test_ifnot_seq_5: failed
    icarus  :test_ifnot_seq_5: success

Regards,
Chris

[1] http://www.myhdl.org/doc/current/manual/modeling.html#sequential-logic

[2] 
https://bitbucket.org/cfelton/myhdl_tests/src/tip/test_ifnot.py?at=default

Re: [myhdl-list] VHDL Conversion Errors

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

On 1/26/13 8:30 PM, Christopher Felton wrote:
> <snip>
>>
>>           1 = /if not reset/
>>           2 = /reset == False/
>>           3 = /reset == bool(0)/
>>           4 = /reset == 0/
>>           5 = /reset == intbv(0)/
<snip>
>
> Norbo, thanks for posting this.  I think we got
> a little off track with this "issue", which I don't
> think is an issue.  The errors we were seeing were with
> the special case of *reset*.  As you demonstrated the
> different conditional statements work fine (except case 5).
> It is only the *reset* case that raises some questions with
> VHDL conversion or more generally an edge sensitive signal
> other than a clock.
>
> In the manual [1] Jan calls out /reset == 0/.  I think this
> is ok to require this for the reset cases.  It can be an
> enhancement to add /reset == False/ but I don't think it
> is a bug and I think it would be low priority enhancement.
> Since the four cases work fine in the other uses, I don't
> see the *reset* case being much worry, especially since we
> can use the /@always_seq/ with the latest 0.8dev.
>

Here is Jan's earlier response on this topic:
http://article.gmane.org/gmane.comp.python.myhdl/2773/match=logical+interpretation

Regards,
Chris

Re: [myhdl-list] Bug in generated code?

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

On 01/17/2013 11:23 PM, Thomas Heller wrote:
> Am 17.01.2013 17:26, schrieb Tom Dillon:
>> Hi,
>>
>> This is interesting but I don't think it would be a bug. I am not sure
>> the MyHDL specs call for automatic size conversions.
>
> I'd say it is a bug, because the generated VHDL code behaves differently
> than the MyHDL simulation.

That is correct - no excuses. If the conversion succeeds, the VHDL
should be have as the VHDL, otherwise it's a bug.

Of course, this doesn't mean that it would be easy to fix :-)

However, I think the issue you reported is fixed now in development.

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] Bug in generated code?

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

On 02/24/2013 09:51 PM, Jan Decaluwe wrote:
> On 01/17/2013 11:23 PM, Thomas Heller wrote:
>> Am 17.01.2013 17:26, schrieb Tom Dillon:
>>> Hi,
>>>
>>> This is interesting but I don't think it would be a bug. I am not sure
>>> the MyHDL specs call for automatic size conversions.
>>
>> I'd say it is a bug, because the generated VHDL code behaves differently
>> than the MyHDL simulation.
>
> That is correct - no excuses. If the conversion succeeds, the VHDL
> should be have as the VHDL

Of course, I meant that the VHDL should behave like the MyHDL :-)


-- 
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] Bug in generated code?

[Thomas H. <th...@ct...>]

Am 24.02.2013 21:51, schrieb Jan Decaluwe:
> On 01/17/2013 11:23 PM, Thomas Heller wrote:
>> Am 17.01.2013 17:26, schrieb Tom Dillon:
>>> Hi,
>>>
>>> This is interesting but I don't think it would be a bug. I am not sure
>>> the MyHDL specs call for automatic size conversions.
>>
>> I'd say it is a bug, because the generated VHDL code behaves differently
>> than the MyHDL simulation.
>
> That is correct - no excuses. If the conversion succeeds, the VHDL
> should be have as the VHDL, otherwise it's a bug.
>
> Of course, this doesn't mean that it would be easy to fix :-)
>
> However, I think the issue you reported is fixed now in development.

Thanks, Jan, for confirming that my understanding of MyHDL is correct.
And thanks for fixing the problem of course.  I'll try it out when I get
back to my project again.

Thomas