Intermediate transaction representation

[ginty]

#18 discusses an internal intermediate representation of pattern vectors, but I'm wondering if we should have similar (or expand that) for transactions?

O2 definitely needs to have as good a story on protocol aware type outputs as it does on vector level.
However, one of the things I've always struggled with a little bit with a pure transaction-level patterns is that there are often times when a pattern needs to do some pin manipulations that are not part of a transaction - e.g. to enter mode, or to test some pin feature after it has been enabled by some transactions.

Therefore, I'm wondering if transactions should also be handled as part of #18, where we have a StartTXNAction and an EndTXNAction.

The StartTXNAction would contain the generic info about the transaction, like address/data/protocol/length, and the EndTXNAction would simply be to identify the end of the pin operations generated by the transaction.

When it came to rendering, a vector level target would largely ignore the transaction actions, except maybe to turn them into comments, and it would proceed to implement the pin actions that occur between Start/EndTXN actions.

A protocol-level target on the other hand would do the opposite - render the transaction but ignore all the pin actions contained within it.
It will then have to decide how to handle the pin actions that are outside of transaction blocks - e.g. either handle them if it can, or turn them into comments, or ignore them.

That seems like it should work well and would naturally enable front-end code that could target either vector-level or transaction-level output on the back end.

It would also work with front end code that didn't generate pin-level info and would therefore only work with a transaction-level target.
In that case the Start/EndTXN actions would have no pin-level actions between them.

[ginty]

Along similar lines, we should probably also put StartRegAction and StopRegAction actions into the list.
That would mean we could also easily support register-level downstream consumers in addition to specific protocols.

[ginty]

O2 patgen will use a full AST representation which will support cycle-level and PA outputs being generated from the same AST.
See this PR for details - #92