A COM PUT ER SIM U LATI ON FOR A ID ING TH E D ESI GN O F A DSP R AD IO by : A.O. BASSIOS Presented as a four month design project in partial fulfillment of the degree of Master of Science in Engineering in the branch of Electrical Engineering ) A B ST RA C T The use of digital signal processing (DSP) techniques to implement functions traditionally done by analogue methods is becoming increasingly popular amongst researchers and designers working in the telecommunications field. A good DSP design approach is to first simulate on a computer using a high level language . Problems exist with large unstructured simulations involving a number of users. This report presents a flexible and user friendly simulation structure to aid designers of radios using DSP techniques and components . The needs of the simulation users are investigated and a number of structures are evaluated. The shell of the simulation is then described. The simulation presented gives the user the ability to easily simulate the effects of different wordlengths of both fixed and floating point DSP microproces sors. A C K N O W L E DG E M E NTS I wish to acknowledge the assistance received from Fuchs Electronics in the use of their computer facilities and I would like to thank them for the opportunity to be involved in a very interesting DSP radio development project. In addition, I would like to thank my supervisor, Professor H.E. Hanrahan, for his helpful comments. C ONT ENT S 1. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . 1 1.1. Possible Solutions 1.2. Structure of the Report 2. OBJECTIVE OF THE SIMULATION 10 2.1. Introduction 2.2. Needs Of The Users 2.3. Needs of the Programmers 3. SIMULATION STRUCTURE 13 3.1. Introduction 3.2. Aspects Concerning the Programmer 3.3. Aspects Concerning the User 3.4. Structures Considered for the Simulation 3.5. Structure Implemented 4. SIMULATION SHELL 2 7 4.1. Introduction 4.2. Programme Descriptive Language 4.3. Description of Simulation Shell Programmes 3 5. SIMULATION OF DIFFERENT CHIPS . . . 44 5.1. Division into Subdirectories 5.2. DSP Microproce ssors 5.3. The Truncation Process 5.4. Linking versus Copying of .EXE files 5.5. Important Data Files 6. INITIALISATION OF THE SIMULATION . . . . . . . . . . . 56 6.1. Simulation Sampling Frequency and Sample Length 6.2. Type of Chip Chosen 7. HIGH LEVEL LANGUAGE PROGRAMMING RULES AND GUIDELINES 60 8. IMPLEMENTING FUNCTIONS IN THE SIMULATION 70 8.1. Introduction 8.2. The DCL Functional Procedure 8.3. Inclusion of the FORTRAN Programmes 8.4. PDL Listings for this Chapter 9. SIMULATION FUNCTIONS 9.1. Utility Functions . . . . . . . . . . . . . . . 82 9.2. Secondary Utility Functions 9.3. Tertiary Utility functions 4 10. TRANSMIT & RECEIVE PATH STEPS 93 10.1. Creating Signals 10.2. Sampling Signals 10.3. Amplification Menu 10.4. Audio Processing Menu 10.5. Modulation/Demodulation 11. EXAMPLE OF SIMULATION USAGE 96 11.1. Introduction 11.2. Explanation of Block Diagram 11.3. Example of Simulation Process 12. CONCLUSION . • • . . • • • . • . • . . . . • • . . • . 113 REFERENCES ......................................... 119 5 L IST OF F IGU R ES 3.1 The Tree Structure 3.2 The Network Structure . 3.3 Serial Processing in a Radio 3.4 The Linear-tree Structure . . . 3.5 The Modified Linear-Tree Structure 17 . . . . . . . . . 18 19 2 0 2 2 3.6 Block diagram of Simulation Structure . 24 3.7 Menu tree structure . . 25 4.1 Interaction of the main programmes . . . . . . . 31 4.2 Transmit Path . . 36 4.3 Receive Path . . . . . . . . . . . . . . . . 38 4.4 Channel menu structure . . . . . . . . . . . 40 4.5 Utility menu structure . . . . . . . . . . . . . . . 43 5.1 Simulation Directory Structure 44 11.1 Block diagram of a simulation process . 97 6 CHAPTER 1. I NT R O D U C T I O N Digital signal processing (DSP) techniques offer a number of significant advantages over conventional processing. Much of the processing in potential to be implemented digitally. analogue signal radios has the current digital signal processors (DSPs) are fast enough to do much of the baseband and IF signal processing . Future advances will make it possible to move the digital part of a radio increasingly close to the antenna, with the ultimate aim of a fully digital radio . Apart from being able to implement functions previously done by analogue methods, digital processing allows far more complex algorithms to be implemented. Thus, digital processing has applications in the radio communications field which were previous ly difficult or impossible to implement . The advantages of using digital signal processing are numerous:- 1. Higher Reliability - A small number of DSP hardware components would replace many analogue components. 2. Easier Manufacture The fine tuning of analogue components would be minimised. 1 3. Flexibility - The modulation schemes, filters and other operations of the DSP software could be changed without altering the hardware. 4. Less Component Ageing. 5. Greater Temperature Stability. 6. Special requirements and different versions of a design may be programme d in software . 7. Built in software testing facilities are possible. 8. Techniques which are virtually unusable in analogue systems become possible in DSP . Examples are the use of new techniques of adaptive filtering to allow equalisation of the channel path [1] and complex AGC algorithms with application to HF receivers. 9. Digital designs can be accurately simulated at a high level so that algorithms can be tested before any hardware design. As a result of the above, universities and telecommunications companies the world over are investing time and resources in the research and development of DSP radios [2,3,4]. 2 A good design approach to developing the software code to be used by the DSPs in the radio would be to first simulate on a computer using a high level language such as Pascal or FORTRAN. The advantage of this approach is that the DSP designers may experiment with, and optimise, the algorithm being developed without becoming involved with the complications of assembly level code. This report describes a simulation structure that was developed to aid in the design of a DSP radio . A problem with large computer simulations is that the designers tend to duplicate work done by their colleagues, or even programmes or subroutines that they themselves might have done some time previously. Interfaces between the Input/Output of one programme/procedure and another can become complicated when an undisciplined, unstructured approach is adopted for the simulation . A solution to this problem is to provide a structure whereby designers can include their contributions to the simulation without difficulty. The structure should allow the user to use other designers' contributions to the simulation both easily and effectively. 3 This report describes a simulation structure that was developed to aid in the design of DSP radio . 1.1. Possi bl e Sol uti ons This section describes some of the options that were considered for the DSP radio development simulation . 1.1.1. Commercial Display Software A number of general DSP display software packages are currently being offered by their vendors. Among these are packages such as ILS, DADiSP and DSPlay [5,6,7). This type of package does not provide the optimum environment needed for the complex DSP radio simulation. The packages are oriented towards display and are very general in nature. They do not provide the specialised features or ease of use wanted for DSP radio design . The chief requirement is for a friendly DSP environment where DSP designers can write their own programmes with a view to implementation in a DSP chip at a later stage . 4 1.1.2. The FUN System A DSP development environment, called FUN (functional language) was written at the University of Stellenbosch (8). FUN is a good attempt to provide a general DSP development environment . However, some of its disadvantages (with respect to DSP radio design) lie in its generality. Unlike some of the display software packages mentioned in the previous section, FUN is not menu driven (apart from the help and some other facilities). It is thus not quite as user friendly. One of the requirements of the simulation was that it was to be run on an in-house VAX 750 computer, which does not have a Pascal compiler. Many of the functions included in FUN were written in Pascal and thus could not easily be altered to suit the DSP radio design . It was not trivial to alter the FUN simulation environment to enable easy simulation of different DSP microprocessors with differing wordlengths. 1.1.3. A General In-Circuit-Emulator An interesting approach to solving the problem of determining the effects of differing wordlengths on the algorithms was presented by Carter (9). He presents a general in-circuit-emulator (ICE). The ICE allows the 5 emulation of a number of DSPs. However, this is not an alternative to a high level simulation as the routines must be written in low-level assembly languages for each DSP chip to be investigated. 1.1.4. Developing a Simulation Specifically for DSP Radio Design An alternative to the above methods was to develop a simulation in-house. The disadvantage of this method was that time would have to be spent on developing the structure. This was weighed up against the following factors:- 1. The simulation could be written to exactly fulfill the requirements of the DSP radio designers, and omit unnecessary and confusing functions . 2. It could incorporate the desirable features of the above mentioned options (eg. be menu based AND simulate for different DSPs). 3. It could include features to guide the inexperienced telecommunications/DSP engineer into using it correctly and facilitate understanding of the 6 fundamental issues of radio design, and thus help good design. 4. The DSP radio designers would be actively involved in writing the DSP software and would thus gain valuable DSP experience and expertise. 5. The programme s could be written in a way that closely simulates the actual implementation of an algorithm in a DSP chip . 6. The initial cost of buying commercial software would be avoided. 7. An in-house simulation could be written to have powerful abilities to simulate the characteristics and effects of different DSP microprocessor word configurations (eg. 24 bit fixed point vs . 22 bit floating point) . It could be written so that comparisons between the effects of different chips could easily be made by the simulation user. This type of simulation is especially important in radio design where signals typically have very large dynamic ranges. 7 After considering the options it was decided to write an in-house simulation . 1.2. Structur e of the Report The rest of this report describes the structure and shell of the simulation developed. Much of the detail of the simulation has already been implemented, but it is beyond the scope of this report to give a description of more than a few examples of the detail. However, more information may be found on the detail and use of the simulation in the references [10,11,12]. Chapter 2 describes the needs of the user and presents the objectives of the simulation. In chapter 3 a number of different structures are considered for the simulation. Chapter 4 describes the shell programme s at the top of the simulation hierarchy. Chapter 5 describes how the simulation is controlled and how the simulation of different DSP microprocessors is facilitated by subdividing the simulation's programme s into a number of subdirectories. 8 In chapter 6, the function of the more important programmes in the simulation are presented. Chapter 7 gives the rules and guidelines for high level language programming in the simulation . Chapter 8 shows how to include a function into the simulation . Chapters 9 and 10 contain short descriptions of the functions available in the simulation . An example of how the simulation is used is shown in chapter 11. The report is concluded in chapter 12. 9 CHAPTER 2. O BJ ECTI V E OF THE SIM U LATI ON 2.1. Introd ucti on This chapter describes the needs of the simulation users. Distinction is made between the users who use the simulation purely as a tool (users) and those actively involved with enhancing and expanding the simulation (programmers). 2.2. Need s Of The Users 1. User friendliness :- The simulation should be simple for an inexperienced user to use. It should guide the user into using it correctly. 2. Flexibility :- It should allow the more advanced user to perform unconventional sequences of functions . 3. Advanced features :- It should incorporate advanced features without complicating the simulation for the inexperienced user. 4. Different word configurations :- It should allow the easy simulation of different wordlength floating and fixed point configurations . 10 5. ut il ity f u nct ions :- It should provide easy access to commonly used ut il ity f unct ions such as the display of signals . 2.3. N e ed s of t h e P r o g r a m m ers 1. Clar ity :- The structure of the simulation should be clear and understandable . 2 . Easy expandability :- The programmers should be able to include f unct ions in the simulat ion without d if f iculty . 3 . Flexibil ity :- The FORTRAN or pascal designers should write their programmes in a structured and well documented way , but there should be the minimum of restrict ions imposed by the simulation . 4 . Trunca t ion methods :- The simulat ion should provide a method whereby it is easy f or the programmers to design a programmes that simulate the ef f ects of dif f erent word conf igurat ions. 11 The aim of the simulation is to attempt to fulfill as many of the above requirements as possible . The balance of this report describes the structure that was developed in an effort to meet the aims . 12 CHAPTER 3. SIM U LATI ON STRUCTUR E 3.1. Introd ucti on This chapter presents and evaluates a number of structures that could have been used for the simulation . 3.2. As pects Concerni n g the Program mer Owing to the limited time available to write the simulation, the structure should be such that engineers can write programmes/subroutines quickly and easily without worrying too much about external constraints imposed by the simulation . The first alternative considered was to write one big simulation programme . The programme would have to be rigidly structured and divided into subroutines. The path of the signal through the simulation would be by passing parameter s. Another method considered was to write a number of shorter programmes and run them Language (DCL) on the VAX. by using the DIGITAL Command (DCL is an interpreted language that allows one to write VAX/VMS operating system command procedures commands . See [13] containing for more details .) The processed signal would be passed from 13 programme to programme by writing the output in one programme to a data file and specifying this data file as the input to the next programme . A disadvantage of this method is that it takes more time to read and write data files on the computer. However, since speed is not an essential aspect of the simulation, this is not a major problem. Unfortunately, the use of DCL confines the portability of the simulation to computers that run the VAX/VMS operating system. However, by designing the DCL command procedures using a "Programme Description Language" or POL (explained in section 4.2 ) rewriting the DCL code for other computers is simplified. A major advantage of this method is its simplicity. It is easy for a number of programmers to write sub-programme s for the simulation without affecting each other. It is also much simpler for them to include their programmes into the simulation structure. The other method would require recompiling and linking every time a new simulation function was to be included. By subdividing the simulation into smaller components, the room for error is decreased. Each programmer is able to use his own style in the programme s he writes. There would only be a few rules concerning the input and output of the 14 programmes that should be adhered to. Also, a record of the signal at every point in the simulation is kept, and thus these signals are readily available at any time . DCL has some attractive file handling features and commands that can be used with great effect in the simulation . Another advantage of this method is that programme s written in different languages (eg. FORTRAN and Pascal) can be used in the same simulation (providing that the data files have similar formats). An advantage of using separate files rather than a big FORTRAN programme is that signals are available at each point in the simulation . This will enable the user to use a DSP simulator, programmed with machine code to process the signal data files instead of the high level language programmes . In this way, once the user has simulated his high level design, he can gradually include his DSP-coded algorithms into the design and show that it still works. After weighing up these considerations,it was decided to use the DCL method. 15 3.3. As pects Concer n i n g the User one of the most important goals of the simulation is to be user-friendly. It has been found that a clear menu based system can contribute to the friendliness of software such as this . It was decided to use a menu system with easily understood instructions and questions. 3.4. STRUCTU R ES CONSI DER ED FOR TH E SIM ULATI ON This section proposes a number of structures for the simulation . The usefulness of each of these structures to the simulation are evaluated. 3.4.1. The Tree Structure A diagram of a tree structure is contained in figure 3.1. This type of structure guides the user through different sub-menus, down the tree to the desired operation . This structure is rigid and useful in many applications. It restricts the number of choices and is thus simpler for the inexperienced user to use. 16 MAIN MENU MENU MENU MENU MENU MENU •xe.;utabJ.e exe cut:at'-• executab;.,e •-'•utatJ•e ex1cta11..e 1xec;.;.lall4e 1'11• llt fl• !!.l• 1le Figure 3.1 The Tree Structure However, the structure lacks flexibility in that it is, not easy to proceed from a menu in one branch to a menu in another branch . The user would have to return back up to the tree hierarchy until a path to the required node could be found. 17 3.4.2. Tbe Network Structure A diagram of a network structure is contained in figure 3.2. Figure 3.2 The Network Structure. This variation of the tree inflexibility of the tree by structure overcomes the providing short-cut paths between menus. However the structure can become complex and is not as easy to implement and maintain. 18 3.4.3. The Linear-tree Structure Processing in a radio can been seen to be essentially a linear, serial process eg. :- TX FILTER AUDIO PROCESSING MODULATION FILTER AGC Rx FILTER AGC DEMODULATION FILTER AUDIO PROCESSING Figure 3.3 Serial Processing in a Radio . For the simulation, the different processing blocks would consist of different options to be chosen by the user. These would be implemented with a tree structure . Figure 3.4 contains a diagram demonstrating the linear-tree structure. This structure would provide the rigidity needed for the first-time user, but would be frustrating for the advanced user who might wish to take short cuts to certain parts of the simulation. 19 START Figure 3.4 Linear-tree structure M = menu F = funct ional program J.4.4. The Modified Linear-tree Structure A modification to the above structure should provide the features required by an advanced user while still guiding the inexperienced user down the accepted path. This is done by providing a route back to the beginning of the path from a "Utility Menu" . From the beginning of the path, any step in the path may be reached without going through the steps which normally precede it. Alternatively the user may choose the Utility menu option which leads to the next logical step in the path. Figure 3.5 contains a flowchart of the modified linear-tree structure . 21 START MAIN MENU u END Figure 3.5 Mod if ed linear-tree structure M = menu F = functio nl program U = ut il ity menu comments on modified linear-tree structure flowchart. "U" stands for "Utility Menu" . This menu would handle commonly used routines such as filter, graphics, FFT's etc. Another important function of this procedure would be to ask the user whether he would like to proceed with the recommended next step of the simulation or return to the start of the path. From the start of the path, he would be able to enter the simulation path at any point. 23 r-. M AIN MENU (Tree ) c 3.5. Structure Im pl emented After considering the aspects above, it was decided to implement a combination of the above structures shown in the block diagram of figure 3.6. START ) I Mess a ge I /' ... '-V I I I TRA NSMIT CHANNEL R ECEIV E PATH MENU PATH M ENU (Tree) MENU (Mo d i f ie d [Mo d i Le d l i n e a r - l i ne a r- t r ee ) t r ee ) 'II' t + "'" END Figure 3.6 Block diagram of Simulation Structure The modified linear-tree structure seemed to be the most desirable one for the transmit and receive paths as these paths consist of essentially serial steps . The channel menu was chosen to be implemented with a tree structure, because 24 C t MENU (DCL) it was expected that the user will not use the channels in series as a matter of course . A Utility menu is available f rom the transmit and receive paths as well as the channel menu . When the Ut ility Menu processing is completed , programme control is returned to the call ing menu . The above menus were programmed in DCL and ca ll sub-menus using the tree structure shown in f igure 3 .7 . alled from one he ma!n DCL menus I MENU (D CL) I I I I MENU (D CL) I I executab le f i le [FORTR AN) exec utable f i le (FOR TR AN) executab le fi le (FORTR AN) executable f i le (FOR TRAN) Figure 3 .7 Menu tree structure 25 Note that the bottom of the hierarchy consists of executable files. This structure allows a high degree of freedom for the high-level language programme designer . The requirements and restrictions are explained in detail in chapter 7. 26 CHAPTER 4. SIM U LATI ON SH EL L 4.1. Introd ucti on This chapter contains a description of the programmes on the top of the simulation hierarchy. More information about the detail of the shell is given in chapters 9 and 10. The first part of the chapter concerns the "Programme Description Language" (POL) used and its application to DCL programming. 4.2. Prog ramme Descr i pti ve L an g ua g e The Software engineers responsibility for the maintenance of the shell should apply discipline in maintaining a structured programme. It should also be readable by people not familiar with DCL, which is an interpreted language very open to unstructured programming. A good way to achieve this would be to use a POL. The PDL described in [14] is a good way of encouraging good design and making a programme more readable. The application of the POL to high level language programme design is well described in the above reference. However, DCL command 27 procedures contain operating system commands which make the specific definition of the POL not entirely applicable to OCL programme design. In spite of this fact, a POL can be of great use in encouraging good OCL procedure design. OCL is an interpreted language which is very open to unstructured programming. In addition a POL makes the programme far more readable . It was decided to use a POL based on Walker' s description in [14]. Any confusion resulting from the operating system nature of the target language could be explained by including explanatory comments in the POL listing. {In the POL used, comments are enclosed by asterisks.) The following concepts and conventions used in the simulation should enhance the understanding of the POL listings . 4.2.1. Logical names When reading the POL listings, it is necessary to understand the VMS concept of creating logical names. A logical name may have any string of characters assigned to it. For example, the logical name L AST may have the name of the data file S I G NA L. DAT assigned to it. LAST remains defined as SIGNAL.DAT until it is reassigned or deassigned. Logical names play an important part in the simulation and there are two of particular significance: 28 "LAST" always has the name of the last signal data file created assigned to it. This is a useful feature which enables the user to chain processing blocks together without remembering the names of the data files in which the processed signals are stored. (These data files are referred to as si g n al d ata fi l es in this report) The most important logical name in the simulation is called "MAI N D IR" . This has the name of the simulation's main (or root} directory assigned to it. The name of this directory on the development computer is [ADS.M EN U] . The logical name is necessary to maintain portability to other VAX/VMS computers. M AI N D IR enables programmes in other directories to access the simulation signal data files which are always stored in the main directory. 4.2.2. Storage of files The file storage convention used in the simulation is as follows : POL files have the extension .POL DCL files have the extension .COM FORTRAN files have the extension .FOR Object files have the extension .OBJ Executable files have the extension .EXE Data files have the extension .DAT 20 Filter coefficient files have the extension .FLT Text files have the extension .MEM 4.3. DESC R I PTI ON OF SIM ULATI ON SHEL L PR OG R A M M ES The shell was written by writing a programme in POL form and then inserting the DCL code . 30 - 4.3.1. Shell structure The structure of the shell programmes on the top of the simulation hierarchy was implemented according to the simulation structure block diagram presented in figure 3.6. The interaction of these shell programmes is shown in more detail in figure 4.1. S IM . COM START I Mes.s age I ,., ' I MAIN MENU (Tree) ·,/ I I 1 mNS"'11T. C.'Jl.l C4ANNEL.CCll.l PECE.IVE.:.Ot.1 CHANNEL M ENU TRA NSMIT 'Tr e e) R ECEIV E PATH P.A TH M ENU M ENU . :,, (Mo d i fie d [Mod i Le d 1i ne a r - !i near·- t r ee] \V t ree) t + c EN0 ) Figure 4.1 Interaction of the main programmes 31 4.3.2. M a i n Progr am me SIM .CO M can be seen as the main programme of the simulation. All other procedures and programmes are on a lower level of the simulation hierarchy. The function of SIM.COM is to display information and news about the simulation by displaying the news file NEW S .HEM . The MA IN M ENU of the simulation is then displayed. The user has the choice of proceeding down the transmit path (stored in TRANSMIT.COM) , the receive path (stored in RECEIVE.COM) , the channel menu (stored in CHANNEL .COM) , or terminating the simulation. When programme control is returned by one of the DCL command procedures called, the MA IN M ENU is displayed again. The PDL of SIM.COM is shown overleaf. The programme with DCL commands included is given in the programme listings . 32 * program SIM.COM ****************************************************************1 This programme is at the top of the simulation hierarchy. 1 * It puts the simulation on either the transmit or receive path. ****************************************************************1 Variables: Integer : Single : Local: CHOICE * input from menu * Integer: Single: Global: LAST * LAST is an assigned value * * which has the name of the last * * signal data file assigned to it * MAIN DIR * MAIN DIR is an assigned value * * which has the name of the main * * directory (containing the * * simulation programs) assigned * * to it. ([ADS .MENU] on Fuchs VAX)* External procedures : DCL procedures: TRANSMIT.COM RECEIVE.COM CHANNEL .COM FORTRAN programs : Text files: NEWS.MEM * transmit main menu * * receive main menu * * channel menu * * simulation information and news * Begin : MAIN DIR := Name of present directory * [ADS .MENU] on Fuchs VAX * * DCL logical assignment * LAST := DUMMY.DAT * DCL logical assignment * Put: " DIGITAL RADIO SIMULATION" NEWS.MEM End put: Repeat: Put: * Display simulation info and news * * Ask whether TRANSMIT,RECEIVE * "WHICH DO YOU WISH TO DO" " " " 1 TRANSMIT " or CHANNEL simulation * is desired 33 " " " 2 " " " 3 " " *" 4 " " " 9 " " End put: RECEIVE " PUT SIGNAL THROUGH CHANNEL" add any additional functions here"* END SIMULATION" Get : CHOICE End get: Case CHOICE of: 1 Call TRANSMIT.COM 2 Call RECEIVE.COM 3 Call CHANNEL .COM * go to transmit path menu * * go to receive path menu * * go to channel menu * * 4 add new functions here * 9 End case: Until (CHOICE=9) Put: " END OF SIMULATION" End put: end: End program: 34 4.3.3. Tr a nsm i t Path The TRA NSM IT.COM DCL procedure is the main calling procedure for the transmit path. This procedure utilises the modified linear tree-structure explained in section 3.4.4. The procedure first displays a message explaining its function and follows this with the TRA NSM IT PATH M ENU. The menu options are ordered in a logical fashion . The user may start at the beginning of the transmit path and continue along it until the programme execution is returned to the calling programme (SIM.COM) . It is also possible to enter and continue along the path from any step in the path. In addition, the option of returning to the TRANSMIT PATH MENU exists after every step. This method provides guidance for the inexperienced user and flexibility for the more experienced programme user/writer . A flowchart of TRANSMIT.COM is shown in figure 4.2. The PDL listing and DCL procedure is may be found in the programme listings . 35 VOGAD/AMPLIFICATIC MEU S TART MESSAGE TRANSMIT PATH MENU ENTER SIMULATION PARAMEIERS CREATE MENU u y9\ c MODULATION MENU AGC ENU UTILITY MENU EO U UTILITY MENU AUDIO PROCESSING MENU A 8 F:i. gur e 4 .2 : rr ansmit p a th 4.3.4. Recei ve Path The Receive Path command procedure (R EC EIV E.COM) has an identical structure to the Transmit Path. The major difference between the two paths is the sequence of the steps . The steps are ordered in the logical fashion of operation in a radio . The receive path flowchart is shown in figure 4.3. The POL and DCL listings may be found in the programme listings . 37 START c AECfIYE PATH MENU ENTER SIMULATION PARAMETERS CREATE MENU u AGC MENU DEMODULATION MENU A 9 F igu re 4 . 3 : qe c e i ve p a t h AUD O OROCESSING '4ENU AMPUF CATION MENU UT!UTY MENU U UTILITY MENU 4.3.5. The Ch annel Men u The command procedure CHAN N EL.COM contains the CHANNEL MENU. Its function is to offer the user a choice of different channels through which he may put his signal. These channels include simply adding gaussian noise and an HF channel simulation [15]. Unlike the transmit and receive paths, it is not desirable for the channel menu to use the modified linear-tree structure in its implementation. It is more logical to use the tree structure in this case, since the channels would probably not be executed in serial steps . The channel menu presents the user with a choice of channels, the opportunity to call the UTILITY MENU, or the option of leaving from the channel menu. If the last option is not chosen, the channel menu is redisplayed on return from any of the called procedures. An interesting feature of the CHANNEL .COM is that the user may choose to run his own channel programme which might not yet have been included in the simulation. By looking at the PDL listing, it can be seen that the programme writers have a clear indication of where and how 39 to include additional channels into the procedure and thus the simulation . This helps in fulfilling the simulation' s requirement of easy expansion. A flowchart of CHANNEL .COM is shown in figure 4.4. STAf1T CHANNEL MENU GAUSSIAN NO SE CHANNEL HF CHANNEL PCl'J v!SIO"l F'JC. 'J f HER CYANNElS JSfR . S iJl'fN CHANNEL Pt:l'.JG RAMME ENli ( EX!i ) Figure 4.4 Channel menu structure 4.3.6. Utility Menu The UTILITY .COM DCL procedure is an integral part of TRANSMIT and RECEIVE paths. One of its functions is to ask the user whether he wishes to continue along the original 40 path. The alternative is to return to the start of the path where all the menu options are displayed. This information is passed to the calling procedure by altering the value of the global variable "MENU". Other facilities accessible from UTILITY.COM include: display routines FFTs hard plot routines filters, the facility to branch in and out of the simulation. Noise addition decimation interpolation Hilbert transformation multiplication by a real tone multiplication by a complex tone signal addition carrier insertion renaming data files HELP facility. etc. 41 ' These f unct ions were implemented in a tree structure . The f unct ions called also use tree-structured menus . More deta il on the f unct ion implementat ions are given in a later chapter . The number of ut il ity f unct ions implemented proh ibit the display of all of them on the console simultaneously . To overcome this problem , submenus of the UTILITY MENU were created and included in the tree structure as shown in f igure 4 .5. The submenus are conta ined in UTILITY2 .COM and UTILITY3 .COM . 42 FFis ( ST,A.fH ·• MAIN U1llIT< MENU Oisp ia y i:iout ines Plot MENU: ..'YES" 11enu "4ENU: •"No• ' . ', ·-.. , .. FiHer Branch to HELP 21en1.; '/MS menu (RetUr'l J SECDl'tJARY U11LlT< MENU I t MlilLply by a real tone Add two f iles . • , • • Oec maL on 1-!ilbert "tu l Lpl y Insert ' men Transf or!ll by C O!Dp leit ca e: LO menu t o'le TERTIARY U1lllH MENU Rename a data f ile Include a ORTRAN tuncLon ' Co'lvert a OFOP tile to Silll . 'or!Dat Reserved tor future functio'l. ' Reserved tor- •uture fL.Onct ion. Add noise Spec H y terminal tye Reserved for •uture function. Reserved for •uture function. i'igure 4.5 Utility menu structure 4 3 CHAPTER 5. SIM U LATI ON OF D I F F ER ENT CHI PS One of the most important aspects of the simulation is its ability to simulate the effects of different DSP micro- processors. This is complicated by the fact that not only do DSPs have differing word lengths, but they can have either fixed or floating point configurations (or both) . This chapter describes how this problem is tackled in the simulation. 5.1. D i v i si on i nto Subd i rector i es The simulation environment consists of a main directory and four subdirectories (shown in figure 5.1). ain directory 'Ul!N_JJIR I - - - - -- - - - - -- - - I I I 32 b A.t Fixed po nt Fl oa tin g po A.nt i:'l oaLng po A.nt Subd irectO"I Subd irectO"f Subdirectory [.FIXED] f. >="LOA TING) f .NOTRUNCJ 1 HELP Subd rectO"J [ .LiELP) Figure 5.1 Simulation Directory Structure 44 The simulation's main directory stores all the programmes that are normally needed during the use of the simulation . These include DCL files, executable files, as well as data files. In addition, almost all the FORTRAN and POL listings and object files are kept in this directory. On the development system, the name of this directory was [AD B.M ENU] , but the simulation maintains its portability by assigning the name of the main directory to the logical name M AI N D I R. The subdirectories [.FIX ED] and [.FLOATI NG] contain the executable and data files which are required for the simulation of the fixed and floating point chips respectively. The subdirectory [.NOTRU NC] contains the files that are necessary for the simulation of the special case of a 32 bit floating point configuration. [.H ELP] is the subdirectory where files used for the HELP facility are stored. The reasons for structuring the environment in the above way are given in the following sections . 5.2. DSP M i croprocessors 45 Currently available DSP microproce ssors can be divided into two broad classes:- 1. Fixed point configuration chips 2. Floating point configuration chips Examples of fixed point chips are :- 1. TI TMS32010 and its derivatives 2. Analog Devices ADSP-21 00 3. Philips PCB 5010,5011 4. Zoran VSP 5. and many others which all have a basic 16 bit wordlength. Another fixed point chip is the Motorola DSP 56000/1 which has a 24 bit basic wordlength (and thus a higher dynamic range). Examples of floating point chips are :- 1. AT&T WEDSP32 2. NEC PD77230 3. TI TMS320C30 (still under development) which have 32 floating point configurations consisting of 24 bit mantissas and eight bit exponents. The OKI MSM6992 is a 22 bit floating point chip with a 16 bit mantissa and six bit exponent. (This chip (amongst 46 others) was seriously considered for DSP radio applications because of its low power consumption. ) One of the aims of the simulation was to allow the DSP radio designer to easily simulate the effects of any of the configurations and wordlengths mentioned above (or any other configuration they might care to define. The simulation is done by truncating the results of arithmetic operations to the required precision during the DSP programmes. 5.3. The Truncati on Process From the programme writers point of view, an important aspect of the simulation is that after every arithmetic operation, the subroutine TRU NCATE must be called. The parameters passed to the subroutine are :- 1. the result of the preceding operation 2. data which was read in from the file TRUNCD ATA.DAT TRUNCD ATA.DAT is a data file which contains the parameters needed by the truncation subroutine . The function of the truncation subroutine {TRUNCATE) , is to truncate the value of the input real number to a value that is a possible 47 representation of the word length of the chip that is being simulated. The method allows the same programme to be used for simulating any word length or configuration. The only things that alter are the data contained in TRUNCD ATA.DAT and the TRU NCAT E subroutine to which the programme object file is linked. Three versions of the TRUNCATE subroutine exist in the simulation. One is stored in each of the three simulation subdirectories. The file TRU NC INT. FOR contains a TRUNCATE subroutine that does f i xed p o i n t truncation. This FORTRAN file and its object file are stored in the subdirectory [.F IX ED] . The file TRUNCAT E.FO R contains a TRU NCATE subroutine that does f l o a t i n g p o i n t truncation . This FORTRAN file and its object file are stored in the subdirectory [.F LOATI NG] . The file TRUNCD U M. FOR contains a TRUNCATE subroutine that is a dummy routine . This FORTRAN file and its object file are stored in the subdirectory [.NOTR UNC] . The dummy routine implies that the input is returned unaltered. This is a way for simulating the effects of 32 bit floating point chips because this is the wordlength of a single precision word on the VAX. 48 The actual mechanics of the truncation process are explained in Appendix A. 5.4. Li nki n g versus Copyi n g of .EXE fi l es It has been shown how the same FORTRAN programmes can be made to simulate fixed point, floating point and 32 bit floating point DSP chips by linking to the appropriate TRUNCATE subroutine. The resulting executable files (with a •EX E extension) then simulate the effects of the required chip. A possible way to take advantage of this could have been to link all the programme s requiring truncation after the user had entered whether he wished fixed or floating point simulation. However, linking a large number of files can take an appreciable time and there would have been a long time delay while the programmes were linked. Another method considered was to link all the programmes and per manentl y store all the resulting executable files in the different subdirectories. i.e. All the executable TRUNCI NT.OBJ would files that be stored were linked to in subdirectory 49 [.F IX ED] . These files would all simulate fixed point configurations . All the executable files that were linked to TRUNCATE.O BJ would [.FLOAT ING] . These be stored in files would subdirectory all simulate floating point configurations . All the executable files that were linked to TRU NCD UM.O BJ would be stored in subdirectory [.NOTR U NC] . These files would all simulate 32 bit floating point configurations . After the user inputs which type of chip he wishes to simulate, the executable files from the relevant directory would have to be copied to the normally active main directory (MAIN_DIR) . A disadvantage of this method was that more storage space is required to store all the .EXE files. (Storage space was not a problem on the development computer .) Another disadvantage might have been the added complexity when including a new DSP programme into the simulation . The compiled programme would have had to be linked at least three times and the .EXE files would have had to be placed 50 to the correct subdirectory. This problem was overcome by writing a DCL command procedure (INCLUD E.COM) to do all the linking and placing by simply running the procedure, or by calling it from the UTILITY menu . An advantage of this method compared to the linking method was that it takes far less time to COPY the files than to LI NK them. This method had the advantage that all the .EXE files were always available . This fact made it possible to allow the user the option of simulating for another configuration instantaneously (i.e. without copying files from one directory to another). This could be done by simply changing the default directory from the main directory (MAIN_DIR) to one of the subdirectories (where the relevant files reside). The latter method seemed to be the better one of the two and it was the method implemented. 5.5. Im porta nt Data Fi l es The data and text files in the simulation can be divided into three classes: 51 1. Si g nal d a ta fi l es signal data and unformatted way to which contain sampled are stored in the reduce storage space needed and read/write times. 2. A uxi l i ary d ata fi l es such as the filter coefficient data files which are stored in the "l i st - d i rected " format 3. Control d ata and text fi l es which are used in the control of the simulation and are stored in the "l i st-d i rected " format to enable easy inspection of their contents. These files are small and do not take up much storage space or time . The control data and text files are : SIMPARAM. DAT TRUNCDATA.DAT CHIPEXPL .MEM CHIPCONF.MEM NEWS.MEM An explanation of the contents and function of these files follows . 52 5.5.1. Simulation Parameters SIMP A RA M.DAT contains the si m ul ati on para meters. i.e Sam pl i n g freq uency Len gth of si g nal d ata fi l es (Sample length) 5.5.2. Truncation data TRUNCD ATA contains the information necessary for the truncation subroutine TRUNCATE to do its task. The data contained in this file is: For the fi xed point version : The maximum positive value possible The maximum negative value possible The minimum value of an ordinary register (LSB) The minimum value of accumulator (accumulator LSB) For the fl oati n g point version: The maximum positive value possible The maximum negative value possible The minimum value of a floating point word. The range of the mantissa. The use of this data is explained in Appendix A. 53 5.5.3. Chip configuration C H I P C O N F.M E M is a text file which contains the words FIXED FLOATING or NOTRUNC This file give the DSP programme s the means of determining the chip configuration active in the simulation. 5.5.4. Chip explanation C H I P E X P L.M E M is a text file which contains an explanation of the chips parameters (i.e configuration and wordlengths) . It also gives the name of a chip with these parameters (if applicable) . This file is used to give the user information about the chip that is currently being simulated. 5.5.5. News and Information N EWS.M E M is a text file containing general information and news about the simulation . It is displayed when the simulation is initiated and can be updated at any time. 54 The creation and alteration of these files are explained in the next chapter . 55 CHAPTER 6. IN ITIA L I SATION OF TH E SIM U LATI ON This section describes how the simulation is initialised when the user choose the option : "ENTER SIMULATION PARAMETERS" This is always the first option in the transmit and receive paths . 6.1. Si m ul ati on Sam pl i n g Freq uency and Sam pl e Len g th The first action of the path is to run the FORTRAN executable file SIM PA RA M. The purpose of this programme is to define the sampling frequency and the number of samples in the signal data files. The first action of SIMPARAM.FOR is to read the current active values of the sampling frequency and sample length by reading the data file SIMP AR A M.DAT. A message is then displayed on the console explaining what the parameters are. The user is then asks if he wishes to alter these values. On a positive reply, the programme prompts for the new values and stores them in a new version of SIM PA RA M.DAT. These parameters remain to be used by the simulation programme s 56 until changed by the above procedure, or by a decimation or interpolation process. The POL and FORTRAN listing of SIMPARAM.FOR are included in the programme listings . 6.2. Type of Ch i p Chosen After SIMPARAM has finished its execution, the procedure CHI PTYP E.COM is called. This DCL procedure informs the user of the name and characteristics of the DSP chip which is presently active in the simulation. It does this by displaying the contents of the file CHI PEXPL.M EM on the screen. The user is asked whether he wishes to simulate for another chip. On a positive reply, it asks the user which chip configuration he wishes to use in the simulation. He may choose one of the chips commercially available from the menu displayed, or input his own configuration. If he chooses one of the configurations from the menu, the procedure copies the applicable truncation data to the TRUNCD ATA. DAT files in the main directory and the applicable subdirectory. 57 Text explaining the name and characteristics of the chip is then written to the text file C H I P E X P L.M E M in both the above mentioned directories. The text file CH I PC O N F.M E M is then copied from the applicable subdirectory to the main directory. This file contains the name of the subdirectory from which it was copied (i.e. either FIXED, FLOATING or NOTRUNC) . Finally, all the executable (.EXE) files are copied from the subdirectory to the main directory. This means that the simulation simulates for the desired chip unless specifically commanded by the user to simulate for another configuration . This is accomplished by temporarily changing the default from the main directory (MA I N _ D I R ) to one of the subdirectories . If the user wishes to define a non-standard configuration, most of the above functions are performed by executing the FORTRAN programme T R U N C DAT A. This programme asks the user for the configuration and wordlength he wishes to simulate . It then calculates the truncation parameters and stores them in the correct T R U N C DAT A.D AT data files. (An explanation of how T R U N C D AT A.F O R calculates the parameters is contained in Appendix A. ) T R U N C DAT A. F O R then writes the required text to 58 the C H I P C O N F . M E M and C H I P E X P L. H E M text files . The executable files are then copied from the applicable subdirectory to the main directory by C H I P T Y P E . C O M . The result of this processing by C H I PT Y P E . CO M is that the simulation's main (root) directory ( M A I N _ D I R ) contains all the executable and data files required for simulating the specified chip. In addition, each of the three subdirectories have all the executable and data files that are required for performing the truncation appropriate to their most recently defined chip. This makes it easy for the simulation to offer the user the option of temporarily simulating another configuration . All the simulation has to do is to change the default directory from the main directory to one of the subdirectories. This feature of the simulation is an extremely useful one for DSP designers who want to quickly compare the effects of different chip configurations on one of their algorithms . 59 CHAPTER 7. HI G H L EV EL LA NG UAG E PR OG R A M M ING R U L ES A ND GU IDELI N ES The simulation structure offers a very flexible working environment for the programme designers, but, obviously, some rules and guidelines must be given to enable the simulation to work cohesively. Although one of the advantages mentioned about the simulation structure was that a combination of programming languages could be used, only FORTRAN was available on the computer on which the simulation was developed. Thus the rules and guidelines were developed to optimise the use of the only language available . It is not envisaged that it will be very difficult to adapt the rules if another language such as Pascal or C becomes available . A good example of how I/O anomalies between different languages can be overcome is shown in [8]. The most important rules of the simulation apply to the data files: 1. All si g nal d ata fi l es (i.e. data files in which the sampled signals being processed are stored} must be "unformatted ". Unformatted files take up less storage 60 space and the data is accessed quicker than in the "list- directed" format . Unformatted files are not man-readable. In the unlikely event of the user wishing to read the data samples, he may use the FO RM AT utility function to create a list-directed copy of the unformatted file. (List-directed files are man-readable. ) 2. All other d ata fi l es must have a "l i st-d i rected " format . This allows easy inspection of the files which are generally not long and do not require much storage space or read/write times. 3. All the data files must be stored and read from (and stored in) the main directory (even when the defaul t d i rectory i s set to one of the subd i rector i es). The exceptions to this rule are some of those files which are used in the control of the simulation. These are : TRUNCDATA. DAT CHIPCONF.MEM and CHIPEXPL.MEM. 4. A message telling the user the name of the output file (s) must be displayed. 61 Other guidelines are : 5. The programme should only prompt the user for the name of the input signal data file and any other information it requires from him that it cannot obtain from the simulation. (eg. the sampling frequency should be obtained from SIMPARAM.DAT and not be asked for.) 6. The data needed for truncation should be read from TRUNCDATA.DAT. This data should then be passed as parameters to the T RUNC A T E subroutine in the same order . 7. The TRUNCATE subroutine is called as follows : CALL TRUNCATE (number,max-pos-val,max-neg-val,min-val,mantis sa-rangE ,where "numb er " is the rea1 number to be truncated and the last four parameter s were read in from TRUNCDATA. DAT in that order. In the fixed point TRUNCATE subroutine (stored in TRUNCINT .FOR) , the last parameter is not used. In this case the last value read in from TRUNCDATA.DAT is the value of the accumulator LSB . This value is inserted as the second last parameter in the calling statement when 62 it is required to simulate the truncation effects of the accumulator . To enable the programme to simulate the effects of the chip as closely as possible, the result of each arithmetic operation should be truncated. 8. The name of the FORTRAN programme should indicate its action . It should be preferably stored in a file with the name of the programme and a .FO R extension. 9. The programme's output signal data file should preferably be the same as the name of the programme with a •DA T extension. 10. Any special inputs required should be clearly explained in the comments . (eg. the format required for the filter and Hilbert transform coefficient data files.) 11. Comments about new programmes should be included in the "news" file NEWS .MEM and/or the HELP menu . 12. The programmes should be written in a structured way and be well documented. A good way to achieve this is to write a POL first and then insert the FORTRAN 63 code. An example of a POL which was converted to a FORTRAN programme is shown overleaf. This is the programme which handles IIR filtering in the simulation. The last point on the POL method of design has particular significance when it is noted that some modern day DSP chip manufacture rs are designing their chips with the aim of writing a high level language compiler for the processor . The use of POLs will make the task of converting the FORTRAN programmes to the high level OSP programme language much easier. Alternatively, it might be possible to write a POL- to-DSP machine code compiler to translate directly from the POL itself. 64 Program: IIRFILTER.FOR ******************** ******************* ******************* * FORTRAN program to implement an IIR Filter * **************************************** ****************** Input files: FILTERIN.DAT FCOEFFS TRUNCDATA.DAT CHIPCONF.MEM output files: FILTER.DAT * File containing input signal data * Char variable containing name * of file containg tap coefficients * File containing truncation data * File containing chip configuratior * either 'FIXED ' or 'FLOATING' * File containing output signal date Variable s: Char : Single : Global: MAIN DIR Single : Local: * logical name for the simulation* * directory normally in use * * ( (ADB.MENU] on the Fuchs VAX * Integer: FCOEFFS * Char variable containing name * * of file containg tap coefficients * CONFIGURATION * 'FIXED I or 'FLOATING' point * Real: Single : Local: ORDER FILE LENGTH q * IIR filter order * * Number of data points processed * While loop variable * Single : Local: GAIN FACTOR Input Output maxpos maxneg * reciprocal of passband * * attenuation * * Filter input * * Filter output * * parameters needed for * * truncation subroutine * min * " * mant range * " * ace Isb * " * ace min * " * sh Array: * scaling factor used in * * fixed point truncation * 65 * * Local: y = of size ( 0 • • 100 , 0 • • 2 ) * nodes * u = of size ( 10 0 , 0 • • 2) * nodes * t = of size ( 100 , 0 • • 2 ) nodes * B = of size ( 100 , 0 • • 2) forward coefficier c = of size ( 100 , 0 • • 2) * reverse coefficier * See diagram at the end of this listing for a clearer descrip1 External procedures: LOG2 * calculates a scale factor used in fixed * * point truncation * TRUNCATE * Truncation subroutine to simulate * * for limited fixed and floating point * * chip configuration s * * This program must be linked to the relevant file in the * subdirectories. i.e. [.FLOATING]TRUNCATE .OBJ * [.FIXED]TRUNCINT .OBJ * [.NOTRUNC]TRUNCDUM.OBJ Begin : Get: TRUNCDATA. DAT : maxpos,maxneg,min,mant_range End get : ace lsb:=mant range * The value for mantissa range (in * -* floating point trucation) and accumulator lsb value * * (in fixed point truncation) are stored in the same * * location in file TRUNCDATA.DAT which contains the * * parameters needed to call the TRUNCATE subroutine * * See the notes on truncation for this simulation for * * more details * Get: CHIPCONF.MEM: CONFIGURATION Endget: If {CONFIG='FLOATING' ) then : ace min :=min else: ace min :=acc lsb End if: * For handling fixed point chips where accumulator wordlength * * exceeds some other register wordlengths * Get : FCOEFFS * Char variable containing name * * of file containg tap coefficients * * eg. MAIN DIR:IIRCOEFS .DAT * End get : Get : "FCOEFFS" : ORDER "FCOEFFS" : GAIN FACTOR 66 End get : ORDER=ORDER/2 CALL LOG2 (GAIN FACTOR,SH) * calculate a scale factor for TRUNCl CALL TRUNCATE (GAIN_FACTOR,maxpos*sh,maxneg*sh,min*sh,mant range * Represent gain factor in limited wordlength form * - k:=l While (q<=ORDER) * Read in filter coefficient s * do : Get: "FCOEFFS" : B (q,2),B(q,l) ,B(q,O) ,C(q,l) ,C(q,O) End get: * Truncate filter coefficients * End while : While (still input data samples remaining to be read) do : Get: MAIN DIR:FILTERIN.DAT: input - * read new sample into first delay element * End get : * It is assumed that the input is of limited wordlength * * If this is not so, insert a statement calling subroutine * * TRUNCATE here * If (there are more samples to be read from FILTERIN.DAT) then : file_length := file_length+l y (0,2):=input•gain factor Call Truncate (y (0,2),maxpos,maxneg,acc_min,mant_range) q:=l While (q<=ORDER) do : * IIR process * u (q,0):=-1 .0*C(q,O)*t (q,O) Call Truncate (u (q,O) ,maxpos,maxneg,acc min,mant rangE * High precision truncation (eg. 31-bit in TMS320J u (q,l) :=-l .O*C (q,l)*t (q,l) Call Truncate (u (q,1),maxpos,maxneg,acc min,mant rangE * High precision truncation (eg. 31-bit in TMS320J u (q,l):=u{q,O)+u (q,1) Call Truncate (u (q,l) ,maxpos,maxneg,acc min,mant rangE * High precision truncation (eg. 31-bit in TMS320J u (q,2) :=u (q,l)+y (q-1,2) t(q,2) :=u{q,2)+min/2.0 •turns truncation into rounding Call Truncate (t (q,2) ,maxpos,maxneg,min,mant_range) * Low precision truncation (eg. 16 bit in TMS320J Y(q,O) :=B (q,O)*t (q,O) 67 Call Truncate (y (q,O) ,maxpos,maxneg,acc_min,mant_rangE 68 * High precision truncation {eg. 31 bit in TMS320J y{q,l) :=B (q,l)*t{q,l) Call Truncate{y{q,1),maxpos,maxneg,acc min,mant rangE * High precision truncation {eg. 31-bit in TMS320 y{q,l) :=y{q,O)+y{q,l) Call Truncate{y{q,1),maxpos,maxneg,acc min,mant rangE y{q,2) :=B{q,2)*t{q,2) - - Call Truncate{y{q,2) ,maxpos,maxneg,acc min,mant rangE * High precision truncation {eg. 31-bit in TMS320J y{q,2) :=y{q,2)+y{q,1) Call Truncate{y (q,2) ,maxpos,maxneg,acc min,mant rangE * High precis ion truncation {eg. 31-bit in TMS320 : t (q,O) :=t{q,1) t (q,l) :=t{q,2) q:=q+l * z**{-1.0) process * End while : * end of IR process * OUTPUT:=y{ORDER,2)+min/2.0 Call Truncate{OUTPUT,maxpo s,maxneg,min,mant range) * Low precision truncation {eg. 16 bit in-TMS320 10) * Put : FILTER.DAT: OUTPUT End put: While (q<=ORDER) do : t{q,O) :=t{q,l) t {q ,1):=t (q ,2) q:=q+l End while : End If: End while : * output result * * z** (-1) process * * end of FILTERIN.DAT * 69 Put: " " file_length "data samples were written to file FILTER.DAT" " " " " End put: End: End program: *******************************************************************; * ** Diagram of the filter implemented * * * y ( q-1, 2 ) u( q , 2 ) t ( q , 2 ) y (q , 2 ) * o---->----o-------->-------0------->-------o---->-----o * I I B (q,2) I * I I I * V Z**-1 * I * u (q,1) I I I --------<------- ------->------- y (q,1) * o 0 o * I -C (q,l) I B (q,l) I * I I I * V Z**-1 * I * I I I * o--------<-------0------->-------o * u (q,O) -C (q,O) B (q,O) y(q,O) * ** The above shows a second-order subsystem of the cascade struct\ * implemented. ** The structure is identical to DOREDI structure 13 (in PROGRAMS * FOR DIGITAL SIGNAL PROCESSING, DSP Committee, IEEE, * IEEE Press, 1979) * Also see Oppenheim & Schafer: DIGITAL SIGNAL PROCESSING * page 152 Fig 4.16 *******************************************************************; 70 CHAPTER 8. IM PLEM ENTI NG FUNCTI O NS IN TH E SIM U LATI ON 8.1. Introd uct i on The DSP functions in the simulation are performed by the FORTRAN programmes. The user accesses these programmes by proceeding down the simulation menu structure until the specific function he requires is reached. All the menus were programmed in DCL. An example of a menu programme is SIM.COM. The POL listing of this programme was shown in chapter 3. Many more examples are contained in the programme listings . This chapter describes how a function is included in the simulation after the menu structure leading to the function has been defined. The first section describes the DCL functi onal proced ure on the bottom of the simulation structure hierarchy which calls the FORTRAN programme which does the actual signal processing. This is followed by a description of how the FORTRAN programme itself is included into the simulation environment . 70 s.2. Th e DC L Funct i ona l Proced ure s.2.1. Straightforward case A PDL listing of a shel l DCL functional procedure is given at the end of this chapter. The DCL coded version is included in the programme listings . The PDL lists the input files that it uses as well as the normal declarations . Its first action is to display the name and attributes of the chip currently active and ask the user whether he wishes to use this chip for that particular function . On a negative reply, the DCL procedure CHA NGD IR.COM (change directory) is called. CHANGDIR.COM displays the chip options available to the user and changes the default directory to the right subdirectory (i.e. the subdirectory which contains the version of the executable file that simulates the required chip) . Control is then returned to the calling DCL functional procedure . This procedure runs the executable file in the default (current) directory. It then assigns the name of the FORTRAN programme' s output signal data file to the logical name LAST. (This negates the need for the user to remember the names of the data files when running a sequential process.) 71 s.2.2. More complex case some of the simulation functions require inputs from the calling DCL procedure as well as from the normal sources (i.e. the user and the control data and text files). For example, the filter and Hilbert transform programmes need the name of the coefficient data file to be used. The functional DCL procedure used in this case is identical to the one described above apart from the following changes: 1. It asks the user for the name of the signal data file to be processed. This data file is then copied to a specific data file. For the FILTER function the name of this file is F I L T E R I N.D A T and for the HILBERT transformer it is H I L B E RT I N.D AT. (Obviously, in this case, the FORTRAN programme does not prompt the user for any information but reads it from one of the above data files). 2. Instead of running the FORTRAN executable file, the DCL procedure calls a DCL menu procedure which may call another DCL menu in a tree structure . The DCL menu on the bottom of the hierarchy gives the user a choice of filters (or Hilbert transforms), stating the 72 characteristics of each one. Depending on the choice, the procedure runs either the IIR or the FIR structure included in the simulation. The filter characteristics are achieved by giving the name of the appropriate fi l ter coeffi ci ent d ata fi l e. An example of this type of menu procedure is HI LBM ENU.COM. A POL listing is included at the end of this chapter. Note that the programmers are clearly shown how to include more options in the procedure . The procedure also gives the user the opportunity to specify his own Hilbert transform coefficient data file and/or run his own transform not yet included in the simulation . 8.3. Incl usi on of th e FO RTR A N Progr ammes The following is the procedure that should be undertaken when including a FORTRAN programme into the simulation environment: The FORTRAN programme should be written according to the guidelines and rules given in the last chapter . When it has been debugged and tested, the statement 73 calling the TRUNCATE subroutine should be inserted after every arithmetic operation as shown in that chapter . The programme should then be compiled to create an object file. The user must the run the "INC LUD E A FOR TR AN FUNC T ION " from the utility menu. This option runs the DCL command procedure INC LUD E .C OM which links the correct T RUNC A T E subroutine to the object file an stores the resulting executable file in the appropriate subdirectory. This is done three times, once for the fixed point configuration, once for the floating point configuration and once for the "no-truncation" (32 bit floating point ) case. After completion of the above procedure the FORTRAN function would have been properly included in the correct directories. All that would remain to include this as a function in the simulation would be to write the DCL menu structure to run the programme as indicted in the previous subsection . 74 * signal data file created * 8.4. POL L i sti n gs for th i s Ch a pter 8.4.1. FU NCTI O N.COM ********************************************************** * This is an example of what a DCL programme * * in the simulation should look like . To implement * * your function into the simulation, replace FUNCTI O N by * * the name of your programme . * ********************************************************** Procedure name : FUNCTI ON.COM ********************************************************** * DCL Procedure to handle this function. * * Include general comments about this procedure here. * ********************************************************** Input files: CHIPEXPL .MEM * description of default chip * Variables : Char : Global: LAST * logical name for the last * Local: MAIN DIR * logical name for the simulation* * directory normally in use * * ( [ADS .MENU] on the Fuchs VAX * External procedures : YN CONTINUE * "Y" or "N" * Begin: Put: form feed CHANGDIR.COM FU NCTI O N.FOR * Changes default directory * * FU NCTI O N •s executable progrc "DO YOU WANT THE DEFAULT CHIP TO BE USED? [Y/N]" "i.e" CHIPEXPL.MEM * TYPEs the file CHIPEXPL.MEM which contain * a description of default chip * " " End put: Put: "Y or N:" End put: Get: YN 75 End get: I f (YN = "N" ) then : Call CHANGOIR.COM End if: * Changes default directory * Run FU NCTI ON.FOR * FU NCTI O N •s executable program * Make MAIN DIR the default directory again * * MAIN DIR is the logical name for the normal simulation * * directory ( [ADS .MENU] on the Fuchs VAX ) * Default_dire ctory:= MAIN_DIR LAST := "FUNCTI ON.DAT" *logical name assignment* * The name and characteristics of the output data file should be * * given by the FORTRAN programme but information or instructions * * be given here if required. * Put : "PRESS RETURN TO CONTINUE: " End put : Get: CONTINUE End get: End: * Return to calling procedure * End procedure : 76 .. 8.4.2. P O L O F H I L B E RT.C O M Procedure name: HILBERT .COM ********************************************************** * Top of HILBERT TRANSFORM menu hierarchy * ********************************************************** Input files: CHIPEXPL .MEM * description of default chip * Variables: Char : Global: LAST * logical name for the last * * signal data file created * Local: MAIN DIR * logical name for the simulation* * directory normally in use * * ( [ADB.MENU] on the Fuchs VAX * FILENAME * Name of the signal data * * file to be transformed * External procedures: YN CONTINUE * 11 Y11 or "N" * Begin: Put : " " " ' " CHANGDIR.COM HILBMENU.COM * Changes default directory * * HILBERT TRANSFORM MENU * WHAT IS THE NAME OF THE DATA FILE YOU WISH TO HILBERT TRAN eg. SIGNAL" " " " " End put: Get: FILENAME End get: HILBERTIN.DAT := FILENAME.DAT Put: "Y or N:" End put : Get: YN * DCL COPY COMMAND * 77 End get: If (YN = "N") then: Call CHANGDIR.COM End if: * Changes default directory * C a l l H I L B M E N U.C O M * HILBERT MENU * LAST := "HILBERT .DAT" *logical name assignment* Put: "PRESS RETURN TO CONTINUE: " End put : Get: CONTINUE End get: End: End procedure: 78 8.4.3. PO L o f H I L B M E N U.C O M Procedure name: HILBMENU.COM ******************************************************************* * This DCL procedure is normally called by HILBERT .COM. * * It allows the user to choose from the hilbert transforms already* * included in the simulation, or to use his own hilbert transform * * coefficient s. * ******************************************************************* Variables: Integer: Single: Local: CHOICE Char : Single: Local: CHOICE2 LOGNAME FILENAME External programs : HILBERT .EXE IIRHILBERT .EXE * FORTRAN FIR program to do * * Hilbert transform * * FORTRAN IIR program to do * * Hilbert transform * Begin: Put: form feed "HILBERT TRANSFORM MENU " " II " 1 : 79 tap FIR Hilbert transform" " Bandwidth : 0.05 to 0.45 of sampling frequency" " maximum error (ripple) : 0.0000010 " " " 2 95 tap FIR Hilbert transform" " Bandwidth : 0.01 to 0.49 of sampling frequency" " maximum error (ripple) : 0.0217910 " " *" 3 Insert additional options here "* " " " 9 Your own Hilbert transformer" " " End put: Put: "CHOICE" 79 MAIN DIR:HILBERT79.FLT * End put : Get: CHOICE End get: Case CHOICE of: 1: Run HILBERT * FIR program Tap coefficients are * read * 2: Run HILBERT MAIN DIR:HILBERT95.FLT * from this file * * FIR program * * Tap coefficients are read * * from this file * * 3 : Add new transforms here . * * eg. Run IIRHILBERT * * MAIN DIR:FIRCOEFTS.FLT * * * * 8: etc. * * * 9: Put: form feed " Is it an IIR or IR structure?" " " " II " A IIR " II " " B FIR " " " " c Another transform program " " " " " " " " " " " " " 11 " 11 " 11 11 End put: Put: "CHOICE:" End put: Get: CHOICE2 End get : Put: 80 " " " " form feed " What is the name of the data file " " containing the filter coefficients ? " 11 eg. HILBERT79.FLT 11 II II II (Read the HELP MENU if you are not II II sure of the correct format .) II II II II II II II II II II II " II II II II II " II End put: Get: FILENAME End get : LOGNAME := MAIN DIR:FILENAME * DCL logical name assignment * Case CHOICE2 of: A: Run IIRHILBERT LOGNAME B: Run HILBERT LOGNAME * IIR HILBERT TRANSFORM * * LOGNAME:= input data file * * FIR HILBERT TRANSFORM * * c: Insert another Hilbert transform program here * * LOGNAME * End case: End case: end: End procedure: 81 CHAPTER 9. SIM ULATI ON FUNCTI ONS This chapter gives short descriptions of some of the functions presently available in the simulation . For more comprehensive information on the implementation and detail of a particular function, refer to the programme listings. 9.1. Uti l i ty Funct i ons This section describes some of the functions accessible from the UTILITY MENU. 9.1.1. Filters The implementation of the filter menu structure was explained in the previous chapter. Two filter programmes have been included into the simulation thus far. These are: 1. FI RFI LTER. FOR , which implements the "Direct form realisation of an FIR structure" [16], and 2. I I R F I LTER.FO R , which implements the "second order cascade IIR structure" [17]. This programme is a good example of 82 how a FORTRAN programme should be written for the simulation. If the user requires any other structures or an implementation that introduces scaling, he has the may write his own programme and run it from the filter menu, or (preferably) he may include it into the simulation structure as explained in the last chapter (and in the filter menu procedures). The filter programme s read their coefficients from the fi l ter coeffi ci ent d ata fi l e whose name is supplied by the calling DCL procedure. The format of the filter coefficient data file is given in the H ELP MENU. 9.1.1.1. Filter design A number of filter design programme s and techniques exist. An expert system described in [18] is a good aid in deciding which one to use . The two programmes used most commonly in the simulation thus far have been DOR ED I (19] and DFDP (20]. DOR EDI outputs the filter coefficients in the form required by the simulation. All that has to be done is to delete all the other unwanted documentation that gets written to the DOREDI output file. 83 D F D P outputs its data in a much less compatible form. The job of converting this file to the simulation format is made trivial by the FORTRAN programme D F D P C O N V , which may be run from the UTILITY function: "C O N V E RT A D F D P F I L E T O SIM U LATI ON FO RM AT" . 9.1.2. o;spl ay;n g t;me d oma;n s;q nal s The display DCL functional procedure is DISPLAY.COM. It runs the FORTRAN programme GRAFI X. The programme G R A F I X .FO R makes use of in-house library routines to display graphics on a CIT-101 terminal. This terminal can be configured as a VT-100 terminal or a TEK- 4014 terminal (graphics mode) . The input to G RAF I X .F O R is always a s;q n al d ata f;l e. The user may specify which portion of the signal he wants to see . This programme might have to be altered when porting the simulation to systems which have other terminals . Routines have already been written to allow the simulation to run on a PC which emulates VTlOO and TEK terminals (using an emulation software package called "SmarTerm 240" [21]). These routines may be made active by using the Utility function "SPECIFY TERMINAL TYPE (CIT-101 or ST240)". This 84 function must be run every time a different type of terminal is used when the simulation is run. 9.1.3. D i spl ayi n g spectr a The DCL functional procedure in this case is FFT.COM. It runs the FORTRAN programme F FT. F FT.FO R makes use of a library FFT subroutine from [22) to do a 1024 point FFT . The FFT is done on the last 1024 points of the input signal data file. This is done so that distortions in the first few samples in a data file caused by filter lag while the first samples travelling through the delay line are not processed. If the input signal data file has less than 1024 points, it is zero padded to bring the number of points to 1024. 9.1.3.1. Windows At present, the user has the choice of the following five windows : 1. Rectangular 2. Hamming 3. Hanning 4. Blackman 5. Triangular . (beta=0.8) 85 It is recommended that the Blackman or Hanning windows be used to see the full dynamic range of the spectrum. 9.1.3.2. Display Output The FFT programme determine the magnitude from the real and imaginary components returned by the subroutine . This may be displayed using either a linear or dB scale. The dB scale has a range of 100 dB. 9.1.4. Pl otti n g si g nal s The DCL procedure HARDPLOT. COM displays the PLOT M ENU. This menu gives the user the option of displaying time or frequency domain signals on the terminal by calling the DCL procedures mentioned in the last two sections . The only difference is that a hard copy is made of the signal displayed by calling the procedure PLOT.COM. The PLOT MENU also allows the option of displaying the last graphics display that had been shown. The HARDPLOT .COM procedure accomplishes this by simply calling PLOT .COM. 9.1.5. Br anc h i ng to V MS The simulation offers the facility to branch into the normal VMS mode. Control is returned to the simulation by typing "EXIT" . This is a useful feature for the more advanced user who is familiar with VMS . It has particular application for the user who is still busy developing his simulation 86 function, but has not yet included it into the simulation structure. 9 .1.6 . H ELP The HELP facility is controlled by the DCL procedure H ELP.COM. This procedure sets the default subdirectory to [.H ELP] , where it calls the help menu procedure H ELPM ENU.COM. [.H ELP] is the subdirectory where all the files needed for the help facility are stored. One of the facilities available from the help menu is an explanation of the format required for the filter coefficient data files. It is envisaged that this report will be subdivided and included under different options in the help menu . The above method of implementing the HELP facility was chosen in preference to the use of the VMS HELP "Librarian Utility" [23]. The above method is consistent with the structure of the simulation and allows easier porting to a system without a similar HELP utility. 9.2. Secon d ary Uti l i ty Funct i ons The user has the option to enter a second utility menu ("OTHER UTI LITY FUNCTI ONS") from the main utility menu. This 87 menu is stored in U T I L I T Y 2 .CO M . The following sections briefly explain the functions available from this menu. 9.2.1. The d ec;mat;on men u The user has the option of three decimation routines: 1. Decimation by "throwing away" the unwanted samples. This method reduces the sampling frequency and the number of samples. 2. Setting the unwantd samples to zero. This preserves the number of samples, but introduces replicas of the signal around multiples of the decimated sampling frequency. 3. Simulating a sample-and-hold circuit by setting the D-1 samples that follow every Dth sample equal to that sample . {D=decimation factor) . 9.2.2. Inter pol ati on The I NT E R P O L AT E function in the simulation inserts ( 1- 1) zeros between every sample . {I = interpolation multiple) . This results in the sampling frequency being increased I times. Replicas of the signal appear around the sampling frequency. 9.2.2.1. Al ter i n g the si m ul at;on par ameters 88 After a decimation or interpolation process which changes the sampling frequency and length of the signal data files, the user is asked whether he wishes to alter these si m ul ati on para meters to the new values . on a positive reply, the control d ata fil e, SIMP A RA M.DAT, is overwritten with the correct values. 9.2.2.2. F i l teri n g w.r.t. sam pl i n g r ate transform ati on The filtering function normally associated with decimation and interpolation must be done by the user as a separate step by entering the FILTER MENU. An example of the advantage of leaving this function up to the user is that he is able to simulate SSB and DSB/SC modulation by inserting zeros and then putting the resulting signal through a bandpass filter. 9.2.3. H i l bert Transfor mati on The Hilbert transform (90 degree phase particular relevance to radio design when quadrature modulation techniques. shifter ) has dealing with The Hilbert transforms implemented in the simulation thus far use FIR structures [24]. Provision has been made for the use of IIR structures. Implementation is done in a similar 89 manner to that of FIR and IIR filters with the exceptions of different input and output signal data file names . 9.2.4. M ul ti pl i cati on b y a real tone This option gives the user the opportunity to multiply his signal with one of two quadrature tones. Output data is written to either COSMULT.DAT or SINMULT.DAT, depending on the option chosen. 9.2.5. M ul ti pl i cati on b y a com pl ex tone This function multiplie s the input signal by both quadrature tones and writes the output to COSMULT.DAT (In-phase channel) and SINMULT.DAT (Quadrature-phase channel) . 9.2.6. Ad d i ti on The user has the option of adding or subtracting two signals . The output is written to SUM.DAT. 9.2.7. Ad d i n g a tone to a si g n al This function enables the conversion of a DSB/SC signal to an AM signal. 9.3. Terti ar y Uti l i ty functi ons 9 0 The user has the option to enter a third utility menu "EV E N M O R E U T I L I T Y F U N C T I O N S ") from the secondary utility menu. This menu is stored in U T I L I T Y 3 .CO M . The following sections briefly explain some of the functions available from this menu. 9.3.1. Renam;n g s;gnal d ata f;l es Sometimes ambiguity might exist in the names of the signal data files. This might occur in a quadrature modulation simulation where identical functions are happening in both channels . For example, if in a quadrature modulator, both channels have to be filtered, two different FILTER.DAT signal data files would exist. The "CH A N G E N A M E O F D ATA F I L E " option provide s a way for distinguishing between the two FILTER.DAT files. In the above case the user would be presented with the option of changing the name of the last FILTER.DAT file created to either : 1. FILTER.DAT 2. QFILTER.DAT 3. any other name (In-phase channel) (Quadrature-phas e channel) 9.3.2. Ad d;n g noi se to si g nal s The NOISE menu is activated by the N O I SE .CO M DCL procedure. This menu gives the user a choice of a number of noise 91 distributions . (At this stage, only gaussian shaped noise has been implemented, but it is clearly shown how to include other distributions into the menu .) If gaussian noise is chosen, control is passed to the procedure GAUSS. COM which runs the FORTRAN programme GAUSS which generates gaussian noise of the required amplitude and adds this to the specified input signal data file. 9.3.3. Other Uti l i ty Functi ons Other utility functions such as "INCLUDE A FORTRAN PROGRAMME" and "CONVERT A DFDP FILE TO SIMULAT ION FORMAT" have been discussed elsewhere in the simulation. Note that space has been left for the inclusion of even more utility functions . The programmer is clearly shown in the PDL and DCL 1istings of UTILITY3.COM I how and where to include these functions . 92 CHAPTER 10. TRA NSM IT l R EC EI V E PATH STEPS Apart from the step which has already been described ("ENTER SIMULATION PARAMETERS" ), a number of other steps exist. The steps basically consist of menus implemented in the tree or a combination of the tree and linear-tree structures (modulation and demodulation) . 10.1. Creati n g Si g nal s This step gives the user the generating signals to be processed during the simulation . The step consists of the CREATE MENU which currently has two options . In the one option, the user has the opportunity of creating multitone signals using the sampling frequency defined in the simulation . The user chooses the wordlength of the signal to be created. The other option allows him to simulate "analogue" signals . This is done by creating the signal using a multiple of the simulation defined sampling frequency and a 32 bit floating point precision . 93 10.2. Sam pl i n g Si g nal s This step allows the simulation of the sampling an "analogue" signal. It does this by choosing only the appropriate samples from the "analogue" signals , or by simulating the effect of a sample-and-hold circuit. 10.3. A m pl i fi cati on Men u This step presents the amplification menu . The menu currently gives the user the option of simple amplification and amplification related to the input signal level (Automatic Gain Control) . 10.4. Aud i o Processi n g Men u This tree-structured menu allows the inclusion of audio processing functions such as: Pre-emphasis De- emphasis Speech processing etc. The pre- and de-emphasis programmes have been implemented using the bilinear z-transform. Detailed information about audio processing simulation is given in (11]. 94 10.5. Mod ul ati on/D emod ul a t i on Many modulation schemes may be simulated by using the utility functions . However, the user may be guided along a particular modulation path by calling the required utility functions from the path. The paths constituting the different modulation methods were implemented using the linear-tree structure mentioned in section 3.4.3. An example of the use of this method is given in the next chapter. A number of different modulation schemes have been implemented in this way. Detailed information is given in [12]. 95 CHAPTER 11. EX A MP L E OF SIM U LATI ON USAG E 11.1. Introd ucti on This chapter gives an example of a few of the abilities of the simulation. The block diagram of figure 11.1 shows the sort of simulation that may be undertaken by the user . 11.2. Ex pl anat i on of Bl ock Di a g ram 11.2.1. Transmit Path Processing done in the transmit path could consist of :- 1. "Analogue" signal generation (actually a digital signal generated at a higher sampling frequency and precision) . 2. Simulation of A/D effects. 3. VOGAD (Voice Operated Gain Amplifying Device) . 4. Speech processing. 5. SSB modulation (eg. using the filter method. ) 96 SSB 'Jcitodul at:ori (ptias.ng !l!ethod) 01ot 4. ©1------1I Transmit pnth SPEECH Plot 1. SSB 14oaulat ion (F Her 'llethodl i- - - - - - - - - - - - - l I l =>----1 PROCES5!NG 1-----4 NTEFPOLATE FILTER ! - - - - - - - -· ------------ I Dlot 2.a Channel menu A i---------- G4USS AN NOISE !IT!R"!!PING TONE Ilf IJU.ar SIOE!!AICI Ill wa :Jlr.igth i - - - - - -- ---- -- - - -- - -- - - --- -- - - -- --- --, Re "? .ve path ------! I "'ILTER DECIMATE OEUY I Plot 5. 1 -- -1 "'!LTER !lEC!MAiE HllllEm TRANSFO'N - - - - - - - - - - - - - - - - - - - - - - ·- - - - - - - - - - - - - - - SPEE"1 llqQCESS!NG 1-- --[:::> -...o_._1A , --) Figure 11. 1 ; 81ock diagram of an example of a s mu1ation process 11.2.2. Channel Menu The signal could then be put through a gaussian noise channel and an interfering tone in the image sideband could be added. 11.2.3. Receive Path The user may choose to amplify the signal, put it through an SSB demodulator eg. (using the phasing method), do some speech processing and simulate the effects of a D/A converter. Plots of the FFTs of the signal data files observed in the above simulation are given at the end of this chapter. 11.3. Examol e of Si m ul ati on Process Space does not permit the showing of the whole simulation process here. What will be shown is how a user would implement a particular modulation process ie. SSB modulation using the filter method (indicated in Fig. 11.1). The user 98 would enter the modulation menu. This would give him a choice of SSB, AM, FM and Data Modulation. He could then choose the SSB modulation option which would present him with a number of SSB modulation techniques. Upon choosing a technique he is presented with a description of the technique . He is then prompted to do the correct functions to implement the techniques. He always has access to the utility menu which allows him to display the processed signal at any point . An indication of how the user would see this process is contained in the next few pages, followed by plots of the graphics the user would see. 99 UTILITY MENU 1: FILTER 2: DISPLAY A SIGNAL 3: DO AN FFT ON A SIGNAL AND DISPLAY IT 4: BR ANCH TO THE V MS OPER ATING SYSTEM 5: OTHER UTILITY FUNCTIONS < HILBERT TRA NSFOR M ETC.> 6 : HELF' 7: PLOT A SIGNAL ON THE PLOTTER a: GO ON TO THE NEXT PART OF THE SIMULATION < A MPLIFY/A 9: R ETUR N TO M A IN CALLI NG MENU CHOICE: 9 T .'. A NSM I T !='A T H 1: ENTE!=\: SIM U:_ AT I0N PAR A METERS ( e 7: EXIT FROM TRANSMIT PATH s: CALL UTILITY M ENU < Flt er s , FFT'<..::. D i sP l a'::' r o•Jtiries ,1 9: EXIT FROM TRA NSM IT MENU CHOICE: 5 MODUL ATION M NU CHOOSE ONE OF THE FOLLOWING MODUL ATION SCHEMES 1: SSB 2: A M 3: FM 4: DATA < MODEM > CHOICE: 1 SSB MODUL ATION MENU CHOOSE ONE OF THE FOLLOWING SSB MODULATION SCHEMES 1: Phasin9 and inter olation 2: Inter pol ate and fil ter CHOICE: 2 Th is secti on of the simul ati on r om ts ou to simul ate a specific modulation technique. To· tr - out mor e gener al techni ques, use the UTILITY M ER U functions The method used b this section is to inser t zero's a band l im ited i nut,thus incr easi ng the samp l i ng frequency The new si nal should then have r el icas ar ound the ol d sampl ing fequenc . If an SSB fi l ter is placed ar ound one of one ·Of the r el icas sidebands an SSB signal shoul d be obtai ned < Note: This is a var iation of the fi lter method commonl used i n anal ogue SSB r adios, wi th the var iati on that - inter polation is used instead of multi pl ication Pr ess R ETUR N to conti nue •• •: The first functi on r equir ed is to inter ol ate the signal Do you want to: 4: INTERPOL ATE A SIGNAL 5: ENTER THE UTILITY M ENU 6: CONTINUE WHICH CHOICE! 4 What is the name of the fi le i n which ou wish to inser t zer os eg. SIGNAL EMPHASIS INT RPOLATI ON MULTIPLE 7 eg. 6 means 5 zeros wi l l be i nser ted between sampl es < i.e. 6 times as many sampl es as befor e) 4 The i nter ol ati on r ecess changes the ar ameter s < Sampl ing frequency and sample length) of the simul ati on The new val ues should be i nser ted into fi le SIMPAR A M.DAT to keep the simulati on r unning smoothly The sam pl i ng frequenc should be changed from 14400.00 to 57600.00 The lenth of the data files should be changed from 1536 to 6144 Do ou wish this to hap en? C Y/N J y INTERPOL ATED SIGNAL IS STOR ED IN FILE INTPOLA TE.DAT The first function r equir ed is to inter bol ate the signal Do you want to: 4! INTERPOLATE A SIGN AL 5: ENTER THE UTILITY MENU 6: CONTI NUE WHICH CHOICE: 5 . UTILITY M ENU 1 : FILTER 2: DISPLA Y A SIGNA L 3: DO A N FFT ON A SIGNAL A ND DISPLAY IT 4: BR ANCH TO THE V MS OPER ATING SYSTEM 5! OTHER UTILITY FUNCTIONS < HILBER T TRA NSFOR M ETC. > 6: HELP 7: PLOT A SIGNAL ON THE PLOTTER 8: GO ON TO THE NEXT PART OF THE SIMULATION 9: R ETUR N TO M A IN CALLI NG MENU CHOICE: 3 What is the narue of the i nut fi le to be FFTed eg. SIGNAL LAST WI NDOW 1! RECTA NGUL AR 2: HA M MI NG 3: HAN NING (RA ISED COSINE> 4!BLACKM A N S: BARTLETT < TR IA NGULA R) 4 1: LINEA R 2!dB SCALE 2 FFT APPEA S ON GR APHICS SCR EEN PRESS R ETUR N TO GO TO CALLING MENU: UTILITY MENU 1: FILTER 2: DISPLAY A SIGNAL 3: DO A N FFT ON A SIGNAL AND DISPLAY IT 4! BR A NCH TO THE V MS OPER ATING SYSTEM 5: OTHER UTILITY FUNCTIONS < HILBERT TRA NSFOR M ETC. > 6: HELP 7: PLOT A SIGNAL ON THE PLOTTER B: GO ON TO THE NEXT PART OF THE SIMULATION 9: RETUR N TO M AI N CALLI NG MENU C H O I C E : 8 The f i r st funct i on r eui r ed is to inter pol ate the si nal Do ou want to: 4: INTERPOLA TE A SIGNAL 5: ENTER THE UTILITY MENU 6! CONTI NUE W H I C H CHOICE: 6 The n x t functi on r euir ed is to fi lter the si nal s to r emove r epl icas of the signal Do ou w a n t t o ! A: F ILTER A SIGNAL B: ENTER THE UTILITY MENU C! CONTI NU E O PT I O N A WH AT IS TYE N A M OF THE DATA FILE YOU WISH TO FILTER ej + S GNA L. F ILEN A ME: INTPOlATE DO YOU W ANT THE DEFAULT CHIP TO BE USED? C Y/N J i.e 16 bit fix ed poi nt wor d lenth eg. TMS 320, TMS320C25, ADSP-210 0 Y o r N: Y FILTER MENU 1 LOW PASS 2 HIGH PASS 3 •• BA ND PA SS < SSB TYPE> 4 BAND PASS (AM TYPE) 9 Your own fi lter CHOICE: 3 i:- I '-· T E R M &:. N U 1 14th or der El l i ti c Band ass fi l ter Desiqned to be USB fi lter w i th nom i nal car r i er at 8 kHz and sam l i nd fr ed uenc of 40 kHz. 0.02 Passband r i ple; 46 dB st6pand sup!::' r esslon. 2 14th or der El l i ti c Band Pass fi l ter Desi gned to be LSB fi lter· with nom inal carr ier at 16 kHz a n d sam l in freuenc of 40 kHz . 0.02 Dassband r ipple,-46 dB stoand s1..1 pPr ess1on. 3 10th or der El l i tic Band ass fi lter Desi gned to be USB fi l ter with nom i nal carr i er at 10 kHz and sam l in fr euenc of 40 kHz 0.02 assband r i Ple.-46 dB stoand supPr ess i on . · · · 4 Other SSB fi l ter s C HO I C E : 4 5 10th or der El l i tic Band a s s fi lter Desi ned to be LSB fi lter wi th nom i nal car r i er at 14.4 kHz and samDl ing frequenc of 57.6 kHz. 0.4 dB Passband r ippl , 20 B cir r i er suPDr ess1on , 40 dB at car r i er + 400 Hz, 58 dB at· arr ier 600 Hz and greater. · 9 Your own fi l ter CHOICE: 5 6144 d ata sam les wer e wr i tten to fi l e FILTER.DAT LAST IS NOW DEFINED AS FILTER.DAT 0 R ESS RETUR N TO CONTI NUE The nex t function r eui r ed i s to fi l ter the signals to r emove r epl icas of the signal Do o•J want to: A: FILTER A SIGNAL B: ENTER THE UTILITY MENU C: CONTI NUE OPTION: C UTILITY M ENU 1! FILTER 2: DISPLAY A SIGNAL 3: DO AN FFT ON A SIGNAL AND DISPLAY IT 4: BR ANCH TO THE VHS OPERATING SYSTEM S: OTHER UTILITY FUNCTIONS < HILBERT TR A NSFOR M ETC > 6: HELP 7: PLOT A SIGNAL ON THE PLOTTER B: GO ON TO THE NEXT PART OF THE SIMULATION < A MPLIFY/ 9: R ETUR N TO M AIN CALLING MENU CHOICE: 3 What is the naffi e of the input fi le to be FFTed e . SIGN A L U ST !.J I N DO W .,.,. . HA M MING :t. : RECTA NGULAR 3: HA NNING < RAISED COSINE> 4!BLACKM AN C"·•. BA RTLETT < TRIA NGULAR > 4 1: LINEAR 2 : dB SCALE 2 FFT APPEA RS ON GRAPHICS SCREEN PRESS R ETUR N TO GO TO CALLING MENU: - = - - :c c:> C> CCI c:> CT. c::> I c::> c::> l- o -J a.. - - 0 :> .D "'T") 0 0 c:ri C) co -0 N ..... 0 _J 0 0.. - - - - .· : :c c::> cc::o> N <::> c:::> c:::> QC c::> 0 CD c::> 0 0 IQ ("I") N 0 0 cc 0 I I t- 0 ...J C> Q_ c:> - r- ! 'c:» C\J C.-.>. 0 0 CD C> 0 $ rr> 0 0 c:> 0 ":"" 0 M 0_, 0 a. - - N :I: c:> c:> cc c:> I cr:.>o I -I -. :c c:> C) er. Lt') c:> N c::> I I t-- 0 _J a.. co "'O CHAPTER 12. CO NC L USI O N A structure for a computer simulation which is an effective aid for the design of a DSP radio has been presented. A number of different structures were investigated, and the form chosen for the simulation was presented. It was explained how the structure permits the simulation of DSPs with differing wordlengths and configurations . The initialisation and control of the simulation were explained and it was shown how a function should be included into the structure. Brief descriptions of the functions already included in the simulation were given, and an example of how the structure and its functions are used was shown. The needs of the simulation users and programmers were met by designing a user friendly, understandable, flexible and easily expandable structure. Advantage was taken of the serial nature of radio processing to do this with a structure with a well defined DCL implementation in the top part of the hierarchy, and the functional level programmed in a high level language . One of the advantages of the structure implemented is that it separates the user interface from the actual processing. (i.e. it allows the user to develop his high level language separate to the simulation and include it once it has been debugged.} 113 Although the simulation as presented is in a highly usable form, there are a number of improvements and alterations that could be included. Some of these are: 1. A 11 ow i n g t h e e v e n e a s i e r r e t u r n t o t h e 1 a s t f u n c t i o n e x e c u t e d . Since the simulation allows the easy simulation of different word configurations, the user might wish to return to the previous function and re-execute it with a different configuration, thus easily comparing the effects of the two configurations . (This ability already exists within the modified linear-tree structure, but it may be enhanced by introducing small changes to the structure and the utility menu. 2. G r e a t e r e r r o r t o l e r a n ce . If the user inputs an illegal value into a FORTRAN programme, the programme may crash. When this happens the simulation terminates. This could be avoided by employing certain programming techniques to trap the programme in an error condition . DCL also has some functions that could be used to allow the simulation to continue after a programme crash. 3. S i m u l a t i on o f w o r d l e n g t h s g r e a t e r t h a n 32 b i t s . The simulation's FORTRAN programme s specifically use s i n g l e p r e c i s i o n (32 bit) real numbers . This was done purposely 114 to allow the easy and quick simulation of 32 bit floating point DSP chips, which are expected to become increasingly prolific. However, the disadvantage of this approach is that it limits the simulation to chips of 32 bits and less. At this time, it is felt that the approach adopted was the correct one for the current DSP scenario . However, should any chips of a higher precision become desirable to use, it would be necessary to alter the FORTRAN programme s to have double or quadruple precision real numbers . 4. T h e u s e o f b e t t e r 1 /0 t e c h n i q u es . The use of techniques to speed up the reading and writing of data files could be investigated. When very big files are handled this could be advantageous . However, one would have to be wary of placing more than the bare minimum of restrictions and rules on the high level language programmers. 5. U s e a t r u n c a t i o n F U N CT I O N . It might have been neater to make the TRUNCATE subroutine a FORTRAN "Function" instead. 6 . A f i l e r e co r d i n g t h e n a m e s o f t h e s i g n a l d a t a f i l e s c r e a t e d i n t h e o r d e r in w h i c h t h e y we r e c r e a t e d • This would give a greater sense of continuity to the user. 115 7. Cat a l og ues accessible from the help menu containing: a. Commonly used signal data files (eg. Audio speech signals, SSB signals, etc.) b. Descriptions of the filters available simulation. in the etc. a. The use of commerci al software as a gra ph i cs "front end " for the si m ul ati on. Although the simulation already has adequate graphics facilities, these could be enhanced by using a software display package such as "DADiSP" to display the signals with more versatility. It would be possible to include a feature such as this as a function accessible from the utility menu. 9. The i ncl usi on of a PR BS g ener ator a nd d i g i ta l mod ul ati on and d emod ul ati on functi ons (QPSK, FSK, etc.) to ena bl e the si mul ati on to be used for d ata as wel l as voi ce transmi ssi on. The simulation structure has been specifically designed to allow the inclusion of these functions as well as other analogue modulation functions 116 such as frequency modulation. 117 None of the above points would be very difficult to implement. If I were to redo this project, I would probably include most of the above points, but the greatest difference would be that I would try to remove the simulation from the restrictive VAX environment with only DCL and FORTRAN available . I would probably do it on a PC, possibly using a more structured and friendly languages (eg. Pascal or C) . Another idea for the future might be to write a PDL-to-DSP machine code compiler. This would enable the user to finalise his algorithms at a high level and automatically compile them into DSP code. No formal testing of the simulation software has been done, but it has been extensively used and any problems noticed have been rectified. Every programme and procedure has been used, and because of the nature of the structure, their dependence on each other is minimal. The simulation has been used to investigate a number of sampling, audio processing, modulation and demodulation techniques, both by the author and designer of the simulation structure [10-12], as well as by a new DSP_ 118 engineer who has recently arrived on the DSP radio project [25,26] . His reaction to the simulation has been very positive . He has found it clear and easy to use and has already begun to implement some functions into the structure . An effective tool for aiding DSP designers in developing a DSP radio has been developed. It is expected that the effort put in designing the simulation structure will bear fruit when a DSP radio is presented in the not too distant future . 119 R E F E R E N C ES 1. K.-D. Kammeyer, R. Mann and w. Tobergte, "A modified FIR Equaliser for Multipath Echo Cancellation in FM Transmission", IEEE Journal on Selected Areas in Communications, volume SAC-5, number 2, pp. 226-237, February, 1987 2. D.J. Bagwell and V. Considine, "Digital Signal Processing Architectures for HF Receivers", Third International conference on HF Communication Systems and Techniques, 26-28 February 1985, pp. 86-88 3. D.T. Anderson and J.W. Whikehart, "A Digital Signal Processing HF Receiver", Third International conference on HF Communication Systems and Techniques, 26-28 February 1985, pp. 89-93. 4 . A. Jongepier, "A digital International Conference on 1984, pp. 180-181 FM-detector", IEEE Consumer Electronics, 5. ILS Signal Processing Software, Signal Technology Inc., 5951 Encina Road, Goleta, California, USA. 6. "DADiSP", DSP Systems, 1 Kendall Square, Cambridge, MA 02139, USA 7 . "DSPlay", Burr Brown, International Industrial Park, Tucson, Arizona, USA. Airport 8. M.W. Coetzer, "The FUN DSP System", University of Stellenbosch, Stellenbosch, 7600, South Africa. 9. A.J .A. Carter, "A General Development System for Digital Signal Processing Microprocessors", Fifth South African Symposium on Digital Signal Processing, 6 July 1987. 10. A.O. Bassios, "DIGITAL BASEBAND: Report on work done on Simulation", Fuchs Electronics, P.O. Box 57, Alberton, December, 1986 120 11. A.D. Bassios, "DIGITAL BASEBAND : Simulation of Audio Processing", Fuchs Electronics, Alberton, April 1987. 12. A.O. Bassios, DIGITAL BASEBAND : Report on simulation of SSB and AM Modulation, Fuchs Electronics, July 1987. 13. "Guide to Using DCL and Command Procedures on VAX/VMS ", Digital Equipment Corporation, Maynard, Massachusetts, USA, September 1984. 14. A.J. Walker, "Structured Information Processing system Design, Department of Electrical Engineering, University of the Witwatersrand, Johannesburg, June 1986. 15. c.c. Watterson, J.R. Juroshek and w .o. Bensema, "Experimental confirmation of an HF channel model", IEEE Transactions on Communication s Technology, COM- 18, 792-803, 1970. 16. A.v. Oppenheim and R.w. Schafer I "DIGITAL SIGNAL PROCESSING, Prentice-Hall, Englewood Cliffs , 1975 I pg 156 . 17. A.v . Oppenheim and R.w. Schafer I "DIGITAL SIGNAL PROCESSING" I Prentice-Hall, Englewood Cliffs, pp 152. 18. A. Woermann, N.M. Bawden and H.E . Hanrahan, "Use of a Knowledge-based Expert System in the Selection of a Digital Filter Design Method", Fourth South African Symposium on Digital Signal Processing, 27 June 1986. 19. G.F. Dehner, "Program for the Design of Recursive Digital Filters", Programs for Digital Signal Processing, DSP Committee, IEEE, IEEE Press, 1979 20. "Digital Filter Design Package", Atlanta Signal Processors Inc., 770 Spring St., Atlanta, USA. 21. "Smarterm 240", Persoft Inc. , Madison, Wisconsin, USA, 1986. 2740 Ski Lane, 12 22. G.D. Bergland and M.T. Dolan, "Fast Fourier Transform Algorithms", Programs for Digital Signal Processing, DSP Committee, IEEE Press, 1979, pp 1.2- 1 to 1.2-18. 23. "VAX/VMS Librarian Reference Manual", Digital Equipment Corporation, Maynard, Massachusetts, September 1984 24. L.R. Rabiner and R.W. Schafer, "On the Behavior of Minimax FIR Digital Hilbert Transformers", The Bell Technical Journal, Vol. 53, No . 2, February 1974, pp 363-391 . 25. M.W. Robson, "Digital Signal .Processing Applied to HF Radio", Fuchs Electronics, Alberton, July, 1987. 26. M.W. Robson, "DIGITAL BASEBAND Report on the simulation of AM demodulation, Fuchs Electronics, to be presented September 1987. 12 APPBBDIX A THE TRUBCATIOB PROCESS The truncation process in an integral and important feature of the simulation . It enables programmers to easily simulate the effects of chips at different wordlengthe and fixed and floating point configurations. The truncation data needed by the truncation subroutines used in the simulation is originally created by the FORTRAN programme TRUHCDATA. The limits of the truncation process are then written to the data file TRUNCDATA. DAT. The subroutines in the simulation then use the data read from TRUNCDATA. DAT to do the truncation . This appendix explains the calculation of the limits CTRUBCDATA programme) and the use of the limits to do the actual truncation for both fixed and floating point. FIXED POINT TRUNCATION Initialisation The maximum possible positive value of the 2 s compliment word is: 21 and the maximum negative value is: -2b 1 where b = number of bits per word Generally, fractional arithlletic is used with fixed point configurations. This means that all values are referenced to the value 1.0. i.e. 2b is taken to represent the value 1.0. Therefore, the value of the least significant bit < LSB> is: = 2-< b-1 ) The maximum positive value a word may have is: 1-2-< b-1 ) and the maxi mum negative value is: -1.0 The programme TRUNCDATA. FOR asks the user for the wordlength of a single precision register of the chip to be simulated as well as the wordlength of the accumulator < which generally has a higher precision> . The maximum possible positive and negative values and the value of the LSBs are then calculated for both cases and written to the data file TRUICDATA.DAT . ii The Truncation Process The programme that wishes to do the truncation then reads the data from TRUBCDATA.DAT . Every time the programme wishes to truncate a number, it passes these parameters to the truncation subroutine < TRUBCATE> . This subroutine then checks to see whether the number falls within the limits. If not it writes an "OVERFLOW'' message to the terminal and limits the number to the maximum allowable value. If the number falls within limits, it is truncated by dividing the number by the LSB, truncating all points to the right of the decimal point and then multiplie s by the LSB again. The truncated number is then returned to the calling programme. 3 FLOATING POINT TRUNCATI ON Initialisation Floating point configurations do not fractional arithmetic, but they also arithmetic . require the use of use 2 s complement The Exponent The exponent is a fixed point number. positive value it can be is: The maximum and the maximum negative value is: -2 P The Mantissa As the mantissa is a fractional fixed . point number similar to that explained in the previous section: The maximum positive value is: 1-2 -< m-1) The maximum negative value is: -1. 0 where m = no. of mantissa bits . 4 The exponent is automatically adjusted by the chip so that the first mantissa bit set after the decimal point is set. Therefore, :mantissa value is 0 . 5 . apart from zero, the minimum Therefore, the :maximum positive value of the floating point wod is: ( 1-2 - C: m- 1> ) , ( 2P-1) The maximum negative value is: <-1. 0).{ 2P-1) The minimum positive value is: ( 0 , 5 ) , (2-P) The minimum negative value is: - ( 0 , 5 ) , ( 2 -P) Where m = number at mantissa bits , and p = number of exponent bits . The maxima and minima are calculated by TRUBCDATA.FOR and written to TRUBCDATA. DAT, along with the value 2m- 1 < the inverse of the value the LSB, called the mantissa_range> . The floating point truncation subroutine then uses these parameters to check if the input value to be truncated is within bounds . I f it is, the truncation process starts: 5 The :mantissa is separated from the exponent. If is then multiplied by the mantissa_range <2m- 1) , and the digits to the right of the decimal point are truncated. The process is then reversed to obtain the original number which has been truncated to a-bit mantissa format. The truncation programmes and subroutines may be examined in the programme listing. 6