Mux Synchronizer on Verilog FPGA

[Samuel Jimenez]

I need help implementing a mux synchronizer on Verilog. I have little knowledge of Verilog and need this design as soon as possible.




Any help is appreciated tremendously!!

 

[ads-ee]

So is this your homework?

hint1:

---

Code Verilog - [expand]
1
2
3
4
// flip-flop code
always @(posedge clk) begin
  q <= d;
end

---

hint2:

---

Code Verilog - [expand]
1
2
3
4
5
6
7
8
9
10
11
// case mulitplexing
always @* begin
  case (sel)
    0       : mux_out = i0;
    1       : mux_out = i1;
    default : mux_out = 'bx;
  endcaes;
end
 
// ? : multiplexing
assign mux_out = sel ? i2 : i0;

---

 

[Samuel Jimenez]

So is this your homework?

hint1:

---

Code Verilog - [expand]
1
2
3
4
// flip-flop code
always @(posedge clk) begin
  q <= d;
end

---

hint2:

---

Code Verilog - [expand]
1
2
3
4
5
6
7
8
9
10
11
// case mulitplexing
always @* begin
  case (sel)
    0       : mux_out = i0;
    1       : mux_out = i1;
    default : mux_out = 'bx;
  endcaes;
end
 
// ? : multiplexing
assign mux_out = sel ? i2 : i0;

---

Thank you,

No, it's not. I'm just having trouble how to appropriately interconnect mux output to the instantiated modules:

For ex, using your presented logic (not complete mux sync design - just an example):

cdc_dff dff1(
 //.input(..) D
 //.clk(..)   clk
 //.outout(wire) 
);

//then

cdc_mux mux_1 (
 //.mux_i0 (select_0),
 //.mux_i1 (select_1),
 //.mux_select (wire from dff1 output)
 //.mux_o (bus wire)
);

//then

always @(posedge dest_clk)
begin
    adc_a <= bus wire from mux_1;
end

Is this correct/appropiate?

 

[ads-ee]

No, it's not [homework].

glad to hear that...

I'm just having trouble how to appropriately interconnect instantiated modules:

Okay then...
I'm not exactly sure what you wrote it looks all wonky to me. Everything is commented out and none of the names match what I wrote above.

For ex (using your presented logic):

cdc_dff dff1(
 //.input(..) D
 //.clk(..)   clk
 //.outout(wire) 
);

//then

cdc_mux mux_1 (
 //.mux_i0 (select_0),
 //.mux_i1 (select_1),
 //.mux_select (wire from dff1 output)
 //.mux_o (bus wire)
);

//then

always @(posedge dest_clk)
begin
    adc_a <= bus wire from mux_1;
end

Is this correct?

just looking at the right two components the FF and the mux you would have to first change my code snippets to modules:

---

Code Verilog - [expand]
1
2
3
4
5
6
7
8
9
10
11
module flip_flop (
  input clk,
  input d,
  output reg q
);
 
  // flip-flop code
  always @(posedge clk) begin
    q <= d;
  end
endmodule

---

taking liberty with the names on your schematic, you have names that are identical for the data_bus for multiple connections.
with both this flip_flop file and the other mux code turned into a module will allow you to code something like this:

---

Code Verilog - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
genvar i;
  generate
  // generate an 8-bit data bus
  for (i=0; i<8; i=i+1) begin : GEN_BUS
    // mux instance
    mux mux_i (
      .i0 (data_bus_fb[i]),
      .i1 (data_bus_in[i]),
      .sel (db),
      .mux_out (data_bus_o[i])
    );
    // FF instance
    flip_flop flip_flop_i (
      .clk (clk),
      .d (data_bus_o[i]),
      .q (data_bus_fb[i]) // feedback to mux input.
    );
  end
  endgenerate

---

Though I would never code anything with this type of structural description, why waste the time instantiating all of these tiny modules, just write behavioral code for the whole thing in like 20-30 lines of code (just a guess).

 

[std_match]

What is the point with proper synchronization for the mux select signal but not for the data path?

 

[ads-ee]

What is the point with proper synchronization for the mux select signal but not for the data path?

I think the MUX select is actually something like a data valid strobe. It's synchronized more to delay it than anything else. This allows the data to become stable. If you synchronize the data bus then you'll end up capturing garbage data every time as some bits may get transferred and some might get missed.

The circuit only works if the data and strobe changes only occur approximately every 3-4 destination clock cycles. Any faster and you'll end up coruppting some of the data transfers.

 

[Samuel Jimenez]

I changed to behavioral like so:
Here's the Verilog Code:

reg [16-1:2] a_a1_o, a_b3_o;
reg a_b1_o, a_b3_o;
reg a_mux_enable;

reg [16-1:2] b_a1_o, b_b3_o;
reg b_b1_o, b_b3_o;
reg b_mux_enable;

always @(posedge adc_clk_in)
begin
    a_a1_o <= adc_dat_a_i[16-1:2];
    b_a1_o <= adc_dat_b_i[16-1:2];
end

always @(posedge adc_clk)
begin
    if (a_mux_enable)
        a_b3_o <= a_a1_o;
    if (b_mux_enable)
        b_b3_o <= b_a1_o;
end

always @(posedge adc_clk)
begin
    a_b1_o <= adc_clk_in;
    a_mux_enable <= a_b1_o;
    
    b_b1_o <= adc_clk_in;
    b_mux_enable <= b_b1_o;

    //adc_dat_a <= data_bus_fb[16-1:2];
    adc_dat_a <= a_b3_o[16-1:2];
    adc_dat_b <= b_b3_o[16-1:2];
    
end

The circuit only works if the data and strobe changes only occur approximately every 3-4 destination clock cycles. Any faster and you'll end up coruppting some of the data transfers.

It seems this CDC may not be appropriate for my situation, then. Continuous multi-bit stream data is coming in (not bursts). What other CDC techniques might satisfy this requirement.

 

[ads-ee]

Use an asynchronous FIFO.

 

[Samuel Jimenez]

Use an asynchronous FIFO.

But the adc data stream is not ordered. I mean, with adc datastream that is not ordered, an async. FIFO with gray code counters would not work.

Or are the gray code counters only responsible for handling the writing/reading pointers?

 

[ads-ee]

But the adc data stream is not ordered. I mean, with adc datastream that is not ordered, an async. FIFO with gray code counters would not work.

Or are the gray code counters only responsible for handling the writing/reading pointers?

They are used to transfer the pointers across the clock domain...single bit changes in a multi-bit bus can be transferred without glitches in the counter order.

The FIFO data is still in a "First-In-First-Out" order, hence the name FIFO. So as each sample from the ADC is written to the FIFO on one clock domain the reading of the data on another clock domain comes out in the same order that the ADC generated the data.