BACKGROUND OF THE INVENTION

1) Field of the Invention

The field of invention is electronic design tools and automation, and more specifically methods and systems for facilitating electronic circuit and chip design using resources accessible over a distributed electronic network such as the Internet.

2) Background

The electronics industry produces ever more advanced chip and circuit designs with the assistance of continuously improving design and verification tools. Chip designs may contain tens or hundreds of thousands of gates per chip, and will soon be in the range of millions of gates per chip. Engineers generally require advanced software tools to lay out a chip design and to help manage the huge volume of information associated therewith.

In a high-level view of the electronic design process, a design team takes a product idea from conception to completion over a period of time referred to as “time-to-market.” Increased competition has resulted in immense pressure to reduce time-to-market with new products, because the first company to the market with a new product can typically expect to capture and hold a large market share against later competitors. In this environment, a difference as small as a few days between the planned and the actual shipment of a product may make an enormous difference in its profitability and in the revenue it generates.

In the present environment for designing large scale circuits and complex chips, time and personnel are often short, and budgets are tight. However, design engineers often discover in the middle of the design process that additional tools for automated design and verification are needed, especially if the schedule begins to slip because the team is using tools that are outdated, inadequate for or unsuited to the tasks to be performed, or incompatible with other tools being used. The ability of design engineers to obtain the design tools they need is nevertheless hindered by bureaucratic and cost considerations. Distributors of automated design tools often require purchasers to enter long-term licenses (e.g., 99 years), even though such tools generally have a lifespan of 5 to 10 years before becoming obsolete. Such long-term lease requirements increase design costs and require large capital expenditures by a company. As a result, a long and inefficient purchasing process is typically required in most organizations to purchase such tools. This can lead to delays in obtaining the best tools for the design tasks at hand.

The purchasing process for design and verification tools is inefficient and costly for a variety of reasons. Typically, design engineers have to endure a lengthy internal evaluation and justification procedure for the large capital expenditures involved in obtaining design or verification software. Potential suppliers must be identified and brought in for presentations and demonstrations. Many suppliers perform detailed benchmarks for comparison against one another, and those benchmarks must be evaluated by the responsible members of the design team. Time-consuming supplier negotiations and bureaucratic approval procedures then ensue, before the design team receives authority to order the desired design tool. Despite the slowness of this process, few companies will allow a design team to simply go to a supplier and purchase the tool they want due to the large capital expenditures involved, even though the desired tool is typically the one that is recommended at the end of the evaluation process.

Eventually, when the selection and purchase process has been completed, the design tool must then be installed and tested before use. In the course of this process, weeks or months may be consumed—time that a design team working on a time-critical project can ill afford to waste.

Traditionally, design and verification tools are installed at the end user's site and integrated into the company's existing tool set by an internal computer-aided design (CAD) group whose purpose is to support the engineers. As software tools grow in complexity and diversity, the ability of internal CAD groups to effectively support the most modern design and verification tools diminishes. Further, CAD support personnel are expensive overhead. As a result, an increasing number of companies are choosing not to hire CAD support personnel in order to save money. However, without internal CAD personnel, the individual engineers are left to install and support the tools themselves—a difficult and frustrating proposition that can consume a large number of invaluable working hours.

In addition to high overhead for support personnel, automated design tools also have significant associated hardware costs. Many design and verification programs, particularly simulation programs, require an enormous amount of computing capacity in order to perform their tasks in a reasonable period of time. Thus, after a software tool is selected, additional computer hardware may be required to run it. The need for this additional hardware may not be immediately apparent, causing delays in product development once the need is realized. Further, the design and verification tools may need to be run, albeit critically, for only a few days or weeks, making it potentially inefficient from a capital standpoint to purchase the additional computing power to run such products.

Another drawback with the present way in which design and verification tools are acquired and used relates to technical support. Vendors often have help lines available to users needing technical support for a given software tool. However, assuming that the engineer gets past the frustrating maze of voicemail and one or more layers of less-knowledgeable first-line support personnel which typically characterize vendor help lines, it often takes a long time for the engineer to explain, and for the support personnel to resolve, an issue with a complex tool as applied to a complex circuit. For serious problems, the vendor may send a field applications engineer to the job site, but it is expensive to do so, and several days may pass before a field applications engineer arrives. During that time, the entire design project may remain at a standstill.

A recent trend to increase design speed and efficiency involves the re-use or recycling of electronic circuit blocks or subsystems, which are alternatively referred to as “cores”, “virtual component blocks” or “IPs” (an acronym for “Intellectual Properties,” which denotes the proprietary nature of these pre-packaged circuit blocks). Once the design for a virtual component block has been tested and verified, it can be re-used in other applications which may be completely distinct from the application which led to its original creation. For example, a subsystem for a cellular phone ASIC may contain a micro-controller as well as a digital signal processor and other components. After the design for the cellular phone subsystem has been tested and verified, it could be re-used (as a virtual component block) in, for example, an automotive application. Design reuse of virtual component blocks allows a designer to complete a design much faster than building the entire design from scratch, and avoids the need for debugging, testing and verification of the subsystems embodied in the virtual component block. Examples of virtual circuit blocks or IP cores that are commercially available at present include Viterbi decoders, microcontrollers, digital/analog converters, and encryption/decryption processors, to name a few.

While virtual circuit blocks (i.e., IP cores) provide a means for reducing time-to-market by allowing for the purchase of standard blocks of code, there are a number of barriers to the convenient sale and use of virtual circuit blocks. With regard to quality assurance, for example, there are few, if any, standard methodologies for a designer to be assured of the quality of a virtual circuit block or its suitability for a particular design. Conversely, there are few, if any, standard methodologies for a seller of virtual circuit blocks to demonstrate the quality of the products to prospective customers. Another barrier is protection of the code and/or data comprising the virtual circuit block. Companies providing virtual circuit blocks are in need of a way to track the usage of their products and to protect the code and/or data in those blocks against theft, and such methodologies are preferably unobtrusive, yet allow full access to information required to incorporate those IP cores into a design. Another issue is data format. A virtual circuit block purchased for use in a circuit design must be compatible with the data formats used in that design. However, standards for interfacing with virtual circuit blocks, if they exist, are still evolving. As a result, becoming familiar with an interface format for a virtual circuit block may require a significant amount of work, as well as integrating a virtual circuit block into a circuit design, thus reducing the time advantage obtained through the use of the virtual circuit block. Transaction overhead in the form of high sales and legal costs also discourages sale and use of virtual circuit blocks. For example, legal review by one or both parties is often required with regard to the licensing of virtual circuit blocks.

Component selection is also an area which suffers from inefficiencies and unnecessary time delays. An engineer may consult printed catalogs put out by component distributors to learn about and select parts, or may, using the Internet, visit a website of a supplier of manufacturer, where information about components may be found, or may use a search engine to try to gather product information on the Internet. However, searching the Internet for individual components can be time-consuming and tedious. Further, current search engines and methodologies are inefficient and incomplete, and may thus return search results that do not include websites offering components that a designer could beneficially use in a design. Engineers also may receive unsolicited data sheets from manufacturers, but such data sheets are often discarded, lost or forgotten about. With increasing pressures to decrease time to market, it has become more difficult for engineers to spend time talking to supplier or distributor sales representatives, exacerbating the problem of information gathering about components.

Another problem experienced with the chip design process is that knowledge concerning design and verification processes is fragmented, and it is difficult to capture and maintain such knowledge. Attempting to discern through observation and study the individual design processes of many individual engineers is very challenging. Moreover, the design process can rarely be discerned from final blueprints or products, and is generally difficult to determine from draft or working documents. Different engineers will approach design in different fashions, which they may not even be able to articulate. Interviewing engineers to obtain data about the engineering design process is likely to be unproductive, and to consume a tremendous amount of time for a comparatively small payoff. Thus, benefits in training and improved methodologies that could result from metrics regarding the engineering design process continue to go unrealized.

Some attempts at addressing problems caused by fragmented design and verification processes involve exclusive partnering arrangements among companies that specialize in different areas of the design and verification process, in order to narrow the range of products and services that need to be learned by engineers and supported by internal technical staff. For example, a partnership of electronic design companies may include a provider of design verification tools, a provider of electronic components, and a company that ties them together. In the partnership model, compatibility issues can be addressed more easily, because a limited number of companies are involved. Further, increased revenue is created by influencing a customer of one partner at one phase of the design process to utilize the products or services of another partner in a different phase of the design process. However, a partnering arrangement drastically reduces the choices available to a design team, and may prevent the most optimum product from being used.

One approach for expediting the design process is to provide certain types of design and verification tools—in particular, FPGA synthesis tools—at a remote computer farm that can be accessed over the Internet. Under this approach, the FPGA synthesis tools are run on a central server farm, or computer farm, owned by a single applications service provider. A server farm, or computer farm, is generally a network of processors that are linked together to accomplish higher intensity computing tasks. In an illustrative system utilizing this approach, the applications service provider rewrites the interface of each offered FPGA synthesis tool in the Java® computing language, allowing usage of the tool on a wide variety of computing platforms and operating systems through standard, commercially available Internet browsers. A drawback of this approach is that the user is limited to the FPGA synthesis tools resident in the server farm of the applications service provider for which interface code has been written. Furthermore, the Java® language is notoriously slow, which can frustrate engineers and slow down the design and verification process.

It would be advantageous to connect participants in the electronic design process, including end users and suppliers, through a single portal site that facilitates information exchange and commercial transactions. It would further be advantageous to make a wide variety of design and verification tools readily and conveniently available to design engineers, and to allow use of such tools without a large initial capital outlay in either software or hardware. It would further be advantageous to provide a mechanism for pooling knowledge and information concerning chip design techniques, applications, products and tools. It would also be advantageous to provide a convenient means for allowing engineers to incorporate virtual circuit blocks into their designs.

SUMMARY OF THE INVENTION

The invention in one aspect provides a multi-faceted portal site allowing connection over a distributed electronic network, such as the Internet, to a plurality of end user systems and suppliers.

In a preferred embodiment, a portal site acts as a server in the context of an n-tier client/server network, and connects electronic designers and design teams to design and verification tool and service providers on the other through a single portal site. Examples of tools and services accessible to users through the portal site include electronic design automation (EDA) software tools, electronic component information, electronic component databases of parts (or dynamic parts), computing and processing resources, virtual circuit blocks, design expert assistance, and integrated circuit fabrication. Such tools and services may be provided in whole or part by suppliers connected to the portal site. Users accessing the portal site are presented with options in a menu or other convenient format identifying the tools and services available, and are able to more rapidly complete circuit designs by having access to a wide variety of tools and services in a single locale. The portal site may facilitate purchase, lease or other acquisition of the tools and services offered through it.

In a preferred embodiment, a portal site tracks the movements of users through the portal site in order to learn about the design preferences and design approaches of users individually and in the aggregate. Previous actions taken by the user and by similarly-situated users may be considered in determining which information presented to the user, or in what order to present information to the user, thereby providing contextually-driven access.

Further embodiments, variations and enhancements are also described herein.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1

is an abstract representation of a portal connecting end users and suppliers of electrical design tools and services.

FIG. 2

is a more detailed diagram of a system for facilitating electronic design by connecting end users with suppliers of electrical design tools, services, information and/or other resources.

FIG. 3

is a flow chart illustrating a process for selecting and managing components in an electronic design, as may be used, for example, in connection with the system of FIG.

2

.

FIG. 4

is a flow chart illustrating a process for user profiling and design assistance, as may be used, for example, in connection with the system of FIG.

2

.

FIG. 5

is a flow chart illustrating a process for purchasing components by accessing a portal site such as shown in

FIG. 2

over a distributed electronic network.

FIG. 6

is a flow chart illustrating a process for providing information and services regarding virtual component blocks or IP cores, as may be used, for example, in connection with the system of FIG.

2

.

FIG. 7

is a flow chart illustrating a process for providing information and services regarding integrated circuit fabrication, as may be used, for example, in connection with the system of FIG.

2

.

FIG. 8

is a flow chart illustrating a process for providing information and services regarding electronic design automation, as may be used, for example, in connection with the system of FIG.

2

.

FIG. 9

is a flow chart illustrating a process for providing access to computing/processing resources through a portal site such as illustrated, for example, in FIG.

2

.

FIG. 10

is a flow chart illustrating a process for providing expert design assistance and services through a portal site such as illustrated, for example, in FIG.

2

.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

FIG. 1

is an abstract diagram in accordance with a preferred embodiment of a electronic design automation resource system

100

for facilitating electronic design by provision of useful goods, services, information and other resources. As illustrated in

FIG. 1

, a plurality of end users

102

and a plurality of suppliers

106

are connected, over a distributed electronic network such as the Internet, to a portal site

104

. End users

102

would typically include circuit designers and users of electronic design automation (EDA) software tools, but may also include a variety of other types of users, as described in more detail herein. Suppliers

106

typically would include providers of EDA software tools, virtual component blocks or IP cores, foundry services, hardware components, expert design services, and a variety of other resources (whether in the form of goods, services, information or other resources), as further described herein.

In a preferred embodiment, the portal site

104

provides engineers and other users

102

access to information on electronic components, and enables commercial transactions between end users

102

and suppliers

106

of the electronic components. In a particular embodiment, the electronic component data is stored in a remote database in the form of “dynamic parts,” having graphical representations with standard symbol and footprint data ready to be transferred (i.e., copied) into an end user's design. Part of the information copied from the remote electronic components database to the end user's workstation (or design database) includes a link to the remote database or a supplier's database, enabling a variety of useful capabilities, including provision of information such as part lead time, availability and cost. Data sheets, timing information and the like regarding the electronic components may also be made available to assist the designer.

In another embodiment, the portal site

104

connects end users

102

who need extra computing power (for example, to run a simulation program) with suppliers

106

who have excess computing resources. The portal site

104

may facilitate the location of computing or processing resources by providing a database of computing/processing sites or resources, and by trying to match up the end user

102

with the most suitable computing/processing site or resource. The end users

102

may select a computing resource supplier

106

based on cost, the type and availability of the supplier's computing resources, or other data made known by the supplier

106

.

In another embodiment, the portal site

104

makes design automation tools, such as simulation software, available to end users

102

who need them. The portal site

104

may facilitate the location of needed design automation tools by providing a database of design automation tools, and by trying to match up the end user

102

with the most suitable design automation tool. The supplier

106

of design automation services may offer the design automation tools on a license or other basis, through a transaction carried out via the portal site

104

.

In another embodiment, the portal site

104

connects end users

102

who need design assistance with suppliers

106

of expert knowledge, such as professors and consultants, or even expert publications. The portal site

104

may facilitate the search of suitable design experts, by providing a database of design experts and trying to match up the end user

102

with the most suitable design experts.

In another embodiment, the portal site

104

connects end users

102

to a foundry or semiconductor manufacturers. The portal site may facilitate the search for a suitable foundry or semiconductor manufacturing facility, by providing a database of such, and by attempting to match up the end user

102

with the most suitable foundries or manufacturing facilities. The portal site

104

provides views into the compatibility of component suppliers

106

with one another and with the standards utilized by specific foundries or semiconductor manufacturers, thus allowing the end users

102

to select appropriate upstream component suppliers

106

early in the design process.

In another embodiment, the portal site

104

connects end users

102

looking for information on virtual circuit blocks or IP cores, or interested in purchasing such, with suppliers

106

offering virtual circuit blocks or IP cores. The portal site

104

may facilitate the locating and acquisition of suitable virtual circuit blocks or IP cores by, for example, providing a catalog of available IP cores, information regarding the IP cores, and access to mechanisms for protecting IP cores from unauthorized user or copying.

In another embodiment, the portal site

104

tracks the movements of the end users

102

through the portal site

104

, in order to learn about the design preferences and design approaches of users individually and in the aggregate. Previous actions taken by the end user

102

are used in determining information presented to the end user

102

in a later visit to the portal site

104

, thereby providing contextually-driven access. Also, actions taken by other similarly situated end users

102

working on analogous designs may be used in determining what information should be presented to the end user

102

, or in what order such information should be presented.

In another embodiment, a plurality of the above features are combined at a single portal site

204

to provide comprehensive support for the circuit design and development process.

FIG. 2

is a more detailed diagram of a system

200

for facilitating electronic design by connecting end users with suppliers of electrical design tools, services, information and/or other resources. As illustrated in

FIG. 2

, a variety of users and resource providers are connected to a portal site

204

over a distributed electronic network such as the Internet

230

, for the purpose of facilitating electronic design. In the system

200

illustrated in

FIG. 2

, user systems

220

connect over the Internet

230

to the portal site

204

. While only a single user system

220

is shown in

FIG. 2

for purposes of illustration, it will be understood that many user systems, on the order of hundreds or thousands, may so connect to the portal site

204

over the Internet

230

or other distributed electronic network. For the purposes of the following discussion, it will be assumed that the user systems are connected to the portal site

204

over the Internet

230

, although it will be understood that other types of distributed electronic networks may also be utilized for such connection. Standard object data models, such as Corba™, BizTalk™, or DCOM™, for example, may be used to link a user system

220

to the portal site

204

over the Internet

230

.

User systems

220

connected to the portal site

204

over the Internet

230

may comprise standalone computers or workstations, which may connect directly to the Internet

230

, or may be part of a local area network (LAN) which comprises designated network hardware and/or software for connecting to the Internet

230

, or may connect to the portal site

204

through some other means. A user system

220

preferably comprises a means for navigating the Internet

230

such as a web browser

224

, which may comprise, for example, a standard commercially available product such as Microsoft's Internet Explorer™, Netscape's Communicator™, or Opera Software's Opera™. The user system

220

also preferably runs one or more supplier applications

226

in the form of computer programs or other software packages, such as, for example, E-Capture™, which is a commercial product available from Cadence Design Systems of San Jose, Calif. A “design console” interface

228

is also preferably provided as part of the user system

220

. The design console interface

228

may comprise a standalone client application software program installed on and running on the user system

228

. The design console interface

228

acts as an interface with the portal site

204

, and is preferably optimized to interlink the functions and processes offered by the portal site

204

in a faster, more robust and more efficient manner than would otherwise be provided by a standard web browser. A universal data interface format or mark-up language, such as XML, is preferably used as a primary data interface between the various components of the system

200

. The details of XML are well-known to those in the art of computer programming.

Turning now to the portal site

204

of the system, the portal site

204

acts as an aggregation point for many suppliers

106

(see

FIG. 1

) in potentially widely different domains. The portal site

204

preferably includes a web server

260

which interfaces with outside entities (such as user system

220

) seeking access to the portal site

204

, acting as an intermediary between those outside entities and the various applications available at the portal site

204

. The portal site

204

also preferably includes an application server

232

, which receives requests from outside entities passed through the web server

260

and responds thereto by accessing the databases and other resources included in or accessible through the portal site

204

. The application server

232

also serves a command-and-control function within the portal site

204

.

The application server

232

preferably accesses one or more databases containing information useful to design engineers, such databases including, for example, a user database

235

, a metrics database

238

, an affinity database

242

, a catalog database

246

, and a business database

250

, the functions of which are described later herein. The user database

235

is accessed through a collaboration server

234

, the metrics database

238

through a metrics server

236

, the affinity database

242

through a context server

240

, the catalog database

246

through a catalog server

244

, and the business database

250

through a business server

248

. Additional databases and servers may be included if desired. Also preferably connected to the portal site

204

over the Internet

230

are one or more component supplier databases

209

, IP core databases

208

, EDA tool suppliers

210

, computing farms

205

, foundries

206

, and/or design experts

203

, the role of which will be explained in more detail herein with reference to

FIGS. 3 through 10

. In a preferred embodiment, the specifics of each user's visit to the portal site

204

are recorded in the affinity database

242

when the user completes a session. The information recorded may include, for example, the nature and size of the design on which the user is working, the components selected by the user, and the navigation path through the various resources at the portal site

204

, among other things.

One of more of the databases

235

,

238

,

242

,

246

and

250

provided by the portal site

204

may be configured with a distributed architecture, with the portal site

204

accessing information from other sites through secure XML tunnels. In particular, the catalog database

246

may advantageously be configured with a distributed architecture, with the portal site

204

accessing catalog information from remote databases (such as

208

and

209

) through secure XML tunnels. Caching may be used where the database architecture is distributed so as to improve access performance.

From a general standpoint, the collaboration server

234

provides collaborative services to both end users

102

and suppliers

106

(see FIG.

1

). The collaboration server

234

preferably integrates and serves collaboration-type applications such as chat, calendar, e-mail, online seminars, online conferencing, application and desktop sharing. The collaboration server

234

also preferably provides infrastructure support for expert design assistance through a “virtual” desktop presence, which allows real-time interaction of experts and designers.

The metrics server

236

assists in collecting data on usage of the portal site

204

and supplier services. In one aspect, the metrics server

236

may comprise a high performance, high capacity data store for data measured at the portal site

204

. Such data may include, for example, web traffic patterns, application usage, component usage (by monitoring electronic bills of materials, for example), and user rating feedback, among other things. The metrics server

236

preferably provides such information to a specialized portal data mining application.

The context server

240

preferably stores user profile data, which may be used for portal personalization, as well as “meta data” derived from analysis of the metrics data handled by the metrics server

236

. The context server

240

may also store data on purchasing history that can be used to provide suppliers with information needed to support the users.

The catalog server

244

preferably provides “electronic catalog” services to the client side software resident at the user system

220

. As noted, the catalog database

246

may be configured in a distributed architecture, and integrated through links and other resources by the catalog server

244

and/or catalog database

246

. Supplier catalog integration is preferably accomplished by use of a universal data format model such as XML.

The business server

248

supports business transactions between users and suppliers, as further described herein.

In a preferred embodiment, the portal site

204

provides a variety of useful resources for design engineers. Access to such resources may be conveniently described with reference to

FIGS. 3 through 10

, each of which illustrates a process for accessing information or other design resources relating to a particular area of design, development or manufacture. The portal site

204

thus, in one aspect, may provide an integrated set of resources for design engineers.

FIG. 3

is a flow chart illustrating a preferred process

300

for selecting and managing components in an electronic design, as may be used, for example, in connection with the system of FIG.

2

. In a first step

302

of the process

300

depicted in

FIG. 3

, a user at the user system

220

accesses the portal site

204

via the Internet

230

by entering the appropriate Unified Locator Resource (URL) or other applicable address, and in response the design console client software

228

displays a main design console menu screen on a computer screen at the user system

220

. Throughout the described process

300

, as well as the other processes described later herein, the display of data at the user system

220

is preferably accomplished by the transmission of appropriate commands over the Internet

230

from the portal site

204

; that is, the portal site

204

transmits data through the Internet

230

to the user system

220

in a suitable format (e.g., hyper-text markup language (HTML) or a similar format) where it is then displayed. Means for formatting and transmitting information over the Internet

230

are well known to those skilled in the art of computer programming.

In a next step

304

of the process

300

illustrated in

FIG. 3

, the user at the user system

220

preferably selects an icon, link or other indicia for the component selection and management resource. For example, the user may click on an appropriate icon or link displayed in the design console main screen so as to select the component selection and management resource. Such icons or links are commonly employed in Internet application software, and techniques for placing the icons or links in a graphical user interfaces are well known to those skilled in the computing arts. Alternatively, the component selection and management resource may be accessed in a text-based environment by typing or entering an appropriate command. When the user selects the component selection and management resource, a message indicating the user's selection is transmitted over the Internet

230

to the portal site

204

.

In response to the user selecting the component selection and management resource, a list of different types of parts available for use or purchase is then retrieved at the portal site

204

from the catalog database

246

, and then transmitted to and displayed at the user system

220

. The process of listing components is generally accomplished through the performance of steps

308

,

310

,

312

and

314

. Listed components may include, for example, capacitors, field-programmable gates arrays (FPGAs), digital signal processors (DSPs), and any other components a design engineer may find useful. The components may either be discrete components for placement on a printed circuit board (PCB), or else may be components and/or virtual circuit blocks for placement within an integrated chip design. If more than one specific type of part is available for a component, then, in step

306

, the user may select the component from the list provided in step

304

, which preferably causes display of the available parts corresponding to the particular component, in an ordering as preferably described below with respect to step

310

. For example, if the user selects a resistor as a component, the user system

220

may display a number of resistors having specified values, tolerances, and so forth. Alternatively, the user may be permitted to input search criteria to allow a search for all components meeting specified criteria, using, for example, ordinary database queries. For example, the user may search for all resistors having a resistance of 50 ohms and/or a tolerance of less than 5%. The user's search criteria may be provided to the portal site

204

over the Internet

230

, resulting in an appropriate database search query being executed. The results of the search then may be transmitted back to the user system

220

from the portal site

204

over the Internet

230

.

In a next step

308

, user profiling and context routines are preferably invoked to assist in determining an ordering of display of the specific parts falling under the category of component selected by the user. The user profiling and context routines are common to many of the processes expected to be run on the portal site

204

, and are described in more detail below with reference to FIG.

4

. In one aspect, the profiling and context routines access and analyze historical data about the user's movement patterns in the portal site

204

, and the movement of other users in the portal site

204

working on similar designs, so as to provide assistance to designers facing similar design issues.

The process

300

then proceeds with step

310

, wherein the application server

232

retrieves a list of available parts from the catalog data base

246

via the catalog server

244

based on the user's component selection in step

306

, the user's design information (if available), and profile and context data obtained from step

308

. In a next step

312

, the application server

232

ranks the available parts, preferably based upon the profile and context data obtained in step

308

. The predicted best or most suitable choices for the user's design are placed at the top of the listing, based on the available information. Other choices of available parts for the component type preferably follow the best or most suitable parts. In one aspect, the user benefits from past design experience of both his or her own design as well as that of other designers who have been in the position of making similar design choices in previous designs. In a next step

314

, the ranked list of available parts for the component type is transmitted from the portal site

204

to the user system

220

and displayed for the user's perusal. The ranked list of available parts may be displayed, for example, as a list of selectable strings, “hotlinks” or icons. The user reviews the ranked list of choices and, in step

316

, selects one of the available choices by, e.g., highlighting the entry and hitting a keyboard key (such as the return key), or clicking on the entry with a computer mouse, or selecting a number corresponding to the ranking of the desired part, or by any other selection means, the specifics of which are not essential to the operation of the inventive concepts described herein. The user's selection is transmitted from the user system

220

to the portal site

204

.

In a next step

318

, additional information about the part chosen in step

316

is displayed to the user. Such information preferably constitutes relatively high level data, and is generally intended to allow the user to determine relatively quickly whether the user should include the selected part in the design, look for a different part from the ranked list, or gather further information about the selected part. Preferably, the user is presented with icons or other interface features for conveniently selecting whether to immediately incorporated the selected part in the user's design, backtrack to the ranked list and look for a different part, or else pull up additional information about the selected part. If the user is interested in additional information, the process

300

proceeds to step

322

, wherein the user selects the appropriate interface feature (e.g., an icon or menu selection entry) to receive additional information about the selected part. The user's selection for more information is transmitted from the user system

220

to the portal site

204

. In a next step

324

, further information concerning the selected part is displayed. Such information may include detailed part information such as component data sheets, timing models (which may be in a language such as DTML or other timing description language), application notes, simulation models, signal integrity models (such as IBIS models), manufacturing information, or other information. A symbol and a footprint configuration for the selected part are also preferably provided, which may allow the user to make more informed decisions about placement of components in an overall design. Information displayed in step

324

may also include application notes regarding a component and its applications.

When the user is satisfied that the selected part is suitable for the user's design, then in step

328

the user selects the part by selecting the appropriate feature from the user interface. If, on the other hand, the user does not want to use the selected part, the process moves to step

332

, wherein the user selects the appropriate feature from the user interface to return to the ranked list of choices displayed in step

314

. If, on the other hand, the user decides to use the selected part in a design, the user then indicates such in step

328

by selecting the appropriate feature from the user interface. In a preferred embodiment, the process then continues with step

330

, wherein the user places a graphical representation (e.g., symbol) of the selected part into the user's design by moving, copying or dragging the symbol of the selected part into the schematic program being used to develop the design. As part of the process of bringing the selected part into the schematic program, information concerning the selected part is preferably copied and stored at the user system

220

in the design database

225

. Such information may include, for example, specifications concerning the selected part, as well as manufacturing information and a hyperlink to either the portal site

204

or a component supplier database

209

of the supplier or distributor of the selected part. Because of the link to a remote database, the parts selected from the portal site

204

and stored in the design database

225

at the user system

220

may be referred to as dynamic parts. Instead of storing the information concerning the selected part in the design database

225

, it may also be stored, for example, in a separate database at the user's physical location or at some remote location.

The steps for selecting specific parts are then repeated for the other desired components of the user's design. Thus, the process

300

returns to step

306

for each remaining component for which the user desires to select a part using the resources of the portal site

204

. Eventually, when the user finishes adding components to the design, the process

300

moves to step

334

, at which the design is considered complete. At a later point, in preparation for manufacturing the design, the process

300

optionally proceeds to step

336

, wherein a bill of materials is automatically generated from the components in the design. The user may initiate automatic generation of the bill of materials by making an appropriate menu selection using the design console client software

228

, or an application

226

at the user system

220

, or in some other manner.

In a next step

338

, a purchasing routine is optionally invoked, during which the selected parts are purchased. Details of a preferred purchasing routine are described later herein. In a following step

340

, the selected and purchased parts are shipped and delivered to a desired location, which may be the designer's physical location, the location of a semiconductor contract manufacturer (SCM), or any other manufacturing or usage site for the components. The component selection and management process

300

is preferably coordinated with other resources provided by the portal site

204

in order to increase the efficiency and effectiveness of the various and complementary circuit design, verification and manufacturing processes. For example, the component selection and management process

300

may be advantageously coordinated with an integrated circuit fabrication management process described herein, so as to facilitate the selection of parts that are easily obtained and assembled by a given foundry or manufacturer.

Further details relating to various aspects of a preferred component selection and management process are described in U.S. patent application Ser. No. 09/514,674 filed concurrently herewith, and hereby incorporated by reference as if set forth fully herein.

FIG. 5

is a flow chart illustrating a process

500

for purchasing components by accessing a portal site

204

such as shown in FIG.

2

. The purchasing process

500

may be invoked directly by the user accessing the portal site

204

to purchase one or more items, or else may be automatically invoked in whole or in part in connection with a larger process, such as the component selection and management process

300

illustrated in FIG.

3

. In a first step

516

of the purchasing process

500

illustrated in

FIG. 5

, the user selects a purchase option for a component or part which is displayed to the user on the user system

220

. The user may be provided with a list of available parts in a manner similar to steps

306

,

308

,

310

and

312

illustrated in

FIG. 3

, or else the user may simply enter the desired part (by model number or designation) if already known, and the entered part information will be compared to parts information stored either at the portal site or available at supplier databases

209

. The user may select a purchase option for a particular part by, for example, clicking on a purchase icon or a designated link with a computer mouse, or entering a purchase command on a computer keyboard. Prior to selecting a purchase option for a particular component, the portal site

204

may provide to the user information about the component availability and/or lead time, which data may be regularly stored and updated at the portal site, or else may be retrieved by the application server

232

on the fly, when needed from the appropriate supplier database

209

.

User selection of the purchase option generates a request for a quote, which, in step

518

, is transmitted to the portal site

204

from the user system

220

over the Internet

230

. At the portal site

204

, the application server

232

receives the request for a quote and invokes the business server

248

, which accesses the business database

250

to generate a transaction record. The transaction record preferably contains information regarding the user's employer and the method of payment utilized by that employer, which may be retrieved from the user profile stored in the affinity database

242

or else may be independently stored in the business database

250

. The transaction record generated in the early stage of a purchasing transaction may be updated as each step towards a final transaction is completed. In a next step

520

, the application server

232

generates a request for a supplier quote and transmits this request via the Internet

230

to the appropriate supplier (which would typically be a site containing a supplier database

209

). The request for a supplier quote may or may not include specifics regarding the user that is requesting the quote and the size of the business employing the user. In a preferred embodiment, such information is included for the purpose of, among other reasons, enabling the supplier to determine whether or not the purchaser qualifies for certain discounts as commonly offered in the industry, such as volume discounts, or preferred supplier or user discounts. The request for a supplier quote may be tagged with a transaction identifier to facilitate match-up of a responsive price quote from the supplier.

In a next step

522

, the supplier preferably transmits a proposed electronic contract, including a price quote, to the portal site

204

over the Internet

230

. The proposed electronic contract preferably is identified at least in part by the transaction identifier transmitted as part of the request for a supplier price quote. In step

524

, the proposed electronic contract is forwarded from the portal site

204

to the user system

220

. In a preferred embodiment, the supplier quote is considered by the user and supplier as an offer for sale, and acceptance of this offer by the user creates a binding contract between the user and the supplier, provided that the user has authority to enter into such a contract.

In a next step

526

, an authentication procedure is performed to ensure that the user is authorized to make the desired purchase. In one embodiment, for example, the design console client software

228

initiates a procedure to determine whether or not the user is authorized to make a purchase. Such factors will vary from user to user and company to company, and may depend upon such factors as the monetary amount of the purchase to be made, the seniority of the individual making the request, and other such factors. The design console client software

228

preferably stores or has access to data regarding the authorization level of the user. The authorization data may, for example, be stored in a separate database (local or remote) operated by the user's employer, through which transactions requiring payment must pass for authorization. Alternatively, the authorization function may be provided at the application server

232

, as the location where the authorization decision is made is not critical to the functionality of the embodiments described herein. As a result of the authentication procedure, the design console client software

228

may not allow the user to purchase the selected part, or it may allow the user to purchase parts up to a certain total dollar value.

If the user is not authorized to make the purchase, then the user obtains authorization, as indicated by step

528

. This authorization step

528

may take a wide variety of forms, including electronic authorization, paper authorization, formal approval processes and the like. If the user does not obtain authorization, the process

500

may terminate at step

528

.

In step

530

, once the user is authorized to make the purchase, then an order is generated to the supplier, and a contract is created between the user and the supplier for the purchase and delivery of desired products or services. The order is then transmitted to the supplier via the portal site

204

, as indicated in step

532

.

The portal site

204

may have varying levels of involvement in the business transaction. In step

534

, for example, a determination is made as to whether or not the portal site

204

is handling the billing for the transaction. If not, then in step

536

, the application server

232

may cause an invoice for a portion of the cost of the transaction that passed through the portal site

204

(i.e., a commission for bringing the user and supplier together) to be generated and transmitted from the portal site

204

over the Internet

230

to the supplier. The amount of the commission as reflected on the invoice may be generated based on a percentage of the overall transaction value, on a per transaction basis, or on another basis worked out on mutually agreeable terms between the particular supplier and the operator of the portal site

204

. In a next step

538

, the supplier then sends the invoiced amount to the portal site

204

as compensation. In a preferred embodiment, invoicing and payment are both electronic in nature; however, one or both of these may be in paper form. For convenience, the supplier may maintain an account at the portal site

204

, which gets automatically debited by the amount which would otherwise be invoiced.

Returning to step

534

, if the portal site

204

is handling billing, then the process

500

proceeds to step

540

, wherein the application server

232

generates an invoice and transmits it from portal site

204

to the user over the Internet

230

. In a next step

542

, the user then transmits remittance for that invoice to the portal site

204

, which may be done electronically or through paper. Alternatively,the user may maintain an account with the portal site

204

, which may be electronically debited. Next, in step

544

, the portal site

204

optionally deducts a portion of the remitted amount as compensation for acting as an intermediary, and transmits the remainder of the remittance (electronically or in paper form) to the supplier. At that point, the purchasing process

500

is complete.

In addition to component selection and management and component purchasing, another feature preferably offered at the portal site

204

is a user profiling and automated design assistance.

FIG. 4

is a flow chart illustrating a preferred process

400

for user profiling and design assistance, as may be used, for example, in connection with the system of FIG.

2

. As illustrated in

FIG. 4

, at the start of the user profiling and automated design process

400

, a user identification step

401

occurs when the user accesses the portal site

204

. Such identification may be accomplished by recognition of a username/password combination, or a “cookie” left on the user system

220

(on, e.g., the user's hard drive), or other means. Typically, a user of the portal site

204

would be required to enter certain information at some point before accessing certain features of the portal site

204

. This information may include, for example, a user name, company affiliation, method of payment, type of engineering performed, and anticipated or actual size of the design in gates. This information is placed in the user's profile and stored, for example in the affinity database

242

. Such information may be updated periodically, as necessary, by the user. The user profile is accessed, as noted above, when the user first enters the portal site

204

. If the user does not have a profile when entering the portal site

204

, the user may be prompted to enter data so as to generate a user profile.

In a preferred embodiment, some portion of the user profile is automatically generated by the portal site

204

based on the user's actions over time while visiting the portal site

204

. For example, the user profile data may include such information as the user's prior component purchases using the portal site

204

, or prior usage or navigation patterns through the resources of the portal site

204

. Such usage patterns may include, for example, the number of times the user has visited or utilized various features of the portal site

204

, the number of times certain information items or types have been accessed and in what order, and other data which may be apparent from analysis of the user's habits through various data mining techniques as known in the art. Preferably, all searches, queries, results and parts utilized by a.user are stored, in combination with other information, if desired, as part of the user profile data in the affinity database

242

(and/or the metrics database

238

).

In a next step

402

, the application server

232

invokes the context server

240

to retrieve the user profile information. In step

404

, the context server

240

locates the user profile in the affinity database

242

(see FIG.

2

). In a next step

406

, the context server

240

pulls user profile data from the affinity database

242

, such as, for example, the user's name, the user's employer or affiliation, the user's prior purchases, and the user's prior site navigation and usage patterns. In a next step

408

, the context server

240

delivers this data to the application server

232

.

After retrieving the user profile information and providing it to the application server

232

, in the following steps of the process

400

, metrics information is retrieved aggregated from the habits and behavior of other design engineers using the portal site

204

. Thus, in step

410

, the application server

232

invokes the metrics server

236

. In a next step

412

, the metrics server

236

pulls data from the metrics database

238

regarding the habits and behavior of users whose designs are similar in scale and/or type. For this reason, it is preferred that the user profile for each user include some data about the scale and/or type of each design on which the user is working. More specifically, metrics data may include prior component purchases and prior site navigation or usage patterns across a plurality of users whose designs have similar design characteristics. In a next step

414

, the metrics server

236

delivers the metrics data retrieved from the metrics database

238

to the application server

232

. The application server

232

thus has available data for the individual user, in addition to users in the aggregate, which may be furnished to the other resources, features or applications of the portal site

204

to facilitate the design process.

An advantage provided by the process

400

described above is that it is useful from the standpoint of design knowledge capture. The ability to track the movements of individual engineers through the portal site

204

, then aggregate those movements together, allows for capture and analysis of some aspects of the engineering design process that may have been previously unappreciated. Such information may be valuable in both academic and industrial contexts.

In one embodiment, the application server

232

comprises campaigning software for targeting messages or banners to engineers and other users of the portal site

204

based on their past historical usage and the usage of those similarly situated. An example of campaigning software that may be used is SiteServer™ which is a commercial product available from Microsoft. Preferably, the campaigning software of the application server

232

provides the capability to assign different targeted messages or banners to different campaigns. A campaign message or banner database may be included at the portal site

204

for use in conjunction with the campaigning software.

FIG. 6

is a flow chart illustrating a process

600

for providing information and services regarding virtual component blocks or IP cores, as may be used, for example, in connection with the system of FIG.

2

. Many of the steps in the process

600

for providing information and services regarding virtual component blocks or IP cores are similar to the steps performed in connection with the component information and management process

300

described earlier herein with respect to FIG.

3

. For the purposes of convenience, the terminology “IP cores” will be used in the explanation of the process of

FIG. 6

, but such terminology is not intended to be limiting.

In a first step

601

of the process

600

depicted in

FIG. 6

, a user at the user system

220

accesses the portal site

204

via the Internet

230

in a manner similar to the described with respect to

FIG. 3

(i.e., by entering the appropriate Unified Locator Resource (URL) or other applicable address), and in response the design console client software

228

displays a main design console menu screen on a computer screen at the user system

220

. In a next step

602

, the user at the user system

220

preferably selects an icon, link or other indicia for the IP core selection and management resource. For example, the user may click on an appropriate icon or link displayed in the design console main screen so as to select the IP core selection and management resource, or by typing or entering an appropriate command. The user's selection is then transmitted over the Internet

230

to the portal site

204

.

In response to the user selecting the IP core selection and management resource, a list of different types of IP cores available for use or purchase is then retrieved at the portal site

204

from the catalog database

246

, and then transmitted to and displayed at the user system

220

. Listed components may include, for example, Viterbi decoders, digital signal processors, or any other IP cores a design engineer may find useful. If more than one specific type of IP core is available for a component, then, in step

603

, the user may select the IP core type from the list provided in step

602

, which preferably causes display of the available IP cores from different manufacturers or suppliers, in a ranked ordering similar to that described with respect to FIG.

3

. For example, if the user selects a digital signal processor as a component, the user system

220

may display a number of digital signal processors having specified sample rates, bandwidths, resolution, and so on. Alternatively, the user may be permitted to input search criteria to allow a search for all components meeting specified criteria, which may be implemented, for example, using ordinary database queries. For example, the user may search for all digital signal processors having a certain sample rate and/or a price of under a specified monetary amount.

In a next step

604

, user profiling and context routines are preferably invoked to assist in determining an ordering of display of the specific IP cores falling under the category of IP core type selected by the user. The user profiling and context routines are generally described in more detail herein with reference to FIG.

4

.

The process

600

then proceeds with step

606

, wherein the application server

232

retrieves a list of available IP cores from the catalog data base

246

via the catalog server

244

based on the user's component selection in step

603

, the user's design information (if available), and profile and context data obtained from step

604

. In a next step

608

, the application server

232

ranks the available IP cores, preferably based upon the profile and context data obtained in step

604

. The predicted best or most suitable choices for the user's design are placed at the top of the listing, based on the available information. Other choices of available IP cores for the selected IP core type preferably follow the best or most suitable IP cores. In one aspect, the user benefits from past design experience of both his or her own design as well as that of other designers who have been in the position of making similar design choices in previous designs. In a next step

610

, the ranked list of available IP cores for the selected IP core type is transmitted from the portal site

204

to the user system

220

and displayed for the user's perusal. The ranked list of available IP cores may be displayed, for example, as a list of selectable strings, “hotlinks” or icons. The user reviews the ranked list of choices and, in step

612

, selects one of the available choices by, e.g., highlighting the entry and hitting a keyboard key (such as the return key), or clicking on the entry with a computer mouse, or selecting a number corresponding to the ranking of the desired IP core, or by any other selection means, the specifics of which are not essential to the operation of the inventive concepts described herein. The user's selection is transmitted from the user system

220

to the portal site

204

.

In a next step

614

, additional information about the IP core chosen in step

612

is displayed to the user. Such information preferably constitutes relatively high level data, and is generally intended to allow the user to determine relatively quickly whether the user should include the selected IP core in the design, look for a different IP core from the ranked list, or gather further information about the selected IP core. Preferably, the user is presented with icons or other interface features for conveniently selecting whether to immediately incorporated the selected IP core in the user's design, backtrack to the ranked list and look for a different IP core, or else pull up additional information about the selected IP core. If the user is interested in additional information, the process

600

proceeds to step

618

, wherein the user selects the appropriate interface feature (e.g., an icon or menu selection entry) to receive additional information about the selected IP core. The user's selection for more information is transmitted from the user system

220

to the portal site

204

. In a next step

620

, the further information concerning the selected IP core is displayed. Such information may include detailed IP core information such as, for example, IP core data sheets. Preferably, information regarding IP packaging technology and service providers for packaging technology is also provided, as is information regarding the quality or the validation of the selected IP core. In a preferred embodiment, interface data regarding each IP core is standardized in a common data format to allow designers to quickly and easily choose between different IP cores which will be easily interchangeable in an end users design. A hotlink to an IP knowledge database is preferably provided whereby the user can access information about IP usage such as bug tracking, IP authoring guidelines, application notes and so forth. A hotlink may also be provided to a posting board or other forum by which users may directly exchange information with each other regarding IP cores. A symbol and a footprint configuration for the selected IP core are also preferably provided, which may allow the user to make more informed decisions about placement of IP cores and other components in an overall design.

When the user is satisfied that the selected IP core is suitable for the user's design, then in step

622

the user selects the IP core by selecting the appropriate feature from the user interface. If, on the other hand, the user does not want to use the selected IP core, the process moves to step

628

, wherein the user selects the appropriate feature from the user interface to return to the ranked list of choices displayed in step

610

. If, on the other hand, the user decides to use the selected IP core in a design, the user then indicates such in step

622

by selecting the appropriate feature from the user interface. In a preferred embodiment, the process permits the user to place a graphical representation (e.g., symbol) of the selected IP core into the user's design by moving, copying or dragging the symbol of the selected IP core into the schematic program being used to develop the design. As part of the process of bringing the selected IP core into the schematic program, information concerning the selected IP core is preferably copied and stored at the user system

220

in the design database

225

. Such information may include, for example, specifications concerning the selected IP core, as well as manufacturing information and a hyperlink to either the portal site

204

or a component supplier database

209

of the supplier or distributor of the selected IP core.

In a next step

624

, a purchasing routine is preferably invoked, during which the selected IP core is purchased. Details of a preferred purchasing routine are described herein with respect to FIG.

5

. In a following step

626

, the selected and purchased IP core is delivered to the user, preferably in electronic format over the Internet

230

. As a part of step

626

, the portal site

204

preferably performs a protection function where the IP core is protected from piracy or unauthorized use by embedding each IP core transmitted via the portal site with a digital watermark. One type of digital watermarking technique that may be used is disclose, for example, in copending U.S. patent application Ser. No. 09/514,695 filed concurrently herewith, and hereby incorporated by reference as if set forth fully herein. Alternatively, a digital watermark may simply comprise an embedded code (such as an encoded/encrypted identifier or set of identifiers) physically included as part of the IP core software.

The steps for selecting specific IP cores are then repeated, if desired, for the other IP cores incorporated into the user's design. Thus, the process

600

returns to step

603

for each remaining IP core for which the user desires to select using the resources of the portal site

204

. Eventually, when the user finishes adding IP cores to the design, the process

600

returns to the general design console menu.

Use of the process

600

illustrated in

FIG. 6

is expected to benefit both suppliers and users. For example, the use of the IP cores selection and management process

600

facilitates the exchange of data regarding the quality and features of IP cores, which is beneficial to suppliers who are able to demonstrate such quality and features to end users, and to users who have greater assurance about the quality and functionality of a given IP core. The IP cores selection and management process

600

also provides for protection of the IP cores, which can be important to facilitating the entry of suppliers into the IP marketplace and to protect their intellectual property rights in IP cores they have developed. Additionally, the IP core selection and management process

600

may advantageously reduce overhead for IP core sale and licensing transactions, because such transactions occur between a designer and a supplier via a portal site

204

without the need for intervention by other personnel from sales, marketing or legal departments.

FIG. 7

is a flow chart illustrating a process

700

for providing information and services regarding integrated circuit (IC) fabrication, as may be used, for example, in connection with the system of FIG.

2

. In a first step

701

of the IC fabrication process

700

, as with the processes described with respect to

FIGS. 3 and 6

, for example, a user at the user system

220

accesses the portal site

204

via the Internet

230

in a manner similar to the described with respect to

FIG. 3

(i.e., by entering the appropriate Unified Locator Resource (URL) or other applicable address), and in response the design console client software

228

displays a main design console menu screen on a computer screen at the user system

220

. In a next step

702

, the user at the user system

220

preferably selects an icon, link or other indicia for the IC fabrication resource. For example, the user may click on an appropriate icon or link displayed in the design console main screen so as to select the IC fabrication resource, or by typing or entering an appropriate command. The user's selection is then transmitted over the Internet

230

to the portal site

204

.

After the user selects the IC fabrication resource, in a next step

704

, user profiling and context routines are preferably invoked to assist the user by determining an ordering of display of the specific IC fabrication options. The user profiling and context routines are generally described in more detail herein with reference to FIG.

4

. The process

700

then proceeds with step

706

, wherein the application server

232

selects appropriate IC fabrication options from the catalog data base

246

via the catalog server

244

for the user based, for example, on the user's specific design and the user's profile and context data obtained from step