prasimix / DIB-v2

DIB (DIY Instrumentation Bus) v2 for hi-speed modules
0 stars 0 forks source link

Backward compatibility, how and why? #4

Open prasimix opened 5 years ago

prasimix commented 5 years ago

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 commented 5 years ago

FPGA chips have built-in differential lines so no additional chips are needed.

Apart from differential bus, other possibility would be to have something like optically decoupled ethernet which will enable each power module GND to float independently from other module's GND and of course with much better noise rejection.

On 7/16/19, prasimix notifications@github.com wrote:

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.

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/prasimix/DIB-v2/issues/4

prasimix commented 5 years ago

FPGA chips have built-in differential lines so no additional chips are needed.

Great, so what is then about "downgrading" to single-ended lines such as SPI? What can be done about that? I presume that SPI (also I2C, USART, ...) are present in "FPGA-centric" solutions, and that some standard way of utilizing FPGA resources is possible for such purposes?

Apart from differential bus, other possibility would be to have something like optically decoupled ethernet which will enable each power module GND to float independently from other module's GND and of course with much better noise rejection.

Ok, that partially answers my comment above. Yes, the galvanic isolation at least between power modules (both sourcing and/or sinking) are of paramount importance. We cannot skip that. Silabs has nice family of both 1 and 100 Mbit/s multi-line isolators (up to six in SOIC-16 narrow and wide packages). They are deployed in both EEZ H24005 and EEZ BB3 projects. But, as we already discussed, possibility to have isolated hi-speed data acquisition modules (that eventually will brings us to DSO/MSO territory) is also interesting. In that way we could offer multi-channel "floating" solution! Therefore, mentioned decopled Ethernet makes sense, and please provide more details about it (e.g. possible top speed, wiring/PCB layout, line count, etc.) that can could help us in discussion.