Modelowanie i analiza
systemów
Dariusz Badura
Zakład Modelowania i Grafiki
Komputerowej
Plan wykładu
• Pojęcie modelowania
• Znaczenie modelowania
• Symulacja
• Prototyp
• Zakres tematów wykładu
Model
Żyjemy w świecie modeli często nie wiedząc o
tym.
O czymkolwiek myślimy, mówimy, zawsze mamy
na myśli pewne nasze wyobrażenie
rzeczywistości fizycznej i / lub
symbolicznej,
czyli jej model.
Model do realnego systemu ma się tak jak mapa
do terenu, a do tego w naszej głowie są same
takie ‘mapy’ świata w którym żyjemy zamiast
rzeczywistego ‘terenu’.
Czym jest model systemu ?
System jest to byt przejawiający
egzystencję przez synergiczną
interakcję swych elementów, system
działa w
czasie i w przestrzeni.
Czym jest model systemu ?
Model systemu jest uproszczoną
reprezentacją systemu, w czasie i
przestrzeni, stworzoną w zamiarze
zrozumienia zachowania systemu
rzeczywistego [Principia].
Modele, z którymi mamy do czynienia w życiu i
pracy mogą być rzeczywiste – fizyczne, jak np. w
skali 1 : 10, i
modele abstrakcyjne.
Modele abstrakcyjne można podzielić na dwie
klasy;
jakościowe (opisowe i wyjaśniające) i
ilościowe – prognostyczne.
Prototyp
Prototyp to urządzenie, obwód lub program
zaprojektowany i zbudowany w celu
zademonstrowania zdolności do budowy
urządzenia docelowego. Podczas budowy
prototypu wprowadzają pierwszy raz w życie
swoje nowe pomysły. Jeżeli uda się zbudować
prototyp i on działa, to można przystąpić do
budowy finalnego urządzenia.
Prototypowanie to proces budowy prototypu.
Często jest on bardzo kosztowny, ponieważ
urządzenie wykonywane jest w skali
jednostkowej.
Modelowanie systemów
dla podejmowania
decyzji
• Kompleksową dziedziną nauki związaną ściśle z
teorią podejmowania decyzji są badania
operacyjne
• ... umożliwiają za pomocą modeli matematyczno-
ekonomicznych praktyczne wyznaczenie metodyki
rozwiązywania ściśle określonych problemów
związanych z podejmowaniem optymalnych
decyzji w różnych, konkretnych sytuacjach.
Metody
• Metody stosowane w modelowaniu skupiają się na
porównaniu efektywności różnych sposobów
rozwiązywania zagadnień i poszukiwania rozwiązania
optymalnego, pozwalają przeanalizować wybrany wycinek
rzeczywistości oraz ocenić ilościowo rezultaty możliwych
do podjęcia decyzji.
• Przy analizie możliwych skutków działania systemu
uwzględniane są takie czynniki, jak przypadkowość i
ryzyko.
Metody
• Do rozwiązywania tak złożonych
zagadnień angażuje się przedstawicieli
różnych specjalności (m.in. ekonomistów,
matematyków, statystyków, inżynierów,
socjologów, psychologów), co przesądza
o kompleksowym, systemowym podejściu
do rozwiązywanych problemów.
Dziedziny zastosowań – 1
• Modelowanie systemów jest stosowane przy
rozwiązywaniu problemów projektowych oraz
diagnostycznych, w w całym cyklu życia systemu.
• Rozwój techniki i technologii informatycznych, coraz
bardziej komplikujący powiązania między
elementami systemów programowania i ich
funkcjonowanie, wzmaga zapotrzebowanie na
metody analizy i obiektywnej oceny efektywności
pracy, testowania i eliminacji błędów, oceny
skuteczności testowania i niezawodności.
Dziedziny zastosowań – 2
• Modelowanie systemów jest również szczególnie
często stosowane przy rozwiązywaniu problemów
gospodarczych, w tym produkcyjnych.
• Rozwój techniki i technologii, coraz bardziej
komplikujący powiązania między elementami
systemów produkcyjnych i ich funkcjonowanie,
wzmaga zapotrzebowanie na metody analizy i
obiektywnej oceny decyzji podejmowanych w
szeroko rozumianym planowaniu i zarządzaniu
działalnością biznesową.
Dziedziny zastosowań – 3
• Każda działalność, w tym szczególnie działalność
gospodarcza, związana jest z określonymi celami,
których osiągnięcie wymaga posiadania określonych
środków.
• Środki te bardzo często są ograniczone i mogą być
użyte w różny sposób, o czym przesądzają
konkretne warunki, w jakich prowadzona jest
działalność (techniczne, organizacyjne, prawne itp.).
• W działalności gospodarczej powstaje zawsze
problem podjęcia decyzji dotyczącej sposobu
zastosowania rozporządzalnych środków i zasobów
oraz realizacji zamierzonego celu.
Etapy budowy modelu i
analizy
• sformułowanie zagadnienia,
• budowę modelu matematycznego opisującego
rozwiązywany problem (lub jego wybór),
• rozwiązanie modelu polegające na określeniu
najlepszej w danych warunkach decyzji,
• weryfikację modelu i uzyskanego rozwiązania
oraz dokonanie ewentualnych poprawek,
• podjęcie decyzji i opracowanie systemu
kontroli bądź sterowania.
Sformułowanie
zagadnienia
• opis słowny wybranego fragmentu
rzeczywistości
Budowa modelu
matematycznego opisującego
rozwiązywany problem
• „przetłumaczenie” opisu na język
matematyczny,
• uwzględnienie wszystkich
istotnych aspektów
• pominięcie pozostałych,
• często powstaje pewien problem
programowania matematycznego
Rozwiązywanie modelu
• wyznaczenie rozwiązania optymalnego
• do rozwiązania modelu używa się m.in. metod
programowania matematycznego, programowania
dynamicznego, rachunku prawdopodobieństwa,
teorii gier, statystyki matematycznej itd.
• do wyboru decyzji optymalnej potrzebne jest
posłużenie się odpowiednim kryterium, za pomocą
którego można ocenić i porównać skutki podjęcia
poszczególnych decyzji.
Weryfikacja modelu
• konfrontacja z rzeczywistością i ocena
uzyskanego rozwiązania tzn. czy spełnia
wszystkie wymagane warunki występujące
warunki
• kontrolę mającą zapewnić dopływ informacji
wpływających na ewentualne zmiany optymalnej
decyzji, jak również umożliwiać wprowadzenie
korekt decyzji w przypadku zmian różnych
czynników wpływających na optymalną decyzję.
Zakres tematyczny
wykładu
• Pojęcie modelowania
• Modelowanie sprzętu i oprogramowania. Modelowanie
procesów współbieżnych
• Języki opisu sprzętu: zakres opisu sprzętu i
oprogramowania.
• Modelowanie procesów diagnostycznych sprzętu:
modelowanie uszkodzeń, modelowanie stochastyczne
• Język UML – modelowanie systemu,
• Modelowanie biznesowe.
• Metody testowania oprogramowania. Modelowanie
testowania systemu.
• Modelowanie błędów oprogramowania
• Modele stochastyczne procesów informatycznych:
• model transmisji, model diagnostyczny,
• Metody analizy systemów informatycznych,
wymiarowanie aplikacji.
Język VHDL
(skrót pochodzi od dwóch innych skrótów: V - Very
High Speed Integrated Circuit oraz HDL -
Hardware Description Language)
... rozwijany był na początku lat 80-tych do opisu
niezależnych metod opisywania układów elektronicznych
przez American Department of Defence (ang. DoD). Po raz
pierwszy został zestandaryzowany w roku 1983, a następnie
standaryzację powtórzono w latach 1987 oraz 1993.
Główne cechy języka VHDL to:
• równoległość przejawiająca się w możliwości zdefiniowania
potrzeby oraz wykonywania równoległego przetwarzania
różnych porcji informacji,
• strukturalność oznaczająca możliwość hierarchicznego
opisywania projektów. W opisie hierarchicznym projekt
zbudowany jest z połączonych bloków o mniejszym stopniu
złożoności, które z kolei zbudowane są z prostszych bloków,
które zawierają w sobie jeszcze prostsze bloki i tak dalej aż
dochodzimy do bloków podstawowych, którymi np. w
przypadku
układów
cyfrowych
są
bramki
logiczne.
Strukturalność oznacza możliwość opisu sprzętu od poziomu
systemu do poziomu bramki,
Język VHDL
• "redesign" - typowy projekt cyfrowego układu elektronicznego
zawiera w sobie do 80% fragmentów z innych projektów. Nowe
projekty nie powstają w pustce. Projektanci wykorzystują
poprzednio zdobyte doświadczenia przenosząc opracowane i
poznane uprzednio rozwiązania do nowych projektów. Proces
ten określa się pochodzącym z języka angielskiego słowem
redesign,
• możliwość wykonywania instrukcji sekwencyjnie (czyli w
sposób przeciwstawny do wykonywania równoległego)
oznaczająca możliwość definiowania czynności wykonywanych
jedna po drugiej, w sposób analogiczny jak w tradycyjnych
językach programowania,
• zdolność do jednolitego opisywania struktury układów
zbudowanych w oparciu o różne technologie stwarzająca
możliwość przenoszenia projektów pomiędzy różnymi
platformami sprzętowymi,
• możliwość symulowania projektowanych układów; możliwość
tworzenia sekwencji sygnałów testujących. Istnieje możliwość
wbudowania sygnałów testowych w projekt,
• "samodokumentowanie" osiągnięte dzięki prostej i przejrzystej
strukturze,
• modelowanie układów z uwzględnieniem upływającego czasu.
Predefiniowane typy
• BOOLEAN przyjmuje jedną z dwóch wartości:
FALSE lub TRUE,
• BIT jest równe '1' lub '0',
• BIT_VECTOR ciąg wartości typu BIT np.
"000000", "01101". Można użyć do modelowania
magistral,
• CHARACTER umożliwia używanie znaków
alfanumerycznych np. 'a', 'X',
• STRING definiuje ciągi znaków np. "ABCD",
"012ws„
• INTEGER reprezentuje liczby całkowite,
• REAL umożliwia zapis liczb zmiennopozycyjnych
Logika wielowartościowa
Logika wielowartościowa posiada więcej typów niż tylko zero i
jedynka logiczna. Pakiet Std_Logic_1164 wchodzący w skład
języka VHDL zawiera definicję typów std_logic (typ
"resolved") oraz std_ulogic (typ "unresolved") o następujących
wartościach wraz z operującymi na nich funkcjami:
•'U' - wartość nigdy dotychczas nie została
określona,
•'X' - wartość była znana ale aktualnie nie można
podać jej konkretnej wartości; sygnał "strong
drive",
•'0' - sygnał logicznego 0 typu "strong drive",
•'1' - sygnał logicznej 1 typu "strong drive",
•'Z' - stan wysokiej impedancji; sygnał nie posiada
"driver"-a,
•'W' - wartość była znana ale aktualnie nie można
podać jej konkretnej wartości; sygnał "weak drive";
rzadko używany,
•'L' - sygnał logicznego 0 typu "weak drive",
•'H' - sygnał logicznej 1 typu "weak drive",
•'-'
- wartość sygnału nie ma znaczenia.
Logika wielowartościowa
Pakiet zawiera również definicje typów
Std_logic_vector oraz Std_ulogic_vector.
Pakiet Std_logic zawarty jest w bibliotece IEEE.
Poniższe instrukcje czynią elementy zdefiniowane w
pakiecie Std_logic dostępnymi w projekcie:
library IEEE;
-- Uczyń
bibliotekę dostępną
use IEEE.Std_Logic_1164.all; -- Całość
biblioteki dostępna
Jest możliwe podstawianie elementów typu
std_ulogic do std_logic i vice-versa.
Deklaracja komponentu
Format deklaracji portu
entity NAME_OF_ENTITY is [ generic
generic_declarations);]
port (signal_names: mode type;
signal_names: mode type;
:
signal_names: mode type);
end [NAME_OF_ENTITY] ;
Tryby portów
mode: is one of the reserved words to
indicate the signal direction:
• in – indicates that the signal is an input
• out – indicates that the signal is an
output of the entity whose value can only
be read by other entities that use it.
• buffer – indicates that the signal is an
output of the entity whose value can be
read inside the entity’s architecture
• inout – the signal can be an input or an
output.
Typy portów
• bit – can have the value 0 and 1
• bit_vector – is a vector of bit values (e.g.
bit_vector (0 to 7)
• std_logic, std_ulogic, std_logic_vector,
std_ulogic_vector: can have 9 values to indicate
the value and strength of a signal. Std_ulogic
and std_logic are preferred over the bit or
bit_vector types.
• boolean – can have the value TRUE and FALSE
• integer – can have a range of integer values
• real – can have a range of real values
• character – any printing character
• time – to indicate time
Generic
•deklaracja generic jest opcjonalna i określa
lokalne stałe używane do opisu czasu i rozmiaru
(np.. wielkość magistrali) wewnątrz komponentu.
Generic może mieć wartość domyślną.
•Składnia deklaracji generic:
generic (
constant_name: type [:=value] ;
constant_name: type [:=value] ;
:
constant_name: type [:=value] );
Przykłady deklaracji
ENTITY
entity mux4_to_1 is
port (I0,I1,I2,I3: in std_logic_vector(7 downto 0);
SEL: in std_logic_vector (1 downto 0);
OUT1: out std_logic
_vector(7 downto 0));
end mux4_to_1;
entity dff_sr is
port (D,CLK,S,R: in std_logic;
Q,Qnot: out std_logic
);
end dff_sr;
Deklaracja multipleksera
Deklaracja przerzutnika
Deklaracja ciała
komponentu
architecture architecture_name of NAME_OF_ENTITY is
-- Declarations
-- components declarations
-- signal declarations
-- constant declarations
-- function declarations
-- procedure declarations
-- type declarations
:
begin
-- Statements
:
end architecture_name;
Komponenty
ENTITY halfadd IS
PORT ( a,b : IN BIT;
sum, carry : OUT BIT);
END halfadd;
halfadd
sum
a
b
carry
ARCHITECTURE behave OF halfadd IS
BEGIN
sum <= a XOR b;
carry <= a AND b;
END behave;
Reprezentacje opisów
układu
Przykład
architecture behavioral of BUZZER is
begin
WARNING <= (not DOOR and IGNITION)
or (not SBELT and IGNITION);
end behavioral;
entity BUZZER is
port (DOOR, IGNITION, SBELT: in std_logic;
WARNING: out std_logic);
end BUZZER;
Modelowanie
behawioralne
architecture behavioral of BUZZER is
begin
WARNING <= (not DOOR and IGNITION)
or (not SBELT and IGNITION);
end behavioral;
Modelowanie
behawioralne
entity AND2 is
port (in1, in2: in std_logic;
out1: out std_logic);
end AND2;
architecture behavioral_and2 of AND2 is
begin
out1 <= in1 and in2;
end behavioral_2;
entity XNOR2 is
port (A, B: in std_logic;
Z: out std_logic);
end XNOR2;
architecture behavioral_xnor of XNOR2 is
-- signal declaration (of internal signals X, Y)
signal X, Y: std_logic;
begin
X <= A and B;
Y <= (not A) and (not B);
Z <= X or Y;
End behavioral_xnor;
Modelowanie strukturalne
architecture structural of BUZZER is
-- Declarations
component AND2
port (in1, in2: in std_logic;
out1: out std_logic);
end component;
component OR2
port (in1, in2: in std_logic;
out1: out std_logic);
end component;
component NOT1
port (in1: in std_logic;
out1: out std_logic);
end component;
-- declaration of signals used to interconnect gates
signal DOOR_NOT, SBELT_NOT, B1, B2: std_logic;
begin
-- Component instantiations statements
U0: NOT1 port map (DOOR, DOOR_NOT);
U1: NOT1 port map (SBELT, SBELT_NOT);
U2: AND2 port map (IGNITION, DOOR_NOT, B1);
U3: AND2 port map (IGNITION, SBELT_NOT, B2);
U4: OR2 port map (B1, B2, WARNING);
end structural;
Modelowanie strukturalne
label: component-name port map (port1=>signal1, port2=> signal2,… port3=>signaln);
U0: NOT1 port map (in1 => DOOR, out1 => DOOR_NOT);
U1: NOT1 port map (in1 => SBELT, out1 => SBELT_NOT);
U2: AND2 port map (in1 => IGNITION, in2 => DOOR_NOT, out1 => B1);
U3: AND2 port map (in1 => IGNITION, in2 => SBELT_NOT, B2);
U4: OR2 port map (in1 => B1, in2 => B2, out1 => WARNING);
Przykład podejścia
hierarchicznego
dla sumatora 4-bitowego
Przykład podejścia
hierarchicznego
library ieee;
use ieee.std_logic_1164.all;
-- definition of a full adder
entity FULLADDER is
port (a, b, c: in std_logic;
sum, carry: out std_logic);
end FULLADDER;
architecture fulladder_behav of FULLADDER is
begin
sum <= (a xor b) xor c ;
carry <= (a and b) or (c and (a xor b));
end fulladder_behav;
-- 4-bit adder
library ieee;
use ieee.std_logic_1164.all;
Przykład podejścia
hierarchicznego
entity FOURBITADD is
port (a, b: in std_logic_vector(3 downto 0);
Cin : in std_logic;
sum: out std_logic_vector (3 downto 0);
Cout, V: out std_logic);
end FOURBITADD;
architecture fouradder_structure of FOURBITADD is
signal c: std_logic_vector (4 downto 0);
component FULLADDER
port(a, b, c: in std_logic;
sum, carry: out std_logic);
end component;
begin
FA0: FULLADDER
port map (a(0), b(0), Cin, sum(0), c(1));
FA1: FULLADDER
port map (a(1), b(1), C(1), sum(1), c(2));
FA2: FULLADDER
port map (a(2), b(2), C(2), sum(2), c(3));
FA3: FULLADDER
port map (a(3), b(3), C(3), sum(3), c(4));
V <= c(3) xor c(4);
Cout <= c(4);
end fouradder_structure;
Pakiety – zakres dostępu
Deklaracja pakietu
deklaracja pakietu = package identyfikator is
część_deklaracyjna_pakietu
end [package] [nazwa pakietu];
część_deklaracyjna_pakietu : deklaracja podprogramu,
deklaracja typu, deklaracja podtypu, condeklaracja stałej,
deklaracja sygnału, deklaracja zmiennej dzielonej,
deklaracja składnika, deklaracja pliku, deklaracja aliasu,
deklaracja atrybutu, specyfikacja atrybutu, specyfikacja rozłączenia,
use_clause, deklaracja wzorca grupy, deklaracja grupy
Deklaracja pakietu
ciało pakietu = package body nazwa pakietu is
część deklaracyjna ciała pakietu
end [package body ] [nazwa pakietu] ;
część_deklaracyjna_ciała_pakietu : deklaracja podprogramu,
deklaracja ciała podprogramu, deklaracja typu, deklaracja podtypu,
condeklaracja stałej, deklaracja zmiennej dzielonej, deklaracja pliku,
deklaracja aliasu, use_clause, deklaracja wzorca grupy, deklaracja grupy
Zakres dostępu pakietu
...Używany w wielu projektach poprzedzone
wywołaniem pakietu
Biblioteki projektów - zakres dostępu
Nazwa ciała pakietu taka sama jak nazwa deklaracji
pakietu
Każdy element biblioteki musi być zweryfikowany
poprzez analizator.
W bibliotece może być tylko jedna deklaracja
jednostki projektowej i wiele ciał architektonicznych
Klauzula biblioteczna : library lista nazw bibliotek , -
dostęp do biblioteki
Klauzula dostępu : use nazwa wybrana[nazwa
wybrana,] – dostęp do elementów biblioteki
Proces
Instrukcje
wykonują się
sekwencyjnie
wówczas gdy
zostaną
umieszczone
wewnątrz procesu.
MUX: process (A, B, SEL)
begin
if SEL = '1' then
Z <= A;
else
Z <= B;
end if;
end process MUX;
[process_label:] process [ (sensitivity_list) ] [is]
[ process_declarations]
begin
list of sequential statements such as:
signal assignments
variable assignments
case statement
exit statement
if statement
loop statement
next statement
null statement
procedure call
wait statement
end process [process_label];
Proces
Przykład przerzutnika D wyzwalanego przednim
zboczem.
library ieee;
use ieee.std_logic_1164.all;
entity DFF_CLEAR is
port (CLK, CLEAR, D : in std_logic;
Q : out std_logic);
end DFF_CLEAR;
architecture BEHAV_DFF of DFF_CLEAR is
begin
DFF_PROCESS: process (CLK, CLEAR)
begin
if (CLEAR = ‘1’) then
Q <= ‘0’;
elsif (CLK’event and CLK = ‘1’) then
Q <= D;
end if;
end process;
end BEHAV_DFF;
Proces
Instrukcje wewnątrz
procesu wykonywane są
sekwencyjnie - "jedna po
drugiej".
Definicja procesu musi
znajdować się w ciele
architektury. Wewnątrz
architektury może
znajdować się dowolna
liczba procesów:
architecture A of E is
begin
-- concurrent statements
P1 : process
begin
-- sequential statements
end process P1;
-- concurrent statements
P2 : process
begin
-- sequential statements
end process P2;
-- concurrent statements
end A;
Instrukcje sekwencyjne
• instrukcja oczekiwania
• instrukcja założenia
• instrukcja raportu
• instrukcja jeżeli
• instrukcja przypadku
• instrukcja pętli
• instrukcja następna
• instrukcja powrotu
• instrukcja pusta
• instrukcja przypisania sygnału
• instrukcja przypisania zmiennej
• instrukcja wywołania procedury
Instrukcje sekwencyjne mogą być poprzedzone etykietą
Zawieszanie wykonania
procesu
Zawieszanie wykonania procesu oznacza
wstrzymanie jego wykonania na określony czas lub
do czasu zmiany wartości określonych sygnałów.
Występują dwa style zawieszania wykonania
procesu w oczekiwaniu na zmiany sygnałów.
Pierwszy wykorzystuje listę inicjalizacyjną:
process (A,B)
begin
if (A='1' or B='1') then
Z <= '1';
else
Z <= '0';
end if;
end process;
process
begin
if (A='1' or B='1') then
Z <= '1';
else
Z <= '0';
end if;
wait on A, B;
end process;
Instrukcja oczekiwania
[etykieta:] wait [sekcja warunku] [sekcja czułości]
[sekcja czasu]
sekcja warunku := until warunek logiczny
sekcja czułości := on lista czułości
lista czułości := nazwa sygnału [nazwa sygnału,]
sekcja czasu := for wyrażenie czasu
process(lista czułości)
Proces posiadający listę aktywacyjną nie może
posiadać instrukcji wait.
Instrukcja wait
Proces wznawia wykonanie po określonym w
instrukcji wait for czasie.
STIMULUS: process
begin
SEL <= '0';
BUS_B <= "0000";
BUS_A <= "1111";
wait for 10 ns;
SEL <= '1';
wait for 10 ns;
-- etc, etc
end process STIMULUS;
Instrukcja wait on
wstrzymuje wykonanie w
oczekiwaniu na zmianę
wartości sygnałów
(zdarzenie zachodzące na
sygnałach)
wyspecyfikowanych w
liście.
process
begin
wait until CLK='1';
Q <= D;
end process;
Instrukcja wait
Instrukcja wait wstrzymuje proces na zawsze. Po
wykonaniu instrukcji wait proces nie zostanie nigdy
wznowiony
STIMULUS: process
begin
SEL <= '0';
BUS_B <= "0000";
BUS_A <= "1111";
wait for 10 ns;
SEL <= '1';
wait;
end process STIMULUS;
Instrukcja założenia
assert
instrukcja_założenia:= [etykieta:] założenie;
założenie:= assert warunek [raport wyrażenie]
[severity wyrażenie]
Poziomy ważności (SEVERITY LEVEL):
NOTE
– notatka
WARNING – ostrzeżenie
FAILURE – błąd
ERROR
– błąd krytyczny
W przypadku, gdy w instrukcji założenia nie
występuje poziom ważności komunikatu, przyjmuje
się, że jest równy ERROR
Instrukcja raportu report
instrukcja_raportu:= [etykieta:] report wyrażenie [severity wyrażenie]
Instrukcja warunkowa if
if CONDITION then
-- sequential statements
end if;
if CONDITION then
-- sequential statements
else
-- sequential statements
end if;
Wykonanie jednej z kilku grup instrukcji
możliwe jest za pomocą instrukcji if w
postaci:
if CONDITION1 then
-- sequential statements
elsif CONDITION2 then
-- sequential statements
elsif CONDITION3 then
-- sequential statements
else
-- sequential statements
end if;
process (A, B, C, X)
begin
if (X = "0000") then
Z <= A;
elsif (X <= "0101") then
Z <= B;
else
Z <= C;
end if;
end process;
Przykład:
Instrukcja case
case OBJECT is
when VALUE_1 =>
-- statements
when VALUE_2 =>
-- statements
when VALUE_3 =>
--statements
--etc...
end case;
W instrukcji case każda możliwa
wartość obiektu MUSI ZOSTAĆ
WYSPECYFIOWANA i musi być
wyspecyfikowana TYLKO JEDEN
RAZ.
process (A, B, C, X)
begin
case X is
when 0 to 4 =>
Z <= B;
when 5 =>
Z <= C;
when 7 | 9 =>
Z <= A;
when others =>
Z <= 0;
end case;
end process;
Podstawowa instrukcja
pętli loop
[ loop_label :] loop
sequential statements
[next [label] [when condition];
[exit [label] [when condition];
end loop [ loop_label];
Przykład licznika 0 – 31
entity COUNT31 is
port ( CLK: in std_logic;
COUNT: out integer);
end COUNT31;
architecture behav_COUNT of COUNT31 is
begin
P_COUNT: process
variable intern_value: integer :=0;
begin
COUNT <= intern_value;
loop
wait until CLK=’1’;
intern_value:=(intern_value + 1) mod 32;
COUNT <= intern_value;
end loop;
end process P_COUNT;
end behav_COUNT;
Instrukcja pętli while
loop
[ loop_label :] while condition loop
sequential statements
[next [label] [when condition];
[exit [label] [when condition];
end loop[ loop_label ];
Instrukcja pętli for
[ loop_label :] for identifier in range loop
sequential statements
[next [label] [when condition];
[exit [label] [when condition];
end loop[ loop_label ];
for I in 0 to 3 loop
-- statements
end loop;
Przykład pętli for loop
entity EX is
port (A : in std_ulogic_vector(0 to 15);
SEL : in integer range 0 to 15;
Z : out std_ulogic);
end EX;
architecture RTL of EX is
begin
WHAT: process (A, SEL)
begin
for I in 0 to 15 loop
if SEL = I then
Z <= A(I);
end if;
end loop;
end process WHAT;
end RTL;
Instrukcja wyjścia exit
exit [label] [when condition];
Instrukcja następna next
next [label] [when condition];
Instrukcja powrotu
instrukcja_powrotu:= [etykieta] return [wyrażenie];
Instrukcja powoduje zakończenie wykonania
najbardziej zagnieżdżonego podprogramu.
Może być użyta tylko w ciele procedury lub funkcji.
Instrukcja powrotu występująca w procedurach nie
może posiadać zadeklarowanego wyrażenia, tzn. nie
może zwracać wartości.
Instrukcja pusta
instrukcja_pusta := [etykieta:] null ;
Instrukcja pusta nic nie wykonuje.
case a is
when 0 => null;
when others => a := a mod 2;