[pre-RFC] Ideas for an I2C peripheral interface on Wishbone

[galibert]

I feel the need for a way to configure the i2c-controlled devices I have on my fpga board from a wishbone bus driven by a cpu core. That means a single master and no real surprises on the bus, everything documented (hopefully) and no collisions. So the question has been what the wishbone-level interface would be to keep the complexity as low as possible in both the cpu code and the module implementation. There's also an idea of "you pay for what you need and no more".

The ideas I currently have:

• prescaling, or baud rate in general, should be separated from the module. The module would take an enable line at (probably) 4x the i2c clock rate which would select the wishbone bus clock edges. That enable would be generated by an otherwise independant divider module that can take multiple forms (fixed divider, multi-frequency, fully-programmable) and can be used for anything else that need that kind of thing (timers, uart, etc).
• the module should provide serialization/deserialization (because cpus suck at that) and start/stop management and also clock stretching, ack recognition and other fun.

A possible starting point on the interface:

• two or three 8-bit ports (e.g two addresses)
• writing to a port sends a byte over the wire, after a start signal if the bus was idle
• writing to a port while a byte is currently being sent blocks (no wishbone ack) until said byte is done
• reading from a port blocks reading a byte from the wire and returns the result
• the first port starts or continues a transmission. The second port adds a stop and bus idle after the transmission is done (e.g. it's used for the last message byte). The (optional?) third port does a repeated start (Sr)

Advantages of the interface:

• writing a smbus-ish register is "*port1 = address; *port1 = register; *port2 = data;". Reading is "*port1 = address; *port1 = register; return *port2;". So the code is simple.
• the module code isn't particularly complicated either

Disadvantages:

• No handling of NAK/No device at that address. Bus error seems heavy. Interrupt is annoying. Status byte maybe tellings things are not ok?
• Not a good interface for interacting with a drq-driven dma module. The DMA module would end up locking the bus until the transfer is done unless a crossbar is available, and that's expensive

Any ideas to complement/replace that one?

[tannewt]

Is the idea to do wishbone transactions over I2C? So Wishbone -> I2C -> Wishbone?

[whitequark]

No, a Wishbone peripheral implementing an I2C controller.