何谓开放性的设计资料库？

一个新世代IC设计资料库大部分的内容，涉及IC设计中用以完成目的（intent）与履行（implementation）的综合资料模组。而具备的高效能、物件导向API（Application Programming Interfaces；应用程式介面）等特质的设计资料库，更可让应用程式开发人员在无须其内部履行细节的情况下轻松使用。

优良的设计资料库是一复杂、精密，支援EDA应用程式中涵盖RTL到光罩（mask）广大范围资料模组的软体系统，且非随着其可用寿命越来越短而老化之过时产品；以Cadence的设计资料库OpenAccess为例，该资料库为一重新设计且具备API定义、参照履行（Reference implementation）、实用层级（Utility classes）、翻译、API使用说明，以及确认套件（Validation Site）等特性的现代化资料库系统，该资料库的设计亦符合业界公用标准，希望能借此达到资源共享的目的。

为共享资源而设计

现今大多数的“开放性”软体很少由私人专有的软体捐赠而不收取任何费用，这些“开放性”软体从未依据各式各样的社群使用需求而设计，不但在功能上有限制，使用上也常令人充满了挫折感。以LEF和DEF为例，由于皆依据Cadence专有的标准所开发，而非开放性软体，因此在软体的使用上将会是一项挑战。相对地，设计资料库软体若能基于“开放性”而制定、设计，对于资源的共享、内容的扩充以及使用端人员来说，都具有重要的意义。

三个建立于相同平台的资料库

《图一 OpenAcces数据库架构》

以OpenAccess为例，它实际上是由三个建立于相同平台上的资料库所组成；如(图一)所示：一为设计资料库（Design database），二为技术资料库（Technology database） ，而第三则为程式库资料库（Library database）。三个子资料库共通的特色，让设计资料库的效能与多功能可维持在一定水准；以下为各子资料库的内容以及所扮演的角色功能：

设计资料库（Design database）

设计资料库提供了设计的资料模型，包括原始外形、实例分层（Instance hierarchy）、逻辑连结、绕线构思（Routing constructs）、空间规划物件（Floorplanning objects）、寄生（Parasitics）、元件萃取资料（ Cell abstract data）与延伸。此资料库陈述着一项设计的区块或模组，而设计资料库的阶层架构允许模组可以参照其他的模组。

技术资料库（Technology database）

技术资料库提供了设计技术上压缩过的资讯，如：光罩阶层（Mask layer）、规则、限制，与延伸。此资料库陈述并管理了由资料库提供的技术相关资讯；在设计过程中技术资料是为所有的模组所共享。

程式库资料库（Library database）

程式库资料库则包含了设计与参照程式库、元件、视野、元件视图（Cellviews），存取管理与延伸等。此资料库陈述了一项设计的组织与架构。使用者通常会自行设计设计程式库（Design library）与参照程式库（Reference library），典型的参照程式库中包含了曾为其他模组使用一次（以上）的模组。相较于参照程式库，设计程式库中的模组则专用于一特定设计。每一种型态的程式库通常只因一特定技术而设计；因此，每一个常见的​​程式库中只有一个技术资料库。

基本功用

在EDA资料模组中遍布了许许多多的基本元件，简单者如：boxes、 points、pointArrays...等在典型的资料模型中均随处可见。开放性存取（Open-Access）的好处在于，它所包含的基本功能物件，除了可让本身的设计资料库之资料模组使用外，其他的应用程式亦能使用。

开放性资料库为EDA工具的新核心

一个开放性设计资料库，不仅是单纯提供资料交换的一种格式，而是可将资料由一应用程式搬移到另一应用程式，或是由一制造供应商软体（Vendor's tool）搬移到另一个，且能达到精确地呈现设计资料与设计目的，并在低度使用记忆体空间的情况下仍能达到高效能目标。低度记忆体使用量与高度效能似乎两相冲突而无法同时兼顾，但以若能充分使用资料杂凑（Data hashing）与快取（Caching）等复杂的技术，在执行效能衰减极低的前提下，尽可能地压缩记忆体的使用量，即可大幅度地压缩在记忆体中的资料，并于资料存取或快取时解压缩，使资料在读、写或修改时能直接使用而不必解压缩。

开发优质的软体为必要条件

能将设计资料库设计成符合EDA标准，是需要在架构设计与程式开发两方面投注大量心力的，过去的软体的功能在撰写完成后虽可正常运作，但其语法通常不够简洁、说明文件不够详尽而令人难以理解，或需要一大群的程式开发人员来维护；很显然地，这些缺点是无法由社群（Community）所拥有、维护的资料库程式码所接受。为解决这样的问题，开发团队必须在“表现特殊的资料库”与“易于维护与发展的程式码”两大议题上进行资料库的设计；而资料库内容的简化，以及资料库应用程式介面是否方便使用者学习使用等议题，都是必须考量的重点。以下为设计资料库架构的两大核心技术（以Open Access为例）：

1.物件导向结构与设计

物件导向架构使得资料模组更加易于了解与使用，物件导向的架构除了在“设计（Design）”与“履行（Implementation）”的组织上是一个非常有效的方法外，更使资料模组在运转（work）与发展（evolve）上更为容易。而在确保可建构出一功能（Function）的同时，亦需兼顾到使用介面的简洁与效率，经由此介面，设计应用程式可以接触到预期中的资料模组，而在履行（Implementation）的过程中所做的变更并不会对应用程式码造成影响。

2.最新的C++ Implementation

开放性资料库具备了公有（Public）与私有（Private）两种类别的特质；公有类别仅以一无任何资料使用的介面作为公有应用程式介面，在公有应用程式介面中，其参数是经过验证且执行绪的安全性是得到保证的；公有的方法所著重的是只需牺牲些微的执行效能便可得到更容易的使用方式。

对于私有类别而言，执行（Implementation）属于完全隐藏的内部行为。由于没有参数验证，使得开发人员必须处理执行绪的同步（Synchronization）。私有类别在使用上需要开发人员所拥有的专业知识，然而这对一般使用者并非一项难题，因为只有开发人员在资料库上对自身进行存取（Implementation itself）时才需要私有类别。

共同API的主要特色

应用程式介面（Application Programming Interfaces；API）在此被特别强调，原因在于大部分应用程式开发错误皆发现于编译时期。 API不使用内嵌方法（In-line method），而相反地改采完整封装的履行方式（Implementation），使其在变更后无需将应用程式重新编译。在设计上为了执行绪的安全，API亦提供了内建式名称映对（Name-mapping）。在类别管理上并不依赖建构子（Constructor）与解构子（Destructor）；在虚拟方法（Virtual method）时，并不使用虚拟表格指标（Virtual table pointer），而改为储存至少4位元组的资料库物件。

例外（Exception）

例外处理在C语言中并不存在，但它在C++中却属于一般的技能。透过典型的资料库应用程式介面，每一次的资料库呼叫皆会回传一状态值（Status）。应用程式开人员花费过多的时间在先产生呼叫（Calls），在依据回传的状态值判断呼叫的过程是否正常。对于每一个发出的资料库呼叫，皆必须对其回传值进行相同次数的错误检查（Error checking），如此大量的错误检查动作使得该执行哪一段的程式码变得很难抉择，也迫使大多数的应用程式开发人员省略了错误检查的步骤，更极有可能因尚未检测出的错误而导致程式码毁损。

若利用了C++的例外处理机制，资料库呼叫就不会回传状态值；相反地，程式开发人员只写入程式码，插入中央例外处理装置（Exception handler）并省略错误检查的手续。当有错误发生时，资料库会发出一“例外”（Exception）讯号，而此呼叫将不被传回；而发出的例外讯号将由应用程式的例外处理机制所“捕获”。集中式错误处理能在确保程式码健全的同时，将履行的困难度降至最低。

复原与重做

将变更复原的能力对于互动式的应用程式而言是很重要的；复原与重做这两项功能支援所有的应用程式呼叫，应用程式可制定其复原检查点（Undo checkpoint），而且每一资料库皆拥有多达128的复原层级（Undo level）。在任一个复原检查点，应用程式皆可对资料库发出“复原”的要求；而资料库中的资料也会依据要求而倒回（Rewound）至上个检查点。同样地，应用程式亦可对资料库发出“重做”（Redo）的要求，则资料库中该点的资料将被回复至上次使用'复原'指令时的最新状态。由于执行“复原”需要适当的资源开销（Overhead），因此该功能的提供与否是可以选择的，此选项在进行大范围的修改时是很方便的。

集合（Collections）与游标（Iterators）

“集合”一词在API中代表着1：N（一对多）关系的意思，如元件视图（Cell-views）中的实例目录（Instance list）或网络中的路径（Route）。这些集合可能是实际或虚拟的，但它们全都支援方法中的共同集合（Common sets）。 API的游标列举了集合（Collection）中的内容；而集合（Collections）与游标（Iterators）的轻量性（lightweight），更在资料库内容的取得上提供了最快速的方法。另外，为了使用上的便利性，其履行（Implementation）将以样版（Template）完成。

扩充性（Extensions）

无论多么完善的资料库，应用程式仍会依其需求将资料库加以修改，其根本原因在于单一资料模组是无法满足每一种应用程式的需求。因此需提供许多机制允许应用程式去扩充资料库的资料模组，其中一项便是增加应用程式专属的资料成员（data member）；这项机制需适用于资料库资料模组中的每一个物件，如此应用程式便可依设计需求而增加其资料成员。资料成员的型态可能为(表一)的其中一员。

《表一 》

设计上，应用程式也会产生其专属的资料库物件；藉由应用程式专属的资料库物件与资料成员的辅助，应用程式的资料模组延伸得以更加复杂。

应用程式专属的延伸（Extension）与资料库原本的资料物件、资料成员同样都具备小而快的特质，这是因为其履行方式与资料库原本的资料物件及资料成员相同的缘故；过多的一般延伸机制（Common extension mechanisms）所造成的大量负担，只会使效能低落和增加记忆体的消耗。

名称映对的重要性

似乎所有的EDA应用程式都各自独立开发且渐趋成熟，也同时采用各自所宣称的“合法名称（legal name）”标记法则，而这些名称必须遵循一包含向量标记（Vector notation）、保留符号（ Reserved symbol）与保留关键字（Reserved keywords）之特定语法。由于两种应用程式所使用的名称空间可能不同或相互冲突，使其在合作的应用上显得困难重重，其原因可能在于某一名称（Name）对于某一应用程式是合法的（Legal），但对于另一者而言却是不合法的（Illegal）。

一个具备开放与互通性的资料库，则藉由订定名称与名称空间的标示法则来解决此问题；名称（Name）是一个类似字串（String）的物件，且​​在它被详细规定的名称空间中是唯一的；相反地，名称（Name）无法直接被应用程式读取，应用程式必须先定义一专司“观看（View）”名称的名称空间，并由此名称空间将其转换成一字串后方可读取。

名称之直译与转译

开放性资料库的一项特色是具备直译（Interpret）与转译（Translate）定义在不同名称空间之名称的复杂能力；能达成此目的之最主要关键，是将产生正确名称的职责由“流程配给（Flow issue）”转为“应用程式配给（Application issue）”。不论是何种类型的名称空间（Name space）其名称皆可以“识别码（Identifier）”代表，其转换方式可为“语义上一对一转换（Semantically one-to-one）”、“演算法转换（Algorithmic）”、以及“可逆式转换（Reversible）”。

区域查询（Region Querying）

@内文此特色使应用程式能够有效地搜寻资料库中某特定区域的资料内容，同时这也是资料库对成果交付（Rendering）、互动选取（Interactive selection），与重叠测试（Overlap testing）等动作展现更加执行效能的另一方法，因为上述的动作并不需要资料库履行（Database implemen-tation）。此项查询功能是以阶级的方式运作，而运作的内容则是由应用程式决定。以OpenAccess为例，该资料库的区域查询功能是利用动态二进制树状图实作的；在设计上，此搜寻动作是可于任何时刻终止的，这对于和成果交付（Rendering）一样需要“可中断（Interruptible）”特性的应用程式是非常重要的。

召回（Callback）

这项机制允许多个应用程式在相同计划运行，而仅需保持与资料库和其他应用程式间的同步（Synchronization）。实际上，“召回”可被设定为用来告知应用程式资料库的状态已改变，这项功能对于彼此间独立运作的应用程式而言是很重要的；对成批应用程式（Batch application）来说，应用程式间的自主性（Independence）似乎不存在，但对互动式应用程式而言，却会造成复杂的问题。

举例来说，某一应用程式在运作时也许必须精确地掌握资料库的所有资讯，而其他应用程式对资料库所做的变更，便会对前者产生了问题。基本来说，“召回”是一个透过虚拟呼叫，以告知应用程式资料库的状态已变更的单纯物件，应用程式会建构自己专属的“召回物件（Callback object）”，并提供其物件被呼叫时的相对应方法。

当召回物件产生、销毁、或变更时，皆会“呼叫”（Invoke）其唯一的方法与之对应；其次，所传回的资讯便会送至召回的拥有者（Callback owner；通常为应用程式）以作为检测资料库物件的参考。由于每当资料库发生变更时就会呼叫一次“召回”，因此开发人员必须确认再处理“召回”的过程不会耗费过多的时间。

结语

建构具备开放与互通性设计资料库的目的，是创造出一个所有EDA社群皆可共享的资料库，它并不会为了符合某单一应用程式或公司的需求予以修改，并依循严谨的标准，为达到简洁的程式码、易于了解与维护的目的而撰写。而目前针对资料库开放的议题，部分EDA业者亦已组成了相关联盟与社群，以针对开放性资料库的功能持续进行改进，让资料库的发展能更加完备并符合往后新的需求。

（作者任职于Santos, Cadence Design Systems；编译：Cadence Taiwan）

＜参考文献：

[1] http://www.si2.org/OpenAccess/faq.htm＞