About use mflow gen to get synthesis information

[qiuqi...@gmail.com]

Hi all,

After I generated the verilog code. I try to use mflowgen to get synthesis result, I got this information:

"

Yosys 0.9 (git sha1 UNKNOWN, gcc 10.1.0 -march=x86-64 -mtune=generic -O2 -fno-plt -fPIC -Os)

-- Executing script file `synth.ys' --

1. Executing Verilog-2005 frontend: design.name_mangled.v

design.name_mangled.v:260: ERROR: syntax error, unexpected invalid token

make: *** [Makefile:264: 3-open-yosys-synthesis/.execstamp] Error 1 "

If I type the same command for the example GCD unit, It will succeed.

Dose anyone have an idea about that? Thank you!

[Christopher Batten]

Hmmm ... can you provide some more information on what you are trying to do? Are you using the Yosys translation backend or the regular SystemVerilog translation backend for your PyMTL code? You probably want to take a closer look at like 260 in your design (i.e., design.name_mangled.v) and verify that syntax is supported by Yosys?

Best,
Chris

> --
> You received this message because you are subscribed to the Google Groups "pymtl-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to pymtl-users...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/pymtl-users/48f28332-7ec3-4632-bed9-14e791fae60en%40googlegroups.com.

[qiuqi...@gmail.com]

My translation code is

"

    macc = Acc()

    macc.set_metadata( YosysTranslationPass.enable, True)

    macc.elaborate()

    macc.apply(YosysTranslationPass())

    done = True

"

but the reported design.name_mangled.v is not part of my code.

[qiuqi...@gmail.com]

I found the error Verilog code:

module Mux__Type_Bits64__ninputs_2

(

  input  logic [0:0] clk ,

  input  logic [63:0] in_ [0:1],

  output logic [63:0] out ,

  input  logic [0:0] reset ,

  input  logic [0:0] sel 

);

this code is generated from pymtl3.stdlib.mux, is there any problem about that code? Thanks

[Christopher Batten]

I wonder if Yosys doesn't like arrays of ports? Hopefully Peitian can chime in ...

Is the verilog snippet you included in design.name_mangled.v or is it in the original Verilog generated by PyMTL3?

It would probably be best if you could provide a minimal example for us to look at ... you could even make a repl.it so we can reproduce at least the PyMTL3 -> Verilog part?

Note that we can't really do _too_ much debugging on mflowgen or yosys on this list since it is focused on PyMTL3. We will try, but you might need to chat with the mflowgen or yosys developers.

Best,
Chris

> To view this discussion on the web visit https://groups.google.com/d/msgid/pymtl-users/c5d92dff-2ecc-45f9-8ce3-adb3d392256cn%40googlegroups.com.

[Peitian Pan]

I'm pretty sure arrays of ports is SystemVerilog-specific and therefore the reported syntax error because yosys only supports Verilog-2005. However I'm not sure why the yosys backend generated this result... I think we have regression tests on the translation result of arrays of ports.

I did a quick check on master branch of pymtl3 with the following code:

```

from pymtl3 import *

from pymtl3.stdlib.basic_rtl import Mux

from pymtl3.passes.backends.yosys import YosysTranslationPass

m = Mux(Bits32, 2)

m.elaborate()

m.set_metadata( YosysTranslationPass.enable, True )

m.apply( YosysTranslationPass() )

```

and the generated Veirlog looks like this

```

module Mux__Type_Bits32__ninputs_2

(

  input  logic [0:0]    clk,

  input  logic [31:0]   in___0,

  input  logic [31:0]   in___1,

  output logic [31:0]   out,

  input  logic [0:0]    reset,

  input  logic [0:0]    sel

);

  ...

```

So seems like translating a stand-alone mux from the stdlib works fine. Can you maybe provide a simple failing case and the pypi package version or git commit hash you are using?

Best,

Peitian

On Aug 4, 2020, at 7:19 PM, qiuqi...@gmail.com <qiuqi...@gmail.com> wrote:

To view this discussion on the web visit https://groups.google.com/d/msgid/pymtl-users/c5d92dff-2ecc-45f9-8ce3-adb3d392256cn%40googlegroups.com.

[Jiangqiu Shen]

Ok.. I was using the Yosys backend and I failed , then I changed to SystemVerilog backend, the I post the result of systemVerilog. Now the error code for Yosys result was:

  always_comb begin : up_rf_read

    for ( __loopvar__up_rf_read_i = 1'd0; __loopvar__up_rf_read_i < 1'd1; __loopvar__up_rf_read_i = __loopvar__up_rf_read_i + 1'd1 )

      rdata[1'(__loopvar__up_rf_read_i)] = regs[raddr[1'(__loopvar__up_rf_read_i)]];

  end

[Christopher Batten]

Hi Jiangqui,

You cannot use the SystemVerilog backend with Yosys because Yosys does not support much of the SystemVerilog spec. That is why we created the Yosys backend ...

Before we go too far down this route, please put together a minimal example which demonstrates the issue (possibly creating a GitHub repo with your code) and provide step-by-step instructions on how we can reproduce the issue from scratch.

Thanks!
Chris

> On Aug 4, 2020, at 11:44 PM, Jiangqiu Shen <qiuqi...@gmail.com> wrote:
>
> Ok.. I was using the Yosys backend and I failed , then I changed to SystemVerilog backend, the I post the result of systemVerilog. Now the error code for Yosys result was:
>
> always_comb begin : up_rf_read
> for ( __loopvar__up_rf_read_i = 1'd0; __loopvar__up_rf_read_i < 1'd1; __loopvar__up_rf_read_i = __loopvar__up_rf_read_i + 1'd1 )
> rdata[1'(__loopvar__up_rf_read_i)] = regs[raddr[1'(__loopvar__up_rf_read_i)]];
> end
>

> To view this discussion on the web visit https://groups.google.com/d/msgid/pymtl-users/CAOyT_6hRVmVzx-0gRtw-F3Arm6PBHkeUoJ%3DY4gBYr3KZcqR_bQ%40mail.gmail.com.

[qiuqi...@gmail.com]

Hi Chris ,

Thanks for your reply, I build a git repo with a simple sample to show the case:

https://github.com/shenjiangqiu/pymtl_test

I wrote a simple pymtl Component class:

class TestComponent(Component):

    def construct(s):

        s.recv = RecvIfcRTL(b32)

        s.send = SendIfcRTL(b32)

        s.q = PipeQueueRTL(b32, 64)

        s.recv //= s.q.enq

        @update

        def comb():

            s.send.en@=s.send.rdy & s.q.deq.rdy

            s.q.deq.en@=s.send.rdy & s.q.deq.rdy

and translate it:

unit = TestComponent()

    unit.set_metadata( YosysTranslationPass.enable, True)

    unit.elaborate()

    unit.apply(YosysTranslationPass())

then I use mflowgen  and the error occurred again. the more detailed build step was in the readme file. Thanks.

[Christopher Batten]

Ok! We will take a look. Can you confirm which version of pymtl3 you are using and which version of yosys?

Sent from my iPhone

On Aug 5, 2020, at 1:08 AM, qiuqi...@gmail.com <qiuqi...@gmail.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/pymtl-users/14fa1987-7163-42d7-b057-104f57457117n%40googlegroups.com.

[qiuqi...@gmail.com]

I was using pymtl3-3.1 and Yosys 0.9 (git sha1 UNKNOWN, gcc 10.1.0 -march=x86-64 -mtune=generic -O2 -fno-plt -fPIC -Os)

[Peitian Pan]

Hi Jiangqui,

I'm able to reproduce the error on the same line as you pointed. It is because yosys gets confused at the explicit size casting inside the index (e.g., `rdata[1'(__loopvar__)]`). As a temporary workaround, can you try to remove the size casting (e.g., change that to `rdata[__loopvar__]`) at every occurrence and rerun yosys? That fixed the issue for me (though i'm on yosys-0.8).

I think we (pymtl3 developers) probably should reconsider if we really want these size castings in an index expression. Verilator seems to work fine with it but I haven't tried DC. If DC throws a warning at this then we probably shouldn't do this at all. But regardless explicit size casting inside index expressions should be gone from the yosys backend in the minor release.

Thanks for the feedback!

Peitian 

To view this discussion on the web visit https://groups.google.com/d/msgid/pymtl-users/14fa1987-7163-42d7-b057-104f57457117n%40googlegroups.com.

[qiuqi...@gmail.com]

Hi Peitian,

Thanks for your reply. After removing all the size casting, my code works!