Table of Contents
Controlling Synthesis
Synthesis Attributes (IEEE 1076.6 - 2004)
- Synthesis tools: can be told to optimize either speed or area
- Sometimes finer control is needed ➔ include “attribute specifications”
- However, different tools support different attributes… ➔ read documentation
- IEEE 1076.6-2004 RTL synthesis standard: defines minimal set of synthesis attributes
- Example: FSM_STATE and ENUM_ENCODING ➔ controlls FSM and enum encoding
package RTL_ATTRIBUTES is -- This package shall be analyzed into library IEEE. attribute KEEP : boolean; attribute CREATE_HIERARCHY : boolean; attribute DISSOLVE_HIERARCHY : boolean; attribute SYNC_SET_RESET : boolean; attribute ASYNC_SET_RESET : boolean; attribute ONE_HOT : boolean; attribute ONE_COLD : boolean; attribute FSM_STATE : string; attribute FSM_COMPLETE : boolean; attribute BUFFERED : string; attribute INFER_MUX : boolean; attribute IMPLEMENTATION : string; attribute RETURN_PORT_NAME : string; attribute ENUM_ENCODING : string; attribute ROM_BLOCK : string; attribute RAM_BLOCK : string; attribute LOGIC_BLOCK : string; attribute GATED_CLOCK : boolean; attribute COMBINATIONAL : boolean; end package RTL_ATTRIBUTES;
Notes
Synthesis tools: can be told to optimize either speed or area Sometimes finer control of the synthesis process is needed ➔ one way in which we can do so is by including “attribute specifications” in our models to direct a synth.tool to infer hardware in particular ways.
Ashenden 3rd, p659: Different synthesis tools support different attributes to specify different aspects of hardware inference and different aspects of target technologies. This is possibly an aspect in which tools most widely diverge, since the attributes a given tool supports reflect the particular capabilities and synthesis algorithms implemented by the tool. We need to refer to a tool’s documentation to discover what attributes are supported and how to use them. In an effort to create at least a small amount of harmony, the IEEE 1076.6 synthesis standard defines a minimal set of synthesis attributes. We describe them here, as they are indicative of the kinds of attributes supported by tools. The standard specifies a package of attribute declaration to be analyzed into the ieee library. While we could declare the attributes ourselves in each design, using the standard package is more convenient. Synthesis tools usually include similar packages for their implementation-defined attributes. The standard package is ….
ENUM_ENCODING (IEEE 1076.6 - 1999)
- attribute “ENUM_ENCODING”: ➔ defines how enumerated data types are encoded
- arbitrary, user defined encoding possible
- only official synthesis attribute in IEEE 1076.6-1999
- does work in Synplify Premier (Synopsys)
- attribute “syn_enum_encoding”: ➔ does the same (own, Synplify specific attribute)
-- Example shows ENUM_ENCODING used to describe one-hot encoding: attribute ENUM_ENCODING: string; type COLOR is (RED, GREEN, BLUE, YELLOW, ORANGE); attribute ENUM_ENCODING of COLOR: type is "10000 01000 00100 00010 00001"; -- Enumeration literal RED is encoded with the first value 10000, GREEN with 01000, and so on. -- example for FSM state encoding: attribute ENUM_ENCODING of state_T : type is "001 010 100 110 111" --IEEE 1076.6, also works in Synplify attribute syn_enum_encoding of state_T : type is "001 010 100 110 111" --only in Synplify
Notes
Ashenden 3rd, p659: Different synthesis tools support different attributes to specify different aspects of hardware inference and different aspects of target technologies. This is possibly an aspect in which tools most widely diverge, since the attributes a given tool supports reflect the particular capabilities and synthesis algorithms implemented by the tool. We need to refer to a tool’s documentation to discover what attributes are supported and how to use them…. Synthesis tools usually include similar packages for their implementation-defined attributes.
FSM_STATE (IEEE 1076.6 - 2004)
- attribute “FSM_STATE”: ➔ directs the tool to encode the state vector of an FSM in a specified way
- The allowed attribute values are:
- “BINARY”: unsigned binary encoding with the minimal number of bits (LOG2(N))
- “GRAY”: Gray coding, in which exactly one bit value changes on each transition
- “ONE_HOT”: an encoding in which each code value has exactly one ‘1’ bit
- “ONE_COLD”: an encoding in which each code value has exactly one ‘0’ bit
- “AUTO” or empty string: the tool selects an encoding
- does NOT work in Synplify Premier (Synopsys)
- attribute “syn_encoding”: ➔ does the same (own, Synplify specific attribute)
attribute FSM_STATE: string; --IEEE 1076.6, not supported by Synplify type state_t is (S1, S2, S3, S4); signal STATE1, STATE2, STATE3, STATE4 : state_t; attribute FSM_STATE of STATE1 : signal is "BINARY"; -- S1 = "00", S2 = "01", S3 = "10", S4 = "11" attribute FSM_STATE of STATE2 : signal is "GRAY"; -- S1 = "00", S2 = "01", S3 = "11", S4 = "10" --in Synplify: attribute syn_encoding of STATE1 : signal is "sequential" -- ="BINARY" in Synplify
syn_encoding (Synplify Synthesis / Synopsys)
Values for syn_encoding are as follows:
- default - Automatically assigns an encoding style based on the number of states:
- sequential: 0-4 enumerated types
- onehot: 5-40 enumerated types
- gray: >40 enumerated types
- sequential - More than one bit of the state register can change at a time, but because more than one bit can be hot, the value must be decoded to determine the state. For example: 000, 001, 010, 011, 100
- onehot - Only two bits of the state register change (one goes to 0; one goes to 1) and only one of the state registers is hot (driven by a 1) at a time. For example: 0000, 0001, 0010, 0100, 1000
- gray - Only one bit of the state register changes at a time, but because more than one bit can be hot, the value must be decoded to determine the state. For example: 000, 001, 011, 010, 110
- string - This can be any value you define. For example: “001, 010, 101”
Notes
same again in synplify, can be ommited
Retiming
- a feature in some Synthesis tools
- Retiming automatically moves registers (register balancing) across computational elements (i.e. LUTs) to improve timing performance in sequential circuits
- Ensures identical behavior; does not change the number of registers in a path
- However, it can change the total number of registers in a design - because registers could get duplicated to improve fan-out!
Synplfify FPGA Synthesis User Guide, © Copyright 2009 Synopsys, Inc.
Notes
Option Retiming: (Synplify Pro and Synplify Premier) - Determines whether the tool moves storage devices across computational elements to improve timing performance in sequential circuits. Retiming is a powerful technique for improving the timing performance of sequential circuits without having to modify the source code. Retiming automatically moves registers (register balancing) across combinatorial gates or LUTs to improve timing while ensuring identical behavior as seen from the primary inputs and outputs of the design. Retiming moves registers across gates or LUTs, but does not change the number of registers in a cycle or path from a primary input to a primary output. However, it can change the total number of registers in a design.
Timing is improved by transferring one level of logic from the critical part of the path (register1 to register2) to a non-critical part (reg2 to reg3).
Logic levels
- longest path (3 logic levels here) determines maximum clock frequency!
Logic levels - after retiming
- reduced logic levels after retiming: only two now
- reduced critical path allows a higher clock frequency!