New hardware adoption workstream

workstreams/Hardware_Adoption_Workstream.md

@@ -0,0 +1,57 @@
+# Workstream: QIR Adoption by Hardware Companies
+
+## Motivation & Benefits
+
+The goal of QIR is to provide a representation which can connect any piece of
+software with any piece of hardware. It is therefore vital to make sure that
+it fits the needs of hardware manufacturers, so that QIR becomes a de-facto
+standard.
+
+The goal of this workgroup is to gather hardware manufacturers who are already
+using QIR for their needs, or are thinking about doing so, in order to identify
+valuable developments that will support QIR adoption by quantum computer
+manufacturers.
+
+## Requirements
+
+To be determined
+
+## Dependencies & Related Projects
+
+To be determined
+
+## Deliverable(s) & Expected Outcome
+
+To be determined
+
+## Future Work (Out of Scope)
+
+To be determined
+
+## Working Group & Getting Involved
+
+Working group participants: Jean Senellart, Stefan Wernli, Amos Anderson,
+Julien Dumazert...
+Working group chair: Laurent Prost
+
+If you would like to contribute to the workstream, please contact
+[[email protected]](mailto:[email protected]) and / or
+[Laurent Prost](mailto:[email protected]).
+
+## Schedule
+
+Launch date: <br/>
+Estimated end date: <br/>
+Meeting schedule and/or channel(s) of communication: 1st meeting planned on
+September 8th
+
+## Status & Discussions
+
+Current status: Workstream has been approved.
+
+The work and status will be tracked in the form of a [GitHub
+issue](https://github.com/qir-alliance/qir-spec/issues/11) on the [specification
+repository](https://github.com/qir-alliance/qir-spec). We encourage comments,
+inputs, and discussions on that issue.
+
+## Open Questions

workstreams/hardware-adoption/minutes/2023-09-08.md

@@ -0,0 +1,57 @@
+# Hardware adoption committee 2023-09-08
+
+## Attendance
+
+- Jean Senellart (Quandela)
+- Sonia Pignorel (Microsoft)
+- Andrei Petrenko (QCI)
+- Tom Lubinski (QCI)
+- Stefan Wernli (Microsoft)
+- Amos Anderson (QCI)
+- Bettina Heim (Nvidia)
+- Bill Ticehurst (Microsoft)
+- Laurent Prost (Alice & Bob)
+- Julien Dumazert (Alice & Bob)
+
+## Meeting agenda
+
+- Presentations by companies
+- Discussion of companies needs and next steps
+
+## Notes
+
+- See presentations folder fo slide decks
+- Topics discussed:
+  - How to handle the different gate sets allowed by the providers?
+    - Possible solution #1: Shift responsiblity to transpile to hardware native
+      gate set from frontend compiler / high-level framework to hardware
+      provider
+    - Possible solution #2: Standardization of known gates so that frontend
+      compilers know most of the gates used by most hardwares
+  - QIR computational model based on sequences of discrete gates doesn't
+    support all styles of hardware control (ex: pulse-based control of
+    superconducting circuits). Should QIR be extended? Or should it stick to
+    gate-based control?
+  - Should QIR include high-level algorithms like QAOA? Ex: the frontend
+    compiler / high-level framework asks for QAOA and the responsibility to
+    implement QAOA is with the hardware provider. "Users care about
+    applications, nobody wants to run a CNOT."
+  - How to increase adoption of QIR by the quantum community and in particular
+    hardware providers?
+    - Possible solution #1: increase interoperability of QIR by improving
+      translations from/to Qiskit and QASM (major frameworks). In practice,
+      this means improving qiskit-qir and qcor.
+    - Possible solution #2: focus a sub-community like hybrid computing, which
+      QIR seems to be well-suited for
+  - Do end users want low-level control?
+    - Interest for low-level control is in academic groups, but it is risky
+      for hardware providers to cater to that crowd before they have secured
+      public grants to fund developments
+
+## Next steps
+
+- Organize another meeting of 1.5 hours in 3 months
+  - Topic: balance between standardization and specialization of QIR
+- Upload hardware providers presentation to GitHub folder
+- Find a way to create a discussion group to facilitate discussions (e.g.,
+- mailing list, Slack channel, etc)

workstreams/hardware-adoption/minutes/2023-12-08.md

@@ -0,0 +1,61 @@
+# Hardware adoption committee 2023-09-08
+
+## Attendance
+
+- Tom Lubinski (QCI)
+- Fabrice Frachon (Microsoft)
+- Stefan Wernli (Microsoft)
+- Ian Davis (Microsoft)
+- John Dumbell (OQC)
+- Kajsa Eriksson Rosenqvist (OQC)
+- Jamie Friel (OQC)
+- Kalan Snyder (Rigetti)
+- Spencer Churchill (IonQ)
+- Patrick Deuley (IonQ)
+- Joe Latone (IonQ)
+- Coleman Collins (IonQ)
+- Julien Dumazert (Alice & Bob)
+- Amos Anderson (QCI)
+- Andrei Petrenko (QCI)
+
+## Meeting agenda
+
+- Presentations by OQC and IonQ
+- Open discussion on QIR current and envisioned usage
+
+## Notes
+
+- See presentations folder fo slide decks
+- Topics discussed:
+  - Different actors pulling QIR in different directions (hardware providers,
+    physicists, compiler engineers, etc)
+  - Two main types of usage for QIR:
+    - As an input language to a hardware service.
+      - In this case, QIR is usually parsed and transformed into an internal
+        language of the hardware provider
+      - Usually, this is used by services who use the base profile and/or do
+        not support mixing classic and quantum primitives
+    - QIR is linked at runtime and executed on the hardware control system of
+      the hardware provider
+      - In this case, an in-house hardware control system is the norm (by
+        opposition to an external solution like Quantum Machines)
+  - A vision: "QIR as a logical schematic"
+    - In this vision, the user expresses a high-level intent in QIR, and the
+      compiler of the hardware provider then optimizes the user program for
+      execution on their hardware
+    - This vision pushes towards adding more high-level primitives in QIR, so
+      that the user includes less low-level logic in their QIR program (e.g.,
+      quantum gates)
+  - Another need for QIR: embedding assembly in QIR
+  - The implicit objective of QIR to be universally portable makes sense, but
+    in the short term hardware providers need ways to fine-tune execution of
+    QIR on their machines. Today users wants to express precise sequences of
+    gates in QIR.
+  - QIR would benefit from having a public roadmap
+
+## Next steps
+
+- Organize another meeting of 1.5 hours in 3 months
+  - Topic: what is the right level for quantum primitives in QIR?
+- Upload hardware providers presentation to GitHub folder
+- QIR alliance to discuss the topic of a public roadmap