an intelligent interface to fastbus

Interfaces in Computing, 1 (1983) 105 - 115 105

AN INTELLIGENT INTERFACE TO FASTBUS

ALEXANDER W. BOOTH

Organisation Europdenne pour la Recherche Nucldaire, Geneva (Switzerland)

(Received January 24, 1983)

Summary

Computer-aided design tools have been used in the development of FBport , a microprogrammed interface between Fastbus and the bus of a powerful microcomputer (M68000). FBport has many attractive features including the ability to execute predefined sequences of Fastbus operations which can be performed wi thout the intervention of a processor or other device. Any device connected to the mic rocompute r bus can become a Fastbus master and take advantage of this new high speed data acquisition system. The bidirectionality of FBport means that any device or system connected to the mic rocompute r bus can also appear as a slave to Fastbus.

1. In t roduct ion

Fastbus [1] is a standard modular 32-bit data bus system for data acquisition, processing and control. A Fastbus system consists of multiple segments which can operate independent ly or link together to form large powerful systems. Fastbus will be particularly attractive to large-scale data acquisition systems because of its increased bandwidth and flexibility. In order to avoid a proliferat ion of separate and unique interfaces to Fastbus, and the multiplicity of software effor t therein, a general purpose interface (GPI) [2] was envisaged. The characteristics of the GPI are such that ports are connected to a microcomputer bus and have identical architectures apart from their own dedicated coupler to the medium being connected. Each port also contains dedicated firmware to drive the protocols of that medium. Buffering the ports overcomes the problem of speed mis- matches between any two media and the mic rocompute r connected to its bus performs the necessary pro tocol translation and transport management. FBport was simulated using the instruction set processor specification (ISPS) language [3], which was very useful for testing alternative architectures and debugging the microcode that had been developed on a micro- assembler.

0252-7308/83/0000-0000/$03.00 © Elsevier Sequoia/Printed in The Netherlands

106

FBport not only has presented us with a flexible, intelligent and fast interface to Fastbus but is giving us the opportuni ty to test out the GPI design philosophy which is reported in ref. 2.

1.1. FBport overview The FBport of the GPI is a single-width module consisting of a pro-

grammable sequencer (PSQ) with microstore, a Fastbus coupler, 2k words (32 bits) of memory and an interface to a controller bus. Although FBport in its first implementat ion is part of the GPI, it could exist in a system with only a controller and command terminal. For example, an M68000 system with sufficient memory using the portable interactive language system (PILS) [4] could employ FBport in the on-line control and monitoring of multicrate Fastbus systems.

FBport has three modes of operation: a master mode where the controller (or some other device on the controller bus) addresses a Fastbus slave, a slave mode where the FBport is addressed as a slave by a Fastbus master, and a segment interconnect (SI) mode where a system (e.g. CAMAC, Unibus etc.) connected to another port of the controller bus appears as a Fastbus slave to a Fastbus master. In the Fastbus master mode the maximum speed of data transfers is attained in a block transfer write operation where 32-bit transfers are performed every 150 ns, although this could be faster if the logic was "hardwired" instead of being driven from microcode.

FBport supports all Fastbus operations except for non-handshake block transfers and is capable of list processing. For example, in the Fastbus master mode, the controller "arms" the port with all necessary data and addresses, sets up the appropriate pointers and sets the "go" bit in the port command register. When the FBport has finished executing a list, it sets a "done" bit in the port status register which optionally causes an interrupt in the controller. The controller is also optionally interrupted if the FBport receives a negative response from Fastbus or detects an error. Vectored interrupts are used, with only one vector being provided in the prototype version. Almost all port operations are controlled by microcode.

In the SI mode the FBport operates as a pseudo-SI. The FBport route map can be loaded to pass the address group for any system connected to another port of the controller bus.

(In the prototype implementat ion of the GPI the route map is loaded to pass an address group for a CAMAC system connected to the controller bus. The Fastbus address field allows mapping of Fastbus logical addresses onto CAMAC features (see ref. 5) and such features can also be accessed in the Fastbus multilistener (broadcast) mode.)

The FBport slave mode is used when a remote Fastbus master wishes to access the Fastbus control and status registers (CSRs) in the port. Access to these CSRs is achieved by extended geographic addressing. This mode could also be used if remote Fastbus masters wanted to use FBport as a simple memory module in which to dump their data.

107

1.2. Background The design p h i l o s o p h y fo r the GPI was laid d o w n in the d o c u m e n t by

Asboe-Hansen [6] who p e r f o r m e d a large par t o f the ground work for the interface. The GPI is seen as t r ans fo rming a sequence of events on one m e d i u m into a sequence o f events on the o ther .

In o rder to faci l i tate this, a symmet r i ca l s t ruc tu re was envisaged which con ta ined an in ter face con t ro l l e r at the cent re , and a po r t conta in ing a m e m o r y buf fe r and a PSQ driving a ded ica ted coup le r on each side. The func t iona l blocks are shown in Fig. 1. The main advantages o f this archi tec- tu re are tha t bo th por ts can ope ra t e c o n c u r r e n t l y at a speed compa t ib l e wi th the par t icu lar med ium to which t h ey are c o n n e c t e d and tha t m u c h o f the hardware is general in tha t b o th por ts have ident ical sequencers , ident ical por t - to -con t ro l le r -bus interfaces, ident ical m e m o r y and pointers , ident ical t ransac t ion stores etc. F B p o r t has been designed with these concep t s and this a rch i t ec tu re in mind.

INTERFACE CONTROLLER1

J [ controller bus

I SEQUENCER 1 I SEQUENCER MEDIUM A tMEDIUM B I

~coul ,!R_4 ,, 1 I I COUPLER-B t

I,,,1 I t MEDIUM A MEDIUM B

Fig. 1. Functional blocks of the GPI.

2. F B p o r t

2.1. FBport hardware F B p o r t consists o f a PSQ, a t ransac t ion store, a buf fe r m e m o r y with

poin te rs , an in te r face to the con t ro l l e r bus and a Fas tbus coupler . Figure 2 is a s implif ied b lock diagram of F Bp o r t c o n n e c t e d to its cont ro l le r .

J FASTBUS COUPLER 1 Fig. 2. FBport architecture.

ICOMMANDI STATUS I I I

TRANS. ~ l ~ ~ I ~ o ~ , ~ MEMORY . ~ S~OUE.~ER PO'"TERS N (P~O,

I

108

2.1.1. Programmable sequencer The intelligent heart of FBport is a PSQ consisting of the AMD-2910

(Advanced Micro Devices Inc., Sunnyvale, CA, U.S.A.), 512 words of 72-bit wide microstore, a mapping programmable read only memory (PROM), "condi t ion logic" implemented in programmable array logic and clock circuit- ry. The microstore contains sequences of micro-instructions which perform the Fastbus pro tocol handling. The PSQ also provides the timing and control signals necessary to move data around inside the port , to invoke Fastbus operations in the coupler, to repor t on status and generally to perform those operat ions which because of speed and concurrency the control ler is unable to do.

2.1.2. Transaction store The transaction store is used to hold numbers which are mapped by the

mapping PROM in the PSQ to point at the start of a sequence of micro- instructions. The transaction store can hold up to 1024 transactions. Groups of transactions can be chosen to perform any desired sequence of Fastbus operat ions and can be invoked by a single command from the controller. Transactions for sequences of operations which are per formed frequent ly can reside in the transaction store "pe rmanen t ly" but the user has the f reedom to load any new or special sequence when and where desired.

There is also an address pointer to the transaction store which advances under control of the PSQ.

2.1.3. Memory with pointers The p r o t o t ype version of FBport is equipped with 2k X 32 bits of fast

memory . However, it is foreseen that the next version of FBport will be equipped with a memory more suited to data acquisition systems, e.g. 16k or 32k words. This memory is used for storing data and addresses to and from Fastbus. It is also used for storing word counts and for emulated Fastbus CSRs. The memory appears in the controller 's address space and is therefore accessible to any device connected to the control ler bus. The control ler accesses the memory by standard control ler bus pro tocol whereas the Fastbus coupler has rapid access in order to conserve block transfer speeds.

FBpor t memory should ideally be of a dual-port type so that data from Fastbus could be put in at one end while another module was taking it out at the other end. However, at the commencemen t of this project a suitable dual-port memory was not available and so the temporary solution chosen was to isolate the memory f rom the control ler when it was being accessed from Fastbus and similarly to isolate the memory from Fastbus when it was being accessed by the controller.

The memory is part i t ioned by means of an array of memory pointers. These are accessible by the control ler and sequencer. However, after access by the sequencer they are auto- incremented in the hardware. Nominally the

109

memory partit ions are as follows: master address out, master data out, master data in, slave data out, slave data in, master word counts out etc.

2.1.4. Interface to the controller bus The control ler bus in the p ro to type version of FBport is a cable exten-

sion of the KDM bus [7]. However, studies are at present under way and it is possible that this may be replaced by the VME bus [8].

The interface to the control ler bus enables FBport ' s memory , transac- t ion store, memory pointers etc. to be read or writ ten by any device which is master of the control ler bus. This interface also contains the necessary logic to perform the interrupt protocol . Vectored interrupts are used with only one vector being provided in the p ro to type version. The actual vector number is selectable.

The cable extension of the control ler bus is interfaced to transceiver circuits in FBport . These circuits have three-state outputs and two control functions: the first determines whether the por t and the control ler bus are connected or isolated, and the second determines which direction informa- t ion will flow when the two are connected. The control of this connection- isolation facility is per formed by the control ler which sets a particular bit in the FBport command register. This register and a status register are always accessible to the controller.

2.1.5. Fastbus coupler The hardware described so far has been general. This means that within

the GPI design phi losophy each por t connected to the controller bus could have this identical hardware, the firmware being medium specific. The coupler is also medium specific. It must contain all that is required of it by the particular medium being interfaced. For Fastbus the coupler contains the electrical interface to Fastbus (drivers-receivers), arbitration logic, address recognit ion logic, word count register, Fastbus CSRs etc. Although the coupler is dedicated to its medium it can still be driven by microcode. A full description of the FBport coupler can be found in ref. 9.

2.2. Fastbus f irmware The microcode was developed on the Signetics micro-assembler [10].

This facility allows a user to define his own specialized assembler. The user is required to provide three files: a micro-instruction definition file which defines the length of the micro-instruction, the various fields and the sym- bols which are used to write the microprogram assembly source (i.e. the assembly language), the microprogram source file which is the actual program to be assembled and the microformat command file which specifies the format of the object file ready for PROM burning.

2.2.1. FBport micro-instruction The micro-instruction in FBpor t is 72 bits wide and is split into the

following fields: coupler control ; por t status; control ler moni tor ; internal

110

control; next address computat ion containing instruction, condition and branch address. The functions of each field are as follows.

(1) The coupler control field is 29 bits wide and invokes operations such as Fastbus arbitration, assert data, assert data synchronize (DS(u)), decrement word count register etc.

(2) The port status field is 9 bits wide. A 4-bit code provides the port status (e.g. the done bit) and 4 other bits provide an error code. These 8 bits are connected directly to the port status register and the ninth bit clocks the status register.

(3) The controller moni tor field is only 1 bit wide; it starts a timer for the controller to take care of the situations where the controller fails to tell FBport to respond to Fastbus.

(4) The internal port control field is 11 bits wide and enables the relevant port internal data paths when and where appropriate, e.g. fetch transaction, fetch data, update pointer etc.

(5) The next address computat ion field is 22 bits wide and contains the operational code for the instruction being executed by the sequencer, a condit ion field for the situations when the following instruction is a condi- tional branch and a branch address for any kind of branch instruction.

2.2.2. Transactions in the FBport A transaction is simply a number, agreed on by both the controller and

the FBport, which when passed to FBport by the controller causes a particular sequence of micro-instructions to be executed. There are at present 50 transactions known to FBport which are related to Fastbus operations. Other transactions have been written to aid the maintenance engineer to test the device. The transactions have been written so that they correspond directly to the Fastbus standard subroutines [ 11]. A detailed description of the transactions of the FBport can be found in ref. 12.

2.3. FBport software For the pro to type version of the GPI, a program has been written [13]

which transfers lists from CAMAC into the controller's address space. These lists are interpreted by another program which is executed by the controller and which arms FBport appropriately, handles interrupts to take care of error conditions and is used in all modes of operation of FBport. For more information see ref. 14.

2.4. FBport operation FBport has three modes of operation; master, slave and SI modes. In all

modes the controller (or another device on the controller bus) is required to load transactions into the transaction store (if it is not already preloaded), to set the transaction pointer to point at the first transaction to be executed and to set the memory pointers to point, where appropriate, at the data, addresses and word counts which have been loaded into memory. The FBport memory is then isolated from the controller bus so that it is accessi-

! 1 1

ble by the coup le r u n d e r con t ro l o f the sequencer . The go bit is then set in the FBpor t c o m m a n d register which indicates to the sequencer tha t it should c o m m e n c e execu t ing t ransact ions . The con t ro l l e r is op t iona l ly i n t e r rup t ed when F B p o r t has f inished execu t ing the list o f t ransac t ions or when some er ror cond i t i on occurs on Fastbus.

The sequencer on seeing the go bit set fe tches the first t ransac t ion f rom the t ransac t ion s tore and maps it o n to the star t o f a sequence o f micro- ins t ruct ions . Each sequence o f mic ro- ins t ruc t ions co r respond ing to a transac t ion n u m b e r t e rmina tes with a c o m m a n d to the sequencer to fe tch the n e x t t ransac t ion . The sequencer con t inues to ex ecu t e t ransact ions unti l it encoun te r s an " e n d o f t ransac t ion l is t" t r ansac t ion or unt i l there is some irregular or u n e x p e c t e d occu r r ence on Fastbus. If the sequencer encoun te r s an end of t ransac t ion list t ransac t ion it sets the done bit in the F B p o r t status register.

2.4.1. Master mode Once the m e m o r y has been loaded app rop r i a t e ly with data, addresses

and word counts , the t r ansac t ion p o in t e r is typ ica l ly loaded to po in t at the star t of a t r ansac t ion list whose first t r ansac t ion is one tha t causes F B p o r t to arb i t ra te fo r Fastbus and whose second is some fo rm of an address cycle on Fastbus. If the a rb i t ra t ion logic in the F B p o r t coup le r fails to gain mastership of Fas tbus then the con t ro l l e r is in t e r rup ted . Similarly if F B p o r t fails to make an address c o n n e c t i o n the con t ro l l e r is also in te r rup ted . Once F B p o r t has gained mastership o f Fas tbus and the c o n n e c t i o n wi th a slave has been made, m a n y cycles (e.g. secondary address, single a n d / o r b lock data t ransfers , d i s connec t ion f rom the p resen t slave and r e c o n n e c t i o n to o the r slaves) can be p e r f o r m e d w i t h o u t con t ro l l e r in te rvent ion . The con t ro l l e r is i n t e r rup ted when F B p o r t encoun te r s an e r ror on Fas tbus or comple t e s ex ecu t i o n o f the list. The con t ro l l e r is also i n t e r rup t ed when the wait (WT) line has been up for a cer ta in length o f t ime and again when the WT line is d ropped .

2.4.2. Slave mode This m o d e is used when a r e m o t e Fas tbus mas te r wishes to access the

CSRs o f the SI par t o f FBpor t . Certain CSRs such as CSR 8, 40 and 41 have been i m p l e m e n t e d physical ly in F B p o r t whilst o thers have been emula ted . Access to all these registers is achieved when the r e m o t e mas te r p e r fo rm s a geographic address cycle to F B p o r t fo l lowed by secondary address cycles to the par t icular CSRs. When the geographic address recogni t ion logic in the F Bpor t coup le r is satisfied tha t some r e m o t e mas te r is t ry ing to m ak e a c o n n e c t i o n it asserts WT(u) and in te r rup ts the cont ro l ler . All opera t ions f rom then to the end o f the address lock are synch ron ized by the use o f the WT line.

2.4.3. Segment interconnect mode This m o d e is used when a r e m o t e Fas tbus mas te r wishes to access a

sys tem c o n n e c t e d to a n o t h e r po r t o f the con t ro l l e r bus. Access to any such

112

system is achieved when the remote master performs a logical address cycle where the high order address and data lines contain the group field. If the "pass" bit in the route table of FBport is high then WT(u) is asserted and the controller is interrupted. As with the slave mode all operations from then on are synchronized by using the WT line.

3. Simulation

FBport was simulated using the computer hardware description language ISPS [ 3 ]. The main reasons for simulating FBport were as follows.

(1) Simulation fills the gap between physical intuition and exact analysis well by providing a means for modelling.

(2) Simulation provides a vehicle for learning and experimentation. {3) Simulation helps to ensure the completeness of design. (4) Simulation allows the prediction of overall system performance

with a high degree of accuracy.

3.1. Instruct ion set processor specification Although the ISPS language can be viewed as a programming language,

the aim of the notat ion is to describe computers and other digital systems as well as general computat ional algorithms.

The ISPS notat ion describes the interface and behaviour of hardware units. The interface (i.e. external structure) describes the number and types of carriers to store and transmit information between the units. In the simplest case a unit is a carrier (e.g. a bus, register, memory etc.) completely specified by its bit and word dimensions. Some examples from the interface description of FBport are shown in Table 1. The memory is specified as being 2k words deep where each word is 32 bits wide. Similarly the memory pointer 's array is only 16 words deep and this time each word contains only 12 bits. The command register is a single 16-bit word and hence there are no square brackets included in its specification.

The behavioural aspects of the units are described by procedures which specify the sequence of control and data operations. Some examples of procedure names from the FBport description are as follows: memory access, fetch transaction, test condition, control clock etc. Table 2 shows the

TABLE 1 Examples from the instruction set processor specification description of FBport

M\MEMORY[0:2k ]<31:0> MP\MEMORY.PO INTERS [ 0:16 ]<11:0> TS\TRANSACTION.STORE [ 0: I k]<7:0) CREG\COMMAND.REGISTER(15:0> SREG\STATUS.REGISTER<15:0> MEMBUS<31:0>

113

TABLE 2

FBport instruction set processor specification description of memory access

Process MEMORY.ACCESS: = Begin wait (MEMSTROBE and CREG.EBB) next delay (MEM.ACCESS.TIME) next if READ = > begin

MEMBUS = MEMORY [MA.LATCH] next wait (not (MEMSTROBE and CREG.EBB)) next restart MEMORY.ACCESS end next

MEMORY [MA.LATCH ] = MEMBUS next wait (not (MEMSTROBE and CREG.EBB)) next restart MEMORY.ACCESS End

ISPS desc r ip t ion o f m e m o r y access f r o m Fas tbus . An e x p l a n a t i o n o f this s imple p r o c e d u r e n o w fol lows. Befo re m e m o r y can be accessed, the A N D c o n d i t i o n of the signals M E M S T R O B E and C R E G . E B B m u s t be sat isf ied. M E M S T R O B E is a signal issued b y the s e q u e n c e r w h e n the F B p o r t coup le r wishes to access m e m o r y , and C R E G . E B B is a bi t in the c o m m a n d regis ter which indicates tha t the m e m o r y is i so la ted f r o m the con t ro l l e r and can t h e r e f o r e be accessed by the coup le r (see Sec t ion 2.1.3) . Once this c o n d i t i o n has been sat isf ied, the p r o c e d u r e waits a t i m e equal to the p r o p a g a t i o n delay of the m e m o r y (M EM.AC C ESS . TIME) be fo re , in the case o f a read cycle , gat ing the da ta f r o m the m e m o r y loca t ion p o i n t e d at b y M A . L A T C H o n t o the in ternal bus MEMBUS. In the case o f a wri te cycle , da ta are t a k e n o f f MEMBUS and p laced in the m e m o r y loca t i on p o i n t e d at b y M A . L A T C H . In b o t h cases the m e m o r y access cycle is n o t c o m p l e t e unt i l the A N D c o n d i t i o n o f M E M S T R O B E and C R E G . E B B goes false.

3.2. Modularity Simula t ing F B p o r t cons is ted o f descr ib ing the ha rdware uni ts in ISPS

t e rms ( the in te r face) and wri t ing func t i ona l desc r ip t ions o f each o f the b locks in the design, e.g. Table 2. To d e m o n s t r a t e the m o d u l a r i t y and "p l ug - i nab i l i t y " o f ISPS the first desc r ip t ion of F B p o r t inc luded an 8X02 sequencer in the PSQ. A second descr ip t ion , ident ica l wi th the f irst e x c e p t for the sequencer , had an AMD-2910 as the sequencer . I t was clear even be fo r e the s imula t ion t h a t the AMD-2910 was the b e t t e r device; however , this e x a m p l e c o n f i r m e d t h a t s imula t ion is a useful vehicle fo r learning and e x p e r i m e n t a t i o n and t h a t wi th ISPS m o d i f i c a t i o n s can be easy.

3.3. Verification of microcode In o rde r to ver i fy the m i c r o c o d e be fo re ac tua l ly burn ing the PROMs an

exac t c o p y o f the a s sembled m i c r o p r o g r a m was fed in to the s imula t ion . This

114

enabled data and control paths to be tested, conflicts to be resolved and logical errors and microprogram errors to be found and corrected. In this way the debugging phase of the pro to type design could be approached with a high level of confidence. There exists a simulation of the Fastbus protocol [15] so that actual Fastbus cycles can be simulated, and an ISPS timing diagram generator [16] enables a graphical display of signal levels for any desired situation.

4. Conclusions

FBport provides a means of interfacing to Fastbus via a microcomputer bus. It supports all Fastbus operations (apart from non-handshake block transfer) and has many desirable features including the ability to execute lists wi thout controller intervention. Because of its microprogrammability it is a very flexible interface; new transactions can be added easily. FBport, as part of the GPI, has many potential applications, e.g. CAMAC-to-Fastbus interface, Unibus-to-Fastbus interface, "any"-bus-to-Fastbus interface; all that is required is that the particular medium make a connection to the microcomputer bus. As mentioned earlier, FBport could be used in a "stand-alone" mode where, for example, an M68000 with sufficient memory using PILS [4] could employ FBport in the on-line control and monitoring of multicrate Fastbus systems. The modular design of FBport means that many of the logical "building blocks" could be used in other interfaces. For example, an interface to CAMAC would only need to change the coupler, microcode and some of the software in the controller, such is the design philosophy of the GPI.

Simulation proved to be a very useful tool. First, before the integrated circuits were even considered, the functionali ty of the module and how the logical building blocks were going to link together were described. Second, different building blocks, e.g. different sequencers, different memories etc. were experimented with to try to find some opt imum combination which satisfied the design goals. Third, the microcode which controls the internal data paths and the timing of FBport architecture was tested and debugged. Fourth, the ISPS description provides an important part of the documenta- tion of the module; if it is not clear from the schematic drawings how a unit functions then the ISPS description of that unit can be referenced or the simulation can even be run with identical microcode and a sequence traced through step by step.

FBport exists in its prototype version. Many lessons have been learnt from this implementation. A design review is currently under way for both the GPI and the FBport, and the outcome will be the subject of another report.

Acknowledgments

I would like to thank P. J. Ponting and E. M. Rimmer for the benefit of their advice and experience, wi thout which this project would not have been successful.

115

Since I joined this project I have had many fruitful discussions on simulation, Fastbus and FBport in particular, with many people. I would like to express my thanks to all those people and in particular to the following: P. Asboe-Hansen, C. Parkman, H. Muller, C. Bizeau, T. Streater, H. Verweij, L. Pregernig, R. Mclaren and D. Burckhart.

References

1 U.S. NIM Committee, Fastbus specification, Stand., September 1982 (National Bureau of Standards, U.S. Department of Commerce).

2 C. F. Parkman, The general purpose interface, CERN Doc. FBDOC-SO03, 1982 (Organisation Europ~enne pour la Recherche Nucl~aire).

3 M. Barbarci, The symbolic manipulation of computer descriptions: the ISPS computer description language, Tech. Rep., 1980 (Department of Computer Science, Carnegie-Mellon University).

4 R. Russell, Portable interactive language system, CERN Rep., 1982 (Organisation Europ~enne pour la Recherche Nucl~aire).

5 E M. Rimmer, External specification and users' guide to CERN Fastbus CAMAC interfacing, CERN Doc. FBDOC-SO01, 1982 (Organisation Europ~enne pour la Recherche Nucl~aire).

6 P. Asboe-Hansen, Development of a Fastbus/CAMAC interface using CAD techniques, CERN Rep., 1981 (EP Division, Organisation Europ~enne pour la Recherche Nuc- l~aire).

7 MEX68KDM design module users' guide, Rep., 1980 (Motorola Inc.). 8 VME bus specification, Rep., 1982 (Motorola Inc.). 9 A. W. Booth, The sequencer-driven coupler in the FBport of the general purpose

interface, CERN Doc. FBDOC-IO08, 1982 (Organisation Europ6enne pour la Re- cherche Nucl~aire).

10 Signetics Micro-Assembler Reference Manual, Signetics, Sunnyvale, CA, 1980. 11 Fastbus Software Working Group, Fastbus Standard Subroutines, 1982. 12 A. W. Booth, The transactions used in the FBport of the general purpose interface,

CERN Doc. FBDOC-I010, 1982 (Organisation Europ6enne pour la Recherche Nuc- l~aire).

13 E. M. Rimmer, CERN's approach to Fastbus software, submitted to Conf. on Real Time Computer Applications in Particle and Nuclear Physics, Berkeley, CA, 1983.

14 C. Bizeau, FBport list processor, to be published. 15 A. W. Booth, Simulation of the Fastbus protocol, Conf. for the Application o f

Microprocessors to High Energy Physics, Organisation Europdenne pour la Recherche Nucldaire, Geneva, 1981.

16 A. W. Booth, Computer generated timing diagrams to supplement simulation, 5th Int. Syrup. of Computer Hardware Description Languages, Kaiserslautern, 1981.

an intelligent interface to fastbus

Documents