ift - User contributions [en]

Bitvis UVVM VHDL Verification Component Framework

2026-03-16T12:45:25Z

Nfyku:

This wiki page is heavily based on the Powerpoint-presentation found [https://github.com/UVVM/UVVM/blob/master/uvvm_util/doc/Simple_TB_step_by_step.pps here].

Copyright 2025 UVVM
Licensed under the [http://www.apache.org/licenses/LICENSE-2.0 Apache License, Version 2.0 (the “License”)].

== Introduction ==
UVVM (Universal VHDL Verification Methodology) is a free and Open Source Methodology and Library for making very structured VHDL-based testbenches, examples and simulations scripts from the [https://github.com/UVVM/UVVM UVVM on github].

=== What's in the folders? ===
[[File:20160302215840!1.png|thumb]]

The download includes severals folders:
* bitvis_irqc - example VHDL design + testbench
* bitvis_uart - example VHDL design + testbench
* bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI)
* bitvis_vip_uart - VIP for UART TX and RX
* uvvm_util - UVVM utility library - sufficient for simple testbenches
* uvvm_vvc_framework - Framework for more advanced tutorials

=== IRQC ===
[[File:irqc.png|thumb]]
The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals.

[[File:irqc2.png|350px]]

== UVVM Utility Library - Testbench creation ==
Copy the folders bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files.
=== Generate TB entity with DUT instantiated ===
Our TB entity can in many cases be generated from several tools. Notepad++ (among other) supports plugins that enables copying an entity and pasting it as an instantiation, and also as a complete testbench template. However, we will change some of our signals so that they fit the VIP SBI BFM. The signals to and from the CPU will be converted to t_sbi_if record, which is a type that includes all the SBI signals (cs, addr, rd, wr, wdata, ready and rdata).

<pre>
--Standard libraries
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.numeric_std.all;

-- Library enabling control of the simulation from VHDL. Eg. std.env.stop
library STD;
use std.env.all;

-- Obviously the UVVM library
library uvvm_util;
context uvvm_util.uvvm_util_context;

-- We will use this library later when implementing the Bus Functional Model
-- Includes among much else the record type t_sbi_if and many functions
-- If other buses are used, you will have to change this library
library bitvis_vip_sbi;
use bitvis_vip_sbi.sbi_bfm_pkg.all;

-- This file includes definitions of everything from registers to record types
use work.irqc_pif_pkg.all;

-- Test case entity
entity irqc_tb is
end entity;

-- Test case architecture
architecture func of irqc_tb is

-- DSP interface and general control signals
signal clk : std_logic := '0';
signal arst : std_logic := '0';
-- CPU interface
-- t_sbi_if is from the verification IP SBI
-- init_sbi_if_signals initialize the inputs to 0 and the outputs to Z
signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8);

-- Interrupt related signals
signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0');
signal irq2cpu : std_logic := '0';
signal irq2cpu_ack : std_logic := '0';

begin

-----------------------------------------------------------------------------
-- Instantiate DUT
-----------------------------------------------------------------------------
i_irqc: entity work.irqc
port map (
-- DSP interface and general control signals
clk => clk,
arst => arst,
-- CPU interface
cs => sbi_if.cs, -- NOTICE THE SIGNALS ARE NOW SBI_IF
addr => sbi_if.addr,
wr => sbi_if.wena,
rd => sbi_if.rena,
din => sbi_if.wdata,
dout => sbi_if.rdata,
-- Interrupt related signals
irq_source => irq_source,
irq2cpu => irq2cpu,
irq2cpu_ack => irq2cpu_ack
);

end func;
</pre>

=== Add support process for clock generation ===
We now have to add a support process that controls the clock. This has to allow enabling/disabling from the test sequencer. We add the following before "begin" in our architecture:
<pre>
-- Added for clock generation
signal clock_ena : boolean := false;

constant C_CLK_PERIOD : time := 10 ns;

procedure clock_gen(
signal clock_signal : inout std_logic;
signal clock_ena : in boolean;
constant clock_period : in time
) is
variable v_first_half_clk_period : time := C_CLK_PERIOD / 2;
begin
loop
if not clock_ena then
wait until clock_ena;
end if;
wait for v_first_half_clk_period;
clock_signal <= not clock_signal;
wait for (clock_period - v_first_half_clk_period);
clock_signal <= not clock_signal;
end loop;
end;
</pre>

Our clock can now be activated from the test sequencer (this will be added in the next step):
<pre>
-- After begin in the architecture
clock_gen(clk, clock_ena, C_CLK_PERIOD);

-- Inside the test sequencer process
clock_ena <= true;
</pre>

=== Add test sequencer process ===
The next step is to add the test sequencer process. This process controls everything from initialization to termination of the simulation.

<pre>
-- Set upt clock generator
clock_gen(clk, clock_ena, C_CLK_PERIOD);

------------------------------------------------
-- PROCESS: p_main
------------------------------------------------
p_main : process
-- The scope tells you where log messages originates - C_SCOPE tells us they originate from the default test sequencer scope
constant C_SCOPE : string := C_TB_SCOPE_DEFAULT;
-- This is where we will add some procedures later to simplify the tests

begin

--Print the configuration to the log
report_global_ctrl(VOID);
report_msg_id_panel(VOID);

enable_log_msg(ALL_MESSAGES);
--disable_log_msg
--enable_log_msg(ID_LOG_HDR);

log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE);
------------------------------------------------------------
clock_ena <= true; -- to start clock generator

------------------------------------------------------------
-- End the simulation
wait for 1000 ns; -- to allow some time for completion
report_alert_counters(FINAL); -- Report final counters and print conclusion for simulation (Success/Fail)
log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE);

--Finish the simulation
std.env.stop;
wait; -- to stop completely
end process p_main;
</pre>

==Simulation==
We now have the skeleton of the testbench, which we will develop further. But now, let's see if everything works. UVVM includes simulation scripts for the IRQC example that compiles everything we need, from the source files of the VHDL design, to the testbench (if you called the file irqc_tb.vhd and placed it in the tb-folder) and the SBI BFM and the UVVM library. Open up QuestaSim/ModelSim.
Change directory to the script folder (where you have copied the UVVM files), for example in phys321/bitviswiki.....:
<pre>
cd ~/phys321/bitviswiki/bitvis_irqc/script
do compile_and_sim_all.do
</pre>

This will present our result in the transcript windows, but also write _Log.txt file which includes all the information we have asked for. We see that we get the results from the following code:
<pre>
report_global_ctrl(VOID);
report_msg_id_panel(VOID);
enable_log_msg(ALL_MESSAGES);
log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE);
report_alert_counters(FINAL);
log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE);
</pre>
Commenting these out will result in an empty log.

== Verbosity control ==
We want to able to control the amount of information in our logs, and the framework enables us to prioritize messages based on ID. This makes it easy to turn on or off the information we want.
To turn on a specific ID
<pre>
enable_log_msg(IDNAME);
</pre>

Turn off:
<pre>
disable_log_msg(IDNAME);
</pre>

For writing a message to a certain log ID:
<pre>
log(IDNAME, "MESSAGE HERE", C_SCOPE);
</pre>
Remember that C_SCOPE just tells us that the message originated from the default scope and will look like "TB seq." in the log file.

Exampled IDs:
* ID_LOG_HDR, -- ONLY allowed in test sequencer, Log section headers
* ID_SEQUENCER, -- ONLY allowed in test sequencer, Normal log (not log headers)
* ID_BFM, -- Used inside a BFM (to log BFM access)
* ID_CLOCK_GEN, -- Used for logging when clock generators are enabled or disabled
* ALL_MESSAGES -- Applies to ALL message ID apart from ID_NEVER

You'll find all the different ID's in the UVVM Utility Library Quick Reference or defined in uvvm_util/adaptions_pkg.vhd. This also where C_TB_SCOPE_DEFAULT is defined.

== Implement first tests ==
[[File:tb.png|thumb|upright=0.35]]
We want to check and verify that our testbench is up and running and to verify our first tests of the DUT. This means that we have to able to set all our signals passive, apply a reset signal and then check the default outputs of the DUT.

Instead of setting all our signals passive one-by-one in our test sequencer we declare a procedure in our p_main process(this is done before begin):
<pre>
procedure set_inputs_passive(
dummy : t_void) is --dummy variable is included only to allow calling the procedure with parenthesis for readability
begin
sbi_if.cs <= '0';
sbi_if.addr <= (others => '0');
sbi_if.wena <= '0';
sbi_if.rena <= '0';
sbi_if.wdata <= (others => '0');
irq_source <= (others => '0');
irq2cpu_ack <= '0';
log(ID_SEQUENCER_SUB, "All inputs set passive", C_SCOPE);
end;
</pre>

Note that the procedure declaration also includes a dummy variable parameter. This means that we will be able to call the procedure with the more readable:

<pre>
set_inputs_passive(VOID);
</pre>

Rather than:
<pre>
set_inputs_passive;
</pre>
which is more ambigious.

We may also would like to send pulses on different signals, f.ex. sending a pulse on our reset to see if it behaves like intended. We therefore can include a pulse procedure:
<pre>
procedure pulse(
signal target : inout std_logic_vector;
constant pulse_value : in std_logic_vector;
signal clock_signal : in std_logic;
constant num_periods : in natural;
constant msg : in string) is
begin
if num_periods > 0 then
wait until falling_edge(clock_signal);
target <= pulse_value;
for i in 1 to num_periods loop
wait until falling_edge(clock_signal);
end loop;
else
target <= pulse_value;
wait for 0 ns; -- Delta cycle only
end if;
target(target'range) <= (others => '0');
log(ID_SEQUENCER_SUB, "Pulsed to " & to_string(pulse_value, HEX, AS_IS, INCL_RADIX) & ". " & msg, C_SCOPE);
end;
</pre>

In the above example the test sequencer is required to inform the procedure of what value the pulse is to take. The call to the procedure would take the following form:
<pre>
pulse(arst, 'Z', clk, 10, "Log message - Im pulsing the value 'Z'");
</pre>
But a more specific overload can be created where pulse always takes value '1':
<pre>
procedure pulse(
signal target : inout std_logic;
signal clock_signal : in std_logic;
constant num_periods : in natural;
constant msg : in string
) is
begin
if num_periods > 0 then
wait until falling_edge(clock_signal);
target <= '1';
for i in 1 to num_periods loop
wait until falling_edge(clock_signal);
end loop;
else
target <= '1';
wait for 0 ns; -- Delta cycle only
end if;
target <= '0';
log(ID_SEQUENCER_SUB, msg, C_SCOPE);
end;
</pre>

These procedures can now be called directly from our test sequence:
<pre>
set_inputs_passive(VOID);
pulse(arst, clk, 10, "pulsed reset-signal - active for 10T");
</pre>

To check signal values we can use the built-in check function check_value():
<pre>
check_value(irq2cpu, 'X', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE);
</pre>
The above call checks if the signal irq2cpu is 'X', and obviously fail if everything works correctly and gives the following message:

[[File:error.png|700px]]

If we want we can change the number of errors logged before the simulation stops:
<pre>
set_alert_stop_limit(ERROR, 3);
</pre>

We now have all the tools needed for the first tests in our sequencer:
<pre>
set_inputs_passive(VOID);
pulse(arst, clk, 10, "Pulsed reset-signal - active for 10T");

check_value(C_NUM_SOURCES > 0, FAILURE, "Must be at least 1 interrupt source", C_SCOPE);
check_value(C_NUM_SOURCES <= 8, TB_WARNING, "This TB is only checking IRQC with up to 8 interrupt sources", C_SCOPE);

log(ID_LOG_HDR, "Check defaults on output ports", C_SCOPE);
------------------------------------------------------------
check_value(irq2cpu, '0', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE);
check_value(sbi_if.rdata, x"00", ERROR, "Register data bus output must be default passive");
</pre>

This will give us the following log:

[[File:sim.png|800px]]

This information may only interesting initially and for debug, and can be turned on or off by use of ID.

== Subprograms ==
Some of our testbench code will be repeated several times and the testbench may therefore benefit from creating several subprograms. Obvious examples for our IRQC is:
- Register access
- Signal checkers
- Interrupt source pulsing?
- Interrupt acknowledge pulsing?
- (Report/log method)
- (Alert-handling)
- (reset, set_passive, ...)

We've already created and declared set_passive and pulse procedures, but we could f.ex create overloads for UVVM procedures:
<pre>
-- Log overloads for simplification
procedure log(
msg : string) is
begin
log(ID_SEQUENCER, msg, C_SCOPE);
end;
</pre>

This exact function is already overloaded in the UVVM packages, so including this in our testbench would produce compilation errors. So, let's not include it, but view it as an example of how it's done.

Let's say that it is probable that we'll want to change the number of interrupt sources that the controller can handle. We will then want to able to easily change vectors to the appropriate size. One way is to declare procedures that can trim and fit vectors. This way we can simply change a constant to change the number of sources.

<pre>
subtype t_irq_source is std_logic_vector(C_NUM_SOURCES-1 downto 0);

-- Trim (cut) a given vector to fit the number of irq sources (i.e. pot. reduce width)
function trim(
constant source : std_logic_vector;
constant num_bits : positive := C_NUM_SOURCES)
return t_irq_source is
variable v_result : std_logic_vector(source'length-1 downto 0) := source;
begin
return v_result(num_bits-1 downto 0);
end;

-- Fit a given vector to the number of irq sources by masking with zeros above irq width
function fit(
constant source : std_logic_vector;
constant num_bits : positive := C_NUM_SOURCES)
return std_logic_vector is
variable v_result : std_logic_vector(source'length-1 downto 0) := (others => '0');
variable v_source : std_logic_vector(source'length-1 downto 0) := source;
begin
v_result(num_bits-1 downto 0) := v_source(num_bits-1 downto 0);
return v_result;
end;
</pre>

All IRQC-dedicated subprograms should be declared locally, but more common (f.ex bus-specific) should be declared in common package that can be shared with other.

== Register access ==
To access the IRQC's registers we need to go through the actual process of writing and reading data from them. Fortunately, Bitvis have already taken the responsibility of writing the BFM for the SBI. This doesn't mean that we doesn't have to understand what's going on, since we'll have to write our own BFM's for other buses that we use(Avalon, AXI, etc). '''January 2017 Bitvis announced that they released VVC for Avalon-MM and AXI4-lite.''' So we should investigate the BFM procedures. We want to check register values:
<pre>
procedure sbi_check (
constant addr_value : in unsigned;
constant data_exp : in std_logic_vector;
constant msg : in string;
signal clk : in std_logic;
signal cs : inout std_logic;
signal addr : inout unsigned;
signal rd : inout std_logic;
signal wr : inout std_logic;
signal ready : in std_logic;
signal rdata : in std_logic_vector;
constant alert_level : in t_alert_level := error;
constant scope : in string := C_SCOPE;
constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel;
constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT
) is
constant proc_name : string := "sbi_check";
constant proc_call : string := "sbi_check(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) &
", " & to_string(data_exp, HEX, AS_IS, INCL_RADIX) & ")";
-- Normalize to the DUT addr/data widths
variable v_normalised_addr : unsigned(addr'length-1 downto 0) :=
normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg);
-- Helper variables
variable v_data_value : std_logic_vector(rdata'length - 1 downto 0);
variable v_check_ok : boolean;
variable v_clk_cycles_waited : natural := 0;
begin
sbi_read(addr_value, v_data_value, msg, clk, cs, addr, rd, wr, ready, rdata, scope, msg_id_panel, config, proc_name);

-- Compare values, but ignore any leading zero's if widths are different.
-- Use ID_NEVER so that check_value method does not log when check is OK,
-- log it here instead.
v_check_ok := check_value(v_data_value, data_exp, alert_level, msg, scope, HEX_BIN_IF_INVALID, SKIP_LEADING_0, ID_NEVER, msg_id_panel, proc_call);
if v_check_ok then
log(config.id_for_bfm, proc_call & "=> OK, read data = " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel);
end if;
end procedure;
</pre>

We see that sbi_check() calls sbi_read() before it checks if the read value is the expected value.

<pre>
procedure sbi_read (
constant addr_value : in unsigned;
variable data_value : out std_logic_vector;
constant msg : in string;
signal clk : in std_logic;
signal cs : inout std_logic;
signal addr : inout unsigned;
signal rd : inout std_logic;
signal wr : inout std_logic;
signal ready : in std_logic;
signal rdata : in std_logic_vector;
constant scope : in string := C_SCOPE;
constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel;
constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT;
constant proc_name : in string := "sbi_read" -- overwrite if called from other procedure like sbi_check
) is
constant proc_call : string := "sbi_read(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ")";
-- Normalize to the DUT addr/data widths
variable v_normalised_addr : unsigned(addr'length-1 downto 0) :=
normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg);
variable v_data_value : std_logic_vector(data_value'range);
variable v_clk_cycles_waited : natural := 0;
begin
wait_until_given_time_after_rising_edge(clk, config.clock_period/4);
cs <= '1';
wr <= '0';
rd <= '1';
addr <= v_normalised_addr;
wait for config.clock_period;
while (config.use_ready_signal and ready = '0') loop
if v_clk_cycles_waited = 0 then
log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel);
end if;
wait for config.clock_period;
v_clk_cycles_waited := v_clk_cycles_waited + 1;
check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity,
": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call);
end loop;

cs <= '0';
rd <= '0';
v_data_value := rdata;
data_value := v_data_value;
if proc_name = "sbi_read" then
log(config.id_for_bfm, proc_call & "=> " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel);
else
-- Log will be handled by calling procedure (e.g. sbi_check)
end if;
end procedure;
</pre>

We don't want to (and probably shouldnt) call the sbi_check and providing all the parameters each time. Some of this can be solved by the overloads with more standard parameters, and with our own check procedures declared locally in our testbench:
<pre>
procedure check(
constant addr_value : in natural;
constant data_exp : in std_logic_vector;
constant alert_level : in t_alert_level;
constant msg : in string) is
begin
sbi_check(to_unsigned(addr_value, sbi_if.addr'length), data_exp, msg,
clk, sbi_if, alert_level, C_SCOPE);
end;
</pre>

The write procedure is also very handy and should be understood:
<pre>
procedure sbi_write (
constant addr_value : in unsigned;
constant data_value : in std_logic_vector;
constant msg : in string;
signal clk : in std_logic;
signal cs : inout std_logic;
signal addr : inout unsigned;
signal rd : inout std_logic;
signal wr : inout std_logic;
signal ready : in std_logic;
signal wdata : inout std_logic_vector;
constant scope : in string := C_SCOPE;
constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel;
constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT
) is
constant proc_name : string := "sbi_write";
constant proc_call : string := "sbi_write(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) &
", " & to_string(data_value, HEX, AS_IS, INCL_RADIX) & ")";
-- Normalise to the DUT addr/data widths
variable v_normalised_addr : unsigned(addr'length-1 downto 0) :=
normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg);
variable v_normalised_data : std_logic_vector(wdata'length-1 downto 0) :=
normalize_and_check(data_value, wdata, ALLOW_NARROWER, "data_value", "sbi_core_in.wdata", msg);
variable v_clk_cycles_waited : natural := 0;
begin
wait_until_given_time_after_rising_edge(clk, config.clock_period/4);
cs <= '1';
wr <= '1';
rd <= '0';
addr <= v_normalised_addr;
wdata <= v_normalised_data;

wait for config.clock_period;
while (config.use_ready_signal and ready = '0') loop
if v_clk_cycles_waited = 0 then
log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel);
end if;
wait for config.clock_period;
v_clk_cycles_waited := v_clk_cycles_waited + 1;
check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity,
": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call);
end loop;

cs <= '0';
wr <= '0';
log(config.id_for_bfm, proc_call & " completed. " & msg, scope, msg_id_panel);
end procedure;
</pre>

We will create a local overload of this too:
<pre>
procedure write(
constant addr_value : in natural;
constant data_value : in std_logic_vector;
constant msg : in string) is
begin
sbi_write(to_unsigned(addr_value, sbi_if.addr'length), data_value, msg,
clk, sbi_if, C_SCOPE);
end;
</pre>

We also need to set the sbi_if.ready signal high for this to work:
<pre>
clock_generator(clk, clock_ena, C_CLK_PERIOD, "IRQC TB clock");

-- Insert this here by the clock generator
sbi_if.ready <= '1'; -- always ready in the same clock cycle.
</pre>

All this enables us to handle transactions at a high level. See UVVM documentation for how to write your own BFM and what it should include(sanity checks, etc).

[[File:bfm.png|550px]]

== Checking register write and read ==
Now we're enabled to write to and read from the registers. The register addresses are defined in the IRQC package file irqc_pif_bkg.vhd. Notice that we also use the previously declared overloaded version of log() and fit().

<pre>
log(ID_LOG_HDR, "Check register defaults and access (write + read)", C_SCOPE);
------------------------------------------------------------
log("\nChecking Register defaults");
check(C_ADDR_IRR, x"00", ERROR, "IRR default");
check(C_ADDR_IER, x"00", ERROR, "IER default");
check(C_ADDR_IPR, x"00", ERROR, "IPR default");
check(C_ADDR_IRQ2CPU_ALLOWED, x"00", ERROR, "IRQ2CPU_ALLOWED default");

log("\nChecking Register Write/Read");
write(C_ADDR_IER, fit(x"55"), "IER");
check(C_ADDR_IER, fit(x"55"), ERROR, "IER pure readback");
write(C_ADDR_IER, fit(x"AA"), "IER");
check(C_ADDR_IER, fit(x"AA"), ERROR, "IER pure readback");
write(C_ADDR_IER, fit(x"00"), "IER");
check(C_ADDR_IER, fit(x"00"), ERROR, "IER pure readback");
</pre>

This check will give us a nice log if everything turns out ok:

[[File:sim2.png|700px]]

However, if there's an error:

[[File:error2.png|700px]]

== Further tests ==

Now that we've tested register read/write, we should test the trigger/clear mechanism. No further adding of procedures are necessary.
<pre>
log(ID_LOG_HDR, "Check register trigger/clear mechanism", C_SCOPE);
------------------------------------------------------------
write(C_ADDR_ITR, fit(x"AA"), "ITR : Set interrupts");
check(C_ADDR_IRR, fit(x"AA"), ERROR, "IRR");
write(C_ADDR_ITR, fit(x"55"), "ITR : Set more interrupts");
check(C_ADDR_IRR, fit(x"FF"), ERROR, "IRR");
write(C_ADDR_ICR, fit(x"71"), "ICR : Clear interrupts");
check(C_ADDR_IRR, fit(x"8E"), ERROR, "IRR");
write(C_ADDR_ICR, fit(x"85"), "ICR : Clear interrupts");
check(C_ADDR_IRR, fit(x"0A"), ERROR, "IRR");
write(C_ADDR_ITR, fit(x"55"), "ITR : Set more interrupts");
check(C_ADDR_IRR, fit(x"5F"), ERROR, "IRR");
write(C_ADDR_ICR, fit(x"5F"), "ICR : Clear interrupts");
check(C_ADDR_IRR, fit(x"00"), ERROR, "IRR");
</pre>

The UVVM Utility Library provides all necessary functions and procedures to do further tests. F.ex. we should send pulses on the irq_source signal to check if the design behaves correctly.

<pre>
log(ID_LOG_HDR, "Check interrupt sources, IER, IPR and irq2cpu", C_SCOPE);
------------------------------------------------------------
log("\nChecking interrupts and IRR");
write(C_ADDR_ICR, fit(x"FF"), "ICR : Clear all interrupts");
pulse(irq_source, trim(x"AA"), clk, 1, "Pulse irq_source 1T");
check(C_ADDR_IRR, fit(x"AA"), ERROR, "IRR after irq pulses");
pulse(irq_source, trim(x"01"), clk, 1, "Add more interrupts");
check(C_ADDR_IRR, fit(x"AB"), ERROR, "IRR after irq pulses");
pulse(irq_source, trim(x"A1"), clk, 1, "Repeat same interrupts");
check(C_ADDR_IRR, fit(x"AB"), ERROR, "IRR after irq pulses");
pulse(irq_source, trim(x"54"), clk, 1, "Add remaining interrupts");
check(C_ADDR_IRR, fit(x"FF"), ERROR, "IRR after irq pulses");
write(C_ADDR_ICR, fit(x"AA"), "ICR : Clear half the interrupts");
pulse(irq_source, trim(x"A0"), clk, 1, "Add more interrupts");
check(C_ADDR_IRR, fit(x"F5"), ERROR, "IRR after irq pulses");
write(C_ADDR_ICR, fit(x"FF"), "ICR : Clear all interrupts");
check(C_ADDR_IRR, fit(x"00"), ERROR, "IRR after clearing all");
</pre>

=== Check stable ===
Another test provided by UVVM is check_stable(). This function enables us to test if a signal is holding the same value for a minimum provided time. We must declare a variable that holds the time from which we want to test if the signal is stable:

<pre>
v_time_stamp := now; -- time from which irq2cpu should be stable off until triggered
</pre>

Later we're now able to test if the signal has been holding the same value the whole period:
<pre>
check_stable(irq2cpu, (now - v_time_stamp), ERROR, "No spikes allowed on irq2cpu", C_SCOPE);
</pre>

Remember to declare the variable in the process:

<pre>
variable v_time_stamp : time := 0 ns;
</pre>

=== Await value ===
To check if a signal gets the expected value within a specified time value we use await_vale(). The test below throws an error if irq2cpu doesn't obtain the value '1' within 0 ns(!). Therefore expected immediately:

<pre>
await_value(irq2cpu, '1', 0 ns, C_CLK_PERIOD, ERROR, "Interrupt expected immediately", C_SCOPE);
</pre>

=== Other useful functions ===

Check the UVVM Utility Library Quick Reference for syntax details.

==== await_change() ====
Expects and waits for a change on the given signal, inside a given time window.

==== check_value_in_range() ====
Throws an error of the signal value is outside the specified minimum and maximum values.

== UVVM VVC ==
Guide coming....

== UVVM LICENCE AGREEMENT ==
{{reflist}}

[[Category:Mikroelektronikk]]

Bitvis UVVM VHDL Verification Component Framework

2026-03-16T12:38:12Z

Nfyku: Updated some external references. Updated from Bitvis to UVVM framework

This wiki page is heavily based on the Powerpoint-presentation found [https://github.com/UVVM/UVVM/blob/master/uvvm_util/doc/Simple_TB_step_by_step.pps here].<ref>

Copyright 2025 UVVM
Licensed under the [http://www.apache.org/licenses/LICENSE-2.0 Apache License, Version 2.0 (the “License”)]

== Introduction ==
UVVM (Universal VHDL Verification Methodology) is a free and Open Source Methodology and Library for making very structured VHDL-based testbenches, examples and simulations scripts from the [https://github.com/UVVM/UVVM UVVM on github].

=== What's in the folders? ===
[[File:20160302215840!1.png|thumb]]

The download includes severals folders:
* bitvis_irqc - example VHDL design + testbench
* bitvis_uart - example VHDL design + testbench
* bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI)
* bitvis_vip_uart - VIP for UART TX and RX
* uvvm_util - UVVM utility library - sufficient for simple testbenches
* uvvm_vvc_framework - Framework for more advanced tutorials

=== IRQC ===
[[File:irqc.png|thumb]]
The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals.

[[File:irqc2.png|350px]]

== UVVM Utility Library - Testbench creation ==
Copy the folders bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files.
=== Generate TB entity with DUT instantiated ===
Our TB entity can in many cases be generated from several tools. Notepad++ (among other) supports plugins that enables copying an entity and pasting it as an instantiation, and also as a complete testbench template. However, we will change some of our signals so that they fit the VIP SBI BFM. The signals to and from the CPU will be converted to t_sbi_if record, which is a type that includes all the SBI signals (cs, addr, rd, wr, wdata, ready and rdata).

<pre>
--Standard libraries
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.numeric_std.all;

-- Library enabling control of the simulation from VHDL. Eg. std.env.stop
library STD;
use std.env.all;

-- Obviously the UVVM library
library uvvm_util;
context uvvm_util.uvvm_util_context;

-- We will use this library later when implementing the Bus Functional Model
-- Includes among much else the record type t_sbi_if and many functions
-- If other buses are used, you will have to change this library
library bitvis_vip_sbi;
use bitvis_vip_sbi.sbi_bfm_pkg.all;

-- This file includes definitions of everything from registers to record types
use work.irqc_pif_pkg.all;

-- Test case entity
entity irqc_tb is
end entity;

-- Test case architecture
architecture func of irqc_tb is

-- DSP interface and general control signals
signal clk : std_logic := '0';
signal arst : std_logic := '0';
-- CPU interface
-- t_sbi_if is from the verification IP SBI
-- init_sbi_if_signals initialize the inputs to 0 and the outputs to Z
signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8);

-- Interrupt related signals
signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0');
signal irq2cpu : std_logic := '0';
signal irq2cpu_ack : std_logic := '0';

begin

-----------------------------------------------------------------------------
-- Instantiate DUT
-----------------------------------------------------------------------------
i_irqc: entity work.irqc
port map (
-- DSP interface and general control signals
clk => clk,
arst => arst,
-- CPU interface
cs => sbi_if.cs, -- NOTICE THE SIGNALS ARE NOW SBI_IF
addr => sbi_if.addr,
wr => sbi_if.wena,
rd => sbi_if.rena,
din => sbi_if.wdata,
dout => sbi_if.rdata,
-- Interrupt related signals
irq_source => irq_source,
irq2cpu => irq2cpu,
irq2cpu_ack => irq2cpu_ack
);

end func;
</pre>

=== Add support process for clock generation ===
We now have to add a support process that controls the clock. This has to allow enabling/disabling from the test sequencer. We add the following before "begin" in our architecture:
<pre>
-- Added for clock generation
signal clock_ena : boolean := false;

constant C_CLK_PERIOD : time := 10 ns;

procedure clock_gen(
signal clock_signal : inout std_logic;
signal clock_ena : in boolean;
constant clock_period : in time
) is
variable v_first_half_clk_period : time := C_CLK_PERIOD / 2;
begin
loop
if not clock_ena then
wait until clock_ena;
end if;
wait for v_first_half_clk_period;
clock_signal <= not clock_signal;
wait for (clock_period - v_first_half_clk_period);
clock_signal <= not clock_signal;
end loop;
end;
</pre>

Our clock can now be activated from the test sequencer (this will be added in the next step):
<pre>
-- After begin in the architecture
clock_gen(clk, clock_ena, C_CLK_PERIOD);

-- Inside the test sequencer process
clock_ena <= true;
</pre>

=== Add test sequencer process ===
The next step is to add the test sequencer process. This process controls everything from initialization to termination of the simulation.

<pre>
-- Set upt clock generator
clock_gen(clk, clock_ena, C_CLK_PERIOD);

------------------------------------------------
-- PROCESS: p_main
------------------------------------------------
p_main : process
-- The scope tells you where log messages originates - C_SCOPE tells us they originate from the default test sequencer scope
constant C_SCOPE : string := C_TB_SCOPE_DEFAULT;
-- This is where we will add some procedures later to simplify the tests

begin

--Print the configuration to the log
report_global_ctrl(VOID);
report_msg_id_panel(VOID);

enable_log_msg(ALL_MESSAGES);
--disable_log_msg
--enable_log_msg(ID_LOG_HDR);

log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE);
------------------------------------------------------------
clock_ena <= true; -- to start clock generator

------------------------------------------------------------
-- End the simulation
wait for 1000 ns; -- to allow some time for completion
report_alert_counters(FINAL); -- Report final counters and print conclusion for simulation (Success/Fail)
log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE);

--Finish the simulation
std.env.stop;
wait; -- to stop completely
end process p_main;
</pre>

==Simulation==
We now have the skeleton of the testbench, which we will develop further. But now, let's see if everything works. UVVM includes simulation scripts for the IRQC example that compiles everything we need, from the source files of the VHDL design, to the testbench (if you called the file irqc_tb.vhd and placed it in the tb-folder) and the SBI BFM and the UVVM library. Open up QuestaSim/ModelSim.
Change directory to the script folder (where you have copied the UVVM files), for example in phys321/bitviswiki.....:
<pre>
cd ~/phys321/bitviswiki/bitvis_irqc/script
do compile_and_sim_all.do
</pre>

This will present our result in the transcript windows, but also write _Log.txt file which includes all the information we have asked for. We see that we get the results from the following code:
<pre>
report_global_ctrl(VOID);
report_msg_id_panel(VOID);
enable_log_msg(ALL_MESSAGES);
log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE);
report_alert_counters(FINAL);
log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE);
</pre>
Commenting these out will result in an empty log.

== Verbosity control ==
We want to able to control the amount of information in our logs, and the framework enables us to prioritize messages based on ID. This makes it easy to turn on or off the information we want.
To turn on a specific ID
<pre>
enable_log_msg(IDNAME);
</pre>

Turn off:
<pre>
disable_log_msg(IDNAME);
</pre>

For writing a message to a certain log ID:
<pre>
log(IDNAME, "MESSAGE HERE", C_SCOPE);
</pre>
Remember that C_SCOPE just tells us that the message originated from the default scope and will look like "TB seq." in the log file.

Exampled IDs:
* ID_LOG_HDR, -- ONLY allowed in test sequencer, Log section headers
* ID_SEQUENCER, -- ONLY allowed in test sequencer, Normal log (not log headers)
* ID_BFM, -- Used inside a BFM (to log BFM access)
* ID_CLOCK_GEN, -- Used for logging when clock generators are enabled or disabled
* ALL_MESSAGES -- Applies to ALL message ID apart from ID_NEVER

You'll find all the different ID's in the UVVM Utility Library Quick Reference or defined in uvvm_util/adaptions_pkg.vhd. This also where C_TB_SCOPE_DEFAULT is defined.

== Implement first tests ==
[[File:tb.png|thumb|upright=0.35]]
We want to check and verify that our testbench is up and running and to verify our first tests of the DUT. This means that we have to able to set all our signals passive, apply a reset signal and then check the default outputs of the DUT.

Instead of setting all our signals passive one-by-one in our test sequencer we declare a procedure in our p_main process(this is done before begin):
<pre>
procedure set_inputs_passive(
dummy : t_void) is --dummy variable is included only to allow calling the procedure with parenthesis for readability
begin
sbi_if.cs <= '0';
sbi_if.addr <= (others => '0');
sbi_if.wena <= '0';
sbi_if.rena <= '0';
sbi_if.wdata <= (others => '0');
irq_source <= (others => '0');
irq2cpu_ack <= '0';
log(ID_SEQUENCER_SUB, "All inputs set passive", C_SCOPE);
end;
</pre>

Note that the procedure declaration also includes a dummy variable parameter. This means that we will be able to call the procedure with the more readable:

<pre>
set_inputs_passive(VOID);
</pre>

Rather than:
<pre>
set_inputs_passive;
</pre>
which is more ambigious.

We may also would like to send pulses on different signals, f.ex. sending a pulse on our reset to see if it behaves like intended. We therefore can include a pulse procedure:
<pre>
procedure pulse(
signal target : inout std_logic_vector;
constant pulse_value : in std_logic_vector;
signal clock_signal : in std_logic;
constant num_periods : in natural;
constant msg : in string) is
begin
if num_periods > 0 then
wait until falling_edge(clock_signal);
target <= pulse_value;
for i in 1 to num_periods loop
wait until falling_edge(clock_signal);
end loop;
else
target <= pulse_value;
wait for 0 ns; -- Delta cycle only
end if;
target(target'range) <= (others => '0');
log(ID_SEQUENCER_SUB, "Pulsed to " & to_string(pulse_value, HEX, AS_IS, INCL_RADIX) & ". " & msg, C_SCOPE);
end;
</pre>

In the above example the test sequencer is required to inform the procedure of what value the pulse is to take. The call to the procedure would take the following form:
<pre>
pulse(arst, 'Z', clk, 10, "Log message - Im pulsing the value 'Z'");
</pre>
But a more specific overload can be created where pulse always takes value '1':
<pre>
procedure pulse(
signal target : inout std_logic;
signal clock_signal : in std_logic;
constant num_periods : in natural;
constant msg : in string
) is
begin
if num_periods > 0 then
wait until falling_edge(clock_signal);
target <= '1';
for i in 1 to num_periods loop
wait until falling_edge(clock_signal);
end loop;
else
target <= '1';
wait for 0 ns; -- Delta cycle only
end if;
target <= '0';
log(ID_SEQUENCER_SUB, msg, C_SCOPE);
end;
</pre>

These procedures can now be called directly from our test sequence:
<pre>
set_inputs_passive(VOID);
pulse(arst, clk, 10, "pulsed reset-signal - active for 10T");
</pre>

To check signal values we can use the built-in check function check_value():
<pre>
check_value(irq2cpu, 'X', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE);
</pre>
The above call checks if the signal irq2cpu is 'X', and obviously fail if everything works correctly and gives the following message:

[[File:error.png|700px]]

If we want we can change the number of errors logged before the simulation stops:
<pre>
set_alert_stop_limit(ERROR, 3);
</pre>

We now have all the tools needed for the first tests in our sequencer:
<pre>
set_inputs_passive(VOID);
pulse(arst, clk, 10, "Pulsed reset-signal - active for 10T");

check_value(C_NUM_SOURCES > 0, FAILURE, "Must be at least 1 interrupt source", C_SCOPE);
check_value(C_NUM_SOURCES <= 8, TB_WARNING, "This TB is only checking IRQC with up to 8 interrupt sources", C_SCOPE);

log(ID_LOG_HDR, "Check defaults on output ports", C_SCOPE);
------------------------------------------------------------
check_value(irq2cpu, '0', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE);
check_value(sbi_if.rdata, x"00", ERROR, "Register data bus output must be default passive");
</pre>

This will give us the following log:

[[File:sim.png|800px]]

This information may only interesting initially and for debug, and can be turned on or off by use of ID.

== Subprograms ==
Some of our testbench code will be repeated several times and the testbench may therefore benefit from creating several subprograms. Obvious examples for our IRQC is:
- Register access
- Signal checkers
- Interrupt source pulsing?
- Interrupt acknowledge pulsing?
- (Report/log method)
- (Alert-handling)
- (reset, set_passive, ...)

We've already created and declared set_passive and pulse procedures, but we could f.ex create overloads for UVVM procedures:
<pre>
-- Log overloads for simplification
procedure log(
msg : string) is
begin
log(ID_SEQUENCER, msg, C_SCOPE);
end;
</pre>

This exact function is already overloaded in the UVVM packages, so including this in our testbench would produce compilation errors. So, let's not include it, but view it as an example of how it's done.

Let's say that it is probable that we'll want to change the number of interrupt sources that the controller can handle. We will then want to able to easily change vectors to the appropriate size. One way is to declare procedures that can trim and fit vectors. This way we can simply change a constant to change the number of sources.

<pre>
subtype t_irq_source is std_logic_vector(C_NUM_SOURCES-1 downto 0);

-- Trim (cut) a given vector to fit the number of irq sources (i.e. pot. reduce width)
function trim(
constant source : std_logic_vector;
constant num_bits : positive := C_NUM_SOURCES)
return t_irq_source is
variable v_result : std_logic_vector(source'length-1 downto 0) := source;
begin
return v_result(num_bits-1 downto 0);
end;

-- Fit a given vector to the number of irq sources by masking with zeros above irq width
function fit(
constant source : std_logic_vector;
constant num_bits : positive := C_NUM_SOURCES)
return std_logic_vector is
variable v_result : std_logic_vector(source'length-1 downto 0) := (others => '0');
variable v_source : std_logic_vector(source'length-1 downto 0) := source;
begin
v_result(num_bits-1 downto 0) := v_source(num_bits-1 downto 0);
return v_result;
end;
</pre>

All IRQC-dedicated subprograms should be declared locally, but more common (f.ex bus-specific) should be declared in common package that can be shared with other.

== Register access ==
To access the IRQC's registers we need to go through the actual process of writing and reading data from them. Fortunately, Bitvis have already taken the responsibility of writing the BFM for the SBI. This doesn't mean that we doesn't have to understand what's going on, since we'll have to write our own BFM's for other buses that we use(Avalon, AXI, etc). '''January 2017 Bitvis announced that they released VVC for Avalon-MM and AXI4-lite.''' So we should investigate the BFM procedures. We want to check register values:
<pre>
procedure sbi_check (
constant addr_value : in unsigned;
constant data_exp : in std_logic_vector;
constant msg : in string;
signal clk : in std_logic;
signal cs : inout std_logic;
signal addr : inout unsigned;
signal rd : inout std_logic;
signal wr : inout std_logic;
signal ready : in std_logic;
signal rdata : in std_logic_vector;
constant alert_level : in t_alert_level := error;
constant scope : in string := C_SCOPE;
constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel;
constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT
) is
constant proc_name : string := "sbi_check";
constant proc_call : string := "sbi_check(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) &
", " & to_string(data_exp, HEX, AS_IS, INCL_RADIX) & ")";
-- Normalize to the DUT addr/data widths
variable v_normalised_addr : unsigned(addr'length-1 downto 0) :=
normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg);
-- Helper variables
variable v_data_value : std_logic_vector(rdata'length - 1 downto 0);
variable v_check_ok : boolean;
variable v_clk_cycles_waited : natural := 0;
begin
sbi_read(addr_value, v_data_value, msg, clk, cs, addr, rd, wr, ready, rdata, scope, msg_id_panel, config, proc_name);

-- Compare values, but ignore any leading zero's if widths are different.
-- Use ID_NEVER so that check_value method does not log when check is OK,
-- log it here instead.
v_check_ok := check_value(v_data_value, data_exp, alert_level, msg, scope, HEX_BIN_IF_INVALID, SKIP_LEADING_0, ID_NEVER, msg_id_panel, proc_call);
if v_check_ok then
log(config.id_for_bfm, proc_call & "=> OK, read data = " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel);
end if;
end procedure;
</pre>

We see that sbi_check() calls sbi_read() before it checks if the read value is the expected value.

<pre>
procedure sbi_read (
constant addr_value : in unsigned;
variable data_value : out std_logic_vector;
constant msg : in string;
signal clk : in std_logic;
signal cs : inout std_logic;
signal addr : inout unsigned;
signal rd : inout std_logic;
signal wr : inout std_logic;
signal ready : in std_logic;
signal rdata : in std_logic_vector;
constant scope : in string := C_SCOPE;
constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel;
constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT;
constant proc_name : in string := "sbi_read" -- overwrite if called from other procedure like sbi_check
) is
constant proc_call : string := "sbi_read(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ")";
-- Normalize to the DUT addr/data widths
variable v_normalised_addr : unsigned(addr'length-1 downto 0) :=
normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg);
variable v_data_value : std_logic_vector(data_value'range);
variable v_clk_cycles_waited : natural := 0;
begin
wait_until_given_time_after_rising_edge(clk, config.clock_period/4);
cs <= '1';
wr <= '0';
rd <= '1';
addr <= v_normalised_addr;
wait for config.clock_period;
while (config.use_ready_signal and ready = '0') loop
if v_clk_cycles_waited = 0 then
log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel);
end if;
wait for config.clock_period;
v_clk_cycles_waited := v_clk_cycles_waited + 1;
check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity,
": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call);
end loop;

cs <= '0';
rd <= '0';
v_data_value := rdata;
data_value := v_data_value;
if proc_name = "sbi_read" then
log(config.id_for_bfm, proc_call & "=> " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel);
else
-- Log will be handled by calling procedure (e.g. sbi_check)
end if;
end procedure;
</pre>

We don't want to (and probably shouldnt) call the sbi_check and providing all the parameters each time. Some of this can be solved by the overloads with more standard parameters, and with our own check procedures declared locally in our testbench:
<pre>
procedure check(
constant addr_value : in natural;
constant data_exp : in std_logic_vector;
constant alert_level : in t_alert_level;
constant msg : in string) is
begin
sbi_check(to_unsigned(addr_value, sbi_if.addr'length), data_exp, msg,
clk, sbi_if, alert_level, C_SCOPE);
end;
</pre>

The write procedure is also very handy and should be understood:
<pre>
procedure sbi_write (
constant addr_value : in unsigned;
constant data_value : in std_logic_vector;
constant msg : in string;
signal clk : in std_logic;
signal cs : inout std_logic;
signal addr : inout unsigned;
signal rd : inout std_logic;
signal wr : inout std_logic;
signal ready : in std_logic;
signal wdata : inout std_logic_vector;
constant scope : in string := C_SCOPE;
constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel;
constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT
) is
constant proc_name : string := "sbi_write";
constant proc_call : string := "sbi_write(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) &
", " & to_string(data_value, HEX, AS_IS, INCL_RADIX) & ")";
-- Normalise to the DUT addr/data widths
variable v_normalised_addr : unsigned(addr'length-1 downto 0) :=
normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg);
variable v_normalised_data : std_logic_vector(wdata'length-1 downto 0) :=
normalize_and_check(data_value, wdata, ALLOW_NARROWER, "data_value", "sbi_core_in.wdata", msg);
variable v_clk_cycles_waited : natural := 0;
begin
wait_until_given_time_after_rising_edge(clk, config.clock_period/4);
cs <= '1';
wr <= '1';
rd <= '0';
addr <= v_normalised_addr;
wdata <= v_normalised_data;

wait for config.clock_period;
while (config.use_ready_signal and ready = '0') loop
if v_clk_cycles_waited = 0 then
log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel);
end if;
wait for config.clock_period;
v_clk_cycles_waited := v_clk_cycles_waited + 1;
check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity,
": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call);
end loop;

cs <= '0';
wr <= '0';
log(config.id_for_bfm, proc_call & " completed. " & msg, scope, msg_id_panel);
end procedure;
</pre>

We will create a local overload of this too:
<pre>
procedure write(
constant addr_value : in natural;
constant data_value : in std_logic_vector;
constant msg : in string) is
begin
sbi_write(to_unsigned(addr_value, sbi_if.addr'length), data_value, msg,
clk, sbi_if, C_SCOPE);
end;
</pre>

We also need to set the sbi_if.ready signal high for this to work:
<pre>
clock_generator(clk, clock_ena, C_CLK_PERIOD, "IRQC TB clock");

-- Insert this here by the clock generator
sbi_if.ready <= '1'; -- always ready in the same clock cycle.
</pre>

All this enables us to handle transactions at a high level. See UVVM documentation for how to write your own BFM and what it should include(sanity checks, etc).

[[File:bfm.png|550px]]

== Checking register write and read ==
Now we're enabled to write to and read from the registers. The register addresses are defined in the IRQC package file irqc_pif_bkg.vhd. Notice that we also use the previously declared overloaded version of log() and fit().

<pre>
log(ID_LOG_HDR, "Check register defaults and access (write + read)", C_SCOPE);
------------------------------------------------------------
log("\nChecking Register defaults");
check(C_ADDR_IRR, x"00", ERROR, "IRR default");
check(C_ADDR_IER, x"00", ERROR, "IER default");
check(C_ADDR_IPR, x"00", ERROR, "IPR default");
check(C_ADDR_IRQ2CPU_ALLOWED, x"00", ERROR, "IRQ2CPU_ALLOWED default");

log("\nChecking Register Write/Read");
write(C_ADDR_IER, fit(x"55"), "IER");
check(C_ADDR_IER, fit(x"55"), ERROR, "IER pure readback");
write(C_ADDR_IER, fit(x"AA"), "IER");
check(C_ADDR_IER, fit(x"AA"), ERROR, "IER pure readback");
write(C_ADDR_IER, fit(x"00"), "IER");
check(C_ADDR_IER, fit(x"00"), ERROR, "IER pure readback");
</pre>

This check will give us a nice log if everything turns out ok:

[[File:sim2.png|700px]]

However, if there's an error:

[[File:error2.png|700px]]

== Further tests ==

Now that we've tested register read/write, we should test the trigger/clear mechanism. No further adding of procedures are necessary.
<pre>
log(ID_LOG_HDR, "Check register trigger/clear mechanism", C_SCOPE);
------------------------------------------------------------
write(C_ADDR_ITR, fit(x"AA"), "ITR : Set interrupts");
check(C_ADDR_IRR, fit(x"AA"), ERROR, "IRR");
write(C_ADDR_ITR, fit(x"55"), "ITR : Set more interrupts");
check(C_ADDR_IRR, fit(x"FF"), ERROR, "IRR");
write(C_ADDR_ICR, fit(x"71"), "ICR : Clear interrupts");
check(C_ADDR_IRR, fit(x"8E"), ERROR, "IRR");
write(C_ADDR_ICR, fit(x"85"), "ICR : Clear interrupts");
check(C_ADDR_IRR, fit(x"0A"), ERROR, "IRR");
write(C_ADDR_ITR, fit(x"55"), "ITR : Set more interrupts");
check(C_ADDR_IRR, fit(x"5F"), ERROR, "IRR");
write(C_ADDR_ICR, fit(x"5F"), "ICR : Clear interrupts");
check(C_ADDR_IRR, fit(x"00"), ERROR, "IRR");
</pre>

The UVVM Utility Library provides all necessary functions and procedures to do further tests. F.ex. we should send pulses on the irq_source signal to check if the design behaves correctly.

<pre>
log(ID_LOG_HDR, "Check interrupt sources, IER, IPR and irq2cpu", C_SCOPE);
------------------------------------------------------------
log("\nChecking interrupts and IRR");
write(C_ADDR_ICR, fit(x"FF"), "ICR : Clear all interrupts");
pulse(irq_source, trim(x"AA"), clk, 1, "Pulse irq_source 1T");
check(C_ADDR_IRR, fit(x"AA"), ERROR, "IRR after irq pulses");
pulse(irq_source, trim(x"01"), clk, 1, "Add more interrupts");
check(C_ADDR_IRR, fit(x"AB"), ERROR, "IRR after irq pulses");
pulse(irq_source, trim(x"A1"), clk, 1, "Repeat same interrupts");
check(C_ADDR_IRR, fit(x"AB"), ERROR, "IRR after irq pulses");
pulse(irq_source, trim(x"54"), clk, 1, "Add remaining interrupts");
check(C_ADDR_IRR, fit(x"FF"), ERROR, "IRR after irq pulses");
write(C_ADDR_ICR, fit(x"AA"), "ICR : Clear half the interrupts");
pulse(irq_source, trim(x"A0"), clk, 1, "Add more interrupts");
check(C_ADDR_IRR, fit(x"F5"), ERROR, "IRR after irq pulses");
write(C_ADDR_ICR, fit(x"FF"), "ICR : Clear all interrupts");
check(C_ADDR_IRR, fit(x"00"), ERROR, "IRR after clearing all");
</pre>

=== Check stable ===
Another test provided by UVVM is check_stable(). This function enables us to test if a signal is holding the same value for a minimum provided time. We must declare a variable that holds the time from which we want to test if the signal is stable:

<pre>
v_time_stamp := now; -- time from which irq2cpu should be stable off until triggered
</pre>

Later we're now able to test if the signal has been holding the same value the whole period:
<pre>
check_stable(irq2cpu, (now - v_time_stamp), ERROR, "No spikes allowed on irq2cpu", C_SCOPE);
</pre>

Remember to declare the variable in the process:

<pre>
variable v_time_stamp : time := 0 ns;
</pre>

=== Await value ===
To check if a signal gets the expected value within a specified time value we use await_vale(). The test below throws an error if irq2cpu doesn't obtain the value '1' within 0 ns(!). Therefore expected immediately:

<pre>
await_value(irq2cpu, '1', 0 ns, C_CLK_PERIOD, ERROR, "Interrupt expected immediately", C_SCOPE);
</pre>

=== Other useful functions ===

Check the UVVM Utility Library Quick Reference for syntax details.

==== await_change() ====
Expects and waits for a change on the given signal, inside a given time window.

==== check_value_in_range() ====
Throws an error of the signal value is outside the specified minimum and maximum values.

== UVVM VVC ==
Guide coming....

== UVVM LICENCE AGREEMENT ==
{{reflist}}

[[Category:Mikroelektronikk]]

Main Page

2026-02-18T13:54:55Z

Nfyku: Fjernet Teknisk avdeling lenke siden den ikke er i bruk

=Velkommen til [http://www.uib.no/ift Institutt for Fysikk og Teknologis]Wiki=

* [[DAMARA]]
* [[Detector lab]]
* [[Cherenkov Telescope Array - Norway]]
* [[Eksperimentalfysikk med prosjektoppgave - PHYS117]]
* [[Experimental Nuclear Physics group]]
* [[Microelectronics group]]
* [http://wiki.uib.no/nanolab Nano Lab]
* [[Particle Physics group]]
* [[GRIEG project "EarlyUniverse"]]
* [[Strålevern]]

== Komme i gang ==

* [[Få tilgang til å opprette eller redigere sider i wikien]]
* [http://meta.wikimedia.org/wiki/Help:Contents User's Guide]
* [http://www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ]
* [http://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list]

Simulering av VHDL

2026-01-19T10:48:26Z

Nfyku:

===Konstruksjon og simulering av VHDL-kode med Modelsim/Questa===

==Innledning==

Hensikten med denne oppgaven er å få et lite innblikk i bruk av høynivåspråk for simulering og uttesting av kretsløsninger. I denne oppgaven skal vi bruker VHDL (Very high speed integrated circuit Hardware Description Language), som er spesielt utviklet for elektronikk. VHDL er definert slik at det passer i en mengde sammenhenger, og er det vil derfor være uoverkommelig å gå inn på detaljer i denne oppgaven. Vi skal ta for oss noen eksempler:

* Eksempel 1: Signalflyt i en SR-lås

* Eksempel 2: Signaler og variable

Et VHDL program består i hovedsak av ENTITY, som definerer tilkobling mellom programmet og omverden, og ARCHITECTURE, som definerer programmets funksjon. Den komplette VHDL-koden for eksempel 1 vist nederst på denne siden.Mentor Graphics har utviklet programvare (Modelsim//Questa) som gjør det mulig å beskrivem, simulere og feilsøke VHDL-kode. Fremgangsmåten for skriving, kompilering og simulering av VHDL-kode finner du under.

==Starte Questa Sim==
Når man skal arbeide med Questa Sim fra Mentor Graphics skriv følgende kommando i et terminalvindu.
Generelt ligger programvaren i /eda/Siemens, og versjonene ligger i mapper sortert på årstall.

ssh -X mikroserver4
export SALT_LICENSE_SERVER="Sett inn rett lisensserver og port her"
source /eda/Siemens/2025-26/scripts/QUESTA-ONE-SIM_2025.3_RHELx86.sh
vsim &

==Lage et nytt prosjekt==

I den følgende teksten er det vist hvordan man kan utføre kompilering, etc. på kommandolinjen. Dette kan enten gjøres i fra X terminalvinduet, eller fra kommandolinjen i Questa. Hvis man velger å bruke Questa-miljøet er de fleste prosedyrer/kommandoer tilgjengelige under menyen.

Start et nytt prosjekt med

<pre>
File > New > Project
</pre>

[[Image:questa_new_project.png]]

Velg et fornuftig navn og katalog. Man kan gjerne ha flere uavhengige vhdl-filer i et prosjekt.
Det er en fordel å ha en hovedkatalog til vhdl prosjektene og en underkatalog for prosjektet fex /home/bruker/vhdl_prosjekt/sr_latch

==Skriving av VHDL kode==

En ny VHDL kode (et design beskrevet med VHDL kode) påbegynnes med å starte emacs i terminal vinduet eller ved å bruke den innebygde teksteditoren i Questa ved å velge Create New File.

Det fine med emacs er at man kan velge VHDL-modus. Dette gjøres med å skrive ''M-x vhdl-mode'' (M står for ''Meta'' og er vanligvis definert som esc-knappen). I emacs har en menyer med alle valg oppe langs kanten som i andre teksteditorer, men programmet skiller seg litt ut med kommandolinjen nederst i vinduet. Når en f. eks. skal lagre filen en har skrevet blir denne kommandolinjen aktiv og en skriver inn sti og filnavn der. Når man lagrer er ikke navnet på kodefilen viktig, men det er fornuftig å kalle den det samme som ENTITY-delen, med ''.vhdl'' som "etternavn" (f. eks. sr_latch.vhdl).

==Kompilering av VHDL kode==

Koden kompileres med

<pre>
vcom sr_latch.vhdl
</pre>

Hvis det er feil i koden vil det komme en melding i kommando vinduet. Dobbeltklikker du på feilen vil du få opp en liste over kompileringsprosessen og alle feilene. Dobbeltklikker du så på linjen som angir en feil så vises den respektive linjen i editoren.

Merk at navnet til det kompilerte designet blir skrevet med små bokstaver, selv om du har brukt store bokstaver i ENTITY- eller ARCHITECTURE-navnet. Det kompilerte designet blir liggende i work-katalogen.

==Simulering og debugging i Questa==

Når koden kompilerer feilfritt kan den simuleres i Questa. Dette startes med:

<pre>
vsim
</pre>

Nå dukker det opp en rute der du skal velge hva som skal simuleres, utvid work og velg vhdl filen. Eventuellt kan du skrive vsim work.sr_latch i kommandovinduet

Questa bruker et standard X-basert vindusoppsett, og er derfor noen forskjellig fra de andre Mentor-programmene. Når du starter simulatoren åpnes det et vindu som vist i figur 1. Begynn med å åpne diverse vinduer:

* View > Wave

* View > Objects

* View > Locals

Man kan også gi kommandoer i Questa-vinduet. F.eks.

<pre>
wave *
</pre>

Dra de signalene du vil se på i wave vinduet fra object vinduet.

Signalverdier settes med kommandoen 'force' eller med

<pre>
force > Force (i "Signals" vinduet)
</pre>

Dersom et av signalene skal være klokkesignal, kan dette gjøres enkelt med

<pre>
force > Clock (i "Signals" vinduet)
</pre>

==Eksempler==
===Signalflyt i en SR-lås===

Simuler SR-låsen. Begynn med å påtrykke stimuli til alle signaler ved tid 0 (t0). Bruk STEP-knappen for å simulere på delta-tid-nivå. (Om en holder musepekeren over knappene i Questa, kommer det en forklarende tekst opp.) Når verdiene er stabile kjører du i f.eks. 100 ns før du endrer stimuli (skriv ''run 100'' i et av vinduene). Tilsvarende kan du endre stimuli ved å skrive f.eks. ''force S 0'' i hoved-vinduet. Legg merke til den røde pilen som peker på den linjen som blir utført.

Hvis du vil begynne på ny kan du velge

<pre>
File > restart -f
</pre>

<pre>
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;

ENTITY SR_latch IS
PORT (
S : IN std_logic ;
R : IN std_logic ;
Q : INOUT std_logic ;
QB : INOUT std_logic );
END SR_latch;

ARCHITECTURE behave OF SR_latch IS

BEGIN -- behave
Q <= S nand QB;
QB <= R nand Q;
END behave;
</pre>

===Signaler og variable===

Simuler VHDL-koden under. Bruk Step eller Step Over for å følge prosedyrens utvikling linje for linje. Simulere med optimaliseringsopsjon "-voptargs=+acc" for å kunne se variablene i wave-vinduet:

vsim -voptargs=+acc sign_var

Bruk View > Objects for å kikke på signalene og View > Local for å se innholdet i variablene. Forklar endringene i signaler og variable. Hva er forskjellen som funksjon av tid/delta-tid?

<pre>
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;

ENTITY sign_var IS
PORT (clk : IN std_logic);
END sign_var;

ARCHITECTURE difference OF sign_var IS

signal SA: bit := '0';
signal SB: bit := '1';

begin -- difference
p_test: process
variable A: bit := '0';
variable B: bit := '1';
begin
wait until rising_edge(clk);
A := B;
B := A;
SA <= SB after 5 ns;
SB <= SA after 5 ns;
end process p_test;
end architecture difference;
</pre>

Simulering av VHDL

2026-01-19T10:46:09Z

Nfyku: /* Signalflyt i en SR-lås */

===Konstruksjon og simulering av VHDL-kode med Modelsim/Questa===

==Innledning==

Hensikten med denne oppgaven er å få et lite innblikk i bruk av høynivåspråk for simulering og uttesting av kretsløsninger. I denne oppgaven skal vi bruker VHDL (Very high speed integrated circuit Hardware Description Language), som er spesielt utviklet for elektronikk. VHDL er definert slik at det passer i en mengde sammenhenger, og er det vil derfor være uoverkommelig å gå inn på detaljer i denne oppgaven. Vi skal ta for oss noen eksempler:

* Eksempel 1: Signalflyt i en SR-lås

* Eksempel 2: Signaler og variable

Et VHDL program består i hovedsak av ENTITY, som definerer tilkobling mellom programmet og omverden, og ARCHITECTURE, som definerer programmets funksjon. Den komplette VHDL-koden for eksempel 1 vist nederst på denne siden.Mentor Graphics har utviklet programvare (Modelsim//Questa) som gjør det mulig å beskrivem, simulere og feilsøke VHDL-kode. Fremgangsmåten for skriving, kompilering og simulering av VHDL-kode finner du under.

==Starte Questa Sim==
Når man skal arbeide med Questa Sim fra Mentor Graphics skriv følgende kommando i et terminalvindu.
Generelt ligger programvaren i /eda/Siemens, og versjonene ligger i mapper sortert på årstall.

ssh -X mikroserver4
export SALT_LICENSE_SERVER="Sett inn rett lisensserver og port her"
source /eda/Siemens/2025-26/scripts/QUESTA-ONE-SIM_2025.3_RHELx86.sh
vsim &

==Lage et nytt prosjekt==

I den følgende teksten er det vist hvordan man kan utføre kompilering, etc. på kommandolinjen. Dette kan enten gjøres i fra X terminalvinduet, eller fra kommandolinjen i Questa. Hvis man velger å bruke Questa-miljøet er de fleste prosedyrer/kommandoer tilgjengelige under menyen.

Start et nytt prosjekt med

<pre>
File > New > Project
</pre>

[[Image:questa_new_project.png]]

Velg et fornuftig navn og katalog. Man kan gjerne ha flere uavhengige vhdl-filer i et prosjekt.
Det er en fordel å ha en hovedkatalog til vhdl prosjektene og en underkatalog for prosjektet fex /home/bruker/vhdl_prosjekt/sr_latch

==Skriving av VHDL kode==

En ny VHDL kode (et design beskrevet med VHDL kode) påbegynnes med å starte emacs i terminal vinduet eller ved å bruke den innebygde teksteditoren i Questa ved å velge Create New File.

Det fine med emacs er at man kan velge VHDL-modus. Dette gjøres med å skrive ''M-x vhdl-mode'' (M står for ''Meta'' og er vanligvis definert som esc-knappen). I emacs har en menyer med alle valg oppe langs kanten som i andre teksteditorer, men programmet skiller seg litt ut med kommandolinjen nederst i vinduet. Når en f. eks. skal lagre filen en har skrevet blir denne kommandolinjen aktiv og en skriver inn sti og filnavn der. Når man lagrer er ikke navnet på kodefilen viktig, men det er fornuftig å kalle den det samme som ENTITY-delen, med ''.vhdl'' som "etternavn" (f. eks. sr_latch.vhdl).

==Kompilering av VHDL kode==

Koden kompileres med

<pre>
vcom sr_latch.vhdl
</pre>

Hvis det er feil i koden vil det komme en melding i kommando vinduet. Dobbeltklikker du på feilen vil du få opp en liste over kompileringsprosessen og alle feilene. Dobbeltklikker du så på linjen som angir en feil så vises den respektive linjen i editoren.

Merk at navnet til det kompilerte designet blir skrevet med små bokstaver, selv om du har brukt store bokstaver i ENTITY- eller ARCHITECTURE-navnet. Det kompilerte designet blir liggende i work-katalogen.

==Simulering og debugging i Questa==

Når koden kompilerer feilfritt kan den simuleres i Questa. Dette startes med:

<pre>
vsim
</pre>

Nå dukker det opp en rute der du skal velge hva som skal simuleres, utvid work og velg vhdl filen. Eventuellt kan du skrive vsim work.sr_latch i kommandovinduet

Questa bruker et standard X-basert vindusoppsett, og er derfor noen forskjellig fra de andre Mentor-programmene. Når du starter simulatoren åpnes det et vindu som vist i figur 1. Begynn med å åpne diverse vinduer:

* View > Wave

* View > Objects

* View > Locals

Man kan også gi kommandoer i Questa-vinduet. F.eks.

<pre>
Wave *
</pre>

Dra de signalene du vil se på i wave vinduet fra object vinduet.

Signalverdier settes med kommandoen 'force' eller med

<pre>
Force > Force (i "Signals" vinduet)
</pre>

Dersom et av signalene skal være klokkesignal, kan dette gjøres enkelt med

<pre>
Force > Clock (i "Signals" vinduet)
</pre>

==Eksempler==
===Signalflyt i en SR-lås===

Simuler SR-låsen. Begynn med å påtrykke stimuli til alle signaler ved tid 0 (t0). Bruk STEP-knappen for å simulere på delta-tid-nivå. (Om en holder musepekeren over knappene i Questa, kommer det en forklarende tekst opp.) Når verdiene er stabile kjører du i f.eks. 100 ns før du endrer stimuli (skriv ''run 100'' i et av vinduene). Tilsvarende kan du endre stimuli ved å skrive f.eks. ''force S 0'' i hoved-vinduet. Legg merke til den røde pilen som peker på den linjen som blir utført.

Hvis du vil begynne på ny kan du velge

<pre>
File > Restart -f
</pre>

<pre>
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;

ENTITY SR_latch IS
PORT (
S : IN std_logic ;
R : IN std_logic ;
Q : INOUT std_logic ;
QB : INOUT std_logic );
END SR_latch;

-------------------------------------------------------------------------------

ARCHITECTURE behave OF SR_latch IS

BEGIN -- behave
Q <= S nand QB;
QB <= R nand Q;
END behave;
</pre>

===Signaler og variable===

Simuler VHDL-koden under. Bruk Step eller Step Over for å følge prosedyrens utvikling linje for linje. Simulere med optimaliseringsopsjon "-voptargs=+acc" for å kunne se variablene i wave-vinduet:

vsim -voptargs=+acc sign_var

Bruk View > Objects for å kikke på signalene og View > Local for å se innholdet i variablene. Forklar endringene i signaler og variable. Hva er forskjellen som funksjon av tid/delta-tid?

<pre>
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;

ENTITY sign_var IS
PORT (clk : IN std_logic);
END sign_var;

-------------------------------------------------------------------------------

ARCHITECTURE difference OF sign_var IS

signal SA: bit := '0';
signal SB: bit := '1';

begin -- difference
p_test: process
variable A: bit := '0';
variable B: bit := '1';
begin
wait until rising_edge(clk);
A := B;
B := A;
SA <= SB after 5 ns;
SB <= SA after 5 ns;
end process p_test;
end architecture difference;
</pre>

Simulering av VHDL

2026-01-19T10:45:14Z

Nfyku: /* Starte Questa Sim */

===Konstruksjon og simulering av VHDL-kode med Modelsim/Questa===

==Innledning==

Hensikten med denne oppgaven er å få et lite innblikk i bruk av høynivåspråk for simulering og uttesting av kretsløsninger. I denne oppgaven skal vi bruker VHDL (Very high speed integrated circuit Hardware Description Language), som er spesielt utviklet for elektronikk. VHDL er definert slik at det passer i en mengde sammenhenger, og er det vil derfor være uoverkommelig å gå inn på detaljer i denne oppgaven. Vi skal ta for oss noen eksempler:

* Eksempel 1: Signalflyt i en SR-lås

* Eksempel 2: Signaler og variable

Et VHDL program består i hovedsak av ENTITY, som definerer tilkobling mellom programmet og omverden, og ARCHITECTURE, som definerer programmets funksjon. Den komplette VHDL-koden for eksempel 1 vist nederst på denne siden.Mentor Graphics har utviklet programvare (Modelsim//Questa) som gjør det mulig å beskrivem, simulere og feilsøke VHDL-kode. Fremgangsmåten for skriving, kompilering og simulering av VHDL-kode finner du under.

==Starte Questa Sim==
Når man skal arbeide med Questa Sim fra Mentor Graphics skriv følgende kommando i et terminalvindu.
Generelt ligger programvaren i /eda/Siemens, og versjonene ligger i mapper sortert på årstall.

ssh -X mikroserver4
export SALT_LICENSE_SERVER="Sett inn rett lisensserver og port her"
source /eda/Siemens/2025-26/scripts/QUESTA-ONE-SIM_2025.3_RHELx86.sh
vsim &

==Lage et nytt prosjekt==

I den følgende teksten er det vist hvordan man kan utføre kompilering, etc. på kommandolinjen. Dette kan enten gjøres i fra X terminalvinduet, eller fra kommandolinjen i Questa. Hvis man velger å bruke Questa-miljøet er de fleste prosedyrer/kommandoer tilgjengelige under menyen.

Start et nytt prosjekt med

<pre>
File > New > Project
</pre>

[[Image:questa_new_project.png]]

Velg et fornuftig navn og katalog. Man kan gjerne ha flere uavhengige vhdl-filer i et prosjekt.
Det er en fordel å ha en hovedkatalog til vhdl prosjektene og en underkatalog for prosjektet fex /home/bruker/vhdl_prosjekt/sr_latch

==Skriving av VHDL kode==

En ny VHDL kode (et design beskrevet med VHDL kode) påbegynnes med å starte emacs i terminal vinduet eller ved å bruke den innebygde teksteditoren i Questa ved å velge Create New File.

Det fine med emacs er at man kan velge VHDL-modus. Dette gjøres med å skrive ''M-x vhdl-mode'' (M står for ''Meta'' og er vanligvis definert som esc-knappen). I emacs har en menyer med alle valg oppe langs kanten som i andre teksteditorer, men programmet skiller seg litt ut med kommandolinjen nederst i vinduet. Når en f. eks. skal lagre filen en har skrevet blir denne kommandolinjen aktiv og en skriver inn sti og filnavn der. Når man lagrer er ikke navnet på kodefilen viktig, men det er fornuftig å kalle den det samme som ENTITY-delen, med ''.vhdl'' som "etternavn" (f. eks. sr_latch.vhdl).

==Kompilering av VHDL kode==

Koden kompileres med

<pre>
vcom sr_latch.vhdl
</pre>

Hvis det er feil i koden vil det komme en melding i kommando vinduet. Dobbeltklikker du på feilen vil du få opp en liste over kompileringsprosessen og alle feilene. Dobbeltklikker du så på linjen som angir en feil så vises den respektive linjen i editoren.

Merk at navnet til det kompilerte designet blir skrevet med små bokstaver, selv om du har brukt store bokstaver i ENTITY- eller ARCHITECTURE-navnet. Det kompilerte designet blir liggende i work-katalogen.

==Simulering og debugging i Questa==

Når koden kompilerer feilfritt kan den simuleres i Questa. Dette startes med:

<pre>
vsim
</pre>

Nå dukker det opp en rute der du skal velge hva som skal simuleres, utvid work og velg vhdl filen. Eventuellt kan du skrive vsim work.sr_latch i kommandovinduet

Questa bruker et standard X-basert vindusoppsett, og er derfor noen forskjellig fra de andre Mentor-programmene. Når du starter simulatoren åpnes det et vindu som vist i figur 1. Begynn med å åpne diverse vinduer:

* View > Wave

* View > Objects

* View > Locals

Man kan også gi kommandoer i Questa-vinduet. F.eks.

<pre>
Wave *
</pre>

Dra de signalene du vil se på i wave vinduet fra object vinduet.

Signalverdier settes med kommandoen 'force' eller med

<pre>
Force > Force (i "Signals" vinduet)
</pre>

Dersom et av signalene skal være klokkesignal, kan dette gjøres enkelt med

<pre>
Force > Clock (i "Signals" vinduet)
</pre>

==Eksempler==
===Signalflyt i en SR-lås===

Simuler SR-låsen. Begynn med å påtrykke stimuli til alle signaler ved tid 0 (t0). Bruk STEP-knappen for å simulere på delta-tid-nivå. (Om en holder musepekeren over knappene i Questa, kommer det en forklarende tekst opp.) Når verdiene er stabile kjører du i f.eks. 100 ns før du endrer stimuli (skriv ''run 100'' i et av vinduene). Tilsvarende kan du endre stimuli ved å skrive f.eks. ''force S 0'' i hoved-vinduet. Legg merke til den røde pilen som peker på den linjen som blir utført.

Hvis du vil begynne på ny kan du velge

<pre>
File > Restart -f
</pre>

<pre>
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;

ENTITY SR_latch IS
PORT (
S,R : IN std_logic ;
Q,QB : INOUT std_logic );
END SR_latch;

-------------------------------------------------------------------------------

ARCHITECTURE behave OF SR_latch IS

BEGIN -- behave
Q <= S nand QB;
QB <= R nand Q;
END behave;
</pre>

===Signaler og variable===

Simuler VHDL-koden under. Bruk Step eller Step Over for å følge prosedyrens utvikling linje for linje. Simulere med optimaliseringsopsjon "-voptargs=+acc" for å kunne se variablene i wave-vinduet:

vsim -voptargs=+acc sign_var

Bruk View > Objects for å kikke på signalene og View > Local for å se innholdet i variablene. Forklar endringene i signaler og variable. Hva er forskjellen som funksjon av tid/delta-tid?

<pre>
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;

ENTITY sign_var IS
PORT (clk : IN std_logic);
END sign_var;

-------------------------------------------------------------------------------

ARCHITECTURE difference OF sign_var IS

signal SA: bit := '0';
signal SB: bit := '1';

begin -- difference
p_test: process
variable A: bit := '0';
variable B: bit := '1';
begin
wait until rising_edge(clk);
A := B;
B := A;
SA <= SB after 5 ns;
SB <= SA after 5 ns;
end process p_test;
end architecture difference;
</pre>

Detector lab

2025-04-22T09:54:16Z

Nfyku: /* Who are we? */

== Goal ==
The aim of our research is to study high energy particle detectors, and to develop new detectors for the future. In particular, we are interested in studying medical applications of these detectors and to help bridge fundamental with technological research.

== Our projects ==
* [[PET Project]]
** [[Labview readout setup]]
** [[XYZ table setup]]
** [[Root analysis programs]]
* [[Calorimeter Activities]]
* [[CALICE]]
* [[3D Detector Activities]]
* [[phys117 - PET project]]

== Who are we? ==
* Researcher: Heidi
* Professors: Bjarne, Dieter, Renate, [http://www.uib.no/personer/Kjetil.Ullaland Kjetil]
* Engineers: Attiq, Thomas

== Our facilities ==
* The main laboratory is situated in the 3rd floor at the IFT, room 332 (55588306)
* The soldering lab, room 334
* The clean room, room 324
* [[The muon spectrometer]]

== Lab Equipment ==
* [[Lab Equipment]] list, how to's, equipment service log's etc...
* [[Wishlist]] Put the things you will need for your projects here.

== Health and Safety ==
* [[Retningslinjer for bruk av kapslede kilder ved IFT]]
* [http://www.uib.no/poa/hms-portalen UIB HMS Portalen]

== Resources ==
* Our [https://subversion.uib.no/repos/detectorlab/ SVN]
* We can use this fileserver to store our collected data:
** Windows: \\ukl-felles\ift-kjernefys1\detectorlab
** Linux: /Data/ift/ift_kjernefys1/detectorlab

== Recent talks ==
04.11.09
* Dominik Fehlker - Presentation of the Lab [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.ppt ppt] [http://web.ift.uib.no/~dominik/files/detectorlabwiki/talks/part_phys_seminar_041109.pdf pdf]
* Lars-Halvard Thunold Helleve - SiPM introduction [https://wikihost.uib.no/ift/images/d/dc/SiPM_small_talk_041109_Lars-Halvard.pdf pdf]
* Kristine Indahl Helle - 3D pixel detectors [[File:3D_Si_pixels.pdf]]
[[older presentations]]

==Documentation==
In the [[documentation-list]] you can find relevant articles and masterthesis concerning the work in the lab.

== Meetings and conferences ==
* 23.09. - 29.09.11: IEEE Nuclear Science Symposium and Medical Imaging Conference, Valencia (http://www.nss-mic.org/2011/)
* 26.09. - 30.09.11: TWEPP-11 Topical Workshop On Electronics For Particle Physics, Vienna (http://twepp11.hephy.at/)

== For internal use ==
[[material]] that can be used in official presentations.

PHYS222

2024-10-02T11:48:20Z

Nfyku:

== Fagressurser for bruk i PHYS222 og PHYS223 ==

=== Fagbøker ===
* [http://www.cmosvlsi.com/ CMOS VLSI Design: A Circuits and Systems Perspective]
* [http://www.ece.ucdavis.edu/sscrl/book_corrections/ghlm/corr/ List of known errors and corrections for Analysis and Design of Analog Integrated Circuits, Fourth Edition]

=== Tutorials and lectures ===
* [http://www.electronics-tutorials.ws Basic Electronics Tutorials]
* [https://www.youtube.com/playlist?list=PLc7Gz02Znph-c2-ssFpRrzYwbzplXfXUT New Analog Circuit Design (By Prof. Ali Hajimiri, Caltech)]
* [https://www.khanacademy.org/science/electrical-engineering Electrical engineering (Khan Academy)]

=== Noise ===
* [http://ieeexplore.ieee.org/search/srchabstract.jsp?arnumber=261888&isnumber=6598&punumber=101&k2dockey=261888@ieeejrns&query=261888%3Cin%3Earnumber&pos=0 White noise in MOS transistors and resistors]
* [http://www.stat.ualberta.ca/people/schmu/preprints/poisson.pdf Shark attacks and the Poisson approximation]
* [https://www.k-state.edu/edl/docs/pubs/technical-resources/Technote1.pdf Equivalent Noise Bandwidth]

=== Halvlederfysikk ===
* [https://www.youtube.com/watch?v=Coy-WRCfems How does a diode work?]
* [http://hyperphysics.phy-astr.gsu.edu/HBASE/solids/semcn.html Hyperphysics om halvledere]
* [http://jas.eng.buffalo.edu/index.html Semiconductor Simulation Applets]
* [http://pveducation.org/ Photovoltaic Education Network]
* [http://www.semi1source.com/glossary/ Semiconductor Glossary]

=== Prosessteknologi ===
* [http://micro.magnet.fsu.edu/electromag/java/transistor/index.html Explore how an individual Field Effect (FET) transistor is fabricated on a silicon wafer simultaneously with millions of its neighbours]
* [https://www.youtube.com/watch?v=Jctk0DI7YP8 Understanding The FinFet Semiconductor Process]
* [https://youtu.be/MvbP_TizoNs Problems and Solutions at 7nm]
* [https://youtu.be/Qo2ywUURSKg A tour inside Intel Corporation's D1D factory]
* [https://www.youtube.com/watch?v=W3rfVpkNquA Intel Ivy Bridge 22nm FinFET Process Fabrication]
* [https://youtu.be/ApWOf6J858Y Integrated circuit scaling to 10 nm and beyond - Mark Bohr, Intel Senior Fellow]
* [http://spectrum.ieee.org/semiconductors/devices/transistor-wars Transistor Wars - Rival architectures face off in a bid to keep Moore's Law alive]

=== Logical effort ===
* [https://en.wikipedia.org/wiki/Logical_effort Logical Effort Wikipedia]

=== Matlab/Maple ===
Vi kan bruke Matlab/Maple for å løse ligninger og plotte resultater. Her er noen eksempler:

* [[Symbolsk løsning av nodeligninger med Matlab]]
* [http://lpsa.swarthmore.edu/Bode/BodeHow.html The Asymptotic Bode Diagram: Derivation of Approximations]
=== Kretssimulering ===

[[ Eksempler/Oppgaver ]]

==== AIM-Spice ====
AIM-Spice is a new version of SPICE running under the Microsoft Windows and Linux operating systems. AIM-Spice for Windows is capable of displaying graphically the results of a simulation in progress, a feature that allows the operator to terminate a run based on an instant information on intermediate simulation results.

SPICE is the most commonly used analogue circuit simulator today and is enormously important for the electronics industry. SPICE is a general purpose analogue simulator which contains models for most circuit elements and can handle complex non-linear circuits. The simulator can calculate dc operating points, perform transient analyses, locate poles and zeros for different kinds of transfer functions, find the small signal frequency response, small signal transfer functions, small signal sensitivities, and perform Fourier, noise, and distortion analyses.

[http://www.aimspice.com/download.html Download a free student version]

==== LTspice ====

LTspice is a high performance Spice III simulator, schematic capture and waveform viewer with enhancements and models for easing the simulation of switching regulators. Included in this download are Spice, Macro Models for 80% of Linear Technology's switching regulators, over 200 op amp models, as well as resistors, transistors and MOSFET models.

[http://www.linear.com/designtools/software/switchercad.jsp Download LTspice]

[[Category:Mikroelektronikk]]

PHYS222

2024-10-02T11:47:54Z

Nfyku: Added some lectures in Tutorials and lectures

== Fagressurser for bruk i PHYS222 og PHYS223 ==

=== Fagbøker ===
* [http://www.cmosvlsi.com/ CMOS VLSI Design: A Circuits and Systems Perspective]
* [http://www.ece.ucdavis.edu/sscrl/book_corrections/ghlm/corr/ List of known errors and corrections for Analysis and Design of Analog Integrated Circuits, Fourth Edition]

==== Tutorials and lectures ====
* [http://www.electronics-tutorials.ws Basic Electronics Tutorials]
* [https://www.youtube.com/playlist?list=PLc7Gz02Znph-c2-ssFpRrzYwbzplXfXUT New Analog Circuit Design (By Prof. Ali Hajimiri, Caltech)]
* [https://www.khanacademy.org/science/electrical-engineering Electrical engineering (Khan Academy)]

=== Noise ===
* [http://ieeexplore.ieee.org/search/srchabstract.jsp?arnumber=261888&isnumber=6598&punumber=101&k2dockey=261888@ieeejrns&query=261888%3Cin%3Earnumber&pos=0 White noise in MOS transistors and resistors]
* [http://www.stat.ualberta.ca/people/schmu/preprints/poisson.pdf Shark attacks and the Poisson approximation]
* [https://www.k-state.edu/edl/docs/pubs/technical-resources/Technote1.pdf Equivalent Noise Bandwidth]

=== Halvlederfysikk ===
* [https://www.youtube.com/watch?v=Coy-WRCfems How does a diode work?]
* [http://hyperphysics.phy-astr.gsu.edu/HBASE/solids/semcn.html Hyperphysics om halvledere]
* [http://jas.eng.buffalo.edu/index.html Semiconductor Simulation Applets]
* [http://pveducation.org/ Photovoltaic Education Network]
* [http://www.semi1source.com/glossary/ Semiconductor Glossary]

=== Prosessteknologi ===
* [http://micro.magnet.fsu.edu/electromag/java/transistor/index.html Explore how an individual Field Effect (FET) transistor is fabricated on a silicon wafer simultaneously with millions of its neighbours]
* [https://www.youtube.com/watch?v=Jctk0DI7YP8 Understanding The FinFet Semiconductor Process]
* [https://youtu.be/MvbP_TizoNs Problems and Solutions at 7nm]
* [https://youtu.be/Qo2ywUURSKg A tour inside Intel Corporation's D1D factory]
* [https://www.youtube.com/watch?v=W3rfVpkNquA Intel Ivy Bridge 22nm FinFET Process Fabrication]
* [https://youtu.be/ApWOf6J858Y Integrated circuit scaling to 10 nm and beyond - Mark Bohr, Intel Senior Fellow]
* [http://spectrum.ieee.org/semiconductors/devices/transistor-wars Transistor Wars - Rival architectures face off in a bid to keep Moore's Law alive]

=== Logical effort ===
* [https://en.wikipedia.org/wiki/Logical_effort Logical Effort Wikipedia]

=== Matlab/Maple ===
Vi kan bruke Matlab/Maple for å løse ligninger og plotte resultater. Her er noen eksempler:

* [[Symbolsk løsning av nodeligninger med Matlab]]
* [http://lpsa.swarthmore.edu/Bode/BodeHow.html The Asymptotic Bode Diagram: Derivation of Approximations]
=== Kretssimulering ===

[[ Eksempler/Oppgaver ]]

==== AIM-Spice ====
AIM-Spice is a new version of SPICE running under the Microsoft Windows and Linux operating systems. AIM-Spice for Windows is capable of displaying graphically the results of a simulation in progress, a feature that allows the operator to terminate a run based on an instant information on intermediate simulation results.

SPICE is the most commonly used analogue circuit simulator today and is enormously important for the electronics industry. SPICE is a general purpose analogue simulator which contains models for most circuit elements and can handle complex non-linear circuits. The simulator can calculate dc operating points, perform transient analyses, locate poles and zeros for different kinds of transfer functions, find the small signal frequency response, small signal transfer functions, small signal sensitivities, and perform Fourier, noise, and distortion analyses.

[http://www.aimspice.com/download.html Download a free student version]

==== LTspice ====

LTspice is a high performance Spice III simulator, schematic capture and waveform viewer with enhancements and models for easing the simulation of switching regulators. Included in this download are Spice, Macro Models for 80% of Linear Technology's switching regulators, over 200 op amp models, as well as resistors, transistors and MOSFET models.

[http://www.linear.com/designtools/software/switchercad.jsp Download LTspice]

[[Category:Mikroelektronikk]]

PHYS321

2024-06-10T08:56:50Z

Nfyku: /* Nettressurser */

== Fagressurser for bruk i PHYS321 ==

=== Fagbøker ===
* [http://site.ebrary.com/lib/bergen/docDetail.action?docID=10053265 Essentials of Electronic Testing for Digital, Memory, and Mixed-Signal VLSI Circuits]

=== Nettressurser ===
* [http://www.ecs.umass.edu/ece/koren/arith/simulator/ Arithmetic Algorithms Simulators]
* [http://en.wikipedia.org/wiki/Linear_feedback_shift_register Linear feedback shift register]
* [https://robey.lag.net/2012/11/14/how-to-add-numbers-2.html How to add numbers (part 2)]

==== Cadence tutorials ====
* [http://www-classes.usc.edu/engr/ee-s/477p/cadencetutorial.pdf Inverter eksempel]
* [https://www.youtube.com/watch?v=DPCu822wXPQ Inverter eksempel 1 youtube]
* [https://www.youtube.com/watch?v=AIjGRzNIWC4 Inverter eksempel 2 youtube]
* [https://www.youtube.com/watch?v=mQm88hoskkw Inverter eksempel 3 youtube]

==== Digilent Nexys 4 ====
* [https://reference.digilentinc.com/vivado:installation Install Vivado with free licence]
* [https://reference.digilentinc.com/nexys:nexys4:gsg Getting started]
* [https://reference.digilentinc.com/vivado Vivado - Xilinx Programming Environment - Board files, reference projects, etc]
* [https://reference.digilentinc.com/nexys:nexys4:start Nexys 4 Resource center]

==== Using Vivado ====

* [[Install Vivado 2015.4 with free license]]
* [[VGA controller VHDL code]]
* [[Nexys4_Master.xdc]]
* [[Using the VGA controller with block ram generator and clock wizard]]

=== Gamle øvingsoppgaver ===
[[Øvingsoppgaver PHYS321]]

[[Category:Mikroelektronikk]]

Transistor operating point printer

2024-05-30T11:56:01Z

Nfyku:

= DC operating parameters from simulation =
This script can be used to print the operating point parameters of all transistors in your design and save them to a file.

If you just want to view them in Virtusoso have a look at this guide instead: [[DCoperatingparameters]]

== Get the DC operating points from a previous simulation ==
Navigate to the folder you want to save the script in (this tutorial uses the home (./) directory) and create a new file in the terminal by entering <code> touch transistors.ocn </code>. Open the file by writing <code> gedit transistors.ocn & </code> and copy the following script into the document. Change ./transistors.csv in the script if you want another output file name and/or location. Save the file.
selectResult('dcOpInfo)
report(?output "./transistors.csv" ?param list("gm" "gmb" "gmoverid" "gds" "id" "idsat" "vth" "region" "cgs" "cgd" "self_gain" "type" "vds" "vdsat" "vgs") ?format "spice" ?maxLineWidth 1000)

file = outfile("./transistors.csv" "a")
fprintf(file "\n\nRegion 0 is cutoff.\nRegion 1 is linear.\nRegion 2 is saturation .\nRegion 3 is subthreshold.\nRegion 4 is breakdown.\n\nType 0 is nMOS. \nType 1 is pMOS.")
close(file)

For the IHP design kit use:
selectResult('dcOpInfo)
report(?output "./transistors.csv" ?param list("model" "gm" "gmb" "gds" "ids" "idsat" "vth" "region" "cgs" "cgd" "vds" "vsat" "vgs") ?format "spice" ?maxLineWidth 1000)

file = outfile("./transistors.csv" "a")
fprintf(file "\n\nRegion 0 is cutoff.\nRegion 1 is linear.\nRegion 2 is saturation .\nRegion 3 is subthreshold.\nRegion 4 is breakdown.\n\nType 0 is nMOS. \nType 1 is pMOS.")
close(file)

This script uses the results from the previous Debug Test (from ADE XL Test Editor). Before running the script, run a test with DC analysis, and remember to check the box with "Save DC Operating Point" :

[[File:Run_debug_simulation.png | 500px]]

After running DC analysis, run the script by entering the following into the Virtuoso Log Window (with file name and location as mentioned above): <code>load("./transistors.ocn")</code>

[[File:Run_transistors_script.png]]

== Copy the file to your computer and convert the values ==
After running the script, you can open the results file from the terminal using for example: <code> gedit transistors.csv & </code> or alternatively to get the file out from the mikroserver you use to another computer try this:

Create a file named "Makefile" and put this into it:

# target that is the first (and default) and does all the stuff below
all: get fix clean

# gets the file from your mikroserver and copies it to your computer in the root of your homefolder
get :
scp my_user_name@mikroserver:~/tsmc/transistors.csv ~/transistors_raw.csv

# converts transitors.csv to a copy where all the postfixes for the SI units generated from Virtuoso (m, f, K etc), has been replaced with E-3, E-15, E+3 etc, so the values are useable in LibreOffice
fix :
sed -e 's/$[0-9]\+$m/\1E-3/g' -e 's/$[0-9]\+$u/\1E-6/g' -e 's/$[0-9]\+$n/\1E-9/g' -e 's/$[0-9]\+$p/\1E-12/g' -e 's/$[0-9]\+$f/\1E-15/g' -e 's/$[0-9]\+$a/\1E-18/g' -e 's/$[0-9]\+$z/\1E-21/g' -e 's/$[0-9]\+$y/\1E-24/g' -e 's/$[0-9]\+$K/\1E+3/g' -e 's/$[0-9]\+$M/\1E+6/g' -e 's/$[0-9]\+$G/\1E+9/g' -e 's/$[0-9]\+$T/\1E+12/g' transistors_raw.csv > transistors.csv

# removes the not-fixed copy
clean:
rm transistors_raw.csv

Modify the scp-command to use
* The username and the correct mikroserver in the scp-command
* change the folder on mikroserver where the transistors.csv is created, default is /home/$user/tsmc/
* change the local folder where you want your copy to be placed, default is /home/$user/

Now you can type <code>make</code> in the folder you created the Makefile and the latestst simulation data will appear in your homefolder.

== Open the file in Libre Office ==
The resulting transistors.csv can then be imported into LibreOffice Calc (similar to Microsoft Excel) using File->Open, then choose the .csv file and enter the settings as in the following image:

[[File:Csv_import_libreoffice.png | 500px]]

== Troubleshooting ==
For the scp-command to work without password you have to set up your connection as described in [[MikroserverSetup]]

[[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]]

TSMC 130nm process

2024-05-30T11:54:37Z

Nfyku:

=Cadence design with TSMC 130nm process=
This tutorial will start from very basics in analog IC design then take you through the whole analog IC design process.

Here is the outline of the analog IC design flow:
# Schematic capture (Cadence tool)
# Netlist extraction from schematic
# Simulating using ELDO simulator and viewing results with EZWAVE (ELDO is a Mentor Graphic's tool for netlist level simulations)
# Layout using Cadence
# Signoff layout (DRC, LVS and parasitic extraction) using Calibre (Calibre is a Mentor Graphic's tool)

==Setup of Cadence==

To start virtuoso one must first connect to the chosen mikroserver
ssh -X mikroserver

'''First''' time you should add the following line to your cds.lib-file by running this command:
mkdir ~/tsmc
echo "DEFINE tsmc13rf /eda/design_kits/tsmc_013/tsmc13rf" > ~/tsmc/cds.lib

Then ('''each time''') run these commands to set up Cadence
source /eda/cadence/2023-24/scripts/analog_flow.sh
source /eda/cadence/eda_general_init.sh

Virtuoso Mixed Signal Design Environment is started by issuing this command:
virtuoso &

=== Troubleshooting ===
* Make sure you source the script from the correct year. For example 2023-24 and not 2016-17
* Make sure you are connected the the right mikroserver
* Make sure you run virtuoso from the same folder as your 'cds.lib'-folder ('~/tsmc/')

== Getting started ==

In the log window, choose "File > New > Library".

In the "New Library" dialog box, you must give the library a name (for example TORLIB, as I did). You must also specify a technology file. Here you choose "Attach to an existing technology library". Then click the OK button. When asked for technology, choose "tsmc13rf". If you are using IHP instead, choose "SG13_dev".

After successfully creating the new library, it is time to create your first design. In the log window, choose "File > New > Cellview". In the "Create New File" dialog box, you must give the design a name. You must also specify which library the design belongs to, and here you specify the library that you have just created. Choose to open the cell with "Schematics XL" and add a check-mark to always use this application if it is not checked.

Now click OK, and the Virtuoso Schematic Editor should pop up. We will now draw a simple inverter design, as shown in the picture:

[[File:virtuoso_schematic_editor.png|400px]]

==Entering the design==
To create the inverter design, do the following:

# Press 'i' or click on the "Instance" icon to invoke the transistors. The "Add Instance" dialog box will now pop up. In the "Library" field, click "Browse" to open the "Library Browser". In the library browser, choose "tsmc13rf" as library, "nmos3v" (for n-type transistor) or "pmos3v" (for p-type transistor) as cell and "spectre" as view. The cell is placed in the schematic by moving the cursor to the desired location and clicking the left mouse button.
# To insert the voltage sources, pick the "vdc" cell from the "analogLib" library. Add one connected to vdd and gnd and one connected to the input.
# To insert the ground and vdd nets, pick the "vdd" and "gnd" cells from the "analogLib" library. Here the view name should be "symbol", not "spectreS" (in fact, "symbol" is the only available option).
# To connect the symbols, press 'w' or click the "Wire (narrow)" icon. Then use the left mouse button to click the nodes togeter, two by two.
# To remove an instance or a wire, left click at the instance or wire that you want to remove, then press the "Delete" button on the keyboard.
# To insert a pin, press 'p'. Choose a name for the pin in the dialog that occurs and click on the schematic to place it. Create one input and one output.
# To change the properties of the icons, press 'q' or click at the "Properties" icon. Then click at the instances or nets that you want to modify. For the vdc source connected between vdd and gnd, set the "DC voltage" property to 3.3.
# To check and save the schematic, press 'x' or click the "Check and save" icon.
# If there are any errors or warnings, press ok and press 'g' or "Check->Find Marker" to view the errors. Make sure you have no errors or warnings before continuing.

==Simulating the design==

# Open "Launch > ADE GXL" and press create new view. The "Virtuoso Analog Environment" should now come up.
# Choose "Create > Test..." select the cell to simulate.
# Choose "Outputs > To be plotted > Select on Schematic". Click at the "in" node connected to the inverter input and the "out" node connected to the output.
# Choose "Analyses > Choose". We will now run a dc analysis to obtain the DC transfer characteristics of the inverter. Choose "Component parameter" as your sweep variable. Then click at "Select component". In the schematic, click at the input "vdc" instance. In the "Select Component Parameter" dialog box, choose dc as your sweep parameter. The sweep range should go from 0 to 3.3.

[[File:select_comp_parameter.png|300px]]

The analog environment should now look like this:

[[File:analog_env_2.png|500px]]

Switch to the "adexl" tab and choose the green run button. When the run is completed press the graph button beside the box that says "Replace". The outputs should look like this:
[[File:plot_output_dc.png|600px]]

To save your simulation settings, choose "Session > Save state" in the test editor windoe to save your state information under whatever file name you want. In a later session, you can reload your saved states using "Session > Load state".

==Generating a Symbol==
Finally, we want to generate a symbol for our inverter. This symbol is needed if we want to use our inverter design inside another design (hierarchical design methodology).

Select the schematic tab and choose "Create -> Create Cellview -> From Cellview".

Press OK in the dialog that occurs.

The pins should already be connected to the right positions in the symbol generator, so press OK here also and ths symbol editor will occur.

Press the red X and delete the pre-created green square. Use the line tool and the circle tool to create the inverter symbol

[[File:symbol.png|400px]]

Save it by clicking the "Save and check" symbol or pressing 'shift+X'.

[[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]]

MikroserverSetup

2024-05-30T11:52:52Z

Nfyku:

= Setup of connection to mikroservers=

This setup process will allow you to connect to the mikroservers with one command without typing any password or long host names.

== SSH key ==
To login to the server without having to type in your password every time, we can use SSH key pairs. The public key is stored on the server, and you have your private key stored on the UiB login server.

To generate a key, type into the terminal
ssh-keygen
This will generate the files id_rsa and id_rsa.pub in the folder ~/.ssh, where the latter is the public key that needs to be stored on the server. Copy the key with your identity to any of the mikroservers (since the user environment is shared for each server, this will give you access to all the servers). You can do this manually, but the easiest way is to use the ssh-copy-id utility. NB: Replace USERNAME with your username and mikroserver with the full name of your preferred mikroserver.
ssh-copy-id USERNAME@mikroserver
You will be prompted your password. After the key is copied, you should be able to login with "ssh USERNAME@mikroserver" without having to enter your password.

== Connection aliases ==

Now that you can login without typing your password, it is also convenient to set up aliases for the servers to connect quicker.

To do this, type "gedit ~/.ssh/config" in the terminal.
This will open up an empty file, and here you can store shorthand names and specific SSH settings for the connection, such as your username.
Host mikroserver
HostName mikroserver
User USERNAME
Port 22
ForwardX11 yes
ForwardX11Trusted yes
Copy and repeat this for each server in the same file, remembering to change the hostname to the full name of the corresponding mikroserver for each entry. ForwardX11 allows you to launch software on the server itself, while displaying the GUI remotely to the lab PC.

After saving the file, you should be able to simply write "ssh mikroserver" in the terminal to login to the chosen mikroserver.
Note: If you are attempting to do this step remotely from the UiB login server you need to use a terminal-based editor like Vim, or connect to the login-server with
ssh -Y USERNAME@login.uib.no
to enable the use of graphical editors such as gedit.

== Automatic sourcing ==
There are two main files of sourcing scripts in a Linux environment. One is the file .bashrc, and the other is the file .profile. The difference in these is that the contents of .profile is executed upon login, and .bashrc is executed every time you access the terminal. .bashrc is not sourced to the system by itself upon login, so we need to source .bashrc in .profile manually to use it. This must be done after connecting to one of the mikroservers.

echo "source ~/.bashrc" >> ~/.profile

Scripts can be sourced either within .profile or .bashrc. This will make sure the scripts are loaded every time you log in, so you don't have to do it manually every time.

== Accessing the lab software remotely on your private PC ==
You do not need to set up a VPN to access the lab software from home. By connecting to the mikroservers through the UiB loginserver with X11 forwarding enabled, you can run the software from any network. You can do this directly on Linux/macOS by using SSH in the bash terminal. For Windows, you will need to download the X server software [https://sourceforge.net/projects/xming/ Xming] to enable X11 forwarding. This install comes with PuTTY, an SSH client we will use to connect to the Linux based UiB server.

=== Linux/macOS ===
The process is the same for both Linux and macOS, except that for macOS you first have to install the X11 server software named [https://www.xquartz.org/ XQuartz].
Then, simply connect to the login server by typing
ssh -Y USERNAME@login.uib.no

The -Y enables trusted X11 forwarding. From here, you can "ssh mikroserver" just as you would from the lab PC and run software. The steps described above (SSH keys and config files) can be repeated on your personal Linux/macOS PC to simplify connecting to the UiB loginserver. On Linux, the configuration file is located in "~/.ssh/config" just as on the server, while on macOS it is located in "/private/etc/ssh/ssh_config".

=== Windows ===
Install Xming and make sure you include PuTTY in the install. Run Xming. It will start minimized, and does not require any setup.
When first opening PuTTY, you will be presented with this configuration menu. Fill in the hostname "login.uib.no", but don't connect yet.
[[File:Puttylogin.png]]
Navigate to Connection -> SSH -> X11, and check Enable X11 forwarding, and type in "localhost:0.0" as X display location.
[[File:Puttyx11.png]]
Return to Session, and make sure connection type is set to SSH. Press "Default Settings" and Save to save this configuration for later. Press Open to connect to the server. Enter your username and password, and now you should be in the Linux terminal for the UiB login server. Try to run "gedit" to confirm that you can run a graphical interface. From here you can ssh to the mikroservers and launch software as on the lab computer. Confirm by running gedit on the mikroserver as well to see that you can tunnel X11 through the login server correctly.

== Add mikroserver as a folder on your pc ==

Open up your home folder in Linux and in the bottom left corner click "Connect to Server" as shown in this picture:
[[File:ConnectToServer.png|thumbnail]]

as server address type:
[sftp://mikroserver3/home/USERNAME sftp://mikroserver/home/USERNAME]
to add your homefolder on mikroserver as a folder on your local PC for easy access to your files (for example the [[Transistor_operating_point_printer]])
To store this connection, right click the "mikroserver"-folder and click "Add Bookmark". The next time you just click the bookmark to open it.

=== Alternative way using scp/secure copy===
If for some reason the above doesn’t work you can try this:
* connect to your mikroserver
* locate the file you want to copy. i.e /home/USERNAME/picture.jpg
* type this command
scp picture.jpg USERNAME@login.uib.no:path/to/folder/to/copy/to
* this will copy the file to your home folder on any UiB machine
* To copy a folder
scp -r NameOfFolder USERNAME@login.uib.no:path/to/folder/to/copy/to

== Troubleshooting ==
* Make sure you have restarted your terminal (or source ~/.bashrc) if the commands doesn't work
* You have to be either connected to the UiB loginserver or run the commands via the computers in the lab to be able to connect to the mikroservers
* If you are using another shell like zsh or csh the aliases has to be in ~/.zshrc or ~/.cshrc instead of ~/.bashrc
* Make sure you have replaced all the instances of USERNAME with your usename, i.e "abc0123"

[[Category:Mikroelektronikk]]

IHP 130nm process

2024-05-30T11:47:50Z

Nfyku:

=Cadence design with IHP 130nm process=

==Starting up the IHP SG13S Design Kit==

The following steps describe how to install the Process Design Kit and start a new design.

Log on to the mikroserver of choise
ssh -X mikroserver

The preferred shell is bash. When using another shell it will be necessary to change the installation routine and modify the initialization script accordingly.

The '''first time''' you are using the IHP design kit you should copy the user environment design to your chosen parent directory (e.g ~/ihp)
cp -rp /eda/design_kits/ihp_sg13/SG13S_618_rev1.12.0/work/skel ~/ihp

Change sh.cadence in ~/ihp/cds to suit your needs. In particular you must define $IHP_TECH and $PROJECT according to your local environment. Then set general and user Cadence environment variables by doing:
source /eda/design_kits/ihp_sg13/sh.cadence
cd ~/ihp/cds/
source /eda/design_kits/ihp_sg13/sh.cadence
To start Cadence Virtuoso : virtuoso &

Example script [[:File:example_script.txt]] to run from_ "user"/ihp/cds/

To avoid having to do this every time try to set up your environment like described in [[MikroserverSetup]]

= Before starting designing =

Read the Design Kit User Guide. It can be found on the SG13SFeatures tab on the Virtuoso console window, or in the folder "/eda/design_kits/ihp_sg13/SG13S_618_rev1.12.0/doc/pdf/" on the mikroserver. Make sure that your web browser is closed or started from the mikroserver, else the file will not be found.

Other documents are found in "eda/design_kits/ihp_sg13/SG13S_618_rev1.12.0/doc/html/"

[[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] [[Category:Cadence_Virtuoso]]

Transistor operating point printer

2024-05-30T11:46:04Z

Nfyku:

= DC operating parameters from simulation =
This script can be used to print the operating point parameters of all transistors in your design and save them to a file.

If you just want to view them in Virtusoso have a look at this guide instead: [[DCoperatingparameters]]

== Get the DC operating points from a previous simulation ==
Navigate to the folder you want to save the script in (this tutorial uses the home (./) directory) and create a new file in the terminal by entering <code> touch transistors.ocn </code>. Open the file by writing <code> gedit transistors.ocn & </code> and copy the following script into the document. Change ./transistors.csv in the script if you want another output file name and/or location. Save the file.
selectResult('dcOpInfo)
report(?output "./transistors.csv" ?param list("gm" "gmb" "gmoverid" "gds" "id" "idsat" "vth" "region" "cgs" "cgd" "self_gain" "type" "vds" "vdsat" "vgs") ?format "spice" ?maxLineWidth 1000)

file = outfile("./transistors.csv" "a")
fprintf(file "\n\nRegion 0 is cutoff.\nRegion 1 is linear.\nRegion 2 is saturation .\nRegion 3 is subthreshold.\nRegion 4 is breakdown.\n\nType 0 is nMOS. \nType 1 is pMOS.")
close(file)

For the IHP design kit use:
selectResult('dcOpInfo)
report(?output "./transistors.csv" ?param list("model" "gm" "gmb" "gds" "ids" "idsat" "vth" "region" "cgs" "cgd" "vds" "vsat" "vgs") ?format "spice" ?maxLineWidth 1000)

file = outfile("./transistors.csv" "a")
fprintf(file "\n\nRegion 0 is cutoff.\nRegion 1 is linear.\nRegion 2 is saturation .\nRegion 3 is subthreshold.\nRegion 4 is breakdown.\n\nType 0 is nMOS. \nType 1 is pMOS.")
close(file)

This script uses the results from the previous Debug Test (from ADE XL Test Editor). Before running the script, run a test with DC analysis, and remember to check the box with "Save DC Operating Point" :

[[File:Run_debug_simulation.png | 500px]]

After running DC analysis, run the script by entering the following into the Virtuoso Log Window (with file name and location as mentioned above): <code>load("./transistors.ocn")</code>

[[File:Run_transistors_script.png]]

== Copy the file to your computer and convert the values ==
After running the script, you can open the results file from the terminal using for example: <code> gedit transistors.csv & </code> or alternatively to get the file out from mikroserver
to another computer try this:

Create a file named "Makefile" and put this into it:

# target that is the first (and default) and does all the stuff below
all: get fix clean

# gets the file from mikroserver3 and copies it to your computer in the root of your homefolder
get :
scp my_user_name@mikroserver:~/tsmc/transistors.csv ~/transistors_raw.csv

# converts transitors.csv to a copy where all the postfixes for the SI units generated from Virtuoso (m, f, K etc), has been replaced with E-3, E-15, E+3 etc, so the values are useable in LibreOffice
fix :
sed -e 's/$[0-9]\+$m/\1E-3/g' -e 's/$[0-9]\+$u/\1E-6/g' -e 's/$[0-9]\+$n/\1E-9/g' -e 's/$[0-9]\+$p/\1E-12/g' -e 's/$[0-9]\+$f/\1E-15/g' -e 's/$[0-9]\+$a/\1E-18/g' -e 's/$[0-9]\+$z/\1E-21/g' -e 's/$[0-9]\+$y/\1E-24/g' -e 's/$[0-9]\+$K/\1E+3/g' -e 's/$[0-9]\+$M/\1E+6/g' -e 's/$[0-9]\+$G/\1E+9/g' -e 's/$[0-9]\+$T/\1E+12/g' transistors_raw.csv > transistors.csv

# removes the not-fixed copy
clean:
rm transistors_raw.csv

Modify the scp-command to use
* The username and the correct microserver in the scp-command
* change the folder on mikroserver where the transistors.csv is created, default is /home/$user/tsmc/
* change the local folder where you want your copy to be placed, default is /home/$user/

Now you can type <code>make</code> in the folder you created the Makefile and the latestst simulation data will appear in your homefolder.

== Open the file in Libre Office ==
The resulting transistors.csv can then be imported into LibreOffice Calc (similar to Microsoft Excel) using File->Open, then choose the .csv file and enter the settings as in the following image:

[[File:Csv_import_libreoffice.png | 500px]]

== Troubleshooting ==
For the scp-command to work without password you have to set up your connection as described in [[MikroserverSetup]]

[[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]]

Synthese av VHDL

2024-05-30T11:43:00Z

Nfyku:

===Syntetiseringen av VHDL kode===

Grunnen til at vi skal syntetisere koden, er at vi må lage beskrivelse av koden tilpassa ein krets.

Vi vil no prøve å synthesisere vhdl kode. Og etterpå vil vi lage ein testbenk der vi samanliknar utsignala frå den syntetiserte og den opprinnelige koden. Vi bruker ein alu som eksempel.

==Precision==

Precision bruker Vivado til å syntetisere vhdl-koden. For å starte synteseprogrammet:

export LM_LICENSE_FILE=27001@lisensserver1:29000@lisensserver2
source /eda/Siemens/2023-24/scripts/PRECISION_2023.2_RHELx86.sh
precision

Erstatt lisensserver med rett navn på lisensserver (se "Micro-how-to" i mikroelektronikk-teamet).Nye versjoner av programvaren ligger i /eda/Siemens sortert på årstall.

Velg deretter New Project, og deretter Add input file (i dette tilfelle add_sub_alu.vhd).
Så går vi inn på Setup design, velger ein kretsprodusent, den ønska kretsen og designfrekvens, for eksempel Zynq med frekvens 200MHz. For å få ut en vhdl fil av den syntetiserte koden må en gå på Tools->Options->Output og hak av for VHDL og trykk ok.

Pass på at Precision finner Vivado, settes i menyen:
Tools > Options > Place and Route Settings
deretter
Vivado > Integrated Place and Route > path to Xilinx Vivado installation tree
settes til
/eda/xilinx/Vivado/2020.2

Trykk så compile, og synthesize.
No kan vi sjå på den generte kretsen i RTL Schematic og Technology Schematic (syntese med den valgte kretsen) under Schematics på venstre side.

==Questasim==

Start opp Questasim, lag nytt prosjekt og legg til vhdl fila (add_sub_alu.vhdl). Så legg vi til fila som Precision generte i prosjektdir til 'precision/prosjektnavn_temp_1/prosjektnavn.vhd' (i vårt tilfelle 'alu/add_sub_alu_temp_1/add_sub_alu.vhd').

Vi trenger simuleringsbibliotek for den valgte kretsfamilien for å kunne simulere etter "Place and Route". Disse bibliotekene kan genereres fra Vivado med menyen
Tools > Compile Simulation Libraries
men, vi har kompilert disse unisim-bibliotekene til mappen /eda/xilinx/lib. Du kan "mappe" disse slik:

vmap unisim /eda/xilinx/lib/unisim

Deretter legger vi til ei ny vhdl fil der vi skal lage testbenken vår. Vi legger til ein komponent av den opprinnelige og den synthesiserte vhdl koden. Vi koblar alle inngangane til samme signal på testbenken, og gir ut 2 forskjellige utsignal for å samanlikne ved hjelp av assert(sjå fila alu_tb.vhdl). På grunn av at utsignala av dei to komponentane ikkje skifta heilt synkront, testa vi berre kvart nanosekund ved å putta assert inn i ein process med wait for 1ns:

test : process
begin
wait for 1 ns;
assert (data_out = data_out_synt)
report "Data ut er ulik"
severity Error;
end process test;

Når vi har laga testbenken, kompilerer vi filene (husk å kompilere i rett rekkefølge med compileorder->autogenerate første gong).

Siden precision generer samme navn på entityen og architecturen på den syntetiserte filen som i den orginale så vil ikke simulatoren kjøre de samtidig. Dette endres ved å endre entity fra add_sub_alu til add_sub_alu_synth og skifte navnet på architecture fra algoritm til structure øverst og nederst i den syntetiserte filen.

==Simulering med timing==

Eksempel på start av simulering med timing:

vsim -t ps -sdfnoerror -sdfmax /alu_synth=/home/kaf003/VHDL_Prosjekter/PHYS321/vivado_impl_1/add_sub_alu_synth.sdf work.alu_tb

Vi kan sjå at i dei første 50 nanosekunda er utsignala ulike. Dette er fordi før første klokkeflanke er verdiane udefinert i den opprinnelige komponenten, medan den synthesisere ikkje kan ha udefinerte verdiar. I Questasim vil vi derfor få ein del feilmeldingar dei første 50 nanosekunda.

==Konklusjon==

Vi kan teste om den syntesiserte komponenten oppfører seg likt med den opprinnelige komponenten ved å koble begge to til samme testbenk. Vi fekk problem i overgangane når vi testa kontinuerlig, så vi løyste problemet ved å berre teste kvart naonosekund. Bortsett frå dei første 50 nanosekunda (sjå grunn over) kan vi sjå at begge komponetane gir ut samme utsignal. Vi prøvde å bruke samme enitynavn på begge komponentane med ulik arcitechture, men fekk berre lov å kompilere og ikkje simulere. Vi kan derfor konkludere med at desse må ha ulike navn.

==Kode==

===Kode til add_sub_alu.vhd===

<pre>
LIBRARY ieee;
USE ieee.std_logic_1164.All;
USE ieee.std_logic_unsigned.all;

ENTITY add_sub_alu IS
PORT (
clk : IN std_logic;
rst : IN std_logic;
enable_in : IN std_logic;
start : IN std_logic;
enable : IN std_logic;
do_add : IN std_logic;
do_subtract : IN std_logic;
do_hold : IN std_logic;
data_in : IN std_logic_vector(3 DOWNTO 0);
data_out : OUT std_logic_vector(3 DOWNTO 0) BUS);
END add_sub_alu;

ARCHITECTURE algorithm OF add_sub_alu IS
TYPE states IS (hold, reset, add, subtract);
SIGNAL state_var : states;
SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0);
SIGNAL latched_data_in : std_logic_vector(3 DOWNTO 0);
BEGIN

latch: PROCESS (enable_in, data_in)is
BEGIN
IF (enable_in = '1') THEN
latched_data_in <= data_in;
END IF;
END PROCESS latch;

fsm: PROCESS (clk, rst) is
BEGIN
IF (rst = '0') THEN
state_var <= reset;
ELSIF rising_edge(clk) THEN
CASE state_var IS
WHEN hold =>
IF (start = '1') THEN
state_var <= reset;
END IF;
WHEN reset =>
IF (do_add = '1') THEN
state_var <= add;
ELSIF (do_subtract = '1') THEN
state_var <= subtract;
END IF;
WHEN add =>
IF (do_hold = '1') THEN
state_var <= hold;
ELSIF (do_subtract = '1') THEN
state_var <= subtract;
END IF;
WHEN subtract =>
IF (do_hold = '1') THEN
state_var <= hold;
ELSIF (do_add = '1') THEN
state_var <= add;
END IF;
WHEN OTHERS => state_var <= reset;
END CASE;
END IF;
END PROCESS fsm;

alu: PROCESS (state_var, latched_data_in, reg)is
BEGIN
CASE state_var IS
WHEN add => int_reg <= reg + latched_data_in;
WHEN subtract => int_reg <= reg - latched_data_in;
WHEN reset => int_reg <= (others => '0');
WHEN hold => int_reg <= reg;
WHEN OTHERS => int_reg <= reg;
END CASE;
END PROCESS alu;

mem: PROCESS (clk) is
BEGIN
IF rising_edge(clk) THEN
reg <= int_reg;
END IF;
END PROCESS mem;

tri: PROCESS (enable, reg) is
BEGIN
FOR i IN 3 DOWNTO 0 LOOP
IF (enable = '1') THEN
data_out(i) <= reg(i);
ELSE
data_out(i) <= 'Z';
END IF;
END LOOP;
END PROCESS tri;

END algorithm;</pre>

===Koden til alu_tb.vhdl===

<pre>
library ieee;
use ieee.std_logic_1164.all;
library work;
use work.all;

entity alu_tb is
end entity alu_tb;

architecture struct of alu_tb is
--Deklaring av signal som skal koblast til komponentane.
--Alle innsignal er felles, medan vi har 2 forskjellige utsignal.
signal clk : std_logic;
signal reset : std_logic;
signal enable_in : std_logic;
signal start : std_logic;
signal enable : std_logic;
signal do_add : std_logic;
signal do_subtract : std_logic;
signal do_hold : std_logic;
signal data_in : std_logic_vector(3 downto 0);
signal data_out : std_logic_vector(3 downto 0);
signal data_out_synt : std_logic_vector(3 downto 0);

begin
--Deklarer komponenten alu.
alu : entity add_sub_alu(algorithm)
--Kobler signala til den opprinnelige komponenten.
port map (
clk => clk,
rst => reset,
enable_in => enable_in,
start => start,
enable => enable,
do_add => do_add,
do_subtract => do_subtract,
do_hold => do_hold,
data_in => data_in,
data_out => data_out);

--Deklarer komponenten alu_synt.
alu_synt : entity add_sub_alu_synth(structure)
--Kobler signala til den synthiserte komponenten.
port map (
clk => clk,
rst => reset,
enable_in => enable_in,
start => start,
enable => enable,
do_add => do_add,
do_subtract => do_subtract,
do_hold => do_hold,
data_in => data_in,
data_out => data_out_synt);

--Klokkegenerator
clock_gen : process
begin
clk <= '0', '1' after 50 ns;
wait for 100 ns;
end process clock_gen;

--Setter testvektorane.
reset <= '0', '1' after 60 ns;
enable <= '1', '0' after 900 ns;
enable_in <= '1', '0' after 400 ns;
start <= '1', '0' after 300 ns;
do_add <= '1', '0' after 660 ns;
do_subtract <= '0';
do_hold <= '0';
data_in <= X"3";

--Test process for å samanlikne utsignala kvart nanosekund.
test : process
begin
wait for 1 ns;
assert (data_out = data_out_synt)
report "Data ut er ulik"
severity Error;
end process test;

end architecture struct;
</pre>

[[Category:Mikroelektronikk]]

Simulering av VHDL

2024-05-30T11:39:53Z

Nfyku:

===Konstruksjon og simulering av VHDL-kode med Modelsim/Questa===

==Innledning==

Hensikten med denne oppgaven er å få et lite innblikk i bruk av høynivåspråk for simulering og uttesting av kretsløsninger. I denne oppgaven skal vi bruker VHDL (Very high speed integrated circuit Hardware Description Language), som er spesielt utviklet for elektronikk. VHDL er definert slik at det passer i en mengde sammenhenger, og er det vil derfor være uoverkommelig å gå inn på detaljer i denne oppgaven. Vi skal ta for oss noen eksempler:

* Eksempel 1: Signalflyt i en SR-lås

* Eksempel 2: Signaler og variable

Et VHDL program består i hovedsak av ENTITY, som definerer tilkobling mellom programmet og omverden, og ARCHITECTURE, som definerer programmets funksjon. Den komplette VHDL-koden for eksempel 1 vist nederst på denne siden.Mentor Graphics har utviklet programvare (Modelsim//Questa) som gjør det mulig å beskrivem, simulere og feilsøke VHDL-kode. Fremgangsmåten for skriving, kompilering og simulering av VHDL-kode finner du under.

==Starte Questa Sim==
Når man skal arbeide med Questa Sim fra Mentor Graphics skriv følgende kommando i et terminalvindu.
Generelt ligger programvaren i /eda/Siemens, og versjonene ligger i mapper sortert på årstall.

ssh -X mikroserver4
export LM_LICENSE_FILE="Sett inn rett lisensserver og port her"
source /eda/Siemens/2023-24/scripts/QUESTA-CORE-PRIME_2023.4_RHELx86.sh
vsim

==Lage et nytt prosjekt==

I den følgende teksten er det vist hvordan man kan utføre kompilering, etc. på kommandolinjen. Dette kan enten gjøres i fra X terminalvinduet, eller fra kommandolinjen i Questa. Hvis man velger å bruke Questa-miljøet er de fleste prosedyrer/kommandoer tilgjengelige under menyen.

Start et nytt prosjekt med

<pre>
File > New > Project
</pre>

[[Image:questa_new_project.png]]

Velg et fornuftig navn og katalog. Man kan gjerne ha flere uavhengige vhdl-filer i et prosjekt.
Det er en fordel å ha en hovedkatalog til vhdl prosjektene og en underkatalog for prosjektet fex /home/bruker/vhdl_prosjekt/sr_latch

==Skriving av VHDL kode==

En ny VHDL kode (et design beskrevet med VHDL kode) påbegynnes med å starte emacs i terminal vinduet eller ved å bruke den innebygde teksteditoren i Questa ved å velge Create New File.

Det fine med emacs er at man kan velge VHDL-modus. Dette gjøres med å skrive ''M-x vhdl-mode'' (M står for ''Meta'' og er vanligvis definert som esc-knappen). I emacs har en menyer med alle valg oppe langs kanten som i andre teksteditorer, men programmet skiller seg litt ut med kommandolinjen nederst i vinduet. Når en f. eks. skal lagre filen en har skrevet blir denne kommandolinjen aktiv og en skriver inn sti og filnavn der. Når man lagrer er ikke navnet på kodefilen viktig, men det er fornuftig å kalle den det samme som ENTITY-delen, med ''.vhdl'' som "etternavn" (f. eks. sr_latch.vhdl).

==Kompilering av VHDL kode==

Koden kompileres med

<pre>
vcom sr_latch.vhdl
</pre>

Hvis det er feil i koden vil det komme en melding i kommando vinduet. Dobbeltklikker du på feilen vil du få opp en liste over kompileringsprosessen og alle feilene. Dobbeltklikker du så på linjen som angir en feil så vises den respektive linjen i editoren.

Merk at navnet til det kompilerte designet blir skrevet med små bokstaver, selv om du har brukt store bokstaver i ENTITY- eller ARCHITECTURE-navnet. Det kompilerte designet blir liggende i work-katalogen.

==Simulering og debugging i Questa==

Når koden kompilerer feilfritt kan den simuleres i Questa. Dette startes med:

<pre>
vsim
</pre>

Nå dukker det opp en rute der du skal velge hva som skal simuleres, utvid work og velg vhdl filen. Eventuellt kan du skrive vsim work.sr_latch i kommandovinduet

Questa bruker et standard X-basert vindusoppsett, og er derfor noen forskjellig fra de andre Mentor-programmene. Når du starter simulatoren åpnes det et vindu som vist i figur 1. Begynn med å åpne diverse vinduer:

* View > Wave

* View > Objects

* View > Locals

Man kan også gi kommandoer i Questa-vinduet. F.eks.

<pre>
Wave *
</pre>

Dra de signalene du vil se på i wave vinduet fra object vinduet.

Signalverdier settes med kommandoen 'force' eller med

<pre>
Force > Force (i "Signals" vinduet)
</pre>

Dersom et av signalene skal være klokkesignal, kan dette gjøres enkelt med

<pre>
Force > Clock (i "Signals" vinduet)
</pre>

==Eksempler==
===Signalflyt i en SR-lås===

Simuler SR-låsen. Begynn med å påtrykke stimuli til alle signaler ved tid 0 (t0). Bruk STEP-knappen for å simulere på delta-tid-nivå. (Om en holder musepekeren over knappene i Questa, kommer det en forklarende tekst opp.) Når verdiene er stabile kjører du i f.eks. 100 ns før du endrer stimuli (skriv ''run 100'' i et av vinduene). Tilsvarende kan du endre stimuli ved å skrive f.eks. ''force S 0'' i hoved-vinduet. Legg merke til den røde pilen som peker på den linjen som blir utført.

Hvis du vil begynne på ny kan du velge

<pre>
File > Restart -f
</pre>

<pre>
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;

ENTITY SR_latch IS
PORT (
S,R : IN std_logic ;
Q,QB : INOUT std_logic );
END SR_latch;

-------------------------------------------------------------------------------

ARCHITECTURE behave OF SR_latch IS

BEGIN -- behave
Q <= S nand QB;
QB <= R nand Q;
END behave;
</pre>

===Signaler og variable===

Simuler VHDL-koden under. Bruk Step eller Step Over for å følge prosedyrens utvikling linje for linje. Simulere med optimaliseringsopsjon "-voptargs=+acc" for å kunne se variablene i wave-vinduet:

vsim -voptargs=+acc sign_var

Bruk View > Objects for å kikke på signalene og View > Local for å se innholdet i variablene. Forklar endringene i signaler og variable. Hva er forskjellen som funksjon av tid/delta-tid?

<pre>
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;

ENTITY sign_var IS
PORT (clk : IN std_logic);
END sign_var;

-------------------------------------------------------------------------------

ARCHITECTURE difference OF sign_var IS

signal SA: bit := '0';
signal SB: bit := '1';

begin -- difference
p_test: process
variable A: bit := '0';
variable B: bit := '1';
begin
wait until rising_edge(clk);
A := B;
B := A;
SA <= SB after 5 ns;
SB <= SA after 5 ns;
end process p_test;
end architecture difference;
</pre>

Bitvis UVVM VHDL Verification Component Framework

2024-02-13T12:14:01Z

Nfyku: /* Simulation */

This wiki page is heavily based on the Powerpoint-presentation found [http://bitvis.no/media/15298/Simple_TB_step_by_step.pps here].<ref>UVVM LICENSE AGREEMENT
IMPORTANT - READ BEFORE USING OR COPYING.
THIS IS THE MIT LICENSE, see https://opensource.org/licenses/MIT
------------------------------------------------------------------

Copyright (c) 2016 by Bitvis AS

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated
documentation files (the "Software"), to deal in the Software without restriction, including without limitation
the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software,
and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of
the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS
OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.</ref>
The presentation can also be found in the uvvm_util folder.

== Introduction ==

Bitvis UVVM VVC Framework is a complete framework for making VHDL testbenches for
verification of FPGA and ASIC desing. You can download the complete code-base, examples and simulations scripts from the [https://github.com/UVVM/UVVM_All Bitvis github].

=== What's in the folders? ===
[[File:20160302215840!1.png|thumb]]

The download includes severals folders:
* bitvis_irqc - example VHDL design + testbench
* bitvis_uart - example VHDL design + testbench
* bitvis_vip_sbi - Verification IP(VIP) for simple bus interface(SBI)
* bitvis_vip_uart - VIP for UART TX and RX
* uvvm_util - UVVM utility library - sufficient for simple testbenches
* uvvm_vvc_framework - Framework for more advanced tutorials

=== IRQC ===
[[File:irqc.png|thumb]]
The provided example VHDL design is a simple interrupt controller with several internal registers, a bus interface and some input and output signals.

[[File:irqc2.png|350px]]

== UVVM Utility Library - Testbench creation ==
Copy the folders bitvis_irqc, bitvis_vip_sbi and uvvm_util to another location before editing the files.
=== Generate TB entity with DUT instantiated ===
Our TB entity can in many cases be generated from several tools. Notepad++ (among other) supports plugins that enables copying an entity and pasting it as an instantiation, and also as a complete testbench template. However, we will change some of our signals so that they fit the VIP SBI BFM. The signals to and from the CPU will be converted to t_sbi_if record, which is a type that includes all the SBI signals (cs, addr, rd, wr, wdata, ready and rdata).

<pre>
--Standard libraries
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.numeric_std.all;

-- Library enabling control of the simulation from VHDL. Eg. std.env.stop
library STD;
use std.env.all;

-- Obviously the UVVM library
library uvvm_util;
context uvvm_util.uvvm_util_context;

-- We will use this library later when implementing the Bus Functional Model
-- Includes among much else the record type t_sbi_if and many functions
-- If other buses are used, you will have to change this library
library bitvis_vip_sbi;
use bitvis_vip_sbi.sbi_bfm_pkg.all;

-- This file includes definitions of everything from registers to record types
use work.irqc_pif_pkg.all;

-- Test case entity
entity irqc_tb is
end entity;

-- Test case architecture
architecture func of irqc_tb is

-- DSP interface and general control signals
signal clk : std_logic := '0';
signal arst : std_logic := '0';
-- CPU interface
-- t_sbi_if is from the verification IP SBI
-- init_sbi_if_signals initialize the inputs to 0 and the outputs to Z
signal sbi_if : t_sbi_if(addr(2 downto 0), wdata(7 downto 0), rdata(7 downto 0)) := init_sbi_if_signals(3, 8);

-- Interrupt related signals
signal irq_source : std_logic_vector(C_NUM_SOURCES-1 downto 0) := (others => '0');
signal irq2cpu : std_logic := '0';
signal irq2cpu_ack : std_logic := '0';

begin

-----------------------------------------------------------------------------
-- Instantiate DUT
-----------------------------------------------------------------------------
i_irqc: entity work.irqc
port map (
-- DSP interface and general control signals
clk => clk,
arst => arst,
-- CPU interface
cs => sbi_if.cs, -- NOTICE THE SIGNALS ARE NOW SBI_IF
addr => sbi_if.addr,
wr => sbi_if.wena,
rd => sbi_if.rena,
din => sbi_if.wdata,
dout => sbi_if.rdata,
-- Interrupt related signals
irq_source => irq_source,
irq2cpu => irq2cpu,
irq2cpu_ack => irq2cpu_ack
);

end func;
</pre>

=== Add support process for clock generation ===
We now have to add a support process that controls the clock. This has to allow enabling/disabling from the test sequencer. We add the following before "begin" in our architecture:
<pre>
-- Added for clock generation
signal clock_ena : boolean := false;

constant C_CLK_PERIOD : time := 10 ns;

procedure clock_gen(
signal clock_signal : inout std_logic;
signal clock_ena : in boolean;
constant clock_period : in time
) is
variable v_first_half_clk_period : time := C_CLK_PERIOD / 2;
begin
loop
if not clock_ena then
wait until clock_ena;
end if;
wait for v_first_half_clk_period;
clock_signal <= not clock_signal;
wait for (clock_period - v_first_half_clk_period);
clock_signal <= not clock_signal;
end loop;
end;
</pre>

Our clock can now be activated from the test sequencer (this will be added in the next step):
<pre>
-- After begin in the architecture
clock_gen(clk, clock_ena, C_CLK_PERIOD);

-- Inside the test sequencer process
clock_ena <= true;
</pre>

=== Add test sequencer process ===
The next step is to add the test sequencer process. This process controls everything from initialization to termination of the simulation.

<pre>
-- Set upt clock generator
clock_gen(clk, clock_ena, C_CLK_PERIOD);

------------------------------------------------
-- PROCESS: p_main
------------------------------------------------
p_main : process
-- The scope tells you where log messages originates - C_SCOPE tells us they originate from the default test sequencer scope
constant C_SCOPE : string := C_TB_SCOPE_DEFAULT;
-- This is where we will add some procedures later to simplify the tests

begin

--Print the configuration to the log
report_global_ctrl(VOID);
report_msg_id_panel(VOID);

enable_log_msg(ALL_MESSAGES);
--disable_log_msg
--enable_log_msg(ID_LOG_HDR);

log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE);
------------------------------------------------------------
clock_ena <= true; -- to start clock generator

------------------------------------------------------------
-- End the simulation
wait for 1000 ns; -- to allow some time for completion
report_alert_counters(FINAL); -- Report final counters and print conclusion for simulation (Success/Fail)
log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE);

--Finish the simulation
std.env.stop;
wait; -- to stop completely
end process p_main;
</pre>

==Simulation==
We now have the skeleton of the testbench, which we will develop further. But now, let's see if everything works. Bitvis have created simulation scripts for the IRQC example that compiles everything we need, from the source files of the VHDL design, to the testbench (if you called the file irqc_tb.vhd and placed it in the tb-folder) and the SBI BFM and the UVVM library. Open up QuestaSim/ModelSim.
Change directory to the script folder (where you have copied the UVVM files), for example in phys321/bitviswiki.....:
<pre>
cd ~/phys321/bitviswiki/bitvis_irqc/script
do compile_and_sim_all.do
</pre>

This will present our result in the transcript windows, but also write _Log.txt file which includes all the information we have asked for. We see that we get the results from the following code:
<pre>
report_global_ctrl(VOID);
report_msg_id_panel(VOID);
enable_log_msg(ALL_MESSAGES);
log(ID_LOG_HDR, "Start Simulation of TB for IRQC", C_SCOPE);
report_alert_counters(FINAL);
log(ID_LOG_HDR, "SIMULATION COMPLETED", C_SCOPE);
</pre>
Commenting these out will result in an empty log.

== Verbosity control ==
We want to able to control the amount of information in our logs, and the framework enables us to prioritize messages based on ID. This makes it easy to turn on or off the information we want.
To turn on a specific ID
<pre>
enable_log_msg(IDNAME);
</pre>

Turn off:
<pre>
disable_log_msg(IDNAME);
</pre>

For writing a message to a certain log ID:
<pre>
log(IDNAME, "MESSAGE HERE", C_SCOPE);
</pre>
Remember that C_SCOPE just tells us that the message originated from the default scope and will look like "TB seq." in the log file.

Exampled IDs:
* ID_LOG_HDR, -- ONLY allowed in test sequencer, Log section headers
* ID_SEQUENCER, -- ONLY allowed in test sequencer, Normal log (not log headers)
* ID_BFM, -- Used inside a BFM (to log BFM access)
* ID_CLOCK_GEN, -- Used for logging when clock generators are enabled or disabled
* ALL_MESSAGES -- Applies to ALL message ID apart from ID_NEVER

You'll find all the different ID's in the UVVM Utility Library Quick Reference or defined in uvvm_util/adaptions_pkg.vhd. This also where C_TB_SCOPE_DEFAULT is defined.

== Implement first tests ==
[[File:tb.png|thumb|upright=0.35]]
We want to check and verify that our testbench is up and running and to verify our first tests of the DUT. This means that we have to able to set all our signals passive, apply a reset signal and then check the default outputs of the DUT.

Instead of setting all our signals passive one-by-one in our test sequencer we declare a procedure in our p_main process(this is done before begin):
<pre>
procedure set_inputs_passive(
dummy : t_void) is --dummy variable is included only to allow calling the procedure with parenthesis for readability
begin
sbi_if.cs <= '0';
sbi_if.addr <= (others => '0');
sbi_if.wena <= '0';
sbi_if.rena <= '0';
sbi_if.wdata <= (others => '0');
irq_source <= (others => '0');
irq2cpu_ack <= '0';
log(ID_SEQUENCER_SUB, "All inputs set passive", C_SCOPE);
end;
</pre>

Note that the procedure declaration also includes a dummy variable parameter. This means that we will be able to call the procedure with the more readable:

<pre>
set_inputs_passive(VOID);
</pre>

Rather than:
<pre>
set_inputs_passive;
</pre>
which is more ambigious.

We may also would like to send pulses on different signals, f.ex. sending a pulse on our reset to see if it behaves like intended. We therefore can include a pulse procedure:
<pre>
procedure pulse(
signal target : inout std_logic_vector;
constant pulse_value : in std_logic_vector;
signal clock_signal : in std_logic;
constant num_periods : in natural;
constant msg : in string) is
begin
if num_periods > 0 then
wait until falling_edge(clock_signal);
target <= pulse_value;
for i in 1 to num_periods loop
wait until falling_edge(clock_signal);
end loop;
else
target <= pulse_value;
wait for 0 ns; -- Delta cycle only
end if;
target(target'range) <= (others => '0');
log(ID_SEQUENCER_SUB, "Pulsed to " & to_string(pulse_value, HEX, AS_IS, INCL_RADIX) & ". " & msg, C_SCOPE);
end;
</pre>

In the above example the test sequencer is required to inform the procedure of what value the pulse is to take. The call to the procedure would take the following form:
<pre>
pulse(arst, 'Z', clk, 10, "Log message - Im pulsing the value 'Z'");
</pre>
But a more specific overload can be created where pulse always takes value '1':
<pre>
procedure pulse(
signal target : inout std_logic;
signal clock_signal : in std_logic;
constant num_periods : in natural;
constant msg : in string
) is
begin
if num_periods > 0 then
wait until falling_edge(clock_signal);
target <= '1';
for i in 1 to num_periods loop
wait until falling_edge(clock_signal);
end loop;
else
target <= '1';
wait for 0 ns; -- Delta cycle only
end if;
target <= '0';
log(ID_SEQUENCER_SUB, msg, C_SCOPE);
end;
</pre>

These procedures can now be called directly from our test sequence:
<pre>
set_inputs_passive(VOID);
pulse(arst, clk, 10, "pulsed reset-signal - active for 10T");
</pre>

To check signal values we can use the built-in check function check_value():
<pre>
check_value(irq2cpu, 'X', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE);
</pre>
The above call checks if the signal irq2cpu is 'X', and obviously fail if everything works correctly and gives the following message:

[[File:error.png|700px]]

If we want we can change the number of errors logged before the simulation stops:
<pre>
set_alert_stop_limit(ERROR, 3);
</pre>

We now have all the tools needed for the first tests in our sequencer:
<pre>
set_inputs_passive(VOID);
pulse(arst, clk, 10, "Pulsed reset-signal - active for 10T");

check_value(C_NUM_SOURCES > 0, FAILURE, "Must be at least 1 interrupt source", C_SCOPE);
check_value(C_NUM_SOURCES <= 8, TB_WARNING, "This TB is only checking IRQC with up to 8 interrupt sources", C_SCOPE);

log(ID_LOG_HDR, "Check defaults on output ports", C_SCOPE);
------------------------------------------------------------
check_value(irq2cpu, '0', ERROR, "Interrupt to CPU must be default inactive", C_SCOPE);
check_value(sbi_if.rdata, x"00", ERROR, "Register data bus output must be default passive");
</pre>

This will give us the following log:

[[File:sim.png|800px]]

This information may only interesting initially and for debug, and can be turned on or off by use of ID.

== Subprograms ==
Some of our testbench code will be repeated several times and the testbench may therefore benefit from creating several subprograms. Obvious examples for our IRQC is:
- Register access
- Signal checkers
- Interrupt source pulsing?
- Interrupt acknowledge pulsing?
- (Report/log method)
- (Alert-handling)
- (reset, set_passive, ...)

We've already created and declared set_passive and pulse procedures, but we could f.ex create overloads for UVVM procedures:
<pre>
-- Log overloads for simplification
procedure log(
msg : string) is
begin
log(ID_SEQUENCER, msg, C_SCOPE);
end;
</pre>

This exact function is already overloaded in the UVVM packages, so including this in our testbench would produce compilation errors. So, let's not include it, but view it as an example of how it's done.

Let's say that it is probable that we'll want to change the number of interrupt sources that the controller can handle. We will then want to able to easily change vectors to the appropriate size. One way is to declare procedures that can trim and fit vectors. This way we can simply change a constant to change the number of sources.

<pre>
subtype t_irq_source is std_logic_vector(C_NUM_SOURCES-1 downto 0);

-- Trim (cut) a given vector to fit the number of irq sources (i.e. pot. reduce width)
function trim(
constant source : std_logic_vector;
constant num_bits : positive := C_NUM_SOURCES)
return t_irq_source is
variable v_result : std_logic_vector(source'length-1 downto 0) := source;
begin
return v_result(num_bits-1 downto 0);
end;

-- Fit a given vector to the number of irq sources by masking with zeros above irq width
function fit(
constant source : std_logic_vector;
constant num_bits : positive := C_NUM_SOURCES)
return std_logic_vector is
variable v_result : std_logic_vector(source'length-1 downto 0) := (others => '0');
variable v_source : std_logic_vector(source'length-1 downto 0) := source;
begin
v_result(num_bits-1 downto 0) := v_source(num_bits-1 downto 0);
return v_result;
end;
</pre>

All IRQC-dedicated subprograms should be declared locally, but more common (f.ex bus-specific) should be declared in common package that can be shared with other.

== Register access ==
To access the IRQC's registers we need to go through the actual process of writing and reading data from them. Fortunately, Bitvis have already taken the responsibility of writing the BFM for the SBI. This doesn't mean that we doesn't have to understand what's going on, since we'll have to write our own BFM's for other buses that we use(Avalon, AXI, etc). '''January 2017 Bitvis announced that they released VVC for Avalon-MM and AXI4-lite.''' So we should investigate the BFM procedures. We want to check register values:
<pre>
procedure sbi_check (
constant addr_value : in unsigned;
constant data_exp : in std_logic_vector;
constant msg : in string;
signal clk : in std_logic;
signal cs : inout std_logic;
signal addr : inout unsigned;
signal rd : inout std_logic;
signal wr : inout std_logic;
signal ready : in std_logic;
signal rdata : in std_logic_vector;
constant alert_level : in t_alert_level := error;
constant scope : in string := C_SCOPE;
constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel;
constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT
) is
constant proc_name : string := "sbi_check";
constant proc_call : string := "sbi_check(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) &
", " & to_string(data_exp, HEX, AS_IS, INCL_RADIX) & ")";
-- Normalize to the DUT addr/data widths
variable v_normalised_addr : unsigned(addr'length-1 downto 0) :=
normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg);
-- Helper variables
variable v_data_value : std_logic_vector(rdata'length - 1 downto 0);
variable v_check_ok : boolean;
variable v_clk_cycles_waited : natural := 0;
begin
sbi_read(addr_value, v_data_value, msg, clk, cs, addr, rd, wr, ready, rdata, scope, msg_id_panel, config, proc_name);

-- Compare values, but ignore any leading zero's if widths are different.
-- Use ID_NEVER so that check_value method does not log when check is OK,
-- log it here instead.
v_check_ok := check_value(v_data_value, data_exp, alert_level, msg, scope, HEX_BIN_IF_INVALID, SKIP_LEADING_0, ID_NEVER, msg_id_panel, proc_call);
if v_check_ok then
log(config.id_for_bfm, proc_call & "=> OK, read data = " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel);
end if;
end procedure;
</pre>

We see that sbi_check() calls sbi_read() before it checks if the read value is the expected value.

<pre>
procedure sbi_read (
constant addr_value : in unsigned;
variable data_value : out std_logic_vector;
constant msg : in string;
signal clk : in std_logic;
signal cs : inout std_logic;
signal addr : inout unsigned;
signal rd : inout std_logic;
signal wr : inout std_logic;
signal ready : in std_logic;
signal rdata : in std_logic_vector;
constant scope : in string := C_SCOPE;
constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel;
constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT;
constant proc_name : in string := "sbi_read" -- overwrite if called from other procedure like sbi_check
) is
constant proc_call : string := "sbi_read(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) & ")";
-- Normalize to the DUT addr/data widths
variable v_normalised_addr : unsigned(addr'length-1 downto 0) :=
normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg);
variable v_data_value : std_logic_vector(data_value'range);
variable v_clk_cycles_waited : natural := 0;
begin
wait_until_given_time_after_rising_edge(clk, config.clock_period/4);
cs <= '1';
wr <= '0';
rd <= '1';
addr <= v_normalised_addr;
wait for config.clock_period;
while (config.use_ready_signal and ready = '0') loop
if v_clk_cycles_waited = 0 then
log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel);
end if;
wait for config.clock_period;
v_clk_cycles_waited := v_clk_cycles_waited + 1;
check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity,
": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call);
end loop;

cs <= '0';
rd <= '0';
v_data_value := rdata;
data_value := v_data_value;
if proc_name = "sbi_read" then
log(config.id_for_bfm, proc_call & "=> " & to_string(v_data_value, HEX, SKIP_LEADING_0, INCL_RADIX) & ". " & msg, scope, msg_id_panel);
else
-- Log will be handled by calling procedure (e.g. sbi_check)
end if;
end procedure;
</pre>

We don't want to (and probably shouldnt) call the sbi_check and providing all the parameters each time. Some of this can be solved by the overloads with more standard parameters, and with our own check procedures declared locally in our testbench:
<pre>
procedure check(
constant addr_value : in natural;
constant data_exp : in std_logic_vector;
constant alert_level : in t_alert_level;
constant msg : in string) is
begin
sbi_check(to_unsigned(addr_value, sbi_if.addr'length), data_exp, msg,
clk, sbi_if, alert_level, C_SCOPE);
end;
</pre>

The write procedure is also very handy and should be understood:
<pre>
procedure sbi_write (
constant addr_value : in unsigned;
constant data_value : in std_logic_vector;
constant msg : in string;
signal clk : in std_logic;
signal cs : inout std_logic;
signal addr : inout unsigned;
signal rd : inout std_logic;
signal wr : inout std_logic;
signal ready : in std_logic;
signal wdata : inout std_logic_vector;
constant scope : in string := C_SCOPE;
constant msg_id_panel : in t_msg_id_panel := shared_msg_id_panel;
constant config : in t_sbi_bfm_config := C_SBI_BFM_CONFIG_DEFAULT
) is
constant proc_name : string := "sbi_write";
constant proc_call : string := "sbi_write(A:" & to_string(addr_value, HEX, AS_IS, INCL_RADIX) &
", " & to_string(data_value, HEX, AS_IS, INCL_RADIX) & ")";
-- Normalise to the DUT addr/data widths
variable v_normalised_addr : unsigned(addr'length-1 downto 0) :=
normalize_and_check(addr_value, addr, ALLOW_WIDER_NARROWER, "addr_value", "sbi_core_in.addr", msg);
variable v_normalised_data : std_logic_vector(wdata'length-1 downto 0) :=
normalize_and_check(data_value, wdata, ALLOW_NARROWER, "data_value", "sbi_core_in.wdata", msg);
variable v_clk_cycles_waited : natural := 0;
begin
wait_until_given_time_after_rising_edge(clk, config.clock_period/4);
cs <= '1';
wr <= '1';
rd <= '0';
addr <= v_normalised_addr;
wdata <= v_normalised_data;

wait for config.clock_period;
while (config.use_ready_signal and ready = '0') loop
if v_clk_cycles_waited = 0 then
log(config.id_for_bfm_wait, proc_call & " waiting for response (sbi ready=0)" & msg, scope, msg_id_panel);
end if;
wait for config.clock_period;
v_clk_cycles_waited := v_clk_cycles_waited + 1;
check_value(v_clk_cycles_waited <= config.max_wait_cycles, config.max_wait_cycles_severity,
": Timeout while waiting for sbi ready", scope, ID_NEVER, msg_id_panel, proc_call);
end loop;

cs <= '0';
wr <= '0';
log(config.id_for_bfm, proc_call & " completed. " & msg, scope, msg_id_panel);
end procedure;
</pre>

We will create a local overload of this too:
<pre>
procedure write(
constant addr_value : in natural;
constant data_value : in std_logic_vector;
constant msg : in string) is
begin
sbi_write(to_unsigned(addr_value, sbi_if.addr'length), data_value, msg,
clk, sbi_if, C_SCOPE);
end;
</pre>

We also need to set the sbi_if.ready signal high for this to work:
<pre>
clock_generator(clk, clock_ena, C_CLK_PERIOD, "IRQC TB clock");

-- Insert this here by the clock generator
sbi_if.ready <= '1'; -- always ready in the same clock cycle.
</pre>

All this enables us to handle transactions at a high level. See Bitvis documentation for how to write your own BFM and what it should include(sanity checks, etc).

[[File:bfm.png|550px]]

== Checking register write and read ==
Now we're enabled to write to and read from the registers. The register addresses are defined in the IRQC package file irqc_pif_bkg.vhd. Notice that we also use the previously declared overloaded version of log() and fit().

<pre>
log(ID_LOG_HDR, "Check register defaults and access (write + read)", C_SCOPE);
------------------------------------------------------------
log("\nChecking Register defaults");
check(C_ADDR_IRR, x"00", ERROR, "IRR default");
check(C_ADDR_IER, x"00", ERROR, "IER default");
check(C_ADDR_IPR, x"00", ERROR, "IPR default");
check(C_ADDR_IRQ2CPU_ALLOWED, x"00", ERROR, "IRQ2CPU_ALLOWED default");

log("\nChecking Register Write/Read");
write(C_ADDR_IER, fit(x"55"), "IER");
check(C_ADDR_IER, fit(x"55"), ERROR, "IER pure readback");
write(C_ADDR_IER, fit(x"AA"), "IER");
check(C_ADDR_IER, fit(x"AA"), ERROR, "IER pure readback");
write(C_ADDR_IER, fit(x"00"), "IER");
check(C_ADDR_IER, fit(x"00"), ERROR, "IER pure readback");
</pre>

This check will give us a nice log if everything turns out ok:

[[File:sim2.png|700px]]

However, if there's an error:

[[File:error2.png|700px]]

== Further tests ==

Now that we've tested register read/write, we should test the trigger/clear mechanism. No further adding of procedures are necessary.
<pre>
log(ID_LOG_HDR, "Check register trigger/clear mechanism", C_SCOPE);
------------------------------------------------------------
write(C_ADDR_ITR, fit(x"AA"), "ITR : Set interrupts");
check(C_ADDR_IRR, fit(x"AA"), ERROR, "IRR");
write(C_ADDR_ITR, fit(x"55"), "ITR : Set more interrupts");
check(C_ADDR_IRR, fit(x"FF"), ERROR, "IRR");
write(C_ADDR_ICR, fit(x"71"), "ICR : Clear interrupts");
check(C_ADDR_IRR, fit(x"8E"), ERROR, "IRR");
write(C_ADDR_ICR, fit(x"85"), "ICR : Clear interrupts");
check(C_ADDR_IRR, fit(x"0A"), ERROR, "IRR");
write(C_ADDR_ITR, fit(x"55"), "ITR : Set more interrupts");
check(C_ADDR_IRR, fit(x"5F"), ERROR, "IRR");
write(C_ADDR_ICR, fit(x"5F"), "ICR : Clear interrupts");
check(C_ADDR_IRR, fit(x"00"), ERROR, "IRR");
</pre>

The UVVM Utility Library provides all necessary functions and procedures to do further tests. F.ex. we should send pulses on the irq_source signal to check if the design behaves correctly.

<pre>
log(ID_LOG_HDR, "Check interrupt sources, IER, IPR and irq2cpu", C_SCOPE);
------------------------------------------------------------
log("\nChecking interrupts and IRR");
write(C_ADDR_ICR, fit(x"FF"), "ICR : Clear all interrupts");
pulse(irq_source, trim(x"AA"), clk, 1, "Pulse irq_source 1T");
check(C_ADDR_IRR, fit(x"AA"), ERROR, "IRR after irq pulses");
pulse(irq_source, trim(x"01"), clk, 1, "Add more interrupts");
check(C_ADDR_IRR, fit(x"AB"), ERROR, "IRR after irq pulses");
pulse(irq_source, trim(x"A1"), clk, 1, "Repeat same interrupts");
check(C_ADDR_IRR, fit(x"AB"), ERROR, "IRR after irq pulses");
pulse(irq_source, trim(x"54"), clk, 1, "Add remaining interrupts");
check(C_ADDR_IRR, fit(x"FF"), ERROR, "IRR after irq pulses");
write(C_ADDR_ICR, fit(x"AA"), "ICR : Clear half the interrupts");
pulse(irq_source, trim(x"A0"), clk, 1, "Add more interrupts");
check(C_ADDR_IRR, fit(x"F5"), ERROR, "IRR after irq pulses");
write(C_ADDR_ICR, fit(x"FF"), "ICR : Clear all interrupts");
check(C_ADDR_IRR, fit(x"00"), ERROR, "IRR after clearing all");
</pre>

=== Check stable ===
Another test provided by UVVM is check_stable(). This function enables us to test if a signal is holding the same value for a minimum provided time. We must declare a variable that holds the time from which we want to test if the signal is stable:

<pre>
v_time_stamp := now; -- time from which irq2cpu should be stable off until triggered
</pre>

Later we're now able to test if the signal has been holding the same value the whole period:
<pre>
check_stable(irq2cpu, (now - v_time_stamp), ERROR, "No spikes allowed on irq2cpu", C_SCOPE);
</pre>

Remember to declare the variable in the process:

<pre>
variable v_time_stamp : time := 0 ns;
</pre>

=== Await value ===
To check if a signal gets the expected value within a specified time value we use await_vale(). The test below throws an error if irq2cpu doesn't obtain the value '1' within 0 ns(!). Therefore expected immediately:

<pre>
await_value(irq2cpu, '1', 0 ns, C_CLK_PERIOD, ERROR, "Interrupt expected immediately", C_SCOPE);
</pre>

=== Other useful functions ===

Check the UVVM Utility Library Quick Reference for syntax details.

==== await_change() ====
Expects and waits for a change on the given signal, inside a given time window.

==== check_value_in_range() ====
Throws an error of the signal value is outside the specified minimum and maximum values.

== UVVM VVC ==
Guide coming....

== UVVM LICENCE AGREEMENT ==
{{reflist}}

[[Category:Mikroelektronikk]]

Synthese av VHDL

2024-01-24T07:58:50Z

Nfyku: /* Precision */

===Syntetiseringen av VHDL kode===

Grunnen til at vi skal syntetisere koden, er at vi må lage beskrivelse av koden tilpassa ein krets.

Vi vil no prøve å synthesisere vhdl kode. Og etterpå vil vi lage ein testbenk der vi samanliknar utsignala frå den syntetiserte og den opprinnelige koden. Vi bruker ein alu som eksempel.

==Precision==

Precision bruker Vivado til å syntetisere vhdl-koden. For å starte synteseprogrammet:

export LM_LICENSE_FILE=1717@lisensserver:2100@lisensserver
source /eda/Siemens/2023-24/scripts/PRECISION_2023.2_RHELx86.sh
precision

Erstatt lisensserver med rett navn på lisensserver.Nye versjoner av programvaren ligger i /eda/Siemens sortert på årstall.

Velg deretter New Project, og deretter Add input file (i dette tilfelle add_sub_alu.vhd).
Så går vi inn på Setup design, velger ein kretsprodusent, den ønska kretsen og designfrekvens, for eksempel Zynq med frekvens 200MHz. For å få ut en vhdl fil av den syntetiserte koden må en gå på Tools->Options->Output og hak av for VHDL og trykk ok.

Pass på at Precision finner Vivado, settes i menyen:
Tools > Options > Place and Route Settings
deretter
Vivado > Integrated Place and Route > path to Xilinx Vivado installation tree
settes til
/eda/xilinx/Vivado/2020.2

Trykk så compile, og synthesize.
No kan vi sjå på den generte kretsen i RTL Schematic og Technology Schematic (syntese med den valgte kretsen) under Schematics på venstre side.

==Questasim==

Start opp Questasim, lag nytt prosjekt og legg til vhdl fila (add_sub_alu.vhdl). Så legg vi til fila som Precision generte i prosjektdir til 'precision/prosjektnavn_temp_1/prosjektnavn.vhd' (i vårt tilfelle 'alu/add_sub_alu_temp_1/add_sub_alu.vhd').

Vi trenger simuleringsbibliotek for den valgte kretsfamilien for å kunne simulere etter "Place and Route". Disse bibliotekene kan genereres fra Vivado med menyen
Tools > Compile Simulation Libraries
men, vi har kompilert disse unisim-bibliotekene til mappen /eda/xilinx/lib. Du kan "mappe" disse slik:

vmap unisim /eda/xilinx/lib/unisim

Deretter legger vi til ei ny vhdl fil der vi skal lage testbenken vår. Vi legger til ein komponent av den opprinnelige og den synthesiserte vhdl koden. Vi koblar alle inngangane til samme signal på testbenken, og gir ut 2 forskjellige utsignal for å samanlikne ved hjelp av assert(sjå fila alu_tb.vhdl). På grunn av at utsignala av dei to komponentane ikkje skifta heilt synkront, testa vi berre kvart nanosekund ved å putta assert inn i ein process med wait for 1ns:

test : process
begin
wait for 1 ns;
assert (data_out = data_out_synt)
report "Data ut er ulik"
severity Error;
end process test;

Når vi har laga testbenken, kompilerer vi filene (husk å kompilere i rett rekkefølge med compileorder->autogenerate første gong).

Siden precision generer samme navn på entityen og architecturen på den syntetiserte filen som i den orginale så vil ikke simulatoren kjøre de samtidig. Dette endres ved å endre entity fra add_sub_alu til add_sub_alu_synth og skifte navnet på architecture fra algoritm til structure øverst og nederst i den syntetiserte filen.

==Simulering med timing==

Eksempel på start av simulering med timing:

vsim -t ps -sdfnoerror -sdfmax /alu_synth=/home/kaf003/VHDL_Prosjekter/PHYS321/vivado_impl_1/add_sub_alu_synth.sdf work.alu_tb

Vi kan sjå at i dei første 50 nanosekunda er utsignala ulike. Dette er fordi før første klokkeflanke er verdiane udefinert i den opprinnelige komponenten, medan den synthesisere ikkje kan ha udefinerte verdiar. I Questasim vil vi derfor få ein del feilmeldingar dei første 50 nanosekunda.

==Konklusjon==

Vi kan teste om den syntesiserte komponenten oppfører seg likt med den opprinnelige komponenten ved å koble begge to til samme testbenk. Vi fekk problem i overgangane når vi testa kontinuerlig, så vi løyste problemet ved å berre teste kvart naonosekund. Bortsett frå dei første 50 nanosekunda (sjå grunn over) kan vi sjå at begge komponetane gir ut samme utsignal. Vi prøvde å bruke samme enitynavn på begge komponentane med ulik arcitechture, men fekk berre lov å kompilere og ikkje simulere. Vi kan derfor konkludere med at desse må ha ulike navn.

==Kode==

===Kode til add_sub_alu.vhd===

<pre>
LIBRARY ieee;
USE ieee.std_logic_1164.All;
USE ieee.std_logic_unsigned.all;

ENTITY add_sub_alu IS
PORT (
clk : IN std_logic;
rst : IN std_logic;
enable_in : IN std_logic;
start : IN std_logic;
enable : IN std_logic;
do_add : IN std_logic;
do_subtract : IN std_logic;
do_hold : IN std_logic;
data_in : IN std_logic_vector(3 DOWNTO 0);
data_out : OUT std_logic_vector(3 DOWNTO 0) BUS);
END add_sub_alu;

ARCHITECTURE algorithm OF add_sub_alu IS
TYPE states IS (hold, reset, add, subtract);
SIGNAL state_var : states;
SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0);
SIGNAL latched_data_in : std_logic_vector(3 DOWNTO 0);
BEGIN

latch: PROCESS (enable_in, data_in)is
BEGIN
IF (enable_in = '1') THEN
latched_data_in <= data_in;
END IF;
END PROCESS latch;

fsm: PROCESS (clk, rst) is
BEGIN
IF (rst = '0') THEN
state_var <= reset;
ELSIF rising_edge(clk) THEN
CASE state_var IS
WHEN hold =>
IF (start = '1') THEN
state_var <= reset;
END IF;
WHEN reset =>
IF (do_add = '1') THEN
state_var <= add;
ELSIF (do_subtract = '1') THEN
state_var <= subtract;
END IF;
WHEN add =>
IF (do_hold = '1') THEN
state_var <= hold;
ELSIF (do_subtract = '1') THEN
state_var <= subtract;
END IF;
WHEN subtract =>
IF (do_hold = '1') THEN
state_var <= hold;
ELSIF (do_add = '1') THEN
state_var <= add;
END IF;
WHEN OTHERS => state_var <= reset;
END CASE;
END IF;
END PROCESS fsm;

alu: PROCESS (state_var, latched_data_in, reg)is
BEGIN
CASE state_var IS
WHEN add => int_reg <= reg + latched_data_in;
WHEN subtract => int_reg <= reg - latched_data_in;
WHEN reset => int_reg <= (others => '0');
WHEN hold => int_reg <= reg;
WHEN OTHERS => int_reg <= reg;
END CASE;
END PROCESS alu;

mem: PROCESS (clk) is
BEGIN
IF rising_edge(clk) THEN
reg <= int_reg;
END IF;
END PROCESS mem;

tri: PROCESS (enable, reg) is
BEGIN
FOR i IN 3 DOWNTO 0 LOOP
IF (enable = '1') THEN
data_out(i) <= reg(i);
ELSE
data_out(i) <= 'Z';
END IF;
END LOOP;
END PROCESS tri;

END algorithm;</pre>

===Koden til alu_tb.vhdl===

<pre>
library ieee;
use ieee.std_logic_1164.all;
library work;
use work.all;

entity alu_tb is
end entity alu_tb;

architecture struct of alu_tb is
--Deklaring av signal som skal koblast til komponentane.
--Alle innsignal er felles, medan vi har 2 forskjellige utsignal.
signal clk : std_logic;
signal reset : std_logic;
signal enable_in : std_logic;
signal start : std_logic;
signal enable : std_logic;
signal do_add : std_logic;
signal do_subtract : std_logic;
signal do_hold : std_logic;
signal data_in : std_logic_vector(3 downto 0);
signal data_out : std_logic_vector(3 downto 0);
signal data_out_synt : std_logic_vector(3 downto 0);

begin
--Deklarer komponenten alu.
alu : entity add_sub_alu(algorithm)
--Kobler signala til den opprinnelige komponenten.
port map (
clk => clk,
rst => reset,
enable_in => enable_in,
start => start,
enable => enable,
do_add => do_add,
do_subtract => do_subtract,
do_hold => do_hold,
data_in => data_in,
data_out => data_out);

--Deklarer komponenten alu_synt.
alu_synt : entity add_sub_alu_synth(structure)
--Kobler signala til den synthiserte komponenten.
port map (
clk => clk,
rst => reset,
enable_in => enable_in,
start => start,
enable => enable,
do_add => do_add,
do_subtract => do_subtract,
do_hold => do_hold,
data_in => data_in,
data_out => data_out_synt);

--Klokkegenerator
clock_gen : process
begin
clk <= '0', '1' after 50 ns;
wait for 100 ns;
end process clock_gen;

--Setter testvektorane.
reset <= '0', '1' after 60 ns;
enable <= '1', '0' after 900 ns;
enable_in <= '1', '0' after 400 ns;
start <= '1', '0' after 300 ns;
do_add <= '1', '0' after 660 ns;
do_subtract <= '0';
do_hold <= '0';
data_in <= X"3";

--Test process for å samanlikne utsignala kvart nanosekund.
test : process
begin
wait for 1 ns;
assert (data_out = data_out_synt)
report "Data ut er ulik"
severity Error;
end process test;

end architecture struct;
</pre>

[[Category:Mikroelektronikk]]

Simulering av VHDL

2024-01-24T07:54:24Z

Nfyku: /* Starte Questa Sim */

===Konstruksjon og simulering av VHDL-kode med Modelsim/Questa===

==Innledning==

Hensikten med denne oppgaven er å få et lite innblikk i bruk av høynivåspråk for simulering og uttesting av kretsløsninger. I denne oppgaven skal vi bruker VHDL (Very high speed integrated circuit Hardware Description Language), som er spesielt utviklet for elektronikk. VHDL er definert slik at det passer i en mengde sammenhenger, og er det vil derfor være uoverkommelig å gå inn på detaljer i denne oppgaven. Vi skal ta for oss noen eksempler:

* Eksempel 1: Signalflyt i en SR-lås

* Eksempel 2: Signaler og variable

Et VHDL program består i hovedsak av ENTITY, som definerer tilkobling mellom programmet og omverden, og ARCHITECTURE, som definerer programmets funksjon. Den komplette VHDL-koden for eksempel 1 vist nederst på denne siden.Mentor Graphics har utviklet programvare (Modelsim//Questa) som gjør det mulig å beskrivem, simulere og feilsøke VHDL-kode. Fremgangsmåten for skriving, kompilering og simulering av VHDL-kode finner du under.

==Starte Questa Sim==
Når man skal arbeide med Questa Sim fra Mentor Graphics skriv følgende kommando i et terminalvindu.
Generelt ligger programvaren i /eda/Siemens, og versjonene ligger i mapper sortert på årstall.

ssh -X mikroserver4
export LM_LICENSE_FILE=1717@lisensserver
source /eda/Siemens/2023-24/scripts/QUESTA-CORE-PRIME_2023.4_RHELx86.sh
vsim

==Lage et nytt prosjekt==

I den følgende teksten er det vist hvordan man kan utføre kompilering, etc. på kommandolinjen. Dette kan enten gjøres i fra X terminalvinduet, eller fra kommandolinjen i Questa. Hvis man velger å bruke Questa-miljøet er de fleste prosedyrer/kommandoer tilgjengelige under menyen.

Start et nytt prosjekt med

<pre>
File > New > Project
</pre>

[[Image:questa_new_project.png]]

Velg et fornuftig navn og katalog. Man kan gjerne ha flere uavhengige vhdl-filer i et prosjekt.
Det er en fordel å ha en hovedkatalog til vhdl prosjektene og en underkatalog for prosjektet fex /home/bruker/vhdl_prosjekt/sr_latch

==Skriving av VHDL kode==

En ny VHDL kode (et design beskrevet med VHDL kode) påbegynnes med å starte emacs i terminal vinduet eller ved å bruke den innebygde teksteditoren i Questa ved å velge Create New File.

Det fine med emacs er at man kan velge VHDL-modus. Dette gjøres med å skrive ''M-x vhdl-mode'' (M står for ''Meta'' og er vanligvis definert som esc-knappen). I emacs har en menyer med alle valg oppe langs kanten som i andre teksteditorer, men programmet skiller seg litt ut med kommandolinjen nederst i vinduet. Når en f. eks. skal lagre filen en har skrevet blir denne kommandolinjen aktiv og en skriver inn sti og filnavn der. Når man lagrer er ikke navnet på kodefilen viktig, men det er fornuftig å kalle den det samme som ENTITY-delen, med ''.vhdl'' som "etternavn" (f. eks. sr_latch.vhdl).

==Kompilering av VHDL kode==

Koden kompileres med

<pre>
vcom sr_latch.vhdl
</pre>

Hvis det er feil i koden vil det komme en melding i kommando vinduet. Dobbeltklikker du på feilen vil du få opp en liste over kompileringsprosessen og alle feilene. Dobbeltklikker du så på linjen som angir en feil så vises den respektive linjen i editoren.

Merk at navnet til det kompilerte designet blir skrevet med små bokstaver, selv om du har brukt store bokstaver i ENTITY- eller ARCHITECTURE-navnet. Det kompilerte designet blir liggende i work-katalogen.

==Simulering og debugging i Questa==

Når koden kompilerer feilfritt kan den simuleres i Questa. Dette startes med:

<pre>
vsim
</pre>

Nå dukker det opp en rute der du skal velge hva som skal simuleres, utvid work og velg vhdl filen. Eventuellt kan du skrive vsim work.sr_latch i kommandovinduet

Questa bruker et standard X-basert vindusoppsett, og er derfor noen forskjellig fra de andre Mentor-programmene. Når du starter simulatoren åpnes det et vindu som vist i figur 1. Begynn med å åpne diverse vinduer:

* View > Wave

* View > Objects

* View > Locals

Man kan også gi kommandoer i Questa-vinduet. F.eks.

<pre>
Wave *
</pre>

Dra de signalene du vil se på i wave vinduet fra object vinduet.

Signalverdier settes med kommandoen 'force' eller med

<pre>
Force > Force (i "Signals" vinduet)
</pre>

Dersom et av signalene skal være klokkesignal, kan dette gjøres enkelt med

<pre>
Force > Clock (i "Signals" vinduet)
</pre>

==Eksempler==
===Signalflyt i en SR-lås===

Simuler SR-låsen. Begynn med å påtrykke stimuli til alle signaler ved tid 0 (t0). Bruk STEP-knappen for å simulere på delta-tid-nivå. (Om en holder musepekeren over knappene i Questa, kommer det en forklarende tekst opp.) Når verdiene er stabile kjører du i f.eks. 100 ns før du endrer stimuli (skriv ''run 100'' i et av vinduene). Tilsvarende kan du endre stimuli ved å skrive f.eks. ''force S 0'' i hoved-vinduet. Legg merke til den røde pilen som peker på den linjen som blir utført.

Hvis du vil begynne på ny kan du velge

<pre>
File > Restart -f
</pre>

<pre>
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;

ENTITY SR_latch IS
PORT (
S,R : IN std_logic ;
Q,QB : INOUT std_logic );
END SR_latch;

-------------------------------------------------------------------------------

ARCHITECTURE behave OF SR_latch IS

BEGIN -- behave
Q <= S nand QB;
QB <= R nand Q;
END behave;
</pre>

===Signaler og variable===

Simuler VHDL-koden under. Bruk Step eller Step Over for å følge prosedyrens utvikling linje for linje. Simulere med optimaliseringsopsjon "-voptargs=+acc" for å kunne se variablene i wave-vinduet:

vsim -voptargs=+acc sign_var

Bruk View > Objects for å kikke på signalene og View > Local for å se innholdet i variablene. Forklar endringene i signaler og variable. Hva er forskjellen som funksjon av tid/delta-tid?

<pre>
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;

ENTITY sign_var IS
PORT (clk : IN std_logic);
END sign_var;

-------------------------------------------------------------------------------

ARCHITECTURE difference OF sign_var IS

signal SA: bit := '0';
signal SB: bit := '1';

begin -- difference
p_test: process
variable A: bit := '0';
variable B: bit := '1';
begin
wait until rising_edge(clk);
A := B;
B := A;
SA <= SB after 5 ns;
SB <= SA after 5 ns;
end process p_test;
end architecture difference;
</pre>

Synthese av VHDL

2021-02-05T13:44:45Z

Nfyku: oppdatert sdf-inkludering med sdfnoerror

===Syntetiseringen av VHDL kode===

Grunnen til at vi skal syntetisere koden, er at vi må lage beskrivelse av koden tilpassa ein krets.

Vi vil no prøve å synthesisere vhdl kode. Og etterpå vil vi lage ein testbenk der vi samanliknar utsignala frå den syntetiserte og den opprinnelige koden. Vi bruker ein alu som eksempel.

==Precision==

Precision bruker Vivado til å syntetisere vhdl-koden. For å starte synteseprogrammet:

export LM_LICENSE_FILE=1717@lisensserver:2100@lisensserver
source /eda/mentor/2019-20/scripts/PRECISION_2019.1.1_RHELx86.sh
precision

Vel deretter New Project, og deretter Add input file (i dette tilfelle add_sub_alu.vhd).
Så går vi inn på Setup design, velger ein kretsprodusent, den ønska kretsen og designfrekvens, for eksempel Zynq med frekvens 200MHz. For å få ut en vhdl fil av den syntetiserte koden må en gå på Tools->Options->Output og hak av for VHDL og trykk ok.

Pass på at Precision finner Vivado, settes i menyen:
Tools > Options > Place and Route Settings
deretter
Vivado > Integrated Place and Route > path to Xilinx Vivado installation tree
settes til
/eda/xilinx/Vivado/2020.2

Trykk så compile, og synthesize.
No kan vi sjå på den generte kretsen i RTL Schematic og Technology Schematic (syntese med den valgte kretsen) under Schematics på venstre side.

==Questasim==

Start opp Questasim, lag nytt prosjekt og legg til vhdl fila (add_sub_alu.vhdl). Så legg vi til fila som Precision generte i prosjektdir til 'precision/prosjektnavn_temp_1/prosjektnavn.vhd' (i vårt tilfelle 'alu/add_sub_alu_temp_1/add_sub_alu.vhd').

Vi trenger simuleringsbibliotek for den valgte kretsfamilien for å kunne simulere etter "Place and Route". Disse bibliotekene kan genereres fra Vivado med menyen
Tools > Compile Simulation Libraries
men, vi har kompilert disse unisim-bibliotekene til mappen /eda/xilinx/lib. Du kan "mappe" disse slik:

vmap unisim /eda/xilinx/lib/unisim

Deretter legger vi til ei ny vhdl fil der vi skal lage testbenken vår. Vi legger til ein komponent av den opprinnelige og den synthesiserte vhdl koden. Vi koblar alle inngangane til samme signal på testbenken, og gir ut 2 forskjellige utsignal for å samanlikne ved hjelp av assert(sjå fila alu_tb.vhdl). På grunn av at utsignala av dei to komponentane ikkje skifta heilt synkront, testa vi berre kvart nanosekund ved å putta assert inn i ein process med wait for 1ns:

test : process
begin
wait for 1 ns;
assert (data_out = data_out_synt)
report "Data ut er ulik"
severity Error;
end process test;

Når vi har laga testbenken, kompilerer vi filene (husk å kompilere i rett rekkefølge med compileorder->autogenerate første gong).

Siden precision generer samme navn på entityen og architecturen på den syntetiserte filen som i den orginale så vil ikke simulatoren kjøre de samtidig. Dette endres ved å endre entity fra add_sub_alu til add_sub_alu_synth og skifte navnet på architecture fra algoritm til structure øverst og nederst i den syntetiserte filen.

==Simulering med timing==

Eksempel på start av simulering med timing:

vsim -t ps -sdfnoerror -sdfmax /alu_synth=/home/kaf003/VHDL_Prosjekter/PHYS321/vivado_impl_1/add_sub_alu_synth.sdf work.alu_tb

Vi kan sjå at i dei første 50 nanosekunda er utsignala ulike. Dette er fordi før første klokkeflanke er verdiane udefinert i den opprinnelige komponenten, medan den synthesisere ikkje kan ha udefinerte verdiar. I Questasim vil vi derfor få ein del feilmeldingar dei første 50 nanosekunda.

==Konklusjon==

Vi kan teste om den syntesiserte komponenten oppfører seg likt med den opprinnelige komponenten ved å koble begge to til samme testbenk. Vi fekk problem i overgangane når vi testa kontinuerlig, så vi løyste problemet ved å berre teste kvart naonosekund. Bortsett frå dei første 50 nanosekunda (sjå grunn over) kan vi sjå at begge komponetane gir ut samme utsignal. Vi prøvde å bruke samme enitynavn på begge komponentane med ulik arcitechture, men fekk berre lov å kompilere og ikkje simulere. Vi kan derfor konkludere med at desse må ha ulike navn.

==Kode==

===Kode til add_sub_alu.vhd===

<pre>
LIBRARY ieee;
USE ieee.std_logic_1164.All;
USE ieee.std_logic_unsigned.all;

ENTITY add_sub_alu IS
PORT (
clk : IN std_logic;
rst : IN std_logic;
enable_in : IN std_logic;
start : IN std_logic;
enable : IN std_logic;
do_add : IN std_logic;
do_subtract : IN std_logic;
do_hold : IN std_logic;
data_in : IN std_logic_vector(3 DOWNTO 0);
data_out : OUT std_logic_vector(3 DOWNTO 0) BUS);
END add_sub_alu;

ARCHITECTURE algorithm OF add_sub_alu IS
TYPE states IS (hold, reset, add, subtract);
SIGNAL state_var : states;
SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0);
SIGNAL latched_data_in : std_logic_vector(3 DOWNTO 0);
BEGIN

latch: PROCESS (enable_in, data_in)is
BEGIN
IF (enable_in = '1') THEN
latched_data_in <= data_in;
END IF;
END PROCESS latch;

fsm: PROCESS (clk, rst) is
BEGIN
IF (rst = '0') THEN
state_var <= reset;
ELSIF rising_edge(clk) THEN
CASE state_var IS
WHEN hold =>
IF (start = '1') THEN
state_var <= reset;
END IF;
WHEN reset =>
IF (do_add = '1') THEN
state_var <= add;
ELSIF (do_subtract = '1') THEN
state_var <= subtract;
END IF;
WHEN add =>
IF (do_hold = '1') THEN
state_var <= hold;
ELSIF (do_subtract = '1') THEN
state_var <= subtract;
END IF;
WHEN subtract =>
IF (do_hold = '1') THEN
state_var <= hold;
ELSIF (do_add = '1') THEN
state_var <= add;
END IF;
WHEN OTHERS => state_var <= reset;
END CASE;
END IF;
END PROCESS fsm;

alu: PROCESS (state_var, latched_data_in, reg)is
BEGIN
CASE state_var IS
WHEN add => int_reg <= reg + latched_data_in;
WHEN subtract => int_reg <= reg - latched_data_in;
WHEN reset => int_reg <= (others => '0');
WHEN hold => int_reg <= reg;
WHEN OTHERS => int_reg <= reg;
END CASE;
END PROCESS alu;

mem: PROCESS (clk) is
BEGIN
IF rising_edge(clk) THEN
reg <= int_reg;
END IF;
END PROCESS mem;

tri: PROCESS (enable, reg) is
BEGIN
FOR i IN 3 DOWNTO 0 LOOP
IF (enable = '1') THEN
data_out(i) <= reg(i);
ELSE
data_out(i) <= 'Z';
END IF;
END LOOP;
END PROCESS tri;

END algorithm;</pre>

===Koden til alu_tb.vhdl===

<pre>
library ieee;
use ieee.std_logic_1164.all;
library work;
use work.all;

entity alu_tb is
end entity alu_tb;

architecture struct of alu_tb is
--Deklaring av signal som skal koblast til komponentane.
--Alle innsignal er felles, medan vi har 2 forskjellige utsignal.
signal clk : std_logic;
signal reset : std_logic;
signal enable_in : std_logic;
signal start : std_logic;
signal enable : std_logic;
signal do_add : std_logic;
signal do_subtract : std_logic;
signal do_hold : std_logic;
signal data_in : std_logic_vector(3 downto 0);
signal data_out : std_logic_vector(3 downto 0);
signal data_out_synt : std_logic_vector(3 downto 0);

begin
--Deklarer komponenten alu.
alu : entity add_sub_alu(algorithm)
--Kobler signala til den opprinnelige komponenten.
port map (
clk => clk,
rst => reset,
enable_in => enable_in,
start => start,
enable => enable,
do_add => do_add,
do_subtract => do_subtract,
do_hold => do_hold,
data_in => data_in,
data_out => data_out);

--Deklarer komponenten alu_synt.
alu_synt : entity add_sub_alu_synth(structure)
--Kobler signala til den synthiserte komponenten.
port map (
clk => clk,
rst => reset,
enable_in => enable_in,
start => start,
enable => enable,
do_add => do_add,
do_subtract => do_subtract,
do_hold => do_hold,
data_in => data_in,
data_out => data_out_synt);

--Klokkegenerator
clock_gen : process
begin
clk <= '0', '1' after 50 ns;
wait for 100 ns;
end process clock_gen;

--Setter testvektorane.
reset <= '0', '1' after 60 ns;
enable <= '1', '0' after 900 ns;
enable_in <= '1', '0' after 400 ns;
start <= '1', '0' after 300 ns;
do_add <= '1', '0' after 660 ns;
do_subtract <= '0';
do_hold <= '0';
data_in <= X"3";

--Test process for å samanlikne utsignala kvart nanosekund.
test : process
begin
wait for 1 ns;
assert (data_out = data_out_synt)
report "Data ut er ulik"
severity Error;
end process test;

end architecture struct;
</pre>

[[Category:Mikroelektronikk]]

Synthese av VHDL

2021-02-05T12:10:31Z

Nfyku: /* Koden til alu_tb.vhdl */

===Syntetiseringen av VHDL kode===

Grunnen til at vi skal syntetisere koden, er at vi må lage beskrivelse av koden tilpassa ein krets.

Vi vil no prøve å synthesisere vhdl kode. Og etterpå vil vi lage ein testbenk der vi samanliknar utsignala frå den syntetiserte og den opprinnelige koden. Vi bruker ein alu som eksempel.

==Precision==

Precision bruker Vivado til å syntetisere vhdl-koden. For å starte synteseprogrammet:

export LM_LICENSE_FILE=1717@lisensserver:2100@lisensserver
source /eda/mentor/2019-20/scripts/PRECISION_2019.1.1_RHELx86.sh
precision

Vel deretter New Project, og deretter Add input file (i dette tilfelle add_sub_alu.vhd).
Så går vi inn på Setup design, velger ein kretsprodusent, den ønska kretsen og designfrekvens, for eksempel Zynq med frekvens 200MHz. For å få ut en vhdl fil av den syntetiserte koden må en gå på Tools->Options->Output og hak av for VHDL og trykk ok.

Pass på at Precision finner Vivado, settes i menyen:
Tools > Options > Place and Route Settings
deretter
Vivado > Integrated Place and Route > path to Xilinx Vivado installation tree
settes til
/eda/xilinx/Vivado/2020.2

Trykk så compile, og synthesize.
No kan vi sjå på den generte kretsen i RTL Schematic og Technology Schematic (syntese med den valgte kretsen) under Schematics på venstre side.

==Questasim==

Start opp Questasim, lag nytt prosjekt og legg til vhdl fila (add_sub_alu.vhdl). Så legg vi til fila som Precision generte i prosjektdir til 'precision/prosjektnavn_temp_1/prosjektnavn.vhd' (i vårt tilfelle 'alu/add_sub_alu_temp_1/add_sub_alu.vhd').

Vi trenger simuleringsbibliotek for den valgte kretsfamilien for å kunne simulere etter "Place and Route". Disse bibliotekene kan genereres fra Vivado med menyen
Tools > Compile Simulation Libraries
men, vi har kompilert disse unisim-bibliotekene til mappen /eda/xilinx/lib. Du kan "mappe" disse slik:

vmap unisim /eda/xilinx/lib/unisim

Deretter legger vi til ei ny vhdl fil der vi skal lage testbenken vår. Vi legger til ein komponent av den opprinnelige og den synthesiserte vhdl koden. Vi koblar alle inngangane til samme signal på testbenken, og gir ut 2 forskjellige utsignal for å samanlikne ved hjelp av assert(sjå fila alu_tb.vhdl). På grunn av at utsignala av dei to komponentane ikkje skifta heilt synkront, testa vi berre kvart nanosekund ved å putta assert inn i ein process med wait for 1ns:

test : process
begin
wait for 1 ns;
assert (data_out = data_out_synt)
report "Data ut er ulik"
severity Error;
end process test;

Når vi har laga testbenken, kompilerer vi filene (husk å kompilere i rett rekkefølge med compileorder->autogenerate første gong).

Siden precision generer samme navn på entityen og architecturen på den syntetiserte filen som i den orginale så vil ikke simulatoren kjøre de samtidig. Dette endres ved å endre entity fra add_sub_alu til add_sub_alu_synth og skifte navnet på architecture fra algoritm til structure øverst og nederst i den syntetiserte filen.

==Simulering med timing==

Eksempel på start av simulering med timing:

vsim -t ps alu_tb -sdfmax :alu_tb:ali=/heim/yngve/vhdl/syntese/alu_temp_1/simulation/modelsim/add_sub_alu_vhd.sdo

Vi kan sjå at i dei første 50 nanosekunda er utsignala ulike. Dette er fordi før første klokkeflanke er verdiane udefinert i den opprinnelige komponenten, medan den synthesisere ikkje kan ha udefinerte verdiar. I Questasim vil vi derfor få ein del feilmeldingar dei første 50 nanosekunda.

==Konklusjon==

Vi kan teste om den syntesiserte komponenten oppfører seg likt med den opprinnelige komponenten ved å koble begge to til samme testbenk. Vi fekk problem i overgangane når vi testa kontinuerlig, så vi løyste problemet ved å berre teste kvart naonosekund. Bortsett frå dei første 50 nanosekunda (sjå grunn over) kan vi sjå at begge komponetane gir ut samme utsignal. Vi prøvde å bruke samme enitynavn på begge komponentane med ulik arcitechture, men fekk berre lov å kompilere og ikkje simulere. Vi kan derfor konkludere med at desse må ha ulike navn.

==Kode==

===Kode til add_sub_alu.vhd===

<pre>
LIBRARY ieee;
USE ieee.std_logic_1164.All;
USE ieee.std_logic_unsigned.all;

ENTITY add_sub_alu IS
PORT (
clk : IN std_logic;
rst : IN std_logic;
enable_in : IN std_logic;
start : IN std_logic;
enable : IN std_logic;
do_add : IN std_logic;
do_subtract : IN std_logic;
do_hold : IN std_logic;
data_in : IN std_logic_vector(3 DOWNTO 0);
data_out : OUT std_logic_vector(3 DOWNTO 0) BUS);
END add_sub_alu;

ARCHITECTURE algorithm OF add_sub_alu IS
TYPE states IS (hold, reset, add, subtract);
SIGNAL state_var : states;
SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0);
SIGNAL latched_data_in : std_logic_vector(3 DOWNTO 0);
BEGIN

latch: PROCESS (enable_in, data_in)is
BEGIN
IF (enable_in = '1') THEN
latched_data_in <= data_in;
END IF;
END PROCESS latch;

fsm: PROCESS (clk, rst) is
BEGIN
IF (rst = '0') THEN
state_var <= reset;
ELSIF rising_edge(clk) THEN
CASE state_var IS
WHEN hold =>
IF (start = '1') THEN
state_var <= reset;
END IF;
WHEN reset =>
IF (do_add = '1') THEN
state_var <= add;
ELSIF (do_subtract = '1') THEN
state_var <= subtract;
END IF;
WHEN add =>
IF (do_hold = '1') THEN
state_var <= hold;
ELSIF (do_subtract = '1') THEN
state_var <= subtract;
END IF;
WHEN subtract =>
IF (do_hold = '1') THEN
state_var <= hold;
ELSIF (do_add = '1') THEN
state_var <= add;
END IF;
WHEN OTHERS => state_var <= reset;
END CASE;
END IF;
END PROCESS fsm;

alu: PROCESS (state_var, latched_data_in, reg)is
BEGIN
CASE state_var IS
WHEN add => int_reg <= reg + latched_data_in;
WHEN subtract => int_reg <= reg - latched_data_in;
WHEN reset => int_reg <= (others => '0');
WHEN hold => int_reg <= reg;
WHEN OTHERS => int_reg <= reg;
END CASE;
END PROCESS alu;

mem: PROCESS (clk) is
BEGIN
IF rising_edge(clk) THEN
reg <= int_reg;
END IF;
END PROCESS mem;

tri: PROCESS (enable, reg) is
BEGIN
FOR i IN 3 DOWNTO 0 LOOP
IF (enable = '1') THEN
data_out(i) <= reg(i);
ELSE
data_out(i) <= 'Z';
END IF;
END LOOP;
END PROCESS tri;

END algorithm;</pre>

===Koden til alu_tb.vhdl===

<pre>
library ieee;
use ieee.std_logic_1164.all;
library work;
use work.all;

entity alu_tb is
end entity alu_tb;

architecture struct of alu_tb is
--Deklaring av signal som skal koblast til komponentane.
--Alle innsignal er felles, medan vi har 2 forskjellige utsignal.
signal clk : std_logic;
signal reset : std_logic;
signal enable_in : std_logic;
signal start : std_logic;
signal enable : std_logic;
signal do_add : std_logic;
signal do_subtract : std_logic;
signal do_hold : std_logic;
signal data_in : std_logic_vector(3 downto 0);
signal data_out : std_logic_vector(3 downto 0);
signal data_out_synt : std_logic_vector(3 downto 0);

begin
--Deklarer komponenten alu.
alu : entity add_sub_alu(algorithm)
--Kobler signala til den opprinnelige komponenten.
port map (
clk => clk,
rst => reset,
enable_in => enable_in,
start => start,
enable => enable,
do_add => do_add,
do_subtract => do_subtract,
do_hold => do_hold,
data_in => data_in,
data_out => data_out);

--Deklarer komponenten alu_synt.
alu_synt : entity add_sub_alu_synth(structure)
--Kobler signala til den synthiserte komponenten.
port map (
clk => clk,
rst => reset,
enable_in => enable_in,
start => start,
enable => enable,
do_add => do_add,
do_subtract => do_subtract,
do_hold => do_hold,
data_in => data_in,
data_out => data_out_synt);

--Klokkegenerator
clock_gen : process
begin
clk <= '0', '1' after 50 ns;
wait for 100 ns;
end process clock_gen;

--Setter testvektorane.
reset <= '0', '1' after 60 ns;
enable <= '1', '0' after 900 ns;
enable_in <= '1', '0' after 400 ns;
start <= '1', '0' after 300 ns;
do_add <= '1', '0' after 660 ns;
do_subtract <= '0';
do_hold <= '0';
data_in <= X"3";

--Test process for å samanlikne utsignala kvart nanosekund.
test : process
begin
wait for 1 ns;
assert (data_out = data_out_synt)
report "Data ut er ulik"
severity Error;
end process test;

end architecture struct;
</pre>

[[Category:Mikroelektronikk]]

Synthese av VHDL

2021-02-05T08:05:35Z

Nfyku: /* Precision */

===Syntetiseringen av VHDL kode===

Grunnen til at vi skal syntetisere koden, er at vi må lage beskrivelse av koden tilpassa ein krets.

Vi vil no prøve å synthesisere vhdl kode. Og etterpå vil vi lage ein testbenk der vi samanliknar utsignala frå den syntetiserte og den opprinnelige koden. Vi bruker ein alu som eksempel.

==Precision==

Precision bruker Vivado til å syntetisere vhdl-koden. For å starte synteseprogrammet:

export LM_LICENSE_FILE=1717@lisensserver:2100@lisensserver
source /eda/mentor/2019-20/scripts/PRECISION_2019.1.1_RHELx86.sh
precision

Vel deretter New Project, og deretter Add input file (i dette tilfelle add_sub_alu.vhd).
Så går vi inn på Setup design, velger ein kretsprodusent, den ønska kretsen og designfrekvens, for eksempel Zynq med frekvens 200MHz. For å få ut en vhdl fil av den syntetiserte koden må en gå på Tools->Options->Output og hak av for VHDL og trykk ok.

Pass på at Precision finner Vivado, settes i menyen:
Tools > Options > Place and Route Settings
deretter
Vivado > Integrated Place and Route > path to Xilinx Vivado installation tree
settes til
/eda/xilinx/Vivado/2020.2

Trykk så compile, og synthesize.
No kan vi sjå på den generte kretsen i RTL Schematic og Technology Schematic (syntese med den valgte kretsen) under Schematics på venstre side.

==Questasim==

Start opp Questasim, lag nytt prosjekt og legg til vhdl fila (add_sub_alu.vhdl). Så legg vi til fila som Precision generte i prosjektdir til 'precision/prosjektnavn_temp_1/prosjektnavn.vhd' (i vårt tilfelle 'alu/add_sub_alu_temp_1/add_sub_alu.vhd').

Vi trenger simuleringsbibliotek for den valgte kretsfamilien for å kunne simulere etter "Place and Route". Disse bibliotekene kan genereres fra Vivado med menyen
Tools > Compile Simulation Libraries
men, vi har kompilert disse unisim-bibliotekene til mappen /eda/xilinx/lib. Du kan "mappe" disse slik:

vmap unisim /eda/xilinx/lib/unisim

Deretter legger vi til ei ny vhdl fil der vi skal lage testbenken vår. Vi legger til ein komponent av den opprinnelige og den synthesiserte vhdl koden. Vi koblar alle inngangane til samme signal på testbenken, og gir ut 2 forskjellige utsignal for å samanlikne ved hjelp av assert(sjå fila alu_tb.vhdl). På grunn av at utsignala av dei to komponentane ikkje skifta heilt synkront, testa vi berre kvart nanosekund ved å putta assert inn i ein process med wait for 1ns:

test : process
begin
wait for 1 ns;
assert (data_out = data_out_synt)
report "Data ut er ulik"
severity Error;
end process test;

Når vi har laga testbenken, kompilerer vi filene (husk å kompilere i rett rekkefølge med compileorder->autogenerate første gong).

Siden precision generer samme navn på entityen og architecturen på den syntetiserte filen som i den orginale så vil ikke simulatoren kjøre de samtidig. Dette endres ved å endre entity fra add_sub_alu til add_sub_alu_synth og skifte navnet på architecture fra algoritm til structure øverst og nederst i den syntetiserte filen.

==Simulering med timing==

Eksempel på start av simulering med timing:

vsim -t ps alu_tb -sdfmax :alu_tb:ali=/heim/yngve/vhdl/syntese/alu_temp_1/simulation/modelsim/add_sub_alu_vhd.sdo

Vi kan sjå at i dei første 50 nanosekunda er utsignala ulike. Dette er fordi før første klokkeflanke er verdiane udefinert i den opprinnelige komponenten, medan den synthesisere ikkje kan ha udefinerte verdiar. I Questasim vil vi derfor få ein del feilmeldingar dei første 50 nanosekunda.

==Konklusjon==

Vi kan teste om den syntesiserte komponenten oppfører seg likt med den opprinnelige komponenten ved å koble begge to til samme testbenk. Vi fekk problem i overgangane når vi testa kontinuerlig, så vi løyste problemet ved å berre teste kvart naonosekund. Bortsett frå dei første 50 nanosekunda (sjå grunn over) kan vi sjå at begge komponetane gir ut samme utsignal. Vi prøvde å bruke samme enitynavn på begge komponentane med ulik arcitechture, men fekk berre lov å kompilere og ikkje simulere. Vi kan derfor konkludere med at desse må ha ulike navn.

==Kode==

===Kode til add_sub_alu.vhd===

<pre>
LIBRARY ieee;
USE ieee.std_logic_1164.All;
USE ieee.std_logic_unsigned.all;

ENTITY add_sub_alu IS
PORT (
clk : IN std_logic;
rst : IN std_logic;
enable_in : IN std_logic;
start : IN std_logic;
enable : IN std_logic;
do_add : IN std_logic;
do_subtract : IN std_logic;
do_hold : IN std_logic;
data_in : IN std_logic_vector(3 DOWNTO 0);
data_out : OUT std_logic_vector(3 DOWNTO 0) BUS);
END add_sub_alu;

ARCHITECTURE algorithm OF add_sub_alu IS
TYPE states IS (hold, reset, add, subtract);
SIGNAL state_var : states;
SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0);
SIGNAL latched_data_in : std_logic_vector(3 DOWNTO 0);
BEGIN

latch: PROCESS (enable_in, data_in)is
BEGIN
IF (enable_in = '1') THEN
latched_data_in <= data_in;
END IF;
END PROCESS latch;

fsm: PROCESS (clk, rst) is
BEGIN
IF (rst = '0') THEN
state_var <= reset;
ELSIF rising_edge(clk) THEN
CASE state_var IS
WHEN hold =>
IF (start = '1') THEN
state_var <= reset;
END IF;
WHEN reset =>
IF (do_add = '1') THEN
state_var <= add;
ELSIF (do_subtract = '1') THEN
state_var <= subtract;
END IF;
WHEN add =>
IF (do_hold = '1') THEN
state_var <= hold;
ELSIF (do_subtract = '1') THEN
state_var <= subtract;
END IF;
WHEN subtract =>
IF (do_hold = '1') THEN
state_var <= hold;
ELSIF (do_add = '1') THEN
state_var <= add;
END IF;
WHEN OTHERS => state_var <= reset;
END CASE;
END IF;
END PROCESS fsm;

alu: PROCESS (state_var, latched_data_in, reg)is
BEGIN
CASE state_var IS
WHEN add => int_reg <= reg + latched_data_in;
WHEN subtract => int_reg <= reg - latched_data_in;
WHEN reset => int_reg <= (others => '0');
WHEN hold => int_reg <= reg;
WHEN OTHERS => int_reg <= reg;
END CASE;
END PROCESS alu;

mem: PROCESS (clk) is
BEGIN
IF rising_edge(clk) THEN
reg <= int_reg;
END IF;
END PROCESS mem;

tri: PROCESS (enable, reg) is
BEGIN
FOR i IN 3 DOWNTO 0 LOOP
IF (enable = '1') THEN
data_out(i) <= reg(i);
ELSE
data_out(i) <= 'Z';
END IF;
END LOOP;
END PROCESS tri;

END algorithm;</pre>

===Koden til alu_tb.vhdl===

<pre>
library ieee;
use ieee.std_logic_1164.all;
library work;
use work.all;

entity alu_tb is
end entity alu_tb;

architecture struct of alu_tb is
--Deklaring av signal som skal koblast til komponentane.
--Alle innsignal er felles, medan vi har 2 forskjellige utsignal.
signal clk, reset : std_logic;
signal enable_in : std_logic;
signal start : std_logic;
signal enable : std_logic;
signal do_add : std_logic;
signal do_subtract : std_logic;
signal do_hold : std_logic;
signal data_in : std_logic_vector(3 downto 0);
signal data_out : std_logic_vector(3 downto 0);
signal data_out_synt : std_logic_vector(3 downto 0);

begin

--Deklarer komponenten alu.
alu : entity add_sub_alu(algorithm)

--Kobler signala til den opprinnelige komponenten.
port map (
clk => clk,
rst => reset,
enable_in => enable_in,
start => start,
enable => enable,
do_add => do_add,
do_subtract => do_subtract,
do_hold => do_hold,
data_in => data_in,
data_out => data_out);

--Deklarer komponenten alu_synt.
alu_synt : entity add_sub_alu_synth(structure)

--Kobler signala til den synthiserte komponenten.
port map (
clk => clk,
rst => reset,
enable_in => enable_in,
start => start,
enable => enable,
do_add => do_add,
do_subtract => do_subtract,
do_hold => do_hold,
data_in => data_in,
data_out => data_out_synt);

--Klokkegenerator
clock_gen : process
begin
clk <= '0', '1' after 50 ns;
wait for 100 ns;
end process clock_gen;

--Setter testvektorane.
reset <= '0', '1' after 60 ns;
enable <= '1', '0' after 900 ns;
enable_in <= '1', '0' after 400 ns;
start <= '1', '0' after 300 ns;
do_add <= '1', '0' after 660 ns;
do_subtract <= '0';
do_hold <= '0';
data_in <= X"3";

--Test process for å samanlikne utsignala kvart nanosekund.
test : process
begin
wait for 1 ns;
assert (data_out = data_out_synt)
report "Data ut er ulik"
severity Error;
end process test;

end;

</pre>

[[Category:Mikroelektronikk]]

Modelsim/Questa

2021-02-04T21:13:27Z

Nfyku: /* Referanselitteratur */

[[Simulering av VHDL]]

[[VHDL Testbenk]]

[[Synthese av VHDL]]

== Referanselitteratur ==
[http://en.wikipedia.org/wiki/VHDL Wikipedia:VHDL]

[http://freerangefactory.org/books_tuts.html Free Range VHDL textbook]

[http://esd.cs.ucr.edu/labs/tutorial/ VHDL Tutorial: Learn by Example]

[http://www.ioenotes.edu.np/media/notes/embedded-system/vhdl.pdf VHDL Quick Start (slides by Ashenden)]

[http://model.com/content/modelsim-pe-simulation-and-debug Modelsim]

[http://m.eet.com/media/1151614/23798-46098.pdf 10 tips for generating reusable VHDL]

[http://www.actel.com/documents/hdlcode_ug.pdf Actel HDL coding Style Guide]

[http://www.seas.upenn.edu/~ese171/vhdl/vhdl_primer.html VHDL primer]

[https://bitvis.no/dev-tools/uvvm/ Bitvis Universal VHDL Verification Methodology ]

[https://github.com/UVVM Bitvis UVVM på GitHub ]

[[Category:Mikroelektronikk]]

VHDL Testbenk

2021-02-04T21:09:23Z

Nfyku: /* Do-file og testbenk */

===Simulering av kode og testbenk i QuestaSim===

==Do-file og testbenk==

Vi vil lage ei Do-file for å sleppe å skrive inn stimuli manuellt kvar gang vi simulerer.

Testbenken er eit nyttig hjelpemiddel for å kontrollere resultet frå simulering.

Oppstart av modelsim

Opne eit terminalvindu, og skriv :

ssh -X mikroserver4
source /eda/mentor/2019-20/scripts/QUESTA-CORE-PRIME_2019.4_RHELx86.sh
vsim

==Lage prosjekt i modelsim==

Velg: file >new>project. Deretter kan du legge til vhdl-filer ved å velge add to project>add existing file. I denne oppgåva treng vi fila: sr_latch. Husk å kompliere vhdl filer før du simulerer.

Koden til SR_latch.vhdl

<pre>
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;

ENTITY SR_latch IS
PORT (
S,R : IN std_logic ;
Q,QB : INOUT std_logic );
END SR_latch;

-------------------------------------------------------------------------------

ARCHITECTURE behave OF SR_latch IS

BEGIN
-- behave
Q <= S nand QB;
QB <= R nand Q;
END behave;
</pre>

==Bruk av "Do-file"==

Første del av oppgåva er å konstruere ei såkalt do-file som beskriv stimuli til sr_latch. Dette er ganske enkelt ei textfil som kan sjå slik ut:

<pre>
# Starter simulering på nytt (clear)
restart -f

# Force s til 1 etter 100ns og til 0 etter 200ns, gjentar etter 200 ns
force s 1 100 ns, 0 200 ns -repeat 200 ns
force r 1 100 ns, 0 300 ns -repeat 400 ns

# Simulerer i 800ns
run 800 ns
</pre>

Bruk av do-file

<pre>
vsim -voptargs=+acc SR_latch
add wave *
do f.do
</pre>

Resultat av simulering

# ** Error: (vsim-3601) Iteration limit reached at time 500 ns.
Som viser at vi får oscillasjon etter 500ns.

Vi får også opp eit wave-vindu med alle signal som er beskrive i entity.

==Testbenk i VHDL==

No skal vi lære oss å lage ein testbench som testar utverdiane mot forventa resultat og skriv ut forskjellige feilmeldingar.
Velg: add to project>new file (type vhdl). I denne skriv vi så testbenken vår.

*Eksempelkode til SR_tb.vhdl:*

<pre>
library ieee;
use ieee.std_logic_1164.all;
library work;
use work.all;

--Navn på testbenken. Vi treng ingen kopling til utanverda i testbenken.
entity sr_tb is
end entity sr_tb;

architecture struct of sr_tb is
--Deklarerer testsignalar og kva type dei er.
signal S_tb : std_logic;
signal R_tb : std_logic;
signal Q_tb : std_logic;
signal QB_tb : std_logic;

begin
--Velg kva einheit testbenken skal teste.
SR : entity SR_latch(behave)

--Koblar signala fra einheiten til testbenken.
port map (
S => S_tb,
R => R_tb,
Q => Q_tb,
QB => QB_tb);

--Setter testvektorane, venter og ser kva vi får ut.
--Samanliknar med forventa resultat, og gir ut eventuelle error.
--Vi har lagt inn alle feiltypane i assert som eit eksempel.
process
begin

--Setter
S_tb <= '0';
R_tb <= '1';

wait for 100 ns;

assert (Q_tb = '1')
report "Q vart ikkje 1!"
severity Error;

assert (QB_tb = '0')
report "QB vart ikkje 0!"
severity Error;

--Ingen endring
S_tb <= '1';
R_tb <= '1';
wait for 100 ns;

--Tester på feil verdier for å lage feilmelding
assert (Q_tb = '0')
report "Dette er ein feil"
severity Error;

assert (QB_tb = '1')
report "Ein feil til"
severity warning;

--Reset
S_tb <= '1';
R_tb <= '0';

wait for 100 ns;

assert (Q_tb = '0')
report "Q vart ikkje 0!"
severity Error;

assert (QB_tb = '1')
report "QB vart ikkje 1!"
severity Error;

--Ingen endring
S_tb <= '1';
R_tb <= '1';
wait for 100 ns;

--Tester på feil verdier
assert (Q_tb = '1')
report "Endå meir feil"
severity note;

assert (QB_tb = '0')
report "hu, masse feil ja"
severity Warning;

--Reset
S_tb <= '1';
R_tb <= '0';
wait for 100 ns;

assert (Q_tb = '0')
report "Q does not match the expected value!"
severity Error;

assert (QB_tb = '1')
report "QB does not match the expected value!"
severity Error;

--Set og reset
S_tb <= '0';
R_tb <= '0';
wait for 100 ns;

assert (Q_tb = '1')
report "Q does not match the expected value!"
severity Error;

assert (QB_tb = '1')
report "QB does not match the expected value!"
severity Error;

--Oscillilerer
S_tb <= '1';
R_tb <= '1';
wait for 100 ns;

assert (Q_tb = '1')
report "Q does not match the expected value!"
severity Error;

assert (QB_tb = '0')
report "QB does not match the expected value!"
severity Error;

end process;
end;
</pre>

For å kjøre igjennom hele filen bruker en
run -all

==Resultat==
Vi kan leggje inn feil for å få fram nokon feil for å vise forskjellige feilmeldinger. Vi fekk også SR_latch til å oscillere.

<pre>
# ** Error: Dette er ein feil
# Time: 200 ns Iteration: 0 Instance: :sr_tb
# ** Warning: Ein feil til
# Time: 200 ns Iteration: 0 Instance: :sr_tb
# ** Note: Endå meir feil
# Time: 400 ns Iteration: 0 Instance: :sr_tb
# ** Warning: hu, masse feil ja
# Time: 400 ns Iteration: 0 Instance: :sr_tb
# ** Error: (vsim-3601) Iteration limit reached at time 600 ns.
</pre>

Om en legger til testbenk signalene i wave vinduet så får en opp markeringer der hvor det har oppstått feil, rød for error og gul for warning. En kan så trykke på markeringene og få opp feilmeldingen.

==Konklusjon==

Vi kan lage ein do-file som styrer stimuli under simulering, slik at vi slepp å skrive kommandoer kvar gang vi simulerer. Vi kan lage ein testbench for å simuler og kontrollere svaret mot forventa resultat. Med assert kan vi skrive ut feilmeldinger av ulike typer når det oppstår feil.

[[Category:VHDL]] [[Category:Mikroelektronikk]]

VHDL Testbenk

2021-02-04T21:08:46Z

Nfyku:

===Simulering av kode og testbenk i QuestaSim===

==Do-file og testbenk==

Vi vil lage ei Do-file for å sleppe å skrive inn stimuli manuellt kvar gang vi simulerer.

Testbenken er eit nyttig hjelpemiddel for å kontrollere resultet frå simulering.

Oppstart av modelsim

Opne eit terminalvindu, og skriv :

ssh -X mikroserver4
source /eda/mentor/2019-20/scripts/QUESTA-CORE-PRIME_2019.4_RHELx86.shvsim

==Lage prosjekt i modelsim==

Velg: file >new>project. Deretter kan du legge til vhdl-filer ved å velge add to project>add existing file. I denne oppgåva treng vi fila: sr_latch. Husk å kompliere vhdl filer før du simulerer.

Koden til SR_latch.vhdl

<pre>
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;

ENTITY SR_latch IS
PORT (
S,R : IN std_logic ;
Q,QB : INOUT std_logic );
END SR_latch;

-------------------------------------------------------------------------------

ARCHITECTURE behave OF SR_latch IS

BEGIN
-- behave
Q <= S nand QB;
QB <= R nand Q;
END behave;
</pre>

==Bruk av "Do-file"==

Første del av oppgåva er å konstruere ei såkalt do-file som beskriv stimuli til sr_latch. Dette er ganske enkelt ei textfil som kan sjå slik ut:

<pre>
# Starter simulering på nytt (clear)
restart -f

# Force s til 1 etter 100ns og til 0 etter 200ns, gjentar etter 200 ns
force s 1 100 ns, 0 200 ns -repeat 200 ns
force r 1 100 ns, 0 300 ns -repeat 400 ns

# Simulerer i 800ns
run 800 ns
</pre>

Bruk av do-file

<pre>
vsim -voptargs=+acc SR_latch
add wave *
do f.do
</pre>

Resultat av simulering

# ** Error: (vsim-3601) Iteration limit reached at time 500 ns.
Som viser at vi får oscillasjon etter 500ns.

Vi får også opp eit wave-vindu med alle signal som er beskrive i entity.

==Testbenk i VHDL==

No skal vi lære oss å lage ein testbench som testar utverdiane mot forventa resultat og skriv ut forskjellige feilmeldingar.
Velg: add to project>new file (type vhdl). I denne skriv vi så testbenken vår.

*Eksempelkode til SR_tb.vhdl:*

<pre>
library ieee;
use ieee.std_logic_1164.all;
library work;
use work.all;

--Navn på testbenken. Vi treng ingen kopling til utanverda i testbenken.
entity sr_tb is
end entity sr_tb;

architecture struct of sr_tb is
--Deklarerer testsignalar og kva type dei er.
signal S_tb : std_logic;
signal R_tb : std_logic;
signal Q_tb : std_logic;
signal QB_tb : std_logic;

begin
--Velg kva einheit testbenken skal teste.
SR : entity SR_latch(behave)

--Koblar signala fra einheiten til testbenken.
port map (
S => S_tb,
R => R_tb,
Q => Q_tb,
QB => QB_tb);

--Setter testvektorane, venter og ser kva vi får ut.
--Samanliknar med forventa resultat, og gir ut eventuelle error.
--Vi har lagt inn alle feiltypane i assert som eit eksempel.
process
begin

--Setter
S_tb <= '0';
R_tb <= '1';

wait for 100 ns;

assert (Q_tb = '1')
report "Q vart ikkje 1!"
severity Error;

assert (QB_tb = '0')
report "QB vart ikkje 0!"
severity Error;

--Ingen endring
S_tb <= '1';
R_tb <= '1';
wait for 100 ns;

--Tester på feil verdier for å lage feilmelding
assert (Q_tb = '0')
report "Dette er ein feil"
severity Error;

assert (QB_tb = '1')
report "Ein feil til"
severity warning;

--Reset
S_tb <= '1';
R_tb <= '0';

wait for 100 ns;

assert (Q_tb = '0')
report "Q vart ikkje 0!"
severity Error;

assert (QB_tb = '1')
report "QB vart ikkje 1!"
severity Error;

--Ingen endring
S_tb <= '1';
R_tb <= '1';
wait for 100 ns;

--Tester på feil verdier
assert (Q_tb = '1')
report "Endå meir feil"
severity note;

assert (QB_tb = '0')
report "hu, masse feil ja"
severity Warning;

--Reset
S_tb <= '1';
R_tb <= '0';
wait for 100 ns;

assert (Q_tb = '0')
report "Q does not match the expected value!"
severity Error;

assert (QB_tb = '1')
report "QB does not match the expected value!"
severity Error;

--Set og reset
S_tb <= '0';
R_tb <= '0';
wait for 100 ns;

assert (Q_tb = '1')
report "Q does not match the expected value!"
severity Error;

assert (QB_tb = '1')
report "QB does not match the expected value!"
severity Error;

--Oscillilerer
S_tb <= '1';
R_tb <= '1';
wait for 100 ns;

assert (Q_tb = '1')
report "Q does not match the expected value!"
severity Error;

assert (QB_tb = '0')
report "QB does not match the expected value!"
severity Error;

end process;
end;
</pre>

For å kjøre igjennom hele filen bruker en
run -all

==Resultat==
Vi kan leggje inn feil for å få fram nokon feil for å vise forskjellige feilmeldinger. Vi fekk også SR_latch til å oscillere.

<pre>
# ** Error: Dette er ein feil
# Time: 200 ns Iteration: 0 Instance: :sr_tb
# ** Warning: Ein feil til
# Time: 200 ns Iteration: 0 Instance: :sr_tb
# ** Note: Endå meir feil
# Time: 400 ns Iteration: 0 Instance: :sr_tb
# ** Warning: hu, masse feil ja
# Time: 400 ns Iteration: 0 Instance: :sr_tb
# ** Error: (vsim-3601) Iteration limit reached at time 600 ns.
</pre>

Om en legger til testbenk signalene i wave vinduet så får en opp markeringer der hvor det har oppstått feil, rød for error og gul for warning. En kan så trykke på markeringene og få opp feilmeldingen.

==Konklusjon==

Vi kan lage ein do-file som styrer stimuli under simulering, slik at vi slepp å skrive kommandoer kvar gang vi simulerer. Vi kan lage ein testbench for å simuler og kontrollere svaret mot forventa resultat. Med assert kan vi skrive ut feilmeldinger av ulike typer når det oppstår feil.

[[Category:VHDL]] [[Category:Mikroelektronikk]]

Simulering av VHDL

2021-02-04T21:06:41Z

Nfyku: /* Starte Questa Sim */

===Konstruksjon og simulering av VHDL-kode med Modelsim/Questa===

==Innledning==

Hensikten med denne oppgaven er å få et lite innblikk i bruk av høynivåspråk for simulering og uttesting av kretsløsninger. I denne oppgaven skal vi bruker VHDL (Very high speed integrated circuit Hardware Description Language), som er spesielt utviklet for elektronikk. VHDL er definert slik at det passer i en mengde sammenhenger, og er det vil derfor være uoverkommelig å gå inn på detaljer i denne oppgaven. Vi skal ta for oss noen eksempler:

* Eksempel 1: Signalflyt i en SR-lås

* Eksempel 2: Signaler og variable

Et VHDL program består i hovedsak av ENTITY, som definerer tilkobling mellom programmet og omverden, og ARCHITECTURE, som definerer programmets funksjon. Den komplette VHDL-koden for eksempel 1 vist nederst på denne siden.Mentor Graphics har utviklet programvare (Modelsim//Questa) som gjør det mulig å beskrivem, simulere og feilsøke VHDL-kode. Fremgangsmåten for skriving, kompilering og simulering av VHDL-kode finner du under.

==Starte Questa Sim==
Når man skal arbeide med Questa Sim fra Mentor Graphics skriv følgende kommando i et terminalvindu.

ssh -X mikroserver4
export LM_LICENSE_FILE=1717@lisensserver
source /eda/mentor/2019-20/scripts/PRECISION_2019.1.1_RHELx86.sh
vsim

==Lage et nytt prosjekt==

I den følgende teksten er det vist hvordan man kan utføre kompilering, etc. på kommandolinjen. Dette kan enten gjøres i fra X terminalvinduet, eller fra kommandolinjen i Questa. Hvis man velger å bruke Questa-miljøet er de fleste prosedyrer/kommandoer tilgjengelige under menyen.

Start et nytt prosjekt med

<pre>
File > New > Project
</pre>

[[Image:questa_new_project.png]]

Velg et fornuftig navn og katalog. Man kan gjerne ha flere uavhengige vhdl-filer i et prosjekt.
Det er en fordel å ha en hovedkatalog til vhdl prosjektene og en underkatalog for prosjektet fex /home/bruker/vhdl_prosjekt/sr_latch

==Skriving av VHDL kode==

En ny VHDL kode (et design beskrevet med VHDL kode) påbegynnes med å starte emacs i terminal vinduet eller ved å bruke den innebygde teksteditoren i Questa ved å velge Create New File.

Det fine med emacs er at man kan velge VHDL-modus. Dette gjøres med å skrive ''M-x vhdl-mode'' (M står for ''Meta'' og er vanligvis definert som esc-knappen). I emacs har en menyer med alle valg oppe langs kanten som i andre teksteditorer, men programmet skiller seg litt ut med kommandolinjen nederst i vinduet. Når en f. eks. skal lagre filen en har skrevet blir denne kommandolinjen aktiv og en skriver inn sti og filnavn der. Når man lagrer er ikke navnet på kodefilen viktig, men det er fornuftig å kalle den det samme som ENTITY-delen, med ''.vhdl'' som "etternavn" (f. eks. sr_latch.vhdl).

==Kompilering av VHDL kode==

Koden kompileres med

<pre>
vcom sr_latch.vhdl
</pre>

Hvis det er feil i koden vil det komme en melding i kommando vinduet. Dobbeltklikker du på feilen vil du få opp en liste over kompileringsprosessen og alle feilene. Dobbeltklikker du så på linjen som angir en feil så vises den respektive linjen i editoren.

Merk at navnet til det kompilerte designet blir skrevet med små bokstaver, selv om du har brukt store bokstaver i ENTITY- eller ARCHITECTURE-navnet. Det kompilerte designet blir liggende i work-katalogen.

==Simulering og debugging i Questa==

Når koden kompilerer feilfritt kan den simuleres i Questa. Dette startes med:

<pre>
vsim
</pre>

Nå dukker det opp en rute der du skal velge hva som skal simuleres, utvid work og velg vhdl filen. Eventuellt kan du skrive vsim work.sr_latch i kommandovinduet

Questa bruker et standard X-basert vindusoppsett, og er derfor noen forskjellig fra de andre Mentor-programmene. Når du starter simulatoren åpnes det et vindu som vist i figur 1. Begynn med å åpne diverse vinduer:

* View > Wave

* View > Objects

* View > Locals

Man kan også gi kommandoer i Questa-vinduet. F.eks.

<pre>
Wave *
</pre>

Dra de signalene du vil se på i wave vinduet fra object vinduet.

Signalverdier settes med kommandoen 'force' eller med

<pre>
Force > Force (i "Signals" vinduet)
</pre>

Dersom et av signalene skal være klokkesignal, kan dette gjøres enkelt med

<pre>
Force > Clock (i "Signals" vinduet)
</pre>

==Eksempler==
===Signalflyt i en SR-lås===

Simuler SR-låsen. Begynn med å påtrykke stimuli til alle signaler ved tid 0 (t0). Bruk STEP-knappen for å simulere på delta-tid-nivå. (Om en holder musepekeren over knappene i Questa, kommer det en forklarende tekst opp.) Når verdiene er stabile kjører du i f.eks. 100 ns før du endrer stimuli (skriv ''run 100'' i et av vinduene). Tilsvarende kan du endre stimuli ved å skrive f.eks. ''force S 0'' i hoved-vinduet. Legg merke til den røde pilen som peker på den linjen som blir utført.

Hvis du vil begynne på ny kan du velge

<pre>
File > Restart -f
</pre>

<pre>
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;

ENTITY SR_latch IS
PORT (
S,R : IN std_logic ;
Q,QB : INOUT std_logic );
END SR_latch;

-------------------------------------------------------------------------------

ARCHITECTURE behave OF SR_latch IS

BEGIN -- behave
Q <= S nand QB;
QB <= R nand Q;
END behave;
</pre>

===Signaler og variable===

Simuler VHDL-koden under. Bruk Step eller Step Over for å følge prosedyrens utvikling linje for linje. Simulere med optimaliseringsopsjon "-voptargs=+acc" for å kunne se variablene i wave-vinduet:

vsim -voptargs=+acc sign_var

Bruk View > Objects for å kikke på signalene og View > Local for å se innholdet i variablene. Forklar endringene i signaler og variable. Hva er forskjellen som funksjon av tid/delta-tid?

<pre>
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;

ENTITY sign_var IS
PORT (clk : IN std_logic);
END sign_var;

-------------------------------------------------------------------------------

ARCHITECTURE difference OF sign_var IS

signal SA: bit := '0';
signal SB: bit := '1';

begin -- difference
p_test: process
variable A: bit := '0';
variable B: bit := '1';
begin
wait until rising_edge(clk);
A := B;
B := A;
SA <= SB after 5 ns;
SB <= SA after 5 ns;
end process p_test;
end architecture difference;
</pre>

Synthese av VHDL

2021-02-04T21:05:20Z

Nfyku:

===Syntetiseringen av VHDL kode===

Grunnen til at vi skal syntetisere koden, er at vi må lage beskrivelse av koden tilpassa ein krets.

Vi vil no prøve å synthesisere vhdl kode. Og etterpå vil vi lage ein testbenk der vi samanliknar utsignala frå den syntetiserte og den opprinnelige koden. Vi bruker ein alu som eksempel.

==Precision==

Precision bruker Vivado til å syntetisere vhdl-koden. For å starte synteseprogrammet:

export LM_LICENSE_FILE=1717@lisensserver;2100@lisensserver
source /eda/mentor/2019-20/scripts/PRECISION_2019.1.1_RHELx86.sh
precision

Vel deretter New Project, og deretter Add input file (i dette tilfelle add_sub_alu.vhd).
Så går vi inn på Setup design, velger ein kretsprodusent, den ønska kretsen og designfrekvens, for eksempel Zynq med frekvens 200MHz. For å få ut en vhdl fil av den syntetiserte koden må en gå på Tools->Options->Output og hak av for VHDL og trykk ok.

Pass på at Precision finner Vivado, settes i menyen:
Tools > Options > Place and Route Settings
deretter
Vivado > Integrated Place and Route > path to Xilinx Vivado installation tree
settes til
/eda/xilinx/Vivado/2020.2

Trykk så compile, og synthesize.
No kan vi sjå på den generte kretsen i RTL Schematic og Technology Schematic (syntese med den valgte kretsen) under Schematics på venstre side.

==Questasim==

Start opp Questasim, lag nytt prosjekt og legg til vhdl fila (add_sub_alu.vhdl). Så legg vi til fila som Precision generte i prosjektdir til 'precision/prosjektnavn_temp_1/prosjektnavn.vhd' (i vårt tilfelle 'alu/add_sub_alu_temp_1/add_sub_alu.vhd').

Vi trenger simuleringsbibliotek for den valgte kretsfamilien for å kunne simulere etter "Place and Route". Disse bibliotekene kan genereres fra Vivado med menyen
Tools > Compile Simulation Libraries
men, vi har kompilert disse unisim-bibliotekene til mappen /eda/xilinx/lib. Du kan "mappe" disse slik:

vmap unisim /eda/xilinx/lib/unisim

Deretter legger vi til ei ny vhdl fil der vi skal lage testbenken vår. Vi legger til ein komponent av den opprinnelige og den synthesiserte vhdl koden. Vi koblar alle inngangane til samme signal på testbenken, og gir ut 2 forskjellige utsignal for å samanlikne ved hjelp av assert(sjå fila alu_tb.vhdl). På grunn av at utsignala av dei to komponentane ikkje skifta heilt synkront, testa vi berre kvart nanosekund ved å putta assert inn i ein process med wait for 1ns:

test : process
begin
wait for 1 ns;
assert (data_out = data_out_synt)
report "Data ut er ulik"
severity Error;
end process test;

Når vi har laga testbenken, kompilerer vi filene (husk å kompilere i rett rekkefølge med compileorder->autogenerate første gong).

Siden precision generer samme navn på entityen og architecturen på den syntetiserte filen som i den orginale så vil ikke simulatoren kjøre de samtidig. Dette endres ved å endre entity fra add_sub_alu til add_sub_alu_synth og skifte navnet på architecture fra algoritm til structure øverst og nederst i den syntetiserte filen.

==Simulering med timing==

Eksempel på start av simulering med timing:

vsim -t ps alu_tb -sdfmax :alu_tb:ali=/heim/yngve/vhdl/syntese/alu_temp_1/simulation/modelsim/add_sub_alu_vhd.sdo

Vi kan sjå at i dei første 50 nanosekunda er utsignala ulike. Dette er fordi før første klokkeflanke er verdiane udefinert i den opprinnelige komponenten, medan den synthesisere ikkje kan ha udefinerte verdiar. I Questasim vil vi derfor få ein del feilmeldingar dei første 50 nanosekunda.

==Konklusjon==

Vi kan teste om den syntesiserte komponenten oppfører seg likt med den opprinnelige komponenten ved å koble begge to til samme testbenk. Vi fekk problem i overgangane når vi testa kontinuerlig, så vi løyste problemet ved å berre teste kvart naonosekund. Bortsett frå dei første 50 nanosekunda (sjå grunn over) kan vi sjå at begge komponetane gir ut samme utsignal. Vi prøvde å bruke samme enitynavn på begge komponentane med ulik arcitechture, men fekk berre lov å kompilere og ikkje simulere. Vi kan derfor konkludere med at desse må ha ulike navn.

==Kode==

===Kode til add_sub_alu.vhd===

<pre>
LIBRARY ieee;
USE ieee.std_logic_1164.All;
USE ieee.std_logic_unsigned.all;

ENTITY add_sub_alu IS
PORT (
clk : IN std_logic;
rst : IN std_logic;
enable_in : IN std_logic;
start : IN std_logic;
enable : IN std_logic;
do_add : IN std_logic;
do_subtract : IN std_logic;
do_hold : IN std_logic;
data_in : IN std_logic_vector(3 DOWNTO 0);
data_out : OUT std_logic_vector(3 DOWNTO 0) BUS);
END add_sub_alu;

ARCHITECTURE algorithm OF add_sub_alu IS
TYPE states IS (hold, reset, add, subtract);
SIGNAL state_var : states;
SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0);
SIGNAL latched_data_in : std_logic_vector(3 DOWNTO 0);
BEGIN

latch: PROCESS (enable_in, data_in)is
BEGIN
IF (enable_in = '1') THEN
latched_data_in <= data_in;
END IF;
END PROCESS latch;

fsm: PROCESS (clk, rst) is
BEGIN
IF (rst = '0') THEN
state_var <= reset;
ELSIF rising_edge(clk) THEN
CASE state_var IS
WHEN hold =>
IF (start = '1') THEN
state_var <= reset;
END IF;
WHEN reset =>
IF (do_add = '1') THEN
state_var <= add;
ELSIF (do_subtract = '1') THEN
state_var <= subtract;
END IF;
WHEN add =>
IF (do_hold = '1') THEN
state_var <= hold;
ELSIF (do_subtract = '1') THEN
state_var <= subtract;
END IF;
WHEN subtract =>
IF (do_hold = '1') THEN
state_var <= hold;
ELSIF (do_add = '1') THEN
state_var <= add;
END IF;
WHEN OTHERS => state_var <= reset;
END CASE;
END IF;
END PROCESS fsm;

alu: PROCESS (state_var, latched_data_in, reg)is
BEGIN
CASE state_var IS
WHEN add => int_reg <= reg + latched_data_in;
WHEN subtract => int_reg <= reg - latched_data_in;
WHEN reset => int_reg <= (others => '0');
WHEN hold => int_reg <= reg;
WHEN OTHERS => int_reg <= reg;
END CASE;
END PROCESS alu;

mem: PROCESS (clk) is
BEGIN
IF rising_edge(clk) THEN
reg <= int_reg;
END IF;
END PROCESS mem;

tri: PROCESS (enable, reg) is
BEGIN
FOR i IN 3 DOWNTO 0 LOOP
IF (enable = '1') THEN
data_out(i) <= reg(i);
ELSE
data_out(i) <= 'Z';
END IF;
END LOOP;
END PROCESS tri;

END algorithm;</pre>

===Koden til alu_tb.vhdl===

<pre>
library ieee;
use ieee.std_logic_1164.all;
library work;
use work.all;

entity alu_tb is
end entity alu_tb;

architecture struct of alu_tb is
--Deklaring av signal som skal koblast til komponentane.
--Alle innsignal er felles, medan vi har 2 forskjellige utsignal.
signal clk, reset : std_logic;
signal enable_in : std_logic;
signal start : std_logic;
signal enable : std_logic;
signal do_add : std_logic;
signal do_subtract : std_logic;
signal do_hold : std_logic;
signal data_in : std_logic_vector(3 downto 0);
signal data_out : std_logic_vector(3 downto 0);
signal data_out_synt : std_logic_vector(3 downto 0);

begin

--Deklarer komponenten alu.
alu : entity add_sub_alu(algorithm)

--Kobler signala til den opprinnelige komponenten.
port map (
clk => clk,
rst => reset,
enable_in => enable_in,
start => start,
enable => enable,
do_add => do_add,
do_subtract => do_subtract,
do_hold => do_hold,
data_in => data_in,
data_out => data_out);

--Deklarer komponenten alu_synt.
alu_synt : entity add_sub_alu_synth(structure)

--Kobler signala til den synthiserte komponenten.
port map (
clk => clk,
rst => reset,
enable_in => enable_in,
start => start,
enable => enable,
do_add => do_add,
do_subtract => do_subtract,
do_hold => do_hold,
data_in => data_in,
data_out => data_out_synt);

--Klokkegenerator
clock_gen : process
begin
clk <= '0', '1' after 50 ns;
wait for 100 ns;
end process clock_gen;

--Setter testvektorane.
reset <= '0', '1' after 60 ns;
enable <= '1', '0' after 900 ns;
enable_in <= '1', '0' after 400 ns;
start <= '1', '0' after 300 ns;
do_add <= '1', '0' after 660 ns;
do_subtract <= '0';
do_hold <= '0';
data_in <= X"3";

--Test process for å samanlikne utsignala kvart nanosekund.
test : process
begin
wait for 1 ns;
assert (data_out = data_out_synt)
report "Data ut er ulik"
severity Error;
end process test;

end;

</pre>

[[Category:Mikroelektronikk]]

Modelsim/Questa

2021-02-04T21:02:47Z

Nfyku:

[[Simulering av VHDL]]

[[VHDL Testbenk]]

[[Synthese av VHDL]]

== Referanselitteratur ==
[http://en.wikipedia.org/wiki/VHDL Wikipedia:VHDL]


[http://freerangefactory.org/books_tuts.html Free Range VHDL textbook]

[http://esd.cs.ucr.edu/labs/tutorial/ VHDL Tutorial: Learn by Example]

[http://www.ioenotes.edu.np/media/notes/embedded-system/vhdl.pdf VHDL Quick Start (slides by Ashenden)]

[http://model.com/content/modelsim-pe-simulation-and-debug Modelsim]

[http://m.eet.com/media/1151614/23798-46098.pdf 10 tips for generating reusable VHDL]

[http://www.actel.com/documents/hdlcode_ug.pdf Actel HDL coding Style Guide]

[http://www.seas.upenn.edu/~ese171/vhdl/vhdl_primer.html VHDL primer]

[https://bitvis.no/dev-tools/uvvm/ Bitvis Universal VHDL Verification Methodology ]

[[Category:Mikroelektronikk]]

Synthese av VHDL

2021-02-04T13:48:16Z

Nfyku:

===Syntetiseringen av VHDL kode===

Grunnen til at vi skal syntetisere koden, er at vi må lage beskrivelse av koden tilpassa ein krets.

Vi vil no prøve å synthesisere vhdl kode. Og etterpå vil vi lage ein testbenk der vi samanliknar utsignala frå den syntetiserte og den opprinnelige koden. Vi bruker ein alu som eksempel.

==Precision==

Precision bruker Vivado til å syntetisere vhdl-koden. For å starte synteseprogrammet:

export LM_LICENSE_FILE=1717@lisensserver;2100@lisensserver
source /eda/mentor/2019-20/scripts/PRECISION_2019.1.1_RHELx86.sh
precision

Vel deretter New Project, og deretter Add input file (i dette tilfelle add_sub_alu.vhd).
Så går vi inn på Setup design, velger ein kretsprodusent, den ønska kretsen og designfrekvens, for eksempel Zynq med frekvens 200MHz. For å få ut en vhdl fil av den syntetiserte koden må en gå på Tools->Options->Output og hak av for VHDL og trykk ok.

Pass på at Precision finner Vivado, settes i menyen:
Tools > Options > Place and Route Settings
deretter
Vivado > Integrated Place and Route > path to Xilinx Vivado installation tree
settes til
/eda/xilinx/Vivado/2020.2

Trykk så compile, og synthesize.
No kan vi sjå på den generte kretsen i RTL Schematic og Technology Schematic (syntese med den valgte kretsen) under Schematics på venstre side.

==Questasim==

Start opp Questasim, lag nytt prosjekt og legg til vhdl fila (add_sub_alu.vhdl). Så legg vi til fila som Precision generte i prosjektdir til 'precision/prosjektnavn_temp_1/prosjektnavn.vhd' (i vårt tilfelle 'alu/add_sub_alu_temp_1/add_sub_alu.vhd').

Vi trenger simuleringsbibliotek for den valgte kretsfamilien for å kunne simulere etter "Place and Route". Disse bibliotekene kan genereres fra Vivado med menyen
Tools > Compile Simulation Libraries
men, vi har kompilert disse unisim-bibliotekene til mappen /eda/xilinx/lib. Du kan "mappe" disse slik:

vmap unisim /eda/xilinx/lib/unisim

Deretter legger vi til ei ny vhdl fil der vi skal lage testbenken vår. Vi legger til ein komponent av den opprinnelige og den synthesiserte vhdl koden. Vi koblar alle inngangane til samme signal på testbenken, og gir ut 2 forskjellige utsignal for å samanlikne ved hjelp av assert(sjå fila alu_tb.vhdl). På grunn av at utsignala av dei to komponentane ikkje skifta heilt synkront, testa vi berre kvart nanosekund ved å putta assert inn i ein process med wait for 1ns:

test : process
begin
wait for 1 ns;
assert (data_out = data_out_synt)
report "Data ut er ulik"
severity Error;
end process test;

Når vi har laga testbenken, kompilerer vi filene (husk å kompilere i rett rekkefølge med compileorder->autogenerate første gong).

Siden precision generer samme navn på entityen og architecturen på den syntetiserte filen som i den orginale så vil ikke simulatoren kjøre de samtidig. Dette endres ved å endre entity fra add_sub_alu til add_sub_alu_synth og skifte navnet på architecture fra algoritm til structure øverst og nederst i den syntetiserte filen.

==Simulering med timing==

Eksempel på start av simulering med timing:

vsim -t ps alu_tb -sdfmax :alu_tb:ali=/heim/yngve/vhdl/syntese/alu_temp_1/simulation/modelsim/add_sub_alu_vhd.sdo

Vi kan sjå at i dei første 50 nanosekunda er utsignala ulike. Dette er fordi før første klokkeflanke er verdiane udefinert i den opprinnelige komponenten, medan den synthesisere ikkje kan ha udefinerte verdiar. I Modelsim vil vi derfor få ein del feilmeldingar dei første 50 nanosekunda.

==Konklusjon==

Vi kan teste om den synthesisere komponenten oppfører seg likt med den opprinnelige komponenten ved å koble begge to til samme testbenk. Vi fekk problem i overgangane når vi testa kontinuerlig, så vi løyste problemet ved å berre teste kvart naonosekund. Bortsett frå dei første 50 nanosekunda (sjå grunn over) kan vi sjå at begge komponetane gir ut samme utsignal. Vi prøvde å bruke samme enitynavn på begge komponentane med ulik arcitechture, men fekk berre lov å kompilere og ikkje simulere. Vi kan derfor konkludere med at desse må ha ulike navn.

==Kode==

===Kode til add_sub_alu.vhd===

<pre>
LIBRARY ieee;
USE ieee.std_logic_1164.All;
USE ieee.std_logic_unsigned.all;

ENTITY add_sub_alu IS
PORT (
clk : IN std_logic;
rst : IN std_logic;
enable_in : IN std_logic;
start : IN std_logic;
enable : IN std_logic;
do_add : IN std_logic;
do_subtract : IN std_logic;
do_hold : IN std_logic;
data_in : IN std_logic_vector(3 DOWNTO 0);
data_out : OUT std_logic_vector(3 DOWNTO 0) BUS);
END add_sub_alu;

ARCHITECTURE algorithm OF add_sub_alu IS
TYPE states IS (hold, reset, add, subtract);
SIGNAL state_var : states;
SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0);
SIGNAL latched_data_in : std_logic_vector(3 DOWNTO 0);
BEGIN

latch: PROCESS (enable_in, data_in)is
BEGIN
IF (enable_in = '1') THEN
latched_data_in <= data_in;
END IF;
END PROCESS latch;

fsm: PROCESS (clk, rst) is
BEGIN
IF (rst = '0') THEN
state_var <= reset;
ELSIF rising_edge(clk) THEN
CASE state_var IS
WHEN hold =>
IF (start = '1') THEN
state_var <= reset;
END IF;
WHEN reset =>
IF (do_add = '1') THEN
state_var <= add;
ELSIF (do_subtract = '1') THEN
state_var <= subtract;
END IF;
WHEN add =>
IF (do_hold = '1') THEN
state_var <= hold;
ELSIF (do_subtract = '1') THEN
state_var <= subtract;
END IF;
WHEN subtract =>
IF (do_hold = '1') THEN
state_var <= hold;
ELSIF (do_add = '1') THEN
state_var <= add;
END IF;
WHEN OTHERS => state_var <= reset;
END CASE;
END IF;
END PROCESS fsm;

alu: PROCESS (state_var, latched_data_in, reg)is
BEGIN
CASE state_var IS
WHEN add => int_reg <= reg + latched_data_in;
WHEN subtract => int_reg <= reg - latched_data_in;
WHEN reset => int_reg <= (others => '0');
WHEN hold => int_reg <= reg;
WHEN OTHERS => int_reg <= reg;
END CASE;
END PROCESS alu;

mem: PROCESS (clk) is
BEGIN
IF rising_edge(clk) THEN
reg <= int_reg;
END IF;
END PROCESS mem;

tri: PROCESS (enable, reg) is
BEGIN
FOR i IN 3 DOWNTO 0 LOOP
IF (enable = '1') THEN
data_out(i) <= reg(i);
ELSE
data_out(i) <= 'Z';
END IF;
END LOOP;
END PROCESS tri;

END algorithm;</pre>

===Koden til alu_tb.vhdl===

<pre>
library ieee;
use ieee.std_logic_1164.all;
library work;
use work.all;

entity alu_tb is
end entity alu_tb;

architecture struct of alu_tb is
--Deklaring av signal som skal koblast til komponentane.
--Alle innsignal er felles, medan vi har 2 forskjellige utsignal.
signal clk, reset : std_logic;
signal enable_in : std_logic;
signal start : std_logic;
signal enable : std_logic;
signal do_add : std_logic;
signal do_subtract : std_logic;
signal do_hold : std_logic;
signal data_in : std_logic_vector(3 downto 0);
signal data_out : std_logic_vector(3 downto 0);
signal data_out_synt : std_logic_vector(3 downto 0);

begin

--Deklarer komponenten alu.
alu : entity add_sub_alu(algorithm)

--Kobler signala til den opprinnelige komponenten.
port map (
clk => clk,
rst => reset,
enable_in => enable_in,
start => start,
enable => enable,
do_add => do_add,
do_subtract => do_subtract,
do_hold => do_hold,
data_in => data_in,
data_out => data_out);

--Deklarer komponenten alu_synt.
alu_synt : entity add_sub_alu_synth(structure)

--Kobler signala til den synthiserte komponenten.
port map (
clk => clk,
rst => reset,
enable_in => enable_in,
start => start,
enable => enable,
do_add => do_add,
do_subtract => do_subtract,
do_hold => do_hold,
data_in => data_in,
data_out => data_out_synt);

--Klokkegenerator
clock_gen : process
begin
clk <= '0', '1' after 50 ns;
wait for 100 ns;
end process clock_gen;

--Setter testvektorane.
reset <= '0', '1' after 60 ns;
enable <= '1', '0' after 900 ns;
enable_in <= '1', '0' after 400 ns;
start <= '1', '0' after 300 ns;
do_add <= '1', '0' after 660 ns;
do_subtract <= '0';
do_hold <= '0';
data_in <= X"3";

--Test process for å samanlikne utsignala kvart nanosekund.
test : process
begin
wait for 1 ns;
assert (data_out = data_out_synt)
report "Data ut er ulik"
severity Error;
end process test;

end;

</pre>

[[Category:Mikroelektronikk]]

Synthese av VHDL

2021-02-04T13:46:34Z

Nfyku: /* Precision */

===Syntetiseringen av VHDL kode===

Grunnen til at vi skal syntetisere koden, er at vi må lage beskrivelse av koden tilpassa ein krets.

Vi vil no prøve å synthesisere vhdl kode. Og etterpå vil vi lage ein testbenk der vi samanliknar utsignala frå den syntetiserte og den opprinnelige koden. Vi bruker ein alu som eksempel.

==Precision==

Precision bruker Vivado til å syntetisere vhdl-koden. For å starte synteseprogrammet:

export LM_LICENSE_FILE=1717@lisensserver;2100@lisensserver
source /eda/mentor/2019-20/scripts/PRECISION_2019.1.1_RHELx86.sh
precision

Vel deretter New Project, og deretter Add input file(i dette tilfelle add_sub_alu.vhd).
Så går vi inn på Setup design, velger ein kretsprodusent, den ønska kretsen og designfrekvens, for eksempel Zynq med frekvens 200MHz. For å få ut en vhdl fil av den syntetiserte koden må en gå på Tools->Options->Output og hak av for VHDL og trykk ok.

Pass på at Precision finner Vivado, settes i menyen:
Tools > Options > Place and Route Settings
deretter
Vivado > Integrated Place and Route > path to Xilinx Vivado installation tree
settes til
/eda/xilinx/Vivado/2020.2

Trykk så compile, og synthesize.
No kan vi sjå på den generte kretsen i RTL Schematic og Technology Schematic(syntese med den valgte kretsen) under Schematics på venstre side.

==Questasim==

Start opp Questasim, lag nytt prosjekt og legg til vhdl fila(add_sub_alu.vhdl). Så legg vi til fila som Precision generte i prosjektdir til 'precision/prosjektnavn_temp_1/prosjektnavn.vhd' (i vårt tilfelle 'alu/add_sub_alu_temp_1/add_sub_alu.vhd').

Vi trenger simuleringsbibliotek for den valgte kretsfamilien for å kunne simulere etter "Place and Route". Disse bibliotekene kan genereres fra Vivado med menyen
Tools > Compile Simulation Libraries
men, vi har kompilert disse unisim-bibliotekene til mappen /eda/xilinx/lib. Du kan "mappe" disse slik:

vmap unisim /eda/xilinx/lib/unisim

Deretter legger vi til ei ny vhdl fil der vi skal lage testbenken vår. Vi legger til ein komponent av den opprinnelige og den synthesiserte vhdl koden. Vi koblar alle inngangane til samme signal på testbenken, og gir ut 2 forskjellige utsignal for å samanlikne ved hjelp av assert(sjå fila alu_tb.vhdl). På grunn av at utsignala av dei to komponentane ikkje skifta heilt synkront, testa vi berre kvart nanosekund ved å putta assert inn i ein process med wait for 1ns:

test : process
begin
wait for 1 ns;
assert (data_out = data_out_synt)
report "Data ut er ulik"
severity Error;
end process test;

Når vi har laga testbenken, kompilerer vi filene (husk å kompilere i rett rekkefølge med compileorder->autogenerate første gong).

Siden precision generer samme navn på entityen og architecturen på den syntetiserte filen som i den orginale så vil ikke simulatoren kjøre de samtidig. Dette endres ved å endre entity fra add_sub_alu til add_sub_alu_synth og skifte navnet på architecture fra algoritm til structure øverst og nederst i den syntetiserte filen.

==Simulering med timing==

Eksempel på start av simulering med timing:

vsim -t ps alu_tb -sdfmax :alu_tb:ali=/heim/yngve/vhdl/syntese/alu_temp_1/simulation/modelsim/add_sub_alu_vhd.sdo

Vi kan sjå at i dei første 50 nanosekunda er utsignala ulike. Dette er fordi før første klokkeflanke er verdiane udefinert i den opprinnelige komponenten, medan den synthesisere ikkje kan ha udefinerte verdiar. I Modelsim vil vi derfor få ein del feilmeldingar dei første 50 nanosekunda.

==Konklusjon==

Vi kan teste om den synthesisere komponenten oppfører seg likt med den opprinnelige komponenten ved å koble begge to til samme testbenk. Vi fekk problem i overgangane når vi testa kontinuerlig, så vi løyste problemet ved å berre teste kvart naonosekund. Bortsett frå dei første 50 nanosekunda(sjå grunn over) kan vi sjå at begge komponetane gir ut samme utsignal. Vi prøvde å bruke samme enitynavn på begge komponentane med ulik arcitechture, men fekk berre lov å kompilere og ikkje simulere. Vi kan derfor konkludere med at desse må ha ulike navn.

==Kode==

===Kode til add_sub_alu.vhd===

<pre>
LIBRARY ieee;
USE ieee.std_logic_1164.All;
USE ieee.std_logic_unsigned.all;

ENTITY add_sub_alu IS
PORT (
clk : IN std_logic;
rst : IN std_logic;
enable_in : IN std_logic;
start : IN std_logic;
enable : IN std_logic;
do_add : IN std_logic;
do_subtract : IN std_logic;
do_hold : IN std_logic;
data_in : IN std_logic_vector(3 DOWNTO 0);
data_out : OUT std_logic_vector(3 DOWNTO 0) BUS);
END add_sub_alu;

ARCHITECTURE algorithm OF add_sub_alu IS
TYPE states IS (hold, reset, add, subtract);
SIGNAL state_var : states;
SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0);
SIGNAL latched_data_in : std_logic_vector(3 DOWNTO 0);
BEGIN

latch: PROCESS (enable_in, data_in)is
BEGIN
IF (enable_in = '1') THEN
latched_data_in <= data_in;
END IF;
END PROCESS latch;

fsm: PROCESS (clk, rst) is
BEGIN
IF (rst = '0') THEN
state_var <= reset;
ELSIF rising_edge(clk) THEN
CASE state_var IS
WHEN hold =>
IF (start = '1') THEN
state_var <= reset;
END IF;
WHEN reset =>
IF (do_add = '1') THEN
state_var <= add;
ELSIF (do_subtract = '1') THEN
state_var <= subtract;
END IF;
WHEN add =>
IF (do_hold = '1') THEN
state_var <= hold;
ELSIF (do_subtract = '1') THEN
state_var <= subtract;
END IF;
WHEN subtract =>
IF (do_hold = '1') THEN
state_var <= hold;
ELSIF (do_add = '1') THEN
state_var <= add;
END IF;
WHEN OTHERS => state_var <= reset;
END CASE;
END IF;
END PROCESS fsm;

alu: PROCESS (state_var, latched_data_in, reg)is
BEGIN
CASE state_var IS
WHEN add => int_reg <= reg + latched_data_in;
WHEN subtract => int_reg <= reg - latched_data_in;
WHEN reset => int_reg <= (others => '0');
WHEN hold => int_reg <= reg;
WHEN OTHERS => int_reg <= reg;
END CASE;
END PROCESS alu;

mem: PROCESS (clk) is
BEGIN
IF rising_edge(clk) THEN
reg <= int_reg;
END IF;
END PROCESS mem;

tri: PROCESS (enable, reg) is
BEGIN
FOR i IN 3 DOWNTO 0 LOOP
IF (enable = '1') THEN
data_out(i) <= reg(i);
ELSE
data_out(i) <= 'Z';
END IF;
END LOOP;
END PROCESS tri;

END algorithm;</pre>

===Koden til alu_tb.vhdl===

<pre>
library ieee;
use ieee.std_logic_1164.all;
library work;
use work.all;

entity alu_tb is
end entity alu_tb;

architecture struct of alu_tb is
--Deklaring av signal som skal koblast til komponentane.
--Alle innsignal er felles, medan vi har 2 forskjellige utsignal.
signal clk, reset : std_logic;
signal enable_in : std_logic;
signal start : std_logic;
signal enable : std_logic;
signal do_add : std_logic;
signal do_subtract : std_logic;
signal do_hold : std_logic;
signal data_in : std_logic_vector(3 downto 0);
signal data_out : std_logic_vector(3 downto 0);
signal data_out_synt : std_logic_vector(3 downto 0);

begin

--Deklarer komponenten alu.
alu : entity add_sub_alu(algorithm)

--Kobler signala til den opprinnelige komponenten.
port map (
clk => clk,
rst => reset,
enable_in => enable_in,
start => start,
enable => enable,
do_add => do_add,
do_subtract => do_subtract,
do_hold => do_hold,
data_in => data_in,
data_out => data_out);

--Deklarer komponenten alu_synt.
alu_synt : entity add_sub_alu_synth(structure)

--Kobler signala til den synthiserte komponenten.
port map (
clk => clk,
rst => reset,
enable_in => enable_in,
start => start,
enable => enable,
do_add => do_add,
do_subtract => do_subtract,
do_hold => do_hold,
data_in => data_in,
data_out => data_out_synt);

--Klokkegenerator
clock_gen : process
begin
clk <= '0', '1' after 50 ns;
wait for 100 ns;
end process clock_gen;

--Setter testvektorane.
reset <= '0', '1' after 60 ns;
enable <= '1', '0' after 900 ns;
enable_in <= '1', '0' after 400 ns;
start <= '1', '0' after 300 ns;
do_add <= '1', '0' after 660 ns;
do_subtract <= '0';
do_hold <= '0';
data_in <= X"3";

--Test process for å samanlikne utsignala kvart nanosekund.
test : process
begin
wait for 1 ns;
assert (data_out = data_out_synt)
report "Data ut er ulik"
severity Error;
end process test;

end;

</pre>

[[Category:Mikroelektronikk]]

Synthese av VHDL

2021-02-04T13:39:37Z

Nfyku:

===Syntetiseringen av VHDL kode===

Grunnen til at vi skal syntetisere koden, er at vi må lage beskrivelse av koden tilpassa ein krets.

Vi vil no prøve å synthesisere vhdl kode. Og etterpå vil vi lage ein testbenk der vi samanliknar utsignala frå den syntetiserte og den opprinnelige koden. Vi bruker ein alu som eksempel.

==Precision==

Precision bruker Vivado til å syntetisere vhdl-koden. For å starte synteseprogrammet:

export LM_LICENSE_FILE=1717@lisensserver;2100@lisensserver
source /eda/mentor/2019-20/scripts/PRECISION_2019.1.1_RHELx86.sh
precision

Pass på at Precision finner Vivado, settes i menyen:
Tools > Options > Place and Route Settings
deretter
Vivado > Integrated Place and Route > path to Xilinx Vivado installation tree
settes til
/eda/xilinx/Vivado/2020.2

Vel deretter New Project, og deretter Add input file(i dette tilfelle add_sub_alu.vhd).
Så går vi inn på Setup design, velger ein kretsprodusent, den ønska kretsen og designfrekvens, for eksempel Zynq med frekvens 200MHz. For å få ut en vhdl fil av den syntetiserte koden må en gå på Tools->Options->Output og hak av for VHDL og trykk ok.
Trykk så compile, og synthesize.
No kan vi sjå på den generte kretsen i RTL Schematic og Technology Schematic(syntese med den valgte kretsen) under Schematics på venstre side.

==Questasim==

Start opp Questasim, lag nytt prosjekt og legg til vhdl fila(add_sub_alu.vhdl). Så legg vi til fila som Precision generte i prosjektdir til 'precision/prosjektnavn_temp_1/prosjektnavn.vhd' (i vårt tilfelle 'alu/add_sub_alu_temp_1/add_sub_alu.vhd').

Vi trenger simuleringsbibliotek for den valgte kretsfamilien for å kunne simulere etter "Place and Route". Disse bibliotekene kan genereres fra Vivado med menyen
Tools > Compile Simulation Libraries
men, vi har kompilert disse unisim-bibliotekene til mappen /eda/xilinx/lib. Du kan "mappe" disse slik:

vmap unisim /eda/xilinx/lib/unisim

Deretter legger vi til ei ny vhdl fil der vi skal lage testbenken vår. Vi legger til ein komponent av den opprinnelige og den synthesiserte vhdl koden. Vi koblar alle inngangane til samme signal på testbenken, og gir ut 2 forskjellige utsignal for å samanlikne ved hjelp av assert(sjå fila alu_tb.vhdl). På grunn av at utsignala av dei to komponentane ikkje skifta heilt synkront, testa vi berre kvart nanosekund ved å putta assert inn i ein process med wait for 1ns:

test : process
begin
wait for 1 ns;
assert (data_out = data_out_synt)
report "Data ut er ulik"
severity Error;
end process test;

Når vi har laga testbenken, kompilerer vi filene (husk å kompilere i rett rekkefølge med compileorder->autogenerate første gong).

Siden precision generer samme navn på entityen og architecturen på den syntetiserte filen som i den orginale så vil ikke simulatoren kjøre de samtidig. Dette endres ved å endre entity fra add_sub_alu til add_sub_alu_synth og skifte navnet på architecture fra algoritm til structure øverst og nederst i den syntetiserte filen.

==Simulering med timing==

Eksempel på start av simulering med timing:

vsim -t ps alu_tb -sdfmax :alu_tb:ali=/heim/yngve/vhdl/syntese/alu_temp_1/simulation/modelsim/add_sub_alu_vhd.sdo

Vi kan sjå at i dei første 50 nanosekunda er utsignala ulike. Dette er fordi før første klokkeflanke er verdiane udefinert i den opprinnelige komponenten, medan den synthesisere ikkje kan ha udefinerte verdiar. I Modelsim vil vi derfor få ein del feilmeldingar dei første 50 nanosekunda.

==Konklusjon==

Vi kan teste om den synthesisere komponenten oppfører seg likt med den opprinnelige komponenten ved å koble begge to til samme testbenk. Vi fekk problem i overgangane når vi testa kontinuerlig, så vi løyste problemet ved å berre teste kvart naonosekund. Bortsett frå dei første 50 nanosekunda(sjå grunn over) kan vi sjå at begge komponetane gir ut samme utsignal. Vi prøvde å bruke samme enitynavn på begge komponentane med ulik arcitechture, men fekk berre lov å kompilere og ikkje simulere. Vi kan derfor konkludere med at desse må ha ulike navn.

==Kode==

===Kode til add_sub_alu.vhd===

<pre>
LIBRARY ieee;
USE ieee.std_logic_1164.All;
USE ieee.std_logic_unsigned.all;

ENTITY add_sub_alu IS
PORT (
clk : IN std_logic;
rst : IN std_logic;
enable_in : IN std_logic;
start : IN std_logic;
enable : IN std_logic;
do_add : IN std_logic;
do_subtract : IN std_logic;
do_hold : IN std_logic;
data_in : IN std_logic_vector(3 DOWNTO 0);
data_out : OUT std_logic_vector(3 DOWNTO 0) BUS);
END add_sub_alu;

ARCHITECTURE algorithm OF add_sub_alu IS
TYPE states IS (hold, reset, add, subtract);
SIGNAL state_var : states;
SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0);
SIGNAL latched_data_in : std_logic_vector(3 DOWNTO 0);
BEGIN

latch: PROCESS (enable_in, data_in)is
BEGIN
IF (enable_in = '1') THEN
latched_data_in <= data_in;
END IF;
END PROCESS latch;

fsm: PROCESS (clk, rst) is
BEGIN
IF (rst = '0') THEN
state_var <= reset;
ELSIF rising_edge(clk) THEN
CASE state_var IS
WHEN hold =>
IF (start = '1') THEN
state_var <= reset;
END IF;
WHEN reset =>
IF (do_add = '1') THEN
state_var <= add;
ELSIF (do_subtract = '1') THEN
state_var <= subtract;
END IF;
WHEN add =>
IF (do_hold = '1') THEN
state_var <= hold;
ELSIF (do_subtract = '1') THEN
state_var <= subtract;
END IF;
WHEN subtract =>
IF (do_hold = '1') THEN
state_var <= hold;
ELSIF (do_add = '1') THEN
state_var <= add;
END IF;
WHEN OTHERS => state_var <= reset;
END CASE;
END IF;
END PROCESS fsm;

alu: PROCESS (state_var, latched_data_in, reg)is
BEGIN
CASE state_var IS
WHEN add => int_reg <= reg + latched_data_in;
WHEN subtract => int_reg <= reg - latched_data_in;
WHEN reset => int_reg <= (others => '0');
WHEN hold => int_reg <= reg;
WHEN OTHERS => int_reg <= reg;
END CASE;
END PROCESS alu;

mem: PROCESS (clk) is
BEGIN
IF rising_edge(clk) THEN
reg <= int_reg;
END IF;
END PROCESS mem;

tri: PROCESS (enable, reg) is
BEGIN
FOR i IN 3 DOWNTO 0 LOOP
IF (enable = '1') THEN
data_out(i) <= reg(i);
ELSE
data_out(i) <= 'Z';
END IF;
END LOOP;
END PROCESS tri;

END algorithm;</pre>

===Koden til alu_tb.vhdl===

<pre>
library ieee;
use ieee.std_logic_1164.all;
library work;
use work.all;

entity alu_tb is
end entity alu_tb;

architecture struct of alu_tb is
--Deklaring av signal som skal koblast til komponentane.
--Alle innsignal er felles, medan vi har 2 forskjellige utsignal.
signal clk, reset : std_logic;
signal enable_in : std_logic;
signal start : std_logic;
signal enable : std_logic;
signal do_add : std_logic;
signal do_subtract : std_logic;
signal do_hold : std_logic;
signal data_in : std_logic_vector(3 downto 0);
signal data_out : std_logic_vector(3 downto 0);
signal data_out_synt : std_logic_vector(3 downto 0);

begin

--Deklarer komponenten alu.
alu : entity add_sub_alu(algorithm)

--Kobler signala til den opprinnelige komponenten.
port map (
clk => clk,
rst => reset,
enable_in => enable_in,
start => start,
enable => enable,
do_add => do_add,
do_subtract => do_subtract,
do_hold => do_hold,
data_in => data_in,
data_out => data_out);

--Deklarer komponenten alu_synt.
alu_synt : entity add_sub_alu_synth(structure)

--Kobler signala til den synthiserte komponenten.
port map (
clk => clk,
rst => reset,
enable_in => enable_in,
start => start,
enable => enable,
do_add => do_add,
do_subtract => do_subtract,
do_hold => do_hold,
data_in => data_in,
data_out => data_out_synt);

--Klokkegenerator
clock_gen : process
begin
clk <= '0', '1' after 50 ns;
wait for 100 ns;
end process clock_gen;

--Setter testvektorane.
reset <= '0', '1' after 60 ns;
enable <= '1', '0' after 900 ns;
enable_in <= '1', '0' after 400 ns;
start <= '1', '0' after 300 ns;
do_add <= '1', '0' after 660 ns;
do_subtract <= '0';
do_hold <= '0';
data_in <= X"3";

--Test process for å samanlikne utsignala kvart nanosekund.
test : process
begin
wait for 1 ns;
assert (data_out = data_out_synt)
report "Data ut er ulik"
severity Error;
end process test;

end;

</pre>

[[Category:Mikroelektronikk]]

Synthese av VHDL

2021-02-04T13:37:06Z

Nfyku:

===Syntetiseringen av VHDL kode===

Grunnen til at vi skal syntetisere koden, er at vi må lage beskrivelse av koden tilpassa ein krets.

Vi vil no prøve å synthesisere vhdl kode. Og etterpå vil vi lage ein testbenk der vi samanliknar utsignala frå den syntetiserte og den opprinnelige koden. Vi bruker ein alu som eksempel.

==Precision==

Precision bruker Vivado til å syntetisere vhdl-koden. For å starte synteseprogrammet:

export LM_LICENSE_FILE=1717@lisensserver;2100@lisensserver
source /eda/mentor/2019-20/scripts/PRECISION_2019.1.1_RHELx86.sh
precision

Pass på at Precision finner Vivado, settes i menyen:
Tools > Options > Place and Route Settings
deretter
Vivado > Integrated Place and Route > path to Xilinx Vivado installation tree
settes til
/eda/xilinx/Vivado/2020.2

Vel deretter New Project, og deretter Add input file(i dette tilfelle add_sub_alu.vhd).
Så går vi inn på Setup design, velger ein kretsprodusent, den ønska kretsen og designfrekvens, for eksempel Zynq med frekvens 200MHz. For å få ut en vhdl fil av den syntetiserte koden må en gå på Tools->Options->Output og hak av for VHDL og trykk ok.
Trykk så compile, og synthesize.
No kan vi sjå på den generte kretsen i RTL Schematic og Technology Schematic(syntese med den valgte kretsen) under Schematics på venstre side.

==Questasim==

Start opp Questasim, lag nytt prosjekt og legg til vhdl fila(add_sub_alu.vhdl). Så legg vi til fila som Precision generte i prosjektdir til 'precision/prosjektnavn_temp_1/prosjektnavn.vhd' (i vårt tilfelle 'alu/add_sub_alu_temp_1/add_sub_alu.vhd').

Vi trenger simuleringsbibliotek for den valgte kretsfamilien for å kunne simulere etter "Place and Route". Disse bibliotekene kan genereres fra Quartus med menyen Tools > Launch EDA Simulation Simulation Library Compiler.

Vi har kompilert disse bibliotekene til mappen /eda/xilinx. Du kan "mappe" disse for eksempel slik:

vmap unisim /eda/xilinx/lib/unisim

Deretter legger vi til ei ny vhdl fil der vi skal lage testbenken vår. Vi legger til ein komponent av den opprinnelige og den synthesiserte vhdl koden. Vi koblar alle inngangane til samme signal på testbenken, og gir ut 2 forskjellige utsignal for å samanlikne ved hjelp av assert(sjå fila alu_tb.vhdl). På grunn av at utsignala av dei to komponentane ikkje skifta heilt synkront, testa vi berre kvart nanosekund ved å putta assert inn i ein process med wait for 1ns:

test : process
begin
wait for 1 ns;
assert (data_out = data_out_synt)
report "Data ut er ulik"
severity Error;
end process test;

Når vi har laga testbenken, kompilerer vi filene (husk å kompilere i rett rekkefølge med compileorder->autogenerate første gong).

Siden precision generer samme navn på entityen og architecturen på den syntetiserte filen som i den orginale så vil ikke simulatoren kjøre de samtidig. Dette endres ved å endre entity fra add_sub_alu til add_sub_alu_synth og skifte navnet på architecture fra algoritm til structure øverst og nederst i den syntetiserte filen.

==Simulering med timing==

Eksempel på start av simulering med timing:

vsim -t ps alu_tb -sdfmax :alu_tb:ali=/heim/yngve/vhdl/syntese/alu_temp_1/simulation/modelsim/add_sub_alu_vhd.sdo

Vi kan sjå at i dei første 50 nanosekunda er utsignala ulike. Dette er fordi før første klokkeflanke er verdiane udefinert i den opprinnelige komponenten, medan den synthesisere ikkje kan ha udefinerte verdiar. I Modelsim vil vi derfor få ein del feilmeldingar dei første 50 nanosekunda.

==Konklusjon==

Vi kan teste om den synthesisere komponenten oppfører seg likt med den opprinnelige komponenten ved å koble begge to til samme testbenk. Vi fekk problem i overgangane når vi testa kontinuerlig, så vi løyste problemet ved å berre teste kvart naonosekund. Bortsett frå dei første 50 nanosekunda(sjå grunn over) kan vi sjå at begge komponetane gir ut samme utsignal. Vi prøvde å bruke samme enitynavn på begge komponentane med ulik arcitechture, men fekk berre lov å kompilere og ikkje simulere. Vi kan derfor konkludere med at desse må ha ulike navn.

==Kode==

===Kode til add_sub_alu.vhd===

<pre>
LIBRARY ieee;
USE ieee.std_logic_1164.All;
USE ieee.std_logic_unsigned.all;

ENTITY add_sub_alu IS
PORT (
clk : IN std_logic;
rst : IN std_logic;
enable_in : IN std_logic;
start : IN std_logic;
enable : IN std_logic;
do_add : IN std_logic;
do_subtract : IN std_logic;
do_hold : IN std_logic;
data_in : IN std_logic_vector(3 DOWNTO 0);
data_out : OUT std_logic_vector(3 DOWNTO 0) BUS);
END add_sub_alu;

ARCHITECTURE algorithm OF add_sub_alu IS
TYPE states IS (hold, reset, add, subtract);
SIGNAL state_var : states;
SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0);
SIGNAL latched_data_in : std_logic_vector(3 DOWNTO 0);
BEGIN

latch: PROCESS (enable_in, data_in)is
BEGIN
IF (enable_in = '1') THEN
latched_data_in <= data_in;
END IF;
END PROCESS latch;

fsm: PROCESS (clk, rst) is
BEGIN
IF (rst = '0') THEN
state_var <= reset;
ELSIF rising_edge(clk) THEN
CASE state_var IS
WHEN hold =>
IF (start = '1') THEN
state_var <= reset;
END IF;
WHEN reset =>
IF (do_add = '1') THEN
state_var <= add;
ELSIF (do_subtract = '1') THEN
state_var <= subtract;
END IF;
WHEN add =>
IF (do_hold = '1') THEN
state_var <= hold;
ELSIF (do_subtract = '1') THEN
state_var <= subtract;
END IF;
WHEN subtract =>
IF (do_hold = '1') THEN
state_var <= hold;
ELSIF (do_add = '1') THEN
state_var <= add;
END IF;
WHEN OTHERS => state_var <= reset;
END CASE;
END IF;
END PROCESS fsm;

alu: PROCESS (state_var, latched_data_in, reg)is
BEGIN
CASE state_var IS
WHEN add => int_reg <= reg + latched_data_in;
WHEN subtract => int_reg <= reg - latched_data_in;
WHEN reset => int_reg <= (others => '0');
WHEN hold => int_reg <= reg;
WHEN OTHERS => int_reg <= reg;
END CASE;
END PROCESS alu;

mem: PROCESS (clk) is
BEGIN
IF rising_edge(clk) THEN
reg <= int_reg;
END IF;
END PROCESS mem;

tri: PROCESS (enable, reg) is
BEGIN
FOR i IN 3 DOWNTO 0 LOOP
IF (enable = '1') THEN
data_out(i) <= reg(i);
ELSE
data_out(i) <= 'Z';
END IF;
END LOOP;
END PROCESS tri;

END algorithm;</pre>

===Koden til alu_tb.vhdl===

<pre>
library ieee;
use ieee.std_logic_1164.all;
library work;
use work.all;

entity alu_tb is
end entity alu_tb;

architecture struct of alu_tb is
--Deklaring av signal som skal koblast til komponentane.
--Alle innsignal er felles, medan vi har 2 forskjellige utsignal.
signal clk, reset : std_logic;
signal enable_in : std_logic;
signal start : std_logic;
signal enable : std_logic;
signal do_add : std_logic;
signal do_subtract : std_logic;
signal do_hold : std_logic;
signal data_in : std_logic_vector(3 downto 0);
signal data_out : std_logic_vector(3 downto 0);
signal data_out_synt : std_logic_vector(3 downto 0);

begin

--Deklarer komponenten alu.
alu : entity add_sub_alu(algorithm)

--Kobler signala til den opprinnelige komponenten.
port map (
clk => clk,
rst => reset,
enable_in => enable_in,
start => start,
enable => enable,
do_add => do_add,
do_subtract => do_subtract,
do_hold => do_hold,
data_in => data_in,
data_out => data_out);

--Deklarer komponenten alu_synt.
alu_synt : entity add_sub_alu_synth(structure)

--Kobler signala til den synthiserte komponenten.
port map (
clk => clk,
rst => reset,
enable_in => enable_in,
start => start,
enable => enable,
do_add => do_add,
do_subtract => do_subtract,
do_hold => do_hold,
data_in => data_in,
data_out => data_out_synt);

--Klokkegenerator
clock_gen : process
begin
clk <= '0', '1' after 50 ns;
wait for 100 ns;
end process clock_gen;

--Setter testvektorane.
reset <= '0', '1' after 60 ns;
enable <= '1', '0' after 900 ns;
enable_in <= '1', '0' after 400 ns;
start <= '1', '0' after 300 ns;
do_add <= '1', '0' after 660 ns;
do_subtract <= '0';
do_hold <= '0';
data_in <= X"3";

--Test process for å samanlikne utsignala kvart nanosekund.
test : process
begin
wait for 1 ns;
assert (data_out = data_out_synt)
report "Data ut er ulik"
severity Error;
end process test;

end;

</pre>

[[Category:Mikroelektronikk]]

Synthese av VHDL

2021-02-04T12:52:47Z

Nfyku: Updated to Vivado

===Syntetiseringen av VHDL kode===

Grunnen til at vi skal syntetisere koden, er at vi må lage beskrivelse av koden tilpassa ein krets.

Vi vil no prøve å synthesisere vhdl kode. Og etterpå vil vi lage ein testbenk der vi samanliknar utsignala frå den syntetiserte og den opprinnelige koden. Vi bruker ein alu som eksempel.

==Precision==

Precision bruker Vivado til å syntetisere vhdl-koden. For å starte synteseprogrammet:

export LM_LICENSE_FILE=1717@lisensserver;2100@lisensserver
source /eda/mentor/2019-20/scripts/PRECISION_2019.1.1_RHELx86.sh
precision

Pass på at Precision finner Vivado, settes i menyen:
Tools > Options > Place and Route Settings
deretter
Vivado > Integrated Place and Route > path to Xilinx Vivado installation tree
settes til
/eda/xilinx/Vivado/2020.2

Vel deretter New Project, og deretter Add input file(i dette tilfelle add_sub_alu.vhd).
Så går vi inn på Setup design, velger ein kretsprodusent, den ønska kretsen og designfrekvens, for eksempel Zynq med frekvens 200MHz. For å få ut en vhdl fil av den syntetiserte koden må en gå på Tools->Options->Output og hak av for VHDL og trykk ok.
Trykk så compile, og synthesize.
No kan vi sjå på den generte kretsen i RTL Schematic og Technology Schematic(syntese med den valgte kretsen) under Schematics på venstre side.

Hvis du får en "ROOTDIR"-error, mangler det en variabel. Skriv følgende i terminalen:

setenv QUARTUS_ROOTDIR /prog/altera/11.1/quartus

==Modelsim==

Start opp Modelsim, lag nytt prosjekt og legg til vhdl fila(add_sub_alu.vhdl). Så legg vi til fila som Precision generte i prosjektdir til 'precision/prosjektnavn_temp_1/prosjektnavn.vhd' (i vårt tilfelle 'alu/add_sub_alu_temp_1/add_sub_alu.vhd').

Vi trenger simuleringsbibliotek for den valgte kretsfamilien for å kunne simulere etter "Place and Route". Disse bibliotekene kan genereres fra Quartus med menyen Tools > Launch EDA Simulation Simulation Library Compiler.

Vi har kompilert disse bibliotekene til mappen /prog/altera/vhdl_libs. Du kan "mappe" disse for eksempel slik:

vmap cyclonev /eda/altera/17.0/quartus/eda/sim_lib

Deretter legger vi til ei ny vhdl fil der vi skal lage testbenken vår. Vi legger til ein komponent av den opprinnelige og den synthesiserte vhdl koden. Vi koblar alle inngangane til samme signal på testbenken, og gir ut 2 forskjellige utsignal for å samanlikne ved hjelp av assert(sjå fila alu_tb.vhdl). På grunn av at utsignala av dei to komponentane ikkje skifta heilt synkront, testa vi berre kvart nanosekund ved å putta assert inn i ein process med wait for 1ns:

test : process
begin
wait for 1 ns;
assert (data_out = data_out_synt)
report "Data ut er ulik"
severity Error;
end process test;

Når vi har laga testbenken, kompilerer vi filene (husk å kompilere i rett rekkefølge med compileorder->autogenerate første gong).

Siden precision generer samme navn på entityen og architecturen på den syntetiserte filen som i den orginale så vil ikke simulatoren kjøre de samtidig. Dette endres ved å endre entity fra add_sub_alu til add_sub_alu_synth og skifte navnet på architecture fra algoritm til structure øverst og nederst i den syntetiserte filen.

==Simulering med timing==

Eksemple på start av simulering med timing:

vsim -t ps alu_tb -sdfmax :alu_tb:ali=/heim/yngve/vhdl/syntese/alu_temp_1/simulation/modelsim/add_sub_alu_vhd.sdo

Vi kan sjå at i dei første 50 nanosekunda er utsignala ulike. Dette er fordi før første klokkeflanke er verdiane udefinert i den opprinnelige komponenten, medan den synthesisere ikkje kan ha udefinerte verdiar. I Modelsim vil vi derfor få ein del feilmeldingar dei første 50 nanosekunda.

==Konklusjon==

Vi kan teste om den synthesisere komponenten oppfører seg likt med den opprinnelige komponenten ved å koble begge to til samme testbenk. Vi fekk problem i overgangane når vi testa kontinuerlig, så vi løyste problemet ved å berre teste kvart naonosekund. Bortsett frå dei første 50 nanosekunda(sjå grunn over) kan vi sjå at begge komponetane gir ut samme utsignal. Vi prøvde å bruke samme enitynavn på begge komponentane med ulik arcitechture, men fekk berre lov å kompilere og ikkje simulere. Vi kan derfor konkludere med at desse må ha ulike navn.

==Kode==

===Kode til add_sub_alu.vhd===

<pre>
LIBRARY ieee;
USE ieee.std_logic_1164.All;
USE ieee.std_logic_unsigned.all;

ENTITY add_sub_alu IS
PORT (
clk : IN std_logic;
rst : IN std_logic;
enable_in : IN std_logic;
start : IN std_logic;
enable : IN std_logic;
do_add : IN std_logic;
do_subtract : IN std_logic;
do_hold : IN std_logic;
data_in : IN std_logic_vector(3 DOWNTO 0);
data_out : OUT std_logic_vector(3 DOWNTO 0) BUS);
END add_sub_alu;

ARCHITECTURE algorithm OF add_sub_alu IS
TYPE states IS (hold, reset, add, subtract);
SIGNAL state_var : states;
SIGNAL reg, int_reg : std_logic_vector(3 DOWNTO 0);
SIGNAL latched_data_in : std_logic_vector(3 DOWNTO 0);
BEGIN

latch: PROCESS (enable_in, data_in)is
BEGIN
IF (enable_in = '1') THEN
latched_data_in <= data_in;
END IF;
END PROCESS latch;

fsm: PROCESS (clk, rst) is
BEGIN
IF (rst = '0') THEN
state_var <= reset;
ELSIF rising_edge(clk) THEN
CASE state_var IS
WHEN hold =>
IF (start = '1') THEN
state_var <= reset;
END IF;
WHEN reset =>
IF (do_add = '1') THEN
state_var <= add;
ELSIF (do_subtract = '1') THEN
state_var <= subtract;
END IF;
WHEN add =>
IF (do_hold = '1') THEN
state_var <= hold;
ELSIF (do_subtract = '1') THEN
state_var <= subtract;
END IF;
WHEN subtract =>
IF (do_hold = '1') THEN
state_var <= hold;
ELSIF (do_add = '1') THEN
state_var <= add;
END IF;
WHEN OTHERS => state_var <= reset;
END CASE;
END IF;
END PROCESS fsm;

alu: PROCESS (state_var, latched_data_in, reg)is
BEGIN
CASE state_var IS
WHEN add => int_reg <= reg + latched_data_in;
WHEN subtract => int_reg <= reg - latched_data_in;
WHEN reset => int_reg <= (others => '0');
WHEN hold => int_reg <= reg;
WHEN OTHERS => int_reg <= reg;
END CASE;
END PROCESS alu;

mem: PROCESS (clk) is
BEGIN
IF rising_edge(clk) THEN
reg <= int_reg;
END IF;
END PROCESS mem;

tri: PROCESS (enable, reg) is
BEGIN
FOR i IN 3 DOWNTO 0 LOOP
IF (enable = '1') THEN
data_out(i) <= reg(i);
ELSE
data_out(i) <= 'Z';
END IF;
END LOOP;
END PROCESS tri;

END algorithm;</pre>

===Koden til alu_tb.vhdl===

<pre>
library ieee;
use ieee.std_logic_1164.all;
library work;
use work.all;

entity alu_tb is
end entity alu_tb;

architecture struct of alu_tb is
--Deklaring av signal som skal koblast til komponentane.
--Alle innsignal er felles, medan vi har 2 forskjellige utsignal.
signal clk, reset : std_logic;
signal enable_in : std_logic;
signal start : std_logic;
signal enable : std_logic;
signal do_add : std_logic;
signal do_subtract : std_logic;
signal do_hold : std_logic;
signal data_in : std_logic_vector(3 downto 0);
signal data_out : std_logic_vector(3 downto 0);
signal data_out_synt : std_logic_vector(3 downto 0);

begin

--Deklarer komponenten alu.
alu : entity add_sub_alu(algorithm)

--Kobler signala til den opprinnelige komponenten.
port map (
clk => clk,
rst => reset,
enable_in => enable_in,
start => start,
enable => enable,
do_add => do_add,
do_subtract => do_subtract,
do_hold => do_hold,
data_in => data_in,
data_out => data_out);

--Deklarer komponenten alu_synt.
alu_synt : entity add_sub_alu_synth(structure)

--Kobler signala til den synthiserte komponenten.
port map (
clk => clk,
rst => reset,
enable_in => enable_in,
start => start,
enable => enable,
do_add => do_add,
do_subtract => do_subtract,
do_hold => do_hold,
data_in => data_in,
data_out => data_out_synt);

--Klokkegenerator
clock_gen : process
begin
clk <= '0', '1' after 50 ns;
wait for 100 ns;
end process clock_gen;

--Setter testvektorane.
reset <= '0', '1' after 60 ns;
enable <= '1', '0' after 900 ns;
enable_in <= '1', '0' after 400 ns;
start <= '1', '0' after 300 ns;
do_add <= '1', '0' after 660 ns;
do_subtract <= '0';
do_hold <= '0';
data_in <= X"3";

--Test process for å samanlikne utsignala kvart nanosekund.
test : process
begin
wait for 1 ns;
assert (data_out = data_out_synt)
report "Data ut er ulik"
severity Error;
end process test;

end;

</pre>

[[Category:Mikroelektronikk]]

IHP 130nm process

2020-10-15T11:30:42Z

Nfyku:

=Cadence design with IHP 130nm process=

==Starting up the IHP SG13S Design Kit==

The following steps describe how to install the Process Design Kit and start a new design.

Log on to the mikroserver:
ssh -X mikroserver4

The preferred shell is bash. When using another shell it will be necessary to change the installation routine and modify the initialization script accordingly.

The '''first time''' you are using the IHP design kit you should copy the user environment design to your chosen parent directory (e.g ~/ihp)
cp -rp /eda/design_kits/ihp_sg13/SG13S_618_rev1.12.0/work/skel ~/ihp

Change sh.cadence in ~/ihp/cds to suit your needs. In particular you must define $IHP_TECH and $PROJECT according to your local environment. Then set general and user Cadence environment variables by doing:
source /eda/cadence/2019-20/scripts/analog.sh
cd ~/ihp/cds/
source /eda/design_kits/ihp_sg13/sh.cadence
virtuoso &

To avoid having to do this every time try to set up your environment like described in [[MikroserverSetup]]

= Before starting designing =

Read the Design Kit User Guide. It can be found on the SG13SFeatures tab on the Virtuoso console window, or in the folder "/eda/design_kits/ihp_sg13/SG13S_618_rev1.12.0/doc/pdf/" on the mikroserver. Make sure that your web browser is closed or started from the mikroserver, else the file will not be found.

Other documents are found in "eda/design_kits/ihp_sg13/SG13S_618_rev1.12.0/doc/html/"

[[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] [[Category:Cadence_Virtuoso]]

IHP 130nm process

2020-10-15T09:20:58Z

Nfyku:

=Cadence design with IHP 130nm process=

==Starting up the IHP SG13S Design Kit==

The following steps describe how to install the Process Design Kit and start a new design.

Log on to the mikroserver:
ssh -X mikroserver4

The preferred shell is bash. When using another shell it will be necessary to change the installation routine and modify the initialization script accordingly.

The '''first time''' you are using the IHP design kit you should copy the user environment design to your chosen parent directory (e.g ~/ihp)
cp -rp /eda/design_kits/ihp_sg13/SG13S_618_rev1.12.0/work/skel ~/ihp

Change sh.cadence in ~/ihp/cds to suit your needs. In particular you must define $IHP_TECH and $PROJECT according to your local environment. Then set general and user Cadence environment variables by doing:
source /eda/cadence/2019-20/scripts/analog.sh
cd ~/ihp/cds/
source /eda/design_kits/ihp_sg13/sh.cadence
virtuoso &

To avoid having to do this every time try to set up your environment like described in [[MikroserverSetup]]

= Before starting layout =

Read the Design Kit User Guide. It can be found on the SG13SFeatures tab on the Virtuoso console window, or in the folder "/eda/design_kits/ihp_sg13/SG13S_618_rev1.12.0/doc/pdf/" on the mikroserver. Make sure that your web browser is closed or started from the mikroserver, else the file will not be found.

Other documents are found in "eda/design_kits/ihp_sg13/SG13S_618_rev1.12.0/doc/html/"

[[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] [[Category:Cadence_Virtuoso]]

Layout XL and IHP SG13S

2020-10-15T09:19:12Z

Nfyku:

= Before starting layout =

Read the Design Kit User Guide. It can be found on the SG13SFeatures tab on the Virtuoso console window, or in the folder "/eda/design_kits/ihp_sg13/SG13S_618_rev1.12.0/doc/pdf/" on the mikroserver. Especially the part of connecting the substrate (chapter 8.2) and layout (chapter 9). Also make sure you understand the Layout Rules document.

Other documents are found in "eda/design_kits/ihp_sg13/SG13S_618_rev1.12.0/doc/html/"

If you're laying out just one cell (in our case a SRAM-cell) make sure it contains defined values and not just pPar("")-values. This makes it easier to produce the right transistor-sizes etc. If you do not want to change your schematic, make a copy to another cell (e.g. from "sram" to "sram-fixed").

= Layout XL =

From the schematic click Launch -> Layout XL to open the layout environment.

[[File:layout.png|200px]] [[File:layout2.png|200px]]

Layout XL opens with a new black empty canvas. The schematic window also opens. This is very useful as when we add our devices in the layout we can see which device they represent in the schematic as they get highlighted.

Before anything you must define some options to avoid a lot of DRC-errors down the line. In the Layout Rules-document we read what our drawing-grid restrictions are (bottom of page 10). In Layout XL press E to open the Display Options-window. Remember that all size-values are in micrometers. Set the X and Y Snap Spacing to reflect the grid rules. Now press Shift-E to open the Layout Editor Options. Set gravity on(you can turn this off later with the g-key if you dont like it), and aperture around 0.1. This defines the the distance before snapping to another object etc.

[[File:grid.png|200px]] [[File:gravity.png|200px]]

= Generate from source =

IHP has already defined transistors, pins, etc. for different sized, so it is not needed to draw these from scratch. You should, however, dissect them to understand how they work. To place all the devices from the schematic press Connectivity -> Generate -> All From Source. In this window we define which of our devices we want to place, the I/O pins, PR boundary (the area which our cell must be within) and floorplan settings (if needed). For our cell we need to change the IO-pins. We want the gnd and bit-lines to be vertical, and vdd and word-lines to be horizontal. This means that they will intersect each other and must be in different layers. We also want two gnd-pins which also can be defined here. Remember to uncheck Create under the sub!-pin since this is not needed.

Change the Label options to a smaller font size (about 0.1 is ok). Click OK to see the results.

[[File:result.png|600px]]

The purple box is the PR boundary in which are layout must be contained. Notice how the ntap1 is highlighted in the schematic when clicked in the layout window.

= Pin Placement =

Press Place -> Pin Placement. This opens a windows that lets us define the position of our pins. This is very helpful to line up our design. Remember that the positions may be tweaked later.

[[File:pinplacement.png|400px]]

= Placing devices =

If you are extremely lazy you can autoplace the components with Place -> Custom Digital -> Placer. This, however, will probably not give you the desired result. To help you place the the devices correctly it is helpful to see which devices that connect to each other and how. This is accomplished with Connectivity -> Nets -> Show/Hide All Incomplete Nets. This will give you a all the nets that are uncompleted and can be very daunting. However, you can use Ctrl++ (that is Ctrl and +-key ) to turn on or off the nets for the selected device.

F4 switches between Full and Partial Select. Partial Select means that we are able to select individual pieces of a device, e.g. if we want to stretch a part.

[[File:partial.png|50px]] [[File:partial2.png|50px]]

== DRD ==
[[File:DRDbuttons.png|50px]]

DRD stands for Dynamic Design Rule Checking and are helpful while laying out your design. DRD Enforce On prevents you from doing anything that breaks the rules, and DRD Notify tells you if what you are doing is illegal. Image below shows example of DRD Notify.

[[File:DRD.png|200px]]

== Drawing ==

To draw rectangles (e.g. NWell) choose the wanted layer on the left side then press R. To create a connection between to nodes you can either create a wire (Ctrl+W) or a path (P). A wire automatically helps with choosing layer, and may also be used to create vias to another layer by left-clicking.

A complete layout could look something like this:

[[File:sram.png|600px]]

Note that there is a specified minimum enclosure in the design rules for vias between polysilicon and metal. This is because during the manufacturing process, the polysilicon and metal layers are created separately and the alignment is not perfect, so the polysilicon connection must be slightly larger to accommodate the potential offset between these layers. Enclosures can be seen by the polysilicon squares on the vias connecting the Q and Q_B lines in the design above. To set a via enclosure size, right click the via and go to properties. On the bottom, there is a setting for GatPoly enclosure. You must set each direction separately.

= DRC =

Run DRC by pressing Assura -> Run DRC. Make sure technology is SG13_dev and the Rule Set is default. Read about the different switches in the user guide (e.g. antenna-rules etc). If everything is ok this message should appear:

[[File:drcok.png|200px]]

The DRC should also be run for Density. See IHP user guide for how to produce dummy metal to fill the design.

= LVS =

This is covered in chapter 12 of the user guide.

Run LVS by pressing Assura -> Run LVS. This will give you a match if the schematic and the layout match each other, or you will get some errors.

[[File:LVS_summary.png|200px]]

= Parasitic extraction QRC =

This is covered in chapter 14 of the user guide. Before you run the QRC, the LVS has to match.

To do an extraction of your circuit click Assura -> Run Quantus. In "Setup Dir" make sure the path is set to "/eda/design_kits/ihp_sg13/SG13S_616_rev1.0.2_a/Assura_SG13/qrc", where the technology files for the qrc run is. Set the "Parasitic Res Component" to "presistor ivpcell SG13_dev" and the "Parasitic Cap Component" to "pcapacitor ivpcell SG13_dev". Open the Extraction tab and set your ground net (gnd!) in the "Reference node" box. Then run the QRC by pressing OK.

[[File:ASSURA_QRC.png|400px]]

This should give you an extracted design called "av_extracted" in the cell of the library. This can be checked and viewed from the library manager. In this picture the extracted cell is a SRAM with bitline conditioning and a write driver.

[[File:Extracted_layout_SRAM_with_bt_wd.png|400px]]

= Post layout simulation =

In the library manager make an copy of the SRAM cell, to use as a test bench cell. Click file -> new -> Cell View and make an config file in your new test bench cell. Use "config" as the type, and click "ok". In the new window click on the "Use template" and select "AMS", and click "ok". Then edit the view list and add "av_extracted" with the add box. Clicking ok will then bring you to the hierarchy editor.

Then you need a test bench schematic. In your copied schematic you will have the whole SRAM or different symbols making up the SRAM, but for the simulation there should only be a symbol that matches the extracted layout. So go back to the schematic in the SRAM cell and make one symbol out of it. Put this symbol into the test bench schematic, and add the pins that are needed.

Go back to the hierarchy editor and change the View to your test bench schematic and update the hierarchy. Then right click on the "view found" for the SRAM from the SRAM cell, and select the av_extracted.

[[File:Hierarchy_editor.png|400px]]

Then Launch -> ADE L to get the simulation setup. Setup -> Design and choose the config file from the test bench cell. Use the stimuli button to create the stimuli (copy the stimuli from the schematic simulation) for the test, and then run it.

[[Category:Mikroelektronikk]]

IHP 130nm process

2020-10-15T08:32:12Z

Nfyku:

=Cadence design with IHP 130nm process=

==Starting up the IHP SG13S Design Kit==

The following steps describe how to install the Process Design Kit and start a new design.

Log on to the mikroserver:
ssh -X mikroserver4

The preferred shell is bash. When using another shell it will be necessary to change the installation routine and modify the initialization script accordingly.

The '''first time''' you are using the IHP design kit you should copy the user environment design to your chosen parent directory (e.g ~/ihp)
cp -rp /eda/design_kits/ihp_sg13/SG13S_618_rev1.12.0/work/skel ~/ihp

Change sh.cadence in ~/ihp/cds to suit your needs. In particular you must define $IHP_TECH and $PROJECT according to your local environment. Then set general and user Cadence environment variables by doing:
source /eda/cadence/2019-20/scripts/analog.sh
cd ~/ihp/cds/
source /eda/design_kits/ihp_sg13/sh.cadence
virtuoso &

To avoid having to do this every time try to set up your environment like described in [[MikroserverSetup]]

Follow the Design Kit User manual found in the menu SG13S Features > Design Kit Documentation. Make sure that your web browser is closed or started from the microserver, else the file will not be found.

[[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] [[Category:Cadence_Virtuoso]]

Layout XL and IHP SG13S

2020-10-15T08:07:40Z

Nfyku:

= Before starting layout =

Read the Design Kit User Guide. The user guide "SG13_user_guide.pdf" can be also be found in the folder "/eda/design_kits/ihp_sg13/SG13S_618_rev1.12.0/doc/pdf/" on the microserver.
Especially the part of connecting the substrate (chapter 8.2) and layout (chapter 9). Also make sure you understand the Layout Rules document.

[[File:SG13 Design Kit User Guide.pdf]]

[[File:SG13 Layout rules.pdf]]

[[File:Documentation.png|200px]]

If you're laying out just one cell (in our case a SRAM-cell) make sure it contains defined values and not just pPar("")-values. This makes it easier to produce the right transistor-sizes etc. If you do not want to change your schematic, make a copy to another cell (e.g. from "sram" to "sram-fixed").

= Layout XL =

From the schematic click Launch -> Layout XL to open the layout environment.

[[File:layout.png|200px]] [[File:layout2.png|200px]]

Layout XL opens with a new black empty canvas. The schematic window also opens. This is very useful as when we add our devices in the layout we can see which device they represent in the schematic as they get highlighted.

Before anything you must define some options to avoid a lot of DRC-errors down the line. In the Layout Rules-document we read what our drawing-grid restrictions are (bottom of page 10). In Layout XL press E to open the Display Options-window. Remember that all size-values are in micrometers. Set the X and Y Snap Spacing to reflect the grid rules. Now press Shift-E to open the Layout Editor Options. Set gravity on(you can turn this off later with the g-key if you dont like it), and aperture around 0.1. This defines the the distance before snapping to another object etc.

[[File:grid.png|200px]] [[File:gravity.png|200px]]

= Generate from source =

IHP has already defined transistors, pins, etc. for different sized, so it is not needed to draw these from scratch. You should, however, dissect them to understand how they work. To place all the devices from the schematic press Connectivity -> Generate -> All From Source. In this window we define which of our devices we want to place, the I/O pins, PR boundary (the area which our cell must be within) and floorplan settings (if needed). For our cell we need to change the IO-pins. We want the gnd and bit-lines to be vertical, and vdd and word-lines to be horizontal. This means that they will intersect each other and must be in different layers. We also want two gnd-pins which also can be defined here. Remember to uncheck Create under the sub!-pin since this is not needed.

Change the Label options to a smaller font size (about 0.1 is ok). Click OK to see the results.

[[File:result.png|600px]]

The purple box is the PR boundary in which are layout must be contained. Notice how the ntap1 is highlighted in the schematic when clicked in the layout window.

= Pin Placement =

Press Place -> Pin Placement. This opens a windows that lets us define the position of our pins. This is very helpful to line up our design. Remember that the positions may be tweaked later.

[[File:pinplacement.png|400px]]

= Placing devices =

If you are extremely lazy you can autoplace the components with Place -> Custom Digital -> Placer. This, however, will probably not give you the desired result. To help you place the the devices correctly it is helpful to see which devices that connect to each other and how. This is accomplished with Connectivity -> Nets -> Show/Hide All Incomplete Nets. This will give you a all the nets that are uncompleted and can be very daunting. However, you can use Ctrl++ (that is Ctrl and +-key ) to turn on or off the nets for the selected device.

F4 switches between Full and Partial Select. Partial Select means that we are able to select individual pieces of a device, e.g. if we want to stretch a part.

[[File:partial.png|50px]] [[File:partial2.png|50px]]

== DRD ==
[[File:DRDbuttons.png|50px]]

DRD stands for Dynamic Design Rule Checking and are helpful while laying out your design. DRD Enforce On prevents you from doing anything that breaks the rules, and DRD Notify tells you if what you are doing is illegal. Image below shows example of DRD Notify.

[[File:DRD.png|200px]]

== Drawing ==

To draw rectangles (e.g. NWell) choose the wanted layer on the left side then press R. To create a connection between to nodes you can either create a wire (Ctrl+W) or a path (P). A wire automatically helps with choosing layer, and may also be used to create vias to another layer by left-clicking.

A complete layout could look something like this:

[[File:sram.png|600px]]

Note that there is a specified minimum enclosure in the design rules for vias between polysilicon and metal. This is because during the manufacturing process, the polysilicon and metal layers are created separately and the alignment is not perfect, so the polysilicon connection must be slightly larger to accommodate the potential offset between these layers. Enclosures can be seen by the polysilicon squares on the vias connecting the Q and Q_B lines in the design above. To set a via enclosure size, right click the via and go to properties. On the bottom, there is a setting for GatPoly enclosure. You must set each direction separately.

= DRC =

Run DRC by pressing Assura -> Run DRC. Make sure technology is SG13_dev and the Rule Set is default. Read about the different switches in the user guide (e.g. antenna-rules etc). If everything is ok this message should appear:

[[File:drcok.png|200px]]

The DRC should also be run for Density. See IHP user guide for how to produce dummy metal to fill the design.

= LVS =

This is covered in chapter 12 of the user guide.

Run LVS by pressing Assura -> Run LVS. This will give you a match if the schematic and the layout match each other, or you will get some errors.

[[File:LVS_summary.png|200px]]

= Parasitic extraction QRC =

This is covered in chapter 14 of the user guide. Before you run the QRC, the LVS has to match.

To do an extraction of your circuit click Assura -> Run Quantus. In "Setup Dir" make sure the path is set to "/eda/design_kits/ihp_sg13/SG13S_616_rev1.0.2_a/Assura_SG13/qrc", where the technology files for the qrc run is. Set the "Parasitic Res Component" to "presistor ivpcell SG13_dev" and the "Parasitic Cap Component" to "pcapacitor ivpcell SG13_dev". Open the Extraction tab and set your ground net (gnd!) in the "Reference node" box. Then run the QRC by pressing OK.

[[File:ASSURA_QRC.png|400px]]

This should give you an extracted design called "av_extracted" in the cell of the library. This can be checked and viewed from the library manager. In this picture the extracted cell is a SRAM with bitline conditioning and a write driver.

[[File:Extracted_layout_SRAM_with_bt_wd.png|400px]]

= Post layout simulation =

In the library manager make an copy of the SRAM cell, to use as a test bench cell. Click file -> new -> Cell View and make an config file in your new test bench cell. Use "config" as the type, and click "ok". In the new window click on the "Use template" and select "AMS", and click "ok". Then edit the view list and add "av_extracted" with the add box. Clicking ok will then bring you to the hierarchy editor.

Then you need a test bench schematic. In your copied schematic you will have the whole SRAM or different symbols making up the SRAM, but for the simulation there should only be a symbol that matches the extracted layout. So go back to the schematic in the SRAM cell and make one symbol out of it. Put this symbol into the test bench schematic, and add the pins that are needed.

Go back to the hierarchy editor and change the View to your test bench schematic and update the hierarchy. Then right click on the "view found" for the SRAM from the SRAM cell, and select the av_extracted.

[[File:Hierarchy_editor.png|400px]]

Then Launch -> ADE L to get the simulation setup. Setup -> Design and choose the config file from the test bench cell. Use the stimuli button to create the stimuli (copy the stimuli from the schematic simulation) for the test, and then run it.

[[Category:Mikroelektronikk]]

IHP 130nm process

2020-10-15T07:58:27Z

Nfyku: Updated to new software distro and design kit

=Cadence design with IHP 130nm process=

==Starting up the IHP SG13S Design Kit==

The following steps describe how to install the Process Design Kit and start a new design.

Log on to the mikroserver:
ssh -X mikroserver4

The preferred shell is bash. When using another shell it will be necessary to change the installation routine and modify the initialization script accordingly.

The '''first time''' you are using the IHP design kit you should copy the user environment design to your chosen parent directory (e.g ~/ihp)
cp -rp /eda/design_kits/ihp_sg13/SG13S_618_rev1.12.0/work/skel ~/ihp

Change sh.cadence in ~/ihp/cds to suit your needs. In particular you must define $IHP_TECH and $PROJECT according to your local environment. Then set general and user Cadence environment variables by doing:
source /eda/cadence/2019-20/scripts/analog.sh
cd ~/ihp/cds/
source sh.cadence
virtuoso &

To avoid having to do this every time try to set up your environment like described in [[MikroserverSetup]]

Follow the Design Kit User manual found in the menu SG13S Features > Design Kit Documentation. Make sure that your web browser is closed or started from the microserver, else the file will not be found.

[[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] [[Category:Cadence_Virtuoso]]

Symbolsk løsning av nodeligninger med Matlab

2020-09-23T11:39:47Z

Nfyku: Added calculation for all capacitors

=== Using Kirchoff's current law (KCL) on a source follower configuration to find Vout as a function of Vin ===
<pre>
% Using Kirchoff's current law (KCL) on a source follower configuration
% to find Vo as a function of Vin
% Kjetil Ullaland, 2020

syms s Cdg Cgs Cds Vin Vo Vgs Zc gm Rl Rs R Av Avo

%%
disp('Only Cgd with series resistor is considered (Zc)')

eq1=(Vo-Vgs)/(R+Zc)+gm*Vgs+Vo/Rl == 0;
eq2=(Vgs-Vo)/(R+Zc)+(Vgs-Vin)/Rs == 0;
eq1=subs(eq1,Zc,1/(s*Cdg));
eq2=subs(eq2,Zc,1/(s*Cdg));
disp('KCL for circuit node 1:');
pretty(eq1);
disp('KCL for circuit node 2:');
pretty(eq2);

disp('Solve for Vo and Vin and calculate Av (Vo/Vin):');
solved=solve(eq1,eq2,Vo,Vin);
Av=solved.Vo/solved.Vin;
pretty(simplify(Av));

pretty(subs(Av,Rl*gm,Avo));
%%
disp('All MOST capasitors are considered')

syms s Cdg Cgs Cds Vin Vo Vgs gm Rl Rs Av Avo

eq1=(Vo-Vgs)*s*Cdg + gm*Vgs + Vo/Rl + Vo*s*Cds == 0;
eq2=(Vgs-Vin)/Rs + Vgs*s*Cgs + (Vgs-Vo)*s*Cdg == 0;
disp('KCL for circuit node 1:');
pretty(eq1);
disp('KCL for circuit node 2:');
pretty(eq2);

disp('Solve for Vo and Vin and calculate Av (Vo/Vin):');
solved=solve(eq1,eq2,Vo,Vin);
Av=solved.Vo/solved.Vin;
pretty(simplify(Av));

pretty(subs(Av,Rl*gm,Avo));
</pre>

=== Using Kirchoff's current law (KCL) on single transistor stage, fig. 9.18 to find Vo as a function of Is ===
<pre>
% Using Kirchoff's current law (KCL) on single transistor stage, fig. 9.18
% to find Vo as a function of Is
% Kjetil Ullaland, 2020

syms Vo V1 s gm R1 R2 C C1 C2 Is Zc Rz;

%% With feedforward capacitor
eq1=(Vo-V1)/Zc+gm*V1+Vo/R2+Vo*s*C2==0;
eq2=(V1-Vo)/Zc+V1*s*C1+V1/R1+Is==0;
eq1=subs(eq1,Zc,1/(s*C));
eq2=subs(eq2,Zc,1/(s*C));

disp('Solve for Vo and V1 and calculate Vo/Is with capacitor only in feedforward loop');
solved=solve(eq1,eq2,Vo,Is);
VoOnIs=solved.Vo/solved.Is;
pretty(simplify(VoOnIs));

%% With series resistor and capacitor in feedforward loop
eq1=(Vo-V1)/(Zc+Rz)+gm*V1+Vo/R2+Vo*s*C2==0;
eq2=(V1-Vo)/(Zc+Rz)+V1*s*C1+V1/R1+Is==0;
eq1=subs(eq1,Zc,1/(s*C));
eq2=subs(eq2,Zc,1/(s*C));

disp('Solve for Vo and V1 and calculate Vo/Is with resistor and capacitor in feedforward loop');
solved=solve(eq1,eq2,Vo,Is);
VoOnIs=solved.Vo/solved.Is;
pretty(simplify(VoOnIs));
</pre>

Symbolsk løsning av nodeligninger med Matlab

2020-09-23T11:13:48Z

Nfyku:

=== Using Kirchoff's current law (KCL) on a source follower configuration to find Vout as a function of Vin ===
<pre>
% Using Kirchoff's current law (KCL) on a source follower configuration
% to find Vo as a function of Vin
% Only Cgd is considered (Zc)
% Kjetil Ullaland

syms s C Vin Vo Vgs Zc gm Rl Rs R Av Avo

eq1=(Vo-Vgs)/(R+Zc)+gm*Vgs+Vo/Rl == 0;
eq2=(Vgs-Vo)/(R+Zc)+(Vgs-Vin)/Rs == 0;
eq1=subs(eq1,Zc,1/(s*C));
eq2=subs(eq2,Zc,1/(s*C));
disp('KCL for circuit node 1:');
pretty(eq1);
disp('KCL for circuit node 2:');
pretty(eq2);

disp('Solve for Vo and Vin and calculate Av (Vo/Vin):');
solved=solve(eq1,eq2,Vo,Vin);
Av=solved.Vo/solved.Vin;
pretty(simplify(Av));

pretty(subs(Av,Rl*gm,Avo));
</pre>

=== Using Kirchoff's current law (KCL) on single transistor stage, fig. 9.18 to find Vo as a function of Is ===
<pre>
% Using Kirchoff's current law (KCL) on single transistor stage, fig. 9.18
% to find Vo as a function of Is
% Kjetil Ullaland, 2020

syms Vo V1 s gm R1 R2 C C1 C2 Is Zc Rz;

%% With feedforward capacitor
eq1=(Vo-V1)/Zc+gm*V1+Vo/R2+Vo*s*C2==0;
eq2=(V1-Vo)/Zc+V1*s*C1+V1/R1+Is==0;
eq1=subs(eq1,Zc,1/(s*C));
eq2=subs(eq2,Zc,1/(s*C));

disp('Solve for Vo and V1 and calculate Vo/Is with capacitor only in feedforward loop');
solved=solve(eq1,eq2,Vo,Is);
VoOnIs=solved.Vo/solved.Is;
pretty(simplify(VoOnIs));

%% With series resistor and capacitor in feedforward loop
eq1=(Vo-V1)/(Zc+Rz)+gm*V1+Vo/R2+Vo*s*C2==0;
eq2=(V1-Vo)/(Zc+Rz)+V1*s*C1+V1/R1+Is==0;
eq1=subs(eq1,Zc,1/(s*C));
eq2=subs(eq2,Zc,1/(s*C));

disp('Solve for Vo and V1 and calculate Vo/Is with resistor and capacitor in feedforward loop');
solved=solve(eq1,eq2,Vo,Is);
VoOnIs=solved.Vo/solved.Is;
pretty(simplify(VoOnIs));
</pre>

Symbolsk løsning av nodeligninger med Matlab

2020-09-23T11:02:34Z

Nfyku: Updated for newer Matalb versions (tested on R2020b)

=== Using Kirchoff's current law (KCL) on a source follower configuration to find Vout as a function of Vin ===
<pre>
% Using Kirchoff's current law (KCL) on a source follower configuration
% to find Vo as a function of Vin
% Only Cgd is considered (Zc)
% Kjetil Ullaland

syms s C Vin Vo Vgs Zc gm Rl Rs R Av Avo

eq1=(Vo-Vgs)/(R+Zc)+gm*Vgs+Vo/Rl == 0;
eq2=(Vgs-Vo)/(R+Zc)+(Vgs-Vin)/Rs == 0;
eq1=subs(eq1,Zc,1/(s*C));
eq2=subs(eq2,Zc,1/(s*C));
disp('KCL for circuit node 1:');
pretty(eq1);
disp('KCL for circuit node 2:');
pretty(eq2);

disp('Solve for Vo and Vin and calculate Av (Vo/Vin):');
solved=solve(eq1,eq2,Vo,Vin);
Av=solved.Vo/solved.Vin;
pretty(simplify(Av));

pretty(subs(Av,Rl*gm,Avo));
</pre>

=== Using Kirchoff's current law (KCL) on single transistor stage, fig. 9.18 to find Vo as a function of Is ===
<pre>
% Using Kirchoff's current law (KCL) on single transistor stage, fig. 9.18
% to find Vo as a function of Is
% Kjetil Ullaland, 2015

syms Vo V1 s gm R1 R2 C C1 C2 Is Zc Rz;

%% With feedforward capacitor
eq1=sym('(Vo-V1)/Zc+gm*V1+Vo/R2+Vo*s*C2=0');
eq2=sym('(V1-Vo)/Zc+V1*s*C1+V1/R1+Is=0');
eq1=subs(eq1,Zc,'1/(s*C)');
eq2=subs(eq2,Zc,'1/(s*C)');

solV1=solve(eq2,V1);
eq3=subs(eq1,V1,solV1);
SolVo=simplify(solve(eq3,[Vo]));
disp('With capacitor only in feedforward loop');
pretty(simplify(SolVo/Is));

%% With series resistor and capacitor in feedforward loop
eq1=sym('(Vo-V1)/(Zc+Rz)+gm*V1+Vo/R2+Vo*s*C2=0');
eq2=sym('(V1-Vo)/(Zc+Rz)+V1*s*C1+V1/R1+Is=0');
eq1=subs(eq1,Zc,'1/(s*C)');
eq2=subs(eq2,Zc,'1/(s*C)');

solV1=solve(eq2,V1);
eq3=simplify(subs(eq1,V1,solV1));
SolVo=solve(eq3,[Vo]);
disp('With series resistor and capacitor in feedforward loop');
pretty(simplify(SolVo/Is));
</pre>

PHYS222

2020-09-07T13:37:04Z

Nfyku: /* Prosessteknologi */

== Fagressurser for bruk i PHYS222 og PHYS223 ==

=== Fagbøker ===
* [http://www.cmosvlsi.com/ CMOS VLSI Design: A Circuits and Systems Perspective]
* [http://www.ece.ucdavis.edu/sscrl/book_corrections/ghlm/corr/ List of known errors and corrections for Analysis and Design of Analog Integrated Circuits, Fourth Edition]

==== Tutorials ====
* [http://www.electronics-tutorials.ws Basic Electronics Tutorials]

=== Noise ===
* [http://ieeexplore.ieee.org/search/srchabstract.jsp?arnumber=261888&isnumber=6598&punumber=101&k2dockey=261888@ieeejrns&query=261888%3Cin%3Earnumber&pos=0 White noise in MOS transistors and resistors]
* [http://www.stat.ualberta.ca/people/schmu/preprints/poisson.pdf Shark attacks and the Poisson approximation]
* [https://www.k-state.edu/edl/docs/pubs/technical-resources/Technote1.pdf Equivalent Noise Bandwidth]

=== Halvlederfysikk ===
* [https://www.youtube.com/watch?v=Coy-WRCfems How does a diode work?]
* [http://hyperphysics.phy-astr.gsu.edu/HBASE/solids/semcn.html Hyperphysics om halvledere]
* [http://jas.eng.buffalo.edu/index.html Semiconductor Simulation Applets]
* [http://pveducation.org/ Photovoltaic Education Network]
* [http://www.semi1source.com/glossary/ Semiconductor Glossary]

=== Prosessteknologi ===
* [http://micro.magnet.fsu.edu/electromag/java/transistor/index.html Explore how an individual Field Effect (FET) transistor is fabricated on a silicon wafer simultaneously with millions of its neighbours]
* [https://www.youtube.com/watch?v=Jctk0DI7YP8 Understanding The FinFet Semiconductor Process]
* [https://youtu.be/MvbP_TizoNs Problems and Solutions at 7nm]
* [https://youtu.be/Qo2ywUURSKg A tour inside Intel Corporation's D1D factory]
* [https://www.youtube.com/watch?v=W3rfVpkNquA Intel Ivy Bridge 22nm FinFET Process Fabrication]
* [https://youtu.be/ApWOf6J858Y Integrated circuit scaling to 10 nm and beyond - Mark Bohr, Intel Senior Fellow]
* [http://spectrum.ieee.org/semiconductors/devices/transistor-wars Transistor Wars - Rival architectures face off in a bid to keep Moore's Law alive]

=== Logical effort ===
* [https://en.wikipedia.org/wiki/Logical_effort Logical Effort Wikipedia]

=== Matlab/Maple ===
Vi kan bruke Matlab/Maple for å løse ligninger og plotte resultater. Her er noen eksempler:

* [[Symbolsk løsning av nodeligninger med Matlab]]
* [http://lpsa.swarthmore.edu/Bode/BodeHow.html The Asymptotic Bode Diagram: Derivation of Approximations]
=== Kretssimulering ===

[[ Eksempler/Oppgaver ]]

==== AIM-Spice ====
AIM-Spice is a new version of SPICE running under the Microsoft Windows and Linux operating systems. AIM-Spice for Windows is capable of displaying graphically the results of a simulation in progress, a feature that allows the operator to terminate a run based on an instant information on intermediate simulation results.

SPICE is the most commonly used analogue circuit simulator today and is enormously important for the electronics industry. SPICE is a general purpose analogue simulator which contains models for most circuit elements and can handle complex non-linear circuits. The simulator can calculate dc operating points, perform transient analyses, locate poles and zeros for different kinds of transfer functions, find the small signal frequency response, small signal transfer functions, small signal sensitivities, and perform Fourier, noise, and distortion analyses.

[http://www.aimspice.com/download.html Download a free student version]

==== LTspice ====

LTspice is a high performance Spice III simulator, schematic capture and waveform viewer with enhancements and models for easing the simulation of switching regulators. Included in this download are Spice, Macro Models for 80% of Linear Technology's switching regulators, over 200 op amp models, as well as resistors, transistors and MOSFET models.

[http://www.linear.com/designtools/software/switchercad.jsp Download LTspice]

[[Category:Mikroelektronikk]]

PHYS222

2020-09-07T13:33:13Z

Nfyku: /* Prosessteknologi */

== Fagressurser for bruk i PHYS222 og PHYS223 ==

=== Fagbøker ===
* [http://www.cmosvlsi.com/ CMOS VLSI Design: A Circuits and Systems Perspective]
* [http://www.ece.ucdavis.edu/sscrl/book_corrections/ghlm/corr/ List of known errors and corrections for Analysis and Design of Analog Integrated Circuits, Fourth Edition]

==== Tutorials ====
* [http://www.electronics-tutorials.ws Basic Electronics Tutorials]

=== Noise ===
* [http://ieeexplore.ieee.org/search/srchabstract.jsp?arnumber=261888&isnumber=6598&punumber=101&k2dockey=261888@ieeejrns&query=261888%3Cin%3Earnumber&pos=0 White noise in MOS transistors and resistors]
* [http://www.stat.ualberta.ca/people/schmu/preprints/poisson.pdf Shark attacks and the Poisson approximation]
* [https://www.k-state.edu/edl/docs/pubs/technical-resources/Technote1.pdf Equivalent Noise Bandwidth]

=== Halvlederfysikk ===
* [https://www.youtube.com/watch?v=Coy-WRCfems How does a diode work?]
* [http://hyperphysics.phy-astr.gsu.edu/HBASE/solids/semcn.html Hyperphysics om halvledere]
* [http://jas.eng.buffalo.edu/index.html Semiconductor Simulation Applets]
* [http://pveducation.org/ Photovoltaic Education Network]
* [http://www.semi1source.com/glossary/ Semiconductor Glossary]

=== Prosessteknologi ===
* [http://micro.magnet.fsu.edu/electromag/java/transistor/index.html Explore how an individual Field Effect (FET) transistor is fabricated on a silicon wafer simultaneously with millions of its neighbours]
* [https://www.youtube.com/watch?v=Jctk0DI7YP8 Understanding The FinFet Semiconductor Process]
* [https://youtu.be/MvbP_TizoNs Problems and Solutions at 7nm]
* [https://youtu.be/Qo2ywUURSKg A tour inside Intel Corporation's D1D factory]
* [https://www.youtube.com/watch?v=W3rfVpkNquA Intel Ivy Bridge 22nm FinFET Process Fabrication]
* [http://spectrum.ieee.org/semiconductors/devices/transistor-wars Transistor Wars - Rival architectures face off in a bid to keep Moore's Law alive]

=== Logical effort ===
* [https://en.wikipedia.org/wiki/Logical_effort Logical Effort Wikipedia]

=== Matlab/Maple ===
Vi kan bruke Matlab/Maple for å løse ligninger og plotte resultater. Her er noen eksempler:

* [[Symbolsk løsning av nodeligninger med Matlab]]
* [http://lpsa.swarthmore.edu/Bode/BodeHow.html The Asymptotic Bode Diagram: Derivation of Approximations]
=== Kretssimulering ===

[[ Eksempler/Oppgaver ]]

==== AIM-Spice ====
AIM-Spice is a new version of SPICE running under the Microsoft Windows and Linux operating systems. AIM-Spice for Windows is capable of displaying graphically the results of a simulation in progress, a feature that allows the operator to terminate a run based on an instant information on intermediate simulation results.

SPICE is the most commonly used analogue circuit simulator today and is enormously important for the electronics industry. SPICE is a general purpose analogue simulator which contains models for most circuit elements and can handle complex non-linear circuits. The simulator can calculate dc operating points, perform transient analyses, locate poles and zeros for different kinds of transfer functions, find the small signal frequency response, small signal transfer functions, small signal sensitivities, and perform Fourier, noise, and distortion analyses.

[http://www.aimspice.com/download.html Download a free student version]

==== LTspice ====

LTspice is a high performance Spice III simulator, schematic capture and waveform viewer with enhancements and models for easing the simulation of switching regulators. Included in this download are Spice, Macro Models for 80% of Linear Technology's switching regulators, over 200 op amp models, as well as resistors, transistors and MOSFET models.

[http://www.linear.com/designtools/software/switchercad.jsp Download LTspice]

[[Category:Mikroelektronikk]]

PHYS222

2020-09-07T13:26:55Z

Nfyku: /* Prosessteknologi */

== Fagressurser for bruk i PHYS222 og PHYS223 ==

=== Fagbøker ===
* [http://www.cmosvlsi.com/ CMOS VLSI Design: A Circuits and Systems Perspective]
* [http://www.ece.ucdavis.edu/sscrl/book_corrections/ghlm/corr/ List of known errors and corrections for Analysis and Design of Analog Integrated Circuits, Fourth Edition]

==== Tutorials ====
* [http://www.electronics-tutorials.ws Basic Electronics Tutorials]

=== Noise ===
* [http://ieeexplore.ieee.org/search/srchabstract.jsp?arnumber=261888&isnumber=6598&punumber=101&k2dockey=261888@ieeejrns&query=261888%3Cin%3Earnumber&pos=0 White noise in MOS transistors and resistors]
* [http://www.stat.ualberta.ca/people/schmu/preprints/poisson.pdf Shark attacks and the Poisson approximation]
* [https://www.k-state.edu/edl/docs/pubs/technical-resources/Technote1.pdf Equivalent Noise Bandwidth]

=== Halvlederfysikk ===
* [https://www.youtube.com/watch?v=Coy-WRCfems How does a diode work?]
* [http://hyperphysics.phy-astr.gsu.edu/HBASE/solids/semcn.html Hyperphysics om halvledere]
* [http://jas.eng.buffalo.edu/index.html Semiconductor Simulation Applets]
* [http://pveducation.org/ Photovoltaic Education Network]
* [http://www.semi1source.com/glossary/ Semiconductor Glossary]

=== Prosessteknologi ===
* [http://micro.magnet.fsu.edu/electromag/java/transistor/index.html Explore how an individual Field Effect (FET) transistor is fabricated on a silicon wafer simultaneously with millions of its neighbours]
* [https://www.youtube.com/watch?v=Jctk0DI7YP8 Understanding The FinFet Semiconductor Process]
* [https://youtu.be/MvbP_TizoNs Problems and Solutions at 7nm]
* [https://www.youtube.com/watch?v=W3rfVpkNquA Intel Ivy Bridge 22nm FinFET Process Fabrication]
* [http://spectrum.ieee.org/semiconductors/devices/transistor-wars Transistor Wars - Rival architectures face off in a bid to keep Moore's Law alive]

=== Logical effort ===
* [https://en.wikipedia.org/wiki/Logical_effort Logical Effort Wikipedia]

=== Matlab/Maple ===
Vi kan bruke Matlab/Maple for å løse ligninger og plotte resultater. Her er noen eksempler:

* [[Symbolsk løsning av nodeligninger med Matlab]]
* [http://lpsa.swarthmore.edu/Bode/BodeHow.html The Asymptotic Bode Diagram: Derivation of Approximations]
=== Kretssimulering ===

[[ Eksempler/Oppgaver ]]

==== AIM-Spice ====
AIM-Spice is a new version of SPICE running under the Microsoft Windows and Linux operating systems. AIM-Spice for Windows is capable of displaying graphically the results of a simulation in progress, a feature that allows the operator to terminate a run based on an instant information on intermediate simulation results.

SPICE is the most commonly used analogue circuit simulator today and is enormously important for the electronics industry. SPICE is a general purpose analogue simulator which contains models for most circuit elements and can handle complex non-linear circuits. The simulator can calculate dc operating points, perform transient analyses, locate poles and zeros for different kinds of transfer functions, find the small signal frequency response, small signal transfer functions, small signal sensitivities, and perform Fourier, noise, and distortion analyses.

[http://www.aimspice.com/download.html Download a free student version]

==== LTspice ====

LTspice is a high performance Spice III simulator, schematic capture and waveform viewer with enhancements and models for easing the simulation of switching regulators. Included in this download are Spice, Macro Models for 80% of Linear Technology's switching regulators, over 200 op amp models, as well as resistors, transistors and MOSFET models.

[http://www.linear.com/designtools/software/switchercad.jsp Download LTspice]

[[Category:Mikroelektronikk]]

Microelectronics group

2020-08-18T14:11:34Z

Nfyku:

== Øvinger og guider ==
=== Mentor Graphics ===

* [[Expedition PCB]] Komme i gang med kretskortutlegg ved hjelp av Expedition PCB

* [[Modelsim/Questa]] Skrive og simulere VHDL-kode med Mentor Graphics ModelSim

=== Cadence ===

* [[Cadence Virtuoso]]

=== Microsemi ===

* [[SmartFusion2- AMBA APB, Custom Peripheral]] Making a custom peripheral for the AMBA APB bus

=== Xilinx ===

* [[Xilinx Vivado]] Tutorials for Xilinx Vivado

* [[Xilinx SDK]] Tutorials for Xilinx Software Development Kit

=== Annet ===
* [[Bitvis UVVM VHDL Verification Component Framework]]

* [[Tutorials]] Tutorials from the web

* [[XJTAG]] Boundary Scan with XJTAG

* [[XJDeveloper]] Innføring i XJDeveloper

* [[FreeRTOS]] Free Real Time Operating System

== Andre fagressurser og laboratorieveiledninger==

* [[MikroserverSetup]] Oppsett av enkel tilkobling til mikroserverene

* [[PHYS222]] Fagressurser for PHYS222 og PHYS223

* [[PHYS321]] Fagressurser for PHYS321

* [[Teknisk hjelp]] Teknisk hjelp for bruk av DAK-programvare

* [[BGA lodding]] bruk av Martin 09.6 XL BGA lodding maskin (intern)

* [[Reflow Soldering]] Use of Technoprint HA-02 reflow oven

== Populærvitenskaplig om elektronikk ==
* [https://youtu.be/NUUeGianTKM The Story of Electricity - BBC Documentary]

* [https://www.youtube.com/watch?v=U4XknGqr3Bo Transiztorized! ]

== Eldre øvinger og guider ==
=== Mentor Graphics ===
* [[IC studio]] Veiledning til IC-design ved hjelp av IC studio

* [[IC studio - SPICE/Symbol Tutorial]] Relate a SPICE file to a Symbol

* [[IC Station]] Tegne utlegg for integrerte kretser

=== Annet ===
* [[PCI-eksperiment]] Øving med HLT-RORC-prototypekort

* [[Xilinx]] Øving i bruk av Xilinx Project Studio

* [[SmartFusion2]] Oppsett og design med SF2

* [[FLTK GUI]] Graphical User Interface using FLTK

[[Category:Mikroelektronikk]]

Microelectronics group

2020-08-18T14:07:19Z

Nfyku:

== Øvinger og guider ==
=== Mentor Graphics ===

* [[Expedition PCB]] Komme i gang med kretskortutlegg ved hjelp av Expedition PCB

* [[Modelsim/Questa]] Skrive og simulere VHDL-kode med Mentor Graphics ModelSim

=== Cadence ===

* [[Cadence Virtuoso]]

=== Microsemi ===

* [[SmartFusion2- AMBA APB, Custom Peripheral]] Making a custom peripheral for the AMBA APB bus

=== Xilinx ===

* [[Xilinx Vivado]] Tutorials for Xilinx Vivado

* [[Xilinx SDK]] Tutorials for Xilinx Software Development Kit

=== Annet ===
* [[Bitvis UVVM VHDL Verification Component Framework]]

* [[Tutorials]] Tutorials from the web

* [[XJTAG]] Boundary Scan with XJTAG

* [[XJDeveloper]] Innføring i XJDeveloper

* [[FreeRTOS]] Free Real Time Operating System

== Andre fagressurser og laboratorieveiledninger==

* [[MikroserverSetup]] Oppsett av enkel tilkobling til mikroserverene

* [[PHYS222]] Fagressurser for PHYS222 og PHYS223

* [[PHYS321]] Fagressurser for PHYS321

* [[Teknisk hjelp]] Teknisk hjelp for bruk av DAK-programvare

* [[BGA lodding]] bruk av Martin 09.6 XL BGA lodding maskin (intern)

* [[Reflow Soldering]] Use of Technoprint HA-02 reflow oven

== Populærvitenskaplig om elektronikk ==
* [https://youtu.be/NUUeGianTKM The Story of Electricity - BBC Documentary]

== Eldre øvinger og guider ==
=== Mentor Graphics ===
* [[IC studio]] Veiledning til IC-design ved hjelp av IC studio

* [[IC studio - SPICE/Symbol Tutorial]] Relate a SPICE file to a Symbol

* [[IC Station]] Tegne utlegg for integrerte kretser

=== Annet ===
* [[PCI-eksperiment]] Øving med HLT-RORC-prototypekort

* [[Xilinx]] Øving i bruk av Xilinx Project Studio

* [[SmartFusion2]] Oppsett og design med SF2

* [[FLTK GUI]] Graphical User Interface using FLTK

[[Category:Mikroelektronikk]]

SSH tunnel

2020-03-30T08:21:14Z

Nfyku:

==VNC-SSH innlogging==
===Opprette SSH tunnel===

# Start opp SSH Secure Shell
# Velg Profiles → Add Profile… gi den et navn f.eks. "mikroserver2 via login"
# Velg Profiles → Edit Profiles…, velg mikroserver2 blant profiles i venstre felt.
# Velg Tunneling tab
# Velg Outgoing tab
## Klikk Add…
## Skriv inn et navn i Display Name feltet, f.eks. mikroserver2
## Pass på at Type er TCP
## Skriv inn 5900 i feltet Listen Port
## Sjekk at Allow Local Connections Only er krysset av
## Skriv inn mikroserver2 i Destination Host (adressen til maskinen du kjører VNC server på. Bruk fullt navn om nødvendig: host.klientdrift.uib.no)
## Skriv inn summen av 5900 og ditt desktop nummer, eks 5906, i feltet Destination Port
## Klikk OK
# Velg Conection tab
## Skriv inn login.uib.no i Host name feltet
## Skriv inn ditt unix-brukernavn i User name feltet
## Port number skal være 22
## la resten være som det er.
## Klikk OK (ferdig med konfigurasjon)
# Velg Profiles -> "mikroserver2 via login"
# Tast inn ditt unix-bruker passord
# Legg ned / minimize SSH vinduet, det kjører nå SSH tunnellen og må kjøre så lenge du bruke VNC Viewer via SSH.
# Når du er ferdig og har avsluttet VNC Viewer, logger du først ut fra serveren med kommandoen logout og så lukker du SSH vinduet.

====Neste gang du skal opprette SSH tunnellen====

# Start SSH Secure Shell
# Utfør punktene fra og med punkt 7 over.

===Login til VNC-SSH server===

Start først opp din egen VNC server som forklart i VNC innlogging mot egen server, eller bruk en eksisternde VNC server.

Start VNC Viewer og skriv inn localhost (ikke :port) i Server feltet og click OK og tast inn ditt vnc passord.

===Logout fra egen VNC-SSH server===

Bruk samme fremgangsmåte som forklart under Metode 2 → Logout fra egen VNC server i VNC innlogging.

===Problemer?===

Om du får melding om at SSH tunnell ikke kunne opprettes, sjekk om du kjører VNC-server på din pc, den kan skape problemer.

[[Category:Mikroelektronikk]]

IHP 130nm process

2020-03-30T08:10:28Z

Nfyku:

=Cadence design with IHP 130nm process=

==Starting up the IHP SG13S Design Kit==

The following steps describe how to install the Process Design Kit and start a new design.

Log on to the mikroserver:
ssh -X mikroserver4

The preferred shell is bash. When using another shell it will be necessary to change the installation routine and modify the initialization script accordingly.

The '''first time''' you are using the IHP design kit you should copy the user environment design to your chosen parent directory (e.g ~/ihp)
cp -rp /eda/design_kits/ihp_sg13/SG13S_617_rev1.10.1/work/skel ~/ihp

Change sh.cadence in ~/ihp/cds to suit your needs. In particular you must define $IHP_TECH and $PROJECT according to your local environment. Then set general and user Cadence environment variables by doing:
source /eda/cadence/2018-19/scripts/analog.sh
cd ~/ihp/cds/
source sh.cadence
virtuoso &

To avoid having to do this every time try to set up your environment like described in [[MikroserverSetup]]

Follow the Design Kit User manual found in the menu SG13S Features > Design Kit Documentation. Make sure that your web browser is closed or started from the microserver, else the file will not be found.

[[Category:Mikroelektronikk]] [[Category:Integrated_Circuts]] [[Category:Cadence_Virtuoso]]