I2C controller: add ability to abort transactions

[Aaron-Hartwig]

A feature we need for the SPD mux testing is the ability for our controller to abort an in-progress transaction. This commit adds an abort port to the i2c_ctrl_txn_layer entity which will react to a pulse of that signal. In practice this means if the controller is writing it will send a STOP instead of the next bit. When reading, the controller will finish reading the byte, NACK, and then send a STOP.

[nathanaelhuffman]

A couple of comments on whether you're intending to us current registered state vs forwarded comb next state logic in some conditionals, otherwise looks fine.

[nathanaelhuffman]

One challenge with the variables and registers is that when you compare a variable, you're building a combinatorial path between that and your checking logic. If you need access to this variable the same cycle it was set, this is correct and acceptable, but if you intend to look at it one or more clock later, you're better off using the sm_reg. value as you'll get it as an output from the register.

You have a mix of these in this block, and while it may be what you intended, it is unclear why you'd pick the variable value or the registered value in some cases. Suggest evaluating and adding clarifying comments as needed. I'll point out some below.

The general pattern should be use the register value unless you need to same-cycle value. I didn't fully analyze this to decide which was needed here.
I find that auto-complete has a harder time when the register isn't named "r" and often substitutes v when I'm writing in this style which can lead to typos.

[Aaron-Hartwig]

I'll add a clarifying comments up where I drive the signal. My intention is to check it on the combinatorial path (the two cases where I use registered version don't make sense to me anymore with a fresh brain). I understand the timing pressure implications but I want to attempt to react to the abort as quickly as possible since it is not as simple as "we could just do it next cycle" because we cannot always just send a STOP. This is an optimization to catch the situation where we'd otherwise be transitioning to a new state and would not evaluate our ability to send a STOP again for some amount of time. It really doesn't make a lot of sense outside of the FastMode+ use case since there our usual FPGA clk cycle is a meaningful amount of time, so if it is causing problems I'll revisit this later.