Verilog로 어떤 코드를 쓰느냐에 따라, latch가 합성 될 수도 있고 Flip flop이 합성 될 수도 있다.
그러나, 우리는 Latch보다 Flip Flop을 사용한다. Flip flop은 데이터를 active edge에서만 값을 채오기 때문에 glitch에서 latch보다 더 안정적이며, 우리는 회로의 clock edge에서 동작하는 회로를 만든다. latch는 enable이 들어오면, D값에 따라 Q값이 계속 변한다..
Full case란, 모든 경우의 수가 정의되어 완성된 조건문이다. -> Flip flop 합성 됨.
정의는 이렇고, 예시를 들어보겠습니다.
input [1:0] Sel;이 있는 경우, Sel의 경우의수는 00, 01, 10, 11입니다.
Verilog에서
case (Sel)
2'b00 : Data_Out = A;
2'b01 : Data_Out = B;
2'b10 : Data_Out = C;
2'b11 : Data_Out = D;
endcase
처럼 case의 모든 조건이 모두 주어졌을 때.
혹은, Default가 있어서, 모든 조건이 완성된 경우.
case(1’b1)
Sel_A : Data_Out = A;
Sel_B : Data_Out = B;
Sel_C : Data_Out = C;
default : Data_Out = D;
endcase
Non-Full case -> Latch 합성됨.
case (Sel)
2'b00 : D_Out = A;
2'b01 : D_Out = B;
2'b10 : D_Out = C;
endcase
2’b11인 경우의 수가 없음. Sel이 2’b11이 들어온 경우, D_Out은 값 변화 없이 이전 값을 유지해야한다. 그래서 Latch 합성됨.
그러나, 디지털 회로 설계에선, Latch가 반드시 필요한 경우가 아니라면, 보통 Flip flop만 사용한다.
Sel은 10비트의 크기를 가진 Signal이지만, Sel에 실제로 출력되는 경우의 수는 5개만 있다고 가정하자.
아래와 같은 코드를 작성하고 싶을 것이다. 하지만, 아래처럼 쓰면 합성 단계에서 Latch가 합성된다.
case (Sel)
10'b0000000000 : D_Out = A;
10'b0000000001 : D_Out = B;
10'b0000000010 : D_Out = C;
10'b0000000011 : D_Out = D;
10'b0000000100 : D_Out = E;
endcase
헌데, Synopsys社의 Design Compiler 같은 합성 툴의 경우, 이러한 경우를 위한 함수가 들어있다.
조건문 옆에 //synopsys full_case라고 써주면, verilog simulation tool에선, 이를 주석으로 인식한다. 하지만 합성 툴에선, 이를 Flip flop으로 합성 가능한 Non-Full case라고 인식을 한다. (자세한건 Full_case Directive라고 찾아보기!)
case (Sel) //synopsys full_case
10'b0000000000 : D_Out = A;
10'b0000000001 : D_Out = B;
10'b0000000010 : D_Out = C;
10'b0000000011 : D_Out = D;
10'b0000000100 : D_Out = E;
endcase
Simulation Tool에선 위 코드에 Latch를 생성하고, Synthesis Tool에선 위 코드에 Flip flop을 생성하기 때문에,
Simulation과 Synthesis의 불일치, 즉 Pre-synthesis와 Post-synthesis간 mismatch가 존재 할 수 있다.
1비트 짜리 신호 In_A, IN_B, In_C, In_D가 있다고 가정하겠습니다. 아래 코드를 먼저 보겠습니다.
case (Sel)
In_A : Data_Out = Out_A;
In_B : Data_Out = Out_B;
In_C : Data_Out = Out_C;
In_D : Data_Out = Out_D;
endcase
Sel이 들어올 때, In_A만 1이고, 나머지는 0이라면 Data_Out에는 A가 출력된다.
그러나 In_A, In_B, In_C, In_D 모두 1이라면?
우선순위 선택 회로가 추가적으로 생겨서, In_A, B, C, D중 하나만 활성화가 된다. 즉, HDL에 작성하지 않은… 설계자의 의도가 들어가지 않은 로직이 추가된다.
설계자가, 이 로직에는 반드시 In_A, B, C, D중 하나만 1이 된다고 알고 있다면, 아래와 같은 코드를 작성 할 수 있다.
case (Sel) // synopsys parallel_case
In_A : Data_Out = Out_A;
In_B : Data_Out = Out_B;
In_C : Data_Out = Out_C;
In_D : Data_Out = Out_D;
endcase
위처럼 작성시,
Synopsys사의 Synthesis tool에선 우선순위 선택 회로가 합성되지 않는다.
Simulation Tool에선 위 코드의 //synopsys parallel_case를 주석처리하여 우선순위 선택 회로를 생성하고, Synthesis Tool에선 함수처럼 취급하여, 우선순위로직을 작성하지 않는다.
Simulation과 Synthesis의 불일치, 즉 Pre-synthesis와 Post-synthesis간 mismatch가 존재 할 수 있다.
조건문은 어떤식으로 회로가 설계 되는지 아시나요?
if(sel) { Data out = Data_in}
else { Data_out = ~Data_in}
같은 문이 있을 경우,
MUX가 생깁니다. Data_in과 ~Data_in이 MUX의 각 입력이 되고, sel은 신호 제어 선이 됩니다.
기본적으로, 조건문 if 하나 거치려면 mux 하나를 통과해야합니다.
즉, 조건 8개가 있는 if문이나 case문을 통과하려면 8개의 2to1 MUX를 통과해야합니다.
하지만 이것은 크기도 많이 차지하고, 타이밍도 늦습니다.
아래와 같은 코드를 작성해주면,
case (Sel) // synopsys infer_mux
3'b000 : Data_Out = A;
3'b001 : Data_Out = B;
3'b010 : Data_Out = C;
3'b011 : Data_Out = D;
3'b100 : Data_Out = E;
3'b101 : Data_Out = F;
3'b110 : Data_Out = G;
3'b111 : Data_Out = H;
endcase
8to1 mux가 생성됩니다. 예를들어 101이 들어오면 8to1 MUX 1개만 통과하고 끝냅니다.
‘그러면, 조건문 쓸 때는 항상 infer_mux 써주면 되나?’ 라고 생각할 수 있는데, 아닙니다.
아래 같은 코드가 있다고 가정합시다.
always @ (In_1, In_2)
begin
case ({In_1, In_2})
2'b00 : Data_Out = In_1;
2'b01 : Data_Out = In_2;
2'b10 : Data_Out = In_1 & In_2;
2'b11 : Data_Out = In_1 | In_2;
endcase
end
- infer_mux를 써준 경우 :
(1) 00일 때는 In_1이 바로 4to1 mux의 Input으로 들아갑니다.
(2) 01일 때는 In_2가 바로 4to1 mux의 Input으로 들아갑니다.
(3) 10일 때는 AND를 타고 4to1 mux에 들어갑니다.
(4) 11일 때는 OR게이트를 타고 4to1 mux에 들어갑니다.
즉, 4to1 mux, and, or 게이트가 필요합니다.
- infer_mux를 안 써준 경우 :
(1) 00일 때는 In_1이 들어가는데, 00이라면 In_1이 0이므로 Data_Out은 0입니다.
(2) 01일 때는 In_2이 들어가는데, 01이라는 것은 In_2가 1이므로 Data_Out은 1입니다.
(3) 10일 때는 In_1&In_2이므로, 항상 0이 됩니다.
| (4) 11일 때는 In_1 | In_2이므로 항상 1이 됩니다. |
In_2가 0이면 0, In_2가 1이면 1이 됩니다. 고로 아무 게이트가 필요 없고, 입력도 In_2만 있으면 이 case문을 나타낼 수 있습니다.