Eindhoven University of Technology

MASTER

The development of bitbus firmware and the accessory VME/ERM bitbus driver for thedDCM804 bitbus board

Boonen, P.E.J.

Award date:1988

Link to publication

DisclaimerThis document contains a student thesis (bachelor's or master's), as authored by a student at Eindhoven University of Technology. Studenttheses are made available in the TU/e repository upon obtaining the required degree. The grade received is not published on the documentas presented in the repository. The required complexity or quality of research of student theses may vary by program, and the requiredminimum study period may vary in duration.

General rightsCopyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright ownersand it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights.

• Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain

53/9

Eindhoven University of TechnologyDepartment of Electrical Engineering

Digital Systems Group (EB)

The development of BitbllS firmwareand the accessory

VMEIERM BitbllS driverfor the dDCM804 BitbllS board

P.EJ. BoonenPhilips CFT CAM-Centre

Keywords: Software design, Structureel analysis, Structureel design, Yourdon,ProMod, Bitbus, \'TS, VMEbus, DATEM dDCM804

Master thesis reportCoaches: Prof. Ir. M.PJ. Stevens, Eindhoven University of Technology

Ir. MJ.M van Weert, Eindhoven University of technologyIr. G.J. Brouwhuis, Philips CFf CAM-CentreM.G. Cur1ey B.E., Philips CFf CAM-Centre

Eindhoven, The NetherlandsAugust 1988

The departrnent of Electrical Engineering of the Eindhoven University of Technology does notaccept any responsibility regarding the contents of student projeets and graduation reports.

E8 1:1:5

Summary

This document describes the analysis, design and implementation of the finnware and driverfor a Bitbus - VMEbus host interface. The Bitbus driver is specially adapted for use with thePhilips VariabIe Transport System. The DATEM dDCM804 interface board was used for thehardware. The finnware is completely finished and tested while the analysis of the driver ispartially finished. The design, coding and testing of the driver must still he done. During thedevelopment, a struetured analysis and StIUctured design method was used. The tooI ProModwas used which supports this method.

- 1 -

Acknowledgements

I would like to thank Prof. Ir. M.PJ. Stevens and Ir. M.J.M. van Ween of the EindhovenUniversity of Technology for their suppon of my graduation project. Also I would offer myspecial thanks to Ir. GJ. Brouwhuis, M.G. Curley RE., Ir. A. van der Pol, A. van der Klooster,Ir. JJ.AJ. Beukeboom, Ir. J.G. van den Hanenberg, Ir. S. Voogt, and all other members ofthe TAM department for their suppon and friendship. I learned a lot during my time spent atthe CAM-Centre and I enjoyed it very much.

Piet Boonen

- III -

Contents

1 Introduction

2 Specification and background2.1 CAM Reference Model .2.2 Hardware and software environment2.3 Logical systems interconnect model .2.4 Network and transport Layer .

2.4.1 Dataflow model .2.4.2 Error recovery and power up2.4.3 Bitbus message format.

2.5 Datalink 1ayer .....2.5.1 Polling scheme2.5.2 Frame format

2.6 Workload distribution2.6.1 Interface to the VMEbus

3 Software development3.1 Software deve10pment phases3.2 Stnletured analysis . . . . . .

3.2.1 Flow diagrams ....3.2.2 State transition diagrams.3.2.3 Data dietionary ...3.2.4 Textual specifications3.2.5 Assistance of ProMod

3.3 Modular design .3.3.1 Assistance of ProMod

3.4 Pseudo code . . . . . . . . .

4 Bitbus firmware4.1 User requirements .

4.1.1 Hardware of the DCM804 board4.1.2 Use of a multi-tasking kemel4.1.3 Control of the datalink 1ayer .

4.2 Analysis . . . . . . . . . . . . . . .4.2.1 Use of a pipeline architecture

- v -

1

557899

11121313141617

1919212123242425272729

31313135363637

4.2.2 Synchronization with the slave 374.2.3 Interfacing with the VMEbus . 394.2.4 Interfacing with the serial line . 39

4.3 Modular design 404.4 Pseudo code . . . . . . . . . . . . . . 41

4.4.1 Synchronization between mam program and intenupt handlers . 424.5 Coding and testing . . . . . 42

4.5.1 Modular test phases 434.5.2 Test results . 46

5 ERM Bitbus driver

6 Results and recommendations

References

Glossary

A Predefined Bitbus messagesA.l Messages from Bitbus-handler to applicationA.2 Orders to the Bitbus-handler. . . . . . . . .

B Jumpers on the dDCM804 board

C Register map on VME side

D Differences between Intel Bitbus and VTS Bitbus

E Analysis report of firmware

- Vi -

47

51

53

57

616162

67

69

71

73

·Chapter 1

Introduction

At the Centre For manufacturing Technology (CPT), Philips does research to new ways ofproducing products. Within the CFT the automation of factories by means of computers isstudied by the CAM-Centre. The objectives of the Computer Aided Manufacturing Centre(CAM-Centre) [12, page 5] are:

1. The gathering, maintenance and application of knowledge and expertise in the field ofComputer Aided Manufacturing.

2. The promotion of co-ordination and standardization in this field.

3. The stimulation of a professional approach to technical and organisational problems inlocal CAM centres in the factories.

4. The promotion of integration between CAM and CAD systems.

The CAM-Centre is divided in three main departments and some special groups. One ofthe main departments is: Technical Automation Means. The aims of this department [12, page12] are to develop and/or select the technical means and methods to create, implement andoperate efficient and cost-effective infrastruetures for industrial automated control, informationand communication systems by relating the state-of-the-art information technology to the goalsof Philips' manufacturing.

Within this department they developed a flexib1e transport system for factories, the VariableTransport System (VTS), see figure 1.1. 1t moves products and components on carriers throughthe factory. This system is now produced by Philips Machine Fabriek Alkmaar.

The Variable Transport System is a modular system, with each module having its ownintelligence. This intelligence is achieved with the help of a local transport controller attachedto each module. The overall supervision of the system is handled by a central computer,the so called routeing controller. This routeing controller communicates with the transportcontrollers by means of aserial communication line according to the Bitbus standard [11], seefigure 1.2. Until now this router was based on an IPC-51 single board computer, a Microvaxor a Multibus computer. In the furore this router may be based on a VMEbus computer.To make this possible, interface hard- and software are needed to connect the Bitbus to theVMEbus. The hardware for this connection [13] is sold off the shelf by the DATEM companyin Canada. They also developed software for this hardware, but the Bitbus protocol used at

- 1 -

RouteingController

Programmabie TrayHandling Module (PTM)

Va"able rranspor1Sy.tem (V1S)

Figure 1.1: The VariabIe Transport System

Bitbus connection

TransportController

# 1

TransportController

#2

Figure 1.2: vrs hardware configuration

- 2 -

Philips is slightly different from the Bitbus standard. For this reason Philips needs to developits own communication software, which is the subject of this project. The functionality ofthis communication software is the same as the functionality of the SLQ-8044 software [2]for connecting the Bitbus to a Microvax.

The project is split in two parts. The fust part is the development of the Bitbus finnware.This part of the software is executed by the local processor on the interface board and is storedin the onboard EPRüM. The second part is executed by the main processor on the VME buson top of the operating system and is called the Bitbus driver. During the development ofthe software the Yourdon method of sttuetured analysis and sttuctured design should be used.This method is supponed by the tooI ProMod. The project was also a test for the practical useof this method and tooI. The project was started in august 1987 and was finished in august1988.

- 3 -

Chapter 2

Specification and background

2.1 CAM Reference Model

The Variable Transport System is controlled by distributed Transport Controllers and a Route­ing Controller. These computers are only building bloeks in the total automation of factories.For this automation of factories, a model is developed at the CAM-Centre, the CAM Ref­erence Model [18, page 5-20], see figure 2.1. The routeing controller and the transportcontroller are only a small pan of this model. The model is a strictly hierarchical model withthe Factory controller at the top. Each controller in the hierarchy receives its orders fiom hissupervising controller one layer higher. Each controller gives his orders to its one or moresubordinate controllers or devices one layer lower. Responses are send back up the hierarchy.The functions of the controllers are:

Factory Controller The Factory Controller can be considered to be responsible for the op­timal use of capital by production in relation to other departments. This computer ishandling the long tenn (half a year) planning for the factories. This computer is notthe target of research done on the CAM-Centre.

Shop Controller The Shop Controller is responsible for the availability of products in stoek,so the workcell can use them. At this level orders for products are handled. Also thereis no research for this controller at the CAM-Centre.

Workcell Controller The Workcell Controller commands workstations to execute operationson certain products. Typically, it is the task of the Workcell Controller to deternrinewhat all its workstations should do, and hence which products should visit whichworkstation. The Workcell Controller also detennines the destination of a product thatis to be transported within the workcell.

Workstation Controller The Workstation Controller is responsible for making basic producttransfonnations. It has knowledge of products.

Automation Module Controller The Automation Module Controller can be ordered to bringthe product into a certain state e.g. a position at a certain place. It has knowledge ofequipment but no lcnowledge of products.

- 5 -

FactoryController

ShopController

WorkcellController

WorkstationController

RouteingController

AutomationModule

Controller

DeviceController

Device

AutomationModule

Controller

DeviceController

Device

TransportController

DeviceController

Device

TransportController

DeviceController

Device

Figure 2.1: CAM Reference Model.

- 6 -

Device Controller The Device Controller controls sensors and/or actuators. Sensors provideinfonnation about the product, actuators change the product in some way.

Routeing Controller The Routeing Controller has to take care of the transport of a prod­uct from source to destination by giving commands to the transport controllers. Itdetennines the path through the transport system.

Transport Controller The Transport Controller is responsibie for driving the mechanics ofone node of the transport system so that a product is transported to the subsequent node.This is done on command from the Routeing Controller.

This project is only involved in the communication between the Routeing Controller andthe Transport Controller.

2.2 Hardware and software environment

Physically the Variabie Transport System consists of a track on which product carriers move.The system is controlled by distributed microcontrollers based on the 8044 microprocessor[16] from Intel. All these controllers are under the control of the Routeing Controller. Thiscomputer can be given commands like "Move a product from source to destination". Thecomputer gives than more detailed commands to the microcontrollers. This commands aresent over aseria! multi-point link, the VTS-Bitbus, see figure 2.2.

Multi-point link

I I IDATEM Slave Slave

dDCM804 Controller ControllerMaster # 1 #2

VMEbus I Ibasedcomputer Device 1 Device 2

Figure 2.2: Hardware configuration of VTS Bitbus devices.

The computer that will be used as Routeing Controller will be a VMEbus based computerusing the ERM operating system [14]. The hardware interface between that VMEbus basedcomputer and the VTS-Bitbus is the dDCM804 Bitbus to VMEbus host adaptor. Whennecessary, more dDCM804 cards can be plugged in the VMEbus based computer. Everyboard can control one multi-point link with 32 slaves, increasing the capacity of the tota!network. The maximum number of links is 8 and the maximum number of slaves on the tota!network is 255.

- 7 -

The target of this work is building a software interface between application tasks on theVMEbus based computer (master) and application tasks on the slave computers. Only thecommunication software and firmware on the master node is developed in this project. Thissoftware and firmware should be able to communicate with VTS Slaves. The possibility ofcommunication at the same time with standard Intel Bitbus slaves should also be investigated.

Because of the hardware the software consist of two parts: The fumware on the dDCM804board and the software running under the ERM operating system on the VMEbus computer.Both parts together are called the Bitbus-Handler. The application tasks on the master interactwith the software under ERM and the slaves interaet with the firmware on the dDCM804.

2.3 Logical systems interconnect model

The model is partly based on the seven layer reference model for open system interconnection(OSI model) from the ISO [1, page 162-164], see figure 2.3. It is not a fu1l implementationof the model because only a subset of all the capabilities of the OSI model are needed. A fu1limplementation would slow down the system too much and not all layers are needed. Thepresentation and session layers are left out because there is no conversion of data needed andthere are no sessions to initiate or terminate.

VMEbus based master computer Slave computer

Application Application layer ApplicationTasks Tasks

Bitbus BitbusMessage Network & Transport layer MessageSttucture Sttueture

SDLC Datalink layer SDLCDriver Driver

RS-485 Physical layer RS-485Driver Driver

Multi-point link

Figure 2.3: The layers of VTS Bitbus.

• RS-485 is a Physical layer solution which supports multidrop configurations.

• SDLC is a datalink protocol which supports synchronous and asynchronous point-point,multi-point and loop configurations.

• The Bitbus message structure defines an orderjreply mechanism for communicationbetween tasks on the master node and tasks on the slave nodes.

- 8 -

2.4 Network and transport Layer

2.4.1 Dataflow model

Communication on the network and transport level takes place with the help of order and replymessages. Order messages are created by the application tasks on the VME computer. Thesemessages pass the Bitbus Handler and go to the slaves. The slaves create reply messageswhich are transferred back to the applications on the VME side. The transport of messagesalso happens in the reverse direction, from slave to VME side and back. This last point is thefundamental difference between Intel Bitbus and VTS Bitbus. According to the Intel Bitbusprotocol a master always sends order messages and a slave can only create replies. Everyactivity is also initiated by the master while the slave is passive. As a consequence onlyslaves which have received an order message from the master for which they did not senda reply, need to send messages. In Intel Bitbus the master does not need to poll slaves atdatalink level which don't have an outstanding order from the master. In VTS Bitbus everyslave can at any moment send a message.

The path of a message

The Bitbus Handler is responsible for a reliable communication between the slaves and theVME computer. When an order message is sent to the Bitbus-Handler by the VME side, it istransferred to the slave, see figure 2.4. In a database, it is marked with the time of sending the

L _

Slaver---------------lI Slave Application Iaommunication onI software the slave

Order I ICreate Mark I I

time I Order I

I I OrderReceiveI I

+I II I

ReplyCreate

DeleteI I

Receive mark I Reply I

Reply I I

Masterr---------------lI Application B' b II on lt us I

VME computer Handler I

IIIIIIIIIIL J

Figure 2.4: The path of an order message to a slave.

message to the Bitbus. Hopefully the message is received by the slave and a reply created.When the reply is received by the Bitbus-Handler, the mark of the corresponding order islooked for. If there is a corresponding order, the mark is deleted and the reply is sent to thetask where the order came from. If there is no corresponding order, the reply message isdeleted after logging this fact on a printer or terminal.

If after a specified time there is still no reply for a certain order message a timeout isgenerated. As a result of this timeout a reply message is created by the Bitbus-Handler. Thisinforms the application task who issued the order that the addressed slave is unreachable.

- 9 -

When after that the reply from the slave still arrives, it is discarded because there is no markfor a corresponding order. All these things are also printed on a logging device.

There may only be one outstanding order message from a single task on the master forevery slave. Orders which would violate this rule should be delayed. The rule is needed toprevent a task from blocking other tasks by overfilling the send queue for a cenain slave.This restriction should be enforced by the Bitbus-Handler because when the second (or third)message is rejected by the slave and there is an error, recovery is not possible anymorebecause more than one message without a reply has passed the serial link at that moment.

The path of a message in the other direction is almost the same, see figure 2.5. It should

I 1 OrderI I Create

Make copy I Order I

Order I IReceive of order

~I II I

Create Make copy I IReply of reply I I

I Reply IReceiveI I Reply

Masterr---------------,I Application Bitbus II on I

YME computer Handler f

IIIIII

III

IL J

Slaver---------------,I Slave Applicationaommunication onI software the slave

L _

Figure 2.5: The path of an order message to the master.

be noted that there is only one application task on the master that receives order messages.If that application task receives an order message, a reply must be created. This has tobe done by the application task itself because only the application can decide if it is anunderstandable message. The application task has to reply within a cenain time otherwisethe communication software of the slave will generate a timeout. There may on every slavealso be only one outstanding order message from every task on the slave. Because in thecurrent implementation there is only one task that can sent messages, there may be only oneoutstanding order message from every slave.

The copying of the order and reply messages is needed to make error recovery possible.This is discussed in a next section.

Disadvantages of the system

This is a very simple design and it is very fiexible, but it has some disadvantages. If you havemultiple outstanding orders from one task at the VME side, the sequence of replies can bedifferent from the sequence of the orders, e.g. the reply from the order message sent last canbe received fust. This makes the design of the application more complicated. The problemcan be avoided by rearranging the reply messages in the Bitbus-Handler so the reply from theorder message sent fust will be received fust. This requires a lot of memory and overheadfrom the Bitbus-Handler so this solution is not very practical. Also messages are delayedwhich may be undesirable.

- 10 -

Communication with the ERM application tasks

The communication between application tasks and the Bitbus-Handler takes place with thehelp of ERM mailboxes. There is one mailbox for all the messages that have to be sent onthe network. There is also one mailbox for all order messages received from the slaves andthere are a number of mailboxes for all the replies received from the slaves. Every task thatcan receive replies has its own mailbox. As a result of this organisation of mailboxes, everytask on the master (application and Bitbus-Handler) receives messages from one and only onemailbox. This restriction was necessary in the old version of the ERM system where a taskcould only wait on one mailbox.

2.4.2 Error recovery and power up

When a slave is reset or goes down, the communication with the master is interrupted. Thisis noticed by the master at datalink level. The datalink layer of the Bitbus Handler informsthis to the network and transport layer. In this network and transport layer a database ismaintained of all slaves. The state of the slave in error is switched from online to offiine inthis database. This means that no more messages can be sent to that slave,messages for it arerejeeted with an error reply. At the same time a message is created by the Bitbus Handler toinform the application on the master of the error.

To make recovery after an error situation possible, every slave has to remember the lastorder message received from every task on the master. The master should remember the lastorder message received from every slave. All this messages should be remembered completelyincluding the data field. This should be done by the network and transport layer.

When a slave starts operating again, it should fust inform the master about it and alsoteil the reason of the communication interruption. This should be done by sending a specialorder message to the master telling the reason, the reset message. This message must berecognized by the network and transport layer because this message should not be remembered.(Remember it would destroy the message received before the error and this would makerecovery impossible.) The reason indication in the message is of no importance for thecommunication software, this is only for the application.

After this all application tasks which are communicating with that slave should be syn­chronized to make recovery possible. This can best be done by the task that receives the ordermessage telling that the reason of the error. How this is done is completely up to the appli­cation. The Bitbus Handler doesn't give any help. Also it is the function of the applicationto inform the network and transport layer that the slave should be switched online.

When the slave has transmitted the reset message to the master, it may resend the lastmessage without a reply if this is needed. On the master side this message is compared withthe last message remembered. lf both messages are the same, it is considered a duplicate. Theremembered reply for this message is resent while discarding the duplicate. lf both messagesare not the same, the message is considered a new message and is handled as normal.

The same happens for the order messages from the master to the slave. Only the masterdoes not send a reset message. Also the order in which the tasks on the master resend theirmessages is not known.

If there is a power down of the master or if the Datem board is reset, then all slaves are

- 11 -

switched offiine. When the board is operational again, all slaves should send a reset messageto the master and the normal recovery procedure should be initiated.

A log should be made of all errors detected during the communication. This should bedone by the Bitbus Handler with the help of an application task that is conneeted to a printeror terminal.

2.4.3 Bitbus message format

Bitbus messages are short messages containing orders and replies, see figure 2.6. The maxi­mum length of every message is 32 bytes. They contain a five byte header.

Order message

Message lengthType (Order =OOh)Slave node address

Source task I Dest. taskCommand

Data (variable)

Reply message

Message lengthType (Reply = 80h)Slave node address

Dest. task I Source taskStatus

Data (variabie)

Figure 2.6: The message format.

• Message length contains the length of the complete message inc1uding the header plus2. Message lengths also vary between 7 and 34. This is in agreement with the Intelstandard but not with VTS Bitbus. The message header length byte contains in VTSBitbus the length of the message without the offset. This change towards Intel wasmade to inc1ude the possibility of incOIporating slaves conforming to the Intel standardin a VTS Bitbus network.

• Type tells if it is an order message (command) or a reply (response). In VTS Bitbusonly the most significant bit (bit 7) is used, other bits are zero. According to the Intelstandard also bits 4, 5 and 6 are used. Bit 4 is the track bit used to provide messagecontrol at the master or the slave. Bit 5 is the destination extension bit. This bitindicates when one that the destination of the order message is on the extension boardof the destination node. In case of a reply message it indicates that the source was on anextension board. Bit 6 is the same as bit 5, only for the other side of the transmission.

• Node address is the logical address of the slave node on the Bitbus. It is the same asthe SDLC slave address. There can be 32 nodes on a link and maximum 8 links.

• Source task is the task identification at the source node.

• Destination task is the task identification at the destination node. This is normally setto zero when an order message is sent because on every node there is only one task

- 12 -

which receives order messages from the Bitbus. This is a restriction of the currentimplementation of the application and no restriction of the Bitbus message structure.According to the Intel specification, there may be 16 tasks that receive order messages.

• Command is the code of the command to be performed by the destination node ifit is an order message. Status is the code in a reply message that gives informationabout possible errors during the transmission or evaluation of the corresponding ordermessage.

• The data field contains optional data needed by the command or response. The maxi­mum length of this field is 27 bytes.

2.5 Datalink layer

At the datalink layer the SDLC protocol is used. SDLC conforms with a defined subset ofthe ISO HDLC protocol: the Unbalanced Normal Class of Procedure [15, App. D]. Onlysome options of HDLC are not available in SDLC. The protocol can be used in half and fullduplex point-point, multi-point and loop configurations. The Bitbus interconnect specificationspecifies a half duplex multi-point configuration.

The SDLC protocol is a master - slave protocol, goveming a datalink between a masternode and many slave nodes in the system. Only one node at a time can send data on themulti-point link. The master node controls the communication link and the slave nodes mayonly send data when requested by the master. Data is sent in blocks (called frames) on thenetwork. The communication pattem is shown in figure 2.7. The master node also decidesin which order the slave nodes may send their data; the polling scheme.

SDLC master node

SDLC slave node

Figure 2.7: The master - slave communication pattem.

2.5.1 Polling scheme

The Bitbus firmware logically divides the slaves into two groups. Slaves in the fust groupare polled frequently. This slaves are said to be on the fast list. The slaves in the other groupare polled less frequently. This slaves are" on the slow list. Within every group the slaves are

- 13 -

polled in a round robin fashion. First all slaves of the fast list are polled and then one slaveof the slow list is polled.

After power up all slaves are in the slow list. They move to the fast list as soon as theyrespond correctly to a poll of the master. Slaves that respond with a Disconneet Mode frame(see later) stay on the slow list. lf a slave is on the fast list, it stays there until a timeout isgenerated when polling that slave or until the slave responds two times in succession withan erroneous frame. A timeout is generated when a sIave does not respond within 10 miliseconds after it is polled. This is a relative long time compared 10 the normal response time.A slave does not immediately go to the slow list if it is in Normal Response Mode when atimeout is generated. A retry is done before the slave is moved from the slow to the fast list.

This polling scheme ensures that slaves are polled less when they do not exist or are notoperating. Polling all slaves in a round robin fashion without the division into two groupswould make the system slower.

2.5.2 Frame format

The following frame format is used, figure 2.8.

I ftag I addr. I contr. I information 'frame check seq·1 ftag I

Figure 2.8: The SDLC frame format.

• The ftags are the frame delimiters.

• The address field gives the address of the destination or source node. lt is always theaddress of the slave involved in the transfer. According to Intel, addresses should be inthe range 1 to 250 but for this project al values are possible with the restriction that the32 nodes on a link must have consecutive addresses starting on a boundary divisibleby 32.

• The control field is used for command and status exchange between the master and theslave.

• The information field carries the Bitbus message and is only required and allowed inInformation (l) frames. Also the FRMR frame may carry an information field. Thisdata is put into the message that is sent to the upper layer of the protocol, telling thatthe slave has gone offiine.

• The frame check sequence contains a 16 bit cyclic redundancy check (CRC). It isgenerated by the standard CRC-CCfIT polynominal X 16 + X 1S + X S + 1.

The control code in the control field tells what kind of frame it is. The following framesare handled by the master, table 2.1 and table 2.2. The Poll/Final bit should always he setin a frame. This means that a slave always should respond to a frame from the master anda slave may not send more than one frame at a time. The only exception to this rule is thesupervisory frame which is sent by the master immediately after an information frame has

- 14 -

Table 2.1: Control codes used by master.Responses recognised Commands send

Unnumbered UA SNRMDM DISCFRMR

SupeIVisory RR RRRNR RNR

Information I I

Table 2.2: Explanation of control codes.Abbreviation Name Bit pattemUA Unnumbered Acknowledge 011P 0011DM Disconnect Mode ooOP 1111FRMR FRaMe Reject lOOP 0111SNRM Set Normal Response Mode lOOP 0011DISC DISConneet 010P 0011RR Receiver Ready xxxP 0001RNR Receiver Not Ready xxxP 0101I Information xxxP yyyO

P IS the Poll/Fmal bIt.xxx is the receive sequence count.

yyy is the send sequence count.

- 15 -

been received from the slave. The function of this frame is to free the transmit buffer of theslave for preparing the next information frame. The slave does not free its transmit bufferuntil it has received a confinnation of the arrival of the previous information frame. Thesupervisory frame is the confinnation. The slave should not react to this frame by sending anew frame so this supervisory frame has the poll bit reset.

The master node uses the control codes in the frame to keep track of the state of the slave.The master should always know in what state the slave is. There are two possible states:Normal Disconnect Mode and Normal Response Mode, see table 2.3.

Table 2.3: Slave device state transitions and responses.Slave state Incoming frame Next state Response

NDM DISC NDM UANDM SNRM NRM UANDM other NDM FRMRNRM I NRM RR,RNR,INRM RR NRM RR,RNR,INRM RNR NRM RR,RNRNRM I,RR,RNR + err. NDM FRMRNRM other NDM FRMR

When a slave does not want to communicate in the network, the slave should send aDisconnect Mode (DM) response on a poll from the master and enter the NDM state. Theslave should do this as long as the master keeps polling. When the master thinks the slaveis in Normal Response Mode, the slave can be marked online by the master, otherwise it ismarked offiine.

2.6 Workload distribution

The work of the Bitbus handler is done by two processors. Part of it is done by the local 8044processor(s) on the DATEM board(s) and the other part is done by the main processor on theVME side. Having two (or more) processors, the question is which part of the Bitbus handleris executed by the main processor. The main processor is in general much faster than the8044 processor. The 68000 microprocessor for example has an instruction cycle that is threetimes as fast as the 8044 when running at 12 Mhz. Also it has very powerfull instructionscompared to the 8044. Specially the acces of external data memory takes many instructionson the 8044 versus one on the 68000. On the other hand there can he more 8044 processorsin the system versus one main processor which compensates for the lower speed. There werethree known situations in which a choise to this question was made.

In the existing Multibus based routeing controller as supplied by Philips Machine FabriekAlkmaar, the datalink: layer is handled by the 8044 processor and the upper layers are handledby the main processor. The same is true for the microvax based routeing controller of theCIMphony pilot factory [7] at the CFf CAM-Centre. This means that for the named systemsthe polling of the slaves at datalink: level is invisible to the main processor.

- 16 -

In the Intel databook [16, page 20.1-20.9] there is an example in which the datalink 1ayeris handled by the main processor. The last solution is not a serious solution to the problembecause it means a too high overhead for the main processor. In the Alkmaar system thehandling of the network and transport layer was the bottleneck for the main processor. Sohaving to do the datalink layer also would make the problem even worse.

An other choice would be to have the 8044 handle both the datalink and the networkand transport layer. This would reduce the workload of the main processor. Having the8044 handle the network and transport layer means that the 8044 must do error detection andrecovery at transport level. Because of the lower speed of the 8044, having the 8044 do thiswould mean that the number of s1aves connected to a DATEM board should be reduced.

Also there is the problem of power down of the master. The RAM on the DATEM boardlooses its contents when the power is removed while the main processor can be equiped withbattery backup RAM. So when power down recovery of the master is needed, the networkand transport layer can not be handled by the 8044.

In the implemented system the choice is made to handle the network and transport layer bythe main processor and the datalink layer by the 8044. This reduces the number of DATEMboards needed and it offers the possibility of recovery after a power down of the master,which is more important.

2.6.1 Interface to the VMEbllS

The picture is a little more complicated because there is a rudimentary datalink between themain processor on the VMEbus and the 8044 processor on the DATEM board. This meansthat the layer model of figure 2.3 on page 8 must be expanded, see figure 2.9.

VMEbus based master computer Slave computer

Application ApplicationTasks Tasks

Bitbus Bitbus BitbusMessage Message MessageStrueture Copier Strueture

VME VME SDLC SDLCDatalink Datalink Driver DriverDriver Driver

Interface Interface RS-485 RS-485Driver Driver Driver Driver

VMEbus Interface Multi-point link

Figure 2.9: The expanded layer model.

The VMEbus interface together with the interface drivers are in fact one unit. Theyconstitute a bidirectional full duplex byte wide interface. This interface has the possibility tomark every byte that passes the interface as being a data or command byte. The receiving

- 17 -

side can read this extra infonnation. The datalink protocol for this VMEbus interface is basedon this propeny.

A very simple home made datalink protocol is used for tbe VMEbus interface. All tbebytes of a message are sent across tbe interface witb tbe last byte of a message marked as acommand byte and tbe otbers as data bytes. No additional bytes are needed for tbe protocolso tbe number of bytes transferred is minimal. The testing of tbe mark bit causes no overheadbecause this testing is also needed for reading a byte. The address where tbe byte must beread depends on tbe mark. The last byte of tbe message must be marked and not tbe fustbyte because otberwise tbe end of message is not deteetable when it is not followed by anotber message.

The protocol does not verify if tbe complete message is received correctly. This is notneeded because tbe chance of data being corrupted is negligible for such a short distance.Only tbe receipt of each single byte is signalled by tbe hardware. As a result of this all, tbeVME datalink driver is very simpIe.

The Bitbus message copier is almost a dummy module. lt only has to pass messagesunaltered between tbe two datalink drivers. This is a result of tbe fact tbat tbe firmware doesnot handle tbe network and transport layer.

- 18 -

Chapter 3

Software development

3.1 Software development phases

The development of a software product can be split in several phases. The CAM-Centredistinguishes nine phases [5].

Feasibility study The feasibility study is the study of the problems that are to be expectedduring the development of the product. It is also a study of the question if it ispractical to develop the product. This study can also be done when a subproblem isencountered during one of the other phases. During the feasibility study a prototype maybe developed. The prototype can be used to evaluate the problems that are expected.It is an optional study and its results are recorded in a separate document.

User requirements analysis The user requirements specification defines what the user wantsfrom the product, it defines the product to be realized. The specification should becomplete and specified in such a way that the ultimate product can be tested againstthe user requirements specification. It should include the pwpose of the system, theconstraints, the area of study and an environmental model. Also in the document can bethe specification of quality assurance, acceptance procedures and project managementinformation. It should be understandable by all partys involved.

System analysis The System analysis is the transformation of the user requirements into afunctional, informational and dynamic view of the problem to be solved. This is doneindependent of implementation aspects. The onginal problem is split into a relatedset of smaller problems. Also a description is made of the data fiowing through thesystem. The resulting model is called the behavioural model and consists of Data FlowDiagrams, State Transition Diagrams, Entity Strueture Diagrams, textual specificationsand a Data Dictionary.

System design System design is the distribution of the functions of the system among mod­ules. Also the distribution of the system among processors and processes is writtendown. The relationship between the modules is modelled with the help of modulecharts. During the system design nothing is stated about the intemals of the functions.Part of this phase is the development of an integration test plan for the integration of

- 19 -

the functions and modules into a system. A test plan for the individual modules shouldalso be made.

Detailed design Dwing detailed design the internals of the functions are composed downto the bottom. The algorithms are defined at this stage. The intemal strueture of thefunction is described with the help of a program design language (also called Pseudo­code) or by graphical means. There should be enough information to code the function.A white box test plan for the functions should also be developed and written down.This is a test plan which is based on knowledge of the intemals of the functions.

Programming Programming is the translarion of the detailed design for every function intosource code. During coding, a uniform coding standard should be used to increase theportability and readability of the sources. Every sourcefile should contain a standardheader for identification [3]. The Pseudo-code of the detailed design should be used asprogram documentation. Also part of the programming phase is the white box test.

Integration The goal of the integration phase is to construct a final product from the partsbuilt during the programming phase. The coded and tested modules and functions arejoined to form a complete system. All modules and functions are tested as a blackbox. Also groups of modules are tested together. This should be done using the buildmethod. A build is a complete path in the hierarchy of modules, from top to bottom.Modules not under test are replaced by dummy ones if needed. Also the softwareintegrated into its environment must be tested. The final result must be in agreementwith the user requirements specification.

Acceptance test The acceptance test is the final test of the complete product under the re­sponsibility of the customer. During this phase, the product documentation is reviewed,tested and released for distribution. The product is compared with the user requirements.If the test is successful, the product is released. After this, changes in the product shouldfollow the formal procedure of changing a released product. This must be done to keepthe product maintainable and the documentation consistent.

Maintenance During the maintenance phase, the software and its documentation are sup­ported and distributed. The documentation and the product are kept up to date. Problemreports and change requests are analysed and actions taken. The maintenance phaselasts from the end of the acceptance test until the end of the product's life.

Every phase should be described in a separate document. Every document should beidentified by a product number, a group number and a sequence number. The product numberis a 12 digit number which is unique for every product created at Philips. The last digit ofthis 12 number code is the revision level of the product. The group number identifies thekind of document. lt is a three digit number. The sequence number distinguishes betweenmultiple documents of the same group. This number may be omitted if there is only onedocument in a group.

Parts of a product, that can be used in other products should have there own productnumber to make reusability possible. An example of this is a module in a large program with

- 20-

general functions. In practice not all phases are carried out by the development team or arenot documented as such.

For some of these nine phases a struetured method is used. These phases are the systemanalysis, system design and detailed design phases which are explained in the followingsections. The other phases like user requirements analysis are handled in a more informalway. During programming a coding standard is used if it is available for the language used.As aresult, the reports of the phases that are handled more informally, don't have a standardcontents.

3.2 Structured analysis

The System Analysis phase was done using a method called Struetured Analysis or YourdonAnalysis [6,9,10]. During this phase the VAX tooI ProMod [19] was used which supports thisanalysis method almost completely. With this method, the system is described by means ofthe flow of data and the transformations on that data. The description is done with a leveledset of pictures called Data Flow Diagrams and Control Flow Diagrams. A combination ofboth is called a Flow Diagram in ProMod.

The resulting model is a description of the behaviour of the system. This model should notbe infiuenced by the implementation of the system. In practice a little infiuence is unavoidableto make the system implementable.

3.2.1 Flow diagrams

Every Flow Diagram specifies the internals of a transformation in a Flow Diagram one levelhigher. The Flow Diagram at the top is called the Context Diagram, see figure 3.1 for anexample. A Flow Diagram may contain the following elements:

Data Transformation A Data Transformation or a Node is shown as a circle with asolidcircumference. The internals of a Data Transformation must he specified with a FlowDiagram, a Data Flow Diagram or a textual specification. Figure 3.2 shows the speci­fication of the node Network..manager.

Control Transformation A Control Transformation is shown as a circ1e with a dashed cir­cumference. It must be further specified with a Control Flow Diagram, a State Tran­sition Diagram or a textual specification. The tooI ProMod does not support ControlDiagrams, but they are replaced by bars, straight lines which have the same function,see figure 3.3. Their internals must be specified by State Transition Diagrams and/ortextual specifications.

Terminator The rectangles in the Context Diagram are Terminators. They represent thingsof the environment of the system and may only be used in the context diagram. TheseTerminators need not be specified any further.

Data Flow Data Flows represent the flow of data through the system and are shown by solidarrows. Flow of control information should not be represented by Data Flows. Thedata that flows through a Data Flow is specified in the Data Dictionary.

- 21 -

ee

frame

" \

_ Dieable timer

""

Enabl~ "timer -

'- Timer int" -

\

Boet transmit­buffir full -Boet reeeivebu f fir empt~-""'"- .......

ostranimuffer

HoetreeeTvbuffer -

Bitbus firmware

LEVEL: LAST UPDATE: 9-NOV-198ï 14: 09

PROJECT: Bitbu~ LAST ANALYSIS: 17 -AUG-l 988 11: 11

Figure 3.1: The Context Diagram.

Control Flow The flow of the control infonnation is represented by Control Flows whichare shown by dashed arrows. Control infonnation is infonnation needed for controllingthe dynamic behaviour of the system. These are the only flows that may enter or Ieavea Bar or Control Transformation.

Store Two parallel horizontal lines are the symbol of a store. A store is used to model thetemporary deposition of data if the delay is extemally observabie. A store is used tomodel a delay which is caused by the implementation.

Entity Structure Diagram AD entity strueture diagram gives in a graphical way a descriptionof the meaning of stored data. 1t defines the relationship between entities. Entitystructure diagrams are not supported by ProMod and for that reason they were not usedduring the project. In the Yourdon literature [9] the name Entity Relation Diagram isused for a equivalent diagram with the same function.

There are some restrictions on drawing Flow Diagrams, most of which are enforced byProMod. Examples of such rules are:

• There should be no flows between a tenninator and a store.

• Two stores should not be connected by a flow.

• Stores and transformations can not create data, it must flow into them or be thereinitially.

- 22 -

Se rial int--- -

/

II Dieable I Enable \ Timertimer -timer - \ Jont

I Ir Y

IReceived fram"s

Messagesfrom nos!"

Messagesto host -

Host receivebuffir emptY- M i_ - essages 0

- _ host queü -, not_impty -

\ ,/

/ Messages 'from,/ host queüe~

not IullHost transmitbuffir full

Bytes fromhost

LEVEL: 0 LAST UPDATE: 1ï-NOV-198ï 10:09

PROJECT: Bitbu5 LAS'I ANALYSIS: 1ï-AUG-1988 11:11

Figure 3.2: The specification of NetworkJIlanager.

• Flows with the same data should not enter or leave the same transfonnation. Theyshould merge or split outside the transfonnation, see figure 3.3.

3.2.2 State transition diagrams

A State Transition Diagram is used to model the dynamic behaviour of the system. lt consistsof states and transitions, see figure 3.4 and specifies the internals of a bar in a flow diagram.A state is shown by a rectangular box with its name and a transition by an arrow. For eachtransition an event and an aetion are specified. The event is written above the separation lineand the action below it. An event can be specified:

1. in a textual specification belonging to the state transition diagram.

2. by a control flow entering a bar e.g. Frame_prepared in figures 3.3 and 3.4.

3. by an action in another sheet of the state transition diagram e.g. StartJegular_operationin figures 3.4 and 3.5.

An action on the other hand, can be specified in a textual specification, by a control flowleaving a bar or as an event in another sheet.

- 23 -

Received frame

Frame" "" prepared

"Trigger " "hanale - \ "controI Triggermessage- \ prepare- \" " frame -

I J

"controt1 I, 1 1<message ,handle cr / I - - ..

/ I Enable/ / I transm'i"ssioReceivra ~~ëeived'frame'" - fr$le / -

..i'alldli'd"" ,/ Trigger handle

receJ.veä frame

Network control and conversion

/""/.. ~-= - -

Messages to hostqueue_nor_empty -

Messages from host queue not full----=---::- -- --" "

"Non controlmessage_from_host \

\Control message Ifrom hoit

LEVEL: LAST UPDATE: 1ï-AUG-198é 11:11

PROJECT: Bitbu~ LAST ANALYSIS: 17-AUG-198é 11:11

Figure 3.3: A flow diagram with a bar and merging flows.

3.2.3 Data dictionary

The data dictionary contains the description of all the data flowing through the data and controlflows. It is the only place where the definition is stored. The data can be defined in a formalway with a record like structure and/or it can be defined in an informal way with the help of acomment. For an example see the definition from Order_bitbus..messageas specified in figure3.6. Parenthesis are used to indicate optional elements, while square brackets are used toindicate a selection list. Curly braces are used for repeated elements. The optional numbersbefore and after the braces indicate the minimum and maximum number of occurrences ofthe repeated element. The elements of a compound data element are further specified in thedata dictionary unless the name is surrounded by double quotes.

3.2.4 Textual specifications

A textual specification or a mini-spec is a short description of the functions provided bythe described unit. It is mandatory for data transformations which have no other specifica­tion. Also data transformations higher on the hierarchy may he accompanied by a textualspecification.

A textual specification should be short, not more than half an A4 page. The descriptionshould be very comprehensive and should describe the functionality, not the implementation.It should be written in plain English and not look like a program. All the data mentionedshould be specified in the data dictionary.

- 24 -

Power on-Trigger_handle control_message-

I Handling_first_control_message I

Control _message_ handled

Trigger_prepare_ frame

I Preparing_first frame I-

Frame_prepared

start_regular_operation

I Regular_operation I

Network control and conversion- - -SHEET NO: 1 OF 2 ILAST UPDATE: 09-FEé-1988 09:56

PROJECT : Bitbu" ILAST ANALYSIS: li-AUG-1988 11:11

Figure 3.4: The fust sheet of a state transition diagram.

A textual specification of the function of a bar specifies the relations between the controlflows at one side and the events and actions on the other side. This relations may be one tomany or many to one.

3.2.5 Assistance of ProMod

ProMod [19] is a software development tooI special designed around the struetured analysisand structured design methods. It does lots of bookkeeping and it has a graphical editorspecial designed for drawing flow diagrarns and state transition diagrarns during the analysisphase. The syntax of all non graphical objeets is checked before they are saved in the projectlibrary. The graphical objects are checked for consistency and compared with the rules beforebeing saved.

The stl"ongest point of ProMod is its ability to do a consistency check of the completeanalysis phase. The hierarchy of the flow diagrarns is verified. The nodes are compared withtheir specifications , bars are compared with state transition diagrarns etc. Also a completeanalysis report is created with a description of all the elements of the project library includingcross references, errors etc.

- 25 -

start_regular_operation

Trigîer prepare_~rame_ena e ~ransm~ss~o

.1 Preparing_frame I

Frame_prepared

Trigger bandle controlmessage:Enable- -

I Handling_ control _message I

Control _message_ handled

Trigg er handle -rece~vea frameReceived frame handled - No received frame- - - -Trigg er_prepare_ frame Tri€,ger bandle

Handlins_ received frame I con rol:messagë-

Network cent rol-and- conversion-SHEET NO: 2 OF 2 ILAST UPDATE: 24-JUN-1988 10:04

PROJECT: Bitbus ILAST ANALYSIS: lï -AUG-1986 11:11

Figure 3.5: The second sheet of a state transition diagram.

Order_bitbus_message = Message_length+ Order identification+ Node address+ Source task identification- -+ Destination task identification- -+ Message_comrnand_code+ 0 { databyte } 27

Figure 3.6: The definition of Order_bitbus-IIlessage.

·26 -

3.3 Modular design

The modular design method was used during the system design phase. This is the methodused by ProMod. lt does not cover the complete system design because the distribution ofthe system among processors and processes is not supported. This omission turned out notto be a serious problem in praetice.

The modular design specification in ProMod consists of three parts.

Modules During the modular design the funetions needed for implementing the system aredistributed among modules. See figure 3.7 for an example of a module. For everymodule a description is made of all funetions inside that module. Also all exportedfunetions are marked as such and all funetions imported from other modules are wrinendown. For every function in a module the parameter list is specified. Every parameter isdescribed by means of its name and the name of its type. Part of the module descriptionis also a list of variables which are local to the module but global to the funetions in it.

Datatype dictionary All the datatypes of all variables in the system are specified in thedatatype dictionary. The elements in the datatype dietionary have the same syntax asthe elements in the data dietionary.

Subsystems Subsystems are meant to collect in a single unit all modules which share thesame global variables. Therefore a subsystem descriptions contains a list of variables,modules and other subsystems.

All these three parts are specified by text, there are no graphical specifications.

3.3.1 Assistance of ProMod

The results of the analysis phase can be converted automaticly to the data for the design phase.During this conversion the flow diagrams are converted to modules and functions. This isdone in a very straight forward manner. All transformations and state transition diagramsare converted to functions without arguments. The transformations of one flow diagrambecome the functions of one module. The textual specifications of the transformations becomecomment for the functions. Also the data dietionary is converted to the datatype dietionary bycopying every element of it. This conversion is a good starting point for the modular design.lts output must be changed a lot but in spite of all the conversion saves a lot of typing.

Also after the conversion ProMod offers a lot of assistance. The syntax of all elements ofthe project library is checked, so saving an element with a syntax error is impossible. ProModcan also do a consistency check of the module hierarchy. During this test ProMod verifiesthat all imported functions are exported from their modules. A verification of the argumentlists is also done. The argument list of an imported funetion should be the same as its exportdeclaration. A picture of the module hierarchy can also be generated by ProMod, see figure3.8 for an example. This picture is automatically generated by ProMod. lt eases programmodifications because after a modification, an updated picture of the module hierarchy isautomaticly drawn. lt is possible in ProMod to modify this picture by hand. This can beuseful for the final version of the document.

- 27 -

MODULE Handle received frame

PURPOSEInformal specification of the purpose of the module.ENDPURPOSE

EXP Handle received frame(OUT Result:Frame_available indication),

Init_handle_received_frame;

IMP FROM Free_buffer_handling:Free_message_frame

(IN Buffer:General_message);FROM Messages_to_host_queue:

Write_message_to_host(IN Buffer: General_message) ;

FROM Received_frames_queue:Read received frame- -

(OUT Buffer: General_message) ;FROM Slave data base:- -

Access slave data(IN Slave:SDLC_address;OUT Slave_data-pointer:Slave_data_element),

Put slave in fast list- - - -(IN Slave_data-pointer:Slave_data_element),

Put slave in slow list- - - -(IN Slave_data-pointer:Slave_data_element);

DATASlave_data:Slave_data_element,Message:General_message,New_state_and_action:Slave_state;

INTERNAL Check_receive_sequence_number,Check_send_sequence_number,Create_slave_offline_message,Do received frame action

Figure 3.7: An example of a module description.

- 28 -

Project: Bitbus

Module Hierarchy

Date: 13-JUL-198B 10:23

Last Ana1ysis: 13-JUL-1986 10:22

Figure 3.8: The module hierarchy.

The picture of the module hierarchy consists of boxes and arrows. A box represents amodule and an arrow means that a function of the module where the arrow points to is calledby a function of the other module.

3.4 Pseudo code

During the detailed design phase, the intemals of the functions are filled in. The methodused for this is called pseudocode in ProMod. Pseudocode uses the structure of a high levelprogramming language and the English vocabulary. In ProMod the description of a functionconsists of four parts.

1. The specification of the argument list. This is the same as the argument list of thefunction in the module specification.

2. The infonnal pwpose specification of the function. This is a textual specification. 1tcan be created from the textual specification for the corresponding transfonnation inthe analysis phase.

3. Variables local to the function. The syntax is the same as for the global variablesspecified in the module and subsystem specifications.

4. Statements, these are mandatory and are the only elements that are not optional.

- 29 -

ProMod distinguishes between four kinds of statements.

Text A text statement consists of a short English sentence.

Selection The IF, THEN, ELSE, ENDIF statement is the selection statement. Optional theremay be several ELSEIF parts between the THEN and the ELSE.

Repetition A loop is specified with a DO, ENDDO statement.

Function eaU A function call statement consists of the function name and its argument list.The type of the arguments must be correct otherwise ProMod will generate errors.

Also during the detailed design phase ProMod can do a consistency check. The use offunctions and variables is verified during this check. After the consistency check structurecharts may be drawn. These pietures represent the relations between the functions.

- 30 -

Chapter 4

Bitbus firmware

4.1 User requirements

The requirements for the finnware of the Bitbus-Handler are almost completely specified inchapter 2. The thing with the strongest impact on the finnware is the use of the dDCMS04board.

4.1.1 Hardware of the DCM804 board

The hardware of the DCM board consists of five parts, see figure 4.1.

• The Intel S044 Bitbus controller in the center.

• The optical isolated RS485 driver and receiver for the Bitbus.

• The memory sockets, one for EPROM, one for RAM and one for EPROM or RAM.

• Bitbus configuration and address circuit. This consists of jumpers which contents canbe read by the finnware.

• The bidirectional interface to the VMEbus with the single byte fifos. Both directionsof the interface can be used independently.

The heart of this board is the Intel 8044 single chip microcomputer. The chip comainsa central processing unit, memory and IlO, see figure 4.2. The central processing unit isthe same as used in the 8051 series microcomputers [4]. 1t bas an instruction set speciallyoriented towards control applications e.g. with special instructions for bit manipulation andtesting.

The intemal memory consists of 4096 bytes program memory (optional) and 192 bytesdual port RAM. There are three variations in the kind of program memory available. The8044 has factory mask programmable memory, the 8744 has user programmable and erasablememory and the 8344 has no program memory. The onboard RAM is shared between thecentral processing unit and the serial interface.

The IlO of the 8044 series consists of four parallel ports which are also used for otherpurposes, two 16 bit timer / event counters and a serial interface unit. The serial interface unit

- 31 -

Bitbusconnector

Opticalisolation

8044Bitbus controller

Bitbuscon- TIrree

figuration 28-pinand i 1

memoryaddress sitescircuitry

Transmit ReceiveFIFO FIFO

r 1VME interface

VMEBUS

Figure 4.1: Hardware of DATEM dDCM804 board.

- 32 -

r

Frequencereference Data Direction

- ï

Oscillator&

timing

8051CPU

Interrupts

4096 bytesprogrammemory

64k-byte busexpansion

control

192 bytesdual port

RAM

Programmabie1/0

Serialinterface

unit

Two 16-bittimer event

counters

Interrupts Control Parallel portsAddress data bus

and 1/0 pins

Counters

_ ..I

Figure 4.2: Block diagram of 8744 processor.

- 33 -

provides a high perfonnance communication link. The protocol used on that link is basedon the synchronous datalink control (SDLC) protocol. A large part of this protocol can behandled by the hardware of the interface unit. The unit can receive and transmit a completeframe without CPU intervention. The data of the frame is transferred to or from the intemalRAM by means of direct memory access (DMA).

The interface can operate in two modes, extemally clocked mode and self cloeked mode.In extemally clocked mode, the clock for the serial interface should be supplied in parallelwith the data. In this mode a datarate of up to 2.4 megabit per second can be achieved witha 12 MHz processor. The Bitbus as specified by Intel has an optional synchronous mode ofoperation. Intel specifies in that mode a bitrate between 0.5 and 2.4 megabit per second.

In the self clocked mode, the serial interface extraets the clock infonnation from the datastream with the help of a digital phase locked loop. The maximum datarate for a 12 Mhzprocessor in this mode is 375 kilobit per second. The Intel Bitbus specification specifies thatthe allowable speeds are 375 and 62.5 kilobit per second. In the previous VTS Bitbus thespeed was 355 kilobit per second because in the slaves of vrs a processor clock of 11.059MHz was used for historical reasons. The newest version operates on the standard speed of375 kilobit per second. The DCM board operates at a cloek speed of 12 Mhz so the speedused is also 375 kilobit per second. This speed is compatible with the Intel specificationwhich allows the use of standard Bitbus slaves. The bitrate used by the previous VTS slavescan easily be increased by replacement of the processor crystal.

The serial interface unit can be programmed to operate in one of two response modes:auto mode and fiexible mode [16, page 19.1-19.11]. In auto mode a subset of the SDLCdatalink protocol is perfonned by the hardware of the serial interface unit. In this mode thehardware can automaticly respond to RR, RNR and I frames received from the master withoutintervention of the processor. But the auto mode can only be used by boards that operate asslave. This makes the mode useless for this application as master.

In fiexible mode the serial interface unit perfonns a subset of the functions of auto mode.The interface does not respond automaticly to frames received but instead the transmissionmust be started by the processor. Also the receipt of frames is completely under the controlof the processor. This is the method that should be used for a system operating as a master.

Only one of the two built-in timers/counters is used by the finnware. The function of thetimer is to generate a time out interrupt when for some reason no frame is received withinthe specified time interval.

With exception of the serialline only five bits of the programmabie 1/0 are used on theDCM board. Three are used for the communication with the VME interface and two areused for diagnostic pwposes, see table 4.1. All inputs are negative true while all outputs arepositive true.

The interface to the VMEbus consists of two byte wide fifos. Associated with every fifois a bit which remembers if there is a command or a data byte in the fifo. This bit is set orreset depending on the address to which the byte was written when filling the fifo. The bitmust be read by the reading side before emptying the fifo. Depending on this bit the FIFOdata byte or the FIFO command byte must be read and these bytes have different addresses.The receive and transmit fifos have addresses in the extemal data address space. This is alsotrue for the addresses where the value of the jumpers can be read, see table 4.2.

- 34 -

Table 4.1: Programmabie IlO bits used.Pin name Direction Polarity Signal nameINTO Input Neg. Receive Fifo Not FullINTI Input Neg. Transmit Fifo Not EmptyPl.2 Input Neg. Transmit CommandPl.1 Output Pos. Green LEDPLO Output Pos. Red LED

Table 4.2: Byte addresses of buffers.Buffer name AddressFifo data OFFOOHFifo command OFF01HConfiguration byte OFFFEHNode address byte OFFFFH

4.1.2 Use of a IDulti-tasking kernel

An important question when building the finnware was whether or not to use a multi-taskingkemel. The use eases the design of the finnware because the problem can be split in severalconcurrent tasks. On the other hand parallel tasks require protection of access to sharedvariables. In the finnware of the SLQ 8044 board [2] a kemel developed by Philips (REX51[8]) is used. This board was used as Bitbus master in the routeing controller of the CIMphonyproject [7].

A point against using a kemel is the processor overhead for the task switching. Duringevery task switch all registers and the stack of the current task are saved and after that theregisters and the stack of the next task are restored. The stack must be moved because it mustbe in the intemal data memory of the 8044 and this memory is too small to simultanious1yhold the stacks of all tasks. This means a lot of data traffic between the intemal and extemaldata memory. The 8044 processor is not very fast in moving data so this takes a long time.

From these points it was concluded that the use of a multi-tasking kemel should be avoidedif possible. By using interrupts, it is possible to avoid this kemel. There are four interruptsused by the finnware. These interrupts are generated when the following interrupts occur.

• The byte buffer to the VMEbus becomes empty as a result of a read operation by theVME side.

• The byte buffer from the VMEbus becomes filled, there is a byte available from thehost.

• A frame is received by the serial interface or a frame is transmitted by the serialinterface.

• A timer has expired.

So the finnware can be organised as a sequential main program with a collection of parallelinteI!Upt handlers._ This use of interrupt handlers is supported by the language PL/M-51 [17]

- 35 -

in which the finnware is coded. TIris language was chosen because it was the only high levellanguage for which a compiler was available at the CAM-Centre that generates code for the8044.

4.1.3 Control of the datalink layer

It should be possible for the application tasks on the master to infiuence the operation of thefumware. This is needed for error recovery, slaves need be marked as online in the slavedata base. The application tasks must also have the opportunity te inspect the operation ofthe finnware. For this purpose special control messages are sent to the finnware. All thesemessages have a slave node address of zero. The finnware should reaet to this messages byperforming the requested operations and creating reply messages stating the success or failureof the operations. TIris messages should have the form of regular Bitbus messages so thereis no special treatment needed by the other parts of the Bitbus Handler. The funetion and thecontents of the messages are defined in appendix A on page 61.

4.2 Analysis

The analysis phase was on paper done in a top-down way but there was a large infiuence bythoughts about the lower layers. The results of it are shown in appendix E on page 73. It wasstarted with the environment model. This is largely fixed by the strueture of the hardwareand the functions that have to be performed. The interface to the VME side is split in twoparts while the serial interface is one unit. This is because the interface with the VME sideis a full duplex interface; communication takes piace in both direetions independent of eachother. The serial interface is a half duplex interface, it can only receive or transmit but notboth together. The timer is needed for generating timeouts when a slave does not respondwithin the specified time. TIris time is fixed for the system so there is no need to send timedata to the timer.

In the flowdiagram that specifies the transformation Network..manager the structure ofone main process and three interrupt handlers is c1early visible. According to the Yourdonbooks this is an undesirable situation. The analysis phase should not be infiuenced by designconstraints but this would make the system very difficult to implement efficiently. TIris is whythe structure was chosen that was discussed in the previous section and where the hardwareinfiuences the analysis.

The communication between the interrupt handlers and the main program is with the helpof queues. This allows an asynchronous operation of the parts and has the advantage thatthe queues form a weIl defined interface between the parts. The main program must do thelargest part of the work to be done. The work to be done by the other parts should be assmall as possible. TIris is because the overall performance of the finnware depends on thelatency between the signalling of an interrupt and the start of the corresponding handler. Thislatency depends on the time that the interrupts are disabled, so it depends on the time spentwithin the interrupt handlers because then other interrupts are disabled.

- 36 -

4.2.1 Use of a pipeline architecture

For increasing the perfonnance a pipeline architecture for the finnware was chosen. Themam program does not wait on the frame returned by the slave after it has created one. Firsta frame for the next slave is created and then the return frame of the fust one is handled,see figure 4.3 where A, B and C are slaves for which frames must be created or responseframes handled. This has consequences for the order in which slaves should be polled. A

_ _ I Create B I Handle A I Create C I Handle B I, •

tJme

Figure 4.3: The work order of the mam program.

slave should not be polled twice consecutively because then the returned frame is not handledbefore the second frame for that slave is created. During the second frame the informationabout the state of the slave may be incorrect, so the wrong frame is created. There shouldalso be more then one slave specified in the slave data base.

This restriction is enforced by the polling scheme used, see section 2.5.1. All slaves aredivided into two lists, the fast list and the slow list. First all slaves of the fast list are polledand then one slave of the slow list is polled. If all slaves are on one list (the fast or the slowlist) then there is no problem because all slaves are polled in a round robin fashion. Thesituation where one slave is polled most frequent, is the situation with one slave at the fastlist and the others at the slow list. In that situation there is only one intervening slave polledbetween two polls of the slave on the fast list. In this situation the system will work so inall other situations it will also work.

A result of the pipeline used is that in total there are maximal two frames in the queuesto and from the serial interrupt handler. This eased the design and coding at the subsequentstages. The number of frames in the queues may be increased by a change to the work order.An increase may make the system faster but it makes the design much more difficult becausethe number of frames created between two successive frames for the same slave must alsobe larger.

The handling of control messages is done outside the pipeline. First all waiting controlmessages are handled before doing the normal work. This was done because t;he controlmessages should also be used for debugging part of the finnware. This means that the controlmessages should still be handled if the rest of the mam part is blocked due to an error.

4.2.2 Synchronization with the slave

For a proper operation of the communication, it is necessary that the master gets the slave inNormal Response Mode. Only in this mode information can be exchanged. This manipulationof the slave state is done with the help of the control codes in each frame.

The master maintams a state variabie for each slave that it trys to synchronize with thestate of the slave. Because the master has to handle errors in the communication, it needsmore states then the slave. The state machine of the master has five states versus two statesof the slave. This five states are:

- 37 -

Go_to-NDM The state of the slave is unknown. The slave has to be brought in NonnalDisconnect mode. While in this state the slave is not polled frequently because it is inthe slow list.

FRMRM FRaMe Reject Mode, this is an intennediate state. From here the state will changeto the Go-to..NDM state or the NDM state depending on the response from the slave.This state is the same as the previous one but the slave is now in the fast list, so it ispolled more often.

NDM The slave is in Nonnal Disconnect Mode according to the master. The master will tryto bring the slave in Nonnal Response Mode.

NRM The slave is in Nonnal Response Mode according to the master. This is the nonnalsituation.

NRM_timeout This state is the same as the previous state. Only the slave didn 't respondlast time when polled.

The transitions between the states are shown in table 4.3 and depend only on the framereceived from the slave.

Table 43· State transitions of the master..Old state Frame received New State ActionGo_to..NDM UA NDM

others Go_to..NDMFRMRM UA NDM

others Go_to..NDMNDM UA NRM

others Go_to..NDMNRM RR NRM

RNR NRMI NRM Forwardtimeout NRM_timeoutothers FRMRM Offiine

NRM_timeout RR NRMRNR NRMI NRM Forwardtimeout Go_to..NDM Offiineothers FRMRM Offiine

There are also actions perfonned at some transitions. Offline means that there was anerror and an offiine message should be created to infonn the application on the VME side.Forward means that the message received should be forwarded to the application if it was notalready received and there is no error detected.

The frame that is created by the master for the slave depends on the value of the statevariabie for that slave. If the value is NRM or NRM_timeout, then it also depends on thefact if there is a message waiting for that s~ave or not, see table 4.4.

- 38 -

Table 4.4: Frames created by the master.Current state Frame CreatedGo_to..NDM DISCFRMRM DISCNDM SNRMNRM RR or INRM_timeout RR orI

4.2.3 Ioterfaciog with the VMEbus

The interfacing with the VMEbus consists of two interface drivers. These are modelled in flowdiagrams Receive.ll1essage..fromJlOst and Transmit.ll1essage..toJlOst. One node assembles thebytes that pass the host transmit buffer into a message and one disassembles the message intobytes for the host receive buffer. There are three modes in which these drivers can work.

Polled The interface driver must continuously poll the interface for the bytes of a message.So the interface is always busy testing the status of the interface.

Interrupt For every byte that passes the interface an interrupt is generated. This means thatthe interrupt handler is called at a very high frequency.

InterruptJpolled An interrupt is generated for the fust byte of a message. After that theinterface is polled until the last byte of the message has passed the interface. In thismode the interrupt rate is much lower as in the interrupt mode. The processor utilizationcan also be lower because less time is spend as interrupt handler setup and return time.This is only true if the other side of the interface can handle the data rate of the interfacedriver. If the other side blocks when transferring data, the interface driver also stopsand blocks the total Bitbus Firmware.

The third option was chosen for the Bitbus Firmware. The problem of the blocking isgot round by restricting the number of unsuccessful polls. This is necessary because it is notvery likely that the interrupt for interfacing to the board has the highest priority at the VMEside. So the data transport can always be delayed by other interrupts. This would mean thatthe firmware is delayed which reduces the performance of the board. The following solutionis used. If after a certain number of polls there is no data the interrupt handler is left. Whenafter a while there is new data an interrupt is generated. This number can be changed fromthe VME side with the help of control messages.

4.2.4 Ioterfacing with the serial lioe

The handling of the serial line is performed with a few transformations which are activatedaltemately, see flow diagram Transmit.Ieceive-irame. The basic actions are transmit a frame,followed by receive a frame. In special circumstances the other transformations are alsoactivated. If the frame received is an information frame and the sequence numbers of theframe are correct, an acknowledge frame has to be transmined as quick as possible. This

- 39 -

means that the expected sequence numbers must be incorporated in the information receivedoom the main part of the firmware.

In case there is no frame received from the polled slave the hardware timer will expire.A dummy frame indicating a timeout is created in that case. This means that the main partof the firmware still receives a frame which is easy for the design of the pipeline.

The interface driver of the serial line will do some error detection. This should be as littleas possibie because the processor should spend as little time as possible inside an interrupthandler. Most errors can be detected by the main part of the firmware but some must bedeteeted here like buffer overflow.

4.3 Modular design

Modular design is the definition of functions and the distribution of them among the modulesand subsystems. The starting point for this was the module hierarchy created by the transfor­mation of the analysis data. This hierarchy was changed substantially because the criterionsfor the analysis phase are complete different form the criterions of the design phases. Thechanges were guided by the following criterions.

• Minimization of coupling between modules. Data should be passed as function argu­ments between modules. There should be no global data if possible. The number ofexported and imported functions should be small.

• Easy adaption to hardware and other changes. The number of modules that must bemodified in case of a change should be small.

• Modules should be small but the total number of modules should be manageable. Oneof the reasons why modules should be small is, that the module is the unit of compilationand the PL/M-51 compiler which is used to compile the resulting code, can only compilesmall files. On the other hand there shouldn 't be too many modules because then thereare many functions with argument lists, which costs lots of intemal data memory. Thisintemal data memory is very scarce in the 8044 processor.

As a result of this changes many functions were moved up and down the module hierarchy.Also a number of modules were removed e.g. the interface driver for the host receive bufferwas contained in two modules. This number is reduced to one which contains two functions.A number of functions was also deleted e.g. all functions which resulted from the statetransition diagrams of the analysis. These functions were deleted because they were verysmall functions. They were called by the functions which resulted from the flow diagramswhich contained the state transition diagrams. These last functions were almost empty. Sothe functionality of the fust functions was added to the last functions.

One module with many functions was added, which has no counterpart in the analysis.This is the result of the fact that all queues in the system are implemented with the help of acentral buffer pool. A queue consists of a linked list of buffers in the buffer pool. So whena message travels through the system and changes from message to frame and back, it neednot be copied. The number of buffers needed is not constant so there should also be a listof free buffers. This list is maintained by the functions of the added module. The use of a

- 40-

central buffer pool and the linked lists is a design decision and should not be refieeted in theanalysis.

The result of these modifications was that the Bitbus Firmware was divided into 13modules which were grouped into three layers, see figure 3.8 on page 29.

• The top layer contains one module. In this module is the supervisory function.

• The middle layer contains six modules. These modules contain application orientedfunctions.

• The remaining modules are in the lowest layer. This lowest modules contain the datastruetures and data access funetions e.g. queue manipulation.

All modules are in a single subsystem. The global data was defined within this subsysteme.g. the central buffer pool.

Every module has its own initialization funetion. There is no counterpart for this functionin the analysis phase because during the analysis only the steady state behaviour of thesystem is modelled. These initialization funetions are called in a hierarchical order. Thesupervisory funetion calls the initialization functions of the middle layer and one of themcalls the functions of the lowest layer.

1t took only a short time (about a week) to make a first design of the module hierarchy.Later on during the detailed design phase and the coding phase, it was changed a little toimprove the design of the firmware. Most changes were the addition of intemal funetionsand variables. This was necessary because some functions had to be split because of theirsize. The changes were design changes and the analysis results were not modified becauseof it. The operation of the system was not modified by the changes.

4.4 Pseudo code

The creation of the pseudo code is a very mechanical operation. The funetions that must becreated are defined during the modular design. Also the operation performed by a functionis known from the analysis. The comment text of the function is initially the same as thetextual specification of the corresponding transformation. This comment must in most casesbe modified because the textual specification contains references to data and control fiows. Inthe pseudo code variables are used instead. These can be completely different although theyhave the same function. For example in the textual specifications there may be referencesto stores that represent queues. In the corresponding funetions are then references to pointervariables which point to an element of the buffer pool.

The control fiows that were defined during the analysis phase are not visible as such inthe design. Their function is incorporated in the calling sequences of the code. Also the statetransition diagrams are transformed into IF and WHILE statements. Only the interrupt handlerof the serial interface has its state transition diagram implemented with a state variabIe becauseit has four states and it must be possible to inspeet the state of the handler for debuggingpurposes.

The pseudo code as supported by ProMod tends to become too detailed. This is becauseall flow control statements and all funetion calls are included in the code. The code of the

- 41 -

firmware consists alrnost completely of flow control and function calls so the pseudo codeis about the same size as the source code. This is not what it should be [5, page 24] and itmakes the pseudo code less usefull as comment for the functions of the source code.

4.4.1 Synchronization between main program and interrupt handiers

The synchronization between the main program and the interrupt handlers is done on a uniformmanner for all handlers. The basic synchronization is incorporated in the access functionsof the queues. A queue is the shared variabIe between two parallel processes, an interrupthandler and the main program. The queue is protected against multiple access by disablingof interrupts. Every access function disables all interrupts at the start of the function andreenables them before returning. This is sufficient because there is only one processor on thedOeM board. In fact this disabling and enabling of interrupts is not needed for the highestpriority interrupt handler, but it is done to make changes easier.

When an interrupt handler trys to write to a full queue or read from an empty queue,it must be blocked. This is done by masking the interrupt belonging to the handler. Theinterrupt is masked by the queue access function. This function then returns to the interrupthandler indicating that the operation was not successful. The interrupt handler then sets theinterrupt pending flag, marks that the operation was not successful and returns.

At the moment when the blocking condition disappears, the interrupt mask is deared bythe queue access function. As a result of this an interrupt is generated because the interruptpending flag is set. The interrupt handler then retries the read or write operation. lt does thisbecause the mark of unsuccessful return was set.

The situation for the main program is a little easier. If a read operation is not successfulthe queue access function either returns to the main program or loops until the operationcan be executed with the interrupts enabled. What is done depends on the fact if the mainprogram can succeed with other work or not.

There is only one place in the firmware where a write to a queue can be unsuccessful.This place is the queue between the interrupt handler that receives messages from the VMEside, and the main program. The number of messages in the queue may not exceed a fractionof the total number of buffers in the buffer pool. This is necessary because otherwise adeadlock situation may occur in which the main program can not read messages from thehost anymore because it waits on a free buffer to succeed.

This restriction is sufficient to prevent deadlock because the number of buffers used forthe rest of the firmware has a fixed maximum. The only exception is the queue with messagesfor the VME side but this last queue can always become empty as long as the VME sidekeeps reading messages.

4.5 Coding and testing

The coding of the firmware in PL/M-51 was straight forward because the pseudo code is verydetailed. Only the symbolic constants required more thinking because the pseudo code doesnot support global constants. During the coding it became dear that some functions shouldbe split because they became too large. If the source code of a function didn 't fit on a single

- 42-

sheet of paper, the function was split. These changes were also incorporated into the pseudocode and the modular design.

The testing phase was started by creating a small test program to test the hardware ofthe dDCM804 board. This was a very simple program. First it turned the green led onthe front panel on and off with a frequency of one Hertz. Aftel' that it copied bytes fromthe HosuransmiLbuffer to the Host.xeceive-buffer. But before this program could be runthe jumpers on the board should be in the right position. 1t took a long time before theright position of the jumpers was selected from the documentation because there were manyjumpers and the documentation was not very clear about it. The positions are shown inappendix B.

During this test it became clear that the hardware was operating but there were someerrors in the documentation. The polarity of the red led on the front panel was wrong; Ü aone is written to the output port the red led is on. Also the bits of the fifo status/reset registerwere on other positions as specified in the documentation, see appendix C. The interfaceregisters on the VME side were read and manipulated with the help of the monitor programPMON68K.

4.5.1 ModlIlar test phases

The testing of the firmware was guided by the modular design and the analysis phases. Everytime an increasing number of modules was tested. This was done according to the buildmethod. A complete path in the module hierarchy from top to bottom was chosen. Functionsneeded from other modules were replaced by dummy ones. Which modules to choose wasguided by the data flows of the analysis phase. See figure 4.4 for a very simplified data flowdiagram of Network.manager.

Duting the testing extensive use was made of the available Intel deve10pment system withits In-Circuit Emulator for the 8044. This device can emulate the 8044 processor. With thehelp of it the memory of the processor and the board can be examined and modified. Alsothe program can be downloaded from the development system into the In-Circuit Emulator.This saves the time of programming the EPROM version of the 8044 aftel' every change ofthe firmware.

Phase 1: First the path from the VMEbus buffer to the central node and back was tested, seefigure 4.5. The central node was replaced by a dummy one. For this and subsequenttests a special test program on the VME side was created. With the help of this programmessages could be assembied from information typed at the keyboard, and transmittedto the firmware. Also this program could read messages from the firmware at the sametime and display them on the terminal.

While testing several errors were detected. One error was that the buffer pool wasdeclared too large, so some buffers were declared outside the available RAM area.Also there were some errors in the queue handling functions. This were errors in thepointer manipulation. An annoying problem was the exchange of the interrupt handlersfor the VME interrupts. Extensive checking of the task synchronization by the queuehandling functions was done. There was no error detected during this test.

- 43 -

VMEI----t~

but.

VME.....--l

but.

Seri I.....----.t

inter ace

Figure 4.4: The simplified data flow diagram.

VMEI----I~

but.

VME~--tbut.

Figure 4.5: Test phase 1.

- 44 -

Phase 2: For the next test the dummy central node was replaced by the module Han­dle_control...message and the slave data base, see figure 4.6. The pUIpose of this test was

VMEI----I~

buf.

VME ,....--;buf.

Slave data

Figure 4.6: Test phase 2.

the testing of the control message handling. In particular the reading and modifying ofthe slave data base was important for the further tests. Only a small problem with theslowand fast list of slaves was detected.

Phase 3: Test phase 3 consisted of a test of the complete firmware with the exception ofthe interrupt handler for the serial line, see figure 4.7. The operation of this handlerwas manipulated by typing commands at the terminal of the In-Circuit Emulator ofthe 8044. With this device the frames created by the firmware were examined. Alsoresponse frames were created by it.

Many minor errors were detected during this test. Also one hard to find error wasdetected. lt was noticed that after some time the system started reacting strange. Thebuffer pool was inspected and it was discovered that there was a buffer on the free listwith the link pointer pointing to itself. The reason could be that a message was put onthe free list twice. After a few days searching the error was spotted, at some place amessage should be copied but the pointer to it was copied instead.

Also an error in the handling of the sequence numbers was detected. The sequencenumber for the frames sent, was incremented when a frame (1, RR or RNR) wasreceived. This happened independent of the fact if there was an unacknowledged framesent to the slave.

- 45 -

VMEI----t~buf.

VMEt-.----l

buf.

Figure 4.7: Test phase 3.

Phase 4: Finally the complete finnware was tested, see figure 4.4. For this pwpose a slavecomputer was connected to the DCM board. This didn 't work the fust time. 1t wasdiscovered that a frame was transmitted to the slave board but none returned. Thereason was that the wrong version of the slave software was installed on the board.After fixing this bug all things seemed to work but a closer look showed that noacknowledge frames were transmitted to the slave. This bug could be fixed easily. Noerrors were detected after that.

4.5.2 Test results

From the following it should be clear that although a structured method was used to developthe firmware, its design was not free of errors. Most errors had their origin in the design ofthe pseudo code. The errors were mostly of a "low level" e.g. wrong pointer manipulation.

Also a few errors were caused by a wrong translation from pseudo code to source code.This translation was done by hand because there was no translation program available thattranslates ProMod pseudo code into PLfM-51 source code. For other source languages thisprogram exists. Such program would have reduced the number of errors a little, but notmuch. During the automatic transformation only the declarations and flow control statementscan be translated. The other statements must be translated by hand.

The total test of the firmware took about four weeks. This is only a short time comparedto the total development time of the firmware. This time was so short because there were nofundamental errors in the design as a result of the analysis phase.

- 46 -

Chapter 5

ERM Bitbus driver

The ERM Bitbus driver is the interface between the application tasks at the VME side and thefinnware ofthe DCM board(s), see figure 5.1. lt deals primary with the Network & Transponlayer of the communication. As such it has 10 handle the error recovery.

There may be many application tasks at the VME side that want to sent order messagesto the slaves, but their is only one task that receives orders from the slaves. This is becausethe destination task field of an order message coming from a slave is not filled in.

There may also be up to eight DCM boards in the system. lt is the function of the driverto ensure that all these boards together behave like one board with all the slaves connectedto it.

The driver can be split into four pans, see figure 5.2. Every pan has a distinct functionto perform, there is a very loose coupling between the pans. The two right transformationshandle the assembling and disassembling of messages. The two left transformations handlethe message administration and error recovery. The function of every transformation is thefollowing:

Administer_orders1rom..slave This transformation is responsible for the administration ofthe order messages that come from the slaves and the reply messages that go to theslaves. A pan of this administration is the error recovery, see section 2.4.2. When anorder message enters the transformation, a copy of it should be made. After that themessage should be forwarded to the application task that is responsible for the handlingof orders from the slaves. A little later the application creates a reply. A copy of thatmessage should also be stored.

The copy of OOth messages should be kept in storage until a new order message isreceived from the same task on the same slave. Because in the current slave applicationthere is only one task that can send messages, the above rule means that the messagesshould be stored until a new order message from that slave arrives.

In case there is an error and a slave is switched offiine by the firmware, this shouldbe signalled to the transformation Administer_orders-from_slave, indicating the slaveinvolved. The transformation Administer_orders_to..slave should now do some actiondepending on the next order message received from the slave.

1. If the message is a reset message, the message should be forwarded to the appli­cation but no copy should be made. The reply message should be discarded that

- 47 -

Replies toslaves - - Byte s t 0 Host

interI~a~c~ë~__~tranim tbuffer

Host transmit /buffër empty ;;- ........

Host receive............ bUffër_full -

" \

Hostrece!vbuffer -

LEVEL:

PROJECT: Driver

Bitbus driver

LAS::: UPDATE:

LAST ANALYSIS:

22-AUG-1988 09: 11

22-AUG-1988 09:13

Figure 5.1: The Context Diagram of the ERM driver.

is created by the application for this message. The transformation should stay inthe same state as before.

2. If a message is received that is the same as the message stored and there is a copyof the corresponding reply, then the order message should be discarded and thereply transmitted to the slave.If there is no copy of the corresponding reply, then the order should sirnply bediscarded. In this case the application has already received the order but hasno reply created. After this actions the transformation should continue norma!operation.

3. In case an other message is received, it should be handled as norma! and norma!operation should continue.

Administer_orders_to..slave This transformation must watch over the correct handling ofmessages by the slaves. If an application task. on the master sends an order messageto a slave, this transformation should mark the time of sending and and forward themessage. When the reply is received for that order, the mark should be deleted andthe reply send to the application. If there is no reply for an order message within aspecified time, a reply message must be created by this transfonnation indicating theerror.

If a slave is marked as offline in the database of this transformation all messages forit must be rejected with an error reply. A slave is switched back online by a control

- 48 -

LEVEL: 0

PROJECT: Driver

ERM driver

LAST UPDATE:

LAST ANALYSIS:

...... - - - -Hoat tranamitbuffir_empty -

!loet reeeivebuffër full -

.= - -

22-AUG-198ó 09:13

22-AUG-1988 09:13

Figure 5.2: The specification of the ERM driver.

message from the application. This message must also he forwarded to the finnwarebecausse in the database of the finnware it must also be switched online.

Control messages that is messages which have a slave node address of zero, are dividedinto two groups. The fust group is handled by this transfonnation while the secondgroup is handled by the finnware. Messages of the second group should also beforwarded to the fumware.

TransmïLmessage_to_board The function of this transfonnation is to distribute the messagesamong the interface boards and send the messages across the fifo buffer. The boardwhere the message should be send to, is seleeted from the slave node address in themessage. The highest three bits indicate the board number. If the slave node address iszero (a control message), the board numher is extraeted from the fust databyte of themessage.

Receive.message.1rom_board This transfonnation should reads the bytes from the fifos ofthe boards and assembie them into messages. All slaves conneeted to all boards havedistinct address so there is no need to place the board number in the message. A secondfunction of this transfonnation is to divide the messages in order and reply messagesand send them to the correct transformations.

The information in this chapter should he a starting point for a complete analysis anddesign phase.

- 49 -

Chapter 6

Results and recommendations

The fust pan of this project, the analysis, design and implementation of the firmware iscompletely finished. For the second pan of the project, the driver, the requirements arespecified and the analysis phase is staned.

During the project the tooI ProMod was used for the analysis and design. The useof the struetured analysis and structured design methods speeded up the coding and testingconsiderably. It took only fourweeks to debug and test the complete firmware. The design wasalso done within a reasonably short time. Most of the time was spent during the specificationof the user requirements and the analysis. During the specification of the user requirements,the specification of the error recovery scheme was the most difficult point. The analysis ofthe firmware lasted about three months.

The structured methods resulted in a division of the firmware in 13 modules with clearlyspecified interfaces and functionality. A large advantage of the structured methods is theextensive documentation. The use of this method forces you to write things down explicitly.Large analysis and design reports are generated by ProMod from this information.

It is possible to use standard Intel Bitbus slave boards with this software. In that case,all slaves should operate at 375 Kbit per second. Also the length byte of a message shouldbe in accordance with the Intel standard. If this requirements are fulfilled Intel slaves canbe mixed with VTS slaves when using the DCM board. The application software should ofcourse be suitable for it.

It is possible to use the spare hardware timer of the processor as a watchdog timer for thefirmware. This timer could be used to initiate a reset routine when the timer is not restanedbefore it expires. This restarting could be done in the main loop of the main program. It isan optional thing which can be added later, it is not implemented yet.

The firmware has a possibility to tune the interface with the VME side, so the interrupthandler for it is called less frequently. This should also he done for the interface routines inthe driver. In this way the performance of the interface can be optimized, which improvesthe performance of the firmware. The interrupt handlers for the VME side have the highestinterrupt rate because in the worst condition an interrupt is generated for every byte transfered.The interrupt handler for the serialline is only activated once for every frame transmitted orreceived.

Becausse the requirements of the driver are already specified it will not take very muchtime to implement the driver. Also the analysis phase is already staned.

- 51 -

References

[1] Vijay Abuja,Design anti Analysis of Computer Communication Networks,McGraw-Hill Book Company, New York, NY, USA,Second printing 1986, ISBN 0-07-Y66161-8

[2] M. Curley,SLQ-8044 Communication Software in CIMphony environment,Philips CFf CAM-Centre, Eindhoven, The Netherlands,September 1986, CTB 86.66.190

[3] J.G. van den Hanenberg, GJ. Mulder,Documentation of Software, Software Unit Development Folder,Philips CFf CAM-Centre, Eindhoven, The Netherlands,CFf Note 056/83 EN

[4] Bob Koehler,8051 Single-Chip Microcomputer Architectural Specification anti Functional Description,Intel Corporation, Microcontroller Product Marketing,3065 Bowers Avenue, Santa Clara, CA, USA,May 1980, Order No. AFN-01488A

[5] M.C. Mandos, J.G. van den Hanenberg, J.W. Brands,CAM Software Engineering Reference Manual,Philips CFf CAM-Centre, Eindhoven, The Netherlands,CFf Report 26/86 EN

[6] Tom de Marco,Szructured Analysis anti System Specification,Yourdon Inc., 1133 Avenue of the Americas, New York., NY, USA,1978, ISBN 0-917072-07-3

[7] A. v.d. Pol,CIMPHONY Pilot Specification,Philips CFf CAM-Centre, Eindhoven, The Netherlands,December 1986, CTB 87.67.009

[8] A. v.d. Pol, A. v.d. Klooster,VTS System Software,

- 53 -

Philips CFf CAM-Centre, Eindhoven, The Netherlands,June 1986, Internal confidential report

[9] Paul T. Ward, Stephen J. Mellor,Structured Deve/opment Jor Real-Time Systems,Volume 1: Introduction & Tools,Yourdon Press, 1501 Broadway, New York, NY, USA,1985, ISBN 0-917072-51-0

[10] Paul T. Ward, Stephen J. Mellor,Structured Development Jor Real-Time Systems,Volume 2: Essential Modelling Techniques,Yourdon Press, 1501 Broadway, New York, NY, USA,1985, ISBN 0-917072-52-9

[11] The Bitbus Interconneet Serial Control Bus Specification,Rev. A, Original Issue, January 1984,Distributed Control Modules Databook, p 51-102,Intel Corporation, Literature Department,3065 Bowers Avenue, Santa Clara, CA, USA

[12] CAM-centre aims anti tasks,Special Issue CAM Messages - April 1988,Philips CFf CAM-Centre, Eindhoven, The Netherlands

[13] dDCM 804, VME bus to Bitbus interface module, Users manual,Version June 1987,DATEM ltd., 148 Colonade Road, Nepean, Ont., Canada

[14] Embedded Real-Time Monitor System, Users manual,Version 31 august 1987, Pan No. 4822 874 20498,Philips Industial & Eleetro-acoustic Systems Division,Eindhoven, The Netherlands

[15] IBM Synchronous Data Link Control, General Information,International Business Machines Corporation,GA27-3093-2, File No. GENL-09

[16] Microcontroller Handbook 1984,Intel Corporation, Literature Department,3065 Bowers Avenue, Santa Clara, CA, USA,Order No. 210918-002

[17] PL/M-51 User' s Guide,Revision 003, November 1983,Intel Corporation, Literature Department,3065 Bowers Avenue, Santa C1ara, CA, USA,Order No. 121966-003

- 54 -

[18] Prefered Hardware and Software Componentsfor CAM Production Control Systems,Version December 1985,Philips CF!' CAM-Centre, Eindhoven, The Netherlands,CF!' Repon 23/85

[19] ProMod Computer Aided Software Engineering, Users manual,Version V1.6_1, March 1988,GEI - Gesellschaft fiir Elektronische Informationsverarbeitung m.b.H.,PascalstraBe 14, Aachen, West Germany

- 55 -

Glossary

8044 Single chip microcomputer fabricated by Intel, and member of the 8051 series micro­controllers.

Bitbus Standard for aserial multi-point communication protocol based on the SDLC datalinkprotocol with a message structure on top of it.

CAD =Computer Aided Design. Design with the help of computer tools.

CAM =Computer Aided Manufacturing. The effective utilization of computer technology inthe control and operation of manufacturing facilities by direct computer interface withthe human and physical resources of the manufacturing organisation [12, page 5].

CIMphony Pilot assembly line at the CFf to show an implementation of the CAM referencemodel.

DCM board Interface board between the Bitbus and the VMEbus.

dDCM804 Same as DCM board.

DISC frame Frame send by the master at datalinklevel to bring a slave in Normal DisconnectMode (NDM).

DM frame Frame send by the slave at datalinklevel to indicate that the slave does not wantto participate in the connection.

DMA =Direct Memory Access. The transfer of data from a peripheral device to the RAMmemory or in other direction, without the intervention of the central processing unit.

Datem Company in Canada which sells the DCM interface board.

Driver A piece of software on top of the operating system which interfaces directly with thehardware of a peripheral device.

ERM =Embedded Real-time Monitor. Real time operating system supplied by Philips.

FIFO =First In, First Out. Buffer in which the item that goes in fust also is taken out fust.

FRMR frame Frame send by the slave at datalink level to indicate that some error wasdetected.

Firmware Part of the software that is permanent sited on the interface board.

- 57 -

Flow Control flow or data flow, indicates during tbe analysis tbe movement of informationin tbe system.

I frame Frame send by tbe master and tbe slave during normal operation. This frame containstbe real infonnation that must be transfered.

ICE44 =In-Circuit Emulater for tbe 8044. Device tbat replaces tbe processor and emulatesits operation. This operation can be manipulated and inspected from a terminal.

IPC-Sl Single board computer fabricated by Philips and used as local controller of tbeVarlable Transport System.

Interrupt Asynchronous event generated by tbe hardware used to initiate special action bytbe software.

MBA 844 Interface board between tbe Bitbus and tbe Intel Multibus.

Master Computer which controls tbe acces to tbe serial line. Tbe otber computers connectedto tbe line may only send information when requested by tbe master.

Microvax Computer used as routeing controller in tbe CIMphony project.

NDM = Normal Disconnect Mode. State of tbe slave in which it can not send information.

NRM =Normal Response Mode. State of tbe slave in which it may send and receiveinformation. This is tbe normal state.

Node Same as Transformation, a symbol used to model during tbe analysis an operation ontbe data.

Online State of a slave indicated by tbe database of tbe Bitbus Handler. In this state messagescan be send to tbe slave.

Omine State of a slave indicated by tbe database of tbe Bitbus Handler. In this state nomessages can be send to tbe slave.

Order One of tbe two messages defined in tbe network and transport layer of tbe Bitbusspecification.

PLIM-Sl Programming language defined by Intel to program tbeir 8051 series microcon­trollers, a subset of PL/M.

Polling Waiting on a certain event to happen by constant testing.

ProMod A program which supports tbe use of structured analysis and design metbods.

RNR frame Frame send by tbe master or tbe slave to indicate tbat tbey are in NormalResponse Mode but at tbe moment tbey can not receive an information frame.

RR frame Frame send by tbe master or tbe slave to indicate tbat tbey are in Normal ResponseMode and tbat they can receive an information frame.

- 58 -

RS485 Standard used at the physicallayer of the Bitbus specification. The standard definesa differential driver and receiver for a multi-point line.

Reply A message as defined by the Bitbus standard and send as a response on the receipt ofan order message.

SDLC =Synchronous Data Link Control. A protocol at data link level defined by IBM.

SLQ board An interface board used to connect the Microvax to the Bitbus.

SNRM frame =Set Normal Response Mode. A frame send by the master to bring the slavefrom Normal Disconnect Mode into Normal Response Mode.

Slave A computer connected to the serialline but which has no control of that line. It mustwait before sending information until the master gives permission to send.

Store A symbol used during the analysis phase to model the temporary deposition of data.

Transformation Same as Transformation, a symbol used to model during the analysis anoperation on the data.

UA frame A frame send by the siave at datalink level as a response on every frame exceptan RR, RNR or 1 frame received from the master. This frame is send only when thereis no error.

VME The VMEbus is an parallel computer backplane bus for connecting the boards insidea computer.

VTS = Variabie Transport System. A modular system to move products through a factory.

- 59 -

Appendix A

Predefined Bitbus messages

For a proper operation of the communication a set of standard messages are defined.

A.I Messages from Bitbus-handler to application

• A reset message from slave to master.

Length:Type:Command:Data (l byte):

08hOrderODOhOOh Power up reset, battery correctOIh Power up reset, battery failed02h Manual reset03h Communication line reset

lbis message is used by the slave to infonn the application on the master over thereason of its reset. The Bitbus-Handler has to distinguish this message from othermessages.

• A slave offiine message from the Bitbus-Handler to the application on the master.

Length:Type:Slave node:Command:Data (Byte 1):

09hOrderOOh (Bitbus-Handler)OFlhOIh Tlffie-out on datalink level02h Tlffie-out on message level03h Invalid I field in frame04h Slave's receive count invalid05h Message too short06h Message too long07h Node in frame unequal to node in message08h Frame reject - Invalid command

- 61 -

Data (Byte 2):

09h Frame reject - Prohibited I fieldlOh Frame reject - I field too longUh Frame reject - Slave's send count incorrectl2h Frame reject - Unknown reasonl3h Slave not ready after several retriesl4h Slaves send count invalidl5h Received controlbyte of frame illegalSlave node address of slave involved

This message is used to inform the application when a slave goes of:fline.

• Reset message from the Bitbus-Handler to the application on the master.

Length:Type:Slave node:Command:Data (l byte):

08hOrderOOh (Bitbus-Handler)OFOhBoard nurnber

This message is created by the Bitbus-Handler to inform the application on the masterthat a DATAM dDCM804 board is reset.

A.2 Orders to the Bitbus-handler

• Cornrnand to switch slave to online form the application on the master to the Bitbus­Handler.

Length:Type:Slave node:Command:Data (1 byte):

08hOrderOOh (Bitbus-Handler)OlhSlave node address of slave to switch online

With this command the Bitbus-Handler is ordered to switch the requested slave online.A reply message is created by the Bitbus-handler to return the status of the operation.

• Cornrnand to read the slave data base for one slave as stored on the dDCM804 board.

Length:Type:Slave node:Command:Data (1 byte):

08hOrderOOh (Bitbus-Handler)02hSlave address

- 62 -

With this command the Bitbus-Handler is ordered to return the slave data for therequested slave in the rep1y message. The contents of the rep1y message are:

Length:Type:Slave node:Status:Data (Byte 1):Data (Byte 2):Data (Byte 3):Data (Byte 4):Data (Byte 5):Data (Byte 6):Data (Byte 7):Data (Byte 8):Data (Byte 9):

lOhRep1yOOh (Bitbus-Handler)OOhSlave stateSend sequence numberReceive sequence numberRetry countPointer to remembered messagePointer to remembered messageSlave SDLC addressAddress of next slave in list modulo 32Address of previous slave in list modulo 32

• Command to return the state of the serial intenupt handler to the application on themaster.

Length:Type:Slave node:Command:Data (1 byte):

08hOrderOOh (Bitbus-Handler)03hBoard number

With this command the Bitbus-Handler is ordered to return the state of the serial inter­rupt handler in the rep1y message.

Length:Type:Slave node:Status:Data (1 byte):

08hRep1yOOh (Bitbus-Handler)OOhOOh State =Idle01h State =Transmitting02h State = Receiving03h State =Transmitting_acknow1edge

• Command to order the Bitbus-handler to show the contents of one message of its intemalbuffer pool.

Length:Type:Slave node:Command:

lOhOrderOOh (Bitbus-Handler)04h

- 63 -

Data (Byte 1):Data (Byte 2):Data (Byte 3):

Board numberBuffer number MSBBuffer number LSB

The contents of the buffer are returned in the repIy message as far as it fits.

Length:Type:Slave node:Status:Data (Byte 1):Data (Byte 2):Data (Byte 3):Data (Byte 4):Data (Byte 5):Data (Byte 6):Data (Byte 7):Data (Byte 8):Data (Byte 9):Data (Byte 10):

Data (Byte 27):

22hRepIyOOh (Bitbus-Handler)OOhBuffer controlbyteBuffer SDLC addressBuffer SDLC controlbyteBuffer message IengthBuffer identification (order / repIy)Buffer node addressBuffer task identificationBuffer message codeBuffer data byte 1Buffer data byte 2

Buffer data byte 19

• Command to show the number of free buffers on the dDCM804 board.

Length:Type:Slave node:Command:Data (1 byte):

08hOrderOOh (Bitbus-Handler)05hBoard number

With this command the Bitbus-Handler is ordered to count the number of free bufferson the dDCM804 board. The number is returned in the repIy message.

Length:Type:Slave node:Status:Data (Byte 1):Data (Byte 2):

09hRepIyOOh (Bitbus-Handler)OOhNumber of free buffers (MSB)Number of free buffers (LSB)

• Command to change the sIave data base.

- 64 -

Length:Type:Slave node:Command:Data (Byte 1):Data (Byte 2):Data (Byte 3):Data (Byte 4):Data (Byte 5):

OChOrderOOh (Bitbus-Handler)06hSlave addressSlave stateSend sequence numberReceive sequence numberRetry count

With this command the Bitbus-Handler is ordered to change the slave data base for therequested slave. A reply message is created by the Bitbus-handler to return the statusof the operation.

• Command to change Max-receive_polls.

Length:Type:Slave node:Command:Data (Byte 1):Data (Byte 2):

09hOrderOOh (Bitbus-Handler)07hBoard numberNumber of polls

This command changes the number of times the VME computer is polled for databefore leaving the interrupt handler. A reply message is created by the Bitbus-handlerto return the status of the operation.

• Command to change Max..send_polls.

Length:Type:Slave node:Command:Data (Byte 1):Data (Byte 2):

09hOrderOOh (Bitbus-Handler)08hBoard numberNumber of polls

This command changes the number of times the VME computer is polled for roomin the buffer before leaving the interrupt handler. A reply message is created by theBitbus-handler to return the status of the operation.

The status byte in the reply message may have the following values, see table A.l

- 65 -

Code SpecificationOOh No error40h lllegal message size4lh Parameter out of range42h Slave not in NRM state43h Slave not connected to this board9lh Slave offiine92h Message too long93h No destination device94h Database fuil95h Message too short96h Unknown command97h Time-out on reply message

Table A.I: Return codes from Bitbus-handler.

- 66-

Appendix B

Jumpers on the dDCM804 board

Table B.l: Jumpers on the dDCM804 board.Jumper Setting FunctionJOl IN IN =No isolationJ02 NONE EPROM/RAM site 3J03 OUT IN =16K EPROM in site 1 at address COOOJ04 OUT IN = 16K RAM in site 2J05 OUT EPROM/RAM site 3J06 IN IN =Supervisor only short 110 address cyclesJ07 OUT IN =No optica! isolators usedJ08 OUT IN =No optica! isolators usedJ09 OUT IN = No optica! isolators used110 A A =Power fiom board111 IN IN =120 ohm standard line termination (R17)112 IN IN =No repeaters used113 NONE Program/Random option site 3114 NONE EPROM/RAM site 3115 BD BD =Optica! isolators used116 B B =Self clocked117 IN IN =No repeaters used118 BD BD =Optica! isolators used119 IN Software120 IN SoftwareJ21 OUT Software122 OUT SoftwareJ23 - Not present124 - Not presentJ25 - Not presentJ26 - Not present

- 67 -

Table B.1: Jumpers on the dDCM804 board. (Continued)Jumper Setting FunctionJ27 B B := RTS-I/O self clockedJ28 - Not presentJ29 OUT Software130 IN Software131 IN Software132 IN Software133 IN Software134 IN Software135 IN Software136 IN Software137 OUT IN := Power from board to Bitbus138 OUT IN := R26 line termination resistor139 IN IN := No isolationJ40 IN IN := No isolationJ41 IN IN := Power from +12V VME-busJA01 IN Interrupt level, IN = 0JA02 OUT Interrupt level, IN = 0JA03 IN Interrupt level, IN = 0JA10 IN Base address, IN = 0JA11 IN Base address, IN = 0JA12 IN Base address, IN = 0JAl3 IN Base address, IN := 0JA14 IN Base address, IN = 0JA15 IN Base address, IN = 0

- 68 -

Appendix C

Register map on VME side

Table C.l: The registers and their addresses.Address RegisterXX8l Status/Control registerXX83 Interrupt Acknowledge Vector registerXX85 Data Byte FIFüXX87 Command Byte FIFüXX89 FIFü StatusJReset register

Table C.2: Bits of Status/Control register.Bit Status Control0 Diagnosric LED (red) -1 Diagnosric LED (green) -2 Interrupt pending -3 Interrupt enable Interrupt enable4 Transmit Interrupt pending -5 Transmit Interrupt enable Transmit Interrupt enable6 Receive Interrupt pending -7 Receive Interrupt enable Receive Interrupt enable

- 69 -

Table C.3: Bits of FIFa Status!Reset register.Bit Status Reset0 Transmit FIFa Empty -1 "1" -2 "1" -3 "1" -4 Receive FIFa Full -5 Receive Command -6 "1" -7 "1" Software Reset

- 70 -

Appendix D

Differences between Intel Bitbus and VTSBitbus

There are some differences between the Intel Bitbus message structure and the messagestrueture as used by the VTS system. The points mentioned below are based on the IntelBitbus standard [11] and some papers of Machine Fabriek Alkmaar regarding the MBA 844interface board. This board is the interface between the Multibus based master and the Bitbus.The remarks below refer to version 1.0 dated 15 july 1987 of the finnware on that board.The documentation about it was dated 11 june 1987. On the IPC-51 slave controllers version5.1 of the finnware was used.

• According to the Intel standard only the master may send order messages and the slaveonly sends replys. This means that the master only has to poll slaves at datalink levelthat have received an order but have not send a reply yet. For the other slaves there isno need to send a message.

In the VTS system both the master and the slaves may send order messages and replymessages. So at datalink level all slaves must always be polled.

• The fust byte of every message indicates the length of that message. This byte containsin the Intel version the total number of bytes in the message plus two. In the VTSversion the byte contains the total number of bytes in the message. There is also adifference of two in the length byte.

• The type byte of a message is also different for the two versions. In VTS this bytecontains the value 00 if the message is an order and the value 80 (hex) if it is a reply.Intel uses only the most significant bit (bit 7) to indicate if it is an order or a reply.Bit 4 is the track bit used to provide message control at the master or the slave. Bit5 is the destination extension bit. This bit indicates when one that the destination ofthe order message is on the extension board of the destination node. In case of a replymessage it indicates that the source was on an extension board. Bit 6 is the same asbit 5, only for the other side of the transmission. Bits 0 to 3 are zero.

• In the Intel standard the source task field and the destination task field contain tasknumbers. In the VTS system these numbers are used to indicate buffer numbers.

- 71 -

• The Intel standard specifies a self c10cked mode of 375 Kbits per second while the VTSsystem operates with 355 Kbits per second. The newer versions of VTS also operatewith 375 Kbits per second.

The Intel standard only defines a message structure. There is no specification of an errorrecovery protocol at the network and transport layer. Also the existing VTS system does errorrecovery at application level. The error recovery was inc1uded to enhance the performanceof future systems.

- 72 -

Appendix E

Analysis report of firmware

This appendix contains the software analysis repon of the finnware generated by ProMod.

****************************************************************

Nederlandse Philips Bedrijven B.V.CFT Centre For manufacturing Technology

CAM CentreEindhoven - The Netherlands

*****************

AcronymName of moduleProduct/Project12NCGroup numberCreation dateModification dateDocument languageProgram languageStatusName author

Bitbus *SA REPORT *Bitbus firmware and drivers for VME-bus *8122 967 79??1 *191 ( Analysis Report (RA&D) *1987-09-01 *1988-08-17 *010 (English) *ProMod Vl. 6 *Preliminary *P . E . J. Boonen *

******

* Copyright (C) N.V. PHILIPS' Gloeilampenfabrieken 1987. All ** rights are reserved. Reproduction in whole or in part is ** prohibited without the written consent of the copyright owner*****************************************************************

- 73 -

SYSTEM HIERA.RCHY •••••.••••••••••••••••••••••••••••••••••••••PROBLEM DESCRIPTION Bitbus firmware ......•.••..•..•••.••..•PO Bitbus firmware .

MSP Network_manager ..••...•..•.•.••••.••....••...•••.•••••PO Network_manager .

MSP Network control and conversion •••••.•.•.••••.•••.•••.•MSP Transmit receive frame ••••.••.••.••..•.••.•••..•.•.•••MSP Receive_message_from_host ..•..•..••••.•••.••••••.•••••MSP Transmit_message_to_host ...••••••••••..•••••••.•.•.•••

FD Network control and conversion •••••.••••••••••••••.•••.•- -MSP Prepare_frame .MSP Handle received frame •••••.•••••••.••.•••••••.••.•••••MSP Handle_control_message .••••••.•••.•.•..•••••.•••.•••••CS Network_control_and_conversion (Sheet 1) •.•••.••.•••••CS Network_control_and_conversion (Sheet 2) ••.•••.•.••.••

PO Prepare_frame .MSP Select slave .MSP Remove_unwanted_message .••••••••..•••••.••••.•••.•••.•MSP Calculate frame contents ••••.••••.••••••••••.•••••••.•- -CS prepare_frame (Sheet 1) •••••.••••.•••..•••••.•••..••••

FO Transmi t receive frame .MSP Transmi t frame to interface •.••••...••.••.....••.•••••- --MSP Receive frame from interface •••••.•••••.••••.••••••..•- - -MSP Transmit_acknowledge_frame••..•••.•.••..•.•...••••••••MSP Handle receiver timeout ...•.•.••...•..•.•.••.•.••.•.••- -CS Transmit_receive_frame (Sheet 1) •.•••.•.•••..••.•••••.

FD Receive_mes sage_from_host ......••••......•••••..•..•.•.•MSP Convert_bytes_into_message.•••••..••••..•••...••..••••CS Receive_message_from_host (Sheet 1) ••..•••••.•••••••.•

FD Transmit_message_to_host .•..•....•..•....•••••..••..•.••MSP Convert_message_into_bytes .••..•.•••••••••••.••••.•.••CS Transmit_message_to_host (Sheet 1) •.•..•.•.•••.•.•..••

DATA DICTIONARY ..••••..•.......•.....•.••••••..•••.••••.•.••ERROR!WARNING SUMMARY OF FLOW DIAGRAMS .•.••.•.•.•••.••••.••ERROR!WARNING STATISTICS .••.•..••..•••••......••.••••....••

757677787980808181828384848586878888888990919191919293949596979899

116117

I BitbusI SA REPORT

I P.E.J. Boenen

I 8122 967 79??1I Analysis Report

I Group 191 -PAGE 74I 1988-08-17 11:11

I CFT CAM Centre

SYSTEM HIERARCHY

Bitbus firmwareo Network_manager

1 Network control and conversion- -1.1 Prepare_frame

1.1.1 Select slave1.1.2 Remove_unwanted_message1.1.3 Calculate frame contents- -

1.2 Handle received frame- -1.3 Handle_control_message2 Transmit receive frame- -

2.1 Transmit frame to interface- --2.2 Receive frame from interface- - -2.3 Transmit_acknowledge_frame2.4 Handle receiver timeout- -3 Receive_message_from_host3.1 Convert_bytes_into_message

4 Transmit_message_to_host4.1 Convert_message_into_bytes

I Bitbus I 8122 967 7977.1 I Group 191 -PAGE 75 - II SA REPORT I Analysis Report I 1988-08-17 11:11 I----------------------------------------------------------------I P.E.J. Boonen I CFT CAM Centre I

PROBLEM DESCRIPTION Bitbus firmware

At Philips factorys there is a need for transportation systems.Components have to be transported to the assembly point, whileassernbled products have to be carried away. Philips has for thispurpose build the Variabie Transport System (VTS). Physicallythe Variabie Transport System consists of a track on whichproduct carriers move. The system is controlled by distributedmicrocontrollers connected by aserial multipc)int link, theVTS-Bitbus. All the controllers are under the control of theRouting Controller.

The computer that will be used as Routing Controller will be aVHE bus based computer. The hardware interface between that VHEbus based computer and the VTS-Bitbus is the dDC11804 Bitbus toVHE bus host adaptor. When nessecary, more dDCM804 cards can beplugged in the VHE bus based computer. Every board can controlone multipoint link.

The target of this work is building the firmware for the dDCM804board. The firmware on the board interfaces with the VHE sitewith the help of the host transmit and recei',e buffers. Itinterfaces with the multipoint link with the help of the serialinterface, built into the central processor on the board, theIntel 8044. It uses the timer for generating timeouts whennecessarily.

I Bitbus I 8122 967 79??1 I Group 191 -PAGE 76 - II SA REPORT I Analysis Report I 1988-08-17 11:11 I----------------------------------------------------------------I P.E.J. Boenen I CFT CAM Centre I

Ol....rt0­c111

IHl......,a~..,CV

Serialinterf ce

Transmit

Bytes to host

......

Host transmitbuffer full

Host receiveb u f fe rem p t;...y ?

- ~

ostransmuffer

HostreceIvbuffer

S"~lIJ N..... N'<11110.... 0'1111 -.I

:tl-.lCV 10'8 ·v·v.., .rt ....

n .... (;1"z:I 10'"1-3 000

OOc

~1'0

0Ol ....I 10

n ........CV -.I::J Irt 'ti.., :a-CV .... (;1

.... tz1..........-.I-.I

'ti tno:l· :a- ....tz1 rt· 0-~ I C· 111

8' :tltz1

::J ~CV :tl::J 1-3

Bitbus firmware

LEVEL: LAST UPDATE: 9-NOV-1987 14:09

PROJECT: Bitbus LAST ANALYSIS: 17-AUG-1988 11:11

MSP 0 Network_manager

The Network_manager has to pass messages coming from the hosttransmit buffer to the serial interface. It also has to passmessages coming frclm the SDLC interface to the host receivebuffer. For this F1urpose it has to poll the slave computersconnected to the serial interface by sending and receivingunnumberd, supervisory and information frames. It uses the timerfor generating tim~~uts when slave computers don't functionproperly or are none}:istent.

I Bitbus I 8122 967 79??1 I Group 191 -PAGE 78 - II SA REPORT I Analysis Report I 1988-08-17 11:11 I----------------------------------------------------------------I P.E.J. Boenen I CFT CAM Centre I

frame

frame

= - -

Timerint

Serial int

"""\ ,\

\

\

\

\

/

/

fr a m.e sI

I

I IIDisableLEnable

I timer Itimer

Iy

Received

Prepared_frames

...,.--Me s sage sto host -

I/

Bytes toost -

Host receivebuffer emptY-M ti- _ essages 0

- host queufi....... " not_empty -, ,/

Messages 1:romho st queue'not Tuil "\

Host transmitbuffer full

Bytes fromhost -

Ulb:l»0 ....

rt0'

I C11I

-II

"IjlI

P.I

c...

b:I

8I ::J

ID::J

Network manager

LEVEL: 0 LAST UPDATE: 17-NOV-1987 10:09

PROJECT: Bitbus LAST ANALYSIS: 17-AUG-1988 11:11

5. Itstateis asent to

MSP 1 Network control and conversion- --Network_control_and_conversion is the central node in theNetwork_manager. It has four functions:

1. It looks if there is a &Control_message_from_host. If thereis one, it performs the requested operation. Af ter that a&Reply_bitbus_message is created.

2. It decides which slave computer is the next one to handle.

3. If a slave is offline, it has toreject every non&Non_control_message_from_host for that sla"e. If the rejectedmessage is an order message, a &Reply_bitbus_rnessage is created,otherwise the message is discarded.

4. It prepares &Prepared_frames to send to thl~ slaves. The frametype depends on the state of the slave and the fact if there isa message waiting for that slave. Af ter that the actualtransmission is started with &Enable transmission.

receives &Received_frames and updates ~t's internal slavetables according to the kind of frame received. If theremessage in a frame or if there is an error, a message is

&Messages_to_host.

MSP 2 Transmit receive frame

Transmit_receive_frame is the node concerned with the handlingof the serial 5DLC interface.

1. It receives a &Prepared_frame from the ~iin message handlerand puts it in the serial interface by &Transrnit_frame.

2. Then it waits until a frame is received from the addressedslave. This &Receive frame is forwarded to &Received frame.

3. Also Transmit receive_frame is resposible for guarding theserial line. If afther a certain time af ter sending the framethere is no response from the slave, a timeout &Received_frameis generated and forwarded to the main message handler like areal &Received frame.

4. If a valid&Transmit_frameThis is donecomputer.

information &Receive frame is received, a RNRhas to be returned to that slave immediately.

to free the transmission l)uffer in the slave

The node is started with the &Enable_transmission signal andstays active until there is no frame to transmit.

I Bitbus I 8122 967 79??1 I Group 191 -PAGE 80 - II SA REPORT I Analysis Report I 1988-08-17 11:11 I----------------------------------------------------------------I P.E.J. Boonen I CFT CAM Centre I

The function of Receive_message_from_host is passing bytes fromthe transmission buffer to the &Message_from_host. The&Message_from_host has to be put in a linked list, implementinga queue. There is a queue for every possible slave in thesystem. The slave number is extracted from the &Bitbus_message.Every last byte from a message that passes the host interface ismarked with the command bit set in the buffer. There is noprotection against filling the whole queue w'ith messages for oneslave computer, this has to be done by the host.

The function of Transmit message to_host is passing the bytesfrom the &Message_to host to the receive buffer. The messagesare taken out of the queue in the same order as they were putin. The last byte of every message is rrerked in the receivebuffer by setting the command bit.

I Bitbus I 8122 967 79??1 I Group 191 -PAGE 81 - II SA REPORT I Analysis Report I 1988-08-17 11:11 I----------------------------------------------------------------I P.E.J. Boonen I CFT CAM Centre I

" 'Trigger \ "handle - \ 'controI Trigger \

,message \ prepare- I" ,frame I

:z:(1),.,.~..,;,;­

Ioo:;l,.,...,o~

IlIJ

,B-oo~(1)..,111....o:;l

\

\

I/

....

Frameprepared

Received frame

Prepared frame- ~

,

---

..... \

,

Control 1 t 1message/ / ,ha n d 1 e..d - I \ - - ->

,/ / I Enable", I No J transmIssio

Recei~'á_ recfive Jfra~ frame;-h-arîdlëd / /

", __ / / Trigger handle/ rece~vea frame

Network control and conversion

II

/ /

", --..- --r-s- - - -

Messages to hostqueue_nof_empty -

Non controlmessage from host

Messages_from_host_queue_not_full-e:-------------=:-,- _, ,

Control messagefrom host -

Message_to_host II

~~lIJ N~ N'<111 10.... 0'1111 .....

::ti .....(1) 10'0 ·Vo ·V.., .,.,. .....

n ..... G)"Ij 10'"t-3 Ol 0

OlC

~1'0

0Ol .....I 10n ..........

(1) .....:;l I,.,.

~..,(1) ..... G)

I ..... tz:II 00

I .....I .....I OlI NIII

-I

'ó tntll0 ):0 ....t':l ,.,.0 IJ'C-t I C

111

tlI ::ti0 t':l0 'ó:;l 0(1) ::ti:;l t-3

LEVEL: 1 LAST UPDATE: 17-AUG-1988 11:11

PROJECT: Bitbus LAST ANALYSIS: 17-AUG-1988 11:11

MSP 1.1 prepare_frame

The function of prepare_frame is:

1. It selects the next slave to poll based on the information in&Slave data.

2. Then it looks if there is a &Rernernbered_message for thatslave. Also if the selecte1 slave is offline, it has to rejectevery &Non_control_message_from_host for that slave.

3. Af ter that it prepares a &Prepared_frame to sEmt to theslave. The kind of frame depends on the state of thE~ slave asmarked in &Slave_data and th,e fact if there is a messaÇJe wai tingfor that slave in &Slave_dat,;l or &Non_control_message_from_host.Af ter that the actual transmission is started.

I Bitbus I 8122 967 79??1 I Group 191 -PAGE 83 - II SA REPORT I Analysis Report I 1988-08-17 11: 11 I----------------------------------------------------------------I P.E.J. Boonen I CFT CAM Centre I------------------------------~----~-~--------------------------

Handle_received_frame evaluates the &Received frame. Baseél onthe old &Slave_state and on the kind of frame received, the new&Slave_state and &Slave_online offline_indication is determi.nedand if needed som action taken.aId state I Received frame I New state I Action=====================================:=======================Go to NOM I UA_frame I NOM I

lOthers I Go_to_NOM I------------+----------------+------_._-----+----------------FRMRM I UA frame I NOM I

lOthers I Go_to_NOM I------------+----------------+------_._-----+----------------NOH I UA frame I NRM I

lOthers I Go_to_NOM I------------+----------------+-------------+----------------NRM I RR frame I NRM I

I RNR frame I NRM II I frame I NRM I Forward messageI Timeout I NRM timeout IlOthers I FRMRM I Slave offline

------------+----------------+------_._-----+----------------NRM timeout I RR frame I NRM I

I RNR frame I NRM II I frame I NRM I Forward messageI Timeout I Go to NOM I Slave offlinelOthers I FRMRM I Slave offline

If there is an error in a frame like a sequence error in thesend or receive count, then the new state is FRMRM and the slaveis switched offline. If the slave is switched offlinE! an&Order_bitbus_message is created telling this to the host.If the last frame sent is confirmed then the &Rernernbered_mes5/ageis deleted.With the act ion "Forward message" is meant that the&Bitbus_message which is in the information field of&Received_frame, is forwarded to &Message_to host.

HSP 1.3 Handle_control_message

The function of Handle control message is to perform theoperation requested in a &Control_message_from_host ifavailable. If there is a &Control_message_from_host it ischecked and af ter that, the execution of the requested operationstarts. A &Reply_bitbus_message is generated, telling whetherthe operation was succesfull. In this reply there may be be 5iomeinforrnation. This &Reply_bitbus_message is put i.nto&Message_to_host.

I Bitbus I 8122 967 79??1 I Group 191 -PAGE 84 - II SA REPORT I Analysis Report I 1988-08-17 11: 11 I------------------------------------------------------------_._--I P.E.J. Boonen I CFT CAM Centre I

'ti UlOl· > ....t'J rT· 0"~ I C· 111

Ol :;ti0 t'J0 'ti::s 0lil :;ti::s ~

Power on-

Trigger_handle control _message-

I Handling first control message I- - -

Control message handled

Trigger_prepare_ frame

I Preparing_ first frame I-

Frame prepared

Start regular operation- -

I Regular - operation I

Network control and conversion- - -

SHEET NO: 1 OF 2 LAST UPDATE: 09-FEB-1988 09:58

PROJECT: Bitbus LAST ANALYSIS: 17-AUG-1988 11:11

nUl

.....

,.......Ul::TlillilrT

oH'l

-II

'ti 1 U'IU1· I > .....tij I rt-· 0'C-l 1 t:· 111

UI ::ti0 tij0 'ti::s 0(\)

~::s

6"::::DJ N..... N'<111 10..... 0'1111 -..I

::tI-..I(\) 10'tl •."o •."., .rt- .....

n ..... G)"Ij 10"1-3 Q)O

Q)t:

~I 'tl

0Q) .....I 10n ..........

(\) -..I I::s I Irt- 'ti 1., > I(\) ..... G) I

..... tIj I.. I..... 1..... IQ) 10'1 I

I1 1

1--I

Start regular operation

Tri 61 er prepa~e_~rame-ena e fransm1ss1o,It -

~I Preparing_ frame II

Frame prepared

Trigger handle controlmessage=Enable- -

I Handling_control_message 1-I

Control message handled

Trigg er handlereCe1VeQ frame -

Received frame handled - No received frame

Trigger_prepare_ frame Trigger handleI Handling_received_frame I control=messageI I

Network control and conversion- - -

SHEET NO: 2 OF 2 LAST UPDATE: 24-JUN-1988 10:04

PROJECT: Bitbus LAST ANALYSIS: 17-AUG-1988 11:11

nU'I

2:(\)rt­~o.,I~o::srt­.,o.....'lil,&n

~(\).,111.....o::s

N

ol"1l

N

Prepare_frame

.....

.....

."..,m]...,m

IHl...,

~m

Preparedframe -

26-JUL-1988 10:03

\ Frame "-,contents )

,calculatëd, /

"- /,

Trigger calculate__frame contents--

LAST UPDATE:

Slave data

/ . f/ Tr1gger prepare rame

t<'\

\

\

\

"" ? ~ \/'

/'. Triggèr....Tr1gger select,-

/' remove -I 1 ­,/ ,/ unwantëq save \

message I ISlave

\selected 1/

/

/

~Frame_prepareC\

/

I

I

\

\

Unwantedmessage ­removecY"--

,/

..- - -Messages to hostqueue_not_empty -

Rememberedmessage

Messageto host-

Messagesfrom hostqueuenot full""l{--_

/'

Non contromessagefrom host

LEVEL: 1.1

S'~lIJ N~ N'<lil \0.... 0\lil .....:;0 .....m \0

'U ·vI o ·v..., .

rt .....

n ..... G"l~ \0""t-3 000

OOt:

~I'U

000 .....I \0n ..........

m .....::l Irt ."..., )00m ..... G"l

..... t':I.. I..... I..... I00 I..... I

II I

I--I

-I --II I

." til IJl I)00 .... I

t':I rt I. 0- Ic... I t: I. lil I

IIJl :;0 10 t':I I0 ." I::l 0 Im

~I

::l I

PROJECT: Bitbus LAST ANALYSIS: 17-AUG-1988 11:11

MSP 1.1.1 Select slave

The function of Select_slave is to select the next slave topoll. It does 50 based on the information in &Slave state. Firstall slaves are polled which are in NRM, NRM_timeout, NDM orFF~ mode, then one slave is polled that is in Go to NDM mode.

The function of Remove_unwanted_message depends on the state ofthe slave and the fact if there is a &Remember~I_message. Ifthere is a &Rernembered message then notthing is done. If theslave is offline every message in &NOn_control_messëlge_from_hostis taken out. If the removed messaqe was an&Order_bitbus_message, a &Reply_bitbus_message is generatedtelling that the message is rejected becausse the slave isoffline. If the slave is online and there is no&Rernembered_me 5 sage then a &NOn_control_message_from_host isstored into the data base as &Remembered_message.

HSP 1.1.3 Calculate frame contents

Calculate frame contents calculates the content 5 of the&Prepared_frame for the &Slave_number. The kind of frame createdis based on the &Slave_state and the fact if there is a messagein &Remembered_message for that slave. This is done according tothe following rules:Slave state I Message I Frame created=====================================Go to NDMFRMRMNDHNRMNRMNRM timeoutNRM timeout

YesNoYesNo

DISC frameDISC frameSNRM frameI frameRR frameI frameRR frame

I Bitbus I 8122 967 79??1 I Group 191 -PAGE 88 - II SA REPORT I Analysis Report I 1988-08-17 11: 11 I----------------------------------------------------------------I P.E.J. Boenen I CFT CAM Centre I

'ti l.1ItJ:l· ):0 ....tz:I rt· tJ"~ I I::· 111

tJ:l ::ti

8 tz:I'ti

::I 0Cl) ::ti::I 1-3

III

--II

~~ II

l1l N I...... N I'< I111\0.... Ol111 -..l

::tI-..lCl) \0'0 .'\1o .'\1., .rt .....

() ..... t:;)'-.j \U Ti1-3 0>0

0>1::

~1'0

00> .....I \0

() ..........Cl) -..l::I Irt 'ti I., ):0Cl) ..... t:;)

..... 1.":1.......

.....0>\0

Power on

Frame contentscalcuTated -

If

I Idle L Frame prepared I I- Calculating frameI -

I'

Trigger Unwanted_messageprepare=frame removed -

Trigger Trigger calculate -select slave frame contents- Slave selected -

Trigger remove

I SelectingI unwanteo_messagr Removing unwanted II I -

Prepare frame-SHEET NO: 1 OF 1 LAST UPDATE: 08-FEB-1988 14:16

PROJECT: Bitbus LAST ANALYSIS: 17-AUG-1988 11:11

()l.1I

.....

.....

Receiveframe

Receivedframe

'- ./,Timeout

\

"" Trigger_" recel.ve

" frame" from -\ interface,

\

\

\

IY

Transmit receive frame

S'~111 NI-' N"<UI 10..... 0'\UI ......

:;0 ......lil 10"0 ·Vo ·V., .r1" .....

Transmitframe

n ..... t;)"Ij 10"~ ooO

OOI:n 1"0

~0oo .....I 10

n ..........lil ......::s Ir1" "ti., ):0lil ..... t;)

..... tr.l............100

"ti Ultl:l. ):0 .....tz:I r1". tJ'~ I I:

UI

tl:I :;00 tz:I0 "ti::s 0lil :;0::s ~

LEVEL: 2 LAST UPDATE: 3-NOV-1987 10:04

PROJECT: Bitbus LAST ANALYSIS: 17-AUG-1988 11:11

MSP 2.1 Transmit frame to interface

Transmit_frame_to_interface splits the information in&Prepared_frame in &Transmit frame and &Expected frame. Af terthe information is loaded, the actual transmission by thehardware is started. Then Transmit_fra.me_to_interface ends, itdoes not wait on the actual transmission signalled by the serialinterupt.

MSP 2.2 Receive frame from interface- - -Receive_frame_from_interface copies the &Receive frame tI:>&Received_frame and does some checkin'3'. A check is made to seeif the received frame is the &Expected_frame and if the lengthof the informationfield is possible. If it is, &I_fr&ne_receivejis signalled. If it is not, Non_I_frame received is signalled.

MSP 2.3 Transmit_acknowledge_frame

Transmit acknowledge_frame sends a RNa frame with the poll bi treset in the &SDLC_controlbyte to &Transmit frame. Af ter that,the actual transmission is started.

MSP 2.4 Handle receiver timeout

Handle receiver timeout puts contol information in&Received_frame telling that there was a timeout.&Timeout status is signalled to notify the completion of it.

I Bitbus I 8122 967 79?? 1 I Group 191 -PAGE 91 - II SA REPORT I Analysis Report I 1988-08-17 11:11 I--------------------------------------_._------------------------I P.E.J. Boonen I CFT CAM Centre I

"ti tIlD:l· :to .....[Ij rt· tr~ I C· UI

D:l :n0 [Ij0 "ti::1 0CD

~::1

~~DI NI-' N'<UI 10..... 0'1UI -..I

:n-..lCD 10

"'0 .'\olo .'\ol1-1 .rt .....

n ..... Q':Ij 101-11-3 CDO

CDC

~1"'0

0CD .....I 10

n ..........~

-..II

rt "ti1-1 :toCD ..... Q

..... [Ij............IûN

l-power on

I Idle

Enable Disabletransm'Ission transmission

Timeout status Trigger Serial inttransmi'f fr- Trigger transmit frTrigger_transmit fr _I Transmitting - - -

1t

Timer int Serial intDisable timer

Enable timerTrigger-handle -Handling timeout- r

Receiving 1 Transmittingtimeout - I acknowledge -

I

Serial int

Disable timer Non I frame received

Trigger=receive_ frame Trigger transmit fr- -

I Saving 1

I frame receivedI

Trigger transmitacknowledge frame-

Transmit receive frame- -

SHEET NO: 1 OF 1 LAST UPDATE: 17-NOV-19B7 11:23

PROJECT: Bitbus LAST ANALYSIS: 17-AUG-19BB 11:11

ntil

N

1-31-1DI::1UI!3.....rt

I1-1CDnCD.....<

ICDHl1-1

~CD

".....

til::rCDCDrt

.......

Receive message from host

"Ijtj

w~IDnID.....<:ID

'aID111111lIJIQ

lIDHl

"I~o111rt

from host/

/ ......

/ "hf, s t

\ Trigger convert bytesI I into_message - -\ /

\ //

\ /

\ /j /.. ~ Messages from host

I \queue nor ful!. _, - - -

\ .-.-, ...-/ " .- .-

- - -

Messages fromqueue fuIIno more da-

Bytes

Host transmitbyffer full

~~lIJ "-II-' "-I I'<111 10..... 0'111 .....~ .....ID 10"0 ."o ."" .rt .....

() ..... G)"Ij 10"~ enO

ene:

~1"0

0en .....I 10

() ..........ID .....::l Irt 'ti

" )llID ..... G)

..... tz:I..

..... ,10 IW I

II I

I--I

'ti tIlD'• )ll .....~ r+

• 0-e... I e:• 111

LEVEL: 3 LAST UPDATE: 9-NOV-1987 11 :08

PROJECT: Bitbus LAST ANALYSIS: 17-AUG-1988 11:11

Convert_bytes_into_message copies the bytes of a &Bitbus_messagefrom &Bytes_from_host to &Message_from_host. The real copying isstarted by &Trigger_c:onvert_bytes_int':l_message. Then an attemptis made to copy a message. If the lllessage has been copied, acheck is made, if there is still roo:>m for another message. Ifnot, &Messages_from_Ï1ost_queue_full is signalled • When duringthe coying, it takE!s to long before the host gives the nextbyte, &No more_data is: signalled and the copying is stopped.

I Bitbus I 8122 967 79??1 I Group 191 -PAGE 94 - II SA REPORT I J1Jlalysis Report 11988-08-17 11:11 I---------------------_._-----------------------------------------I P.E.J. Boenen I CFT CAM Centre I

"d VlIJ'· :r- 1-'-tij rt· tr~ I C· 111

8 :;0t>J"d

::l 0CD

~::l

~~I III N

I-' N'<111101-'- Ol111 -...I

:;0-...1CD 10'0 ."o ."1'1 .rt .....

n ..... Q"Ij 101'1~ I ():)o

():)C

~1'0

0():) .....! '.0n ..........

CD -...I::l Irt "d1'1 :r-CD ..... Q

..... tIj.......

.....10U1

Power on-

I From host waiting on host I- - - -

Host transmit No more databuffer full - -

Trigger convert bytesinto_message - -

I From host _copying I-

Messages from host Messages from hostfuTI - - queue not fulT -queue - -

Trigger convert bytesinto_message - -

I From host waiting on spa ce I- - - -

Receive _message_ from host-

SHEET NO: 1 OF 1 LAST UPDATE: 09-NOV-1987 11 :56

PROJECT: Bitbus LAST ANALYSIS: 17-AUG-1988 11:11

nVI

W

.....

Transmit message to host

1f

9-NOV-1987 11: 11LAST UPDATE:

~\

\

\

\

\

\Trigger convert message

\ into byfes\

\

\

\

Messages to hostqueue_nof_empty

I

/

I

I

IMessages_to_hos~_

queue emptyhost Is del- I

I

I

t

Hos t r e~ eî ve ­buffer empty-

LEVEL: 4

S"~lIJ N...... N'<UI 10.... 0\UI-..J

~-..JCD 10'0 ."o ."" .rt .....

n ..... Q"Ij 10"""l coo

coc::

~1'0

0co .....I 10

n ..........CD -..J::J Irt "ti

" ):0 ICD ..... Q I

..... t':I I.. I..... I..... I10 I0\ I

II I

I--I

--II

"ti UltJ:l I· ):0 .... It':I rt I· 0- I~ I c:: I· UI I

ItJ:l ~ I

8 t':I"ti

::J 0CD I ~::J ""l

PROJECT: Bitbus LAST ANALYSIS: 17-AUG-1988 11:11

Convert_message_into_bytes tries to e:opy the bytes of a&Bitbus_message from &Message_to_host te) &Bytes_to_host. Firstit checks if there is any message in &M,!ssage to host If thereis no message, it signals &MeSSages_to_host_queue_empty a'.ndends. If there is a message it tries te) copy that message. Ifdur ing the copying the host doesn I t accept a byte for a certa.intime &Host_is_delayed is signalIed and the cOFying stopped.During the copying there can be no receiv,!r interuFt generateel.

I Bitbus I 8122 967 79??1 I Group 191 -PAGE 97 - II SA REPORT I Analysis Report I 1988-08-17 11:11 I-----------------------------------------------------------------I P.E.J. Boonen I CFT CAM Centre I

-II

't3 1 U'ItJ:10 I > ....tzj I rt'0 , 0-c.... , c0 lil

8 ::0tzj't3

::l 0ID

~::l

S'~III NI-' N'<lil 10.... 0\lil -...I

::0-...1ID 10

'"0 0'U

o o'U.., .rt' ....

n .... G')"Ij 10'"1-3 coo

coc

~1'"0

0co ....I 10

n ........ID -...I::l Irt' 't3.., >ID .... G')

.... tzj00........

10co

Power on-

It

I To host idle I- -I'

Messages to hostMessages to host queue empty- -queue not ernpty -

-

I Ta host wait on host I- - - -

Host rece1.ve Host 1.S delayedbuffer -empty

Trigger_ convert -messageinto_ ytes

I Ta host _copying I- I

Transmit message to host- - -

SHEET NO: 1 OF 1 LAST UPDATE: 09-NOV-1987 12:00

PROJECT: Bitbus LAST ANALYSIS: 17-AUG-1988 11:11

nU'I..,.1-3..,III::llila....rt'

'aIDlillilIII"llIDrt'

I~olilrt'

......,U'I::rIDIDrt'

DATA DICrIONARï***************

Bitbus_message

= [Order_bitbus_messageI Reply_bitbus_message

*Last byte has command bit set in buffer*

= Bitbus_message

*Last byte has command bit set in buffer*

= Bitbus_message

*Node address is 0*

*Signals that the available cjntrol messages have been handled*

= "Sof tware_control_signal "

I Bitbus I 8122 967 7911.1 I Group 191 -PAGE 99 - II SA REPORT I Analysis Report I 1988-08-17 11: 11 I----------------------------------------------------_ ..----------I P.E.J. Boonen I CFT CAM Centre I

databyte

*Conta.ins application !:.pecific informati·on*

= "byte"

Destination task ident.ification

= "nibble"

Disable timer

*Stops the timeout timer and disables the Timer int*

= "Hardware_control signaI"

Disable_timer_Tr igger_.handle_timeout

= Disable timer+ Trigger_handle_rec:eiver timeout

= Disable timer+ Trigger_receive_frame from interface

Disable transmission

*Signals that there is no frame waiting for transmission whentrying to send one*

= "Software_control_signal"

I Bitbus I 8122 967 79??1 I Group 191 -PAGE 100 - II SA REPORT I Analysis Report I 1988-08-17 11:11 I----------------------------------------------------------------I P.E.J. Boenen I CFT CAM Centre I

Enable timer

*Starts a predefined timeout period*

= "Hardware_control signal"

Enable transmission

*Signals that a frame is ready for transmission*

= SDLC address+ Expected_I_SDLC_contrc)lbyte

Expected_I_SDLC_controlbyte

*Byte indicating the expl:!cted controlbyte in the received framewhen it is an information frame*

= SDLC_controlbyte

Frame contents calculated- -

*Signals that a frame is ~ide ready for transmission*

I Bitbus I 8122 967 7911.1 I Group 191 -PAGE 101 - II SA REPORT I Analysis Report I 1988-08-17 11: 11 I----------------------------------------------------------------I P.E.J. Boonen I CFT CAM Centre I

Frameyrepared

*Signals that the frame header for a SDLC frame has beencalculated*

*FRMRM

*

= "nibble"

Go to normal disconnect mode

*Go to NDM*

= "nibble"

*Signals that the host didn ' t accept bytes fast enough*

*Signals that the receive buffer ol: the VME bus is empty*

= "Hardware_interupt"

I Bitbus I 8122 967 7917.1 I Group 191 -PAGE 102 - II SA REPORT I Analysis Report I 1988-08-17 11 : 11 I-----------------------------------------------------------------I P.E.J. Boonen I CFTCAM Centre I

Host transmit buffer full

*Signals that a byte has been written into the buffer by the VMEsite*

= "Hardware_interupt"

I frame received

*Signals that an information frameReceive frame from interface which hadnumbers*

= "Software_control_signal"

*

hasthe

been received byexpected sequence

Signals that there is no room left in Messages_from_host*

= "Software_control signaI"

= Messages_from_host_queue_full+ No more data

I Bitbus I 8122 967 7911.1 I Group 191 -PAGE 103 - II SA REPORT I Analysis Report I 1988-08-17 11:11 I-----------------------------------------------------------------I P.E.J. Boonen I CFT CAM Centre I

*Signals th,at there h,as become room in the Messages_from_host*

= "Software_control_signal"

*Signals th,at there w,as no message in Messages_to_host*

= Messages_to_host._queue_empty+ Host_is_delayed

*Signals th,at Messages_to_host is not empty*

= "Softw,are_control_signal"

Message_coJmnand_code

= "byte"

I Bitbus I 8122 967 79??1 I Group 191 -PAGE 104 - II SA REPORT I Analysis Report I 1988-08-17 11: 11 I----------------------------------------------------------------I P.E.J. B'jonen I CFTCAM Centre I

= [Non_control message Erom_hostI Cont::-ol_message_from._host ]

Mes sage_l ength

*Number of bytes + 2*

= "byte"

Message_re5ponse_code

= "byte"

Message_to._host

= Bitbus._message

= Slave number

Node addre:is

= SDLC address

Non_control_message_from_host

*Node addre:is is not 0*

= Bitbus._message

I Bitbus I 8122 967 7911.1 I GIOUp 191 -PAGE 10S - II SA REPORT I Analysis Report I 1988-08-17 11 : 11 I---------_._------------------------------_._---------------------lp.E •J. Boonen I CF'T CAM Centre I

Non I frame rece:i.ved

*Signals that a frame has been received byReceive frame fn:>m interface which was n.:>t an information frame- - -with the expectej sequence numbers*

Normal disconnect mode

*NDM*

= "nibble"

*NRM*

= "nibble"

*NRM timeout*

= "nibble"

No more data- -*Signals that the host didn I t supply bytes fast enough*

I Bitbus I 8122 967 79??1 I G{OUP 191 -PAGE 106 - II SA REPORT I Analysis Report I 1988-08-17 11: 11 I----------------------------------------------------------------I P.E.J. Boonen I CFT CAM Centre I

No recEüved frame- -

*Signals that there was no Rec1üved_frame handled becausse therewas no frame in Received_frames_queue*

= "Sof tware_control_signal "

Order bitbus_message

= Message_length'+ Order identification+ Ncxle address+ Source task identification- -+ Destination task identification- -+ Message conunand code+ 0 ( databyte } 27

Order identification

*00 h*

= "byte"

Power on

*Power on is signalled at the startup of the system and used toindicate the initial state of the State Transition Diagrams*

= "Software_control_signal"

= Expected_I_frame_controlbyte+ SDLC frame

I Bitbus I 8122 967 79??1 I Group 191 -PAGE 107 - II SA REPORT I Analysis Report I 1988-08-17 11:11 I----------------------------------------------------------------I P.E.J. Boonen I CFT CAM Centre I

prepared_frames

= 0 ( prepared_frame } 2

Received frame

= Receiver status code- -+ SDLC frame

Received frames

= 0 ( Received frame } 2

Received frame handled

*Signals that Slave data has been updated and optionally aMessage_to host created as result of a Received frame*

Receiver status

= [I_frame_receivedI Non I frame received

Receive frame

= SDLC frame

*0-7

*

= "byte"

I Bitbus I 8122 967 79??1 I Group 191 -PAGE 108 - II SA REPORT I Analysis Report I 1988-08-17 11: 11 I-----------------------------------_._---------------------------lp. E. J. Boonen I CFT CAM Centre I

= Bitbus_me~sage

Reply bitbus IIIessage- -I

= Message le:ngth+ Reply_idertification+ Node addréss+ Destinatidn task identification+ Source ta~'k-identification- -+ Mes sage re!sponse code+ 0 { databyte } 27

Reply_identification

*80 h*

= "byte"

*Number of time:s a frame is transmitted*

= "byte"

SDLC address

= "byte"

SDLC_controlbyte

= "byte"

I Bitbus I 8122 967 79??1 I Group 191 -PAGE 109 - II SA REPOF~ I Analysis Report I 1988-08-17 11:11 I-------------_._-------------------------------------------------I P.E.J. Boone,n I CFT CAM Centre I

SDLC frame

= SDLC aèldress+ SDLC_cClntrolbyte+ ( Bitbl.:ls_message )

= "byte"* 0 - 7 *

Sect...numbers

= Send_sE!quence_number+ ReceiVE!_sequence_number

Serial int

*Signals that a frame h,as been transrnitted or received*

= "Hardware_interupt"

Slave data

= Slave online offline indication- -+ Slave state+ S€1-numbers+ Next_slave_to-poll+ Retry_count+ Rernembered_message

Slave data base

= 32 { Slave data } 32

I Bitbus I 8122 967 7911.1 I Group 191 -PAGE 110 - II SA REPORT I Analysis Report I 1988-08-17 11:11 I----------------------------------------------------------------lp. E. J. Boonen I CFT CAM Centre I

Slave number

*Value 0 to émd including 31*

= "byte"

Slave of f line

= "bit"

Slave onlinE~

= "bit"

Slave onlinE~ off line indication- -= [Slave online

I Slave offline ]

Slave selected

*Signals that a slave has been selected*

Slave state

= [Go_to__normal_disconnect_modeI Frame__reject_modeI Normal_disconnect_modeI Normal_response_modeI Norma:_response_mode_timeout

I Bitbus I 8122 967 79?? 1 I Group 191 -PAGE 111 - II SA REPORT I Analysis Report I 1988-08-17 11: 11 I------------~----------------------------------------------------

I P.E.J. Bo(men I CFT CAM Centre I

Source task identification

= "nibble"

*Sinchronisation signal between two STDs*

= "Software_control_signal"

Timeout status

*Signals that a Received frame has been created as result of atimeout*

Timer int

*Signals that a predefined time period has expired*

= "Hardware_interupt"

Transmit frame

= SDLC frame

*Starts the calculation of a frame for a given slave*

I Bitbus I 8122 967 79??1 I Group 191 -PAGE 112 - II SA REPORT I Analysis Report I 1988-08-17 11 : 11 I----------------------------------------------------------------I P.E.J. Boonen I CFT CAM Centre I

*Starts the copying of ( part of ) a message from the host to thequeue*

= "Software_control_signal"

*Starts the copying of ( part of ) a message from the queue tothe host*

= "Software_control_signal"

*Starts the handling ofMessages_from_host_queue*

= "Software_control_signal"

the control messages in the

= Trigger_handle_control_message+ Enable transmission

*Starts the handling of a Received frame and the updating ofSlave data*

= "Sof tware_control_signal "

I Bitbus I 8122 967 79??1 I Group 191 -PAGE 113 - II SA REPORT I Analysis Report I 1988-08-17 11: 11 I----------------------------------------------------------------I P.E.J. Boenen I CFT CAM Centre I

Trigger_handle_receiver timeout

*Starts the creation of a dummy Received frame*

Trigger-prepare_frame

*Starts the calculation of a SDLC frame header for the selectedslave*

= "Software_control signaI"

= Trigger-prepare_frame+ Enable transmission

Trigger_receive frame from interface

*Starts the copying and checking of a Receive frame to aReceived frame*

*Starts the handling of messages if the slave is offline*

= "Software_control_signal"

I Bitbus I 8122 967 79??1 I Group 191 -PAGE 114 - II SA REPORT I Analysis Report I 1988-08-17 11:11 I----------------------------------------------------------------I P.E.J. Boenen I CFTCAMCentre I

*Starts the selction of the next slave to poll*

= "Software_control signaI"

Trigger_.transmi t_acknowledge_frame

*Signals that a supervisor frame has to be send as a response onthe receipt of an information frame*

Trigger_.transmi t_frame_to_interface

*Starts the transmission of a frame if one available*

Unwanteà._message_removed

*Signals that the messages waiting for a slave wich is offlinehave beE!n removed*

= "Software_control_signal"

I Bitbus I 8122 967 79??1 I Group 191 -PAGE 115 - II SA REPORT I Analysis Report I 1988-08-17 11:11 I----------------------------------------------------------------I P.E.J. Boonen I CFT CAM Centre I

ERRon/WARNING SUMMARY OF FLOW DIAGRAMS=====;===============~============;===

No E:!rrors detected

I Bitbus I 8122 967 79??1 I Group 191 -PAGE 116 - II SA - REPORT I Analysis Report I 1988-08-17 11:11 I----------------------------------------------------------------I P.E.J. Boonen I CFT CAM Centre I

ERROR/WARNING STATISTICS========================

severe errors 0errors detected 0

system model may be transformed

I Bitbus I 8122 967 79??1 I Group 191 -PAGE 117 - II SA - REPORT I Analysis Report I 1988-08-17 11 :11 I----------------------------------------------------------------I P.E.J. Boonen I CFT CAM Centre I