New aiger backend

[povik]

Start a new AIGER2 backend which accepts designs in less expanded forms. This is staging ground for new features before they are integrated into the existing XAIGER/AIGER backends.

Also add a read_xaiger2 -sc_mapping command and an abc_new command for round tripping through ABC and obtaining an SC mapping back.

What are the reasons/motivation for this change?

Some of the scalability ills of Yosys synthesis on large designs may be alleviated if we move more of the flattening/mapping/bit-blasting steps into the backend which writes out the design for ABC processing. Also this has potential to simplify non-synthesis flows.

Compared to the existing AIGER/XAIGER backends, this new backend is able to ingest

• coarse cells (using basic AIG representations implanted by the backend)
• levels of hierarchy to be flattened during the write-out process

The levels of hierarchy may be design hierarchy, or hierarchy introduced by techmap -extern. This mentioned command would be a way for users to override/supplement the hard-coded mapping rules of the backend.

There's rudimentary constant folding (working across hierarchy levels).

[povik]

I tried for a separation of concerns between this Index struct (dealing with the generic problem of generating an AIG from the design) and a derived AigerWriter which holds the AIGER specifics.

This means the Index (or whatever we rename it to) can be reused for other places we may need an AIG, e.g. hypothetical commands linking to ABC and filling its data structures directly, or toymap, or commands linking to imctk, etc.

[widlarizer]

How did you resolve #3967 (comment) ? I can't reproduce it, but I don't see anything related in d5aae80

[povik]

How did you resolve #3967 (comment) ?

I am not sure if I did anything which would address that specifically.

[povik]

Current help printout:

-- Running command `help write_aiger2' --

    write_aiger2 [options] [filename]

Write the current design to an AIGER file.

This command is able to ingest all combinational cells except for:

    $alu, $lcu, $demux, $bmux, $pmux, $bweqx, $macc, $concat, $pow, 
    $modfloor, $divfloor, $mod, $div, $mul, $sub, $add, $nex, $eqx, 
    $shiftx, $shift, $sshr, $sshl, $shr, $shl, $sop, $lut, $slice, $neg, 

And all combinational gates except for:

    $_TBUF_, $_MUX16_, $_MUX8_, $_MUX4_, 

WARNING: THE 'write_aiger2' COMMAND IS EXPERIMENTAL.

[povik]

From the VS build:

 "D:\a\yosys\yosys\yosys-win32-vcxsrc-latest\YosysVS.sln" (default target) (1) ->
"D:\a\yosys\yosys\yosys-win32-vcxsrc-latest\YosysVS\YosysVS.vcxproj" (default target) (2) ->
(ClCompile target) -> 
  D:\a\yosys\yosys\yosys-win32-vcxsrc-latest\yosys\backends\aiger2\aiger.cc(49,40): error C2039: 'CONST_FALSE': is not a member of '`anonymous-namespace'::AigerWriter' [D:\a\yosys\yosys\yosys-win32-vcxsrc-latest\YosysVS\YosysVS.vcxproj]
  D:\a\yosys\yosys\yosys-win32-vcxsrc-latest\yosys\backends\aiger2\aiger.cc(49,1): error C2065: 'CONST_FALSE': undeclared identifier [D:\a\yosys\yosys\yosys-win32-vcxsrc-latest\YosysVS\YosysVS.vcxproj]

Not sure what to think of it.

[widlarizer]

Doesn't it boil down to this?

[povik]

Yes, thanks. It's not clear to me if it's valid C++, or how to change it to make the compiler happy

[widlarizer]

I was told "default member initializers are complete-class context, so I think msvc is wrong to reject this" by a clang dev. Seems to suggest that initializers aren't declared until the class is complete, which it isn't because you have something like a type dependency loop. I guess you have to find a different class structure for the functionality you want. It's not too surprising to me that there would be problems related to struct A : B<A>

[widlarizer]

As expected, we still have that queue pointer problem, I just had to re-run the unreduced file and re-reduce it. valgrind ./yosys -p "read_rtlil bug.il; proc; bufnorm -update; opt; bufnorm -update"

on this bug.il

module \top.U$$0
  wire width 32 output 1 \data
  wire width 32 \RAM_r_data
  wire width 32 $delete_wire$2
  cell $mem_v2 \i_bus
    parameter \ABITS 11
    parameter \INIT 65536'0
    parameter \MEMID "\\i_bus"
    parameter \OFFSET 0
    parameter \RD_ARST_VALUE 64'0
    parameter \RD_CE_OVER_SRST 2'00
    parameter \RD_CLK_ENABLE 2'00
    parameter \RD_CLK_POLARITY 2'11
    parameter \RD_COLLISION_X_MASK 2'00
    parameter \RD_INIT_VALUE 64'0
    parameter \RD_PORTS 2
    parameter \RD_SRST_VALUE 64'0
    parameter \RD_TRANSPARENCY_MASK 2'00
    parameter \RD_WIDE_CONTINUATION 2'00
    parameter \SIZE 2048
    parameter \WIDTH 32
    parameter \WR_CLK_ENABLE 1'1
    parameter \WR_CLK_POLARITY 1'1
    parameter \WR_PORTS 1
    parameter \WR_PRIORITY_MASK 1'0
    parameter \WR_WIDE_CONTINUATION 1'0
    connect \RD_ADDR 22'x
    connect \RD_ARST 2'x
    connect \RD_CLK 2'x
    connect \RD_DATA { $delete_wire$2 \RAM_r_data }
    connect \RD_EN 2'x
    connect \RD_SRST 2'x
    connect \WR_ADDR 11'x
    connect \WR_CLK 1'x
    connect \WR_DATA 32'x
    connect \WR_EN 32'x
  end

  process $group_0
    assign \data \RAM_r_data
  end
end

[widlarizer]

I discussed this with @povik and decided that it seems safe to remove the bufnorm command and go on using the buffer normalized mode as a one-shot index without staying in the mode subsequently, avoiding the dynamic addition of pointers into the bufnormqueue

[povik]

I discussed this with @povik and decided that it seems safe to remove the bufnorm command and go on using the buffer normalized mode as a one-shot index without staying in the mode subsequently, avoiding the dynamic addition of pointers into the bufnormqueue

This discussion belongs to #4593 #3967 but I think it's fine to merge the bufnorm command too as long as it's marked experimental. Other than that yes, for the time being the normalized mode has value as a one-shot index until we iron out the updating of it.

[widlarizer]

You have linked this PR from itself and the universe will now proceed to explode. Did you mean #3967 ? You want this PR to only be merged after the bufnorm PR and a rebase?

[povik]

Did you mean #3967 ?

Yes, thanks.

You want this PR to only be merged after the bufnorm PR and a rebase?

Pretty much

[povik]

Rebased after merge of #3967

[georgerennie]

Just a drive-by nitpick, but in the off chance aiger2 does exist as a standard version at somepoint/to avoid confusion that we aren't supporting an aiger version that doesn't exist, would it be better to call this pass something else? write_aiger_techmap, write_lowered_to_aiger, write_aiger_eager or some such?

[povik]

write_aiger_techmap, write_lowered_to_aiger, write_aiger_eager or some such?

If we cannot outright replace the existing backends I'd prefer we fold in the new code as an option on the existing backend commands, e.g. write_aiger -bitblasted

[georgerennie]

Oh yeah that works too definitely