Re: noise filter for single-bit serial data
- From: "Dwayne Dilbeck" <ddilbeck@xxxxxxxxx>
- Date: Tue, 29 Jan 2008 15:31:39 -0800
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@xxxxxxxxx> wrote in message
news:05acb686-e990-4b4a-a2e5-699265da9dec@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Jan 29, 12:12 am, gabor <ga...@xxxxxxxxxxx> wrote:
On Jan 28, 3:43 am, alan <almkg...@xxxxxxxxx> wrote:Honestly, I don't know. This is the first actual hardware project
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?
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.
Not necessarily after it configures.
When you say "the first clock" do you mean after the FPGA configures
it needs to react to the first clock edge it receives?
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 needYes, definitely. Although I do have a current/power budget too,
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?
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.
Yes, I probably need the luck.
Good Luck,
Gabor
Thanks,
AmkG
.
- Follow-Ups:
- Re: noise filter for single-bit serial data
- From: alan
- Re: noise filter for single-bit serial data
- References:
- noise filter for single-bit serial data
- From: alan
- Re: noise filter for single-bit serial data
- From: gabor
- Re: noise filter for single-bit serial data
- From: alan
- noise filter for single-bit serial data
- Prev by Date: Re: bitwise or logical operators
- Next by Date: SoC design
- Previous by thread: Re: noise filter for single-bit serial data
- Next by thread: Re: noise filter for single-bit serial data
- Index(es):
Relevant Pages
|