ModelSim software. Since the code was not up to the industrial standard, I was asked to rewrite the code meeting those standards. 2.1.2.1.3.1 Functionality of pointers Figure 2.2: Traversal of Pointers The Asynchronous FIFO in CDC works using Synchronize architecture of FIFO module. I.e. synchronizing read and write pointers between clock domains. Thus the flags are generated after comparing the read and write pointers. Later in the week I could possibly test the functionality of pointers in FIFO and sent to the management for review. The observations are listed along with the feedback I received (In red). First I tested whether the pointers are working properly. For that I just enabled the ‘asff_wr_en’ and fetched input data continuously (20 – 130 ps). Since the DEPTHLN2 is 3 and hence the size of the memory is 8x8, the maximum it can fetch in to the memory is 8 bytes. In that the ‘wr_ptr’ is incremented as expected. Then the ‘asff_rd_en’ is set (130 – 320 ps) and allowed to be read whole the memory. In that the ‘rd_ptr’ is also incremented as expected. And at this stage (280 ps + 4 ps (clock offset)) both pointers are at 3’b000. But the problem at this stage is since the ‘rd_ptr’ initially points on first element in the memory and since that time it should point on the second element in the memory when the first element is trigerred (but since it is not happening here) the cycle of reading extends to one more element (reads nine elements). The next element in the memory from where the limit created by the wr_ptr is also read by the rd_ptr (if it is end of the memory then the first element). Closely look at the time gap between 280 – 300 ps with respect to asff_rddata and rd_ptr. See how empty flag works and conditions on how we use a FIFO Figure 2.3: inspection on asff_rddata and asff_rdptr
Scan chains can be fully triggered at either positive or negative. But at a crossing of positive to negative clock triggered scan chains, a ‘copy flip-flop’ is a must. This is to guarantee a reliable chain operation. Figure 2.18: Scan_40 validation If either the f3a’s input is not the output of f3 or that net is not consisted with even number of inverters then a violation is said to happen. This will issue a violation message under Scan_40. Understood the basic concept and validated the rule on the following bases. No violation Simple violation Negative to positive MUX between FF_(L-1) and FF_L After rectifying what has been given in all_case_netlist_01 Two ffs are in different scan chains Two negative edge scan chains Comb in between scan chains With two clocks With dftStrictTestClkDomains FF_(L-1)’s and FF_L’s d pins are connected with inversion Two FF_(L-1) for FF_L Only two scans More in one scan 2.1.3.2.4 Intel LSSD support in DFT This is another request made by Russ Roan of Intel on behalf of Kavita Rachakatla. The validation of this modification was brought down in two phases. This modification introduces the scannability of latches in addition to the ‘pipeline’ extension. When test clocks are inferred at outputs of ICG using ‘pipeline’ constraint then the registers driven by them will be considered to be scannable.
Figure 2.19: Intel LSSD validation The ‘pipeline_depth’ constraint in sgdc file can only be specified with the value which is the depth of the registers which are presented before ICGC. But the ‘pipeline_depth_range’ comes handy in use as the user can specify a value range on which it will automatically define a depth of registers which match the design. The impact on latch scannability was also validated along with the functional validation of ‘pipeline’. 2.1.3.2.4.1 Functional validation on ‘pipeline’ The bases on which this modification is tested is listed below. Case 00 – default case where ‘-pipeline_depth’ is left without defining. Case 01 – There are two ‘gating_cell_enable’ and one ‘-pipeline_depth’ is left without defining. Case 02 – Normal operation of ‘-pipeline_depth’ (two latches are placed before and after CGC) Case 03 – Normal operation of ‘-pipeline_depth_range’ (two latches are placed before and after CGC) Case 04 – ‘pipeline_depth_range 0 5’ and placing a CGC 6th flop Case 05 – ‘pipeline_depth_range 3 6’ and placing a CGC before 2nd flop Case 06 – ‘pipeline_depth_range 0 5’ and placing many CGCs in between Case 07 – Check whether both are working together Case 08 – Negative value for ‘-pipeline_depth’ Case 09 – Negative values for ‘-pipeline_depth_range’ Case 10 – More valid values for ‘-pipeline_depth’ Case 11 – More valid values for ‘-pipeline_depth_range’ Case 12 – One valid value for ‘-pipeline_depth_range’ Case 13 – Zero valid values for ‘-pipeline_depth’ Case 14 – Zero values for ‘-pipeline_depth_range’ Case 15 – Two CGCs and ‘-pipeline_depth’ for one CGC and ‘-pipeline_depth_range’ for other one 2.1.3.2.4.2 Latch Scannability
2. Two (out of three) data pins are driven by one clock in above (i) design 3. Two clocks are converged so as to feed a data pin of one flop out of two flops 4. Clock blocked by a flop (for the design in (i)) 5. Clock blocked by a MUX 6. One flip-flop is defined to be ‘no_scan’ Clock_16: A bug was detected while validating ‘Robust test’ under this rule. This was reported and rectified. The bug is described below. This is related to the unit test case in the following path. dft/test/Ruledecks/dft/Verilog/Clock_16/case0 The top module diagram is, Figure 2.29: Clock_16 reported bug As the “Metric_Possibilities_for_Robust_Tests-v6.docx” says for the Clock_16 rule, “Count the # of FFs with a data path from a FF that is clocked on opposite edge” As we can figure out, “q2” and “q3” flip-flops are victims of Clock_04 violation whereas “q1” is a victim of Clock_16 violation. BTW for the robustness testing (as the above reference suggests) “q2” is flagged though “q1” is the one which should be flagged. We can see that in the following too. There, even though the percentages per rule are correct, the overall percentage is incorrect. Figure 2.30: Incorrect Robustness Clock_17: 1. Output to d pin of a flip-flop 2. Using two test-clocks