Back in the day (1990s), I worked for a company whose primary product was a piece of telecom equipment that was constructed as a rack of cards in a 3-U rackmount chassis (17" wide). A backplane ran across the width of the box about 3/4 the way back, with logic cards plugged into the front and I/O adapter cards plugged into the back.

Physically, the logic cards used the same card-edge connectors as the STD bus, with 56 fingers, but the signal assignments were completely proprietary.

I needed to come up with a way to communicate between a "master" card near one end of the chassis and all of the other "channel" cards, using at most 4 signal pins that we could identify as "spares". I looked at both I2C and SPI, and ended up inventing my own "SCB" (Serial Control Bus) protocol that implemented what I saw as the best features of both: separate "data in" and "data out" lines like SPI that allow higher speeds with no turn-around issues, but device addressing built into the protocol like I2C.

The backplane already had a continuous 6.176 or 8.192 MHz clock signal, so I just needed three additional pins — the aforementioned data in and data out, plus a "sync" signal that marked the beginning and end of bus transactions. The master card and most of the channel cards had small Actel FPGAs that implemented the protocol hardware, but it was simple enough that it could be done in TTL or a CPLD if necessary.

Anyway, getting back to your own project, I mainly wanted to say that the system generally worked quite well. The biggest problem we had was getting clean edges on the clock — since it was a pre-existing signal, I had no control over things like crosstalk with other nearby signals. I ended up adding a glitch filter inside the FPGA to clean it up.

And I agree with the others regarding the DIN 41612 connectors — they should work fine in an application like this. You've already identified the necessity of buffering on the cards to keep the backplane stubs short. Just keep in mind that the total end-to-end propagation delay will be a factor in how fast a clock you can use.

Back in the day (1990s), I worked for a company whose primary product was a piece of telecom equipment that was constructed as a rack of cards in a 3-U rackmount chassis (17" wide). A backplane ran across the width of the box about 3/4 the way back, with logic cards plugged into the front and I/O adapter cards plugged into the back.

Physically, the logic cards used the same card-edge connectors as the STD bus, with 56 fingers, but the signal assignments were completely proprietary.

I needed to come up with a way to communicate¹ between a "master" card near one end of the chassis and all of the other "channel" cards, using at most 4 signal pins that we could identify as "spares". I looked at both I2C and SPI, and ended up inventing my own "SCB" (Serial Control Bus) protocol that implemented what I saw as the best features of both: separate "data in" and "data out" lines like SPI that allow higher speeds with no turn-around issues, but device addressing built into the protocol like I2C.

The backplane already had a continuous 6.176 or 8.192 MHz clock signal, so I just needed three additional pins — the aforementioned data in and data out, plus a "sync" signal that marked the beginning and end of bus transactions. The master card and most of the channel cards had small Actel FPGAs that implemented the protocol hardware, but it was simple enough that it could be done in TTL or a CPLD if necessary.

Anyway, getting back to your own project, I mainly wanted to say that the system generally worked quite well. The biggest problem we had was getting clean edges on the clock — since it was a pre-existing signal, I had no control over things like crosstalk with other nearby signals. I ended up adding a glitch filter inside the FPGA to clean it up.

And I agree with the others regarding the DIN 41612 connectors — they should work fine in an application like this. You've already identified the necessity of buffering on the cards to keep the backplane stubs short. Just keep in mind that the total end-to-end propagation delay will be a factor in how fast a clock you can use.

¹ This was configuration and status information, not payload. The idea was to add a remote control capability to cards that up to this point had been configured by DIP switches and showed their status on front-panel LEDs.