myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] 0.5a1

[George P. <ge...@ga...>]

Hi Guenter,

How did you go about removing your old version?

Thanks,
George

> Günter Dannoritzer wrote:
>
>> Jan,
>>
>> I was just running some test code I had under 0.5a1 and when 
>> traceSignal gets imported in __init__.py I am getting an exception.
>
>
> I take that back. I installed the snapshot over my old version and 
> somehow that messed up.
>
> Removing the old version and installing it again it worked just fine.
>
> Cheers,
>
> Guenter
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log 
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] 0.5a1

[<dan...@we...>]

Günter Dannoritzer wrote:
> Jan,
> 
> I was just running some test code I had under 0.5a1 and when traceSignal 
> gets imported in __init__.py I am getting an exception.

I take that back. I installed the snapshot over my old version and 
somehow that messed up.

Removing the old version and installing it again it worked just fine.

Cheers,

Guenter

Re: [myhdl-list] 0.5a1

[<dan...@we...>]

Jan,

I was just running some test code I had under 0.5a1 and when traceSignal 
gets imported in __init__.py I am getting an exception.

It seems to miss now _findInstanceName in _extractHierarchy.py.

Here is a trace back:

Traceback (most recent call last):
   File "./test_stability.py", line 9, in ?
     from myhdl import Simulation,Cosimulation,toVerilog,StopSimulation
   File "/usr/lib/python2.4/site-packages/myhdl/__init__.py", line 111, in ?
     from _traceSignals import traceSignals
   File "/usr/lib/python2.4/site-packages/myhdl/_traceSignals.py", line 
39, in ?
     from myhdl._extractHierarchy import _findInstanceName, _HierExtr
ImportError: cannot import name _findInstanceName


I did a diff between 1.12 and 1.18 of _extractHierarchy.py and the 
_findInstanceName function seems to be deleted, but the _traceSignals.py 
file still imports it.


Guenter




Jan Decaluwe wrote:
> Hi:
> 
> I have just put the an alpha release for MyHDL 0.5
> on the website - 0.5a1.
> 
> This signals that I have implemented all features and
> all verification code planned for 0.5. So we are now
> in bugfix mode - anyone willing to test things out
> is very welcome.
> 
> I have brought the whatsnew document up-to-date.
> 
> I will now concentrate on the documentation, making a
> full pass over the manual to prepare a release candidate.
> 
> Regards,
> 
> Jan
> 

[myhdl-list] 0.5a1

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

Hi:

I have just put the an alpha release for MyHDL 0.5
on the website - 0.5a1.

This signals that I have implemented all features and
all verification code planned for 0.5. So we are now
in bugfix mode - anyone willing to test things out
is very welcome.

I have brought the whatsnew document up-to-date.

I will now concentrate on the documentation, making a
full pass over the manual to prepare a release candidate.

Regards,

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] Re: Shift register in myHDL

[George P. <ge...@ga...>]

Update: Using concatenation proved to be the answer!
The following myHDL (0.5dev5) code snippet (only inner generator shown) 
successfully produced Verilog that was inferred as a shift register by 
Xilinx ISE 7.1.04i:


    @always(clk.posedge, reset.negedge)
    def SRProcess():

        if reset == ACTIVE_LOW:
            reg.next = 0
            parallelOut.next = 0
        else:
            reg.next = concat(serialIn, reg[WIDTH:1])
            if firstBit: # pulse indicating first input bit of a word
                parallelOut.next = reg

    return instances()


Regards,
George

Re: [myhdl-list] Re: Shift register in myHDL

[George P. <ge...@ga...>]

Hi Jan,
 
   This example I coded straight in Verilog seems to do what I want (a 
Serial-in, Parallel-out right-shift register). Xilinx ISE infers an 
8-bit shift register from the following Verilog code. Now the question 
is, how to get myHDL to produce this code :)

module Shifter (C, SI, PO);
  input C, SI;
  output PO;

  reg [7:0] tmp;
  reg [7:0] PO;

  always @(posedge C)
  begin
    tmp = {SI, tmp[7:1]};
  end

  always@(posedge C)
  begin
     PO = tmp;
  end
endmodule


> Hi Jan,
>
>    The example code does not seem to produce Verilog that Xilinx ISE 
> 7.1.04i recognizes as a shift register template. Some online resources 
> as well as the Xilinx ISE templates I looked at seem to do the 
> shifting in one line of Verilog. They mostly have a line similar to 
> the snippet below:
>
>      begin
>        tmp = {tmp[6:0], SI};
>      end
>
> I've attached the myHDL shift_reg, its output Verilog, and a Verilog 
> code sample I found on the net.
>
> Thanks,
> George
>
>
> ----------------------------------------------------
> Begin shift_reg_test.py
> ----------------------------------------------------
>
> from myhdl import *
>
> ACTIVE_LOW = 0
>
> WIDTH = 8
> parallelOut = Signal(intbv(0)[WIDTH:])
> serialIn = Signal(bool(0))
> firstBit = Signal(bool(0))
> clk = Signal(bool(0))
> reset = Signal(bool(1))
> def ShiftReg(clk, WIDTH, reset, firstBit, serialIn, parallelOut):
>
>    reg = Signal(intbv(0)[WIDTH:])
>
>    @always(clk.posedge, reset.negedge)
>    def SRProcess():
>
>        if reset == ACTIVE_LOW:
>            reg.next = 0
>            parallelOut.next = 0
>        else:
>            reg.next[WIDTH:1] = reg[WIDTH-1:]
>            reg.next[0] = serialIn
>            if firstBit: # pulse indicating first input bit of a word
>                parallelOut.next = reg
>
>    return instances()
>
>
> toVerilog.name = "shift_reg"
> SHIFT_REG_0 = toVerilog(ShiftReg, clk, WIDTH, reset, firstBit, 
> serialIn, parallelOut)
> ----------------------------------------------------
> End shift_reg_test.py
> ----------------------------------------------------
>
> ----------------------------------------------------
> Begin shift_reg.v
> ----------------------------------------------------
> module shift_reg (
>    clk,
>    reset,
>    firstBit,
>    serialIn,
>    parallelOut
> );
>
> input clk;
> input reset;
> input firstBit;
> input serialIn;
> output [7:0] parallelOut;
> reg [7:0] parallelOut;
>
> reg [7:0] reg;
>
>
> always @(posedge clk or negedge reset) begin: _shift_reg_SRProcess
>    if ((reset == 0)) begin
>        reg <= 0;
>        parallelOut <= 0;
>    end
>    else begin
>        reg[8-1:1] <= reg[(8 - 1)-1:0];
>        reg[0] <= serialIn;
>        if (firstBit) begin
>            parallelOut <= reg;
>        end
>    end
> end
>
> endmodule
> ----------------------------------------------------
> End shift_reg.v
> ----------------------------------------------------
>
>> From 
>
> http://toolbox.xilinx.com/docsan/3_1i/data/fise/xst/chap02/xst02007.htm 
> I found:
>
>
>      Verilog Code
>
> Following is the Verilog code for an 8-bit shift-left register with a 
> positive-edge clock, asynchronous clear, serial in, and serial out.
>
> module shift (C, CLR, SI, SO);
> input  C,SI,CLR;
> output SO;
> reg [7:0] tmp;
>
>
>  always @(posedge C or posedge CLR)
>  begin
>    if (CLR)
>      tmp = 8'b00000000;
>    else
>      begin
>        tmp = {tmp[6:0], SI};
>      end  end
>  assign SO  = tmp[7];
> endmodule
>
>
> Jan Decaluwe wrote:
>
>> George Pantazopoulos wrote:
>>
>>> Hi all,
>>>
>>>    What is the recommended way of creating a serial-in, parallel out 
>>> shift register in myHDL (for Verilog output)?
>>
>>
>>
>> I would expect to see something similar to this (only local
>> generator shown, untested):
>>
>> @always(clock.posedge, reset.negedge)
>> def shiftreg():
>>     if reset == ACTIVE_LOW:
>>         reg.next = 0
>>         parallelOut.next = 0
>>     else:
>>         reg.next[n:1] = reg[n-1:]
>>         reg.next[0] = serialIn
>>         if firstBit: # pulse indicating first input bit of a word
>>             parallelOut.next = reg
>>
>>
>> Jan
>>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log 
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] Re: Shift register in myHDL

[George P. <ge...@ga...>]

Hi Jan,
 
    The example code does not seem to produce Verilog that Xilinx ISE 
7.1.04i recognizes as a shift register template. Some online resources 
as well as the Xilinx ISE templates I looked at seem to do the shifting 
in one line of Verilog. They mostly have a line similar to the snippet 
below:

      begin
        tmp = {tmp[6:0], SI};
      end 


I've attached the myHDL shift_reg, its output Verilog, and a Verilog 
code sample I found on the net.

Thanks,
George


----------------------------------------------------
Begin shift_reg_test.py
----------------------------------------------------

from myhdl import *

ACTIVE_LOW = 0

WIDTH = 8
parallelOut = Signal(intbv(0)[WIDTH:])
serialIn = Signal(bool(0))
firstBit = Signal(bool(0))
clk = Signal(bool(0))
reset = Signal(bool(1))
def ShiftReg(clk, WIDTH, reset, firstBit, serialIn, parallelOut):

    reg = Signal(intbv(0)[WIDTH:])

    @always(clk.posedge, reset.negedge)
    def SRProcess():

        if reset == ACTIVE_LOW:
            reg.next = 0
            parallelOut.next = 0
        else:
            reg.next[WIDTH:1] = reg[WIDTH-1:]
            reg.next[0] = serialIn
            if firstBit: # pulse indicating first input bit of a word
                parallelOut.next = reg

    return instances()


toVerilog.name = "shift_reg"
SHIFT_REG_0 = toVerilog(ShiftReg, clk, WIDTH, reset, firstBit, serialIn, 
parallelOut)
----------------------------------------------------
End shift_reg_test.py
----------------------------------------------------

----------------------------------------------------
Begin shift_reg.v
----------------------------------------------------
module shift_reg (
    clk,
    reset,
    firstBit,
    serialIn,
    parallelOut
);

input clk;
input reset;
input firstBit;
input serialIn;
output [7:0] parallelOut;
reg [7:0] parallelOut;

reg [7:0] reg;


always @(posedge clk or negedge reset) begin: _shift_reg_SRProcess
    if ((reset == 0)) begin
        reg <= 0;
        parallelOut <= 0;
    end
    else begin
        reg[8-1:1] <= reg[(8 - 1)-1:0];
        reg[0] <= serialIn;
        if (firstBit) begin
            parallelOut <= reg;
        end
    end
end

endmodule
----------------------------------------------------
End shift_reg.v
----------------------------------------------------

From 
http://toolbox.xilinx.com/docsan/3_1i/data/fise/xst/chap02/xst02007.htm 
I found:


      Verilog Code

Following is the Verilog code for an 8-bit shift-left register with a 
positive-edge clock, asynchronous clear, serial in, and serial out.

module shift (C, CLR, SI, SO);
input  C,SI,CLR;
output SO;
reg [7:0] tmp;


  always @(posedge C or posedge CLR)
  begin
    if (CLR)
      tmp = 8'b00000000;
    else
      begin
        tmp = {tmp[6:0], SI};
      end 
  end
  assign SO  = tmp[7];
endmodule


Jan Decaluwe wrote:

> George Pantazopoulos wrote:
>
>> Hi all,
>>
>>    What is the recommended way of creating a serial-in, parallel out 
>> shift register in myHDL (for Verilog output)?
>
>
> I would expect to see something similar to this (only local
> generator shown, untested):
>
> @always(clock.posedge, reset.negedge)
> def shiftreg():
>     if reset == ACTIVE_LOW:
>         reg.next = 0
>         parallelOut.next = 0
>     else:
>         reg.next[n:1] = reg[n-1:]
>         reg.next[0] = serialIn
>         if firstBit: # pulse indicating first input bit of a word
>             parallelOut.next = reg
>
>
> Jan
>

[myhdl-list] Re: Shift register in myHDL

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

George Pantazopoulos wrote:
> Hi all,
> 
>    What is the recommended way of creating a serial-in, parallel out 
> shift register in myHDL (for Verilog output)?

I would expect to see something similar to this (only local
generator shown, untested):

@always(clock.posedge, reset.negedge)
def shiftreg():
     if reset == ACTIVE_LOW:
         reg.next = 0
         parallelOut.next = 0
     else:
         reg.next[n:1] = reg[n-1:]
         reg.next[0] = serialIn
         if firstBit: # pulse indicating first input bit of a word
             parallelOut.next = reg


Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] Shift register in myHDL

[George P. <ge...@ga...>]

All, I'm sorry for the double post. I thought my previous email didn't 
get sent by my client. Please reply to this thread and not the previous one.
Thanks,
George


> Hi all,
>
>    What is the recommended way of creating a serial-in, parallel out 
> shift register in myHDL (for Verilog output)?
>
> Thanks,
> George
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log 
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

[myhdl-list] Shift register in myHDL

[George P. <ge...@ga...>]

Hi all,

    What is the recommended way of creating a serial-in, parallel out 
shift register in myHDL (for Verilog output)?

Thanks,
George

[myhdl-list] shift register

[George P. <rob...@ga...>]

Hi all,

      What is the "proper" way to make a serial-in, parallel-out shift 
register in myHDL (with the goal of outputting Verilog)?

Thanks,
George

[myhdl-list] Style based on decorators

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

Hi:

I have decided to proceed with the introduction of decorators
to create local generators in 0.5.

In addition, I would like to make this the default coding style.
In particular, I would change all documentation and examples to
use decorators, including in tutorials. Note that 3 decorators
are introduced: @always, @always_comb, and @instance.

Also, the possibility to use a parametrizable generator directly
would be de-emphasized (but possible, of course). The equivalent
in VHDL/Verilog would be a process/always block with a port
interface, something which doesn't exist. Therefore, this
can be confusing to new users. Instead, one would use a function
that returns a single generator (as many of you do already).
This makes the overall style more consistent: structure is
always specified using a plain function, behavior using
a local generator (created with a decorator).

Note that all of this has no impact on backwards compatibility.

As always, let me know if you disagree.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

[myhdl-list] Re: Asynchronous receiver strange problem

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

George Pantazopoulos wrote:
> Hi all,
> 
> I'm having a strange problem testing my UART in-silico. I don't believe it
> is related to my overall design or myHDL. I'm hoping maybe someone has
> come across this before.
> 

I suggest to seek help on comp.lang.fpga for issues such as this. It's
quite active and I think you have a good chance of getting help.

Of course, you'll have to illustrate the issue using the generated
Verilog, at least for the time being :-)

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] Asynchronous receiver strange problem

[Haitao Z. <ha...@gm...>]

You didn't give much detail on what LEDs are lighting up and what are
not, but anyway this is not a list to debug designs. One thing you
want to consider is how fast you are clocking the shift registers.
Your eyes and the LEDs can't respond to the normal clock rate used in
the digital design. You can only see relatively static signals.

Haitao

On 11/23/05, George Pantazopoulos <ge...@ga...> wrote:
>
> Hi all,
>
> I'm having a strange problem testing my UART in-silico. I don't believe i=
t
> is related to my overall design or myHDL. I'm hoping maybe someone has
> come across this before.
>
> I have verified (in simulation, as well as in hardware using LEDs and my
> o-scope) that my Receiver goes through all the state transitions for an
> incoming serial stream. It even appears to be shifting the correct data
> into the Shift Register.
>
> My Asynchronous Receiver module has an 8-bit debug_out port that I connec=
t
> to 8 LED's on my Digilent Spartan3 FPGA dev board. A DebugProcess
> continually outputs any internal signals I choose to observe.
>
> When I try to display all eight bits of the shift register using the
> debug_out port, no LED's light up on my board. But if I display four of
> the Shift Register bits and four of the state bits, then the LED's light
> up just fine!
>
> In fact, I can even dislay seven of the eight bits correctly, as long as
> the other bit is displaying state (All LED's stay off if I make the
> remaining bit a constant 0). I can reliably reproduce this effect. What i=
n
> the world is going on here?
>
> I'm using the Digilent Spartan3 FPGA dev board, with Xilinx ISE 7.1i on
> Windows XP, with myHDL 0.5dev4.
>
> Changing the drive strength of the FPGA's LED output pins from 12ma to
> 24ma did not help.
>
> ----------------------------------------
> Excerpt from my Receiver design:
> (indentation is not necessarily correct)
> ----------------------------------------
>
> state =3D Signal(intbv(0)[4:])
> shift_reg =3D Signal(intbv(0)[8:])
>
> @always(clk.posedge)
> def DebugProcess():
>
> # This fails to light up any LED's on my dev board
> #    debug_out.next[0] =3D shift_reg[0]
> #    debug_out.next[1] =3D shift_reg[1]
> #    debug_out.next[2] =3D shift_reg[2]
> #    debug_out.next[3] =3D shift_reg[3]
>
> #    debug_out.next[4] =3D shift_reg[4]
> #    debug_out.next[5] =3D shift_reg[5]
> #    debug_out.next[6] =3D shift_reg[6]
> #    debug_out.next[7] =3D shift_reg[7]
>
> # This lights up the LED's ok!
> #    debug_out.next[0] =3D shift_reg[0]
> #    debug_out.next[1] =3D shift_reg[1]
> #    debug_out.next[2] =3D shift_reg[2]
> #    debug_out.next[3] =3D state[3] # NOTE: state here makes it work
>
> #    debug_out.next[4] =3D shift_reg[0]
> #    debug_out.next[5] =3D shift_reg[1]
> #    debug_out.next[6] =3D shift_reg[2]
> #    debug_out.next[7] =3D shift_reg[3]
>
>
> # This lights up the LED's ok also!
>     debug_out.next[0] =3D state[0]
>     debug_out.next[1] =3D state[1]
>     debug_out.next[2] =3D state[2]
>     debug_out.next[3] =3D state[3]
>
>     debug_out.next[4] =3D shift_reg[0]
>     debug_out.next[5] =3D shift_reg[1]
>     debug_out.next[6] =3D shift_reg[2]
>     debug_out.next[7] =3D shift_reg[3]
>
>
> --------------------------------------------
>
> Thanks,
>
> --
> George Pantazopoulos
> http://www.gammaburst.net
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id=16865&opclick
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

[myhdl-list] Asynchronous receiver strange problem

[George P. <ge...@ga...>]

Hi all,

I'm having a strange problem testing my UART in-silico. I don't believe i=
t
is related to my overall design or myHDL. I'm hoping maybe someone has
come across this before.

I have verified (in simulation, as well as in hardware using LEDs and my
o-scope) that my Receiver goes through all the state transitions for an
incoming serial stream. It even appears to be shifting the correct data
into the Shift Register.

My Asynchronous Receiver module has an 8-bit debug_out port that I connec=
t
to 8 LED's on my Digilent Spartan3 FPGA dev board. A DebugProcess
continually outputs any internal signals I choose to observe.

When I try to display all eight bits of the shift register using the
debug_out port, no LED's light up on my board. But if I display four of
the Shift Register bits and four of the state bits, then the LED's light
up just fine!

In fact, I can even dislay seven of the eight bits correctly, as long as
the other bit is displaying state (All LED's stay off if I make the
remaining bit a constant 0). I can reliably reproduce this effect. What i=
n
the world is going on here?

I'm using the Digilent Spartan3 FPGA dev board, with Xilinx ISE 7.1i on
Windows XP, with myHDL 0.5dev4.

Changing the drive strength of the FPGA's LED output pins from 12ma to
24ma did not help.

----------------------------------------
Excerpt from my Receiver design:
(indentation is not necessarily correct)
----------------------------------------

state =3D Signal(intbv(0)[4:])
shift_reg =3D Signal(intbv(0)[8:])

@always(clk.posedge)
def DebugProcess():

# This fails to light up any LED's on my dev board
#    debug_out.next[0] =3D shift_reg[0]
#    debug_out.next[1] =3D shift_reg[1]
#    debug_out.next[2] =3D shift_reg[2]
#    debug_out.next[3] =3D shift_reg[3]

#    debug_out.next[4] =3D shift_reg[4]
#    debug_out.next[5] =3D shift_reg[5]
#    debug_out.next[6] =3D shift_reg[6]
#    debug_out.next[7] =3D shift_reg[7]

# This lights up the LED's ok!
#    debug_out.next[0] =3D shift_reg[0]
#    debug_out.next[1] =3D shift_reg[1]
#    debug_out.next[2] =3D shift_reg[2]
#    debug_out.next[3] =3D state[3] # NOTE: state here makes it work

#    debug_out.next[4] =3D shift_reg[0]
#    debug_out.next[5] =3D shift_reg[1]
#    debug_out.next[6] =3D shift_reg[2]
#    debug_out.next[7] =3D shift_reg[3]


# This lights up the LED's ok also!
    debug_out.next[0] =3D state[0]
    debug_out.next[1] =3D state[1]
    debug_out.next[2] =3D state[2]
    debug_out.next[3] =3D state[3]

    debug_out.next[4] =3D shift_reg[0]
    debug_out.next[5] =3D shift_reg[1]
    debug_out.next[6] =3D shift_reg[2]
    debug_out.next[7] =3D shift_reg[3]


--------------------------------------------

Thanks,

--=20
George Pantazopoulos
http://www.gammaburst.net

[myhdl-list] Feedback on clk.posedge style issue

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

Hi all:

For the 0.5 release, I'm thinking to make a few style changes.

One change involves edge specifiers. In particular, I would like
to suggest the following usage (with 'clk' any kind of signal):

    clk.posedge (instead of posedge(clk))
    clk.negedge (instead of negedge(clk))

No code changes are required: these attributes always existed
and the functions were wrappers around them. Probably I was
thinking to use the functions to make it look more like Verilog,
but now I consider this to be a very weak argument.

The arguments for this style change are, in order of increasing
significance:

- one character less to type
- more object-oriented style
- no brackets, which is better for clarity
- no function call overhead (Function calls are expensive. Note
that these functions may be called over and over again during
simulation.)

To introduce this, I would not touch any MyHDL code in 0.5,
so the functions would remain available. However, they would
be removed from the documentation, and all examples would
be updated to the new style. The functions will be deprecated
and removed in later releases.

If you *disagree*, please respond quickly.

Regards,

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

[myhdl-list] Re: shadowing error

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

George Pantazopoulos wrote:
> Hi Jan,
> 
> I had a module Foo, where I accidentally re-created the signal in_a even 
> though it was already there as an input. As a result, it used the 
> "local" in_a which was fixed to 0, and this resulted in incorrect 
> simulation results. I spent a lot of time debugging before I found my 
> stupid mistake. It would be nice if myHDL gave an error in this situation.
> 
>     def Foo(clk, in_a):
>         in_a = Signal(bool(0)) # should not be here!
> 
>         INST_0 = Bar(clk, in_a, ... )  
>          return INST_0
> 
> 
> Thanks,
> George

I had expected that pychecker would report this case, where
a local assignment shadows a function argument.

But unfortunately, it doesn't. If feel this is a general
Python code issue, so the best way may be to try to get it
into pychecker.

toVerilog does flag this case as an error.

See also my comments on MyHDL code checking in another thread:
very useful, but it will take a while before I can spent time
on it personally.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

[myhdl-list] Re: omiting .next should cause an error

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

George Pantazopoulos wrote:
> Hi Jan,
> 
>    I've often run into the situation where I forget to use .next for a 
> variable, and it produces subtle errors that are hard to detect.
> 
> (eg. doing "count = (count + 1) % 2**COUNTER_WIDTH", rather than doing 
> "count.next = (count + 1) % 2**COUNTER_WIDTH)". I often slip up because 
> I'm very used to programming in C/C++ at work. I feel that myHDL should 
> flag this as an obvious error.

 From a Python point of view, it's not necessarily that obvious. It's a
fact that assignment in Python is very different from other languages,
and this has to be understood for effecive Python (not just MyHDL)
coding. See also:

   http://www.jandecaluwe.com/Tools/MyHDL/manual/conv-meth-assign.html

On the other hand, you are right that with Signals (and intbv's) this
must usually be an unintended error. In fact, toVerilog does flag
such issues (not checked for this case - but it should).
Of course, I can hardly recommend using toVerilog before
simulation, when I usually do the opposite :-)

Anyway, toVerilog shows that it can be done. However, it's
not nessarily straigthforward what would be the best way for
general checking. We should also investigate what we can reuse from
general Python linting tools, such as pychecker.

A MyHDL checker would be very useful, but it's a significant
project. I can't devote time to it in the short term. If
someone is looking for a major contribution ...

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

[myhdl-list] Re: signed arithmetic

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

Jan Decaluwe wrote:
> Hi all:
> 
> I have added support for Verilog conversion of signed arithmetic to the
> development version.

The original approach has been discarded. The new approach is described
here:

 
http://myhdl.jandecaluwe.com/doku.php/whatsnew:0.5#support_for_signed_arithmetic

It is available for testing in 0.5dev5.

The test suite contains more tests, and more cases are covered. Also,
I think the implementation has everything in place to make it a
robust solution. However,  this is tricky stuff and there may still be
cases that fail. You are welcome to try to make it fail!

On the other hand, when this becomes robust, I believe we have
created significant added value for the poor Verilog designer
that tries to get his negative numbers right.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

[myhdl-list] shadowing error

[George P. <ge...@ga...>]

Hi Jan,

I had a module Foo, where I accidentally re-created the signal in_a even 
though it was already there as an input. As a result, it used the 
"local" in_a which was fixed to 0, and this resulted in incorrect 
simulation results. I spent a lot of time debugging before I found my 
stupid mistake. It would be nice if myHDL gave an error in this situation.

     def Foo(clk, in_a):
         in_a = Signal(bool(0)) # should not be here!

         INST_0 = Bar(clk, in_a, ... )   

          return INST_0


Thanks,
George

[myhdl-list] toVHDL page

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

I have a added a web page on VHDL conversion development:

     http://myhdl.jandecaluwe.com/doku.php/tovhdl

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     Electronic design with Python:
     http://myhdl.jandecaluwe.com

[myhdl-list] Re: toVHDL co-simulation

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

Günter Dannoritzer wrote:
> Jan,
> 
> I looked through the myhdl.c code for the Icarus co-simulation,
> searching for the functions and data types used by MyHDL for co-simulation.
> 
> I would like to write them out to the wiki, so that it is documented
> what functions of the PLI are required for MyHDL. That could be used as
> a base to discuss what is needed from a VHDL simulator for co-simulation.
> 
> There is some notion on the GHDL mailing list to go on with the
> development of the existing C-based VPI interface (not the Ada based
> VHPI). If we could show them our requirements, we might be able to
> influence what parts they are implementing. At least we could use it as
> a base to asked whether we could ever expect that functionality from GHDL.
> 
> Should I add the requirements to the toVHDL page you created or make a
> new page specific for that?

I suggest to add a new page (e.g [[vhdl_cosimulation]]) and make it
accessible under the "Development Zone".

> Am I going the wrong way with this?

It's progress, so it's always the right way! To implement VHDL
co-simulation, your efforts will be very helpful, so I suggest
to document your findings while they are still fresh.

However, as you can see from the toVHDL page, I am currently
suggesting to try to find a way to verify without co-simulation.
I am sceptical that we will get VHDL co-simulation to work
as needed any time soon; so for VHDL conversion it would be
helpful if we can do without it.

Thanks and regards,

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     Electronic design with Python:
     http://myhdl.jandecaluwe.com

[myhdl-list] toVHDL co-simulation

[<dan...@we...>]

Jan,

I looked through the myhdl.c code for the Icarus co-simulation,
searching for the functions and data types used by MyHDL for co-simulation.

I would like to write them out to the wiki, so that it is documented
what functions of the PLI are required for MyHDL. That could be used as
a base to discuss what is needed from a VHDL simulator for co-simulation.

There is some notion on the GHDL mailing list to go on with the
development of the existing C-based VPI interface (not the Ada based
VHPI). If we could show them our requirements, we might be able to
influence what parts they are implementing. At least we could use it as
a base to asked whether we could ever expect that functionality from GHDL.

Should I add the requirements to the toVHDL page you created or make a
new page specific for that?

Am I going the wrong way with this?

I appreciate any comments.

Cheers,

Guenter

[myhdl-list] Re: 0.5dev3 testing

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

Hi:

I have put the current approach on hold for reconsideration.

See also my comments:

Tom Dillon wrote:
> Jan,
> 
> I don't like making all signals signed in a design just because you use 
> one signed number somewhere in the design.  Let's say you have a design 
> basically working (with all unsigned numbers) and you need to pull in a 
> module that needs to do a single signed operation, all your signals now 
> grow by a bit, for no good reason. That doesn't seem right to me.

I agree it seems brute-force, but the good reason would be get it right.

My thinking was that it would not be common to have a single, or a
few signed operations - I thought either none, ore lots of them. But I
agree that the scenario you describe is not like that.

Internally in the design, I think the issue is largely psychological
(although that counts) - I don't think there would be any significant
impact on efficiency in synthesis results by adding a sign bit
systematically (if it's needed, you'll be glad it's there, otherwise
a synthesis tool may remove it by logic optimization).

However, at the port level the additional (unexpected) bit may be
disturbing. And perhaps also for special cases like single-bit signals.

> I would prefer to be in control of the bit widths of all signals from 
> the MyHDL source.
> 
> MyHDL simulation really does all math signed, and the only concern it 
> has is that you always assign a number to a variable that is within its 
> min/max range.
> 
> For example, if you do the following with a, b, x all having their _min 
> set to 0,
> 
> x.next = a - b,
> 
> it will work fine until you try it with b > a. Once you try with b > a, 
> you get a MyHDL simulation error and need to fix the problem.  The fix 
> is as a minimum make x._min negative enough to hold all the the results 
> of your simulation. This is no different than the simulation catch a 
> x._max too small.
> 
> The next problem you will run into is anywhere x goes, will also need to 
> be have a similar _min or else the simulation will again flag an error 
> and stop when the assignment occurs that violates the _min. My point is, 
> MyHDL simulation forces proper prorogation of the signed numbers, at 
> least if you do a reasonable simulation. So far this is good with MyHDL 
> providing a very nice means of making sure all your numbers can be 
> contained within all the signals of your design.
> 
> The real trouble comes if only one of a or b are signed and the target 
> is signed. Since the MyHDL simulation will always do the math correctly, 
> it is hard to match the Verilog simulation.  

Interesting statement :-) (I have to remember that one!)

> I would suggest one of the following for this case:
> 
>    1. Do nothing, force a good simulation which will leave some Verilog
>       debugging.

I think what you suggest here is that after conversion, a succesful
MyHDL simulation would not necessarily match the Verilog simulation.

That would definitely be not an option for me. If at all possible, I
want to make sure (ideally guarantee) that the simulations match.
I believe this is the only way to create a level of confidence in
a new tool. Also, it makes it unambiguous where the bug is (that is,
if the simulations don't match, it's a MyHDL bug).

On 2 occasions in the past, I have rejected EDA tools that didn't
follow this approach.

>    2. Locally add a bit to a or b if unsigned and make MSB 0, basically
>       concatenate a 0 during the operation and force the operation to be
>       signed.

That's a valid alternative - a fine-grained approach.

Initially, I was a little overwhelmed by the apparent complexities
in getting this right in Verilog. So I looked for an approach that
would "always" work. Hence the current coarse-grained approach.

However, during implementation, I noticed that this fine-grained
approach might not be too difficult after all. I don't have to
deal with *any* Verilog, only with code that comes from MyHDL.
And this code is structured in a way that may make it not
too hard to do it like that.

So I'll reconsider all this and give it some thinking.

> Another note on signed numbers. I have found that the only way to 
> propagate a negative number through a slice operation is to use a[:n]. 
> That seems to work fine, while slicing from the MSB down doesn't get the 
> negative number passed. This is OK, but maybe a note is needed in the 
> manual on that.

This is modelled after Verilog.
There's a note on this in the reference part on the intbv. I agree
it should be also be mentioned when slicing is introduced.

> What if I want to concat() some bits together to form a signed number (a 
> negative one). For example if I wanted to sign extend a negative number. 
> Normally I would expect this to work (at least in an HDL):
> 
> b.next = concat(a[MSB],a[MSB],a) # with b 2 bits bigger than a.
> 
> But this will always result in a positive number in the MyHDL simulation.

Of course in this case "b.next = a" would work as expected. In general,
I guess manipulating the bits of a signed number would be easiest:

a[:] = -1
a[3:] = .....

Or a sign-extension function.

concat itself returns positive numbers as you note. To me it's a bit
like slicing: when working on a limited number of bits, I think
you're normally not concerned about positive/negative interpretation.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     Electronic design with Python:
     http://myhdl.jandecaluwe.com

[myhdl-list] Re: 0.5dev3 Verilog signal name conflict

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

Thanks for this bug report and the fix. Especially thanks for providing
a small failing example!

I have fixed this (long-standing) bug in 0.5dev4.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     Electronic design with Python:
     http://myhdl.jandecaluwe.com