Abstract:
Methods of designing integrated circuit gate arrays include the step of generating a netlist for a gate array integrated circuit having at least first logic and signal resources therein, directly from bitstream data which characterizes a programmable logic device having a first operational functionality and the first logic and signal resources as well. The generating step is also followed by the step of using the netlist to configure the first logic and signal resources within the gate array integrated circuit to provide the first functionality. A preferred integrated circuit design system is also provided and includes a programmable logic device having pre-programmed logic and signal resources therein and a gate array device having base logic and signal resources therein which are equivalent to the unprogrammed logic and signal resources of the programmable logic device. A computer-based apparatus is also provided for decoding a bitstream that characterizes the programmable logic device having a first operational functionality when programmed, into a netlist that designates electrical connections in the gate array device when wired to have the first operational functionality, and to provide a method for generating scan-based test vectors to verify the first functionality. Accordingly, when switching from a functional programmable logic device (PLD) implementation to a gate array implementation, it is unnecessary to start the design process over from scratch by performing logic synthesis, place and route and other front end design operations associated with conventional gate array design techniques.

Description:
CROSS-REFERENCE TO RELATED APPLICATION  
       [0001]    This application is a continuation of prior application Ser. No. 09/211,515, filed Dec. 14, 1998, the disclosure of which is hereby incorporated herein by reference. 
     
    
     
       FIELD OF THE INVENTION  
         [0002]    The present invention relates to integrated circuit design methods, and more particularly to application specific integrated circuit design methods.  
         BACKGROUND OF THE INVENTION  
         [0003]    Integrated circuit designers frequently choose application specific integrated circuit (ASIC) technology when designing integrated circuits to perform unique and customized functions. This is because ASIC technology provides designers with comprehensive tools to customize logic to perform specialized and multiple functions on a single integrated circuit substrate or chip, instead of the multiple chips which typically would be required in the event standardized circuit technology was employed. As will be understood by those skilled in the art, ASICs may be generated in many different ways and have many different designations based on the methods used to design and/or manufacture them. The most time consuming method, but often the one that yields the smallest chip size and/or best performance, is the “full-custom” designed ASIC. These ASICs are often designed entirely from scratch at the transistor level with only occasional use of previously designed circuit “blocks” which are typically referred to as cells, standard cells, or macrocells. Because of this comprehensive approach, custom designed ASICs typically require the creation of an entire design database and test methods (including custom test vectors). A complete set of customized fabrication masks is also typically required for fabrication. These requirements typically make the design and fabrication of custom ASICs very time consuming and expensive when generating prototype devices and when iterating through design changes. Alternative ASIC design methodologies include the use of standard cell technology, which differs from full custom design in that multiple cells or macrocells that have been previously designed are utilized. These cells are selected from libraries of cells for their applicability to the design, and placed and routed with software that is well known in the art. The final circuit then has no fewer custom mask layers than the full custom design method. However, this method does have advantages over the full custom design method in the time required to complete a design, because the elementary level of cell design is only done once to create the libraries, and this work can be reused in multiple subsequent designs.  
           [0004]    Alternative application specific integrated circuit design technologies which typically do not incur the time and expense penalties associated with full custom ASICs include gate array technology. Gate array technology typically utilizes the building blocks of logic gates and/or memory devices as resources to minimize design time and cost. This extensive use of blocks enables the gate array designer to focus more on the routing of connections (e.g., metal wiring and interconnects) between these blocks and less on the design and operation of the individual logic gates and other low-level devices. Here, the designer may be able to reduce the number of custom mask layers that must be generated for fabrication because typically only the uppermost masking layers are specific to a particular design. On the other hand, the base masking layers that determine the logic and memory blocks are typically identical for a variety of designs. With these savings comes a penalty since only certain types and sizes of logic gates are typically available to choose from and constraints on the placement of such gates may not always lead to a device having ideal characteristics.  
           [0005]    Gate array technology also provides a reduction in the time and expense associated with making design changes through an iterative process. This is because less than all mask layers are involved in any design change at any level, as opposed to the full-custom ASIC design case where design changes may require a change to all mask layers. Notwithstanding these benefits, gate array technology may still require some relatively expensive custom tooling for the upper level masks. Moreover, design checking in physical silicon cannot take place without processing one or more wafers through multiple fabrication steps including deposition, masking and etching, for example, just like full-custom ASIC technology. The terms ASIC and gate array are meant to be interchangeable for the purposes of this disclosure. ASIC or gate array can refer to fully-custom integrated circuits, or semi-custom integrated circuits, including standard cell integrated circuits.  
           [0006]    Referring now to FIG. 1, a flow diagram of operations  100  performed when designing a full-custom ASIC will be described. Although the flow diagram displays many decision points and their associated unacceptable paths, the following description does not attempt to elaborate on all the unacceptable paths. As illustrated, a design specification of a desired integrated circuit is initially provided, Block  102 , and then from this a HDL/schematic description of the integrated circuit is entered into a design system, Block  104 , to generate a complete HDL/schematic description, Block  106 . From this HDL/schematic description, an operation is performed to simulate the functional operation of the integrated circuit, Block  108 . The simulation is then checked for accuracy, Block  110 . If the simulation is correct, an operation is performed to synthesize logic and generate a logic netlist, Blocks  112  and  114 . The synthesis of the logic may require ASIC logic primitives and resources, Block  113 , and user synthesis constraints, Block  111 . A check may then be performed to determine whether the integrated circuit will receive an internal scan test, Block  116 . If so, scan elements can be added to the logic netlist, Block  118 . Then, with the addition of ASIC element timing estimates, Block  115 , an operation is performed to simulate the timing of the integrated circuit, Block  121 . The timing simulation is then checked for accuracy, Block  123 . If the simulation is correct, a logic placement and signal routing operation will be performed, Block  120 , based on a set of user routing and logic placement constraints, Block  150 , and ASIC logic resources and routing resources and constraints, Block  117 . From this placement and routing operation, a routed netlist will be generated, Block  122 .  
           [0007]    A timing extraction operation (e.g., parasitic R and C extraction operation) may then be performed, Block  124 , to generate timing parameters, Block  126 . The routed netlist and timing parameters are then used to perform another timing simulation, Block  128 , which takes into account the actual placement of gates, devices, etc., and interconnect nets which link these devices together. A check is then performed to determine whether the simulation is acceptable, Block  130 . If the simulation is acceptable, test vectors are created, Block  140 . Operations are also performed to create mask-making data, Block  132 . The mask-making data, Block  134 , is then used to create masks, Block  136 . A prototype of the full-custom ASIC device is then fabricated, Block  138 . An operation is then performed to test and evaluate the device and/or system, Block  142 . If the test results are acceptable, then the design is complete. However, if the test results are not acceptable, then a check is made to determine whether the HDL/schematic description of the invention (i.e. logic) needs to be modified, the routing and placement needs to be modified, or the synthesis constraints need to be modified, Block  144 . If the HDL/schematic description needs to be modified, Block  146 , then essentially all the above-described steps and operations will need to be repeated. If the synthesis constraints need to be modified, Block  119 , then the majority of the above-described steps and operations will need to be repeated from the logic synthesis step, Block  112 . But, if only the routing and placement constraints need to be modified, Block  148 , then the process can resume at the logic placement and signal routing step, Block  120 .  
           [0008]    Programmable logic devices (PLDs) may also be used as an alternative application specific integrated circuit design technology. Such devices are also typically referred to as programmable array logic (PAL) and field programmable gate arrays (FPGAs), as described in Chapter  11  of a textbook by Jan M. Rabaey, entitled Digital Integrated Circuits, Prentice Hall, pp. 629-692 (1996), the disclosure of which is hereby incorporated herein by reference. When customizing a PLD, a user typically defines the device within the constraints of the PLD architecture, and then creates through the use of computer aided design tools, a specific set of interconnections or device states at each of the programmable configuration points within the PLD. As will be understood by those skilled in the art, each of these configuration points may be controlled by one or more fuses, antifuses or memory elements, and may be one-time programmable or reprogrammable. The configuration of the PLD is then stored in a configuration file, which is commonly referred to as a “bitstream”. This configuration file defines the state of each fuse, antifuse or memory element in the PLD. In the case of PLDs, this bitstream may be programmed into the PLD directly, or in the case of a volatile device, this bitstream may be stored in another device and then read into the PLD upon startup.  
           [0009]    An obvious advantage of PLDs is that they require relatively little time and expense to design or generate design iterations. However, for a given functional design, PLDs typically require greater layout area, consume considerably more power and are slower than ASIC technologies (i.e. custom ASIC, standard cell, or gate array). PLDs consume more power and are slower because the signals which traverse programmable elements within the PLD typically encounter higher resistance and capacitance associated with the programmable elements than the resistance and capacitance associated with metal interconnect lines within the gate array and full-custom ASIC technologies. PLDs also require greater layout area because they include additional programmable elements and configuration points.  
           [0010]    Referring now to FIG. 2, a flow diagram of operations  200  performed when designing a conventional PLD will be described. As illustrated, a design specification of a desired integrated circuit is initially provided, Block  202 , and then from this a HDL/schematic description of the integrated circuit is entered into a design system, Block  204 , to generate a complete HDL/schematic description, Block  206 . From this HDL/schematic description, an operation is performed to simulate the functional operation of the integrated circuit, Block  208 . The simulation is then checked for accuracy, Block  210 . If the simulation is correct, an operation is performed to synthesize logic and generate a logic netlist, Blocks  212  and  214 . The synthesis of the logic typically requires PLD logic primitives and resources, Block  213 . A logic placement and signal routing operation is then performed, Block  220 , based on a set of user routing and logic placement constraints, Block  250 , and PLD logic resources and routing resources and constraints, Block  217 . From this placement and routing operation, a routed netlist will be generated, Block  222 .  
           [0011]    A timing extraction operation may then be performed, Block  224 , to generate timing parameters, Block  226 . The routed netlist and timing parameters are then used to perform a timing simulation, Block  228 , which takes into account the actual placement of gates, devices, etc., and interconnect nets which link these devices together. A check is then performed to determine whether the simulation is acceptable, Block  230 . If the simulation is acceptable, an operation is performed to generate a bitstream/programming file, Blocks  232  and  234 . A prototype of the PLD can then be programmed, Block  236 . An operation is then performed to test and evaluate the operation and/or system of the device, Block  242 . If the test results are acceptable, then the design of the PLD is complete. However, if the test results are not acceptable, then a check is made to determine whether the HDL schematic description of the circuit needs to be modified or the routing and placement needs to be modified, Block  244 . If the HDL schematic description needs to be modified, Block  246 , then essentially all the above-described steps and operations of FIG. 2 will need to be repeated. But, if only the routing and placement constraints need to be modified, Block  248 , then the process can resume at the logic placement and signal routing step, Block  220 .  
           [0012]    Unfortunately, as integrated circuit designs such as those having asynchronous inputs increasingly become more complex, the importance of physical testing becomes more important since many of state-of-the-art software simulation tools cannot provide completely accurate simulation. Accordingly, physical designs may need to be redesigned in an iterative manner more frequently, which increases design time and expense. To address these limitations in the ability to accurately and completely simulate highly complex integrated circuits, integrated circuit design methodologies have been developed which include the generation of prototype devices and the performance of small volume production with PLDs. Then, once a final functional design is obtained utilizing the PLD, a conversion is then typically made to full-custom or gate array ASICs for large volume production after the design has been finalized. Unfortunately, a problem with this design methodology is the lack of an efficient technique to provide this conversion from a PLD to a gate array or full-custom ASIC without having to go back to the beginning or HDL/schematic definition stage and repeat the time-consuming and expensive process of generating the gate array or full-custom ASIC to mimic the operation of the PLD. Thus, when switching from a functional PLD implementation to a gate array ASIC implementation, the design process essentially starts over since the logic synthesis operations must be repeated along with the place and route operations and all the other steps in the flow.  
           [0013]    This relatively inefficient design methodology is more fully illustrated by FIG. 3. In particular, FIG. 3 illustrates conventional operations  300  which are performed when switching from a PLD implementation to an ASIC implementation. Although the flow diagram displays many decision points and their associated unacceptable paths, the following description does not attempt to elaborate on all the unacceptable paths. These operations include the step of selecting a PLD for conversion, Block  302 , with the description of the PLD being defined by a HDL/schematic description, Block  304 . A check is then made to determine whether the HDL/schematic format of the PLD is compatible with the format for specifying an ASIC, Block  306 . If the formats are not compatible, then the HDL/schematic of the PLD undergoes a conversion process, Block  308 , to generate a converted format for the desired ASIC, Block  349 . From this HDL/schematic description, an operation is performed to simulate the functional operation of the integrated circuit, Block  350 . The simulation is then checked for accuracy, Block  352 . If the simulation is correct, an operation is performed to synthesize logic and generate a logic netlist, Blocks  312  and  314 . The synthesis of the logic may require ASIC logic primitives and resources, Block  313 , and the user synthesis constraints, Block  311 . A check may then be performed to determine whether the integrated circuit will receive an internal scan test, Block  316 . If so, scan elements will be added to the logic netlist, Block  320 . Then, with the addition of the ASIC element timing estimates, Block  315 , an operation is performed to simulate the timing of the integrated circuit, Block  317 . The timing simulation is then checked for accuracy, Block  323 . If the timing simulation is not correct, a check is made at Block  343  to determine whether the synthesis constraints need to be modified, Block  325 , or whether the logic needs to be modified. However, if the simulation is correct, a logic placement and signal routing operation will be performed, Block  318 , based on a set of user routing and logic placement constraints, Block  321 , and ASIC logic resources and routing resources and constraints, Block  319 . From this placement and routing operation, a routed netlist will be generated, Block  322 .  
           [0014]    A timing extraction operation (e.g., parasitic R and C extraction operation) may then be performed, Block  324 , to generate timing parameters, Block  326 . The routed netlist and timing parameters are then used to perform another timing simulation, Block  328 , which takes into account the actual placement of gates, devices, etc., and interconnect nets which link these devices together. A check is then performed to determine whether the simulation is acceptable, Block  330 . If the simulation is acceptable, test vectors are created, Block  342 . Operations are also performed to create mask-making data, Block  332 . The mask-making data, Block  334 , is then used to create masks, Block  336 . A prototype of the ASIC device is then fabricated, Block  338 . An operation is then performed to test and evaluate the operation of the device and/or the device within the application, Block  340 . If the test results are acceptable, then the design is complete. However, if the test results are not acceptable, then a check is made to determine whether the HDL/schematic description of the invention (i.e. logic) needs to be modified, the routing and placement needs to be modified, or the synthesis constraints need to be modified, Block  344 . If the HDL schematic description needs to be modified, Block  346 , then essentially all the above-described steps and operations will need to be repeated. If the synthesis constraints need to be modified, Block  325 , then the majority of the above-described steps and operations will need to be repeated from the logic synthesis step, Block  312 . But, if only the routing and placement constraints need to be modified, Block  348 , then the process can resume at the logic placement and signal routing step, Block  318 .  
           [0015]    Alternative methods of converting PLDs to ASICs have been devised that reduce the workload in the conversion process by creating parameterized software models for elements of the PLD such as described in U.S. Pat. No. 5,815,405 to Baxter titled “Method and apparatus for converting a programmable logic device representation of a circuit into a second representation of the circuit”. These methods attempt to allow the reuse of work product in the same way that standard cell ASIC technology allows the reuse of work product. Standard cell ASIC technology reuses previously created cells or macrocells and allows the designer to reuse these higher level previously designed building blocks, lessening the design effort over full custom design. In the same way, Baxter proposes reusing previously designed software macros of the logic elements within the PLD, and creating a software model of the design from the bitstream of the PLD, relieving the designer of these repetitive tasks. These methods however still suffer from the limitations that they require the user to complete the multiple steps of synthesis and place and route after the software model has been created, and do not guarantee that equivalent logic implementation and timing, or relative placement and relative routing delays of signals will be maintained between the target PLD representation being converted and the ASIC device as converted.  
           [0016]    In particular, U.S. Pat. No. 5,815,405 to Baxter discloses an apparatus which parses a device specific bitwise representation used to program a PLD. The apparatus identifies various configurable elements being programmed by the bitwise representation, and identifies the actual configuration of the identified elements. As illustrated by FIG. 1B of the &#39;405 patent, for each configurable element represented in the bitwise representation, a new instance of that type of element is included in a pre-compiled representation  137  of the circuit design. This pre-compiled representation, which is independent of the target fabrication technology, may be an HDL representation or a netlist representation. A compiler then uses a target fabrication technology library  142  to convert the pre-compiled representation  137  into a post-compiled representation  147 . A place and route tool  150  is then used to place and route the post-compiled representation  147  in the desired target technology. Unfortunately, like the relatively inefficient design methodology of FIG. 3, expensive and time consuming operations are still required to convert from an HDL or netlist representation of the desired circuit to a design which is compatible with the target technology. Conventional place and route operations are also required.  
           [0017]    Thus, notwithstanding the above-described techniques for designing integrated circuits, there still continues to be a need for design techniques which enable more efficient conversion of PLD-based designs to functionally equivalent ASIC designs.  
         SUMMARY OF THE INVENTION  
         [0018]    It is therefore an object of the present invention to provide improved integrated circuit design and manufacturing methodologies.  
           [0019]    It is another object of the present invention to provide integrated circuit design and manufacturing methodologies which enable a more efficient conversion from PLD integrated circuits to gate array integrated circuits.  
           [0020]    It is still another object of the present invention to provide integrated circuit design and manufacturing methodologies which maintain functional equivalency when converting from PLD integrated circuits to gate array integrated circuits.  
           [0021]    It is still a further object of the present invention to provide integrated circuit design and manufacturing methodologies which enable replication of the functionality of a PLD in a gate array integrated circuit, without requiring the synthesis or the placement and routing steps which are typically required when starting from an HDL or schematic entry level of a circuit design.  
           [0022]    These and other objects, features and advantages of the present invention are provided by methods of designing integrated circuit devices which comprise the step of generating a netlist for a gate array integrated circuit having at least first logic and signal resources therein, directly from bitstream data which characterizes a programmable logic device having a first operational functionality and the first logic and signal resources as well. The generating step is also followed by the step of using the netlist to configure the first logic and signal resources within the gate array integrated circuit to provide the first functionality. A preferred integrated circuit design system is also provided. This system includes a programmable logic device having unprogrammed logic and signal resources therein and a gate array device having base logic and signal resources therein which are equivalent to the unprogrammed logic and signal resources of the programmable logic device. A computer-based apparatus is also provided for decoding a bitstream that characterizes the programmable logic device having a first operational functionality when programmed, into a netlist that designates electrical connections in the gate array device when wired to have the first operational functionality. Accordingly, when switching from a functional programmable logic device (PLD) implementation to a gate array implementation, it is unnecessary to start the design process over from scratch by performing logic synthesis, place and route and other front end design operations associated with conventional gate array design techniques.  
           [0023]    According to one aspect of the present invention, the generating step comprises the step of generating a netlist for the gate array integrated circuit having a first operational functionality. The generating step may also make use of definition data for the programmable logic device, and may further make use of definition data for the gate array integrated circuit. The netlist may be further used to generate test vectors for a test of operational functionality of the gate array integrated circuit. The test of operational functionality may include scan-based testing.  
           [0024]    According to another aspect of the present invention, the generating step comprises the step of generating hookup data which characterizes a plurality of nets for a gate array integrated circuit having a first operational functionality. Preferentially, this generating step would not require a logic synthesis operation or placement and/or routing steps. The generating step may also make use of definition data for the programmable logic device, and may further make use of definition data for the gate array integrated circuit. In another embodiment of the present invention, hookup coordinates are generated as an output of the generating step, which may also include the use of definition data for the programmable logic device or the gate array integrated circuit or both. The hookup coordinates may define points of electrical connections, disconnections or both. The creation of the connections or disconnections may make use of a targeting energy beam, such as an electron beam, ion beam, laser, or other similar methods, hereinafter referred to as a laser, or may make use of photolithography, etch, plating, and deposition technology which is well known in the art, wherein the pattern locations created by the laser or photomask are designated by the hookup coordinates. 
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0025]    [0025]FIG. 1 is a flow diagram of operations which may be performed when designing a conventional application specific integrated circuit (ASIC).  
         [0026]    [0026]FIG. 2 is a flow diagram of operations which may be performed when designing a conventional programmable logic device (PLD).  
         [0027]    [0027]FIG. 3 is a flow diagram of conventional operations which may be performed when converting a PLD implementation of an integrated circuit to an application specific integrated circuit.  
         [0028]    [0028]FIG. 4 is a flow diagram of preferred operations for converting a PLD implementation of an integrated circuit to a gate array having equivalent functionality.  
         [0029]    [0029]FIG. 5A is a block diagram of an exemplary PLD which can be converted directly to a gate array in accordance with the present invention.  
         [0030]    [0030]FIG. 5B is a block diagram of a first portion of the exemplary PLD shown in FIG. 5A.  
         [0031]    [0031]FIG. 5C is a block diagram of a second portion of the exemplary PLD shown in FIG. 5B.  
         [0032]    [0032]FIG. 5D is a block diagram of a portion of a base gate array device into which an exemplary PLD can be directly converted in accordance with the present invention.  
         [0033]    [0033]FIG. 6 is a diagram of a bitstream file used to program the exemplary PLD.  
         [0034]    [0034]FIG. 7 is an exemplary table of bitstream bits and their logical implications used in converting an exemplary PLD directly into a gate array in accordance with the present invention.  
         [0035]    [0035]FIG. 8 is an exemplary table of logic block coordinates of a gate array device used in converting an exemplary PLD directly into a gate array in accordance with the present invention.  
         [0036]    [0036]FIG. 9 is an exemplary table of logic element hookup coordinates within a logic block of a gate array device used in converting an exemplary PLD directly into a gate array in accordance with the present invention.  
         [0037]    [0037]FIG. 10A is a first portion of a base gate array simulation model for use in creating test vectors when converting an exemplary PLD directly into a gate array in accordance with the present invention.  
         [0038]    [0038]FIG. 10B is a second portion of a base gate array simulation model for use in creating test vectors when converting an exemplary PLD directly into a gate array in accordance with the present invention.  
         [0039]    [0039]FIG. 10C is a third portion of a base gate array simulation model for use in creating test vectors when converting an exemplary PLD directly into a gate array in accordance with the present invention.  
         [0040]    [0040]FIG. 10D is a fourth portion of a base gate array simulation model for use in creating test vectors when converting an exemplary PLD directly into a gate array in accordance with the present invention.  
         [0041]    [0041]FIG. 10E is a fifth portion of a base gate array simulation model for use in creating test vectors when converting an exemplary PLD directly into a gate array in accordance with the present invention.  
         [0042]    [0042]FIG. 10F is a sixth portion of a base gate array simulation model for use in creating test vectors when converting an exemplary PLD directly into a gate array in accordance with the present invention.  
         [0043]    [0043]FIG. 11 is a portion of a connection/configuration data file for use in directly converting an exemplary PLD directly into a gate array in accordance with the present invention.  
         [0044]    [0044]FIG. 12 is a portion of a modified gate array simulation model for use in creating test vectors when converting an exemplary PLD directly into a gate array in accordance with the present invention.  
         [0045]    [0045]FIG. 13 is a block diagram of a portion of a base gate array device into which an exemplary PLD can be directly converted in accordance with the present invention.  
         [0046]    [0046]FIG. 14 is a schematic diagram representation of the portion of a base gate array device shown in FIG.13. 
     
    
     DESCRIPTION OF PREFERRED EMBODIMENTS  
       [0047]    The present invention now will be described more fully hereinafter with reference to the accompanying drawings, in which preferred embodiments of the invention are shown. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. Like numbers refer to like elements throughout.  
         [0048]    [0048]FIG. 5A illustrates a PLD device  500  of a type manufactured by Altera Corporation of San Jose, Calif., which can be converted directly to a gate array in accordance with the present invention. Device  500  has a row and column architecture, with multiple I/O elements  510  on four sides connected to row  502  and column  503  interconnects, with logic blocks (LBs)  520  disposed along the rows and columns in a two dimensional format. Each LB  520  contains  8  logic elements (LEs)  30  and has multiple interconnections to its adjacent row interconnect  502  and column interconnect  503 , as illustrated in FIG. 5B. Control signals  540  are derived from row interconnect  502 . Local interconnect  550  allows input lines  560  to LE  30  be drawn from row interconnect  502  or from feedback bus  570  made up of the eight LE-Out lines  14  from each of the logic elements  30  in the logic block.  
         [0049]    [0049]FIG. 5C shows a block diagram of exemplary logic element  30  containing look-up table  40 , fed by four LE input lines  560  and Carry-in line  41 , cascade chain logic  15 , register  16 , register bypass circuit  12  , and LE-Out MUX  10  controlled by logic state  11  and yielding LE-Out line  14 . Logic element  30  also contains clock select MUX  50  controlled by logic state  51  and selecting one of two LE control signals  540  to go into register  16 . Clear/Preset logic  571  uses one of the four LE input lines  560  and two of the four LE control signals  540  to determine the states of preset and clear on register  16 . This exemplary portion is a logic element of a FLEX 8000 architecture used in PLDs manufactured by Altera Corporation of San Jose, Calif.  
         [0050]    PLD devices are manufactured with different fundamental logic architectures, the two most popular of which are the lookup-table architecture, and the product-term architecture. Examples of lookup-table architecture are devices such as the FLEX 8000 family manufactured by Altera Corporation of San Jose, Calif., and the XC4000 family manufactured by Xilinx, Inc. of San Jose, Calif. Examples of product-term architecture are the MAX 7000 family manufactured by Altera Corporation, and the XC9500 family manufactured by Xilinx, Inc. In one aspect of the present invention, it is advantageous for the base gate array device into which the PLD device is to be converted to have the same architecture type, such that if the PLD to be converted has an architecture containing logic elements made up of a four input lookup table, cascade logic, a register, a register bypass path, and arithmetic carry capability, then the base gate array device into which the PLD is to be converted should have blocks containing the same or equivalent elements. Likewise, if the PLD to be converted contains macrocells with five product terms each with thirty-six input terms feeding an OR gate, a register, product term sharing logic, and a register bypass path, then the base gate array device into which the PLD is to be converted should have blocks containing the same or equivalent elements. Since this will also allow segments of logic in the PLD, when converted and placed into the gate array device, to be in the same relative locations as they occupied in the PLD. In this way internal logic placement and routing can most easily be matched, and internal timing and logic consistency can be most easily maintained, without need of logic resynthesis, or placement and routing steps.  
         [0051]    [0051]FIG. 5D is a block diagram of such a base gate array device  599  into which PLD device  500  with a first operational functionality can be directly converted, to yield a gate array device with the first operational functionality. Base gate array device  599  contains at least the logic resources and signal path resources present in PLD device  500 . Each logic building block  590  of base gate array device  599  contains eight gate array logic element sections  70  (as shown in FIG. 13), each corresponding to logic elements  30  of PLD device  500 . The device contains I/O elements (IOE)  591  containing multiple I/Os, connected to row  592  and column  593  interconnect structures, corresponding to like elements  510 ,  502 , and  503  of PLD device  500 . It is a feature of the present invention that the congruence of logic resources and signal path resources of PLD device  500  and base gate array device  599 , allows a high efficiency of conversion when PLD device  500  with a first operational functionality is converted to a gate array device with the same first operational functionality. It can be noted that the congruence of logic and signal path resources of PLD device  500  and base gate array device  599  include such things as the row and column architecture of elements  502 , and  503  to  592  and  593 , and the relative placement of major logic blocks such as LB  520  and LBB  590 . Interconnect structures of the base gate array device  599 , such as row  592  and column  593  interconnects should have at least the signal path resources of corresponding row  502  and column  503  interconnect structures of PLD device  500 . It is less important that the congruence extend to the physical placement of elements  30  within block  520  compared to the placement of sections  70  within blocks  590 . It would be perfectly acceptable for elements  30  to be stacked eight high in a vertical arrangement in block  520  of PLD device  500 , while logic element sections  70  of LBB  590  of base gate array device  599  were disposed in a two by four matrix. This is due to the relative importance of distance and length of signal line in determining signal delays on an integrated circuit. It will be understood by one skilled in the art that the relative signal delays between logic elements  30  within the same LB  520  will be small in comparison to the signal delays generally encountered between logic blocks  520  located in different areas of PLD device  500 .  
         [0052]    [0052]FIG. 13 is a block diagram of a gate array logic element section  70  of a base gate array device  599 , corresponding to the logic element  30  of PLD device  500  shown in FIG. 5C, which is suitable for direct conversion using the invention described herein from the PLD device  500  into the corresponding gate array device  599 . It can be seen that the base gate array logic element section  70  also contains similar logic resources and signal path resources to logic element  30  of PLD device  500 . Among these are lookup-table (LUT)  71  corresponding to the lookup-table  40  of PLD logic element  30 , cascade logic  76  corresponding to similar logic  15  in logic element  30 , and a register  72  to correspond with register  16  of logic element  30 . FIG. 13 also shows that a logic element section  70  of a base gate array  599  in accordance with one aspect of this invention has the addition of multiple internal scan registers  73 ,  74 , and  75  for use in testing the completed device.  
         [0053]    [0053]FIG. 14 shows a schematic diagram of the logic element section  70  of the base gate array shown in FIG. 13. This schematic diagram more completely shows the logic resources and possible connections of the base gate array logic element section  70 , including register  72  and scan registers  73 ,  74 , and  75 . It will be apparent to one skilled in the art that additional internal scan registers can be placed as required in other areas of gate array device  599  such that scan test of the majority of the operational logic can be performed without use of all the device pins.  
         [0054]    Referring now to FIG. 4, preferred operations  400  will now be described for designing an application specific integrated circuit (ASIC), by directly converting bitstream data of a programmable logic device (PLD) having first logic and signal path resources into connection data (e.g., a netlist) which is compatible with an ASIC (e.g., gate array) having the first logic and signal path resources as well. This bitstream data, programming-ready for writing directly into the PLD, or into a Programmable Read-Only Memory (PROM), may be a file generated by MAXPLUS™ II software in lntel™ hex format, or other appropriate format for the PLD. As illustrated by Block  410 , an operation is initially performed to automatically decode a PLD bitstream or programming file, Block  412 , and generate a connection/configuration data file therefrom, Block  415 . As described more fully hereinbelow, this decoding operation is performed using PLD definition data, Block  408 . This definition data may include a data set that describes the function of a majority of the bits contained within the bitstream or a data set that describes the functionality of the PLD as defined by the bits, or both. This connection/configuration data may represent logic, logic states and interconnections specified in a bitstream provided by a user. The data will contain information relating to the configuration of logic resources into various logic segments, as well as relative placement of these logic segments, and the routing of signal paths. The combination of the circuit resource and routing resource information of the base gate array and the connection/configuration data can yield information about the placement of the logic resources and the routing of signals between those resources (including the starting and terminating points of at least one connection path on the target gate array integrated circuit).  
         [0055]    Operations are then performed to convert the configuration/connection data to laser fuse coordinates and/or mask data, Block  430 . Here, the connection/configuration data file, Block  415 , and base gate array integrated circuit connection coordinate data, Block  435 , are used to create a laser fuse file, Block  440 .  
         [0056]    A test vector file, Block  495 , is also generated by automatically creating test vectors, Block  490 , from the modified gate array models, Block  480  . These test vectors may also be used for scan-based testing. As will be understood by those skilled in the art, scan-based test methods may utilize a plurality of storage elements which are connected together as a chain on an integrated circuit substrate. During testing, these elements can be loaded with input test data using a reduced number of I/O pins, as described by U.S. Pat. No. 5,519,713 to Baeg et al. entitled “Integrated Circuit Having Clock-Line Control and Method for Testing Same”.  
         [0057]    In addition, the laser fuse file, Block  440 , can be used to fabricate a lasered device, Blocks  445  and  448 . Alternatively, the laser fuse file Block  440 , and/or the connection/configuration data, Block  415 , can be converted to a mask making data file, Blocks  450 ,  452 . Using conventional operations, the mask making data file can be used to make fabrication masks, Block  460 , and fabricate the target gate array (having at least the same signal path resources and logic resources as the programmed PLD), Block  465 .  
         [0058]    According to another aspect of the present invention, the decoding operation may also generate hookup data as connection/configuration data which describes a plurality of patterned interconnect segments in the gate array which, when joined, create an electrically conductive path between starting and terminating points, and hookup coordinates which describe, relative to an origin, connection points between these patterned interconnect segments. These coordinates may also give the location of points of disconnect to form a single path out of a plurality of possible signal paths. For example, the base target gate array may have both the first and second nets connected and the connection/configuration data file may provide hookup data which designates which of the first or second nets is to be disconnected in the base gate array to provide the desired function.  
         [0059]    The above-described operations for decoding a bitstream for a PLD  500  having first logic and signal path resources therein into a connection/configuration data file for a gate array integrated circuit having equivalent logic and signal path resources will now be more fully described with reference to FIG. 5C. In particular, FIG. 5C illustrates a exemplary portion of a programmable logic device (PLD) element  30  which can be converted directly to a gate array integrated circuit by decoding the bitstream which programs the PLD element  30  as a connection/configuration data file. This exemplary portion is a logic element of a FLEX 8000 architecture used in PLDs manufactured by Altera Corporation of San Jose, Calif. Here, the decoding process utilizes base PLD definition data to interpret a pattern of bits within a bitstream or programming file used to program the PLD  500  and determine the function of each bit or combination of bits. This bitstream may take the form of:  
         [0060]    000010000000001000000111000000 . . . 1000000010100  
         [0061]    000010000001000010000001110 . . . 000000101100001  
         [0062]    0000000001000000000000000 . . . 1110000100000010  
         [0063]    00000110000000001110000 . . . 111110000  
         [0064]    000010000001101000000111000000 . . . 1000000110100  
         [0065]    000010011001000010000001110 . . . 0001001011  
         [0066]    000010000110001000000000000000 . . . 111001010  
         [0067]    00001001100110000000001110000 . . . 111110001.  
         [0068]    The geometry of the bits within the bitstream can be representative of the logic and signal path resources of the PLD or it can be independent of the PLD structure. For example, bit “n” of the bitstream as the control for multiplexer  10  via a select input  11 . If the multiplexer  10  is programmed within the PLD to pass input line  12  to the output line  14 , the LE-OUT signal will be provided directly by the output  20  of the cascade chain  15  in the target gate array. Alternatively, if the multiplexer  10  is programmed to pass input line  13  to the output line  14 , the LE-OUT signal will be provided directly by the output of the register  16  in the target gate array. Thus, the function of bit “n” in the bitstream would be to determine whether LE-OUT is registered or not registered. Then, upon decoding of the bitstream, the connection/configuration data file would indicate whether a first net interconnecting the output  20  of the cascade chain  15  directly to LE-OUT is to be provided or whether a second net connecting the output Q of register  16  to LE-OUT is to be provided. A similar process is also repeated for each of the remaining bits in the bitstream, with the PLD device definition data (Block  408 ) associating a particular bit or bits in the bitstream with a function and the gate array device connection/configuration data (Block  415 ) associating the function with a plurality of nets. The high efficiency of this decoding process is preferably achieved by the base gate array having similar signal path and logic resources as the target PLD. In particular, the base gate array  599  should have at least the logic and signal path resources available in the target PLD  500 .  
         [0069]    [0069]FIG. 6 shows a pictorial representation  600  of a portion of data set  408  showing how an exemplary bitstream file  412  for such a PLD device such as device  500  disposed in  5  rows and  22  columns of LEs  30  grouped into logic blocks  520  of eight logic elements would commonly be organized. It is common for records other than the header and trailer to be a uniform length, however this is not a requirement. FIG. 6 illustrates such an exemplary bitstream file of  208  records in length with a uniform record length of 240 bits each. The bitstream file begins with a header record  610 , followed by several records  620  containing configuration bits for the top I/Os  510 . At the bottom of the file are additional bottom I/O configuration records  630  and a trailer record  640 . The center section of the file contains multiple groups of records for configuring each of the five rows of logic block  520  as well as the interconnections to rows  502  and columns  503  and the left and right side I/Os  510  as well. The third row is described by records  85  to  124 . Within this section records  117 - 124  can be seen to contain the LE Configuration bits, and more particularly, bits  21 - 30  of these records  650  can be seen to contain the LE Configuration bits for the LB in column  2  of row  3  and these blocks of LE Configuration bits are replicated in a typically geometric fashion for columns  1  to  22 .  
         [0070]    [0070]FIG. 7 shows a pictorial representation  700  of another section of data set  408 , containing the definitions of a portion of the bits in the LE Config area for each LB. This area of the file  412  is shown to contain 8 records of 10 bits in width. It can be seen from table  700  that there is one record for each of the eight logic elements  30  in the logic block, which happen in this case to match the order of the logic elements, but this is not required. Table  700  show that bit fields  2  and  8  are unused and that the order of the other bits and their polarities are constant throughout the block, but this will depend upon the layout of PLD device  500  and need not be constant. Table  700  also shows logic states for only single bits, with each bit defining the logic states of two logical connections only. This is not a limiting aspect of the invention, and other numbers of bits or combinations of bits and other numbers of logical connections may be more advantageous in other cases. Entry  701  of table  700  corresponds to the setting of logic state  11  controlling MUX  10  , and shows that to make the LE-Out of the second LE in an LB be registered, the third bit of the second record of this block is set to 1 such that KREG is true and KUNREG is false. For bypass of register  16  by MUX  10 , the bit is set to 0, such that KREG is false and KUNREG is true, where the values of KREG and KUNREG correspond to the possible logical connections of MUX  10  of logic element  30  of the PLD device  500  to be converted. It will be apparent to one skilled in the art that computing the position of this bit “n” within file  412  can be easily accomplished, and that by observing the status of this and other bits within the bitstream file  412 , given a full description of the file with tables such as those described above, the intended functions of the logic elements, and the intended connections within the PLD can also be established. It will also be apparent to one skilled in the art that there are multiple ways to tabulate and store the PLD definition data  408 , other than in the forms shown in these drawings.  
         [0071]    [0071]FIGS. 8 and 9 show exemplary tables which are a portion of data set  435  for use in the calculation of hookup coordinates in step  430 . Tables  800  and  850  which indicate the base coordinates of LBs for the calculation of such hookup coordinates show the respective Y coordinate bases of each of the rows of LBs in the gate array base array relative to an origin, and the X coordinate bases of each column of LBs within each row relative to an origin. Table  860  shows the offsets of individual connection or disconnection points relative to such LB base coordinates. Referring to the example above, the base coordinates of the LB located on the third row and second column would be (−1910,50). Referring to FIG. 9 we see that when the first operational functionality of PLD device  500  includes setting LE-Out to registered, this corresponds to KREG=true and KUNREG=false. In this example we have used “true” to correspond to connections made or kept and “false” to correspond to connections broken or not made. Therefore we would make the connection corresponding to KREG=true and break the connection corresponding to KUNREG=false. Therefore a connection to be made or retained would be computed equal to the base address of the LB (−1910,50) from tables  800  and  850 , plus the offset for KREG of LE  2  (70,810) from table  860 , resulting in coordinates of (−1840,860) and coordinates of a connection to be broken or not made would be computed likewise to be (−1910,50)+(180,775)=(−1730,825). These coordinates would then be entered into file  440  for use in making mask data  452  or lasering the device  448  using techniques well known in the art. Operations are then performed to automatically create gate array device models, Block  480 , by modifying base gate array integrated circuit simulation models, Block  472 , using the connection/configuration data file, Block  415 .  
         [0072]    [0072]FIGS. 10A through 10F show an exemplary portion of a base gate array device simulation model  472  in Verilog for a section  70  of the base gate array to correspond to the logic element  30  of device  500 . FIG. 10C describes three internal scan based test registers  830  labeled “iscan i — 25”,  831  labeled “iscan i — 26”, and  832  labeled “iscan i — 27”. FIG. 10D contains various logic and register  840 , the equivalent to register  16  with the title “leff i — 29”. FIG. 10E contains the settings for the 16 lookup-table values for the base gate array LUT  71 , and FIG. 10F contains the assignments for the LE configuration bits of the base gate array referred to in table  700 .  
         [0073]    [0073]FIG. 11 shows a section  833  of connection/configuration data file  415  which shows several logic states and configurations specified by bitstream file  412  as decoded by process  410 . More particularly this section of file  415  refers to the LE configuration bits for LE  2  of the LB on row  3  and column  2 , designated by the line prefix “LB,3,2,LE2,”. Each line ends with the desired state of a connection or logic state, such as &lt;KREG&gt;=T and &lt;KUNREG&gt;=F, designating that the lines in the base gate array model  472  on FIG. 1 OF ending in &lt;KREG&gt; are to be included in the modified model  480 , and the lines ending in &lt;KUNREG&gt; are not to included in the modified model  480 , after processing by step  470  is completed. FIG. 12 shows the modified lines of code of the modified model  480  corresponding to the settings defined by file  415  as shown on FIG. 11. It will be apparent to one skilled in the art that there are other ways to create modified gate array simulation model  480 , and that model  480  can be subsequently used in the creation of test vector file  495 .  
         [0074]    In the drawings and specification, there have been disclosed typical preferred embodiments of the invention and, although specific terms are employed, they are used in a generic and descriptive sense only and not for purposes of limitation, the scope of the invention being set forth in the following claims.