Multibit flops can pose a challenge in logic equivalence check and ECO due to the different naming conventions used by various synthesis tools. For example, as depicted in Figure 5, a four-bit multibit flop has a different naming style in Cadence Genus compared to Synopsys Design Compiler after name changing. Additionally, backend tools may split some multibit flops into single bit flops to address timing issues. These factors make key point mapping a complex task.
+In logic equivalence check, multibit flops need to be mapped to single flops. However, the mapping of single flops to multibit flops from the Reference Netlist may differ from the Implementation Netlist. For instance, in Figure 5, the Implementation Netlist has a four-bit multibit flop instance named 'a_reg_0_2_4_', whereas the Reference Netlist after Synthesis may have two-bit multibit flops named 'a_reg_0_1_' and 'a_reg_2_4_'. Depending solely on naming conventions may not lead to the correct multibit to single bit mapping. Although LEC and ECO tools can handle some limited multibit to single bit mapping using comprehensive algorithms, there is no guarantee of complete successful mapping.
+Figure 5: Multibit flop naming in synthesis tools
+GOF provides support for accurate and reliable key point mapping through the use of text mode SVF files from Design Compiler. These SVF files are encrypted by default, but can be converted to text mode when using Formality to read the encrypted file. Additionally, GOF can convert backend multibit flop split/merge information into an SVF file. By reading both the synthesis SVF and the converted SVF file, GOF is able to completely resolve the mapping of multibit flops to single bit flops.
+For instance, Innovus generates a multi_bit_pin_mapping file to store split and merge information. This file can be converted to an SVF text file using a GOF script.
+Here is an example script for converting an Innovus multi_bit_pin_mapping file:
+read_library("libdir/art.lib"); +set_multibit_blasting(0); # Disable multibit blasting +read_design('-imp', "imp_net.v"); +set_top("the_top"); + +open(FIN, "./multi_bit_pin_mapping"); +my $mbit_split = {}; +my $mbit_merge = {}; +while(<FIN>){ + my ($from, $to) = (m/(\S+)\s+(\S+)/); + $from =~ s/\/\w+$//; # remove the pin + $to =~ s/\/\w+$//; + my ($module, $to_inst) = get_resolved($to); + my ($from_inst) = ($from =~ m/([^\/]+)$/); + my $libcell = get_ref($to); + gprint("get ref of $to as $libcell\n"); + my $is_ff = is_seq($libcell, "-ff"); + if($is_ff){ + if(is_seq($libcell, "-bank")==0){ + if(!exists $mbit_split->{$module}{$from_inst}){ + $mbit_split->{$module}{$from_inst} = []; + } + if(grep($_ eq $to_inst, @{$mbit_split->{$module}{$from_inst}})==0){ + gprint("Multibit split in $module $from_inst to $to_inst\n"); + push @{$mbit_split->{$module}{$from_inst}}, $to_inst; + } + }else{ + # Bank + if(!exists $mbit_merge->{$module}{$to_inst}){ + $mbit_merge->{$module}{$to_inst} = []; + } + if(grep($_ eq $from_inst, @{$mbit_merge->{$module}{$to_inst}})==0){ + gprint("Multibit merge in $module $from_inst to $to_inst\n"); + push @{$mbit_merge->{$module}{$to_inst}}, $from_inst; + } + } + } +} +close(FIN); + +my $svf = ""; +foreach my $module (keys %$mbit_merge){ + $svf .= "guide_multibit -design $module -type { svfMultibitTypeBank } \\\n"; + $svf .= " -groups { \\\n"; + foreach my $mbit_inst (keys %{$mbit_merge->{$module}}){ + my $i_st = ""; + my $cnt = 0; + foreach my $s_bit (@{$mbit_merge->{$module}{$mbit_inst}}){ + $i_st .= " $s_bit 1"; + $cnt++; + } + $i_st .= " $mbit_inst $cnt"; + $svf .= "\t{ $i_st } \\\n"; + } + $svf .= " }\n"; +} +foreach my $module (keys %$mbit_split){ + $svf .= "guide_multibit -design $module -type { svfMultibitTypeSplit } \\\n"; + $svf .= " -groups { \\\n"; + foreach my $mbit_inst (keys %{$mbit_split->{$module}}){ + my $i_st = ""; + my $cnt = 0; + foreach my $s_bit (@{$mbit_split->{$module}{$mbit_inst}}){ + $i_st .= " $s_bit 1"; + $cnt++; + } + $i_st = " $mbit_inst $cnt $i_st"; + $svf .= "\t{ $i_st } \\\n"; + } + $svf .= " }\n"; +} +open(FOUT, ">backend_multibit.svf.txt"); +print FOUT $svf; +close(FOUT); +
Two SVF files for Implementation are loaded in the implementation read_svf:
+read_svf("-ref", "reference.svf.txt"); +read_svf("-imp", "implementation.svf.txt", "backend_multibit.svf.txt"); # Two SVF files are loaded +read_design("-ref", "reference.gv");# Read in Reference Netlist +read_design("-imp", "implementation.gv");# Read in Implementation Netlist Which is under ECO +
Physical Synthesis is more and more popular in logic synthesis. Physical Synthesis tool, Design Compiler Topographical(DCT) or Design Compiler Graphical(DCG) for example, may add hierarchical pins that are not in RTL code and it may cause mapping issue when Implementation Netlist is comparing with Reference Netlist in ECO.
+For example, DCT may add 'IN0', 'IN1', 'IN2', 'IN2_BAR' ... to hierarchical modules. The new added pins are not necessarily matching to each other in Implementation Netlist and Reference Netlist. That is, IN0 in module A in Reference Netlist maybe a different signal from IN0 in module A in Implementation Netlist.
+
Figure 12: No Exact Pin Match
+These pins are randomly named in each run. They won't affect logic equivalence check, but they need to be excluded in pin matching in ECO. Otherwise, the ECO tool would insert redundant logic or wrong logic. +API set_noexact_pin_match can be used to resolve the mapping issue between Implementation Netlist and Reference Netlist.
+By adding the port naming regular expression in the API argument, set_noexact_pin_match('\bIN\d+(_BAR)?\b'), these ports will be remapped.
+Note: This API should be run before reading designs.
+When modifying RTL and do re-synthesis, care should be taken to maintain the database as much alike Implementation Netlist as possible.
+A common problem in modifying RTL is having sequential signal name changed, which appears in Reference Netlist as a different flop instance. For example
+It creates a flop instance 'abc_reg' in synthesis. If the ECO in RTL change this to
+After synthesis, a new flop instance 'abc_new_reg' is created. GOF may fail to find that 'abc_new_reg' being able to merge with 'abc_reg', due to other non-equivalent points present, which brings a redundant fix in the new register creation.
+So it is highly recommended to keep the sequential signal names in re-synthesis.
+When do re-synthesis, the same constraints should be used as what has been used in Implementation Netlist synthesis. If any hierarchy is not present in Implementation Netlist, it's better to flatten the module in synthesis to maintain the same hierarchies.
diff --git a/src_en/man.geco_phaseinvert.txt b/src_en/man.geco_phaseinvert.txt new file mode 100644 index 0000000000000000000000000000000000000000..9d9b95e24c413dbbe98efcce1e7af034d353a21d --- /dev/null +++ b/src_en/man.geco_phaseinvert.txt @@ -0,0 +1,31 @@ +During the pre-mask design stage, transitioning a flip-flop from resettable to settable type or vice versa is a relatively straightforward task. However, making such changes during the post-mask design stage can be challenging because it can be difficult to locate an available spare flip-flop to replace the original one. To overcome this challenge, a common approach is to add inverters to the input and output pins of the flip-flop while maintaining its original set/reset type.
+Aside from resolving the issue of locating spare flip-flops, adding inverters to the flip-flop input and output pins can also address timing or power-related concerns. In some cases, this technique can help with timing closure or reduce power consumption.
+It is essential to note, however, that implementing such changes can lead to challenges during logic equivalence checking. Incorrectly addressing these changes can result in false non-equivalent points, leading to design uncertainty. As such, appropriate measures should be taken to ensure that the changes made to the flip-flop type do not affect logic equivalence checking.
+
Figure 13: Flip-flop Phase Inverted
+To address this issue, the GOF platform provides an API command to configure these cases. The set_mapping_method('-phase') API is utilized to handle such situations and ensure that the changes made to the flop type do not cause false non-equivalent result.
+Timing can be reported before or after ECO by report_timing API.
+Timing report related APIs are these:
+The ECO Script can be run by '-run' option.
+Check Run and debug ECO script section in User Manual for more detail
diff --git a/src_en/man.geco_script4gatearray.txt b/src_en/man.geco_script4gatearray.txt new file mode 100644 index 0000000000000000000000000000000000000000..91e016ef69019f1e36244432670c010c3a33bb6e --- /dev/null +++ b/src_en/man.geco_script4gatearray.txt @@ -0,0 +1,33 @@ +GOF script has the exact same syntax of Perl script. It runs the exported commands that access the netlist database and modify the netlist.
+GOF script has the exact same syntax of Perl script. It runs the exported commands that access the netlist database and modify the netlist.
+The following shows an example of an automatic Metal Only ECO:
+In Manual Metal Only ECO, any new added gates are automatically mapped to spare gate instances by 'map_spare_cells' command. A Design Exchange Format file has to be loaded for the tool to find optimal spare instances. If the file is not present, the mapping is skipped.
+In many cases, the ECO operations are well known by users. They can be inserting buffers to a 128bits bus, or adding isolation AND gates to all outputs of a module. In these cases, manual ECO by scripts is more efficient and resource saving.
+GOF exports many APIs for ECO operations in GOF script.
diff --git a/src_en/man.geco_sparegatesnumanddis.txt b/src_en/man.geco_sparegatesnumanddis.txt new file mode 100644 index 0000000000000000000000000000000000000000..c07502f5469b5b67631e1ee19af2ad524352c03f --- /dev/null +++ b/src_en/man.geco_sparegatesnumanddis.txt @@ -0,0 +1,13 @@ +Spare gates are incorporated into the design and their percentage relative to the entire digital area is usually dependent on the design maturity. For instance, the first version of a design typically requires a higher percentage of spare cells, usually around 8-10% of the entire digital area. As the design progresses to the second version, a lower percentage of spare cells, approximately 4-5% of the total digital area, is sufficient. By the third version, less than 3% additional spare cells may be necessary. Additionally, during the backend placement process, any remaining empty space can be filled with extra spare gates.
+Besides the spare gate area percentage, the proportion of various spare gate types is also crucial. For example, a design with 126K instances may have spare gates in different categories, as depicted in the following figure:
+
Figure 19: Spare Gates numbers and distribution
+Usually, spare gates are uniformly distributed on the floor plan, as shown in figure 19. Nevertheless, if accessible, users can adjust the distribution based on historical metal-only ECO data. Blocks that are prone to design changes may require more spare gates, while mature logic may require fewer spare gates.
diff --git a/src_en/man.geco_sparegatessyn.txt b/src_en/man.geco_sparegatessyn.txt new file mode 100644 index 0000000000000000000000000000000000000000..d652de68a532a74d5ce2e2dcc36f6520d9a742b7 --- /dev/null +++ b/src_en/man.geco_sparegatessyn.txt @@ -0,0 +1,4 @@ +GOF ECO utilizes a heuristic method that employs constraints to identify the optimal mapping of spare gates. The process involves setting constraints to restrict the types of NAND/NOR/AND/OR gates to be considered, and then conducting a mapping exercise to identify the nearest available spare gates. The cost of the mapping is determined by adding the distance between the measured location and the actual location of the spare gate. For example, if a NAND gate needs to be mapped in a metal-only ECO, and the measured location is (100, 100), while the closest spare gate (spare_0) is located at (120, 120), then the cost is calculated as (120-100)+(120-100)=40. The method involves multiple iterations, and the optimal solution is selected based on the lowest cost.
+To ensure that new instances are accurately mapped to the nearest spare gate instances, it is necessary to have a Design Exchange Format (DEF) file. Without loading the DEF file, the GOF process will use spare gate types without precise mapping to exact spare instances. However, P&R tools like SOC Encounter will map new instances in the new netlist to the closest spare gates.
+During the 'fix_design' command, GOF examines the top-level module and its sub-modules to identify any non-equivalent points and optimize the logic cone to create a patch circuit with the minimum number of gates.
diff --git a/src_en/man.geco_specialcharacters.txt b/src_en/man.geco_specialcharacters.txt new file mode 100644 index 0000000000000000000000000000000000000000..a8c80c89f43a157c1fd2afb47ae019e6479c090e --- /dev/null +++ b/src_en/man.geco_specialcharacters.txt @@ -0,0 +1,12 @@ +The special character '-' is used to represent existing connection. For example
+A buffer is inserted into A pin of instance U0. The old existing net drives the new buffer now.
+The special character '.' is used in ECO new instance name if the new instance needs to be in the same hierarchy as the ECO spot.
+If the instance is empty, GOF creates 'AOI21X2' in the current top level. With ".", GOF creates 'AOI21X2' new instance in hierarchy "u_qcif/u_num2/u_spare1".
+ diff --git a/src_en/man.geco_standcellmapping.txt b/src_en/man.geco_standcellmapping.txt new file mode 100644 index 0000000000000000000000000000000000000000..edfa58d72ddab4c42ff2b8186f2c2ec3249447a2 --- /dev/null +++ b/src_en/man.geco_standcellmapping.txt @@ -0,0 +1,14 @@ +In Metal Only ECO, the design has completed place and route. Any new gates added should map to spare gates that located in the design. GOF supports Standard Spare Cells and Metal Configurable Gate Array Spare Cells post-mask metal only ECO.
+
Figure 17: Metal Only ECO
+GOF employs an internal synthesis engine to map patch logic onto spare gates. These spare gates must consist of the following spare type combinations.
+Out of the three combinations, the second combination has the least area and the third combination has the best performance in metal only EOC.
+In Figure 18, the circuit produced by ECO on the left-hand side contains arbitrary standard cells. During the mapping process, gates of type MUX and flop are mapped directly onto the spare gates, as they have a one-to-one correspondence with the spare gate list. However, for more complex cell types such as AO32, they must be synthesized and mapped onto three AND gates and one NOR gate.
+
Figure 18: Standard Cells Spare Gates Mapping
diff --git a/src_en/man.geco_stepstodofullfuneco.txt b/src_en/man.geco_stepstodofullfuneco.txt new file mode 100644 index 0000000000000000000000000000000000000000..abde871a05c8adb99f86fabc3278b3678e75114b --- /dev/null +++ b/src_en/man.geco_stepstodofullfuneco.txt @@ -0,0 +1,16 @@ +Steps for an automatic functional ECO:
+A typical situation for a Manual ECO:
+A typical process for gate array spare cells ECO:
+A typical process for an automatic Metal Only ECO:
+When working with designs that include multibit flops or significant name changes, SVF files can be a valuable tool for facilitating key point mapping. Although multibit flops are used to reduce silicon area and power consumption, the different combinations of single bit flop instances in each multibit flop instance can create challenges for key point mapping, especially when combined with name changes. Additionally, backend tools may split or merge multibit flops, further complicating the process. To avoid these challenges and ensure accurate key point mapping, it's highly recommended to load SVF files when working with multibit flops. For more information on this topic, please refer to the Multibit Flops in ECO section.
diff --git a/src_en/man.geco_synsubmod.txt b/src_en/man.geco_synsubmod.txt new file mode 100644 index 0000000000000000000000000000000000000000..bc1eb354f4f56e20618fded61ae804df718b23cb --- /dev/null +++ b/src_en/man.geco_synsubmod.txt @@ -0,0 +1,54 @@ +Performing a complete top-level netlist synthesis can be time-consuming. GOF provides APIs enabling the integration of newly synthesized sub-modules into the original pre-layout netlist, along with updates to the top-level SVF file. This incremental approach allows the generation of the large top-level netlist and the top-level SVF file, resulting in significant time and effort savings. At the RTL level, designers identify modified RTL modules during ECO and synthesize them to create netlist and SVF files. Some altered RTL modules, particularly sub-parent modules with only sub-module instantiations, may not require synthesis.
+In Figure 4, only two sub-modules, SUB_MOD31 and SUB_MOD32, require re-synthesis in the extensive SOC_TOP design. Their parent module has only experienced connection changes and remains in netlist format, eliminating the need for synthesis. The example below illustrates how to process these files and generate a new SOC_TOP level netlist and SVF file.
+
Figure 4: Sub-modules to be synthesized
+Step 1: Add missing DFT ports
+The newly synthesized sub-modules may lack certain ports present in the original netlist. Notably, ports essential for scan in and scan out are typically added by the DFT tool. Since the DFT process is not applied to the new synthesized sub-modules, it's necessary to incorporate these ports as dummy ones within the modules to avoid syntax errors.
+The procedure for incorporating DFT ports into the newly synthesized modules is as follows:
+use strict; +read_library("tsmc.lib"); +read_design("-ref", "SOC_TOP.pre_layout.gv");# Read in the original pre_layout netlist +read_design("-imp", "SUB_MOD31.new_syn.gv");# Read in new synthesized netlist +set_tree("ref"); +set_top("SUB_MOD31_1"); # The old pre-layout netlist may have this module with prefix or suffix added in uniquify +my @ref_port_ins = get_ports("-input"); +my @ref_port_outs = get_ports("-output"); +set_tree("imp"); +set_top("SUB_MOD31"); +my @imp_port_ins = get_ports("-input"); +my @imp_port_outs = get_ports("-output"); +my $cnt = 0; +foreach my $port (@ref_port_ins){ + if(!grep($port eq $_, @imp_port_ins)){ # The input port is not in the new synthesized module + new_port($port, "-input"); + gprint("$cnt: Warning input $port is not in the new synthesized sub-module\n"); $cnt++; + } +} +foreach my $port (@ref_port_outs){ + if(!grep($port eq $_, @imp_port_outs)){ # The output port is not in the new synthesized module + new_port($port, "-output"); + gprint("$cnt: Warning output $port is not in the new synthesized sub-module\n"); $cnt++; + } +} +write_verilog("SUB_MOD31.dft_ports_added.gv"); +exit; +
The identical process should be executed on SUB_MOD32 to include the necessary DFT-related ports.
+Step 2: Replace sub-modules netlist and SVF
+During this step, the DFT ports added netlist and SVF files of the synthesized sub-modules are read to substitute the original pre-layout netlist and SVF files.
+The procedure for replacing netlist and SVF:
+read_library("tsmc.lib"); +read_svf("-imp", "SOC_TOP.pre_layout.svf"); +read_design("-imp", "SOC_TOP.pre_layout.gv"); +read_sub_module_svf("SUB_MOD31.svf.txt", "-module", "SUB_MOD31_1", "-syn_module", "SUB_MOD31"); +read_sub_module_svf("SUB_MOD32.svf.txt", "-module", "SUB_MOD32_1", "-syn_module", "SUB_MOD32"); +read_sub_module_netlist("SUB_MOD31.dft_ports_added.gv", "-module", "SUB_MOD31_1", "-syn_module", "SUB_MOD31"); +read_sub_module_netlist("SUB_MOD32.dft_ports_added.gv", "-module", "SUB_MOD32_1", "-syn_module", "SUB_MOD32"); +read_sub_module_netlist("SUB_MOD3.new.v", "-module", "SUB_MOD3_1", "-syn_module", "SUB_MOD3", "-sub_only"); # Need sub_only option + +replace_sub_module_netlist("SOC_TOP.new_reference.gv"); # Replace netlist should be run first +replace_sub_module_svf("SOC_TOP.new_reference.svf"); # Then replace SVF + +
After the generation of both the top-level netlist and SVF files, they can be incorporated into the complete top-level automatic ECO process.
diff --git a/src_en/man.geco_tcloutaftergatearray.txt b/src_en/man.geco_tcloutaftergatearray.txt new file mode 100644 index 0000000000000000000000000000000000000000..457abaec22ab4db27caa75c41e50abcd94fad6ec --- /dev/null +++ b/src_en/man.geco_tcloutaftergatearray.txt @@ -0,0 +1,39 @@ +By default, GOF uses 1'b0 for tie low net and 1'b1 for tie high net. Some designs may prefer tie cell over 1'b0/1'b1. API set_tiehi_net and set_tielo_net can be used to control which tie format is used. To overwrite the default 1'b0/1'b1, simply set empty argument to the APIs.
+In order to report the timing in paths of interest before a functional ECO, it is necessary to specify the option of 'from,' 'to,' or 'through' in the report_timing function. By comparing the numbers obtained before and after a functional ECO, an appropriate timing ECO method can be selected.
+After performing a functional ECO, report_timing can utilize the 'from,' 'to,' or 'through' options. If the function is executed without specifying any of these options, it will report the timing of paths that traverse the ECO instances.
+
Figure 29: Report timing on paths through ECO instances
diff --git a/src_en/man.geco_tstitchscanchain.txt b/src_en/man.geco_tstitchscanchain.txt new file mode 100644 index 0000000000000000000000000000000000000000..f24f7405664b362ad83170614c4220c79b7216ab --- /dev/null +++ b/src_en/man.geco_tstitchscanchain.txt @@ -0,0 +1,67 @@ +To prevent any loss of DFT coverage, it is recommended to integrate new flops added in an ECO into the existing scan chains. Industrial data suggests that in a design with 100K flops, 100 newly added non-scan flops can lead to a DFT coverage loss of over 0.1%. Such loss of DFT coverage is unacceptable for high-reliability chips, such as those used in automobiles. Therefore, if there are any new flops introduced in a functional ECO, it is necessary to redo the scan chain to incorporate the new flops.
+
Figure 14: Stitch scan chain
+There are multiple methods available in GOF to insert new flops into scan chains. One option is to utilize the 'stitch_scan_chain' API, which automatically integrates the new flops into the scan chains. Alternatively, there are several netlist processing APIs that can be used to manually insert the new flops into the scan chains.
+Automatic mode to insert flops into a scan chain in the local modules
+An automatic method can be used to integrate flops into a scan chain within local modules. In the following example script, suppose the 'fix_design' command adds eight new flops named 'state_new_reg_0' to 'state_new_reg_7'. To integrate these flops into the scan chain within the local module:
+Automatic mode to insert flops before one flop
+GOF offers an automatic method to insert new flops before a specified flop instance. Users can identify the instance name of one flop, and GOF will insert all new flops into the scan chain before that instance.
For instance, let's say it is required to integrate all the new flops into the scan chain prior to the instance named 'u_pixel_ctrl/pulse_reg':
+ +Manual mode to connect up all new flops
+The scan chain can be re-connected up manually by ECO APIs. And new scan in/out ports are created.
++# GOF ECO script, run_manual_stitch_scan_chain_example.pl +use strict; +undo_eco; # Discard previous ECO operations +setup_eco("eco_manual_stitch_scan_chain_example");# Setup ECO name +read_library("art.5nm.lib");# Read in standard library +read_svf("-ref", "reference.svf.txt"); # Optional, must be loaded before read_design, must be in text format +read_svf("-imp", "implementation.svf.txt"); # Optional, must be loaded before read_design, must be in text format +read_design("-ref", "reference.gv");# Read in Reference Netlist +read_design("-imp", "implementation.gv");# Read in Implementation Netlist Which is under ECO +set_top("topmod");# Set the top module +set_ignore_output("scan_out*"); +set_pin_constant("scan_enable", 0); +set_pin_constant("scan_mode", 0); +fix_design; +save_session("current_eco_name"); # Save a session for future restoration +set_error_out(0); # Don't exit if finds error +my @flops = get_cells("-hier", "-nonscan"); # Find all new flops that are not in scan chain yet +# @flops can be defined by reading a list file +if(scalar(@flops)){ # If there are new flops, start the work + new_port("so1", "-output"); # New a scan out port so1 + new_port("si1", "-input"); # New a scan in port si1 + my $cnt = 0; + my $now_si; + foreach my $flop (@flops){ + $cnt++; + if(is_scan_flop($flop)==0){ + my $flop_name = get_ref($flop); + my $scanflop = get_scan_flop($flop_name); # If the flop is not scan type, change to scan type flop + change_gate($flop, $scanflop); + } + if($cnt==1){ + change_port("so1", "$flop/Q"); # The first flop drives the new scan out port + }else{ + change_pin($now_si, "$flop/Q"); + } + $now_si = "$flop/SI"; + change_pin("$flop/SE", "te"); # All scan enable pin is connected to scan enable signal + } + change_pin($now_si, "si1"); # The last flop has the new scan in port driving SI pin +} +write_verilog("eco_verilog.v");# Write out ECO result in Verilog +exit; + +
SPFM and LFM metrics can be calculated in two methods, rough mode and detail mode. The rough mode is done by structural analysis of the Cone of Influence. The detail mode is calculated by formal analysis of the Cone of Influence.
+Two types of strobing points shall be defined for the Cone of Influence extraction.
+The observation points are the outputs or registers that are impacted by the injected faults which affect functional safety and violate safety goal. The diagnostic points are the outputs or registers to check if injected faults can be detected at these strobing points or perceived by the up level driver.
+The logic back traced starting from the observation points and the diagnostic points all the way to the inputs or black boxes. The Cone of Influence (COI) is created for the observation points and the diagnostic points respectively. Each cell and each input port in the cones will be injected faults according to the Fault Model section.
+
Figure 31: Cone of Influence
diff --git a/src_en/man.gformal_debugonefault.txt b/src_en/man.gformal_debugonefault.txt new file mode 100644 index 0000000000000000000000000000000000000000..c1e1b3aaa9eeac8f21881f5d388d54fc79ea01ec --- /dev/null +++ b/src_en/man.gformal_debugonefault.txt @@ -0,0 +1,15 @@ +The API verify_faults can run on an individual fault to check if the fault can propagate to the observation points. If the fault is observable, a VCD file can be dumped to show how to toggle the input ports cycle by cycle to propagate the fault. All internal signals waveforms are captured in the VCD file.
+The following script is to check if one SEU fault can propagate. If yes, a VCD file is dumped:
++set_log_file("spfm_lfm.log"); # Set log file name +read_library("art.5nm.lib"); # Read in liberty file +read_design('-imp', 'ecc_process.v'); # Read in the design block +set_top("ecc_top"); # Set the top module name +set_pin_constant("test_mode", 0); # Set pin constraint +set_observe_points("data_out*"); # data_out[31:0] affects functional safety +set_observe_points("synd_out"); # synd_out affects functional safety +# To check if the fault can be propagated to the detect points, set_observe_points on the detect points +verify_faults("u_ecc_ops/bit_reg:SEU", "-vcd", "debug_seu.vcd"); # Check if the Single Event Upset on the flop can propagate +gexit; +
The formal COI analysis needs to be run to get the final accurate metrics. For each fault injected, GOF Formal either proves that a path exists to propagate the fault to the observation or diagnostic points, or disprove there is such path. A path means by toggling input ports in some limited clock cycles, the fault can propagate to the observation/diagnostic points.
+GOF Formal doesn't require stimulus nor is a testbench required. The tool automatically determines the stimulus. For each fault injected, two designs are compared to see if the specified outputs are equal. One design is the fault injected design, the other is the original design. The specified outputs are the observation points or the diagnostic points set by user. The faults to be injects can be thousands or millions. GOF Formal uses cluster command to fully utilize the cluster computing power. Thousands of jobs can be submitted in parallel to the cluster machines with only one license being used.
+After the detail formal COI analysis of the above example, the residual fault number is 178, and the final SPFM is 96%. The latent fault number is 260, so the final LFM is 94%.
diff --git a/src_en/man.gformal_falutmodel.txt b/src_en/man.gformal_falutmodel.txt new file mode 100644 index 0000000000000000000000000000000000000000..cc6332f9ffe611a890bf57169329028be689e94c --- /dev/null +++ b/src_en/man.gformal_falutmodel.txt @@ -0,0 +1,4 @@ +GOF Formal injects faults to each input port and each pin of logic gates. Each input port has stuck-at 0 and stuck-at 1 faults injected. Every combinational gate has stuck-at 0 and stuck-at 1 faults injected into each pin. For flip-flop, stuck-at 0 and stuck-at 1 faults are injected into each data and clock pin. And flip-flop has Single Event Upset (SEU) fault injected to the state in random time.
+
Figure 30: Fault model for logic gates
diff --git a/src_en/man.gformal_goformaloverview.txt b/src_en/man.gformal_goformaloverview.txt new file mode 100644 index 0000000000000000000000000000000000000000..84a72f515f6fe0b3783ec3e4719461b7b66dc701 --- /dev/null +++ b/src_en/man.gformal_goformaloverview.txt @@ -0,0 +1,15 @@ +GOF Formal is one of the function components integrated in GOF platform. It provides a formal method to calculate fault coverage in an IC design in functional safety.
+ISO26262 defines functional safety as "the absence of unreasonable risk due to hazards caused by malfunctioning behavior of electrical and electronic systems". Four ASILs are proposed to represent four degrees of automotive hazards. In IC component, the coverage in the ASIL requirement is the fault coverage in the logic circuit. Specifically, single point fault metric (SPFM) and latent fault metric (LFM) should meet minimum numbers for the corresponding ASIL levels. The following table lists the three ASIL levels with specific coverage numbers defined in the standard.
+| ASIL | SPFM | LFM |
|---|---|---|
| B | ≥90% | ≥60% |
| C | ≥97% | ≥80% |
| D | ≥99% | ≥90% |
The traditional method to calculate the fault coverage is pure simulation based. It's inefficient and time consuming. GOF Formal provides a formal and efficient way to calculate the SPFM and LFM numbers of a logic design. It can work in a standalone mode to calculate the coverage metric. And it can also work as a supplemental method to cover the faults left over from simulation based process.
\ No newline at end of file diff --git a/src_en/man.gformal_metricsimprovement.txt b/src_en/man.gformal_metricsimprovement.txt new file mode 100644 index 0000000000000000000000000000000000000000..5739a1c9bafbcc1c3dddb3319f739c41bcc02a3a --- /dev/null +++ b/src_en/man.gformal_metricsimprovement.txt @@ -0,0 +1,8 @@ +In order to improve the fault coverage, safety mechanisms should be built in the IC design. There are several approaches for safety mechanism implementation.
+In Figure 32, a safety mechanism can be a double modular design or ECC design. The diagnostic points would be the alarm bits in the double modular error bit, or ECC error recovering signals. For SPFM metric improvement, those gates in Area A that are not covered by safety mechanism can be modified to support TMR (Triple Module Redundancy), so that λSPF can be further reduced and SPFM improved accordingly. See this TMR ECO Case
diff --git a/src_en/man.gformal_roughmethodbycoi.txt b/src_en/man.gformal_roughmethodbycoi.txt new file mode 100644 index 0000000000000000000000000000000000000000..e6a98b062dac77b8fc7e7f71b4137fcfc8cdc6b3 --- /dev/null +++ b/src_en/man.gformal_roughmethodbycoi.txt @@ -0,0 +1,13 @@ +In the rough method calculation by analyzing COI structure, the best and worst metrics can be quickly calculated.
+In the example shown in Figure 32, the faults are distributed as:
+The best SPFM assumes the faults in Area B are propagatable to the diagnostic points. The single-point/residual faults Σ(λSPF+λRF) has number 122 only in Area A. Therefore, the best case SPFM is 97.3%.
+The worst SPFM assumes the faults in Area B are all residual faults, so Σ(λSPF+λRF) has number 1330 which is 1208 plus 122, and get calculated metric to be 70%.
+The best LFM assumes the faults in Area C are all detectable. Σ(λMPF_UD) is zero, So LFM is 100% in the rough structural COI analysis.
+The worst LFM assumes the faults in Area C can not propagate to the diagnostic points, and they are not detectable. Therefore, Σ(λMPF_UD) has the number of 2582, and the worst LFM is 59.5%.
Figure 32: Example fault numbers in COI
diff --git a/src_en/man.gformal_scriptspfmlfmcal.txt b/src_en/man.gformal_scriptspfmlfmcal.txt new file mode 100644 index 0000000000000000000000000000000000000000..cdabb3b2a3576b5e3a7a6d89c5474c27860f9f76 --- /dev/null +++ b/src_en/man.gformal_scriptspfmlfmcal.txt @@ -0,0 +1,17 @@ +One example script for SPFM and LFM calculation:
++set_log_file("spfm_lfm.log"); # Set log file name +read_library("art.5nm.lib"); # Read in liberty file +read_design('-imp', 'ecc_process.v'); # Read in the design block +set_top("ecc_top"); # Set the top module name +create_clock("data_clk", 2); +set_pin_constant("test_mode", 0); # Set pin constraint +set_observe_points("data_out*"); # data_out[31:0] affects functional safety +set_observe_points("synd_out"); # synd_out affects functional safety +set_detect_points("sb_err_o"); # Safety mechanism detecting output +set_detect_points("db_err_o"); # Safety mechanism detecting output +verify_faults("-full"); # Calculate and print SPFM and LFM, Use verify_faults("-coi") for fast SPFM/LFM calculation +gexit; +
Single point fault (SPF) is the fault in the IC design that leads directly to the violation of a safety goal which is defined as observation point in the "Cone of Influence" section below and no fault in the IC circuit is covered by any safety mechanism. However, if there is safety mechanism, but the fault can't be covered by the safety mechanism, the fault is called residual fault according to the standard. In calculating SPFM, residual fault is treated as single point fault. Latent faults are multiple-point faults not detected by a safety mechanism or perceived by the driver. The latent fault metric is to determine whether coverage by safety mechanisms is sufficient to protect against risk from latent faults in the IC design.
diff --git a/src_en/man.gformal_spfmlfmcal.txt b/src_en/man.gformal_spfmlfmcal.txt new file mode 100644 index 0000000000000000000000000000000000000000..5b44ce800eb636976c3fe1c69e41a5d491f157e9 --- /dev/null +++ b/src_en/man.gformal_spfmlfmcal.txt @@ -0,0 +1,18 @@ +In Figure 31, all faults that are outside of the two COIs are safe faults.
+Area A has faults that are observable but not detectable, so they can be classified as residual faults. And they are called single point faults if safety mechanism is not implemented for the design, in which case the diagnostic points are not present and Area B and Area C are zero size. However, if they don't propagate to the observation points in the detail formal COI analysis, they can be classified as multiple point faults. For example, TMR is implemented on Area A. The majority faults in this area will become multiple point faults.
+Area B has faults that are classified as multiple point faults, since they are observable and detectable. In the rough structural COI analysis, the worst SPFM metric can be calculated by assuming them as all residual faults and the best SPFM metric by assuming them as propagatable to the diagnostic points. So the detail formal COI analysis will determined the fault classification.
+Area C has faults that are classified as detectable multiple point faults, but they are not observable. The detail formal COI analysis will be run on Area C to check if the faults in this area can not propagate to the diagnostic points, then they can be classified officially as latent faults. The best and worst LFM metrics can be gained by the rough structural COI analysis method.
+The Single Point Fault Metric (SPFM) can be calculated according to the following equation.
+SPFM = 1 - Σ(λSPF+λRF)/Σ(λ)
+where:
+λSPF: Single Point Fault when there is no safety mechanism
+λRF: Residual Fault
+λ: Any Fault
+The Latent Fault Metric (LFM) can be calculated according to the following equation.
+LFM = 1 - Σ(λMPF_UD)/Σ(λMPF - λSPF - λRF)
+where:
+λMPF_UD: Multiple Point Fault not detected by the driver
+λMPF: Any Multiple Point Fault
+λSPF: Single Point Fault when there is no safety mechanism
+λRF: Residual Fault
diff --git a/src_en/man.gofdebug_guidetail.txt b/src_en/man.gofdebug_guidetail.txt new file mode 100644 index 0000000000000000000000000000000000000000..2613949a0d40d35d1df9a400c728e1aa85a3d3ca --- /dev/null +++ b/src_en/man.gofdebug_guidetail.txt @@ -0,0 +1,2 @@ +For all GUI mode operations and schematic usage, refer to this chapter.
\ No newline at end of file diff --git a/src_en/man.gofecguimode.txt b/src_en/man.gofecguimode.txt new file mode 100644 index 0000000000000000000000000000000000000000..58e707fc35c66ad51278e7b6a5c9e60f5e8a0513 --- /dev/null +++ b/src_en/man.gofecguimode.txt @@ -0,0 +1,4 @@ +GUI mode ECO has advantage of fast ramping up. It's good for small size ECOs. The incremental schematic feature is very helpful for analyzing the netlist before the next step is decided.
diff --git a/src_en/man.gofechiereco.txt b/src_en/man.gofechiereco.txt new file mode 100644 index 0000000000000000000000000000000000000000..918a6f6b68685e632117fbf25759cc5963bdd3d2 --- /dev/null +++ b/src_en/man.gofechiereco.txt @@ -0,0 +1,4 @@ +GOF supports hierarchical ECO by set the ECO scope to the sub-modules. Some Logic Equivalence Check cases can only be resolved in flatten mode. Since GOF only focuses on the modules or spots that user specifies, it can avoid to get false non-equivalence in hierarchical netlist.
diff --git a/src_en/man.gofecintegratedenv.txt b/src_en/man.gofecintegratedenv.txt new file mode 100644 index 0000000000000000000000000000000000000000..572a50936fd8442bcbdccecfd6f7e6b8cb375af7 --- /dev/null +++ b/src_en/man.gofecintegratedenv.txt @@ -0,0 +1,4 @@ +The ECO modes listed above are integrated into one work environment seamlessly. The mixing of ECO modes can produce most optimal ECO result. For example, automatic ECO and manual script ECO can be done in one ECO script, so that the minimum size ECO patch can be achieved.
diff --git a/src_en/man.gofecmetalonly.txt b/src_en/man.gofecmetalonly.txt new file mode 100644 index 0000000000000000000000000000000000000000..1fb85878b882f02397ad0ce5501d4cfb13143e1a --- /dev/null +++ b/src_en/man.gofecmetalonly.txt @@ -0,0 +1,4 @@ +When ECO is done in either automatic mode or manual mode, 'map_spare_cells' command is run to convert the newly added cells to spare gate types cells. Users can control only spare gate type cells being used in manual mode ECO, so that the converting stage can be bypassed. The flow supports both standard spare cells and gate array spare cells.
diff --git a/src_en/man.gofecoautomode.txt b/src_en/man.gofecoautomode.txt new file mode 100644 index 0000000000000000000000000000000000000000..8839748009f07e59076e332e4d7a4c9fb82a9ffd --- /dev/null +++ b/src_en/man.gofecoautomode.txt @@ -0,0 +1,5 @@ + +The automatic functional ECO is carried out using a GOF ECO script, which requires an Implementation Netlist that is currently under ECO and a Reference Netlist that is re-synthesized from the modified RTL with the same constraints as the pre-layout netlist. The 'fix_design' API is utilized to execute a top-down global ECO. GOF leverages its built-in Logic Equivalence Check engine to identify and analyze non-equivalent points in both the top-level module and its sub-modules. Logic patches are generated to rectify any non-equivalent modules, and the final patches are optimized circuits that minimize the gate count required to make the Implementation Netlist equivalent to the Reference Netlist. Finally, the 'map_spare_cells' API is used to map these patches to spare-type-gates.
diff --git a/src_en/man.gofecofeatures.txt b/src_en/man.gofecofeatures.txt new file mode 100644 index 0000000000000000000000000000000000000000..eaa4947f7543aa431357cb02511f6c88d95e9f1d --- /dev/null +++ b/src_en/man.gofecofeatures.txt @@ -0,0 +1,13 @@ +GOF ECO incorporates the following features:
+If the ECO changes are limited in scope and size or involve repetitive operations such as adding inverts on a bus, it is more efficient to use the manual mode ECO. This mode is a better option as it results in fewer final gates being touched compared to automatic mode ECO. Additionally, both automatic and manual modes can be combined and executed within a single GOF ECO script.
diff --git a/src_en/man.gofecovariousmethods.txt b/src_en/man.gofecovariousmethods.txt new file mode 100644 index 0000000000000000000000000000000000000000..87e8abea098bcfcbac40b2ee13d7113270a61f07 --- /dev/null +++ b/src_en/man.gofecovariousmethods.txt @@ -0,0 +1,10 @@ + +GOF ECO utilizes various advanced ECO methodologies, as netlist ECO can vary significantly in terms of size and complexity across different cases and companies. To provide users with maximum flexibility, GOF offers a range of methodologies to choose from, allowing them to select one or multiple options based on the specific requirements of the changes involved.
+
Figure 1: Complete Functional ECO Solutions
+The GOF platform features a logic equivalence checker tool called GOF LEC. While not mandatory, the tool can benefit from SVF files in certain cases. It is strongly advised to utilize SVF files if they are obtainable. The two designs being compared can either be in RTL or Netlist format, with RTL supporting SystemVerilog2017. The read design method differs depending on whether RTL or Netlist is being supported.
+
Figure 38: GOF LEC Engine
+The following is the example script for Netlist to Netlist LEC:
+# LEC script, run_net2net_lec.pl +use strict; +read_library("art.5nm.lib"); # Read in standard library +read_svf('-ref', 'AI2023_top_syn.svf.txt'); # Optional, must be loaded before read_design, must be in text format +read_svf('-imp', 'AI2023_top_pr.svf.txt'); # Optional, must be loaded before read_design, must be in text format +read_design('-ref', 'AI2023_top_syn.v'); # Read in the Reference Netlist, prelayout netlist +read_design('-imp', 'AI2023_top_pr.v'); # Read in the Implementation Netlist, postlayout netlist +set_top("AI2021_top"); # Set the top module +set_ignore_output("scan_out*"); +set_pin_constant("scan_enable", 0); +set_pin_constant("scan_mode", 0); +my $non_equal = run_lec; # Run logic equivalence check on the two netlists +if($non_equal){ + gprint("LEC failed with $non_equal non-equivalent points"); +}else{ + gprint("LEC passed"); +} +
The following is the example script for RTL to Netlist LEC:
+# LEC script, run_rtl2net_lec.pl +use strict; +read_library("art.5nm.lib"); # Read in standard library +set_inc_dirs("-ref", "inc_dir_path/include"); +set_define("-ref", "NO_SIMULATION", 1); +my @rtl_files = ("cpu_core.sv", "mem_ctrl.sv", "display_sys.sv", "chip_top.sv"); +read_rtl("-ref", @rtl_files); # Read in the Reference RTL files +read_svf('-imp', 'chip_top.svf.txt'); # Optional, must be loaded before read_design, must be in text format +read_design('-imp', 'chip_top.v'); # Read in the Synthesis Netlist +set_top("CHIP_TOP"); # Set the top module +set_ignore_output("scan_out*"); +set_pin_constant("scan_enable", 0); +set_pin_constant("scan_mode", 0); +elab_rtl(); # RTL processing +my $non_equal = run_lec; # Run logic equivalence checking on RTL vs Netlist +if($non_equal){ + gprint("LEC failed with $non_equal non-equivalent points"); +}else{ + gprint("LEC passed"); +} +
These APIs are for Automatic ECO
+Combining netlist browsing APIs, users can come up a short script to do complicated changes.
+For example, to fix all modules named "tx_machine_*"
+ diff --git a/src_en/man.gsc_bexampletosch.txt b/src_en/man.gsc_bexampletosch.txt new file mode 100644 index 0000000000000000000000000000000000000000..5b5428f84b48a437e051d9fecd8f33d891772b79 --- /dev/null +++ b/src_en/man.gsc_bexampletosch.txt @@ -0,0 +1,7 @@ +In GOF shell 'GOF > sch the_non_equivalent_point -both', so that both instances/ports in the Implementation and Reference Netlists are loaded into a schematic. Select both of them, right the mouse and select 'LEC Debug the_non_equivalent_point'. After the run finishes, use mouse middle button to expand the schematic, and the counter-example values are back-annotated on the schematic.
+
Figure 36: Debug non-equivalence by counter-example back-annotated
+Two corresponding flops, two corresponding output ports, and any two nets in the Reference Netlist and the Implementation Netlist can be compared in debug mode. In cases where the outcome is non-equivalent, the counterexample will be presented to the gate pins on the schematic.
+
Figure 37: Counter-example back-annotated on the schematic
diff --git a/src_en/man.gsc_breakfordebug.txt b/src_en/man.gsc_breakfordebug.txt new file mode 100644 index 0000000000000000000000000000000000000000..11a98a67949debbcb4f11bbaaaf034182ad89402 --- /dev/null +++ b/src_en/man.gsc_breakfordebug.txt @@ -0,0 +1,24 @@ +'sch' fast schematic launch command can be used as break points for debug. For example, 'sch' commands are inserted in GOF script, when the tool runs to the point, a schematic is launched.
++
On the schematic, user can use mouse-middle-button clicking on the pin 'D' to see if the ECO is done as expected.
++
+
Figure 34: Launch schematic at break point
+Note: 'ECO' check-button is enabled automatically, since there is ECO having been done.
+To compare with the logic before ECO, launch a new schematic by menu Schematic->'New Schematic'. On the new schematic, press 'ctrl-g' or by menu Schematic->'Load Gate' to load in the flop under ECO.
+
Figure 35: Launch schematic before ECO
+Note: 'ECO' check-button is un-checked.
diff --git a/src_en/man.gsc_changefloptoothertype.txt b/src_en/man.gsc_changefloptoothertype.txt new file mode 100644 index 0000000000000000000000000000000000000000..b6ff048cdcbc2cc6b23a3a008c81ff2d675fc3dc --- /dev/null +++ b/src_en/man.gsc_changefloptoothertype.txt @@ -0,0 +1,10 @@ +In GOF shell, GUI windows can be launched by 'start_gui' or 'sch' commands.
+'start_gui' launches netlist view window first and user can bring up schematic window from netlist view window.
+'sch' command only launches schematic window, and it doesn't enable netlist view window. So it has fast turnaround in GUI interactive debug.
+For example,
+After the following command is done,
+ + +Run 'sch' in 'GOF >'
+The instance is loaded into a schematic and user can click on the instance's pins to trace fanin/fanout on the schematic to see if the ECO is done as expected.
diff --git a/src_en/man.gsc_fileipapis.txt b/src_en/man.gsc_fileipapis.txt new file mode 100644 index 0000000000000000000000000000000000000000..1682af7dcd4f7b0d4bfb7ffc75c63c466afc8e04 --- /dev/null +++ b/src_en/man.gsc_fileipapis.txt @@ -0,0 +1,17 @@ +These APIs are for reading/writing files.
+GOF Script Interface can access and change internal netlist design database by exported APIs.
+Both input port and output port have the same operation
+These are APIs for Manual ECO.
+Combining netlist browsing APIs, a short GOF script can do very efficient ECOs.
+For example, to add isolation cells for all output ports of a module.
++
Instance with backslash should be either put in single quote and with a space in the end.
+ + +Net name with backslash should keep the backslash and space. For example
+The net '\u_abc/u_def/net123 ' should have backslash and space kept in API, for example:
+ + diff --git a/src_en/man.gsc_netlistbrowseapis.txt b/src_en/man.gsc_netlistbrowseapis.txt new file mode 100644 index 0000000000000000000000000000000000000000..7970cc2f00f3427552144cae59c3853e5d4e112d --- /dev/null +++ b/src_en/man.gsc_netlistbrowseapis.txt @@ -0,0 +1,32 @@ +One key element to do efficient manual ECO is to isolate the ECO spots quickly. The following APIs are for fast Netlist Browsing.
+For example, to get data pins of flops in one module. The script can use these browse APIs
+After run the script, @flop_data_pins have all data pins of all flops in the module.
+ diff --git a/src_en/man.gsc_runanddebuggofscript.txt b/src_en/man.gsc_runanddebuggofscript.txt new file mode 100644 index 0000000000000000000000000000000000000000..545d9dfa4636560fdea7de7e1861a046188639ba --- /dev/null +++ b/src_en/man.gsc_runanddebuggofscript.txt @@ -0,0 +1,22 @@ +In Linux Shell, the script can be run by ‘-run’ option.
+gof -run run_example.pl
+If '-run' option is present in the command line, and 'exit' or 'gexit' is not in the script, or GOF meets error when executing the script, GOF goes into interactive mode with GOF shell 'GOF >'.
+Individual command can be executed in GOF shell. The command can be in nested mode
+GOF scripts can be run in GUI window. In GofViewer, click Menu Commands->’Launch GOF Script Interface’ to launch GOF GUI window.
+Type ‘help’ in the shell entry for help information. Scripts can be run by ‘run’ command in the shell entry
+
Figure 33: GofCall window
diff --git a/src_en/man.gsc_stringquotes.txt b/src_en/man.gsc_stringquotes.txt new file mode 100644 index 0000000000000000000000000000000000000000..347989b37486eccdf1e15789469e32d6f728b36c --- /dev/null +++ b/src_en/man.gsc_stringquotes.txt @@ -0,0 +1,9 @@ ++
Any string in GOF script for module/instance/wire/pin/port should be enclosed by single quote or double quote. When a Perl variable is used, double quote should be used
+ + diff --git a/src_en/man.install.txt b/src_en/man.install.txt new file mode 100644 index 0000000000000000000000000000000000000000..f9dc27bc01383722c2df5d5928f5aeb4324601a7 --- /dev/null +++ b/src_en/man.install.txt @@ -0,0 +1,4 @@ +GOF release package can be found in
+https://nandigits.com/download.php
+Please complete the form to request an evaluation license before downloading the application.
The tool supports Linux 64bits OS. Download the release package and unzip to a directory. Set 'the_64bit_install_path/GOF64/bin' in search path.
diff --git a/src_en/man.intro.txt b/src_en/man.intro.txt new file mode 100644 index 0000000000000000000000000000000000000000..bb448f891129f248ca42952eef52f1d4ee4e6102 --- /dev/null +++ b/src_en/man.intro.txt @@ -0,0 +1,7 @@ +The GOF platform is comprised of four powerful functional components: GOF ECO, GOF Formal, GOF LEC, and GOF Debug.
+GOF ECO is the flagship tool within the GOF platform, offering state-of-the-art technology and methodologies for functional netlist ECO. Whether you need to identify non-equivalent modules, fix non-equivalent points, or streamline the Implementation netlist, GOF ECO has you covered.
+GOF Formal is another critical component of the GOF platform, providing a formal method for calculating fault coverage in an IC design in functional safety.
+GOF LEC is the logic equivalence checker tool within the GOF platform, enabling users to easily verify the equivalence of their designs and ensure that they function as intended.
+GOF Debug is the netlist debug tool integrated with incremental schematic, providing a fast and efficient way to identify and resolve errors in your netlist.
diff --git a/src_en/man.license.txt b/src_en/man.license.txt new file mode 100644 index 0000000000000000000000000000000000000000..bc316ee4952a56e3b933e588c56b1ab4bb1387cb --- /dev/null +++ b/src_en/man.license.txt @@ -0,0 +1,6 @@ +Visit https://nandigits.com/supports.php?type=license to request an evaluation license. Or email support@nandigits.com for more information. Without license, the tool can support netlist size less than 500K bytes. There are two license modes, fixed node mode and floating node mode.
+