Miscellaneous Issues. TIE Logic Synthesis Arto Perttula Tampere University of Technology Spring 2017

Transcription

1 Miscellaneous Issues TIE Logic Synthesis Arto Perttula Tampere University of Technology Spring 2017

2 Contents Tri-state logic, high-impedance state Z Variables versus signals in VHDL The notorius latches Several synthesis examples here and there Example codes can be downloaded from the course web site Arto Perttula

3 About Exam For-loop in HDL: known bounds, parallel HW, single cycle (or combinatorial delay) RTL vs. structural is about style: if/for/case vs. instantiations, not necessarily about the abstraction level Usually structural model connects RTL or other structural blocks together Philosophically structural could also use basic gates, but that is commonly dubbed as gatelevel, and that is below RTL Mark signal tansitions clearly and use lines for 1-bit signals Like this, så här Arto Perttula

4 BIDIRECTIONAL I/O WITH TRI-STATE LOGIC Arto Perttula

5 Simplex, Half-Duplex, (Full) Duplex 3 basic types of communication channels Arto Perttula

6 Channel Control Only two communicating blocks in the simplest case During transfer master initiates transfers slave accepts transfers and responds to them In some cases, a certain block can act both as master and slave Many buses are shared multimaster buses shared = more than 2 units multimaster = more than 1 master arbitration mechanism decides which has the ownership Arto Perttula

7 Bidirectional IO Port Three-state buffer allows output ports to have a) logical 0 or 1 value b) hi-z (high-impedance), aka. tri-state In high-impedance state, the buffer s input is not connected to its output Output floats Other blocks can drive it a) Pull-up/down resistors are often used Buffer is stronger than pull-up b) Hold circuit keeps the last value The output_enable signal oe selects between conducting and Hi-Z states Arto Perttula

8 Bidirectional IO Port (2) Only 1 output can be drived at any time to avoid short-circuit! Bus protocol defines arbitration policy How to select current master (driver) block Note that here the tri-state enable TRISn is active low. Arto Perttula Fig. R. Reese 8

9 Tri-State Just in I/O, Not on Chip Three-state should be used only in I/O pins Difficult to test that only one driver is active at any time Pull-up/Bus keeper logic problematic Simplifies PCB design (less components and wires) Not inside chip! Use multiplexers instead Logic is cheap verification is expensive We consider multiplexer-based buses to be the only acceptable architecture for on-chip interconnect. Tri-state buses should never be used on chip. Keating, Bricaud, Reuse Methodology Manual Conditions (such as if-else and case) are synthesized differently with tri-state logic! There won t be a multiplexer but a special tri-state buffer Note also that tri-state buffer is after DFF in synchronous logic Arto Perttula

10 Tri-State Logic in VHDL High-impedance state denoted with Z process (...) -- both seq. and comb. possible begin... if (...) data_out <= new_value; else data_out <= (others => Z ) 10

11 Note on Following Examples These simple examples have three purposes 1. Show how to implement tri-state logic in VHDL 2. Show the schematic created by synthesis tool 3. Show the resulting wave form After this course, you should be able to understand the correlation between 1. HDL and HW (all constructs are not synthesizable!) 2. HDL and simulator output You can perform simple simulation and synthesis in your head Arto Perttula

12 Example: tri_state1.vhd reg_z: process (clk, rst_n) begin if rst_n = '0' then test0_out <= '0'; elsif clk'event and clk = '1' then if ctrl_in = '1' then test0_out <= data_in; else test0_out <= 'Z'; end if; end if; end process reg_z; comb_z: process (ctrl_in) begin if ctrl_in = '1' then test1_out <= '1'; else test1_out <= 'Z'; end if; end process comb_z; Arto Perttula

13 tri_state1 HW (OK) Arto Perttula

14 Wave Form of tb_tri_state1 Arto Perttula 14

15 Mismatch between Tri-State Logic Simulation and Synthesis Propagation Z cannot propagate through flip-flop in real circuit Z cannot propagate through real logic gates Physical DFF s or gate s output will be undefined if its input is Z (=floating somewhere between GND and VDD) Same notes apply U, X, H, L, and - Z must be assigned to output port directly Arto Perttula

16 tri_state2.vhd reg_z _ process -- similar to previous, but -- intermediate signal test0_r used instead -- of output. Registers gets either data_in or Z test0_out <= test0_r; reg_z_bad: process (clk, rst_n) begin -- process reg_z if rst_n = '0' then test1_out <= '0'; elsif clk'event and clk = '1' then test1_out <= test0_r; end if; end process reg_z_bad; comb_z_bad: process (test0_r, enable_in) begin -- process comb_z test2_out <= test0_r and enable_in; end process comb_z_bad; Arto Perttula

17 HW from tri_state2.vhd (BAD) Arto Perttula 17

18 Mismatch between Tri-State Logic Simulation and Synthesis -2 a 2. Reading if a_in /= ZZZ then -- may work in simulation but makes no sense in synthesis There is not any logic circuit that can detect if input is Z Depending on technology and phase of the moon, Z at input will be interpreted as 0 or 1 One cannot predict the result! Same notes apply to U, X, H, L, and - Logic must read some control signal to see if data is valid Example: HW using the value of a which might be Z : 0 0 Z b non-deterministic value from AND a Z b something_else 1 0 Arto Perttula

19 tri_state3.vhd test0_out <= std_logic_vector(accu0_r); test1_out <= std_logic_vector(accu1_r); test_z_bad : process (clk, rst_n) begin if rst_n = '0' then accu0_r <= (others => '0'); elsif clk'event and clk = '1' then if data_in /= "ZZZZ" then accu0_r <= accu0_r + signed(data_in); end if; end if; end process test_z_bad; read_ctrl_ok : process (clk, rst_n) begin -- process reg_z if rst_n = '0' then accu1_r <= (others => '0'); elsif clk'event and clk = '1' then if ctrl_in = '1' then accu1_r <= accu1_r + signed(data_in); end if; end if; end process read_ctrl_ok; Arto Perttula

20 tri_state3 HW in Design Vision Error: Illegal use of tri-state variable (ELAB-306) *** Presto compilation terminated with 1 errors. *** Had to comment out the process test_z_bad! Hence, no logic is synthesized for that Sidenote: This schematic is harder to read Wide data (although just 4 bits ) No hierarchy 4-bit register is spread around Logic for multiplexers and adders combined Hierarchy can be added by grouping cells together Arto Perttula

21 tri_state3 HW on Quartus Arto Perttula

22 Tri-State Summary Use for I/O between chips Just for chip s I/O pins and not between logic modules on chip Usually with bidirectional I/O Some cases Z assigned to regular unidirectional output E.g., many slave outputs connected to single input at master, such as multiple memories connected to same CPU Third signal state high-impedance Lets the signal voltage float and some other device may drive it Assigned by writing Z to the signal/port Cannot be propagated through real DFFs or gates Presence of Z cannot be tested directly Must use separate valid signal to see when signal can be read safely Simulation and real HW do not always match! Arto Perttula

23 ABOUT VHDL VARIABLES Arto Perttula

24 Variables in VHDL Variables allow a more sequential style of programming It seems alluring option BUT: a death cap also looks nice but is venomous inside For communication between processes, only signals can be used There are so called shared variables but we won t use them With TEXTIO, variables are must In procedures and functions, variables can be used Certain structures are best captured with variables The problems are related to synthesis and not seeing the values in simulator Arto Perttula

25 Variables vs. Signals In contrast to signals, the order of reading/assigning variables is important. Remember: 1. The value assigned to a signal can be read back only after at least a delta cycle 2. Another way of looking at it (in case of a flip-flop): a) a signal allows to read only the Q output of a flip-flop b) a variable also makes it possible to read the D input of a flip-flop incr : process (clk, rst_n) variable sum_v... begin if rst_n... elsif rising_edge(clk) then sum_v := sum_r + 1; sum_r <= sum_v; if sum_v =... end process ; +1 + sum_v D Q if... sum_r Arto Perttula

26 Relation between HDL and HW Given the usual RTL paradigm, the relationship between 1. VHDL signals and the hardware they represent, can be explained rather easily 2. VHDL variables and the hardware they represent (or don t!) is much subtler Note! Not the variables themselves, but references to them imply storage or not (i.e., thus a register or not) The same variable name may represent a combinatorial value in one reference, and a register value in another Arto Perttula

27 comb VHDL HW: Combinatorial Process 1. Signal assignment: Must get a value for every execution of the process. OK. Otherwise, it will create a latch Recommendations: Assign signals in every if-branch or give them default value and override it later It is not recommended to read a value that is written in the same combinatorial process, otherwise, signal must be on sensitivity list and process must iterate Write a complete sensitivity list 2. Variable assignment: Implies combinational logic when always written before read. OK. Must get a value for every execution of the process Otherwise, it will create a latch just like signal would If read before written, behaviour in synthesis may vary Pretty similar behaviour between signals and variables Arto Perttula

28 VHDL HW: Sequential Process 1. Signal assignment: Always implies a register Registers are created for all signal and port assignments unless there is a redundancy that can be merged with another register Very simple! Easy to remember and analyze 2. Variable assignment: a) Implies combinational logic when always written before read Good! See earlier example on sum_v b) Implies a register if variable read before written c) Alternately implies a register if variable has a life time May be hard to figure out which variables imply registers Some will imply many, some will imply one, some will imply none The designer does not master the HW that he/she is designing Signals and variables differ clearly Their timing in simulator might look identical, but behaviours differ comb Arto Perttula

29 Variables in Combinatorial Process (var1.vhd) -- Invert the input signal comb_ok : process (a_in) variable inv_v : std_logic; begin -- process comb inv_v := not a_in; test0_out <= inv_v; end process comb_ok; -- Stores the prev value of a_in seq_help : process (clk, rst_n) begin -- process seq_help if rst_n = '0' then tmp_r <= '0'; elsif clk'event and clk = '1' then tmp_r <= a_in; end if; end process seq_help; -- Tries to indicate if input -- has been high for more than -- 1 cycle comb_bad: process (a_in, tmp_r) variable last_a_v : std_logic; begin -- process comb_bad if tmp_r = a_in then last_a_v := a_in; -- else branch missing end if; test1_out <= last_a_v; end process comb_bad; Arto Perttula

30 Variables in Combinatorial Process: Resulting HW (var1.vhd)

31 Wave Form of var1.vhd 31

32 VHDL Code of var2 seq_ok : process (clk, rst_n) variable comb_v : std_logic; begin -- process seq_ok if rst_n = '0' then test0_r <= '0'; test1_out <= '0'; test2_out <= '0'; -- reset values are ok elsif clk'event and clk = '1' then comb_v := a_in; test0_r <= comb_v; test1_out <= comb_v and b_in; test2_out <= test0_r and b_in; end if; end process seq_ok; test0_out <= test0_r; Arto Perttula

33 Wave Form of var2.vhd

34 HW of var2.vhd Arto Perttula

35 VHDL Code of var3 seq_baddish : process (clk, rst_n) variable dff_v : std_logic; begin -- process seq_baddish if rst_n = '0' then test0_out <= '0'; -- value comes from var test1_r <= '0'; -- value comes from signal dff_v := '0'; elsif clk'event and clk = '1' then if a_in = '1' then dff_v := not dff_v; test1_r <= not test1_r; Invert the output every time when input a end if; is 1 test0_out <= dff_v; end if; end process seq_baddish; test1_out <= test1_r; -- just a wire Arto Perttula

36 Wave Form of var3.vhd Identical outputs. So far, so good... Arto Perttula

37 HW of var3.vhd 37

38 When to Use Variables When they simplify non-synthesizable design (=test bench) notably Especially, when modeling memory (RAM) Because variables do not have an event queue associated, their space requirement (memory footprint on your workstation/pc) is about ten times smaller than the equivalent signal For large RAMs this could prevent running out of memory If you are absolutely certain and can assure everyone around you that they simplify synthesizable code Arto Perttula

39 ABOUT LATCHES Arto Perttula

40 Latches and Flip-Flops Two categories of memory elements 1. level sensitive latches 2. edge-triggered flip-flops Various types Some are unnecessarily difficult to use Edge-triggered behaviour simplifies timing analysis Simple data flip-flop (DFF) is superior and the others are obsolete and should be avoided Arto Perttula

41 Why Are D-Latches Good? Compared to edge triggered flip-flops Less area Less power Allow cycle-stealing/time-borrowing Hence, latches were/are used in real designs But that is intentional and done by experienced professionals (senior full-custom ASIC designers) Usually, only in full-custom design (Intel and AMD but not too many others), like CPU pipeline However, most latches in student design are unintentional and therefore very harmful Arto Perttula

42 Why Are Latches Evil? 1. They are nightmare for Static Timing Analysis tools Use of STA tools is mandatory 2. They are bad for Design for Test tools Use of DFT tools is mandatory for ASIC 3. There aren t any latches in FPGAs One may emulate them with LUT and flip-flops 4. Glitches in the enable pin of the latches cause improper functioning. Glitch-free logic is hard to synthesize. 5. Latches in feedback loops may create unintentional oscillator Arto Perttula

43 Example Latch Usage We can connect some latches, acting as memory, to an ALU +1 S X ALU G Q Latches D en Let s say these latches contain some value that we want to increment The ALU should read the current latch value Q via input X It applies the increment operation G = X+1 The incremented value is stored back into the latches At this point, we have to stop the cycle, so the latch value doesn t get incremented again by accident One convenient way to break the loop is to disable the latches by driving en=0 Arto Perttula

44 The Problem with Latches +1 S X ALU G Q Latches D en enable generation The problem is exactly when to disable the latches. You have to wait long enough for the ALU to produce its output, but no longer. But different ALU operations have different delays. For instance, arithmetic operations might go through an adder, whereas logical operations don t. Changing the ALU implementation, such as using a carry-lookahead adder instead of a ripple-carry adder, also affects the delay In general, it s very difficult to know how long operations take, and how long latches should be enabled for If you take the max. delay you could as well use regular edge-triggered DFF Arto Perttula

45 Latch Timing Example transparent =D latch latched Setup and hold w.r.t. falling edge of CLK CLK pulse width must be larger than certain min. value Ambiguity regarding exactly when the D input gets latched into Q If a transition in D occurs sometime during a clock HIGH, what will occur? The answer will depend upon the characteristics of the particular electronics being used This lack of clarity is often unacceptable [Ray Frey,

46 Inferred Latch Example process(enable, data_in) so far, so good begin if (enable='1') then... badass <= data_in; -- so far, so good else branch missing! so bad end if; end process; Combinational process (=logic), but the signal badass does not get a value assigned in every possible branch Logic will have to remember the last value when enable= 0 Common mistake Arto Perttula

47 (Not) Inferring Latches 1. Latches are inferred by branch statements (if-elsif) which are not completely specified in combinatorial process To avoid Latch being developed 1. Assign an output for all possible input conditions 2. Use an else statement instead of an elsif in the final branch of an if to avoid a latch 3. You may assign default values at the beginning of a process to avoid an inferred latch 2. When the event statement is missing in sequential process Arto Perttula

48 (Not) Inferring Latches (2) ps/avoid_synthesizing_unwanted_latches/ uments/techdocs/3583.htm Arto Perttula

49 Conclusions Be careful with reset Be careful with clocks Be careful with Z Avoid variables in most cases Avoid latches in practically all cases Arto Perttula