WIP: Automated pack patterns

[acomodi]

This PR addresses #89, and builds on top of #75.

It tries to add automation in the pack patterns generation without requiring the (* pack *) attribute added to the wire for which tha pack_pattern needs to be generated.

The implementation takes care also of the propagation of the pack pattern only to the first level of children pb_types, modifying the already generated XML to add the pack pattern.

TODO:

• Add more tests specific to the pack pattern generation
• Fix the documentation accordingly

[mithro]

The implementation takes care also of the propagation of the pack pattern only to the first level of children pb_types, modifying the already generated XML to add the pack pattern.

Could you explain this a little more?

[mithro]

Why is the (* carry *) removed here?

[acomodi]

As far as I understood, carry was used to generate a pack pattern itself. I am not sure why this needed to be handled in a special case, but with the new code, the pack pattern should be automatically detected.

[mithro]

Why is the order changing here? I think these use to be alphabetically sorted?

[mithro]

I would probably call this some "internal and top"?

[acomodi]

Could you explain this a little more?

@mithro Sure.

In v2x the pb_type/model generation is an iterative step, where the hierarchy must be generated from leaf pb_types to the top-level ones.

For instance, if a top-level pb_type is to be generated, all its children needs to be already generated in a previous step, and those will be added as <xi:include>s.
This poses an issue with the pack_pattern automatic generation, as, if a wire on a top-level pb_type (or intermediate pb_type) requires a pack_pattern, than the whole path of direct connections of its children pb_types (that are included with <xi:include> require the addition of the same pack_pattern.

In the above example, there is a three level hierarchy

• LOGIC
  • SLICE_MODES
    • MODE 1
    • MODE 2
  • FLIP FLOP

At the moment of generation of the LOGIC the SLICE_MODES one has already been generated, hence we need to modify it to add the pack pattern required to connect the SLICE_MODES to FLIP FLOP. If the additional pack pattern in SLICE_MODE is not added, VPR throws an error as it would not be able to find the source block for that pack pattern.

[mkurc-ant]

I have one concern about modifying already generated XMLs. What if such XML is included by more than one pb_type? Say you have a single FF model used in two places in the arch (eg. different modes). For such a case different pack-pattern names may be required. So effectively the included XML would need to be duplicated.

[mithro]

I have one concern about modifying already generated XMLs. What if such XML is included by more than one pb_type? Say you have a single FF model used in two places in the arch (eg. different modes). For such a case different pack-pattern names may be required. So effectively the included XML would need to be duplicated.

We should not be modifying already generated XML.

[acomodi]

We should not be modifying already generated XML.

@mithro I think that we would need to duplicate the XML then, as @mkurc-ant suggested. And change the reference in the top level pb_type to include the newly generated child with the pack patterns.

[mithro]

In v2x the pb_type/model generation is an iterative step, where the hierarchy must be generated from leaf pb_types to the top-level ones.

For instance, if a top-level pb_type is to be generated, all its children needs to be already generated in a previous step, and those will be added as <xi:include>s.
This poses an issue with the pack_pattern automatic generation, as, if a wire on a top-level pb_type (or intermediate pb_type) requires a pack_pattern, than the whole path of direct connections of its children pb_types (that are included with <xi:include> require the addition of the same pack_pattern.

This is what the https://github.com/SymbiFlow/vtr-xml-utils/blob/master/vtr_xml_utils/resources/pack-patterns.xsl and https://github.com/SymbiFlow/vtr-xml-utils/blob/master/vtr_xml_utils/resources/convert-prefix-port.xsl are suppose to achieve?

GitHub

SymbiFlow/vtr-xml-utils

Contribute to SymbiFlow/vtr-xml-utils development by creating an account on GitHub.

GitHub

SymbiFlow/vtr-xml-utils

Contribute to SymbiFlow/vtr-xml-utils development by creating an account on GitHub.

[mithro]

See also https://github.com/SymbiFlow/vtr-xml-utils/blob/master/tests/convert_and_merge_composable_tests/composable-interconnect-pack_patterns.xml

GitHub

SymbiFlow/vtr-xml-utils

Contribute to SymbiFlow/vtr-xml-utils development by creating an account on GitHub.