Home

Documentation

Project Support

Changes in Version 4 of GraspSwRegisters

Author:
isani
Timestamp:
Wed Aug 12 09:40:47 2009

Legend:

Unmodified
Added
Removed
Modified

  • GraspSwRegisters

    v3 v4
    1 1  '''E. [wiki:GraspSw Controller Address Space and Clocking Instructions]''' 
    2 2  [[TracNav(GraspContents)]] 
    3 3  This is a very low level API, used only by someone writing a newer 
    4 4  controller socket level command.  All controller socket level 
    5 5  commands are implemented in C code (downloaded as the stage2.srec 
    6 6  to the controller) which modifies registers or address space, and/or 
    7 7  writes instructions to the clocking engine. 
    8 8  Our FPGA [wiki:V2P20Phase0HWSWInterface Memory Map] includes [wiki:V2P20GPIO General Purpose I/O (GPIOs)] that 
    9 9  allow access to: 
    10 10   * Board ID Register Bits 
    11 11   * Board I2C Register Bits 
    12 12   * ADC SPI Configuration Register Interface 
    13 13   * Clocking Engine Register Interface 
    14 14  == Board ID Bits == 
    15 15  The first generation of STARGRASP controller fpga boards contain a 2 bits in a GPIO register which indicate which slot of a 4 slot chassis the board is in, and 3 more bits which are programmable as a "chassis ID" to differentiate the chassis when used in a mosaic camera or on a network with multiple development systems e.g. in a lab. 
    16 16  The current generation of STARGRASP uses more flexible I2C parts so that we can ID each board and store more information than just the chassis number. 
    17 17  == Board I2C Bits == 
    18 18  (More info needed on all of the things accessible by I2C here.) 
    19 19  == ADC SPI Configuration Register == 
    20 20  (More information on the ADC needed here.) 
    21 21  == Clocking Engine == 
    22 22  The "Clocking Engine" is an fpga-hardware pattern generator which we developed specifically for controlling clock lines to read a detector.  It consists of one 3-bit pattern generator we call "PG3" and two 4-bit pattern generators we call "PG4s".  Each bit in the PG can control one detector clock line signal. 
    23 23  Todo: Incorporate the wiki pages above into GraspContents. 
    24 24  Related info: 
    25 25   * [wiki:ClockMath Clocking Engine Math Module] 
    26 26   * [wiki:VIDSEQ_bit_packing Clocking Engine pattern generator bit packing] 
    27 27   * Clocking engine block diagram attached below. 
    28 28  [[Image(clocking_engine.gif)]] 
      29   
      30  === Polled Readout Mode === 
      31   
      32  The basic order of operations for embedded C code to perform a readout 
      33  in '''polled mode''' is: 
      34   
      35  1. Write CONTROL REGS to set up any data processing that will be 
      36     required.  For example, will 4 16-bit ADC samples need to be 
      37     averaged into one value during the readout? 
      38   
      39  2. Write CONTROL REGS with the buffer locations and sizes 
      40     where 16-bit video pixels will go.  An even number of pixels must 
      41     be requested, on a 32-bit aligned address within the "OCM" memory 
      42     space.  OCM is a few kilobytes of fast, shared memory which the 
      43     clocking engine HDL hardware and the PowerPC can both access. 
      44   
      45  3. Check STATUS REGS and wait until there is room for instructions in the 
      46     clocking engine's input register. 
      47   
      48  4. Fill FIFO INPUT with 16-bit instructions words which: 
      49   
      50    * Set DAC voltages 
      51    * Insert delay times 
      52    * Wait for and synchronize with other clocking engines 
      53    * Control digital I/O lines (OTA CCD cell selects.) 
      54    * Produce Parallel clocking patterns to shift charge 
      55    * Shift the Serial register and general video samples 
      56   
      57    These instructions are executed serially, in the order written. 
      58    The FIFO INPUT must not be written when the STATUS REGS indicate 
      59    that the FIFO is full. 
      60   
      61  5. Check STATUS REGS to see if enough video samples have been produced 
      62     to fill one of the requested OCM buffers.  If not, go to step 3. 
      63   
      64  6. Copy pixel data out of OCM into DRAM or transfer it directly 
      65     over the Ethernet link to the Pixel server.  If requested, the 
      66     embedded C code may also perform pedestal subtraction or other 
      67     "software math engine" functions.  Go to step 2. 
      68   
      69  === Error Conditions === 
      70   
      71  '''Stalled''' conditions occur when the FIFO INPUT is not filled with a 
      72  new instruction in time for seamless back-to-back execution with the 
      73  previous instruction.  Detector readouts will still complete, but the 
      74  readout timing may be irregular. 
      75   
      76  '''Overrun''' conditions occur when 16-bit video samples are produced 
      77  as a result of a SERIAL instruction but no (more) OCM memory locations 
      78  have been defined.  When they have nowhere to go, they are dropped 
      79  and the readout function will report missing pixels. 
      80   
      81  === Interrupt Driven Mode === 
      82   
      83  To reduce the errors above, a new mode of operation triggered by interrupts 
      84  rather than polling improves the reliability of the system.  Interrupts 
      85  can be used in place of the polling checks in steps 3. and 5. above. 
      86   
      87  Step 3 checked for available space in FIFO INPUT for new instructions 
      88  that drive clocking.  This FIFO is 512 instructions deep, so one 
      89  possible implementation would have hardware assert an interrupt 
      90  whenever the FIFO was at least half empty.  In this case, the 
      91  interrupt routine could safely write up to 256 new instructions 
      92  whenever the interrupt triggers.  Making the FIFO INPUT interrupt 
      93  driven is less of a priority because a '''Stalled''' condition only 
      94  causes a warning and is rare because the FIFO is relatively deep. 
      95   
      96  Step 5 checks to see if one of the two requested OCM buffers has 
      97  been completely written and can be memcpy()'d to DRAM and re-used. 
      98  An interrupt which triggers whenever one of these buffers is ready 
      99  (i.e., one which is asserted as long as BUFRDY bit in STATUS REGS 
      100  is high) would allow faster response time for the memory copy than 
      101  the polling method, thus avoiding the '''overrun''' errors which 
      102  occur sporadically in polled mode especially when the stage2 embedded 
      103  C code is off servicing the network (e.g. logging, DHCP, or answering 
      104  an asynchronous request for something from a pixel server.) 
      105  These type of operations would get interrupted rather than needing 
      106  to complete before the next polling cycle. 
      107   
      108  In addition to making the current readout modes more reliable in 
      109  the face of random, unpredictable network events, interrupts should 
      110  also allow a higher level of performance (faster pixel rates) from 
      111  the STARGRASP because the interrupt routine requires less overhead 
      112  than polling constantly.