|
|
|
# Frequently Asked Questions
|
|
|
|
|
|
|
|
|
|
|
|
### Q: How many channels does a TTL to blocking pulse converter system have?
|
|
|
|
|
|
|
|
Six *pulse conversion* channels. Each channel has one TTL output and
|
|
|
|
three blocking outputs.
|
|
|
|
|
|
|
|
On any channel, you can input and output any combination between TTL and
|
|
|
|
blocking:
|
|
|
|
|
|
|
|
- TTL input to TTL output
|
|
|
|
- TTL input to blocking output
|
|
|
|
- Blocking input to TTL output
|
|
|
|
- Blocking input to blocking output
|
|
|
|
|
|
|
|
Flip the TTL switch (SW2.4) on the board and you can use the board
|
|
|
|
exclusively with TTL-BAR:
|
|
|
|
|
|
|
|
- TTL-BAR input to TTL-BAR output
|
|
|
|
- TTL-BAR input to blocking output
|
|
|
|
- Blocking input to TTL-BAR output
|
|
|
|
- Blocking input to blocking output
|
|
|
|
|
|
|
|
Additionally, you also have four general-purpose *inverter* channels on
|
|
|
|
the front panel. These can be used to invert a signal locally, without
|
|
|
|
having to remove the board from the rack.
|
|
|
|
|
|
|
|
As an example, if your TTL switch is set to TTL signals and you need to
|
|
|
|
repeat/convert a TTL-BAR signal, you don't need to remove the board from
|
|
|
|
the rack, flip a switch and plug it back. You can use one of the INV-TTL
|
|
|
|
channels to reverse the polarity of the TTL-BAR signal and use it to
|
|
|
|
your will. Bear in mind that if you want to *repeat* this TTL-BAR
|
|
|
|
signal, you need to use another INV-TTL channel to reverse the polarity
|
|
|
|
the CONV-TTL-BLO is outputting, since the CONV-TTL-BLO will output TTL
|
|
|
|
signals.
|
|
|
|
|
|
|
|
### Q: Can I obtain more than three blocking signals out of a single one?
|
|
|
|
|
|
|
|
Sure you can\! An example of this is covered in Appendix B.2 of the
|
|
|
|
[CONV-TTL-BLO user guide](https://www.ohwr.org/project/conv-ttl-blo/wikis/Documents/CONV-TTL-BLO-User-Guide). You can
|
|
|
|
form a daisy-chain on the front panel using the TTL channels, and use
|
|
|
|
the blocking outputs of each channel to repeat your signal. Like this,
|
|
|
|
you can repeat one blocking signal into a maximum of 18. Keep in mind
|
|
|
|
there is a delay of 80 ns associated with each channel.
|
|
|
|
|
|
|
|
Should you want to repeat one TTL signal into more, you can do the exact
|
|
|
|
same thing in reverse; input a TTL signal on a channel, and use the
|
|
|
|
blocking channels to make a daisy-chain. You can use this technique to
|
|
|
|
replicate one TTL signal into a maximum of six TTL signals and thirteen
|
|
|
|
blocking signals. Keep in mind there will again be a delay of 80 ns on
|
|
|
|
each channel.
|
|
|
|
|
|
|
|
*Note that if you daisy-chain the INV-TTL outputs, you might get
|
|
|
|
glitches on startup, due to a delay in the signal chain. It is therefore
|
|
|
|
not recommended to daisy-chain INV-TTL outputs.**
|
|
|
|
|
|
|
|
### Q: Are the input and output lines terminated?
|
|
|
|
|
|
|
|
The input lines on both TTL and blocking signals are terminated with
|
|
|
|
50-ohm resistors. The output lines are not terminated.
|
|
|
|
|
|
|
|
### Q: Can I uses LVTTL input levels?
|
|
|
|
|
|
|
|
Yes, the TTL input is made of a parallel 50 Ohm termination and a
|
|
|
|
[SN74LVC14AD](http://www.ti.com/lit/ds/symlink/sn74lvc14a.pdf) Schmitt
|
|
|
|
trigger inverter. The inputs are compatible to TTL and LVTTL input
|
|
|
|
levels.
|
|
|
|
|
|
|
|
### Q: What to do to have a low jitter?
|
|
|
|
|
|
|
|
When needing a low jitter on the output signal, just make sure that
|
|
|
|
SW1.1 is set in the position OFF ([User
|
|
|
|
Guide](https://www.ohwr.org/project/conv-ttl-blo/wikis/Documents/CONV-TTL-BLO-User-Guide), pages 15 and 20). With this
|
|
|
|
(default) setting the signal chain is fully combinatorial. The jitter is
|
|
|
|
then virtually 0, and negligible compared to the Blocking level signal
|
|
|
|
rise times of 75ns or more.
|
|
|
|
|
|
|
|
### Q: What is the width of a pulse output by the converter system?
|
|
|
|
|
|
|
|
The output pulse width is set to the nominal 1.2 us (see [blocking
|
|
|
|
signal
|
|
|
|
definition](https://www.ohwr.org/project/conv-ttl-blo/uploads/8ba57dff4f18540c947830f70e8c8ead/BlockingSpecification.pdf)).
|
|
|
|
|
|
|
|
### Q: What is the maximum input frequency?
|
|
|
|
|
|
|
|
The input frequency of pulses should not be higher than 4.150 kHz.
|
|
|
|
CONV-TTL-BLO boards have pulse rejection logic implemented inside the
|
|
|
|
FPGA, that limit the pulse duty cycle to 1/200. This is to protect the
|
|
|
|
blocking output circuitry.
|
|
|
|
|
|
|
|
### Q: What is the maximum input pulse width ?
|
|
|
|
|
|
|
|
On blocking channels, 4.8 us. Pulse widths longer than this value may
|
|
|
|
damage the blocking input circuitry (mainly, the optocoupler).
|
|
|
|
|
|
|
|
On TTL channels, anything up to the limit pulse period. The idea here is
|
|
|
|
to have a pulse, so that the FPGA circuitry notices the rising edge and
|
|
|
|
generates a pulse.
|
|
|
|
|
|
|
|
Note that whatever the input pulse width, the output pulse width will
|
|
|
|
always be 1.2
|
|
|
|
us.
|
|
|
|
|
|
|
|
### Q: Why is a TTL-BAR pulse generated when an upstream card powers down?
|
|
|
|
|
|
|
|
This is a natural effect with TTL-BAR. Since TTL-BAR is an active-low
|
|
|
|
pulse, and therefore the idle state is high, when an upstream node
|
|
|
|
powers down, the TTL-BAR input goes low, and this gets interpreted by
|
|
|
|
the CONV-TTL-BLO as a pulse.
|
|
|
|
|
|
|
|
The effect cannot be mitigated, but in any case crates should not power
|
|
|
|
down under normal operation.
|
|
|
|
|
|
|
|
Note that this effect only occurs under TTL-BAR pulse repetition. TTL
|
|
|
|
pulse repetition is not
|
|
|
|
affected.
|
|
|
|
|
|
|
|
### Q: Why is a TTL-BAR pulse generated when I remove a wire from the TTL input?
|
|
|
|
|
|
|
|
Similar to the question above, a pulse gets generated because we have a
|
|
|
|
50-ohm termination to chassis ground, and this termination acts as a
|
|
|
|
pull-down on the channel when a cable is not plugged in. When a cable
|
|
|
|
which carries an idle-high signal gets removed, the 50-ohm termination
|
|
|
|
pulls down the line to chassis ground, and this again gets interpreted
|
|
|
|
as a pulse on the input.
|
|
|
|
|
|
|
|
A pulse may also get generated when a the cable is plugged into the
|
|
|
|
board due to the fact that glitches are created due to imperfect
|
|
|
|
mechanical contact between the cable conductor and the connector as the
|
|
|
|
cable is plugged in. Note that even with the glitch filter enabled, this
|
|
|
|
effect is not fully removed.
|
|
|
|
|
|
|
|
By making sure no cables are removed or plugged in while the board is in
|
|
|
|
operation, this effect will not appear.
|
|
|
|
|
|
|
|
Note that this effect only occurs under TTL-BAR pulse repetition. TTL
|
|
|
|
pulse repetition is not affected.
|
|
|
|
|
|
|
|
### Q: What is MultiBoot? What is a typical MultiBoot sequence?
|
|
|
|
|
|
|
|
MultiBoot is described
|
|
|
|
[here](https://www.ohwr.org/project/conv-ttl-blo-gw/wikis/Xil-multiboot).
|
|
|
|
|
|
|
|
The typical sequence a user should run through when uploading is the
|
|
|
|
following:
|
|
|
|
|
|
|
|
1. Get the latest release gateware version from
|
|
|
|
[here](https://www.ohwr.org/project/conv-ttl-blo-gw/wikis/Releases#release-gateware)
|
|
|
|
2. Run MultiBoot to update the gateware to **flash address 0x170000**
|
|
|
|
this latest release (use for example
|
|
|
|
**software/multiboot/multiboot.py** from the
|
|
|
|
[repository](https://www.ohwr.org/project/conv-ttl-blo/tree/master))
|
|
|
|
3. Check that the updated gateware is the expected one, by reading the
|
|
|
|
gateware version from the board's SR at address 0x4
|
|
|
|
|
|
|
|
Should you want to check which golden gateware version you have, run the
|
|
|
|
following steps:
|
|
|
|
|
|
|
|
1. Run MultiBoot from a wrong address (e.g., 0x180000), without writing
|
|
|
|
a new bitstream to the flash
|
|
|
|
2. This boots back to the golden gateware version, which you should
|
|
|
|
check is the latest (by reading the SR at address 0x4) against [this
|
|
|
|
webpage](https://www.ohwr.org/project/conv-ttl-blo-gw/wikis/Releases#golden-gateware)
|
|
|
|
3. Power-cycle the ELMA crate to boot back to the latest release
|
|
|
|
gateware
|
|
|
|
|
|
|
|
-----
|
|
|
|
|
|
|
|
Theodor-Adrian Stana, Erik van der Bij, 23 July 2015
|
|
|
|
|