Functional Safety Clock Checker Diagnostic IP Core

Transcription

1 Functional Safety Clock Checker Diagnostic IP Core AN Application Note The Altera Clock Checker Diagnostic IP core is for applications that comply with IEC 61508:2010 and ISO 26262: You can use this IP core to extend the diagnostic coverage of a design by providing on-line checking of the presence and frequency of an input clock against a stable reference clock. You can use this IP core to check the correct function of a PLL within the FPGA device or check other system clocks within a safety-related design. You can specify high and low frequency thresholds. If the clock under test falls outside of these thresholds, the IP core produces an error signal to alert your system. About This Clock Checker Diagnostic IP Core This IP core requires the Quartus II software v14.1 update 1. Device Family Support IP cores provide the following levels of support for target Altera device families: Preliminary verified with preliminary timing models for this device Final verified with final timing models for this device Table 1 shows the level of support offered by the Clock Checker Diagnostic IP core for each Altera device family. f For the latest device information, refer to the Customer Advisories, Process Change Notifications & Product Discontinuance Notifications web page. Table 1. Device Family Support Arria II GX Arria II GZ Arria V Arria V GZ Cyclone IV E Cyclone IV GX Cyclone V Stratix IV Stratix V MAX II MAX II Z Device Family Final Final Final Final Final Final Final Final Final Final Final Support 101 Innovation Drive San Jose, CA Copyright 2016 Altera Corporation. All rights reserved. Altera, The Programmable Solutions Company, the stylized Altera logo, and specific device designations are trademarks and/or service marks of Altera Corporation in the U.S. and other countries. All other words and logos identified as trademarks and/or service marks are the property of Altera Corporation or their respective owners. Altera products are protected under numerous U.S. and foreign patents and pending applications, maskwork rights, and copyrights. Altera warrants performance of its semiconductor products to current specifications in accordance with Altera's standard warranty, but reserves the right to make changes to any products and services at any time without notice. Altera assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly agreed to in writing by Altera. Altera customers are advised to obtain the latest version of device specifications before relying on any published information and before placing orders for products or services. March 2016 Altera Corporation Subscribe

2 Page 2 About This Clock Checker Diagnostic IP Core Table 1. Device Family Support Device Family MAX V Other device families Final None Support Features Complies with IEC61508:2010 systematic capability SIL 3 (see IEC :2010, and 7.4.3) Qualified as an ASIL D safety element out of context (SEooC) according to ISO :2011 and ISO/PRF PAS Checks the presence and frequency of system clocks against a fixed reference Indicates if an input clock is above or below user defined thresholds CPU interface allows reading of clock count register for coarse frequency measurement 1 This diagnostic IP core covers the module design stage of the IEC61508:2010 V-model (IEC :2010, Figure 3). If you use this diagnostic IP core, ensure you follow other V-model steps during the application development. 1 This diagnostic IP core covers the logical module design step in the Automotive Safety Manual for Cyclone V FPGAs and Cyclone V SoCs (for ISO 26262). If you use the diagnostic IP, ensure you follow the other user development flow steps in the Automotive Safety Manual for Cyclone V FPGAs and Cyclone V SoCs. General Description Figure 1 shows a typical clock checker diagnostic IP core example in a safety-related system. In this example the IP core checks for the presence and frequency of the signal safety_critical_clk. The IP core indicates any error condition to the system safety controller. The safety controller must place the system into a safe state if an error condition occurs. Figure 1. Example System FPGA Safety Critical Clock Stable Reference Clock Clock Checker Diagnostic IP Core Flags Resets System Safety Controller You can parameterize the IP core for your particular system requirements ( Parameters on page 7). You can parameterize thresholds for upper and lower clock frequencies. If the safety critical clock falls outside these thresholds, the IP core indicates an error. 1 These thresholds are not run-time adjustable. Functional Safety Clock Checker Diagnostic IP Core March 2016 Altera Corporation

3 Functional Description Page 3 You connect the safety critical clock to the cut_clk input of the IP core ( Signals on page 10). You must connect a stable reference clock to the input of the IP core. You connect error flags and status flags from the IP core to the system safety controller, which may be outside the FPGA. You must connect the correct resets from the safety controller to the diagnostic IP core. The following steps summarize the basic operation of the IP core: 1. Reset the IP core, which places the core into a known state. 2. Apply the safety critical clock and the reference clock to the IP core. 3. The IP core uses the flag interface to indicate that a measurement is in progress. 4. Eventually the IP core indicates that it has made a measurement. You set the measurement time with the IP core parameter REF_CLK_TC ( Parameters on page 7). 5. If the clock under test falls outside the threshold parameters, the IP core indicates an error. 6. The safety controller responds to the error flag and may place the system into a safe state. 7. The IP core continually measures the clock under test until you stop the system or reset the IP core. Performance and Resource Utilization Functional Description Figure 2. Block Diagram For all device families, resource usage is approximately 100 registers and 100 to 150 LEs or ALUTs. Figure 2 shows the IP core block diagram. Clock Under Test Clock Under Test Counter Count Value Storage High Frequency Limit Comparator Low Frequency Limit Comparator Flag Generator Output Flags Control State Machine Reference Clock Reference Clock Counter Terminal Count Check March 2016 Altera Corporation Functional Safety Clock Checker Diagnostic IP Core

4 Page 4 Functional Description Clock Under Test Counter The clock under test counter is a standard binary counter. The counter should always increment by 1 (unless in reset or terminal count state). For state machine control, the counter has enable and reset ports it is not free running. Reference Clock Counter This reference clock counter is also a standard binary counter. The count value should always increment by 1 (unless in reset or terminal count state). The reference clock counter has enable and reset ports. Terminal Count Check The terminal count check is a simple comparator. A flag goes active when the value of the reference clock counter reaches a user supplied value. You specify this value by setting the REF_CLK_TC parameter value. The terminal count flag is input to the control state machine. Control State Machine The control state machine controls the IP core, which cycles through the various states of the IP core during its operation. The IP core operates in a continuous free running mode with no direct start or stop mechanism, which allows the IP core to operate without the need for direct processor connection. You can use the reset signal to set the IP core to a defined state, for example to restart the IP core. High Frequency Limit Comparator The high frequency limit comparator compares the clock under test counter value to a user defined value that represents the high frequency limit of the clock. If the counter value exceeds the threshold parameter value, the IP cores indicates a frequency high error. The IP core implements this function with a simple greater than comparator. During synthesis, a high-level HDL operator implements this function. Low Frequency Limit Comparator Flag Generator The low frequency limit comparator compares the clock under test counter value to a user defined value that represents the low frequency limit of the clock. If the counter value falls below the threshold parameter value, the IP cores indicates a frequency low error. The IP core implements this function with a simple less than comparator. During synthesis, a high-level HDL operator implements this function. The outputs of the high and low frequency limit comparators are only valid at certain points during the checking cycle. A flag from the control state machine indicates the validity of the limit comparator outputs. The flag generator takes the high and low frequency limit comparator outputs, with control state machine signals, and generates the final output flags. Functional Safety Clock Checker Diagnostic IP Core March 2016 Altera Corporation

5 Functional Description Page 5 Count Value Storage Thresholds The count value storage stores the clock under test counter value from the previous checking cycle. It is a register storage block and allows you to read the clock under test counter value. You can use this value to determine an approximate frequency of the clock under test. The IP core only updates the value at the end of the checking cycle. The architecture of the IP core is based on the running of two counters. A reference clock (ref_clk) of a known frequency drives one of the counters; the clock under test (cut_clk) drives the other counter. The two counters are reset at, or near to, the same point in time. Once the reference clock counter reaches a predetermined terminal count, the IP core stores the value of the counter that the counter under test drives. The IP core then compares the clock under test counter value with two predetermined threshold values. If the count is less than the lower limit compare value, or if the count is more than the high limit count value, the IP core flags an error. Figure 3 shows the case where the clock under test counter lies within expected bounds. The count is above the lower count threshold and the count is below the upper count threshold. Figure 3. Clock Under Test within Frequency Limits Clock Under Test Count Value Upper Count Threshold Lower Count Threshold 0 t Note to Figure 3: (1) Time t is the time to complete one clock frequency measurement cycle. Time March 2016 Altera Corporation Functional Safety Clock Checker Diagnostic IP Core

6 Page 6 Functional Description Figure 4 shows the case where the clock under test counter is below the lower count threshold. The frequency of the clock is lower than expected. The condition that the count value is below the upper count threshold is still satisfied. Figure 4. Clock Under Test Under Lower Frequency Limit Clock Under Test Count Value Upper Count Threshold Lower Count Threshold 0 t Note to Figure 4: (1) Time t is the time to complete one clock frequency measurement cycle. Time Figure 5 shows the case where the clock under test counter is above the upper count threshold. The frequency of the clock is higher than expected. The condition that the count value is above the lower count threshold is still satisfied. Figure 5. Clock Under Test Above Upper Frequency Limit Clock Under Test Count Value Upper Count Threshold Lower Count Threshold 0 t Note to Figure 5: (1) Time t is the time to complete one clock frequency measurement cycle. Time When the design indicates the counter value is above the upper count threshold and the counter value is below the lower count threshold, the IP core indicates an error. This combination of flags is not possible in a correctly operating IP core. IP Core Diagnostic Coverage You can calculate the diagnostic coverage for a particular set of parameters. The IP core derives the diagnostic coverage from the range of frequencies within the upper and lower thresholds. The nominal clock frequency is the expected frequency of the clock under test (cut_clk). To calculate diagnostic coverage, use the following equations: The range of frequencies within threshold (in %) = [(upper freq lower freq)/nominal frequency] 100 Diagnostic coverage % = 100 range of frequencies within threshold (in %) Functional Safety Clock Checker Diagnostic IP Core March 2016 Altera Corporation

7 Parameters Page 7 For example, for: Table 2. IP Core Diagnostic Coverage nominal clock frequency = 50 MHz upper threshold frequency = 60 MHz lower threshold frequency = 40 MHz The range of frequencies within threshold = [(60 40)/50] 100 = 40% Therefore, the diagnostic coverage = 100% 40% = 60% Table 2 shows the IP core diagnostic coverage. Diagnostic Item Detection Notes Clock under test clock frequency too high Yes User threshold. Clock under test clock frequency too low Yes User threshold. Clock under test clock stuck at 1 or 0 Yes Detected after time-out period. Clock under test clock excessive jitter No No jitter measurement made. Clock under test clock intermittent Partial Clocks with significant stuck-at periods affect the number of edges counted in a measurement cycle, which may trigger the too low error condition. Reference clock stuck at 1 or 0 No You should provide mitigation techniques. IP Core Failure Mitigation Techniques You can use the following techniques to verify that the IP core is functioning as intended and to mitigate against hardware failures: Apply incorrect frequency clocks deliberately for fault injection (for example, at startup or during operation) to ensure the IP core asserts the error flags. When you apply the correct frequency clocks, ensure the IP core deasserts the error flags. Check the error flags against the CUT_COUNT control and status registers values. The CUT_COUNT value should be greater than the LO_COUNT_THR and less than HI_COUNT_THR parameter values if the IP core deasserts the error flags; and less than the LO_COUNT_THR or greater than the HI_COUNT_THR parameter values if the IP core asserts the error flags. Check for periodic changes in check_done and check_running flags to verify the IP core has not locked up. Use two instances of the clock checker: one instance checks the cut_clk clock in reference to the ref_clk clock; the other checks the ref_clk clock in reference to the cut_clk clock. To achieve two instances, switch the ref_clk and cut_clk clock connections and parameterize each instance correctly. Parameters Table 3 shows the IP core parameters. March 2016 Altera Corporation Functional Safety Clock Checker Diagnostic IP Core

8 Page 8 Parameters 1 You must strictly adhere to the parameterization instructions and ranges, otherwise the IP core may not operate correctly. Table 3. Parameters Wizard Name HDL Name Type Low count threshold High count Threshold Ref clock terminal count Range (Bits) Default LO_COUNT_THR Binary HI_COUNT_THR Binary REF_CLK_TC Binary 24 1,000,000 Description The value above which the clock under test counter must count for no error to be indicated. The value below which the clock under test counter must count for no error to be indicated. Terminal count value of the reference clock. This count value determines the time period over which the IP core performs the clock test. Determining Parameters Example 1 The IP core counts the number of rising edges on the cut_clk (cut_cnt) over a period of time defined by the time taken to count REF_CLK_TC rising edges on ref_clk. For the IP core to detect a state with no errors, the following conditions must be true: LO_COUNT_THR cut_cnt HI_COUNT_THR The following equation defines an expected midpoint for the cut_cnt value: cut_cnt_mid = (HI_COUNT_THR LO_COUNT_THR)/2 For a system operating correctly the following equality holds: ref_clk (period) * REF_CLK_TC = cut_clk (period) cut_cnt_mid 1 Time to complete one clock frequency measurement cycle = ref_clk (period) REF_CLK_TC Altera recommends values for REF_CLK_TC or cut_cnt_mid of at least 1,000 to give a measurement accuracy granulation of 0.1%, but you can use values as low as 100. Measurement accuracy increases with larger values of REF_CLK_TC or cut_cnt_mid at the expense of a longer measurement cycle. You should trade off accuracy against test time when selecting your parameter values. To allow you to calculate suitable values for the parameters, define the clock rates you are using: ref_clk (period) (ns) = 10 (100 MHz) cut_clk (period) (ns) = 10,000 (100 khz) Now, REF_CLK_TC/cut_cnt_mid = cut_clk (period)/ref_clk (period) Therefore, REF_CLK_TC/cut_cnt_mid = 1,000 Functional Safety Clock Checker Diagnostic IP Core March 2016 Altera Corporation

9 Parameters Page 9 Example 2 Assuming a value of 1,000 for the lowest of these two values, for a relatively fast and accurate measurement, therefore: REF_CLK_TC = 100,000 cut_cnt_mid = 1,000 To calculate the final values for HI_COUNT_THR and LO_COUNT_THR based on cut_cnt_mid and the desired clock measurement accuracy: HI_COUNT_THR cut_cnt_mid + measurement accuracy LO_COUNT_THR cut_cnt_mid measurement accuracy Adjust the measurement accuracy in units of cut_clk (period): measurement accuracy (%) = measurement accuracy/cut_cnt_mid For a measurement accuracy of 10: measurement accuracy (%) = 10/1,000% = 1% Which implies: HI_COUNT_THR = 1, = 1,010 LO_COUNT_THR = 1, = 990 The IP core flags an error if cut_clk changes frequency by 1%. To allow you to calculate suitable values for the parameters, define the clock rates you are using: ref_clk (period) (ns) = 100 (10 MHz) cut_clk (period) (ns) = 5 (200 MHz) Now, REF_CLK_TC/cut_cnt_mid = cut_clk (period)/ref_clk (period) Therefore, REF_CLK_TC/cut_cnt_mid = 0.05 Assuming a value of 10,000 for the lowest of these two values, for a more accurate measurement, therefore: REF_CLK_TC = 10,000 cut_cnt_mid = 200,000 To calculate the final values for HI_COUNT_THR and LO_COUNT_THR based on cut_cnt_mid and the desired clock measurement accuracy: HI_COUNT_THR cut_cnt_mid + measurement accuracy LO_COUNT_THR cut_cnt_mid measurement accuracy Adjust the measurement accuracy in units of cut_clk (period): measurement accuracy (%) = measurement accuracy/cut_cnt_mid For a measurement accuracy of 200: measurement accuracy (%) = 200/200,000% = 0.1% March 2016 Altera Corporation Functional Safety Clock Checker Diagnostic IP Core

10 Page 10 Signals Which implies: HI_COUNT_THR = 200, = 200,200 LO_COUNT_THR = 200, = 199,800 The IP core flags an error if cut_clk changes frequency by 0.1%. Measurement Error The IP core always has some measurement error because of the data transfer between the clock domains. This measurement error is approximately: 3 (ref_clk (period) + cut_clk (period)). Thus, you may need to offset the values for HI_COUNT_THR and LO_COUNT_THR by this number for more accurate measurements. To minimize the effect of the measurement error, select larger values for REF_CLK_TC or cut_cnt_mid. For example: HI_COUNT_THR (offset) = HI_COUNT_THR (nominal) + measurement error LO_COUNT_THR (offset) = LO_COUNT_THR (nominal) + measurement error For example 1: measurement_error 3 ( ) = 30,030 ns As 30,030 ns is equal to approximately 3 cut_clk (period), thus: measurement error = 3 cut_clk (period) = (3/cut_cnt_mid) % = (3/1000)% = 0.3% HI_COUNT_THR (offset) = 1, LO_COUNT_THR (offset) = For example 2: measurement_error 3 ( ) = 315 ns As 315 ns is equal to approximately 63 cut_clk (period), thus: measurement error = 63 cut_clk (period) = (63/ cut_cnt_mid)% = (63/200,000)% = 0.03% HI_COUNT_THR (offset) = 200, LO_COUNT_THR (offset) = 199, Signals Table 4 shows the IP core interfaces. Table 4. IP Core Interfaces Interface Name Safety Related Type Clock Domain Description Status and control No status only Avalon- MM Avalon-MM system clock Provides current IP core status with last count value. Flag Yes indicates error outputs I/O Reference clock Provides error flag outputs. Functional Safety Clock Checker Diagnostic IP Core March 2016 Altera Corporation

11 Signals Page 11 Table 4. IP Core Interfaces Interface Name Safety Related Type Clock Domain Description Clock under test Yes the main clock under test I/O Clock under test Reference clock Note to Table 4: Yes failure prevents operation of the IP core (1) You must reset both interfaces simultaneously. Table 5 shows the control and status interface signals. Table 5. Control and Status Interface Signals I/O Table 6 shows the flag interface signals. Reference clock Clock under test input interface. Includes the global reset that puts the IP core into acquisition state. (1) Reference clock input to the IP core. Includes global reset that puts the IP core into acquisition state. (1) Signal Name Clock Domain Safety Related Description csr_addr[1:0] ref_clk Yes Read address to select status or count values. csr_readdata[31:0] ref_clk Yes Read data value. ref_clk ref_clk Yes ref_rst_n ref_clk Yes Table 6. Flag Interface Signals System clock. The interface logic should all be synchronous to this clock. Asynchronous active-low reset. You can asynchronously assert ref_rst_n but you must deassert ref_rst_n synchronously to the ref_clk. Signal Name Clock Domain Safety Related Description check_done ref_clk No (informative) check_running ref_clk No (informative) error ref_clk Yes error_n ref_clk Yes freq_too_high ref_clk No (informative) int_error ref_clk No (informative) Indicates that the IP core has reached the ref_clk terminal count and it has entered the count checking phase. It indicates the IP core has performed a test. Active-high signal that indicates that the clock under test counter is enabled and that the clock checking is in progress. This signal is de-asserted during reset and count checking phases. Indicates an error with the clock under test. Reset condition is low. Is also active if there is an internal or parameter error. Inverse output that indicates an error with the clock under test with inverse polarity from error. Reset condition is high. Is also active if there is an internal or parameter error. Indicates that the clock under test is too high or too low. Only valid when error is active. Indicates if the error was an internal error or an error in clock measurement (information only). March 2016 Altera Corporation Functional Safety Clock Checker Diagnostic IP Core

12 Page 12 Registers Figure 6 shows the timing of the output flag interface signals. Figure 6. Output Flag Interface Signals Timing Resets check_running check_done error_n Table 7. Clock Under Test Interface Signals Table 7 shows the clock under test interface signals. Signal Name Clock Domain Safety Related Description cut_clk Yes cut_rst_n cut_clk Yes Table 8. Reference Clock Interface Signals Table 5 shows the reference clock interface signals. The clock under test to the IP core. Check this clock for its presence and frequency. Active-low reset for the parts of the IP core that use cut_clk. Signal Name Clock Domain Safety Related Description ref_clk ref_clk Yes ref_rst_n ref_clk Yes System clock. The interface logic should all be synchronous to this clock. Asynchronous active-low reset. You can asynchronously assert ref_rst_n but you must deassert ref_rst_n synchronously to the ref_clk. Registers Table 9 shows the read-only register map. Table 9. Register Map Offset Mnemonic Name Description 0x00 STATUS Status General purpose status register. 0x04 CUT_COUNT Count value Count value for the most recent clock test period. 0x08 CLK_REF_TC Terminal count value Terminal count value for reference clock counter. Functional Safety Clock Checker Diagnostic IP Core March 2016 Altera Corporation

13 Registers Page 13 Status Register Table 10. Status Register Bits Table 10 shows the status register bits. Bits Mnemonic Access Name Description 31:8 Reserved. 7:6 int_err Read Internal error 5:4 clk_err Read 3 freq_toohigh Read 2:0 fsm Read Count Value Register Table 11. Count Value Register Bits Clock under test error flag Too high and low flag Finite state machine (FSM) current state Table 11 shows the count value register bits. Terminal Count Value Register Table 12 shows the terminal count value register bits. Bit 7 = param_error. The IP core sets this bit if you set illegal parameter values, for example, if the LO_COUNT_THR is greater than the HI_COUNT_THR. Bit 6 = flag_internal_error. The IP core sets this bit if the too high flag and too low flags are both active, which is an illegal condition. The IP core also sets this flag for the condition of a param_error. Must only be 01 or 10, otherwise internal error (refer to int_err). These bits are a reproduction of the IP core error flags. Indicates if the clock under test clock is too high or too low. Only valid when clk_err is active. Set to 1 when clock under test is too high a frequency, set to 0 when clock under test is too low a frequency. Direct connection of state register to Avalon Memory-Mapped (Avalon-MM) interface: RESET = 000 COUNT_ACK = 001 COUNTING = 010 TC_REACHED = 011 FLAG_GEN = 100 UNEXP_ERROR = 101 CUT_CLK_STOPPED = 110 Bits Mnemonic Access Name Description 23:0 cut_cnt Read Table 12. Terminal Count Value Register Bits Clock under test count Last registered value of clock under test counter. Bits Mnemonic Access Name Description 23:0 clk_ref_tc Read Reference terminal count Value of the terminal count value parameter that you specify. March 2016 Altera Corporation Functional Safety Clock Checker Diagnostic IP Core

14 Page 14 Getting Started Getting Started This topic provides a general overview of the Altera diagnostic IP core design flow to help you quickly get started. The following sections describe the general installation, design flow, evaluation, and production use of Altera diagnostic IP cores. Installation and Licensing Altera distributes the clock checker diagnostic IP core in the Diagnostic_IP_cust_<version>.zip file. Figure 7 shows the directory structure after you unzip the IP core, where <path> is the installation directory. You can install the IP core to any directory. Figure 7. IP Core Directory Structure <path> Installation directory. Diagnostic_IP_<version> Contains the Altera diagnostic IP library. common Contains the common files for the diagnostic IP library. test Contains test libraries. altera_avalon_mm_master_bfm Contains Avalon-MM master bus functional model library.. altera_avalon_mm_moniter_bfm Contains Avalon-MM monitor bus functional model library.. altera_avalon_mm_slave_bfm Contains Avalon-MM slave bus functional model library.. dip_bfm Contains clock and reset generator bus functional model library. dip_clk_check Contains the clock checker IP core. docs Contains the documentation.. hdl Contains HDL design files. test Contains files for testing. quartus Contains files for a test project. sim Contains files for simulating. tb Contains testbenches. Table 13 describes the files in the hdl directory. Table 13. Files in the hdl Directory Filename dip_clk_check.v dip_clk_check_cut_count.v dip_clk_check_flag_gen.v Description Clock checker top-level file. Clock under test (cut_clk) counter. Flag generation. Functional Safety Clock Checker Diagnostic IP Core March 2016 Altera Corporation

15 Getting Started Page 15 Table 13. Files in the hdl Directory Filename dip_clk_check_freq_comp.v dip_clk_check_fsm.v dip_clk_check_hw.tcl dip_clk_check_ref_clk_count.v dip_clk_check_slave_if.v Description Clock frequency comparator. Main FSM. Qsyshardware definition file. Reference clock (ref_clk) counter. Avalon-MM slave interface. Table 14. Files in the test\tb Directory Table 14 describes the files in the test\tb directory. Filename Purpose Description scenario<number>.sv Scenario generation Test constraints for varioustestscenarios. tb_tasks.v Testbench Avalon-MM bus functional model tasks for use in test harness. tb_test.v test_scenario.sv test_scenario_constraints.sv Testbench Scenario generation Scenario generation Avalon-MM bus functional model configuration, control and status register polling and scoreboard. Runs scenario randomization and generates auto_inc_file.txt and Qsys generation script. Default empty scenario file. test_scenario_pkg.sv Scenario generation Defines the test scenario class, basic constraints, and coverage. test_types_pkg.sv Testbench Test specific definitions for use in test harness. toptb.sv Testbench Test harness top-level file with device under test instance and test controller logic. Table 15. Files in the test\sim\test1 Directory Design Flow Table 15 describes the files in the test\sim\test1 directory. Filename Purpose Description test_scenario_constraints.sv Scenario Generation Modify this file to adjust generated scenario or copy over one of the scenario.v files. sopc_testharness.qsys Testbench Qsys test harness with Avalon-MM bus functional model and device under test. auto_inc_file.txt Testbench Include this file with test scenario parameterizations. The following sections describe the general steps on how to use Qsys to implement your design. 1 If you wish to use the clock checker in your design without using Qsys, you can instance the IP core and amend the parameters according to your requirements in the HDL. March 2016 Altera Corporation Functional Safety Clock Checker Diagnostic IP Core

16 Page 16 Getting Started You can use Qsys to build a system that includes your customized IP core. You easily can add other components and quickly create a Qsys system. Qsys automatically generates HDL files that include all of the specified components and interconnections. The HDL files are ready to be compiled by the Quartus II software to produce output files for programming an Altera device. Qsys generates a simulation testbench module for supported cores that includes basic transactions to validate the HDL files. Figure 8 shows a block diagram of an example Qsys system. Figure 8. Qsys System Altera IP Core Simulation Testbench Module Qsys System Altera IP Core Instance System Interconnect Fabric Peripheral 1 Peripheral 2 Peripheral 3 f f For more information about system interconnect fabric, refer tothe QsysInterconnect chapter in the Quartus II Handbook,Volume 1: Design and Synthesis, and Avalon Interface Specifications. For more information about Qsys and the Quartus II software, refer to the Quartus II Handbook,Volume 1: Design and Synthesis and Quartus II Help. Specify Parameters To specify IP core parameters with the Qsys flow, follow these steps: 1. Create a new Quartus II project using the New Project Wizard from the File menu. 2. Specify the hdl directories for the IP diagnostic cores using the example search_path.ipx file in the test_project directory. 3. On the Tools menu, click Qsys. 4. For a new system, specify the system name and language. Functional Safety Clock Checker Diagnostic IP Core March 2016 Altera Corporation

17 Getting Started Page On the System Contents tab, double-click the name of your IP core to add it to your system. The relevant MegaWizard interface appears. 1 The System Contents tab lists Altera IP cores by category. For example, you can find the diagnostic IP cores by expanding Industrial Safety. 6. Specify the required parameters in the MegaWizard interface. For detailed explanations of these parameters, refer to Parameters on page Click Finish to complete the IP core instance and add it to the system. Complete the Qsys System To complete the Qsys system, follow these steps: 1. Add and parameterize any additional components. 2. Use the Qsys Connection panel on the System Contents tab to connect the components. 3. By default, clock names are not displayed. To display clock names in the Module Name column and the clocks in the Clock column in the System Contents tab, click Filters to display the Filters dialog box. In the Filter list, click All. 4. If you intend to simulate your Qsys system, on the System Generation tab, turn on Simulation to generate a functional simulation model for your system. 5. Click Generate to generate the system. Simulate the System 1 Qsys generates a.qip file and a top-level HDL file for the Qsys system in the <Qsys system name>/synthesis sub-directory of the Quartus II project. This file contains information about a generated IP core or system. In most cases, the.qip file contains all of the necessary assignments and information required to process the IP core or system in the Quartus II Compiler. Generally, a single.qip file is generated for each Qsys system. However, some more complex Qsys components generate a separate.qip file. In that case, the system.qip file references the component.qip file. Add the.qip file to the Quartus II project from the Assignments menu. During system generation, Qsys generates a functional simulation model and testbench, which you can use to simulate your system easily in any Altera-supported simulation tool. Qsys also generates a set of ModelSim Tcl scripts and macros that you can use to simulate the testbench and functional simulation models or clear text RTL design files that describe your system in the ModelSim simulation software. Compile the Design After you define and instantiate your IP core, you must compile your design to create programming files to configure the FPGA. March 2016 Altera Corporation Functional Safety Clock Checker Diagnostic IP Core

18 Page 18 Testbench Before you compile the IP core, ensure you add correct timing constraints to the IP core. The test\quartus directory contains an example.sdc file that includes constraints for the clock domains and sets false paths between the ref_clk and cut_clk clocks. You should customize this file for the constraints in your system. f For more information on TimeQuest timing analysis, refer to Quartus II Help. You can use the Start Compilation command on the Processing menu in the Quartus II software to compile your design. After successfully compiling your design, program the targeted Altera device with the Programmer and verify the design in hardware. Testbench The testbench consists of the clock checker device under test instantiated within an Qsys system. The testbench connects the IP core to the Avalon-MM bus functional model and other bus functional models for driving the clock inputs and checking the flag outputs. The testbench controls and accesses the Avalon-MM interface even though there is no direct signal connection. Figure 9 shows the testbench. Figure 9. Testbench Clock Generator Clock Generator Testbench Qsys Top-Level File cut_clk error cut_rst_n ref_clk ref_rst_n Clock Checker error_n freq_too_hi Flag Test avalon_status Avalon-MM Master Bus Functional Model Functional Safety Clock Checker Diagnostic IP Core March 2016 Altera Corporation

19 Testbench Page 19 Clock Generator Flag Test The testbench includes a basic clock and reset generator with two clock period parameters and a reset parameter. To simulate stuck at faults, the testbench sets the clock period parameter to zero. The clock generator switches to the second clock period after a defined number of clock cycles (switch_period_cycles parameter) to mimic a change in clock rate during operation. To model the reset, the testbench initializes the reset state and then releases the reset after a parameterizable number of cycles. The testbench models normal reset (release after reset_cycles cycles) and midtest reset (reset after reset_midtest_delay cycles for reset_cycles cycles). The clock generator does not model or test for jitter conditions on the generated clock, because the IP core only measures average clock periods over a set time period. The flag test decodes the flags to provide internal status and any error status, for example, cut_clk too high. The testbench tests these flags dynamically to make sure it only asserts or deasserts errors within a certain period of the presence or removal of an input condition with an error. The testbench generates an error if the flags do not match the expected state. Avalon MM Master Bus Functional Model The Avalon MM master bus functional model (and the Avalon-MM monitor bus functional model) provide stimulus to and check the protocol of the status interface. 1 Altera ships the Quartus II software v9.1 SP2 models with the IP core. Altera have made several minor enhancements to these models to make them compatible with the Quartus II software v14.1. The testbench requires these specific models. Test Controller Directed functions provide the interface to the bus functional model to issue write or read operations. The testbench copies the register status in testbench variables, so that you can compare previous values and read them immediately if required. The test controller takes a static configuration from Verilog HDL parameters, sets up the device under test and the bus functional model and then performs the test. At the end of the tests it checks for pass or fail criteria from each bus functional model. Some tests cause failure conditions in the device under test and some cause normal operation conditions. The test controller checks for both conditions. It implements a simple behavioral model of the device under test in a function that calculates the expected pass or fail condition from the input stimulus and static parameters. It then compares the device under test state to the output of the model at the end of simulation. March 2016 Altera Corporation Functional Safety Clock Checker Diagnostic IP Core

20 Page 20 Testbench Test Flow Table 16. Test Flow The test flow is divided into START and END phases. In the START phase the testbench sets up a clock frequency relationship between the ref_clk and cut_clk that results in a detected condition of frequency range (OK, TOO_HIGH, TOO_LOW, or STOPPED). In the END phase, the testbench changes the frequency of cut_clk, which results in another detected condition (OK, TOO_HIGH, TOO_LOW, or STOPPED). The testbench continuously monitors the device under test status and error flags throughout the simulation and checks them against expected values based on the test state. Any deviation from the expected behavior causes the testbench to exit immediately without issuing the TEST_COMPLETE state. Table 16 summarizes the test flow. State START_INIT. START_MEASURING START_STABLE END_INIT END_MEASURING END_STABLE TEST_COMPLETE Description Initializes the counters and clock generators. The flow transitions to START_MEASURING state. The device under test starts measuring the relative clock frequencies. During this state the testbench expects a maximum of one flag value change. The flow transitions to the START_STABLE state after waiting sufficient clocks for the first measurement to take place. The device under test continues measuring, but now the measurement result and flags should be stable. The testbench expects no flag values to change in this state. The flow transitions to the END_INIT state after waiting sufficient clocks for the second measurement to take place. Switches cut_clk clock generator to its alternative clock frequency. The flow transitions to the END_MEASURING state. The device under test starts measuring the relative clock frequencies. If the START or END frequency condition is OK, during this state the testbench expects to see a maximum of one flag value change, otherwise it may see two as it transitions from one error condition to another and potentially transitions through the OK condition. The flow transitions to the END_STABLE state after waiting sufficient clocks for the first measurement to take place. The device under test continues measuring, but now the measurement result and flags should be stable. The testbench expects no flag values to change in this state. The flow transitions to the TEST_COMPLETE state after waiting sufficient clocks for the second measurement to take place. The test is complete and the testbench issues a pass, if the flow reaches this state. Using the Testbench Altera supply a testbench, to use the design or to modify the test scenario (optional), follow these steps: 1 Altera verifies this testbench using the ModelSim software version 10.3c. 1. Open the Quartus II software. 2. Click Tools > Qsys. 3. In Qsys, open the Qsys test harness <installation directory>\test\sim\test1\sopc_testharness.qsys. 1 Ignore any warnings about invalid device family name. 4. Modify the IP core parameters (optional). Functional Safety Clock Checker Diagnostic IP Core March 2016 Altera Corporation

21 IP Core Verification Page On the Project Setting tab, set the device family to Cyclone V. 6. Generate the design. 7. Close Qsys and the Quartus II software. 8. Edit <installation directory>\test\sim\test1\auto_inc_file.txt to change testbench parameters to match IP parameters and desired test parameters (optional). 9. Open the ModelSim-Altera simulator and change to the <installation directory>\test\sim\test1\ directory. 10. On the File menu, click load. Open the msim.do file. 11. On the Simulate menu, point to Run and click Run All. 12. When the simulation completes, you see the message Simulation passed. f f For information about the latest Altera-supported simulation tools, refer to the Quartus II Software Release Notes. For information about simulating Qsys systems, refer to Volume 1: Design and Synthesis of the Quartus II Handbook IP Core Verification Altera performed basic hardware tests during the development of the IP core with specific development boards to demonstrate the IP core functionality. Altera includes one of these test project designs in the test\quartus\test_project_cyclonevsoc directory. This design targets a Cyclone VSoC devlopment board, or you can adapt it to any other development board. To compile the design, follow these steps: 1. In the Quartus II software, open the clk_check_hw_example.qpf. 2. In Qsys, open the dip_clk_jtag_mast.qsys file and generate the system. 3. In the Quartus II software, compile the project. The design contains an instance of the IP core connected to an instance of an Avalon-MM JTAG master. The design includes this dummy Avalon-MM JTAG master to allow the design to pass connectivity checks, but it has no function within the design. The IP core has a low-count threshold that corresponds to 49 MHz and a high-count threshold that corresponds to 51 MHz. The design routes error flags to the board LEDs. The design also includes a PLL with three outputs: one at MHz; one at 50 MHz; and one at MHz. You can use BUTTON[1] and BUTTON[2] on the board to select which of these three PLL outputs you connect to the IP core cut_clk input. During operation, if you select the MHz clock, the IP core flags show an error and the freq_too_high signal is inactive, to indicate a low-frequency clock. If you select the MHz clock, the IP core flags show an error and the freq_too_high signal is active, to indicate a high-frequency clock. If you press no buttons, the design connects the 50-MHz clock to the IP core, and no error flags are active. March 2016 Altera Corporation Functional Safety Clock Checker Diagnostic IP Core

22 Page 22 Standards The design includes a SignalTap II instance to allow you to observe the IP core operating. Table 17 shows the files in the test\quartus\test_project_cyclonevsoc directory. Table 17. Files in the test\quartus\test_project_cyclonevsoc Directory File Name clk_check_hw_example.qsf and.qpf clk_check_hw_example.sdc clk_check_hw_top.v dip_clk_jtag_mast.qsys searchpath.ipx pll.v Description Quartus II project files. TimeQuest timing constraints file. Top-level Verilog HDL Qsys system. IP search path for Qsys PLL. Standards Altera developed this IP core according to the following documents: IEC 61508:2010 ISO 26262: TÜV Rheinland has qualified this IP core. For the certificate number, contact your Altera representative. 1 Only a sufficiently competent person, with knowledge of Altera tools and practices, should perform the integration of this IP core. IEC :2010 Annex F and ISO :2011, 7.4 provide recommended steps in hardware design. If you modify this IP core source code, the TÜV Rheinland qualification becomes invalid. In this instance, you must perform an impact analysis to ensure that the IP core is still working as defined. Document Revision History Table 18 shows the revision history for this document. Table 18. Document Revision History (Part 1 of 2) Date Version Changes March Corrected error and error_n signal description. July Added further ISO references. Updated for the Quartus II software v14.1 update 1 July Removed Cyclone III and Stratix III devices Added ISO references Functional Safety Clock Checker Diagnostic IP Core March 2016 Altera Corporation

23 Document Revision History Page 23 Table 18. Document Revision History (Part 2 of 2) Date Version Changes Updated for the Quartus II software v13.1 update 4: Removed mixed simulator steps Updated device support April Updated performance data Removed references to SOPC Builder and replaced with Qsys Updated file names Updated doc references October Updated for the Quartus II software v11.0 SP1. November Initial release valid for the Diagnostic_IP_cust_v1.0.zip file. March 2016 Altera Corporation Functional Safety Clock Checker Diagnostic IP Core

24 Page 24 Document Revision History Functional Safety Clock Checker Diagnostic IP Core March 2016 Altera Corporation