US20070124717A1 - Method and program product for protecting information in EDA tool design views - Google Patents
Method and program product for protecting information in EDA tool design views Download PDFInfo
- Publication number
- US20070124717A1 US20070124717A1 US11/290,368 US29036805A US2007124717A1 US 20070124717 A1 US20070124717 A1 US 20070124717A1 US 29036805 A US29036805 A US 29036805A US 2007124717 A1 US2007124717 A1 US 2007124717A1
- Authority
- US
- United States
- Prior art keywords
- names
- design
- name
- databases
- views
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000013461 design Methods 0.000 title claims abstract description 130
- 238000000034 method Methods 0.000 title claims abstract description 44
- 238000013507 mapping Methods 0.000 claims description 14
- 230000003071 parasitic effect Effects 0.000 claims description 7
- 238000004519 manufacturing process Methods 0.000 claims description 6
- 238000004088 simulation Methods 0.000 abstract description 18
- 238000005516 engineering process Methods 0.000 description 17
- 230000008569 process Effects 0.000 description 17
- 238000003860 storage Methods 0.000 description 7
- 230000015572 biosynthetic process Effects 0.000 description 6
- 238000003786 synthesis reaction Methods 0.000 description 6
- 238000010586 diagram Methods 0.000 description 4
- 230000015654 memory Effects 0.000 description 4
- XUIMIQQOPSSXEZ-UHFFFAOYSA-N Silicon Chemical compound [Si] XUIMIQQOPSSXEZ-UHFFFAOYSA-N 0.000 description 3
- 238000011161 development Methods 0.000 description 3
- 239000004065 semiconductor Substances 0.000 description 3
- 229910052710 silicon Inorganic materials 0.000 description 3
- 239000010703 silicon Substances 0.000 description 3
- 239000000758 substrate Substances 0.000 description 3
- 238000012546 transfer Methods 0.000 description 3
- 238000004458 analytical method Methods 0.000 description 2
- 230000001419 dependent effect Effects 0.000 description 2
- 238000012938 design process Methods 0.000 description 2
- 230000010354 integration Effects 0.000 description 2
- 230000001960 triggered effect Effects 0.000 description 2
- 101100521334 Mus musculus Prom1 gene Proteins 0.000 description 1
- 238000007792 addition Methods 0.000 description 1
- 230000003542 behavioural effect Effects 0.000 description 1
- 239000003990 capacitor Substances 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 238000011960 computer-aided design Methods 0.000 description 1
- 230000002596 correlated effect Effects 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 238000005242 forging Methods 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000012804 iterative process Methods 0.000 description 1
- 229910044991 metal oxide Inorganic materials 0.000 description 1
- 150000004706 metal oxides Chemical class 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
- 238000000638 solvent extraction Methods 0.000 description 1
- 238000001228 spectrum Methods 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
- G06F21/12—Protecting executable software
- G06F21/14—Protecting executable software against software analysis or reverse engineering, e.g. by obfuscation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6209—Protecting access to data via a platform, e.g. using keys or access control rules to a single file or object, e.g. in a secure envelope, encrypted and accessed using a key, or with access control rules appended to the object itself
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
- G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
- G06F21/76—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information in application-specific integrated circuits [ASIC] or field-programmable devices, e.g. field-programmable gate arrays [FPGA] or programmable logic devices [PLD]
Definitions
- the present invention relates generally to the field of computer aided design for digital circuits, and particularly to protecting design information contained in electronic design automation (EDA) models.
- EDA electronic design automation
- CMOS complementary metal-oxide semiconductor
- DSP digital signal processing
- Core designs and models are relatively easy to copy, forge and re-design because they physically exist as data or code on storage devices. Moreover, the increased efficiency brought about by the existence of cores also provides an incentive for unauthorized use, re-use, transfer or sale of these items. As a consequence, while the complexity of designs and methodologies require transferring a significant amount of information to permit usability of the core by a SOC designer, it is becoming more important that efforts be taken to protect the IP transferred to customers, vendors and third parties participating in the SOC design.
- FIG. 1 is a block diagram of one embodiment of the present invention.
- FIG. 2 is an example of a flat gate-level SPEF.
- FIG. 3 shows an example of a module or a core design in a Verilog view.
- FIG. 4 shows the an exemplary format of the Instance Names.
- FIG. 5 shows a mapping of the replacement scheme performed by the design protection system, in accordance with a preferred embodiment of the present invention.
- FIG. 6 shows an example of a protected SPEF, in accordance with a preferred embodiment of the present invention.
- FIG. 7 shows a protected Verilog, in accordance with a preferred embodiment of the present invention.
- FIG. 8 shows a flow diagram of a process for protecting confidential information in design views of an EDA tool, in accordance with a preferred embodiment of the present invention.
- a method and program product for protecting sensitive circuit design information being transferred as part of a simulation model of a circuit design and consequently avoiding unauthorized use of that information is provided, wherein sensitive information such as module names and structures within certain EDA tool design views.
- sensitive information such as module names and structures within certain EDA tool design views.
- the method and system of the present invention enables a SOC designer to use a simulation model of a core design to determine if the operation of the core and components of the simulation model satisfy the designer's needs without permitting access to confidential information contained within the model. This alleviates, in part, reliance on confidentiality agreements between the SOC designer (or company) and IP owner to protect sensitive core design information that might otherwise be embodied in the simulation model.
- Virtual component blocks are typically generated as part of a design process which can involve a number of steps, depending upon the level of abstraction desired for the particular circuit design.
- Chip designers often use electronic design automation (EDA) software tools to assist in the design process, and to allow simulation of a chip design prior to prototyping or production.
- EDA electronic design automation
- Chip design using EDA software tools generally involves an iterative process whereby the chip design is gradually perfected.
- the chip designer builds up a circuit by inputting information at a computer workstation generally having high quality graphic capability so as to display portions of the circuit design as needed.
- HDLs hardware description languages
- Verilog Verilog or VHDL
- the various components of an integrated circuit are initially defined by their functional operations and relevant inputs and outputs. During these design states, the designer generally structures the circuit using considerable hierarchical information, and has typically provided substantial regularity in the design.
- the design of a digital circuit can be represented or specified in different ways within the memory of a computer system. Each type of digital circuit representation is called a view. Different views contain different amounts and types of information regarding the structure of a circuit. Views which contain more information regarding the structure of the circuit require more of the computer's memory and require more of the computer's time to construct and manipulate.
- the actual logic cell implementation is typically determined by logic synthesis, which converts the functional description of the circuit into a specific circuit implementation.
- the logic cells are then “placed” (i.e., given specific coordinate locations in the circuit layout) and “routed” (i.e., wired or connected together according to the designer's circuit definitions).
- the placement and routing software routines generally accept as their input a flattened netlist that has been generated by the logic synthesis process. This flattened or hierarchical netlist identifies the specific logic cell instances from a target standard cell library, and describes the specific cell-to-cell connectivity.
- An IC chip comprises cells and connections between the cells formed on a surface of a semiconductor substrate.
- a cell is a group of one or more circuit elements such as transistors, capacitors and other basic circuit elements grouped to perform a function.
- the IC may include a large number of cells and require complex connections between the cells.
- Each of the cells of an IC may have one or more pins, each of which, in turn, may be connected to one or more other pins of the IC by wires. The wires connecting the pin to the IC are also formed on the surface of the chip.
- a net is a set of two or more interconnected pins and wires, thereby connecting the logic circuits having pins. Because a typical chip has thousands, tens of thousands or hundreds of thousands of pins that must be connected in various combinations, the chip also includes definitions of thousands, tens of thousands, or hundreds of thousands of “nets”, or connections of sets of pins. The number of nets for a chip is typically of the same order as the order of the number of cells on that chip. Commonly, a majority of the nets include only two pins to be connected; however, many nets comprise three or more pins. Some nets may include hundreds or tens of thousands of pins to be connected.
- An IC model is a set of interconnected circuit cells and nets typically represented in a HDL, and is sometimes interchangeably referred to herein as a module, core, intellectual property (IP), IP block, block, or component.
- a core is an electronic design implementable in hardware, typically specified in HDL, and also typically represented in a top-level netlist.
- a “netlist” is a list of nets (“Net Names”) including names of connected pins or list of cells (“Instance Names”) including names of nets that connect to pins of cells.
- Top-level RTL is synthesized to generate a gate-level netlist at a lower level of abstraction. After the synthesis of the design, the gate-level netlist is verified, the layout of the circuit is determined, and the IC is fabricated.
- HDL Hardware Description Language
- the HDL methodology begins with the IC being specified by a specification document. Then, the IC specification is written to a high-level HDL code at a level of design abstraction referred to as the Register Transfer Language (RTL).
- RTL code describes circuits as a collection of registers, Boolean equations, and control logic such as “if-then-else” statements as well as complex event sequences.
- RTL code is typically implemented using a HDL language such as Verilog-HDL (“Verilog”) or VHDL at the RTL level of abstraction, where the IC design is specified by describing the operations that are performed on data as it flows between circuit inputs, outputs and clocked registers.
- Verilog Verilog-HDL
- VHDL VHDL
- designers must make all key design decisions such as design hierarchy and partitioning, clocking scheme, reset scheme, and locations of registers. All those decisions are contained and reflected in the RTL code.
- the RTL code is generally technology independent, as well as independent from design tools.
- the IC design as expressed by the RTL code, is then synthesized to generate a gate-level description or a netlist. Synthesis is the step taken to translate the architectural and functional descriptions of the design, represented by RTL code, to a lower level of representation of the design such as a logic-level and gate-level descriptions.
- the IC design specification and RTL code are generally technology independent. That is, the specification and the RTL code do not generally specify the exact gates or logic devices to be used to implement the design.
- the gate-level description of the IC design can be technology dependent. This is because, during the synthesis process, the synthesis tool may use a given technology library to map the technology independent RTL code into a technology-dependent gate-level netlist. However, a netlist may be generic or technology specific.
- a generic netlist is a netlist created from RTL code that has not been correlated with a technology-specific library of cells.
- a technology-specific netlist or a map netlist is a netlist created after an IC design has been mapped to a particular technology-specific library of cells.
- Virtual component blocks can generally be categorized according to their “firmness” as far as level of abstraction in the design stage. Virtual component blocks may, for example, be classified in one of three firmness categories: “soft,” “firm,” and “hard.” The category of firmness characterizes the development stage, on the spectrum from functional specifications to a particular fabrication process.
- Soft virtual component blocks are typically delivered to a SOC integrator in the form of a synthesizable hardware description language (such as, for example, VHDL or Verilog). Soft virtual components are highly flexible and may be generic and configurable. “Firm” virtual component blocks are largely structural-type models optimized for a generic technology. The level of detail of a firm virtual component block may range, for example, from a circuit design in which region placement of RTL sub-blocks is specified, via relatively placed data paths, to circuit design having a fully placed netlist. Firm virtual component blocks generally do not include routing and are portable across target technologies. “Hard” virtual components are mapped to a specific technology, and are generally optimized for power, size and performance in the target technology.
- hard virtual components may include a custom physical layout, or a netlist which is fully placed, routed and optimized for a given technology.
- Hard virtual component blocks are process or vendor specific, and usually expressed in a standard design language such as GDSII.
- GDSII standard design language
- a user generally is given access to a high level behavioral model and full physical/timing models along with the GDSII file in order to effectively use a hard virtual component block.
- a complex design can be divided into blocks, i.e. any user- or system-defined hierarchy within a chip.
- the blocks can be replaced with interface models.
- interface models can provide a compact means of exchanging the interface information for the blocks with a SOC integrator of the block, for example.
- the use of interface models in place of the full gate-level netlist for a block or core is key to improving performance and capacity associated with a chip-level analysis and simulation, particularly for complex designs whose gate counts exceeds five million gates.
- interface logic models permit the chip designer to preserve and protect the internal gate level design not required to be transferred with the interface logic model (ILM).
- ILM interface logic model
- ILMs discard the netlist, constraints, and back-annotation associated with internal register-to-register paths on a design, thereby offering significant runtime and performance improvements without sacrificing accuracy.
- an ILM contains only interface logic of the original netlist. For example, logic that is only contained in register-to-register paths on a block is not placed in an ILM.
- the ILM includes cells (i.e. combination of logic and associated nets (called interface nets herein)) contained in a timing path that starts at an input port and ends at either an edge-triggered register (i.e. sequential logic) or an output port. If a transparent latch is encountered in such a timing path, then it is treated as combinational logic and path tracing continues through the latch until an edge-triggered register or output port is encountered.
- An ILM can be used as a simulation model representation of the interface timing of the design.
- the ILM model can be generated from a design Verilog netlist and appropriate parasitic information.
- the ILM model of a component enables a detailed understanding and exploration of how that component operates and interacts with other components with respect to timing.
- IC design information (Verilog design) 102 is implemented in Verilog.
- IC design parasitic information (SPEF) 104 is associated with IC design information 102 and is in the Standard Parasitic Exchange Format (SPEF).
- SPEF Standard Parasitic Exchange Format
- ILM ILM
- Verilog design 102 can be converted into Verilog ILM 108 .
- the EDA tool When generating an ILM, the EDA tool formats a flat gate-level netlist, as sometimes used by EDA tools for circuit simulation, timing verification and circuit placement and routing.
- Each of the SPEF ILM 106 and Verilog ILM 108 represent model views of the circuit design. As will be appreciated, each model view contains confidential simulation information that may provide insight into the operation and capability of the module.
- FIG. 2 is an example of a flat gate-level SPEF.
- Netlist 200 contains name map 202 , port parasitic information 204 and net connections and parasitic information 206 .
- FIG. 3 shows an example of a module or a core design in a Verilog view.
- Flat gate-level netlist 300 defines each “Instance Name,” each “Net Name,” and the hierarchical association between the Instance Names and Net Names.
- Interfaces 302 identify nets that connect to the inputs and outputs at the top level of the module.
- Net Names 304 identify each instance of a net that does not connect to an input or output at the top level of the module.
- Instance Names 306 identify each instance of an interface cell in the view.
- FIG. 4 shows the format of the Instance Names 306 as being identified by an instance name 402 , a plurality of inputs 404 , 406 (or more) and an output 408 .
- design protection system 110 shields disclosure of the proprietary portions of a simulation model, core and/or components to an external designer, while still giving the designer an understanding about whether or not the components, core or model meet design goals.
- design protection system 110 redefines instance names and net names and possibly the associated hierarchical information contained in the IC models to thereby protect the confidential information.
- Design protection system 110 redefines specific data across all design views in a consistent manner. A first view of the design is encoded by using a cipher to re-define certain instance names and net names within the view. When an instance name, net name or hierarchical association in the flat netlist identifies full logic paths, these are replaced with a single unique identifier for that instance or net. Then, related complimentary views are encoded exactly the same way to maintain consistency across the views.
- a script within design protection system 110 generates protected SPEF ILM 112 and protected Verilog ILM 114 stripped of some or all sensitive or confidential information, but still permitting third party users to have full interaction with the models.
- Protected SPEF ILM 112 and protected Verilog ILM 114 result in simulations of the core in a format fully compatible with standard EDA tools.
- FIG. 5 shows a mapping of the replacement scheme performed by the script in design protection system 110 for encoding the instance names, net names and hierarchical associations found in each of the views 102 , 104 or ILMs 106 , 108 , in accordance with a preferred embodiment of the present invention.
- design protection system 110 is described protecting ILMs 106 , 108 (considered derived from exemplary views 200 , 300 for purposes of illustration), however, design protection system 110 is operable to protect most any design views, including views 102 , 104 for example.
- Each line of the mapping key 500 has an identifier 502 specifying an instance name within SPEF 104 (defined as between the first two “!”) and an encoded identifier 504 (defined as between the second and third “!”) that replaces the identifier 502 .
- the instance name 502 in line 506 i.e., “and_gate — 3” found at line “*12” of name map 202
- unique identifier 504 shown in line 506 i.e., “JWW12JWW”.
- the encoded identifier 504 has been created by identifying the line in SPEF ILM 106 (after conversion from SPEF 104 ) where the instance name is identified and prepending and appending it with pre-selected letters.
- Mapping key 500 also provides an encoding of a net name using both encoded instance names and unencoded instance names. For example, as shown in FIG. 5 at line 508 , the unique identifier “JWW17JWW” is created to identify the net connecting the previously re-named instance “JWW12JWW” and the cell “nand_gate.”
- design protection system 110 is implemented by a script that scans SPEF ILM 106 for a name map (derived from name map 202 in SPEF 200 ) to identify instance names and net names to be encoded. From the scan, design protection system 110 generates an encoding map 500 to uniquely identify each identified name using nomenclature unrelated to the names or other confidential information contained in the netlist. Design protection system 110 then generates a protected SPEF ILM 112 as a fully functional ILM design view but having selected sensitive or confidential information stripped from the netlist.
- a script that scans SPEF ILM 106 for a name map (derived from name map 202 in SPEF 200 ) to identify instance names and net names to be encoded. From the scan, design protection system 110 generates an encoding map 500 to uniquely identify each identified name using nomenclature unrelated to the names or other confidential information contained in the netlist. Design protection system 110 then generates a protected SPEF ILM 112 as a fully functional ILM design view but having selected sensitive or confidential information stripped from the netlist.
- FIG. 6 shows an example of a protected SPEF, in accordance with a preferred embodiment of the present invention.
- lines “*12”-“*17” of name map 202 in the example of FIG. 2 have been determined to be confidential information and have been encoded using mapping key 500 into unique codes 602 to generate protected SPEF 600 .
- Design protection system 110 then proceeds to protect all other associated design views of the core design using the same mapping key 500 .
- design protection system 110 generates protected Verilog ILM 114 from Verilog ILM 108 using mapping key 500 .
- FIG. 7 An example of a protected Verilog file generated by applying mapping key 500 to Verilog 300 , implemented as HDL netlist 700 , is shown in FIG. 7 .
- Nets 304 in Verilog 300 have been encoded into uniquely named connections shown as protected net names 702 .
- instance names 306 have been encoded into protected instance names 704 according to mapping key 500 .
- the first “NAND3 ⁇ 1” of instance names 306 has been encoded into the first protected instance name (of 704 ) using the unassociated instance name “JWW17JWW” and a unique identified output “JWW30JWW.”
- Process 800 begins at step 802 where HDL code describing an IC design is flattened to remove hierarchical structure. For example, when protecting files to be transferred to a third party for simulation purposes, the SPEF and Verilog HDL files are flattened. The process then proceeds to step 804 where ILM models are generated. The process then proceeds to step 806 where signal names to be protected are identified.
- the process would parse the SPEF file to determine the number and location of signal names to remain or to be renamed in the SPEF file. For example, the SPEF file would be parsed to determine the number and location of module ports so that they are retained in their original form.
- step 808 a mapping file associating signal names with protected signal names is created by mapping selected signal names to unique identifiers unrelated to the original signal names but uniquely identifying each signal name to be distinguished from the others. Signal names contained within port names are not mapped or replaced in a preferred embodiment.
- step 810 the SPEF file is encoded with the protected signal names by scanning the file for instances of the original signal names and replacing them with their mapped protected names.
- step 812 a script file is generated containing code for mapping signal names to their unique protected signal names.
- step 814 the script file is executed on Verilog design files and other supporting design views of the IC containing the same signal names as the first file.
- the script performs steps 806 , 808 and 810 on the subject design view file to protect each instance of the selected signal names by replacing them with their unique mapped protected signal names.
- the process ends at step 816 by outputting encoded SPEF, Verilog and other supported design views in a protected format that hides module names and structures, while still retaining consistency between each design view and providing complete usability in EDA tools by third party recipients of the design views.
- the preferred embodiment of the present invention allows for multiple IC design views to be filtered of confidential information in an efficient manner to present protected design views without loss of necessary information to permit utilization by standard EDA tools across the multiple views. Because encoding protected design views is performed using a mapping key, the original designer can easily translate comments or technical issues from the user of the protected file design view. This is important in order to support customers interacting with protected design views on many issues or questions regarding technical design.
- the processes in preferred embodiments of the present invention may be implemented using any combination of computer programming software, firmware or hardware.
- the computer programming code (whether software or firmware) according to a preferred embodiment will typically be stored in one or more machine readable storage mediums such as fixed (hard) drives, diskettes, optical disks, magnetic tape, semiconductor memories such as ROMs, PROMs, etc., thereby making an article of manufacture in accordance with the invention.
- the article of manufacture containing the computer programming code is used by either executing the code directly from the storage device, by copying the code from the storage device into another storage device such as a hard disk, RAM, etc., or by transmitting the code for remote execution.
- the method form of the invention may be practiced by combining one or more machine-readable storage devices containing the code according to the present invention with appropriate standard computer hardware to execute the code contained therein.
- An apparatus for practicing the invention could be one or more computers and storage systems containing or having network access to computer program(s) coded in accordance with the invention.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Physics & Mathematics (AREA)
- Software Systems (AREA)
- General Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- General Engineering & Computer Science (AREA)
- Mathematical Physics (AREA)
- Microelectronics & Electronic Packaging (AREA)
- Multimedia (AREA)
- Technology Law (AREA)
- Health & Medical Sciences (AREA)
- Bioethics (AREA)
- General Health & Medical Sciences (AREA)
- Design And Manufacture Of Integrated Circuits (AREA)
- Semiconductor Integrated Circuits (AREA)
- Storage Device Security (AREA)
Abstract
Description
- 1. Field of the Invention
- The present invention relates generally to the field of computer aided design for digital circuits, and particularly to protecting design information contained in electronic design automation (EDA) models.
- 2. Description of the Related Art
- Modern advances in silicon technology such as multi-layer deep sub-micron complimentary metal-oxide semiconductor (CMOS) technology are responsible for allowing larger and more complex designs to be formed on a single chip, and hence enabling entire “system-on-a-chip” (SOC) designs to be placed on the same silicon substrate. These complex designs may incorporate, for example, one or more processor components, a digital signal processing (DSP) component, memory, several communications interfaces, and a graphics support component.
- The advent of SOC design has the electronic systems industry shifting toward a new design paradigm based on the use of preexisting circuit blocks or “cores.” Under this paradigm, systems are assembled by integrating one or more preexisting circuit blocks on the same silicon substrate. It is more efficient and practical for IC designers to incorporate components already developed rather than redesigning all the necessary hardware with each new IC design. It has naturally followed from this shift for different chip design vendors to supply preexisting circuit blocks to a system-level integrator or manufacturer developing a system-on-a-chip (SOC), and often these cores involve intellectual property (IP) owned by such vendors or groups other than the IC integrator.
- As market demands continue to push electronic system manufacturers to develop systems more rapidly and efficiently, it is useful for the electronic system integrators or manufacturers to receive design models of a core to permit simulation and design integration of the SOC. An IC design simulation model allows an IC designer to know whether one component will work with another component to achieve the designer's needs. As the complexity of designs and methodologies increase, more and more detail and visibility into the core design is required to permit usability and integration. Unfortunately, the more accurate and detailed the model transferred to an SOC integrator, the greater the risk of misuse such as theft and unauthorized manipulation of those designs.
- Core designs and models are relatively easy to copy, forge and re-design because they physically exist as data or code on storage devices. Moreover, the increased efficiency brought about by the existence of cores also provides an incentive for unauthorized use, re-use, transfer or sale of these items. As a consequence, while the complexity of designs and methodologies require transferring a significant amount of information to permit usability of the core by a SOC designer, it is becoming more important that efforts be taken to protect the IP transferred to customers, vendors and third parties participating in the SOC design.
- Because the simulation model provides such valuable insight into the operation and capability of the design, those who own the IP in the design typically do not disclose the simulation model without carefully drafted legal agreements between the collaborating parties. Negotiating such agreements takes time and costs money for all parties. If a SOC designer wants to test out a design or idea, then procuring such agreements is a significant detriment to rapid, efficient and cost-effective design development. Moreover, by themselves, such legal means are of limited use because detection of illegal copying, forging, transfer or reuse of proprietary cores is difficult. It can be extremely challenging to determine whether a core was illegally acquired by a particular user or what sensitive information within a circuit design has been procured from its electronic form. Providers of cores are therefore in need of an effective method of protecting their designs so that they are not deprived of the benefits of the resources spent on design, development and procurement of cores.
- This invention is described in a preferred embodiment in the following description with reference to the drawings, in which like numbers represent the same or similar elements, as follows:
-
FIG. 1 is a block diagram of one embodiment of the present invention. -
FIG. 2 is an example of a flat gate-level SPEF. -
FIG. 3 shows an example of a module or a core design in a Verilog view. -
FIG. 4 shows the an exemplary format of the Instance Names. -
FIG. 5 shows a mapping of the replacement scheme performed by the design protection system, in accordance with a preferred embodiment of the present invention. -
FIG. 6 shows an example of a protected SPEF, in accordance with a preferred embodiment of the present invention. -
FIG. 7 shows a protected Verilog, in accordance with a preferred embodiment of the present invention. -
FIG. 8 shows a flow diagram of a process for protecting confidential information in design views of an EDA tool, in accordance with a preferred embodiment of the present invention. - In the following detailed description of exemplary embodiments of the invention, reference is made to the accompanying drawings, which form a part hereof, and in which is shown by way of illustration specific exemplary embodiments in which the invention may be practiced.
- In the following detailed description of exemplary embodiments of the invention, specific exemplary embodiments in which the invention may be practiced are described in sufficient detail to enable those skilled in the art to practice the invention, and it is to be understood that other embodiments may be utilized and that logical, architectural, programmatic, mechanical, electrical and other changes may be made without departing from the spirit or scope of the present invention. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope of the present invention is defined only by the appended claims. In particular, it will be apparent to those of ordinary skill in the art that any manner of representing an IC design or a simulation model of an IC design using a hardware description language (HDL) representation or other symbolic representation is considered within the scope of the present invention.
- In one or more embodiments as described herein, a method and program product for protecting sensitive circuit design information being transferred as part of a simulation model of a circuit design and consequently avoiding unauthorized use of that information is provided, wherein sensitive information such as module names and structures within certain EDA tool design views. In this way, the method and system of the present invention enables a SOC designer to use a simulation model of a core design to determine if the operation of the core and components of the simulation model satisfy the designer's needs without permitting access to confidential information contained within the model. This alleviates, in part, reliance on confidentiality agreements between the SOC designer (or company) and IP owner to protect sensitive core design information that might otherwise be embodied in the simulation model.
- Virtual component blocks are typically generated as part of a design process which can involve a number of steps, depending upon the level of abstraction desired for the particular circuit design. Chip designers often use electronic design automation (EDA) software tools to assist in the design process, and to allow simulation of a chip design prior to prototyping or production. Chip design using EDA software tools generally involves an iterative process whereby the chip design is gradually perfected. Typically, the chip designer builds up a circuit by inputting information at a computer workstation generally having high quality graphic capability so as to display portions of the circuit design as needed. A top-down design methodology is commonly employed using hardware description languages (HDLs), such as Verilog or VHDL, for example, by which the designer creates an integrated circuit by hierarchically defining functional components of the circuit, and then decomposing each component into smaller and smaller components.
- The various components of an integrated circuit are initially defined by their functional operations and relevant inputs and outputs. During these design states, the designer generally structures the circuit using considerable hierarchical information, and has typically provided substantial regularity in the design. The design of a digital circuit can be represented or specified in different ways within the memory of a computer system. Each type of digital circuit representation is called a view. Different views contain different amounts and types of information regarding the structure of a circuit. Views which contain more information regarding the structure of the circuit require more of the computer's memory and require more of the computer's time to construct and manipulate.
- From the HDL or other high level description, the actual logic cell implementation is typically determined by logic synthesis, which converts the functional description of the circuit into a specific circuit implementation. The logic cells are then “placed” (i.e., given specific coordinate locations in the circuit layout) and “routed” (i.e., wired or connected together according to the designer's circuit definitions). The placement and routing software routines generally accept as their input a flattened netlist that has been generated by the logic synthesis process. This flattened or hierarchical netlist identifies the specific logic cell instances from a target standard cell library, and describes the specific cell-to-cell connectivity.
- An IC chip comprises cells and connections between the cells formed on a surface of a semiconductor substrate. A cell is a group of one or more circuit elements such as transistors, capacitors and other basic circuit elements grouped to perform a function. The IC may include a large number of cells and require complex connections between the cells. Each of the cells of an IC may have one or more pins, each of which, in turn, may be connected to one or more other pins of the IC by wires. The wires connecting the pin to the IC are also formed on the surface of the chip.
- A net is a set of two or more interconnected pins and wires, thereby connecting the logic circuits having pins. Because a typical chip has thousands, tens of thousands or hundreds of thousands of pins that must be connected in various combinations, the chip also includes definitions of thousands, tens of thousands, or hundreds of thousands of “nets”, or connections of sets of pins. The number of nets for a chip is typically of the same order as the order of the number of cells on that chip. Commonly, a majority of the nets include only two pins to be connected; however, many nets comprise three or more pins. Some nets may include hundreds or tens of thousands of pins to be connected.
- An IC model is a set of interconnected circuit cells and nets typically represented in a HDL, and is sometimes interchangeably referred to herein as a module, core, intellectual property (IP), IP block, block, or component. A core is an electronic design implementable in hardware, typically specified in HDL, and also typically represented in a top-level netlist. A “netlist” is a list of nets (“Net Names”) including names of connected pins or list of cells (“Instance Names”) including names of nets that connect to pins of cells. Top-level RTL is synthesized to generate a gate-level netlist at a lower level of abstraction. After the synthesis of the design, the gate-level netlist is verified, the layout of the circuit is determined, and the IC is fabricated.
- Today, the design of most digital integrated circuits (IC's) is a highly structured process based on an HDL (Hardware Description Language) methodology. The HDL methodology begins with the IC being specified by a specification document. Then, the IC specification is written to a high-level HDL code at a level of design abstraction referred to as the Register Transfer Language (RTL). RTL code describes circuits as a collection of registers, Boolean equations, and control logic such as “if-then-else” statements as well as complex event sequences. RTL code is typically implemented using a HDL language such as Verilog-HDL (“Verilog”) or VHDL at the RTL level of abstraction, where the IC design is specified by describing the operations that are performed on data as it flows between circuit inputs, outputs and clocked registers. At the RTL level, designers must make all key design decisions such as design hierarchy and partitioning, clocking scheme, reset scheme, and locations of registers. All those decisions are contained and reflected in the RTL code. The RTL code is generally technology independent, as well as independent from design tools.
- The IC design, as expressed by the RTL code, is then synthesized to generate a gate-level description or a netlist. Synthesis is the step taken to translate the architectural and functional descriptions of the design, represented by RTL code, to a lower level of representation of the design such as a logic-level and gate-level descriptions. The IC design specification and RTL code are generally technology independent. That is, the specification and the RTL code do not generally specify the exact gates or logic devices to be used to implement the design. The gate-level description of the IC design can be technology dependent. This is because, during the synthesis process, the synthesis tool may use a given technology library to map the technology independent RTL code into a technology-dependent gate-level netlist. However, a netlist may be generic or technology specific. A generic netlist is a netlist created from RTL code that has not been correlated with a technology-specific library of cells. A technology-specific netlist or a map netlist is a netlist created after an IC design has been mapped to a particular technology-specific library of cells.
- The embodiments of the invention as described herein are applicable to a wide variety of virtual component blocks, whether they relate to system level macros, megacells, or embedded software “cores” used in system chip design. Virtual component blocks can generally be categorized according to their “firmness” as far as level of abstraction in the design stage. Virtual component blocks may, for example, be classified in one of three firmness categories: “soft,” “firm,” and “hard.” The category of firmness characterizes the development stage, on the spectrum from functional specifications to a particular fabrication process.
- “Soft” virtual component blocks are typically delivered to a SOC integrator in the form of a synthesizable hardware description language (such as, for example, VHDL or Verilog). Soft virtual components are highly flexible and may be generic and configurable. “Firm” virtual component blocks are largely structural-type models optimized for a generic technology. The level of detail of a firm virtual component block may range, for example, from a circuit design in which region placement of RTL sub-blocks is specified, via relatively placed data paths, to circuit design having a fully placed netlist. Firm virtual component blocks generally do not include routing and are portable across target technologies. “Hard” virtual components are mapped to a specific technology, and are generally optimized for power, size and performance in the target technology. Examples of hard virtual components may include a custom physical layout, or a netlist which is fully placed, routed and optimized for a given technology. Hard virtual component blocks are process or vendor specific, and usually expressed in a standard design language such as GDSII. A user generally is given access to a high level behavioral model and full physical/timing models along with the GDSII file in order to effectively use a hard virtual component block.
- To simplify the tasks of design and analysis of a SOC, a complex design can be divided into blocks, i.e. any user- or system-defined hierarchy within a chip. At this point, the blocks can be replaced with interface models. Advantageously, such models can provide a compact means of exchanging the interface information for the blocks with a SOC integrator of the block, for example. The use of interface models in place of the full gate-level netlist for a block or core is key to improving performance and capacity associated with a chip-level analysis and simulation, particularly for complex designs whose gate counts exceeds five million gates. Moreover, such interface logic models permit the chip designer to preserve and protect the internal gate level design not required to be transferred with the interface logic model (ILM).
- Automatic model generation can include the use of ILMs. ILMs discard the netlist, constraints, and back-annotation associated with internal register-to-register paths on a design, thereby offering significant runtime and performance improvements without sacrificing accuracy. Moreover, an ILM contains only interface logic of the original netlist. For example, logic that is only contained in register-to-register paths on a block is not placed in an ILM. The ILM includes cells (i.e. combination of logic and associated nets (called interface nets herein)) contained in a timing path that starts at an input port and ends at either an edge-triggered register (i.e. sequential logic) or an output port. If a transparent latch is encountered in such a timing path, then it is treated as combinational logic and path tracing continues through the latch until an edge-triggered register or output port is encountered.
- An ILM can be used as a simulation model representation of the interface timing of the design. The ILM model can be generated from a design Verilog netlist and appropriate parasitic information. The ILM model of a component enables a detailed understanding and exploration of how that component operates and interacts with other components with respect to timing.
- With reference now to the figures, and in particular with reference to
FIG. 1 , there is shown a block diagram of one embodiment of the present invention. IC design information (Verilog design) 102 is implemented in Verilog. IC design parasitic information (SPEF) 104 is associated withIC design information 102 and is in the Standard Parasitic Exchange Format (SPEF). Together,Verilog design 102 andSPEF 104 provide an important set of design information for a core or design block. Using standard EDA tools,SPEF 104 can be converted into anILM 106, andVerilog design 102 can be converted intoVerilog ILM 108. When generating an ILM, the EDA tool formats a flat gate-level netlist, as sometimes used by EDA tools for circuit simulation, timing verification and circuit placement and routing. Each of theSPEF ILM 106 andVerilog ILM 108 represent model views of the circuit design. As will be appreciated, each model view contains confidential simulation information that may provide insight into the operation and capability of the module. -
FIG. 2 is an example of a flat gate-level SPEF.Netlist 200 containsname map 202, portparasitic information 204 and net connections andparasitic information 206. -
FIG. 3 shows an example of a module or a core design in a Verilog view. Flat gate-level netlist 300 defines each “Instance Name,” each “Net Name,” and the hierarchical association between the Instance Names and Net Names.Interfaces 302 identify nets that connect to the inputs and outputs at the top level of the module.Net Names 304 identify each instance of a net that does not connect to an input or output at the top level of the module. Instance Names 306 identify each instance of an interface cell in the view.FIG. 4 shows the format of the Instance Names 306 as being identified by aninstance name 402, a plurality ofinputs 404, 406 (or more) and anoutput 408. - Referring back to
FIG. 1 ,design protection system 110 shields disclosure of the proprietary portions of a simulation model, core and/or components to an external designer, while still giving the designer an understanding about whether or not the components, core or model meet design goals. In accordance with a preferred embodiment,design protection system 110 redefines instance names and net names and possibly the associated hierarchical information contained in the IC models to thereby protect the confidential information.Design protection system 110 redefines specific data across all design views in a consistent manner. A first view of the design is encoded by using a cipher to re-define certain instance names and net names within the view. When an instance name, net name or hierarchical association in the flat netlist identifies full logic paths, these are replaced with a single unique identifier for that instance or net. Then, related complimentary views are encoded exactly the same way to maintain consistency across the views. - In a preferred embodiment, a script within
design protection system 110 generates protectedSPEF ILM 112 and protectedVerilog ILM 114 stripped of some or all sensitive or confidential information, but still permitting third party users to have full interaction with the models. ProtectedSPEF ILM 112 and protectedVerilog ILM 114 result in simulations of the core in a format fully compatible with standard EDA tools. -
FIG. 5 shows a mapping of the replacement scheme performed by the script indesign protection system 110 for encoding the instance names, net names and hierarchical associations found in each of theviews ILMs design protection system 110 is described protectingILMs 106, 108 (considered derived fromexemplary views design protection system 110 is operable to protect most any design views, includingviews mapping key 500 has anidentifier 502 specifying an instance name within SPEF 104 (defined as between the first two “!”) and an encoded identifier 504 (defined as between the second and third “!”) that replaces theidentifier 502. For example, theinstance name 502 in line 506 (i.e., “and_gate —3” found at line “*12” of name map 202) is replaced withunique identifier 504 shown in line 506 (i.e., “JWW12JWW”). In this example, the encodedidentifier 504 has been created by identifying the line in SPEF ILM 106 (after conversion from SPEF 104) where the instance name is identified and prepending and appending it with pre-selected letters. It will be appreciated by those skilled in the art that any naming or encoding scheme can be used, so long as each instance name, net name and hierarchical association in the netlist is given a unique and un-shared identifier.Mapping key 500 also provides an encoding of a net name using both encoded instance names and unencoded instance names. For example, as shown inFIG. 5 at line 508, the unique identifier “JWW17JWW” is created to identify the net connecting the previously re-named instance “JWW12JWW” and the cell “nand_gate.” - In a preferred embodiment,
design protection system 110 is implemented by a script that scansSPEF ILM 106 for a name map (derived fromname map 202 in SPEF 200) to identify instance names and net names to be encoded. From the scan,design protection system 110 generates anencoding map 500 to uniquely identify each identified name using nomenclature unrelated to the names or other confidential information contained in the netlist.Design protection system 110 then generates a protectedSPEF ILM 112 as a fully functional ILM design view but having selected sensitive or confidential information stripped from the netlist. -
FIG. 6 shows an example of a protected SPEF, in accordance with a preferred embodiment of the present invention. In this example, lines “*12”-“*17” ofname map 202 in the example ofFIG. 2 have been determined to be confidential information and have been encoded usingmapping key 500 intounique codes 602 to generate protectedSPEF 600. -
Design protection system 110 then proceeds to protect all other associated design views of the core design using thesame mapping key 500. In a preferred embodiment,design protection system 110 generates protectedVerilog ILM 114 fromVerilog ILM 108 usingmapping key 500. - An example of a protected Verilog file generated by applying
mapping key 500 toVerilog 300, implemented as HDL netlist 700, is shown inFIG. 7 .Nets 304 inVerilog 300 have been encoded into uniquely named connections shown as protectednet names 702. Similarly, instance names 306 have been encoded into protectedinstance names 704 according tomapping key 500. For example, the first “NAND3×1” of instance names 306 has been encoded into the first protected instance name (of 704) using the unassociated instance name “JWW17JWW” and a unique identified output “JWW30JWW.” - With referenced now to
FIG. 8 , there is shown a flow diagram of a process for protecting confidential information in design views of an EDA tool, in accordance with a preferred embodiment of the present invention.Process 800 begins atstep 802 where HDL code describing an IC design is flattened to remove hierarchical structure. For example, when protecting files to be transferred to a third party for simulation purposes, the SPEF and Verilog HDL files are flattened. The process then proceeds to step 804 where ILM models are generated. The process then proceeds to step 806 where signal names to be protected are identified. Here the process would parse the SPEF file to determine the number and location of signal names to remain or to be renamed in the SPEF file. For example, the SPEF file would be parsed to determine the number and location of module ports so that they are retained in their original form. - Thereafter, the process proceeds to step 808 where a mapping file associating signal names with protected signal names is created by mapping selected signal names to unique identifiers unrelated to the original signal names but uniquely identifying each signal name to be distinguished from the others. Signal names contained within port names are not mapped or replaced in a preferred embodiment. The process then proceeds to step 810, where the SPEF file is encoded with the protected signal names by scanning the file for instances of the original signal names and replacing them with their mapped protected names. Thereafter, the process proceeds to step 812 where a script file is generated containing code for mapping signal names to their unique protected signal names. Thereafter, the process proceeds to step 814 where the script file is executed on Verilog design files and other supporting design views of the IC containing the same signal names as the first file. When run, the script performs
steps step 816 by outputting encoded SPEF, Verilog and other supported design views in a protected format that hides module names and structures, while still retaining consistency between each design view and providing complete usability in EDA tools by third party recipients of the design views. - As will be appreciated, the preferred embodiment of the present invention allows for multiple IC design views to be filtered of confidential information in an efficient manner to present protected design views without loss of necessary information to permit utilization by standard EDA tools across the multiple views. Because encoding protected design views is performed using a mapping key, the original designer can easily translate comments or technical issues from the user of the protected file design view. This is important in order to support customers interacting with protected design views on many issues or questions regarding technical design.
- As will be appreciated, the processes in preferred embodiments of the present invention may be implemented using any combination of computer programming software, firmware or hardware. As a preparatory step to practicing the invention in software, the computer programming code (whether software or firmware) according to a preferred embodiment will typically be stored in one or more machine readable storage mediums such as fixed (hard) drives, diskettes, optical disks, magnetic tape, semiconductor memories such as ROMs, PROMs, etc., thereby making an article of manufacture in accordance with the invention. The article of manufacture containing the computer programming code is used by either executing the code directly from the storage device, by copying the code from the storage device into another storage device such as a hard disk, RAM, etc., or by transmitting the code for remote execution. The method form of the invention may be practiced by combining one or more machine-readable storage devices containing the code according to the present invention with appropriate standard computer hardware to execute the code contained therein. An apparatus for practicing the invention could be one or more computers and storage systems containing or having network access to computer program(s) coded in accordance with the invention.
- While the invention has been particularly shown and described with reference to preferred embodiments, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention. Any variations, modifications, additions, and improvements to the embodiments described are possible and may fall within the scope of the invention as detailed within the following claims.
Claims (20)
Priority Applications (6)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/290,368 US7437698B2 (en) | 2005-11-30 | 2005-11-30 | Method and program product for protecting information in EDA tool design views |
JP2008543551A JP2009518717A (en) | 2005-11-30 | 2006-10-26 | Method and program product for protecting information in EDA tool design view |
PCT/US2006/060261 WO2007102887A2 (en) | 2005-11-30 | 2006-10-26 | Method and program product for protecting information in eda tool design views |
EP06850073A EP1958107A2 (en) | 2005-11-30 | 2006-10-26 | Method and program product for protecting information in eda tool design views |
KR1020087013174A KR101336516B1 (en) | 2005-11-30 | 2006-10-26 | Method and program product for protecting information in eda tool design views |
CN2006800448986A CN101395609B (en) | 2005-11-30 | 2006-10-26 | Method and system for protecting information in eda tool design views |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/290,368 US7437698B2 (en) | 2005-11-30 | 2005-11-30 | Method and program product for protecting information in EDA tool design views |
Publications (2)
Publication Number | Publication Date |
---|---|
US20070124717A1 true US20070124717A1 (en) | 2007-05-31 |
US7437698B2 US7437698B2 (en) | 2008-10-14 |
Family
ID=38088978
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/290,368 Active 2026-08-27 US7437698B2 (en) | 2005-11-30 | 2005-11-30 | Method and program product for protecting information in EDA tool design views |
Country Status (6)
Country | Link |
---|---|
US (1) | US7437698B2 (en) |
EP (1) | EP1958107A2 (en) |
JP (1) | JP2009518717A (en) |
KR (1) | KR101336516B1 (en) |
CN (1) | CN101395609B (en) |
WO (1) | WO2007102887A2 (en) |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080059956A1 (en) * | 2006-08-30 | 2008-03-06 | Via Technologies, Inc. | Methods and systems for compiling a shading process of a 3d computer graphics |
US20100031209A1 (en) * | 2008-08-04 | 2010-02-04 | Texas Instruments Incorporated | Partial Timing Modeling for Gate Level Simulation |
US20100199233A1 (en) * | 2009-01-30 | 2010-08-05 | Petunin Vladimir V | Uniquely Marking Products And Product Design Data |
US20130007676A1 (en) * | 2007-01-03 | 2013-01-03 | Dipti Motiani | Method for the definition of a library of application-domain-specific logic cells |
US20140137231A1 (en) * | 2011-12-21 | 2014-05-15 | Manoj R. Sastry | INCORPORATING ACCESS CONTROL FUNCTIONALITY INTO A SYSTEM ON A CHIP (SoC) |
US20170124305A1 (en) * | 2015-10-30 | 2017-05-04 | Synopsys, Inc. | Deterministic Identifiers for Source Code Elements |
CN106815387A (en) * | 2015-12-02 | 2017-06-09 | 北京华大九天软件有限公司 | A kind of method using specifying View to carry out netlist output |
CN112818616A (en) * | 2021-01-15 | 2021-05-18 | 珠海泰芯半导体有限公司 | Pin naming method, register excitation source adding method and electronic device |
Families Citing this family (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7543265B1 (en) * | 2006-04-26 | 2009-06-02 | Altera Corporation | Method for early logic mapping during FPGA synthesis |
US7925940B2 (en) * | 2007-10-17 | 2011-04-12 | Synopsys, Inc. | Enhancing speed of simulation of an IC design while testing scan circuitry |
US9984194B2 (en) * | 2015-09-15 | 2018-05-29 | Arm Limited | Integrated circuit design |
JP6578841B2 (en) * | 2015-09-17 | 2019-09-25 | 日本電気株式会社 | Obfuscation device, method and program |
KR101881915B1 (en) * | 2018-06-14 | 2018-07-26 | 에스브이디 주식회사 | Plug-in system for vehicle design |
KR102150335B1 (en) * | 2019-01-17 | 2020-09-01 | 주식회사 쓰리데이즈 | Database management system |
US11023646B2 (en) | 2019-06-18 | 2021-06-01 | Samsung Electronics Co., Ltd. | Hierarchical clock tree construction based on constraints |
CN112560401B (en) * | 2020-12-22 | 2024-04-09 | 成都海光微电子技术有限公司 | Verilog file conversion method, device, storage medium and equipment |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5937190A (en) * | 1994-04-12 | 1999-08-10 | Synopsys, Inc. | Architecture and methods for a hardware description language source level analysis and debugging system |
US6263483B1 (en) * | 1998-02-20 | 2001-07-17 | Lsi Logic Corporation | Method of accessing the generic netlist created by synopsys design compilier |
US20030004699A1 (en) * | 2001-06-04 | 2003-01-02 | Choi Charles Y. | Method and apparatus for evaluating an integrated circuit model |
US6886140B2 (en) * | 2002-01-17 | 2005-04-26 | Micron Technology, Inc. | Fast algorithm to extract flat information from hierarchical netlists |
US20050229128A1 (en) * | 2004-04-05 | 2005-10-13 | Synopsys Inc. | Hierarchical signal integrity analysis using interface logic models |
US7168041B1 (en) * | 2002-06-10 | 2007-01-23 | Cadence Design Systems, Inc. | Method and apparatus for table and HDL based design entry |
US20070050745A1 (en) * | 2005-08-31 | 2007-03-01 | Lsi Logic Corporation | Timing violation debugging inside place and route tool |
Family Cites Families (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5963454A (en) * | 1996-09-25 | 1999-10-05 | Vlsi Technology, Inc. | Method and apparatus for efficiently implementing complex function blocks in integrated circuit designs |
JPH10187767A (en) * | 1996-12-24 | 1998-07-21 | Mitsubishi Electric Corp | Parameterized hdl describing method, logic synthesizer, and medium recording logic synthesizing program |
JP2002230061A (en) * | 2001-01-30 | 2002-08-16 | Matsushita Electric Ind Co Ltd | Data base for semiconductor circuit connection and semiconductor circuit designing method using the same |
US6868531B1 (en) * | 2002-12-27 | 2005-03-15 | Unisys Corporation | Generation of ordered interconnect output from an HDL representation of a circuit |
JP4776172B2 (en) * | 2004-02-17 | 2011-09-21 | 株式会社リコー | Security method for LSI design and manufacturing system |
JP2007026178A (en) * | 2005-07-19 | 2007-02-01 | Canon Inc | Data generation apparatus and method |
-
2005
- 2005-11-30 US US11/290,368 patent/US7437698B2/en active Active
-
2006
- 2006-10-26 EP EP06850073A patent/EP1958107A2/en not_active Withdrawn
- 2006-10-26 KR KR1020087013174A patent/KR101336516B1/en active IP Right Grant
- 2006-10-26 WO PCT/US2006/060261 patent/WO2007102887A2/en active Application Filing
- 2006-10-26 CN CN2006800448986A patent/CN101395609B/en active Active
- 2006-10-26 JP JP2008543551A patent/JP2009518717A/en active Pending
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5937190A (en) * | 1994-04-12 | 1999-08-10 | Synopsys, Inc. | Architecture and methods for a hardware description language source level analysis and debugging system |
US6263483B1 (en) * | 1998-02-20 | 2001-07-17 | Lsi Logic Corporation | Method of accessing the generic netlist created by synopsys design compilier |
US20030004699A1 (en) * | 2001-06-04 | 2003-01-02 | Choi Charles Y. | Method and apparatus for evaluating an integrated circuit model |
US6886140B2 (en) * | 2002-01-17 | 2005-04-26 | Micron Technology, Inc. | Fast algorithm to extract flat information from hierarchical netlists |
US7168041B1 (en) * | 2002-06-10 | 2007-01-23 | Cadence Design Systems, Inc. | Method and apparatus for table and HDL based design entry |
US20050229128A1 (en) * | 2004-04-05 | 2005-10-13 | Synopsys Inc. | Hierarchical signal integrity analysis using interface logic models |
US20070050745A1 (en) * | 2005-08-31 | 2007-03-01 | Lsi Logic Corporation | Timing violation debugging inside place and route tool |
Cited By (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8601450B2 (en) * | 2006-08-30 | 2013-12-03 | Via Technologies, Inc. | Methods and systems for compiling a shading process of a 3D computer graphics |
US20080059956A1 (en) * | 2006-08-30 | 2008-03-06 | Via Technologies, Inc. | Methods and systems for compiling a shading process of a 3d computer graphics |
US20130007676A1 (en) * | 2007-01-03 | 2013-01-03 | Dipti Motiani | Method for the definition of a library of application-domain-specific logic cells |
US8589833B2 (en) * | 2007-01-03 | 2013-11-19 | Pdf Acquisition Corp. | Method for the definition of a library of application-domain-specific logic cells |
US7941774B2 (en) * | 2008-08-04 | 2011-05-10 | Texas Instruments Incorporated | Partial timing modeling for gate level simulation |
US20100031209A1 (en) * | 2008-08-04 | 2010-02-04 | Texas Instruments Incorporated | Partial Timing Modeling for Gate Level Simulation |
US20100199233A1 (en) * | 2009-01-30 | 2010-08-05 | Petunin Vladimir V | Uniquely Marking Products And Product Design Data |
US20140137231A1 (en) * | 2011-12-21 | 2014-05-15 | Manoj R. Sastry | INCORPORATING ACCESS CONTROL FUNCTIONALITY INTO A SYSTEM ON A CHIP (SoC) |
US9805221B2 (en) * | 2011-12-21 | 2017-10-31 | Intel Corporation | Incorporating access control functionality into a system on a chip (SoC) |
US20170124305A1 (en) * | 2015-10-30 | 2017-05-04 | Synopsys, Inc. | Deterministic Identifiers for Source Code Elements |
US9858398B2 (en) * | 2015-10-30 | 2018-01-02 | Synopsys, Inc. | Deterministic identifiers for source code elements |
CN106815387A (en) * | 2015-12-02 | 2017-06-09 | 北京华大九天软件有限公司 | A kind of method using specifying View to carry out netlist output |
CN112818616A (en) * | 2021-01-15 | 2021-05-18 | 珠海泰芯半导体有限公司 | Pin naming method, register excitation source adding method and electronic device |
Also Published As
Publication number | Publication date |
---|---|
WO2007102887A3 (en) | 2008-12-04 |
KR101336516B1 (en) | 2013-12-03 |
WO2007102887A2 (en) | 2007-09-13 |
CN101395609A (en) | 2009-03-25 |
US7437698B2 (en) | 2008-10-14 |
JP2009518717A (en) | 2009-05-07 |
EP1958107A2 (en) | 2008-08-20 |
CN101395609B (en) | 2012-05-30 |
KR20080072028A (en) | 2008-08-05 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7437698B2 (en) | Method and program product for protecting information in EDA tool design views | |
US6292931B1 (en) | RTL analysis tool | |
US6378123B1 (en) | Method of handling macro components in circuit design synthesis | |
Kundert et al. | Design of mixed-signal systems-on-a-chip | |
US6173435B1 (en) | Internal clock handling in synthesis script | |
US6295636B1 (en) | RTL analysis for improved logic synthesis | |
US6421818B1 (en) | Efficient top-down characterization method | |
US6836877B1 (en) | Automatic synthesis script generation for synopsys design compiler | |
US6263483B1 (en) | Method of accessing the generic netlist created by synopsys design compilier | |
US6289498B1 (en) | VDHL/Verilog expertise and gate synthesis automation system | |
US6205572B1 (en) | Buffering tree analysis in mapped design | |
US7685545B2 (en) | Methods and devices for independent evaluation of cell integrity, changes and origin in chip design for production workflow | |
CN102112988B (en) | Methods and devices for independent evaluation of cell integrity, changes and origin in chip design for production workflow | |
CN102902839B (en) | The apparatus and method of management integrated circuit (IC) design | |
US5696694A (en) | Method and apparatus for estimating internal power consumption of an electronic circuit represented as netlist | |
US6289491B1 (en) | Netlist analysis tool by degree of conformity | |
US10896280B1 (en) | Netlist abstraction for circuit design floorplanning | |
Alpert et al. | Placement: Hot or not? | |
US7299446B2 (en) | Enabling efficient design reuse in platform ASICs | |
US20100275168A1 (en) | Design method of semiconductor integrated circuit device and program | |
US7194715B2 (en) | Method and system for performing static timing analysis on digital electronic circuits | |
US6272665B1 (en) | Method and tool for automatically generating engineering change order | |
Engel et al. | Design methodology for IBM ASIC products | |
US8024681B2 (en) | Hierarchical HDL processing method and non-transitory computer-readable storage medium | |
US7272542B1 (en) | Method and system for re-targeting integrated circuits |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: FREESCALE SEMICONDUCTOR, INC., TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:DEUR, MICHAEL W.;WOOLSEY, JOHN W.;REEL/FRAME:017288/0574 Effective date: 20051129 |
|
AS | Assignment |
Owner name: CITIBANK, N.A. AS COLLATERAL AGENT, NEW YORK Free format text: SECURITY AGREEMENT;ASSIGNORS:FREESCALE SEMICONDUCTOR, INC.;FREESCALE ACQUISITION CORPORATION;FREESCALE ACQUISITION HOLDINGS CORP.;AND OTHERS;REEL/FRAME:018855/0129 Effective date: 20061201 Owner name: CITIBANK, N.A. AS COLLATERAL AGENT,NEW YORK Free format text: SECURITY AGREEMENT;ASSIGNORS:FREESCALE SEMICONDUCTOR, INC.;FREESCALE ACQUISITION CORPORATION;FREESCALE ACQUISITION HOLDINGS CORP.;AND OTHERS;REEL/FRAME:018855/0129 Effective date: 20061201 |
|
FEPP | Fee payment procedure |
Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
AS | Assignment |
Owner name: CITIBANK, N.A., NEW YORK Free format text: SECURITY AGREEMENT;ASSIGNOR:FREESCALE SEMICONDUCTOR, INC.;REEL/FRAME:022380/0409 Effective date: 20090216 Owner name: CITIBANK, N.A.,NEW YORK Free format text: SECURITY AGREEMENT;ASSIGNOR:FREESCALE SEMICONDUCTOR, INC.;REEL/FRAME:022380/0409 Effective date: 20090216 |
|
AS | Assignment |
Owner name: CITIBANK, N.A., AS COLLATERAL AGENT,NEW YORK Free format text: SECURITY AGREEMENT;ASSIGNOR:FREESCALE SEMICONDUCTOR, INC.;REEL/FRAME:024397/0001 Effective date: 20100413 Owner name: CITIBANK, N.A., AS COLLATERAL AGENT, NEW YORK Free format text: SECURITY AGREEMENT;ASSIGNOR:FREESCALE SEMICONDUCTOR, INC.;REEL/FRAME:024397/0001 Effective date: 20100413 |
|
FPAY | Fee payment |
Year of fee payment: 4 |
|
AS | Assignment |
Owner name: CITIBANK, N.A., AS NOTES COLLATERAL AGENT, NEW YOR Free format text: SECURITY AGREEMENT;ASSIGNOR:FREESCALE SEMICONDUCTOR, INC.;REEL/FRAME:030633/0424 Effective date: 20130521 |
|
AS | Assignment |
Owner name: CITIBANK, N.A., AS NOTES COLLATERAL AGENT, NEW YOR Free format text: SECURITY AGREEMENT;ASSIGNOR:FREESCALE SEMICONDUCTOR, INC.;REEL/FRAME:031591/0266 Effective date: 20131101 |
|
AS | Assignment |
Owner name: FREESCALE SEMICONDUCTOR, INC., TEXAS Free format text: PATENT RELEASE;ASSIGNOR:CITIBANK, N.A., AS COLLATERAL AGENT;REEL/FRAME:037354/0225 Effective date: 20151207 Owner name: FREESCALE SEMICONDUCTOR, INC., TEXAS Free format text: PATENT RELEASE;ASSIGNOR:CITIBANK, N.A., AS COLLATERAL AGENT;REEL/FRAME:037354/0807 Effective date: 20151207 Owner name: FREESCALE SEMICONDUCTOR, INC., TEXAS Free format text: PATENT RELEASE;ASSIGNOR:CITIBANK, N.A., AS COLLATERAL AGENT;REEL/FRAME:037356/0553 Effective date: 20151207 Owner name: FREESCALE SEMICONDUCTOR, INC., TEXAS Free format text: PATENT RELEASE;ASSIGNOR:CITIBANK, N.A., AS COLLATERAL AGENT;REEL/FRAME:037356/0143 Effective date: 20151207 |
|
AS | Assignment |
Owner name: MORGAN STANLEY SENIOR FUNDING, INC., MARYLAND Free format text: ASSIGNMENT AND ASSUMPTION OF SECURITY INTEREST IN PATENTS;ASSIGNOR:CITIBANK, N.A.;REEL/FRAME:037486/0517 Effective date: 20151207 |
|
AS | Assignment |
Owner name: MORGAN STANLEY SENIOR FUNDING, INC., MARYLAND Free format text: ASSIGNMENT AND ASSUMPTION OF SECURITY INTEREST IN PATENTS;ASSIGNOR:CITIBANK, N.A.;REEL/FRAME:037518/0292 Effective date: 20151207 |
|
AS | Assignment |
Owner name: MORGAN STANLEY SENIOR FUNDING, INC., MARYLAND Free format text: SECURITY AGREEMENT SUPPLEMENT;ASSIGNOR:NXP B.V.;REEL/FRAME:038017/0058 Effective date: 20160218 |
|
FPAY | Fee payment |
Year of fee payment: 8 |
|
AS | Assignment |
Owner name: MORGAN STANLEY SENIOR FUNDING, INC., MARYLAND Free format text: SUPPLEMENT TO THE SECURITY AGREEMENT;ASSIGNOR:FREESCALE SEMICONDUCTOR, INC.;REEL/FRAME:039138/0001 Effective date: 20160525 |
|
AS | Assignment |
Owner name: MORGAN STANLEY SENIOR FUNDING, INC., MARYLAND Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE REMOVE APPLICATION 12092129 PREVIOUSLY RECORDED ON REEL 038017 FRAME 0058. ASSIGNOR(S) HEREBY CONFIRMS THE SECURITY AGREEMENT SUPPLEMENT;ASSIGNOR:NXP B.V.;REEL/FRAME:039361/0212 Effective date: 20160218 |
|
AS | Assignment |
Owner name: NXP, B.V., F/K/A FREESCALE SEMICONDUCTOR, INC., NETHERLANDS Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:MORGAN STANLEY SENIOR FUNDING, INC.;REEL/FRAME:040925/0001 Effective date: 20160912 Owner name: NXP, B.V., F/K/A FREESCALE SEMICONDUCTOR, INC., NE Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:MORGAN STANLEY SENIOR FUNDING, INC.;REEL/FRAME:040925/0001 Effective date: 20160912 |
|
AS | Assignment |
Owner name: NXP B.V., NETHERLANDS Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:MORGAN STANLEY SENIOR FUNDING, INC.;REEL/FRAME:040928/0001 Effective date: 20160622 |
|
AS | Assignment |
Owner name: NXP USA, INC., TEXAS Free format text: CHANGE OF NAME;ASSIGNOR:FREESCALE SEMICONDUCTOR INC.;REEL/FRAME:040652/0180 Effective date: 20161107 |
|
AS | Assignment |
Owner name: NXP USA, INC., TEXAS Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE NATURE OF CONVEYANCE LISTED CHANGE OF NAME SHOULD BE MERGER AND CHANGE PREVIOUSLY RECORDED AT REEL: 040652 FRAME: 0180. ASSIGNOR(S) HEREBY CONFIRMS THE MERGER AND CHANGE OF NAME;ASSIGNOR:FREESCALE SEMICONDUCTOR INC.;REEL/FRAME:041354/0148 Effective date: 20161107 |
|
AS | Assignment |
Owner name: MORGAN STANLEY SENIOR FUNDING, INC., MARYLAND Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE REMOVE PATENTS 8108266 AND 8062324 AND REPLACE THEM WITH 6108266 AND 8060324 PREVIOUSLY RECORDED ON REEL 037518 FRAME 0292. ASSIGNOR(S) HEREBY CONFIRMS THE ASSIGNMENT AND ASSUMPTION OF SECURITY INTEREST IN PATENTS;ASSIGNOR:CITIBANK, N.A.;REEL/FRAME:041703/0536 Effective date: 20151207 |
|
AS | Assignment |
Owner name: MORGAN STANLEY SENIOR FUNDING, INC., MARYLAND Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE REMOVE APPLICATION 12681366 PREVIOUSLY RECORDED ON REEL 039361 FRAME 0212. ASSIGNOR(S) HEREBY CONFIRMS THE SECURITY AGREEMENT SUPPLEMENT;ASSIGNOR:NXP B.V.;REEL/FRAME:042762/0145 Effective date: 20160218 Owner name: MORGAN STANLEY SENIOR FUNDING, INC., MARYLAND Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE REMOVE APPLICATION 12681366 PREVIOUSLY RECORDED ON REEL 038017 FRAME 0058. ASSIGNOR(S) HEREBY CONFIRMS THE SECURITY AGREEMENT SUPPLEMENT;ASSIGNOR:NXP B.V.;REEL/FRAME:042985/0001 Effective date: 20160218 |
|
AS | Assignment |
Owner name: SHENZHEN XINGUODU TECHNOLOGY CO., LTD., CHINA Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE TO CORRECT THE APPLICATION NO. FROM 13,883,290 TO 13,833,290 PREVIOUSLY RECORDED ON REEL 041703 FRAME 0536. ASSIGNOR(S) HEREBY CONFIRMS THE THE ASSIGNMENT AND ASSUMPTION OF SECURITYINTEREST IN PATENTS.;ASSIGNOR:MORGAN STANLEY SENIOR FUNDING, INC.;REEL/FRAME:048734/0001 Effective date: 20190217 |
|
AS | Assignment |
Owner name: NXP B.V., NETHERLANDS Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:MORGAN STANLEY SENIOR FUNDING, INC.;REEL/FRAME:050744/0097 Effective date: 20190903 Owner name: NXP B.V., NETHERLANDS Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:MORGAN STANLEY SENIOR FUNDING, INC.;REEL/FRAME:050745/0001 Effective date: 20190903 |
|
AS | Assignment |
Owner name: MORGAN STANLEY SENIOR FUNDING, INC., MARYLAND Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE REMOVE APPLICATION 12298143 PREVIOUSLY RECORDED ON REEL 042985 FRAME 0001. ASSIGNOR(S) HEREBY CONFIRMS THE SECURITY AGREEMENT SUPPLEMENT;ASSIGNOR:NXP B.V.;REEL/FRAME:051029/0001 Effective date: 20160218 Owner name: MORGAN STANLEY SENIOR FUNDING, INC., MARYLAND Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE REMOVE APPLICATION 12298143 PREVIOUSLY RECORDED ON REEL 042762 FRAME 0145. ASSIGNOR(S) HEREBY CONFIRMS THE SECURITY AGREEMENT SUPPLEMENT;ASSIGNOR:NXP B.V.;REEL/FRAME:051145/0184 Effective date: 20160218 Owner name: MORGAN STANLEY SENIOR FUNDING, INC., MARYLAND Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE REMOVE APPLICATION 12298143 PREVIOUSLY RECORDED ON REEL 039361 FRAME 0212. ASSIGNOR(S) HEREBY CONFIRMS THE SECURITY AGREEMENT SUPPLEMENT;ASSIGNOR:NXP B.V.;REEL/FRAME:051029/0387 Effective date: 20160218 Owner name: MORGAN STANLEY SENIOR FUNDING, INC., MARYLAND Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE REMOVE APPLICATION12298143 PREVIOUSLY RECORDED ON REEL 039361 FRAME 0212. ASSIGNOR(S) HEREBY CONFIRMS THE SECURITY AGREEMENT SUPPLEMENT;ASSIGNOR:NXP B.V.;REEL/FRAME:051029/0387 Effective date: 20160218 Owner name: MORGAN STANLEY SENIOR FUNDING, INC., MARYLAND Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE REMOVE APPLICATION12298143 PREVIOUSLY RECORDED ON REEL 042985 FRAME 0001. ASSIGNOR(S) HEREBY CONFIRMS THE SECURITY AGREEMENT SUPPLEMENT;ASSIGNOR:NXP B.V.;REEL/FRAME:051029/0001 Effective date: 20160218 Owner name: MORGAN STANLEY SENIOR FUNDING, INC., MARYLAND Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE REMOVE APPLICATION 12298143 PREVIOUSLY RECORDED ON REEL 038017 FRAME 0058. ASSIGNOR(S) HEREBY CONFIRMS THE SECURITY AGREEMENT SUPPLEMENT;ASSIGNOR:NXP B.V.;REEL/FRAME:051030/0001 Effective date: 20160218 Owner name: MORGAN STANLEY SENIOR FUNDING, INC., MARYLAND Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE REMOVE APPLICATION12298143 PREVIOUSLY RECORDED ON REEL 042762 FRAME 0145. ASSIGNOR(S) HEREBY CONFIRMS THE SECURITY AGREEMENT SUPPLEMENT;ASSIGNOR:NXP B.V.;REEL/FRAME:051145/0184 Effective date: 20160218 |
|
AS | Assignment |
Owner name: MORGAN STANLEY SENIOR FUNDING, INC., MARYLAND Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE REMOVE APPLICATION11759915 AND REPLACE IT WITH APPLICATION 11759935 PREVIOUSLY RECORDED ON REEL 037486 FRAME 0517. ASSIGNOR(S) HEREBY CONFIRMS THE ASSIGNMENT AND ASSUMPTION OF SECURITYINTEREST IN PATENTS;ASSIGNOR:CITIBANK, N.A.;REEL/FRAME:053547/0421 Effective date: 20151207 |
|
AS | Assignment |
Owner name: NXP B.V., NETHERLANDS Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE REMOVEAPPLICATION 11759915 AND REPLACE IT WITH APPLICATION11759935 PREVIOUSLY RECORDED ON REEL 040928 FRAME 0001. ASSIGNOR(S) HEREBY CONFIRMS THE RELEASE OF SECURITYINTEREST;ASSIGNOR:MORGAN STANLEY SENIOR FUNDING, INC.;REEL/FRAME:052915/0001 Effective date: 20160622 |
|
AS | Assignment |
Owner name: NXP, B.V. F/K/A FREESCALE SEMICONDUCTOR, INC., NETHERLANDS Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE REMOVEAPPLICATION 11759915 AND REPLACE IT WITH APPLICATION11759935 PREVIOUSLY RECORDED ON REEL 040925 FRAME 0001. ASSIGNOR(S) HEREBY CONFIRMS THE RELEASE OF SECURITYINTEREST;ASSIGNOR:MORGAN STANLEY SENIOR FUNDING, INC.;REEL/FRAME:052917/0001 Effective date: 20160912 |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 12TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1553); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Year of fee payment: 12 |