Maker Pro
Maker Pro

looking for serializer / deserializer circuits (olde school stuff)

S

sswitaj

Jan 1, 1970
0
Hi Guys;

I need a circuit to serialize a 24 bit word at relative low rates
(1mhz), transmit it down a coax cable, and reconstruct it at the other end.

For various reasons, most of the commercially available serializer chips
aren’t especially well suited to my application (they're optimized for
160mbs+ systems, and I've got media issues).

In the Olde, Olde days, we sued to do this all the time - essentially
make our own UARTS out of shift registers and PLLs. But I don’t work
much in that area of digital design any more, and can’t seem to remember
(or find) much information on clock recovery issues or (especially)
efficient methods for correctly re-framing the resulting data stream
into words.

Anybody out there know of either a good app note on the subject or a
source for ser/des building block components?

- Steve
 
M

M.Randelzhofer

Jan 1, 1970
0
sswitaj said:
Hi Guys;

I need a circuit to serialize a 24 bit word at relative low rates
(1mhz), transmit it down a coax cable, and reconstruct it at the other end.

For various reasons, most of the commercially available serializer chips
aren’t especially well suited to my application (they're optimized for
160mbs+ systems, and I've got media issues).

In the Olde, Olde days, we sued to do this all the time - essentially
make our own UARTS out of shift registers and PLLs. But I don’t work
much in that area of digital design any more, and can’t seem to remember
(or find) much information on clock recovery issues or (especially)
efficient methods for correctly re-framing the resulting data stream
into words.

Anybody out there know of either a good app note on the subject or a
source for ser/des building block components?

- Steve

There are lots of good books about network technology.
My favorite is :

FRED HALSALL "Data communications, computer networks and open systems".

Of course, the book covers all details about serial data communication, all
that may not be of interest for your needs.

For your special app, you can simply use an async bittransmitter and
receiver (UART, similar to RS232, but for 24bits) with 16x oversampling of
the data stream. If your datarate is e.g. 1 Mbit, use a 16Mhz clock to
recover data. This frees you from using analog PLL's.
Put an uart in a cpld or fpga, but transmit 24bit at once. A start and stop
bit syncs the data words.

See:
http://www.xilinx.com/xapp/xapp341.pdf

One important issue is the signalling on the coax cable. You may need
special 50ohm drivers and receivers. An asymmetrical approach for data
transfer is always critical, because one's and zero's are distorted
differently - so only short cables can be used. Better way to go is
symmetrical with RS485 tranceivers / receivers.

MIKE
 
F

Fred Bloggs

Jan 1, 1970
0
sswitaj said:
Hi Guys;

I need a circuit to serialize a 24 bit word at relative low rates
(1mhz), transmit it down a coax cable, and reconstruct it at the other end.

For various reasons, most of the commercially available serializer chips
aren’t especially well suited to my application (they're optimized for
160mbs+ systems, and I've got media issues).

In the Olde, Olde days, we sued to do this all the time - essentially
make our own UARTS out of shift registers and PLLs. But I don’t work
much in that area of digital design any more, and can’t seem to remember
(or find) much information on clock recovery issues or (especially)
efficient methods for correctly re-framing the resulting data stream
into words.

Anybody out there know of either a good app note on the subject or a
source for ser/des building block components?

- Steve

PIC== Peripheral Interface Controller- you're lost- hire an engineer.
 
J

John Devereux

Jan 1, 1970
0
Fred Bloggs said:
PIC== Peripheral Interface Controller- you're lost- hire an engineer.

1MHz is pushing it for a PIC isn't it? Or do you mean something other
than PIC-the-microcontroller? Or perhaps he really does mean 1
millihertz! :)
 
S

sswitaj

Jan 1, 1970
0
PIC== Peripheral Interface Controller- you're lost- hire an engineer.

PICs aren't well suited to my application, even the fastest UART-style
part is too slow, (at about 1.8mbits/s) I need about 12 times as much
bandwidth (24bits at 1Mword/sec = 24Mbit/s). Also, the output of UART
style chips has appreciable DC offset, so it's going to be difficult to
properly engineer a good transmission line through cheap coax. Also, all
commercially available UART/PICs are designed around a conventional data
bus and have bus-driven configuration registers, which would force me to
add a small microcontroller to both ends of the circuit just to pump data.

Unfortunatley, I'm operating in the gap between low-speed UARTS
(1.8mb/s) and high speed (160Mb/s) serializer/deserializer chips.

The high speed chips would easily do my job but would have penalties
involving part cost, additional 3.3v power supplies and level shifters,
restrictions on transmission media, and radiated noise.

I actually need something right in the middle, and with my odd word
width (24bits) I'll probably have to brew it myself in an FPGA. I'm
looking for old appnotes, though, because there used to be a lot of
information available about optimizing deserializing circuitry for
recovering clocks and reframing data at the receiving end, which is an
art that involves lots of voodoo.

- Steve
 
S

sswitaj

Jan 1, 1970
0
M.Randelzhofer said:
For your special app, you can simply use an async bittransmitter and
receiver (UART, similar to RS232, but for 24bits) with 16x oversampling of
the data stream.

Thanks, Mike. I'll look up the Halsall book.

Because of the fixed (and non-negotiable) nature of my transmission link
I'll probably have to use a coding that minimizes DC component, some
sort of NRZI or Manchester thing. Since those both those schemes also
encode clock, I'd like to stay with synchronous architectures, because
once you've got the clock back, you've got the raw data, all you have to
do is parse the string.
If your datarate is e.g. 1 Mbit, use a 16Mhz clock to
recover data.

Unfortunately, my *word* rate is 1Mhz, my data rate is 24Mb/s. This puts
me squarely between commercial UARTS, which aren't fast enough and
commercial serializer chips, which are expensive overkill for this app.
Put an uart in a cpld or fpga, but transmit 24bit at once. A start and stop
bit syncs the data words.
See: http://www.xilinx.com/xapp/xapp341.pdf

Yeah, I imagined that I'd have to brew my own in an FPGA, But I'm still
looking for good clock recovery and data parsing circuit examples. There
used to be a lot of art involved with optimizing this stuff, and I'm
kind of rusty at it since I mostly deal with motor control issues these days

I figured that since many of the denizens of this newsgroup are circuit
pack-rats, I might turn something up.

- Steve
 
F

Frank Bemelman

Jan 1, 1970
0
sswitaj said:
PICs aren't well suited to my application, even the fastest UART-style
part is too slow, (at about 1.8mbits/s) I need about 12 times as much
bandwidth (24bits at 1Mword/sec = 24Mbit/s). Also, the output of UART
style chips has appreciable DC offset, so it's going to be difficult to
properly engineer a good transmission line through cheap coax. Also, all
commercially available UART/PICs are designed around a conventional data
bus and have bus-driven configuration registers, which would force me to
add a small microcontroller to both ends of the circuit just to pump data.

Unfortunatley, I'm operating in the gap between low-speed UARTS
(1.8mb/s) and high speed (160Mb/s) serializer/deserializer chips.

The high speed chips would easily do my job but would have penalties
involving part cost, additional 3.3v power supplies and level shifters,
restrictions on transmission media, and radiated noise.

I actually need something right in the middle, and with my odd word
width (24bits) I'll probably have to brew it myself in an FPGA. I'm
looking for old appnotes, though, because there used to be a lot of
information available about optimizing deserializing circuitry for
recovering clocks and reframing data at the receiving end, which is an
art that involves lots of voodoo.

Perhaps SX52 (www.ubicom.com) is an option. Enough pins for your 24 bits
to load, and certainly fast enough to encode/decode manchester code.
Clocked at 50MHz you get 50 Mips. Price is $10 a piece in low quantaties.
Coding almost similar to PIC, so with the voodoo aspect of your project
you can expect to have some nightmares.
 
U

Uns Lider

Jan 1, 1970
0
Because of the fixed (and non-negotiable) nature of my transmission link
I'll probably have to use a coding that minimizes DC component, some
sort of NRZI or Manchester thing.

If the transmission link were negotiable (say, to 2 twisted pairs), things
would be easier.
Unfortunately, my *word* rate is 1Mhz, my data rate is 24Mb/s. This puts
me squarely between commercial UARTS, which aren't fast enough and
commercial serializer chips, which are expensive overkill for this app.

I'm not expert on this stuff... Would a plain old 74F86 (Tpd<=8ns) be too
slow for the encoder? One input gets fed with your data and the other gets
a 48MHz clock synchronous with the 24MHz bit clock, IIRC...

-- uns
 
S

sswitaj

Jan 1, 1970
0
Uns said:
If the transmission link were negotiable (say, to 2 twisted pairs), things
would be easier.

Yeah, but it's not. It's a system for the entertainment industry, where
coax is ubiquitous, and it’s simply what the client wants to use.
Fortunately, there are good chips for driving and receiving coax, like
the NatSemi CLC005 and CLC012, but with any AC coupled system like this,
it’s important to eliminate as much DC offset from the signal as
possible, hence the necessity for something like Manchester encoding.
Would a plain old 74F86 (Tpd<=8ns) be too
slow for the encoder? One input gets fed with your data and the other gets
a 48MHz clock synchronous with the 24MHz bit clock, IIRC...

No, that would work well (though you'd want to add a few gates for a
synchronous design). You get into finicky circuits on the recieve end,
where you have to recover the clock, and (especially) parse the data out
of the esrial stream.

It's a cost-sensitive product, so I'm trying to do it with a design
that's as simple as possible, lower speed chips, minimal programmed
parts, etc. Otherwise, I'd just use a commercial serializer chip (eg the
NatSemi 65lv1023), tell 'em to use twin coax for a differential pair,
and be done with it.

- Steve
 
J

John Fields

Jan 1, 1970
0
It's a cost-sensitive product, so I'm trying to do it with a design
that's as simple as possible, lower speed chips, minimal programmed
parts, etc. Otherwise, I'd just use a commercial serializer chip (eg the
NatSemi 65lv1023), tell 'em to use twin coax for a differential pair,
and be done with it.
 
F

Fred Bloggs

Jan 1, 1970
0
sswitaj said:
PICs aren't well suited to my application, even the fastest UART-style
part is too slow, (at about 1.8mbits/s) I need about 12 times as much
bandwidth (24bits at 1Mword/sec = 24Mbit/s). Also, the output of UART
style chips has appreciable DC offset, so it's going to be difficult to
properly engineer a good transmission line through cheap coax. Also, all
commercially available UART/PICs are designed around a conventional data
bus and have bus-driven configuration registers, which would force me to
add a small microcontroller to both ends of the circuit just to pump data.

Unfortunatley, I'm operating in the gap between low-speed UARTS
(1.8mb/s) and high speed (160Mb/s) serializer/deserializer chips.

The high speed chips would easily do my job but would have penalties
involving part cost, additional 3.3v power supplies and level shifters,
restrictions on transmission media, and radiated noise.

I actually need something right in the middle, and with my odd word
width (24bits) I'll probably have to brew it myself in an FPGA. I'm
looking for old appnotes, though, because there used to be a lot of
information available about optimizing deserializing circuitry for
recovering clocks and reframing data at the receiving end, which is an
art that involves lots of voodoo.

- Steve

It would be simple to suggest something real if you tell me something
more about your constraints. Okay- we know you want a single cheap
controlled impedance line- but what is maximum distance?- 1 meter or 1
kilometer; how is the 24-bit being presented to the serializer?- a
parallel word w/strobe, asynchronously, burst stream- what is it?;
5-Volt supplies all the way? The simplest synchronous serial protocol is
SDLC- well proven and documented- framed- variable words per bursts- the
conventional implementation max's at 10MBS but there's no reason why you
can't make it go at 24MBS with proprietary PLD- load, frame preamble,
shift, update CRC- note this process is independent of the encoding-
Manchester is a trivial snap-you will need a 2x 24MHz clk. But your
question is way too general to offer specific help as it stands.
 
S

sswitaj

Jan 1, 1970
0
It would be simple to suggest something real if you tell me something
more about your constraints.


The application is a professional video product intended to interface
encoder signals off a camera system with graphics equipment at a
different location. Many camera systems generate various information for
their own internal use (pan, tilt angles, boom position, etc) and there
are several specialized outboard applications that piggyback onto this
information.

The receiving end expects data in this parallel form, or else I’d just
parse it out at the source and transmit the positions down a
conventional serial line.

The systems currently in use are based on 12 pair cables driven via
standard differential techniques – a simple parallel bus. This has
disadvantages, of course. The obvious one is the expense, size and
fragility of the cables, but a secondary effect is the unsuitability of
DC coupling in large systems.

Though there’s a surprising amount of signal conditioning involved you
can consider the signals to be TTL quatrature encoder signals, plus some
low-speed sync signals. Nothing above 100 Khz. A 1 Mhz sample rate is an
arbitrary rate that gives me reasonable duty cycles and timing precision
given a squarewave in at 100Khz, plus a little room to grow, just in case

The data is essentially a 24 asychronous bits, sampled periodically, and
reconstructed at the far end.

Ideally, I’d like to have a solution that’s the functional equivalent of
the commercial serializer/deserializer chips (see the Cypress HotLink or
T-I MuxIt parts). You latch data into the transmit side, and it pops out
the receive side some microseconds later.

The transmission line has to be 75 ohm coax, because it’s ubiquitous in
the industry. I can’t use differential methods - one line is all the
clients will tolerate. Transmission distance is now typically no more
than 30m, but I wouldn’t be happy unless I could guarantee at least 100m
because someday somebody will want to do that.

It has to be an AC coupled system, to avoid system problems involving
ground loops.

Though I can be pretty sure they won’t use really cheap coax, I likewise
cannot guarantee that they’ll use really good coax. If I spec, say,
Belden 8281, that spec will likely be ignored. Consequently, I have to
worry about noise issues, both transmitted and received. The environment
tends to be electrically noisy because of high frequency lighting equipment.

Despite all the money video productions spend, like everything in the
accessory segment of the pro video market this product is surprisingly
cost sensitive. Therefore, I’ve been trying to stay away from the
commercial ser/des chips.

I’m wary of part cost (the chips themselves, an additional 3.3V supply,
and the handful of gates and level shifters at either end to pack and
unpack the data into 8 bit words) I’m cautious about the need for a
better medium than I have (the parts typically clock at 160Mbs and up)
and that the parts are mostly available only in surface mount. There’ll
be small production runs (<100 at a time), and I hate to add just 1 SMD
to an otherwise all thru-hole board.

Some quick calculations seem to show that an FPGA at either end could be
cheaper, even when you consider handling and programming, but there’s
the design time to amortize (I haven’t started full time this project
yet, it’s up next)

Power is not an issue, there’s +5V at either end for the rest of the
logic. I could add another supply, but I’d prefer not to.

Though I’m no stranger to digital design, I work mostly in
microcontrollers and motor control, and communications is enough of a
specialty art that I know when to ask for hints and tips.

Got any?

- Steve
 
S

sswitaj

Jan 1, 1970
0
Are you free to post your budgetary constraints? And if you are, would
you, please?

Ideally, I'd like to keep the cost of the link parts (both ends) below
$75, including parts and assembly labor.

Unfortunately, the boards will be produced in small quantities (<100 at
a run) and on an upredictable schedule, so that pretty much eliminates
economies of scale from large parts buys and automated production. Given
the realities of this manyfacturer, it's largely thru-hole technology. I
forsee a mostly hand-stuffed board.

$100 wouldn't kill me, in the overall budget, but $75 is a point that
allows me to shift funds into the important "pretty blinking lights"
category.

- Steve
 
Top