Add schema checks to make sure all block have metadata

[mithro]

In this repository all the <pb_type> objects should have a metadata tag which contains;

<metadata>
  <meta name="type">xxxx</meta>
  <meta name="subtype">xxxx</meta>
</metadata>

It should also check that the type + subtype values are valid.

[mithro]

Previously it was;

Names are of the form XXX_YY-aaaaaa where;

• XXX is the high level type of the block. It should be one of;

  • BLK, for composite blocks,
  • BEL, for primitives which can not be decomposed, or
  • PAD, for special input/output blocks.

• YY is the subtype of the block. It is dependent on the high level block type.

• aaaaa is the name of the block. The name should generally match both the file and directory that the files are found in.

• BLK_MB-block_1_name-block_2_name - BLOCK which is a "mega block". A "mega block" is a top level block which is made up of other blocks.

• BLK_XX-name - BLOCK which is the hierarchy. Maps to BLK_SI -> SITE and BLK_TI -> TILE in Xilinx terminology.

• BLK_IG-name - BLOCK which is ignored. They don't appear in the output hierarchy and are normally used when something is needed in the description which doesn't match actual architecture.

• BEL_RX-mux_name - BEL which is a routing mux. Routing muxes are statically configured at PnR time.

• BEL_MX-mux_name - BEL which is a mux .

• BEL_LT-lut_name - BEL which is a look up table.

• BEL_MM-mem_name - BEL which is a memory.

• BEL_FF-ff_name - BEL which is a flip flop (FF).

• BEL_LL-latch_name - BEL which is a latch (LL).

• BEL_BB-name - BEL which is a black box (BB).

• PAD_IN-name - A signal input location.

• PAD_OT-name - A signal output location.

[mithro]

I think the valid types are;

• bel
• block

If type is bel then valid subtypes are;

• routing - Routing mux
• lut - Lookup table.
• flipflop - Lookup table.
• memory - Memory.
• blackbox - Black box object.

If type is block then valid subtypes are;

• tile
• slice
• ignore

[mithro]

@Laksen do you know how to do this?

[Laksen]

@mithro not sure. Can you give an example of a valid metadata block?

[mithro]

@Laksen In words it would be;

• A <pb_type> tag should contain a <metadata> tag.
• A <pb_type> with a <metadata> tag should have a <meta name="type"> and a `<meta name="subtype">
• <meta name="type"> text value should be one of bel or block
• If <pb_type> has <meta name="type>block</meta> then the text value of <meta name="subtype"> should be tile, slice or ignore.
• If <pb_type> has <meta name="type>bel</meta> then the text value of <meta name="subtype"> should be routing, lut or flipflop, ....

Valid example;

<pb_type>
 <metadata>
   <meta name="type">bel</meta>
   <meta name="subtype">routing</meta>
 </metadata>
</pb_type>

Broken example -- missing <meta name="subtype">;

<pb_type>
 <metadata>
   <meta name="type">bel</meta>
 </metadata>
</pb_type>

Broken example -- <meta name="type"> text value is invalid;

<pb_type>
 <metadata>
   <meta name="type">random</meta>
   <meta name="subtype">routing</meta>
 </metadata>
</pb_type>

Broken example -- <meta name="subtype"> text value is invalid for <meta name="type">block</meta>;

<pb_type>
 <metadata>
   <meta name="type">block</meta>
   <meta name="subtype">routing</meta>
 </metadata>
</pb_type>

[Laksen]

@mithro Can the metadata contain other meta tags? Is it okay to enforce ordering (subtype meta tags should follow type meta tags)?

[mithro]

@Laksen Yes, it can contain other <meta name="xxx"> values.

[mithro]

@Laksen I think enforcing ordering should be fine?

[Laksen]

@mithro Hmm. Don't think it's possible with a version 1.0 schema

[mithro]

@Laksen Should be able to enforce some parts (like must have a <metadata> and <meta name="type"> tags).

[Laksen]

You can guarantee that there should be a meta element with that name and that type attribute. But nothing more really. It's very context sensitive and not good xml, from reading about it.

Could the overall design be changed?

[mithro]

@Laksen How would you suggest it be changed?