Biphase Mark Code Generator

Why would you care about biphase mark coding? The only reasons I can think of are:

  1. You are exploring the history of binary encoding schemes
  2. You want to poke your eyes out
  3. You have this burning need to develop hardware that uses it
  4. You want to party like it's 1998
  5. Options 3 and 4
  6. Options 2, 3 and 4
  7. Options 2 and 5

No one really deals with BMC anymore, unless they have to support a standard that requires it. Besides using it to shuffle bits around for digital audio, it probably still gets heavy use by digital television broadcasters in North America and South Korea. If you're curious as to how broadcasters use it, read on. Otherwise, skip to the hardware.

8-VSB Background

Back in the day, 8-VSB became the OTA modulation of choice for ATSC, the next-generation digital television standard for North America and South Korea. Like most other DTV standards, all information — be it video, audio, or even internet data — is shipped out via the MPEG-2 Transport Stream.

8-VSB is a bit of a misnomer. What most people accept to be 8-VSB is actually its 2/3 Trellis coded variant, 8T-VSB. However, 8T-VSB is the only modulation that OTA broadcasters currently use, and one that they'll likely stick with in the future given the need for transmission reliability. At any rate, 8T-VSB is so common that everyone just drops the T.

SMPTE-310M, which came into effect in 1998, is a synchronous serial interface dedicated to transporting an MPEG-2 TS from point to point. The data clock rate is a very particular 19.39265846 MHz. The reason this is so is due to legacy NTSC spectrum constraints placed on the 8-VSB symbol clock, as well as data framing and forward error correction measures. See the end of this entry for further reading.

Don't ask me how they arrived at 684 symbols per NTSC horizontal scan line. I would like an answer myself.

The electrical interface is pretty simple, putting bits on the line with no modulation per se. The line in question is a single standard 75-ohm BNC cable, so the physical layer is cheap and plentiful. Another advantage is that the data clock is exactly at the rate of the serialized bitstream, so there should be no need for null packet stuffing. It allows a radio transmitter to generate the 8-VSB symbol clock directly from the bitstream.

One of the disadvantages of SMPTE-310M is that it's broadcast calibre, so tight constraints are placed on the data clock. The other drawback is that a single cable can only carry 19.39265846 Mbps, which is one 720p or 1080i stream. Other standards, like DVB-ASI, can carry up to 214 Mbps of data, allowing multiple high-definition television feeds to be multiplexed into a single transport stream and carried on the same BNC cable.

SMPTE-310M boils down to two things: precise clock and biphase mark coding. For our purposes, the relevant information is that biphase mark coding requires a clock that is twice as fast as the data clock, and that there has to be a bit transition whenever there is a new bit, or if the bit being transmitted is a logic '1'.

The RTL

The BMC generator is written in synthesizable VHDL, and as a bonus, it comes with a testbench! It isn't the most useful piece of digital hardware in the world, but it was once relevant. Maybe it still is. At least, it's straightforward to think about.

What is going on?

First off, I use synchronous resets on all flops and registers, which may be of some consternation to ASIC designers. That's just how I roll, since what little digital hardware experience I have is in FPGA prototyping, and with an FPGA the synchronous reset on a flop comes free.

With that out of the way, the first thing that happens is the introduction of a toggle flop that divides the fast transmitter clock in half to replicate the data clock. This slower clock will govern the shift-register timing. That shift-register, assigned to the internal signal data, is a parallel load, shift left configuration.

The assumption is that the MPEG-2 transport stream is incoming in a parallel byte form, and the BMC generator will perform serialization and conversion. To that end, a 3-bit up counter is introduced. It's initialized to 7 so that the serializer idles until data comes in.

The BMC output is a flop that changes on new data, as well as if the bit being transmitted is a logic '1'. It's important to note that the output must flip on new data. If it didn't, a string of zeroes would flat-line the signal across the cable, which defeats the purpose of BMC in the first place.

Simulation Results

The testbench takes the 8-bit pattern found in the BMC screenshot on the Wikipedia article and feeds it to the generator. Note that the clock signal is twice is the transmitter clock which is twice as fast as the data clock.

ModelSim waveform for bmc_tbModelSim signal waveform for bmc_tb

I'm thinking you might want to open the image in a dedicated tab.

Note that the output BMC flop transitions line up with the Wikipedia screenshot. It's got to be working if that's the case! Okay, maybe not. If you're serious about testing this, get yourself an FPGA, a 19.39 Mbps MPEG-2 HD stream, and a SMPTE-310M decoder with video out. I, unfortunately, can't afford any of the above.

Possible Improvements (for SMPTE-310M)

What happens if the iValid signal goes to zero during normal operation? In theory, this should never happen. If the transport stream is lost, it's really up to the upstream device to continue to fire away null MPEG-2 packets or drop in a feed with some apology message, because there are going to be some irate viewers. The transport stream must go on!

There is also no signaling from the generator back to the input source, which will likely be a FIFO. That means that data must be supplied on time and at the byte clock, which is about 2.42 MHz. This is actually not too bad, as one can just take the 38.8 MHz transmitter clock, divide it by 8, and use that as a read acknowledge signal for the FIFO.

You could try to generate that divide by 8 signal off of the 3-bit up counter, since once it starts it should never stop, but I leave it up to you to make that modification. I think, to be safe, it's better to generate the 2.42 MHz acknowledge signal outside of the BMC entity so that you are not beholden to the slowClk signal, which governs bitCtr. Use one 38.8 MHz clock domain for the whole thing. I might elaborate on this in a separate entry.

Driving Coax

I think it goes without saying that it's a bad idea to route the output directly to a BNC connector. Cable drivers exist to protect your precious ASIC or FPGA, unless you're building a cable driver into your ASIC in which case, power to you. For the rest of us, the buffering and increased drive strength from a cable driver is most welcome. Cable drivers also go where FPGA I/O pins currently cannot, because not only can they drive coaxial cable, they drive it fast with single-ended outputs.

The Xilinx folks have been kind enough to provide XAPP514. Page 419, Figure 15-21 details a possible LVDS to National Semiconductor CLC001 cable driver setup. I would take capacitive coupling over having to use a transformer any day, but if you disagree, there's always Figure 15-20.

For Altera users, note that your particular FPGA may not have on-chip termination for the LVDS transmitter pair. Consult your manual for the appropriate resistor termination scheme. Given that SMPTE-310M is such a slow standard, you could probably get away with not having any termination whatsoever, but if you want to be cheap and run two (or more) serial standards off of the same BNC cable connector, put in the termination resistors to cover all your bases.

Further Reading

|