8. MODULATOR
8.1 Description
- Usage: This module will merge all the previously designed modules.
- Block diagram:
- Drawing 8.1: Modulator block diagram
- Input ports:
- clk_p: differential input clock signal
- clk_n: differential input clock signal
- sw0: input signal from the on-board switch, used for changing output signal frequency
- Output ports:
- pwm_out: pulse width modulated signal
- Generics:
- this_module_is_top_g: if some module is top, it needs to implement the differential clk buffer, otherwise this variable will be overwritten by a upper hierarchy layer
- board_name_g: parameter that specifies major characteristics of the board that will be used to implement the modulator design. Possible choices: lx9_c, zedboard_c, ml605_c, kc705_c. Adjust the modulator_pkg.vhd file to add more
- design_setting_g: user defined settings for the pwm design
- File name: modulator_rtl.vhd
8.2 Creating Module
To create Modulator module use steps for creating modules, Sub-chapter 2.3.1 Creating a Module Using an Text Editor.
Modulator VHDL model:
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
use ieee.std_logic_textio.all;
use ieee.std_logic_unsigned.all;
use work.modulator_pkg.all;
library unisim;
use unisim.vcomponents.all;
entity modulator is
generic(
this_module_is_top_g : module_is_top_t := yes;
-- If some module is top, it needs to implement the differential clk buffer,
-- otherwise this variable will be overwritten by a upper hierarchy layer
board_name_g : board_setting_t := kc705_c;
-- Parameter that specifies major characteristics of the board that will be used
-- to implement the modulator design
-- Possible choices: lx9_c, zedboard_c, ml605_c, kc705_c
-- Adjust the modulator_pkg.vhd file to add more
design_setting_g: design_setting_t := design_setting_c
-- User defined settings for the pwm design
);
port(
clk_p : in std_logic; -- differential input clock signal
clk_n : in std_logic; – differential input clock signal
sw0 : in std_logic; -- signal made for selecting frequency
pwm_out : out std_logic -- pulse width modulated signal
);
end;
architecture rtl of modulator is
signal clk_in_s : std_logic;
signal ampl_cnt_s : std_logic_vector(design_setting_g.depth-1 downto 0); -- amplitude counter
signal sine_ampl_s : std_logic_vector(design_setting_g.width-1 downto 0); -- current amplitude value of the sine signal
signal freq_trig_s : std_logic := '0'; – signal which frequency depends on the sw0 state
constant c1_c : real := board_name_g.fclk/(real((2**design_setting_g.depth)*(2**design_setting_g.width)));
-- c1_c = fclk/(2^depth*2^width) - c1_c = 190.73486, fclk = 200 MHz
constant div_factor_freqhigh_c : integer := integer(c1_c/design_setting_g.f_high)*(2**design_setting_g.width);
-- div_factor_freqhigh_c = (c1_c/f_high)*2^width - threshold value of frequency a = 221184
constant div_factor_freqlow_c : integer := integer(c1_c/design_setting_g.f_low)*(2**design_setting_g.width);
-- div_factor_freqlow_c = (c1_c/f_low)*2^width - threshold value of frequency b = 782336
begin
-- if module is top, it has to generate the differential clock buffer in case
-- of a differential clock, otherwise it will get a single ended clock signal
-- from the higher hierarchy
clk_buf_if_top : if (this_module_is_top_g = yes) generate
clk_buf : if (board_name_g.has_diff_clk = yes) generate
IBUFGDS_inst : IBUFGDS
generic map (
IBUF_LOW_PWR => TRUE,
-- low power (TRUE) vs. performance (FALSE) setting for referenced I/O standards
IOSTANDARD => "DEFAULT"
)
port map (
O => clk_in_s, -- clock buffer output
I => clk_p, -- diff_p clock buffer input
IB => clk_n -- diff_n clock buffer input
);
end generate clk_buf;
- Usage: used to verify correct operation of the Modulator module defined in the modulator_rtl.vhd file
- Test bench internal signals:
- clk_p_s: differential input clock signal
- clk_n_s: differential input clock signal
- sw0_s: input signal from the on-board switch, used for changing output signal frequency
- pwm_s: pulse width modulated signal
- Generics:
- this_module_is_top_g: if some module is top, it needs to implement the differential clk buffer, otherwise this variable will be overwritten by a upper hierarchy layer
- board_name_g: parameter that specifies major characteristics of the board that will be used to implement the modulator design. Possible choices: lx9_c, zedboard_c, ml605_c, kc705_c. Adjust the modulator_pkg.vhd file to add more
- design_setting_g: user defined settings for the pwm design
-
File name: modulator_tb.vhd
- Modulator test bench:
- You can start your simulation (see Chapter 3.4 Simulating)
- Simulate your design for 200 ms (see Chapter 2.5 Simulating (with ISim) – step 12.)
- Assuming no errors, your simulation result should look similar to Illustration 8.1.
-
Timing Constrains – are typically specified globally but can also be specified for individual paths. Global constraints include period constraints for each clock, setup times for each input, and clock-to-out constraints for each output. You can enter timing constraints using the Create Timing Constraints process in Project Navigator. This creates a text-based User Constraints File (UCF).
-
Placement Constraints - for FPGA designs, you can specify placement constraints for each type of logic element, such as BRAMs, DSPs, LUTs, FFs, I/Os, IOBs, and global buffers. Individual logic gates, such as AND and OR gates, are mapped into CLB function generators before the constraints are read and cannot be constrained. For CPLD designs, you can specify placement constraints for macrocells, for function blocks, and for I/Os.
-
Synthesis Constraints - Synthesis constraints instruct the synthesis tool to perform specific operations. When using XST for synthesis, synthesis constraints control how XST processes and implements FPGA resources, such as state machines, multiplexers, and multipliers, during the HDL synthesis and low level optimization steps. Synthesis constraints also allow control of register duplication and fanout control during global timing optimization.
- using Wizard (PlanAhead-Floorplanner Wizard)
-
using Text Editor
- If necessary, in the Design window, select Implementation view
- In the Hierarchy window, select the top modulator file (modulator_rtl.vhd)
- In the ISE Project Navigator, choose Project / New Source... option from the ISE main menu
- In the Select Source Type dialog box, select Implementation Constraints File option, enter module_name_ucf (modulator_rtl) in the File name field and click Next, see Illustration 8.2
- In the Summary dialog box, click Finish and the Project Navigator will create an empty modulator_rtl.ucf source file for you, see Illustration 8.3
- In the Processes window, expand User Constraints, and you will find three options that are related to PlanAhead tool:
- I/O Pin Planning (PlanAhead) – Pre-Synthesis
- I/O Pin Planning (PlanAhead) – Post-Synthesis
-
Floorplan Area/IO/Logic (PlanAhead)
- I/O Pin Planning (PlanAhead) – Pre-Synthesis – At this stage of the design, synthesis step has not been done. The tool don't have concept of clock ports, clock related logic,... I/O Pin Planning should be performed after logic synthesis, because the presence of a netlist ensures that the clocks will be recognized by PlanAhead tool. This means that with this option you can't create timing constraints, just placement constraints.
- I/O Pin Planning (PlanAhead) – Post-Synthesis – I/O Pin Planning should be performed after logic synthesis, because the presence of a netlist ensures that the clocks will be recognized by PlanAhead tool. This means that with this option you can create both timing and placement constraints.
- Floorplan Area/IO/Logic (PlanAhead) – To analyze the design or to perform floorplanning from the Project Navigator after running logic synthesis and prior to implementation, double-click on the Floorplan Area/IO/Logic (PlanAhead) (see Illustration 8.4), or select the Tools → PlanAhead → Floorplan Area/IO/Logic (PlanAhead)... command.
- Double-click on the I/O Pin Planning (PlanAhead) – Post-Synthesis option and PlanAhead tool will open, see Illustration 8.4
- The main window of the PlanAhead displays the package view of the Kintex-7 device. Below the Package view, two additional tabs are populated. One tab displays the list of I/O ports of the design and the second tab displays the list of package pins on the device package.
- In the I/O Ports tab, click Expand All option, or just expand Scalar ports, which shows all I/O Ports of your design, see Illustration 8.5
-
Note that none of the pins in this view have an assigned location.
Grey icons indicate unplaced ports, while yellow icons indicate placed ports. On the Illustration 8.5 we can see that all I/O ports are coloured grey, since none of them has been placed to a specific pin location. After we assign a pin location to each of the I/O ports they will be coloured yellow, as can be seen on the Illustration 8.7.
-
To connect your logical with your physical ports, select one scalar port (for example pwm_out) and find in the data sheet for the Kintex-7 (KC705) development board to which pin location you would like to connect your pwm_out port. In our case it will be:
NET "GPIO_LED_0_LS" LOC = "AB8" | IOSTANDARD = LVCMOS15 | SLEW = SLOW | DRIVE = 12 ;
- Click on the pwm_out's Site field and choose AB8 as a pin location to connect the pwm_out port
- Click on the pwm_out's I/O Std column and change the I/O standard from default LVCMOS18 to LVCMOS15
-
Leave all the other pwm_out's options unchanged, because they are default values
Note: After assigning pin location and I/O standard for pwm_out port, we can notice that I/O Port Properties window popped up. This is the another way to change port properties, see Illustration 8.6. If you want to apply some changes that you made, just click the Automatically update button. - Repeat these configuration steps for the remaining ports using the port map information below:
- Note that clk_n, which is the differential input pair of clk_p, is automatically assigned a pin location of AD11. The clock pin locations you can see in the Package and Device views. In the Package view, mouse over the pin AD12 and AD11 to confirm that clk_p and clk_n have been locked to this locations, see Illustration 8.8.
-
As pins or banks are selected, the corresponding pins or banks become highlighted in the other views. This makes it easier to see that the pins assigned in each bank meet the I/O banking rules and the grouped appropriately.
As you drag across the package view, yellow icons indicate assigned pins, grey icons indicate unassigned pins and both displayed indicates assigned I/O banks.
In the Package view you can also notice that:
- the coloured areas between the pins display the I/O banks
- the clock pins are shown as grey hexagons
- the clock-capable pins are shown as blue hexagons 
- the power pins (VCC) are shown as red squares
- the ground pins (GND) are shown as green squares - When you are finished with the placement constraints, click File → Save Constraints option, see Illustration 8.9
- Now, if you turn back to the ISE Project Navigator, your modulator_rtl.ucf constraints file should appear in the Hierarchy window, under the modulator module, see Illustration 8.10
-
In the Hierarchy window, double-click on the modulator_rtl.ucf to see what the tool has created for us, see Illustration 8.11
Note: The another way to open the modulator_rtl.ucf is to select it in the Hierarchy window, right-click on it and choose Open option.
- As you can see from the code above, PlanAhead tool has created placement constraints using the port map information as we specified.
- Click on the Constraints tab and open the Constraints window
- In the Constraints window click on the Create new constraint toolbar button and the New Timing Constraint dialog box will appear
- In the New Timing Constraint dialog box, set the parameters as it is shown on the Illustration 8.12:
Illustration 8.12: Create New Timing Constraint dialog box
- in the Constraint Types window select Basic period
- in the Basic period window select clk_p signal in the Clock Nets field
- in the Period Specification box type 5 ns in the Width field, because 5 ns is the period of the 200 MHz input clock signal
- in the Period Specification box enable Duty Cycle and Specify Duty Cycle to 50% and click OK
- At the end, click OK to accept the changes
- Now you should see your timing constraints in the Constraints window as it is shown on the Illustration 8.13
- Open any text editor (for better usability take one with VHDL code support)
- Insert the ucf constraints from the code below
- Save the constraints file as constraints_file_name (e.g. modulator) into your working directory
- Change the ending from *.txt to *.ucf
- Optional: Launch Project Navigator (if it is not already launched)
- Optional: Open “Modulator” project (modulator.xise)(if it is not already opened)
- If necessary, select Implementation as a Design View
- Select the top modulator file (modulator_rtl.vhd) in the Hierarchy window
- Select Project → Add Source... option from the ISE Project Navigator main menu
- Select constraints file (e.g. modulation_rtl.ucf) in the Add Source window and click Open
- Click OK in the Adding Source Files dialog box and your modulator_rtl.ucf constraints file should appear in the Hierarchy window, under the modulator module, see Illustration 8.10
-
typing constraints in the text editor (see ucf constrains file above)
(to learn more about writing UCF constraints, please see Xilinx's “Constraints Guide”)
- using “Create Timing Constraints” option from the ISE Project Navigator
- Select the top modulator file (modulator_rtl.vhd) in the Hierarchy window
- In the Processes window, expand User Constraints option and double-click on the Create Timing Constraints command, see Illustration 8.14
- Timing Constraints editor will open immediately, see Illustration 8.15
-
In the Unconstrained Clocks window, right-click on the clk_p signal and select Create Constraint option, as it is shown on the Illustration 8.16
Note: You can run the same option by double-clicking on the clk_p signal.
- In the Clock Period dialog box set the parameters as it is shown on the Illustration 8.17
- In the Clock signal definition box specify Time period of the clk_p input signal to 5 ns and Rising duty cycle to 50% and click OK
- After setting clock period parameters you will see your clock constraints in the Create Timing Constraints for Clock Domains (PERIOD) window as it is shown on the Illustration 8.18
- First, save your Timing Constraints file
- Back from the Timing Constraints tab to the Design tab in the Project Navigator
- Select modulator_rtl.ucf file in the Hierarchy window
- Double-click on the Edit Constraints (Text) option in the Processes window, see Illustration 8.19 and ISE will immediately open your ucf file with both, placement and timing constraints, see Illustration 8.20
- Doing detailed-level floorplanning
- Creating an Relationally Placed Macro (RPM) core that can be used in other designs
- Viewing and editing location constraints (see Chapter 8.5 Creating UCF File, Creating UCF File using the PlanAhead-Floorplanner Wizard)
- Finding logic or nets by name or connectivity
- Cross probing from the Timing Analyzer to the Floorplanner
- Placing ports automatically for modular design (part of a design)
- In the Hierarchy window, right-click on the translatable module (modulator_rtl) and select Set as Top Module, if it is not already set
- In the Hierarchy window, select the translatable module (modulator_rtl)
- In the Processes window, expand Implement Design and double-click on the Translate command, Illustration 8.21.
- In the ISE Project Navigator, select Project → Design Summary/Reports option from the main menu, see Illustration 8.22
- In the Design Summary window, select Detailed Reports → Translation Report, see Illustration 8.23
- NetGen converts the Translate process output (an NGD file) to a post-translate simulation model (a structural SIMPRIM-based VHDL and Verilog file). This model is then used in the Simulate Post-Translate Model process to verify that design functionality is correct after the translation stage as the input file for your simulator.
- In the Processes window, expand Implement Design and then expand Translate, see Illustration 8.25
- Right-click on the Generate Post-Translate Simulation Model and select Process Properties..., see Illustration 8.25
- In the Process Properties – Simulation Model Properties dialog box, write in the “Rename Top Level Architecture To” field rtl, and click OK
- At the end, double-click on the Generate Post-Translate Simulation Model command, see Illustration 8.27
- In the Hierarchy window, right-click on the mapping module (modulator_rtl) and select Set as Top Module, if it is not already set
- In the Hierarchy window, select the mapping module (modulator_rtl)
- In the Processes window, expand Implement Design and double-click on the Map command, see Illustration 8.28
no_clk_buf : if (board_name_g.has_diff_clk = no) generate
clk_in_s <= clk_p;
end generate no_clk_buf;
end generate clk_buf_if_top;
not_top : if (this_module_is_top_g = no) generate
clk_in_s <= clk_p;
end generate not_top;
freq_ce : entity work.frequency_trigger(rtl) -- frequency trigger instance
generic map(
div_factor_freqhigh_g => div_factor_freqhigh_c,
div_factor_freqlow_g => div_factor_freqlow_c
)
port map(
clk_in => clk_in_s,
freq_trig => freq_trig_s,
sw0 => sw0
);
counterampl : entity work.counter(rtl) -- counter instance
generic map(
cnt_value_g => design_setting_g.cntampl_value,
depth_g => design_setting_g.depth
)
port map (
clk_in => clk_in_s,
cnt_en => freq_trig_s,
cnt_out => ampl_cnt_s
);
sine : entity work.sine(rtl) -- digital sine instance
generic map(
depth_g => design_setting_g.depth,
width_g => design_setting_g.width
)
port map(
ampl_cnt => ampl_cnt_s,
clk_in => clk_in_s,
sine_out => sine_ampl_s
);
pwmmodule : entity work.pwm (rtl) -- pwm instance
generic map(
width_g => design_setting_g.width,
div_factor_freqhigh_g => div_factor_freqhigh_c / (2**design_setting_g.width),
div_factor_freqlow_g => div_factor_freqlow_c / (2**design_setting_g.width)
)
port map (
clk_in => clk_in_s,
sw0 => sw0,
sine_ampl => sine_ampl_s,
pwm_out => pwm_out
);
end;
8.3 Creating Test Bench
We will now create a test bench for Modulator module (modulator_tb.vhd).We will use the same steps as for creating frequency_trigger_rtl.vhd module, explained in Sub-chapter 2.3.1 Creating a Module Using an Text Editor.
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
use ieee.std_logic_unsigned.all;
use work.modulator_pkg.all;
entity modulator_tb is
generic(
this_module_is_top_g : module_is_top_t := yes;
-- If some module is top, it needs to implement the differential clk buffer,
-- otherwise this variable will be overwritten by a upper hierarchy layer
board_name_g : board_setting_t := kc705_c;
-- Parameter that specifies major characteristics of the board that will be used
-- to implement the modulator design
-- Possible choices: lx9_c, zedboard_c, ml605_c, kc705_c
-- Adjust the modulator_pkg.vhd file to add more
design_setting_g: design_setting_t := design_setting_c
-- User defined settings for the pwm design
);
end;
architecture tb of modulator_tb is
signal clk_p_s : std_logic := '1'; -- differential input clock signal
signal clk_n_p : std_logic := '0'; – differential input clock signal
signal sw0_s : std_logic := '1'; -- signal made for selecting frequency
signal pwm_s : std_logic := '0'; -- pulse width modulated signal
constant clock_period_c : time := 1000000000.0 / board_name_g.fclk * 1ns; -- period of input clock signal
begin
pwmmodulator : entity work.modulator -- modulator instance
generic map(
this_module_is_top_g => this_module_is_top_g, board_name_g => board_name_g, design_setting_g => design_setting_g
)
port map(
clk_p => clk_p_s,
clk_n => clk_n_s,
sw0 => sw0_s,
pwm_out => pwm_s
);
clk_p_s <= not (clk_p_s) after clock_period_c/2; -- generates input clock signal
clk_n_s <= not (clk_n_s) after clock_period_c/2; -- generates input clock signal
sw0_s <= '1', '0' after 25 us;
end;
8.4 Simulating
After you have entered the code for the input stimulus in order to perform simulation:
Illustration 8.1: Simulation Results
Note: All the information about creating the Modulator Module, generating its test bench and simulating the Modulator design, you can also find in the Lab 10: “Creating Modulator Module”.
8.5 Creating UCF File
The ISE software allows you to specify different types of constraints to help improve your design performance. Each type of constraint serves a different purpose and is recommended under different circumstances. Following are some of the most commonly used types of constraints:
Note: To learn more about UCF Constraints, please see Xilinx's “Constraints Guide” document.
Note: Information about the types of constraints and how to generate the UCF-File, you can also find in the Lab 11: “Creating UCF-File”.
There are two different ways of generating an UCF-File:
Creating UCF File using the PlanAhead-Floorplanner Wizard:
(to read more about PlanAhead Floorplanner, see Chapter 8.6 PlanAhead-Floorplanner)
Illustration 8.2: Select Source Type – Implementation Constraints File
Illustration 8.3: Summary dialog box
To perform I/O Pin Planning from the Project Navigator, double-click on the I/O Pin Planning (PlanAhead) – Pre-Synthesis (see Illustration 8.4), or select the Tools → PlanAhead → Pre-Synthesis - IO Pin Planning (PlanAhead) – Pre-Synthesis... command.
To perform I/O Pin Planning from the Project Navigator, double-click on the I/O Pin Planning (PlanAhead) – Post-Synthesis (see Illustration 8.4), or select the Tools → PlanAhead → I/O Pin Planning (PlanAhead) – Post-Synthesis... command.
Note: In this Tutorial we will use this option!
Illustration 8.3: User Constraints options
Illustration 8.4: PlanAhead tool environment
Illustration 8.5: I/O Ports tab
Illustration 8.6: I/O Port Properties window
NET "SYSCLK_P" LOC = "AD12" | IOSTANDARD = LVDS ;
NET "SYSCLK_N" LOC = "AD11" | IOSTANDARD = LVDS ;
NET "GPIO_DIP_SW0" LOC = "Y29" | IOSTANDARD = LVCMOS25 ;
Illustration 8.7: I/O Ports tab with assigned pin locations and I/O standards
Illustration 8.8: Package view – clk_n pin location
Illustration 8.9: Save Constraints option
Illustration 8.10: modulator_rtl.ucf constraints file in Hierarchy window
Illustration 8.11: modulator_rtl.ucf constraints file
Illustration 8.13: Timing Constraints in the PlanAhead Constraints window
Creating a UCF File using a Text Editor:
The another way to create a UCF constraints file is using an text editor. The steps will be similar like in the Sub-chapter 2.3.1 Creating a Module Using an Text Editor.
Here are the steps for creating XDC file using an text editor:
ucf constraints file:
NET "clk_p" LOC = "AD12" | IOSTANDARD = LVDS;
NET "clk_n" LOC = "AD11" | IOSTANDARD = LVDS;
NET "sw0" LOC = "Y29" | IOSTANDARD = LVCMOS25;
NET "pwm_out" LOC = "AB8" | IOSTANDARD = LVCMOS15 | SLEW = SLOW | DRIVE = 12;
NET “clk_p” TNM_NET = clk_p;
TIMESPEC TS_clk_p = PERIOD “clk_in” 5 ns HIGH 50%;
First four lines are the Placement Constraints and the last two lines are the Timing Constraints.
Placement constraints we will find in the data sheet for the Kintex-7 (KC705) development board depending to which pin location we would like to connect our signals. In our case it will be:
NET "SYSCLK_P" LOC = "AD12" | IOSTANDARD = LVDS ;
NET "SYSCLK_N" LOC = "AD11" | IOSTANDARD = LVDS ;
NET "GPIO_DIP_SW0" LOC = "Y29" | IOSTANDARD = LVCMOS25 ;
NET "GPIO_LED_0_LS" LOC = "AB8" | IOSTANDARD = LVCMOS15 | SLEW = SLOW | DRIVE = 12 ;
Timing Constraints we can create on two ways:
Create Timing Constraints with the “Create Timing Constraints” option from the Project Navigator:
Illustration 8.14: Create Timing Constraints command
Illustration 8.15: Timing Constraints Editor
Illustration 8.16: Unconstrained Clocks window
Illustration 8.17: Clock Period dialog box
Illustration 8.18: Create Timing Constraints for Clock Domains (PERIOD) window
Now, we made both placement and timing constraints. To see all the constraints that we made, do the following:
Illustration 8.19: Edit Constraints (Text) command
Illustration 8.20: UCF file with defined placement and timing constraints
8.6 PlanAhead-Floorplanner
Floorplanner™ is an interactive graphical tool that you can use to improve the performance of your design by constraining critical paths or adjusting the automatic placement. Floorplanner performs the following functions on your designs:
The graphical user interface includes pull-down menus and toolbar buttons that contain the necessary commands for changing the design hierarchy, floorplanning, and performing design rule checks. Dialog boxes allow you to set parameters and options for command execution.
Note: For more informations and instructions please read in the Floorplanner Help.
8.7 Implementation/Translation
The ISE implementation process includes all steps necessary to place and route the netlist onto the FPGA device resources, while meeting the design's logical, physical and timing constraints. The ISE implementation process includes logical and physical transformations of the design and it will be done in tree steps: translation, map and place&route.
8.7.1 Description
The Translate process merges all of the input netlists and design constraints and outputs a Xilinx Native Generic Database (NGD) file, which describes the logical design reduced to Xilinx primitives.
8.7.2 Translate
To run the translation step, please do the following:
Illustration 8.21: Translate command
Note: Information about the Implementation/Translation step in the Design Implementation process, you can also find in the Lab 12: “Design Implementation”.
8.7.3 Translation Report
Translation Report displays NGDBUILD Design Results Summary which includes warning and error messages from the translation process, such as:
– Missing or untranslatable hierarchical blocks
– Invalid or incomplete timing constraints
– Output contention, loadless outputs, and sourceless inputs
To see Translation Report:
Illustration 8.22: Design Summary/Reports option
Illustration 8.23: Detailed Reports – Translation Report
Illustration 8.24: Translation Report
8.7.4 Generate Post-Translate Simulation Model
To Generate Post-Translate Simulation Model, follow these steps:
Illustration 8.25: Process Properties option
Note: Verify that Advanced option is enabled in the Property display level field, see Illustration 8.26.
Illustration 8.26: Process Properties – Simulation Model Properties dialog box
Illustration 8.27: Generate Post-Translate Simulation Model command
8.8 Implementation/Map
8.8.1 Description
The Map process maps the design specified by an NGD file into available resources on the target FPGA device, such as Flip-Flops, CLBs, IOBs... As a result is an Native Circuit Description (NCD) file.
8.8.2 Mapping
To run the mapping step, please do the following:
Illustration 8.28: Map command
Note: Information about the Implementation/Map step in the Design Implementation process, you can also find in the Lab 12: “Design Implementation”.
8.8.3 Map Report
Map Report shows Design Information and Design Summary. In the Design Summary, you can find number of errors and warnings and how many resources (Flip-Flops, LUTs, Slices, RAMs, IOBs,...) are used by the mapped design, see Illustration 8.29
Design Information
------------------
Command Line : map -intstyle ise -p xc7k325t-ffg900-2 -w -logic_opt off -ol
high -t 1 -xt 0 -register_duplication off -r 4 -mt off -ir off -pr off -lc off
-power off -o modulator_map.ncd modulator.ngd modulator.pcf
Target Device : xc7k325t
Target Package : ffg900
Target Speed : -2
Mapper Version : kintex7 -- $Revision: 1.55 $
Mapped Date : Tue Jun 17 20:10:14 2014
Design Summary
--------------
Number of errors: 0
Number of warnings: 15
Slice Logic Utilization:
Number of Slice Registers: 109 out of 407,600 1%
Number used as Flip Flops: 109
Number used as Latches: 0
Number used as Latch-thrus: 0
Number used as AND/OR logics: 0
Number of Slice LUTs: 164 out of 203,800 1%
Number used as logic: 160 out of 203,800 1%
Number using O6 output only: 36
Number using O5 output only: 76
Number using O5 and O6: 48
Number used as ROM: 0
Number used as Memory: 0 out of 64,000 0%
Number used exclusively as route-thrus: 4
Number with same-slice register load: 0
Number with same-slice carry load: 4
Number with other load: 0
Slice Logic Distribution:
Number of occupied Slices: 55 out of 50,950 1%
Number of LUT Flip Flop pairs used: 175
Number with an unused Flip Flop: 104 out of 175 59%
Number with an unused LUT: 11 out of 175 6%
Number of fully used LUT-FF pairs: 60 out of 175 34%
Number of unique control sets: 5
Number of slice register sites lost
to control set restrictions: 11 out of 407,600 1%
A LUT Flip Flop pair for this architecture represents one LUT paired with
one Flip Flop within a slice. A control set is a unique combination of
clock, reset, set, and enable signals for a registered element.
The Slice Logic Distribution report is not meaningful if the design is
over-mapped for a non-slice resource or if Placement fails.
OVERMAPPING of BRAM resources should be ignored if the design is
over-mapped for a non-BRAM resource or if placement fails.
IO Utilization:
Number of bonded IOBs: 17 out of 500 3%
Number of LOCed IOBs: 4 out of 17 23%
Specific Feature Utilization:
Number of RAMB36E1/FIFO36E1s: 0 out of 445 0%
Number of RAMB18E1/FIFO18E1s: 1 out of 890 1%
Number using RAMB18E1 only: 1
Number using FIFO18E1 only: 0
Number of BUFG/BUFGCTRLs: 1 out of 32 3%
Number used as BUFGs: 1
Number used as BUFGCTRLs: 0
Number of IDELAYE2/IDELAYE2_FINEDELAYs: 0 out of 500 0%
Number of ILOGICE2/ILOGICE3/ISERDESE2s: 0 out of 500 0%
Number of ODELAYE2/ODELAYE2_FINEDELAYs: 0 out of 150 0%
Number of OLOGICE2/OLOGICE3/OSERDESE2s: 0 out of 500 0%
Number of PHASER_IN/PHASER_IN_PHYs: 0 out of 40 0%
Number of PHASER_OUT/PHASER_OUT_PHYs: 0 out of 40 0%
Number of BSCANs: 0 out of 4 0%
Number of BUFHCEs: 0 out of 168 0%
Number of BUFRs: 0 out of 40 0%
Number of CAPTUREs: 0 out of 1 0%
Number of DNA_PORTs: 0 out of 1 0%
Number of DSP48E1s: 0 out of 840 0%
Number of EFUSE_USRs: 0 out of 1 0%
Number of FRAME_ECCs: 0 out of 1 0%
Number of GTXE2_CHANNELs: 0 out of 16 0%
Number of GTXE2_COMMONs: 0 out of 4 0%
Number of IBUFDS_GTE2s: 0 out of 8 0%
Number of ICAPs: 0 out of 2 0%
Number of IDELAYCTRLs: 0 out of 10 0%
Number of IN_FIFOs: 0 out of 40 0%
Number of MMCME2_ADVs: 0 out of 10 0%
Number of OUT_FIFOs: 0 out of 40 0%
Number of PCIE_2_1s: 0 out of 1 0%
Number of PHASER_REFs: 0 out of 10 0%
Number of PHY_CONTROLs: 0 out of 10 0%
Number of PLLE2_ADVs: 0 out of 10 0%
Number of STARTUPs: 0 out of 1 0%
Number of XADCs: 0 out of 1 0%
Average Fanout of Non-Clock Nets: 2.38
Peak Memory Usage: 928 MB
Total REAL time to MAP completion: 1 mins 17 secs
Total CPU time to MAP completion: 1 mins 9 secs
Illustration 8.29: Design Information and Design Summary
To see Map Report:
- In the ISE Project Navigator, select Project → Design Summary/Reports option from the main menu
- In the Design Summary window, select Detailed Reports → Map Report, see Illustration 8.30
Illustration 8.30: Detailed Reports – Map Report
In the Map Report / Design Summary, you will also find:
Section 1 - Errors
Section 2 - Warnings
Section 3 - Informational
Section 4 - Removed Logic Summary
Section 5 - Removed Logic
Section 6 - IOB Properties
Section 7 - RPMs
Section 8 - Guide Report
Section 9 - Area Group and Partition Summary
Section 10 - Timing Report
Section 11 - Configuration String Information
Section 12 - Control Set Information
Section 13 - Utilization by Hierarchy
Removed Logic - Describes in detail all logic (design components and nets) removed from the input NGD file when the design is mapped.
Section 4 - Removed Logic Summary
---------------------------------
2 block(s) optimized away
Section 5 - Removed Logic
-------------------------
Optimized Block(s):
TYPE BLOCK
GND XST_GND
VCC XST_VCC
To enable printing of redundant blocks removed and signals merged, set the
detailed map report option and rerun map.
Illustration 8.31: Removed Logic Summary and Removed Logic
IOB Properties - Lists each IOB to which the user has supplied constraints along with the applicable constraints, see Illustration 8.32
Section 6 - IOB Properties
--------------------------
+---------------------------------------------------------------------------------------------------------------------------------------------------------+
| IOB Name | Type | Direction | IO Standard | Diff | Drive | Slew | Reg (s) | Resistor | IOB |
| | | | | Term | Strength | Rate | | | Delay |
+---------------------------------------------------------------------------------------------------------------------------------------------------------+
| clk_n | IOB18 | INPUT | LVDS | FALSE | | | | | |
| clk_p | IOB18 | INPUT | LVDS | FALSE | | | | | |
| debug_data<0> | IOB | OUTPUT | LVCMOS18 | | 12 | SLOW | | | |
| debug_data<1> | IOB | OUTPUT | LVCMOS18 | | 12 | SLOW | | | |
| debug_data<2> | IOB | OUTPUT | LVCMOS18 | | 12 | SLOW | | | |
| debug_data<3> | IOB | OUTPUT | LVCMOS18 | | 12 | SLOW | | | |
| debug_data<4> | IOB | OUTPUT | LVCMOS18 | | 12 | SLOW | | | |
| debug_data<5> | IOB | OUTPUT | LVCMOS18 | | 12 | SLOW | | | |
| debug_data<6> | IOB | OUTPUT | LVCMOS18 | | 12 | SLOW | | | |
| debug_data<7> | IOB | OUTPUT | LVCMOS18 | | 12 | SLOW | | | |
| debug_data<8> | IOB | OUTPUT | LVCMOS18 | | 12 | SLOW | | | |
| debug_data<9> | IOB | OUTPUT | LVCMOS18 | | 12 | SLOW | | | |
| debug_data<10> | IOB | OUTPUT | LVCMOS18 | | 12 | SLOW | | | |
| debug_data<11> | IOB | OUTPUT | LVCMOS18 | | 12 | SLOW | | | |
| debug_data<12> | IOB | OUTPUT | LVCMOS18 | | 12 | SLOW | | | |
| pwm_out | IOB | OUTPUT | LVCMOS15 | | 12 | SLOW | | | |
| sw0 | IOB33 | INPUT | LVCMOS25 | | | | | | |
+---------------------------------------------------------------------------------------------------------------------------------------------------------+
Illustration 8.32: IOB Properties
Timing Report - This section, produced with Perform Timing driven packing & placement option, shows information on timing constraints considered during the MAP run.
8.8.4 Generate Post-Map Static Timing
You can optionally generate a post-map static timing report for your design. A post-map timing report lists the signal path delays in your design, derived from the design logic. This report can be useful in evaluating timing performance of the logic paths, particularly if your design does not meet timing requirements.
Although route delays are not accounted for in this report, the logic delays can provide valuable information about the design, which can help identify problems with logic path timing. You can eliminate potential problems before investing time in examining routing delays. To eliminate problems, you may choose to redesign the logic paths to use fewer levels of logic, tag the paths for specialized routing resources, move to a faster device, or allocate more time for the path.
To Generate Post-Map Static Timing, follow these steps:
- In the Processes window, expand Implement Design and then expand Map
-
Right-click on the Generate Post-Map Static Timing option, select Process Properties and make the appropriate selections for the report details
-
At the end, double-click on the Generate Post-Map Static Timing command, see Illustration 8.33
Illustration 8.33: Generate Post-Map Static Timing command
After running this process, you can run the Analyze Post-Map Static Timing process to open the static timing report and your design NCD file for further timing analysis in Timing Analyzer.
You can use Timing Analyzer to perform static timing analysis on mapped, placed only or placed and routed FPGA designs.
To run Analyze Post-Map Static Timing process, please do the following:
-
In the Processes window, expand Implement Design, then expand Map and at the end expand Generate Post-Map Static Timing option, see Illustration 8.34
-
Double-click on the Analyze post-Map Static Timing command, see Illustration 8.34
-
In the Timing Report Tips dialog box, just click OK
Note: Timing Report Tips dialog box gives you an information how you can view a timing report, in either html or textual format.
Illustration 8.34: Analyze Post-Map Static Timing command
After double-clicking the Analyze Post-Map Static Timing command, the Timing Analyzer window will show up, see Illustration 8.35.
Timing Analyzer:
- reports path delay and the slack based upon the specified timing requirements.
- analyze critical paths in a circuit,
- the cycle time of the circuit,
- quick analysis of the effect speed grades, voltage, and temperature prorating have on the same design
- set up and hold checks (works with synchronous systems comprising synchronous elements and combinatorial logic)
- creates timing analysis reports based on timing constraints or user-specified paths within the program
- uses Timing Wizard for all FPGA analysis functions, ensuring consistency with PAR
Illustration 8.35: Timing Analyzer window
Note: For more information and instructions please read in the Timing Analyzer Help.
8.8.5 Manually Place & Route (FPGA Editor)
You can use FPGA Editor to manually place and route critical components of your design before running the Place & Route process. After running the Map process, the output design is a Native Circuit Description (NCD) file that physically represents the design mapped to components of the Xilinx FPGA, such as CLBs and IOs. The FPGA Editor requires an NCD file as input.
Note: Manually routing sections of the design is not recommended unless absolutely necessary.
FPGA Editor launches and displays the routed design NCD file. FPGA Editor reads from and writes to a physical constraints file (PCF) as follows:
-
When you create a constraint in FPGA Editor , the constraint is written to the PCF file whenever you save your design.
-
When you delete a constraint in FPGA Editor and then save the design file, the constraint is commented out in the PCF file and is not removed.
Note: For more information on using FPGA Editor, see the FPGA Editor Help.
To Manually Place and Route a design:
-
In the Processes window, expand Implement Design and then expand Map
-
Double-click on the Manually Place & Route (FPGA Editor) command, see Illustration 8.36
Illustration 8.36: Manually Place&Route (FPGA Editor) command
The following is a list of a few functions you can perform on your design in the FPGA Editor.
- Place and route critical components before running the automatic place and route tools.
- Finish placement and routing if the routing program does not completely route your design.
- Add probes to your design to examine the signal states of the targeted device. Probes are used to route the value of internal nets to an IOB for analysis during the debugging of a device.
- Cross-probe your design with Timing Analyzer.
- Run the BitGen program and download the resulting BIT file to the targeted device.
- View and change the nets connected to the capture units of an ILA core in your design.
- Create an entire design by hand (advanced users)
8.8.6 Generate Post-Map Simulation Model
You can generate a simulation model after mapping your design. For this process, NetGen converts the output of the Map process (an NCD file) to a post-map simulation model (a structural SIMPRIM-based VHDL or Verilog file) and a standard delay format (SDF) file. The SDF file contains estimates of the timing delays in your design. The simulation model and SDF files are then used in the Simulate Post-Map Model process to verify that functionality is correct at this stage of implementation.
To Generate Post-Map Simulation Model:
-
In the Process window, expand Implement Design and then expand Map
-
Right-click on the Generate Post-Map Static Timing option, select Process Properties and make the appropriate selections for the report details
- At the end, double-click on the Generate Post-Map Simulation Model command, see Illustration 8.37
Illustration 8.37: Generate Post-Map Simulation Model command
8.9 Implementation/Place&Route
8.9.1 Description
The Place and Route process takes a mapped Native Circuit Description (NCD) file, places and routes the design, and produces an NCD file that is used as input for bitstream generation.
8.9.2 Place & Route
To run the place&route step, please do the following:
- In the Hierarchy window, right-click on the place&route module (modulator_rtl) and select Set as Top Module, if it is not already set
- In the Hierarchy window, select the place&route module (modulator_rtl)
- In the Processes window, expand Implement Design and double-click on the Place&Route command, see Illustration 8.38
Illustration 8.38: Place&Route command
Note: Information about the Implementation/Place&Route step in the Design Implementation process, you can also find in the Lab 12: “Design Implementation”.
8.9.3 Place & Route Report
The Place&Route report lists which resources in the device were used to implement the design, lists all clocks used in the design, and details design performance against timing constraints.
To see Place & Route Report:
- In the ISE Project Navigator, select Project → Design Summary/Reports option from the main menu
- In the Design Summary window, select Detailed Reports → Place and Route Report, see Illustration 8.39
Illustration 8.39: Detailed Reports – Place and Route Report
In the Place and Route Report, you can find:
Design Summary Report – which provides a breakdown of the resources in the design and includes the Device Utilization Summary, see Illustration 8.40
Device Utilization Summary:
Slice Logic Utilization:
Number of Slice Registers: 109 out of 407,600 1%
Number used as Flip Flops: 109
Number used as Latches: 0
Number used as Latch-thrus: 0
Number used as AND/OR logics: 0
Number of Slice LUTs: 164 out of 203,800 1%
Number used as logic: 160 out of 203,800 1%
Number using O6 output only: 36
Number using O5 output only: 76
Number using O5 and O6: 48
Number used as ROM: 0
Number used as Memory: 0 out of 64,000 0%
Number used exclusively as route-thrus: 4
Number with same-slice register load: 0
Number with same-slice carry load: 4
Number with other load: 0
Slice Logic Distribution:
Number of occupied Slices: 55 out of 50,950 1%
Number of LUT Flip Flop pairs used: 175
Number with an unused Flip Flop: 104 out of 175 59%
Number with an unused LUT: 11 out of 175 6%
Number of fully used LUT-FF pairs: 60 out of 175 34%
Number of slice register sites lost
to control set restrictions: 0 out of 407,600 0%
A LUT Flip Flop pair for this architecture represents one LUT paired with
one Flip Flop within a slice. A control set is a unique combination of
clock, reset, set, and enable signals for a registered element.
The Slice Logic Distribution report is not meaningful if the design is
over-mapped for a non-slice resource or if Placement fails.
OVERMAPPING of BRAM resources should be ignored if the design is
over-mapped for a non-BRAM resource or if placement fails.
IO Utilization:
Number of bonded IOBs: 17 out of 500 3%
Number of LOCed IOBs: 4 out of 17 23%
Specific Feature Utilization:
Number of RAMB36E1/FIFO36E1s: 0 out of 445 0%
Number of RAMB18E1/FIFO18E1s: 1 out of 890 1%
Number using RAMB18E1 only: 1
Number using FIFO18E1 only: 0
Number of BUFG/BUFGCTRLs: 1 out of 32 3%
Number used as BUFGs: 1
Number used as BUFGCTRLs: 0
Number of IDELAYE2/IDELAYE2_FINEDELAYs: 0 out of 500 0%
Number of ILOGICE2/ILOGICE3/ISERDESE2s: 0 out of 500 0%
Number of ODELAYE2/ODELAYE2_FINEDELAYs: 0 out of 150 0%
Number of OLOGICE2/OLOGICE3/OSERDESE2s: 0 out of 500 0%
Number of PHASER_IN/PHASER_IN_PHYs: 0 out of 40 0%
Number of PHASER_OUT/PHASER_OUT_PHYs: 0 out of 40 0%
Number of BSCANs: 0 out of 4 0%
Number of BUFHCEs: 0 out of 168 0%
Number of BUFRs: 0 out of 40 0%
Number of CAPTUREs: 0 out of 1 0%
Number of DNA_PORTs: 0 out of 1 0%
Number of DSP48E1s: 0 out of 840 0%
Number of EFUSE_USRs: 0 out of 1 0%
Number of FRAME_ECCs: 0 out of 1 0%
Number of GTXE2_CHANNELs: 0 out of 16 0%
Number of GTXE2_COMMONs: 0 out of 4 0%
Number of IBUFDS_GTE2s: 0 out of 8 0%
Number of ICAPs: 0 out of 2 0%
Number of IDELAYCTRLs: 0 out of 10 0%
Number of IN_FIFOs: 0 out of 40 0%
Number of MMCME2_ADVs: 0 out of 10 0%
Number of OUT_FIFOs: 0 out of 40 0%
Number of PCIE_2_1s: 0 out of 1 0%
Number of PHASER_REFs: 0 out of 10 0%
Number of PHY_CONTROLs: 0 out of 10 0%
Number of PLLE2_ADVs: 0 out of 10 0%
Number of STARTUPs: 0 out of 1 0%
Number of XADCs: 0 out of 1 0%
Illustration 8.40: Design Summary Report
Clock Report - Lists all clocks in the design and provides information on the routing resources, number of fanout, maximum net skew for each clock, and the maximum delay. The locked column in the clock table indicates whether the clock driver (BUFGMUX) is assigned to a particular site or left floating, see Illustration 8.41.
**************************
Generating Clock Report
**************************
+---------------------+--------------+------+------+------------+-------------+
| Clock Net | Resource |Locked|Fanout|Net Skew(ns)|Max Delay(ns)|
+---------------------+--------------+------+------+------------+-------------+
| clk_in_s_BUFG | BUFGCTRL_X0Y0| No | 22 | 0.138 | 1.525 |
+---------------------+--------------+------+------+------------+-------------+
Illustration 8.41: Clock Report
Delay Summary Report - Summarizes the connection and pin delays for the design.
Timing Score - Lists information on timing constraints contained in the input PCF, including how many timing constraints were met, see Illustration 8.42.
Timing Score: 0 (Setup: 0, Hold: 0, Component Switching Limit: 0)
Asterisk (*) preceding a constraint indicates it was not met.
This may be due to a setup or hold violation.
----------------------------------------------------------------------------------------------------------
Constraint | Check | Worst Case | Best Case | Timing | Timing
| | Slack | Achievable | Errors | Score
----------------------------------------------------------------------------------------------------------
TS_clk_p = PERIOD TIMEGRP "clk_p" 5 ns HI | SETUP | 1.548ns| 3.452ns| 0| 0
GH 50% | HOLD | 0.124ns| | 0| 0
----------------------------------------------------------------------------------------------------------
All constraints were met.
Illustration 8.42: Timing Score
8.9.4 Generate Post-Place & Route Static Timing
After placing and routing your design, this process generates a post-place and route static timing report. A post-place and route static timing report incorporates timing delay information to provide a comprehensive timing summary of your design. You can customize the report contents to help you determine how well your design has met the timing requirements.
If a placed and routed design has met all of your timing constraints, then you can create configuration data. If you identify problems in the timing report, you can redesign the logic paths to use fewer levels of logic, tag the paths for a specialized routing resources, move to a faster device, or allocate more time for the paths.
You can generate one of two report types:
-
Error report, which lists timing errors and associated net and path delay information.
-
Verbose report, which lists delay information for all nets and paths.
To Generate Post-Place & Route Static Timing, follow these steps:
-
In the Processes window, expand Implement Design and then expand Place & Route
-
Right-click on the Generate Post-Place & Route Static Timing option, select Process Properties and make the appropriate selections for the report details
-
At the end, double-clock on the Generate Post-Place & Route Static Timing command, see Illustration 8.43
Illustration 8.43: Generate Post-Place & Route Static Timing command
You can open the static timing report and the NCD file for further timing analysis in Timing Analyzer.
To Analyze Post-Place & Route Static Timing:
-
In the Processes window, expand Implement Design and then expand Place & Route option
-
After that, expand Generate Post-Place & Route Static Timing option
-
At the end, double-click on the Analyze Post-Place & Route Static Timing command, see Illustration 8.44, and the Timing Analyzer will pop-up, see Illustration 8.45
Illustration 8.44: Analyze Post-Place & Route Static Timing command
Illustration 8.45: Timing Analyzer
8.9.5 Analyze Timing / Floorplan Design (PlanAhead)
To read more about Plan-Ahead-Floorplanner, please see Chapter 8.6. PlanAhead-Floorplanner.
To Analize Timing / Floorplan Design (PlanAhead):
-
In the Processes window, expand Implement Design and then expand Place & Route option
-
Double-click on the Analyze Timing / Floorplan Design (PlanAhead) command, see Illustration 8.46
Illustration 8.46: Analyze Timing / Floorplan Design (PlanAhead) command
After ISE tool analyses timing of your design, it will automatically open the PlanAhead tool and show the timing analysis data, as it is show on the Illustration 8.47
Illustration 8.47: Timing results of Modulator design
8.9.6 View/Edit Routed Design (FPGA Editor)
You can view or edit your routed design in FPGA Editor to fine tune your design or to improve the performance of the automatic place and route tools. After placing and routing your design, the Native Circuit Description (NCD) output file can be viewed or edited in FPGA Editor.
To read more about FPGA Editor, please see Sub-chapter 8.8.5 Manually Place & Route (FPGA Editor).
To View/Edit Routed Design (FPGA Editor):
-
In the Processes window, expand Implement Design and then expand Place & Route option
-
Double-click on the View/Edit Routed Design (FPGA Editor) command, see Illustration 8.48, and the Xilinx FPGA Editor will automatically pop-up, see Illustration 8.49
Using the Xilinx FPGA Editor you can inspect placed and routed design to see the actual positions of every FPGA physical component used to implement your design as well as every existing connection between FPGA physical components. Using the Xilinx FPGA Editor you can even make manual modifications to the placed and routed design, but this is not recommended in most cases.
Illustration 8.48: View/Edit Routed Design (FPGA Editor)
Illustration 8.49: Xilinx FPGA Editor
8.9.7 Analyze Power Distribution (XPower Analyzer)
Use the XPower Analyzer interactive graphic tool to perform the following functions on your design:
- Analyze Power consumption for Xilinx FPGA and CPLD devices
- Report thermal information (junction temperature)
- Report static and dynamic power for the different voltage supplies
- Validate the accuracy of the estimation given in Xilinx Power Estimator
- Analyze power data supplied by hierarchical power reporting
- Examine the data for areas where power can be reduced
- Generate design power consumption reports and add them to the overall project documentation
To open XPower Analizer:
-
In the Processes window, expand Implement Design and then expand Place & Route option
-
Double-click on the Analyze Power Distribution (XPower Analizer) command, see Illustration 8.48 and the XPower Analyzer interactive graphic tool will automatically pop-up, see Illustration 8.50
Illustration 8.50: Analyze Power Distribution (XPower Analyzer) command
Illustration 8.51: Xilinx XPower Analyzer graphical tool
8.9.8 Generate Text Power Report
You can optionally generate text power report for your entire design or for one module in your design. Text power report provides measurements about the usage of voltage and other power resources.
To Generate Text Power Report:
-
In the Processes window, expand Implement Design and then expand Place & Route option
-
Double-click on the Generate Text Power Report command, see Illustration 8.52, wait for some time, and in the ISE Console window you will find generated text power report for your entire design. How text power report looks like, you can see on the Illustration 8.53.
Illustration 8.52: Generate Text Power Report command
Illustration 8.53: Text Power Report for entire Modulator design
8.9.9 Generate Post-Place & Route Simulation Model
You can generate a simulation model after placing and routing your design. For this process, NetGen converts the Place & Route process results (an NCD file) to the simulation model (a structural SIMPRIM-based VHDL or Verilog file) and a standard delay format (SDF) file. The SDF file contains true timing delay information for your design.
The simulation model file and SDF file can be used to verify the functionality and timing of your design at this point in the design flow by using the Simulate Post-Place and Route Model process.
To Generate Post-Place & Route Simulation Model:
-
In the Processes window, expand Implement Design and then expand Place & Route command
-
Right-click on the Generate Post-Map Static Timing option, select Process Properties and make the appropriate selections for the report details
-
At the end, double-click on the Generate Post-Place & Route Simulation Model command, see Illustration 8.54
Illustration 8.54: Generate Post-Place & Route Simulation Model command
-
After generating Post-Place & Route Simulation Model, we must prepare our modulator_tb.vhd test bench for the timing simulation.
Remove all the generics from the modulator instance (pwmmodulator) as it is shown in the code bellow, and save the new testbench file as modulator_timesim_tb.vhd.
This step is necessary because during the Synthesis process all the generics are being replaced by the values supplied by the designer. This means that the design that will be implemented will have no generics. Therefore, when we generate a Post-Place & Route Simulation Model it can't contain any generics since they don't exist any more.
Modulator VHDL model for the timing simulation:
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
use ieee.std_logic_unsigned.all;
use work.modulator_pkg.all;
entity modulator_timesim_tb is
generic(
this_module_is_top_g : module_is_top_t := yes;
-- If some module is top, it needs to implement the differential clk buffer,
-- otherwise this variable will be overwritten by a upper hierarchy layer
board_name_g : board_setting_t := kc705_c;
-- Parameter that specifies major characteristics of the board that will be used
-- to implement the modulator design
-- Possible choices: lx9_c, zedboard_c, ml605_c, kc705_c
-- Adjust the modulator_pkg.vhd file to add more
design_setting_g: design_setting_t := design_setting_c
-- User defined settings for the pwm design
);
end;
architecture tb of modulator_timesim_tb is
signal clk_p_s : std_logic := '1'; -- differential input clock signal
signal clk_n_s : std_logic := '0'; -- differential input clock signal
signal sw0_s : std_logic := '1'; -- signal made for selecting frequency
signal pwm_s : std_logic := '0'; -- pulse width modulated signal
constant clock_period_c : time := 1000000000.0 / board_name_g.fclk * 1ns; -- period of input clock signal
begin
pwmmodulator : entity work.modulator – modulator instance
port map(
clk_p => clk_p_s,
clk_n => clk_n_s,
sw0 => sw0_s,
pwm_out => pwm_s
);
clk_p_s <= not (clk_p_s) after clock_period_c/2; -- generates input clock signal
clk_n_s <= not (clk_n_s) after clock_period_c/2; -- generates input clock signal
sw0_s <= '1', '0' after 25 us;
end;
-
After we have created a new test bench file (modulator_timesim_tb.vhd), we must include it in our design:
- In the Project Navigator, select Project → Add Source... option
- In the Add Sources window, choose modulator_timesim_tb.vhd and click Open
- In the Adding Source Files... window, select Simulation in the Association drop-down many (if it is not automatically selected) and click OK, see Illustration 8.55
Illustration 8.55: Adding Source Files window
-
After we added modulator_timesim_tb.vhd test bench file into our design, we can now start our timing simulation.
-
Choose Post-Route simulation in the Design View drop-down list
-
Select testbench_name (modulator_timesim_tb.vhd) in the Hierarchy window
-
In the Processes window, expand ISim Simulator and double-click on the Post-Place & Route Check Syntax command, see Illustration 8.56
-
At the end, double-click on the Simulate Post-Place & Route Model command, see Illustration 8.56
Illustration 8.56: Simulate Post-Place & Route Model command
Note: If your Project Navigator notify an error that compiler cannot find package (modulator_pkg.vhd) in library <work>, that means that ISim simulator has not included package automatically. To correct this, you must create a custom project file that includes modulator_pkg.vhd. Here are the steps to make this happen:
-
- Edit the <testbench>_par.prj file that can be found in your project directory
- Add in the file that you want. In our case it will be modulator_pkg.vhd, and it should look like the code bellow:
vhdl work "modulator_pkg.vhd"
vhdl work "netgen/par/modulator_timesim.vhd"
vhdl work "modulator_timesim_tb.vhd"
-
- Save this file with a new name, although use the same extension
- Then, turn back in the Project Navigator and select Post-Route simulation in the Design View drop-down list
- Right-click on the Simulate Post-Place & Route Model and choose Process Properties... option, see Illustration 8.57
Illustration 8.57: Process Properties option
-
- In the Process Properties – ISE Properties window, enable Use Custom Project File option and in the Custom Project Filename field, choose in the box beside, the newly created project file and click OK, see Illustration 8.58
Illustration 8.58: Process Properties – ISE Properties window
-
Note: Now each time you run your timing simulation, you will have this file compiled correctly.
- After all these modifications, repeat steps 6 - 9
- Simulate your design for 200 ms (see Chapter 2.5 Simulating (with ISim) – step 12.)
- Assuming no errors, your simulation result should look similar to Illustration 8.59
Illustration 8.59: Timing Simulation Result
As you can see the results of timing simulation (waveform of the pwm_s signal) look identical to the results of functional simulation. This means that the desired functionality is preserved after all implementation steps have been performed. What is identical is the desired functionality (the shape of the pwm_s signal), but the timing properties of the pwm_s signal simulated using functional and timing simulation are significantly different, as can be seen from the following Illustrations (8.60 and 8.61).
Illustration 8.60: Functional Simulation Result
Illustration 8.61: Timing Simulation Results (with signal delays)
Illustration 8.61 shows how big is the pwm_s signal delay related to the rising edge of the input clock signal (clk_p_s). This signal delay is illustrated with two markers (yellow and white) and it amounts 4.783 ns.
Note: You can see that timing simulation lasts much longer than functional simulations. This is the reason why timing simulation is not often used in practice.
8.9.10 Generate IBIS Model
You can generate an Input Output Buffer Information Specification (IBIS) file that contains a pin list and models that are unique to your design. IBIS is a device modelling standard that allows for the development of behavioral models used to describe the signal behavior of device I/Os, while preserving proprietary circuit information.
The IBIS models can be used for the following:
- To model best and worst case models by using min, max current with the proper min, max ramp rates.
- To simulate and predict electrical performance by providing I/V and V/T characteristics of the I/Os.
The IBIS Writer tool, the tool that generates the model, requires a design source file as input:
-
For FPGA designs, the design source is a physical description of the design in a Native Circuit Description (NCD) file with an .ncd file extension.
-
For CPLD designs, the input is produced by the CPLD fitter tools and has a .pnx file extension.
To Generate IBIS Model:
-
Select Implementation in the Design View
-
In the Processes window, expand Implement Design and then expand Place & Route option
-
Right-click on the Generate IBIS Model and choose Process Properties option
-
In the Process Properties – IBIS Model Generation Properties window make the appropriate selections (verify that the Advanced Property Display Level is enabled), see Illustration 8.62
Illustration 8.62: Process Properties - IBIS Model Generation Properties window
-
At the end, double-click on the Generate IBIS Model command, see Illustration 8.63
Illustration 8.63: Generate IBIS Model command
After running this process, you can do either of the following:
-
View the generated IBIS model
-
Read the IBIS model file into a signal integrity simulation tool for further simulation and analysis.
To View IBIS Model:
-
In the Processes window, expand Implement Design and then expand Place & Route option
-
After that, expand Generate IBIS Model option
-
At the end, double-click on the View IBIS Model command, see Illustration 8.64
Illustration 8.64: View IBIS Model command
Note: You may have a problem with generating IBIS model, because BISWriter doesn't provide support for Kintex-7 device!
8.9.11 Back-annotate Pin Locations
You can run the Back-annotate Pin Locations process after you implement your design. The Back-annotate Pin Locations process runs the PIN2UCF program which back-annotates pin locking constraints from a successfully placed and routed FPGA design to a User Constraints File (UCF). This process extracts pin locations and logical pad names from the NCD file and writes this information to an existing UCF. If a UCF does not exist in your project, a new file is created.
Note: By default, PIN2UCF does not write conflicting constraints to a UCF. If user-specified constraints are exact matches of PIN2UCF generated constraints, a pound sign (#) is added in front of all matching user-specified location constraint statements. If PIN2UCF discovers conflicting constraints, it writes this information to the pinlock.rpt report file.
To Back-annotate Pin Locations:
-
In the Processes window, expand Implement Design and then expand Place & Route option
-
Double-click on the Back-annotate Pin Locations command, see Illustration 8.65
Illustration 8.65: Back-annotate Pin Locations command
After running this process, you can perform any of the following:
-
View the back-annotate pin report
-
Generate Post-Place & Route Static Timing
-
Run Generate Programming File
To View Locked Pin Constraints:
-
In the Processes window, expand Implement Design and then expand Place & Route option
-
After that, expand Back-annotate Pin Locations option
-
At the end, double-click on the View Locked Pin Constraints command, see Illustration 8.66 and ISE will automatically open modulator.lpc file, where you will find yours locked pin constraints, see Illustration 8.67
Illustration 8.66: View Locked Pin Constraints command
Illustration 8.67: modulator.lpc file with locked pin constraints
8.10 Generate Programming File
8.10.1 Description
You can run the Generate Programming File process after your design has been completely fitted (for CPLDs) or routed (for FPGAs). The Generate Programming File process produces a bitstream for Xilinx device configuration. After the design is completely routed, you must configure the device to execute the desired function.
To run the Generate Programming File process:
- In the Hierarchy window, right-click on the programming module (modulator_rtl) and select Set as Top Module, if it is not already set
- In the Hierarchy window, select programming module (modulator_rtl)
- In the Processes window, double-click on the Generate Programming File command, see Illustration 8.68
Illustration 8.68: Generating Programming File command
Note: Information about the Generating Programming File, you can also find in the Lab 12: “Design Implementation”.
8.10.2 Generate Programming File Report
Generate Programming File Report provides information about the results of the BIT file generation process, including a list of the property options and any warnings or errors that occurred.
To see Bitgen Report:
- In the ISE Project Navigator, select Project → Design Summary/Reports option from the main menu
- In the Design Summary window, select Detailed Reports → Bitgen Report, see Illustration 8.69
Illustration 8.69: Detailed Reports – Bitgen Report
8.11 Configure Target Device
The Configure Target Device process uses the output from the Generate Programming File process, a BIT, JEDEC, or ISC file to configure or program your target device. The target device can be any of the following:
-
FPGA - The BIT and ISC files contain all of the configuration information from the NCD file, which defines the internal logic and interconnections of the device, plus device-specific information from other files associated with the target device.
-
CPLD - The JEDEC and ISC files contain all of the necessary configuration information from the design database. The data from the JEDEC or ISC files is downloaded to the CPLD device.
-
PROM or Flash configuration device – Used to configure FPGAs, the configuration information in the BIT or ISC file is used to create a PROM file. The data from the PROM file then programs the PROM or Flash device.
To Configure Target Device:
- In the Hierarchy window, select programming module (modulator_rtl)
- In the Processes window, expand Configure Target Device and double-click on the:
- Generate Target PROM/ACE File, or
- Manage Configuration Project (iMPACT)
Note: Information about the Configuring Target Device, you can also find in the Lab 12: “Design Implementation”.
8.11.1 Generate Target PROM/ACE File
The Generate Target PROM/ACE File process runs iMPACT in the background to generate the target PROM or ACE file. The file is generated according to the settings in an iMPACT project (.ipf) file saved from an iMPACT session.
Note: Alternatively, you can generate a target PROM or ACE file when you run the Configure Target Device process. By setting the automatically run Generate Target PROM/ACE File process property for the Configure Target Device process, a PROM or ACE file is generated each time the Configure Target Device Process is run.
To Generate Target PROM/ACE File:
- In the Hierarchy window, select programming module (modulator_rtl)
- In the Processes window, expand Configure Target Device and double-click on the Generate Target PROM/ACE File command, see Illustration 8.70
Illustration 8.70: Generate Target PROM/ACE File command
Generating PROM Programming File
The PROM file, as we said in the beginning of this chapter, contains all the configuration data that will be used to program the PROM or Flash device. You can store PROM files in the PROM devices or in your computer. When you want to program your FPGA device, you will use that files from a PROM device on your board, or from your computer using a serial or parallel cable.
Note: Typically, during debugging and testing, you program your FPGA device using download cable and your PC. Only if everything works, you will program PROM/Flash device on your board. This is important to mention, because with programmed PROM/Flash device, you have a system independent from your PC.
To generate PROM programming file, follow these steps:
- In the ISE iMPACT window, double-click on the Create PROM File (PROM File Formatter) command in the iMPACT Flows window, see Illustration 8.71
Illustration 8.71: Create PROM File (PROM File Formatter) command
- In the PROM File Formatter window, select Xilinx Flash/PROM in the Step 1. “Select Storage Target” and left-click on the green arrow , see Illustration 8.72
- In the Step 2. “Add Storage Device(s)”, select Auto Select PROM option (for beginners) and left-click on the second green arrow
- In the Step 3. “Enter Data” , type file name (modulator) in the Output File Name field , check if the Output File Location is your working directory and the File Format is set to MCS , see Illustration 8.72
Illustration 8.72: PROM File Formatter window
- Click OK at the bottom of the PROM File Formatter window
- In the Add Device dialog box, click OK to start adding device file to Data Stream
- In the Add Device window, open the modulator.bit file from the modulator directory
- In the Add Device dialog box, click No, but if necessary, you can add another device file to the PROM File Formatter by repeating the previous steps
- After you have included all device files, you can generate PROM file by double-clicking on the Generate File... option in the iMPACT Processes window, see Illustration 8.73
Illustration 8.73: ISE iMPACT window with generated PROM file
When you are creating PROM file using iMPACT, you must select one of the targets from the list that provides PROM File Formatter (as it is shown on the Illustration 8.72, Step 1 “Select Storage Target”):
- Xilinx Flash/PROM - iMPACT generates a PROM file that you can use to program a Xilinx Flash/PROM. Use this if your FPGA configure from one or more PROMs
- Non-Volatile FPGA - If you are targeting the non-volatile FPGA device, select this storage target
- Serial Peripheral Interface (SPI) Flash - The PROM File Formatter can generate PROM files for SPI Flash devices and that can be used in one of two modes:
- Configure Single FPGA - If you are targeting any 3rd party supplied SPI PROM, select this storage device type
- Configure MultiBoot FPGA - If you are targeting any 3rd party supplied SPI PROM and will use it in MultiBoot mode, select this storage device type. SPI Flash MultiBoot is available for the following Xilinx FPGAs: Spartan-6, Spartan-3A, Kintex-7, Artix-7, Virtex-7, Virtex-6 and Virtex-5
- Byte Peripheral Interface (BPI) Flash - The PROM File Formatter can generate PROM files for BPI Flash devices and that can be used in one of two modes:
- Configure Single FPGA - If you are targeting a Xilinx XCF128X BPI Flash PROM or any 3rd party supplied BPI PROM, select this storage device type
- Configure MultiBoot FPGA - If you are targeting a Xilinx XCF128X BPI Flash PROM or any 3rd party supplied BPI PROM and will use it in MultiBoot mode, select this storage device type. BPI Flash MultiBoot is available for the following Xilinx FPGAs: Virtex-7, Artix-7, Kintex-7, Virtex-6, Virtex-5, Spartan-6, Spartan-3A and Spartan-3E
-
Configure from Paralleled PROMs - Select this if you will configure the FPGA using two Xilinx BPI Flash storage devices operating in parallel.
- Generic Paraller PROM - Select this option if you are using a microprocessor or other device to read from a Parallel PROM and load a chain of Xilinx FPGAs
Generating ACE Programming File
The ACE file is a programming file for the System ACE CF (System Advanced Configuration Environment CompactFlash) family. System ACE CF is a two-chip solution that requires the System ACE CF controller, and either a CompactFlash card on one-inch Microdrive disk drive technology as the storage medium. System ACE CF has a built-in microprocessor interface to coordinate FPGA configuration directly with system requirements.
To generate ACE programming file, follow these steps:
- In the ISE iMPACT window, double-click on the SystemACE command in the iMPACT Flows window, see Illustration 8.74
Illustration 8.74: SystemACE command
-
In the Prepare System ACE Files dialog box, choose Novice as Operating Mode and click Next, see Illustration 8.75
Novice – is the recommended for SystemACE CF. This requires that each configuration address has the same number of devices
Expert – this enables each revision to have a different number of devices
Illustration 8.75: Prepare System ACE Files dialog box
-
In the System ACE Compact Flash Size dialog box, select Generic as System ACE CF Size and leave 0 as Reserve Space and click Next, see Illustration 8.76
Size – enables you to specify the size of the CompactFlash you want to use. If your device is larger then 256 Mb, select Generic.
Illustration 8.76: System ACE Compact Flash Size dialog box
-
In the System ACE Name And Location dialog box, specify Name (SysACE) and Location (your working directory) and click Next, see Illustration 8.77
Illustration 8.77: System ACE Name and Location dialog box
-
In the System ACE Configuration Address And Design dialog box, select which configuration address will be used and name them and click Next, see Illustration 8.78
Note: System ACE will allow you to store up to 8 configurations on one CF card. The names that you give are for your convenience only.
Illustration 8.78: System ACE Configuration Address And Design dialog box
- In the System ACE File Generation Summary dialog box, check the entered information in and if you are satisfied, click Finish to start adding device files, see Illustration 8.79
Illustration 8.79: System ACE File Generation Summary dialog box
- In the Add Device diloag box, click OK to start assigning device configuration files
- In the Add Device window, open the modulator.bit file from the modulator directory
- Add any other device configuration files or click No in the Add Device dialog box
- After you have included all device files, you can generate ACE file by double-clicking on the Generate File... option in the iMPACT Processes window
- Click OK in the ACE File Generation Option dialog box to start generating your ACE file, see Illustration 8.80
Illustration 8.80: ACE File Generation Option dialog box
Illustration 8.81: ISE iMPACT window with generated ACE file
8.11.2 Manage Configuration Project (iMPACT)
The Manage Configuration Project (iMPACT) process opens iMPACT, the tool that allows you to perform device configuration and configuration device file generation. iMPACT uses the output from the Generate Programming File process a BIT, JEDEC, or ISC file, to configure your target device or to create the following types of programming files: System ACE CF, PROM, SVF, SXVF, and STAPL files.
To Manage Configuration Project (iMPACT):
- In the Hierarchy window, select programming module (modulator_rtl)
- In the Processes window, expand Configure Target Device and double-click on the Manage Configuration Project (iMPACT) command, see Illustration 8.82 and ISE iMPACT tool will automatically open, see Illustration 8.83
Illustration 8.82: Manage Configuration Project (iMPACT) command
Illustration 8.83: ISE iMPACT tool window
After the ISE iMPACT tool is open, you can start generating either PROM or ACE programming file, repeating steps from the Sub-chapter 8.11.1 Generate Target PROM/ACE File:
- If you want to generate PROM programming file, please repeat steps for Generating PROM Programming File
- If you want to generate ACE programming file, please repeat steps for Generating ACE Programming File
8.12 Programming
Instead of programming the device by following the steps explained in the Chapter 8.11: Configure Target Device, you can start iMPACT tool independently:
- Connect the Digilent USB JTAG cable of your Kintex-7 (KC705) evaluation board to the Windows machine's USB port
- Ensure that the board is plugged in and powered on
- Make sure that the board settings are proper
- Launch iMPACT tool
- Double-click on the Boundary Scan command in the iMPACT Flows window, see Illustration 8.84
Illustration 8.84: Boundary Scan command
- Right-click in the Boundary Scan window and choose Initialize Chain option, see Illustration 8.85
Illustration 8.85: Initialize Chain option
- In the Auto Assign Configuration Files Query Dialog dialog box, click Yes to continue and assign configuration files
- In the Assign New Configuration File window, choose modulator.bit file from your working directory and click Open
- In the Attach SPI or BPI PROM dialog box, click No
- In the Device Programming Properties dialog box click OK to verify that iMPACT tool found the xc7k325t device, see Illustration 8.86
Illustration 8.86: Device Programming Properties dialog box
- Right-click on the programming device (device which displays the modulator.bit file) and choose Program command, see Illustration 8.87. This command will load your design into the device.
Illustration 8.87: Program command
- Wait a little bit when Configuration Operation Status window shows up and when Executing command attains 100%, your device is programmed, what you can also see in the Boundary Scan window, see Illustration 8.88
Illustration 8.88: Boundary Scan window with Program Succeeded notification
Assuming no errors occurs, you can test your design with a Chipscope core or an oscilloscope.
Note: Information about the Device Programming, you can also find in the Lab 12: “Design Implementation”.
8.13 ChipScope
8.13.1 Description
After configuring your device, you can debug your FPGA design using the Xilinx ChipScope Pro tool. The ChipScope Pro tool comprises from:
-
CORE Generator Tool – provides core generation capability for the ICON (Integrated Controller), ILA (Integrated Logic Analyzer), VIO (Virtual Input/Output) and ATC2 (Agilent Trace Core 2) cores targeting all supported FPGA device families. Also provides core generation capability for the IBERT (Internal Bit Error Ratio Tester) core targeting 7 Series, Spartan-6, Virtex-6 and Virtex-5 FPGA families. Also provides core generation capabilities for the AXI ChipScope Monitor core. The Xilinx CORE Generator tool is part of the Xilinx ISE Design Suite tool installation.
-
Core Inserter – automatically inserts the ICON, ILA and ATC2 cores into the user's synthesized design
-
PlanAhead Design Analysis Tool - automatically inserts the ICON and ILA cores into the design netlist
-
ChipScope Pro Analyzer Tool – provides in-system device configuration, trigger setup, trace display, control and status for the ICON, ILA, VIO, and IBERT cores. The Analyzer tool also provides device configuration, project management, and control over the IBERT core, including monitoring status and controlling variables
-
ChipScope Engine Tcl (CSE/Tcl) Scripting Interface – the scriptable CSE/Tcl command interface makes it possible to interact with devices in a JTEG chain from a TCL shell
For a typical design it is enough to use CORE Generator Tool or Core Inserter, to create and insert ChipScope Pro cores and Analyzer Tool to debug a design.
ChipScope Pro Tool Design Flow:
-
Insert ChipScope Pro cores into your design using the CORE Generator software or ChipScope Pro Core Inserter
-
In the Project Navigator, implement your design in and configure your device
-
In the ChipScope Pro Analyzer, analyze your design
Illustration 8.89: ChipScope Pro Tool Design Flow
8.13.2 ChipScope Pro Cores
The ChipScope Pro tool allows you to embed the following cores within your design, which assist with on-chip debugging: ICON (Integrated Controller), ILA (Integrated Logic Analyzer), VIO (Virtual Input/Output), IBERT (Internal Bit Error Ratio Tester), AXI ChipScope Monitor and ATC2 (Agilent Trace Core 2). These cores allow you to view internal signals and nodes in your FPGA.
ChipScope Pro cores and there functions:
- ICON: The Integrated Controller (ICON) core provides the communication path between the JTEG boundary scan port of the target FPGA and up to 15 ILA, VIO, and/or ATC2 cores.
- ILA: The ILA core is a customizable logic analyzer core that can be used to monitor internal signals of your design. Because the ILA core is synchronous to the design being monitored, all design clock constraints that are applied to your design are also applied to the components inside the ILA core.
- VIO: The virtual input/output core is a customizable core that can both monitor and drive internal FPGA signals in real time. Unlike the ILA core, no on- or off-chip RAM is required.
- IBERT: The IBERT core has all the logic to control, monitor, and change transceiver parameters and perform bit error ratio tests.
- AXI ChipScope Monitor: The AXI ChipScope Monitor core is designed to monitor and debug AXI interface. The core allows the probing of any signals going from a peripheral to the AXI interconnect.
- ATC2: The Agilent Trace Core 2 (ATC2) is a customizable debug capture core that is specially designed to work with the latest generation Agilent logic analyzers. The ATC2 core provides external Agilent logic analyzers access to internal FPGA design nets.
Note: EDK provides additional specific cores.
8.13.3 ChipScope Core Insertion
The ISE software and ChipScope Pro tool are integrated. Within the ISE software, you can create a ChipScope Definition and Connection (CDC) file to associate with the HDL or EDIF design that you process in the Project Navigator. This file stores information about source files, destination files, core parameters, and core settings for the ChipScope Pro Core Inserter. The CDC file is also used as input to the ChipScope Pro Analyzer to import signal names.
The CDC file is treated as a source file, and appears in the Project Navigator Hierarchy window. You can double-click the file to launch the ChipScope Pro Core Inserter software in which you can specify the ChipScope Pro cores.
To run the ChipScope Pro Core Inserter:
- In the ISE Project Navigator, select Project → New Sources... option from the main menu
- In the Select Source Type dialog box, select ChipScope Definition and Connection File, enter chipscope_name (modulator) in the File name field, and click Next, see Illustration 8.90
Illustration 8.90: Select Source Type dialog box
- In the Summary window click Finish and Project Navigator will create a modulator.cdc file for you, see Illustration 8.91
Illustration 8.91: modulator.cdc file in Hierarchy window
- Double-Click on the chipscope file (modulator.cdc) in the Hierarchy window to start the ChipScope Pro Core Inserter tool, see Illustration 8.92
Illustration 8.92: ChipScope Pro Core Inserter – main window
- In the ChipScope Pro Core Inserter main window, click Next
Note: Only one CDC may exist in a project. To remove all traces of ChipScope Pro cores in an ISE project, remove the CDC file and recompile the design.
After starting ChipScope Pro Core Inserter tool, you will have a possibility to make one of two possible Units, see Illustration 8.93:
-
New ILA Unit, or
-
New ATC2 Unit
Illustration 8.93: ChipScope Pro Core Inserter window with two possible units for creation
In our design we choose to use ILA core, because ATC2 core is not included in the standard ISE software. So, in this tutorial, creating new ATC2 unit is given just as an example.
New ILA Unit:
-
Select New ILA Unit in the ChipScope Pro Core Inserter window
-
Click on the ILA module, above the Core Utilization window, to modify the core
- Set the Trigger Parameters, as it is shown on the Illustration 8.94. Set Trigger Width (it is the number of signals that trigger port is composed of) to 13 and # Match Units (it is the number of units for comparing) to 2 and check is Enable Storage Qualification enabled in the Storage Qualification Condition Settings.
Illustration 8.94: ChipScope Pro Core Inserter – ILA Trigger Parameters tab
The number of Trigger Width is 13, because the size of the sine_ampl_s signal, that we want to see in the ChipScope, is 12 bits and the size of the freq_trig signal, with which we will do the storage qualification, is 1 bit.
Storage qualification condition is a Boolean combination of events that is detected by match unit comparators that are attached to the trigger ports of the core. Only when this combination is detected, data will be stored in the ChipScope's buffer.
The number of the Match Units is 2, because one is necessary for the trigger condition (when the sine_ampl_s signal is 0) and the second one is necessary for the storage qualification condition (when the freq_trig signal is 1).
- Click Next
- In the Capture Parameters tab, choose 1024 Samples in the Data Depth drop-down list, see Illustration 8.95
Illustration 8.95: ChipScope Pro Core Inserter – ILA Capture Parameters tab
Illustration 8.96: ChipScope Pro Core Inserter – ILA Net Connections tab
- In the Select Net dialog box, select clk_in_s_BUFG as the clock signal and click Make Connections button, see Illustration 8.97
Illustration 8.97: Select Net dialog box
- Select Trigger/Data Signals tab in the Net Selections tab and make the following connections, as we made the connection for clk_in_s_BUFG clock signal in step 8, see Illustration 8.98
- connect sine_ampl_s (11 downto 0) signal, and
- connect freq_trig signal
- Click OK
- Click Return to Project Navigator button
- Save and Close ChipScope Pro Core Inserter project
- In the ISE Project Navigator, rerun the implementation process (see Chapters 8.7 Implementation/Translation, 8.8 Implementation/Map and 8.9 Implementation/Place&Route)
- Regenerate programming file (see Chapter 8.10. Generate Programming File) and
- Reconfigure target device (see Chapters 8.11 Configure Target Device and 8.12 Programming)
- Select New ACT2 Unit in the ChipScope Pro Core Inserter window
- Click on the ACT2 module, above the Core Utilization window, to modify the core
- In the Pin Selection Parameters tab, set the Capture Mode to TIMING and ATD Pin Count to 12, as it is shown on the Illustration 8.99
- Set the Individual Pin Settings and add the pin locations in the Pin Loc fields, see Illustration 8.99. Find in the data sheet for the Kintex-7 KC705 development board to which pin locations you would like to connect your signals.
- Select Modify Connections in the Net Connections tab
- Modify connections like for the ILA core (see steps 7 - 11)
- Save and Close ChipScope Pro Core Inserter project
- In the ISE Project Navigator, rerun the implementation process (see Chapters 8.7 Implementation/Translation, 8.8 Implementation/Map and 8.9 Implementation/Place&Route)
- Regenerate programming file (see Chapter 8.10. Generate Programming File)
- Reconfigure target device (see Chapters 8.11 Configure Target Device and 8.12 Programming)
- First, select Implementation in the Design View, if it is not already set
- In the Hierarchy window, select analyzable module (modulator_rtl.vhd)
- In the Processes window, double-click on the Analyze Design Using ChipScope command, see Illustration 8.100
- In the ChipScope Analyzer window, click on the icon Open Cable/Search JTAG Chain
- Click OK
- In the Signals window, expand Data Port and select signals starting from CH:0 up to CH:11. Right click on them and select Move to Bus → New Bus option, see Illustration 8.101
- Enter desired name of the new bus (in our case it is sine_ampl_s) and press Enter
- Rename the remaining channel (CH: 12 DataPort[12]) to freq_trig_s (select the channel, right click on it and select Rename option)
- Select sine_ampl_s bus and freq_trig_s signal, right click on them, and select Add to View → Waveform option, see Illustration 8.102
- In the Waveform window, right click on the sine_ampl_s bus, and select Bus Radix → Unsigned Decimal option, see Illustration 8.103
- Configure Trigger Setup, as it is shown on the Illustration 8.104
- In the Match section, configure Value of the M0:TriggerPort0 to X_0000_0000_0000 and M1:TriggerPort0 to 1_XXXX_XXXX_XXXX, and check is Radix set as Bin
- In the Capture section, configure Storage Qualification to M1. To open and configure the Storage Condition, left click on the Storage Qualification box, select AND Equation, enable the M1 as Match Unit and click OK, see Illustration 8.105
- Run the ChipScope Analyzer tool, see Illustration 8.106
- Now you should see your design being analyzed by the onboard ChipScope module, see Illustration 8.107
- To analyze the operation of the Modulator design in case of the other output signal frequency, move the onboard switch (sw0) to the other position and run the ChipScope Analyzer again by pressing the Arm Trigger button as it is shown in the Illustration 8.106.
- In the ISE Project Navigator, select Project → New Sources... option from the main menu
- In the Select Source Type dialog box, select IP (CORE Generator & Architecture Wizard), enter vio_core_name (VIO_core) in the File name field, and click Next, see Illustration 8.108
- In the Select IP dialog box, expand Debug & Verification, then expand Debug and select VIO (ChipScope Pro – Virtual Input/Output) as it is shown on the Illustration 8.109
- Click Next
- In the Summary dialog box click Finish (see Illustration 8.110) and Project Navigator will create a new skeleton source for your VIO core
- Enable Synchronous Input Port and Synchronous Output Port options and configure Port Width to 1, because our input (sw0) and output (pwm) signals are 1-bit signals, see Illustration 8.111
- Click Generate
- In the ISE Project Navigator, select Project → New Sources... option from the main menu
- In the Select Source Type dialog box, select IP (CORE Generator & Architecture Wizard), enter icon_core_name (ICON_core) in the File name field, and click Next, see Illustration 8.112
- In the Select IP dialog box expand Debug & Verification, then expand Debug and select ICON (ChipScope Pro – Integrated Controller) as it is shown on the Illustration 8.113
- Click Next
- In the Summary dialog box click Finish and Project Navigator will create a new skeleton source for your ICON core
- Configure Number of Control Ports to 2. One will be used to connect the VIO core and the other to connect the ILA core
- Number of Control Ports: The ICON core can communicate with up to 15 VIO core units at any given time, so you can select the number of control ports from the Number of Control Ports pull-down list. In our case it is only one VIO core.
- Leave all other ICON Parameters unchanged, because:
- Disable Boundary Scan Component Instance: As we said, the ICON core provides an interface between ChipScope Pro Analyzer software and up to 15 ChipScope Pro target cores (such as VIO) via the JTAG Boundary Scan port of the target FPGA device. The ICON core can be configured to automatically include the Boundary Scan (BSCAN) primitive component (what we done in our design) or to use a BSCAN elsewhere in the design.
- Boundary Scan Chain: The ChipScope Analyzer software can communicate with the VIO cores by using one of the four internal scan chains, USER1, USER2, USER3, or USER4, provided by the Boundary Scan component. If the Boundary Scan component is instantiated inside the ICON core, like in our case, then you can select the desire scan chain from the pull-down list.
- Click Generate
- In the ISE Project Navigator, select Project → New Sources... option from the main menu
- In the Select Source Type dialog box, select IP (CORE Generator & Architecture Wizard), enter ila_core_name (ILA_core) in the File name field, and click Next, see Illustration 8.115
- In the Select IP dialog box expand Debug & Verification, then expand Debug and select ILA (ChipScope Pro – Integrated Logic Analyzer) as it is shown on the Illustration 8.116
- Click Next
- In the Summary dialog box click Finish and Project Navigator will create a new skeleton source for your ILA core
- The window that will be opened is used to set up the general ILA core parameters, see Illustration 8.117. Configure the parameters on the same way as it is done in the Sub-chapter 8.13.3 ChipScope Core Insertion → 1. New ILA Unit.
- Configure Max Sequence Levels to 16
- Click Next
- Configure Trigger Port Width to 13 and Match Units to 2, as it is shown on the Illustration 8.118
- Click Generate
- Connect the VIO core's CONTROL port signal to an unsigned CONTROL port of the ICON core instance in the design, because communication with the VIO core is ran using a connection to the JTAG port via the ICON core, see Illustration 8.119
- Connect all unsigned bits of the VIO core's synchronous and asynchronous input signals to a “0”. This prevents the mapper from removing the unsigned trigger and/or data signals and also avoids any DRC errors during the implementation process
- For best results, make sure the synchronous input source signals are synchronous to the VIO clock signal (CLK). Also make sure the synchronous output sink signals are synchronous to the VIO clock signal (CLK)
- Add modulator_vio_test.vhd and modulator_vio_test.ucf files in the modulator design using Project → Add Source... option from the ISE Project Navigator main menu
- In the Hierarchy window, right-click on the modulator_vio_test.vhd file and choose Set as Top Module option
- Made the necessary changes in the modulator_rtl.vhd source file as it is explained in the text above
-
Implement Design (see Chapters 8.7 Implementation/Translation,
8.8 Implementation/Map and 8.9 Implementation/Place&Route)
- Generate Programming File (see Chapter 8.10. Generate Programming File)
-
Configure Device (see Chapters 8.11 Configure Target Device and
8.12 Programming)
- Repeat the steps form the Sub-chapter 8.13.4 Analyze design using ChipScope Pro tool and you should get the same simulation results as on the Illustration 8.107
- If you open VIO Console from the ChipScope's Project window (see Illustration 8.120), you will see two 1-bit signals, SyncIn[0] and SyncOut[0]. SyncIn[0] port is actually connected to the pwm_s signal, as can be seen from the Drawing 8.2 and from the modulator_vio_test.vhd source code. Similarly, SyncOut[0] port is connected to the sw0 port of the modulator module. Rename SyncIn[0] signal to the pwm_s and SyncOut[0] signal to the sw0. Now, you can observe the rate of change of the pwm_s signal in the VIO Console window also. You can also change the frequency of the pwm_s signal by changing the values of the sw0 signal from 0 to 1 and from 1 to 0, see Illustration 8.121.
Illustration 8.121: VIO Console window
- Connect the USB Connector to the Starter Kit Board Connector and to the PC
- Connect the oscilloscope's probe to some expansion connector on the Starter Kit Board, see Illustration 8.122
- Power on the Kintex-7 (KC705) development board
- In the modulator_rtl.vhd file made the following corrections:
add a new pwm_osc port in the modulator entity declaration:
pwm_osc: out std_logic;
in the architecture add a new temporary signal declaration:
signal temp_out_s: std_logic;
in the port map of the pwm module (pwmmodule) connect the pwm_out port with the temp_out_s signal:
pwm_out => temp_out_s;
at the and of the architecture connect the pwm_out and pwm_osc signals with the temp_out_s signal:
pwm_out <= temp_out_s;
pwm_osc <= temp_out_s;
- In the UCF file add location of the pwm_osc signal. Location of the pwm_osc signal should be chosen in such way to allow easy access for the oscilloscope's probe
-
Rerun the implementation process (see Chapters 8.7 Implementation/Translation, 8.8 Implementation/Map and 8.9 Implementation/Place&Route)
-
Regenerate programming file (see Chapter 8.10. Generate Programming File) and
-
Reconfigure target device (see Chapters 8.11 Configure Target Device and 8.12 Programming)
- Configure the oscilloscope, and if your oscilloscope's settings are correct, you should see a pwm_out signal on the display, see Illustration 8.123
- Change the type of the target FPGA device
- Product Category: All
- Family: Virtex-7
- Device: XC7VX485T
- Package: FFG1761
- Speed Grade: -2
- Synthesis Tool: XST (VHDL/Verilog)
- Simulator: ISim (VHDL/Verilog)
- Preferred Language: VHDL
- Change the ucf constraints file
- In the Hierarchy window select the modulator_rtl.ucf file
- In the Processes window double-click on the Edit Constraints (Text) command (see Illustration 8.126) and the modulator_rtl.ucf file will be immediately opened
- In the modulator_rtl.ucf file made the changes from above
- Save the changes in the Project Navigator
- Placement Constraints – find in the User Guide for the Virtex-7 (VC707) development board pin locations where you would like to connect the input differential clock (clk_p, clk_n) and the sw0 and pwm_out ports.
- Timing Constraints – change the period of the input clock signal. In case of using Virtex-7 development board we didn't have to change nothing, because Kintex-7 (KC705) and Virtex-7 (VC707) development boards have the same frequency of the input clock signal (200 MHz). For example, if you use Zedboard, you must change input clock period from 5 ns to 10 ns, because Zedboard has 100 MHz input clock signal.
- Change the source codes
- modulator_pkg.vhd:
- modulator_rtl.vhd and modulator_tb.vhd:
Illustration 8.98: ILA Trigger/Data Signals tab
New ACT2 Unit:
Illustration 8.99: ChipScope Pro Core Inserter – ACT2 Pin Selection Parameters tab
8.13.4 Analyze design using ChipScope Pro tool
To launch the ChipScope Pro Analyzer tool from the Project Navigator:
Illustration 8.100: Analyze Design Using ChipScope command
Note: Verify that your design is running
Illustration 8.101: Creating a New Bus option
Illustration 8.102: Add to Waveform option
Illustration 8.103: Changing Bus Radix option
Illustration 8.104: Configured Trigger Setup
Illustration 8.105: Storage Condition dilaog box
Illustration 8.106: Running the ChipScope Analyzer tool
Illustration 8.107: Content of the ChipScope waveform window after trigger has been detected
If you compare Illustration 8.107 with Illustration 7.1: Simulation Results, you can see that signals sine_ampl_s and sine_out_s have identical waveforms. This means that the implemented Modulator design in the FPGA is behaving in the same way as it was predicted by the simulation.
Note: For more information, please see “ChipScope Pro 14.7 Software and Cores User Guide”.
Note: Information about the ChipScope Pro Tool, such as its cores, ChipScope Core Inserter and Analyzer, you can also find in the Lab 13: “ChipScope”.
8.13.5 ChipScope and VIO Core
As we said in the beginning of this chapter, VIO core is a customizable core that can monitor and drive internal FPGA signals in real time. Two different kinds of input and two different kinds of output signals are available in the VIO core: synchronous and asynchronous inputs and synchronous and asynchronous outputs.
The CORE Generator tool provides the ability to define and generate a customized VIO core for adding virtual inputs and outputs to your HDL design. You can customize the virtual inputs and outputs to be synchronous to a particular clock in your design or to be completely asynchronous with respect to any clock domain in your design. You can also customize the number of input and output signals used by the VIO core.
Note: The VIO core is currently not supported in the Core Inserter tool.
After the CORE Generator tool validates the user-defined parameters, it generates an XST netlist (*.ngc) and other files specific to the HDL language and synthesis tool associated with the CORE Generator project. You can easily generate the netlist and code examples for use in normal FPGA design flows.
Note: If you want more information about the VIO core, please see “ChipScope Pro Software and Cores User Guide”.
To generate the VIO core using CORE Generator tool, use the following steps:
Illustration 8.108: Select Source Type dialog box – VIO core
Illustration 8.109: Select IP dialog box – VIO core
Illustration 8.110: Summary dialog box – VIO core
The window that will be opened is used to set up the general VIO core parameters, see Illustration 8.111
Illustration 8.111: VIO core configuration window
Note: A maximum of 15 VIO cores can be used in a single design.
Note: If you click on the Datasheet option in the bottom of the VIO core configuration window, you will get a short datasheet for the ChipScope Pro VIO core.
After generating the VIO core, we will also generate the ICON core, because ICON core provides the communication between the VIO cores and the ChipScope Pro Analyzer software.
To generate the ICON core using CORE Generator tool, use the following steps:
Illustration 8.112: Select Source Type dialog box – ICON core
Illustration 8.113: Select IP dialog box – ICON core
The window that will be opened is used to set up the general ICON core parameters, see Illustration 8.114
Illustration 8.114: ICON core configuration window
Note: Currently, only one ICON core can be used in a single design.
Note: If you click on the Datasheet option in the bottom of the ICON core configuration window, you will get a short datasheet for the ChipScope Pro ICON core.
In order to use the VIO core we must also use the ILA core. The VIO core is currently not supported in the Core Inserter tool, it is only supported in the CORE Generator tool. Therefore we must also generate the ILA core using the CORE Generator.
Note: If you have in your project ILA core generated using the Core Inserter tool, please remove it, and generate a new one with CORE Generator.
To generate the ILA core using CORE Generator tool, use the following steps:
Illustration 8.115: Select Source Type dialog box – ILA core
Illustration 8.116: Select IP dialog box – ILA core
Illustration 8.117: ILA core configuration window - 1
Illustration 8.118: ILA core configuration window - 2
Note: If you click on the Datasheet option in the bottom of the ILA core configuration window, you will get a short datasheet for the ChipScope Pro ILA core.
To instantiate the VIO core in your design, use the following guidelines to connect the VIO core port signals to various signals in your design:
Illustration 8.119: VIO core connection to ICON core
After generating and configuring VIO, ICON and ILA cores, we should make a new module (modulator_vio_test.vhd) where we will connect the existing design (modulator_rtl.vhd) with the VIO core (see Drawing 8.2). By doing so, for the sw0 port control it wont be necessary to use switch on the development board. Instead, we will use one of the VIO core's outputs to control the sw0 port. This will enable us to change the state of the sw0 port inside the ChipScope Pro Analyzer.
Drawing 8.2: Connection between the VIO core and Modulator module
Now we will create an VHDL module (modulator_vio_test.vhd) that will make connection between the VIO core and Modulator module (modulator_rtl.vhd).
To create a module, use steps for creating modules, Sub-chapter 2.3.1 Creating a Module Using an Text Editor.
modulator_vio_test.vhd:
library ieee;
use ieee.std_logic_1164.all;
use work.modulator_pkg.all;
library unisim;
use unisim.vcomponents.all;
entity modulator_vio_test is
generic(
board_name_g : board_setting_t := kc705_c;
-- Parameter that specifies major characteristics of the board that will be used
-- to implement the modulator design
-- Possible choices: lx9_c, zedboard_c, ml605_c, kc705_c
-- Adjust the modulator_pkg.vhd file to add more
design_setting_g: design_setting_t := design_setting_c
-- User defined settings for the pwm design
);
port(
clk_p : in std_logic; -- differential input clock signal
clk_n : in std_logic; -- differential input clock signal
pwm_out : out std_logic -- pulse width modulated signal
);
end;
architecture rtl of modulator_vio_test is
signal sync_out_s : std_logic_vector (0 downto 0);
signal vio_control_s : std_logic_vector(35 downto 0);
signal ila_control_s : std_logic_vector(35 downto 0);
signal pwm_s : std_logic_vector (0 downto 0);
signal clk_in_s : std_logic;
signal debug_data_s : std_logic_vector (12 downto 0);
component VIO_core
port (
CLK : in std_logic;
CONTROL : inout std_logic_vector(35 downto 0);
SYNC_OUT : out std_logic_vector (0 downto 0);
SYNC_IN : in std_logic_vector (0 downto 0)
);
end component;
component ICON_core
port (
CONTROL0 : inout std_logic_vector(35 downto 0);
CONTROL1 : inout std_logic_vector(35 downto 0)
);
end component;
component ILA_core
port (
CONTROL : inout std_logic_vector(35 downto 0);
CLK : in std_logic;
TRIG0 : in std_logic_vector (12 downto 0)
);
end component;
begin
pwm_out <= pwm_s (0);
clk_buf : if (board_name_g.has_diff_clk = yes) generate
IBUFGDS_inst : IBUFGDS
generic map(
IBUF_LOW_PWR => TRUE,
-- low power (TRUE) vs. performance (FALSE) setting for referenced I/O standards
IOSTANDARD => "DEFAULT"
)
port map (
O => clk_in_s, -- clock buffer output
I => clk_p, -- diff_p clock buffer input
IB => clk_n -- diff_n clock buffer input
);
end generate clk_buf;
no_clk_buf : if (board_name_g.has_diff_clk = no) generate
clk_in_s <= clk_p;
end generate no_clk_buf;
modulator: entity work.modulator(rtl)
generic map(
this_module_is_top_g => no,
board_name_g => board_name_g,
design_setting_g => design_setting_g
)
port map(
clk_p => clk_in_s,
clk_n => '0',
sw0 => sync_out_s(0),
pwm_out => pwm_s(0),
debug_data => debug_data_s
);
vio: VIO_core
port map (
CLK => clk_in_s,
CONTROL => vio_control_s,
SYNC_OUT => sync_out_s,
SYNC_IN => pwm_s
);
icon: ICON_core
port map (
CONTROL0 => vio_control_s,
CONTROL1 => ila_control_s
);
ila: ILA_core
port map (
CONTROL => ila_control_s,
CLK => clk_in_s,
TRIG0 => debug_data_s
);
end;
As you can see from the picture above (Drawing 8.2), we have added the debug_data output port to the Modulator module (modulator_rtl.vhd) and connected it to the TRIG0 input port of the ILA core. This is important, because we will connect the internal sine_ampl_s and freq_trig_s signals from the Modulator module to the debug_data port, and use them as the trigger/data signals for the ILA core.
As we can also see from the picture above (Drawing 8.2), we have connected the sw0 input port of the Modulator module to the SYNC_OUT output port of the VIO core. This is also important, because now we don't need any physical switch from the development board to drive the sw0 input port. Now, this is done using an synchronous output port from the VIO core (sync_out_s signal). This signal can be controlled within the ChipScope Analyzer tool to change the value of the sw0 input port, and by doing so the frequency of the pwm signal.
To make these modifications, modulator_rtl.vhd source code must be modified as it is shown bellow:
Modulator VHDL model:
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
use ieee.std_logic_textio.all;
use ieee.std_logic_unsigned.all;
use work.modulator_pkg.all;
library unisim;
use unisim.vcomponents.all;
entity modulator is
generic(
this_module_is_top_g : module_is_top_t := yes;
-- If some module is top, it needs to implement the differential clk buffer,
-- otherwise this variable will be overwritten by a upper hierarchy layer
board_name_g : board_setting_t := kc705_c;
-- Parameter that specifies major characteristics of the board that will be used
-- to implement the modulator design
-- Possible choices: lx9_c, zedboard_c, ml605_c, kc705_c
-- Adjust the modulator_pkg.vhd file to add more
design_setting_g: design_setting_t := design_setting_c
-- User defined settings for the pwm design
);
port(
clk_p : in std_logic; -- differential input clock signal
clk_n : in std_logic; – differential input clock signal
sw0 : in std_logic; -- signal made for selecting frequency
pwm_out : out std_logic; -- pulse width modulated signal
debug_data : out std_logic_vector (12 downto 0)
);
end;
architecture rtl of modulator is
signal clk_in_s : std_logic;
signal ampl_cnt_s : std_logic_vector(design_setting_g.depth-1 downto 0); -- amplitude counter
signal sine_ampl_s : std_logic_vector(design_setting_g.width-1 downto 0); -- current amplitude value of the sine signal
signal freq_trig_s : std_logic := '0'; – signal which frequency depends on the sw0 state
constant c1_c : real := board_name_g.fclk/(real((2**design_setting_g.depth)*(2**design_setting_g.width)));
-- c1_c = fclk/(2^depth*2^width) - c1_c = 190.73486, fclk = 200 MHz
constant div_factor_freqhigh_c : integer := integer(c1_c/design_setting_g.f_high)*(2**design_setting_g.width);
-- div_factor_freqhigh_c = (c1_c/f_high)*2^width - threshold value of frequency a = 221184
constant div_factor_freqlow_c : integer := integer(c1_c/design_setting_g.f_low)*(2**design_setting_g.width);
-- div_factor_freqlow_c = (c1_c/f_low)*2^width - threshold value of frequency b = 782336
begin
-- if module is top, it has to generate the differential clock buffer in case -- of a differential clock, otherwise it will get a single ended clock signal -- from the higher hierarchy
clk_buf_if_top : if (this_module_is_top_g = yes) generate
clk_buf : if (board_name_g.has_diff_clk = yes) generate
IBUFGDS_inst : IBUFGDS
generic map (
IBUF_LOW_PWR => TRUE,
-- low power (TRUE) vs. performance (FALSE) setting for referenced I/O standards
IOSTANDARD => "DEFAULT"
)
port map (
O => clk_in_s, -- clock buffer output
I => clk_p, -- diff_p clock buffer input
IB => clk_n -- diff_n clock buffer input
);
end generate clk_buf;
no_clk_buf : if (board_name_g.has_diff_clk = no) generate
clk_in_s <= clk_p;
end generate no_clk_buf;
end generate clk_buf_if_top;
not_top : if (this_module_is_top_g = no) generate
clk_in_s <= clk_p;
end generate not_top;
freq_ce : entity work.frequency_trigger(rtl) -- frequency trigger instance
generic map(
div_factor_freqhigh_g => div_factor_freqhigh_c,
div_factor_freqlow_g => div_factor_freqlow_c
)
port map(
clk_in => clk_in_s,
freq_trig => freq_trig_s,
sw0 => sw0
);
counterampl : entity work.counter(rtl) -- counter instance
generic map(
cnt_value_g => design_setting_g.cntampl_value,
depth_g => design_setting_g.depth
)
port map (
clk_in => clk_in_s,
cnt_en => freq_trig_s,
cnt_out => ampl_cnt_s
);
sine : entity work.sine(rtl) -- digital sine instance
generic map(
depth_g => design_setting_g.depth,
width_g => design_setting_g.width
)
port map(
ampl_cnt => ampl_cnt_s,
clk_in => clk_in_s,
sine_out => sine_ampl_s
);
pwmmodule : entity work.pwm (rtl) -- pwm instance
generic map (
width_g => design_setting_g.width,
div_factor_freqhigh_g => div_factor_freqhigh_c / (2**design_setting_g.width),
div_factor_freqlow_g => div_factor_freqlow_c / (2**design_setting_g.width)
)
port map (
clk_in => clk_in_s,
sw0 => sw0,
sine_ampl => sine_ampl_s,
pwm_out => pwm_out
);
debug_data (11 downto 0) <= sine_ampl_s;
debug_data (12) <= freq_trig_s;
end;
After we made a new VHDL module (modulator_vio_test.vhd), we must modify the modulator_rtl.ucf file, because we don't have any more sw0 port. The new content of the ucf file is shown in the code below.
modulator_vio_test.ucf file:
NET "clk_p" LOC = "AD12" | IOSTANDARD = LVDS;
NET "clk_n" LOC = "AD11" | IOSTANDARD = LVDS;
NET "pwm_out" LOC = "AB8" | IOSTANDARD = LVCMOS15 | SLEW = SLOW | DRIVE = 12;
NET "clk_p" PERIOD = 5 ns;
After finishing with the modifications, we must return to the Project Navigator and do the following:
Illustration 8.120: VIO Console command
Note: All the information about the VIO core, such as how to generate, configure and instantiate the VIO core, as well as how to connect the VIO core with your existing design, you can also find in the Lab 14: “ChipScope and VIO Core”.
8.14 Oscilloscope
An oscilloscope is a type of electronic instrument that creates a two-dimensional graph of one or more electrical potential differences. Typically horizontal, or x-axis, represents function of time and vertical, or y-axis, represents voltage.
To see the pwm signal on the oscilloscope, follow these steps:
Illustration 8.122: Using oscilloscope for viewing PWM signal
Now, the modulator_rtl.vhd source file should look like the code below.
modulator_oscilloscope.vhd:
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
use ieee.std_logic_textio.all;
use ieee.std_logic_unsigned.all;
use work.modulator_pkg.all;
library unisim;
use unisim.vcomponents.all;
entity modulator is
generic(
this_module_is_top_g : module_is_top_t := yes;
-- If some module is top, it needs to implement the differential clk buffer,
-- otherwise this variable will be overwritten by a upper hierarchy layer
board_name_g : board_setting_t := kc705_c;
-- Parameter that specifies major characteristics of the board that will be used
-- to implement the modulator design
-- Possible choices: lx9_c, zedboard_c, ml605_c, kc705_c
-- Adjust the modulator_pkg.vhd file to add more
design_setting_g: design_setting_t := design_setting_c
-- User defined settings for the pwm design
);
port(
clk_p : in std_logic; -- differential input clock signal
clk_n : in std_logic; – differential input clock signal
sw0 : in std_logic; -- signal made for selecting frequency
pwm_out : out std_logic; -- pulse width modulated signal
pwm_osc : out std_logic -- pulse width modulated signal for the oscilloscope
);
end;
architecture rtl of modulator is
signal clk_in_s : std_logic;
signal ampl_cnt_s : std_logic_vector(design_setting_g.depth-1 downto 0); -- amplitude counter
signal sine_ampl_s : std_logic_vector(design_setting_g.width-1 downto 0); -- current amplitude value of the sine signal
signal freq_trig_s : std_logic := '0'; – signal which frequency depends on the sw0 state
signal temp_out_s : std_logic; – temporary signal
constant c1_c : real := board_name_g.fclk/(real((2**design_setting_g.depth)*(2**design_setting_g.width)));
-- c1_c = fclk/(2^depth*2^width) - c1_c = 190.73486, fclk = 200 MHz
constant div_factor_freqhigh_c : integer := integer(c1_c/design_setting_g.f_high)*(2**design_setting_g.width);
-- div_factor_freqhigh_c = (c1_c/f_high)*2^width - threshold value of frequency a = 221184
constant div_factor_freqlow_c : integer := integer(c1_c/design_setting_g.f_low)*(2**design_setting_g.width);
-- div_factor_freqlow_c = (c1_c/f_low)*2^width - threshold value of frequency b = 782336
begin
-- if module is top, it has to generate the differential clock buffer in case
-- of a differential clock, otherwise it will get a single ended clock signal
-- from the higher hierarchy
clk_buf_if_top : if (this_module_is_top_g = yes) generate
clk_buf : if (board_name_g.has_diff_clk = yes) generate
IBUFGDS_inst : IBUFGDS
generic map (
IBUF_LOW_PWR => TRUE,
-- low power (TRUE) vs. performance (FALSE) setting for referenced I/O standards
IOSTANDARD => "DEFAULT"
)
port map (
O => clk_in_s, -- clock buffer output
I => clk_p, -- diff_p clock buffer input
IB => clk_n -- diff_n clock buffer input
);
end generate clk_buf;
no_clk_buf : if (board_name_g.has_diff_clk = no) generate
end generate no_clk_buf;
end generate clk_buf_if_top;
not_top : if (this_module_is_top_g = no) generate
clk_in_s <= clk_p;
end generate not_top;
freq_ce : entity work.frequency_trigger(rtl) -- frequency trigger instance
generic map(
div_factor_freqhigh_g => div_factor_freqhigh_c,
div_factor_freqlow_g => div_factor_freqlow_c
)
port map(
clk_in => clk_in_s,
freq_trig => freq_trig_s,
sw0 => sw0
);
counterampl : entity work.counter(rtl) -- counter instance
generic map(
cnt_value_g => design_setting_g.cntampl_value,
depth_g => design_setting_g.depth
)
port map (
clk_in => clk_in_s,
cnt_en => freq_trig_s,
cnt_out => ampl_cnt_s
);
sine : entity work.sine(rtl) -- digital sine instance
generic map(
depth_g => design_setting_g.depth,
width_g => design_setting_g.width
)
port map(
ampl_cnt => ampl_cnt_s,
clk_in => clk_in_s,
sine_out => sine_ampl_s
);
pwmmodule : entity work.pwm (rtl) -- pwm instance
generic map (
width_g => design_setting_g.width,
div_factor_freqhigh_g => div_factor_freqhigh_c / (2**design_setting_g.width),
div_factor_freqlow_g => div_factor_freqlow_c / (2**design_setting_g.width)
)
port map (
clk_in => clk_in_s,
sw0 => sw0,
sine_ampl => sine_ampl_s,
pwm_out => temp_out_s
);
pwm_out <= temp_out_s;
pwm_osc <= temp_out_s;
end;
Illustration 8.123: PWM signal measured by oscilloscope
Note: All the information about the Oscilloscope, which are in this chapter, you can also find in the Lab 15: “Oscilloscope”.
8.15 Modifications in case of using different development boards
In case of using some other development board, some small modifications to accommodate your design to the new development board, must be done.
These modifications will be illustrated in case of using Virtex-7 (VC707) development board.
Note: Virtex-7 (VC707) development board has the same differential 200 MHz input clock as the Kintex-7 (KC705) development board, so the design changes will be minor.
In the Hierarchy window, select the type of your FPGA device. In our case it is xc7k325t-2ffg900, Kintex-7 (KC705) evaluation platform. Right-click on it and choose Design Properties... option, see Illustration 8.124
Illustration 8.124: Design Properties option
In the Design Properties dialog box, set the following parameters to change the type of the FPGA device:
Note: Leave all other selections unchanged.
Illustration 8.125: Design Properties dialog box
Open the modulator_rtl.ucf file from your working directory and make the following changes:
NET "clk_p" LOC = "E19" | IOSTANDARD = LVDS;
NET "clk_n" LOC = "E18" | IOSTANDARD = LVDS;
NET "sw0" LOC = "AV30" | IOSTANDARD = LVCMOS18;
NET "pwm_out" LOC = "AM39" | IOSTANDARD = LVCMOS18 | SLEW = SLOW | DRIVE = 12;
NET “clk_p” TNM_NET = clk_p;
TIMESPEC TS_clk_p = PERIOD “clk_in” 5 ns HIGH 50%;
The another way to change the ucf constraints file is from the Project Navigator:
Illustration 8.126: Edit Constraints (Text) command
The things that we changed in the ucf file are:
Because we changed the target development board, from Kintex-7 (KC705) to Virtex-7 (VC707), we must accommodate the whole system to the new parameters.
Changes that must be done are listed below.
If you want to add some other development board that is not on the list of the available development boards in our design, please open the modulator_pkg.vhd source file and add the desired development board information.
- Add the name of the new development board in the board_type_t type declaration:
type board_type_t is (lx9, zedboard, ml605, kc705, vc707);
- Create a new constant for the new development board. Constant must be a structure of type board_setting_t. In that structure you must declare the following parameters:
- the name of the new development board defined in the board_type_t type declaration
- the frequency of the input clock signal in MHz
- is the input clock differential (yes) or not (no), using a has_diff_clk_t type field
-- place the information about the new boards here:
constant lx9_c : board_setting_t := (lx9, 100000000.0, no); -- Spartan-6
constant zedboard_c : board_setting_t := (zedboard, 100000000.0, no); -- Zynq-7000
constant ml605_c : board_setting_t := (ml605, 200000000.0, yes); -- Virtex-6
constant kc705_c : board_setting_t := (kc705, 200000000.0, yes); -- Kintex-7
constant vc707_c : board_setting_t := (vc707, 200000000.0, yes); -- Virtex-7
- Change the type of your development board. In our case it will be from kc705_c (Kintex-7) to vc707_c (Virtex-7).
board_name_g : board_setting_t := vc707_c;
-- Parameter that specifies major characteristics of the board that will be used to implement the modulator design
-- Possible choices are: lx9_c, zedboard_c, ml605_c, kc705_c, vc707_c
-- Adjust the modulator_pkg.vhd file to add more