Slide 1: Design Verification Design Profiler Course 8
Slide 2: 8. Design Profiler Design Profiler is a tool integrated within Active-HDL. The Design Profiler provides insight into how the CPU is utilized during simulation. When the simulation is running, the profiling engine counts CPU ticks for each HDL statement. Profiling data is used to identify design units or code sections that put the greatest strain on the simulator. All materials updated on: September 30, 2004
Slide 3: 8.1 Enabling Design Profiler To enable Design Profiler you have to: • Open the Design Settings window from the Design menu • Select the Code Coverage/Profiler tab • Check the Profiler option • Specify the name of the output file directory • Press OK button All materials updated on: September 30, 2004
Slide 4: 8.2 Enabling Design Profiler When a design simulation is initialized by a DO-macro file and you would like to use Design Profiler, you have to initialize simulation with following options: asim -profiler -tbp_dest $DSN/profiler count This will enable Design Profiler data gathering in default mode i.e. information will be collected for each unit. To distinguish each instance from the others, use syntax: asim -profiler –profiler_hierarchy -tbp_dest $DSN/profiler count Note: Please refer to on-line documentation for more details on asim command usage. All materials updated on: September 30, 2004
Slide 5: 8.3 Invoking Design Profiler Viewer When your simulation is finished, you can run the Design Profiler Viewer from the Tools menu in Active-HDL. All data gathered by Design Profiler can be presented in a graphical or textual form in the Design Profiler Viewer window. All materials updated on: September 30, 2004
Slide 6: 8.4 Design Profiler To load the Design Profiler data collected during simulation run: • Select Open… from the File menu or use button in the main toolbar. • Find profiler.tbp file. It should have been created in previously specified path. All materials updated on: September 30, 2004
Slide 7: 8.5 Design Profiler There are two panels in the Design Profiler Viewer window: • Hierarchy pane - displays the hierarchical structure of the design • Source Code /Details pane Source Code tab Details tab Hierarchy pane All materials updated on: September 30, 2004
Slide 8: 8.6 Hierarchy Window The Hierarchy tab is divided into several columns: Hierarchy: Shows an expandable tree with the design structure. CPU Ticks:Shows the number of CPU ticks that were required during simulation to execute the code for the object highlighted in the hierarchy tree. Share [%]:Shows the share in the total simulation time for the object highlighted in the hierarchy tree. Time [us]:Shows time in microseconds that was required during simulation to execute the code for the object highlighted in the hierarchy tree. Time measurement is derived from the number of CPU ticks and the CPU frequency. All materials updated on: September 30, 2004
Slide 9: 8.7 Hierarchy Window Processes Tab (Hierarchical) shows data for individual processes in the design hierarchy. Units tab in the left pane shows profiling statistics for all units used in the design, irrespective of their position in the hierarchy tree. If a given unit is instantiated more than once in the design, profiling data is merged for all instances of that unit. Processes Tab (Flat): If the unit in which the process is defined is instantiated more than once in the design, profiling data is merged for all instances of the process. The Unused Subprograms tab lists all subprograms that were not executed during the simulation process. All materials updated on: September 30, 2004
Slide 10: 8.8 Hierarchy Window You can select which data should be displayed using list-box or button in the Main Tool Bar. Display settings allows you to configure and customize view of gathered data by Design Profiler. To customize visibility, please use the Filter dialog box. All materials updated on: September 30, 2004
Slide 11: 8.9 Source Code Tab The source code of unit or process selected in Hierarchy pane is displayed in the Source tab. Executed statements are displayed in red color. The number of CPU Ticks is also shown to the left of corresponding line. Statements that were not executed at all are shown in blue. Non-executable lines or lines are displayed against a gray background. Non-executable lines CPU Ticks Not executed statement Executed statements All materials updated on: September 30, 2004
Slide 12: 8.10 Details Tab The Details tab shows pie charts with profiling statistics. The display on the Details tab is synchronized with the left pane of the Profiler Viewer. Selecting a unit or a process on the Hierarchy, Processes, or Units tab brings up the appropriate chart. The first chart (Results for selected instance) shows statistics that do not account for objects nested further down in the hierarchy tree. The second chart (Results for selected instance and all its children) is based on statistics that include nested objects. Accordingly, the time share for the top-level unit is 100% All materials updated on: September 30, 2004
Slide 13: 8.11 Design Profiler Report The Design Profiler provides also possibility to generate a custom report file from gathered data. Using Profiler Report settings, you can easily choose interesting data which should be put into the report file. All materials updated on: September 30, 2004
Slide 14: Design Profiler Example profiler_example Project All materials updated on : September 3, 2002
Slide 15: 8.12 Preview Project functionality based on modulator sample installed with Active-HDL. The top level – modulator contains two sine generators (oscillator + counter + main sine generator) and multiplier module based on IP Core Generator. U4 CLOCK clk1 U6 clock 1 CLK CLR counter GND U8 rst U5 reset CLOCK clk2 clock 2 Q[5:0] counte r1(5:0) U1 D TA[ : ] A 50 FR CK L CLR Q[7 : ] 0 sine1 (7 :0) U 3 A ( : ) Q( 5 : ) 70 10 B(7 : ) 0 U2 Q[5 : ] 0 counter2(5:0 ) D TA[ : ] A 50 FR GND CK L CLR multipler_0 0 sine2(7 :0) Q[7 : ] 0 Q(15:0) sine_gener ator s rt U7 C K CLR L counter sine_gener ator All materials updated on: September 30, 2004
Slide 16: 8.13 Contents Design includes four architectures of Modulator entity top-level and four configurations to invoke simulation with proper architecture. The IP_CORE subfolder contains units generated by IP Core Generator. Additionally, for each example a macro file has been provided. This way, to verify each case you have to invoke the proper macro. All materials updated on: September 30, 2004
Slide 17: 8.14 Modulator architecture In this case as a multiplier module a fully synthetizable unit containing muxes and adders has been used. After execution “runme_0.do” macro you can see that this component and its subcomponents takes over 70% of simulation execution time. All materials updated on: September 30, 2004
Slide 18: 8.15 Modulator_1 architecture To provide better performance the multiplier unit has been replaced by multiplier_01. The new unit has the same functionality but its architecture is much simpler: ”Q<=A*B”. If you execute the “runme_1.do” macro you can easily find difference: the CPU usage for multiplier unit has been drastically decreased - about 10 times! U4 clk1 U6 CLOCK clock1 CLKCLR Q[5:0] c ount r e G ND U8 rst re set CLOCK clk2 clo ck2 rs t U7 CL CL KR counte r G ND Q[ :0 ] 5 o cunte r (5:0) 2 U2 DATA [5:0] FR Q[7:0 ] CLK CLR sin e_gener ato r si e2(7:0) n counte r1(5:0 ) U1 DATA [5:0] FR Q[7:0 ] CLK CLR sin e_gener ato r si e1(7:0) U3 n A( :0 ) Q( 5:0 ) 7 1 B( :0 ) 7 m ul ip le r_0 1 ti Q(15 : ) 0 U5 use IEEE.std_logic_signed.all; architecture multi_arch of multiplier_01 is begin Q <= A * B; end multi_arch; All materials updated on: September 30, 2004
Slide 19: 8.16 Modulator_2 architecture The “Modulator_2” architecture includes additional process. This process writes all simulation results to text file. After execution the “runme_2.do” macro you can find that new process takes 58% of entire CPU time. U4 clk1 U8 U6 CLOCK clock1 CLKCLR count r e Q[ :0 ] 5 counte 0) r1(5: GND U1 DATA[5:0 ] FR CLK CLR sine_g enera t r o s rt e r set CLOCK lo k c c2 rs t U7 CL CLR K counte r GND Q[ :0 ] 5 co nte r (5 ) u 2 :0 U2 DATA[5:0 ] FR CLK CLR sine_g enera t r o Q[7:0] sine2( :0 7) Q[7:0] sine1( :0 U3 7) A(7:0) B(7:0) Q(15:0 ) x16 Q(15:0 ) U5 m ultip lie r_0 1 clk2 Wri te _Pro ess c Q_i nt 15 ) ( :0 All materials updated on: September 30, 2004
Slide 20: 8.17 Modulator_3 architecture The Write_Process has been optimized on “modulator_3” architecture. The sensitivity list has been reduced to the only one signal: “Q_int”. After execution “runme_3.do” you can verify the optimization effect. U 4 CLOCK c l1 k U6 clo ck1 CLKCLR Q[5: ] 0 coun t r e cont er1 u (5:0) U1 DATA[ 0] 5: FR CLK CLR sin e_ge nera t r o rs t re set CLOCK c l2 k lo c ck2 rs t U 7 CLKCLR counte r G ND Q[ :0] 5 counte 5:0 ) r2( U2 DATA[ 0] 5: FR CLK CLR sin e_ge nera t r o Q[ : ] 70 si e2(7 ) n :0 Q[ : ] 70 si e1(7 ) U3 n :0 A( : ) Q(15 ) 70 0 : B( : ) 70 m ultip le r_01 i x16 Q (15:0 ) G ND U 8 U 5 Write _P cess ro Q t 15 ) _in ( :0 One signal “Q_int” on sensitivity list All materials updated on: September 30, 2004