myhdl-list — Mailing list for discussions on MyHDL

[myhdl-list] Signal has multiple drivers: tlp_tx_tvalid_renamed0

[Guy E. <guy...@gm...>]

Hi,

I'm not sure why the following code gives the conversion error mentioned
above.

===

from myhdl import *

class TlpTxInterface:
    """ PCIe endpoint TX-interface """
    def __init__(self):
        self.tvalid = Signal(bool(False))

def tx_engine(clk, rst, tlp_tx):

    t_tx_state = enum("TX_IDLE", "TX_CPLD_WORD0", "TX_CPLD_WORD1",
"TX_CPLD_WAIT_ACK", "TX_DONE")

    s_tx_state_r = Signal(t_tx_state.TX_IDLE)

    @always_seq(clk.posedge, reset=rst)
    def logic():

        if s_tx_state_r == t_tx_state.TX_IDLE:
            s_tx_state_r.next = t_tx_state.TX_CPLD_WORD0
            tlp_tx.tvalid.next = 0

        elif s_tx_state_r == t_tx_state.TX_CPLD_WORD0:
            tlp_tx.tvalid.next = 1
            s_tx_state_r.next = t_tx_state.TX_CPLD_WORD1

        elif s_tx_state_r == t_tx_state.TX_CPLD_WORD1:
            tlp_tx.tvalid.next = 1
            s_tx_state_r.next = t_tx_state.TX_CPLD_WAIT_ACK

        elif s_tx_state_r == t_tx_state.TX_CPLD_WAIT_ACK:
            s_tx_state_r.next = t_tx_state.TX_DONE

        elif s_tx_state_r == t_tx_state.TX_DONE:
            s_tx_state_r.next = t_tx_state.TX_CPLD_WORD1

    return instances()

if __name__ == "__main__":
    # Define port signals:
    clk = Signal(bool(0))
    rst = ResetSignal(0, active=1, async=False)
    tlp_tx = TlpTxInterface()

    # Convert to VHDL:
    toVHDL.std_logic_ports = True
    inst_tx_engine = toVHDL(tx_engine, clk, rst, tlp_tx)


===

Thanks,
Guy.

Re: [myhdl-list] tri1 and tri0 net types

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

On 6/9/2015 4:32 PM, Jan Marjanovic wrote:
> Hi,
>
> I am starting to experiment with MyHDL and I noticed that there is a feature
> missing, namely an equivalent to tri1 and tri0 net types in Verilog. They are
> used to model a net with a pull-up or pull-down resistor, e.g. an I2C bus.

You should be able to do what you want with the
TristateSignal [1].

There were some questions recently on IRC, couple
examples from that discussion:

https://gist.github.com/cfelton/748f5364a1a483f1e982
https://gist.github.com/josyb/c816d585e12ae397627b
https://gist.github.com/cfelton/6119313

There is an outstanding TristateSignal conversion
bug but with any luck (resources) we should have
it fixed soon ...

Hope that helps,
Chris

[1] 
http://docs.myhdl.org/en/latest/manual/reference.html?highlight=tracesignals#myhdl.traceSignals

[myhdl-list] tri1 and tri0 net types

[Jan M. <jan...@ou...>]

Hi,

I am starting to experiment with MyHDL and I noticed that there is a feature 
missing, namely an equivalent to tri1 and tri0 net types in Verilog. They are 
used to model a net with a pull-up or pull-down resistor, e.g. an I2C bus.

I believe that this feature could add to completeness of the language, and 
also that it is quite trivial to implement it. The user would specify a 
default value to TristateSignal constructor and the resolve function will 
honor the default value instead of just returning None when no driver is 
driving the net.

What do the others think?

Best Regards,
(the other) Jan

Re: [myhdl-list] multiple instances and (e.g.) vhdl_code

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

On 08/06/15 13:41, Christopher Felton wrote:
> On 6/8/2015 7:05 AM, Henry Gomersall wrote:
>> Is there a template string for getting an identifier for the current
>> instance when using vhdl_code?
>>
>> That is, I want the name of the function inside the vhdl code to be
>> different for each call to the instance constructor. So the vhdl_code
>> could look something like:
>> FOO_BAR.vhdl_code = '''
>> foo_bar_$this_id: entity work.SOME_BLOCK(MyHDL)
>> ...
>> '''
> I don't believe there exists an automatic method for
> doing this, you would need to manage it yourself.  You
> could have a random unique value created or use a `id`
> string argument to the module (function).
>
> You could use a function attribute and increment on
> each call [1]:
>
>       def vhdl_stub(...)
>           vhdl_stub.id = vhdl_stub.id + 1
>           this_id = vhdl_stib_id
>
>

Thanks Chris,

That is essentially what I've done (albeit with a global list keeping 
track of the allocated values). I do think there is probably grounds for 
an ID to be set by the converter.

Cheers,

Henry

Re: [myhdl-list] multiple instances and (e.g.) vhdl_code

[Ben <ben...@gm...>]

That is a frequent request, and as such, I think it would make sense
to implement, document such an automatic method in the core of MyHDL.

Regards,
Ben.

On Mon, Jun 8, 2015 at 2:41 PM, Christopher Felton
<chr...@gm...> wrote:
> On 6/8/2015 7:05 AM, Henry Gomersall wrote:
>> Is there a template string for getting an identifier for the current
>> instance when using vhdl_code?
>>
>> That is, I want the name of the function inside the vhdl code to be
>> different for each call to the instance constructor. So the vhdl_code
>> could look something like:
>> FOO_BAR.vhdl_code = '''
>> foo_bar_$this_id: entity work.SOME_BLOCK(MyHDL)
>> ...
>> '''
>
> I don't believe there exists an automatic method for
> doing this, you would need to manage it yourself.  You
> could have a random unique value created or use a `id`
> string argument to the module (function).
>
> You could use a function attribute and increment on
> each call [1]:
>
>      def vhdl_stub(...)
>          vhdl_stub.id = vhdl_stub.id + 1
>          this_id = vhdl_stib_id
>
> Regards,
> Chris
>
> [1] https://gist.github.com/cfelton/79012fa54868fbd2ebf7
>
>
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] multiple instances and (e.g.) vhdl_code

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

On 6/8/2015 7:05 AM, Henry Gomersall wrote:
> Is there a template string for getting an identifier for the current
> instance when using vhdl_code?
>
> That is, I want the name of the function inside the vhdl code to be
> different for each call to the instance constructor. So the vhdl_code
> could look something like:
> FOO_BAR.vhdl_code = '''
> foo_bar_$this_id: entity work.SOME_BLOCK(MyHDL)
> ...
> '''

I don't believe there exists an automatic method for
doing this, you would need to manage it yourself.  You
could have a random unique value created or use a `id`
string argument to the module (function).

You could use a function attribute and increment on
each call [1]:

     def vhdl_stub(...)
         vhdl_stub.id = vhdl_stub.id + 1
         this_id = vhdl_stib_id

Regards,
Chris

[1] https://gist.github.com/cfelton/79012fa54868fbd2ebf7

[myhdl-list] multiple instances and (e.g.) vhdl_code

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

Is there a template string for getting an identifier for the current 
instance when using vhdl_code?

That is, I want the name of the function inside the vhdl code to be 
different for each call to the instance constructor. So the vhdl_code 
could look something like:
FOO_BAR.vhdl_code = '''
foo_bar_$this_id: entity work.SOME_BLOCK(MyHDL)
...
'''

I'm currently working around it with a module local list of allocated 
ids and creating a new one each time. This works, but is not very neat.

Cheers,

Henry

Re: [myhdl-list] Initial value support

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

On 6/5/2015 6:38 AM, Henry Gomersall wrote:
> What is current status of the initial value support? My understanding is
> that the code is there but comes caveat emptor.
>
> Certainly, in the Xilinx FPGA world, initial values seem to be the
> preferred strategy:
> http://www.xilinx.com/support/documentation/white_papers/wp272.pdf
>
> (though I appreciate that ASICs are not like that).

Yes, there is code that can be enable for initial value
support (IVS).  At one point XST actually failed on IVS.

Before enabling we wanted to do our due-diligence and
verify most major tools supported:

http://dev.myhdl.org/tasks/initial-values-support.html
http://dev.myhdl.org/ideas/initial-values.html

Creating an issue request IVS to be enabled is probably
a reasonable path forward (or a PR enabling it).

Inevitably, IVS also morphs into RAM initialization
support (RIS), which is less consistent between
languages and vendors.  We should not try and include
RIS when enabling IVS.

Regards,
Chris

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
>
>

[myhdl-list] Initial value support

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

What is current status of the initial value support? My understanding is 
that the code is there but comes caveat emptor.

Certainly, in the Xilinx FPGA world, initial values seem to be the 
preferred strategy:
http://www.xilinx.com/support/documentation/white_papers/wp272.pdf

(though I appreciate that ASICs are not like that).

Cheers,

Henry

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...>]

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] Array of constants and code generation

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

Am 02.06.2015 um 12:55 schrieb Josy Boelen:
>
> This converts:
[...]

> By introducing the variable *aa* and coercing *angles* into a tuple we
> get plausible VHDL code.
> I agree that  *indexing an array of constants* would looks nice, and
> probably is what you expected. But I'm almost 100% sure the
> synthesizer/mapper will generate the same element usage for both.

Cool!  Thanks for this trick.

> I had to disable the print statement as that doesn't convert when using
> parenthesis and without it will emit writelines, which is probably not
> intended either.

Sure.

> Regards,
>
> Josy

Thanks again,
Thomas

Re: [myhdl-list] Array of constants and code generation

[Josy B. <jos...@gm...>]

> I'm trying to implement a cordic module to calculate the phase of a
> vector with rectangular coordinates x and y.  The cordic is a full
> parallel pipelined architecture; the vector rotations are generated in 
a 
> loop.  The angles are precalculated as integers in a list.
> The code simulates perfectly; but code generation with toVHDL
> or toVerilog fails with this error:
> 
> ConversionError: in file 
> 
C:\Users\thomas\devel\mytss5\dist\components\_Pythonlib\pmc4\hardware\ip
\cordic.py, 
> line 40:
>      Object type is not supported in this context: angles, <type 
'list'>
> 
> I tried a tuple instead of a list but conversion failed as well.
> 
> How can I rewrite the code for conversion?

This converts:
SCALE = 2000
N = 10

def Cordic(clk,  x, y, phase):

    xi = [Signal(intbv(0, min = - 2**12, max = 2**12)) for _ in 
range(N)]
    yi = [Signal(intbv(0, min = - 2**12, max = 2**12)) for _ in 
range(N)]
    zi = [Signal(intbv(0, min = - 2**11, max = 2**11)) for _ in 
range(N)]

    angles = tuple([int(round(math.atan(2**-i) * SCALE / 2 / math.pi)) 
for i in range(N)])

    @always_seq(clk.posedge, reset = None)
    def doit():
        if x < 0:
            xi[0].next = -x
            yi[0].next = -y
            zi[0].next = SCALE // 4 * 3
        else:
            xi[0].next = x
            yi[0].next = y
            zi[0].next = SCALE // 4

        for i in range(9):
            aa = angles[i]
            if yi[i] < 0:
                xi[i+1].next = xi[i] - (yi[i] >> i)
                yi[i+1].next = yi[i] + (xi[i] >> i)
                zi[i+1].next = zi[i] + aa
            else:
                xi[i+1].next = xi[i] + (yi[i] >> i)
                yi[i+1].next = yi[i] - (xi[i] >> i)
                zi[i+1].next = zi[i] - aa

#         print(xi[N-1], yi[N-1], zi[N-1])
        phase.next = zi[N-1]

    return  doit

By introducing the variable *aa* and coercing *angles* into a tuple we 
get plausible VHDL code.
I agree that  *indexing an array of constants* would looks nice, and 
probably is what you expected. But I'm almost 100% sure the 
synthesizer/mapper will generate the same element usage for both.
I had to disable the print statement as that doesn't convert when using 
parenthesis and without it will emit writelines, which is probably not 
intended either.

Regards,

Josy

[myhdl-list] Array of constants and code generation

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

I'm trying to implement a cordic module to calculate the phase of a
vector with rectangular coordinates x and y.  The cordic is a full
parallel pipelined architecture; the vector rotations are generated in a 
loop.  The angles are precalculated as integers in a list.
The code simulates perfectly; but code generation with toVHDL
or toVerilog fails with this error:

ConversionError: in file 
C:\Users\thomas\devel\mytss5\dist\components\_Pythonlib\pmc4\hardware\ip\cordic.py, 
line 40:
     Object type is not supported in this context: angles, <type 'list'>

I tried a tuple instead of a list but conversion failed as well.

How can I rewrite the code for conversion?

Thanks,
Thomas

<code>
SCALE = 2000
N = 10

def Cordic(clk,
            x, y,
            phase):

     xi = [hdl_util.signed(13) for _ in range(N)]
     yi = [hdl_util.signed(13) for _ in range(N)]
     zi = [hdl_util.signed(12) for _ in range(N)]

     angles = [int(round(math.atan(2**-i) * SCALE / 2 / math.pi))
               for i in range(N)]

     @myhdl.always(clk.posedge)
     def doit():
         if x < 0:
             xi[0].next = -x
             yi[0].next = -y
             zi[0].next = SCALE // 4 * 3
         else:
             xi[0].next = x
             yi[0].next = y
             zi[0].next = SCALE // 4

         for i in range(9):
             if yi[i] < 0:
                 xi[i+1].next = xi[i] - (yi[i] >> i)
                 yi[i+1].next = yi[i] + (xi[i] >> i)
                 zi[i+1].next = zi[i] + angles[i]
             else:
                 xi[i+1].next = xi[i] + (yi[i] >> i)
                 yi[i+1].next = yi[i] - (xi[i] >> i)
                 zi[i+1].next = zi[i] - angles[i]

         print(xi[-1], yi[-1], zi[-1])

         phase.next = zi[-1]

     return myhdl.instances()

</code>

Re: [myhdl-list] Hello World

[Günther S. <gue...@gm...>]

Hi Christopher,
Now i rewrote my code with only the system clock in the
process, and i do not have any timing issues anymore.
Now i can run the 3wire SPI with 1 MHz and get
the correct DEVID of the accelerometer.
i checked in my code:
https://github.com/stangassinger/de0_nano_adxl345
Thanks a lot.

Regards

guenther


Am 26.05.2015 um 16:59 schrieb Christopher Felton:
> On 5/21/2015 5:20 AM, Günther Stangassinger wrote:
>> Hello Christopher,
>> you wrote:
>>
>> "The DEnano has a 50MHz clock, this should be
>> the clock driving all your processes/generators.  Don't
>> use the generated SCLK to clock any internal logic."
>>
>>
>> Can you please tell me the reason for this?
> It is going to be the safest design practice and
> the easiest to guarantee you have met timing.  Even
> with slow clocks it is best to use a single clock
> and a single edge in most cases (there are always
> exceptions).
>
> The Altera Quartus synthesis guide is a reasonable
> reference and will do a better job describing the
> pitfalls than I would in a short response.
>
> See section "Synchronous FPGA Design Practices" on
> page12-2 in the following document and specifically
> "Clocking Schemes" on page 12-7.
> https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/hb/qts/qts_qii51006.pdf
>
> Hope that helps,
> 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] VHDL converted ConcatSignal

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

On 27/05/15 14:20, Josy Boelen wrote:
>>> > >3. I don't have the issue when taking a subscript instead of a slice,
>>> > >and neither should you because a single bit from either a signed or an
>>> > >unsigned still is a std_logic.
>> >
>> >Yes, I think I was wrong on this - the problem was a zero length vector,
>> >which Python is quite happy with but Vivado baulks at (I assume because
>> >it's invalid VHDL or something).
> A zero-length vector is invalid VHDL, and perhaps we should have MyHDL
> complain about that too? But how do you fabricate a zero-length vector in
> MyHDL?

Hmmm good question. I suspect this is a non-issue that some other 
problem caused to be shown. I've removed such a case from my test suite 
and caught it earlier, so I'm not concerned with it anymore. I suspect 
if it is a real problem it will be corrected by proper coercion of types.

Cheers,

Henry

Re: [myhdl-list] VHDL converted ConcatSignal

[Josy B. <jos...@gm...>]

> > 3. I don't have the issue when taking a subscript instead of a slice,
> > and neither should you because a single bit from either a signed or an
> > unsigned still is a std_logic.
> 
> Yes, I think I was wrong on this - the problem was a zero length vector, 
> which Python is quite happy with but Vivado baulks at (I assume because 
> it's invalid VHDL or something).

A zero-length vector is invalid VHDL, and perhaps we should have MyHDL 
complain about that too? But how do you fabricate a zero-length vector in 
MyHDL?

Regards,

Josy

Re: [myhdl-list] VHDL converted ConcatSignal

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

On 27/05/15 13:57, Josy Boelen wrote:
> 2. Actually the ShadowSignal(h,l) remembers that the source was signed,
> but the ConcatSignal() doesn't take that into account. The fix is quite
> simple. I'm actually working on the new 'std_logic_ports' feature and
> some issues when ShadowSignal is involved. I'll post a PR later tonight.
> I have no idea on solving 1. (yet) but will look into that. I'm going to
> do it in several PR's though (or at least in separate commits)

That sounds great. I look forward to seeing the PR.

Cheers,

Henry

Re: [myhdl-list] VHDL converted ConcatSignal

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

On 27/05/15 13:57, Josy Boelen wrote:
> 3. I don't have the issue when taking a subscript instead of a slice,
> and neither should you because a single bit from either a signed or an
> unsigned still is a std_logic.

Yes, I think I was wrong on this - the problem was a zero length vector, 
which Python is quite happy with but Vivado baulks at (I assume because 
it's invalid VHDL or something).

Cheers,

Henry

Re: [myhdl-list] VHDL converted ConcatSignal

[Josy B. <jos...@gm...>]

> I started writing this when I noticed that the new (allowing 
constants) 
> ConcatSignal doesn't produce VHDL that coerces a signed intbv signal 
to 
> unsigned such that (at least in Vivado) an error occurs. In producing 
a 
> minimal non-working example, I've noticed some other peculiarities in 
> conversion.
> 
> I say the new ConcatSignal, but it might still be present in the older 
code.
> 
> The following gist gives an example of code causing a problem, along 
> with generated output and my comments:
> 
> https://gist.github.com/hgomersall/cf8a47e7f6929564addd
> 
> The work around for the above is fairly simple and neat (and arguably 
> better as it makes the signedness explicit) by having an interim 
> unsigned signal. This is shown in the second comment of the above 
gist.
> 
> FYI: I get a similar complaint if concat_sig_in is set to be a single 
bit:
> 
> concat_sig_in = ConcatSignal(sig_in(1), intbv(0)[9:])
> 
> in which case I get an error along the lines of "indexed name is not a 
> std_ulogic".

Hello Henry,

Three issues in one :)
1. ShadowSignals are taken from the 'original' Signal, but the VHDL 
conversion takes the names from the top-level function. I guess that 
almost everybody uses the same names in the definition and in the 
instantiations, so this doesn't show up often? See 2.

2. Actually the ShadowSignal(h,l) remembers that the source was signed, 
but the ConcatSignal() doesn't take that into account. The fix is quite 
simple. I'm actually working on the new 'std_logic_ports' feature and 
some issues when ShadowSignal is involved. I'll post a PR later tonight.
I have no idea on solving 1. (yet) but will look into that. I'm going to 
do it in several PR's though (or at least in separate commits) 

3. I don't have the issue when taking a subscript instead of a slice, 
and neither should you because a single bit from either a signed or an 
unsigned still is a std_logic.

Regards,

Josy

[myhdl-list] VHDL converted ConcatSignal

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

I started writing this when I noticed that the new (allowing constants) 
ConcatSignal doesn't produce VHDL that coerces a signed intbv signal to 
unsigned such that (at least in Vivado) an error occurs. In producing a 
minimal non-working example, I've noticed some other peculiarities in 
conversion.

I say the new ConcatSignal, but it might still be present in the older code.

The following gist gives an example of code causing a problem, along 
with generated output and my comments:

https://gist.github.com/hgomersall/cf8a47e7f6929564addd

The work around for the above is fairly simple and neat (and arguably 
better as it makes the signedness explicit) by having an interim 
unsigned signal. This is shown in the second comment of the above gist.

FYI: I get a similar complaint if concat_sig_in is set to be a single bit:

concat_sig_in = ConcatSignal(sig_in(1), intbv(0)[9:])

in which case I get an error along the lines of "indexed name is not a 
std_ulogic".

Cheers,

Henry

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...>]

> 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 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