myhdl-list

[myhdl-list] Constant assignments in co-simulation

[Nikolay K. <nik...@gm...>]

Hi All,

We have a co-simulation issue: when constants are assigned to signals in
co-simulation, the assigned values are not visible in MyHDL.

The issue is demonstrated by the following gist:
https://gist.github.com/nkavaldj/650fafbc3693f7a501e2

The flow we use: MyHDL - > toVerilog -> Icarus

Is there a known workaround?



Regards,

Nikolay

Re: [myhdl-list] Constant assignments in co-simulation

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

On 5/26/2015 7:10 AM, Nikolay Kavaldjiev wrote:
> Hi All,
>
> We have a co-simulation issue: when constants are assigned to signals in
> co-simulation, the assigned values are not visible in MyHDL.

In the example you linked there are two issues that
prevent it from working:  first, the initial values
is not (currently) used in the converted HDL.  The
`b` Signal in `concat_assign` will not be assigned
an initial value of `True`.

Second, you can't use and `always_comb` to assign
a Signal to a constant (as you comments indicate).

>
> The issue is demonstrated by the following gist:
> https://gist.github.com/nkavaldj/650fafbc3693f7a501e2
>
> The flow we use: MyHDL - > toVerilog -> Icarus
>
> Is there a known workaround?

I haven't run into this issue, a workaround would
be to use the constant directly and not create a
constant Signal.

Or use a dummy(ies) Signal in the `always_comb`
to preserve the const assignments.

     d1 = Signal(bool(0))
     d2 = Signal(bool(0))

     @always_comb
     def assign():
	# keep the combinatorial process
         d2.next = d1
	# assign constants
         x1.next = True
         x2.next = 0x55

     return assign

Or you could use the ROM design pattern:
http://docs.myhdl.org/en/latest/manual/conversion_examples.html#rom-inference

Regards,
Chris

Re: [myhdl-list] Constant assignments in co-simulation

[Nikolay K. <nik...@gm...>]

Thanks Chris!

I don't think that preserving the combinatorial assignment is my issue,
because the module I have:


def const_assign(aBit, aByte):

    b = Signal(bool(True)) # to avoid "myhdl.AlwaysCombError:
sensitivity list is empty"

    @always_comb
    def logic():
        aBit.next = b
        aByte.next = 0x55

    return logic


Simulates as expected in MyHDL.

Converts to Vorilog as :

module const_assign (
    aBit,
    aByte
);
output aBit;
wire aBit;
output [7:0] aByte;
wire [7:0] aByte;
wire b;
assign b = 1;
assign aBit = b;
assign aByte = 85;

endmodule


Which to me looks OK.

My problem comes when I do co-simulation with Icarus. Then instead of
observing the expected aBit==True and aByte==0x55, I observe aBit==False
and aByte==0, which are the default values of the MyHDL signals connected
co-simulated module.


The problem disappears when I add a dummy print statement in the
"always_comb":

def const_assign(aBit, aByte):

    b = Signal(bool(True)) # to avoid "myhdl.AlwaysCombError:
sensitivity list is empty"

    @always_comb
    def logic():
        aBit.next = b
        aByte.next = 0x55
        print "something"

    return logic


Then the code converts to:

module const_assign (
    aBit,
    aByte
);
output aBit;
reg aBit;
output [7:0] aByte;
reg [7:0] aByte;
wire b;
assign b = 1;

always @(b) begin: CONST_ASSIGN_LOGIC
    aBit = b;
    aByte = 85;
    $write("something");
    $write("\n");
end

endmodule


And in co-simulation I see what I expect: aBit==True and aByte==0x55


It seam to me that the problem I have is related to the interface between
myhdl and icarus and a verilog statement of the type:

assign output_port = some_constant


I am not sure whether this is an issue with my local setup or it is a myhdl
issue. So to check that, can someone using Icarus, please, try to run on
his machine the gist given earlier. It should be only a matter of single
copy/paste and adjusting the path to myhdl.vpi


Regards,

Nikolay


Nikolay Kavaldjiev

E-mail: nik...@gm...
Mobile: +31 641 820 815
Address: Hogewerf 133, 1082NC, Amsterdam, Netherlands
LinkedIn Profile: http://www.linkedin.com/in/kavaldjiev

On 26 May 2015 at 15:43, Christopher Felton <chr...@gm...> wrote:

> On 5/26/2015 7:10 AM, Nikolay Kavaldjiev wrote:
> > Hi All,
> >
> > We have a co-simulation issue: when constants are assigned to signals in
> > co-simulation, the assigned values are not visible in MyHDL.
>
> In the example you linked there are two issues that
> prevent it from working:  first, the initial values
> is not (currently) used in the converted HDL.  The
> `b` Signal in `concat_assign` will not be assigned
> an initial value of `True`.
>
> Second, you can't use and `always_comb` to assign
> a Signal to a constant (as you comments indicate).
>
> >
> > The issue is demonstrated by the following gist:
> > https://gist.github.com/nkavaldj/650fafbc3693f7a501e2
> >
> > The flow we use: MyHDL - > toVerilog -> Icarus
> >
> > Is there a known workaround?
>
> I haven't run into this issue, a workaround would
> be to use the constant directly and not create a
> constant Signal.
>
> Or use a dummy(ies) Signal in the `always_comb`
> to preserve the const assignments.
>
>      d1 = Signal(bool(0))
>      d2 = Signal(bool(0))
>
>      @always_comb
>      def assign():
>         # keep the combinatorial process
>          d2.next = d1
>         # assign constants
>          x1.next = True
>          x2.next = 0x55
>
>      return assign
>
> Or you could use the ROM design pattern:
>
> http://docs.myhdl.org/en/latest/manual/conversion_examples.html#rom-inference
>
> Regards,
> Chris
>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] Constant assignments in co-simulation

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

On 5/26/2015 10:57 AM, Nikolay Kavaldjiev wrote:
> Thanks Chris!
>
> I don't think that preserving the combinatorial assignment is my issue,
> because the module I have:
<snip>
>
> assign b = 1;
> assign aBit = b;
> assign aByte = 85;
>
>
> Which to me looks OK.

I agree, the conversion look fine.

>
> My problem comes when I do co-simulation with Icarus. Then instead of
> observing the expected aBit==True and aByte==0x55, I observe aBit==False
> and aByte==0, which are the default values of the MyHDL signals connected
> co-simulated module.
>

Ahhh yes, you are trying to Cosimulate a design
that has no inputs.  I forget the particular
reasons but I don't believe it is possible to
Cosimulate such a limited design.
http://docs.myhdl.org/en/latest/manual/cosimulation.html#restrictions

See the example in the documents for a basic
example:
http://docs.myhdl.org/en/latest/manual/cosimulation.html#co-simulation-with-verilog

You shouldn't have any issue Cosimulating a
complete design.

Regards,
Chris

Re: [myhdl-list] Constant assignments in co-simulation

[Nikolay K. <nik...@gm...>]

> Ahhh yes, you are trying to Cosimulate a design
> that has no inputs.  I forget the particular
> reasons but I don't believe it is possible to
> Cosimulate such a limited design.
> http://docs.myhdl.org/en/latest/manual/cosimulation.html#restrictions

To exclude this as a possibility I modified the example module in the gist (
https://gist.github.com/nkavaldj/7cc69372246e64d68f58) to have an input and
I still have the same issue with co-simulation (only with co-simulation).

The modified code:

def const_assign(x, y, aBit, aByte):

    @always_comb
    def logic():
        y.next = x + 5
        aBit.next = True
        aByte.next = 55

    return logic


Converted code:

module const_assign (
    x,
    y,
    aBit,
    aByte
);

input [7:0] x;
output [7:0] y;
wire [7:0] y;
output aBit;
wire aBit;
output [7:0] aByte;
wire [7:0] aByte;

assign y = (x + 5);
assign aBit = 1'b1;
assign aByte = 55;

endmodule



> You shouldn't have any issue Cosimulating a
> complete design.

Actually we have the issue in a large/complete design with plenty of inputs
and outputs. The gist is just a minimalistic example that demonstrates the
issue. We are using myhdl for more that two years now, including
co-simulation, so it should not be a beginners issue. I hit the issue a
week ago, and I cannot move since.


Regards,

Nikolay


On 26 May 2015 at 18:25, Christopher Felton <chr...@gm...> wrote:

> On 5/26/2015 10:57 AM, Nikolay Kavaldjiev wrote:
> > Thanks Chris!
> >
> > I don't think that preserving the combinatorial assignment is my issue,
> > because the module I have:
> <snip>
> >
> > assign b = 1;
> > assign aBit = b;
> > assign aByte = 85;
> >
> >
> > Which to me looks OK.
>
> I agree, the conversion look fine.
>
> >
> > My problem comes when I do co-simulation with Icarus. Then instead of
> > observing the expected aBit==True and aByte==0x55, I observe aBit==False
> > and aByte==0, which are the default values of the MyHDL signals connected
> > co-simulated module.
> >
>
> Ahhh yes, you are trying to Cosimulate a design
> that has no inputs.  I forget the particular
> reasons but I don't believe it is possible to
> Cosimulate such a limited design.
> http://docs.myhdl.org/en/latest/manual/cosimulation.html#restrictions
>
> See the example in the documents for a basic
> example:
>
> http://docs.myhdl.org/en/latest/manual/cosimulation.html#co-simulation-with-verilog
>
> You shouldn't have any issue Cosimulating a
> complete design.
>
> Regards,
> Chris
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] Constant assignments in co-simulation

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

On 5/26/2015 12:22 PM, Nikolay Kavaldjiev wrote:
>> Ahhh yes, you are trying to Cosimulate a design
>> that has no inputs.  I forget the particular
>> reasons but I don't believe it is possible to
>> Cosimulate such a limited design.
>> http://docs.myhdl.org/en/latest/manual/cosimulation.html#restrictions
>
> To exclude this as a possibility I modified the example module in the gist (
> https://gist.github.com/nkavaldj/7cc69372246e64d68f58) to have an input and
> I still have the same issue with co-simulation (only with co-simulation).
>
> The modified code:

Add a transition of the input in the `stim` and
see if anything changes.   Example, create a loop
and increment `y` and monitor the outputs.

>> You shouldn't have any issue Cosimulating a
>> complete design.
>
> Actually we have the issue in a large/complete design with plenty of inputs
> and outputs. The gist is just a minimalistic example that demonstrates the
> issue. We are using myhdl for more that two years now, including
> co-simulation, so it should not be a beginners issue. I hit the issue a
> week ago, and I cannot move since.
>

Sorry my foray hasn't been productive.  The additional
background is useful.  I don't recall running across
an issue like this.

Regards,
Chris

Re: [myhdl-list] Constant assignments in co-simulation

[Nikolay K. <nik...@gm...>]

Hi All,

To close this thread, I give a summary and a workaround, which can also be
found in the original gist:
https://gist.github.com/nkavaldj/650fafbc3693f7a501e2

==============

The Problem

When we do MyHDL co-simulation using Icarus Verilog simulator, we have the
following problem: if in the converted MyHDL code we have a combinatorial
assignment of type

OutPort.next = CONSTANT

, where OutPort is an output port of the co-simulated module and CONSTANT
is some constant value, then during the co-simulation, in MyHDL we do not
see on OutPort value CONSTANT.

The problem is demonstrated by the code in cosim_issue.py given in the gist
above. There we have the MyHDL module "const_assign":

def const_assign(x, y, aBit, aByte):
    @always_comb
    def logic():
        y.next = x + 5
        aBit.next = True
        aByte.next = 55
    return logic

, which we convert to Verilog:

module const_assign (
    x,
    y,
    aBit,
    aByte
);
input [7:0] x;output [7:0] y;wire [7:0] y;output aBit;wire aBit;output
[7:0] aByte;wire [7:0] aByte;
assign y = (x + 5);assign aBit = 1'b1;assign aByte = 55;
endmodule

, and then we co-simulate with Icarus Veriog.

During co-simulation we expect to see the output ports aBit and aByte of
the co-simulated module to be assigned values True and 55 respectively.
However, the values that we actually see are different, False and 0. These
are the default values of the signals my_bit and my_byte connected to the
co-simulated module.

The Reason

We are not sure what the reason for this problem is, but what causes the
problem seams to be a Verilog continuous assignments of type:

assign OutPort = CONSTANT

The reason might be a VPI issue?!

A Workaround

We managed to to avoid the problem by slightly modifying the MyHDL module
to:

def const_assign(x, y, aBit, aByte):
    @always_comb
    def logic():
        dummy = 0
        y.next = x + 5
        aBit.next = True
        aByte.next = 55
    return logic

The only difference with the previous version of the module is the addition
of the dummy assignment dummy = 0, which serves no other purpose, but to
alter the generated Verilog:

module const_assign (
    x,
    y,
    aBit,
    aByte
);
input [7:0] x;output [7:0] y;reg [7:0] y;output aBit;reg aBit;output
[7:0] aByte;reg [7:0] aByte;
always @(x) begin: CONST_ASSIGN_LOGIC
    reg dummy;
    dummy = 0;
    y = (x + 5);
    aBit = 1'b1;
    aByte = 55;end
endmodule

By adding the dummy assignment to our @always_comb section we avoid the
Verilog continuous assignments that cause our problem, and instead of them
we get a combinatorial Verilog process, which co-simulates fine.



Regards,

Nikolay

Re: [myhdl-list] Constant assignments in co-simulation

[Henry G. <he...@ca...>]

On 05/06/15 12:19, Nikolay Kavaldjiev wrote:
>
> During co-simulation we expect to see the output ports aBit and aByte 
> of the co-simulated module to be assigned values True and 55 
> respectively. However, the values that we actually see are different, 
> False and 0. These are the default values of the signals my_bit and 
> my_byte connected to the co-simulated module.
>
> The Reason
>
> We are not sure what the reason for this problem is, but what causes 
> the problem seams to be a Verilog continuous assignments of type:
>
> assign  OutPort=  CONSTANT

I would have expected the Verilog to work as expected. Does it need a 
bitwidth or something?

What do other simulators do?

Henry

Re: [myhdl-list] Constant assignments in co-simulation

[Nikolay K. <nik...@gm...>]

On 5 June 2015 at 13:29, Henry Gomersall <he...@ca...> wrote:

> I would have expected the Verilog to work as expected. Does it need a
bitwidth or something?

I would also expect so. My guess is that the problem is in the interface
between MyHDL and Icarus. The OutPort never changes value, the expression
assign OutPort = CONSTANT is never evaluated, the value on the MyHDL side
is never updated... something like that. When you put the assignment in a
alway @ section which is evaluated, the value on the MyHDL side in correct.


> What do other simulators do?

I haven't tried with other simulators.

Nkolay



On 5 June 2015 at 13:29, Henry Gomersall <he...@ca...> wrote:

>  On 05/06/15 12:19, Nikolay Kavaldjiev wrote:
>
> During co-simulation we expect to see the output ports aBit and aByte of
> the co-simulated module to be assigned values True and 55 respectively.
> However, the values that we actually see are different, False and 0. These
> are the default values of the signals my_bit and my_byte connected to the
> co-simulated module.
>
> The Reason
>
> We are not sure what the reason for this problem is, but what causes the
> problem seams to be a Verilog continuous assignments of type:
>
> assign OutPort = CONSTANT
>
>
> I would have expected the Verilog to work as expected. Does it need a
> bitwidth or something?
>
> What do other simulators do?
>
> Henry
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>