I don't get the structure of your code (or why you are writing structural code in the first place).
A synchronizer, which is what I'm assuming you are trying to implement is just two (or more) FFs chained together with the D input of the first flop fed by the asynchronous input the Q output of the 1st FF feeding the D input of a 2nd FF and the Q output (for two stage) being synchronous to the new clock domain. All FFs in the synchronizer are clocked by the clock domain being entered.
The simplest code for doing this is written something like this:
| Code Verilog - [expand] |
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| module synchronizer #(
parameter NUM_STAGES = 2
) (
output sync_out,
input async_in,
input clk
);
reg [NUM_STAGES:1] sync_reg;
always @ (posedge clk) begin
sync_reg <= {sync_reg[NUM_STAGES-1:1], async_in};
end
assign sync_out = sync_reg[NUM_STAGES];
endmodule |
Notes:
* number of stages is parameterized so you can make it larger than a 2 stage synchronizer.
* a shift register is implemented by assigning the correctly shifted output back into the input of the sync_reg DFFs.
* sync_out does not have reg as it is a wire type.
In the case of your code you should not have
output reg dataOut as dataOutis a wire type as it is driven by the output of the instance u2. You can either use
output wire dataOut or as the default is wire you can use just
output dataOut.
***** Some observations on your code ******
| Code Verilog - [expand] |
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
| module synchronizer (
/* line up signals verically makes it easier to read code
--\/\/\/------\/\/\/--*/
input clk, // all signals on different lines
input adata, // can add comments for each signal
output reg synched // this is the output of a DFF
);
// use consistent formatting and line up things in columns so they are easier to see at a glance.
// my rule: if you can't glance at a piece of simple code for 1 second and determine what it might
// be doing then you formatted it badly. If it has a complex if/case/etc statement then you should
// be able to only take the time to look at each if expression to determine what the code is doing,
// if it takes longer than the time it takes to read each if expression then the code is badly formatted.
always @ (posedge clk)
// why would you do this to implement a simple DFF!?
if (!adata) synched <= 0;
else synched <= 1;
// the equivalent, traditional way of writing a simple DFF
// that others will immediately recognize without having to
// analyze your code
always @ (posedge clk)
synched <= adata;
// this is my preferred style, which allows you to add more signals in the if statement
// if needed without affecting other lines that are not part of the change. This is helpful
// when you use some form of source control and the diff will now show actual changes
// instead of formatting changes because you had to add the begin-end block because
// of the addition of a new signal.
always @(posedge clk) begin
if (!adata) begin
synched <= 1'b0;
end else begin
synched <= 1'b1;
end
end
endmodule
// 2 ff
module ff2 (input clk, dataIn, // ugh, reformat these like
output dataOut); // my example above. No reg!
wire synch; // use some whitespace above and below for readability!
synchronizer u1 (clk, dataIn, synch); // No,no,no, use named association
synchronizer u2 (clk, synch, dataOut); // i.e. .synched (dataOut)
// the order then doesn't matter and
// you can add new ports without having
// to count which position it is in.
// this is critical when you start writing
// code that has 100's of ports.
endmodule |