Quantity  A generic mechanism to model performance

1. SM SM SM Application Space Application Instance Platform Mapping System Platform (HW and SW) Platform Design-Space Export Platform Instance Architectural Space Guang Yang Professor Alberto Sangiovanni- Vincentelli Performance Modeling and Built-in Logic of Constraints in Metropolis http://chess.eecs.berkeley.edu LTL & LOC There are two sorts of declarative constraints: Linear Temporal Logic (LTL) and Logic of Constriants (LOC). 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. 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. 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 • Quantity •  A generic mechanism to model performance • 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 GlobalTime quantity Performance Modeling 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. Declarative Constraints 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. P0 GlobalTime c0 M P1 public final quantity GlobalTime implements GlobalTimeManager { double _gtime; public update double sub(double t1, double t2) { return t1 - t2; } public eval boolean equal(double t1, double t2) { return t1 == t2; } public eval boolean less(double t1, double t2) { return t1 < t2; } public eval double A(); // annotate an event public eval void request(); // make quantity annotation request public update void resolve(); // resolve all annotation requests public update postcond(); // clean up after resolve() public eval boolean stable(); // check whether a resolution stabilize public elaborate eval Quantity getQuantity(); // return the quantity itself for built-in LOC public update registerLOC(); // register built-in LOCs public update unregisterLOC(); // unregister built-in LOCs } events constrained by the built-in LOC. To handle this, registerLOC and unregisterLOC are introduced. In quantity managers, resolve function should take care of such LOCs. In particular, in GlobalTime 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. Netlist Scheduling Netlist process c0{ port reader X; thread(){ while(true){ {@ registerLOC(X.read, 10); beg{ requestI(0);} X.read(); end{ begTime=A(LAST); request(begTime+3); } @} }} unregisterLOC(X.read, 10); } process c0{ port reader X; thread(){ while(true){ {@ beg{ requestI(0);} X.read(); end{ begTime=A(LAST); request(begTime+3); } @} }} LOC maxrate(X.read, 10); } process P1{ port writer Y; thread(){ while(true){ z=z+1; {@ beg{ requestI(0);} Y.write(z); end{ begTime=A(LAST); request(begTime+4); } @} }}} process c0{ port reader X; thread(){ while(true){ {@ beg{ requestI(0);} X.read(); end{ begTime=A(LAST); request(begTime+3); } @} }} LOC maxrate(X.read, 10); } GlobalTime Annotation Requests November 18, 2004