Systems and methods for estimating performance characteristics of hardware implementations of executable models

• US 10,078,717 B1
• Filed: 12/05/2014
• Issued: 09/18/2018
• Est. Priority Date: 12/05/2013
• Status: Active Grant

• Current Assignee: The MathWorks, Inc.
• Original Assignee: The MathWorks, Inc.
• Inventors: Venkataramani, Girish, Gu, Yongfeng, Kokku, Rama
• Primary Examiner(s): Kik, Phallaka
• Application Number:
  US14/562,647
• Time in Patent Office: 1,383 Days
• Field of Search: 716104, 716103, 716106, 716108, 716109, 716111, 716113, 716131, 716133, 716134, 716135, 716136, 716117, 703 16
• CPC Class Codes: G06F 2119/08 Thermal analysis or thermal optimisation
• CPC Class Codes: G06F 2119/10 Noise analysis or noise optimisation
• CPC Class Codes: G06F 2119/12 Timing analysis or timing optimisation
• CPC Class Codes: G06F 30/327 Logic synthesis; Behaviour synthesis, e.g. mapping logic, HDL to netlist, high-level language to RTL or netlist
• CPC Class Codes: G06F 30/3312 Timing analysis
• CPC Class Codes: G06F 30/3315 using static timing analysis [STA]
• CPC Class Codes: G06F 30/398 Design verification or optimisation, e.g. using design rule check [DRC], layout versus schematics [LVS] or finite element methods [FEM] optical proximity correction [OPC] design processes G03F1/36

Abstract

Systems and methods automatically generate optimized hardware description language code for a model created in a modeling environment. A training tool selects and provides scripts to a hardware synthesis tool chain that direct the tool chain to synthesize hardware components for core components of the modeling environment. A report generated by the tool chain is evaluated to extract performance data for the core components, and the performance data is stored in a library. An optimization tool estimates the performance of the model using the performance data in the library. Based on the performance estimate and an analysis of the model, the optimization tool selects an optimization technique which it applies to the model generating a revised. Estimating performance, and selecting and applying optimizations may be repeated until a performance constraint is satisfied or a termination criterion is met.

Claims

1. A method comprising:

storing, in a first memory, a plurality of hardware synthesis scripts, where the plurality of hardware synthesis scripts

include instructions directing a hardware synthesis tool chain to implement functionality of core components of a modeling environment using hardware components of one or more physical target hardware elements, the core components providing base level functions or operations for use in executable models created in or run by the modeling environment, one or more of the core components implemented as model elements of the modeling environment;

providing the plurality of hardware synthesis scripts to the hardware synthesis tool chain for synthesizing the hardware components to implement the functionality of the core components of the modeling environment;

receiving performance data from the hardware synthesis tool chain for the hardware components synthesized to implement the functionality of the core components;

mapping, by a first processor coupled to the first memory, the performance data received from the hardware synthesis tool chain to the core components of the modeling environment;

storing, in the first memory or a second memory, the performance data as mapped to the core components of the modeling environment;

utilizing, by the first processor or a second processor, the performance data as mapped to the core components during generation of code for at least a portion of a given executable model that includes a plurality of the core components; and

implementing a given physical target hardware element based on the code generated for the at least a portion of the given executable model.

2. The method of claim 1 where the plurality of hardware synthesis scripts further specify characteristics for hardware implementations of the core components of the modeling environment.

3. The method of claim 2 where the characteristics are at least one of:

bitwidths,

fan-in values,

fan-out values,

number of inputs, or

core component parameters.

4. The method of claim 1 where the performance data as mapped to the core components is stored as one or more lookup tables.

5. The method of claim 1 where at least some of the plurality of synthesis scripts are custom-created by a user.

6. The method of claim 1 where the plurality of synthesis scripts are written in a Tool Command Language (tcl).

7. The method of claim 1 further comprising:

abstracting the performance data received from the hardware synthesis tool chain; and

storing the abstracted performance data in one or more data structures.

8. The method of claim 7 where the one or more data structures include sparse lookup tables (LUTs).

9. The method of claim 8 further comprising:

applying an interpolation algorithm or an extrapolation algorithm to derive particular performance data from the sparse LUTs.

10. The method of claim 1 further comprising:

a. receiving the given executable model, the given executable model including a plurality of the model elements;

b. generating an intermediate representation (IR) of the given executable model, the IR stored in the first memory, the second memory, or a third memory, the IR having a plurality of nodes associated with the core components that form the plurality of the model elements of the given executable model;

c. annotating the plurality of nodes of the IR with at least a portion of the performance data from the hardware synthesis tool chain;

d. estimating a hardware performance for the IR based on the performance data annotated to the plurality nodes of the IR;

e. automatically selecting an optimization technique;

f. applying the selected optimization technique to the IR to generate a revised IR having a plurality of nodes; and

g. repeating steps c to f using the revised IR, wherein the optimization technique is at least one of;

improving timing through pipelining or retiming,

improving area usage by replacing a first set of the plurality of nodes of the IR that implement functionality of a first model element with replacement nodes that implement the functionality of the first model element with less area than the first set of the plurality of nodes, or

improving power consumption by replacing a second set of the plurality of nodes of the IR that implement functionality of a second model element with substitute nodes that implement the functionality of the second model element with less power than the second set of the plurality of nodes.

11. The method of claim 10 where the repeating steps c to f is performed until

the estimated hardware performance satisfies a specified constraint, or

a termination criterion is met.

12. The method of claim 11 where the specified constraint is a timing constraint of a hardware implementation of the given executable model, and the estimating includes:

identifying a critical path, and

determining a latency of the critical path.

13. The method of claim 11 where the specified constraint is a timing constraint of a hardware implementation of the given executable model, and the estimating includes:

identifying a signal of the given executable model that operates at a slower rate than a clock speed associated with the given executable model;

identifying a register on a path of the given executable model that includes the signal that operates at the slower rate; and

determining a final latency for the path of the given executable model by dividing an initial latency by a ratio of the slower rate to the clock speed.

14. The method of claim 10 where the given executable model includes a plurality of occurrences of a subsystem, the method further comprising:

determining a latency for a first occurrence of the subsystem; and

applying the determined latency to the other occurrences of the subsystem.

15. The method of claim 1 wherein the performance data is for at least one of timing, area, or power.

16. The method of claim 1 wherein a first script of the plurality of hardware synthesis scripts specifies a constraint on at least one of timing, area, or power, and is free of identifying particular hardware components.

17. The method of claim 1 wherein the hardware components include at least one of:

logic cells;

input/output (I/O) cells;

hardware lookup tables;

or

standard cells of an ASIC technology library.

18. One or more non-transitory computer-readable media comprising program instructions for execution by one or more processors, the program instructions instructing the one or more processors to:

store, in a first memory coupled to at least one of the one or more processors, a plurality of hardware synthesis scripts, where the plurality of hardware synthesis scripts

include instructions directing a hardware synthesis tool chain to implement functionality of core components of a modeling environment using hardware components of one or more physical target hardware elements, the core components providing base level functions or operations for use in executable models created in or run by the modeling environment, one or more of the core components implemented as model elements of the modeling environment;

provide the plurality of hardware synthesis scripts to the hardware synthesis tool chain for synthesizing the hardware components to implement the functionality of the core components of the modeling environment;

receive performance data for the hardware components of the one or more physical target hardware elements from the hardware synthesis tool chain;

map the performance data received from the hardware synthesis tool chain to the core components of the modeling environment;

store, in the first memory or a second memory, the performance data as mapped to the core components of the modeling environment;

utilize the performance data as mapped to the core components during generation of code for at least a portion of a given executable model that includes a plurality of the core components; and

implement a given physical target hardware element based on the code generated for the at least a portion of the given executable model.

19. The one or more non-transitory computer-readable media of claim 18 where the plurality of hardware synthesis scripts further specify characteristics for hardware implementations of the core components of the modeling environment.

20. The one or more non-transitory computer-readable media of claim 18 where the performance data as mapped to the core components is stored as one or more lookup tables.

21. The one or more non-transitory computer-readable media of claim 18 wherein the program instruction further include instructions to:

abstract the performance data received from the hardware synthesis tool chain;

store the abstracted performance data in one or more data structures; and

apply an interpolation algorithm or an extrapolation algorithm to derive particular performance data from the one or more data structures.

22. The one or more non-transitory computer-readable media of claim 18 where the performance data is for at least one of timing, area, or power.

23. The one or more non-transitory computer-readable media of claim 18 wherein the program instructions further include instructions to:

abstract the performance data received from the hardware synthesis tool chain; and

store the abstracted performance data in one or more sparse lookup tables (LUTs) structures.

24. The one or more non-transitory computer-readable media of claim 23 wherein the program instructions further include instructions to:

apply an interpolation algorithm or an extrapolation algorithm to derive particular performance data from the sparse LUTs.

25. The one or more non-transitory computer-readable media of claim 18 wherein a first script of the plurality of hardware synthesis scripts specifies a constraint on at least one of timing, area, or power, and is free of identifying particular hardware components.

26. The one or more non-transitory computer-readable media of claim 18 wherein the hardware components include at least one of:

logic cells;

input/output (I/O) cells;

hardware lookup tables;

or

standard cells of an ASIC technology library.

27. An apparatus comprising:

a memory storing a plurality of hardware synthesis scripts, where the plurality of hardware synthesis scripts

include instructions directing a hardware synthesis tool chain to implement functionality of core components of a modeling environment using hardware components of one or more physical target hardware elements, the core components providing base level functions or operations for use in executable models created in or run by the modeling environment, one or more of the core components implemented as model elements of the modeling environment; and

one or more processors at least one of which is coupled to the memory, the one or more processors configured to

provide the plurality of hardware synthesis scripts to the hardware synthesis tool chain for synthesizing the hardware components to implement the functionality of the core components of the modeling environment;

receive performance data from the hardware synthesis tool chain for the hardware components synthesized to implement the functionality of the core components;

map the performance data received from the hardware synthesis tool chain to the core components of the modeling environment;

store, in the memory or in an additional memory, the performance data as mapped to the core components of the modeling environment;

utilize the performance data as mapped to the core components during generation of code for at least a portion of a given executable model that includes a plurality of the core components; and

implement a given physical target hardware element based on the code generated for the at least a portion of the given executable model.

28. The apparatus of claim 27 wherein the plurality of hardware synthesis scripts further specify characteristics for hardware implementations of the core components of the modeling environment, and the characteristics are at least one of:

bitwidths,

fan-in values,

fan-out values,

number of inputs, or

core component parameters.

29. The apparatus of claim 27 wherein the performance data as mapped to the core components is stored as one or more lookup tables.

30. The apparatus of claim 29 wherein the one or more processors is further configured to:

abstract the performance data received from the hardware synthesis tool chain; and

store the abstracted performance data in one or more data structures.

31. The apparatus of claim 30 wherein the one or more data structures include sparse lookup tables (LUTs).

32. The apparatus of claim 31 wherein the one or more processors is further configured to:

apply an interpolation algorithm or an extrapolation algorithm to derive particular performance data from the sparse LUTs.

33. The apparatus of claim 27 wherein the performance data is for at least one of timing, area, or power.

34. The apparatus of claim 27 wherein a first script of the plurality of hardware synthesis scripts specifies a constraint on at least one of timing, area, or power, and is free of identifying particular hardware components.

35. The apparatus of claim 27 wherein the hardware components include at least one of:

logic cells;

input/output (I/O) cells;

hardware lookup tables;

or

standard cells of an ASIC technology library.