Add support for Yosys's extended blif format

[mithro]

Yosys can output an "extended" blif format which includes a lot of useful extensions which enable BLIF usage for real world FPGA support (related to #245).

    -conn
        do not generate buffers for connected wires. instead use the
        non-standard .conn statement.

    -attr
        use the non-standard .attr statement to write cell attributes

    -param
        use the non-standard .param statement to write cell parameters

    -cname
        use the non-standard .cname statement to write cell names

[mithro]

I think the first step would be to make vpr have an argument which makes it ignore unknown values in a .blif file with a warning?

[mithro]

We should also see if there is a specification / more documentation on the extended BLIF format.

@cliffordwolf - Do you have any more information on the extended BLIF format?

[kmurray]

Adding support for Yosys's extensions seems reasonable. BLIF has lots of limitations and these all seem like good extensions.

Is there any convention about naming extended BLIF files? For example giving them a special file extension (e.g. .blif_ext, .blif2 or something similar)? If our goal is to use this as an interchange format it may be worth coming up with a convention.

I'd prefer to keep the formats VPR accepts explicit, so I'd rather add support for the extended BLIF statements directly to libblifparse (probably with a flag to control accepting/reject the extensions), rather than just treat unknowns as warnings. This level of support should be pretty simple to add.

[mithro]

Maybe .eblif would be good idea? or .bleif would be good extensions.

I think it would be good for vpr to have both a strict and warn modes on the blif parser. strict -- the default option -- would die when it find unsupported stuff. warn would just ignore unsupported stuff.

[cliffordwolf]

I'm not convinced a different file extension would be necessary since the file format is a strict superset of standard blif. However, if a new file extension is used, I am hugely in favor of .eblif or .blif2 over .bleif.

Unfortunately there is no documentation for the extensions beyond the info in the help message. But I'd be happy to answer questions if there are any.

I also think that simply ignoring unknown constructs (with or without warning) is not the right way forward. That sounds like a dangerous direction.. Better would be to add support for one feature after the other. Since all the features can be enabled or disabled individually in Yosys there is no need imo to ignore yet unsupported features in VPR.

[kmurray]

I've added support for the BLIF extenions to VPR (main commit is 2235541).

I also like .eblif as the file extension.

By default, VPR will treat .blif files as strict BLIF (and will error if any of the extensions are used), and .eblif files as BLIF + the YOSYS extensions (.conn, .cname, .param, .attr).

In case anyone wants to use different file extensions they can also explicitly specify the file format with the --circuit_format command-line option.

Currently params/attrs produce warnings, since VPR ignores them. In the future we could tag these on VPR's internal data structures and include them (somewhere) in the implementation VPR produces.

[mithro]

Can we dump the attributes / parameters to a new output file? Maybe xxx.prop?

I need a file which has the name which matches the .place, .net & .route files and the attribute / parameter values. I would suggest an xml format something like;

<properties name="ff.prop" architecture_id="SHA256:e7afccd145fe4ce56ee52853bf93d8b7ac0c32dd1b72478feec26436c6fc03c7" atom_netlist_id="SHA256:ebb92b151c104b0efdf1366139686bd430bb0ef2ac
d1ba9a3c275dbe3a794e11">
  <block name="D1">
    <parameters>
       ....
    </parameters>
    <attributes>
      ...
    </attributes>
  </block>
</properties>

[kmurray]

Currently we store post-implementation primitive information in the .net file which described the packed netlist.

So I'd lean towards sticking the params/attr there, so all the primitive info is in one place. For example:

<block name="D1" instance="clb[1]" mode="clb"> <!-- Top-level clustered block -->
  <!-- intermediate hierarchy not shown -->
    <block name="O" instance="lut[0]"> <!-- Leaf corresponding to BLIF atom primitive -->
        <inputs>
            <port name="in">open lut5.in[1]->direct:lut5  lut5.in[2]->direct:lut5  lut5.in[3]->direct:lut5  lut5.in[4]->direct:lut5  </port>
            <port_rotation_map name="in">open 2 1 0 3 </port_rotation_map>
        </inputs>
        <outputs>
            <port name="out">O </port>
        </outputs>
        <clocks>
        </clocks>
        <parameters>
            <parameter name="my_param" value="my_param_value"/>
        </parameters>
       <attributes>
            <attribute name="my_attr" value="my_attr_value"/>
        </attributes>
    </block>
  <!-- intermediate hierarchy not shown -->
</block>

[mithro]

@kmurray Exactly the route we are going at the moment :-)

We even already have a patch for that here that we need to clean up and send to you -> https://github.com/verilog-to-routing/vtr-verilog-to-routing/compare/master...kc8apf:netlist_eblif_attr_props

@kc8apf got distracted with https://github.com/verilog-to-routing/vtr-verilog-to-routing/issues/291

Do you want to assign this bug to @kc8apf?

[mithro]

@kmurray Do you want to reopen this issue until we land the support for outputting the attributes / properties in the .net file?

[kmurray]

I've re-opened the bug.

The in-progress patch looks to be taking the right approach for tagging things on the netlist.