Support for printf

[leonardt]

Project Repo: https://github.com/bjmnbraun/icestick_fastio
Final Paper: fastio_final_paper.docx

Example printf app: https://github.com/bjmnbraun/icestick_fastio/blob/master/test/src/printf_app.py

[leonardt]

Wasn't super happy with the architecture and interface for this. Mainly it's a bit clunky to use (requires preprocessing and compiling a C file) and it sacrifices ease of use and simplicity for speed (makes sense for streaming input/output data, but for printf debugging I think we should focus on simplicity and ease of use).

My proposed interface is:

icestick = IceStick()
icestick.Clock.on()
main = icestick.main()
c1 = Counter(2)
c2 = Counter(4)
icestick.printf("c2.O = {}", c2.O).when(c1.COUT)
compile("printf", main)

Which would emit a circuit to send the format parameters over the board's communication mechanism (in this case the UART) with a unique tag corresponding to each printf call (and it's unformatted string parameter) whenever the condition is met. Mantle would also emit a configuration file for the host display driver that associates unique tag to unformatted string (probably just a pickled python dictionary). The host display driver will monitor the port for messages of the form (start_byte, "unique id", format parameters..., end_byte). Whenever it receives a message it will look up the unformatted string and print a formatted version with the parameters.

Design issue: Message format (need to consider reliability and speed). I'll probably start with a simple framing approach with start/stop/escape bytes for simplicity.

[leonardt]

I have a minimum working example for the icestick that can be found at https://github.com/leonardt/silica/tree/master/examples/printf/magma

I will work on extending it to be more robust, particularly with tight integration to loam (each board will need it's own transimit logic depending on the available IO hardware), as well as convenience features such as multiple format arguments). Further extensions could include a buffering mechanism for messages that are sent a high rate (although is this even useful? perhaps to collect waveforms, but in that case maybe we should have an explicit mechanism for capturing waveforms from a board). I will track future issues/enhancements in the silica/loam repos.