SWA: SoftWare for Analog Design Automation

Abstract

We have developed SWA: SoftWare for Analog design automation. Its commands can describe analog and mixed-signal (AMS) layouts and schematics to replace the graphic editor with a program reflecting the knowledge of design experts. Also, it is able to utilize variables to parameterize schematics and layouts to fulfill design needs. We programmed a 10b 1 GS/s DAC using SWA with 8.3 K lines of code, which is about 1/10 compared with conventional programs. The programmed DAC is configurable with multiple voltages and multiple resolutions from 4 to 12 bits. The DAC schematic and layout generation with DRC and LVS SWA API can be finished in about 1 min.

1. Introduction

Over the decades, EDA technology has advanced toward higher abstraction levels to increase productivity. Digital design benefits from behavioral/functional language and standardized cell place and route. However, we have received only a few benefits from analog and mixed-signal (AMS) EDA. AMS behavioral language [1], parameterized cells [2,3], and a variety of graphics editor commands have been major progressions in this area.

Parameterized cells are based on a polygonal design, which is very detailed and needs expertise to combine graphical APIs to create a PCell because graphical APIs provide many primitive functionalities, and they must be combined for the required result to be obtained.

Automated layout design methods, including constraint-based approaches [4,5,6,7,8,9] and module generators [10,11,12,13], operate at a high level. The constraint-based approach may introduce a new type of constraint for a new circuit application and is in the investigation stage. Module generators provide enhancements primarily for average designers. Their application in other design environments is limited because they support specific fabrication processes [14].

We propose SWA: SoftWare for Analog design automation, which can describe AMS layouts and schematics. SWA provides device-level editing to handle transistors, resistors, and capacitors as design objects. A device-level program elevates SWA to a higher abstraction level than PCells. Commercial graphics editors support device-level editing with a huge number of interactive commands. These numerous commands are beneficial for skilled designers but not useful for beginners. In addition, the editing result cannot be used for design standardization.

SWA supports commands for placing pins, elements, labels, and routing. The layout routing command allows layer changes with automatically placed vias. Users utilize variables, and conditional and loop statements to program designs. SWA offers a higher level of abstraction than parameterized cells, which handle polygons as design objects. It can parameterize everything, including device parameters (W, L, NF), bus sizing, and circuit connections. However, these parameters cannot be altered in graphics editors.

Element locations and routing points can be programmed as variables, arrays, or structural data types. Once an SWA program is created, it runs with different variable values with good repeatability, provided corrections have been made. It is flexible to design changes, not only with element parameters but also in adopting design rule variations.

Figure 1 shows the SWA scheme and SWA modules. The SWA consists of three software modules to program symbol/schematic and layout, and it supports layout verification DRC/LVS/LPE. The schematic programming module handles SWA schematic commands and the command interpreter, while the layout programming module manages SWA layout commands and the command interpreter. The SWA provides DRC/LVS/LPE APIs for specific layout verification tools. Currently, it supports PVS and Assura/QRC. Users can instantly call verification tools from SWA programs.

SWA commands have a list-based structure built on the existing EDA language system. Although SWA currently runs on Cadence Virtuoso SKILL [15,16,17,18,19,20,21], the list data type is supported by various languages, making it easy to convert SWA commands to other languages or EDA tools.

2. SWA Overview

2.1. SWA Basics

Listing 1 shows the skeleton of SWA cell define procedures. They trace cell hierarchy and view representations. The Cell_A procedure (lines 1–5) calls layout (2), schematic (3), and symbol (4) sub-procedures. Each sub-procedure creates its contents data in the database.

Listing 1. SWA program skeleton.

1     Procedure( Cell_A(libName cellName )

2               Cell_A_layout(libName cellName “layout”)

3               Cell_A_schematic(libName cellName “symbol”)

4               Cell_A_symbol(libName cellName “schematic”)

5     )

6        Procedure( Cell_A_layout(lib cell view)

7                  cv = SWA_CheckOpen(lib cell view techfile)

8                  LAY = SWA_list(

9                         list( “%pin” “VDD” “inputOutput” “m1” 0:10 …)

10                       list( “%pInst” “mylib” “mycell” “layout” “M0” …)

11                       list( “%path” “m1” 0:10 …)

12                       ...

13               )

14               SWA_layTrans(cv LAY list(“R0” ‘(0 0)))

15               save(cv)

16               SWA_AUTOPVS_run_drc(…)

17               SWA_AUTOPVS_run_lvs(…)

18             close(cv)

19     )

20     Procedure( Cell_A_schematic( lib cell view)

21               cv = SWA_CheckOpen( lib cell view techfile)

22               CKT = SWA_list(

23                              list(“%pin” “analogLib” “sympin” “symbol” “inputOutput” “VDD”…)

24                              list(“%pInst” “mylib” “nch” “symbol” “M1” 2:10 …)

25                              list(“VDD” 2:10 )

26                       …

27                  )

28                  SWA_sch( cv CKT )

29                  check( cv)

30                  save(cv)

31                  close(cv)

32     )

33     Procedure( Cell_A_symbol( lib cell view )

34           …

34     )

35     Procedure( Process_Change()

37        ;; Define layout grid, layer usage, width and spacing rules

38        ;; for process compatibility

39     )

In layout sub-procedure (6–19), SWA_CheckOpen (7) creates/opens cellview and clears it. The SWA provides procedures to support SWA commands.

Table 1. SWA procedure.

SWA Procedure	Function
SWA_CheckOpen( lib cell view tech )	Create/clear cellview
SWA_list( list list … )	Append command lists
SWA_sym( cv cmd_list )	Symbol command interpreter
SWA_sch( cv cmd_list )	Schematic command interpreter
SWA_layTrans( cv cmd_list [transform])	Layout command interpreter
SWA_AUTOPVS_run_drc( libName cellName viewName drcRuleFiles )	Run DRC
SWA_AUTOPVS_run_lvs( libName cellName viewName ruleFiles )	Run LVS
SWA_AUTOASSURA_run_lvs( … )	Run LVS for LPE
SWA_AUTOASSURA_run_qrc( … )	Run LPE

shows SWA procedures and functions.

An ‘SWA command’ starts with a keyword such as %pin or %pInst and instructs data generation. SWA commands like “%pin”, “%pInst”, and “%path” (9–11) are used for pin placement, parameterized instance placement, and path creation, respectively.

An ‘SWA command list’ is a list of SWA commands. SWA procedure SWA_list combines SWA commands and SWA command lists into one big SWA command list (8).

Table 2. Typical SWA command.

Symbol Commands and Arguments	Function
list(“” type style pointList [width] )	Draw symbol figure
list(“%box” [bBox] )	Draw bounding box
list(“%pin” termName direction origin orient [labelSpec])	Place pin
list(“%NoteLabel” origin labelText orient labelType [height])	Place label
list(“%SymbolLabel” origin choice labelText orient labelType)	Place label with layer choice
Schematic command and arguments	Function
list(“%pin” termName direction origin orient [view])	Place pin
list(“%inst” lib cell view name origin orient )	Place instance
list(“%pInst” lib cell view name origin orient paramList )	Place instance with parameters
list(labelText pointList labelOrigin [labelSpec] )	Route wire with wire labelText
list(“%NoteLabel” origin labelText justify orient labelType height)	Place label
Layout command and arguments	Function
list(“%pin” name direction layer centerPoint width [labelSpec])	Place layout pin
list(“%inst” lib cell view name name point orient)	Place instance
list(“%pInst” lib cell view name point orient paramList)	Place parameterized instance
list(“%path” layer point point … width)	Route wire
list(“%via” viaName point orient paramList)	Place Via
list(“%rect” layers bBox )	Place rectangle
list(“%rect1” layer lowerLeft upperRight )	Place rectangle
list(“%polygon” layer points )	Place polygon
list(“%prBoundary” point point …)	Place boundary
list(“%guardRing” mppName isClosed point point …)	Place MPP guard ring

lists typical SWA commands for each view. SWA command and SWA command list have simple list structure. Any sub-program can be defined to create the lists. Multiple view creation procedures can share a sub-program that creates a SWA command list.

The command interpreter SWA_layTrans (14) accepts an SWA command list and generates layout data in the cellview. It also supports rotation and displacement. After layout data were generated, DRC and LVS (16–17) are performed.

We should add the Process_Change procedure (35–38) to increase fabrications process portability. The procedure is called from the main program. Layout grid, layer usage, design rule width, spacing, and via rule are defined in this procedure and stored in variables. These variables are used in the cellview procedure and will relax process porting efforts.

SWA program-generated design data are stored in an OA database, making them compatible with standard interactive EDA tools. SPICE and layout verification tools can also be applied to the SWA-generated design data.

Designers can sketch a design using the SWA program and then refine it using a text editor. This process is easier than expected. However, if we start with graphics editor data, this process is not possible, and the data becomes bound to the specific EDA vendor’s graphics editor. SWA commands cover enough database operation and hide complex EDA API details from users. Users can utilize the full flexibility of the programming language with standardized SWA commands. In addition, SWA’s command-interpreter model simplifies the process of porting user procedures between EDA tools.

Figure 2 and Listing 2 show SWA command usage for the example schematic diagram. Figure 3 and Listing 3 show SWA command usage for the example layout. Listings 2 and 3 omit codes for terminal coordinate calculation from the instance location, rotation, and terminal displacement for simplicity. Listing 4 shows the conventional programming for Figure 3 layout in pseudo-API code. Comparing Listings 3 and 4, we can see that API-dependent commands and command combinations are hidden and generalized in SWA commands Listings 2 and 3.

Listing 2. SWA commands for Figure 2 example schematic.

1  cirmirSch = SWA_list(

2      (“%pin” “AVSS” “inputOutput” 0.0:0.0 “R0” nil)

3      (“%pin” “CIN” “inputOutput” 5.0:11.0 “R0” nil)

4      (“%pin” “COUT” “inputOutput” 13.0:11.0 “R0” nil)

5      (“%pInst” “myLib” “nch” “symbol” “M1” 7.0:4.5 “MY”

‘((“W” “string” “0.3u”) (“1” “string” “65n”) (“fingers” “string” “2”)))

6      (“%pInst” “myLib” “nch” “symbol” “M2” 11.0:4.5 “R0”

‘((“W” “string” “0.3u”) (“1” “string” “65n”) (“fingers” “string” “2”)))

7      (“” list(0.0:0.0 5.0:0.0) 0)

8      (“” list(5.0:0.0 5.0:3.0) 0)

9      (“” list(5.0:4.5 3.0:4.5) 0)

10    (“” list(3.0:4.5 3.0:0.0) 0)

11    (“” list(7.0:4.5 11.0:4.5) 0)

12    (“” list(7.0:4.5 9.0:4.5) 0)

13    (“” list(9.0:4.5 9.0:6.0) 0)

14    (“” list(9.0:6.0 5.0:6.0) 0)

15    (“” list(0.0:0.0 13.0:0.0) 0)

16    (“” list(13.0:0.0 13.0:3.0) 0)

17    (“” list(13.0:4.5 15.0:4.5) 0)

18    (“” list(15.0:4.5 15.0:0.0) 0)

19    (“” list(15.0:0.0 13.0:0.0) 0)

20    (“” list(5.0:6.0 5.0:11.0) 0)

21    (“” list(13.0:6.0 13.0:11.0) 0)

22  )

Listing 3. SWA commands for Figure 3 example layout.

1        curmirLay = SWA_list(

2              (“%pInst” “myLib” “nch” “layout” “M1” 0.5:0.6 “R0”

‘((“W” “string” “0.3u”) (“1” “string” “65n”) (“fingers” “string” “2”)))

3              (“%pInst” “myLib” “nch” “layout” “M2” 1.44:0.6 “R0”

‘((“W” “string” “0.3u”) (“1” “string” “65n”) (“fingers” “string” “2”)))

4              (“%pin” “AVSS” “inputOutput” “M1” 0.3:0.0 0.2 “centerCenter” “R0” 0.0625)

5              (“%path1” “M1” list(1.0:0.0 2.0:0.0) 0.2)

6              (“%path1” “M1” list(0.4:0.75 0.4:0.0) 0.09)

7              (“%path1” “M1” list(0.93:0.75 0.93:0.0) 0.09)

8              (“%path1” “M1” list(1.34:0.75 1.34:0.0) 0.09)

9              (“%path1” “M1” list(1.87:0.75 1.87:0.0) 0.09)

10            (“%pin” “CIN” “inputOutput” “M2” 0.665:1.6 0.1 “centerCenter” “R0” 0.0625)

11            (“%path1” “M1” list(0.665:0.75 0.665:1.4) 0.09)

12            (“%via1” “M2_M1”0.665:1.4 “R0” ‘((“cutColumns” 1) (“cutRows” 1)

(“cutSpacing” (0.13 0.13)) (“layer1Enc” (0.04 0.04)) (“layer2Enc” (0.04 0.04))))

13            (“%path1” “M2” list(0.665:1.4 0.665:1.6) 0.09)

14            (“%pin” “COUT” “inputOutput” “M2” 1.605:1.6 0.1 “centerCenter” “R0” 0.0625)

15            (“%path1” “M1” list(1.605:0.75 1.605:1.4) 0.09)

16            (“%via1” “M2_M1”1.605:1.4 “R0” ‘((“cutColumns” 1) (“cutRows” 1)

(“cutSpacing” (0.13 0.13)) (“layer1Enc” (0.04 0.04)) (“layer2Enc” (0.04 0.04))))

17            (“%path1” “M2” list(1.605:1.4 1.605:1.6) 0.09)

18            (“rect1” “PO” 0.5:1.04 0.565:1.19)

19            (“rect1” “PO” 0.765:1.04 0.83:1.19)

20            (“rect1” “PO” 1.44:1.04 1.505:1.19)

21            (“rect1” “PO” 1.705:1.04 1.77:1.19)

22            (“rect1” “PO” (0.5 1.19) (1.77 1.12))

23            (“%path1” “PO” list(0.83:1.155 1.135:1.155) 0.07)

24            (“%via1” “M1_PO” 1.135:1.155 “R0” ‘((“cutColumns” 1) (“cutRows” 1)

(“cutSpacing” (0.14 0.14)) (“layer1Enc” (0.04 0.04)) (“layer2Enc” (0.04 0.04))))

25            (“%path1” “M1” list(1.135:1.155 0.665:1.155) 0.07)

26            (“%guardring” “PSubGuardring” nil 0.4:0.0 2.0:0.0 1.9:0.0)

27            (“rect1” “NP” 0.195:0.26 2.075:1.4)

28          )

Listing 4. Conventional programming for Figure 3 example layout.

1    techVia = FindViaByName(getTechFile(cv) “M2_M1”)

2    createVia(cv techVia 0.665:1.4 “R0” ’((“cutSpacing” (0.130 0.130))))

3    createVia(cv techVia 1.605:1.4 “R0” ’((“cutSpacing” (0.130 0.130))))

4    techViaPO = FindViaByName(getTechFile(cv) “M1_PO”)

5    createVia(cv techViaPO 1.135:1.155 “R0” ’((“cutSpacing” (0.140 0.140))))

6    ;;

7    createPath(cv list(“PO” “drawing”) list(0.83:1.155 1.135:1.155) 0.07 “truncateExtend”)

8    createRect(cv list(“PO” “drawing”) list(0.5:1.12 1.77:1.19))

9    createRect(cv list(“PO” “drawing”) list(1.705:1.04 1.77:1.19))

10  createRect(cv list(“PO” “drawing”) list(1.440:1.04 1.505:1.19))

11  createRect(cv list(“PO” “drawing”) list(0.765:1.04 0.83:1.19))

12  createRect(cv list(“PO” “drawing”) list(0.5:1.040 0.565:1.19))

13  createPath(cv list("OD" “drawing”) list(0.4:0.0 1.9:0.0) 0.17 “extendExtend”)

14  createPath(cv list(“M1” “drawing”) list(0.4:0.0 1.9:0.0) 0.19 “extendExtend”)

15  createPath(cv list(“M1” “drawing”) list(1.135:1.155 0.665:1.155) 0.09 “truncateExtend”)

16  createPath(cv list(“M1” “drawing”) list(1.605:0.75 1.605:1.4) 0.09 “truncateExtend”)

17  createPath(cv list(“M1” “drawing”) list(0.665:0.75 0.665:1.4) 0.09 “truncateExtend”)

18  createPath(cv list(“M1” “drawing”) list(1.87:0.75 1.87:0.0) 0.09 “truncateExtend”)

19  createPath(cv list(“M1” “drawing”) list(1.34:0.75 1.34:0.0) 0.09 “truncateExtend”)

20  createPath(cv list(“M1” “drawing”) list(0.93:0.75 0.93:0.0) 0.09 “truncateExtend”)

21  createPath(cv list(“M1” “drawing”) list(0.4:0.75 0.4:0.0) 0.09 “truncateExtend”)

22  createPath(cv list(“M1” “drawing”) list(1.0:0.0 2.0:0.0) 0.2 “truncateExtend”)

23  pinAVSS = createRect(cv list(“M1” “drawing”) list(0.2:-0.1 0.4:0.1))

24  createRect(cv list("CO" “drawing”) list(1.81:-0.045 1.9:0.045))

25  createRect(cv list("CO" “drawing”) list(1.61:-0.045 1.7:0.045))

26  createRect(cv list("CO" “drawing”) list(1.41:-0.045 1.5:0.045))

27  createRect(cv list("CO" “drawing”) list(1.21:-0.045 1.3:0.045))

28  createRect(cv list("CO" “drawing”) list(1.01:-0.045 1.1:0.045))

29  createRect(cv list("CO" “drawing”) list(0.81:-0.045 0.9:0.045))

30  createRect(cv list("CO" “drawing”) list(0.605:-0.045 0.695:0.045))

31  createRect(cv list("CO" “drawing”) list(0.40:-0.045 0.49:0.045))

32  pin_CIN = createRect(cv list(“NP” “drawing”) list(0.195:0.26 2.075:1.4))

33  label = createLabel(cv list(“M1” “pin”) 0.3:0.0 “AVSS” “centerCenter” “R0” “stick” 0.063)

34  createPath(cv list(“M2” “drawing”) list(1.605:1.40 1.605:1.6) 0.1 “truncateExtend”)

35  pinCOUT = createRect(cv list(“M2” “drawing”) list(1.555:1.55 1.655:1.6

36  createPath(cv list(“M2” “drawing”) list(0.665:1.4 0.665:1.6) 0.1 “truncateExtend”)

37  createRect(cv list(“M2” “drawing”) list(0.615:1.55 0.71:1.65))

38  label = createLabel(cv list(“M2” “pin”) 1.605:1.6 “COUT” “centerCenter” “R0” “stick” 0.063)

39  label = createLabel(cv list(“M2” “pin”) 0.0665:1.6 “CIN” “centerCenter” “R0” “stick” 0.063)

40  createPath(cv list("PP" “drawing”) list(0.4:0.0 1.9:0.0) 0.43 “extendExtend”)

41  ;;

42  nchSym = OpenCellView(“myLib” “nch” “layout”)

43  nchM2 = createInst(cv nchSym “M2” 1.44:0.6 “R0” 0)

44  createProp(nchM2 “W” “string” “300n”)

45  createProp(nchM2 “1” “string” “65.0n”)

46  createProp(nchM2 “fingers” “string” “2”)

47  createInst(cv nchSym “M1” 0.5:0.6 “R0” 0)

48  createProp(nchM1 “W” “string” “300n”)

49  createProp(nchM1 “1” “string” “65.0n”)

50  createProp(nchM1 “fingers” “string” “2”)

51  ;;

52  netAVSS = createNet(cv “AVSS” nil)

53  netCIN = createNet(cv “CIN” nil)

54  netCOUT = createNet(cv “COUT” nil)

55  createTerm(netAVSS “AVSS” “inputOutput”)

56  createTerm(netCIN “CIN” “inputOutput”)

57  createTerm(netCOUT “COUT” “inputOutput”)

58  createPin(netAVSS pinAVSS “AVSS”)

59  createPin(netCIN pinCIN “CIN”)

60  createPin(netCOUT pinCOUT “COUT”)

2.2. SWA Macro Commands

Using the SWA command, we must perform trivial tasks in the user program. To locate an instance terminal coordinate, we need to know the terminal name and its location in the master cellview to calculate the coordinate before starting programming. Multiple %path and %via commands are requested for a single route when via and layer/width changes are involved in the route. We added macro commands to reduce these trivial tasks from the user’s program.

A macro command is a procedure that returns an SWA command list, allowing macro commands to be placed in SWA_list just like simple SWA commands. The placement macro SWA_schPInst searches terminals/pins in the instance master and then translates the coordinates to the user cell axis based on the instance origin and orientation. The SKILL symbol, having the same name as the instance name, is used to hold the terminal/pin information in the symbol property.

These properties can be accessed using the dot operator, which functions similarly to Python class instance variable access. When placing an M1 transistor using the SWA_schPInst macro, the symbol’s properties M1.D, M1.G, and M1.S hold the coordinates of the Drain, Gate, and Source locations in the user cellview axes. The pin placement command operates in the same manner.

Table 3. SWA schematic macro command and property.

Schematic Macro Procedure Interface	Function
SWA_schPin( termName direction origin orient [view] )	Place schematic termina/pin.
SWA_schPInst( libName cellName viewName name origin orient paramList )	Place symbol instance with parameter specified.
SWA_schWire( startPoint (move|label)… )	Route wire segments with the relative coordinate move.
SWA_schPin generated property	Property value
<termName>.xy	Terminal location in schematic, list(x y)
<pinName>.xy	Pin location in schematic, list(x y)
SWA_schInst generated property	Property value
<name>.<termName>	Terminal location in schematic, list(x y)
<name>.<pinName>	Pin location in schematic, list(x y)

and

Table 4. SWA symbol macro command and property.

Symbol Macro Procedure Interface	Function
SWA_symPin( termName direction origin orient [labelSpec] )	Place symbol terminal/pin, optionally place pin label.
SWA_symShape( type [?style style] point point … )	Draw a symbol figure.
SWA_symPin generated property	Property value
<termName>.xy	Terminal location, list(x y)
<pinName>.xy	Pin location, list(x y)

show the schematic and symbol macro commands and properties. Listing 5 shows the macro command programming for the example schematic in Figure 2.

Listing 5. SWA macro command for Figure 2 example schematic.

1  procedure( SWA_CURMIR_sch( lib cell view )

2  prog( (cv trProps cirmir)

3       cv = SWA_CheckOpen( lib cell view SWA_techname )

4       trProps = list(

5            ’(“W” “string” “0.3u”) ’(“1” “string” “65n”) ’(“fingers” “string” “2”)

6       )

7       curmir = SWA_list(

8            SWA_schPin( “AVSS” “inputOutput” 0.0:0.0 “R0” )

9            SWA_schPin( “CIN” “inputOutput” 5.0:11.0 “R0” )

10         SWA_schPin( “COUT” “inputOutput” 13.0:11.0 “R0” )

11

12         SWA_schPInst( “myLib” “nch” “symbol” “M1” 7.0:4.5 “MY” trProps )

13         SWA_schPInst( “myLib” “nch” “symbol” “M2” 11.0:4.5 “R0” trProps )

14

15         SWA_schWire( AVSS.xy “abs” xCoord(M1.S):0.0 “abs” M1.S )

16         SWA_schWire( M1.B -2.0:0 0.0:-4.5 )

17         SWA_schWire( M1.G “abs” M2.G )

18         SWA_schWire( M1.G 2.0:0.0 0.0:1.5 “abs” M1.D )

19         SWA_schWire( AVSS.xy “abs” xCoord(M2.S):0.0 “abs” M2.S )

20         SWA_schWire( M2.B 2.0:0 0.0:-4.5 -2.0:0.0)

21         SWA_schWire( M1.D “abs” CIN.xy )

22         SWA_schWire( M2.D “abs” COUT.xy )

23    )

24    SWA_sch( cv curmir )

25    check( cv )

26    save( cv )

27    close( cv )

28  )

29  )

A layout macro sets more layout-specific information than a schematic. The pin center coordinate, pin layer, pin bounding box, and instance boundary are held by symbol properties. The SWA_layInst and SWA_layPInst macros set pin information.

Table 5. SWA layout macro command.

Layout Macro Procedure Interface	Function
SWA_layPin( termName direction layer origin [size [labelParameters]])	Place layout pin.
SWA_layInst( libName cellName viewName name origin orient)	Place layout instance.
SWA_layPInst( cv libName cellName viewName name origin orient paramList)	Place layout PCell with parameters.
SWA_layWire( cmd0 cmd…)	Route wire segments allowing layer change with vias, and segment width change.
SWA_prBoundary( point point …)	Draw a bounding box.
SWA_layRect( layer point1 point2 [mode] )	Draw rectangle.
SWA_layLabel( labelText layer origin [justify [orient [font [height]]]])	Place text label.
SWA_layGR( mppName [closed] point…)	Draw an MPP guard ring. MPP setting is taken from the technology database.
SWA_layAlignMOSPins( SWA_layPInst command which places MOS PCell)	Place MOS PCell instance. Pin names are aligned from left to right, bottom to top. Ex. SD0, SD1, SD2, …

lists layout macro and

Table 6. SWA layout macro property.

SWA_layPin Generated Property	Property Value
<termName | pinName>.lxy	list(layer centerXY pinBBox)
<termName | pinName>.layer	Layer of the pin
<termName | pinName>.xy	Pin center location, centerXY
<termName | pinName>.x	xCoord(centerXY)
<termName | pinName>.y	yCoord(centerXY)
<termName | pinName>.llx	xCoord(lowerLeft(pinBBox))
<termName | pinName>.lly	yCoord(lowerLeft(pinBBox))
<termName | pinName>.urx	xCoord(upperRight(pinBBox))
<termName | pinName>.ury	yCoord(upperRight(pinBBox))
<termName | pinName>.bBox	pinBBox
SWA_layInst generated property	Property value
<name>.<termName | pinName>	list(layer centerXY pinBBox)
<name>.<termName | pinName>_layer	Layer of the pin
<name>.<termName | pinName>_xy	Pin center location, centerXY
<name>.<termName | pinName>_x	xCoord(centerXY)
<name>.<termName | pinName>_y	yCoord(centerXY)
<name>.<termName | pinName>_llx	xCoord(lowerLeft(pinBBox))
<name>.<termName | pinName>_lly	yCoord(lowerLeft(pinBBox))
<name>.<termName | pinName>_urx	xCoord(upperRight(pinBBox))
<name>.<termName | pinName>_ury	yCoord(upperRight(pinBBox))
<name>.prBBox	Instance boundary

shows layout macro properties.

SWA_layWire is a layout routing macro. It supports layer changes with stacked via placement and width changes. It accepts <instanceName>.<terminalName> property as an argument and takes layer and coordinate information from the property.

Listing 6 demonstrates how symbol properties are utilized. The AVSS, CIN, COUT pins, and M1, M2 transistor terminal layers and coordinates are stored in AVSS, CIN, COUT, M1, and M2 symbol properties. These properties are then used in SWA_layWire to specify the starting layers and points for the wires.

Listing 6. SWA macro command for Figure 3 example layout.

1  procedure( SWA_CURMIR_lay( lib cell view )

2  prog( (cv trProp cirmir)

3       cv = SWA_CheckOpen( lib cell view SWA_techname )

4       trProps = list(

5            ’(“W” “string” “0.3u”) ’(“1” “string” “65n”) ’(“fingers” “string” “2”)

6       )

7       curmir = SWA_list(

8            ;; M1

9            SWA_layAlignMOSPins(

10              SWA_layPInst( cv “myLib” “nch” “layout” “M1” 0.5:0.6 “R0” trProps )

11        )

12        ;; M2

13        SWA_layAlignMOSPins(

14            SWA_layPInst( cv “myLib” “nch” “layout” “M2” 1.44:0.6 “R0” trProps )

15        )

16        ;; AVSS

17        SWA_layPin( “AVSS” “inputOutput” “M1” 0.3:0.0 0.2 )

18        SWA_layWire( “M1” 0.2 1.0:0.0 2.0:0.0 )

19        SWA_layWire( M1.SD0 xCoord(M1.SD0_xy):0.0 )

20        SWA_layWire( M1.SD2 xCoord(M1.SD2_xy):0.0 )

21        SWA_layWire( M2.SD0 xCoord(M2.SD0_xy):0.0 )

22        SWA_layWire( M2.SD2 xCoord(M2.SD2_xy):0.0 )

23        ;; CIN

24        SWA_layPin( “CIN” “inputOutput” “M2” xCoord(M1.SD1_xy):1.6 0.10 )

25        SWA_layWire( M1.SD1 xCoord(M1.SD1_xy):1.4 “M2” CIN.xy )

26        ;; COUT

27        SWA_layPin( “COUT” “inputOutput” “M2” xCoord(M2.SD1_xy):1.6 0.10 )

28        SWA_layWire( M2.SD1 xCoord(M2.SD1_xy):1.4 “M2” COUT.xy )

29        ;; Gate

30        SWA_layRect( “PO” M1.G0_llx:M1.G0_ury M1.G0_urx:M1.G0_ury+0.15 )

31        SWA_layRect( “PO” M1.G1_llx:M1.G1_ury M1.G1_urx:M1.G1_ury+0.15 )

32        SWA_layRect( “PO” M2.G0_llx:M2.G0_ury M2.G0_urx:M2.G0_ury+0.15 )

33        SWA_layRect( “PO” M2.G1_llx:M2.G1_ury M2.G1_urx:M2.G1_ury+0.15 )

34        SWA_layRect( “PO” M1.G0_llx:M2.G1_ury+0.15 M2.G1_urx:M2.G1_ury+0.15-0.070 )

35        SWA_layWire( “PO” 0.07 M1.G1_urx:M1.G1_ury+0.15-0.035

36             1.135:M1.G1_ury+0.15-0.035 “M1” xCoord(M1.SD1_xy):M1.G1_ury+0.15-0.035 )

37        ;; SUB

38        SWA_layGR(“PSubGuardring” nil 0.4:0.0 2.0:0.0 1.9:0.0)

39        SWA_layRect( “NP” 0.195:0.26 2.075:1.4 )

40    )

41    SWA_layTrans( cv curmir list(0.0:0.0 “R0”) )

42    save( cv )

43    close( cv )

44  )

45  )

SWA_layWire (lines 25, 28) connects M1.SD1 diffusion terminal to CIN pin, and M2.SD1 diffusion terminal to COUT pin. SWA_layAlignMOSPins gives sequence names SD0, SD1, … for multi-fingered MOS diffusion terminals, G0, G0, … for gate terminals from left to right or bottom to top.

Table 7. Comparison of layout programming between conventional, SWA simple command, and SWA macro command.

Layout	Conventional Programming	SWA Simple Command	SWA Macro Command
Place instance	Define place and route grid foreach instances;   place instance using grid   master=getCellView( lib cell “layout”)   instance=createParameteriseInstance(    cv master name origin orient   parameterList) … )	Define place and route grid. SWA_list(   list (“%pInst” lib cell “layout” name     origin orient parameterList)   … )	Optional: Define place and route grid SWA_list(   SWA_layPInst (lib cell “layout” name     origin orient parameterList)   … )
Place pin	foreach pins   net1=createNet(pin_name1)   term1 = createTerm(name1 name1)   fig1=createRect(cv layer1 bBox1)   createPin(net1 fig1 pin_name1 term1)   …	SWA_list(   list(“%pin” term1 direction1    layer1 point1 witdth1)     … )	SWA_list(   SWA_layPin(term1 direction1    layer1 point1 width1)     … )
Route wire	foreach route   createPath(cv firstLayer width     point1 point2)   createVia(cv viaName point2      orient viaParameter)   createPath(cv secondLayer width1      point2 point3)    createPath(cv secondLayer width2      point3 point4)    …	SWA_list(    list(“%path” firstLayer point1 point2      width)    list(“%via” viaName point2 viaParameter)   list(“%path” secondLayer point2 point3     width1)   list(“%path” secondLayer point3 point4      width2)    … )	SWA_list(    SWA_layWire(firstLayer width point1      point2      list(secondLayer viaName        viaParameter)      width1 point3 width2 point4     …    ) )

compares conventional programming, SWA command programming, and SWA macro programming in typical layout tasks. We use a pseudo-API for the conventional part. A conventional layout program requires many API command combinations to achieve the same functionality as SWA commands.

SWA commands are tailored to the designer’s needs, providing a good abstraction for describing designs. However, similar abstractions can be achieved by user sub-programs implemented using conventional APIs that have the same functionality as SWA commands. The key advantage of SWA is that it standardizes APIs, allowing users to share cellview programs without any modifications.

Comparing SWA simple commands with macro commands, program compaction is evident in the macro case. Table 7 does not include pin location calculation codes; thus, a higher compaction rate will be observed in real programming. We skip comparisons in schematic tasks, as the same arguments apply to schematic generation.

2.3. Layout Verification

The SWA includes batch-type DRC, LVS, and LPE APIs. These APIs are shown in Table 1, SWA_AUTOPVS_run_drc and SWA_AUTOPVS_run_lvs.

These APIs perform run the directory setup, GDS output, and CDL output for LVS, then start the layout verification tool execution. They also assist with cell-by-cell layout debugging.

Because these APIs are called during multiple cellview generations, they just return concise information to the user program. The DRC API returns the number of violations. Similarly, the LVS API returns match un-match information.

These APIs save detailed verification results in separate directories for each cell. To observe detailed violations or mismatch reasons, users can open the saved verification results using the interactive debug environment of the EDA tool.

3. Design Example

We have developed an RDAC module generator using SWA. The TSMC 65 nm GP process was utilized, and a sub-micron slice structure [22,23,24,25] was applied. The RDAC has a maximum resolution of 12 bits, with an 8-bit segment DAC in series with a 4-bit R-2R DAC for the lower bits. The RDAC is configurable in resolution, input/output transistor types, and output segment resistor formations. Resolution is allowed between 4 and 12 bits. Bit assignment between segment DAC bit and R2R DAC is allowed.

Table 8. The RDAC configuration.

Type	Logic Tr.	Output Tr.	Resolution
0	1.0 V core	1.0 V core	4–12 bit
1	2.5 V under drive 1.8 V	2.5 V under drive 1.8 V	4–12 bit
2	2.5 V	2.5 V	4–12 bit
3	2.5 V overdrive 3.3 V	2.5 V overdrive 3.3 V	4–12 bit
4	1.0 V core	2.5 V under drive 1.8 V	4–12 bit
5	1.0 V core	2.5 V	4–12 bit
6	1.0 V core	2.5 V overdrive 3.3 V	4–12 bit

shows the RDAC typical configurations. The software nature of SWA enables these large variations.

Figure 4 shows the RDAC layout generated using SWA. A special module was created to allow free series/parallel width/length configuration for output resistors. Element sizing was done outside SWA referencing similar previous designs through theoretical mathematical calculations and simulations. Schematics were generated from extracted netlists to debug and assure layout correctness using a SPICE simulator.

The layout was created using 8.3 K lines of SWA program code. In contrast, conventional programming with SKILL dump estimates 87 K lines. Schematic and layout generation, along with DRC and LVS verification, were completed in 63 s using a 2.4 GHz Xeon processor.

4. Discussion

We evaluated SWA based on abstraction level, cellview program development effort, design quality, and completeness. Device-level programming abstraction is particularly suitable for AMS designs, especially in the analog part, as most analog blocks are designed at the device level. SWA macro commands take this a step further by reducing trivial programming tasks.

The complexity of EDA APIs often hinders designers from creating their designs through programming. SWA provides a necessary and sufficient command API, focusing on objects relevant to the designer’s interests. Additionally, SWA macro commands reduce trivial programming efforts. Layout verification API helps to debug layouts. The programming effort is less than expected due to the ease of fine layout grid tuning compared to graphics editors.

The module generated by SWA maintains a human quality, as it avoids heuristics and simplifications. The design quality is dependent on the designer’s skill and knowledge. The RDAC example demonstrates that expert designer knowledge can be effectively acquired using SWA programming.

For completeness, SWA currently lacks prevention codes for certain design rules, such as the minimum-area and minimum-step maximum-edge rules. This necessitates user correction coding, and we should work on improving this aspect.

Other issues include fabrication process porting and EDA framework porting. For process porting, our current solution to ease the porting effort is to introduce the Process_Change scaling procedure in the user program.

Every EDA framework offers a different API, such as Python [26] or Tcl [27]. Creating a language translator from SKILL to Python or Tcl is not difficult, and user programs can be translated using this translator. However, due to API differences, the SWA command interpreter and macro commands need to be translated manually. We are currently in the trial phase of porting SWA to some open-source or more affordable EDAs [28,29].

Foundry PDKs are currently available only for major EDA frameworks. The readiness of CDF and pCell/PyCell for these tools remains an open issue.

Having a module generation GUI for SWA-programmed modules enhances ease of use. We have developed an RDAC GUI prototype, but it is EDA-dependent [30,31,32]. The GUI includes features such as simulation test bench creation and step-by-step layout verification, including LPE. Generic GUI support would be desirable.

5. Conclusions

We have developed the SWA command language to describe AMS blocks as a program. SWA’s device-level feature provides an advanced abstraction compared to PCells.

With its simple command structure, users can easily program layouts and schematics without needing to learn the EDA API, while still enjoying full programming language flexibility. The SWA macro commands and the layout verification API significantly enhance programming efficiency.

Using SWA, we developed a configurable RDAC module generator with 8.3 K lines of code, which is 1/10 compared with conventional programming. The generation of a 10-bit RDAC schematic and layout, including DRC and LVS, was completed in only about 1 min.

We hope that SWA will encourage more designers to participate in design through programming.