分频电路

Love The Way You Lie 2022-07-16 01:19 340阅读 0赞

第一次写技术性的blog，就先选择一个看似简单的话题吧。

无论从算法上还是逻辑上，这个题目都非常简单，但是对于ASIC工程师，恐怕却是一个不小的挑战。

首先，看看我们的目标：

![wave1633808457876875000.JPG][]

很简单吧，只要在响应的输入时钟沿上产生输出的翻转就可以了。但是对于ASIC工程师，却有很多东西是值得讨论的。

1.行为级的实现是非常简单的，只要你会写C，就可以简单的用verilog写出来，甚至连语法都基本一致：

[always@( negedge resetn or posedge][always_ negedge resetn or posedge] clk or negedge clk)

begin

if (resetn==1'b0)

begin

counter\[2:0\]<=3'd0;

out\_clk<=1'b0;

end

else

begin

if (counter\[2:0\]==3'd5)

begin

counter\[2:0\]<=3'd0;

end

else

beign

counter\[2:0\]<= counter\[2:0\]+1;

end

if (counter\[2:0\]==3'd5 || counter\[2:0\]==3'd2)

begin

out\_clk<=~out\_clk;

end

不要不相信这种写法，现在甚至还有一些书仍然有类似的范例。其仿真结果也确实是正确的

![wave2.JPG][]

但是如果你只是想做一个测试仿真用还可以，要是想做真正的芯片那会被人嘲笑的。因为这个逻辑在现有的条件下无法综合。没有支持2个时钟沿的寄存器。所以这个写不对不是因为逻辑问题，而纯粹是现在的半导体工艺问题，也许以后会有支持双沿的寄存器。

2.下面给出一个逻辑图，很值得回味的。

![wave3.JPG][]

这个逻辑是用器件画出来的，所以肯定不存在物理上的实现问题。但是其工作过程在逻辑上却有些让人头痛。如果你的数字电路学的很扎实，可以写一下方程来验证一下。在实际的实验中我相信它也80％以上是工作的。

仿真图如下：

![wave4.JPG][]

也许有人要问，既然仿真都是对的，那么为什么要说实际中是80％工作呢？

看到波形图上的clk1（黄色）上的那些毛刺了么，毛刺并不可怕，但是这个电路工作的基础却是那些毛刺，准确地说，那些毛刺是必须有的，是工作过程的比不可少的部份。这样的电路是否能正常工作就很让人匪夷所思了。

我们能不能让电路的正常功能不依赖于毛刺呢？

小结一下：

以上的思路都是试图在输入的clk上做改造，试图在恰当的地方取正沿，恰当的地方取反沿。但是要知道，这一定会导致竞争和冒险。虽然逻辑上是可性的，但是实践中却没有那么简单。这个时候，我们需要调整一下思路了：

能不能营造一个安全的时机来切换时钟沿的选择？显然，这需要在切换时钟沿时，强制时钟输出固定电平，当切换完成后，在取消这个强制条件。对么？我们来试试看。

3. 看看以下的代码，也是一段有趣的东西。

[always@(negedge][always_negedge] resetn or posedge clk)  
begin  
if (resetn==1'b0)  
begin  
cnt1\[1:0\]<=2'd0;  
end  
else  
begin  
if(cnt1\[1:0\]==2'd2)  
begin  
cnt1\[1:0\]<=2'd0;  
end  
else  
begin  
cnt1\[1:0\]<=cnt1\[1:0\]+1;  
end  
end  
end

[always@(negedge][always_negedge] resetn or negedge clk)  
begin  
if (resetn==1'b0)  
begin  
cnt2\[1:0\]<=2'd0;  
end  
else  
begin  
if(cnt2\[1:0\]==2'd2)  
begin  
cnt2\[1:0\]<=2'd0;  
end  
else  
begin  
cnt2\[1:0\]<=cnt2\[1:0\]+1;  
end  
end  
end

always@\*  
begin  
if (cnt1\[1:0\]==2'd2 || cnt2\[1:0\]==2'd0)  
begin  
clk1 = 1'b0;  
end  
else if (cnt1\[1:0\]==1'b1)  
begin  
clk1 = ~clk;  
end  
else  
begin  
clk1 = clk;  
end  
end

[always@(negedge][always_negedge] resetn or posedge clk1)  
begin  
if (resetn==1'b0)  
begin  
clk\_out<=1'b0;  
end  
else  
begin  
clk\_out<=~clk\_out;  
end  
end

最后用的时钟clk1是clk和clk的反，但是在切换之间加上的强制为0的逻辑。

![wave5.JPG][]

这段代码肯定是可综合的，而且简单的约束一下时序就可以生产。

但重要的是看了这段逻辑后我们突然明白了一件事情：要想长生质量好的3分频时钟，我们似乎必须要用到clk的下降沿来做点控制逻辑，这是被反复求证后逼出来的（不知道其它人是否有同感）。那么我们为什么不愿意用下降沿触发的的寄存器呢？因为有些库里可能没有这样的器件，而必须在时钟树上上加反向。如果有下降沿的寄存器，那么今后的扫瞄链又要多一些麻烦，虽然这些麻烦都可以客服，但是作为一个成熟的工程师要明白：尽量不要给自己找麻烦。在工程上，最平常的东西最可靠。

4. 到这里我们的命题似乎解决了，但是我们的思考还不应该停止。既然我们要用clk的下降沿，呢就完全可以打破以前的思路，来看看这个新的手段能给我们带来什么。

[always@(negedge][always_negedge] resetn or posedge clk)  
begin  
if (resetn==1'b0)  
begin  
cnt1\[1:0\]<=2'd0;  
clk1<=1'b0;  
end  
else  
begin  
if(cnt1\[1:0\]==2'd2)  
begin  
cnt1\[1:0\]<=2'd0;  
clk1<=1'b1;  
end  
else  
begin  
cnt1\[1:0\]<=cnt1\[1:0\]+1;  
clk1<=1'b0;  
end  
end  
end

[always@(negedge][always_negedge] resetn or negedge clk)  
begin  
if (resetn==1'b0)  
begin  
clk2<=2'd0;  
end  
else  
begin  
clk2<=clk1;  
end  
end

assign clk\_out = clk1 | clk2;

代码似乎更简单了，思路也完全变了。这回的思路是：先做一个简单的3分频电路，然后再调整占空比。以这个思路，所有的1/N分频都可以解决。

很高兴么？其实是有点失落。我们费了很大的周折，最后的结果竟然是这么传统的分频方法（后加一些调整），如果早知道是这样恐怕都没有人愿意浪费时间来就此问题专门的讨论。

但是我们对结果满意么？似乎有点疑虑。因为我们更喜欢寄存器做最后的输出，而对组合逻辑输出总是觉得不那么妥当。至少我的内心一致有这样的情节。

5. 最后的总结：

写这个东西并不是真的要讨论3分频电路，至少对于我来说不是，我只想说明一个ASIC工程师在面对一个问题时，从理想到现实到现实的挣扎过程。只有每天都经历这个过程的人才明白ASIC工程师的含义和价值。

有时会有人问我做ASIC前端好好事后端好，我不能答。我比较不出好坏，但是我知道要是你想做前端工程师就要时常面对上述的思考过程，这是纯粹脑力的耗费，而结果往往让别人觉得很简单，所以有时你还要承受这样的不平衡。因为对于一个没有真正经历过ASIC工程的人，你耗费的脑力和解释都是苍白的，而这个人很可能就是你的老板。

[wave1633808457876875000.JPG]: /images/20220716/0822b68ab70f48c6a333ac23e2bad3dd.png
[always_ negedge resetn or posedge]: mailto:always@%28%20negedge%20resetn%20or%20posedge
[wave2.JPG]: /images/20220716/5abda54daf2b42a0a9fa1354145e6ea2.png
[wave3.JPG]: /images/20220716/32be91d835ae43a0ad7f11d1b5475e97.png
[wave4.JPG]: /images/20220716/1d3f974d890f4d64b65195262cc2f1c6.png
[always_negedge]: mailto:always@%28negedge
[wave5.JPG]: /images/20220716/6e1304b56531424c87964dc90eaf2667.png