| SLICC - Version 0.3 Design Document - January 17, 1999 |
| Milo Martin and Dan Sorin |
| |
| Question: Rethinking of support for profiling the transactions |
| |
| Question: How do we deal with functions/methods and resources |
| |
| Comment: We need to discuss the sequencer interface so it can work now |
| and for the speculative version buffer. |
| |
| Overview |
| -------- |
| |
| We are in the process of designing and implementing SLICC v0.3, an |
| evolution of SLICC v0.2. The new design includes capabilities for |
| design of multilevel cache hierarchies including the specification of |
| multiple protocol state machines (PSMs) and the queues which connect |
| these PSMs and the network. We actually believe that most of the |
| network and network topology, including the ordered network, can be |
| expressed using the new hierarchical extensions to the language. |
| |
| In addition, many implicit aspects of the language will be eliminated |
| in favor of explicit declarations. For example functions, queues, and |
| objects declarations such as "cacheMemory" and "TBETable" will be |
| explicitly declared. This will allow for full static type checking |
| and easier extension for the language. Event triggering will be part |
| of "in_port" declarations and not "event" declarations. Finally, many |
| less fundamental, but important, features and internal code |
| improvements will be enhanced. |
| |
| SLICC History |
| ------------- |
| |
| v0.1 - Initially the language only handled the generation of the PSM |
| transition table logic. All actions and event triggering were |
| still coded in C++. At this point it was still called, "the |
| language." |
| |
| v0.2 - Extended the language to include a simple C like syntax for |
| specifying actions, event triggering, and manipulating queues |
| and state elements. This version was the first version of the |
| language known as SLICC (suggested by Amir) and was used for |
| the Multifacet ISCA 2000 submission. |
| |
| v0.3 - Development effort started January 2000. Intended features and |
| enhancements are described by this document. |
| |
| Specifying Hierarchical Designs |
| ------------------------------- |
| |
| Right now all of our protocols have two tables, a processor/cache PSM |
| and a directory PSM. In v0.2 this is a rigid requirement and |
| the names are implicit. SLICC v0.3 will allow for an arbitrary number |
| of different PSMs. |
| |
| The most significant improvement in v0.3 is the ability for the user |
| to define an arbitrary set of interconnected PSMs. PSMs may include |
| an L1 cache controller, L2 cache controller, directory controller, |
| speculative version buffer, network interface, etc. There are a |
| couple of "primitive PSMs" such as the sequencer. |
| |
| There will be a notion of a "node" of the system. In a node, each PSM |
| will be instantiated and connected together with queues. For example, |
| assume we define a PSMs and want to create a queue of RequestMessages |
| to communicate between it and the network. |
| |
| machine(CacheController) { |
| ... |
| out_port(to_network, RequestMessage, "To the network", desc="..."); |
| ... |
| } |
| |
| CacheController cache, desc="..."; |
| |
| connect(cache.to_network, network.from_cache, ordered="yes", desc="..."); |
| |
| Explicit State Manipulation |
| --------------------------- |
| |
| As before, PSMs have states, events, and transitions. New in v0.3 each |
| PSM must have user defined methods for get_state(address) and |
| set_state(address, state), and these methods are written explicitly, |
| instead of being implicit functions of memory states (e.g., our |
| current implementation which implicitly uses the TBE state if there is |
| a TBE or uses the cache state). Functions have a return value, |
| procedures do not. Function calls are expressions, procedure calls |
| are statements. All function and procedure parameters are considered |
| pass-by-value. |
| |
| procedure set_state(Address addr, State state) { |
| ... |
| } |
| |
| function State get_state(Address addr) { |
| ... |
| } |
| |
| Explicit Declaration |
| -------------------- |
| |
| PSMs reference or declare structures, such as queues, ports, cache |
| memories, main memory, TBEs, write buffers, etc. These primitive |
| types and structures are written in C++, and their semantics are still |
| specified by the C++ coder. Examples of these primitive types include |
| "CacheMemory," "TBETable," as well as various types of queues. |
| |
| One major difference is that in v0.3 the interface for all of these |
| primitive objects will be declared (but not defined) in the SLICC |
| language. This also allows adding primitive structures by defining a |
| C++ implementation and a SLICC interface specification. This will |
| make the language much more extensible. Specifying the interface of |
| these primitive types, structures, and queues in SLICC will eliminate |
| much of the implicit semantics that is currently hiding in the |
| controllers. |
| |
| The interface declaration might be in one file and shared between all |
| protocols. The object instantiation would be internal to each PSM |
| that requires a cache memory. The syntax for messages will also be |
| enhanced by using this new syntax. Notice the support for default |
| values. |
| |
| structure(CacheMemory, "Cache memory", desc="...") { |
| void cache_change_state(Address addr, State state), desc="..."; |
| Data dataBlk, default="", desc=""; |
| bool cache_avail(Address addr), desc="..."; |
| Address cache_probe(Address addr), desc="..."; |
| void cache_allocate(Address addr), desc="..."; |
| } |
| |
| CacheMemory L1cacheMemory, desc="..."; |
| |
| Structure specification is going to require the introduction of an |
| object model in the language. The "." (dot) operator is going to be |
| extended beyond the use as structure element access, but also allow |
| for a object method call syntax similar to C++ and Java. |
| |
| L1cacheMemory.cache_allocate(addr); |
| |
| Polymorphism |
| ------------ |
| |
| We are also going to want to allow for polymorphism for many of the |
| structures. We already have a limited degree of polymorphism between |
| different protocols by using the same cache memory structure with |
| different "CacheEntry" types in each protocol. Now that we are going |
| to have multiple levels of cache, each requiring slightly different |
| state bits, we are going to want to specify cache memory structures |
| which have different "CacheEntry" types in the same protocol. To do |
| this right, this is going to require adding full polymorphism support |
| to the language. Right now we imagine something like C++'s templates, |
| since they are a more natural fit to hardware synthesis in the future. |
| |
| Type Checker |
| ------------ |
| |
| All of the above substantially complicates our type system by |
| requiring more types and scoping rules. As a step towards |
| understanding the implications of the type system, a type checking |
| system will be implemented. This is a hard requirement if we are ever |
| to distribute the system since receiving compile time errors in the |
| generated code is not acceptable. In order to ensure that we don't |
| accidentally design a language that is not statically type checkable, |
| it is important to add the type checker sooner rather than later. |
| |
| Event Triggering |
| ---------------- |
| |
| In v0.2, PSM events were individually specified as sets of conditions. |
| The following SLICC v0.2 code is a simplified example from the origin |
| protocol. |
| |
| event(Dir_data_ack_0, "Data ack 0", desc="... ack count == 0") { |
| if (queue_ready(responseNetwork)) { |
| peek(responseNetwork, ResponseMsg) { |
| if(in_msg.NumPendingAcks == 0) { |
| trigger(in_msg.Address); |
| } |
| } |
| } |
| } |
| |
| event(Dir_data_ack_not_0, "Data ack not 0", desc="... ack count != 0") { |
| if (queue_ready(responseNetwork)) { |
| peek(responseNetwork, ResponseMsg) { |
| if(in_msg.NumPendingAcks != 0) { |
| trigger(in_msg.Address); |
| } |
| } |
| } |
| } |
| |
| The above code defines the exact conditions for the events to be |
| triggered. This type of event specification led to redundant code and |
| numerous bugs where conditions for different events were not |
| completely orthogonal. |
| |
| In v0.3, events will be declared with no accompanying code (similar to |
| how states are specified). Instead, the code that determines which |
| event is triggered will be part of each incoming port's declaration. |
| This approach should eliminate redundancy and bugs in trigger |
| conditions. The v0.3 code for the above would look like: |
| |
| event(Dir_data_ack_0, "Data ack 0", desc="... ack count = 0"); |
| event(Dir_data_ack_not_0, "Data ack not 0", desc="... ack count != 0"); |
| |
| in_port(responseNetwork, ResponseMsg, "Response Network", desc="...") { |
| if(in_msg.NumPendingAcks == 0) { |
| trigger(Dir_data_ack_0, in_msg.Address); |
| } else { |
| trigger(Dir_data_ack_not_0, in_msg.Address); |
| } |
| } |
| |
| Notice that one no longer needs to explicitly check if the queue is |
| ready or to perform the peek operation. |
| |
| Also notice that the type of messages that arrives on the port is |
| explicitly declared. All ports, incoming and outgoing, are now |
| explicitly type channels. You will still be required to include the |
| type of message when manipulating the queue. The type specified will |
| be statically type checked and also acts as self-documenting code. |
| |
| Other Improvements |
| ------------------ |
| |
| There will be a number of other improvements in v0.3 such as general |
| performance tuning and clean up of the internals of the compiler. The |
| compiler will be modified to operate on multiple files. In addition, |
| the abstract syntax tree internal to the code will need to be extended |
| to encompass more information, including information parsed in from |
| multiple files. |
| |
| The affiliates talk and the document for the language should also be |
| updated to reflect the changes in the new version. |
| |
| Looking Forward |
| --------------- |
| |
| When designing v0.3 we are keeping future plans in mind. |
| |
| - When our designs of the multilevel cache hierarchy are complete, we |
| expect to have a large amount of replication between the protocols |
| and caches controllers within a protocol. For v0.4 we hope to look |
| at the patterns that have evolved and look for ways in which the |
| language can capture these patterns. Exploiting reuse will provide |
| quicker protocol development and maintainability. |
| |
| - By keeping the specification structural, we are looking towards |
| generating VHDL/Verilog from SLICC. The type system will help this, |
| as will more explicit instantiation and declaration of types and |
| structures. The structures now written in C++ (sequencer, network, |
| cache arrays) will be ported to the HDL we select. The rest of the |
| controllers will be generated by the compiler. At first the |
| generated controller will not be optimized. I believe that with |
| more effort we can automatically generate reasonably optimized, |
| pipelined implementation of the controllers. |
| |
| Implementation Plan |
| ------------------- |
| |
| - HTML generator |
| - Extend internal parser AST nodes |
| - Add get_state function and set_state procedure declarations |
| - Move trigger logic from events to in_ports |
| - Types |
| - Change type declaration syntax |
| - Declare primitive types and corresponding C++ types |
| - Add default values to structures and types |
| - Add object method call syntax |
| - Write type checker |
| - Documentation |
| - Revise document |
| - Update presentation |
| |
| Document History |
| ---------------- |
| |
| $Id: SLICC_V03.txt,v 3.0 2000/09/12 20:27:59 sorin Exp $ |
| |
| $Log: SLICC_V03.txt,v $ |
| Revision 3.0 2000/09/12 20:27:59 sorin |
| Version 3.0 signifies a checkpoint of the source tree right after the |
| final draft of the ASPLOS '00 paper. |
| |
| Revision 1.1.1.1 2000/03/09 10:18:38 milo |
| Initial import |
| |
| Revision 2.0 2000/01/19 07:21:13 milo |
| Version 2.0 |
| |
| Revision 1.5 2000/01/18 10:26:24 milo |
| Changed the SLICC parser so that it generates a full AST. This is the |
| first step in moving towards v0.3 |
| |
| Revision 1.4 2000/01/17 18:36:15 sorin |
| *** empty log message *** |
| |
| Revision 1.3 2000/01/15 10:30:16 milo |
| Added implementation list |
| |
| Revision 1.2 2000/01/15 08:11:44 milo |
| Minor revisions |
| |
| Revision 1.1 2000/01/15 07:14:17 milo |
| Converted Dan's first draft into a text file. Significant |
| modifications were made. |
| |