Stop Creating Clocks & Resets Locally

When this topic first came to my mind, I was hanging out on a beach in Tsingtao. It has been so long since the last time when I went to a beach. The warm and overwhelming salty smell of Tsingtao beach reminded me of the old time when I was cycling along the Southampton Water shore. It was also an windy day in late September. The red roofed terraces upon the hills looked so cute and so much like the house I wished to have after retirement that located right at the mouth of the River Itchen. You must wonder how did I come up with this topic when I was taking holidays? Well, since this place reminded me of Southampton, and Southampton reminded me of a very admired teacher of mine -- Iain McNally, and then BAAAAANG!!! -- I suddenly recalled the first mistake Iain had ever corrected me in my life.

"Stop creating clocks & resets in your module."

I. What Are Locally Created Clocks & Resets

I bet many of you guys, just like how I was in school lab, don't understand what are locally created clocks & resets. You may wonder what did I do to have made Iain utter that line. All right, the original code I handed to Iain when he asked me to do a synchronous design as coursework is very similar to the code showing below.

[source lang="verilog"]
//==============================================================================
// Copyright (C) 2015 By Kellen.Wang
// mail@kellen.wang, All Rights Reserved
//==============================================================================
// Module : example
// Author : Kellen Wang
// Contact : mail@kellen.wang
// Date : Oct.02.2015
//==============================================================================
// Description :
//==============================================================================

module example (
input wire data_en ,
input wire data_in ,
output reg data_even ,
output reg data_odd
);
parameter DLY = 1'd1;
reg odd_en;
wire even_en = ~odd_en;

always @(posedge clk_in or negedge rst_n) begin
if (!rst_n) begin
odd_en <= #DLY 1'd0;
end
else if (!data_en) begin
odd_en <= #DLY 1'd0;
end
else begin
odd_en <= #DLY ~odd_en;
end
end

always @(posedge odd_en or negedge rst_n) begin
if (!rst_n) begin
data_odd <= #DLY 1'd0;
end
else begin
data_odd <= #DLY data_in;
end
end

always @(posedge even_en or negedge rst_n) begin
if (!rst_n) begin
data_even <= #DLY 1'd0;
end
else begin
data_even <= #DLY data_in;
end
end
endmodule
[/source]

In the code above, when input signal data_en goes HIGH, the register odd_en starts to flip at positive edge of clock clk_in. When odd_en flips to HIGH, the input data data_in is registered into output data_odd; Whereas when it flip to LOW, wire even_en goes HIGH, and the input data data_en is registered into output data_even.

If you build a test bench for this module, you will find it works exactly as we expected. However, is it a good design? Is there any potential problem in this design? Is it really a synchronous design? Think them through, and let me explain them in the next paragraph.

First question, is it a good design? No, although it seems working in simulation, it doesn't necessarily working as expected when implemented into circuit. The second question, is there any potential problem in this design? Yes, cause in this design, two locally generated clocks are used. To be specific, registers data_odd and data_even are using generated clock odd_en and even_en respectively. Some people do not realise that when they write code as 'always @(posedge some_thing or negedge rst_n)', the signal some_thing here has implied a clock. If only not all registers in one module share the same clock signal, the module could not be taken as a synchronous design and thus multiple-clock-domain-crossing issues must be considered when registers in two clock domains have data transfers.

Take the previous code as example, the input signal data_in is synchronous to input clock clk_in. As internal logic of the example module, this incoming signal data_in is then registered to two registers -- data_even and data_odd -- that are driving by two locally generated clocks (even_en and odd_en). However, since data_in is synchronous to clk_in but not odd_en or even_en, how can we ensure that signal data_in will remain unchanged during the sampling edges of odd_en and even_en? What will happen if odd_en becomes HIGH while data_in is changing? Well, data_odd may enter metastable state (none HIGH nor LOW logic, just like 1'dZ) and then propagate this state through its following data path.

Someone may think that, since odd_en and even_en is created from clk_in, their flipping edges must be naturally aligned to the edges of clk_in, thus they are practically 'synchronous' to input signal data_in, problem solved! Indeed, I would say that it is possible to align the edges of these 'clocks', but to reach this goal, extra synthesis constraints have to be applied to the two locally generated clocks. This not only brings us more pending works to do, but also increases the risk that the design may fail to reach target performance.

In VHDL or SOC system design projects, normally we divide modules not only by functions, but also by clock domains. By constraining each module with sole clock, clock-domain-crossing problems could be systematically solved in betweens of modules using different clocks, and all generated clocks in the whole system should be gathered in a dedicated module to ensure all timing constraints are met as expected.

Locally created resets are risky too.

II. How To Avoid Locally Created Clocks & Resets

III. The Correct Way To Create Clocks & Resets

+2

0