Get @kc8apf eblif attribute/parameter change into upstream

[mithro]

Take a look at verilog-to-routing#281

@kc8apf has a WIP change at verilog-to-routing@2235541

@kc8apf is happy for @daveshah1 to steal this.

@kmurray is happy with the way this is going. Lets get it upstream into vpr.

[daveshah1]

I have rebased this onto current master (including the change to pugixml), finished the parameter support and tidied it up a bit in 68565f1.

The only remaining issue in my mind is the output syntax. @kmurray gave this example in VPR verilog-to-routing#281:

        <parameters>
            <parameter name="my_param" value="my_param_value"/>
        </parameters>
       <attributes>
            <attribute name="my_attr" value="my_attr_value"/>
        </attributes>

But the current implementation does not use the parameters or attributes wrappers, instead putting attributes and parameters straight into the block thus:

<attribute name="test_attr">1</attribute>
<parameter name="test_param">x</parameter>

I'm not sure which option is preferable though?

[mithro]

I think we prefer my example with the value inside the tag <t>value</t>? I think this because the value of attribute / parameters might have double quotes or other similar types of characters which are harder to escape inside the tag?

It also lets us expand with maybe a "type" value?

<attributes>
  <attribute name="xxx" type="yyy">value</attribute>
</attributes>

[kmurray]

I'm happy with either format, although to be consistent with the current .net format the <attribute>/<parameter> tags should be wrapped in containing <attributes>/<parameters> tags.

I'm not sure adding a 'type' field is a good idea. Treating the attributes/params only as strings means VPR can just blindly pass them through and doesn't have to understand what they mean. To me this seems less fragile and more general (since the potential set of params/attributes which can be set by other tools is unbounded).

[daveshah1]

I will add the <attributes> and <parameters> wrappers to the PR. Do you think it is best to generate empty wrappers when there are no attributes/parameters, or should the wrappers only be generated when there is at least one attribute/parameter?

[kmurray]

Looking at the existing format it seems like the convention is to generate empty wrappers even when there are no elements (e.g. <clocks> is still specified even for combinational primitives). Probably best to stick with the convention.

[daveshah1]

This has been implemented in 2851778