Finite State Machine

A project log for SPI4C

It's not SPI, I2C or I3C, it's another protocol with full duplex self-clocked links with 2×2 wires that is rich and easy to implement.

yann-guidon-ygdesYann Guidon / YGDES 08/28/2022 at 14:234 Comments

Paul's comments made me realise that what I thought was obvious, well, wasn't. One has to carefully read the chronograms to understand the signals and their sequencing. After a while, I found a much better representation and use it now as the project's avatar:

Trits are transmitted by changing the line's state. If you send a data bit, you move along an edge and change one output line.

If you send ACK then you change both lines, which translate in this FSM by moving across the diagonal.

There is no "idle" state, just the current state... It's some pretty simple signaling, right ?

All the rest is derived from this.


Paul wrote 08/28/2022 at 23:02 point

As far as naming, I think the finite state machine kind of looks like a spiderweb. 

SPIDER or Spider would be a cool name but has several problems:

1. For SPIDER it basically has to be an acronym, and that's a long acronym

2. For either, they both start with "Spi", which isn't great since it's unrelated

3. Technology already has a lot of spider-related naming as a result of The Worldwide Web

4. Doesn't relate the advantages of the protocol, nor anything about how it works

Something like TritSpider might be cool since it solves a few of these.

  Are you sure? yes | no

Yann Guidon / YGDES wrote 08/29/2022 at 13:27 point

Choosing a GOOD name is hard, yes...

I'd like it to have the number 4, or 2×2 in the name to express the nuber of wires.

Ideally it's short and not necessary an existing word (they are all trademarked anyway)

But the ACK issue is more pressing for now.

  Are you sure? yes | no

Paul wrote 08/28/2022 at 22:50 point

Yes, this would be very useful for someone being introduced to the protocol.

In my initial post I didn't yet understand where in the protocol the XOR took place - I believed the 2-bit values corresponded to levels of the wires, and the data bit transmitted was XORed with the previously transmitted bit.

I did not yet realize the existing output wire state gets XORed with the two-bit value to produce the new wire state. The "idle" (00) I was looking at before just denotes "no wire change" and as such isn't really a state. ACK(11) indicates both wires flip, and 0/1 each flip a wire.

Sending a bit is considered an acknowledgement, correct? So, ACK will be transmitted only if there are no bits to send.
So, when there are no data bits for either device to transmit, the devices ACK back and forth indefinitely, correct? This would make sense to me.
Probably a delay should (optionally, for the protocol spec this would only be a recommendation, in IETF terms a "MAY") be inserted for an ACK of an ACK to reduce pointless power draw incurred by running the lines at full speed and transmitting no data. By inserting delays for acknowledgement in that case, the data rate (+power consumption) will be artificially reduced while there is no data going either direction. Acceptable delays would probably depend on the use-case's latency sensitivity. 

  Are you sure? yes | no

Yann Guidon / YGDES wrote 08/29/2022 at 13:15 point

I think that now you nailed it. The 2nd part however is still "work in progress" that I must address in a coming log. And now that I see better how to explain the system with FSM diagrams, it will be more formalised :-)

  Are you sure? yes | no