From: owner-lcls-controls@lists1.slac.stanford.edu [mailto:owner-lcls-controls@lists1.slac.stanford.edu] On Behalf Of Allison, Stephanie
Sent: Friday, May 27, 2005 3:22 PM
To: lcls-controls
Cc: Gromme, Anthony E.
Subject: PNET Design Review Comments

Hi -

Thanks to Dayle for a nice presentation and discussion of the PNET design.  
The attendees were Doug, Kristi, Ron Chestnut, Steph, Diane, Debbie.

Here are the comments from the review:

(1) What should be done with a corrupted PNET pattern?  If a corrupted PNET 
    pattern is passed on to the EVRs, what do they do?  Maybe not trigger 
    anything.

(2) What happens if PNET pattern is corrupted for multiple pulses?

(3) What happens if the ISR stops firing because the VME module fails or 
    there is some failure between the MPG and the PNET VME module?  Should 
    there be a watchdog on the ISR that inserts a "bad" PNET pattern into 
    the EVG in this case?

(4) Consider keeping the timestamp of the last good PNET pattern for 
    diagnostic purposes.

(5) Consider logging an error when the PNET pattern is corrupted or bad with 
    appropriate metering.

(6) Consider using OSI calls for the message queue and semaphores.  We think 
    the OSI message queue call can be done in the ISR.  Dayle is using devLib 
    calls for the VME registration, etc.  Diane investigated the OSI RTEMS 
    layer and it does NOT involve semaphores. 

(7) Does the message queue between the ISR and receiver task needs to be 
    protected in some way?  I think the answer was NO.

(8) Dayle plans to add waveform support for a full 128 bit pattern 
    (16 byte waveform).   The waveform can then be used in an FLNKed compress 
    record and for future PNET diagnostics.  For waveform support, the shared 
    data between the message receive task and device support performed in 
    either a callback task (for I/O Intr) or a scan task (for periodic) must 
    be protected with a semaphore.  The semaphore is not needed for 
    binary-input support.  There was a question if a semaphore is needed for 
    mbbiDirect since the maximum number of bits ever used in a PNET mbbiDirect 
    would be 12 which is less than the 16 bit word which Dayle and Bob say can 
    be read/write in one uninterruptable command.  Doug thought it was less 
    than a word for a PPC.

(9) Some discussion of PRD, ESD, EDD, and ICD.  For software, it seems that 
    the "ESD" (Engineering Specification Document) is a combination of 
    requirements and high-level design and the "EDD" (Engineering Design 
    Document) is the software design.  The "PRD" (Physics Reqts Document) 
    probably does not have enough detail to be used as-is for software reqts.  
    "ICD" (Interface Control Document) is a requirements?/design?/description? 
    document.

(10) Some discussion of the EPICS timestamp (2 4-byte longwords) that Dayle 
     puts into the EVG pattern.  The initial thought is to put the pulse ID 
     into the nanosecs longword (the number of nanoseconds elapsed since the 
     last second) which means that clients that use the timestamp for normal 
     things (like the archive viewer) has time good to only one second.  Ron 
     Chestnut suggests putting the 17 bit pulse ID, which must be 
     reconstructed from the PNET pattern, into the lower 17 bits of the 
     nanosecond longword and leave the upper 15 bits for the nanosecond value 
     from epicsGetTime.  

>From Ron after the meeting: 
The PULSEID is 17 bits, not 16. It wraps every 6 minutes and 2 seconds. The 
top 4 bits are sent in the PNET broadcast, and the current micro logic looks 
for a transition to a non-zero 4 bits (I guess to catch an error state). 
So 15 of 16 times each 6 minutes, the micros resynch the PULSEID.

Dayle's ISR should do the same thing in reconstructing the 17 bit pulse ID 
from the PNET pattern.

(11) Some discussion on the number of times the 16 byte PNET pattern is copied:
	(1) register to ISR buffer
	(2) ISR buffer to EVG register
	(3) ISR buffer to message queue
	(4) message queue to msg recv task buffer
	(5) msg recv task buffer to waveform record 
Some discussion about using double-buffering and pointers to eliminate the 
message queue.  But there's plenty of time left even with these extra copies 
so maybe not an issue.  There was no issue with the extra task switch for the 
message recv task at 360 hz.

Stephanie