UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Train set bus controller Kender, Nana S. 1998

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata


831-ubc_1999-0052.pdf [ 3.69MB ]
JSON: 831-1.0051484.json
JSON-LD: 831-1.0051484-ld.json
RDF/XML (Pretty): 831-1.0051484-rdf.xml
RDF/JSON: 831-1.0051484-rdf.json
Turtle: 831-1.0051484-turtle.txt
N-Triples: 831-1.0051484-rdf-ntriples.txt
Original Record: 831-1.0051484-source.json
Full Text

Full Text

Train Set Bus Controller by N a n a S. Kender Diploma de inginer, Universi tatea Tehnica Timisoara , Romania , 1994 A T H E S I S S U B M I T T E D I N P A R T I A L F U L F I L L M E N T O F T H E R E Q U I R E M E N T S F O R T H E D E G R E E O F Master of Science in T H E F A C U L T Y O F G R A D U A T E S T U D I E S (Department of Computer Science) we accept this thesis as conforming to the required standard The University of British Columbia December 1998 © Nana S. Kender, 1998 In presenting this thesis in partial fulfilment of the requirements for an advanced degree at the University of British Columbia, I agree that the Library shall make it freely available for reference and study. 1 further agree that permission for extensive copying of this thesis for scholarly purposes may be granted by the head of my department or by his or her representatives. It is understood that copying or publication of this thesis for financial gain shall not be allowed without my written permission. Department of COMPUTER SlkhlCB The University of British Columbia Vancouver, Canada Date DE-6 (2/88) Abstract This thesis presents the design of a bus interface for a computer controlled train set. Th i s design is useful for experiments in real-time control and embedded sys-tems. The design was based on an experimental methodology based on modeling both hardware and software with programs in a guarded command language. The successful completion of this design provides empirical support for this approach. ii Contents A b s t r a c t i i Contents i i i L i s t o f Figures v i 1 In t roduc t ion 1 1.1 Train set project 2 1.2 Summary of thesis contributions 3 2 Co-Des ign 4 2.1 W h a t Is Co-Design ? 4 2.2 Current Issues in Co-Design 7 2.3 Models and Specification Languages for Co-design 8 2.4 System Mode l ing and Co-simulat ion 10 2.5 s u m m a r y 10 3 B u s Interface Specif icat ion 11 3.1 The train set 11 3.1.1 Acknowledgments and brief history of the project 11 3.1.2 Descript ion of train set components 12 3.2 The existing design 14 3.3 The proposed design 14 3.4 The train-bus 15 3.4.1 High-level design choices 16 3.4.2 Logical details 16 3.4.3 Elect r ica l details 16 3.4.4 Compar ison with other bus-schemes 20 3.5 T h e I S A to train-bus interface 20 3.6 Summary 24 i i i 4 Specification Language 25 4.1 W h y S T ? 25 4.2 Synchronized Transit ions 26 4.2.1 Combinators 26 4.2.2 Modu la r Designs 27 4.2.3 S T for Co-design 28 4.3 Summary 37 5 The Design 38 5.1 S T model design 38 5.1.1 The F I F O Buffers 38 5.1.2 T h e Con t ro l Logic 44 5.1.3 S T simulations 51 5.2 Implementation Decisions 51 5.3 F r o m S T to V H D L 52 5.3.1 Clock signal 52 5.3.2 Sensitivity lists 52 5.3.3 O n mix ing S T combinators 52 5.4 Summary 53 6 Evaluations and future work 54 6.1 Testing the train controller board 54 6.1.1 Problems I encountered while going through the whole design process 58 6.2 S T for co-design 58 6.3 Conclusions 59 6.4 Future work 59 6.4.1 Comple t ing the train-bus design 59 6.4.2 Better C A D support for S T based design 60 Bibliography 61 Appendix A ST code for the controller 63 Appendix B ST cell instantiation diagrams 71 Appendix C V H D L code 75 Appendix D Board Schematics 82 iv A p p e n d i x E B o a r d Des ign Detai ls List of Figures 3.1 The track topology 13 3.2 The old architecture 14 3.3 The proposed architecture 15 3.4 Voltage shifts at imbalanced changes of signal lines 17 3.5 A 4-phased Tra in-Bus Pro toco l 18 3.6 The train-bus clocks 19 3.7 Standard ISA cycle 21 3.8 A write to a device on the train-bus 22 4.1 A direct mapping of the S T 3-bit counter to hardware 29 4.2 The counter modulo-21 32 4.3 The differential clock generator 33 4.4 Instantiations of the counter cells 33 4.5 State Diagram for the C o m m a n d Dispatcher 34 4.6 S T code for the dispatcher cell 35 4.7 State Diagram for the Ret i r ing of a C o m m a n d 36 4.8 S T code for the retire cell 36 5.1 Bus Control ler - Register View 39 5.2 The need for an addit ional data-write buffer 41 5.3 The "ou t -F IFOs" : C m d , A d d r and Data -Wri te 42 5.4 State Diagram for Modu le driver.sti 43 5.5 The state variable declaration 46 5.6 Funct ion definitions for the qcontroller cell 47 5.7 C o m m a n d F I F O control signals 48 5.8 Da ta -Wr i te F I F O control signals 48 5.9 Result F I F O control signals 49 5.10 Qcontroller module: forcing an idle train-bus cycle 49 5.11 The special buffer for C o m m a n d - F I F O stage 2 50 v i 6.1 Sample test application (in C + + ) for the bus controller: constant and function definitions 55 6.2 Sample test application (in C + + ) for the bus controller: main func-tion body 56 B . l The "ou t -F IFOs" : C m d , A d d r and Data-Wri te 72 B.2 The " i n - F I F O s " : Status and Data-Read 73 B.3 The Cont ro l Logic Cells 74 D . l Boa rd schematic sheet 1 83 D .2 Board schematic sheet 2 84 D . 3 Board schematic sheet 3 85 E . l The controller board with components 87 E.2 A list of the components placed on the controller board 88 v i i In memoria tatalui meu. To the memory of my Dad. vi i i Chapter 1 Introduct ion Embedded systems can be found everywhere from airplanes to doorknobs. A s em-bedded systems have become more widespread and more complicated, interest in systematic approaches to their design has grown as well . A n embedded system dif-fers from a general purpose computer by its specialization for a particular group of tasks; often the system has to deal wi th interfacing and communicat ion between a wide variety of sensors (i.e. input devices) and actuators (i.e. output devices). Design specification plays an important role in the design process. Embedded systems are inherently concurrent. There are the sensors to be monitored, the actuators for process control, and several software tasks may coordi-nate all these activities. If we take as an example the automatic control of trains on the same track system, several trains move on the track at the same time; position sensors need to be monitored, each train has its own set of geographic objectives and time schedule. Th is raises a coordination problem: avoiding collisions and ful-filling the schedule requirements. Our model train set - a research project in the Integrated System Design lab, see section 1.1 - includes several pieces of hardware, each with its own notion of time: the host computer, the I S A bus, the train bus, the switch controllers, the sensor interfaces, the signaling protocol on the track by which commands are sent to the speed controllers in each t ra in . These all operate concurrently. Concurrency may introduce non-determinism. M o s t hardware description languages ( H D L s ) generally have deterministic semantics to appeal to designer in-tui t ion and to simplify synthesis. Mul t i p l e notions of t ime, multiple clock-rates, and non-determinism are hard or impossible to represent in such commonly used frame-works. Al though many H D L s prevent the designer from expressing non-determinism in their models, this does not ensure that reality wi l l cooperate: events may occur in the implementation in orders that were not considered by the H D L model. Such 1 incomplete modeling can lead to errors in the final design. This thesis uses a concurrent programming language, Synchronized Transi-tions (ST) , for design specification. A n introductory description of the language is given in chapter 4. It consists of a set of state variables and transitions; transitions can be combined either synchronously or asynchronously. Considering the train set example, we have components that operate synchronously but at different speeds so there may not be a synchronous way to describe their interaction; also the soft-ware that controls the whole application can issue commands at its own pace, which should not have to be predictable. Here, the concurrency and non-determinism inherent in the S T language provide a natural way to model the design. S T was originally proposed by R a v n and Staunstrup [14] and has been used extensively for design and verification of both synchronous and asynchronous cir-cuits. M u c h of this work has been done by students at the Danish Technical Univer-sity in Lyngby. The S T compiler used allowed either synchronous or asynchronous descriptions, but not both; mixing the two kinds of operators was not allowed. The S T version used in this thesis removes this l imi ta t ion . The mixing of combinators in U B C S T provides a natural way to express concurrency and non-determinism encountered in co-design. The uti l i ty of this ap-proach is demonstrated by using it to design a bus interface for a computer controlled train set. A more detailed description of the necessity and usefulness of mixing com-binators is given in chapter 4; chapter 5 shows in what way this feature affects the translation from S T to V H D L . 1.1 Train set project Chapter 3 presents the train set. The train set is a test bed for embedded system design in the Integrated System Design lab in the Computer Science department at the Universi ty of Br i t i sh Co lumbia . It consists of a model train set (with tracks, engines and cars) connected to a computer v i a a parallel bus. The test bed is used for s tudying and i l lustrat ing safe implementations (e.g. running the trains without accidents) in an integrated software/hardware system. The project was started in 1992 by two former graduate students, and al-though it has been operational, several factors have determined the decision for important design changes. These are explained in detail in chapter 3. The main concern are electrical problems (transmission line effects) and design modulari ty; also the possibility to use the project for design verification studies. 2 1.2 Summary of thesis contributions The research undertaken for this thesis included the design, implementation, and test of a useful interface for real-time control and embedded system research. The design is more modular than the previous design and it allows a standard computing platform to be used for the controller. The thesis offers a documented design for future verification projects. Furthermore, this thesis proposes a methodology for hardware/software co-design. The train bus controller represents a component of interest from a co-design point of view: an interface between two buses with two different clocking method-ologies. Th is design process was an experiment to validate the design methodology. The S T language provided the framework for co-simulation. The S T design model was used - with manual translations - for board layout and component program-ming. Current ly, we do not have automatic synthesis and layout tools based on S T . Instead, the detailed S T description was translated to V H D L . Al though this is not an efficient design approach, it allowed a comparison of S T with V H D L . Chapter 6 gives an evaluation of the chosen methodology and test results. It summarizes the accomplishment of this thesis and suggests further work. 3 Chapter 2 Co-Design 2.1 What Is Co-Design ? Co-design refers to a common framework for designing the hardware and software architectures for an embedded system. "Embedded system" is a definition for a very wide range of digi tal systems used mostly in dedicated applications, containing ana-log circuitry and often mechanical parts as well. Co-design has become a strategic technology for systems as simple as household items like thermostats or answering machines, as well as for complicated medical instrumentation, automobile control systems, or "fly by wire" aircrafts. Whi l e the design of general purpose computers aims at a solution which minimizes cost while maximizing speed, storage capacity etc. for a broad range of applications, embedded systems are very application specialized. The application domain also dictates the co-design methodology for a particular embedded system. A p a r t from cost constraints, these systems also often have power, weight, and phys-ical size l imits (Wolf [21]); embedded systems usually have to meet hard real-time deadlines. For general purpose computers, requirements are relatively well defined: the instruction set determines the correct behaviour of the processor, and performance targets for benchmarks give high-level t iming properties. For embedded systems, specifications must describe the interaction of the system with its environment, and producing a correct and complete specification can be much more challenging. For example, consider the design of an ignition and fuel-injection controller for an engine. The designer's intention may be in terms of performance and efficiency of the engine wi th its controller. Thus, a specification for the controller must include a detailed model of the engine. Such a model may not be available at early stages in the design. 4 A d d i n g to the difficulty of the co-design problem is also the fact that in embedded systems, as the name says, the computing part is embedded, therefore hard to access for debugging. Tradi t ional break-point debugging is often infeasible for embedded designs. Aga in , consider the example of the engine controller: the embedded system operates in a real-time environment. The only way to test the controller is when it is connected to an engine. If the software stops at a breakpoint, the engine wi l l stop running. Given the specification of a system which may include hardware, software, analog and mechanical components, co-design represents the process of going from the specification level to the implementation level. A typical co-design flow is hard to give since co-design tools differ in how they delimit the design steps, but a generic co-design methodology would include some key phases such as (see Ga j sk i et al . [5]): • Specification: stat ing system requirements and building a model of the de-sign from these. If we take the engine control example, design specification includes [9]: (a) identifying the tasks of the system - in this case providing the correct amount of fuel and firing spark plugs at the right t ime, (b) identifying the inputs to the controller, such as signals from the crank position sensor or the manifold pressure sensor, (c) usually making abstraction of details, de-ciding how the system is going to fulfill its tasks. Th i s includes dealing wi th deadlines, wi th obstacles to correct functioning - such as noise - , wi th power constraints, safety requirements, etc. In other words, design specification gives a description of the design as the outside world expects it to behave. • Al loca t ion & Par t i t ioning: In general, a specification should describe what the system is supposed to to, and an implementation describes how it does i t . However, most work on specification for co-design has been done by the C A D community wi th a goal of automatic design synthesis from the specification. To make this goal practical , specifications for co-design tend to include top-level design decisions. For example, a specification may be in terms of a collection of communicat ing processes [15] or as a "control da ta f low graph" [11]. Each pro-cess can be implemented in either hardware or software, and the specification describes the da ta and control interactions between these processes. Al loca t ion is the process of choosing the type and number of components for implementation, part i t ioning defines the mapping of functions and /or processes from the specification onto the allocated components. M o s t often allocation and part i t ioning constitute one step only since if the part i t ioning is not satisfactory, a different allocation may be tr ied. M u c h work has been done towards C A D tools for this step of co-design [7, 12, 11]. There is usually 5 no single opt imal solution to this allocation & part i t ioning problem; there are trade-offs that need to be balanced. For example, one might want to put all the functions into a general system processor to minimize cost. However, such a processor may not be fast enough to handle everything. For the engine controller, there may be one processor that computes the injector setting and spark t iming. A second processor may handle the real-time interface with the engine. A dedicated D S P may process some of the data that is sampled to assess the engine's operation. A n A S I C may provide communicat ion between these processors. Scheduling: The operation of the embedded system is partit ioned to tasks, and tasks have been assigned to various kinds of C P U s , A S I C s , etc. The same hardware component may handle several tasks. Th i s is why scheduling is needed. Taking the engine controller example, there are operations that need to be done for every rotation of the crankshaft: actuating fuel injectors and firing spark plugs. These have real-time constraints. There are operations that can be done on a longer t ime scale, but st i l l must be fast compared to human response time: computing the amount of fuel to be injected, setting the throttle valve in the intake manifold. There are computations that can be done on an even longer time scale: changing mode of operation based on engine temperature, air temperature, oxygen content in exhaust, etc. These processes need to be scheduled so that all deadlines are met. There are many approaches to solve this N P - h a r d problem. One that takes into account non-determinism (the impossibil i ty to predict task execution times) is the work of Gerber et al . [6]: an offline component checks if there is a possible scheduling to meet all constraints and then produces a calendar that has lower and upper bound functions for the start times of the tasks rather than absolute numeric conditions. The online component then fills in the numeric values of the parameters inside the functions as they become known (the parameters in the bound functions of one task are start and execution times of other tasks). Other approaches, as reviewed by R.Camposano et a l . in [4], are - A S A P / A L A P (as soon as possible/as late as possible) scheduling; - Lis t scheduling - the difference between the A S A P and A L A P times are computed for all the tasks; this denotes the mobility of a task. The task with the least mobil i ty has the highest priority. Other cr i ter ia for priority can also be used. - Force-directed - also starts from computing the A S A P / A L A P difference, then the algori thm builds a model of "operation density" using the prob-6 abilities of operations to fall into certain execution steps. F r o m here there may be different variations of summing up these probabilities and deciding on the actual scheduling. - Path-based - each of the possible execution paths is scheduled, then the path schedules are merged to form a single state transit ion graph. - heuristic approaches: "percolation" scheduling, and scheduling by sim-ulated annealing or simulated evolution. These are based on an ini t ia l ( tr ivial or random) schedule from which better solutions are iteratively generated using heuristics. • Communica t ion Synthesis: components need to communicate with each other. Th is communication can be implemented using shared memory, buses, special serial l inks, etc. In the case of our t rain set, communicat ion happens through a special network - a bus wi th an established protocol. For the engine controller it is signal lines, that is serial ports, that connect the controller to sensors and actuators. Analys is and validation is necessary after every step. In our case, the bus controller fits into the context of a bigger co-design research project, the train set described in the next chapter. The enumerated design steps apply mostly only to the train set as a whole. For the controller, the choices for allocation and part i t ioning were quite straightforward, as described in chapter 5. 2.2 Current Issues in Co-Design A good reference for the reader regarding current issues in co-design is an I E E E roundtable [16] where seven designers were invited to express their views on the definitions, characteristics and shortcomings of co-design. Th i s roundtable actually shows how vaguely defined the term co-design st i l l is. For instance, Paul in sees co-design as all-hardware, programmable or not, while Harr says designers start from the premise that everything should be done in software and only the necessary hardware should be included. Nagasamy points out that the "co" in co-design should stand for "concurrent and cooperative design", and that the real challenge lies in designing the software along wi th the hardware. Agnew embraces this viewpoint too. Hav ing different teams working independently on hardware and on software is not really co-design. Erns t prefers call ing it computer-aided co-design because it is the C A D support that unifies hardware and software development, but he further states that no decent tools exist that go all the way down from specification to Register Transfer Level 7 ( R T L ) code, which is due the variety of target architectures. Wol f [20] also points out pressing needs for C A D tools in several design phases such as co-simulation, restructuring and part i t ioning of processes, system- and program-level evaluation. In Paul in 's opinion [16], the main issue in co-design is compilers for the diversity of processor architectures and the real-time constraints typical to embedded systems. B u t Nagasamy sees a single pressing issue, which is the capture of the design engineer's specification. Paul in and Har r agree this time that the design process in most cases starts from an incomplete specification; such specifications are assumed complete and accurate before design starts, in other words, this high-level description is usually not "debugged". A n impressive percentage of the roundtable article is taken by arguments for the need for good specifications. Yasuura comes right out and says academics should focus on a new specification model. 2.3 Models and Specification Languages for Co-design A s Staunstrup states in [19], the aim of high-level design techniques is to reduce design t ime and effort by moving decisions upwards in the abstraction level of the design models. A s designs become larger, the details are too many to be all grasped by one designer. Models are necessary for design overview. A s electronic designs become more complex they push the abstraction levels of models upwards, making it common today to describe hardware circui t ry in a similar way to the abstraction found in software. In other words, designing hardware and software is not that much different anymore. The delimitations of hardware and software components wi th in an appli-cation become less evident, and the designer needs to be able to model his design in a manner general enough to cover both hardware and software, without any com-mitment from the start as to what should be implemented in hardware and what in software. B u t most existing modeling tools and languages today start from either pure hardware description (for example G u p t a and DeMiche l i ' s approach [7]), pure software description (for example C O S Y M A [12]), or mixtures of both but clearly delimited by using a different language for each (like C o W a r e [15] and Ptolemy [8]). Vulcan [7] is a hardware-software cosynthesis system which performs au-tomated part i t ioning on an internal graph representation; init ially, the design is specified in HardwareC, a subset of C . Vulcan starts from assuming an all-hardware design and then performs repeated iterations of t ry ing to move parts of the design to software; the cri teria are: (a) whether t ime constraints are s t i l l satisfied and (b) minimiz ing communicat ion overheads. Vulcan can handle parallel processes: hard-ware and software components may run in parallel [11]. The method targets systems 8 consisting of A S I C s and a C P U to reduce A S I C size. C O S Y M A [12] is quite similar to Vulcan , except it starts from an all-software assumption of a design specified in C * . C * is a superset of C wi th added features to allow for t iming constraints, task concepts and task communicat ion. C O S Y M A targets systems consisting of one C P U and one A S I C for processor speed-up. A s mentioned, it is a "software-oriented" approach; hardware is added only where nec-essary because t iming constraints are violated by the all-software solution. It is an automated software-oriented part i t ioning tool with hardware extraction when needed. L Y C O S [11] is another automated part i t ioning tool . It also starts from trans-lating specifications to an internal graph representation, but it aims at not to l imi t the designers in using the specification language they prefer; it currently supports C and V H D L but the research group is working towards including other specifica-tion languages among the accepted ones - including Synchronized Transit ions. The way it works is that based on the internal representation graph, L Y C O S generates "Basic Bu i ld ing Blocks" which later can be moved between hardware and software. The part i t ioning algori thm - P A C E - is based on elaborate methods for estimating software execution time, hardware execution time and hardware area size. CoWare [15] is a hardware-software co-design environment which aims at integrating hardware and software components that were specified, implemented, simulated in different languages and with different tools. A similar approach is found in P to lemy [8]; part i t ioning and mapping is done at the very beginning of the design process. C o W a r e uses notions such as processes, ports, channels, protocols, communicat ion mechanisms - Ptolemy has blocks with portholes - the idea is that after hardware and software components are produced by different tools, they need to be interfaced correctly to result in the final system. These approaches do not solve the problem of the separate design of hardware and software for an embedded system, from the root of the problem, but a im at helping the designer "glue" the components together in a correct and reliable way at the end. The computat ional model of a design is a "delicate balance between abstract and concrete" (Staunstrup [19]): if it is too concrete, the designer is constrained by low-level decisions in early phases; if it is too abstract, it may become difficult at later stages to make an efficient realization. However, it should be abstract enough to describe computations in a range of technologies. 9 2.4 System Modeling and Co-simulation A s mentioned above in section 2.1, the process of going through various levels of abstraction of the design model requires simulation after the model for each level has been established, to make sure the model st i l l respects the ini t ia l system require-ments. If design is actually co-design of hardware and software, then simulation has to become co-simulation of hardware and software, since we want to simulate the system as a whole and not just isolated components. From the examples given in the previous section, we can conclude that system-level specifications can be viewed as homogeneous - when a single language is used, like in [7], [12] - or heterogeneous, where different languages are used for hardware parts and software parts ( [11], [8], [15]). Th is thesis uses and em-phasizes the benefits for the former, using S T as the single language for modeling the design. A most common example for heterogeneous specifications on the other hand is the mixed C - V H D L model. Heterogeneous specification approaches make co-simulation more complex and difficult since they have to deal wi th interfacing, translating protocols, etc. 2.5 Summary Co-design is a relatively new field of computer science, and one in which designer's efforts to cope wi th the difficulties of the moment have had to be "quick fixes" for the simple reason that industry and market did not have time to wait for "elegant" solutions. Al though much work has been done by academia to address the most pressing needs in industry, some issues, as mentioned in section 2.2, are s t i l l not at all addressed, or in our opinion not satisfactorily solved. Some of these issues, which the present thesis addresses, are: • high-level specification wi th possibilities for automatic verification; • modeling concurrency and non-determinism inherent to embedded systems; • providing a single specification language for both hardware and software -modeling the design as a whole rather than spl i t t ing it into hardware and software from the start . 10 C h a p t e r 3 Bus Interface Specification 3.1 The train set A s mentioned in chapter 1, the t rain set is a model train set built and used in our lab for real-time application experiments. 3.1.1 A c k n o w l e d g m e n t s a n d b r i e f h i s t o r y o f t he p r o j e c t Since the train bus project was started several years ago and many students (and 2 faculty members) contributed to its design, I wi l l give a brief history of the work: • 1992: F i r s t train-set built . The idea to do a train set was D r . C a r l Seger's based on a similar set-up at the Univers i ty of Waterloo. The hardware was designed and built by A n d y M a r t i n and E r i c B o r m . M i k e Donat and Nancy Day wrote demonstration software (to move trains randomly without collisions). • 1993: Train-set considered in class project in C p S c 513. A bus-based design was chosen. The existing buses were evaluated and we chose our own design for reasons of scalability and potential for verification (see section 3.4.4). The original train-bus protocol was worked out in a project involving Catherine Leung and Dwight Makaroff. • 1994: D a v i d Weih wrote an S T model for the ISA to train-bus interface. • 1995: M o h a m m a d Darwish designed hardware for the bus interface based on David ' s code. • 1996: D r . M a r k Greenstreet recognized the ground shift problem. His solution to this (see section 3.4.3) involved changing the protocol from two-phase to four-phase; also adding series resistors to drivers for signals other than the 11 clocks; using complementary signaling for clocks to improve robustness. It appears that complementary signaling is not needed for other signals; doing so would result in an unwieldy number of wires in the bus. • 1996: I took over the project. 3.1.2 Description of train set components Figure 3.1 is a diagram of the train track system; it shows tracks, switches (marked wi th an "S") and position sensors (small circles). The train set has been working with three trains in the past; they are shown in the start ing posit ion. There are about 18 meters of track, 13 track switches and 60 position sensors. The sensors are photo-darlington transistors that detect the shadow of a t rain as it passes over the sensor. The train engines include decoder chips like the ones used in infrared (IR) controllers for T V s , V C R s etc. Commands are sent to the trains by pulsing the power supply that drives the track. Each such command has 9 bits: 5 bits specify a t rain, and 4 specify the speed. Each train has 8 forward and 8 reverse speeds. There are 32 train addresses, but not enough room on the track for that many trains. Typical ly , the t rain set has been operated with three trains. The figure-8 type of track layout requires a polarity reverser. Trains may start in the same direction and end up facing each other. This means that if ini t ia l ly both had all the right wheels touching the positive rail and all the left wheels touching the negative rai l , eventually one of them wi l l have all the right wheels negative; that train went across a polarity reverser. Polar i ty reversal means there must be electrical breaks in the rails. Furthermore, the engines draw current from all of their wheels, which means that all of the wheels on one side of the engine are connected in parallel. The polarity reverser is a segment of track that is electrically isolated from the segments before and after i t . A s a train approaches this segment, the segment is connected to the power supply in the same polarity as the segment that the train is currently on. This allows the train to safely cross onto the reverser. W h e n the train is fully on the reverser, the polarity of the reverser is flipped. Th is allows the train to safely continue on to the next segment. The trains have bridge rectifiers in them so they can accept power of either polari ty without changing direction. The direction control is independent of the polarity of the tracks. The power is D C (a reverser would s t i l l needed if A C power were used). The difference between the existing and the proposed train set is in the implementation of the controller. The existing train-set was implemented by two former graduate students in 1992, as described in section 3.2. The necessity for a more modular design which could better serve design and verification experiments 12 13 became evident later. A key piece of the new design is a bus interface, which is the focus of this thesis. 3.2 The existing design Figure 3.2: The old architecture Figure 3.2 shows the existing train controller architecture. Programs are writ ten and cross-compiled on the S U N workstat ion. Executables are then down-loaded over a serial link to the single board computer ( S B C ) . A M O T O R O L A 68010 based controller was used because U N I X doesn't provide real-time guarantees; the simpler computer can respond to real time events. The 68010 S B C communicates with the interface hardware using its parallel port . Th is involves using undocu-mented features of the parallel port to allow da ta to be read from the port . The interface hardware consists of 31 T T L chips in addit ion to some discrete components for the speed controller and to read the photo transistors. There is a rats nest of wires under the track layout table, to connect to the switches and sensors in the track. The design is monolithic and incompletely documented, which makes any hardware modification difficult and unreliable. 3.3 The proposed design To support more experimentation, we wanted a more modular design. A n adequately documented design is also a prerequisite for verification. The key change is to make the control and sensor hardware distr ibuted. Th i s wi l l allow individual pieces to be replaced for design experiments. 14 train-bus switch control module sensor control module speed control module Figure 3.3: The proposed architecture Figure 3.3 presents the proposed architecture for the t rain set control . The software wi l l run on a P C as the host computer; the train-bus controller wil l be a P C - b o a r d . We chose a PC-based controller because P C s are readily available, cheap, and provide a popular software development environment. Th is also means we can further expand the design in the future - we can add other interfaces, such as network cards to communicate wi th other computers during experiments. The use of D O S makes it possible for an application to override all operating system functionality, thus making real-time applications possible. The separate modules for each control and sensor function allow the design to be modified one piece at a time; they provide an alternative to the monolithic rats nest of wires of the current design. 3.4 The train-bus The decentralization of the design requires an organized means of communi-cation between the modules. Th is is the train-bus, which provides a simple interface to sensor and actuator modules. The simple design should help teaching and verifi-15 cation research. 3.4.1 High-level design choices A parallel bus was chosen for teaching and verification purposes. A l so , a protocol for the bus had to be established: it should be synchronous, master-slave. Th is should make it easier to teach to C S grad students with litt le hardware experience. Bus operations are simple. There is a clear mapping of wires to functions (unlike a serial bus where the same wire carries several different logical signals at different times). We hope that this wi l l make formal verification easier as well. F rom a mechanical point of view, the decision was for r ibbon cable. Devices can be connected v ia cr imp connectors. The bus goes under most of the track so that sensor and switch modules can be close to the devices that they sense or control . We expect to use between 5 and 15 meters of ribbon cable. Th is makes it impract ical to ensure tight control of electrical properties. 3.4.2 Logical details The wires of the train-bus are split into logical groups as follows: • 8 wires for data • 8 wires for address • 4 wires for command The justification for choosing these numbers is as follows: for address, 4 bits pre-sented a risk for running out of device addresses if the design was successful. 8 bits offer 256 distinct addresses, which seems large enough to be a safe choice (since slave devices may be controllers that can handle several sensors/actuators). For data, an 8 bit bus is small enough to keep the bus from having too many wires and seems adequate for typical control applications. The 4 bits for command offer 16 possible commands, which means again flexibility for future extensions. 3.4.3 Electrical details This section presents some issues that need to be considered when implementing a long bus with many devices. The devices draw no D C power. The bus operates at a relative low clock frequency, giving the signals t ime to settle to valid digital values. However the low frequency does not mean we can completely ignore high-frequency effects. Ringing, spurious triggering, etc. are all possibilities because the logic devices can drive their outputs wi th small rise and fall-times, the ribbon cable 16 can transmit relatively high-frequency signals, and the logic devices can respond on short time-scales. We have to make sure that this sensitivity to short-time scale behaviour doesn't cause the system to malfunction. Our concern is about reflections and about power voltage shifts that may occur for imbalanced changes of the signals. Accord ing to Kirchhoff 's current law, the current through the ground circuit must equal the current through the signal wires. The signal wires each have their own impedance so it wi l l take a certain time for the data/address lines to become low, during which the ground voltage level is shifted upwards. A s a worst case example, let's see what happens if 8 address and 4 command wires happen to change in the same direction at the same time (later in this section, figure 3.5 and the related explanation show why we are considering this example). We get the voltage divider effect shown in figure 3.4, where V1/V2 = 2/3 and VI + V2 — 5, which means that the signal lines wi l l go to 2 V (instead of 5V) and the 8 ground lines wi l l go to - 3 V . Figure 3.4: Voltage shifts at imbalanced changes of signal lines The signal lines of the train bus are very long and have to be analyzed as transmission lines. Reflection along the cable lines causes the power lines to bounce back and forth after such shifts, and since ground is the reference voltage, the circuit behaves as if the signal lines would bounce. Even if power shifts would not be a problem, reflection means that every t ime we have a transitions at the dr iv ing end of a line, this voltage change wil l travel along the cable and get reflected at the other end, which results in ringing on the signal lines. We apply a strategy to deal wi th this problem: 1 7 • We use series resistors to l imit drive current for address, data, and command. The impedance of the ribbon cable was measured (about 70 ohms). Using 680 ohm series resistors gives a total drive impedance of 680/12 = 56 ohms (for the worst case considered, of 12 wires switching simultaneously). Ground impedance is 70/8 = 9 ohms. Thus , we expect a worst-case ground shift of about 1 volt . • We use differential clocking, so clock signals should have minimal contribution to ground shift. Also , wi th the 4-phase protocol, address and command lines are changing at different times from data lines (less wires that may change level at the same time). A t iming diagram of the new protocol is shown in figure 3.5. The actions corresponding to the 4 marked clock edges are as C L K l CLK2 0 0 Figure 3.5: A 4-phased Tra in-Bus Pro tocol follows: - 1. controller sends address and command; — 2. device reads address and command; - 3. controller or device sends data (depending if it was a read or a write); — 4. data received. • We use Schmitt-triggers and C-element clock debouncers, as in figure 3.6. The Schmit t triggers annihilate slight variations on the signal lines, while the Mue l l e r -C element eliminates ringing. Tha t is, one signal can oscillate until the other one changes, without causing problems. A s a summary, we make the clock distr ibution robust and we only look at the address, data, and command signals at times when they are guaranteed to have settled. 18 a b c A Mueller-C element © © Figure 3.6: The train-bus clocks 1 9 3.4.4 C o m p a r i s o n w i t h o t h e r bus -schemes • H P - I B : (Hewlett Packard Instrumentation Bus interface, or G P - I B or I E E E 488 standard) Th i s bus standard has similar bandwidth (also 8 bit parallel data). It allows a l imited number of devices to connect (15). Devices present a D C load, which l imits scalability. • I IC: This is a serial, twisted pair interface standard for embedded controllers. It would require less wir ing and we could use micro-controller chips that have the interface hardware buil t- in. In that case however, all the design details would be buried in those microcontrollers. We believe that it would be difficult to write a satisfactory formal model for such a controller. Th is would be a barrier to our verification efforts. Also , hiding all of the hardware would make the design be of less pedagogical value 3.5 The ISA to train-bus interface A s mentioned in section 3.3, the proposed design uses a controller between the host P C and the train bus; the controller is the interface between the ISA-bus and the train-bus. The design of this interface is the subject of this thesis: the interface is needed before other modules can be built and tested. A l so , interfacing between two different bus protocols with two different sets of t iming requirements provides an interesting design example. T h e I S A b u s We used the P C ' s Industry Standard Archi tecture (ISA) bus because it 's simple and we do not need the higher performance of other P C buses. Fol lowing is a very brief description of the ISA-bus, presenting only details relevant for our applicat ion. More information can be found in [17]. A standard ISA 8-bit I / O cycle is given in figure 3.7. The meanings of the signal names are: • B C L K - bus clock: the ISA clock; • A E N - address enable. Th is line is driven by the platform circui t ry as an indication to I S A resources not to respond to the address and I / O command lines when the D M A controller is the bus owner. 20 B C L K C O M M A N D ( IOW / IOR) D A T A (READ) D A T A (WRITE) Figure 3.7: Standard ISA cycle • B A L E - bus address latch enable. Th is signal is driven by the platform C P U to indicate when the address lines are valid. Th is signal is used to latch the address lines. • SA(0-9) - the address lines. • I O W - I / O write: indicates a write cycle to an inpu t /ou tpu t port; • I O R - I / O read: similar as above; The cycle starts with a rising edge of B A L E . On the falling edge of B A L E , the address is guaranteed to be valid (on lines SAO-9). O n the rising edge of BCLK3 we are guaranteed to have the correct value for the command lines. There are two separate lines for read and for write: I O R and I O W , both active low. If neither is driven low, this means the cycle is not an IO-access. If it is an IO-write cycle, the data to be wri t ten is already valid at the falling edge of I O W . If it is an IO-read cycle, the data must be valid on the fifth rising edge of B C L K after I O W goes low ( B C L K 7 in the figure). The ISA-bus supports many other operations. For example, there are "early read" and "early write" operations that can be performed if the device asserts the 21 appropriate signals. Alternatively, the device can signal that it is not ready and the bus stalls until the device indicates that it is ready. We use the default t imings for simplicity. There are also 16-bit transfer cycles for both 10 and memory operations, but we do not need to use these. R e a d and wr i te transactions on the train-bus A t iming diagram for the 4-phase clocking was shown in figure 3.5. The train-bus protocol operates on a master-slave basis; the controller is always the master of the train bus, while the devices connected to it are the slaves. Regardless of the direction of the transfer, it is always the master who initiates i t . The least significant bit of the command specifies whether it is a command of type write or read, so there are 8 write commands and 8 read commands possible. The signal diagram for a write command on the train-bus is shown in figure 3.8 (a write to a device connected to the train-bus). On the rising edge of tbclki (clock-event #1) , the master (the tb_clkl tb_clk2 tb_addr, tb_cmd tb_data / \ 1 L a / X \ i i master sends (' master drives address and ' data lines command i device reads address and command device reads data Figure 3.8: A write to a device on the train-bus bus controller) sends the address of the device the command is intended for, and the actual command. O n the following clock event (#2), the rising edge of tbclk2, the devices decode the address and command lines. O n the falling edge of tbclki (clock-event #3) the master drives the data lines with the information intended for 22 the addressed device, and on the falling edge of tbclk2 (clock-event #4) the device that decoded its own address on event #2 wi l l read the data. A read is quite similar except the direction of the data transfer is reversed so on clock-event #3 the slave device (instead of the master) is the one who drives the data lines with the requested data, and it is the master who reads the data lines on clock-event #4. T h e top-level control ler design We can model the design as a F in i te State Machine ( F S M ) for the ISA bus on one end, another F S M for the train-bus at the other end, and F I F O s in-between for communicat ion. The application running on the P C , i.e., performing write and read trans-actions on the ISA-bus, wil l see the controller as a collection of registers. We need one for D a t a , Address and C o m m a n d each, and then we also need one for Status because we need to know when the controller is ready to accept a new command; and since the train-bus operates at a much lower frequency than the ISA-bus, this means we must have a way to inform the application when there is requested data available to read. So our Status register has two bits of information, CfO (Command F I F O stage 0 is full) and R f l (Result F I F O stage 1 is full). The application must also be able to reset the controller; this is done by performing a write to the Status register. Every program running on the host computer for the train-set control wi l l need to start by doing a write to this register. Note that the Status register may be both read and wri t ten, as well as the D a t a register; but the Address and C o m m a n d registers may only be wri t ten. Before sending a command, the program has to check whether the controller is ready for a new command, so it needs to read the Status register unti l the CfO bit indicates the F I F O has room in its bot tom stage for a new command. The controller guarantees that only the application can set this bit, so once it was read as empty, it wi l l stay so until the application issues a new command, that is, performs a write to the C o m m a n d register. The application may write to the Address and D a t a registers without changing the status of the controller; only a write to the C o m m a n d register changes that. A write to the C o m m a n d register wi l l cause the F I F O s to advance even if there were not new values supplied to the D a t a and Address registers. Th is means that if a new write command was issued for instance, the last values wri t ten into those registers wi l l be used for the new command. A s mentioned in the section above, the controller does not need to know about the exact command, only about the transfer direction (read/wri te) . A write command does not need to be retired, but a read command does, because when 23 issuing the command the application only asks for the data, and then it has to wait unti l the device provides the requested data. To retire a command, the program needs to read the Status register until the R f l bit indicates that the result F I F O has new da ta available; then it may perform a read from the D a t a register to get the actual da ta value. A s with CfO, the controller guarantees that once R f l became high, it wi l l stay so until the program performs a read from the D a t a register, which is the only way to reset this bit. The controller also guarantees that the da ta read is always in the order the read commands were dispatched. Due to the F I F O s , we may have several train-bus transactions outstanding at any time; however, the condition for correct operation of the controller is that operations are completed in the same order that they were issued by the program. 3.6 Summary We presented the train-set - the history of the project, the description of its com-ponents, and the train-bus. For the train-bus we justified the choice for the type of the bus (and the number of wires) as well as for the protocol. We explained the electrical considerations that were the reason for changing the protocol from two-phase to four-phase. We further justified the choice for a PC-p la t fo rm for the bus-controller. The circuit is an interface between the ISA bus on the P C and the train-bus on the experimental t rain set up; we described the protocols used in each of these buses, and the interaction between the two protocols. 24 C h a p t e r 4 Specification Language 4.1 Why ST ? A n important issue in co-design is correct design specification capture (Nagasamy, [16]; Wolf, [20]). Because of the complex application nature of embedded systems, a clean and complete specification is both very important and hard to achieve. The penalty of specification errors grows with the time unti l detection. Embedded systems can contain hardware, software, analog circuits, and me-chanical parts. Interfacing them correctly is as important as it is challenging. The components are working at the same time, often at different rates. This is why wri t ing specifications in sequential programming languages may not be accurate. Staunstrup [19] makes a strong case for the use of concurrent programming languages in the design of embedded systems: for such systems, the order of external events and computat ion systems cannot be known in advance or prescribed, so sequential languages are not adequate since the operation sequence is unknown. Concurrent models are more appropriate since they can model non-determinacy, simultaneity, and multiprocessing, which arise in embedded systems. Synchronized Transitions (ST) [18] is a concurrent programming language that wi l l be described in section 4.2. It is easy to learn and use, yet very powerful for modeling. Its advantages address many of the current co-design problems (some cited above) and bottlenecks. A major co-design bottleneck is in the design flow from specification to im-plementation (Nagasamy, [16]). In that respect, S T code is easy to translate to either another programming language like C or a hardware description language like V H D L . K e y areas of co-design like part i t ioning and co-simulation are also helped by using S T . The same notation is used to model both hardware and software. A l -though we cannot claim we have practical synthesis techniques for going from an 25 arbitrary ST program to a hardware implementation or to an efficient software im-plementation, we do have techniques that work if the program is written in a certain style. However, the styles that are suitable for hardware implementation are not the same as the styles that are suitable for software implementation. We also take a refinement based approach. The design starts with a high-level program that models the key behaviours of the intended system. This program is successively refined, adding more detail at each step, until we get something we can implement. Although there may be little or no distinction between hardware and software at the most abstract level, we tend to head towards hardware-specific or software specific styles for different parts of the program in this refinement process. Thus, partitioning is done by the designer as part of the refinement process. Co-simulation is done naturally since everything, hardware and software, is modeled in the same ST program. Last but not least, verification, or rather co-verification, is well supported by ST. It can even be done automatically [10, 13] 4.2 Synchronized Transitions Synchronized Transitions (ST) is a concurrent programming language. In ST a design is modeled as a set of independent t ransi t ions. Transitions consist of a guard and a mult i -assignment . For example < a AND b ->• c := d > is read "a and b enables c gets d". "a A N D 6" is the guard of this transition; in other words, the assignment c :— d can only be executed if the guard evaluates to true. A transition is said to be enabled if the guard is satisfied. Transitions are executed a tomical ly , i.e. the evaluation of the guard and performing the multi-assignment is a single indivisible operation. 4.2.1 Combinators ST offers three transition combinators, ||, * and +. If two or more transitions are combined with the asynchronous combinator, ||, then at each step in program execution, one is selected non-determinis t ica l ly from those that are enabled. For example, if we have < a ->• c := d > || < b->e:=f > 26 then if only one of a or b holds, the corresponding assignment will be executed; how-ever, if both hold, one of the transitions will be chosen, but the choice is not specified by the program. This allows abstract models to describe a wide class of behaviours. It also provides an opportunity for optimization when deriving an implementation. For example, the implementation may choose which transition to execute to max-imize performance or minimize the amount of hardware required, or to optimize some trade-offs. The final implementation is often completely deterministic. The operands of the product combinator, *, are performed as a single, atomic state transition. <C a -> c := d > * < 6 - > e : = / > is equivalent to < a A N D b c, e := d, f > in other words the combined transitions are enabled only if both of their guards are enabled. For transitions combined with the synchronous combinator, +, at each step during program execution all enabled transitions are executed as a single atomic operation. For example, if we have: < a —>• c := d > + < 6 - > e := / > this means that if only one of a, b is true, then only the corresponding assignment is executed, and if both a and b are true, then the two assignments are executed as an atomic operation. Any transition or combination of transitions that causes a write conflict is illegal. A write conflict occurs when there is more than one assignment to the same variable in the same atomic operation. A write conflict can occur if transitions are erroneously combined with the + or the * operator, or even within a single transitions if the same variable is used more than once on the left side of a multias-signment: for example, if two array elements, a(i) and a(j) are on the left side, and i = j holds when the transition is enabled. 4.2.2 Modular Designs 27 A solution to dealing with increasingly complex designs is making them mod-ular. A modular design can be flat, i.e. all modules communicat ing on the same level, or hierarchical - a module can contain other modules in its internal structure. Synchronized Transitions supports modular and hierarchical designs through the use of cells - collections of state variables and transitions. In a hardware analogy, cells are like subcircuits. One cell may have several different instantiations just like a circuit may have many instances of the same subcircuit wi th different external connections. Likewise, a cell may be composed of other cells just as a circuit design may consist of a hierarchy of subcells. A n S T program has a top cell that is the root of this cell hierarchy. The interface of a cell to the outside world are its formal parameters. These can be of type static or state. Formal parameters that have been declared as S T A T E variables are bound to storage locations (like latches on a chip or memory locations of a process) when the cell is instantiated. B o t h the cell and its parent can read or write these parameters, which provides a mechanism of communicat ion between cells. The values of S T A T I C parameters are bound when the cell is instantiated and are typically used to control the size of data structures or control recursive instantiations. The default for formal parameters is S T A T E . S T also has arrays, records and functions, which have the usual interpreta-t ion. S T programs can be split into modules; each module consists of a definition part (file .std) and an implementation part (file .sti). Th is eases the wri t ing and maintaining of the program; however, a module can contain descriptions of several cells, so program modules do not necessarily have a clear mapping to the design mod-ules (the cells); this depends on the programmer's way of organizing his program files. S T also allows a module to be wri t ten with the definition part in S T and the implementation part in C . This is a way to refine an abstract S T description to detailed code. 4.2.3 ST for Co-design M o d e l i n g synchronous c i r cu i t ry w i t h + Let 's take a three-bit synchronous counter. In S T , it would be described as follows: < incr -> qo := NOTqO > (* i l *) + <C incr A N D qO -> ql := NOTql > (* t2 *) + < incr A N D gO A N D ql -> q2 := NOTq2 > (* £3 *) A diagram of the digital c i rcui t ry to implement this is shown in figure 4.1. "expr;" in this case mean just " N O T q ," , but they could be more complicated in other examples (here we could just have taken them from the negated output of the 2 8 D-latch, but we wanted to illustrate an approach); "enable;" is high if transition i is enabled and low otherwise. For example, if enablei is high, on the next clock cycle the qO latch will load expri, otherwise it will keep its old value. M U X exprl enablei expr2 enable2 expr3 enable3 D Q| qO D-latch M U X , Q qi D-latch M U X D Q q2 D-latch exprl expr2 expr3 enablei enable2 enable3 combinational logic Figure 4.1: A direct mapping of the ST 3-bit counter to hardware This hardware can be described in V H D L as follows: e n t i t y counter i s por t ( e l k , i n c : i n s t d _ l o g i c ; ent: out s td_ log ic_vec to r (2 downto 0) ) ; end counter; a r ch i t ec tu re s t r uc t of counter i s component mux por t ( inO, i n l , s e l e c t : i n s t d _ l o g i c ; out: out s t d_ log i c ) ; end component; component d_la tch por t ( d , e l k : i n s t d _ l o g i c ; q: out s t d _ l o g i c ) ; 29 end component; component comb_logic por t ( i n l , i n 2 , i n 3 , i n4 : i n s t d _ l o g i c ; o u t l , out2, out3, out4, out5, out6: out s t d_ log i c ) ; end component; s i g n a l e x p r l , expr2, expr3: s t d _ l o g i c ; s i g n a l e n a b l e l , enable2, enable3: s t d _ l o g i c ; s i g n a l dO, d l , d2: s t d _ l o g i c ; s i g n a l q: s td_ log ic_vec to r (2 downto 0 ) ; begin ml : mux( q (0 ) , e x p r l , e n a b l e l , dO); m2: mux( q ( l ) , expr2, enable2, d l ) ; m3: mux( q (2 ) , expr3, enable3, d2); qO: d_latch( dO, e l k , q(0) ) ; q l : d_latch( d l , e l k , q ( l ) ) ; q2: d_latch( d2, e l k , q(2) ) ; c: comb_logic( q (0 ) , q ( l ) , q (2) , i n c , e x p r l , expr2, expr3, enab l e l , enable2, enable3 ) ; end s t r u c t ; where the the multiplexer and the D-latch are regular multiplexers and D-latches and the combinational logic performs the logic operations described in the S T code. M i x i n g combinators : non-determinism to mode l mul t ip le clock domains A s mentioned, the train-bus controller is an interface between two synchronous buses operating at different clock rates. A description of this in S T would look like: (isal + isa2 + isa3 + ...) || isaTOtrainbusFIFOQ || trainbusTOisaFIFOQ || [tbl + tb2 + m + ...) where isal,isa2,... are transitions synchronous to the ISA-bus and tbl,tb2,... are transitions synchronous to the train-bus. Note that this S T model does not state the relative frequency of the ISA-bus and the train-bus and is robust to changes in the train-bus frequency. In other words, we do not have to worry about frequency details at this high-level description stage. 30 To refine this model for a particular clock frequency, even a specific clocking protocol, we can write: (isal + isa2 + isa3 + ...) + isaTOtrainbusFIFOQ + trainbusTOisaFIFOQ + trainbusClockGeneratorQ + < tbEdgel > *{tbla + tblb + tblc+ ...) + <£.tbEdge2^> *(tb2a + tb2b + tb2c+...) + <^tbEdge3^> *(tb3a + tb3b + tbZc + ...) + -C tbEdgeA > *(i64a + 4646 + tb4c + ...) The asynchronous combinator || has disappeared and the synchronous combinator + is used instead, since we went from a high-level description of components operating at different speeds, to a refined (lower-level) description where we already decided about the clocking methodology. Note there are transitions without any actions in the example above (e.g. <C tbEdgel >>); when combined wi th the product operator *, such transitions act as guards for the transitions they are combined wi th . The execution of this code looks as follows: at every execution step, the following group of transitions wil l be executed as an atomic operation: • every enabled transit ion from the isa-group; • every enabled transit ion from the trainbusTOisaFIFO-group; • every enabled transit ion from the isaTOtrainbusFIFO-group; • the counter model is incremented; the counter divides the ISA-clock signal to generate the clocking required for the train-bus. In our case, this is a 4-phase clocking which means the events of interest are the rising and falling edges of two differential clocks (tbEdgel to tbEdge4). • whenever tbEdgei is true, every enabled transit ion from the group £6, is exe-cuted. The train-bus clock generator is modeled in a similar fashion. It consists of two cells, a counter modulo 21 and a counter modulo 4 that generates the two delayed clocks p h i i , phi2 and the pulses corresponding to the 4 edges (rising and falling for the two clocks). The "counter21" cell (in figure 4.2) is a value of a C E L L type, its value is given by the initializer expression, which is roughly a lambda expression. The type definition for the C E L L type defines the types and storage classes of the parameters 31 STATIC counter21: C0UNTER21 = STATIC max: INTEGER = 21; STATE count: INTEGER; BEGIN « reset -> count := 1 » « NOT reset » * ( « count := (count+1) MOD m a x » + « inc := count=0 » ) END; Figure 4.2: The counter modulo-21 for the cell. The code is straightforward: it generates a positive pulse for inc every 21 execution steps. The counter4-cell (see figure 4.3) uses the output of the modulo-21 counter to toggle phi\\ and phi2 follows phi\ by a delay equal to the period of the signal inc. Th is means that if we use the four events corresponding to the 4 edges of the signals phi\ and phi2, they wi l l be separated by periods equal to the inc period, and if we look at the set of 4 events, they wi l l repeat after a period of 4 * period(inc). The two cells are connected in the main cell of the controller hierarchy as shown in figure 4.4. The full code of this cell, wi th comments, can be found in appendix A ; the purpose of the above fragment was just to illustrate that we need 3 of the 4 events to control the operations of some of the F I F O buffers, so we presented these actions in a simplified way. M i x i n g combinators : non-de te rmin ism to model the envi ronment The non-determinism of S T can be used to model the environment for a design. For example, the train-bus controller should work with any legal software running on the P C , and we do not want to l imi t our model to describing one specific program. The S T model for the ISA interface can perform any sequence of ISA reads and writes that correspond to legal transactions with the bus controller. Figure 4.5 gives a state diagram of a "dispatcher" cell - a cell modeling the legal actions a train-set control software may take to send commands to the train-bus. Note that from state S T A R T , several actions may be taken without any condition specified on the arrows 32 STATIC counter4: C0UNTER4 = STATE p h i l , phi2: BOOLEAN; BEGIN « reset -> p h i l , phi2 := FALSE, FALSE » + « (NOT reset) AND inc » * ( « p h i l := NOT phi2 » + « phi2 := p h i l » ) + « evl := inc AND (NOT reset) AND p h i l AND (NOT phi2) » + « ev2 := inc AND (NOT reset) AND p h i l AND phi2 » + « ev3 := inc AND (NOT reset) AND (NOT phil) AND phi2 » + « ev4 := inc AND (NOT reset) AND (NOT phil) AND (NOT phi2) » END; Figure 4.3: The differential clock generator STATIC bcCell: BCcell = (* the model for the bus controller *) (* ... declaration of internal signals *) BEGIN counter21( reset, inc ) + counter4( reset, inc, p h i l , phi2, tbEdgel, tbEdge2, tbEdge3, tbEdge4 ) + « tbEdgel » * ( AdvanceAddressFIFOO + AdvanceCommandFIFOQ ) + « tbEdge3 » * WriteTrainDataO + « tbEdge4 » * ReadTrainDataO (*+...*) Figure 4.4: Instantiations of the counter cells 33 read status CfO CfO = Command FIFO stage 0 is full Figure 4.5: State Diagram for the C o m m a n d Dispatcher 34 « state = START » * ( ReadStatusO I| WriteAddress() I | WriteDataQ I I WriteCmdO * « state := ISSUED » ) + « state = ISSUED -> state := NEXT » * ReadStatus() + « state = NEXT » * ( « CfO » * ReadStatusO + « NOT CfO » * « state := START » ) Figure 4.6: S T code for the dispatcher cell towards these actions; this means that from state S T A R T , any of "read status", "write address", and "write data" can be done without advancing to the following state; only wr i t ing a command advances the state machine to I S S U E D . After we issued a command, we cannot issue the'next before we know the controller is ready to accept a new command, which is signaled by the CfO status bit being false. CfO is an acronym for "Command F I F O , stage 0"; CfO being true indicates that the stage that accepts a new command is full . So the state machine stays in the intermediary state " N E X T " until the status bit CfO indicates a new command can be dispatched, and the state machine moves back to S T A R T . Also note that since we have a choice of actions in the S T A R T state, it means the order of sending the data and address components is not specified; what 's more, we can dispatch a new command without providing new data and/or address values; in that case, the last wri t ten data and address values wi l l be the ones sent onto the train-bus. The S T code for such a cell is presented in figure 4.6. The non-determinism of the choice between the actions that can be taken from the S T A R T state is modeled by using the asynchronous combinator ||. We also need a model of a cell that can retire data requested by a previous read command. The state diagram for such a "retire" cell is given in figure 4.7. It is similar to the one for the dispatcher, but simpler because there is not a choice of actions that can be done from a certain state. A new response can only be read if another status bit, R f l (which stands for "response F I F O 1 full), is true. The corresponding code is in figure 4.8. The application program wi l l look like: 35 Rfl NOT Rfl read status read status read data Rfl = Result FIFO stage 1 is full Figure 4.7: State Diagram for the Ret i r ing of a C o m m a n d « state = START » * ( « NOT R f l » * ReadStatusO + « R f l » * « state := NEWDATA » ) + « state = NEWDATA -> state := RECEIVED » * ReadDataO + « state = RECEIVED -> state := START » * ReadStatusO Figure 4.8: S T code for the retire cell 36 dispatchCell{) || retireCellQ This allows the client to perform split-transaction operations - i.e., the client may dispatch a new command while one or more previous commands are st i l l out-standing; the client is guaranteed to have the commands retired in the order they were dispatched. 4.3 Summary After reviewing some of the problems that the co-design community is faced wi th , we are proposing the use of Synchronized Transitions as a specification language for co-design. The language has been extensively used for hardware design by other research groups, and the book published about S T [18] mentions the possibility of using it for co-design. We enumerate the features of S T that make it suitable for embedded system design, and give examples of the use of S T ' s synchronous and asynchronous combinators. The use of both combinators in the same design model has not been applied in previous research with S T . We explain the advantages of removing this l imitat ion (i.e., not being able to mix the two types of combinators) by giving examples of how we apply this new method to our train-bus controller design. 37 C h a p t e r 5 The Design The bus controller is an interface between two buses running at different speeds and having different clocking methodologies and protocols. It consists essentially of buffers and logic to control the buffering so that the two protocols are respected. 5.1 ST model design 5.1.1 The F I F O Buffers Sending commands to the train-bus A s described in chapters 3 and 4, the train-bus can be logically split into train-data, train-address and train-command. Sending a command means sending the three components; da ta and address are optional and the order of sending them does not matter (as shown in figure 4.5). Because the two buses run at different speeds - the ISA bus goes 84 times faster than the train bus - F I F O s are used to temporari ly store the information until it can be sent out to the trainbus. A new command can only be sent if the F I F O is not full . The commands that are implemented so far are of type read, write and idle. A register view of the bus controller The P C sees the bus controller as a collection of registers it can write t o / read from. The four registers are Data, Address, Command and Status, and their addresses are (in hexadecimal) 0x300, 0x304, 0x308, 0x30C. A register view of the bus controller is given in figure 5.1. The number of stages for each F I F O is shown there as well: 3 for Address and C o m m a n d , 4 for Da ta -Wri te , 2 for Data-Read and Status-Read. A write to the Status register 38 causes a reset of the whole controller; the picture shows the two stages of the counter generating the clocks (see section 4.2.3, figures 4.2 and 4.3), which have all outputs set to "0" on reset. The data-write F I F O has an addit ional stage compared to the address and command ones, because of the four-phase clock - this F I F O is being read at a different clock edge. (in) D A T A - REGISTER (out) ADDRESS - REGISTER C O M M A N D - REGISTER D A T A • R E A D D A T A - WRITE ( W ) ADDRESS - WRITE ( R ) C O M M A N D - W R I T E (C) (in) REGISTER STATUS - INFO (S) (out) reset count21 count4 -Figure 5.1: Bus Control ler - Register V iew The top stages of the Address (A) and C o m m a n d (C) F I F O s are being read at t b E d g e l , while the top stage of the Da ta -Wr i te (W) F I F O is being read at tbEdge3. The A and C F I F O s advance when the shif tCf (shift C o m m a n d F I F O ) signal is high, and that signal goes high whenever the last C - F I F O stage is empty. B u t that stage could be empty when the last W stage is not. O n the other hand, new commands may be sent by the application to the controller if the C - F I F O is not full . T h a t means w,e could send a new da ta component to the W - F I F O when the W - F I F O is s t i l l full, if it doesn't advance on the same signal. Th is is why an. addit ional W stage was added, to buffer the delay from t b E d g e l to tbEdge3. In 39 other words, this is in order to avoid the situation illustrated in figure 5.2, where we risk overwrit ing the write-data. For a better understanding see also figure 5.3; the signals names are explained in the following section and in appendix A . Since it is an S T cell instantiation diagram, it does not explicit ly show the clock signal. The V H D L code has a clock signal (the controller operates on the ISA clock) input for every buffer showed in the figure (each square represents one F I F O buffer, the names and stages of the F I F O s are printed beneath the buffer-cells). The buses carrying the information to be stored in the latches (buffers) are shown as horizontal lines entering the left side of each buffer, while the F I F O control signals are shown as connected to the top side of each buffer (these are usually load or chip-select or output-enable signals; the command buffer, stage 2, is the special buffer described in section 5.1.2). The design simulation worked correctly with only 2 stages for the A and C F I F O s and 3 stages for the W - F I F O , but several idle commands appeared on the train bus in-between the useful ones, which meant that too much time was lost wait ing for the the first stage of the C - F I F O to become empty in order to send a new command. (The controller issues idle train-bus cycles, identified by the idle-command code, every time it does not have a command ready to be issued, or when the result F I F O is full and it therefore cannot record the result for a new command.) A n d since the ISA-bus runs at a higher frequency than the train-bus, it could provide the useful commands at a much higher rate than the train-bus could process them; this means the only problem were the insufficient F I F O stages, so I increased the F I F O depth; currently, sending 10 or 20 commands works without idle train-bus cycle insertion. The buffer-cells used to model the F I F O are defined in the buffers.sti module (see appendix A ) , and their instantiations are shown in appendix B . Different buffers had to be used since some require load-signals, others are tristate buffers and require output-enable signals; some are 4-bit wide ( C - F I F O ) , some have 2-bit inputs (the 2 status bits R f l and CfO in case of the S ta tus -F IFO) , others are 8-bit wide. Because of the S T syntax, declaring a general buffer and instantiat ing it in different ways would have been complicated. Also for debugging purposes, I wanted to be able to print different messages from inside different buffer cells, which would not have been possible for different instantiations of the same S T cell. Section 4.2.3 gave a detailed description of how the interfacing of the two bus protocols is achieved (see especially figure 4.5). Figure 5.4 reminds the reader of the steps for sending/ret ir ing commands from the train-bus; this is a diagram that was used as a sketch to write the ST-code for the module "driver.st i" (appendix A ) . 40 FIFO status right before tbEdgel FIFO status between tbEdgel and tbEdge3 Figure 5.2: The need for an addit ional data-write buffer 41 -4H I T e •2 X Figure 5.3: The "out-FIFOs": Cmd, Addr and Data-Write 42 > Figure 5.4: State Diagram for Modu le driver.sti 43 Read ing the Status A t every clock cycle (every S T program step), the outputs CfO (command F I F O full) and R f l (result F I F O has data available) from the queue controller are latched into the first Status F I F O stage buffer. A t any point the application decides to do a read from the Status Register, this information is available wi th in the same ISA-IOread cycle . Read ing Response D a t a Whenever the controller has result da ta available (Rf l=h igh ) , the application can do a read from the D a t a Register, which wi l l cause the controller to anable the tristate outputs of the final stage of the Result F I F O to drive the ISA-da ta lines. New response data from the train-bus is loaded on every tbEdge4 pulse into the first F I F O stage when the current command is a read. Current command means the last command that was sent out, i.e. the command sent out at the previous t b E d g e l pulse. The signals telling whether this was a read or a write are the "isread" and "iswrite" outputs from the special buffer that makes the last C F I F O stage. The control of the F I F O s to ensure the above described operation is presented in the following section. 5.1.2 The C o n t r o l L o g i c Cont ro l logic actually means everything that 's not a F I F O buffer. Address Decod ing The bus controller is IO-mapped. It needs to know when it is being accessed by the program running on the P C , which is being done by first decoding the address - the addrdec cell - and then looking whether it is a write to or a read from that address - the readwrite cell . The address decoder samples the ISA-address lines at the correct moment (defined by the state of the ISA lines A E N , B A L E ) and decodes it for Tra inDa ta , TrainAddress , T r a i n C o m m a n d or TrainStatus: « NOT aen AND ale » * ( « addrlsTD := BAToInt( addr ) = trainData » + « addrlsTA := BAToInt( addr ) = trainAddr » + « addrlsTC := BAToInt( addr ) = trainCmd » 44 + « addrlsTS := BAToInt( addr ) = trainStatus » ) B A T o I n t is an S T l ibrary function that takes an argument of type Boolean A r r a y and converts it into an integer. The read/wri te cell uses these signals and ISA-iow, ISA-ior to generate wr i t eCmd, wr i t eAddr , wr i teData , writeStatus, readData, and readStatus. O f the four registers that constitute the interface of the controller to the outside world, two may only be writ ten ( C m d and A d d r ) , two may be both wri t ten and read by the master (Data and Status). « writeAddr := addrlsTA AND (NOT iow) » + « writeData := addrlsTD AND (NOT iow) » + « writeCmd := addrlsTC AND (NOT iow) » + « writeSts := addrlsTS AND (NOT iow) » + « readData := addrlsTD AND (NOT ior) » + « readSts := addrlsTS AND (NOT ior) » The Counters or Clock Dividers Clock dividers are needed to generate the train-bus clocks from the ISA clock. Th i s is done by two S T counter cells, "count'21" and "count4" (see also section 4.2.3). Th is means the train-bus wi l l run 84 times slower than the ISA-bus . The counter modulo-4 is needed to generate 4 pulses, 21 ISA-clock cycles apart; it outputs these on lines t b E d g e l , tbEdge2, tbEdge3, tbEdge4. In other words, these wi l l be clock signals with a period equal to 84 ISA-clock cycles and wi th a pulse width of one ISA-clock cycle. The train-bus only needs the two differential clock signals t b c l k l , tbclk2 so that the slave devices can detect rising and falling edges on these lines. B u t the controller also needs to take actions on certain edges so we use the same cell to detect them. However, tbEdge2 is not used inside the controller since only the slave devices act on this edge (see figure 3.5, section 3.4.3). The Queue Controller The queue controller, or F I F O controller, generates the F I F O command signals and also status information signals. F I F O command signals are • shiftCf - shift C o m m a n d F I F O • shiftRf - shift Read F I F O • shift Wf - shift Wri te F I F O 45 STATIC qcontroller: QC0NTR0LLER= STATE (* C f l = Command FIFO stage l f u l l ; * RfO = Result-data FIFO stage 0 f u l l ; * Wf2 = Write-data FIFO stage 2 f u l l *) C f l , RfO, Wf2: BOOLEAN; Figure 5.5: The state variable declaration • forceldle - force an idle command out on the bus if no new command has been issued. This doesn't actually affect the F I F O advancing, but the output of the F I F O . The sh i f t -FIFO signals are generated based on space in the next F I F O stage; for this, we need to keep track of the status of the F I F O stages (empty/ful l ) . Some of these status variables are also necessary outside the queue controller cell, as actual status information about the bus controller; they must be available to the application sending the commands/reading the results, so that it knows when to send/retire a command. Ret i r ing a command means reading the result requested by the command; the point at which the result is available is several I S A clock cycles away, which means the status has to be checked to see if it arrived. The status variables that tell the application program when the bus controller can accept new commands or has new data available are: • CfO - C o m m a n d F I F O stage 0 is full; • Rfl - Response F I F O stage 1 is full . Since this cell is the most difficult to understand, I 'm going to list its defini-tion code here, even though it is a bit longer, so that the reader may recognize the above explanations in the code. The code is organized as follows: • State-variable declarations: state variables indicating the state of some of the F I F O s ; see figure 5.5 • function definitions (figure 5.6): I defined some functions just to make the cell body code easier to read. These functions are of type BoolFnO (Boolean Function) and their meaning is: — "issuecmd" (issue command): we may only issue a new command - i.e., enable the outputs of the buffers connected to the train-bus - if there is 46 STATIC (* some functions to make the main c e l l body easier to read:*) (* issue command: *) issuecmd: BoolFnO = BEGIN C f l AND (NOT RfO) END; (* advance Command-FIFO: *) advancefifoc: BoolFnO = BEGIN CfO AND (NOT Cfl) END; (* advance Result-FIFO ( i . e . data-read-FIFO): *) advancefifor: BoolFnO = BEGIN RfO AND (NOT Rfl) END; (* data available *) availdata: BoolFnO = BEGIN isread AND tbEdge4 END; Figure 5.6: Funct ion definitions for the qcontroller cell a new command si t t ing in the top C - F I F O stage and there is room in the bot tom R - F I F O stage to record the new result if necessary; - "advancefifoc" (advance C o m m a n d F I F O ) : if stage 0 is full and stage 1 is empty; - "advancefifor" (advance R e s u l t F I F O ) : if stage 0 is full and stage 1 is empty; - "availdata" (data available): response data from the slave device is loaded from the train-bus into the R - F I F O on tbEdge4 if the current command on the train-bus is a read-command, i.e., if a read-command was issued onto the train-bus on the last t b E d g e l • transitions for the C o m m a n d - F I F O control (figure 5.7): If the C - F I F O is ad-vancing and we are not wri t ing to i t , the bot tom stage (0) becomes empty (transition t l ) . It becomes full when there is a write to the C o m m a n d reg-ister (indicated by the "wri tecmd" signal) (t2). If stage 0 is full , stage 1 is empty ("advanceficoc"-function evaluates to true) and we are not wr i t ing to the C o m m a n d register, we can advance the F I F O (t4). F inal ly , if we issue the content of the top C - F I F O stage to the train-bus, and we are not currently advancing the F I F O , the top stage becomes empty (t5). (notations: CfO = C o m m a n d FIFO"stage 0, C f l = stage 1, shif tCf = "shift C o m m a n d F I F O " ) • transitions for the D a t a - W r i t e - F I F O control (figure 5.8): O n tbEdge3, write-da ta is let out to the train-bus, and since the W - F I F O (write da t a -F IFO) advances only on t b E d g e l , the top stage (2) of this F I F O becomes empty (transition t l ) . The following condition results from the fact that the W -F I F O advances stage 0 to 1 synchronously wi th the C - F I F O , but stage 1 to 47 BEGIN « reset OR ((NOT writeCmd) AND advancefifoc()) -> CfO := FALSE » (* t l *) + « (NOT reset) AND writeCmd -> CfO := TRUE » (* t2 *) + « shiftCf := CfO AND NOT C f l » (* advance the FIFO: *) + « NOT reset AND advancefifoc() AND (NOT writeCmd) -> C f l := CfO » (* t4 *) + « reset OR (NOT advancefifoc() AND issuecmdO AND tbEdgel) -> C f l := FALSE » (* t5 *) Figure 5.7: C o m m a n d F I F O control signals + « reset OR tbEdge3 -> Wf2 := FALSE » + « NOT reset AND shiftWf AND NOT shiftCf -> Wf2 := TRUE » + « shiftWf := C f l AND NOT Wf2 » Figure 5.8: Da ta -Wri te F I F O control signals 2 separately, depending on the state of W-stage 2; so the W - F I F O advances: stage 0 to 1 when shiftCf is true, stage 1 to 2 when shiftWf is true. It is okay to advance stage 1 to 2 if we are not currently wr i t ing to stage 1 (transition t2). For the shiftWf assignment, C f l indicates the same as a supposed variable W f l ; that is, the state of stage 1 of the C - F I F O is the same as the state of stage 1 of the W - F I F O since for stage 0 to 1 the W - F I F O is synchronous wi th the C - F I F O (transition t3). • transitions for the R e s u l t - F I F O control (figure 5.9): If the R - F I F O (result, or data-read F I F O ) advances and there is not new data to be loaded, stage 0 becomes empty (transition t l ) . It becomes full when new data is wri t ten to the bot tom stage (0), on tbEdge4 if the current command, i.e., the one that was issued to the train-bus on the previous t b E d g e l , is a read (t2). If the current ISA-IO-read cycle is one from the controller D A T A register, and the R - F I F O is not currently advancing, the top stage, 1, becomes empty (t4). If stage 0 is full , stage 1 is empty, and we are not wr i t ing to stage 0, it is okay to advance the F I F O (t5). • transitions for forcing an idle train-bus cycle (figure 5.10): If the conditions for (* t l *) (* t2 *) (* t3 *) 48 + « reset OR (NOT (tbEdge4 AND isread) AND advancefifor()) -> RfO := FALSE » (* t l *) + « NOT reset AND isread AND tbEdge4 -> RfO := TRUE » (* t2 *) + « shiftRf := RfO AND NOT R f l » + « reset OR (readData AND NOT advancefifor()) -> R f l := FALSE » (* t4 *) + « NOT reset AND advancefifor() AND N0T(tbEdge4 AND isread) -> Rfl := RfO » (* t5 *) Figure 5.9: Result F I F O control signals + « reset OR (NOT issuecmdO ) -> forcel d l e := TRUE » + « (NOT reset) AND issuecmdO -> forcel d l e := FALSE » Figure 5.10: Qcontroller module: forcing an idle train-bus cycle issuing a new command are not met (see "issuecmd"-function), the controller issues an idle command out on the train-bus. Forcing an idle command on the train-bus is achieved by controlling the special buffer that makes the last C - F I F O stage, wi th this "forceldle" signal from the queue controller - figure 5.11 presents the ST-code for the buffer. Th is buffer is also the one that generates the isread and iswrite signals used as inputs in the qcontroller cell . It generates these signals by just looking at (a) the least significant bit of the command code it contains, which indicates a read or a write, (b) whether it had to force an idle or not, in which case none of the signals is true. " I n t T o B A ( ) " is a function that takes an Integer and translates it into a Boolean A r r a y with a specified number of bits (in our case 4, the bi t -width of the t rain-command lines) T h e contrlogic cell This is not the most proper name for this cell, since it is not the only control logic component, but it is not specialized on certain things either like the others. It is just combinational logic generating the reset signal and output enable signals. The output enable signals are for the buffers wi th outputs connected to the ISA-da ta lines. When the board is not addressed by the ISA bus, it should not be dr iv ing the ISA data lines at a l l . The two buffers wi th outputs connected to the ISA data-bus 49 buf2c: Buffer4spec = STATE cmdldle: INTEGER = 3; STATIC (* the least s i g n i f i c a n t b i t of the command, in(0), * indicates a read or a write command *) iswritefn: BoolFnO = BEGIN NOT force AND NOT in(0) ) = cmdWrite) END; isreadfn: BoolFnO = BEGIN NOT force AND in(0) ) = cmdRead) END; BEGIN (* forces i d l e when force i s TRUE *) « cs » * ( « NOT force -> out := i n » + « force -> out := IntToBA( cmdldle, 4) » + « iswrite := iswritefnQ » + « isread := isreadfnQ » ) END; Figure 5.11: The special buffer for Command-FIFO stage 2 50 are the second (or final) stages of the Status and the Rep ly -Da ta F I F O s . 5.1.3 S T simulations In order to test the S T program, a driver module was necessary to simulate the master application; that is, to send commands to devices and retire them (read response data if any). Th is module was built according to the state diagram from figure 5.4. We also needed an ISA-bus simulator (modules isa and 10, the latter containing the inByte and outByte cells that model the communicat ion between the application and the ISA-bus) . Another necessary component was a module simulat ing a slave device con-nected to the train-bus. Th is is the device module; all it needs to do is detect whether it is being addressed (by comparing the information on the train-address lines to its own identification information) and respond to the different commands (provide a response in case it was a read). 5.2 Implementation Decisions A s justified in chapter 3, we are using a P C as the host computer; the bus controller is implemented as an ISA-board . The general idea was to use programmable logic on such a board. This implied translat ing the ST-code into V H D L - c o d e that could automatical ly be synthesized by available C A D tools. For previous versions of the bus controller, Progammable A r r a y Logic ( P A L ) integrated circuits were used ( A M D P A L 2 2 V 1 0 - see databook [1]). For a more ele-gant design we ini t ial ly decided to use the M A C H - 4 family Complex Progammable Logic Devices ( C P L D s ) , M A C H 4 4 5 [2]. Tha t is, we wanted to use more powerful chips and the choice was for the mentioned ones because at that point the depart-ment already had licenses for the necessary C A D tools to program those. Since the download program was using around 80% of one device's resources, we decided to use two and forced the CAD-sof tware to part i t ion the design onto 2 chips. We took this decision in order to leave room for further changes in the design; since the controller is a hardware piece for an experimentation project, it wi l l almost certainly be further modified in the future. Debugging also needs to be kept in mind. However, the M A C H - 4 family has a reputation for being hard to reprogram with the same pinout. Al though I tried out the procedure succesfully wi th a minor change, reprogramming it later wi th a much different code did not succeed. Also , in the meantime part i t ioning is not supported anymore, so every t ime we would need to re-program the chip, we would have to do manual part i t ioning. This is why recently 51 we decided to change the implementation from using the M A C H 4 4 5 ' s to using only one X i l i n x Spartan chip [22]. 5.3 From ST to V H D L After successfully simulating the S T program, the next step is to translate the S T code into V H D L . Several things have to be taken into consideration here: 5.3.1 Clock signal Fi r s t of al l , for a program, the clock is implici t : it is the rate at which instructions are executed. In S T , at every execution step, one or more transitions are picked for execution. When going from S T to V H D L , the clock has to be explici t ly specified as a signal connecting all components (the equivalent of the cells in S T ) . 5.3.2 Sensitivity lists Another problem is raised by the sensitivity lists of V H D L processes. Sensitivity list means a list of signals to which a process is sensitive ( [3]). W h e n any of these signals change value, the process resumes execution of the sequential statements; after executing the last statement, the process suspends again unti l a new change occurs on one of the sensitivity list signals. Now when going from S T to V H D L , one would be tempted to include all formal parameters of a cell into the sensitivity list for the V H D L component rep-resenting that cell. B u t this is not how the S T program executes: in S T , at every timestep, one or more transitions have their guards evaluated and are executed. This rather corresponds to having only the global clock signal on the sensitivity list of any V H D L process. The decision about what should be included on the sensi-t iv i ty list depends on how cells are executed in S T ; this issue is addressed in the following section. 5.3.3 O n mixing S T combinators In all previous work where S T has been used, mixing synchronous and asynchronous combinators has been considered illegal by the compiler ( [18]). The S T version used in this thesis allows mixing synchronous and asynchronous combinators. The need and advantages of mixing the synchronous and asynchronous com-binators has been shown in chapter 4. Suppose we have an S T program where we model subcircuits working at the same clock rate; in this case, we use the syn-chronous combinator +. W i t h i n each cell however we may be using the asynchronous 52 "bar" combinator, ||. F rom the definition of the + combinator, it results that at every time step, all transitions combined with + whose guards are enabled, wi l l be executed in one atomic operation. The question arises here whether to regard the cell as a transparent hull for the transitions it groups together, or as an indivisible body of transitions. In the former case, it can be represented as ( < C action 3 > || < C action ^>) + ( < C action ^> || < C action ~^>) and the way to interpret it is to non-deterministically pick one transit ion from every cell and execute all of them that have their guards satisfied, in one atomic step. In the latter case, if we view the cells as indivisible action bodies, then once a cell is "fired", it is like a spawned process, meaning its enabled transitions - the ones combined with || - execute repeatedly until no more are enabled; we could say we let the whole cell "settle down", before we fire it again, (this is from a discussion with Joergen Staunstrup, the author of [18], this last summer (1998) at the Danish Technical Universi ty in Lyngby, Denmark) . The convention used in the U B C S T compiler is to view cells like transparent hulls of the transitions grouped in its body. In other words, we do not let the cells "settle down", but, if there are transitions combined with ||, we pick some transit ion each time the subcell is "called" in the top cell. Th is convention is the reason why, when I went from S T to V H D L , I only included the clock signal on the sensitivity lists of most of the processes (except combinatorial logic and some components that use other signals for latching values). Th i s is because in our version of S T , we do not spend more than one clock cycle in a cell at a t ime, so the next time we pick a transit ion of that cell, we wil l have all the updated information about all the other signals that are input parameters to the cell. 5 . 4 Summary I described the process of refining the high-level specification of the controller, some issues I encountered and how solving them affected decisions about implementation details - e.g. F I F O depths. I further described the process of translat ing the simu-lated S T version to V H D L ; the decisions I took, based on the conventions we made in order to be able to apply the mixing of S T combinators. 53 C h a p t e r 6 Evaluations and future work This project had two main purposes, as presented in the introduction: to produce a hardware piece necessary for further development of a model train set for real-time experiments, and to experiment with a new hardware-software codesign methodol-ogy. 6.1 Testing the train controller board The P C - b o a r d , as tested so far, now corresponds to the requirements. Al though it was not possible yet to test it wi th the train-bus connected to the board and devices connected to the train-bus, I ran a few tests by sending write and read commands and looking at the train-bus outputs wi th an oscilloscope. The testing applications were writ ten in D J G P P , a version of the U n i x C + + compiler for the P C . One of the test programs is presented in figures 6.1 and 6.2 These tests included: • Doing sequences of writes to the train-bus, alternating the values for address and data (I used values 0x00 and Oxff). Th is works correctly; I checked by using the oscilloscope to see the transitions on the train-bus lines. • Do ing long sequences of write commands works without idle train-bus cycles inserted by the controller; this shows that the F I F O depth was chosen big enough (see section 5.1.1). • Inserting (forcing) an idle command in a sequence of useful read/wri te was checked by looking at how the train-command lines change • Execut ing a program that takes the following actions: 54 tinclude <stdio.h> #include <pc.h> ttdefine TDATA 0x0300 #define TADDR 0x0304 #define TCMD 0x0308 #define TSTATUS 0x030C ttdefine DATAO 0x00 #define DATA1 OxFF ttdefine ADDRO 0x00 ttdefine ADDR1 OxFF void reset_controller( void ) i outportb( TSTATUS, 0 ); /* doesn't matter what we write, just a write to the Status Register resets the controller */ > void getstatus( unsigned char * c f _ f u l l , unsigned char *rf_empty) •c unsigned char status; status = inportb(TSTATUS); * c f _ f u l l = (unsigned char)(status && 0x01); *rf_empty = (unsigned char)(!(status && 0x02)); } void issuecmd( unsigned char addr, unsigned char cmd, unsigned char data ) /* addr, data are optional here */ •c outportb( TADDR, addr ); outportb( TDATA, data ); outportb( TCMD," cmd ); } Figure 6.1: Sample test application (in C + + ) for the bus controller: constant and function definitions 55 void main(){ unsigned char data; unsigned char cf_full=0, rf_empty=l; int i ; rese t _ c o n t r o l l e r ( ) ; p r i n t f ( " \ n controller reset"); for (i=0; i<20; i++) { do { getstatus(&cf_full, &rf_empty); } while ( c f . f u l l ) ; issuecmd( ADDR1, 0x04, DATA1 ); do { getstatus(&cf_full, &rf_empty); > while ( c f . f u l l ) ; issuecmd( ADDRO, 0x04, DATAO ); } } Figure 6.2: Sample test application (in C++) for the bus controller: main function body - write Oxff; - read data; - write 0x00; - read data; also works, where "data" always returns the previously written value, which is because the controller sees the train-bus as a big capacitor. This feature was seen in the following experiments: • when writing Oxff and no action afterwards, the train-data lines go to logic " 1 " for a short pulse then gradually fall towards "0". • also for the read-after-write experiment, if I had the probe on train-data line 0, I read Oxfe instead of Oxff, because the data-write buffer connected to it was tristated and touching the line with the probe discharged it. I have tried several different sequences of alternating read and write commands and I believe the controller works according to the specification; however, testing read 56 commands really requires a device providing responses from the other end of the train-bus. Th i s is addressed in section 6.4. For testing the correct generation of the train-bus clock signal I did not need any application program; just inserting the controller card into the ISA connector and programming the F P G A is what it takes to get the clock signals at the t rain-bus connector pins. A l l lines t b c l k i , tbclk2, plus the signals that are internal to the controller but essential to the correct functioning, evl, ev3, and ev4, look correct. I made a header (2x15 pins) geometry that I used to connect all the unused pins of the F P G A , so that if I needed to test or debug the board I could add internal signals to the outputs of the F P G A and thus observe their behaviour on the oscilloscope. (Because of the very small dimensions of the F P G A package, it is extremely difficult and probably not very reliable to attach an oscilloscope probe to its pins.) To test evl, ev3, ev4 I connected these to some of the 2xl5-header pins. These test pins were very helpful for some of the problems I encountered: • I first programmed the device only with the code for generating the clock signals for the train-bus and the event detection of the 4 edges of those two clocks. The two clock lines did not look correct at al l , and from the oscilloscope display I saw it was because of erroneous pulses that were about one ISA-clock cycle long. Th i s made me follow the advice of a colleague and use the V H D L condition "clk'event"; even though I thought it was redundant if elk was included on the sensitivity list of the process. It was the only thing I could think of t ry ing because this part of the code had looked perfectly correct when I simulated i t . It works correctly now, wi th "clk'event". • The P C ceased to accept keyboard input when the F P G A on my board was fully programmed. The only way for my board to interfere with the P C was by dr iv ing the ISA-da ta lines, so I connected this observation wi th the fact that the synthesizing C A D - t o o l s gave a warning: "Unknown port type for isadata", although I used the correct syntax. I also remembered that when I previously used a Synopsys product for compil ing V H D L code (when t ry ing to program the M A C H 4 4 5 s ) , I was not able to use two different tristate buffers to alternatively drive the same line; at that t ime I had to rewrite the code so that in one of my components I was mult iplexing the two internal buses. So now I did the same: I inserted a multiplexer so that only one tristate buffer was connected to each output ISA-da ta port . Th i s worked correctly. • W h e n t ry ing to issue write commands, I d id not see the correct behaviour on the train-bus lines at first. Then I added all necessary debugging information - signals indicat ing the states of the C o m m a n d F I F O , etc - as output port 57 connections so that I could see how their values changed. This is how I realized that in the translation from S T to V H D L , at some point I had omitted a " N O T " in the code for the queue controller. Once I corrected that too, all the tests I did (as mentioned above) were satisfactory. 6.1.1 P r o b l e m s I e n c o u n t e r e d w h i l e g o i n g t h r o u g h the w h o l e de s ign process One conclusion from my experience is that the time it took me to write and debug the S T code for the controller, or the V H D L code, was noticeably smaller in comparison to the time it took me to design a PC-boa rd and successfully program the device on the board. This is part ly because it was the first time I ever undertook such a project. After deciding to change the board, in other words when I was forced to go through the same process once again, it went much faster. I was then stuck wi th a X i l i n x download cable/software bug (Xi l inx web solution record #3701) which took me one week to find and solve (with technical support help). I found the reason for this experience (similar to the one programming the M A C H s ) to be the fact that C A D - t o o l s have to be marketed very fast because of the fierce competi t ion, and thus bugs are detected and fixed after the software is already in use. The solution to the X i l i n x downloading tools bug - the software patch in-dicated on the web did not solve the problem - was to disconnect the P R O G wire of the download cable from the board; and to solder a pull-up resistor (2.2 K O h m is what I used) for that p in . I also needed a pull-up resistor for the D O N E pin; in the current state, I just soldered a wire to the pull-up I had for the "response" line of the train-bus, because we are not currently using it anyway. This needs to be changed if we wi l l actually connect the train-bus. 6.2 ST for co-design I started work on this design vir tual ly without any previous experience either in S T or in V H D L . T h a t is, I had learned about hardware description languages (including V H D L ) during my undergrad courses and I had used Veri log in a course project, but I never actually went all the way to implement a design in any H D L . A t least I had had some exposure to V H D L , while S T was a total ly new programming environment. However I did not find it difficult to adjust to i t . A few simple homework exercises I did in the Formal Verification course where I learned about S T were enough to help me understand this new notion of non-determinism in a program. Once I grasped the concept, I came to think it is essential in correctly modeling real-time applications. 58 Since S T is not supported by any automated synthesis tool , I had to model my design in S T , simulate it and debug it; after I was happy with the behaviour of the model, I had to translate this into V H D L . This means the final version was totally deterministic. B u t the modules I used to simulate the controller (the ISA-bus model, application program model, train-bus device model) did make use of the possibility to model non-determinism in S T . This I believe to be a strong argument to use S T for co-design: the abil i ty to make good and reliable simulations by correctly modeling the real-time environment that the design has to interact wi th . I firmly sustain this viewpoint since I also had to simulate and debug the V H D L version of my design (since the translation is not done automatically, this process is prone to errors). The worst problem I had with V H D L was the way in which different ways of describing things that should essentially synthesize to the same hardware, resulted in such different behaviours after synthesizing (see also the problems I had to correct, section 6.1). 6.3 Conclusions I used Synchronized Transitions to design a bus controller - a P C - I S A board wi th a X I L I N X Spartan F P G A - without having had any previous hardware experience (although several course projects in the past included designing some piece of hard-ware, I have never actually implemented and tested anything). I found S T very helpful in this process and I was finally able to see that the implemented design, the actual hardware, works correctly. I think S T is a good choice for a co-design specification language since the specification that one can simulate does not depend on whether the model wi l l be implemented in hardware or in software. It can therefore also provide a means of communication between hardware and software teams that would work on the same project. For my particular design case, I found it very helpful in dealing wi th interfacing between two components running at different speeds, which I believe is due to the possibility of expressing non-determinism in S T . 6.4 Future work 6.4.1 Completing the train-bus design A s mentioned in section 6.1, a complete test of the device requires another device to be present at the other end of the train-bus, to respond to commands sent by the application on the host P C . A first step would be to program a few simple Programmable A r r a y Logic devices (like the 22V10 [1]) and connect them to the 59 train-bus connector on the controller board. Th is way it would be possible to test the R e s u l t - F I F O . The next step, after making sure the controller works correctly, would be to actually connect the train-bus itself (several meters of ribbon cable). Th is is in order to test if the 4-phase protocol we proposed is a reliable communicat ion protocol. We further need to design the devices that wi l l be connected to the train-bus - speed controller, position controller, track switch controller - in the same modular manner and responding to the new protocol . The final task wi l l be to write the software for controll ing the trains. Here S T would be a way to model the application before implementing i t . 6.4.2 Better C A D support for S T based design From my current experience, I believe that from the information contained in the S T model of the design, much of the final design can be generated automatically. M o r e precisely, after deciding how to implement the design (i.e. part i t ioning decisions), most of the schematic could be generated automatically - in our case, the connec-tions between the F P G A and the ISA-bus on one side, the F P G A and the train-bus on the other side, are all described in the S T code. (Of course the analog parts are not included there - like amplifiers or current limiters for some of the train-bus lines, or decoupling capacitors for the F P G A . ) Also , all the information for generating the download file for the programmable device (the F P G A ) is included in the S T . The most useful tool would therefore be an automatic S T - t o - V H D L transla-tor, or better yet, S T - t o - E D I F . Th i s may constitute a future research objective. Another very useful feature would be to be able to see simulation results of hardware modeled in S T , as waveforms. Currently, the way to simulate S T code is by inserting "Wri teStr ing" (a function that writes a string to the standard output) in places of interest in the code, which seems rather awkward. For instance, if I wanted to see how a certain digi tal signal behaved, I had to make the program write out the value of the signal every t ime it changed. I think that the availability of such support tools would make S T a very convenient co-design tool that would offer a reliable specification language, easy to learn and use, wi th high modeling power for real-time applications; and the possibility of going through a safer stepwise refinement process from specification to implementation. 60 Bibl iography Advanced M i c r o Devices, Inc. PAL Device Data Book, 1992. Advanced M i c r o Devices, Inc. Mach 3 and 4 Family Data Book, 1994. Peter J . Ashenden. The Designer's Guide to VHDL. Morgan Kaufmann Pub-lishers, San Francisco, 1992. R . Camposano, D . K n a p p , and D . M a c M i l l a n . Hardware/Software Co-Design. Kluwer Academic Publishers - N A T O A S I , 1997. Daniel D . Ga j sk i , J ian wen Zhu, and Rainer Doemer. Hardware/Software Co-Design: Principles and Practice, chapter Essential Issues in Co-Design. Kluwer Academic Publishers, 1997. R . Gerber, W . Pugh , and M . Saksena. Parametr ic dispatching of hard real-time tasks. IEEE Transactions on Computers, 44(3), 1995. R . G u p t a and G . DeMiche l i . Hardware-software co-synthesis for digi tal systems. IEEE Design & Test, 10, September 1993. Asawaree Kalavade and Edward A . Lee. A hardware-software codesign method-ology for D S P applications. IEEE Design & Test, 10, September 1993. E d Lansinger. Developing an engine control system. Circuit Cellar INK, September 1995. Trevor W . S. Lee, M a r k Greenstreet, and Car l - Johan Seger. Au tomat i c verifi-cation of asynchronous circuits. IEEE Design & Test, 12, Spring 1995. J . Madsen, J . Grode, P . V . Knudsen, M . E . Petersen, and A . Haxthausen. Lycos: the lyngby co-synthesis system. Design Automation for Embedded Systems, 2(2), 1997. 61 [12] A c h i m Oesterling, Thomas Benner, Ro l f Erns t , D i r k Hermann, Thomas Scholz, and Wei Ye . Hardware/Software Co-Design: Principles and Practice, chapter The C o s y m a System. Kluwer Academic Publishers, 1997. [13] Tarik Ono-Tesfaye, Chr is toph K e r n , and M a r k R . Greenstreet. Verifying a self-timed divider. In Proc. International Symposium on Advanced Research in Asynchronous Circuits and Systems. I E E E Computer Society Press, A p r i l 1998. [14] Anders P . Ravn and J0rgen Staunstrup. Synchronized Transitions. Techni-cal Report D A I M I P M - 2 1 9 , Computer Science Department , Arhus University, Arhus, Denmark, January 1987. [15] K . Rompaey, D . Verkest, I. Bolsens, and H . D . M a n . Coware - a design en-vironment for heterogenous hardware/software systems. In Proceedings of the European Design Automation Conference, Geneve, September 1996. [16] D & T Roundtable . Hardware-software codesign. IEEE Design & Test of Com-puters, january-march 1997. [17] Edward Solari . ISA & EISA - Theory and Operation. Annabooks , 1992. [18] Joergen STaunstrup. A formal approach to hardware design. Kluwer Academic Publishers, Boston, 1994. [19] Joergen Staunstrup. Hardware/Software Co-Design: Principles and Practice, chapter Design Specification and Verification. Kluwer Academic Publishers, 1997. [20] Wayne Wolf. Lessons from the design of a pc-based private branch exchange. Design Automation for Embedded Systems, 1, 1996. [21] Wayne Wolf. Hardware/Software Co-Design: Principles and Practice, chap-ter Hardware/Software Cosynthesis Algor i thms . Kluwer Academic Publishers, 1997. [22] X i l i n x , Inc. Spartan and SpartanXL Families Field Programmable Gate Arrays, 1998. 62 A p p e n d i x A ST code for the controller The S T code presented is a refined specification version. Its refinement degree corresponds to the point where this project took over a class project started by another student. Changes were made to adapt the design to a more reliable protocol as described in section 3.5. (* * the d e f i n i t i o n module for the counter modulo-21 * *) DEFINITION MODULE counter2i; FROM useful IMPORT BoolArray; EXPORT counter21; TYPE C0UNTER21 = CELL( reset: BOOLEAN; q: BoolArray; countmax: BOOLEAN ); STATIC counter21: C0UNTER21; END. 63 64 a OJ H 10 Dl 0) W 4-1 u ta i O ol X) -TJ Q> <0 C U CL. U te i aj g O J U n 4J TJ e a rd -• O 41 l l ' q 3 ro TJ Q 1 U OlTJ i : > w ro c CJ — U a> o i i ai BL, I U OS H O Cl- O C l-l C 3 *—i I '—' Z 0 JJ O UJ 3 O O O X) JJ C ro JJ i c bu 1 JJ C C 0 >"* (U -H o - TJ ra TJ o j io u cu ca > 01 3 JJ 3 - S m o CJ > t ro Tj Q — OJ aj i a m (DO E 3 u 2 aj n — -a nj w C > Q HI C CJ Q IH U UJ ro QJ ~ - — O X! ~ J « OJ U J U > HI O J [J C Cnuj •i D ai TJ ra H J n- JJ c JJ UJ u H C ro w ai 6 5 A 0 o fJU U (- Cl) IH JJ O l i O Z J 1 Xi" < CJ — 6u QJ OJ Qu ll u a 3 c a> ro -! Z W 3 Dl> 2 UJ t0 TJ C OJ 01 -H rj 01 ro C E ti ro o 4.) > u TJ CU 0> (0 X) JJ — O O tu 0 M JJ M U. u. q ro -H o u r u -O QJ UJ <-t 0) o 01 - H QJ •rl u cn 3 ro •d [L. a I H o 0) [l. JJ r J J TJ A JJ I QJ ro c x: u QJ -H U t" ID 3 ro O J lu QJ u • • C i a cj TJ AJ .c 0) u QJ u I TJ MJ 01 «4 C -n O O UJ ) -H j ; tt o FH Bl QJ / o DI ai / 1 2 rO ro Ol l> Q 10 01 U U. j OJ O UJ f ro > 3 O X OJ HiTJ XI G Ol C o' j .. ns o i i oi o ) >iO tJ S U £ t, J JJ JJ C ai ai III v : E c ) 0) w E- JJ JJ O f O JJ • £ r l I Q> JJ QI • 0> II TJ / : a x i 233 J Q oi x cu UJ B 2, QJ JJ Xj CJ : Q as i JJ JJ ; O T J 2 < HI d K J J h « -i c < > O fjt Q TJ "5^ ro CJ JJ rO 01 0) C TJ £, JZ t. u u QJ a I C 0) Q> O QJ U-J JJ d M-Q, ' O P E ' U U QI 65 66 U) TJ r ai ai u ca — U TJ OiTJ > JJ -OV <D 01 01 tn Ui ui ni D tt) TJ -C U ai JJ u v •H O M IJ H O C < a. oi B: ZOO .c 3 3 c • H UH HH o M (U 0) U to 3 3 E-i E E E O O O O P. cd CC CC E ll, Cu k. H j O to ) D 3 3 -a v j TJ u. -> ca m u u ti i n ci ai : c c c J O O 4J 1 -i m c o E-> OJ < cj f- u ~ T J • - -w ro u < X J 2 ui H H C X C TJ TJ 3 ro <u TJ TJ o E ro ro ic r— m u o < ro OJ ty u 1-1 $ ro j? •a ro H Ed QJ cu •H O 1 II TJ C ro B J 3 U -r TJ XJ • • c r-t x> ra 1 S S 4-J m E : Q Q 3 — u TJ • j ^ w U H c E «i JfDQJiJ H (J J-> u ro TJ oi C 3 Ul Oi C O H - r i O V-'—i w -H jn — <D u I I . CJ TJ 10 -H C O SSI S3 -H o to p 3 CJ ro TJ Xi J-> — vi ai ui u 3 QJ x ^ T J U I £ ) T J i • U U -TJ TJ -J CO CO TJ TJ TJ TJ " £ u u • < < • c I 0) -HUT! - - JJ J W O T J U H ro C cC in < u u Q J 3 0) u Oi0) J . 1J U W TJ tl HO CO -H -H Cd -H : u 4J u £ J 3 in u 3 ai u cj OJ u LI mai u oi U-i xu XJ U u-i TJ -H -H LO "H -H Ld J : . C J J U n U IJ Ul U>TJTJTJTJTJ'tJ'tJ C « CJ •-* JQ TJ . — OJ 4J ddr, • * IcH O . a> uj ui [SAa « HTj< * 0 L0 • M W H PQ - C « O - TJ * U - Ui « - ra i ! c * 3 M | * Jj o< * £ CO . 1) SH * £ - — ISAsc I  * Li * MM * O0) -TJ >! u C 3 H O * OJ a) <u V • <-H CJ PiTJ SI < L0 TJ * TJ U U O * Q U * £ 0 OJ <L> o o -CQ QJ C D J= tl 14 QJ O id OJ .C W Ui •DSHil a Ul QJ o -H M x: Ul 0) QJ H T) J J x; 0) C (J EH O TJ XI CC - C TJ O 3 (0 ui a. m • J E B"rf -OH E P CJ TJ UJ U S Z J) Jj U O f M 3 E-M a u u -OJ DS < < Q) TJ O *-H #—• *—I u o o ni OJ u o o EH — TJ < CQ U EH EH X3 . 5 3 L0 Cd H Z W CJ •—l TJ EH TJ OJ TJ c u u c -TJ ro p c O" o TJ U <D O P CJ r-H TJ M U O EH «-l CJ TJ CJ DS EH 3 jq ro EH EH O <X. n n; oi EH CL, O L O E H O O C C E A - E H Z) O E E 0- H O a CL, M M E u a. O E H m u E OJUiOJQJUinHH HT33LILI1JUQ) EiUDCCCum E H T J O J O O U O P g i u n u u c T u j j E E E E E E E E u o o o o o o o JcCKCtlCCCdPio: o o o, E- CL, O. E CC E E M E E E E o o o o tc CC CC CC UJ UJ I", [Li 67 6 8 Appendix B ST cell instantiation diagrams 71 •o — « TIT -7fT iV -a \ S U •a < i/i a , T J n M Figure B . l : The "ou t -F IFOs" : C m d , A d d r and Data -Wri te 72 T 3 rt ( j a IF tU rt 3 rt 7rT p t/3 3 -4—* o c 8 u oi E a o 5 o IT1 o tu 00 rt cn c/3 3 •a rt <D u-1i bO rt rt • rt -O _>> a, p rt [\ xi tu rt rt -a a, tu rt C . " O r t - ^ r t Figure B .2 : The " i n - F I F O s " : Status and Data-Read 73 Figure B . 3 : The Cont ro l Logic Cells 74 Appendix C V H D L code . . . i O O O O t-t O >HH X. M X. M U a U U W TS O T> TJ tH w 2 u u ta oi S ui w H • [/] . . to to to >,[U >W fj : u u H > — u J w c ! dl II O II : ii c i 1 V 3 \ ) o I CT U t 11) O U tJ 3 M O TJ TJ Tj U >, >, W [il W ^ i—I r-u mi 1 nl TJ TJ : c c 1 u (0 ro aj C r-\ O) x J£ ^  OJ <a OJ G 4J c u - H It-•ri En C O Ov-76 - c O dl II 4J o d C 0) 0) -C 01 > u o — U Ol ^ £ O ""l u > .-J TJ TJ UI C 5 ^ o i ! TJ o C UJ ro U TJ U iJ - TJ II C M rO - o ^ r-i O UJ -O TJ TJ - I  I  E I  C M V V U V TO TJ Ol JJ u C 0) Oi u c JJ 01 -UJ 01 U O -H 01 o u ui UI — 0) OJ C UI O DI-H OJ V-i 0> ax> o TJ c O TJ C O U u-t O -H a TJ C uj 0) H d OJ TJ "5 c II - U TJ O UJ ro U I  (fl JJ TJ o M d C UJ ro C -H OJ -x: I TJ c V UJ U V UJ U TJ 0) UI > 0) 3 O C TJ C U uj s TJ "H c x: OJ in TJ a (0 o QJ U u I  O JJ O «n - O TJ JJ C UJ JJ ii d d o u o •-t ro d TJ d I  TJ 1  O U o SJ •!-* VJ C • (0 -II n • - T 3 •- o v - JJ - d O UJ rjj O rfl U4 U QJ ll J£ U) U --IV -HO) TJ TJ U U tl -IJ \J V TJ Vj Ij — 01 TJ ui TJ d UJ ,-t d OJ -H 0) 0) J u H O 3 TJ u o i o TJ o • - u u a> •rt > Ol I o u U I Ol •HTJ O O UI I 1—I TJ I C JJ TJ -"-I ul W ,-< 3 d C O w TJ' H •• - UI W JJ fNJUO i J WW UJ .—I d 3 M - 3 U -H O •-W X) CN >i W — UJ U W >, JJ 3 10 h-t U U XI Vj 'H O xi OJ JJ a TJ 'H Ul d c »—I 3 QJ 0) - d II -J. U ^ — U TJ -d a m d C II QJ O > -QJ -H d Vj 0? to XJ 0) c CJ -H UJ O Oi-rt VJ 0) axi j<: v ui j^ .-aj u ui UJ u JJ -H o — 3 VJ -O T3 UJ C JJ 0) TJ t-t 77 78 79 4J -H O — JJ TJ I U T J O g Hi 3 M £ U JZ ro W O — - H m m u .-> JJ a - r o n WW Ul E u r o a - r a QlEVirrj H C M rOOJJJl E O W I - H a T j u au-ira Q, ra o. ro JJ TJ a«-» TJ G Q I T J a E u ID-H u . 'o ni H <-• ll A O C N A JJ -rt » III io U > M M UJ U) H JJ id rO rO 1 O U V 4 ro U ra T J ra ra U V- ra 3 U O U rOUta 6 A rO JJ rO - TJ U Q > A II "-J U II H U - QJTJ JJ l-l -H Q) — - JJ U 3 D U 1 E O J T J S U 01 E D E 01 TJ E U H E U 0) JJ OJ £ 0J TJ A I I J J T J M u 3 ra ro a 01 TJ H U 3 O 3 u J J ^ X l O O J3 U a o G V J J J J J O ) J J I O U-IJJ - JJ u r a UJ JJ W U U - " J J N 3 u n <aE o r o o a i T J E «*-< ^ a tu u ui JJ c a m e m u-i-H o ro c JJ " • H M JJ -H C U - H C J J - H O I U ^ C J J - H C O ro C J J - H W U V H T J U a T j - H J J T j V l A U T j l - i A A U - U) O -H E u ftU-H t j l j - H V* , C - I V J > - H H l-l -H U J Z U SZ -H U > - H H lu-H o 111 Tl H H H u -H m aj II a> ro JJ II II JJ u ui 01 a A O J O I A A U> A o 3 O U) O Q ) o 3 O UI O U I OJ O 3 a>-i TJUMQI aiojinvjaj *—i JJOJUJ. u-i - H J J U A H U O H A LI A II OJ A II a A a A a A a A a A U A QI A a A ra ro Ul Ul JJ Ul -H 3 U .-I -H -H U -M o tN -H Cn Ul TJ ll rO TJ 11 U U O A II A l l A H A II A II A l l A li O A II A II U -H O > li H ^ U I U J : C O • H 111 ^->TJ O U 1 0 O I I U 1 T J I I T j l l T j l l TJl l TJII TJ N TJ II TJl l QI U M I U 3 - r t l l l U 3 l 0 H l U i ! U) Ul C O CO U) U O 1J W U) JJ Ul Ul U l - H U l " ) Ul .-I Ul U l ^ H Ul TJ 3 JJ luOJ^ O U - H H * i C C D 3 0 J C a W T J C C O T J G C O T J C r o T J C r j 3 T J C O 3 T J C C O T J C ^ T J C 8 0 Appendix D Board Schematics 82 ACCESSC0:22XO>-X O > T B C L K 1 » T B C M O ( 0 : 3 > T B I R Q » I S A I R O S <4 W R I T E D A T A « — URITEADDR « — r WRITECMD<< R E A D D A T A << R E A D S T S << C C L K < 0 > _ | _ D C 1 I d c a p J_DC2 JJJC3 J d c a p D C 1 •i.luF leap Figure D . l : Board schematic sheet 1 83 A C C E S S ( Q : 2 2 X O > U R I T E D A T A » -U R I T E A D O R » -W R I T E C M D » -R E A D D A T A » -R E A D S T S » -N i l HI HEADERI5x2 2 1 3 1 5 6 7 o 9 13 11 12 13 H 15 18 17 18 19 20 21 22 23 21 25 26 27 28 29 30 3 I 0IN<O>-C C L K <o: I N I T - « ^ > — L DONE < e > > ui ISxIOho les U5 SPROM DATA SER_EN* CLK CEO-RESET.OE CE" I Figure D.2: Board schematic sheet 2 84 T B C L K 2 » 2 N 2 9 0 5 A - N D 04 T B C L K 1 » -hexfet, 0 ohn - A A A — R6 I R L Z 2 4 - N D Q2 T B C M D ( 0 : 3 ) » -T B A D D R ( 0 : 7 ) » -T B D A T A ( Q : 7 X O > -v c c 5< A / R2 RP1 resnet ^ ^ ^ ^ 1 4 12_ hexfet, B P 3 5. 0 9 DATAO TBIRQ « -S 2 N 2 9 Q 5 A - N D Q3 I R L Z 2 4 - N D 01 3SL 22 23 _21 • 5 m 39 14 12 0 13 13 31 12 1? 13 11 11 32 o IQ m 14 9 9 33 is: 34 16, 3sr D837R Figure D.3: Board schematic sheet 3 85 Appendix E Board Design Details A view of the board with the component geometries is shown in figure E . l . The list of the components, as generated by the P C - b o a r d layout tools (Men-tor Graphics) , is given in figure E .2 . The train-bus wil l have 8 wires for ground, and 7 spare wires for future expansions and/or experiments. These include probably 1 wire for response (the one labelled D A T A D in the schematics, figure D . l ) , to allow bus-repeaters to be used in large designs; and probably one wire for interrupt requests (one of the trainbus lines is connected to the F P G A on the board because I also planned a connection from the F P G A to I S A - I R Q 5 , so that if we later want to implement this, we may do it wi thout hardware changes. Unfortunately I noticed I forgot this last connection, which was not necessary for the current version. Also , the board currently has the pin holes for a configuration E E P R O M to keep the data for programming the F P G A , so that it wi l l not be necessary to always use the download cable to program the F P G A after power shutdown. The actual memory device is not soldered on, but the schematics were conceived having this operating mode in mind (the current version has the M O D E - p i n of the F P G A bent up, i.e., unconnected). The device I was planning to use is A T M E L ' s A T 1 7 C 2 5 6 A (application note on " F P G A Configuration E E P R O M Programming Specification", A t m e l , 1998). 86 O S © 8 8 © 9 a © a a • 9 8 © 9 9 © © 9 a © a a © © 9 9 © a s © a © © 9 o |Q5£D 5 0 4 ^ a Rf?3 R i ? 2 • s s : 03 • O (?Vl o L E E S o i i 11 OCT o o o i I r g c n ° O e o e e s © a © © a e o e e o © © a e e a © o © e o e a e e a a l l a e e o e a a e e o 9 9 a • o e a a 6 9 6 8 9, e a e • a © 9 k « e W_&-/© a a © 9 9 9 8 9 tt 9 9 © a © [ E H e e a t t a a e a s 9 9 9 9 9 9 0 9 9 | 9 © © 8 © 8 © © 9 9 Figure E . l : The controller board with components 8 7 # Reference Part. .number Symbol Geometry Properties DC1 dcap dcap rcl206 (VALUE, "O.luF") DC2 dcap dcap rcl206 (VALUE,"O.luF") DC3 dcap dcap rcl206 (VALUE,"O.luF") DC4 dcap dcap rcl206 (VALUE,"O.luF") HI headerl5x2 HEADER15x2 headerl5x2 H2 header5x2 HEADER5x2 header5x2 PI tbconn DB37R db37r QI nhexfet n-hexfet to220ab (VALUE,"IRLZ24-ND") 02 nhexfet n-hexfet to220ab (VALUE,"IRLZ24-ND") Q3 pnp pnp to39 (VALUE,"2N2905A-ND") 04 pnp pnp to39 (VALUE,"2N2905A-ND") RI res r e s i s t o r rcl206 (VALUE,"IK") R2 res r e s i s t o r rcl206 (VALUE,"5K") R3 res r e s i s t o r rcl206 (VALUE,"2.2K") R4 res r e s i s t o r rcl206 (VALUE,"2.2K") R5 res r e s i s t o r rcl206 (VALUE,"0 ohm") R6 res r e s i s t o r rcl206 (VALUE,"0 ohm") R7 res r e s i s t o r rcl206 (VALUE,"IK") RP1 resnet resnet soml6 RP2 resnet resnet soml6 RP3 resnet resnet soml6 Ul 10x10 lOxlOholes lOxlOholes U3 isaconn ISACONN isaconn U4 spartan30 SPARTAN30 vqlOO U5 sprom SPROM dip8 Figure E .2 : A list of the components placed on the controller board 88 


Citation Scheme:


Citations by CSL (citeproc-js)

Usage Statistics



Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            async >
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:


Related Items