Designing a system for a programmable system-on-chip using performance characterization techniques

An example method of implementing a system design for a programmable system-on-chip (SOC) having a processing system and programmable logic includes receiving a description of performance objectives for the system design. The method further includes accessing a characterization database that relates parameter settings of the processing system to performance under different traffic profiles as generated by an emulation system comprising the processing system and one or more circuit blocks implemented in the programmable logic. The method further includes obtaining a parameter set from the characterization database based on the description of the performance objectives. The method further includes generating a parameter image for setting registers of the processing system based on the parameter set.

TECHNICAL FIELD

Examples of the present disclosure generally relate to electronic system design and, in particular, to designing systems for programmable system-on-chips (SoCs) using performance characterization techniques.

BACKGROUND

Estimating the likely performance of a system is an important part of the design process. A variety of performance estimation tools are available for system designers of application specific integrated circuits (ASICs). Similarly, a variety of different performance estimation tools are available for developing purely software-based systems. Whether hardware-based or software-based, the approach taken by most performance estimation tools is to add monitor functionality to existing designs. This approach necessarily infers that the complete design for which performance estimation is desired, whether hardware or software, is fully realized. The necessity of having a fully realized design makes make performance estimation tools unusable in the early stages of system design when many architectural decisions are made.

SUMMARY

Techniques for designing a system for a programmable SOC using performance characterization techniques are described. In an example, a method of implementing a system design for a programmable system-on-chip (SOC) having a processing system and programmable logic includes receiving a description of performance objectives for the system design. The method further includes accessing a characterization database that relates parameter settings of the processing system to performance under different traffic profiles as generated by an emulation system comprising the processing system and one or more circuit blocks implemented in the programmable logic. The method further includes obtaining a parameter set from the characterization database based on the description of the performance objectives. The method further includes generating a parameter image for setting registers of the processing system based on the parameter set.

In another example, a method of implementing a system design for a programmable system-on-chip (SOC) having a processing system and programmable logic includes receiving an initial parameter set for the processing system and an expected traffic profile. The method further includes accessing a characterization database that relates parameter settings of the processing system to performance under different traffic profiles as generated by an emulation system comprising the processing system and one or more circuit blocks implemented in the programmable logic. The method further includes obtaining performance data from the characterization database based on the initial parameter set and the expected traffic profile. The method further includes generating an updated parameter image for setting registers of the processing system based on the performance data.

In another example, a computer system includes a memory storing program code, and a processor, coupled to the memory, configured to execute the program code to: receive a description of performance objectives for the system design; access a characterization database that relates parameter settings of the processing system to performance under different traffic profiles as generated by an emulation system comprising the processing system and one or more circuit blocks implemented in the programmable logic; obtain a parameter set from the characterization database based on the description of the performance objectives; and generate a parameter image for setting registers of the processing system based on the parameter set.

DETAILED DESCRIPTION

Techniques for implementing a system design for a programmable SOC having a processing system and programmable logic are described. In an example, an expert system tool is provided that receives a description of performance objectives for the system design from a designer. The expert system tool accesses a characterization database that relates parameter settings of the processing system to performance under different traffic profiles. The performance data is generated by an emulation system comprising the processing system and one or more circuit blocks implemented in the programmable logic. The expert system tool obtains a parameter set from the characterization database based on the description of the performance objectives. The expert system tool generates a parameter image for setting registers of the processing system based on the parameter set. The expert system tool can then output the parameter image, or use the parameter image to generate a boot loader and/or system image for programming the programmable SOC. The expert system tool obviates the need for the designer to have an understanding of the many thousands of registers that configure the processing system. These and further aspects are described below with respect to the following figures.

FIG. 1is a block diagram depicting an example of a design system100. The design system100includes a computer101coupled to a programmable system150, input/output (IO) devices112, and a display114. The programmable system150can be a circuit board comprising a programmable system-on-chip (SOC)122. The programmable system150can further include nonvolatile memory152(e.g., FLASH memory or the like), volatile memory154(e.g., dynamic random access memory (DRAM) or the like), and other circuits156(e.g., clock generators, voltage regulators, and the like).

The programmable SOC122can be an integrated circuit (IC) comprising a processing system132and programmable logic134. The programmable logic134includes programmable circuit elements within an integrated circuit (IC), e.g., the various programmable or configurable circuit blocks or tiles described herein, as well as interconnect circuitry that selectively couples the various circuit blocks, tiles, and/or elements according to configuration data that is loaded into the IC. In general, the functionality of programmable logic134is not established unit a configuration data is loaded into the IC. A set of configuration bits can be used to program the programmable logic134. The configuration bits are typically referred to as a “configuration bitstream.” In general, the programmable logic134is not operational or functional without first loading a configuration bitstream into the IC. The configuration bitstream effectively implements or instantiates a circuit design within the programmable logic134. The circuit design specifies, for example, functional aspects of the programmable circuit blocks and physical connectivity among the various programmable circuit blocks.

The processing system132comprises hardwired circuitry. Circuitry that is “hardwired” or “hardened” is manufactured as part of the IC. Unlike programmable logic, hardwired circuitry is not programmed with functionality after the manufacture of the IC through the loading of a configuration bitstream. Hardwired circuitry is generally considered to have dedicated circuit blocks and interconnects, for example, which have a particular functionality and are functional without first loading a configuration bitstream into the IC. Hardwired circuitry can have one or more operational modes (as opposed to functionality) that can be set or selected according to parameter settings. The parameter settings can be realized, for example, by storing values in one or more memory elements within the IC (e.g., registers123). The operational modes can be set, for example, through the loading of the configuration bitstream into the programmable SOC122. Despite this ability, the hardwired circuitry is not considered to be “programmable logic”, as the hardwired circuitry is operable and has a particular function when manufactured as part of the IC.

The computer101includes a hardware platform118, which can include conventional components of a computing device, such as a central processing unit (CPU)102, system memory108, various support circuits104, storage120, and an IO interface106. The CPU102can include one or more microprocessors. The CPU102is configured to execute instructions that perform one or more operations described herein. The instructions can be stored in system memory108, storage120, or any other memory in the hardware platform118(e.g., cache memory). The system memory108includes devices that store information and can include, for example, random access memory (RAM), read-only memory (ROM), or a combination thereof. The storage120includes local storage devices, such as hard disks, flash memory modules, solid state disks, optical disks, and the like. The storage120can also include interface(s) configured for communication with one or more network data storage systems. The support circuits104can include conventional cache, power supplies, clock circuits, data registers, IO interfaces, and the like. The IO interface106includes conventional interfaces to the computer101known in the art. The IO interface106can be coupled to the IO devices112, which can include conventional keyboard, mouse, and the like. The IO interface106can also be coupled to the display114, which can present a GUI116to a user.

The computer101further includes a software platform comprising an operating system (OS)124and design tools110. The OS124and the design tools110include instructions that are executed by the CPU102. The OS124can include any known operating system, such as Linux®, Microsoft Windows®, Mac OS®, and the like. The design tools110include applications that execute within the OS124, which provides an interface to the hardware platform118. The design tools110can include various applications, such as a hardware design tool126and a software development kit (SDK) design tool128. The hardware design tool126can be used to configure hardware of the programmable SOC122. The SDK design tool128can be used to develop software for execution on the programmable SOC122. In general, a system designer can use the design tools110to specify an electronic system for implementation in the programmable SOC122. The electronic system can include processor(s) executing program code that interact with circuit(s). The design tools110can implement the circuit(s) within the programmable logic134and target the program code for execution within the processing system132. The design tools110can generate a system image for the programmable system150, which can include one or more configuration bitstreams for configuring the programmable SOC122and program code for execution by the processing system132. The program code can include one or more bootloaders, one or more operating systems, one or more applications, data, and the like.

The design tools110can further include an expert system tool130. The expert system tool130can guide a system designer in selecting optimal parameter settings for the processing system132based on desired performance requirements. The processing system132can include a large number of parameter settings, such as a large number of configurable registers123. For example, the processing system132can include thousands or even tens of thousands of registers123, each having one or more fields. It can be difficult for a system designer to identify a combination of parameter settings that achieves optimal performance for a particular system. Typically, a system designer must iteratively investigate a myriad of parameter setting combinations during system design. Keeping track of which parameters are available, how each parameter affects the system performance, and how each parameter interacts (or even conflicts) with each other can be a daunting task. The expert system tool130solves these issues. The expert system tool130can be used to characterize a specific target SOC platform, such as the programmable SOC122. The expert system tool130can be used to sweep and characterize the programmable SOC122to create a characterization database that relates parameter settings with performance results. The expert system tool130can then use the characterization database to provide a system designer suggested parameter settings that provide optimal performance for a system design.

FIG. 2is a block diagram depicting an example of the programmable SOC122. The programmable SOC122includes a processing system132(also referred to as PS132) and programmable logic134(also referred to as PL134). The programmable SOC122can integrate a microprocessor-based processing system with programmable logic of a field programmable gate array (FPGA), complex programmable logic device (CPLD), or the like. The processing system132can be coupled to various input/output (IO) pins of the programmable SOC122, including multiplexed IO (MIO) pins224and dynamic random access memory (DRAM) pins226. The programmable logic134can be coupled to programmable logic (PL) pins228.

The processing system132can include a processing unit214, one or more memory interfaces (memory interface(s)216), interconnect218, one or more peripherals (peripheral(s)221), an MIO circuit (MIO220), and a PS-PL interface236, among other components. The processing unit214can be coupled to the memory interface(s)216. The memory interface(s)216can include DRAM memory controllers, non-volatile memory controllers, and the like. The memory interface(s)216can be coupled to the DRAM pins226to communicate with the DRAM204(e.g., system memory for the processing system132). The processing unit214, the memory interface(s)216, and the peripheral(s)221can be coupled to the interconnect218. The interconnect218can include busses, switches, ports, and the like to facilitate connection between components of the processing system132.

The peripheral(s)221and the memory interface(s)216can also be coupled to the MIO220, which is in turn coupled to the MIO pins224. The peripheral(s)221can communicate with other circuits through the MIO220. The MIO220multiplexes interfaces of the peripheral(s)221and the memory interface(s)216among the MIO pins224. The peripheral(s)221, MIO220, the interconnect218, and the processing unit214can be coupled to the PS-PL interface236for communicating with the programmable logic134.

The processing unit214includes one or more microprocessors (microprocessor(s)230), on-chip memory (OCM)232, and support circuits234. The microprocessor(s)230can include any type of microprocessors known in the art. The OCM232can include cache memory, local memory, or the like. The support circuits234can include various types of circuits, such as interrupt controller(s), direct memory access (DMA) controllers, timers, registers, interconnect, cache controllers, and the like.

The processing system132is coupled to the programmable logic134through the PS-PL interface236. The programmable logic134can communicate with the processing unit214, the memory interface(s)216, the MIO220, and the peripheral(s)221of the processing system132. For example, the programmable logic134can interrupt the processing unit214, access memory through the memory interface(s)216or within the processing unit214, and access the peripheral(s)221.

The programmable logic134can include a large number of different programmable tiles including, configurable logic blocks (“CLBs”)250, random access memory blocks (“BRAMs”)254, input/output blocks (“IOBs”)252, digital signal processing blocks (“DSPs”)258, and other programmable logic, such as digital clock managers, analog-to-digital converters, system monitoring logic, multi-gigabit transceivers (“MGTs”), configuration and clocking logic, specialized input/output blocks (e.g., configuration ports and clock ports), processor blocks, and so forth. The programmable logic134also includes programmable interconnect elements (INTs256) that provide a programmable interconnect structure between the various blocks.

The registers123(not explicitly shown inFIG. 2) can be distributed throughout the processing system132. The registers123store parameters of the processing system132that are set to control various parts of the processing system132, such the processing unit214, the memory interfaces216, the interconnect218, the peripherals221, the MIO220, and the PS-PL interface236. Some of the registers123are only programmable at reset of the processing system132(referred to as the “static register set”). The remainder of the registers123(referred to as the “dynamic register set”) can be configured after reset.

FIG. 3is a block diagram depicting an example of the design tools110. As described above, the design tools110include the expert system tool130, the SDK design tool128, and the hardware design tool126. Each of the expert system tool130, the SDK design tool128, and the hardware design tool126can include one or more components as illustrated inFIG. 3. The expert system tool130can include a user interface302, a backend304, and a characterization database305. The SDK design tool128can include software development tools324(e.g., various compilers, linkers, etc.), drivers/libraries310, a system performance analysis (SPA) component312, and a system programmer component326. The SDK design tool128can include one or more other tools306, such as software profiling tools, a system debugger, and the like. The SPA component312component can include system performance modeling (SPM) component314and a monitor framework316. The hardware design tool126can include a base system generator318, implementation tools320, and a bitstream generation component319.

A designer can use the hardware design tool126to design the hardware platform of the electronic system to be implemented in the programmable SOC122. The hardware platform of the electronic system can include one or more processors, volatile and/or nonvolatile memory within the programmable SOC122, volatile and/or nonvolatile memory external to the programmable SOC122, peripherals, and other custom circuits to be implemented in programmable logic. The base system generator318can be used to generate a base hardware platform for the electronic system. The base system generator318provides a hardware platform specification as output. The hardware platform specification describes the system elements, such as processor types, debug interfaces, cache configuration, memory types and sizes, peripherals and the like. The hardware platform specification can include parameter settings for the processing system132that implement the base hardware platform. The implementation tools320can include synthesis, map, place-and-route, and the like tools, and can be used to implement hardware (e.g., custom circuits) for a target programmable SOC. The bitstream generation component319can generate a configuration bitstream to be loaded into the programmable SOC122.

A designer can use the SDK design tool128to develop software of the electronic system to be implemented in the programmable SOC122. The software can include program code to be executed on one or more processors in the programmable SOC122(e.g., one or more processors in the processing system). A designer can use the software development tools324and the drivers/libraries310to develop the software. A designer can use the SPA component312to analyze performance of the electronic system, as described further below. The system programmer component326can be used to load a system image to the programmable system150. The system image can include configuration bitstreams, bootloaders, applications, operating systems, data, and the like for the programmable SOC122.

FIG. 4is a block diagram depicting an example system400implemented using the programmable SOC122. The nonvolatile memory152is loaded with a system image414. The system image414includes configuration bitstream(s) for configuring the programmable SOC122, as well as program code for execution by the processing system132. The program code can include a first stage boot loader (FSBL), one or more other boot loader stages, an operating system, applications, and the like. The system400includes the processing system132having the registers123loaded with a particular parameter set. Some or all of the registers123can be set through execution of an FSBL. For example, the FSBL can be used to set the static register set and set initial values for the dynamic register set. Other program code can be used to modify the dynamic register set.

The programmable logic134is configured with one or more circuit blocks406coupled to a bus403of the processing system132. The circuit block(s)406can be coupled to one or more other circuits410in the programmable logic134. The circuit(s)410can include hardwired circuits (e.g., an MGT) and/or configured circuits. The circuit blocks406can be coupled to one or more external circuits412. In some examples, the circuit block(s)406can be coupled to both the circuit(s)410and the external circuit(s)412. In some examples, some circuit block(s)406are coupled to the circuit(s)410, other circuit block(s)406are coupled to the external circuit(s)412, other circuit block(s)406are coupled to both the circuit(s)410and the external circuit(s)412, and/or other circuit block(s)406are not coupled to any other circuits. In some examples described below, the programmable logic134can also be configured with a monitor404. The monitor404can be coupled to the bus403, as well as the circuit(s)410and/or the external circuit(s)412.

Returning toFIG. 3, the SPA component312provides for early exploration of hardware and software systems. A designer can use the SPM component314to perform complex performance modeling even before design work has started. The SPM component314can load a fixed configuration bitstream to the programmable SOC122that implements a predefined system design. The predefined system design includes one or more traffic generators configured in the programmable logic134and the monitor. The traffic generators are configurable cores that can model PL traffic activity. The monitor is configured to cooperate with the monitor framework316to monitor the overall performance of the system during test runs. To initiate the SPA process, the designer specifies a parameter set for the processing system132and the data traffic to be modeled. The designer can also specify program code to be executed. The SPM component314generates a corresponding system image for the programmable system150. The SPM component314can perform multiple test runs using the parameter settings and the traffic defined by the designer. The traffic generators perform the requested data traffic and the processing system132executes the requested software traffic or program code. The monitor framework316obtains data from the monitor during the test runs to observe overall performance of the system. In some examples, the designer may already have specified the hardware platform or portions of the hardware platform. The SPM component314can use custom circuit blocks defined by the designer, rather than the traffic generators, during the test runs.

A designer can interact directly with the hardware design tool126to specify the hardware platform of the system. However, as discussed above, this requires that the designer specify a parameter set for the registers123of the processing system132, which can be a difficult task. A designer can also interact directly with the SDK design tool128to implement a predefined system for performance modeling and analysis. However, as discussed above, this also requires that the designer specify a parameter set for the registers123of the processing system132in order to initiate the test environment.

Accordingly, a designer can instead interact with the expert system tool130. In an example, the designer can initiate the process without having a system design or without any knowledge of a particular parameter set for the processing system132. Rather, the designer can interact with the user interface302to specify a description of performance objectives for the system. The performance objectives can be specified in different ways. Possible formats include desired throughput values (e.g., in megabytes per second), a desired latency (e.g., in cycles) for each communication channel, or the like, or a combination thereof. The user interface302then passes the description of the performance objectives to the backend304. The backend304accesses the characterization database305using the performance objectives as query parameters.

The characterization database305relates parameter settings of the processing system132to performance under different traffic loads. In an example, characterization database305can be populated using test runs performed by the SPA component312. The SPA component312can perform test runs as described above given different parameter sets and for different traffic settings. The monitor framework316collects the performance results, which are stored in the characterization database305in relation to the parameter settings and the traffic settings. The characterization database305can be pre-populated by distributor of the design tools110. The characterization database305can also be populated by a designer through various test runs performed by the designer. Thus, the characterization database305can be initially populated by the distributor of the design tools110, and updated and augmented over time through test runs by designer(s).

Given performance objectives specified by the designer, the backend304can query the characterization database305to obtain one or more parameter sets. If the designer did not specify traffic settings, the backend304can specify default traffic settings. Alternatively, the designer can also specify traffic settings through the user interface302. In such case, the backend304can use both the designer-specified performance objectives and traffic settings to obtain a parameter set from the characterization database305. The backend304then generates a parameter image for configuring the registers123of the processing system132based on the parameter set. The parameter image includes the values to be stored in the registers123to implement the selected parameter set.

The backend304can take various actions given the parameter image. In an example, the backend304can cooperate with the user interface302to display the register values encoded in the parameter image to the designer in a human-readable form. In another example, the backend304can output the parameter image in computer-readable form for use by other tools (e.g., the SDK design tool128). In another example, the backend304can generate program code for configuring the registers123based on the parameter image. For example, the backend304can generate an FSBL that sets the values of the registers123based on the generated parameter image. In another example, the backend304can generate a system image for the programmable system150that includes an FSBL that sets the registers123. The backend304can cooperate with other tools (e.g., the hardware design tool126and/or the SDK design tool128) to generate the FSBL and/or system image. Alternatively, if the designer invokes the hardware design tool126and/or the SDK design tool128directly, the backend304can provide the parameter image for use in generating the FSBL and the system image.

In the example described above, the designer can be in the “pre-design” stage. In the pre-design stage, the designer may have knowledge of general system structure, performance objectives for such system, and potentially expected traffic patterns (e.g., either software traffic patterns or hardware traffic patterns between the processing system132and the programmable logic134). The designer can use the expert system tool130to generate a parameter image. The SDK design tool128can be invoked (either manually by the designer or automatically by the expert system tool130) to generate a predefined system using the SPA component312. The SPA component312can take the parameter image generated by the expert system tool130as input. The designer can then verify the performance through the monitoring framework by executing one or more test runs.

Other use cases are possible. In another example, the designer can be in the “mid-design” stage. In the mid-design stage, the designer may already have an initial parameter set for the processing system132along with expected traffic patterns. In some cases, the designer may also have one or more known circuit modules that generate the traffic. The designer can specify this initial parameter set and the expected traffic patterns through the user interface302. The backend304can query the characterization database305with the initial parameter set and the expected traffic patterns to obtain expected performance data. The backend304can report the expected performance data to the designer through the user interface302so that the designer. If the expected performance is satisfactory, the designer can then invoke the SPA component312to test the system given the initial parameter set and the expected traffic patterns. This allows the designer to verify the expected performance reported by the expert system tool130in the actual hardware. Should the actual performance differ, the backend304can update the performance data for the given parameter set in the characterization database305.

In another example, the designer can be in a “late-design stage”. The late-design stage is similar to the mid-design stage, but the designer may have designed the custom circuit(s) that generate the expected traffic. In such case, the expert system tool130can be invoked as described above with the mid-design stage. However, when the SPA component312implements the system, the SPA component312can use the designer's custom circuit(s) rather than the traffic generators.

As discussed above, the backend304can report expected performance data to the designer through the user interface302given an initial parameter set and expected traffic patterns. In addition to reporting the expected performance, the backend304can report suggested changes to the parameter set to achieve a more optimal performance. The backend304can perform various data analysis techniques to identify the suggested changes. In an example, the backend304can implement an unsupervised machine learning process to explore the performance space, such as k-means clustering. In such a process, the backend304can group the parameter sets in the characterization database305based on different attributes (e.g., a group of best performance for various traffic patterns, a group for lowest power consumption for various traffic patterns, etc.). The backend304can then determine deltas between the initial parameter set and the best performance, the lowest power consumption, etc. for the expected traffic patterns. The backend304can then suggest changes to the initial parameter set to the designer in order to achieve optimal performance, lowest power consumption, etc.

In another example, the backend304can implement a supervised machine learning process. In such a process, the backend304can designate specific performance sets in the characterization database305as being “best performance,” “lowest power consumption,” etc. for different traffic patterns. The backend304can determine deltas between the initial parameter set and the designated parameter sets for best performance, lowest power consumption, etc. for the expected traffic patterns. The backend304can then suggest changes to the initial parameter set to the designer in order to achieve optional performance, lower power consumption, etc.

The characterization database305can store data in various ways and using various relations. For example, the characterization database305can store raw performance results related to particular parameter sets and traffic patterns. Alternatively, the characterization database305can store equations relating performance and parameters for particular traffic patterns. In still another example, the characterization database can store a combination of raw performance data and equations from which performance data can be derived. Since there can be a large number of parameters, the search space for the characterization database305can be large. In some examples, the characterization database305can store performance data for key parameter sets and then interpolate performance results for other parameter sets. If the backend304reports interpolated performance data, the backend304can update the characterization database305with actual performance data after test runs executed by the SPA component312.

FIG. 5is a flow diagram depicting a method500of implementing a system design for a programmable SOC according to an example. The method500can be performed by the design system100described above. The method500begins at step502, wherein the expert system tool130receives input from a designer. The input can take different forms. In one example, the designer inputs a description of performance objectives. The performance objectives can be described in terms of throughput, latency, or the like. The performance objectives can be optional or required. Required performance objectives translate into performance constraints. In another example, in addition to the performance objectives, the designer specifies an expected traffic profile. The expected traffic profile includes one or more traffic patterns. A traffic pattern can be a software traffic pattern or a hardware traffic pattern. In another example, a designer can specify an initial parameter set for the processing system132. Optionally, the designer can specify performance objectives and/or an expected traffic profile in addition to the initial parameter set.

At optional step510, the expert system tool130evaluates current performance of an initial parameter set. The expert system tool130performs optional step510if the designer has specified an initial parameter set for the processing system132. If the designer has not specified an initial parameter set (e.g., pre-design stage), then the expert system tool130does not perform optional step510.

The expert system tool130can obtain current performance for an initial parameter set in different ways. At step512, the expert system tool130can obtain performance data from the characterization database305. For example, given the initial parameter set and an expected traffic profile, the expert system tool130can query the characterization database305to obtain performance data. As described above, the performance data can be raw performance data obtained from the characterization database, performance data derived from an equation, or performance data interpolated from other performance data. As an alternative to or in addition to step512, at step514, the expert system tool130can invoke the SDK design tool128to generate actual performance data using SPA. If actual performance data is generated, at step515, the expert system tool130can update the characterization database305with the actual performance data.

At step516, the expert system tool130determines optimum parameter set(s). In an example, the expert system tool130, at step517, accesses the characterization database305. As described above, the characterization database305relates parameter settings of the processing system132to performance under difference traffic profiles as generated by an emulation system comprising the processing system132and one or more circuit blocks406implemented in programmable logic134(e.g., the system400). At step518, the expert system tool130obtains the optimum parameter set(s) from the characterization database305given the designer's performance objectives and optionally an expected traffic profile. As an alternative to or in addition to step518, the expert system tool130can, at step520, obtain optimum parameter set(s) from data analysis of the characterization database305given an initial parameter set and expected traffic profile. As described above, the expert system tool130can use techniques such as unsupervised machine learning, supervised machine learning, or the like to obtain or suggest an optimal parameter set based on the designer's initial parameter set and expected traffic profile.

At step522, the expert system tool130generates a parameter image for the registers123of the processing system132. The parameter image includes values for the registers123that implement a selected parameter set. The expert system tool130can generate a new parameter image if the designer did not provide an existing parameter set. If the designer provided an existing parameter set at step508, then the expert system tool130can, at step523, generate an updated parameter image that is a combination of the initial parameter set and the selected parameter set.

At step524, the expert system tool130optionally generates further output(s). In an example, at step526, the expert system tool130can generate an FSBL based on the parameter image that sets the registers123. In another example, at step528, the expert system tool130can generate a system image for the programmable SOC122that includes a configuration bitstream, an FSBL to set the registers, and other program code (e.g., an operating system, applications, etc.).

FIG. 6is a flow diagram depicting a method600of populating the characterization database305according to an example. The method600can be performed by the expert system tool130described above. At step602, the expert system tool130receives defined parameter sets and traffic profiles to be tested. At step604, the expert system tool130evaluates performance of a system design given the parameter sets across the traffic profiles using SPA. At step606, the expert system tool130adds relations between parameter sets and performance data across the traffic profiles to the characterization database305.