200 likes | 325 Views
ECE 681 VLSI Design Automation. Khurram Kazi Lecture 6 Thanks to Automation press THE button outcomes the Chip !!! Reality or Myth. Blocking vs non Blocking. The difference between the two is that one is similar to variable in VHDL and the other acts like a signal Blocking in synonymous to
E N D
ECE 681VLSI Design Automation Khurram Kazi Lecture 6 Thanks to Automation press THE button outcomes the Chip !!! Reality or Myth
Blocking vs non Blocking • The difference between the two is that one is similar to variable in VHDL and the other acts like a signal • Blocking in synonymous to = assignment (more like a variable) • Where as non blocking is represented by <= assignment
Non blocking assignment • Non blocking infers a flip flop after synthesis (when clock is in the sensitivity list) example 1: reg a, b, c; always @(posedge clk) begin b <= a; // b and c are flip flops c <= b; end
Non blocking assignment • Non blocking infers a flip flop after synthesis (when clock is in the sensitivity list) example 2: reg a, b, c; always @(posedge clk) begin c <= b; // b and c are flip flops in this code also b <= a; end
blocking assignment • blocking statement does not infer a flip flop in synthesis all the time (code dependent) example 3: reg a, b, c; always @(posedge clk) begin b = a; // only c will be a flip flop b will cancel c = b; // out since c is finally equal to a. end
blocking assignment • blocking statement does not infer a flip flop in synthesis all the time (code dependent) example 4: reg a, b, c; always @(posedge clk) begin c = b; // b and c will be a flip flops b = a; end
Why at times blocking assignment is preferred At times some designers prefer blocking as they can see sharing of resources more readily: reg [15:0] a, b, c, d, e, f, g, h; reg [16:0] x, y, z; always @ (posedge clk) begin x = a + b + c + d + e + f; y = x + g; z = x + h; end reg [15:0] a, b, c, d, e, f, g, h; // In this example resource sharing is synthesizer reg [16:0] y, z; // dependant always @ (posedge clk) begin y <= (a + b + c + d + e + f) + g; z <= (a + b + c + d + e + f) + h; end
Why at times blocking assignment is not desired Blocking statement can cause race condition: file first.v module first (a, b, clk) input b, clk; output a; always @ (posedge clk) begin a = b; end file second.v module first ( b, c, clk) input c, clk; output b; always @ (posedge clk) begin b = c; end Some simulators may evaluate module second.v and then module first. This effectively transfers contents of c to a in ONE clock cycle. This is known as simulator race condition. While some other simulators will execute module first followed by second. Hence two different simulation results AVOID USING BLOCKING STATEMENT
Some simple ALU functions shal: f <= a << 1; shar: f <= a >> 1; passa: f <= a; passb: f <= b; default: f <= 8’bx; endcase end endmodule module alu (f, a, b, opcode); parameter addab = 4’b0000, inca = 4’b0001, incb = 4’b0010, andab = 4’b0011, orab = 4’b0100, nega = 4’b0101, shal = 4’b0110, shar = 4’b0111, passa = 4’b1000, passb = 4’b1001; output [7:0] f; input [7:0] a, b; input [3:0] opcode; reg [7:0] f; always @ (a or b or opcode) begin case (opcode) addab: f <= a + b; inca: f <= a + 1; incb: f <= b + 1; andab: f <= a & b; orab: f <= a | b; nega: f <= !a;
Latches implementation if (preset3) y3 <= 1’b1; else if (enable) y3 <= a3; end endmodule module latches (y1, y2, y3, enable, a1, preset1, a2, preset2, a3, preset3); output y1, y2, y3; input a1, preset1; input a2, clear2; input a3, preset3; input enable; reg y1, y2, y3; always @ (a1 or a2 or a3 or preset1 or preset2 or preset3 or enable) begin if (preset1) y1 <= 1’b1; else if (enable) y1 <= a1; if (clear2) y2 <= 1’b0; else if (enable) y2 <= a2;
Inferring counters always @ (posedge clk) begin if (clear) // Sync clear counter y3 <= 0; else y3 <= y3 + 1; end always @ (posedge clk) begin if (up_down) // up down counter direction <= 1; else direction <= -1; y4 = y4 + direction; // NOTICE HERE // y4 assignment is outside the if else end endmodule WOULD THIS CODE GENERATE DANGLING/ UNCONNECTED WIRES OR PORTS??? module counters (y1, y2, y3, y4, y5, y6, d, clk, enable, clear, load, up_down); output [7:0] y1, y2, y3, y4, y5, y6; input [7:0] d; input clk, enable, clear, load, up_load; reg [7:0] y1, y2, y3, y4, y5, y6; integer direction; always @ (posedge clk) begin if (enable) // enable counter y1 <= y1 + 1; end always @ (posedge clk) begin if (load) // loadable counter y2 <= d; else y2 <= y2 + 1; end
Frequency Divider always @ (posedge clk or nededge reset_n) begin if (!reset_n) div11 <= 0; else if (counter == 10) div11 <= 1; else div11 <= 0; end module div11 (clkdiv11, clk, reset_n); output clkdiv11; input clk, reset_n; reg div11; reg [3:0] counter; always @ (posedge clk or nededge reset_n) begin if (!reset_n) counter <= 0; else if (counter == 10) counter <= 0; else counter <= counter + 1; end
FSM with four states else begin next_state <= st_three; lsb <= 1; msb <= 1; end st_one: if (up_down == 0) begin next_state <= st_two; lsb <= 0; msb <= 1; end else begin next_state <= st_zero; lsb <= 0; msb <= 0; end module state_machine (lsb, msb, up_down, clk, reset_n); output lsb, msb; input up_down, clk, reset_n; parameter [1:0] st_zero = 2’b00, st_one = 2’b01, st_two = 2’b10, st_three = 2’b11; reg lsb, msb; reg present_state, next state; always @ (up_down or present_state) // combinatorial part begin case (present_state) //0 = up, 1 = down st_zero: if (up_down == 0) begin next_state <= st_one; lsb <= 1; msb <= 0; end
FSM with four states cont’d else begin next_state <= st_two; lsb <= 0; msb <= 1; end endcase end always @ (posedge clk or negedge reset_n) //sequential part begin if (!reset_n) present_state <= st_zero; else present_state <= next_state; end endmodule st_two: if (up_down == 0) begin next_state <= st_three; lsb <= 1; msb <= 1; end else begin next_state <= st_one; lsb <= 1; msb <= 0; end st_three: if (up_down == 0) begin next_state <= st_zero; lsb <= 0; msb <= 0; end
Simple FIFO using same clock Data in Write pointer Data out • FIFO full • FIFO empty Read pointer Up_down counter
Details of the synchronous FIFO (mini assignment 2) Assume there are 20 clocks in a frame. There can be 8 reads and 8 writes to the FIFO at any time within the frame. Use up down counter to monitor the state of the FIFO, i.e. FIFO full or FIFO empty. Design a 10 word 8 bit wide FIFO Generate traffic, i.e. data writes to the FIFO at different times and read at different times within the frame over multiple frames, let us say at least 20 frames. In some frames have less than 8 writes or reads. Generate FIFO full or empty conditions. Also have a condition where FIFO read and write happen on the same clock cycle. Use flip flop as the memory elements Write the code in Verilog Assignment due on October 16
Details of the synchronous FIFO (mini assignment 2) inputs (clk, reset_n, data_in[7:0]) outputs (data_out[7:0], fifo_empty, fifo_full, dropped_data[6:0]) dropped_data is a counter that keeps track of number of data bytes that were dropped due to data arriving while FIFO was full. For extra credit design a FIFO with different clocks. They should not be integer multiple of each other
Reading Assignment http://www.csix.org/csixl1.pdf Please read it and see if it makes sense to you. We will discuss it in the upcoming lecture.