- Email: [email protected]
Distributed collaborative design of IP components in the TRMS environment
Microelectronics Reliability 46 (2006) 1019–1024 www.elsevier.com/locate/microrel
Research note
Distributed collaborative design of IP components in the TRMS environment K. Siekierska a, P. Fras´ b, A. Kokoszka a, T. Kostienko b, N. Ługowski a, D. Obre˛bski a, A. Pawlak b,*, P. Penkala b, D. Stachan´czyk b, M. Szle˛zak b b
a Institute of Electron Technology, Al. Lotniko´w 32/46, 02-668 Warszawa, Poland Collaborative Engineering Laboratory, Institute of Electronics, Silesian University of Technology, Akademicka 16, 44100 Gliwice, Poland
Received 18 October 2004; received in revised form 11 July 2005 Available online 21 September 2005
Abstract A methodology, an application scenario and a new system enabling collaborative distributed design have been presented. The system based on Tool Registration and Management Services (TRMS) constitutes the core of the engineering collaborative infrastructure that has been deployed in the distributed design of intellectual property (IP) components. The system assures information security (including user authorization, data and transfer encrypting), communication through firewalls, remote administration of users and tools, and some support for distributed inter-organization workflows. Ó 2005 Elsevier Ltd. All rights reserved.
1. Introduction The broadband access to the Internet enables closer collaboration of distributed teams. This new networkbased engineering paradigm referred to as collaborative engineering [3] is still a young field of research with challenges related to integration of dispersed engineers and their tools [7,9,11]. Profound changes in the engineering paradigm call for new design methodologies that will leverage on the engineerÕs ability to access globally to necessary resources. The last is especially promising as enabling technology for new methodologies for system-
* Corresponding author. Tel.: +48 32 237 2986; fax: +48 32 237 2225. E-mail address: [email protected] (A. Pawlak).
on-a-chip (SoC) designs based on reuse of intellectual property (IP) components. The note presents a new system for integration of dispersed tools enabling distributed collaborative design of IP components. Problems, like: construction of a collaborative network even across firewalls, tool integration assuring consistency of design data formats, and application of appropriate standards, had to be addressed. Internet-based collaborative environments for applications in electronic design automation (EDA) have been a target of academic R&D since a decade. The examples of the most relevant academic solutions are: WELD [2], REUBEN [10], ASTAIÒ [1], MOSCITO [12], and JavaCAD [4]. It should be noticed that, despite many research efforts, including those mentioned above, widely accepted Internet-based tool integration technology is still not available. Furthermore, the existing distributed collaborative engineering infrastructures do
0026-2714/$ - see front matter Ó 2005 Elsevier Ltd. All rights reserved. doi:10.1016/j.microrel.2005.07.118
1020
K. Siekierska et al. / Microelectronics Reliability 46 (2006) 1019–1024
not sufficiently support such requirements, like intellectual property protection, information security (including user authorization, data and transfer encrypting), communication through firewalls, support for distributed inter-organization workflows, and remote administration of users and tools. This note briefly demonstrates advantages of deployment of the new system to collaborative design of IP components. The system based on Tool Registration and Management Services (TRMS) that has been developed by the EU IST E-Colleg project [5] allows integration of remote tools and crossing of firewalls transparently. In TRMS, tools once registered, provide their services to distributed design teams. Advanced service discovery technologies connect to the most appropriate service with respect to optimal availability within the current configuration of the collaborative network. A dedicated workflow for IP design is explained after an overview of the TRMS functionality.
2. Methodology and scenario for collaborative design of IP components The term collaborative design is used with regard to realisation of complex designs of micro-systems or SoCs performed by a geographically dispersed group of engineers. A distributed work environment is quite common nowadays. The Internet is a medium that can significantly improve collaboration in such a distributed setting. The collaborative design methodology provides mechanisms supporting work of IP designers, as well as engineers responsible for integration of the final design. From the IP component designerÕs point of view, the most important is an easy access to design data and tools that are made available by the system integrator. For an SME that can hardly afford expensive design tools, the possibility of remote use of tools provided by a cooperating company, is of a great advantage. Since the IP protection is an essential issue, the collaboration platform has to provide mechanisms for secure tool invocation and data exchange between partnersÕ LANs protected by firewalls. 2.1. Collaborative IP design scenario The note focuses on a part of collaborative work related to design of IP components. Although, design of a complete digital system can involve a number of designers dispersed across different locations, the particular component design methodology based on HDL (VHDL, Verilog or SystemC) and RTL synthesis, is generally the same as in the case of on-site design [8]. However, the established collaborative environment enables a designer to perform some design processes with the use of remote
EDA tools. The scenario of a collaborative IP component design is shown in Fig. 1. While RT-level design modelling and simulation should be done with local tools, the rest of the design process can be performed remotely. The main design phases in ASIC and FPGA cases are described below as either local or remote operations. 2.1.1. Local simulation Each designer should have an HDL simulator (client 1/2 in Fig. 1) available locally, as a graphical output of a simulation cannot be sent in practice by the network. There are many HDL simulators on the market, and the cost of some is not too high. The analysis of simulation results, based on the text format information, like signal values snapshots only, which can be easily interchanged by a network, is very uncomfortable in a real design, especially in the early phase of a design, when the architecture of the component is often changed. A designer has to view waveforms in the debugging phase of a new developed HDL code to verify its correctness. Textual simulation results are generated for the final verified version of the IP component to be compared later with simulation results of the related post-synthesis or post-implementation structure, performed remotely. 2.1.2. Remote synthesis and simulation As a synthesis tool cost is much higher than the cost of a simulator, it is reasonable to share synthesisers in a collaborative network (in accordance with the license agreement). Logic and RTL synthesis, in a selected standard cell ASIC library or FPGA library, of a developed component can be performed on a remote machine (Tool Server in Fig. 1). It allows to check if the code is synthesisable and thus to choose the optimisation conditions after analysis of the synthesis reports. The postsynthesis simulation is done in the case of an ASIC target technology. It has to be performed remotely, because HDL simulation models of all standard cells included in the selected ASIC library are a part of the Design Kit located at the synthesis tool ownerÕs site. The simulations with the use of the developed previously test-benches give results written to text files. The results in the text format can be easily compared with the final simulation results of the HDL source code. If they are functionally equivalent the IP model is validated. Data transfer on both sides (Fig. 1) is restricted to text files– HDL files (IP models and test-benches) and synthesis scripts are being sent from client 1/2 to the Tool Server, and synthesis reports and simulation results are being resent. 2.1.3. Remote implementation and simulation Final design phases performed in the case of FPGA after synthesis—mapping, placement and routing,
K. Siekierska et al. / Microelectronics Reliability 46 (2006) 1019–1024
1021
Fig. 1. Collaborative design of an IP component.
generation of back-annotated files for simulation and a bit-stream file for implementation into a selected device—can also be done remotely. A designer can validate his IP component by means of post-implementation simulation using the generated back-annotated HDL model and SDF file (Tool Server in Fig. 1) and the previously developed test-benches, and in the following, comparing its results with the related HDL source code ones. The implementation report provides a designer with valuable information about timing and area parameters of the developed IP synthesised under selected optimisation constraints.
3. TRMS system The TRMS system [6,9] is built upon the Tool Registration and Management Services. It enables remote tools invocation, assures secure transmission of data generated by the invoked tools, as well as management of user rights to access specific tools. TRMS includes support for transformation and registration of new tool definitions. TRMS uses the native XML database for storing tool definitions. The TRMS client has a powerful
Windows-based GUI that allows efficient, user friendly management of tools and users registered in the environment. Through this GUI it supports a designer in establishing a distributed design environment to solve a particular design problem. A designer does not waste time to write long tool configuration scripts. Instead, he can login through the TRMS client to the system in order to find the required tools. In the next step he can build a workflow that suits his particular design task. With TRMS the best available tools can be deployed to solve a design problem, following the most appropriate design methodology. The configuration of a distributed design environment is highly reusable, as all information and design configurations are stored as XML-files. The TRMS system can be used in different engineering domains. This note briefly shows how an EDA engineer, e.g. an IP designer, can use TRMS to facilitate the design process with remote tools and the workflow technology. 3.1. TRMS architecture The TRMS system is made up of the three main components: the Global Tool Lookup Server (GTLS), the
1022
K. Siekierska et al. / Microelectronics Reliability 46 (2006) 1019–1024
Fig. 2. The main components of the TRMS architecture.
Tool Server (TS), the client (a TRMS client-side application). A network topology of these components is illustrated in Fig. 2. The core of the architecture constitutes the GTLS (Global Tool Lookup Server). It fulfils a management role of the whole TRMS integration environment. GTLS enables tools sharing and their integration in a dynamic and secure way. The GTLS is responsible for registration and storage of data on users, their privileges, their public keys, a configuration of the system elements and information about available tools, their definitions and their physical network locations. A registered user who wants to find and invoke a certain tool has to know only the GTLS serverÕs IP. After corrected authorization he can find the tool and its definition on the GTLS without knowledge where the tool is physically located. If the user has enough rights he can invoke the tool based on its definition. Every exchanged message between the GTLS and the client is encrypted and signed by using a pair of asymmetrical keys. An authorized centre with a public keysÕ repository is placed on the GTLS. The Tool Server (TS) controls usersÕ access to tools and enables their remote invocation/lunching. Every host which wants to make its tools available through the Internet in a secure way makes it via the TS. The TS as an integral part of the TRMS environment connects with the GTLS in order to check usersÕ permissions, their public keys, and verify a set of the permitted parameters for launching tools. Messages exchanged between the TS and the GTLS are also encrypted with a public key and signed with a confidential private key. The last component is a GUI application on a client side. The all operation throughout the TRMS environment such as: logging to the GTLS, launching tools, defining toolsÕ workflow and managing the GTLS server (registering tools, registering users, defining toolsÕ parameters, etc.) is done by means of a visual Java GUI. The GUI has different views: for GTLS and TS administrators, and for an ordinary user. In a general case, all the TRMS components are on separate machines connected to the Internet. A TRMS
massages transport is realised as the HTTP/SOAP communication protocol. All exchanged data are encrypted and digitally signed by a sender. If necessary, the TRMS can use the Advanced Network Transport Services (ANTS) [11] mechanism for transporting data to hosts behind firewalls. The ANTS mechanism developed by C-Lab within the E-Colleg Project is a SOAP-based web service that enables routing of data through gateways and firewalls. The system has been developed on the Java platform with commonly available technologies and tools, like: UML, XML, SQL and Web. A new XML-based technique for integration of remote tools which provides the semantics of the communication layers has been defined for TRMS [14]. 3.2. TRMS functionality 3.2.1. Tool registration A user needs appropriate permissions in order to be able to register a tool in the global TRMS repository. During the registration process of a new tool an engineer fills in the form that describes the tool and its parameters. To simplify this task easy to use dialog boxes are available. A user has to choose one of the existing Tool Servers. 3.2.2. Tool search Upon search a designer gets the list of tools, availability for invocation, short descriptions, and related keywords. If the tool attributes satisfy design requirements, the tool can be parameterized by choosing the options and arguments, redefining input/output, and invoked separately, or included into the design workflow. TRMS has a common dialog box for searching information on tools, tasks, and workflows. 3.2.3. User management Each designer has to be registered in GTLS by the TRMS administrator. After generation of keys for authorization, a designer can login into the environment and check for needed tools. TRMS employs user management based upon a group system. A system admin creates a group of privileges to perform certain operations on tools, users, Tool Servers, etc. This approach enables easy control of usersÕ rights and is adaptable to the requirements of collaborating engineering teams. The Tool Server offers further control of access to the tools available on a particular machine. 3.2.4. Workflows In case a designer knows which tools he needs, he should be interested in integrating them into a workflow. Creation of the workflow is straightforward in TRMS– GTLS. A designer simply chooses particular tools and parameterizes them in the same way as in the separate
K. Siekierska et al. / Microelectronics Reliability 46 (2006) 1019–1024
use described above. He must only remember to match the inputs of the tool with the outputs of the preceding one. The tools in the workflow can be invoked manually or automatically, which accelerates the design process. Once created, a workflow can be exported to an XML file and reused in a different application.
4. IP component design workflow The collaborative IP design process (Fig. 1) was divided into two main parts: the local one containing the local IP HDL code development and simulation tasks, as well as the remote one comprising the synthesis and implementation tools. Since the IP modelling and the local simulation are usually performed completely in the used by a designer graphic integrated design environment, there was no need for the local tools integration into the TRMS workflow. The outputs of the local tools, the HDL model and synthesis scripts, were passed as inputs to the prepared TRMS workflow which integrated the remotely invoked tools only. Because of differences between ASIC and FPGA design flows, the two separate TRMS workflows, containing different design tools, had to be implemented. The first workflow that describes the ASIC design flow is relatively simple. It contains two tasks only: synthesis
Fig. 3. Implementation part of the FPGA design workflow.
1023
and post-synthesis simulation. For these tasks Leonardo Spectrum and Modelsim tools were used, respectively. The implementation process (Fig. 3) must be additionally included in case of the FPGA workflow. This process consists of five tasks, which are parts of Xilinx ISE: ngbuild (translating design into the Xilinx database), map (mapping design to FPGA primitives), par (place and route), netgen (simulation netlist generation), bitgen (programming file generation). Each of them (excluding the first one) needs, as its input, the output of the previous one, and there is no need for human interaction, so the automated invocation is very useful in this case. If some of the tools return the exit code different than ‘‘0’’, the workflow is stopped, and each of the tools generates a report which is sent to the designer, therefore, the IP designer can monitor the progress and status of the workflow performance all the time.
5. Conclusions An access to remote synthesis and FPGA implementation services is very attractive for IP providers, or generally design-based SMEs, as it enables their new designs without having their own synthesis and implementation tools. IP components developed locally must be validated using the synthesis tools and the result netlist simulation. An IP provider attains such a possibility due to the TRMS system. A final product engineer, supported by the system, is able to convert his own design idea into a working hardware prototype on the application board, using FPGAs configured by EEPROMs, supplied by bitstream files generated as an output of the remote workflow. Although TRMS is still in the evaluation phase, its functionality is already very useful for an IP designer [13]. Easy search and integration of required tools enable improvements in the design productivity. The workflow-centred design process allows designers to concentrate on the main challenges of a design, leaving integration of tools to TRMS. Using the TRMS client application, an engineer is able to run remotely a wide range of tools necessary for his work, even if the tool is on a machine inside the company network protected by a firewall. TRMS assures user access to specialised tools without necessity for their installation on a local workstation. This can significantly decrease costs and shorten design time because designers do not have to spend money on specialised software and waste time on unnecessary software administration. Due to builtin complex security mechanisms, all essential project data are well protected. The performed experiments demonstrated advantages of TRMS, but also pointed up the need for a couple of enhancements, namely: an advanced workflow editor, e-commerce solution related to remote tool usage,
1024
K. Siekierska et al. / Microelectronics Reliability 46 (2006) 1019–1024
distributed license management, better support for dispersed designers (a functionality similar to groupware is needed). Some of these issues are to be addressed in further research of the group. References [1] ASTAIÒ Manual v. 2.2. C-Lab, Univ of Paderborn, Germany, 2000. [2] Chan F, Spiller M, Newton R. WELD—An environment for web-based electronic design. Proc DAC, San Francisco, 1998. [3] Cutkosky M, Tenenbaum J, Glicksman J. Madefast: an exercise in collaborative engineering over the Internet. Communications of the ACM 1996;39(9). [4] Dalpasso M, Bogliolo A, Benini L. Specification and validation of distributed IP-based designs with JavaCAD, Proc date, 1999. [5] E-Colleg and TRMS web pages: http://www.ecolleg.org, http://www.ecolleg.org/trms. [6] Fras´ P, Kostienko T, Magiera J, Pawlak A, Penkala P, Stachan´czyk D, Szle˛zak M, Witczyn´ski M. Collaborative infrastructure for distance—spanning concurrent engineering. PRO-VEÕ04. In: Luis M. Camarinha-Matos editor. Virtual enterprises and collaborative networks. 5th IFIP working conference on virtual enterprises. Kluwer Academic Publishers. Toulouse, 23–26.08.2004. [7] Indrusiak L, Glesner M, Reis R. Comparative analysis and application of data repository infrastructure for collaboration-enabled distributed design environments. Proc date, Paris: 2002.
[8] Kokoszka A, Nguyen QT, Siekierska K, Pawlak A, Obre˛bski D, Ługowski N. Distributed design of semiconductor IP based on the workflow concept. In: Proc IEEE design and diagnostic of electronic circuits and systems workshop (DDECS 2001). Gyor: April 18–20, 2001. p. 299– 306. [9] Kostienko T, Mueller W, Pawlak A, Schattkowsky T. Advanced infrastructure for collaborative engineering in electronic design automation. 10th ISPE Int conference on concurrent engineering: research and applications. Madeira Island: July 26–30, 2003. [10] Lavana HA. Universally configurable architecture for taskflow-oriented design of a distributed collaborative computing environment. Thesis PhD, CBL, North Carolina State University, 2000. [11] Schattkowsky T, Mueller W. Distributed engineering environment for the design of electronic systems. In: Proc E-Colleg workshop on challenges in collaborative engineering (CCEÕ03). Poznan´: April 15–16, 2003. [12] Schneider A, Ivask E. Internet-based collaborative system design using Moscito, Workshop on challenges in collaborative engineering (CCEÕ03), Poznan´, Poland: April 15–16, 2003. [13] Siekierska K, Obre˛bski D, Kokoszka A, Ługowski N, Pawlak A, Carballeda M, Schlichter B. Verification of advanced collaborative infrastructure by affine FPGA design. In: Proc 2nd workshop on challenges in collaborative engineering (CCEÕ04). Tatranska Lomnica: April 18–21, 2004. [14] Szle˛zak M. Markup language in realization of design tasks. In: Proc 3rd workshop on challenges in collaborative engineering (CCEÕ05), Sopron, Hungary, 14–15.04.2005.
Research note
Distributed collaborative design of IP components in the TRMS environment K. Siekierska a, P. Fras´ b, A. Kokoszka a, T. Kostienko b, N. Ługowski a, D. Obre˛bski a, A. Pawlak b,*, P. Penkala b, D. Stachan´czyk b, M. Szle˛zak b b
a Institute of Electron Technology, Al. Lotniko´w 32/46, 02-668 Warszawa, Poland Collaborative Engineering Laboratory, Institute of Electronics, Silesian University of Technology, Akademicka 16, 44100 Gliwice, Poland
Received 18 October 2004; received in revised form 11 July 2005 Available online 21 September 2005
Abstract A methodology, an application scenario and a new system enabling collaborative distributed design have been presented. The system based on Tool Registration and Management Services (TRMS) constitutes the core of the engineering collaborative infrastructure that has been deployed in the distributed design of intellectual property (IP) components. The system assures information security (including user authorization, data and transfer encrypting), communication through firewalls, remote administration of users and tools, and some support for distributed inter-organization workflows. Ó 2005 Elsevier Ltd. All rights reserved.
1. Introduction The broadband access to the Internet enables closer collaboration of distributed teams. This new networkbased engineering paradigm referred to as collaborative engineering [3] is still a young field of research with challenges related to integration of dispersed engineers and their tools [7,9,11]. Profound changes in the engineering paradigm call for new design methodologies that will leverage on the engineerÕs ability to access globally to necessary resources. The last is especially promising as enabling technology for new methodologies for system-
* Corresponding author. Tel.: +48 32 237 2986; fax: +48 32 237 2225. E-mail address: [email protected] (A. Pawlak).
on-a-chip (SoC) designs based on reuse of intellectual property (IP) components. The note presents a new system for integration of dispersed tools enabling distributed collaborative design of IP components. Problems, like: construction of a collaborative network even across firewalls, tool integration assuring consistency of design data formats, and application of appropriate standards, had to be addressed. Internet-based collaborative environments for applications in electronic design automation (EDA) have been a target of academic R&D since a decade. The examples of the most relevant academic solutions are: WELD [2], REUBEN [10], ASTAIÒ [1], MOSCITO [12], and JavaCAD [4]. It should be noticed that, despite many research efforts, including those mentioned above, widely accepted Internet-based tool integration technology is still not available. Furthermore, the existing distributed collaborative engineering infrastructures do
0026-2714/$ - see front matter Ó 2005 Elsevier Ltd. All rights reserved. doi:10.1016/j.microrel.2005.07.118
1020
K. Siekierska et al. / Microelectronics Reliability 46 (2006) 1019–1024
not sufficiently support such requirements, like intellectual property protection, information security (including user authorization, data and transfer encrypting), communication through firewalls, support for distributed inter-organization workflows, and remote administration of users and tools. This note briefly demonstrates advantages of deployment of the new system to collaborative design of IP components. The system based on Tool Registration and Management Services (TRMS) that has been developed by the EU IST E-Colleg project [5] allows integration of remote tools and crossing of firewalls transparently. In TRMS, tools once registered, provide their services to distributed design teams. Advanced service discovery technologies connect to the most appropriate service with respect to optimal availability within the current configuration of the collaborative network. A dedicated workflow for IP design is explained after an overview of the TRMS functionality.
2. Methodology and scenario for collaborative design of IP components The term collaborative design is used with regard to realisation of complex designs of micro-systems or SoCs performed by a geographically dispersed group of engineers. A distributed work environment is quite common nowadays. The Internet is a medium that can significantly improve collaboration in such a distributed setting. The collaborative design methodology provides mechanisms supporting work of IP designers, as well as engineers responsible for integration of the final design. From the IP component designerÕs point of view, the most important is an easy access to design data and tools that are made available by the system integrator. For an SME that can hardly afford expensive design tools, the possibility of remote use of tools provided by a cooperating company, is of a great advantage. Since the IP protection is an essential issue, the collaboration platform has to provide mechanisms for secure tool invocation and data exchange between partnersÕ LANs protected by firewalls. 2.1. Collaborative IP design scenario The note focuses on a part of collaborative work related to design of IP components. Although, design of a complete digital system can involve a number of designers dispersed across different locations, the particular component design methodology based on HDL (VHDL, Verilog or SystemC) and RTL synthesis, is generally the same as in the case of on-site design [8]. However, the established collaborative environment enables a designer to perform some design processes with the use of remote
EDA tools. The scenario of a collaborative IP component design is shown in Fig. 1. While RT-level design modelling and simulation should be done with local tools, the rest of the design process can be performed remotely. The main design phases in ASIC and FPGA cases are described below as either local or remote operations. 2.1.1. Local simulation Each designer should have an HDL simulator (client 1/2 in Fig. 1) available locally, as a graphical output of a simulation cannot be sent in practice by the network. There are many HDL simulators on the market, and the cost of some is not too high. The analysis of simulation results, based on the text format information, like signal values snapshots only, which can be easily interchanged by a network, is very uncomfortable in a real design, especially in the early phase of a design, when the architecture of the component is often changed. A designer has to view waveforms in the debugging phase of a new developed HDL code to verify its correctness. Textual simulation results are generated for the final verified version of the IP component to be compared later with simulation results of the related post-synthesis or post-implementation structure, performed remotely. 2.1.2. Remote synthesis and simulation As a synthesis tool cost is much higher than the cost of a simulator, it is reasonable to share synthesisers in a collaborative network (in accordance with the license agreement). Logic and RTL synthesis, in a selected standard cell ASIC library or FPGA library, of a developed component can be performed on a remote machine (Tool Server in Fig. 1). It allows to check if the code is synthesisable and thus to choose the optimisation conditions after analysis of the synthesis reports. The postsynthesis simulation is done in the case of an ASIC target technology. It has to be performed remotely, because HDL simulation models of all standard cells included in the selected ASIC library are a part of the Design Kit located at the synthesis tool ownerÕs site. The simulations with the use of the developed previously test-benches give results written to text files. The results in the text format can be easily compared with the final simulation results of the HDL source code. If they are functionally equivalent the IP model is validated. Data transfer on both sides (Fig. 1) is restricted to text files– HDL files (IP models and test-benches) and synthesis scripts are being sent from client 1/2 to the Tool Server, and synthesis reports and simulation results are being resent. 2.1.3. Remote implementation and simulation Final design phases performed in the case of FPGA after synthesis—mapping, placement and routing,
K. Siekierska et al. / Microelectronics Reliability 46 (2006) 1019–1024
1021
Fig. 1. Collaborative design of an IP component.
generation of back-annotated files for simulation and a bit-stream file for implementation into a selected device—can also be done remotely. A designer can validate his IP component by means of post-implementation simulation using the generated back-annotated HDL model and SDF file (Tool Server in Fig. 1) and the previously developed test-benches, and in the following, comparing its results with the related HDL source code ones. The implementation report provides a designer with valuable information about timing and area parameters of the developed IP synthesised under selected optimisation constraints.
3. TRMS system The TRMS system [6,9] is built upon the Tool Registration and Management Services. It enables remote tools invocation, assures secure transmission of data generated by the invoked tools, as well as management of user rights to access specific tools. TRMS includes support for transformation and registration of new tool definitions. TRMS uses the native XML database for storing tool definitions. The TRMS client has a powerful
Windows-based GUI that allows efficient, user friendly management of tools and users registered in the environment. Through this GUI it supports a designer in establishing a distributed design environment to solve a particular design problem. A designer does not waste time to write long tool configuration scripts. Instead, he can login through the TRMS client to the system in order to find the required tools. In the next step he can build a workflow that suits his particular design task. With TRMS the best available tools can be deployed to solve a design problem, following the most appropriate design methodology. The configuration of a distributed design environment is highly reusable, as all information and design configurations are stored as XML-files. The TRMS system can be used in different engineering domains. This note briefly shows how an EDA engineer, e.g. an IP designer, can use TRMS to facilitate the design process with remote tools and the workflow technology. 3.1. TRMS architecture The TRMS system is made up of the three main components: the Global Tool Lookup Server (GTLS), the
1022
K. Siekierska et al. / Microelectronics Reliability 46 (2006) 1019–1024
Fig. 2. The main components of the TRMS architecture.
Tool Server (TS), the client (a TRMS client-side application). A network topology of these components is illustrated in Fig. 2. The core of the architecture constitutes the GTLS (Global Tool Lookup Server). It fulfils a management role of the whole TRMS integration environment. GTLS enables tools sharing and their integration in a dynamic and secure way. The GTLS is responsible for registration and storage of data on users, their privileges, their public keys, a configuration of the system elements and information about available tools, their definitions and their physical network locations. A registered user who wants to find and invoke a certain tool has to know only the GTLS serverÕs IP. After corrected authorization he can find the tool and its definition on the GTLS without knowledge where the tool is physically located. If the user has enough rights he can invoke the tool based on its definition. Every exchanged message between the GTLS and the client is encrypted and signed by using a pair of asymmetrical keys. An authorized centre with a public keysÕ repository is placed on the GTLS. The Tool Server (TS) controls usersÕ access to tools and enables their remote invocation/lunching. Every host which wants to make its tools available through the Internet in a secure way makes it via the TS. The TS as an integral part of the TRMS environment connects with the GTLS in order to check usersÕ permissions, their public keys, and verify a set of the permitted parameters for launching tools. Messages exchanged between the TS and the GTLS are also encrypted with a public key and signed with a confidential private key. The last component is a GUI application on a client side. The all operation throughout the TRMS environment such as: logging to the GTLS, launching tools, defining toolsÕ workflow and managing the GTLS server (registering tools, registering users, defining toolsÕ parameters, etc.) is done by means of a visual Java GUI. The GUI has different views: for GTLS and TS administrators, and for an ordinary user. In a general case, all the TRMS components are on separate machines connected to the Internet. A TRMS
massages transport is realised as the HTTP/SOAP communication protocol. All exchanged data are encrypted and digitally signed by a sender. If necessary, the TRMS can use the Advanced Network Transport Services (ANTS) [11] mechanism for transporting data to hosts behind firewalls. The ANTS mechanism developed by C-Lab within the E-Colleg Project is a SOAP-based web service that enables routing of data through gateways and firewalls. The system has been developed on the Java platform with commonly available technologies and tools, like: UML, XML, SQL and Web. A new XML-based technique for integration of remote tools which provides the semantics of the communication layers has been defined for TRMS [14]. 3.2. TRMS functionality 3.2.1. Tool registration A user needs appropriate permissions in order to be able to register a tool in the global TRMS repository. During the registration process of a new tool an engineer fills in the form that describes the tool and its parameters. To simplify this task easy to use dialog boxes are available. A user has to choose one of the existing Tool Servers. 3.2.2. Tool search Upon search a designer gets the list of tools, availability for invocation, short descriptions, and related keywords. If the tool attributes satisfy design requirements, the tool can be parameterized by choosing the options and arguments, redefining input/output, and invoked separately, or included into the design workflow. TRMS has a common dialog box for searching information on tools, tasks, and workflows. 3.2.3. User management Each designer has to be registered in GTLS by the TRMS administrator. After generation of keys for authorization, a designer can login into the environment and check for needed tools. TRMS employs user management based upon a group system. A system admin creates a group of privileges to perform certain operations on tools, users, Tool Servers, etc. This approach enables easy control of usersÕ rights and is adaptable to the requirements of collaborating engineering teams. The Tool Server offers further control of access to the tools available on a particular machine. 3.2.4. Workflows In case a designer knows which tools he needs, he should be interested in integrating them into a workflow. Creation of the workflow is straightforward in TRMS– GTLS. A designer simply chooses particular tools and parameterizes them in the same way as in the separate
K. Siekierska et al. / Microelectronics Reliability 46 (2006) 1019–1024
use described above. He must only remember to match the inputs of the tool with the outputs of the preceding one. The tools in the workflow can be invoked manually or automatically, which accelerates the design process. Once created, a workflow can be exported to an XML file and reused in a different application.
4. IP component design workflow The collaborative IP design process (Fig. 1) was divided into two main parts: the local one containing the local IP HDL code development and simulation tasks, as well as the remote one comprising the synthesis and implementation tools. Since the IP modelling and the local simulation are usually performed completely in the used by a designer graphic integrated design environment, there was no need for the local tools integration into the TRMS workflow. The outputs of the local tools, the HDL model and synthesis scripts, were passed as inputs to the prepared TRMS workflow which integrated the remotely invoked tools only. Because of differences between ASIC and FPGA design flows, the two separate TRMS workflows, containing different design tools, had to be implemented. The first workflow that describes the ASIC design flow is relatively simple. It contains two tasks only: synthesis
Fig. 3. Implementation part of the FPGA design workflow.
1023
and post-synthesis simulation. For these tasks Leonardo Spectrum and Modelsim tools were used, respectively. The implementation process (Fig. 3) must be additionally included in case of the FPGA workflow. This process consists of five tasks, which are parts of Xilinx ISE: ngbuild (translating design into the Xilinx database), map (mapping design to FPGA primitives), par (place and route), netgen (simulation netlist generation), bitgen (programming file generation). Each of them (excluding the first one) needs, as its input, the output of the previous one, and there is no need for human interaction, so the automated invocation is very useful in this case. If some of the tools return the exit code different than ‘‘0’’, the workflow is stopped, and each of the tools generates a report which is sent to the designer, therefore, the IP designer can monitor the progress and status of the workflow performance all the time.
5. Conclusions An access to remote synthesis and FPGA implementation services is very attractive for IP providers, or generally design-based SMEs, as it enables their new designs without having their own synthesis and implementation tools. IP components developed locally must be validated using the synthesis tools and the result netlist simulation. An IP provider attains such a possibility due to the TRMS system. A final product engineer, supported by the system, is able to convert his own design idea into a working hardware prototype on the application board, using FPGAs configured by EEPROMs, supplied by bitstream files generated as an output of the remote workflow. Although TRMS is still in the evaluation phase, its functionality is already very useful for an IP designer [13]. Easy search and integration of required tools enable improvements in the design productivity. The workflow-centred design process allows designers to concentrate on the main challenges of a design, leaving integration of tools to TRMS. Using the TRMS client application, an engineer is able to run remotely a wide range of tools necessary for his work, even if the tool is on a machine inside the company network protected by a firewall. TRMS assures user access to specialised tools without necessity for their installation on a local workstation. This can significantly decrease costs and shorten design time because designers do not have to spend money on specialised software and waste time on unnecessary software administration. Due to builtin complex security mechanisms, all essential project data are well protected. The performed experiments demonstrated advantages of TRMS, but also pointed up the need for a couple of enhancements, namely: an advanced workflow editor, e-commerce solution related to remote tool usage,
1024
K. Siekierska et al. / Microelectronics Reliability 46 (2006) 1019–1024
distributed license management, better support for dispersed designers (a functionality similar to groupware is needed). Some of these issues are to be addressed in further research of the group. References [1] ASTAIÒ Manual v. 2.2. C-Lab, Univ of Paderborn, Germany, 2000. [2] Chan F, Spiller M, Newton R. WELD—An environment for web-based electronic design. Proc DAC, San Francisco, 1998. [3] Cutkosky M, Tenenbaum J, Glicksman J. Madefast: an exercise in collaborative engineering over the Internet. Communications of the ACM 1996;39(9). [4] Dalpasso M, Bogliolo A, Benini L. Specification and validation of distributed IP-based designs with JavaCAD, Proc date, 1999. [5] E-Colleg and TRMS web pages: http://www.ecolleg.org, http://www.ecolleg.org/trms. [6] Fras´ P, Kostienko T, Magiera J, Pawlak A, Penkala P, Stachan´czyk D, Szle˛zak M, Witczyn´ski M. Collaborative infrastructure for distance—spanning concurrent engineering. PRO-VEÕ04. In: Luis M. Camarinha-Matos editor. Virtual enterprises and collaborative networks. 5th IFIP working conference on virtual enterprises. Kluwer Academic Publishers. Toulouse, 23–26.08.2004. [7] Indrusiak L, Glesner M, Reis R. Comparative analysis and application of data repository infrastructure for collaboration-enabled distributed design environments. Proc date, Paris: 2002.
[8] Kokoszka A, Nguyen QT, Siekierska K, Pawlak A, Obre˛bski D, Ługowski N. Distributed design of semiconductor IP based on the workflow concept. In: Proc IEEE design and diagnostic of electronic circuits and systems workshop (DDECS 2001). Gyor: April 18–20, 2001. p. 299– 306. [9] Kostienko T, Mueller W, Pawlak A, Schattkowsky T. Advanced infrastructure for collaborative engineering in electronic design automation. 10th ISPE Int conference on concurrent engineering: research and applications. Madeira Island: July 26–30, 2003. [10] Lavana HA. Universally configurable architecture for taskflow-oriented design of a distributed collaborative computing environment. Thesis PhD, CBL, North Carolina State University, 2000. [11] Schattkowsky T, Mueller W. Distributed engineering environment for the design of electronic systems. In: Proc E-Colleg workshop on challenges in collaborative engineering (CCEÕ03). Poznan´: April 15–16, 2003. [12] Schneider A, Ivask E. Internet-based collaborative system design using Moscito, Workshop on challenges in collaborative engineering (CCEÕ03), Poznan´, Poland: April 15–16, 2003. [13] Siekierska K, Obre˛bski D, Kokoszka A, Ługowski N, Pawlak A, Carballeda M, Schlichter B. Verification of advanced collaborative infrastructure by affine FPGA design. In: Proc 2nd workshop on challenges in collaborative engineering (CCEÕ04). Tatranska Lomnica: April 18–21, 2004. [14] Szle˛zak M. Markup language in realization of design tasks. In: Proc 3rd workshop on challenges in collaborative engineering (CCEÕ05), Sopron, Hungary, 14–15.04.2005.