noise filter for single-bit serial data

[alan]

Hello all,

I'm constructing an FPGA-based system to perform a serial transmission
test on an IC, and currently one problem I have with the prototype is
noise (because I didn't have the foresight to consider proper
layout). There's a bit of design tradeoff between noise on the FPGA-
to-IC path and the IC-to-FPGA path, so I chose to put the noise more
on the IC-to-FPGA path on the logic that I could probably add
something to filter out the noise coming into the FPGA but not on the
IC.

Currently my design is to transmit at the required frequency (about
20MHz max), but receive at the FPGA system clock frequency, 100MHz, so
that I can add some noise filtering on the FPGA receiver. So far the
best noise filter I've thought of is a best-of-three filter:

module filter3(
input in,

output out,

input clk,
input reset_n
);

reg [1:0] r;
always @(posedge clk, negedge reset_n) if(!reset_n) r <= 0; else begin
r <= {r[0], in}; end

wire filtered =
(in && r[0]) ||
(r[0] && r[1]) ||
(in && r[1]);

reg d_filtered;
always @(posedge clk, negedge reset_n) if(!reset_n) d_filtered <= 0;
else begin
d_filtered <= filtered; end

assign out = d_filtered;

endmodule

Because I fully expect delays on the FPGA-to-IC and IC-to-FPGA paths
(to be specific, level shifters on both paths) I decided to also
include the serial clock signal in the FPGA's inputs from the test IC
(also following the same delay paths), so I expect the serial clock
input to be in-phase with the serial data input; the receiver and the
transmitter thus have "independent" clocks.

The problem I'm facing with a best-of-three filter is that with the
clock signal just 1/5th the system clock, the sampled clock may very
well be something like:
1 1 0 0 0 1 1 0 0 0 1 1 0 0 0
Assuming a noise-free system the best-of-three filter will simply add
two system clock cycles delay (which is okay since the serial clock of
the receiver and transmitter are independent). However if noise flips
one of the "1" bits the best-of-three filter will simply skip an
entire serial clock cycle.

I'm currently wondering if some algorithm, say a DPLL, may be more
useful for clock recovery (with the caveat that the first clock pulse
clocks in the first data bit, so I need something that can recover at
the first clock.)

 

[gabor]

On Jan 28, 3:43 am, alan <almkg...@gmail.com> wrote:

Hello all,

I'm constructing an FPGA-based system to perform a serial transmission
test on an IC, and currently one problem I have with the prototype is
noise (because I didn't have the foresight to consider proper
layout). There's a bit of design tradeoff between noise on the FPGA-
to-IC path and the IC-to-FPGA path, so I chose to put the noise more
on the IC-to-FPGA path on the logic that I could probably add
something to filter out the noise coming into the FPGA but not on the
IC.

Currently my design is to transmit at the required frequency (about
20MHz max), but receive at the FPGA system clock frequency, 100MHz, so
that I can add some noise filtering on the FPGA receiver. So far the
best noise filter I've thought of is a best-of-three filter:

module filter3(
input in,

output out,

input clk,
input reset_n
);

reg [1:0] r;
always @(posedge clk, negedge reset_n) if(!reset_n) r <= 0; else begin
r <= {r[0], in}; end

wire filtered =
(in && r[0]) ||
(r[0] && r[1]) ||
(in && r[1]);

reg d_filtered;
always @(posedge clk, negedge reset_n) if(!reset_n) d_filtered <= 0;
else begin
d_filtered <= filtered; end

assign out = d_filtered;

endmodule

Because I fully expect delays on the FPGA-to-IC and IC-to-FPGA paths
(to be specific, level shifters on both paths) I decided to also
include the serial clock signal in the FPGA's inputs from the test IC
(also following the same delay paths), so I expect the serial clock
input to be in-phase with the serial data input; the receiver and the
transmitter thus have "independent" clocks.

The problem I'm facing with a best-of-three filter is that with the
clock signal just 1/5th the system clock, the sampled clock may very
well be something like:
1 1 0 0 0 1 1 0 0 0 1 1 0 0 0
Assuming a noise-free system the best-of-three filter will simply add
two system clock cycles delay (which is okay since the serial clock of
the receiver and transmitter are independent). However if noise flips
one of the "1" bits the best-of-three filter will simply skip an
entire serial clock cycle.

I'm currently wondering if some algorithm, say a DPLL, may be more
useful for clock recovery (with the caveat that the first clock pulse
clocks in the first data bit, so I need something that can recover at
the first clock.)

Any chance of just fixing the route for the clock? I've heard of
workarounds for "noise" on data, but generally it's best to have
a reliable clock source. What sort of "noise" is it? Other
signals coupling into the clock? Transmission line reflections?
Can you lift pins / cut etch / run a wire to fix it?

When you say "the first clock" do you mean after the FPGA configures
it needs to react to the first clock edge it receives? You would need
to have a bit of storage in the FPGA and run your DPLL or other
filter on the stored data in order to reconstruct the first edge...
Can you live with large delays?

Good Luck,
Gabor

 

[Mike Treseler]

alan wrote:

I'm currently wondering if some algorithm, say a DPLL, may be more
useful for clock recovery (with the caveat that the first clock pulse
clocks in the first data bit, so I need something that can recover at
the first clock.)

This algorithm might prove effective:

1. Respin the proto board with a full ground layer.
2. Redo the cables with twisted pairs.

-- Mike Treseler

 

[alan]

On Jan 29, 12:12 am, gabor <ga...@alacron.com> wrote:

On Jan 28, 3:43 am, alan <almkg...@gmail.com> wrote:



Hello all,

I'm constructing an FPGA-based system to perform a serial transmission
test on an IC, and currently one problem I have with the prototype is
noise(because I didn't have the foresight to consider proper
layout).  There's a bit of design tradeoff betweennoiseon the FPGA-
to-IC path and the IC-to-FPGA path, so I chose to put thenoisemore
on the IC-to-FPGA path on the logic that I could probably add
something tofilterout thenoisecoming into the FPGA but not on the
IC.

Currently my design is to transmit at the required frequency (about
20MHz max), but receive at the FPGA system clock frequency, 100MHz, so
that I can add somenoisefiltering on the FPGA receiver.  So far the
bestnoisefilterI've thought of is a best-of-threefilter:

module filter3(
    input in,

    output out,

    input clk,
    input reset_n
);

reg [1:0] r;
always @(posedge clk, negedge reset_n) if(!reset_n) r <= 0; else begin
    r <= {r[0], in}; end

wire filtered > >     (in && r[0]) ||
    (r[0] && r[1]) ||
    (in && r[1]);

reg d_filtered;
always @(posedge clk, negedge reset_n) if(!reset_n) d_filtered <= 0;
else begin
    d_filtered <= filtered; end

assign out = d_filtered;

endmodule

Because I fully expect delays on the FPGA-to-IC and IC-to-FPGA paths
(to be specific, level shifters on both paths) I decided to also
include the serial clock signal in the FPGA's inputs from the test IC
(also following the same delay paths), so I expect the serial clock
input to be in-phase with the serial data input; the receiver and the
transmitter thus have "independent" clocks.

The problem I'm facing with a best-of-threefilteris that with the
clock signal just 1/5th the system clock, the sampled clock may very
well be something like:
1 1 0 0 0 1 1 0 0 0 1 1 0 0 0
Assuming anoise-free system the best-of-threefilterwill simply add
two system clock cycles delay (which is okay since the serial clock of
the receiver and transmitter are independent).  However ifnoiseflips
one of the "1" bits the best-of-threefilterwill simply skip an
entire serial clock cycle.

I'm currently wondering if some algorithm, say a DPLL, may be more
useful for clock recovery (with the caveat that the first clock pulse
clocks in the first data bit, so I need something that can recover at
the first clock.)

Any chance of just fixing the route for the clock?  I've heard of
workarounds for "noise" on data, but generally it's best to have
a reliable clock source.  What sort of "noise" is it?  Other
signals coupling into the clock?  Transmission line reflections?
Honestly, I don't know. This is the first actual hardware project

I've ever done, and I don't even have the benefit of having a mentor
(all the good engineers have resigned, I should probably do the same).

Can you lift pins / cut etch / run a wire to fix it?
Possibly, although I wouldn't actually know which wire to do what to.

Noob, noob.

When you say "the first clock" do you mean after the FPGA configures
it needs to react to the first clock edge it receives?
Not necessarily after it configures.

The clock being "returned" to me is actually the "same" clock as my
transmitter. It's just that there's a level shifter out, and a level
shifter in, which adds delay (about 10 ns avg each way IIRC, don't
have the specs on hand). For signals of about 20MHz. <sigh>. This
means I can't use the same clock that comes from my transmitter, so I
also send out the clock through the level shifter out and in, in the
hope that the delay will at least be reasonably close to the delay of
the data.

So basically, I expect the "first clock" to be a very short time after
my transmitter's first clock, maybe about 10ns or so after. I don't
remember the exact delay off hand, but it was a sizeable portion of
the clock cycle at our specified maximum frequency.

 You would need
to have a bit of storage in the FPGA and run your DPLL or otherfilteron the stored data in order to reconstruct the first edge...
Can you live with large delays?
Yes, definitely. Although I do have a current/power budget too,

meaning I want to keep as few flipflops switching at a time.
What I could even do is, sample at 100MHz and send the data to the PC
(it's connected to a PC via a USB device; so far the USB-USB device-
FPGA path seems reliable, although I haven't actually sent a lot of
data on that path yet) and do the computations PC-side. (which might
save power too; the power budget I have is the power budget the USB
connection gives me)

Maybe even sample the transmitter's output clock and the receiver's
input clock, compute the correlation (PC-side, of course) and figure
out the delay from that, then clean the data based on the computed
delay.

Good Luck,
Gabor
Yes, I probably need the luck.

Thanks,
AmkG

 

[alan]

On Jan 29, 1:26 am, Mike Treseler <mike_trese...@comcast.net> wrote:

alan wrote:
I'm currently wondering if some algorithm, say a DPLL, may be more
useful for clock recovery (with the caveat that the first clock pulse
clocks in the first data bit, so I need something that can recover at
the first clock.)

This algorithm might prove effective:

1. Respin the proto board with a full ground layer.
2. Redo the cables with twisted pairs.

     -- Mike Treseler
LOL. Our proto board is a universal board (you know, the board that's

just full of holes and where you make paths by putting wires on the
bottom layer), and our requester is penny-pinching. Cables with
twisted pairs would probably work (although I'm reasonably sure I'll
actually have to *build* the twisted pairs manually) but respinning
the proto board? It took me about a week just to get approval of
buying universal boards. La la la la la...

That said, I'm almost sure that most of the problems I have are from
having insufficient grounding.

 

[Dwayne Dilbeck]

If all the experienced engineers resigned at once, that tells you to get the
hell out of dodge. That usually only happens when the economy is great and
another firm offers them a bunch of money at once. Or more likely they
have just gotten to much crap dumped on them and left at once on purpose.
Finally it could point to finacial problems with the company.

I would look really closely for the reason those other guys left.



"alan" <almkglor@gmail.com> wrote in message
news:05acb686-e990-4b4a-a2e5-699265da9dec@m34g2000hsb.googlegroups.com...
On Jan 29, 12:12 am, gabor <ga...@alacron.com> wrote:

On Jan 28, 3:43 am, alan <almkg...@gmail.com> wrote:



Hello all,

I'm constructing an FPGA-based system to perform a serial transmission
test on an IC, and currently one problem I have with the prototype is
noise(because I didn't have the foresight to consider proper
layout). There's a bit of design tradeoff betweennoiseon the FPGA-
to-IC path and the IC-to-FPGA path, so I chose to put thenoisemore
on the IC-to-FPGA path on the logic that I could probably add
something tofilterout thenoisecoming into the FPGA but not on the
IC.

Currently my design is to transmit at the required frequency (about
20MHz max), but receive at the FPGA system clock frequency, 100MHz, so
that I can add somenoisefiltering on the FPGA receiver. So far the
bestnoisefilterI've thought of is a best-of-threefilter:

module filter3(
input in,

output out,

input clk,
input reset_n
);

reg [1:0] r;
always @(posedge clk, negedge reset_n) if(!reset_n) r <= 0; else begin
r <= {r[0], in}; end

wire filtered =
(in && r[0]) ||
(r[0] && r[1]) ||
(in && r[1]);

reg d_filtered;
always @(posedge clk, negedge reset_n) if(!reset_n) d_filtered <= 0;
else begin
d_filtered <= filtered; end

assign out = d_filtered;

endmodule

Because I fully expect delays on the FPGA-to-IC and IC-to-FPGA paths
(to be specific, level shifters on both paths) I decided to also
include the serial clock signal in the FPGA's inputs from the test IC
(also following the same delay paths), so I expect the serial clock
input to be in-phase with the serial data input; the receiver and the
transmitter thus have "independent" clocks.

The problem I'm facing with a best-of-threefilteris that with the
clock signal just 1/5th the system clock, the sampled clock may very
well be something like:
1 1 0 0 0 1 1 0 0 0 1 1 0 0 0
Assuming anoise-free system the best-of-threefilterwill simply add
two system clock cycles delay (which is okay since the serial clock of
the receiver and transmitter are independent). However ifnoiseflips
one of the "1" bits the best-of-threefilterwill simply skip an
entire serial clock cycle.

I'm currently wondering if some algorithm, say a DPLL, may be more
useful for clock recovery (with the caveat that the first clock pulse
clocks in the first data bit, so I need something that can recover at
the first clock.)

Any chance of just fixing the route for the clock? I've heard of
workarounds for "noise" on data, but generally it's best to have
a reliable clock source. What sort of "noise" is it? Other
signals coupling into the clock? Transmission line reflections?
Honestly, I don't know. This is the first actual hardware project

I've ever done, and I don't even have the benefit of having a mentor
(all the good engineers have resigned, I should probably do the same).

Can you lift pins / cut etch / run a wire to fix it?
Possibly, although I wouldn't actually know which wire to do what to.

Noob, noob.

When you say "the first clock" do you mean after the FPGA configures
it needs to react to the first clock edge it receives?
Not necessarily after it configures.

The clock being "returned" to me is actually the "same" clock as my
transmitter. It's just that there's a level shifter out, and a level
shifter in, which adds delay (about 10 ns avg each way IIRC, don't
have the specs on hand). For signals of about 20MHz. <sigh>. This
means I can't use the same clock that comes from my transmitter, so I
also send out the clock through the level shifter out and in, in the
hope that the delay will at least be reasonably close to the delay of
the data.

So basically, I expect the "first clock" to be a very short time after
my transmitter's first clock, maybe about 10ns or so after. I don't
remember the exact delay off hand, but it was a sizeable portion of
the clock cycle at our specified maximum frequency.

You would need
to have a bit of storage in the FPGA and run your DPLL or otherfilteron
the stored data in order to reconstruct the first edge...
Can you live with large delays?
Yes, definitely. Although I do have a current/power budget too,

meaning I want to keep as few flipflops switching at a time.
What I could even do is, sample at 100MHz and send the data to the PC
(it's connected to a PC via a USB device; so far the USB-USB device-
FPGA path seems reliable, although I haven't actually sent a lot of
data on that path yet) and do the computations PC-side. (which might
save power too; the power budget I have is the power budget the USB
connection gives me)

Maybe even sample the transmitter's output clock and the receiver's
input clock, compute the correlation (PC-side, of course) and figure
out the delay from that, then clean the data based on the computed
delay.

Good Luck,
Gabor
Yes, I probably need the luck.

Thanks,
AmkG

 

[alan]

On Jan 30, 7:31 am, "Dwayne Dilbeck" <ddilb...@yahoo.com> wrote:

If all the experienced engineers resigned at once, that tells you to get the
hell out of dodge.   That usually only happens when the economy is great and
another firm offers them a bunch of money at once.
Not exactly all at once, although turnover certainly is relatively

fast here. It's just that *now* I'm one of the "most experienced"
engineers, and this is my first actual hardware project (mostly I do
simulations, which is where my experience mostly is).

That said, yes, various (not one single, but several) other firms have
been offering better incentives for easier jobs. I mostly ignore
offers because I happen to like the technical difficulty level of the
jobs here and am not very interested in money (spoiled brat), although
the fact that I hardly have anyone to ask now is starting to really
stress me.

As for economy, my whole *country* is an economic mess and most of the
"another firm"s are based in Singapore and other countries. Yes,
they're willing to work in a foreign country, it's that bad.

My direct superior is a "more experienced" engineer than I am but it
seems his grasp of the technical side is not as good as it could be,
and technical discussions with him are not very stimulating; I have to
correct his ideas more often than I can get new ideas.

Really, what I'm looking for is a stimulating technical discussion. I
get good ideas just tossing around stupid stuff in a discussion, and
talking to myself just isn't good enough. My department head (who is
about three-four levels above me) can get into a stimulating
discussion but he prefers philosophical topics (since he claims to
have forgotten much of tech), which don't really help.

  Or more likely they
have just gotten to much crap dumped on them and left at once on purpose.
Finally it could point to finacial problems with the company.
Possibly. The company's moving from a relatively "affluent"-looking

building to an apparently less affluent one this mid february too.
Ha, ha.

I would look really closely for the reason those other guys left.

Thanks.

In any case, back to the tech discussion... I've mocked up a
simulation of the correlation function (of course, not in verilog) and
it appears to be good at detecting the delay even in the presence of
noise. Now all I have to do is assume that the delay on both clock
feedback signal and the input data are the same. I'd assume that if
they're on the same IC, they'd have very similar delays.

The other problem now is the fact that transmission speeds can be as
low as 1kHz (!!) to as high as 20MHz (they want to test a range of
frequencies). I've already got a Direct Digital Synthesis clock
generator that drives an output clock as low as 1kHz up to 40MHz at
1kHz increments (with inevitable jitter at frequencies not equal to
40MHz/N where N is an integer), with my serial output generator
dividing the clock by 2. However the sampling clock has to be better
than twice the clock for better noise protection (I think), especially
since I have to get a bigger sample around the potentially noisy data.

"alan" <almkg...@gmail.com> wrote in message

news:05acb686-e990-4b4a-a2e5-699265da9dec@m34g2000hsb.googlegroups.com...
On Jan 29, 12:12 am, gabor <ga...@alacron.com> wrote:

On Jan 28, 3:43 am, alan <almkg...@gmail.com> wrote:

Hello all,

I'm constructing an FPGA-based system to perform a serial transmission
test on an IC, and currently one problem I have with the prototype is
noise(because I didn't have the foresight to consider proper
layout). There's a bit of design tradeoff betweennoiseon the FPGA-
to-IC path and the IC-to-FPGA path, so I chose to put thenoisemore
on the IC-to-FPGA path on the logic that I could probably add
something tofilterout thenoisecoming into the FPGA but not on the
IC.

Currently my design is to transmit at the required frequency (about
20MHz max), but receive at the FPGA system clock frequency, 100MHz, so
that I can add somenoisefiltering on the FPGA receiver. So far the
bestnoisefilterI've thought of is a best-of-threefilter:

module filter3(
input in,

output out,

input clk,
input reset_n
);

reg [1:0] r;
always @(posedge clk, negedge reset_n) if(!reset_n) r <= 0; else begin
r <= {r[0], in}; end

wire filtered > > > (in && r[0]) ||
(r[0] && r[1]) ||
(in && r[1]);

reg d_filtered;
always @(posedge clk, negedge reset_n) if(!reset_n) d_filtered <= 0;
else begin
d_filtered <= filtered; end

assign out = d_filtered;

endmodule

Because I fully expect delays on the FPGA-to-IC and IC-to-FPGA paths
(to be specific, level shifters on both paths) I decided to also
include the serial clock signal in the FPGA's inputs from the test IC
(also following the same delay paths), so I expect the serial clock
input to be in-phase with the serial data input; the receiver and the
transmitter thus have "independent" clocks.

The problem I'm facing with a best-of-threefilteris that with the
clock signal just 1/5th the system clock, the sampled clock may very
well be something like:
1 1 0 0 0 1 1 0 0 0 1 1 0 0 0
Assuming anoise-free system the best-of-threefilterwill simply add
two system clock cycles delay (which is okay since the serial clock of
the receiver and transmitter are independent). However ifnoiseflips
one of the "1" bits the best-of-threefilterwill simply skip an
entire serial clock cycle.

I'm currently wondering if some algorithm, say a DPLL, may be more
useful for clock recovery (with the caveat that the first clock pulse
clocks in the first data bit, so I need something that can recover at
the first clock.)

Any chance of just fixing the route for the clock? I've heard of
workarounds for "noise" on data, but generally it's best to have
a reliable clock source. What sort of "noise" is it? Other
signals coupling into the clock? Transmission line reflections?

Honestly, I don't know.  This is the first actual hardware project
I've ever done, and I don't even have the benefit of having a mentor
(all the good engineers have resigned, I should probably do the same).

Can you lift pins / cut etch / run a wire to fix it?

Possibly, although I wouldn't actually know which wire to do what to.
Noob, noob.



When you say "the first clock" do you mean after the FPGA configures
it needs to react to the first clock edge it receives?

Not necessarily after it configures.

The clock being "returned" to me is actually the "same" clock as my
transmitter.  It's just that there's a level shifter out, and a level
shifter in, which adds delay (about 10 ns avg each way IIRC, don't
have the specs on hand).  For signals of about 20MHz.  <sigh>.  This
means I can't use the same clock that comes from my transmitter, so I
also send out the clock through the level shifter out and in, in the
hope that the delay will at least be reasonably close to the delay of
the data.

So basically, I expect the "first clock" to be a very short time after
my transmitter's first clock, maybe about 10ns or so after.  I don't
remember the exact delay off hand, but it was a sizeable portion of
the clock cycle at our specified maximum frequency.

You would need
to have a bit of storage in the FPGA and run your DPLL or otherfilteron
the stored data in order to reconstruct the first edge...
Can you live with large delays?

Yes, definitely.  Although I do have a current/power budget too,
meaning I want to keep as few flipflops switching at a time.
What I could even do is, sample at 100MHz and send the data to the PC
(it's connected to a PC via a USB device; so far the USB-USB device-
FPGA path seems reliable, although I haven't actually sent a lot of
data on that path yet) and do the computations PC-side. (which might
save power too; the power budget I have is the power budget the USB
connection gives me)

Maybe even sample the transmitter's output clock and the receiver's
input clock, compute the correlation (PC-side, of course) and figure
out the delay from that, then clean the data based on the computed
delay.



Good Luck,
Gabor

Yes, I probably need the luck.

Thanks,
AmkG