myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] Re: Problems inferring RAM when it is buried in system

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

Hi Jan,

         I am using the free Xilinx ISE 
WebPACK(http://www.xilinx.com/ise/logic_design_prod/webpack.htm). The 
latest version is 7.1.04i (which is what I am using). I would recommend 
installing it, even if you don't use a Xilinx part at the moment. You 
can choose to only synthesize (right click the Synthesize-XST item in 
the list of processes and select Run) and see what is being inferred 
when you view the synthesis report in the Design Summary. You don't need 
to do any other steps of the FPGA implementation. You probably need my 
device stats. I am using the xc3s1000 device, speed grade -4, package 
type ft256. You can see the templates that ISE looks for when inferring 
components if you select the menu Edit->Language Templates.

And yes, I was having the same problem with the shift register you 
showed me in a previous email. It would infer on a standalone example, 
but not if it was buried inside my system.

The warning I get is:

 "INFO:Xst:738 - HDL ADVISOR - 2048 flip-flops were inferred for signal 
<_S65X81_0_S65X81_0_0_mem>. You may be trying to describe a RAM in a way 
that is incompatible with block and distributed RAM resources available 
on Xilinx devices, or with a specific template that is not supported. 
Please review the Xilinx resources documentation and the XST user manual 
for coding guidelines. Taking advantage of RAM resources will lead to 
improved device usage and reduced synthesis time."

Even though my small example doesn't necessarily prove my statement, I 
have been watching the Synthesis Report when I synthesize my entire 
system, and no Distributed RAMs or shift registers are inferred. But 
they are inferred when I try synthesizing trivial examples. I'd like to 
provide you with a more complete example. Is there something specific 
you'd like to see? This is a crucial feature and I've come so far with 
myHDL already, thanks to your good work. I'd like to help you get it 
working.

Thanks,
George

> George Pantazopoulos wrote:
>
>> However, Xilinx ISE fails to infer a Distributed RAM if the ram logic 
>> is buried in the system (input/output ports not exposed at top level).
>
>
> That's quite surprizing, because I don't see the technical
> reason behind it, and it would also severely restrict the usefulness
> of the RAM inference feature. I assume other kinds of embedded
> structures are inferred properly (counters, shift registers ...)
>
> Now, I don't have Xilinx installed so I can't experiment myself. BTW, is
> this something that I could check with the free version? In that
> case, I'll install it here.
>
> Can other Xilinx users confirm this, perhaps with other (more recent?)
> ise versions, before we start looking for workarounds?
>
> Note that the small example you give doesn't prove your statement
> above: it merely shows that RAM inference fails when the output
> port is not connected at all. (In fact, I would have expected
> that the synthesis tool removes all logic in that case.)
> But I assume that the RAM output is properly connected in the
> embedded case, because otherwize the Verilog convertor would
> have turned it into an output.
>
> Jan
>

[myhdl-list] Re: Problems inferring RAM when it is buried in system

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

George Pantazopoulos wrote:

> However, Xilinx ISE fails to infer a Distributed RAM if the ram logic is 
> buried in the system (input/output ports not exposed at top level).

That's quite surprizing, because I don't see the technical
reason behind it, and it would also severely restrict the usefulness
of the RAM inference feature. I assume other kinds of embedded
structures are inferred properly (counters, shift registers ...)

Now, I don't have Xilinx installed so I can't experiment myself. BTW, is
this something that I could check with the free version? In that
case, I'll install it here.

Can other Xilinx users confirm this, perhaps with other (more recent?)
ise versions, before we start looking for workarounds?

Note that the small example you give doesn't prove your statement
above: it merely shows that RAM inference fails when the output
port is not connected at all. (In fact, I would have expected
that the synthesis tool removes all logic in that case.)
But I assume that the RAM output is properly connected in the
embedded case, because otherwize the Verilog convertor would
have turned it into an output.

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] Problems inferring RAM when it is buried in system

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

Hi Jan,

    Your trivial example of mapping a list of signals to a RAM memory 
successfully infers a Distributed RAM under myHDL 0.5a1 and Xilinx ISE 
7.1.04i:

def RAM(dout, din, addr, we, clk, depth=128):
    """  Ram model """
    
    mem = [Signal(intbv(0)[8:]) for i in range(depth)]
 
    @always(clk.posedge)
    def write():
        if we:
            mem[int(addr)].next = din
                
    @always_comb
    def read():
        dout.next = mem[int(addr)]
        
    return write, read


However, Xilinx ISE fails to infer a Distributed RAM if the ram logic is 
buried in the system (input/output ports not exposed at top level).

In my system, I have a UART (in myHDL) that feeds a RAM bank, such that 
the RAM bank is not accessible directly from the outside world.
I have boiled down the resulting Verilog code to just the code necessary 
to show the problem.

Xilinx ISE infers a Distributed RAM successfully from the Verilog code I 
pasted below. However, merely commenting out the lines that bring 
data_out to the top level causes ISE to fail to infer a Distributed RAM. 
It wrongly creates 2048 flip-flops and prints a warning. Because my RAM 
bank needs to be hidden within the system, I can not have data_in or 
data_out listed as an input and output, respectively, at the module level.

Besides the possibility of a myHDL problem, am I going about things 
wrong? All my work in myHDL so far has resulted in a single module( ); 
section in the verilog code. Do I need to somehow make multiple modules?

module Synth_plus_UART_BUG (
    sysclk,
    RxD,
    TxD,
    RxD_led,
    audio_out,
    debug_out,
    data_in,
    data_out,   // commenting this out causes RAM inference to fail
);

input sysclk;
input RxD;
output TxD;
reg TxD;
output RxD_led;
reg RxD_led;
output audio_out;
reg audio_out;
output [7:0] debug_out;
reg [7:0] debug_out;

input data_in;
output data_out;   // commenting this out causes RAM inference to fail

reg [7:0] addr;


reg we;

wire [7:0] data_out;

reg [7:0] _S65X81_0_rbank [0:32-1];
reg [7:0] _S65X81_0_S65X81_0_0_mem [0:256-1];

always @(posedge sysclk) begin: _Synth_plus_UART_BUG_S65X81_0_RAM_0_write
    if (we) begin
        _S65X81_0_S65X81_0_0_mem[addr] <= data_in;
    end
end


assign data_out = _S65X81_0_S65X81_0_0_mem[addr];


endmodule

Re: [myhdl-list] 0.5a1

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

George Pantazopoulos wrote:
> 
> Hi Guenter,
> 
> How did you go about removing your old version?
> 
> Thanks,
> George
> 

My python packages are in:

   /usr/lib/python/site-packages

To delete it I go as su in that folder and do:

  rm -rf myhdl

This will remove the installed package.

But to be safe and maybe keep it in case you want to switch back, you 
could just rename it.

   mv myhdl myhdl_old

as an example.

Now the myhdl folder is gone and you can install the new version from 
scratch.

I don't know whether there are better ways to do it. This worked always 
for me.


Cheers,

Guenter

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