Profibus

Profibus

Profibus DP - VHDL BUS Model
The main intention of this document is to describe VHDL formal model of the Profibus
DP fieldbus. Document has four primary objectives:
1. Basic description of the new model of the Profibus DP physical layer - i.e. model
based on telegram or bit oriented communication bus.
2. Description of the models of communication entities based on a wire medium.
3. Description of the models of communication entities based on a wireless medium.
4. Description of the configurations for purpose of simulations.

Structure of the model

- Specification of the Devices
Every Profibus DP Master/Slave device, except Wireless Station, is described by three
different VHDL entities:
1. Application entity - chapter 4.1
2. Communication entity - chapter 4.2
3. Link & Physical layer entity - chapter 4.3
Wireless Station is described by the same Application and Communication entities,
however Link & Physical entity is different (due to wireless medium) and the entity is
described in the chapter 4.12.
- Specification of the Equipments
Specification of the communication equipments consists of several VHDL models:
1. Telegram Monitor - chapter 4.4
2. UART Monitor - chapter 4.5
3. UART EMI - chapter 4.6
4. Telegram Repeater - chapter 4.7
5. UART Repeater - chapter 4.8
6. Link Station - chapter 4.9
7. Base Station - chapter 4.10
8. Link Base Station - chapter 4.11
9. Wireless Station - chapter4.12
10. Wireless EMI - chapter 4.13
-Description of the model
-Application entity
Application entity has two different models with two different architectures:
1. DpMasterAppl - for Master Application module; 4.1.1
2. DpSlaveAppl - for Slave Application module; 4.1.2

-DP Master Application - DpMasterAppl
Master Application entity consists of the one process called MasterState. State machine of
this process is shown in Fig. 3. Master is in the state STOP at the beginning. Once the
message with OK status is received, i.e. RxA(2) = 00h, the master enter the CLEAR state and
it attempts to parameterize and configure its slaves. Once OK message is received again, the
master enter the OPERATE state and it is in user data operation with the slave(s).

-DP Slave Application - DpSlaveAppl
Implementation of the DpSlaveAppl architecture is not realized.

-Communication entity
Communication entity has two different models with two different architectures:
1. DpMasterComm - for Master Communication module; 4.2.1
2. DpSlaveComm - for Slave Communication module; 4.2.2

-DP Master communication - DpMasterComm
Master communication architecture is an interface for Master device between DpDll2.dll
executable library and VHDL model. It consists of 4 processes:
1. AppProc - trigged by TxA event; then it calls function estDpMasterCommEnq with
appropriate message (TxA) from the Application model (DpMasterAppl). If the call is
successful then AppProc starts the MainProc.
2. busIndProc - trigged by busIndFlg event; then it calls function estDpMasterCommEnq
with appropriate busIndType and busIndPar messages. If the call is successful then
busIndProc starts the MainProc.
3. fmCnfProc - trigged by fmCnfFlg; then it calls function estDpMasterCommEnq with
appropriate fmCnfPar message. If the call is successful then busIndProc starts the
MainProc.
4. MainProc - trigged by any of AppProc, busIndProc or fmCnfProc processes; then it
calls ddl function estDpMasterCommAct.

-DP Slave communication - DpSlaveComm
Slave communication architecture is an interface for Slave device between DpDll2.dll
executable library and VHDL model. It consists of 4 processes:
1. AppProc - trigged by TxA event; then it calls dll function estDpSlaveCommEnq with
appropriate message (TxA) from the Application model (DpSlaveAppl). If the call is
successful then AppProc starts the MainProc.
2. busIndProc - trigged by busIndFlg event; then it calls dll function
estDpSlaveCommEnq with appropriate busIndType and busIndPar messages. If the
call is successful then busIndProc starts the MainProc.
3. fmCnfProc - trigged by fmCnfFlg; then it calls dll function estDpSlaveCommEnq with
appropriate fmCnfPar message. If the call is successful then busIndProc starts the
MainProc.
4. MainProc - trigged by any of AppProc, busIndProc or fmCnfProc. Then process calls
ddl function estDpMasterCommAct.

Status

- status1
- status2