Abstract:
A method and system for representing an electronic device having input-output ports and test circuits associated with the input-output ports includes: receiving a functional level description of the electronic device; determining a connectivity relationship between a first test circuit associated with a first input-output port and a second test circuit associated with a second input-output port; and generating a functional level representation of the determined connectivity relationship. Functional level descriptions include hardware description languages such as VHDL and VERILOG.

Description:
BACKGROUND 
     The invention relates generally to semiconductor device design and, more particularly, to the functional representation of the device&#39;s input-output test circuitry. 
     The design of semiconductor devices using programmable logic device (PLD), application specific integrated circuit (ASIC), and field programmable gate array (FPGA) technologies generally includes the design of input-output (I/O) circuits for each of the device&#39;s I/O ports and the test circuitry to validate operation of the I/O circuits. In one test mode, I/O test circuits coupled into a string configuration wherein the output from one test circuit is coupled to the input of the next closest test circuit. Following device fabrication, I/O test circuit strings may be used to facilitate operational testing such as, for example, determining whether an I/O circuit meets DC input and output threshold voltage requirements. 
     Referring to FIG. 1, a typical design process for an ASIC device begins with a designer&#39;s conception (block  100 ), followed by the development of a functional model (block  102 ). Functional models may be generated using any one of a variety of hardware description languages such as VHDL and VERILOG. Functional models may be used to exercise and/or verify the operational characteristics of the device&#39;s design via simulation tools. Once a design is thought to be complete, it may be compiled (also referred to as synthesized) into a gate level description (block  104 ) that describes the device in terms of vendor-specific gates and interconnections thereto. Following compilation, the gate level description may be imported into a vendor-specific place and route tool (block  106 ) that may then be used to generate a netlist (block  108 )—the electrical connectivity data associated with the specified design. Netlist data may then be used to drive fabrication and/or assembly equipment (block  110 ). 
     Input-output circuitry is typically identified (e.g., its position within the device) and automatically interconnected during netlist generation (block  108 ). At this stage in the design process, however, the information describing this interconnection is not available to functional circuit simulations which are performed on the model of block  102 . Further, it is not currently possible to extract I/O test circuit connectivity descriptions from a netlist and “insert” it into a functional model, e.g., the model of block  102 . Thus, designers are not readily able to simulate the complete device circuitry. Alternatively, it is possible to manually specify I/O test circuit interconnectivity at the functional description level (e.g., during the acts of block  102 ). This technique, however, may require large amounts of a designer&#39;s time and is prone to data entry error. Consider, for example, the task of manually specifying the interconnection of 300 I/O test circuits. 
     Thus, it would be beneficial to provide a mechanism to automatically specify the interconnection of I/O test circuitry at the functional model level during a semiconductor design process. 
     SUMMARY 
     In one embodiment the invention provides a method of representing an electronic device having input-output ports and test circuits associated with the input-output ports. The method includes receiving a functional level description of the electronic device, determining a connectivity relationship between a first test circuit associated with a first input-output port and a second test circuit associated with a second input-output port, and generating a functional level representation of the determined connectivity relationship. Functional level descriptions include hardware description languages such as VHDL and VERILOG. Methods in accordance with the invention may be stored in any media that is readable and executable by a computer system. 
     In another embodiment, the invention provides a computer aided design system, that includes a processor, a storage device coupled to the processor, and a program stored on the storage device to generate a functional level representation in accordance with the previously described method. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     FIG. 1 shows a prior art semiconductor design process flowchart. 
     FIG. 2 shows a custom designed semiconductor device having input-output buffers that include both functional circuitry and test circuitry. 
     FIG. 3 shows the flowchart of a semiconductor design process in accordance with one embodiment of the invention. 
     FIGS. 4 shows the flowchart of one aspect of the design process of FIG. 3 in accordance with the invention. 
     FIG. 5 shows a computer system in accordance with one embodiment of the invention. 
    
    
     DETAILED DESCRIPTION 
     Techniques (including methods and devices) to automatically specify the configuration of semiconductor device input-output test circuitry are described. The following embodiments of the invention, described in terms of a VHDL functional model, are illustrative only and are not to be considered limiting in any respect. 
     Referring to FIG. 2, custom designed semiconductor device  200  generally includes core device  202  that embodies the device&#39;s functional circuitry and a plurality of input-output (I/O) buffers (e.g.,  204  and  206 ). Each I/O buffer includes I/O circuitry (e.g.,  208  and  210 ) that embodies the desired I/O buffer&#39;s functional circuitry and I/O test circuitry (e.g.,  212  and  214 ) that may be used to test the operational characteristics of the buffer&#39;s functional circuitry (e.g.,  208  and  210 ). One aspect of the design process is to configure a device&#39;s I/O test circuits into strings, wherein the output from one test circuit (e.g.,  212 ) is coupled to the input of the next closest test circuit (e.g.,  214 ). In this configuration, operational characteristics of the I/O circuits themselves may be tested. 
     Referring to FIG. 3, a semiconductor design process in accordance with one embodiment of the invention begins with the development of a functional model representing target device  200  (block  300 ). Functional models are typically expressed in a chosen hardware description language (HDL) such as VHDL and embodied in VHDL file  302  as a sequence of VHDL statements or instructions. 
     In addition to VHDL file  302 , I/O buffer specification  304  and pin-out specification  306  are generated as a part of, or subsequent to, the initial functional description embodied in file  302 . Input-output buffer specification  304  describes the functional structure and connectivity guidelines for each type of I/O buffer used in the design of device  200 . In one embodiment, I/O buffer specification  304  includes a buffer type identifier or name, a list of the buffer&#39;s input ports, a list of the buffer&#39;s output ports, and a description of how the input and output ports are to be configured (i.e., connectivity rules) for each type of buffer specified by the designer during generation of VHDL file  302 . For example, an I/O buffer may have input A, output Z, test circuit input PI, and test circuit output PO. In another example, an I/O buffer may have bidirectional inputs A and EN, outputs ZI and ZO, test circuit input PI, and test circuit output PO. 
     The structural description of each buffer (e.g., its identifier and list of input and output ports) is generally defined by the vendor chosen to provide simulation and/or gate level description capability. The rules describing how each buffer port is to be configured are specific to the device being designed (e.g.,  200 ) and are established by the designer as part of the design process. For example, for a given device pin “P” the connection from an I/O buffer to the device&#39;s core logic may be made through netlist identifier “Pi,” the connection from the core logic to the I/O buffer may be made through the netlist name “Po,” and an enable signal from the core logic to the I/O buffer&#39;s enable input (in a bidirectional I/O buffer, for example) may be made through netlist name “Pe”. 
     Pin-out specification  306  associates, for each I/O signal of target device  200 , an I/O signal name (e.g., D 0  for data bit zero and A 10  for address bit ten), with an I/O buffer type (e.g., input, output, and bidirectional) and a pin identifier (e.g., pin  0  and pin  75 ) that identifies a specific I/O pin location on a chosen semiconductor device package. It will be recognized that each semiconductor device package has a predetermined number of I/O pins and, further, that each I/O pin&#39;s location may be uniquely determined by its name or identifier. Illustrative device packages include  452  and  580  pin gate array devices. 
     Based on I/O buffer  304  and pin-out  306  specifications, a functional level description of a device  200 &#39;s I/O buffer configuration may be generated (block  308 ). FIG. 4 illustrates one technique in accordance with the invention to generate a functional level description of device  200 &#39;s I/O buffer configuration. An initial I/O signal is selected from those I/O signals identified in pin-out specification  306  (block  400 ). For example, the first I/O signal listed in pin-out specification  306  may be selected. Alternatively, that I/O signal associated with a specified device package I/O pin (e.g., pin  1 ) may be selected. Next, the buffer type associated with the selected I/O signal is determined (block  402 ), and that I/O device package pin that is nearest, or at some other predetermined relationship to the selected I/O pin is identified (block  404 ). The ability to determine a “nearest neighbor” or some other predetermined relationship of a specified I/O pin relies on knowledge of the device package chosen by the designer. Based on the selected I/O pin, the identified nearest I/O pin, and the buffer type (including the identified buffer&#39;s connectivity rules), a functional level (e.g., VHDL) description of the selected I/O buffer&#39;s configuration is generated (block  406 ). In one embodiment, the generated function level VHDL description of a buffer&#39;s configuration has the following form: 
     ID: &lt;Buffer Type&gt; port map (Port 1 _Name  First_Signal_Name, Port 2 _Name  Second_Signal_Name, . . . , PortN_Name  Last_Signal_Name); 
     where ID represents a unique identifier/name value for the I/O buffer, &lt;Buffer Type&gt; identifies the type of buffer, port map indicates the beginning of a connectivity specification, and the notation Port_Name Signal_Name indicates that the I/O buffer&#39;s port identified by Port_Name is to be coupled to the device signal identified by Signal_Name. 
     Following generation of a functional specification for a first I/O buffer, a check is made to determine if all I/O signals identified in pin-out specification  306  have been processed. If all I/O signals have been processed (the ‘yes’ prong of diamond  408 ), processing halts (block  410 ). If all I/O signals have not been processed (the ‘no’ prong of diamond  408 ), another I/O signal is selected (block  412 ) and processing continues at block  402 . 
     Referring again to FIG. 3, the I/O buffer configuration generated during the acts of block  308  may be combined (block  310 ) with initial VHDL file  302  to generate composite VHDL file  312 . Composite VHDL file includes a functional description of core device  202 , I/O buffers (e.g.,  204  and  206 ), and the connectivity between I/O test circuits (e.g.,  212  and  214 ). The act of combining initial VHDL file  302  and I/O buffer connectivity specifications as illustrated above may be facilitated by representing each in a text format (e.g., ASCII text). Using this representation, I/O buffer specifications may be “cut and pasted” into the architectural module of initial VHDL file  302 . 
     Composite VHDL file  312  may be supplied as input to a functional simulator (e.g., ModelSim from Model Technology of Oregon) for test and design verification operations (block  314 ). Composite VHDL file  312  may also be used to generate a gate level description of the combined design (block  316 ) and, subsequently, imported into a place and route application (block  318 ). The place and route operation may then generate a netlist (block  320 ) which may, finally, be used during device fabrication. 
     One benefit of some embodiments of the invention is that functional models incorporating I/O buffer configuration data may be automatically generated by a design engineer during their functional specification efforts. This, in turn, allows a more complete simulation of the designed device. In particular, having a functional specification of a device&#39;s I/O buffers allows a more complete timing analysis of the target device. This is in contrast to prior art techniques in which I/O buffer configuration was added only after generation of a gate level model (e.g., following the acts of block  316 ), necessitating a significant reworking of the functional model to incorporate the (more detailed) I/O buffer configuration data. Another benefit of the invention is that test circuit simulation and verification may be performed using a functional model. This, in turn, allows connectivity errors to be detected earlier in a device&#39;s design life cycle (before creating a gate level model and before place and route operations are performed). 
     Various changes in the materials, components, as well as in the details of the illustrated operational methods are possible without departing from the scope of the claims. For instance, hardware description languages other than VHDL may be used. In addition, I/O buffer and pin-out specification data do not need to be maintained in separate files. For example, I/O buffer specification information may be obtained directly from an initial HDL file (e.g., VHDL file  302 ). Similarly, pin-out specification data may be obtained directly from an initial HDL file. Thus, segregating pin-out and I/O buffer specification information into discrete files as shown in FIG. 3 was done for ease of explanation and is not a restrictive feature of the invention. 
     Referring to FIG. 5, acts in accordance with FIGS. 3 and 4 may be performed by programmable control device  500  executing instructions organized into one or more program modules. As indicated, programmable control device  500  may be one element of computer system  502  which may also include system memory  504  and long-term storage device  506  coupled via communication link  508 . Programmable control device  500  may be a single computer processor, a plurality of computer processors coupled by a communications link, or a custom designed state machine. System  502  may be a general purpose computer system (e.g., a personal computer) or a special purpose workstation (e.g., a computer aided design (CAD) workstation). Program modules may be stored in any storage device that may be operatively coupled to computer system  502 . Storage devices (e.g., storage device  506 ) suitable for tangibly embodying program instructions include all forms of non-volatile memory including, but not limited to: semiconductor memory devices such as EPROM, EEPROM, and flash devices; magnetic disks (fixed, floppy, and removable); other magnetic media such as tape; and optical media such as CD-ROM disks. 
     While the invention has been disclosed with respect to a limited number of embodiments, numerous modifications and variations will be appreciated by those skilled in the art. It is intended, therefore, that the following claims cover all such modifications and variations that may fall within the true sprit and scope of the invention.