Modelowanie i analiza systemów

Modelowanie i analiza

systemów

Dariusz Badura

Zakład Modelowania i Grafiki

Komputerowej

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 ?

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.

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.

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

carry

ARCHITECTURE behave OF halfadd IS
BEGIN
sum <= a XOR b;
carry <= a AND b;
END behave;

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

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;

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 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;

Document Outline