prasimix / dib-v2 Goto Github PK

Introduce new pins (TCK, TDO, TDI, TMS) that will be used for daisy-chained JTAG. That will enable on-board programming of devices that require JTAG (e.g. FPGA).

This task is initiated by mentioning isolated Ethernet in #4. It does not require immediate attention, but should be of interest when we exceed BB3's three modules limit (better sooner, then later :).
The next chassis could be "signaling" only, i.e. does not include space for AC/DC conversion, TFT display and can in that case house 6 to 7 modules. One of them should be "slave" module capable to communicate with master chassis (one that has "local console").
Existing BB3 MCU module provides only 10/100 Mbits Ethernet and USB 2.0 as mean of communication with external world. Perhaps it Ethernet could be replaced with our "Ethernet" alternative.

One of possibility I had in mind is token ring with
differential I/O, minimal signaling (maybe clock only)
and variable data bit length in terms of 2^n so it could
be 1-bit 2-bit etc up to 32-bit bus.

mixed bit width devices can co-exist in the same ring but then for
example if a 1-bit device is inserted inbetween A and B 32-bit nodes
then 32-bit node A must be serialize traffic to 1-bit and
32-bit node B must de-serialize it to 32-bit again.

This will introduce latency and reduce speed but will be
flexible to let it work. When number of devices are small
like 2-8 it is very efficient reliable and low cost

Token ring has advantage to re-generate signal quality after
each node so it should be less prone to noise and it makes
node wiring simple and no additional chips for bus transievers,
hubs and switches.

The BB3 chassis comes with backplane that is designed in line with DIB v1.0 specification. A few DIB v1.0 compatible modules are available, and more are coming in the future. Backward compatibility protects existing investment, and also provides more choice for building bench lab based od DIB v2.
Therefore we should take that into account, and I can see at least two possibilities that are not mutually exclusive:

1. Introduce new connector for DIB v2 hi-speed signaling (based on the #3 proposal or something else). There is a lot of room in the BB3 chassis and it could be simply placed in line with existing module connectors. For communication with "legacy" modules existing dedicated SPI buses will be used. Of course, new hi-speed modules can also use that part for less demanding communication (status acquisition, devices control and configuration, etc.).
2. Reuse existing SPI lines on the DIB v1.0 to become "general purpose" or "chameleon" type of thing where master ("MCU") module could adapt signaling in accordance with peripheral module capability that can be negotiated at the startup over shared I2C bus. That approach is limited by master module capability to assign communication protocol "on-demand" over the same set of I/O pins (that asked for FPGA instead of general purpose MCU). More serious limitation represents different electrical requirements for different communication type (e.g. LVDS need rx/tx devices with differential pairs that operates on different voltage levels then SPI, etc.).
   At least we can try to provide chameleoning to greatest possible extent.

In summary, backward compatibility i.e. offering an infrastructure that allows mix of lo- and hi-speed should be taken into account, but that is not an imperative and shouldn't become a show stopper to define a versatile and appealing hi-speed bus for DIY/maker/students audience.

@emard, we've discussed about need of master/reference clock for peripheral modules if they have FPGAs deployed since it could be more cost efficient and accurate to introduce master clock on the new master ("CPU") board then to use separate oscillators on each modules and take extra care about inter-module sync. Question is what clock frequency to use (e.g. VXI is using 10 MHz, but ULX3S use 25 MHz) and what price/accuracy class?

What kind of isolation can be deployed to isolate communication between master module and peripheral modules, and between two or more peripheral modules? Perhaps we could use:

• AC-coupled LVDS (check if DC balancing has to be added)
• Optical barrier using Rx/Tx pairs used to drive fibre optic cable.