US 7,110,935 B1Grant
Method and system for modeling and automatically generating an electronic design from a system level environment
Issue Date:2006-09-19
•11 Claims
•4 Drawing Sheets
Abstract
Method and system for creating an electronic circuit design from a system-level environment. A plurality of user-selectable system-level design objects are provided in the system-level environment. Each system-level design object is defined by a system-level function and is selectable by a system-level designer. A plurality of hardware-level design objects are also provided. Each hardware-level design object is configured to generate a hardware definition of a hardware-level function. Each system-level design object maps to one or more hardware-level design objects. In response to selections made by the designer, a system-level design is instantiated in a system-level design file. The system-level design includes user-selected ones of the system-level design objects. The system simulates behavior of the system-level design consistent with both the system-level functions and behavior of a hardware definition from the hardware-level design objects that implement the user-selected ones of the system-level design objects.
Metadata
Assignee
- Xilinx, Inc.
Inventors
- L. James Hwang
- R. Brent Milne
- Nabeel Shirazi
- Jeffrey D. Stroomer
Application Information
Application Number:US 09/981,503
Filing Date:2001-10-16
Priority Date:2001-10-16
Art Unit:2128
Classifications
IPC:
G06F17/50
Patent Drawings (4 sheets)
Description
Field of the Invention
[0001] The present invention generally relates to electronic circuit design tools, and more particularly to a tool that supports system-level development and simulation of a design that is bit-true and cycle-true to a hardware implementation.
Background
[0002] Modern electronic systems that are implemented in application-specific integrated circuits (ASICs), field-programmable integrated circuits (FPGAs), or complex programmable logic devices (CPLDs) are often extremely complex, requiring years of effort to realize. For this reason, it is common to decompose the design problem into phases: a specification phase in which the functional requirements of the system are defined, a modeling phase in which an executable version of the functional description is realized, and an implementation phase in which a hardware realization of the system is created. For the end result to be correct, each phase must faithfully implement the result of the previous phase. For example, the hardware realization must exactly mirror the functional model created during the modeling phase. In practice, validating that implementations are faithful, which is the greatest part the design effort, often exposes design flaws or faulty assumptions upstream. This, in turn, results in reworking the earlier design representation.
[0003] The modeling phase consists of capturing the design in an executable form, simulating, then analyzing the results. The modeling phase is appropriate for algorithm exploration, in which system parameters such as sample rates, data precision, and choice of functional blocks are decided. This process is iterative, with the results of analysis leading to revisions that allow system specifications to be met. In the modeling phase, a high level of abstraction is desirable in order to facilitate algorithm exploration. For example, it is common to represent arithmetic values using floating point or fixed point rather than as buses of logic signals. Sampled data systems are also most conveniently modeled by defining sample rates rather than using explicit interconnections (“wires”) representing clock and associated control signals (e.g., enable, reset).
[0004] The hardware realization phase consists of creating a low-level implementation of the system in terms of primitives in an appropriate technology library. Hardware description languages such as VHDL and Verilog are commonly used for such a representation. In this representation, high level constructs such as sample rates and arithmetic values must be implemented in terms of clock signals and buses of logic vectors, and functional operators (e.g., discrete Fourier transform) must be mapped into appropriate circuitry. To achieve high performance, libraries of intellectual property (IP) blocks are commonly used. Such IP blocks are typically custom built to be efficient in the target technology.
[0005] In traditional system design flows, the system designer is responsible for creating both the system model and the hardware realization. Moreover, the designer must ensure that the hardware realization meets the system specification. This validation can be extremely time-consuming, especially if redesign of the system model is required.
[0006] For high-level modeling of digital signal processing (DSP) systems, a visual data flow paradigm has been found to be well suited and widely adopted by system architects. In a data flow model, the system is a network of functional operators that process data carried by signals between the operators. Since many DSP algorithms are naturally specified by signal flow graphs, the topology of a visual data flow model often closely resembles the algorithm specification. Specifying a system in a visual data flow environment is in some ways similar to specifying a design in a traditional schematic capture tool. Visual data flow environments provide a block editor, which can be used to construct models by connecting elements selected from libraries of functional blocks. In contrast to schematic tools, however, the library blocks and the simulation environment in a data flow tool provide a high level of functional abstraction, with polymorphic data types and operators to model arithmetic operations on integer, fixed-point, and floating-point data. Time evolution is typically specified by sample rates rather than by wiring explicit clocks.
[0007] Although previous design flow environments support system-level modeling, the costs associated with the high level of abstraction include inefficient hardware implementations and inexact modeling of the hardware in the system-level simulation. Prior existing visual data flow environments have been suitable for system modeling (i.e., specification and simulation), but have not provided automatic generation of a hardware realization of the system model. Instead, a typical design flow involves a manual translation of the system model to a hardware realization (e.g., ASIC or FPGA), and a manual verification that ensures the hardware faithfully implements the system model.
[0008] For example, the commercial visual data flow environment, SPW, from Cadence, provides simulation libraries and target implementations. However, the user is required to manually create the hardware implementation by explicitly replacing simulation models by the target library elements. This process is non-trivial, since replacement can involve one-to-many mapping (architectural synthesis, including re-timing and hardware sharing), as well as synthesis of additional circuitry for inferred control logic (handshaking and clocking).
[0009] A method and system that supports both modeling and automatic generation of a faithful and efficient hardware realization are therefore desirable.
Summary of the Invention
[0010] In various embodiments, the present invention provides a method and system for creating an electronic circuit design from a system-level environment. A plurality of user-selectable system-level design objects are provided in the system-level environment. Each system-level design object is defined by a system-level function and is selectable by a system-level designer. A plurality of hardware-level design objects are also provided. Each hardware-level design object is configured to generate a hardware definition of a hardware-level function. Each system-level design object maps to one or more hardware-level design objects. In response to selections made by the designer, a system-level design is instantiated in a system-level design file. The system-level design includes user-selected ones of the system-level design objects. The system simulates behavior of the system-level design consistent with both the system-level functions and behavior of a hardware definition from the hardware-level design objects that implement the user-selected ones of the system-level design objects. Thus, the simulation at the system level is faithful to the system level functions as well as to the eventual hardware implementation.
[0011] It will be appreciated that various other embodiments are set forth in the Detailed Description and Claims which follow.
Brief Description of the Drawings
[0012] Various aspects and advantages of the invention will become apparent upon review of the following detailed description and upon reference to the drawings in which:
[0013] FIGS. 1A and 1B illustrate the difference between an example fast Fourier transform (FFT) operator in a system library and a FFT operator in a target hardware library;
[0014] FIG. 2 is a functional block diagram of a design system structured in accordance with one embodiment of the invention;
[0015] FIG. 3A is a block diagram of an example system-level design of an electronic circuit, and FIG. 3B is a block diagram of a hardware implementation generated from the system-level design.
Detailed Description
[0016] The present invention is described in terms of system-level designs for digital signal processing (DSP) systems and implementations for FPGAs. It will be appreciated, however, that the various concepts described herein, along with the various embodiments of the invention, can be applied to designs other than DSP systems and to implementation technologies other than FPGAs. The invention is applicable both to visual data flow modeling environments, and to other high-level design flows, e.g., based on a programming language such as C++.
[0017] The present invention addresses the validation problem by providing a mechanism for automatically generating a hardware realization from a system model, thereby removing the necessity of verifying the equivalence of the two representations. In addition, a mechanism and methodology are provided for the automatic production of a verified hardware representation from a high-level system model. In various embodiments, the invention includes a system library, a target library, and a compiler. The system library includes the functional operators in the system environment. The target library includes the implementations of the functional operators in the target hardware technology. The compiler translates a specified sequence of system library operations into a functionally corresponding circuit of interconnected components in the target library. The mapping of functional operations to implementation components may be one-to-one, one-to-many, or many-to-one.
[0018] The system library provides polymorphic arithmetic for floating-point, fixed-point, and integer operations. For quantization of data, the library supports various forms of saturation arithmetic and rounding. In each case, the target library provides equivalent data representations, although in hardware the values are represented as buses of standard logic vectors, with, for example, the binary point of a fixed point data representation being carried as an attribute (e.g., using VHDL generics). In the target library, floating point values may be realized by representing mantissas and exponents individually as buses of logic vectors. Functional operators are implemented as hardware design (sometimes referred to as “intellectual property”) blocks that have been tailored for high efficiency.
[0019] In addition to arithmetic abstraction that is mirrored in the target library, the system library elements implement handshaking protocols that allow data to flow through the system model without having explicit operators to control data transmission. In the target library, this functionality is, for example, realized through hardware in the blocks themselves and also through the injection of additional circuitry by the compiler.
[0020] With the present invention, it will be appreciated that in simulation, the behavior of the system library matches that of the target library bit-for-bit and cycle-for-cycle. This means detailed hardware behavior is made manifest in the system model without needing to simulate the hardware realization itself. The mapping from system element to target element may be one-to-many, but for any parameterization in the system model, the bit and cycle behavior is an accurate representation of the corresponding hardware behavior at the sample rate defined in the system model. In the example embodiment, the designer is provided with the ability to specify in the system model the points at which and in what fashion the hardware and system behaviors should be constrained to match, up to and including the ability of the user to relax the constraint on bit-true and cycle-true correspondence. With the relaxation of constraints, it is often possible for the compiler to realize more efficient hardware (e.g., through extensive re-timing and pipelining in the event that the user requests that the data match identically, but that the latency in its production can be tailored for performance).
[0021] The compiler allows networks of system library elements to be intermingled with networks of non-system library operators (e.g., user-defined elements). The compiler resolves system-level parameters into attributes on the target library blocks, and into additional circuitry (ports, blocks, and signals) in hardware. For example, the compiler converts a sample-rate-based representation into a clocked hardware implementation, automatically inferring clock, clock enable, and clear ports and signals (not present in the system model) based on sample rates defined in the system model. In the event that an HDL simulation is desired, the compiler generates a test bench and test vectors in the system environment integrated with the generated hardware realization.
[0022] The compiler also includes customization mechanisms to tailor the hardware realization to user specifications. For example, the compiler performs architectural synthesis, in response to user controls, when mapping system blocks to target blocks.
[0023] The current invention provides the IP library embedded in the target library. The replacement of elements in the simulation model with target library elements is automatic. In one embodiment, the system library includes functions (S-functions) in the Simulink™ simulation environment from The MathWorks, Inc. The target library includes VHDL modules and support packages, and the compiler translates a Simulink™ model (the system model) into a hardware realization. The compiler operates on the system model in successive stages. The software components of one embodiment of the invention are written in multiple languages, each selected for accomplishing the task at hand. The system library elements are written in a combination of MATLAB code (part of the Simulink™ environment), which interfaces directly to the underlying system simulation engine, and C++, which provides the benefits of object-oriented design. The compilation and simulation mechanisms chosen in this embodiment of the invention enable simulation-time customization of many system parameters (e.g., data precision). Such customization is not provided in previous approaches such as SPW or A|RT.
[0024] Functional operators in the system library are abstract to support ease of use. Operators in the target library are lower level, and often are highly detailed and closely tied to hardware. This makes the operators in the target library relatively complex to use. The simplicity of the system library operators makes algorithm exploration and high-level modeling practical. FIGS. 1A and 1B illustrate the difference between the fast Fourier transform (FFT) operator 52 in the system library and FFT operator 54 in the target library. It is clear that much of the detail in the hardware has been abstracted away in the system view, making the block much easier to use in practice. One of the tasks of the compiler is to bridge the gap between the system and hardware realizations of library elements.
[0025] FIG. 2 is a functional block diagram of a design system structured in accordance with one embodiment of the invention. System 100 includes the system library (block 112) and blocks that perform the phases of compilation. The compiler phases include resolving system parameters into attributes in an internal representation (block 122); expanding data types and inferring clock ports, signals, and generators (block 126); performing architectural synthesis (block 130); and netlisting into an HDL representation (block 144). The target library (block 118) provides synthesizable circuitry that wraps IP blocks (block 116) to extend the functionality, e.g., support of fixed-point data.
[0026] System 100 illustrates how a Simulink™ system model is transformed by a MATLAB function (netlister) into an internal representation. This internal representation undergoes several transformations that resolve system parameters into the required control circuitry and target library mapping. In particular, data types are resolved into hardware-realizable forms, and clock signals, flip-flop clock enables and resets are inferred from system sample rates.
[0027] A user's design 108 is defined within a system-level simulation environment 110, such as Simulink™. Based on the user's design, the system-level simulator calls on simulation functions 112, along with user simulation functions 114 to simulate the system-level design. The simulation functions 112 and user simulation functions 114 are configured to be bit-true and cycle-true relative to a hardware implementation. Thus, the bit-true and cycle-true characteristics of the simulation functions 112 and 114 are reflected in the cores 116 and in the synthesizable VHDL 118, respectively. Simulation functions 112 are associated with system-provided design objects, and user simulation functions 114 are those provided by the user for simulating user-provided design objects.
[0028] In order to support simulation at the system level that is bit-true to a hardware implementation, each simulation function 112 is defined to operate on a particular data type. For example, one instance of an FFT simulation function is defined to operate on fixed-point sample data. The simulation of the system-level design is also cycle-true to the hardware implementation. The sample periods associated with the system-level design blocks are translated into clock enable signals in the hardware implementation.
[0029] In translating the system-level design 108 to a hardware implementation, netlister 122 converts the system-level design into an internal representation, for example, textual representation 124, of the design hierarchy. Also included in the textual representation are attributes of the design objects. For example, the text describing a multiplier block includes attributes that specify the precision, whether the multiplier is implemented using a serial or parallel algorithm, whether pipelining is required, and the size. The textual representation of the system-level design elements is shown as blocks 124.
[0030] The hardware expander 126 further processes the textual representation of the design by adding control circuitry, signals, and ports for clock, clock-enable, and reset signals, and generating definition files 128 in the process. In addition, the hardware expander resolves data types. The additional ports that are required for a design are created by the hardware expander. For example, the hardware expander generates clock and clock-enable ports. To resolve data types, the hardware expander identifies types that have no direct analog in hardware (e.g., fixed point) and generates a suitable hardware representation.
[0031] Ports for clock, clock enable, and reset signals are identified as follows. In the system-level design 108 there are no explicit clocks. However, each object in the design outputs results at a sample rate that depends on the function of the object and on the sample rates of input data to the object. Hardware expander 126 performs the following operations in annotating the design with clock, clock-enable, and reset ports.
[0032] First, the hardware expander determines the sample rates that have been specified for every port on every object and then calculates the GCD (greatest common divisor) of these values. A period p=g/r is assigned to each port, where r is the port's sample rate and g is the GCD. Each period is a positive integer, and there is at least one port whose period equals 1.
[0033] Second, the hardware expander determines which clock signals are needed for the netlist by looking at the number of distinct periods assigned to ports. For example, if the set of periods assigned to ports is {1, 2, 3}, then the netlist must contain three clock signals with periods of 1, 2, and 3. There is always a clock that runs with period 1, which is referred to as the system clock. In hardware, every clock is derived from the system clock.
[0034] Third, the hardware expander determines which of the clock signals to assign to each of the design objects by looking at the periods associated with the object's ports. If, for example, an object has ports with periods 1 and 2, then clock, reset, and clock-enable signals corresponding to periods 1 and 2 must be attached to the object. The wiring pattern is inferred from the distribution of sample periods amongst the ports. No clocks are assigned to combinatorial logic objects.
[0035] Finally, the hardware expander adds one or more clock-generating components to the design; adds clock, reset, and clock-enable ports to the intermediate levels of the hierarchy; adds clock, reset, and clock-enable nets to each level; and then connects the clock generator, the newly added ports, and nets.
[0036] For resolving data types, the hardware expander identifies system data types, for example, fixed-point and floating-point data types, that have no direct correspondence in hardware and generates suitable hardware to accommodate the specified data types.
[0037] Architectural synthesis block 130 inputs the annotated design objects 128 and identifies specific logic cores 116 that are to be used by core generator 132 in generating VHDL files 134 for hardware simulation. Architectural synthesis block 130 also identifies additional supporting hardware that may be needed by a system-level design object. Thus, all the “leaf nodes” of the design are identified by architectural synthesis block 130. For example, an FFT object may require memory banks along with the logic that implements the function. The architectural synthesis block outputs commands 140 that are input to core generator 132, which generates VHDL for the identified leaf nodes of the design.
[0038] Architectural synthesis block 130 also generates descriptions of the connectivity between the leaf nodes of the design. The leaf nodes of the design and the defined interconnectivity descriptions are stored as files 142.
[0039] After architectural synthesis, all of the design hierarchy and mapping to target library elements are known. To facilitate a high-performance implementation, a constraint file (not shown) is generated to provide constraints for the subsequent synthesis, technology mapping, placement and routing phases of an implementation. One important constraint is to specify a timing budget that should be met when implementing critical paths in the design. In the synchronous scheme described above, every flip-flop runs at a single rate, which must be fast enough to meet the overall performance requirements. However, in a multi-rate design, not every path needs to run at this rate, since flip-flop activity occurs only under the control of the clock enable signal driving the flip-flop. A multi-cycle path constraint is therefore created for every path that corresponds to logic running at a slower rate.
[0040] VHDL netlister 144 creates wrapper VHDL files 146 that provide the structural definition and interconnectivity of the hardware design. VHDL files 146 also define the testbench for hardware simulation.
[0041] Testbench generation can be requested by a user at the time the user initiates generation of the hardware implementation with the netlister 122. To generate a hardware simulation testbench, the system-level simulation is translated into a VHDL file 146. At the system simulation level, simulation data are generated by “source functions” that are provided with the simulator and that are parameterizable by the user. For example, one source function might be a sine wave generator, which supplies a stream of values conforming to a sine wave, and an associated parameter is the frequency of the sine wave. While the system-level simulator 110 is running, the input values to the source functions are stored in a data file. The system-level simulation data files are then used to create hardware testbench data files and VHDL for inputting the data.
[0042] In one implementation, cores 116 are executable programs that are called on by core generator 132 to generate VHDL files 134 for use by HDL simulator 150 and to generate hardware-specific, low-level design files 152. An embodiment of a core generator is provided in the CoreGen software from Xilinx.
[0043] HDL simulator 150 performs hardware-level simulation on the hardware-level design as set forth in the VHDL files 134 and user-supplied VHDL files 118, with testbench data provided by VHDL files 146. HDL synthesis block 160 and foundry block 162 represent functional components in a conventional HDL design flow.
[0044] System 100 supports integration of user-provided, system-level design objects with vendor-provided design objects in a system-level design 108. Where the user has provided synthesizable VHDL files 118 that implement user-defined system-level objects, the bit-true and cycle-true simulation of the system-level design that includes the user-provided objects can be performed. The user-provided objects are tagged as “black boxes” in the system-level design, and are not subject to the core generator implementation operations that are performed for the system-provided objects.
[0045] FIG. 3A is a block diagram of an example system-level design of an electronic circuit, and FIG. 3B is a block diagram of a hardware implementation generated from the system-level design. System 200 is a multi-rate filter arrangement and includes input register 202, up-sampler 204, FIR filter 206, down-sampler 208, and output register 210. Input sample values are up-sampled by a factor of two, filtered, and then down-sampled by a factor of three. The overall sample rate conversion for system 200 is ⅔.
[0046] The sample rates that are specified at the system level are 48 kHz for input to register 202, 96 kHz for output from up-sampler 204 and input to FIR filter 206, and 96 kHz for output from down-sampler 208 and input to register 210. The normalized periods are determined to be 2, 1, and 3, respectively, as determined by the hardware expander 126, for example.
[0047] Gateway design objects 240 and 242 define the input and output boundaries of system 200, respectively. Gateway-in objects are design objects used for an input interface, and gateway-out objects are design objects used for an output interface. The simulation function associated with the gateway-in object captures input simulation data, and the simulation function associated with the gateway-out object captures output simulation data.
[0048] FIG. 3B illustrates a hardware implementation 250 of the system-level design shown in FIG. 2A . Register 252 corresponds to system object 202, block 254 correspond to system up-sampler 204, block 256 corresponds to system FIR filter 206, block 258 corresponds to system down-sampler 208, and register 260 corresponds to system object 210. The example illustrates the generation of clock-enable ports and clock control circuitry in the hardware design based on the information in the system-level design.
[0049] Hardware component 270 is a control circuit that generates clock-enable signals to accommodate the sample periods of 1, 2, and 3. The system clock signal is input at the CLK port, and the system clock-enable signal is input at the CE port. The system clock-enable signal is also connected to the CE port of filter component 256 to implement the sample period of 1. The clock-enable signal at output port CE2 of component 270 is connected to the CE2 input ports of input register 252 and up-sampler 254 to implement the sample period of 2. The clock-enable-signal at output port CE3 is connected to the CE3 input ports of down-sampler 258 and register 260 to implement the sample period of 3.
[0050] Even though it is not shown, it will be appreciated that some of the system-level objects may be implemented in the hardware-level design with multiple hardware components. For example, FIR filter 206 in the system design includes one or more memory modules that are used in conjunction with adders and multipliers.
[0051] Having described the gateway-in and gateway-out design objects, further details regarding system-level simulation, testbench creation, and hardware-level simulation are set forth in the following paragraphs. During system-level simulation, data samples flow into the gateway-in objects and out of the gateway-out objects at regular sample periods. The input values are the stimuli, and the output values are the responses. The input samples that are captured during system-level simulation can be used for the hardware-level simulation. The faithfulness of the hardware representation can be demonstrated in that if the stimuli in the hardware-level simulation are the same as the stimuli in the system-level simulation, the responses from the hardware-level simulation will be the same as the responses from the system-level simulation. The values presented at the input ports in the hardware-level simulation and produced at the output ports are bit vectors, which represent the fixed-point values from the system-level simulation.
[0052] The gateway-in objects in the system-level design are translated into VHDL components by the core generator 132 and cores 116. The VHDL components for the gateway-in objects read the input data that was captured during system-level simulation and input the data to the hardware-level design components, for example to register 252 of FIG. 3B . Gateway-out objects are translated into VHDL components that compare hardware-level simulation results, for example, from register 260, to expected results, as captured during system-level simulation.
[0053] The fixed-point data type of the system-level generator 110 (e.g., Simulink) is represented using a std_logic_vector in VHDL. The position of the binary point, size of the container, and treatment of sign are supplied to the VHDL as generic parameters. To ease interpretation of fixed-point types in VHDL, the gateway objects convert the std_logic_vector into a VHDL real number by using the generic parameter information. A sequence of real numbers can be viewed as an analog waveform in an HDL simulator such as ModelSim from Mode Technology, Inc. This allows the user to view results in the same format as with the system-level simulator.
Claims
What is claimed is:
1. A computer-implemented method for creating an electronic circuit design, comprising:
providing a plurality of user-selectable system-level design objects, each system-level design object defined by a system-level function;
providing a plurality of hardware-level design objects, each hardware-level design object configured to generate a hardware definition of a hardware-level function, wherein one or more hardware-level design objects are combinable to implement each system-level design object;
instantiating a system-level design in a system-level design file, the system-level design including user-selected ones of the system-level design objects;
simulating behavior of the system-level design consistent with the system-level functions and behavior of a hardware definition from the hardware-level design objects that implement the user-selected ones of the system-level design objects;
wherein each system-level design object is parameterizable and has associated therewith at least one input data port or at least one output data port, and each input and output data port has an associated, user-specified sample rate;
in response to a signal to generate a hardware-level design from the system-level design file,
supplementing the system-level design objects with clock-clear and clock-enable ports;
generating a clock control hardware definition that includes output ports for each different sample rate, with each clock-enable port coupled to a clock control output port having a rate corresponding to the associated sample rate;
identifying for each system-level design object one or more hardware-level design objects that implement the system-level design object; and
generating hardware definitions using hardware definition generators that are associated with the hardware-level design objects.
2. The method of claim 1, further comprising:
simulating behavior of the system-level design with user-specified input-data generators that generate system-level input data;
capturing the system-level input data generated by the input-data generators; and
generating a hardware definition for a first testbench component that provides the system-level input data as input data to the hardware definitions.
3. The method of claim 2, further comprising simulating behavior of the design defined by the hardware definitions and the testbench component.
4. The method of claim 3, further comprising:
capturing system-level output data generated during simulation of the system-level design;
generating a hardware definition for a second testbench component that compares output data generated during simulation of the design defined by the hardware definitions to output data captured during simulation of the system-level design.
5. The method of claim 1, further comprising:
simulating behavior of the design defined in the system-level design file with user-specified input-data generators that generate system-level input data;
capturing the system-level input data generated by the input-data generators; and
generating a hardware definition for a first testbench component that provides the system-level input data as input data to the hardware definitions.
6. The method of claim 5, further comprising simulating behavior of the design defined by the hardware definitions and the testbench component.
7. The method of claim 6, further comprising:
capturing system-level output data generated during simulation of the design defined in the system-level design file;
generating a hardware definition for a second testbench component that compares output data generated during simulation of the design defined by the hardware definitions to output data captured during simulation of the design defined in the system-level design file.
8. An apparatus for creating an electronic circuit design, comprising:
means for providing a plurality of user-selectable system-level design objects, each system-level design object defined by a system-level function;
means for providing a plurality of hardware-level design objects, each hardware-level design object configured to generate a hardware definition of a hardware-level function, wherein one or more hardware-level design objects are combinable to implement each system-level design;
means for instantiating a system-level design in a system-level design file, the system-level design including user-selected ones of the system-level design objects;
means for simulating behavior of the system-level design consistent with the system-level functions and behavior of a hardware definition from the hardware-level design objects that implement the user-selected ones of the system-level design objects;
wherein each system-level design object is parameterizable and has associated therewith at least one input data port or at least one output data port, and each input and output data port having an associated, user-specified sample rate;
means responsive to a signal to generate a hardware-level design from the system-level design file,
for supplementing the system-level design objects with clock-enable and clock-clear ports;
for generating a clock control hardware definition that includes output ports for each different sample rate, with each clock-enable port coupled to a clock control output port having a rate corresponding to the associated sample rate;
for identifying for each system-level design object one or more hardware-level design objects that implement the system-level design object; and
for generating hardware definitions using hardware definition generators that are associated with the hardware-level design objects.
9. A system for creating an electronic circuit design, comprising:
a plurality of user-selectable system-level design objects, each system-level design object defined by a system-level function;
a plurality of hardware-level design objects, each hardware-level design object configured to generate a hardware definition of a hardware-level function, wherein one or more hardware-level design objects are combinable to implement each system-level design;
a computing arrangement that hosts a system-level simulator, wherein the simulator is configured to instantiate a system-level design in a system-level design file, the system-level design including user-selected ones of the system-level design objects, and simulate behavior of the system-level design consistent with the system-level functions and behavior of a hardware definition from the hardware-level design objects that implement the user-selected ones of the system-level design objects;
wherein each system-level design object is parameterizable and has associated therewith at least one input data port or at least one output data port, and each input and output data port having an associated, user-specified sample rate;
a translator coupled to the system-level simulation environment, the translator configured to, responsive to a signal to generate a hardware-level design from the system-level design file,
supplement the system-level design objects with clock-enable and clock-clear ports;
generate a clock control hardware definition that includes output ports for each different sample rate, with each clock-enable port coupled to a clock control output port having a rate corresponding to the associated sample rate;
identify for each system-level design object one or more hardware-level design objects that implement the system-level design object; and
generate hardware definitions using hardware definition generators that are associated with the hardware-level design objects.
10. The system of claim 9, wherein the system-level simulation environment is configured to:
simulate behavior of the system-level design with user-specified input-data generators that generate system-level input data;
capture the system-level input data generated by the input-data generators; and
generate a hardware definition for a first testbench component that provides the system-level input data as input data to the hardware definitions.
11. The system of claim 10, wherein the system-level simulation environment is configured to:
capture system-level output data generated during simulation of the system-level design; and
generate a hardware definition for a second testbench component that compares output data generated during simulation of the design defined by the hardware definitions to output data captured during simulation of the system-level design.
Patent Citations (5)
| Patent | Date | Inventor | Cited By |
|---|---|---|---|
| US5870588(A) | 1999-02-01 | Rompaey et al. | Examiner |
| US6216255(B1) | 2001-04-01 | Ito et al. | Examiner |
| US6305001(B1) | 2001-10-01 | Graef | Examiner |
| US6606588(B1) | 2003-08-01 | Schaumont et al. | Examiner |
| US2004/0143801(A1) | 2004-07-01 | Waters et al. | Examiner |
Non-Patent Literature (12)
- Krukowski et al, “Simulink/Matlab-to-VHDL Route for Full-Custom/FPGA Rapid Prototyping of DSP Algorithms,” Matlab DSP Conference, pp. 1-10 (Nov. 1999)(text available at: http://dolphin.wmin.ac.uk/˜/artur/pdf/Paper18.pdf).Examiner
- Garbergs et al, “Implementation of a State Space Controller in a FPGA,” IEEE 9th Mediterranean Electrotechnical Conference, vol. 1, pp. 566-569 (May 1998).Examiner
- Chris Dick et al.; “Configurable Logic for Digital Communications: Some Signal Processing Perspectives”; Copyright 1999 IEEE; IEEE Communications Magazine; Aug. 1999; vol. 2; pp. 107-111.Applicant
- Chris H. Dick et al.; “Design and Implementation of High-Performance FPGA Signal Processing Datapaths for Software Defined Radios”; Embedded Systems Conference; Apr. 2001; pp. 1-16.Applicant
- Maya Gokhale et al.; “Stream-Oriented FPGA Computing in the Streams-C High Level Language”; Copyright 2000 IEEE; in Proceedings FCCM00; IEEE Computer Society Press 2000; pp. 49-56.Applicant
- Jennifer Eyre; “The Digital Signal Processor Derby”; IEEE Spectrum; Jun. 2001; pp. 62-68.Applicant
- Michael R. Strugill et al.; “Design and Verification of Third Generation Wireless Communication Systems”; White Paper, Cadence Design Systems, Inc.; Dec. 18, 2000; pp. 1-10.Applicant
- Edward A. Lee; “What's Ahead for Embedded Software?”; Copyright 2000 IEEE; IEEE Computer; vol. 33, No. 9; Sep. 2000; pp. 18-26.Applicant
- Benjamin Levine et al.; “Mapping of an Automated Target Recognition Application from a Graphical Software Environment to FPGA-based Reconfigurable Hardware”; in Proceedings FCCM99; IEEE Computer Society Press; 1999; pp. 292-293.Applicant
- Roger Lagadec et al.; “A 2-Channel, 16-Bit Digital Sampling Frequency Converter for Professional Digital Audio”; Proceedings IEEE International Conference ASSP; Copyright 1982 IEEE; Apr. 1982; pp. 93-96.Applicant
- Stanley A. White; “Applications of Distributed Arithmetic to Digital Signal Proceedings: A Tutorial Review”; IEEE ASSP Magazine; vol. 6(3); Jul. 1989; Copyright 1989 IEEE; pp. 4-19.Applicant
- M. Schiff; “Baseband Simulation of Communications System”; Application Note AN133; Elanix, Inc.; Apr. 2000; pp. 1-5.Applicant