SVG for Remote EDA Schematic Representation

Keywords: Electronic Design Automation, SVG, Web Services

Stephen Dawson
PhD Student
Queen's University Belfast
Northern Ireland
stephen.dawson@ee.qub.ac.uk
http://www.ee.qub.ac.uk/dsp/acs

Biography

Stephen Dawson obtained his honours degree in Electronic and Software Engineering from Queen’s University Belfast, Northern Ireland in 2002. He has been a researcher and Ph.D. candidate since then. His research interests include distributed systems, web services and autonomous agents.

Paul Murphy
Queen's University Belfast
Northern Ireland
paul@ninetdesign.com
http://www.ninetdesign.com

Biography

Paul has just completed a Masters of Electrical and Electronic Engineering degree in Queen's University Belfast. He has been working with ASP (Active Server Pages) for a number of years and runs his own internet firm. His experience with ASP, XML (eXtensive Markup Language) and EDA (Electronic Design Automation) enabled him to undertake this project which resulted in a solution utilising the complementary capabilities of SVG (Scalable Vector Graphics)

Sakir Sezer, Ph.D.
President
Queen's University Belfast
Northern Ireland
s.sezer@ee.qub.ac.uk
http://www.ee.qub.ac.uk/dsp/acs

Biography

Sakir Sezer obtained his Dipl. Ing. degree from the University of Technology Aachen, (RWTH), Germany, in 1994, and the Ph.D. degree from Queen’s University Belfast, Northern Ireland, in 2000. From 1995 to 1998 he worked with Nortel Networks on the development of ATM access and SONET/SDH transmission products and with Amphion Semiconductor Ltd. on the development of IP cores. In 1998 he joined Queen’s University Belfast academic staff to lead research and teaching in the areas of communication- and digital systems. Since 1998, Dr Sezer has been involved as a consultant in a number of industrial projects with Nortel Network and Amphion- Semiconductors and contributed to the development of numerous networking products and intellectual properties. His research interests include WEB based services, Quality of Service (QoS) of packet switched networks, configurable network and protocol processing architectures, packet scheduling architectures and communication Systems on a Chip (SoC).


Abstract


The huge growth of the internet has opened up a new market for many industries from the supplying and selling of books and holidays to scientific calculations. One industry which has flirted with the web and it associated standards as a new platform for business is the EDA tool providers. In the past this has been a largely unsuccessful trail due to bandwidth, security and graphical representation problems. SVG coupled with the emergence of the service orientated architecture offers the possibility such a pay per use EDA service. We developed an architecture for visually representing common netlists outputted from EDA tools. This framework is subsequently implemented and a demonstration system is presented.


Table of Contents


1. Introduction
2. Background
3. System Overview
4. System Implementation
     4.1 Server-Side Processing Script
         4.1.1 Overview
         4.1.2 Write ASP Headers and Define Constants
         4.1.3 Create Document Object Models (XMLDOM)
         4.1.4 Define Functions and Sub-Routines
         4.1.5 Function: Get Circuit Ports (Input/Output)
         4.1.6 Sub-Routine: Convert String to XML Node
         4.1.7 Sub-Routine: Join Two Points on the Schematic Grid
         4.1.8 Validate EdaXML Document
         4.1.9 Create SVG Headers
         4.1.10 Deduce Gates Used & Define SVG Symbols
         4.1.11 Build Array of Circuit Inputs & Outputs
         4.1.12 Begin Building Gate & Signal Arrays
         4.1.13 Calculate Grid Gate Stage & Populate Signals Array
         4.1.14 Locate Positions of Gates & Ports on Schematic Grid
         4.1.15 Locate Positions of Circuit Input & Output Ports
         4.1.16 Join All Connecting Points & Complete Schematic
         4.1.17 Clean-Up and Save SVG Schematic Document
     4.2 Event-Handling Client-Side Script
         4.2.1 Overview
         4.2.2 Function: Show Details of Selected Signal
         4.2.3 Function: Hide Details of Deselected Signal
         4.2.4 Function: Show Details of Selected Gate
         4.2.5 Function: Hide Details of Deselected Gate
         4.2.6 Function: Change the Style of an Element
         4.2.7 Function: Resize the Containing Frame
     4.3 Cascading Style Sheet
     4.4 Graphical User Interface
5. Conclusions
6. Further Work
     6.1 Technology Improvements
     6.2 Software Integration
     6.3 Mobile SVG
     6.4 Other Applications
Bibliography

1. Introduction

"Electronic Design Automation (EDA) tools are the design centre of the almost $1 trillion electronics industry. These tools are used by computer and electrical engineers for the design and simulation of increasingly sophisticated systems. The complex and computation intense nature of EDA tools dictate not only the specification of the system required to run the tools but also the need for constant updates. These updates can often be difficult to install and costly for the vendors to supply. These problems could be resolved by service providers supplying an online Graphical User Interface (GUI) to these tools, which clients could access on a pay per use basis. Such an implementation has the capacity to provide both added revenue to large tool companies who permit their services to be consumed by users as well as a new design option for smaller companies to explore.

Scalable Vector Graphics (SVG) has been used to represent various types of physical and geographic maps ( [SVG 2002] / [SVG 2003] ). EDA design schematics are analogous to geographic maps. In the same way maps range in size, schematics range in complexity. Each entity on a map can have properties, for example, a mountain peak would have a certain name and altitude value, while in electronic schematics each component would have a certain id and associated parameters. Similar to geographic route planners, signal routing can be performed on a circuit. This allows designers to analyse timing and delay characteristics of both components and the circuit as a whole.

This paper presents extensive research into the graphical translation of output schematics from common EDA tools. Finally a translator is developed to convert from the proprietary formats outputted by EDA tools to the universal web based graphical representation standard SVG. The interface to this system is built using Active Server Pages (ASP). The raw materials inputted into the system are EDIF Netlists. These are circuit representations easily exported from mainstream EDA Tools such as Synopsys and Synplify Pro. The Netlists are converted to [EDAXML] format using an XML Document Type Declaration (DTD) defined by E-Tools. A script then uses the Microsoft Document Object Model [XMLDOM] to parse the EdaXML. The system interprets the electronic circuit layout using an SVG library of electronic symbols to build a graphical view of the circuit schematics. The result is an SVG graphic file of the desired circuit that allows clear viewing of the design along with the identification of signal routing and component parameters from a web browser. With the help of sample circuitry, the demonstration program is introduced and the resulting schematics are shown, highlighting the successful proof of concept. Limitations to the program are also highlighted at this stage. Finally we conclude the value of this work and list possible future directions of research.

2. Background

While many other components of the high-tech marketplace have experienced wild fluctuations in the past few years, the EDA industry has been much more stable. After a slight drop in revenue growth for the EDA industry in 2002, resulting from the global downturn in technology markets, 2003 saw a very positive return to growth. EDA revenue totalled $3,825 million in 2003, which was 3% more than $3,709 million, reported the previous year [Edat] .

While, for many working in the EDA industry, the main challenge is to maintain an efficient design environment to cater for ever more complex systems-on-a-chip (SoCs), others believe that for the EDA industry to prosper substantially more, a new business model is needed. The growth of e-business and the versatility of the World Wide Web may be the solution, or at least part of it. This led to much excitement between 1998 and 2000 with many in the industry foreseeing the future of EDA in a similar shape or form [IC03] , [EEDesign] , [EEDesign2] . High-powered third-party servers were envisaged, hosting data sets and tools with designers paying per-use fees for a huge variety of these high-end services. The huge overheads associated with buying EDA tools and providing servers to run them on means that small designers simply cannot afford to do so. This new concept of online renting of tools from an Application Service Provider (ASP) would pave the way for many smaller companies to take advantage of EDA [Tech] .

“The Internet will turn EDA vendors into ASPs” argued Mar Hershenson, founder and chief executive officer of Barcelona Design, in June 1999 [EEDesign3] . Barcelona introduced their analogue optimisation tools over the Internet on an ASP basis shortly afterwards. Initial response was very positive – hundreds of users tried early versions and valuable feedback was attained. However, despite the low maintenance costs and ease of access, Barcelona has recently withdrawn their web model completely claiming that customers were simply “feeling more comfortable with the traditional software delivery through a CD”.

Another company, Toolwire Inc. seemed to have hit the note with their ASP model. Toolwire was the best-known independent provider of EDA tools on an ASP basis since 1998. The company offered tools from Lucent, Novas, Synopsys and Triscend allowing design of Configurable System-on-Chip (CSoC) devices and Application-Specific Integrated Circuits (ASIC), alongside their main focus of Field Programmable Gate Array (FPGA) tools. One problem faced was that many FPGA vendors offer free tools to users already, so why pay for something that’s available elsewhere for free? In 2001 the company shut down its pay per use service with a sudden shift of business strategy.

It seemed that none of the big third-party EDA vendors were interested in offering their IC design tools through Toolwire's service [EEDesign4] . Realising that venture capital was flowing to Internet companies, many EDA vendors developed their own Internet strategies to go where the money is. Monterey Design Systems Inc. introduced eDolphin, DesignSphere form Synopsis and Cadence’s Quickturn emulators arrived to provide their own web based solutions. During this time the industry leaders were more cautious - Dr. Aart J. de Geus, Chairman and CEO of Synopsys, in 2000, warned that “current business suffers while trying to launch new Web EDA tools” [Tech2] .

3. System Overview

Our model can first be broken down into its individual files, or pages that can be separated further into functional blocks. Table 5.1 lists the files contained within the system, their respective implementation technologies. Figure 5.1 depicts how the files interact. Each of these will be described in detail in this section.

Description Technology Filename
Main Server-Side Processing Script ASP with VBScript go.asp
Event-Handling Client-Side Script JavaScript; events.js
Cascading Style Sheet CSS styles.css
Graphical User Interface HTML default.asp

Table 1

1.png

Figure 1: SVG generation and linking of external filesSVG generation and linking of external files

4. System Implementation

4.1 Server-Side Processing Script

4.1.1 Overview

The key processing block on the server side is an Active Server Pages (ASP) script that is written in Visual Basic Script (VBScript). This is the main script that actually parses the XML documents (EdaXML netlist and SVG library). It is called using a GET command, with variables sent to the script within query-strings. The following is the minimum query-string required to generate a schematic: go.asp?circuit=fulladder. The variable ‘circuit’ is used to locate the EdaXML netlist and is also used in naming the output SVG document.

2.png

Figure 2: Variable passing from GUI to main script

The sequential nature of this script means there are a number of distinctive steps required to produce the final output. Each of these steps, for the process of explanation, will represent a design sub-unit. The steps follow a distinct path necessary to parse the XML documents and perform place-and-route programming in order to derive the layout of the circuit and translate the schematic to SVG format. The path to follow is shown in Figure 5.3. The full code for this script is referenced in the Appendices. There are a number of functions and sub-routines used for repeatable processes and along with the steps indexed on the next page, these will be described in the following sections. Each will be modeled as a design unit and the code will be explained fully.

3.png

Figure 3: Main script functionality path

4.1.2 Write ASP Headers and Define Constants

At the top of every ASP page the scripting language used should be defined. VBScript, the Microsoft scripting language is the standard language used on Windows IIS servers and although this is the default language, for the benefit of readers and as best practice, the very first line of any ASP page should contain the following:

<%@LANGUAGE="VBSCRIPT" CODEPAGE="1252"%>

The codepage should also be declared so that the server definitely knows that all query-string values coming in from the browser in an HTTP request should be converted to Unicode (1252) for processing by the ASP script. An Option Explicit statement is then included in the ASP page, before any other code is written, to inform the server that all variables used in the script should be declared properly before being employed. All ASP statements in the script including this one are located within the parenthesis <%%>.

All variables used are then declared. It was decided to declare these variables in related groups for clear understanding of how they are used. The full code, with reference to each variable used can be found in the Appendices. Although in conflict with the practice of declaring everything before running commands, it was decided that the Timer function was called within the declarations because it is most effective when employed as soon as possible in the script. The Timer function is used to ultimately find the length of time it takes for the server to process the script.

  lngStopWatch = Timer 'Start the timer"/>

The constants employed throughout the script are then defined so that if they are to be changed in the future they can be found immediately.

'Read in the name of the circuit from the query-string
strCircuit = Request.Querystring("circuit")
'Set Locations of XML documents
strXmlFile = Server.MapPath(strCircuit & ".xml")
              

The snippet above shows how the EdaXML file is read in. The circuit name is deduced from the query-string and the MapPath function is used to find the full directory path to the file located in the same directory as the script, because a virtual path is not valid for creating a Document Object Model for the XML information. The schematic grid, on which all symbols and signals are drawn, will be discussed later but the constant values for symbol and block dimensions are defined next.

4.1.3 Create Document Object Models (XMLDOM)

XMLDOM is used to create the Document Object Model for the EdaXML netlist, the SVG library, the SVG output schematic and a temporary XML document held only in memory for modification of created XML nodes. The Document Object Model is set using the following code:

  lngStopWatch = Timer 'Start the timer"/>

The constants employed throughout the script are then defined so that if they are to be changed in the future they can be found immediately.

'Create And load the Document Object Model For the EdaXML Netlist
Set objXmlDoc = Server.CreateObject("Microsoft.XMLDOM") 
objXmlDoc.async = False
objXmlDoc.load(strXmlFile)
              

The other objects are created in a similar way although the SVG output model and the temporary XML model are not required to be loaded as such. By executing the above code the XML document can now be accessed efficiently and the nodes traversed to find and create the required information.

4.1.4 Define Functions and Sub-Routines

In this script there is a need for one function and two sub-routines each with a precise role. They are used so that instead of code repetition in the script, each time a certain methodology is to be carried out the function or sub-routine is called that performs the desired action. A function is defined using the syntax below:

Function nameOfFunction(passedVariableA, passedVariableB, ...)
  ...
  nameOfFunction = returnedVariable
End Function
              

A sub-routine is defined similarly but there is nothing returned. The sub-routines are called at the required stage in the process, in the following way:

Call nameOfSub(passedVariableA, passedVariableB, ...)

More than one variable is passed to the sub-routine using this method. If only one variable needs to be passed the sub-routine above could be initiated without the Call command included in the line and with just one variable between the parentheses. To call a function and return the desired variable, this code is used:

returnedVariable = nameOfFunction(passedVariable)

All functions and sub-routines are defined at this stage in the script and are described in detail on the following pages.

4.1.5 Function: Get Circuit Ports (Input/Output)

This function is used to get all circuit inputs or outputs and return a one-dimensional array with the names of the ports. The string containing the type of port to list is passed to the function, and the array is returned and named arrCircuitInputs:

arrCircuitInputs = getPorts("inputport")

In the XMLDOM Tree, the input ports are found at: /EdaXML/library/cell/cluster/interface/port/inputport/ where the library identifier is “DESIGNS”, so the code used to loop through all such nodes is:

For Each nodPort In nodLibrary.SelectNodes("cell/cluster/interface/port/" & strPort)
  ...
Next
                    

In this case strPort is equal to either “inputport” or “outputport” and nodLibrary has already been defined globally as the “DESIGNS” library node before the function is called. Each time the loop repeats, the selected port is added to the relevant array.

4.1.6 Sub-Routine: Convert String to XML Node

This sub-routine is used to convert a string that is formatted as an XML snippet but needs to be converted to a node object. It is then amended to the new SVG document model by making use of the temporary Document Object Model (objTempDoc). The string, received as a sent variable is loaded as XML and then added to the new SVG model.

Sub strToNode(xmlStr)
  objTempDoc.loadxml(xmlStr & vbNewLine) 'load string as an xml document
  'Add the converted nodes to the new svg document model
objSvgDoc.documentelement.appendChild(objTempDoc.firstChild.cloneNode(True))  
End Sub
                    

This is a sub-routine and as such there is no variable returned.

4.1.7 Sub-Routine: Join Two Points on the Schematic Grid

This sub-routine is much more complicated than the previous two. Its purpose is to join two points (co-ordinates for certain ports on the circuit) and name the signal that it is carrying. For presentation and clear viewing purposes the connecting line cannot be a direct line but instead must be made up of horizontal and vertical lines carefully placed so they do not overlap each other. The function is structured with variables to be passed shown below.

Sub joinPoints(lngXPointA, lngYPointA, lngXPointB, lngYPointB, strSignal)
  ...
End Sub
                  

These variables are the X and Y co-ordinates of the start point and the end point of the signal. A string containing the signal name is also passed for identifying it on the schematic when complete.The first thing that is done on executing the sub-routine is to ensure that Point A lies to the left of Point B. If not, the two points are swapped around. The model used to calculate how to connect the points with vertical transition lines is shown below.

4.png

Figure 4: Geometric model for deducing transition lines

To avoid overlapping of transition lines each is shifted by a value stored as variable lngXShift. It was found that a suitable value of this X Shift distance could be calculated based on the number of circuit inputs - UBound(arrCircuitInputs):

lngXShift = (lngXPointB - lngXPointA)/((UBound(arrCircuitInputs) + 2)*2)
lngXPointTrans = lngXPointA + (lngXShift * 3) 
' Shift the first point to get the X transition point
                  

The transition point is first set by shifting the initial X Point by the distance lngXShift. An array is used to store previous transition line information, and the new transition line just set is compared to each previous transition line in the array.Firstly, though the signal is checked against previous signals so that if signals match, a point connection can be placed on the schematic where the signal splits in two.

5.png

Figure 5: Explanation of Point Connection term

To deduce where the point connection should be drawn, the following model was used and implemented in the code, where arr(YPointB) represents the Y co-ordinate of the end point of the matching signal in the transition line array.

6.png

Figure 6: Geometric model used to define location of Connection Points

If, on the other hand the signals do not match but the vertical transition lines overlap then it is necessary to shift the X Transition point to the right by the defined XShift distance. The looping mechanism ensures that the number of shifts correlating to the number of line matches will be enforced. The connection point is drawn on the circuit by calling the strToNode sub-routine:

strToNode("<circle net=""" & strSignal & """ cx=""" & Round(lngXPointTrans) & """ cy=""" & Round(lngYPointConn) & """ r=""1.6"" class=""str1 fil1""/>")

In case the joined points cross through a full stage the following code is employed. This is to prevent lines from crossing through gates at the center of each grid block.

lngXDistance = lngXPointB - lngXPointA 'get distance between start and end point

'While the distance is greater than that of the block width
Do While lngXDistance > lngBlockWidth
  'Shift the X transition point by a block width
  lngXPointTrans = lngXPointTrans + lngBlockWidth
  Minus the block width from the distance for the while loop to work correctly
  lngXDistance = lngXDistance - lngBlockWidth 
Loop
                

As the new transition point has been deduced at this point in the sub-routine, the transition line information is added to the array. With the information stored, the strToNode sub-routine is called again to draw the polyline connecting the two original points on the SVG schematic:

strToNode("<a href=""#""><polyline net=""" & strSignal & """ points=""" & Round(lngXPointA) & "," & Round(lngYPointA) & " " & Round(lngXPointTrans) & "," & Round(lngYPointA) & " " & Round(lngXPointTrans) & "," & Round(lngYPointB) & " " & Round(lngXPointB) & "," & Round(lngYPointB) & """ class=""str1 fil0"" onmouseover=""showNetDetails(evt)"" onmouseout=""hideNetDetails(evt)""/></a>")

The sub-routine is now complete. No variables are returned.

4.1.8 Validate EdaXML Document

The document type for an EdaXML netlist is “EdaXML”. To check the document read in and to ensure that it is the correct type (equal to strDocType defined earlier) each highest-level child node is checked and for the node containing document type (doctype) the strings are compared for a match:

If nodChild.nodeType = 10 And strDocType = nodChild.nodeName Then bolDocValid = True
...
'If the document type has been validated			 
If bolDocValid = True Then
  ...
  MAIN BULK OF CODE
  ...
End If
                    

The value of 10 for nodeType (the full list of node types is found at the W3 Schools website, referenced in the bibliography) denotes that this node type is the document type. The main bulk of code is contained within the If condition above.

4.1.9 Create SVG Headers

The SVG library is already in a suitable SVG format, so the most effective way of creating the headers in the new SVG document is by looping through all highest-level nodes in the library document and using the cloneNode method to duplicate all necessary headers and SVG structure:

'Get SVG headers and structure from the SVG library file
For Each nodChild In objLibDoc.childNodes
  objSvgDoc.appendChild nodChild.cloneNode(False) ‘append the cloned node to new doc
Next
    

As there are JavaScript event handlers for roll-over effects on the final schematic, rather than recreating the functions each time an SVG schematic is generated a more efficient way to reference them is to create a link to a static JavaScript file. The code for these functions will be addressed later, and the file name has already been defined in strJsFile. The code below is what is needed to link to the client-side script.

strToNode("<script xmlns:xlink=""http://www.w3.org/1999/xlink"" xlink:href=""" & strJsFile & """/>")

It is essential for the XML node to have contained an XML namespace for the link.

4.1.10 Deduce Gates Used & Define SVG Symbols

The EdaXML netlists compatible for use by this program contain two main library sections: one containing the gate definition of all gates used; one containing all the design information. For this programming unit and the following units, the appropriate library is accessed and traversed. Looping through all library nodes (in this case, two), the identifier can be checked and the appropriate action taken to deal with each library of information.

The gates used are investigated in the loop where the identifier string is equal to “GENERIC_GATES”. In the SVG document to be produced reusable symbols are defined within the element <defs>, which is usually located as the first child node within the <svg> element. This element is created by using a combination of the appendChild, and createChild methods for the new SVG document object model:

objSvgDoc.documentElement.appendChild(objSvgDoc.createElement("defs"))

Each gate node in the netlist is looped through and within this loop, each symbol in the SVG library is looped through in order to find a match. If so, the <defs> element in the new SVG document model is appended with a duplicate of the relating symbol copied from the SVG library.

objSvgDoc.documentElement.selectSingleNode("defs").appendChild(nodSymbol.cloneNode(True))

For the next sequential units, described on the following pages, all the design information is investigated using the library with identifier string “DESIGNS”. The node nodLibrary for the functionality above referenced the gates library and similarly, for the rest of the script, nodLibrary refers to the designs library.

4.1.11 Build Array of Circuit Inputs & Outputs

The step is simple and straightforward. The function getPorts, described earlier, is used to build an array of all circuit inputs and an array of circuit outputs.

arrCircuitOutputs = getPorts("outputport")

The arrays arrCircuitInputs and arrCircuitOutputs are one-dimensional arrays and can be seen in use later in this chapter.

4.1.12 Begin Building Gate & Signal Arrays

This functional unit is quite extensive and complex. It is essential to first explain the structure of the array containing gate information. The array arrGates is two-dimensional and also includes nested arrays (arrInputs, arrOutputs) contained in some of its first order elements. The diagram below helps to explain the structure. Note that numOutputPorts for all used gates for demonstration is

7.png

Figure 7: Format of the array containing gate information

8.png

Figure 8: Format of the array containing signal information

Before the process of building the arrays begins the number count of gates and signals must be set to zero. The script loops through all nodes contained at the XML tree location “cell/cluster/connectivityview/logicalconnectivity/instance” within the nodLibrary (“DESIGNS”) node for each (gate) instance. The array of gates is re-declared, preserving the elements within, each time the loop repeats. The gate identifier and library gate referenced are loaded directly into the array at the correct location (see Figure 5.7).

arrGates(0,iNumGates) = nodInstance.selectSingleNode("identifier").Text
arrGates(1,iNumGates) = nodInstance.selectSingleNode("clusterref/cellref/identifier").Text
    

The array and number of input and output ports for each gate are reset on each loop.

Next, the arrays of input and output ports are deduced by checking the looped gate against the “GENERIC GATES” library discussed earlier. When there is a match the input and output ports of the library gate are checked and added to their respective array. The method of adding the input ports to the gate array is shown below, where nodCell is the node containing the used library gate. The process is identical to that of obtaining the gate output port(s).

For Each nodInputport In nodCell.selectNodes("cluster/interface/port/inputport")
  ReDim preserve arrInputPorts(iNumInputPorts) 'redefine array
  arrInputPorts(iNumInputPorts) = nodInputport.parentNode.selectSingleNode("identifier").Text
  iNumInputPorts = iNumInputPorts + 1 'increment number of inputs recorded
Next
    

The arrays of input and output ports are then nested in the array locations arrGates(2, …) and arrGate(3, …) respectively.

Next the input port array for this gate is traversed, and within this loop the portinstanceref of the signal-("cell/cluster/connectivityview/logicalconnectivity/signal/signaljoined/portinstanceref") - is looped to find a match for the input port and the gate identifier. If there is a match this means that the signal in question is connected to this gate’s input port. It can also be deduced that if there is also a portref as a sibling node then this gate’s input port is directly connected to a circuit input. The number of input point matches is counted at the start of each loop and at this stage there is not yet a signal match.

'Count up the matches of input ports To circuit inputs 
iNumInputMatches = iNumInputMatches + 1
'For checking if this is the first time this signal has been referenced or not
bolSignalMatch = False
    

If this signal has already been referenced, the new start and end point of the joining line is added to the nested array arrJoins. The variable bolSignalMatch is set to True. Otherwise (bolSignalMatch = False) the signal is added to the array arrSignals and then a newly created array arrJoins for this signal is amended. The code below shows how the array of points is nested within the array of signals.

'Add extra points just found to temporary array
arrPoints(0, iNumPoints) = nodPortref.selectSingleNode("identifier").Text 'start point
arrPoints(1, iNumPoints) = nodPortinstanceref.selectSingleNode("instanceref/identifier").Text & ":" & nodPortinstanceref.selectSingleNode("identifier").Text 'end point

arrSignals(1, iCountB) = arrPoints 'set points array to nested array within arrSignals
    

For each gate in the circuit, as already described, the number of connections to actual circuit inputs is counted. This value (iNumInputMatches) is used in the next unit to deduce the positioning of gates on the schematic grid. Up to this point the array of signals has been populated with all input signals only.

4.1.13 Calculate Grid Gate Stage & Populate Signals Array

If the number of input ports for a specific gate connected to actual circuit inputs match the total number of inputs for that gate then it can be inferred that this gate is located at the first gate stage on the schematic grid. For positioning of all points, ports and gates on the schematic image the following model is used:

9.png

Figure 9: Geometric model for schematic grid placement

For gates that are not located at the first gate stage, signals are again traversed and the input ports are checked against output ports of other gates as well as circuit inputs. For example, in the model shown above, the XOR gate furthest right can be deduced to be located at Gate Stage 2 because of its total two inputs, one input is connected to a circuit input, for modelling purposes Stage 0, and the other input is connected to the output of the other XOR gate, at Stage 1. The greatest stage of the two is used to infer that the stage of this gate is equal to the highest input stage incremented by one (iHighestInputStage + 1). See the code below for actual implementation:

'If gate stage is greater or equal to the current highest input stage And gate instance matches this input
If arrGates(4, iCountB) >= iHighestInputStage And arrGates(0, iCountB) = nodPortinstancerefOut.selectSingleNode("instanceref/identifier").Text Then
  iHighestInputStage = arrGates(4, iCountB) 'set the highest input stage to the stage of this gate
End If

...

'set the stage of this gate to one higher than the highest input stage
arrGates(4, iCountA) = iHighestInputStage + 1
    

While the gates are being assigned a stage, the signals joining the gates are added to the signals array similar to before. The signals connecting gates to circuit outputs are discovered and added by searching for a signal based on the outputs of the gate in question. Similarly to finding the gate inputs / circuit inputs connection, if a signal shares a gate output with a circuit interface point, and all the remaining gates have been assigned a stage based on previous gates then it can be inferred that the only remaining signals now added to the array are output signals.

4.1.14 Locate Positions of Gates & Ports on Schematic Grid

An array containing all the ports (connection points) on the circuit is created and populated in this functional unit. The arrAllPorts array is a two dimensional array also containing the actual co-ordinates of the port on the schematic grid contained within a nested array. This array structure is shown below:

10.png

Figure 10: Format of the array containing all ports in the circuit

Another array arrBlocksHigh is used for storing the count of vertical blocks for each stage in the circuit schematic (see model in previous sub-chapter), with the highest of these recorded for later use. For each gate to be positioned at a particular stage, this count is incremented. The location of each gate, i.e. the position of the top-left corner of the gate symbol itself, is then determined by the following geometric relationships:

11.png

Figure 11: Equations governing the placement of gates on the grid

Gate inputs and outputs are positioned horizontally in the centre of the gate symbol (the symbol itself is graphically arranged above the inputs and outputs, so they will appear to be at the entrance point to the gate). A vertical shift (see next page) from the top of the symbol is used to space the inputs equally, as well as to line up gates with previous gates for better viewing. If the gate is understood to appear at a stage later than Stage 1, then the Y Position of the gate is shifted:

12.png

Figure 12: Equation used for adapting gate position relative to inputs

The SVG content for drawing the gate is then written as a string and stored in the gate array. The strToNode sub-routine is used to do this:

arrGates(5, iCountA) = "<a href=""#""><use id=""" & arrGates(0, iCountA) & """ x=""" & Round(lngXPos) & """ y=""" & Round(lngYPos) & """ xmlns:xlink=""http://www.w3.org/1999/xlink"" xlink:href=""#" & arrGates(1, iCountA) & """ onmouseover=""showGateDetails(evt)"" onmouseout=""hideGateDetails(evt)""/></a>"

The SVG string includes <a> tags with no evident link for the mouse cursor to change when hovering over the symbol. The <use> element has already been described for repeating defined symbols in a SVG document. Note that the id for this gate is defined as an attribute and the JavaScript event handlers are also defined. Their purpose is to provide identification of each gate when the user ‘rolls’ the mouse cursor over the symbols.

The Y Shift value is then used for placing the inputs at the required position. The figure below explains how the Y Shift value is used, and the equation for this shift value is defined:

13.png

Figure 13: Geometric model for shifting gate input port points

This equation is repeated as needed for positioning outputs although for the purposes of this project all components used are gates with just one output

Looping through each input and output port for each gate, the array of all ports in the circuit is populated with the name of the port and the nested array of co-ordinates calculated.

arrCoOrds = Array(Round(lngXCoOrd), Round(lngYCoOrd)) 'Array of co-ordinates (re)set
ReDim preserve arrAllPorts(1, iNumAllPorts) 'Array of ports resized
arrAllPorts(0, iNumAllPorts) = arrGates(0, iCountA) & ":" & arrGates(3, iCountA)(iCountB) 'Port name defined
arrAllPorts(1, iNumAllPorts) = arrCoOrds 'Port co-ordinates defined as nested array
    

Note that for quality of viewing purposes, that the co-ordinates are Rounded off to the nearest whole number in the final SVG output document.

4.1.15 Locate Positions of Circuit Input & Output Ports

To position the input ports on the grid a starting reference point is defined. The X co-ordinate will be simply located half-way across the Input Stage grid. The Y co-ordinate reference point is the same as the Y starting point of the first gate in the circuit, at Gate Stage 1. A Y Shift value is also defined, after investigation with a number of circuits. These variables are defined in the code as below:

lngYPos = (lngBlockHeight - lngSymbolHeight)/2 'Y starting position set for placement
lngYShift = lngSymbolHeight/4 'Shift value for Y placement of inputs
    

To explain how the points are placed, Figure 5.14 shows how the first three inputs of a circuit are placed at the Input Stage, with the space between each input Y Shift times larger than the spacing before.

14.png

Figure 14: Geometric model for locating position of input ports

The locations of the circuit outputs are determined by the position of the gate whose output is connected to each. The array of signals, arrSignals is searched to find the signal containing this circuit output. On finding a match, the Y co-ordinate of the other connecting port is used as the Y co-ordinate for this circuit output, thus for better viewing, there is a horizontal line directly connecting these points.

The input ports and the output ports are drawn to the schematic identically by calling the strToNode sub-routine as below:

strToNode("<text x=""" & (lngXPos + 4) & """ y=""" & (lngYPos + 4) & """>" & strOutputPort & "</text>")
strToNode("<circle cx=""" & lngXPos & """ cy=""" & lngYPos & """ r=""1"" class=""str1 fil1""/>")
    

The co-ordinates for the ports found in this unit are added to the array arrAllPorts as shown in the previous sub-chapter.

4.1.16 Join All Connecting Points & Complete Schematic

To join up all the gates and ports whose co-ordinates have already been found, a loop is made through all the signals and the number of joined connections for each signal is found. For each of these joined connections per signal the array arrAllPorts is searched and on finding a match the co-ordinates for all points forming a connection are stored. The sub-routine described earlier to join a set of two points is called with the following statement:

Call joinPoints(lngXPointA, lngYPointA, lngXPointB, lngYPointB, arrSignals(0, iCountA))

The name of the signal is also sent to the sub-routine for identification on the SVG schematic.

The gate SVG symbol information is now written to the SVG document. It is written at this stage in the script so that the symbols are arranged-to-top of the SVG image. The strToNode sub-routine is used again to form the SVG content of the string stored in the array of gates. This sub-routine is also used to create the SVG content for text elements used in identifying nets and gates. Although not immediately viewable on the schematic when the mouse cursor moves over a gate or signal, appropriate text must appear to identify the components.

strToNode("<text id=""netId"" x=""-16"" y=""10"" class=""fon1""> </text>")
strToNode("<text id=""gateId"" x=""11"" y=""-2"" class=""fon1""> </text>")
strToNode("<text id=""gateRef"" x=""-1"" y=""42"" class=""fon1""> </text>")
    

The X and Y positions defined above are relative to the position of the gate/net that they will identify.

4.1.17 Clean-Up and Save SVG Schematic Document

With all gates, ports and signals drawn on the schematic, the dimensions of the SVG document itself now need to be set. These dimensions are based on the number of stages in the circuit as well as the number of blocks in the stage of the largest number of gates. These values were recorded earlier when calculating the position of the gates and are amended to the SVG document as shown below:

Call objSvgDoc.documentElement.setAttribute("width", (iNumStages + 2) * lngBlockWidth)
Call objSvgDoc.documentElement.setAttribute("height", iHighestNumBlocks * lngBlockHeight)
    

A JavaScript onload event handler is also written to the SVG document element node as a new attribute. This calls a function contained in the client-side event handling script (Section 5.4) that resizes the frame (if it exists) that contains the SVG image on the Graphical User Interface.

At the script nears completion, at this stage the Timer function is again employed and the difference between the start time and the end time is calculated by simple subtraction. Although highly unlikely, the timings are checked to make sure that the script did not begin before midnight and end after midnight. If this is found to have happened the values are adequately amended. The time taken to execute the script as found, along with the filename of the new document, is written as text on the bottom-right corner of the image by use of the strToNode sub-routine.

The IIS FileSystemObject model is then used to examine if a file of the same filename already exists on the disk. If so, for simple management purposes, the file is deleted, and the and the DOM containing the full content is saved to disk:

objCleanUp.DeleteFile strSvgFileName, True
...
objSvgDoc.save strSvgFile 'SVG document is saved to disk
    

The final operation required is to ‘clean-up’ the newly formed SVG document. The XMLDOM used in parsing and creating the SVG file creates namespaces that are not required by and are incompatible with the plugin used in the Internet Browser. The FileSystemObject model is again used by the script to extract (and write back) the full SVG file as text with a simple Replace function used to remove the unwanted content. The browser is then redirected to the newly formed SVG document with the Response.Redirect ASP command as the script completes execution.

4.2 Event-Handling Client-Side Script

4.2.1 Overview

This file is a JavaScript text based file, events.js used by the client web browser to perform functions on the SVG document in the browser window. The script is linked from the SVG document in order to perform the functionality required to identify the gates, ports and signals that make up the circuit. The ability to perform client-side functions from within an SVG image shows the potential of the dynamic ability of SVG. In the earlier sub-chapters the SVG written to link to and call the functions was described. The following pages describe the code layout and methodology employed to perform the desired operations. Note that the parameter passed to each function called within the SVG document is named evt. This is a reserved SVG word that describes the event that has just happened.

4.2.2 Function: Show Details of Selected Signal

This function is used to identify a signal as the mouse cursor ‘rolls’ over a line connecting two or more ports on the schematic. The only parameter passed to the function is the evt word described above. This is used to identify the SVG document so that it can be modelled and traversed as in the main processing script.

var objSvgDoc=evt.getTarget().getOwnerDocument(); // Identify root document

The linked points in each polyline are defined within the points attribute so this attribute can be extracted and split to find the point where the line changes from a horizontal to vertical direction. This point is used as a reference point to which the signal id is displayed as text. Figure 5.15 below explains exactly how the text is positioned:

15.png

Figure 15: Geometric model for positioning of signal name

The Code Snippet 5.36, on the following page is the SVG source syntax for this model.

<polyline signal="NET NAME" points="X1,Y1 X2,Y2 X3,Y3 X4,Y4" class="str1 fil0" onmouseover="showSignalDetails(evt)" onmouseout="hideSignalDetails(evt)"/>
...
<text id="signalId" x="-16" y="10" class="fon1"> </text>
                          

Note also the JavaScript onmouseover and onmouseout event handlers. For each polyline representing a signal line, that the mouse cursor hovers over the JavaScript function parses the XML contained within and sets the text node of the text element with id “signalId”. Values of X2 and Y2 are then added to the x and y attributes of the element respectively. The code below shows how the text node and attributes are then set.

// Set the text node to contain the signal name
nodTextSignalId.replaceChild(strText,nodTextSignalId.getFirstChild());
nodTextSignalId.setAttribute('x', lngXPos); // Set the X co-ordinate
nodTextSignalId.setAttribute('y', lngYPos); // Set the Y co-ordinate
                          

As well as naming the signal, the colour of all the lines and join points making up the signal is changed. This is done by calling changeClass function to be described later.

4.2.3 Function: Hide Details of Deselected Signal

This process is almost identical to the one just described, the only difference being that the text node replaced is blank, so the text that denoted the name of the signal seems to disappear. As well as this, the values of X2 and Y2 are, this time subtracted from the x and y attributes to return the co-ordinates of the text node to its original values for next use. The changeClass function is called again but with different parameters so that the original styles are reset.

4.2.4 Function: Show Details of Selected Gate

This function is used to identify a gate as the mouse cursor ‘rolls’ over it on the schematic. The only parameter passed to the function again is the evt word, used by the function to identify the SVG document so that it can be modelled and traversed. The position of the (top-left corner of the) gate is used as the reference point to which the gate id and gate reference name are displayed as text. Figure 5.16, right, explains exactly how the text is positioned:

16.png

Figure 16: Geometric model for positioning of gate details

The SVG code snippet below shows how the function is called and the origin of the co-ordinate calculating values:

<use id="ID" x="X1" y="Y1" xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#OR03D1" onmouseover="showGateDetails(evt)" onmouseout="hideGateDetails(evt)"/>
...
<text id="gateId" x="11" y="-2" class="fon1"> </text>
<text id="gateRef" x="-1" y="42" class="fon1"> </text>
    

When the mouse cursor hovers over the gate, the JavaScript function is called which parses the SVG source and sets the text node of the text elements with ids “gatelId” and “gateRef”. Values of X1 and Y1 are then added to the x and y attributes of the element respectively. The text node and attributes are set similarly to the in the previous functions. The id of the gate is that employed by the <use> element to link a defined symbol, so this id is realised by the following code:

var strText = objSvgDoc.createTextNode(evt.getTarget().getAttribute('xlink:href').replace('#',''));

4.2.5 Function: Hide Details of Deselected Gate

his process is almost identical to the one just described, the only difference being that the text nodes replaced are blank, so the text that denoted the id of the gate and the referenced gate type seem to disappear. As well as this, the values of X1 and Y1 are, this time subtracted from the respective x and y attributes to return the co-ordinates of the text nodes to the original values for next use.

4.2.6 Function: Change the Style of an Element

This function is used to change the class defined in the linked Cascading Style Sheet (see next section) for a certain element – for the purposes of a circuit, a polyline. The parameters passed to the function are the SVG document model, the node or element name to be changed, and the string value for the alternative class ('fil0 str1') or its original class ('fil0 str2').

A node list of all polylines is first created (below) and then it is traversed.

var nodPolylineList = objSvgDoc.getElementsByTagName(nodeName);

For each polyline looped, if the value of the custom attribute signal is equal to the value of the same attribute belonging to the polyline that called the function, then the class of the polyline is changed accordingly.

4.2.7 Function: Resize the Containing Frame

The SVG schematics produced will be of different sizes and for the purposes of demonstration the image is contained within an inline frame on the Graphical User Interface (Section 5.6). To ensure that the frame dimensions match the SVG image exactly this function is called using the onload method contained within the main SVG tag. This method is used to carry out some functionality as soon as the document is fully loaded to the browser.

This function also makes use of the evt word passed to it from the SVG document. After using this parameter to identify the SVG document, a check it made to find out if there if a parent document containing the inline frame exists. This is done so that the SVG file can be opened independent of the GUI (for whatever reason) without causing scripting errors on the browser. If the frame does exist the SVG document must be contained within it. The dimensions of the frame are then altered corresponding to the SVG image.

if ((top.document.getElementById('innerFrame'))) {
  // Set the height and width of the frame to correspond with the SVG image
  top.document.getElementById('innerFrame').style.height = objSvgDoc.getElementsByTagName('svg').item(0).getAttribute('height');
  top.document.getElementById('innerFrame').style.width = objSvgDoc.getElementsByTagName('svg').item(0).getAttribute('width');
}
                    

The code above is that used to check if the frame innerFrame exists and to change its dimensions accordingly.

4.3 Cascading Style Sheet

The style sheet used for the circuits is predefined and linked from the SVG document as shown earlier in the main processing script section. The style sheet is named styles.css and contains the styles used to visually describe the strokes, fills and fonts used in the SVG image. The style represents the specific colour, thickness, font-type, font-size and other attributes describing graphical features of an element.

The table below describes each style used. For the style-sheet itself, please refer to the Appendices.

Name Description
str0 No stroke
str1 Black stroke, 1.4 pixels thick
str2 Red stroke, 2 pixels thick
fil0 No fill
fil1 White fill
fon0 10 pt Black Font (Verdana/Arial/Helvetica)
fon1 8 pt Red Font (Verdana/Arial/Helvetica)

Table 2

4.4 Graphical User Interface

The purpose of the graphical user interface is for demonstration purposes. From this page the script is requested. The GUI page (default.asp) consists of a standard HTML web page (HTML 1.1) with a form (form1) whose action is set to “go.asp”. The method of the form is “GET” meaning that the form variables are sent to the ASP script as query-string variables.

17.png

Figure 17: Graphical User Interface screen-shot

The screen-shot above shows the GUI. The drop-down menus allow the user to choose what circuit to examine as well as giving the user the option to either Generate the SVG Schematic or simply View the EdaXML Netlist. On submitting the form a JavaScript function is used to change the form’s target based on this choice. For the netlist a new window is opened with the XML code view. If the user chooses to generate the schematic, the target is an inline frame, innerframe, which before making a selection has dimensions of 0 x 0 pixels (ie. it is not visible). Please refer to the Client-Side Event Handler section for details on how the frame is resized based on the dimensions of the SVG image. Please refer to the appendices for full HTML code for the GUI including the onsubmit function just described.

5. Conclusions

The aim of this paper was to research and develop techniques for representing Graphical User Interfaces (GUI) of EDA Tools via the Internet on a remote Web browser. Substantial Market Research was performed in order to forge an understanding of the EDA industry. Through this research, the potential for Web-based business models was realised which helped to justify the work undertaken. It was decided that the Scalable Vector Graphics (SVG) format was the most suitable option for displaying circuit schematics translated from EDIF netlists via EdaXML. A demonstration program was developed to allow the script to read-in a required netlist and library, generate and then display the resulting SVG graphic in the browser window. Although the demonstration model is limited to certain complexities of netlists, it does serve effectively as a proof of concept. Integrating the script into a full Web-based GUI for an EDA Tool would still require substantial work, this document serving as a user guide and direction pointer for further development.

6. Further Work

6.1 Technology Improvements

The main technology used for building the system described in this document is Microsoft’s Active Server Pages. Web applications have been successfully developed using ASP since the late 1990s and advanced dynamic Web systems are still being developed today with this tried and tested technology. However, over the last few years, Microsoft’s latest offering for providing high-end Web Services has eclipsed ASP in terms of functionality and power. With this newer ASP.Net platform now well established, its stability and credibility ever increasing, it seems logical that the next step in improving the performance and interoperability of the system is to upgrade the program in line with this. Although the requirements specification has been met in this project, there is always room for improvement, and rewriting the program for a platform that boasts the power and compatibility of Dot Net can only result in a better end product.

6.2 Software Integration

The script and demonstration program at the time of writing has been employed as a standalone application only. For the script to operate within a full GUI of an EDA Tool, it would need amendment. It would be quite straight-forward to edit the script in order to allow another process call it, and pass the netlist provided it was within the systems capabilities as described earlier. The response of the script would be to simply display the schematic image. However, if a full GUI was required, there would be a desire for much more functionality of the SVG, with functions sent back to the GUI for processing, enabling full route-planning and timing analysis. The employment of the Dot Net framework described above would ensure this was a much closer target.

6.3 Mobile SVG

Within the last year a lot of development has gone into bringing Scalable Vector Graphics to mobile devices (phones, PDAs etc). The W3C’s Tiny SVG specification has been used to develop products such as ZoomOn and BitFlash. SVG renderers are now available commercially for Windows CE and Symbian among other mobile operating systems. Provided the device has Internet access, there is no reason why this translator software cannot be run. Some minor changes might need to be made to the system – graphical layout of GUI enhanced for a smaller screen view, and SVG source altered slightly to adhere to the SVG Tiny specification. The system would then enable mobile users to take full advantage of the application.

6.4 Other Applications

There is potential for SVG circuit schematics to be used for many other applications. For example, an application could be developed for educational purposes at a low-level of understanding. Primary and secondary educational institutes are always researching alternative methods of teaching; a common buzz-word at the moment being e-learning. A graphically friendly web-based electronics learning tool, among other things might be useful for such purposes. With declining interest in recent years in secondary level Physics and Mathematics, students might find graphic friendly and easily accessible applications like this a breath of fresh air. A similar system could even be used in Queen’s University for allowing students to perform circuit analysis remotely from their home computers, instead of flocking to busy laboratories for practical work.

Bibliography

[EDAXML]
Electronic Tools Company EdaXML DTD http://www.e-tools.com/xml/dtds/EdaXML.dtd
[SVG 2002]
SVG Open 2002 Conference Proceedings http://www.svgopen.org/2002/
[SVG 2003]
Electronic Tools Company EdaXML DTD http://www.svgopen.org/2003/
[XMLDOM]
Microsoft XML Document Object Modelhttp://www.topxml.com/xml_dom/
[IC03]
A framework for Remote Design Automation with XML Web Services Stephen Dawson, Sakir Sezer (International Conference on Internet Computing ’03)
[Edat]
EDA Recovery Starts Up, Slowly But Surelyhttp://www.edat.com/NEA22.htm
[EEDesign]
EDA versus Dot.com Enterprise http://www.eedesign.com/editorial/2000/editorial0005.html
[EEDesign2]
Panel sees dot-com revolution for design http://www.eedesign.com/story/showArticle.jhtml?articleID=18303365
[Tech]
Evolving Business Models are Key to Web-Enabling EDA http://www.techonline.com/community/tech_topic/web_enabled_design/feature_article/11126
[EEDesign3]
Debaters tackle tough EDA issues http://www.eedesign.com/story/showArticle.jhtml?articleID=17406104
[EEDesign4]
Web-based EDA tools find limited acceptance http://www.eedesign.com/story/showArticle.jhtml?articleID=12805520
[Tech2]
View from the Top of the EDA Mountain http://www.techonline.com/community/related_content/5425

XHTML rendition created by gcapaper Web Publisher v2.0, © 2001-3 Schema Software Inc.