Performance Modeling and Builtin Logic of Constraints in

Performance Modeling and Built-in Logic of Constraints in Metropolis Guang Yang Professor Alberto Sangiovanni. Vincentelli http: //chess. eecs. berkeley. edu Quantity Performance Modeling A generic mechanism to model performance Define different quantities for different performance indices. Add performance models to platform by annotating quantities to services provided by the platform. (Including quantity annotation request phase and quantity resolution phase. ) Based on the quantities, it is easy to evaluate the performance of the platform, and it is easy to enforce the performance of the services with declarative constraints. Application Space Application Instance Platform Mapping System Platform (HW and SW) Platform Design-Space Export Platform Instance Architectural Space In platform-based design, two pieces of information are required to capture the characteristics of a platform. - Services provided by the platform - Performance (costs) of these services In Metropolis, all services provided by a platform can be abstracted by an object called interface. The performance or cost of these services are modeled by quantities. An example using Global. Time quantity Mixing imperative specification and declarative constraints is one of the key features of Metropolis. Declarative constraints can be used to specify the properties of the platform. They significantly reduce the development efforts, especially at the very beginning of the design cycle, where the properties themselves are of great importance while the realization is not. This allows designers to focus on the abstract behavior of the system, not the implementation of the system. To support this methodology, tools such as simulator must be able to enforce the constraints automatically. SM P 0 M SM c 0 Netlist port writer Y; port reader X; thread(){ while(true){ {@ beg{ request. I(0); } Y. write(z); end{ beg. Time = A(LAST); request(beg. Time+4); Built-in LOC Constraints Although LOC is powerful enough to express many types of constraints, in practice, only a set of such constraints are usually used. To ease the performance modeling, Metropolis provides a set of built-in LOC constraints, including maxrate, minrate, maxdelta, mindelta and period. Do not be misled by their names. They are not only constraints about execution time. They just define the mathematical relationship for quantities. For example, maxdelta specifies the distance between two events must be no more than a certain value. In time domain, this corresponds to the maximum latency between the two events; in priority domain, this probably means one event can not have more than some level of priorities over another event, etc. Enforcing Built-in LOC Constraints The regular execution flow of quantity annotation is that processes first make quantity annotation requests to a quantity manager, then the quantity manager works on the set of requests. One biggest problem in enforcing LOC constraints is that when resolving quantities, the set of requests might not consist of the public eval double A(); public eval void request(); public update void resolve(); public update postcond(); public eval boolean stable(); public elaborate eval Quantity get. Quantity(); // return the quantity itself for built-in LOC public update register. LOC(); // register built-in LOCs public update unregister. LOC(); // unregister built-in LOCs request(beg. Time+3); } @} }} @} LOC maxrate(X. read, 10); }}} } // annotate an event // make quantity annotation request // resolve all annotation requests // clean up after resolve() // check whether a resolution stabilize } port reader X; process c 0{ thread(){ port reader X; thread(){ X. read(); end{ beg. Time = A(LAST); } process c 0{ public update double sub(double t 1, double t 2) { return t 1 - t 2; } public eval boolean equal(double t 1, double t 2) { return t 1 == t 2; } public eval boolean less(double t 1, double t 2) { return t 1 < t 2; } {@ beg{ request. I(0); } Global. Time Annotation Requests LOC is defined over quantities and variables. LOC is a general logic such that it can refer to all variables and quantities occurred in the entire execution. In theory, it can express almost all runtime properties of a system. double _gtime; process c 0{ z=z+1; LTL is to specify coordination among events or services. It can be enforced by keeping track of Buchi Automata. Please refer to my previous Chess review posters. public final quantity Global. Time implements Global. Time. Manager { Scheduling Netlist process P 1{ There are two sorts of declarative constraints: Linear Temporal Logic (LTL) and Logic of Constriants (LOC). Global. Time SM P 1 November 18, 2004 Declarative Constraints LTL & LOC while(true){ {@ beg{ request. I(0); } X. read(); end{ beg. Time = A(LAST); request(beg. Time+3); } @} }} LOC maxrate(X. read, 10); } while(true){ {@ register. LOC(X. read, 10); beg{ request. I(0); } X. read(); end{ beg. Time = A(LAST); request(beg. Time+3); } @} }} unregister. LOC(X. read, 10); } events constrained by the built-in LOC. To handle this, register. LOC and unregister. LOC are introduced. In quantity managers, resolve function should take care of such LOCs. In particular, in Global. Time quantity manager, if there are LOC constraints, it should reserve the required quantity for the events, even if the events are disabled, because otherwise when they becomes enabled, they will stuck.