Remove voltage translators for the M-LVDS inputs

MLVDS circuit could be simplyfied by using the separate receiver/driver signals from the M-LVDS and using different pins for input and output in the FPGA. This would remove the need for bus direction selection, and the FPGA gateware can just ignore the inputs when transmitting in the channel.

In this manner, we could employ the 8-bit SN65MLVD082 (or 080 for Type-1 receiver), allowing for better skew between channels (350ps, before it was 800ps), specially in the reception, as the voltage translation from the 3.3V M-LVDS driver to the 1.5V bank could be done by using only resistors and/or fast diodes.

The output would still need a voltage translator, but this can be unidirectional and do not need to be controlled by the FPGA. NXP 74AVC8T245 has 8 channels and allow for data rates above 200Mbps in this application. To avoid glitching the bus while programming, this translator OE could be set up as proposed in issue #87 (closed).

This would also simplify schematics, and the faster transition between receiving and sending could allow for better reuse of the bus for trigger signaling. And this modification would not need demand more pins in the FPGA. The main downside would be the lost of the ability to switch between Type 1 and Type 2 receivers dinamically, as the 8-pin MLVDS options have only one receiver option.

Let me add a little bit more context here. Discussing with colleagues at FRIB we learned that AFC M-LVDS circuitry could be improved for timing-sensitive applications (such as those found in FRIB) if 2 new conditions could be satisfied:

1. Provide an option (dynamic or by assembly variant) of fail-safe Type-2 M-LVDS tranceiver. This can be done on SN65MLVD040 via FSEN input, but this pin is currently not connected on AFC v3.1.

2. Skew between M-LVDS channels below 0.5 ns (ideal) or 1 ns.

A third requirement is already fulfilled: operate at rates around 100 Mbps. The current circuit should allow 250 Mbps.

What @gustavo.bruno suggests seems to meet those more stringent requirements in an elegant way. After discussing with FRIB we see no reason why not use Type-2.

Could we all converge to Type-2 for the default AFC assembly?

beware of bi-directional level translators. They are fragile to line termination - reflection spike can switch the direction. We already had issues with SPI on FMC. Avoid them if possible.

To limit the number of wires, just use SPI extender like HC4094

from FPGA side it needs just clock generator, serial register and counter. 15LEs is enough to implement it.

Currently, we have selectable direction translators in MLVDS lines. The idea is to have single-direction translators, just in the TX. We would keep using the same number of FPGA pins, the direction selection being changed to TX lines. I don't see why we would want an extender - we have currently about 40 GPIOs unused in the FPGA.

Converging to Type-2 sounds good. If we have an assembly option to go for Type-1 then I see no reason not to apply this in v4.

assigned to @tprzywoz

Great. The selection between Type-1 and Type-2 is easily done by selecting which IC to solder, SN65MLVD080 or SN65MLVD082, as you probably are already aware of.

Now, the question about whether this should be an assembly option or not, that's a good question. Since we're trying to minimize the number of variants, we could leave Type-1 as an "undocumented assembly option" instead of reserving one character in the part number for this.

We have no preference from our side. We'd be happy with any choice.

changed the description

Why do we want to change the MLVDS transceiver? We can connect one free FPGA IO (or MMC) to FSEN pin and avoid another assembly option.

This is more related with timing sensitive use cases, such as those found at FRIB (Michigan University). They need lower skew and skew drifts among channels.

So, the main argument for simplifying the level translators is "timing performance", with the trade-off of losing the dynamic selection among Type-1 and Type-2.

As a side note, I don't see any advantage in the proposed solution (Gustavo's) in terms of slew rate performance. The current circuit is already very fast. It should operate up to 250 Mbps, and it is hard to imagine someone would want to go beyond that. The SN65MLVD would cap to 250 Mbps in any case.

We would keep using the same number of FPGA pins, the direction selection being changed to TX lines.

We can't do that because we still need to drive DE RE pins of MLVDS transceiver. But there are more than 8 free IO of FPGA so we can use them.

Why would we need do drive DE and RE pins on the MLVDS if we are using separate pins in the FPGA? The RE pins can be always on (we just ignore them in the FPGA if we are sending data), and at worst the DE pins may be controlled in the same manner we control the voltage translators. Or we can just let the voltage translator off during programming as it already is and the drivers pulled.

make sure that during power on phase the transceiver outputs are Hi-Z. This is to make sure that when 3V3 wakes up first, it won't supply the FPGA rail via these voltage dividers.

Something went out of our radar for a while about this circuit. There were 2 hidden but important points to consider:

1. To enable wired-OR functionality, which is required in LNLS use cases, we should use the FPGA to assert SN65LVD082's DE pins instead of D pins. D is fixed in HIGH. It means the bus is released when we have no signal to transmit.

So, in practical terms, we should swap D and DE circuits on the above schematics.

2. The mode of operation described in (1) has a downside for timing-sensitive applications: the edge of the transmitter output when DE goes low will be slower, since it is not driven but given by the circuit capacitance. Fig. 6 of the SN65MLVD082 datasheet should illustrate this (https://www.ti.com/lit/ds/symlink/sn65mlvd082.pdf).

If high speed is required and wired-OR is not (i.e. there's only one driver on the bus), then it is probably better to command D directly while the driver is enabled (DE = HIGH).

Meeting 1 and 2 would require then 8 more pins on the FPGA (same bank) and one more SN74AVC8T.

We can also change IC28 to just placing the MLVDS_DIR circuit to the DIR input of the voltage translator for DE pins and pull them down, if this makes things any easier.

Meeting 1 and 2 would require then 8 more pins on the FPGA (same bank) and one more SN74AVC8T.

We don't have any bank where we can find 24 IO pins (for existing 16 pins + 8 additional)

8 additional lines controlling DE maybe don’t need to be the same bank. They should be fast, but probably not critical to be in sync. We can plan to use an extra clock to change DE before we trust the data.

Yes, we agree. Bank 35 could probably accommodate those 8 additional pins.

@cogansco, since your application is very timing-senstive I think you're in the best position to answer this: would you prefer to bundle D+DE in the same bank or D+R in the same bank?

There are 16 pins on bank 32 and 8 pins available on bank 35. The true question is how to make the best use of them for the M-LVDS lines.

In the currently proposed schematics the connections of ports A and B to AMC connector are not ordered in correspondence with the MLVDS 1-8 lines. AMC RX-TX ports 17-20 not being in order on SN65MLVD082 is not an issue, since this may be related to easing the routing, but I suggest at least R, D and DE ports follow the same order.

For instance, MLVDS_O_1 (and MLVDS_I_1) should be connected to 4D (and 4R), not 1D (1R), since it should be associated with AMC Port 17 Rx. Does it make sense?

mentioned in commit 9098d25e

To sum up: final conclusion is that we want to control all transceiver pins (D R DE) except RE which is ON all the time. D and R signals should be connected to the same bank of FPGA (as in our first version) and DE added to another bank. Am I right?

Yes, looks right.

I agree that is fine. DE on separate bank.

DE signals connected to bank 36. According to #87 (comment 116783): IO pin (for switching off MLVDS drivers during configuration) changed to DONE pin.

mentioned in issue #87 (closed)

mentioned in commit 0d87a553

What is the purpose of D31 and D32? Could they not be omitted or replaced with small resistor?

FPGA_DONE has pullup to P3V3 for MMC. Power supply for DIR pin is P1V5.

I assume we've reached a final version.

closed

I see now on RC6 that all AMC ports are reverse ordered on the driver MLVDS input/output (A-B ports):

• Rx17 goes to ports 8A-8B
• Tx17 goes to ports 7A-7B
• ...
• Tx20 goes to ports 1A-1B

This is no problem at all. The choice of A-B ports must be driven by the layout.

What bothers me now is that MLVDS_[DE/I/O] signals connected to DE/R/D ports are now in reversed order too.

For better readability and to avoid confusions when operating with other AMC boards in the crate, the order we prefer is:

• MLVDS_[DE/I/O]_1 : Rx17
• MLVDS_[DE/I/O]_2 : Tx17
• ...
• MLVDS_[DE/I/O]_8 : Tx20

My suggestion: assign the AMC ports 17-20 in the way you prefer to ease routing. Make the correspondent assignment on ports DE/R/D that ensures MLVDS_[DE/I/O]_1 refers to Rx17, MLVDS_[DE/I/O]_2 refers to Tx17, etc.

reopened

Was not implemented in v4.0 and I'd keep it that way. After all it's just the matter of constraints. @danielot if you disagree feel free to reopen and assign to v4.1.

closed

@msowinski, I suppose you refer only to my last comment (#131 (comment 117049)), that is, reording the labels.

Documentation has been an issue in the past and I think we should try to keep things as clean as possible. I do think it will pay off to do this minor fix.

reopened

changed milestone to %AFC v4.1

I think the main issue "Remove voltage translators for the M-LVDS inputs " was already done. The only thing left seems to be the label reordering. Can we open a new issue for that and target at the next AFC version?

Makes sense!

@msowinski @tprzywoz Is it ok if we do this?

mentioned in issue #180 (closed)

Made a #180 (closed) , so yes :-)

closed

Nice. Thanks! =]

changed milestone to %AFC v4.0

Since we closed this one considering the label reordering is not in its scope, I moved it back to v4.0 (where the main modification was already implemented).