A Java–based Server/Client Architecture that Enables Undergraduate Usage of Complex CAD Tools 1 Samuel H. Russ, Dan Linder, Jonathan Robinson, Robert Reese, and Ben Blalock Department of Electrical and Computer Engineering and Microsystems Prototyping Laboratory Mississippi State University {russ, linder, reese, blalock}@erc.msstate.edu,
[email protected] A Manuscript Submitted to IEEE Transactions on Education Abstract –– Undergraduate electrical engineering education can be made more effective by exposing students to the types of computer–aided design tools that are used in industry. Often these tools are complex and expensive, making their use difficult, distracting, and possibly unrealistic for resource–poor institutions. A Java–based system to provide distributed electronic CAD services has been adopted in the classroom at Mississippi State. Named JavaCADD, it is able to overcome these obstacles by providing remote, simplified access to complex tools. Its architecture and pedagogical impact are assessed and discussed. Key Words: Education, Java, Client/Server, Worldwide Web, Computer–Aided Design, Digital Design
I. Introduction, Survey of Existing Systems, and Background Electrical engineering education is attempting to produce graduates that can function successfully in the modern engineering environment. Rapid changes in the engineering environment, and in the ability of communications technology to deliver information efficiently, have created a need for rapid changes in engineering education. The use of Java–based delivery of information, in particular, opens up new possibilities for the classroom. A. Web–based Educational Paradigms The World–Wide Web has emerged as a very popular means of delivering educational materials. Because of the Web’s ability to display hypertext, animation, and simple software routines, it can deliver information interactively and remotely. It has become a primary tool for the delivery of distance learning and even more advanced educational paradigms that use the Web will certainly emerge over time. A complete survey of the Web in education is well outside the scope of this paper. The key point is that the Web’s ability to deliver and display information remotely and interactively makes it a popular tool for education. (More information about the subject can be found in the latest proceedings of the Frontiers in Education (FIE) conference and the ASEE annual conference [1].) B. Java–based Architectures More recently, the Java programming language has emerged as an introductory object–oriented language for classroom use and as a means of delivering educational products over the Web. In the former case, its simplicity and rigorous typecasting has made it a promising choice for programming education. In the latter case, its flexibility and portability have made it an attractive choice for delivering educational software. For example, educators at the University of Toledo have used Java to develop and distribute educational software [2]. Its ability to support interactive animations have enabled 1
This work was funded in part by DARPA/ARO Grant No. DAAG55–97–1–0345, NC State Subcontract No. 97–1034–03. 1
educators at Syracuse University to develop modules usable in not only college environments but also for K–12 education [3]. In both cases, Java is being used as a portable, readily delivered programming language, and the software and courseware modules are coded in it and delivered over the Web. A more ambitious approach is to use Java’s ability to provide a client/server model so as to give collaborators a means of interacting and controlling remote simulations. The TANGOsim environment at Syracuse University has been developed for this purpose [4]. This paper introduces another, slightly different use for Java––as a means of providing a graphical user interface to control the remote execution of sophisticated CAD tools. The simplifying effect of the interface and the ability to run jobs remotely are the features needed for classroom use of the tools. C. Electronic CAD in the Classroom Modern computer engineering is increasingly being conducted by using software–based computer–aided design (CAD) tools. These tools can be used to design and test digital logic, lay out circuit boards, and design integrated circuits. In computer engineering education, the role of CAD tools is in a state of flux. One reason is that there is a considerable range of tools available for use, offering varying degrees of sophistication and cost. Some packages are designed to be simple, and appear to be aimed at introductory–level digital courses. For example, Electronics Workbench by Interactive Image Technologies, Ltd. offers basic digital and electronic schematic capture and has support for “virtual instruments”, computer displays that emulate familiar lab equipment such as oscilloscopes and logic analyzers [5]. B2 Logic by BeigeBag Software offers similar digital capabilities [6], and their B2 Spice package offers analog capabilities [7]. These packages do not offer a back–end that permits mapping onto programmable logic, as they are intended to simulate older small–scale–integration logic. Another set of packages are supplied by programmable logic vendors. Xilinx Foundation software [8] and Altera MaxPlus II software [9] are examples. These packages only support digital logic and typically support only one vendor’s hardware. MaxPlus supports both schematic and language–based logic entry. Vendor–supplied software typically only supports one brand of hardware for implementation. Both of these types of packages, educational and vendor, have low unit costs, which are intended to be borne by students. Costs are on the order of textbook costs, which may be an obstacle to some students. More sophisticated software packages are used for commercial design and/or for integrated circuit design. Some public–domain packages are available, primarily for upper–level chip design classes. One well–known example is the Magic toolset originally from Berkeley and now from Digital’s Western Research Lab [10]. Finally, several commercial packages are intended for use by engineers. Examples include Powerview by Viewlogic [11], Synopsys logic synthesis [12], the tool suite from Mentor Graphics [13], and tools from Cadence [14]. These are complex and full–featured. They are traditionally centrally licensed, and so the costs are borne by the university. As one might expect, they can be quite expensive as well. (Note that Viewlogic also has a less expensive, student–purchased student edition and a University program [15].) The differences between the student, vendor, and commercial software packages are interesting and significant. Some of the lower–end packages, such as the student version of Viewlogic, are identical to more complex commercial packages, but with key features disabled or limited. Some of the vendors seem to regard the software as something they can literally give away, probably in the hope that it will spur sales of their product, but others charge significant amounts for it. The high–end packages provide support for complete commercial–quality design. The Mentor and Cadence suites, for example, include both integrated circuit and circuit board design tools. While a 2
complete discussion of how to select software is outside the scope of this paper, it is sufficient to say that selection of a system for a particular class can be difficult. Whether or not a commercial system can be maintained at a university can be a complex issue. For example, institutions may have to maintain the software as part of ongoing research obligations, and so classroom use can, in effect, be subsidized. Note that, since the licensing of these packages is “floating” (i.e. that some number of people can be using the product at the same time), the classroom use of the tools does not affect the researchers who need it. For smaller universities, however, this is not an option. Another critical issue is that of ease of use. Educational software does not have all of the features of commercial software, but that also makes educational software easier to use and, arguably, more appropriate for introductory classes. The simpler software does not confuse students with features they literally are incapable of understanding. More complex software may blunt the pedagogical impact of basic digital principles. D. Mississippi State’s Computer–Aided Digital Design Class A traditional solution to the “ease of use” issue is to introduce less complicated educational software early in the curriculum and work up to more complicated commercial software later in the curriculum. This is the approach taken at Mississippi State University. In the two introductory digital classes (basic digital devices and microprocessors) very simple packages are used. The emphasis is on the basic digital principles. The third class in the digital sequence is called “computer aided digital design” and it represents a mini–capstone in their course sequence. This class is abbreviated CADD. (In the following discussion, “CAD” will refer to computer–aided design in general and “CADD” will refer to the specific Mississippi State class.) CADD unifies all of the concepts in digital design they have learned to that point, introduces them to complete, complex computer design and engineering, and introduces them to a commercial software package (Powerview) in which to do design. This is the first class in the digital and computer engineering sequence that is not required for all electrical engineers, and so the students are exclusively ones that have chosen to specialize in digital design and/or computer engineering. The class is offered as a split–level class, and graduate students from other schools (especially from foreign schools and from non–traditional backgrounds) enroll in the course in their first semester because of the exposure to commercial tools and industry–style digital design. Before Spring 1998, the class used Viewlogic’s logic synthesis package to do language– based digital design. The older Viewlogic synthesis tool, “vhdldes”, used a modified version of the VHDL synthesis language. (VHDL is one of two widely accepted hardware description languages that are used to specify the design of digital logic. Such languages are commonly used in industry because they are a hardware–independent way of designing digital logic and can be “retargeted” to different implementation hardware structures as the design evolves.) While vhdldes was easy for students to use (only one Unix command line, with two simple command–line arguments), it did not expose them to complete, industry–standard VHDL. (It used non–standard types for signals and buses, and it did not permit the use of generics and packages.) Also, it did not have a graphical user interface (GUI). Because of the limitations of vhdldes, and because Viewlogic began to phase it out, it was decided to switch to ViewSynthesis, Viewlogic’s new logic synthesis package. Two issues immediately arose––it called for a series of Unix commands, with arcane, easily misunderstood command– line arguments, and it had no GUI to simplify its use. E. An Architecture to Address the Issues During the same time period, Mississippi State’s Microsystems Prototyping Laboratory had finished the development of a tool that offered remote access to CAD services as part of a larger research program [16]. As discussed below, it was intended to provide a new model for doing inte3
grated circuit design, in which the design tools would actually remain resident at the institution (company or university) where the tool was maintained and users would submit work to it remotely. It became clear that this same model would support classroom use of complex CAD tools. Students could submit work “remotely” (across campus) without having to become fluent in the arcane details of the software itself. This software package, named JavaCADD, replaced the logic synthesis package in the CADD lab experiments and became the primary tool for logic synthesis. The purpose of this replacement was to present students with a very simple interface for logic synthesis. A GUI replaced a tedious series of command lines. Since the actual logic synthesis is being done remotely, it becomes clear that this model can also be adopted to provide complex CAD services to resource–poor institutions. Thus this became a demonstration of methods to overcome the two primary limitations of using complex commercial software in a classroom setting. After a discussion of the JavaCADD package itself in section II, the results of this usage are discussed in section III.
II. JavaCADD’s Architecture A. Background and Intended Uses The original goal of the project was to make ECAD services available to outside users without having to grant the users full login privileges. The basic reason for doing so is to support user populations whose members either change rapidly or are not known ahead of time. One example is students in classes that change on a semester basis. Another reason for doing this is that the ECAD design tool can remain resident where it is written or maintained, and so maintaining, upgrading, modifying, and extending the tool is simplified, as only one copy of the tool has to be changed. There are two approaches to providing these types of distributed services. First, Web–browser–based access to services can be used. In this approach, a browser is used to access the service interface and a WWW–server is used to execute the service. One problem with this approach is is that the browser is limited in its ability to access the local file system for security reasons. The user either stores files on the system where the server resides or manually transfers these files between the local and remote file system. Email services can be setup to make this easier, but it is difficult to achieve a seamless capability. Important advantages of browser–based services include ease of implementation and portability of the client–side interface. Such a system is illustrated in Figure 1. This web–browser approach was initially taken in a first–generation ECAD services implementation [17]. However, the file–passing limitations created a need for other approaches, and so a custom client/server architecture was selected to replace the web–browser model. Custom client/server architectures offer the utmost in flexibility. There are several candidate client/server protocols and data transfer options to choose from, and a recent addition is Java Remote Method Invocation (RMI). RMI has two advantages. First, since it is Java–based, both the client and server are portable because of Java’s operating–system independence. Second, it provides a very sophisticated data packing mechanism that allows complex objects to be passed between client and server with minimum programmer effort. These two advantages led to the choice of this approach for implementation [18]. The resulting JavaCADD system is illustrated in Figure 2. Note that all of the complexities of reading and transferring files, as well as of running the CAD programs, is completely hidden from the user. Two Java applications make up the JavaCADD architecture – the client and the server. Their internal construction is designed to support this “remote services” style of computing. Since both are written in Java, they can, in theory, be run on a variety of platforms. The client GUI, for example, has been used on both PC’s and Unix workstations by students in the CADD lab. The server requires more operating–system–specific attributes, such as local file access and the ability to spawn new 4
tasks. While the server has been tested under both Unix and Windows NT, only the Unix version of the server was used in the CADD lab. B. Server Construction The function of the server is to accept task requests from the client, perform some action to resolve the task request, and then return results to the client. The task request includes a set of parameters passed using Java Remote Method Invocation (RMI). A parameter may include a stream of data representing a compressed set of files. The details of the design of the property file (which specifies how requests are to be serviced), and of the properties that are recognized by the server, may be found in [18]. While the Java portion of the server is OS–independent, the method for spawning external tasks is OS–dependent, and a configuration file is used to specify how this is accomplished for a particular operating system. Typically the server begins by creating a uniquely named temporary directory for files and then runs a shell script to do the actual processing. The shell scripts supported for logic synthesis place the results in a single subdirectory, which are then compressed and returned to the client. Further details about the processing and return of results may be found in [18]. C. Client (GUI) Construction The JavaCADD client is a Java GUI for remote task invocation built upon the capabilities of the JavaCADD server. At startup, the JavaCADD GUI contacts the server for the contents of a special property file that tells the client which tool services are available on the server. This information is then displayed in a local window as shown in Figure 3. The user selects a tool and clicks “Launch Tool” to cause the JavaCADD client to query the server for the GUI–specifics for that tool. Once the tool information has been returned, the JavaCADD GUI customized for that tool will appear. This is an important feature––the GUI for the application is actually downloaded on demand, and so can be changed without having to modify the client. The window for ViewSynthesis logic synthesis is shown below in Figure 4. Note that new tools can be supported on the server side, and access to the tool and its custom GUI can be obtained immediately on the client side. That is, adding support for new tools on the server side does not require any changes on the client side, and so new tools can be added very quickly. For example, when it became clear that ViewSynthesis was needed by the CADD class, support for it was added in a matter of days. There is no limit to the number of active tool application windows; there can be multiple JavaCADD launch windows present, each connected to a different server if desired During execution of the server, a tool application window will be opened on the client machine that allows the user to monitor the progress of the task. The user also has the ability to kill the task at any time. An example is shown below in Figure 5. The tool property file for a JavaCADD GUI tool service not only describes the JavaCADD GUI for the tool, but also determines what parameters will be passed to the server ’s tool script during execution. Two properties apply specifically to sets of files that are passed between client and server. First, any properties of type “FileField” are passed as compressed Java GZIP streams. It is the responsibility of the task script (not the server) to uncompress these streams. Second, the JavaCADD GUI looks for a special key called “results.zip” in the returned hashtable from the server. The value of this key is treated as a ZIP stream and unzipped into the results directory specified by the user. Any other keys found in the returned hashtable are echoed by the JavaCADD GUI to the “log” window. Note that access to local files is the reason that the client is a Java application and not an in– browser Java applet. A complete description of these and other property attributes is found in [18].
III. Educational Impact of Actual Usage 5
A. First Impressions Discussions with the students and with the lab’s teaching assistant provided the first feedback on the system. Besides uncovering a few minor bugs (such as students’ use of unexpected ways to specify pathnames), it provided a window into how students interacted with JavaCADD. The most immediate realization was that the students thought of the GUI as actually doing the logic synthesis. This was surprising at first, but obvious in hindsight. The GUI is the only part that they “see”, with which they have any interaction. That the files are actually being sent over the network to a remote server is not obvious. In fact, in student lab reports, some of them actually talked about “JavaCADDing” VHDL files, turning the name of the package into a verb. This may not be good English, but it is an indication of the extent to which JavaCADD became their interface to logic synthesis. For students at this level, this is actually an indicator of success. The purpose of the class is to teach how logic synthesis fits into an overall design strategy, and not to teach how logic synthesis is done. The situation is analogous to an introductory programming class, in which details of how the compiler works are essentially irrelevant. The students write a VHDL file and submit it to JavaCADD. Some time later the appropriate output files return, all in the correct places, and so they naturally come to think of the local GUI as doing all of the work. It is the seamlessness of JavaCADD that leads to this conclusion. This led to another interesting result––students blamed all of the problems, including the degree to which error message were cryptic, on JavaCADD. In fact, students had to be convinced that their VHDL codes were at fault, as they preferred to blame JavaCADD for the error. One suspects they were likelier to mistrust JavaCADD because they knew it was a newly written, experimental piece of software. Another subtle indicator of success is that the course’s lab teaching assistant used JavaCADD in research work during the same semester. This is an endorsement of the ability of JavaCADD to conduct “actual” logic design. B. Survey Results Rather than relying exclusively on anecdotal evidence of success, a survey of students was taken. Conducted in anonymity, it provided a way for them to offer more tangible and more specific feedback on JavaCADD. It should also be noted that the alternative to JavaCADD, the complicated command–line interface, had to be explained to them since they had never used it and so that they could make a meaningful comparison. The text of the survey is shown in Appendix 1. The survey results are summarized below. There were a total of 20 responses, which was about 87% of the class enrollment. Recall that all of the students in this class are either computer engineering students or electrical engineering students specializing in digital systems. 14 were undergraduates with senior standing and 9 were graduate students (mostly masters–level). When asked how they prefer to learn new software, 50% preferred to learn about the internal details as they go, and 40% preferred to learn a minimal amount and just use it. This seems to indicate that hiding the complexity of CAD software is preferred by the students, although JavaCADD hides the internal details completely. 80% of the students said that using commercial software, as opposed to educational software with less features, was essential or very important. Likewise, 75% said that learning complete, industry–standard VHDL was essential or very important. This indicates that measures to deploy commercial software and methods in the classroom are well–received by students, who appreciate the benefits of using commercial methods. Recall that the purpose of switching to ViewSynthesis was to provide industry–standard VHDL to the students without using a distracting, complicated interface. 55% of the students had access to a PC at home, and 55% said that the ability to use or access software from home was preferable (not necessarily the same 55%). In the latter case, 25% also said 6
that home access was essential or very important and 20% said it was unimportant. One assumes that PC ownership will rise, but student enthusiasm for home software use was less than expected. Only three students tried to use it at home by running the JavaCADD client on their home PC, and one was successful. JavaCADD itself received very favorable reviews, with 95% rating it as “very easy” to use or “easy once I learned it”. (30% said very easy and 65% said easy once learned.) All of the students gave it an “extremely good” or “pretty good” rating, with 55% rating it extremely good. Interestingly enough, most of the students (60%) said that a GUI was only “preferable” over a series of commands. Only 35% indicated that a GUI was “essential” or “important”, which were the categories that were expected to be more popular. Using a GUI to replace a command–line prompt was preferable, but the alternative was not as unappealing as expected. 85% of the students gave it good marks for reliability, with only 15% rating it “occasionally unavailable”. The question was worded to exclude cases in which the local CADD lab was down, as that is not a function of the JavaCADD system. Unavailability was due either to a network disconnection to the research center (where the JavaCADD server resided) or to the server itself being down. The latter occurred more frequently than normal because file and mail servers were being changed at the research center during the semester. Most of the students additional comments were either bug reports or suggestions for improvements. Some of the comments were complimentary. For example, one student said, “I was glad there was a fairly easy way to synthesize everything.” Another said, “I greatly prefer it to the command line method. I already know way too many command line switches.” Many “bug reports” involved a specific problem. The original server–side script would continue to run a fixed sequence of processing steps even after an error had occurred. This had the side effect of burying the first, actual error message deep inside the application output, making diagnosis of the fault tedious. This became a significant human–factors issue, as students had difficulty fixing problems in their VHDL script. This was compounded by the fact that the error messages themselves are often cryptic, but this is a shortcoming in ViewSynthesis itself. It should be added that the error messages are significantly less cryptic than those in Viewlogic’s earlier synthesis environment. This early issue was fixed on the server side by stopping additional processing once an error had occurred, making the error message the last one in the application output window. C. Other Classes During the Fall 1997 semester, JavaCADD was also used in Mississippi State’s VLSI Systems course, a graduate–level course which requires extensive use of standard cell place and route and Synopsys synthesis tools in numerous projects. JavaCADD may be introduced into Mississippi State’s split–level VLSI I course, particularly for lab exercises introducing standard cell place and route methods and techniques. It is expected to benefit the class since JavaCADD will buffer the students from superfluous details, such as changes in environment variables and setup scripts. These details often seem to distract the students from the actual premise of the lab.
IV. Conclusions A system to provide remote access to complex CAD services was adopted for use in a split– level electrical engineering laboratory setting. Intended to provide a simpler interface into a complex software package, the tool was able to provide services remotely. Surveys and conversations with students indicate that the package was well–liked and easy to use. In classes where it is appropriate to hide the internal complexities of tools from students, such as introductory classes or classes where the tools are only a small part of an overall learning experience, this system has been shown to be successful in providing simplified access to the tools. 7
The system is very easily modified and extended, because the centralized–services model permits rapid changes to the services provided. The Java client is able to automate sending and receiving files, lending the process a high degree of seamlessness, and can display messages as the files are processed. Both the client and the server are portable among Unix and Windows computers. The model of using a Java application linked via Java RMI back to a central server is an interesting one for educational purposes. First, it hides software complexity from students, permitting the class to focus on the pedagogical purpose that underlies the use of software. That is, freed from the distraction of learning the details of a particular tool, students can devote more time to learning and applying principles. Second, with appropriate arrangements among universities and industry partners, it may become a model through which resource–poor institutions can have access to industry–standard tools and methods for their laboratories.
V. References [1]
Proceedings of the 1997 ASEE Annual Conference, June 15–18 1997, Milwaukee, WI, USA, ASEE,Washington DC USA, 1997.
[2]
J. A. Reed, A. A. Afjeh, “Using Java to develop educational engineering software”, Proceedings of the 1997 ASEE Annual Conference, June 15–18 1997, Milwaukee, WI, USA, ASEE,Washington DC USA, 1997.
[3]
S. Warner, S. Catterall, and E. Lipson, “Java simulations for physics education”, Proceedings of the 1997 Conference on Java in Science and Engineering Simulation, Dec 16–17 1996, Syracuse, NY, USA, found in Concurrency: Practice and Experience, vol. 9 no. 6, Jun 1997, John Wiley & Sons Ltd Chichester Engl, p 477–484.
[4]
L. Beca, G. Cheng, G. Fox, T. Jurga, K. Olszewski, M. Podgorny, P. Sokolowski, K. Walczak, “Java enabling collaborative education, health care, and computing”, Proceedings of the 1997 Conference on Java in Science and Engineering Simulation, Dec 16–17 1996, Syracuse, NY, USA, found in Concurrency: Practice and Experience, vol. 9 no. 6, Jun 1997, John Wiley & Sons Ltd Chichester Engl, p 521–533
[5]
http://www.interactiv.com
[6]
B2Logic 3.0 User’s Manual, Beige Bag Software, Ann Arbor MI, 1998. http://www.beigebag.com.
[7]
J. Englebert, L. Meuller, H. Bui, and T. Nguyen, B2 Spice Version 2 User’s Manual, Beige Bag Software, Ann Arbor MI, 1998.
[8]
D. Van den Bout, The Practical Xilinx Designer Lab Book, Prentice–Hall, Upper Saddle River NJ, 1998. See also http://www.xilinx.com/products/software/software.htm.
[9]
http://www.altera.com/html/products/maxplus.html
[10]
http://www.research.digital.com/wrl/projects/magic/magic.html
[11]
http://www.viewlogic.com/products/index.html and http://www.viewlogic.com/about/educov.html
[12]
http://www.synopsys.com/products/products.html
[13]
http://www.mentor.com/index.html and http://www.mentor.com/products/index.html 8
See also
[14]
http://www.cadence.com/software/software.html
[15]
R. J. Duckworth, Workview Office Student Edition: Schematic Entry and Digital Analysis, Prentice–Hall, Upper Saddle River NJ, 1997. Also see http://www.workviewoffice.com/ WVOffice/.
[16]
L. Geppert, “IC Design on the World Wide Web”, IEEE Spectrum, Vol. 35, No. 6, June 1998, pp. 45–50.
[17]
R. Reese and D. Linder. “A Generator–Based Standard Cell Library using Mentor ICGEN”, Mentor User Group Meeting, October 21–23rd, 1996.
[18]
D. H. Linder, R. B. Reese, J. Robinson, and S. H. Russ, “JavaCADD: A Java–based Server and GUI for Providing Distributed ECAD Services”, Mississippi State University Technical Report No. MSSU–COE–ERC–98–07, May 1998.
9
VI. Appendix 1: JavaCADD Survey This is a survey of the JavaCADD software package, the GUI you use to do VHDL (logic) synthesis. Filling it out will help us see how well the software works and will give you a chance to suggest improvements. There are some background questions on here as well that will help us see how JavaCADD fits into the CADD class and our curriculum in general. Needless to say, this survey won’t affect your grade, so feel free to tell us your honest opinions! Also, if there are questions you don’t want to answer, then don’t answer them; that is OK. Background Questions 1. When given a chance to use a new software tool, would you prefer to _____ a. learn everything about it all at once _____ b. learn about the internal details as you go _____ c. learn only a minimal amount and just use it 2. How important is it to you that you use some of the same type of software that is used in industry, as opposed to “educational” software with less features? _____ a. Essential _____ b. Very Important _____ c. Preferable _____ d. Not Important 3. How important is it to you that you be able to access or use software at home? _____ a. Essential _____ b. Very Important _____ c. Preferable _____ d. Not Important 4. Do you have a PC at home? _____ a. Yes _____ b. No JavaCADD Questions There are two alternatives to JavaCADD that probably weren’t explained in class. Alternative 1 is a single–command program that uses a special, modified version and subset of VHDL (as opposed to JavaCADD’s industry–standard VHDL). Alternative 2 is to hand–enter a series of cryptic commands into a Unix command line prompt. 5. How important is it to you that you use complete, industry–standard VHDL? _____ a. Essential _____ b. Very Important _____ c. Preferable _____ d. Not Important 6. How important is it to you that you use a single GUI window to do logic synthesis as opposed to typing a series of commands at a command–line prompt? _____ a. Essential _____ b. Very Important _____ c. Preferable _____ d. Not Important 10
7. How easy was the software to use? _____ a. Very easy _____ b. Easy once I learned it _____ c. A bit of a struggle _____ d. Very difficult 8. If the machines in the CADD lab were up, was it always available? _____ a. Available always _____ b. Almost always available _____ c. Occasionally unavailable _____ d. Seemed to take frequent breaks 9. Did you try to use it at home, and did it work? _____ a. Did not try it at home _____ b. Tried at home and used it successfully _____ c. Tried at home and was not successful 10. What overall rating would you give it? _____ a. Extremely good and helpful _____ b. Pretty good _____ c. OK to fair _____ d. Bad –– should be abandoned Additional Comments and Suggestions:
11
VII. Drawings and Figures
Web Server (CGI Script) Web Browser
CAD Programs and Features
Local User
Remote Host
Files sent separately ahead of time
Files
Figure 1: Web–browser–based Remote Services Architecture Input files (Compressed)
Java–based Server (using RMI) CAD Programs and Features
GUI (Java Application)
Results
Local User
Remote Host
Files Figure 2: JavaCADD’s Java–based Remote Services Architecture
12
Figure 3: Initial Window of JavaCADD. Note that the tool list is updated dynamically.
Figure 4: The ViewSynthesis GUI Window. In this example, it has successfully completed the synthesis of two VHDL files into a single logic block. 13
Figure 5: The Application Output Window. Updated as the tool runs remotely, it provides immediate and detailed feedback on the status of the tool, including error messages.
14
