The goal of this repository is to ensure further development is approachable for the TripleModularRedundancyTool developed in the second half of 2023.
If the reader is interested in how to interact with the implementation through the RTL see TripleModularRedundancyTool User Guide.
This GitHub repository was created as documentation to subsidise a tool developed for triplication and majority voting of ASICs by leveraging industry EDAs, which in this case only covers Synopsys' Design Compiler NXT and Design Vision (GUI).
The TripleModularRedundancyTool was created as a part of a short-term internship at CERN during my 9th semester of my Master's degree in Electronic Systems.
The implementation leans heavily on attributes and has only been tested with SystemVerilog attributes (see pp. 236--240). The way to interact with the implementation is through two attributes and a suffix:
(*default_tmrt="value"*), wherevalueis false/true- This should be applied to module declarations
- This is the default value for whether or not ports, registers, and module instantiations should be triplicated. This will not override the
tmrtattribute if already set
(*tmrt="value"*), wherevalueis false/true- This can be applied to ports, register (inferred by sequential logic), and module instantiations
- This signals the implementation that an element should not follow the default w.r.t triplication, but rather the set value of the attribute
- "_Voted"-suffix
- Can be applied to net declarations
- Will create and insert 3 voters to create an intermediate vote of a net
As the TripleModularRedundancyTool currently stands, the design philosophy follows three steps (in order)
- Update: Updating/propagating the values of the attribute mentioned above to other cells, ports, etc.
- Triplicate: Creating 3 replicants of the elements with
tmrt="true" - Rewire: Drive all new cells appropriately, which includes voting when appropriate
To visualise the three steps the following figures were created, note that blue outline indicates a change of the circuitry. A piece of RTL design with two input ports (could also have been output pins from module instantiations or registers), two logic cells, and an output port (could also be input pins to module instantiations or registers). From the RTL the tmrt attribute has been set to true on input port B, marked with a orange text.
The update step applies the tmrt attribute set to true on all reachable logic cells from port B. This is visualised below with the orange text.
Every element with the tmrt attribute set to true is fetched and triplicated in the triplicate step. The replicants have their inputs driven by the same sources as the original cell, which can be seen below. Furthermore, this step implicitly handles all fanout situations, notice that port A has already been connected to all the correct pins.
The unconnected ports and output pins are handled in the rewire step. All the original elements, from which replicants have been generated, are inspected with a focus on their outputs. If the original cell is driving a triplicated element, the connections are redistributed to the replicants. B_A is driving three redundancy-generated AND-gates, and the connections are redistributed below. However, if the original cell is driving an element that is not triplicated, a voter should be inserted and its output should be connected to the element. This is the case for the three redundancy-generated NOT-gates and in the figure below, they are voted.
To see how the "_Voted"-suffix is handled and voted see Example in vote_nets.
Before you continue the development of the tool, there are a few things, concepts, and interactions you should familiarize yourself with!
- TCL 8.6 (Tool Command Language)
- The language used to interact with the Synopsys tools
- TMR (Triple Modular Redundancy)
- There are several TMR strategies worth investigating. A good start would be looking at the current TMRG used by CERN at the time of writing as this documentation.
- Synopsys' Design Compiler NXT (Will require a SolvNet user)
- Synopsys Design Vision (Will require a SolvNet user)
- Design Vision User Guide
- The 'man pages' through the GUI are also good to familiarize oneself with. They are faster, up to date, and do not include commands that you can't use (which is the case for SolvNet).
W.r.t interactions worth familiarization it is mostly between TCL and the Synopsys Tools. Try running the following commands line-by-line in the Design Compiler NXT CLI:
dcnxt_shell> set cells [get_cells]
dcnxt_shell> puts $cellsYou may see, that the output of puts $cells is something akin to _sel21. This is due to Synopsys using Collections (see ch. 6), which I was unaware of during development. A way of dealing with this interaction is using their built-in function redirect to divert the command output to a variable:
dcnxt_shell> redirect -variable cells {get_cells}
dcnxt_shell> puts $cellsThis will now output the correct value! However, another interaction will be present, try looping over the $cells variable:
dcnxt_shell> foreach cell $cells {puts $cell}All cells are printed in the first loop! The variable is actually an element containing the list... To avoid these specific interactions, a helper function was created: get_synopsys_value. This function is also capable of grabbing relevant information from other function, most notably duplicate_logic -report_only.
And a few small advices:
- Most "return" functions (get_, all_, etc.) have a flag like
-quietorreturn_null_values, which should always be applied! Otherwise, when usingredirectthe value of you variable will become the displayed message. - Attributes cannot be applied to combinational logic from the RTL design, SystemVerilog attributes (see pp. 236--240)
The main script can be found in main_script with a flowchart and the definition of the code.
The scripts and functions used in this tool have been separated in four categories; update, triplicate, rewire, and helper functions, where the first three correspond to the steps in the design philosophy presented above. Every function has been documented with focus on purpose, usage, definition, and an example with a figure if applicable.
- Helper functions
- Update scripts and functions
- Triplicate scripts and functions
- Rewire scripts and functions
Since this implementation was created over a relatively short period, some features were not implemented, and some of the functions are a bit underdeveloped/outdated (carried over from a previous version). These are some of the suggestions that could potentially improve the implementation:
- See if it is worth using collections (see ch. 6)
- Rewrite some functions
update_port_tmrtandupdate_reg_tmrtstill usingredirectinstead ofget_synopsys_value. Furthermore, they go through the entire hierarchy instead of being called once per design (include them in the loop)
- Change naming scheme
- To create three intermediate voters, nets are suffixed with "_Voted", however to gain continuity with the current TMRG the suffix should just be "Voted"
- Replicants are suffixed with "_A", "_B", and "_C", but to gain contiunity with the current TMRG the suffixes should lose the underscore.
- Include the missing functionalities (see TMRG)
- Slicing
- Using the error signal
- etc.
- Include a way to control how the
tmrtattribute is propagated trough the combinatorial logic- Tie it to the default?
- Create another attribute that can be applied to designs?
- Check the documentation for improved TMR built-in functions
- At the time of writing functions associated with
safety_register_rule,safety_error_rule, andsafety_core_ruleare the only TMR possibilities, but they were deemed too simple and incapable of performing certain TMR strategies
- At the time of writing functions associated with
Feel free to contact me with questions about the implementation!
