Raceway Read Operations

To specify a data-pull or Read operation on the Raceway, the user adds a 
special attribute to the DFG arc for that transfer. The arc will have the 
following attribute:

	xfertype = pull

The scheduler will generate "postmessg" / "readmessg"  command-pairs in the 
.prog files instead of the normal "sendmessg/recvmessg" pairs, respectively.  

The read_program(pe_id, program) function in subroutines.sim was updated to 
recognize these new instructions having the following formats:

postmessg <Message_ID> <dst_pe> <length> [priority] [comment]
readmessg <Message_ID> <dst_pe> <length> [priority] [comment]

These instructions generate opcodes op_postmessg and op_readmessg, 
respectively, used by the processor. 

The same instructions are generated by the dynamic scheduler when running in 
DYNAMIC mode.

The generic_pe.sim, static_pe.sim and multi_priority_pe.sim models have been 
updated to support Raceway Read operations.

A POST and READ_REQ message_type was added to the enumerated message types in 
subroutines.sim.

When a processor reads an op_postmessg opcode, it generates a POST message and 
sends it out its "ioport". It then continues to process its next instruction.

It is presumed that the processor interfaces to a racepp_nic.sim or 
racepp_nic_fd.sim (NIC) model.  This sourcing NIC model holds (posts) the data.

The counterpart processor will read an op_readmessg opcode which will generate 
a READ_REQ message, send it out its "ioport" and wait until it receives the 
data.

The NIC at its proximity will receive the READ_REQ message, packetize it and 
send READ_REQ packets across the Raceway crossbars.  The crossbars 
(racepp_xbar.sim or racepp_xbar_fd.sim) handle a READ_REQ the same way as a 
REQ. The READ_REQ packet will end up at the sourcing NIC.

The sourcing NIC, upon receiving a READ_REQ, will check that it has sufficient 
data for the requested packet. If it has the data, it will send an ACK back 
after the computed transfer delay. If it does not have the data (which may 
occur in debugging mode when the READ_REQ arrives before the POST), it will 
print out a warning and send a NACK back.

The cycle continues between the two NICs until all data packets have 
transfered. When the receiving NIC has received all data packets requested by 
the READ_REQ message, it sends a REQ to its local processor with the same MID 
and message/packet length as the original READ_REQ message.

The local processor will receive the REQuested data and resume out of its 
instruction processing "wait" state.

Post/read messages between processors that do not go across the Raceway will 
not behave properly. It will result in a processor receiving an erroneous 
post/read message which will cause a CSIM_HALT_POPUP("WARNING: Received bad 
message"). The terminal window will show more detail about the message.