anchor.diff:  
   * An alternative method for shifting a voltage down is to use a diode and pullup resistor.  The anode gets connected to the higher voltage device.  The cathode is connected to the lower voltage device.  A 10K pullup resistor is connected from the cathode to the supply voltage for the lower voltage device.  --- A word of advice: This method is quick and easy.  But, you get a slow rise time which makes it a terrible way of shifting the level of a clock signal (like TCLK for JTAG or SPICLK for SPI).
   
  -------------------------------------------------------------------------------------------------------
  +---
   
   # How It Works
   
  -This section will explain the in's and out's of how the plug-in and server applications work and how they communicate.  Look for an update soon.
  +This section will explain the in's and out's of how the plug-in and server applications work and how they communicate.  This section is intended to aid developers who want to add or modify features.  More in depth information can be found in the api documentation.
  +
  +## Server Side App
  +
  +What follows is the structure of the server side app.
  +
  +### Pin IO
  +
  +Pin IO is accomplished by using the file objects exported by linux at \sys\class\gpio
  +
  +~~~
  +<command_prompt>$ cd /sys/class/gpio
  +
  +# export the file objects for a pin
  +<command_prompt>$ echo 20 > export
  +
  +# read the state of gpio20
  +<command_prompt>$ cd gpio20
  +<command_prompt>$ cat value
  +
  +# drive gpio20 to logic 1
  +<command_prompt>$ echo out > direction
  +<command_prompt>$ echo 1 > value
  +
  +# change gpio20 from output to input
  +<command_prompt>$ echo in > direction
  +~~~
  +
  +### Pin Class
  +
  +The server pin class implements IO interactions for a pin.  When the pin assign command creates a pin object, it exports the associated IO number and opens IO objects for the direction and value of that pin.  The IO objects are kept open until the pin is destroyed.  For more information see the api documentation.
  +
  +### Pin Sequencer
  +
  +The pin sequencer is the class that does all of the heavy lifting for the server side app.  It implements all of the command messages that begin with "pin_".  See the api documentation (Server::Sequencer) for more information.  Timing is perhaps the most complicated construct to understand:
  +
  +~~~ruby
  +  # tset is a number that corresponds to a timeset name from origen ex: 1 corresponds to 'tp0'
  +  # @cycletiming[tset] is a hash
  +  # each timeset contains these keys: 
  +  #    'events'               -  [array of timestamps for timing events]
  +  #    'drive_event_data'     -  hash, the keys of the hash correspond to elements of 'events'
  +  #                           -  each value in the hash is an array
  +  #                           -  each element in the array is one of 3 values: 'data', '0', or '1'
  +  #    'drive_event_pins'     -  hash, the keys of the hash correspond to elements of 'events'
  +  #                           -  each value in the hash is an array
  +  #                           -  each element in the array is an array of pin objects
  +  #                           -  the drive event data will be performed for each pin object
  +  #    'compare_event_data'   -  similar to drive_event_data, the only valid event data is 'data'
  +  #    'drive_event_pins'     -  similar to drive_event_pins
  +  
  +  @cycletiming[tset] = {
  +  ['events'] = [0, 5, 10, 35]
  +  ['drive_event_data'] = {
  +        0: ['data']
  +       10: ['data','0']
  +       35: ['0']
  +      }
  +  ['drive_event_pins'] = {
  +        0: [[pin_obj1, pin_obj2]]
  +       10: [[pin1,pin2], [pin3]]
  +       35: [[pin4]]
  +      }
  +  }
  +~~~
  +
  +The main message supported by the sequencer is 'pin_cycle'.  As the name implies, this message implements 1 or more cycles of vector data.  It will return the response of the dut to the plug-in side app along with pass/fail information.
  +
  +### Server
  +
  +The server serves a TCP socket at 12777.  No fancy gems are used for several reasons, the main one being simplicity.  Ruby has a built in socket library that is extremely simple to use.  Multiple messages from the plug-in side app can be received with a single connection.  "\n" indicates the end of a message.  "\n\n" indicates that the packet of messages has ended.  Why TCP and not UDP?  I know the web says that UDP socket communication is faster.  But, my testing indicated otherwise.  Plus, TCP is more reliable.
   
   % end
  
positive.code:   debugger	# generation of the pattern will pause here
  ~~~
  
  #### Staying Synchronized
  
  For efficiency vectors that are generated by your app are compressed and stored until the pattern generation is completed.  This means that when execution reaches a 'debugger' statement the previously generated vectors may not have been sent to the server yet.  There are a handful of ways to make this happen.
  
negative.code: 
  #### Low-Level Timing Setup
  
  ~~~ruby
      # pinformat=
      #   This method is used to setup the pin clock format on the debugger device.
      #   The supported formats are rl and rh
  