jvansomeren
commented
2 years ago Part of the problem is existing practice: some json files for cc and for diamond use a space as separator in the key in the gate_decomposition section and/or in the sub instructions. Are the following used:
- src/ql/arch/cc/resources/hwconf_default.json
- tests/cc/cc_s5_direct_iq.json
- src/ql/arch/diamond/resources/hwconf_default.json
Nowhere in the code is checked when reading a json file what is the case. Only some sanitation is done: removal of redundant spacing. Resulting keys are accepted and stored in the instruction_map. When finding keys on gate creation in the instruction_map, a comma without spacing is required, hence those finds fail.
wvlothuizen
In old style configuration files in the instruction and decomposition sections keys (and decompositions) contain gates with operands. Those operands are identifiers such as q0, %0, etc. In those keys and decomposition sections, those operands are separated by a single comma optionally with spaces around them (that is the way that OpenQL accepts those rules). But when those commas are omitted and only white space separates those operands, OpenQL cannot match those keys with actual gates with operands and/or when in decomposition rules operand separation no commas are used, the generated gates cannot be matched with instruction and decomposition rule keys. The end-effect is that particular gates are not decomposed and end up in the resulting qasm or at the entry of the code-generator. Examples have been seen of such behavior with cnot and swap gates (because these are the ones that occur often and need decomposition, also because swap decomposes to cnots).
Exactly which absence of commas is accepted and which result in non-matching has not been investigated yet. What has been done, is a consistent replacement of sole white space by commas, which worked out well.
So the following are suspect in the decomposition section:
And in the instructions section:
What needs to be done: