1.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.2 +++ b/src/Application/CircuitNetlistCreator.c	Sat Nov 19 17:58:21 2011 -0800
     1.3 @@ -0,0 +1,1 @@
     1.4 +/*
     1.5  *  Copyright 2011 OpenSourceStewardshipFoundation.org
     1.6  *  Licensed under GNU General Public License version 2
     1.7  *
     1.8  * Author: seanhalle@yahoo.com
     1.9  *
    1.10  */
    1.11 
    1.12 #include "HWSim__Hello_World_HW/HWSim__Hello_World_HW.h"
    1.13 
    1.14 
    1.15 /*This file constructs the netlist for the Hello World circuit, which is
    1.16  * used during design and implementation of the HWSim language
    1.17  * 
    1.18  *It has two timelines, each with one input port and one output port, and
    1.19  * a single span-type.
    1.20  *
    1.21  *The timelines are cross-coupled, so output port of one connects to input
    1.22  * port of the other.  The input port has a single trigger, which fires
    1.23  * the one span-type.
    1.24  * 
    1.25  *The span does nothing, except send a NULL message on the output port.
    1.26  * 
    1.27  *The span-sim-time and communication-sim-time are both constants.
    1.28  *
    1.29  *Note that timelines are generic.  They are specialized by declaring
    1.30  * inports and outports, and by registering triggers that fire particular
    1.31  * span-types.
    1.32  */
    1.33 HWSimNetlist *
    1.34 createPingPongNetlist()
    1.35  { HWSimNetlist *netlist;
    1.36    HWSimWire   **wires;
    1.37    TimeLine    **timelines;
    1.38    
    1.39    int numTimelines;
    1.40    int numWires;
    1.41  
    1.42    netlist = malloc( sizeof(HWSimNetlist) );
    1.43    
    1.44       //declare timelines
    1.45    numTimelines = 2;
    1.46    timelines = malloc( numTimelines * sizeof(TimeLine) );
    1.47    netlist->numTimelines = numTimelines;
    1.48    netlist->timelines    = timelines;
    1.49    
    1.50    timelines[0] = createAPingPongTimeline();
    1.51    timelines[1] = createAPingPongTimeline();
    1.52    
    1.53       //add a trigger to reset port of one of the timelines, to start things
    1.54    HWSimSpanType *pingPongSpan;
    1.55    pingPongSpan = malloc( sizeof(HWSimSpanType) );
    1.56    pingPongSpan->behaviorFn = &behaviorOf_ping_pong_span;
    1.57    pingPongSpan->timingFn   = &timingOf_ping_pong_span;
    1.58    
    1.59    timelines[1]->triggers[0]->inPortNum = -1//the reset port
    1.60    timelines[1]->triggers[0]->spanType = pingPongSpan;
    1.61    
    1.62       //Connect timelines together
    1.63    numWires = 2;
    1.64    wires = malloc( numWires * sizeof(HWSimWire) );
    1.65    netlist->numWires = numWires;
    1.66    netlist->wires    = wires;
    1.67    
    1.68    wires[0] = {0,0,1,0,0}; //tl 0, out-port 0 to tl 1, in-port 0, msg-type 0
    1.69    wires[1] = {1,0,0,0,0};
    1.70 
    1.71 /* For starters, not doing time-domains..  will add later (Nov 2011)
    1.72       //Create time domains
    1.73    numTimeDomains = 2;
    1.74    timeDomains    = malloc( numTimeDomains * sizeof(TimeDomain) );
    1.75    netlist->numTimeDomains = numTimeDomains;
    1.76    netlist->timeDomains    = timeDomains;
    1.77    
    1.78    timeDomains[0]->numDomains   = 0;
    1.79    timeDomains[0]->numTimelines = 1;
    1.80    timeDomains[0]->timelines[0] = 0;//is index into netlist->timelines[]
    1.81    
    1.82    timeDomains[1]->numDomains   = 0;
    1.83    timeDomains[1]->numTimelines = 1;
    1.84    timeDomains[1]->timelines[0] = 1;//index into netlist->timelines[]
    1.85    
    1.86       //Create time domain connections -- must respect hierarchy
    1.87    numDomainConnections = 2;
    1.88    domainConnects = malloc( numDomainConnections * sizeof(HWSimDomainConn) );
    1.89    netlist->numDomainConns = numDomainConnections;
    1.90    netlist->domainConns    = domainConnects;
    1.91    
    1.92    domainConnects[0] = {0,1}; //domain 0 sends sim-time updates to domain 1
    1.93    domainConnects[1] = {1,0}; //domain 1 sends sim-time updates to domain 0
    1.94  */
    1.95  }
    1.96 
    1.97 TimeLine *
    1.98 createAPingPongTimeline()
    1.99  { TimeLine *tl;
   1.100    HWSimTrigger **triggers;
   1.101    
   1.102    tl = malloc( sizeof(TimeLine) );
   1.103     
   1.104    tl->numInPorts  = 1;
   1.105    tl->numOutPorts = 1;
   1.106    tl->numTriggers = 2;
   1.107    
   1.108    triggers = malloc( 2 * sizeof(HWSimTrigger) ); //extra is reset trig
   1.109    tl->triggers[0].inPortNum = -1; //reset trigger
   1.110    tl->triggers[0].spanType = IDLE_SPAN;
   1.111    
   1.112    HWSimSpanType *pingPongSpan;
   1.113    pingPongSpan = malloc( sizeof(HWSimSpanType) );
   1.114    pingPongSpan->behaviorFn = &behaviorOf_ping_pong_span;
   1.115    pingPongSpan->timingFn   = &timingOf_ping_pong_span;
   1.116    
   1.117    tl->triggers[1].inPortNum = 0; //TODO: Debug: verify whether . or ->
   1.118    tl->triggers[1].spanType = pingPongSpan;
   1.119  }
   1.120 \ No newline at end of file

     2.1 --- a/src/Application/HWSim__Hello_World_HW/Communicator_TimeLine.c	Mon Nov 07 16:03:01 2011 -0800
     2.2 +++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
     2.3 @@ -1,297 +0,0 @@
     2.4 -/*
     2.5 
     2.6 - *  Copyright 2009 OpenSourceStewardshipFoundation.org
     2.7 
     2.8 - *  Licensed under GNU General Public License version 2
     2.9 
    2.10 - *
    2.11 
    2.12 - * Author: seanhalle@yahoo.com
    2.13 
    2.14 - *
    2.15 
    2.16 - */
    2.17 
    2.18 -
    2.19 
    2.20 -#include "HWSim_TeraFlux.h"
    2.21 
    2.22 -
    2.23 
    2.24 -//=====================
    2.25 
    2.26 -
    2.27 
    2.28 -//===========================================================================
    2.29 
    2.30 -/*This is the collection of spans for the Communication Processor TimeLine
    2.31 
    2.32 - *
    2.33 
    2.34 - *This TimeLine does acquire-start, acquire-send, release, acquire-receive,
    2.35 
    2.36 - * all triggered by communications coming from other TimeLines.
    2.37 
    2.38 - * 
    2.39 
    2.40 - *  Sometime after Feb 2011 it will also have the control-
    2.41 
    2.42 - * communications that Albert wants for Erbium (the broad-cast of counter
    2.43 
    2.44 - * updates to registered listener TNodes).  And, it will probably get some
    2.45 
    2.46 - * form of control communication for implementing a fast chip-wide VMS.
    2.47 
    2.48 - *
    2.49 
    2.50 - *
    2.51 
    2.52 - *
    2.53 
    2.54 - *The kinds of span the TimeLine can have are:
    2.55 
    2.56 --] acquire-start -- is triggered by the reception of a "start-acquire"
    2.57 
    2.58 -   communication from the CPU TimeLine. It generates an "acquire send"
    2.59 
    2.60 -   communication to the TNode that currently owns the data.
    2.61 
    2.62 --] acquire-send -- when triggered, checks if the Frame is free.  If yes,
    2.63 
    2.64 -   sends an "acquire-receive" communication back to the requester.  If not
    2.65 
    2.66 -   free, places data representing the acquire-request into a queue of waiting
    2.67 
    2.68 -   ones in the Communicator TimeLine.  When the Communicator receives a
    2.69 
    2.70 -   "release" communication from the CPU TimeLine, it runs the release span.
    2.71 
    2.72 --] release -- takes the data of the next request waiting for the released
    2.73 
    2.74 -   Frame out of the queue and then sends an "acquire-receive" communication
    2.75 
    2.76 -   to the TNode requesting.
    2.77 
    2.78 --] acquire-receive -- when triggered, runs firmware, which writes memory
    2.79 
    2.80 -   shared with the CPU, modifying data-structures.  This firmware for
    2.81 
    2.82 -   TeraFlux works with the System Code that runs on the CPU TimeLine to
    2.83 
    2.84 -   notify it that the acquire is complete.
    2.85 
    2.86 - *
    2.87 
    2.88 - *
    2.89 
    2.90 - *Background on acquire:
    2.91 
    2.92 - *The request handler invokes acquire by placing the calling VP into
    2.93 
    2.94 - * a holding list, then executing the hardware instruction that starts the
    2.95 
    2.96 - * acquire.
    2.97 
    2.98 - *This instruction sends a communication from the CPU TimeLine to the
    2.99 
   2.100 - * Communicator TimeLine.  The instruction passes a pointer to the
   2.101 
   2.102 - * list element, and also passes a pointer to the queue of
   2.103 
   2.104 - * ready VPs.  When acquire comm is done, the Communicator takes the list
   2.105 
   2.106 - * element out and recycles it, and places the pointer to the VP into the
   2.107 
   2.108 - * queue of ready VPs.
   2.109 
   2.110 - * 
   2.111 
   2.112 - *In the actual hardware, each node has an ultra-simple communication
   2.113 
   2.114 - * processor -- like an 8 bit control data-path and a physical-addr-width
   2.115 
   2.116 - * addr-data-path (simple -- only power-of-2 shift, add, and maybe mask).
   2.117 
   2.118 - *The acquire-instruction parameters are placed into a data
   2.119 
   2.120 - * structure and only the pointer to them is in a register.  The CPU performs
   2.121 
   2.122 - * a write of the ptr to a particular physical addr, which the comm hardware
   2.123 
   2.124 - * catches and queues.  The comm-processor is driven by the queue -- stalls
   2.125 
   2.126 - * when queue is empty -- returns after finishes to get next from queue.
   2.127 
   2.128 - *Firmware in the comm-processor then fetches the params out of the data
   2.129 
   2.130 - * structure and starts the communication.  The comm involves the
   2.131 
   2.132 - * BIU, which is asked to grant acquire on the frame. BIU sends back
   2.133 
   2.134 - * the node that currently has the frame, or else main-mem physical address
   2.135 
   2.136 - * range.
   2.137 
   2.138 - *When comm is complete, the comm processor performs list-element removal,
   2.139 
   2.140 - * recycling, and pointer movement.
   2.141 
   2.142 - *End Background on acquire
   2.143 
   2.144 - *
   2.145 
   2.146 - *So, the HWInstr_acquire() is the hardware instruction called by the
   2.147 
   2.148 - * GuestSystemCode. This instruction's job is to perform the communication
   2.149 
   2.150 - * protocol that gets data from wherever it is and brings it onto the TNode
   2.151 
   2.152 - * executing this instr.
   2.153 
   2.154 - *In the simulator, this happens in a separate time-line than the CPU, which
   2.155 
   2.156 - * is animating another virtual TNode while the communication happens.
   2.157 
   2.158 - *There may be several acquires started while one is in progress.  But not
   2.159 
   2.160 - * going to model queueing of them.  This time-line treats them as
   2.161 
   2.162 - * zero width.  They each start a new span, but the span ends and reports
   2.163 
   2.164 - * its end-time as the same as its start time, then starts the idle-span.
   2.165 
   2.166 - *
   2.167 
   2.168 - *HWInstr_acquire:   CPU TimeLine
   2.169 
   2.170 - * when executes on the CPU TimeLine, sends a communication to the
   2.171 
   2.172 - * Communicator TimeLine, which equals inserting an acquire-start span into
   2.173 
   2.174 - * the consistent-time trigger-priority-queue that's driven by the TNode's
   2.175 
   2.176 - * ConsistentTime.  It will stop ConsistentTime advancement at its target
   2.177 
   2.178 - * arrival time, ending the Idle-span and starting the acquire-start span.
   2.179 
   2.180 - *
   2.181 
   2.182 - *Acquire-start:  requesting TNode's Communicator TimeLine
   2.183 
   2.184 - * this span looks inside the data-struct to find the Frame start addr.  It
   2.185 
   2.186 - * looks this up in a hash table to see which TNode owns the Frame.  If none,
   2.187 
   2.188 - * means hasn't been allocated yet, so puts acquire-info into the wait-queue
   2.189 
   2.190 - * that's in the hash entry.
   2.191 
   2.192 - *
   2.193 
   2.194 - *Acquire-send: Dwelling TNode's Communicator TimeLine
   2.195 
   2.196 - * When advancement of ConsistentTime stopped by the acquire-send reception,
   2.197 
   2.198 - * check to see
   2.199 
   2.200 - * if the desired Frame is still owned (hash table keyed by Frame start
   2.201 
   2.202 - * addr).  If desired Frame is owned, places the data of the request into
   2.203 
   2.204 - * the queue of waiting acquires that's in the hash-entry.
   2.205 
   2.206 - * If no longer owned, then set new Dwelling TNode to be requester and
   2.207 
   2.208 - * place Acquire-receive into waiting-comm queue of requesting TNode
   2.209 
   2.210 - * TimeDomain.
   2.211 
   2.212 - *
   2.213 
   2.214 - *Release: CPUTimeLine of Owning TNode
   2.215 
   2.216 - * put Release into Communicator TimeLine, with the Frame start addr in it
   2.217 
   2.218 - *
   2.219 
   2.220 - *Release: Communicator TimeLine of Owning TNode
   2.221 
   2.222 - * look up the hash entry for released Frame, set to Not Owned.  If waitQ
   2.223 
   2.224 - * in the Frame's hash entry is not empty, take next entry, set as Owner of
   2.225 
   2.226 - * the Frame, and as new Dwelling TNode, then place Acquire-receive into
   2.227 
   2.228 - * waiting-comm queue of requesting TNode-TimeDomain.
   2.229 
   2.230 - *
   2.231 
   2.232 - *Acquire-receive: Communicator TimeLine of requesting TNode
   2.233 
   2.234 - * When advancement of ConsistentTime stopped by the acquire-receive
   2.235 
   2.236 - * reception, run the Firmware that sets the shared state, so that the CPU
   2.237 
   2.238 - * TimeLine will see the acquire is complete -- also do the data-structure
   2.239 
   2.240 - * rearrangement stuff.  Finally, do the thing of checking if all VTNodes
   2.241 
   2.242 - * are suspended waiting for acquires -- if so, the receive will have to be
   2.243 
   2.244 - * pro-active in restarting the CPU TimeLine, kicking it out of the
   2.245 
   2.246 - * LightSleep span. THIS SPECIAL SPAN IS KEY BENEFIT OF HW SUPPORT FOR VMS --
   2.247 
   2.248 - * can put hardware into light sleep mode when nothing to do -- power/energy
   2.249 
   2.250 - * saver.
   2.251 
   2.252 - * 
   2.253 
   2.254 - *
   2.255 
   2.256 - *So, a time-line is the virtual processor itself.  It animates the
   2.257 
   2.258 - * "current span" as the top-level function.  That span executes span-end,
   2.259 
   2.260 - * the next span's function replaces the old one as the top-level function.
   2.261 
   2.262 - * The stack is also reset, and the parameters for the new span are placed
   2.263 
   2.264 - * on the stack, and the pointer to the span's function is set as the resume-
   2.265 
   2.266 - * ptr.  When the time-line VP is resumed, it's equivalent to that span's
   2.267 
   2.268 - * function being called.
   2.269 
   2.270 - *The time-line VP has app-specific data that says whether the current-span
   2.271 
   2.272 - * is the Idle span, and the simulated-time of the last span-end.
   2.273 
   2.274 - *
   2.275 
   2.276 - *So, rather than having a single top-level functin, a timeLine VP has many,
   2.277 
   2.278 - * a different TLF for each kind of span.
   2.279 
   2.280 - *
   2.281 
   2.282 - *This file holds all the spans == TLFs for the comm-procr TimeLine.
   2.283 
   2.284 - */
   2.285 
   2.286 -
   2.287 
   2.288 -
   2.289 
   2.290 -//===========================================================================
   2.291 
   2.292 -/*
   2.293 
   2.294 - *Acquire-start:  requesting TNode's Communicator TimeLine
   2.295 
   2.296 - * this span looks inside the data-struct to find the Frame start addr.  It
   2.297 
   2.298 - * looks this up in a hash table to see which TNode owns the Frame.  If none,
   2.299 
   2.300 - * means hasn't been allocated yet, so puts acquire-info into the wait-queue
   2.301 
   2.302 - * that's in the hash entry.
   2.303 
   2.304 - *Q: want to put global data-structs into HWSim, with some protection
   2.305 
   2.306 - *  mechanism (like the transactions have already implemented), or want to
   2.307 
   2.308 - *  make general request-handler extension thingie?  Request-handler
   2.309 
   2.310 - *  extensions would be done by registering a handler function during
   2.311 
   2.312 - *  architecture-definition code.
   2.313 
   2.314 - *A: transactions awkward..  make all state be either contained in the
   2.315 
   2.316 - *  TimeLine, or else global.  If in TimeLine, has to be allocated during
   2.317 
   2.318 - *  architecture definition, and if global, has to be declared, and a
   2.319 
   2.320 - *  pointer to the functions that access it, along with an ID for that kind
   2.321 
   2.322 - *  of access is registered.  Then, in the span-code, call
   2.323 
   2.324 - *  HWSim__access_global_var( params, ACCESSID )  the ACCESSID determines
   2.325 
   2.326 - *  which function-pointer is called, and the function code determines
   2.327 
   2.328 - *  which global var is accessed, and the params hold all the data the
   2.329 
   2.330 - *  function needs to do whatever is to be done.
   2.331 
   2.332 - */
   2.333 
   2.334 -void
   2.335 
   2.336 -commSpan_acquire_start( void *_params, VirtProcr *animTimeLine )
   2.337 
   2.338 - { 
   2.339 
   2.340 -   AcquireParams  *params;
   2.341 
   2.342 -
   2.343 
   2.344 -   params    = (AcquireParams *)_params;
   2.345 
   2.346 -
   2.347 
   2.348 -         DEBUG( dbgAppFlow, "acquire_start\n", cloneAcquireParams( params ));
   2.349 
   2.350 -
   2.351 
   2.352 -      //invoke global-var-accessor to get the TNode owns the Frame
   2.353 
   2.354 -   residingTNode =
   2.355 
   2.356 -      HWSim__access_global_var( params, GET_OWNING_TNODE, animTimeLine );
   2.357 
   2.358 -
   2.359 
   2.360 -      //send a communication to that TNode's Communicator
   2.361 
   2.362 -   targetTL = residingTNode->communicatorTL;
   2.363 
   2.364 -
   2.365 
   2.366 -      //params are: amount of simulated time the communication takes,
   2.367 
   2.368 -      // the TimeLine receiving, the span-function to run when consistent-
   2.369 
   2.370 -      // time reaches the reception time, params for that span, and animTL
   2.371 
   2.372 -   HWSim__send_comm( calcNetworkTime(), targetTL, targetTL->sendAcquireSpan,
   2.373 
   2.374 -                     params, animTimeLine );
   2.375 
   2.376 -
   2.377 
   2.378 -   duration = 0; //starting an acquire modeled as taking zero time
   2.379 
   2.380 -
   2.381 
   2.382 -      //every span function ends with this call -- duration of this span,
   2.383 
   2.384 -      // pointer to next span-function to run, params for it, and animTL
   2.385 
   2.386 -   HWSim__transition_to_new_span( duration, IDLE_SPAN, NULL, animTimeLine );
   2.387 
   2.388 - }
   2.389 
   2.390 -
   2.391 
   2.392 -
   2.393 
   2.394 -/*Acquire-send: Dwelling TNode's Communicator TimeLine
   2.395 
   2.396 - * Runs when advancement of ConsistentTime stopped by the acquire-send
   2.397 
   2.398 - * reception.  Check to see
   2.399 
   2.400 - * if the desired Frame is still owned (hash table keyed by Frame start
   2.401 
   2.402 - * addr).  If desired Frame is owned, place the data of the request into
   2.403 
   2.404 - * the queue of waiting acquires that's in the hash-entry.
   2.405 
   2.406 - * If already released, then set new Dwelling TNode to be requester and
   2.407 
   2.408 - * do an Acquire-receive back to the requesting TNode, which has the effect
   2.409 
   2.410 - * of placing an acquire-receive span to wait in its consistent-time-arrest
   2.411 
   2.412 - * queue.
   2.413 
   2.414 - *The release span will take waiting requests out of the waiting-acquires Q
   2.415 
   2.416 - */
   2.417 
   2.418 -void
   2.419 
   2.420 -commSpan_acquire_send( void *_params, VirtProcr *animTimeLine )
   2.421 
   2.422 - {
   2.423 
   2.424 -   AcquireParams  *params;
   2.425 
   2.426 -
   2.427 
   2.428 -   params    = (AcquireParams *)_params;
   2.429 
   2.430 -
   2.431 
   2.432 -         DEBUG( dbgAppFlow, "acquire_send\n", cloneAcquireParams( params ));
   2.433 
   2.434 -
   2.435 
   2.436 -
   2.437 
   2.438 -      //invoke global-var-accessor to lookup hash entry and see if Frame is
   2.439 
   2.440 -      // still owned, and if so, add this acquire to queue of waiting ones.
   2.441 
   2.442 -      // note, this is non-physical behavior -- any use of global vars is
   2.443 
   2.444 -      // non-physical.  To make this function physical, implement a TimeLine
   2.445 
   2.446 -      // that holds the hash table and all other TimeLines communicate to.
   2.447 
   2.448 -      //Caveat there is that collisions can happen unless also impl protocol.
   2.449 
   2.450 -      // So leave that for later improvement.
   2.451 
   2.452 -   notCurrentlyOwned =
   2.453 
   2.454 -      HWSim__access_global_var( params, DO_ACQUIRE_SEND, animTimeLine );
   2.455 
   2.456 -
   2.457 
   2.458 -   if( notCurrentlyOwned )
   2.459 
   2.460 -    {
   2.461 
   2.462 -         //send a communication to requesting TNode's Communicator
   2.463 
   2.464 -      targetTL = params->requestingTNode->communicatorTL;
   2.465 
   2.466 -
   2.467 
   2.468 -         //params are: amount of simulated time the communication takes,
   2.469 
   2.470 -         // the TimeLine receiving, the span-function to run when consistent-
   2.471 
   2.472 -         // time reaches the reception time, params for that span, and animTL
   2.473 
   2.474 -      HWSim__send_comm( calcNetworkTime(), targetTL, COMM_INPORT,
   2.475 
   2.476 -                        &commSpan_acquire_receive, params, animTimeLine );
   2.477 
   2.478 -    }
   2.479 
   2.480 -   
   2.481 
   2.482 -   HWSim__transition_to_new_span( IDLE_SPAN, NULL, animTimeLine );
   2.483 
   2.484 - }
   2.485 
   2.486 -
   2.487 
   2.488 -
   2.489 
   2.490 -/*Acquire-receive: Communicator TimeLine of requesting TNode
   2.491 
   2.492 - * When advancement of ConsistentTime stopped by the acquire-receive
   2.493 
   2.494 - * reception, run the "Firmware" that sets the shared state, so that the CPU
   2.495 
   2.496 - * TimeLine will see the acquire is complete -- also do the data-structure
   2.497 
   2.498 - * rearrangement stuff.  Finally, do the thing of checking if all VTNodes
   2.499 
   2.500 - * are suspended waiting for acquires -- if so, the receive will have to be
   2.501 
   2.502 - * pro-active in restarting the CPU TimeLine, kicking it out of the
   2.503 
   2.504 - * LightSleep span. THIS SPECIAL SPAN IS KEY BENEFIT OF HW SUPPORT FOR VMS --
   2.505 
   2.506 - * can put hardware into light sleep mode when nothing to do -- power/energy
   2.507 
   2.508 - * saver.
   2.509 
   2.510 - */
   2.511 
   2.512 -void
   2.513 
   2.514 -commSpan_acquire_receive( void *_params, VirtProcr *animTimeLine )
   2.515 
   2.516 - {
   2.517 
   2.518 -   AcquireParams  *params;
   2.519 
   2.520 -
   2.521 
   2.522 -   params    = (AcquireParams *)_params;
   2.523 
   2.524 -
   2.525 
   2.526 -         DEBUG( dbgAppFlow, "acquire_receive\n", cloneAcquireParams(params));
   2.527 
   2.528 -
   2.529 
   2.530 -
   2.531 
   2.532 -   HWSim__transition_to_new_span( IDLE_SPAN, NULL, animTimeLine );
   2.533 
   2.534 - }
   2.535 
   2.536 -
   2.537 
   2.538 -
   2.539 
   2.540 -/*Release: Communicator TimeLine of Owning TNode
   2.541 
   2.542 - * look up the hash entry for released Frame, set to Not Owned.  If waitQ
   2.543 
   2.544 - * in the Frame's hash entry is not empty, take next entry, set as Owner of
   2.545 
   2.546 - * the Frame, and as new Dwelling TNode, then place Acquire-receive into
   2.547 
   2.548 - * waiting-comm queue of requesting TNode-TimeDomain.
   2.549 
   2.550 - */
   2.551 
   2.552 -void
   2.553 
   2.554 -commSpan_release( void *_params, VirtProcr *animTimeLine )
   2.555 
   2.556 - {
   2.557 
   2.558 -   AcquireParams  *params;
   2.559 
   2.560 -
   2.561 
   2.562 -   params    = (AcquireParams *)_params;
   2.563 
   2.564 -
   2.565 
   2.566 -         DEBUG( dbgAppFlow, "acquire_start\n", cloneAcquireParams( params ));
   2.567 
   2.568 -
   2.569 
   2.570 -
   2.571 
   2.572 -   HWSim__transition_to_new_span( IDLE_SPAN, NULL, animTimeLine );
   2.573 
   2.574 - }
   2.575 
   2.576 -
   2.577 
   2.578 -/*At reset only starts the Idle span in the communicator.
   2.579 
   2.580 - */
   2.581 
   2.582 -void
   2.583 
   2.584 -commSpan_at_reset( void *_params, VirtProcr *animTimeLine )
   2.585 
   2.586 - {
   2.587 
   2.588 -
   2.589 
   2.590 -         DEBUG( dbgAppFlow, "commSpan at_reset\n", NULL );
   2.591 
   2.592 -         
   2.593 
   2.594 -   HWSim__transition_to_new_span( IDLE_SPAN, NULL, animTimeLine );
   2.595 
   2.596 - }
   2.597 

     3.1 --- a/src/Application/HWSim__Hello_World_HW/DESIGN_NOTES.txt	Mon Nov 07 16:03:01 2011 -0800
     3.2 +++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
     3.3 @@ -1,369 +0,0 @@
     3.4 -
     3.5 
     3.6 -
     3.7 
     3.8 -TeraFlux Hardware Model  (impl of this model in terms of HWSim is below)
     3.9 
    3.10 -
    3.11 
    3.12 -As of Feb 2011, the hardware being simulated is:
    3.13 
    3.14 -
    3.15 
    3.16 -A number of TNodes on a chip, which are connected by a network, with a
    3.17 
    3.18 - main-memory.
    3.19 
    3.20 -
    3.21 
    3.22 -The address space is divided into a local address-space and a shared
    3.23 
    3.24 - address-space.  Both address spaces are divided among the TNodes -- each
    3.25 
    3.26 - has its own unique range of local virtual addresses and own range of
    3.27 
    3.28 - global virtual addresses.  A given TNode may only allocate virtual
    3.29 
    3.30 - addresses within its own two ranges.  The contents of *local* addresses it
    3.31 
    3.32 - allocates may only ever be seen by the allocating TNode.  The contents of
    3.33 
    3.34 - shared addresses may be seen by any TNode after executing an acquire
    3.35 
    3.36 - hardware instruction and being granted the contents.
    3.37 
    3.38 -
    3.39 
    3.40 -Each TNode has a single CPU core, a local memory, and a
    3.41 
    3.42 - communication processor with its own network hardware.
    3.43 
    3.44 -
    3.45 
    3.46 -The local memory size is not modelled, so is considered unlimited.
    3.47 
    3.48 -The network has undefined topology and is modelled as having constant latency
    3.49 
    3.50 - from any TNode to any other TNode, with a fixed BW between any two TNodes.
    3.51 
    3.52 -
    3.53 
    3.54 -The only modelled communication is movement of data, which can only be
    3.55 
    3.56 - triggered by the "acquire" hardware instruction.
    3.57 
    3.58 -
    3.59 
    3.60 -The behavior of acquire is defined as:
    3.61 
    3.62 --] Only one TNode at a time owns a given shared-memory "Frame", which has a
    3.63 
    3.64 -   start address and a size.
    3.65 
    3.66 --] A given shared virtual address is in at most one Frame for the duration
    3.67 
    3.68 -   of a program run (IE, no overlap of Frames, implying no change of size).
    3.69 
    3.70 --] The hardware mechanism by which single-ownership is enforced is not
    3.71 
    3.72 -   modelled.  Control communication is considered infinitely fast.
    3.73 
    3.74 --] The simulated time between a given TNode's CPU executing the acquire
    3.75 
    3.76 -   instruction and the simulated time the data of the Frame appears in the
    3.77 
    3.78 -   local memory of that TNode is determined by both a queue of waiting
    3.79 
    3.80 -   acquire requests and the network time required to move the data.
    3.81 
    3.82 -
    3.83 
    3.84 -The CPU in a TNode executes the standard x86 instruction set.
    3.85 
    3.86 -
    3.87 
    3.88 -The communication processor performs the acquire instruction and the 
    3.89 
    3.90 - release instruction.  The exact hardware mechanism by which these
    3.91 
    3.92 - instructions get from the instruction stream fetched by the CPU to the
    3.93 
    3.94 - communication processor is not defined.
    3.95 
    3.96 -
    3.97 
    3.98 -As an aside.  For simulation, the acquire and release instruction  are
    3.99 
   3.100 - implemented in the lightweight simulator as library-calls that trigger
   3.101 
   3.102 - the simulation infrastructure. In the application they are stated as
   3.103 
   3.104 - macro-calls.  These macros can then be defined in the tool-chain.
   3.105 
   3.106 -When the COTSon simulator is targeted, the
   3.107 
   3.108 - macro is implemented as an in-line assembly custom op-code.  When the
   3.109 
   3.110 - lightweight simulator is targeted, the macro is implemented as a call to
   3.111 
   3.112 - a library, which invokes the acquire or release functionality in the
   3.113 
   3.114 - lightweight simulator.
   3.115 
   3.116 -
   3.117 
   3.118 -The effect of transferring data between TNode local memory and the chip's
   3.119 
   3.120 - main memory is not modelled.
   3.121 
   3.122 -
   3.123 
   3.124 -The portions of the hardware left undefined or not modelled may all be
   3.125 
   3.126 - filled-in in future versions, according to research needs.
   3.127 
   3.128 -
   3.129 
   3.130 -
   3.131 
   3.132 -=============================================================================
   3.133 
   3.134 -Implementing the hardware model in terms of HWSim
   3.135 
   3.136 -
   3.137 
   3.138 -HWSim is used to implement the TeraFlux hardware model for simulation.
   3.139 
   3.140 -
   3.141 
   3.142 -The implementation consists of four elements:
   3.143 
   3.144 -1) A CPU TimeLine, which executes the Guest code
   3.145 
   3.146 -2) A Communicator TimeLine, which performs all inter-node communication
   3.147 
   3.148 -3) A TNode TimeDomain, which has one CPU TimeLine and one Communicator
   3.149 
   3.150 -   TimeLine in it
   3.151 
   3.152 -4) A Chip TimeDomain, which has a number of TNode TimeDomains in it.
   3.153 
   3.154 -
   3.155 
   3.156 -For the first version, there is no local memory element in a TNode, there is
   3.157 
   3.158 - no Main Memory node, and there is no address translation mechanism modelled.
   3.159 
   3.160 - These may be added later, and so might a TSU mechanism, and experimental
   3.161 
   3.162 - alternative memory models.
   3.163 
   3.164 -
   3.165 
   3.166 -The CPU TimeLine has as spans:
   3.167 
   3.168 --] at_reset -- standard span that runs when the hardware is reset.  Runs the
   3.169 
   3.170 -   TeraFlux System Code bootstrap function.
   3.171 
   3.172 --] guestCode span -- runs whatever Guest code is pointed to.. each span of
   3.173 
   3.174 -   this type is created with a pointer to code to run
   3.175 
   3.176 --] lightSleep -- implemented as the built-in IDLE span.  When no virtual
   3.177 
   3.178 -    nodes are ready to animate, the CPU enters light sleep until the
   3.179 
   3.180 -    Communicator wakes it up
   3.181 
   3.182 -
   3.183 
   3.184 -The CPU TimeLine generates two kinds of communication-spans:
   3.185 
   3.186 -  acquire-start in Communicator
   3.187 
   3.188 -  release in Communicator
   3.189 
   3.190 -
   3.191 
   3.192 -For now, these communications are considered to be performed by dedicated
   3.193 
   3.194 - hardware in the CPU, so they take exactly one simulated instruction, and
   3.195 
   3.196 - their simulated time is thus included in the measured time of the span.  The
   3.197 
   3.198 - HWSim__send_comm takes a time-stamp before suspending the TimeLine, then
   3.199 
   3.200 - another just after resume, and accumulates -- the end-span adds this in.
   3.201 
   3.202 -
   3.203 
   3.204 -  All TimeLines begin by running the at_reset span defined for that TimeLine.
   3.205 
   3.206 -  The CPU's at_reset is hard-coded to start a GuestCode span that runs the
   3.207 
   3.208 -  TeraFlux System Code's boot sequence.
   3.209 
   3.210 -
   3.211 
   3.212 -The Communicator TimeLine has a number of spans, all related to acquire and
   3.213 
   3.214 -  release:
   3.215 
   3.216 --] acquire-start -- is triggered by the reception of a "start-acquire"
   3.217 
   3.218 -   communication from the CPU TimeLine. It generates an "acquire send"
   3.219 
   3.220 -   communication to the TNode that currently owns the data.
   3.221 
   3.222 --] acquire-send -- when triggered, checks if the Frame is free.  If yes,
   3.223 
   3.224 -   sends an "acquire-receive" communication back to the requester.  If not
   3.225 
   3.226 -   free, places data representing the acquire-request into a queue of waiting
   3.227 
   3.228 -   ones in the Communicator TimeLine.  When the Communicator receives a
   3.229 
   3.230 -   "release" communication from the CPU TimeLine, it runs the release span.
   3.231 
   3.232 --] release -- takes the data of the next request waiting for the released
   3.233 
   3.234 -   Frame out of the queue and then sends an "acquire-receive" communication
   3.235 
   3.236 -   to the TNode requesting.
   3.237 
   3.238 --] acquire-receive -- when triggered, runs firmware, which writes memory
   3.239 
   3.240 -   shared with the CPU, modifying data-structures.  This firmware for
   3.241 
   3.242 -   TeraFlux works with the System Code that runs on the CPU TimeLine to
   3.243 
   3.244 -   notify it that the acquire is complete.
   3.245 
   3.246 -
   3.247 
   3.248 -Note, nothing checks whether a Frame's addresses are accessed from outside an
   3.249 
   3.250 - Acquire-Release block, which could be a source of difficult to find bugs in
   3.251 
   3.252 - the application.
   3.253 
   3.254 -
   3.255 
   3.256 -
   3.257 
   3.258 -=============================================================================
   3.259 
   3.260 -Earlier versions of notes:
   3.261 
   3.262 -
   3.263 
   3.264 -A time-line is a virtual-processor, and has a sequence of spans -- each
   3.265 
   3.266 - span performs one hardware-function, and has a start-time and an end-time
   3.267 
   3.268 - -- those are simulated-time, not physical time.
   3.269 
   3.270 -
   3.271 
   3.272 -Each time-line is created with a start-span that initializes it, then every
   3.273 
   3.274 - span ends with an "end span" sem-lib call.
   3.275 
   3.276 -
   3.277 
   3.278 -There are three kinds of span -- fixed-function spans, which represent
   3.279 
   3.280 - hard-wired hardware behavior, processing-core spans, which represent
   3.281 
   3.282 - processing elements that execute code, and communication-spans, which
   3.283 
   3.284 - cross time-lines.
   3.285 
   3.286 -
   3.287 
   3.288 -a fixed-function span has a fixed function-pointer that it is created with
   3.289 
   3.290 - and jumps to when the time-line is resumed.  Fixed-function spans also have
   3.291 
   3.292 - a pointer to a function that calculates the width of the span.  The
   3.293 
   3.294 - width-caluclating span is defined in the application directory.
   3.295 
   3.296 -
   3.297 
   3.298 -a processing-core span has a function-pointer that is assigned to it by the
   3.299 
   3.300 - end-span call of the preceeding span.  The width is also determined by a
   3.301 
   3.302 - pointer to a width-calculating function.  The width-calculating function
   3.303 
   3.304 - for these spans is also defined in the application directory (In first
   3.305 
   3.306 - teraflux impl, this function uses RDTSC to measure physical execution time,
   3.307 
   3.308 - and makes that the simulated execution time too -- but with a "BS" detector
   3.309 
   3.310 - that sees when the time is significantly larger than the previous
   3.311 
   3.312 - invocation of the same function-pointer).
   3.313 
   3.314 -
   3.315 
   3.316 -Communication spans are special because they cross time-lines.  So, a
   3.317 
   3.318 - communication span has zero width in the time-line it's created in, and
   3.319 
   3.320 - goes onto the queue as a new span in the target time-line (which also has
   3.321 
   3.322 - zero-width).  When the target span runs, it changes the state available to
   3.323 
   3.324 - the target time-line, to represent the reception of the communication.
   3.325 
   3.326 -
   3.327 
   3.328 -=============================
   3.329 
   3.330 -Span-end is the only semantic-library call implemented.  Inside the
   3.331 
   3.332 - request-handler, it causes new spans to be created.
   3.333 
   3.334 -
   3.335 
   3.336 -So, have to have a separate receive time-line, that modifies hardware shared
   3.337 
   3.338 - with other time-lines.  The send span causes a receive-span to be inserted
   3.339 
   3.340 - into the target receive time-line.  
   3.341 
   3.342 -
   3.343 
   3.344 -Receive-spans are zero-width -- they update the hardware-state atomically,
   3.345 
   3.346 - so don't have to worry about conflicts between different receive spans in
   3.347 
   3.348 - the simulator.  The hardware-application that uses the simulator-library
   3.349 
   3.350 - must model the receive hardware and implement the send-hardware function
   3.351 
   3.352 - to work out any physical conflicts among receives targeted to the same
   3.353 
   3.354 - receive time-line.
   3.355 
   3.356 -
   3.357 
   3.358 -
   3.359 
   3.360 -=============================
   3.361 
   3.362 -
   3.363 
   3.364 -Time-lines are specialized to specific hardware functions inside the
   3.365 
   3.366 - Application directory -- that's where the main creates all the time-lines,
   3.367 
   3.368 - and where the spans are implemented that have the behavior of a given type
   3.369 
   3.370 - of time-line.
   3.371 
   3.372 -
   3.373 
   3.374 -For example, if the hardware is a communication-unit, then span-types are
   3.375 
   3.376 - created that have the behavior that does all the setup of a communication
   3.377 
   3.378 - span and then does an end-span that creates as its follow-on the
   3.379 
   3.380 - communication-span.
   3.381 
   3.382 -
   3.383 
   3.384 -Communication spans are special because they cross time-lines.  So, a
   3.385 
   3.386 - communication span has zero width in the time-line it's created in, and
   3.387 
   3.388 - goes onto the queue in the target time-line, where it creates a new span
   3.389 
   3.390 - that also has zero-width.  The target span's function updates the hardware
   3.391 
   3.392 - state available to the target time-line, which may be shared with other
   3.393 
   3.394 - time-lines and that update may cause new spans to be spawned in those.
   3.395 
   3.396 -
   3.397 
   3.398 -if the hardware is a processing-core, then the function points to
   3.399 
   3.400 - Guest-application-code.  This function-pointer is what core_loop jumps to
   3.401 
   3.402 - when it reanimates the time-line virtual processor.
   3.403 
   3.404 -
   3.405 
   3.406 -================  Albert e-mail =================
   3.407 
   3.408 -
   3.409 
   3.410 -
   3.411 
   3.412 -Hi Albert,
   3.413 
   3.414 -
   3.415 
   3.416 -   the simulator is a thing of beauty.  I'm getting goose bumps as I put the
   3.417 
   3.418 - last pieces of the design into place.  It's a sweet thing.
   3.419 
   3.420 -
   3.421 
   3.422 -Just in case you're curious, attached are my design notes <this file>.  The
   3.423 
   3.424 - thing that makes it nice is the clean decomposition and reusability -- the
   3.425 
   3.426 - core simulator only has three things: time-lines, spans, and a
   3.427 
   3.428 - priority-queue with an associated "certain-time" or "consistent-time".
   3.429 
   3.430 -
   3.431 
   3.432 -   A time-line is a VMS virtual-processor, which executes a sequence of
   3.433 
   3.434 - spans.  Each span has a function that represents the behavior performed
   3.435 
   3.436 - during that span, plus a function that calculates the simulated-time width
   3.437 
   3.438 - of that span.  The certain-time represents the advancement of global
   3.439 
   3.440 - simulated-time.  At all points in physical time during the simulation, it
   3.441 
   3.442 - is guaranteed that no spans are waiting to execute that have a
   3.443 
   3.444 - simulated-time older than the certain-time.
   3.445 
   3.446 -   In other words, at any physical moment, there are lots of spans sitting
   3.447 
   3.448 - in queues waiting to run.  So, a given time-line finishes a span at a given
   3.449 
   3.450 - simulated-time point in global simulated-time.  But there may be spans from
   3.451 
   3.452 - other time-lines in the queue that finish at a preceeding simulated-time.
   3.453 
   3.454 - But there can never be any waiting spans that finish before the
   3.455 
   3.456 - certain-time.  This is important for communications, which cross
   3.457 
   3.458 - time-lines.
   3.459 
   3.460 -
   3.461 
   3.462 -
   3.463 
   3.464 -   Time-lines, spans, and certain-time are implemented in a semantic-library.
   3.465 
   3.466 -
   3.467 
   3.468 -This is, in essence a new parallel language for writing hardware-simulators
   3.469 
   3.470 - with.  (this just turns out to be the most natural and most simple way to
   3.471 
   3.472 - write the TeraFlux simulator)
   3.473 
   3.474 -
   3.475 
   3.476 -The behavior of particular hardware is defined as a simulator-application
   3.477 
   3.478 - that makes calls to that semantic-library.
   3.479 
   3.480 -
   3.481 
   3.482 -The main of that simulator-application creates the pieces of the hardware
   3.483 
   3.484 - -- for Teraflux, that means it creates the nodes, and the pieces inside
   3.485 
   3.486 - each node.
   3.487 
   3.488 -
   3.489 
   3.490 -Running this simulator-application equals turning on the power-switch of
   3.491 
   3.492 - the Guest hardware.
   3.493 
   3.494 -
   3.495 
   3.496 -The Guest application code is retrieved by the main of the
   3.497 
   3.498 - simulator-application, and starts running when the "power-switch" is
   3.499 
   3.500 - turned on (running the simulator-application causes the Guest-application
   3.501 
   3.502 - to be retrieved and start running on the hardware created by main).  This
   3.503 
   3.504 - is equivalent to the boot sequence of the BIOS, which happens at power-on.
   3.505 
   3.506 -
   3.507 
   3.508 -So, the end-effect is that full Linux is available to the Guest hardware as
   3.509 
   3.510 - a sort of "escape".  The Guest hardware can use the Host's disk access,
   3.511 
   3.512 - debugging, and everything else, but these usages are "outside" the
   3.513 
   3.514 - simulated time -- they are essentially magic-spells that the Guest
   3.515 
   3.516 - hardware can perform that take place outside of time as far as the Guest
   3.517 
   3.518 - application-code is concerned.  Hence, the main is able to use the Host
   3.519 
   3.520 - Linux to retrieve-from-disk the Guest application (but the disk-access
   3.521 
   3.522 - takes place outside the measurements reported by the simulator).
   3.523 
   3.524 -
   3.525 
   3.526 -Which maybe seems trivial, but I consider it a very cool trick  : )
   3.527 
   3.528 -
   3.529 
   3.530 -The part I like best is the fact that the simulator itself is such a simple
   3.531 
   3.532 - semantic-library, and the behavior of the hardware is written all as
   3.533 
   3.534 - sequential code.  This makes it easily customizable to any architecture
   3.535 
   3.536 - someone might want to investigate, and still run on parallel hardware  : D
   3.537 
   3.538 -
   3.539 
   3.540 -The only caveat is the thing I noted in earlier e-mails about communication
   3.541 
   3.542 - updates -- memory images and other hardware state  atomically  update at
   3.543 
   3.544 - the ends of spans.  So, Guest-code-execution that overlaps the
   3.545 
   3.546 - simulated-time at which reception happens, on a node, will not see that
   3.547 
   3.548 - reception until the end of the span.
   3.549 
   3.550 -   For TeraFlux hardware, the only natural span-endings are acquire
   3.551 
   3.552 - instructions and release instructions.
   3.553 
   3.554 -   What this means for you is that you may want to insert artificial
   3.555 
   3.556 - end-span calls into the Guest application code you generate (I'll provide
   3.557 
   3.558 - a "dummy" call).  Communication-receptions on a node will only become
   3.559 
   3.560 - visible to Guest application code after one of these dummy end-span calls.
   3.561 
   3.562 - So, the granularity of time in the simulation is related to the frequency
   3.563 
   3.564 - of end-span calls in the application code.  If you don't insert any
   3.565 
   3.566 - artificial ones, then acquire and release instructions will be the only
   3.567 
   3.568 - span-ending events, and will define the granularity of
   3.569 
   3.570 - communication-receptions being seen by Guest application code.
   3.571 
   3.572 -   In particular, this means that no Guest application code is allowed to
   3.573 
   3.574 - monitor memory to see when it changes -- so, programming techniques that
   3.575 
   3.576 - would work on real hardware, to detect acquire-updates early won't work
   3.577 
   3.578 - in the simulator -- all Guest code to run on the simulator must use the
   3.579 
   3.580 - acquire-library call, which will suspend the virtual-node the code is
   3.581 
   3.582 - running on until the acquire is complete, then re-start that node at some
   3.583 
   3.584 - simulated-time after the acquire completes.
   3.585 
   3.586 -   
   3.587 
   3.588 - 
   3.589 
   3.590 -No idea when something will start running, but the design is getting quite
   3.591 
   3.592 - detailed, so progress is being made,
   3.593 
   3.594 -
   3.595 
   3.596 -Sean
   3.597 
   3.598 -
   3.599 
   3.600 -
   3.601 
   3.602 -=============================================================================
   3.603 
   3.604 - Notes from before figured out how to do ConsistentTime for each TimeDomain
   3.605 
   3.606 - and have a priority-queue of waiting communication receptions for the
   3.607 
   3.608 - TimeDomain.
   3.609 
   3.610 -
   3.611 
   3.612 -This illustrates the tortured logic would have to go through otherwise.
   3.613 
   3.614 - *
   3.615 
   3.616 - * that acquire's release point in
   3.617 
   3.618 - * sumulated is either already known, or not yet known.  If already known,
   3.619 
   3.620 - * then recursively check if another TNode has already been granted acquire,
   3.621 
   3.622 - * until reach the end of the chain. If the end is already known without any
   3.623 
   3.624 - * other acquires, then set state that this TNode gets the acquire at the
   3.625 
   3.626 - * release-time of the last in the chain.  This acquire will have an unknown
   3.627 
   3.628 - * release time.
   3.629 
   3.630 - *If the release time of the end of the chain is unknown, then put the
   3.631 
   3.632 - * requesting acquire into a queue of acquires waiting for that Frame. When
   3.633 
   3.634 - * the release happens, it will check if any acquires are in the queue for
   3.635 
   3.636 - * the released Frame.  If so, it will do the same as is done when the end
   3.637 
   3.638 - * of a chain is known -- set the Frame's state to acquired, with release-
   3.639 
   3.640 - * time as the start-time of the new acquire-grant, and unknown end-time.
   3.641 
   3.642 - *
   3.643 
   3.644 - *When a HWInstr_release() is executed, it has a simulated-time at which the
   3.645 
   3.646 - * span starts -- the span will also have zero width and start the idle span
   3.647 
   3.648 - * when it ends, just like the acquire-start span, and the triggered
   3.649 
   3.650 - * spans.
   3.651 
   3.652 - *
   3.653 
   3.654 - *The release span will check the wait queue for the Frame it is releasing,
   3.655 
   3.656 - * and either mark the Frame as free, or else fire off the grant-acquire
   3.657 
   3.658 - * function for the first waiting acquire.
   3.659 
   3.660 - *
   3.661 
   3.662 - *The grant-acquire function checks the ConsistentTime, and if the
   3.663 
   3.664 - * simulated time of the grant preceeds the ConsistentTime, then the
   3.665 
   3.666 - * acquire is put into the readyQ as an acquire-send span in the comm
   3.667 
   3.668 - * TimeLine of the TNode that owns the acquired data, or else the MainMem
   3.669 
   3.670 - * Node.
   3.671 
   3.672 - *
   3.673 
   3.674 - *The comm TimeLine that executes an acquire-send creates a comm span between
   3.675 
   3.676 - * the sending TNode or MMNode and the receiving TNode.  The width of the
   3.677 
   3.678 - * span is set by hardware model.  This will be a parameter for experiments.
   3.679 
   3.680 - * It's the main phenomenon affecting performance and scalability.  A fixed
   3.681 
   3.682 - * latency plus Frame-size / fixed-BW to start.
   3.683 
   3.684 - *
   3.685 
   3.686 - *An acquire can only be granted when the Consistent time reaches the
   3.687 
   3.688 - * Release-time of the previous acquire.  That's when know for certain that
   3.689 
   3.690 - * the memory image being acquired is correct, and the acquire order is
   3.691 
   3.692 - * correct (all acquires that want a given Frame will have been queued up
   3.693 
   3.694 - * for that Frame, so can't grant to one, in Host time, then a different
   3.695 
   3.696 - * acquire arrives that SHOULD have been the one given the grant).
   3.697 
   3.698 - *Each Frame has a priority-queue of acquires waiting for it, ordered by the
   3.699 
   3.700 - * simulated time the acquire-request was made.
   3.701 
   3.702 - *When ConsistentTime advances past the last Release of a Frame, then check
   3.703 
   3.704 - * the priority queue of waiting acquires -- if the top is older than the
   3.705 
   3.706 - * ConsistentTime, then grant to that one -- otherwise, move the acquire to
   3.707 
   3.708 - * the TriggerByConsistentTime queue.
   3.709 
   3.710 - *
   3.711 
   3.712 - *Each time ConsistentTime *wants* to advance, check the Trigger priority-
   3.713 
   3.714 - * queue to see if any triggers are older than the proposed new Consistent-
   3.715 
   3.716 - * Time.  If yes, then ConsistentTime is only advanced to that trigger's
   3.717 
   3.718 - * time, and the tigger is performed.
   3.719 
   3.720 - *
   3.721 
   3.722 - *Triggers are spans that have a start-time that depends on actions in other
   3.723 
   3.724 - * time-lines.  So, the span is created in one TimeLine, either ending an
   3.725 
   3.726 - * idle-span, or being queued up to run in that TimeLine's sequence -- all
   3.727 
   3.728 - * dependencies have been satisfied except access to the TimeLine resource.
   3.729 
   3.730 - *
   3.731 
   3.732 - *Each Frame has a hash-entry key'd by the Frame's start-addr.  This entry
   3.733 
   3.734 - * has a priority queue holding acquires waiting for the Frame, sorted
   3.735 
   3.736 - * by sim-time the acquire was executed.
   3.737 
   3.738 -
   3.739 
   3.740 -
   3.741 

     4.1 --- a/src/Application/HWSim__Hello_World_HW/EntryPoint.c	Mon Nov 07 16:03:01 2011 -0800
     4.2 +++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
     4.3 @@ -1,40 +0,0 @@
     4.4 -/*
     4.5 
     4.6 - *  Copyright 2009 OpenSourceStewardshipFoundation.org
     4.7 
     4.8 - *  Licensed under GNU General Public License version 2
     4.9 
    4.10 - *
    4.11 
    4.12 - * Author: seanhalle@yahoo.com
    4.13 
    4.14 - *
    4.15 
    4.16 - */
    4.17 
    4.18 -
    4.19 
    4.20 -#include <math.h>
    4.21 
    4.22 -
    4.23 
    4.24 -#include "HWSim_TeraFlux.h"
    4.25 
    4.26 -
    4.27 
    4.28 -
    4.29 
    4.30 -
    4.31 
    4.32 -/*Every HWSim system has an "entry point" function that creates the first
    4.33 
    4.34 - * virtual processor, which is the seed processor.
    4.35 
    4.36 - *
    4.37 
    4.38 - *The seed processor will construct the system to be simulated.
    4.39 
    4.40 - *The other files in this directory define the components the system is
    4.41 
    4.42 - * constructed from.
    4.43 
    4.44 - *
    4.45 
    4.46 - *
    4.47 
    4.48 - *This entry-point function follows the same pattern as all entry-point
    4.49 
    4.50 - * functions do:
    4.51 
    4.52 - *1) it creates the params for the seed processor, from the
    4.53 
    4.54 - *    parameters passed into the entry-point function
    4.55 
    4.56 - *2) it calls HWSim__create_seed_procr_and_do_work
    4.57 
    4.58 - *3) it gets the return value from the params struc, frees the params struc,
    4.59 
    4.60 - *    and returns the value from the function
    4.61 
    4.62 - *
    4.63 
    4.64 - */
    4.65 
    4.66 -void
    4.67 
    4.68 -runTheSimulation( SimulationParams *simParams )
    4.69 
    4.70 - {
    4.71 
    4.72 -      //create divider processor, start doing the work, and wait till done
    4.73 
    4.74 -      //This function is the "border crossing" between normal code and HWSim
    4.75 
    4.76 -   HWSim__create_seed_procr_and_do_work( &constructAndSimulateSystem,
    4.77 
    4.78 -                                          simParams );
    4.79 
    4.80 -   
    4.81 
    4.82 - }
    4.83 

     5.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     5.2 +++ b/src/Application/HWSim__Hello_World_HW/HWSim__Hello_World_HW.h	Sat Nov 19 17:58:21 2011 -0800
     5.3 @@ -0,0 +1,1 @@
     5.4 +/*
     5.5  *  Copyright 2011 OpenSourceStewardshipFoundation.org
     5.6  *  Licensed under GNU General Public License version 2
     5.7  */
     5.8 
     5.9 
    5.10 #ifndef _HWSim_TERAFLUX_H_
    5.11 #define _HWSim_TERAFLUX_H_
    5.12 
    5.13 #include <stdio.h>
    5.14 
    5.15 #include "../../HWSim_lib/HWSim.h"
    5.16 
    5.17 
    5.18 //===============================  Defines  ==============================
    5.19    //Port 0 is unused, as a bug-catch
    5.20 #define COMMUNICATOR_OUTPORT  1
    5.21 
    5.22 
    5.23 //==============================  Structures  ==============================
    5.24 typedef struct
    5.25  { 
    5.26  }
    5.27 PingPongParams;
    5.28 
    5.29 
    5.30 //============================= Span Functions =========================
    5.31 void *
    5.32 behaviorOf_ping_pong_span( void *_params, VirtProcr *timeLine );
    5.33 
    5.34 uint64
    5.35 timingOf_ping_pong_span( void * dataFromBehaviorFn );
    5.36 
    5.37 
    5.38 #endif /**/
    5.39 
    5.40 \ No newline at end of file

     6.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     6.2 +++ b/src/Application/HWSim__Hello_World_HW/HW_DESIGN_NOTES.txt	Sat Nov 19 17:58:21 2011 -0800
     6.3 @@ -0,0 +1,1 @@
     6.4 +Implementing the hardware model
     6.5 
     6.6 
     6.7 This is the "hello world" for HWSim.  It is hardware that has just two timelines that send a message back and forth between them.  The message has no content, it simply triggers the other timeline, which then sends the same empty message back, repeating the cycle.
     6.8 
     6.9 Each timeline has one in-port and one out-port.  The out-port of the first timeline is connected to the in-port of the second and vice-versa.
    6.10 
    6.11 The code of the span consists only of sending an empty message on the timeline's out-port.
    6.12 
    6.13 The trigger for the span is registered on the in-port and message type 0.
    6.14 
    6.15 The span timing is a constant.
    6.16 
    6.17 The port-to-port timing is a constant.
    6.18 
    6.19 Both timelines are in the same time-domain.
    6.20 
    6.21 at_reset of one timeline is set to the ping-pong span, the other timeline's at_reset is set to idle.
    6.22 
    6.23 And that is the entire hardware.
    6.24 
    6.25 \ No newline at end of file

     7.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     7.2 +++ b/src/Application/HWSim__Hello_World_HW/PingPong_TimeLine.c	Sat Nov 19 17:58:21 2011 -0800
     7.3 @@ -0,0 +1,1 @@
     7.4 +/*
     7.5  *  Copyright 2011 OpenSourceStewardshipFoundation.org
     7.6  *  Licensed under GNU General Public License version 2
     7.7  *
     7.8  * Author: seanhalle@yahoo.com
     7.9  *
    7.10  */
    7.11 
    7.12 #include "HWSim__Hello_World_HW.h"
    7.13 
    7.14 
    7.15 
    7.16 //====================================================================
    7.17 /*This is the ping-pong timeline for the Hello World hardware
    7.18  *
    7.19  *It has only one kind of span, which only puts a communication on
    7.20  * the timeline's one out-port.
    7.21  * 
    7.22  *The in-port has only one trigger registered on it, which fires that
    7.23  * span.
    7.24  */
    7.25 
    7.26 #define NO_MSG NULL
    7.27 #define PORT0 0
    7.28 
    7.29 /*
    7.30  *Note, the returned value is passed to the timing function
    7.31  */
    7.32 void *
    7.33 behaviorOf_ping_pong_span( void *_params, TimeLine *timeline )
    7.34  {
    7.35    PingPongParams  *params;
    7.36    params    = (PingPongParams *)_params;
    7.37          DEBUG( dbgHW, "ping pong span\n", clone_PingPongParams(params) );
    7.38    
    7.39    HWSim__send_on_port( NO_MSG, PORT0, timeline );
    7.40  }
    7.41 
    7.42 uint64
    7.43 timingOf_ping_pong_span( void * dataFromBehaviorFn )
    7.44  {
    7.45    return 10;
    7.46  }
    7.47 \ No newline at end of file

     8.1 --- a/src/Application/HWSim__Hello_World_HW/Seed_VP.c	Mon Nov 07 16:03:01 2011 -0800
     8.2 +++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
     8.3 @@ -1,181 +0,0 @@
     8.4 -/*
     8.5 
     8.6 - *  Copyright 2009 OpenSourceStewardshipFoundation.org
     8.7 
     8.8 - *  Licensed under GNU General Public License version 2
     8.9 
    8.10 - *
    8.11 
    8.12 - * Author: seanhalle@yahoo.com
    8.13 
    8.14 - *
    8.15 
    8.16 - */
    8.17 
    8.18 -
    8.19 
    8.20 -
    8.21 
    8.22 -#include "HWSim_TeraFlux.h"
    8.23 
    8.24 -#include <math.h>
    8.25 
    8.26 -#include <string.h>
    8.27 
    8.28 -
    8.29 
    8.30 -
    8.31 
    8.32 -
    8.33 
    8.34 -//===========================================================================
    8.35 
    8.36 -/*This is the seed processor.
    8.37 
    8.38 - *
    8.39 
    8.40 - *It takes the simulation parameters that were passed in to the entry point
    8.41 
    8.42 - * and uses them to construct the system and start it running.
    8.43 
    8.44 - *
    8.45 
    8.46 - *The way this VP Top-level-function is written is specific to TeraFlux, so
    8.47 
    8.48 - * the system it constructs is specifically a TeraFlux chip.
    8.49 
    8.50 - *
    8.51 
    8.52 - *HWSim, on the other hand, expects to be handed functions that it can call
    8.53 
    8.54 - * itself.  The first function should perform a bunch of
    8.55 
    8.56 - * HWSim__create_TimeLine()  and HWSim__create_TimeDomain()  calls.  The
    8.57 
    8.58 - * second function should connect together the entities created in the first
    8.59 
    8.60 - * function.
    8.61 
    8.62 - *
    8.63 
    8.64 - *So, the job of this seed processor is to construct the parameters those
    8.65 
    8.66 - * two functions will take, and hand them to HWSim with the
    8.67 
    8.68 - * HWSim__run_creation_fn( createFnPtr, createFnParams, animVP)
    8.69 
    8.70 - */
    8.71 
    8.72 -void
    8.73 
    8.74 -TFSeedVP_TLF( void *_params, VirtProcr *animPr )
    8.75 
    8.76 - {
    8.77 
    8.78 -   TFSimulatorParams   *params;
    8.79 
    8.80 -
    8.81 
    8.82 -   params    = (TFSimulatorParams *)_params;
    8.83 
    8.84 -
    8.85 
    8.86 -         DEBUG( dbgTFHW, "CPU Span at_reset\n", _params );
    8.87 
    8.88 -         
    8.89 
    8.90 -         int32
    8.91 
    8.92 -         constructProbe = VMS__create_single_interval_probe("constructProbe",
    8.93 
    8.94 -                                                                    animPr );
    8.95 
    8.96 -         VMS__record_sched_choice_into_probe( constructProbe, animPr );
    8.97 
    8.98 -         VMS__record_interval_start_in_probe( constructProbe );
    8.99 
   8.100 -
   8.101 
   8.102 -   HWSim__register_constructor( &constructTeraFluxArch, _params, animPr);
   8.103 
   8.104 -   HWSim__reset_and_sim( params->results, animPr );//animPr suspends til done
   8.105 
   8.106 -
   8.107 
   8.108 -   //=========== Setup 
   8.109 
   8.110 -   /* for performance, want each phys core's master to have own acquire state
   8.111 
   8.112 -    *  locally, and only read some config info that tells it whether needs
   8.113 
   8.114 -    *  to read other data to update itself, or something..
   8.115 
   8.116 -    * But, for now, just doing simplest thing.. can add a "comm plugin" to
   8.117 
   8.118 -    * HWSim, so the the handler for communication-calls takes a plugin that
   8.119 
   8.120 -    * it calls..  that lets HWSim be modified, so that acquire is done in
   8.121 
   8.122 -    * the request handler in the master.
   8.123 
   8.124 -    *Other alternative is making a communication-controller element, and send
   8.125 
   8.126 -    * messages to it to do the acquires and releases -- will make that
   8.127 
   8.128 -    * time-line be animated a lot -- will need it to be able to jump around
   8.129 
   8.130 -    * among the physical cores -- so, something about letting a given time-
   8.131 
   8.132 -    * line be able to be animated on whichever core needs it at the moment.
   8.133 
   8.134 -    *Let's see..  the cores will be busy, than one will do an acquire, which
   8.135 
   8.136 -    * will need the acquire-controller time-line -- but don't want that core
   8.137 
   8.138 -    * to run out of work waiting for the controller -- hmmm, how about, use
   8.139 
   8.140 -    * the affinity feature to keep each of the nodes to a particular core,
   8.141 
   8.142 -    * but don't use it on the controller, which will let it move around..
   8.143 
   8.144 -    *So, have separate readyQs -- one for each core, and another for free-
   8.145 
   8.146 -    * floating..  when whatever scheduler is running has its local readyQ
   8.147 
   8.148 -    * empty, it takes from the floating.
   8.149 
   8.150 -    */
   8.151 
   8.152 -   make acquire-controller. (central control over acquires but no timing)
   8.153 
   8.154 -   make array to hold all the nodes.
   8.155 
   8.156 -      loop makes each node and gives it an x and a y ID, and code-ptrs
   8.157 
   8.158 -      (call make_node(), which constructs the four time-lines in a node)
   8.159 
   8.160 -
   8.161 
   8.162 -      loop through, send each "start" signal.
   8.163 
   8.164 -
   8.165 
   8.166 - }
   8.167 
   8.168 -
   8.169 
   8.170 -
   8.171 
   8.172 -/*This function is the constructor given to HWSim by the seed processor.
   8.173 
   8.174 - * It uses HWSim calls to create all the TimeLines and TimeDomains, and to
   8.175 
   8.176 - * hook them together.  Note that HWSim will start them, itself, after this
   8.177 
   8.178 - * constructor is done.
   8.179 
   8.180 - *
   8.181 
   8.182 - *Note, timelines don't have to be connected in order to communicate -- it's
   8.183 
   8.184 - * just one way of getting the needed info to the sending TimeLine, which
   8.185 
   8.186 - * consists of the pointer to the destination TimeLine, and which port to
   8.187 
   8.188 - * tell that target Timeline the communication is coming in on.
   8.189 
   8.190 - *The acquire will have the target TimeLine stored in a hash table, that's
   8.191 
   8.192 - * how the sending TimeLine gets the pointer to the target.  It has the port
   8.193 
   8.194 - * number hard-coded.
   8.195 
   8.196 - */
   8.197 
   8.198 -void
   8.199 
   8.200 -constructTeraFluxArch( void *_params, VirtProcr *animPr )
   8.201 
   8.202 - {
   8.203 
   8.204 -   TFSimulatorParams   *params;
   8.205 
   8.206 -   int nodeNum;
   8.207 
   8.208 -   HWSimTimeDomain *node;
   8.209 
   8.210 -   HWSimTimeLine   *cpu, *communicator;
   8.211 
   8.212 -
   8.213 
   8.214 -   params    = (TFSimulatorParams *)_params;
   8.215 
   8.216 -
   8.217 
   8.218 -   //========Define the types of TimeLine, which sets the at_reset fn========
   8.219 
   8.220 -   //
   8.221 
   8.222 -   HWSim__define_TimeLine_type( CPU_TIMELINE, &CPUSpan_at_reset, animPr );
   8.223 
   8.224 -   HWSim__define_TimeLine_type( COMM_TIMELINE, &commSpan_at_reset, animPr );
   8.225 
   8.226 -   
   8.227 
   8.228 -   //==========Register HWSim handlers=========
   8.229 
   8.230 -   //
   8.231 
   8.232 -   // Handlers are special because they run inside HWSim with access to
   8.233 
   8.234 -   //  shared global state and have the ability to start new spans, modify
   8.235 
   8.236 -   //  TimeLine state, and so on.
   8.237 
   8.238 -
   8.239 
   8.240 -      //All data is local to a TimeLine, except global vars.  Those can only
   8.241 
   8.242 -      // be accessed through a registered handler.
   8.243 
   8.244 -   HWSim__register_global_var_accessor( DO_ACQUIRE_SEND, &do_acquire_send,
   8.245 
   8.246 -                                        animPr );
   8.247 
   8.248 -   HWSim__register_global_var_accessor( GET_OWNING_TNODE, &get_owning_TNode,
   8.249 
   8.250 -                                        animPr );
   8.251 
   8.252 -
   8.253 
   8.254 -      //HWInstrs are able to generate communications, start new spans, and
   8.255 
   8.256 -      // so forth -- they are considered extensions of HWSim itself, with the
   8.257 
   8.258 -      // ability to affect the language's internal semantic and scheduling
   8.259 
   8.260 -      // state, and so are created as handlers, which must be registered.
   8.261 
   8.262 -   HWSim__register_HWInstr_type( ACQUIRE_INSTR,
   8.263 
   8.264 -                                 &handle_Acquire_HWInstr_request, animPr );
   8.265 
   8.266 -   HWSim__register_HWInstr_type( RELEASE_INSTR,
   8.267 
   8.268 -                                 &handle_Release_HWInstr_request, animPr );
   8.269 
   8.270 -
   8.271 
   8.272 -   //==========Create the TimeDomains and TimeLines and connect them=========
   8.273 
   8.274 -   //
   8.275 
   8.276 -   for( nodeNum = 0; nodeNum < params->numNodes; nodeNum++ )
   8.277 
   8.278 -    {
   8.279 
   8.280 -      node          = HWSim__create_TimeDomain( params?, animPr );
   8.281 
   8.282 -      cpu           = HWSim__create_TimeLine_of_type( CPU_TIMELINE, animPr );
   8.283 
   8.284 -      communicator  = HWSim__create_TimeLine_of_type( COMM_TIMELINE, animPr);
   8.285 
   8.286 -      HWSim__add_TimeLine_to_TimeDomain( cpu,          node );
   8.287 
   8.288 -      HWSim__add_TimeLine_to_TimeDomain( communicator, node );
   8.289 
   8.290 -         //This stores the target ptr + port-num in the out-port position in
   8.291 
   8.292 -         // the cpu TimeLine -- so spans in cpu TimeLine can look up target
   8.293 
   8.294 -      HWSim__connect_TimeLine_outPort_to_TimeLine_inPort(
   8.295 
   8.296 -         cpu, COMMUNICATOR_OUTPORT, communicator, CPU_INPORT );
   8.297 
   8.298 -    }
   8.299 
   8.300 -
   8.301 
   8.302 -   //Done -- the architecture is very simple for now -- inter-node comm
   8.303 
   8.304 -   // happens via acquire spans, which use global vars to find the target
   8.305 
   8.306 -   // communicator, and the comm spans have the target port hard-coded.
   8.307 
   8.308 -   //So no inter-node communication connections
   8.309 
   8.310 - }
   8.311 
   8.312 -
   8.313 
   8.314 -/*The acquire handler uses HWSim calls to generate a communication in the
   8.315 
   8.316 - * Communicator TimeLine.  When the ConsistentTime reaches the appointed
   8.317 
   8.318 - * simulation time at which that comm arrives, it triggers the acquire-start
   8.319 
   8.320 - * span in the Communicator TimeLine.
   8.321 
   8.322 - *
   8.323 
   8.324 - *Q: what's with HWSim__send_comm?  Can just use that, don't need to register
   8.325 
   8.326 - * an instruction..  Means GuestCode span just keeps going..  pause it during
   8.327 
   8.328 - * an HWInstr, then resume it..  Want multiple spans for any reason?
   8.329 
   8.330 - */
   8.331 
   8.332 -void
   8.333 
   8.334 -handle_Acquire_HWInstr_request()
   8.335 
   8.336 - {
   8.337 
   8.338 -
   8.339 
   8.340 -
   8.341 
   8.342 - }
   8.343 
   8.344 -
   8.345 
   8.346 -/*The release handler uses HWSim calls to generate a communication in the
   8.347 
   8.348 - * Communicator TimeLine.  When the ConsistentTime reaches the appointed
   8.349 
   8.350 - * simulation time at which that comm arrives, it triggers the release
   8.351 
   8.352 - * span in the Communicator TimeLine.
   8.353 
   8.354 - */
   8.355 
   8.356 -void
   8.357 
   8.358 -handle_Release_HWInstr_request()
   8.359 
   8.360 - {
   8.361 
   8.362 -
   8.363 
   8.364 - }
   8.365 

     9.1 --- a/src/Application/SimParams.c	Mon Nov 07 16:03:01 2011 -0800
     9.2 +++ b/src/Application/SimParams.c	Sat Nov 19 17:58:21 2011 -0800
     9.3 @@ -1,91 +1,1 @@
     9.4 -/*
     9.5 
     9.6 - *  Copyright 2009 OpenSourceStewardshipFoundation.org
     9.7 
     9.8 - *  Licensed under GNU General Public License version 2
     9.9 
    9.10 - *
    9.11 
    9.12 - * Author: seanhalle@yahoo.com
    9.13 
    9.14 - *
    9.15 
    9.16 - * Created on November 15, 2009, 2:35 AM
    9.17 
    9.18 - */
    9.19 
    9.20 -
    9.21 
    9.22 -#include <malloc.h>
    9.23 
    9.24 -#include <stdlib.h>
    9.25 
    9.26 -
    9.27 
    9.28 -#include "SimParams.h"
    9.29 
    9.30 -#include "ParamHelper/Param.h"
    9.31 
    9.32 -
    9.33 
    9.34 -
    9.35 
    9.36 -uint8 *
    9.37 
    9.38 -read_Machine_Code_From_File( int numBytesInFile, char *machineCodeFileName );
    9.39 
    9.40 -
    9.41 
    9.42 - 
    9.43 
    9.44 -void
    9.45 
    9.46 -fill_sim_params_from_bag( SimulationParams *simParams, ParamBag *paramBag )
    9.47 
    9.48 - { char *guestAppFileName, *systemCodeFileName;
    9.49 
    9.50 -   int numBytesInGuestApp, numBytesInSystemCode;
    9.51 
    9.52 -   
    9.53 
    9.54 -      ParamStruc *param;
    9.55 
    9.56 -      param = getParamFromBag( "GuestApplicationFileName", paramBag );
    9.57 
    9.58 -   guestAppFileName = param->strValue;
    9.59 
    9.60 -      param = getParamFromBag( "numBytesInGuestApp", paramBag );
    9.61 
    9.62 -   numBytesInGuestApp = param->intValue;
    9.63 
    9.64 -
    9.65 
    9.66 -   simParams->guestApp =
    9.67 
    9.68 -    read_Machine_Code_From_File( numBytesInGuestApp, guestAppFileName );
    9.69 
    9.70 -
    9.71 
    9.72 -      param = getParamFromBag( "SystemCodeFileName", paramBag );
    9.73 
    9.74 -   systemCodeFileName = param->strValue;
    9.75 
    9.76 -      param = getParamFromBag( "numBytesInSystemCode", paramBag );
    9.77 
    9.78 -   numBytesInSystemCode = param->intValue;
    9.79 
    9.80 -
    9.81 
    9.82 -   simParams->systemCode =
    9.83 
    9.84 -    read_Machine_Code_From_File( numBytesInSystemCode, systemCodeFileName );
    9.85 
    9.86 -
    9.87 
    9.88 -
    9.89 
    9.90 -      param = getParamFromBag( "numNodes", paramBag );
    9.91 
    9.92 -   simParams->numNodes = param->intValue;
    9.93 
    9.94 -
    9.95 
    9.96 - }
    9.97 
    9.98 -
    9.99 
   9.100 -
   9.101 
   9.102 -
   9.103 
   9.104 -uint8 *
   9.105 
   9.106 -read_Machine_Code_From_File( int numBytesInFile, char *machineCodeFileName )
   9.107 
   9.108 - { int byte;
   9.109 
   9.110 -   FILE  *file;
   9.111 
   9.112 -   char  *machineCode = malloc( numBytesInFile );
   9.113 
   9.114 -   if( machineCode == NULL ) printf( "\nno mem for machine code\n" );
   9.115 
   9.116 -   
   9.117 
   9.118 -   file = fopen( machineCodeFileName, "r" );
   9.119 
   9.120 -   if( file == NULL ) { printf( "\nCouldn't open file!!\n"); exit(1);}
   9.121 
   9.122 -
   9.123 
   9.124 -   fseek( file, 0, SEEK_SET );
   9.125 
   9.126 -   for( byte = 0; byte < numBytesInFile; byte++ )
   9.127 
   9.128 -    {
   9.129 
   9.130 -      if( feof( file ) )  printf( "file ran out too soon" );
   9.131 
   9.132 -      machineCode[byte] = getchar( file );
   9.133 
   9.134 -      
   9.135 
   9.136 -    }
   9.137 
   9.138 -   return machineCode;
   9.139 
   9.140 - }
   9.141 
   9.142 -
   9.143 
   9.144 -
   9.145 
   9.146 - //==========================================================================
   9.147 
   9.148 -void
   9.149 
   9.150 -printSimResults( SimulationResults simResults )
   9.151 
   9.152 - { int r, c, numRows, numCols, rowsToPrint, colsToPrint, rowIncr, colIncr;
   9.153 
   9.154 -   float32 *matrixArray;
   9.155 
   9.156 -
   9.157 
   9.158 -   numRows = rowsToPrint = matrix->numRows;
   9.159 
   9.160 -   numCols = colsToPrint = matrix->numCols;
   9.161 
   9.162 -   matrixArray = matrix->array;
   9.163 
   9.164 -
   9.165 
   9.166 -   rowIncr = numRows/20; if(rowIncr == 0) rowIncr = 1;//20 to 39 rows printed
   9.167 
   9.168 -   colIncr = numCols/20; if(colIncr == 0) colIncr = 1;//20 to 39 cols printed
   9.169 
   9.170 -   for( r = 0; r < numRows; r += rowIncr )
   9.171 
   9.172 -    { for( c = 0; c < numCols; c += colIncr )
   9.173 
   9.174 -       { printf( "%3.1f | ", matrixArray[ r * numCols + c ] );
   9.175 
   9.176 -       }
   9.177 
   9.178 -      printf("\n");
   9.179 
   9.180 -    }
   9.181 
   9.182 - }
   9.183 
   9.184 -
   9.185 
   9.186 +/*
   9.187 
   9.188  *  Copyright 2009 OpenSourceStewardshipFoundation.org
   9.189 
   9.190  *  Licensed under GNU General Public License version 2
   9.191 
   9.192  *
   9.193 
   9.194  * Author: seanhalle@yahoo.com
   9.195 
   9.196  *
   9.197 
   9.198  * Created on November 15, 2009, 2:35 AM
   9.199 
   9.200  */
   9.201 
   9.202 
   9.203 
   9.204 #include <malloc.h>
   9.205 
   9.206 #include <stdlib.h>
   9.207 
   9.208 
   9.209 
   9.210 #include "SimParams.h"
   9.211 
   9.212 #include "ParamHelper/Param.h"
   9.213 
   9.214 
   9.215 
   9.216 
   9.217 
   9.218 uint8 *
   9.219 
   9.220 read_Machine_Code_From_File( int numBytesInFile, char *machineCodeFileName );
   9.221 
   9.222 
   9.223 
   9.224  
   9.225 
   9.226 void
   9.227 
   9.228 fill_sim_params_from_bag( SimulationParams *simParams, ParamBag *paramBag )
   9.229 
   9.230  { char *guestAppFileName, *systemCodeFileName;
   9.231 
   9.232    int numBytesInGuestApp, numBytesInSystemCode;
   9.233 
   9.234    
   9.235 
   9.236       ParamStruc *param;
   9.237 
   9.238       param = getParamFromBag( "GuestApplicationFileName", paramBag );
   9.239 
   9.240    guestAppFileName = param->strValue;
   9.241 
   9.242       param = getParamFromBag( "numBytesInGuestApp", paramBag );
   9.243 
   9.244    numBytesInGuestApp = param->intValue;
   9.245 
   9.246 
   9.247 
   9.248    simParams->guestApp =
   9.249 
   9.250     read_Machine_Code_From_File( numBytesInGuestApp, guestAppFileName );
   9.251 
   9.252 
   9.253 
   9.254       param = getParamFromBag( "SystemCodeFileName", paramBag );
   9.255 
   9.256    systemCodeFileName = param->strValue;
   9.257 
   9.258       param = getParamFromBag( "numBytesInSystemCode", paramBag );
   9.259 
   9.260    numBytesInSystemCode = param->intValue;
   9.261 
   9.262 
   9.263 
   9.264    simParams->systemCode =
   9.265 
   9.266     read_Machine_Code_From_File( numBytesInSystemCode, systemCodeFileName );
   9.267 
   9.268 
   9.269 
   9.270 
   9.271 
   9.272       param = getParamFromBag( "numNodes", paramBag );
   9.273 
   9.274    simParams->numNodes = param->intValue;
   9.275 
   9.276 
   9.277 
   9.278  }
   9.279 
   9.280 
   9.281 
   9.282 
   9.283 
   9.284 
   9.285 
   9.286 uint8 *
   9.287 
   9.288 read_Machine_Code_From_File( int numBytesInFile, char *machineCodeFileName )
   9.289 
   9.290  { int byte;
   9.291 
   9.292    FILE  *file;
   9.293 
   9.294    char  *machineCode = malloc( numBytesInFile );
   9.295 
   9.296    if( machineCode == NULL ) printf( "\nno mem for machine code\n" );
   9.297 
   9.298    
   9.299 
   9.300    file = fopen( machineCodeFileName, "r" );
   9.301 
   9.302    if( file == NULL ) { printf( "\nCouldn't open file!!\n"); exit(1);}
   9.303 
   9.304 
   9.305 
   9.306    fseek( file, 0, SEEK_SET );
   9.307 
   9.308    for( byte = 0; byte < numBytesInFile; byte++ )
   9.309 
   9.310     {
   9.311 
   9.312       if( feof( file ) )  printf( "file ran out too soon" );
   9.313 
   9.314       machineCode[byte] = getchar( file );
   9.315 
   9.316       
   9.317 
   9.318     }
   9.319 
   9.320    return machineCode;
   9.321 
   9.322  }
   9.323 
   9.324 
   9.325 
   9.326 
   9.327 
   9.328  //==========================================================================
   9.329 
   9.330 void
   9.331 
   9.332 printSimResults( SimulationResults simResults )
   9.333 
   9.334  { 
   9.335 
   9.336  }
   9.337 
   9.338 
   9.339 
   9.340 \ No newline at end of file

    10.1 --- a/src/Application/SimParams.h	Mon Nov 07 16:03:01 2011 -0800
    10.2 +++ b/src/Application/SimParams.h	Sat Nov 19 17:58:21 2011 -0800
    10.3 @@ -1,48 +1,1 @@
    10.4 -/*
    10.5 
    10.6 - *  Copyright Oct 24, 2009 OpenSourceStewardshipFoundation.org
    10.7 
    10.8 - *  Licensed under GNU General Public License version 2
    10.9 
   10.10 - */
   10.11 
   10.12 -
   10.13 
   10.14 -#ifndef MATRIX_MULT_H_
   10.15 
   10.16 -#define MATRIX_MULT_H_
   10.17 
   10.18 -
   10.19 
   10.20 -#include <stdio.h>
   10.21 
   10.22 -#include <unistd.h>
   10.23 
   10.24 -#include <malloc.h>
   10.25 
   10.26 -
   10.27 
   10.28 -#include "../HWSim_lib/VMS/VMS_primitive_data_types.h"
   10.29 
   10.30 -#include "ParamHelper/Param.h"
   10.31 
   10.32 -
   10.33 
   10.34 -//==============================  Structures  ==============================
   10.35 
   10.36 -
   10.37 
   10.38 -typedef
   10.39 
   10.40 -struct
   10.41 
   10.42 - { uint8 *guestApp;
   10.43 
   10.44 -   uint8 *systemCode;
   10.45 
   10.46 -   int32 numNodes;
   10.47 
   10.48 - }
   10.49 
   10.50 -SimulationResults;
   10.51 
   10.52 -
   10.53 
   10.54 -
   10.55 
   10.56 -typedef
   10.57 
   10.58 -struct
   10.59 
   10.60 - { uint8 *guestApp;
   10.61 
   10.62 -   uint8 *systemCode;
   10.63 
   10.64 -   int32 numNodes;
   10.65 
   10.66 -   SimulationResults *simResults;
   10.67 
   10.68 - }
   10.69 
   10.70 -SimulationParams;
   10.71 
   10.72 -
   10.73 
   10.74 -
   10.75 
   10.76 -
   10.77 
   10.78 -//==============================  Functions  ================================
   10.79 
   10.80 -
   10.81 
   10.82 -void
   10.83 
   10.84 -printSimResults( SimulationResults simResults );
   10.85 
   10.86 -
   10.87 
   10.88 -void
   10.89 
   10.90 -fill_sim_params_from_bag( SimulationParams *simParams, ParamBag *paramBag );
   10.91 
   10.92 -
   10.93 
   10.94 -//===========================================================================
   10.95 
   10.96 -
   10.97 
   10.98 -#endif /*MATRIX_MULT_H_*/
   10.99 
  10.100 +/*
  10.101  *  Copyright 2011 OpenSourceStewardshipFoundation.org
  10.102  *  Licensed under GNU General Public License version 2
  10.103  */
  10.104 
  10.105 #ifndef SIM_PARAMS_
  10.106 #define SIM_PARAMS_
  10.107 
  10.108 #include <stdio.h>
  10.109 #include <unistd.h>
  10.110 #include <malloc.h>
  10.111 
  10.112 #include "../HWSim_lib/VMS/VMS_primitive_data_types.h"
  10.113 #include "ParamHelper/Param.h"
  10.114 
  10.115 
  10.116 //==============================  Structures  ==============================
  10.117 typedef struct
  10.118  { uint8 *guestApp;
  10.119    uint8 *systemCode;
  10.120    int32 numNodes;
  10.121  }
  10.122 SimulationResults;
  10.123 
  10.124 typedef struct
  10.125  { uint8 *guestApp;
  10.126    uint8 *systemCode;
  10.127    int32 numNodes;
  10.128    SimulationResults *simResults;
  10.129  }
  10.130 SimulationParams;
  10.131 
  10.132 //==============================  Functions  ================================
  10.133 void
  10.134 printSimResults( SimulationResults simResults );
  10.135 
  10.136 void
  10.137 fill_sim_params_from_bag( SimulationParams *simParams, ParamBag *paramBag );
  10.138 
  10.139 
  10.140 //===========================================================================
  10.141 
  10.142 #endif /**/
  10.143 
  10.144 \ No newline at end of file

    11.1 --- a/src/Application/main.c	Mon Nov 07 16:03:01 2011 -0800
    11.2 +++ b/src/Application/main.c	Sat Nov 19 17:58:21 2011 -0800
    11.3 @@ -1,48 +1,38 @@
    11.4 -/*
    11.5 
    11.6 - *  Copyright Oct 24, 2009 OpenSourceStewardshipFoundation.org
    11.7 
    11.8 - *  Licensed under GNU General Public License version 2
    11.9 
   11.10 - *
   11.11 
   11.12 - * author seanhalle@yahoo.com
   11.13 
   11.14 - */
   11.15 
   11.16 -
   11.17 
   11.18 -#include <malloc.h>
   11.19 
   11.20 -#include <stdlib.h>
   11.21 
   11.22 -
   11.23 
   11.24 -#include "SimParams.h"
   11.25 
   11.26 -#include "HWSim_TeraFlux/HWSim_TeraFlux.h"
   11.27 
   11.28 -
   11.29 
   11.30 -/**
   11.31 
   11.32 - * 
   11.33 
   11.34 - */
   11.35 
   11.36 -int main( int argc, char **argv )
   11.37 
   11.38 - { SimulationParams  *simParams;
   11.39 
   11.40 -   SimulationResults *simResults;
   11.41 
   11.42 -   ParamBag          *paramBag;
   11.43 
   11.44 -   
   11.45 
   11.46 -   printf( "arguments: %s | %s\n", argv[0], argv[1] );
   11.47 
   11.48 -
   11.49 
   11.50 -   simParams             = malloc( sizeof(SimulationParams) );
   11.51 
   11.52 -
   11.53 
   11.54 -
   11.55 
   11.56 -      //VMS has its own separate internal malloc, so to get results out,
   11.57 
   11.58 -      // have to pass in empty array for it to fill up
   11.59 
   11.60 -      //The alternative is internally telling HWSim make external space to use
   11.61 
   11.62 -   simResults            = malloc( sizeof(SimulationResults) );
   11.63 
   11.64 -   simParams->simResults = simResults;
   11.65 
   11.66 -
   11.67 
   11.68 -   paramBag              = makeParamBag();
   11.69 
   11.70 -
   11.71 
   11.72 -   readParamFileIntoBag(     argv[1],   paramBag );
   11.73 
   11.74 -   fill_sim_params_from_bag( simParams, paramBag );
   11.75 
   11.76 -
   11.77 
   11.78 -
   11.79 
   11.80 -   constructAndSimulateSystem( simParams );
   11.81 
   11.82 -
   11.83 
   11.84 -   printSimResults( simResults );
   11.85 
   11.86 -
   11.87 
   11.88 -   fflush(stdin);
   11.89 
   11.90 -   
   11.91 
   11.92 -   exit(0); //cleans up
   11.93 
   11.94 - }
   11.95 
   11.96 -
   11.97 
   11.98 -
   11.99 
  11.100 +/*
  11.101 + *  Copyright 2011 OpenSourceStewardshipFoundation.org
  11.102 + *  Licensed under GNU General Public License version 2
  11.103 + *
  11.104 + * author seanhalle@yahoo.com
  11.105 + */
  11.106 + 
  11.107 +#include <malloc.h>
  11.108 +#include <stdlib.h>
  11.109 +
  11.110 +#include "SimParams.h"
  11.111 +#include "HWSim__Hello_World_HW/HWSim__Hello_World_HW.h"
  11.112 +
  11.113 +/*
  11.114 + *
  11.115 + * 
  11.116 + */
  11.117 +
  11.118 +int main( int argc, char **argv )
  11.119 + { ParamBag      *simParams;
  11.120 +   HWSimResults  *simResults;
  11.121 +
  11.122 +   printf( "param file name: %s\n", argv[1] );
  11.123 +
  11.124 +   simParams = makeParamBag();
  11.125 +   readParamFileIntoBag( argv[1], simParams );
  11.126 +   
  11.127 +   netlist = createPingPongNetlist();
  11.128 +   simResults = 
  11.129 +    HWSim__run_simulation( simParams, netlist );
  11.130 +
  11.131 +      //HWSim 
  11.132 +   printSimResults( simResults );
  11.133 +   
  11.134 +   fflush(stdin);
  11.135 +   exit(0); //cleans up
  11.136 + }
  11.137 +