Run IIA L1 Calorimeter Trigger SPARK FPGA --------------------------------------------- Original Rev. 27-SEPT-2001 Current Rev. 29-JULY-2003 Introduction ------------ Spark is a simplified version of the Bougie FPGA. Features of the Bougie that are not included in the Spark are: generation of L2 Header/Trailers, generation of the L2 Seed Mask, and generation of the check-sum for L2. As originally delivered in the fall of 2001 the Spark only provided for readout of the EM Et and Total Et Trigger Tower information. Summer 2003 Upgrade ------------------- Before moving to the full Bougie implementation we will upgrade the Spark with a few new features. The purpose of this is to use the relatively simple environment of the Spark to learn how to implement these functions. The new functions that will be included in this version of the Spark are: 1. Cleaned up handling of the Data_Strobe that comes from the Distributor Cap. Implementing this clean up in the Spark requires cleaning up the Transmit Sequencer PAL in the Distributor Cap. The goal of this is a cleaner more robust design with clear and understandable timing constraints. This will facilitate operating with a higher speed Xmit_Clk, i.e. faster readout the L1 Cal Trig. 2. Implement the "Monitor Data" function in the Spark so that TCC has access to the Spark's HSRO data (Just as it already has access to the HSRO data from all the other components that implement HSRO). Clean Up of the Handling of Distributor Cap Data_Strobe ------------------------------------------------------------ Current Rev. 29-JULY-2003 The main complexity of this part of the logic design is to transfer from the Xmit_Clk domain to the RF_Clk timing domain. This is actually straight forward because the Distributor Cap ERPB Data and Data Strobe will always arrive at a known constant rate. Full FIFO buffering is not needed. Recall some of the basic guide lines and numbers that are involved in this system. HDMP-1012 G-Link timing Data_00 : Data_19 , DAV* and all that stuff must be valid a minimum of 6 nsec before the rising edge of STRBIN (its frame clock) and there is a 0 nsec hold time requirement HSRO Data_00 : Data_19 and DAV* are clocked out of the Spark FPGA by the RF_Clk. STRBIN to the G-Link is the RF_Clk. Spark Timing Basic Numbers 53.104 MHz is 18.83 nsec 5x 18.83 nsec is 94.15 MHz which is 10.62 MHz If you run that against a 10.00 MHz Xmit_Clk then 10.00 MHz is 100.0 nsec so the Xmit_Clk is 5.85 nsec longer on each cycle than 5 RF_Clk's. 4x 18.83 nsec is 75.32 nsec which is 13.276 MHz If you run that against a 12.50 MHz Xmit_Clk then 12.50 MHz is 80.00 nsec so the Xmit_Clk is 4.68 nsec longer on each cycle than 4 RF_Clk's. 3x 18.83 nsec is 56.49 MHz which is 17.70 MHz If you run that against a 16.00 MHz Xmit_Clk then 16.00 MHz is 62.5 nsec so the Xmit_Clk is 6.01 nsec longer on each cycle than 3 RF_Clk's. 62.5 nsec is still long enough so that 62.5/2 = 31.25 nsec which is significantly longer than an 18.83 cycle so both the HI and Low states of the Distributor Cap Data Strobe will be ingested by the Spark's RF clocked latches. We want to move to using a 25 MHz crystal on the Distributor Cap which would give a 12.50 MHz Xmit_Clk. This should be a comfortable fit in the ERPB's and the Spark timing. General Rules and Information and Observations: Want data to setup on the bus to the G-Link for a good fraction of the cycle. Running with a 12.50 MHz Xmit_Clk we should have data setup to the G-Link for 3 cycles of RF_Clk and then issue the DAV* in the 4th cycle of RF_Clk. Want to sample the Data_Strobe with the RF_Clk only in one place. (make one decision and then use it everywhere) Do it in a way that avoids meta-stability problems. Note that the asserted state of Data Strobe is always guaranteed to last for => 2 RF Clocks so you are guaranteed to capture it. Having Data Strobe asserted and negated for => 1 RF clock in each state should be good enough to guarantee that Spark always sees both states. The timing of data output from the Distributor Cap vs Data_Strobe is setup to be optimal, i.e. the data settles for about 2/3 of the cycle before the leading edge of the Data_Strobe and holds for about 1/3 of a cycle after the leading edge of Data_Strobe. Data is captured in the Spark by the leading edge of Data_Strobe. Then, a minimum of 18.8 nsec and a maximum of 37.6 nsec later it is transfered to the RF_Clk timing domain. I.E. there is no chance of a race getting it to the RF_Clk domain. Data_Strobe is sampled by RF_Clk in only one place and in a way that has zero meta stability problems. All further use of Data_Strobe is based on this sampled version of Data_Strobe. Data is sent to the G-Link for 3 cycles of RF_Clk and then in the 4th cycle the DAV* is asserted. During the 5th cycle of RF_Clk new data may be sent to the G-Link. See book #4 page 272 for P5 I/O to FPGA pin numbers and which pins are clock nets on the 4036XLA. An issue is that the Data Strobe from the Distributor Cap does not go to a global clock net in the 4036XLA. Making a Monitor Data Copy of the Spark's HSRO Data ------------------------------------------------------- Current Rev. 4-JULY-2003 To buffer the full HSRO data transfer (L2 Header, Rack TT Et data, L2 Mask, L2 Trailer) requires 152 words of 2 bytes each. If you make the Monitor Data FIFO 256 x 2 bytes it will require about 10% of the CLB's in the 4036XLA device. The intent is to capture in the Monitor Data FIFO an exact copy of the data that is sent to the HSRO. The 16 bit wide write data to the Monitor Data FIFO is a straight copy of what is sent to the HSRO. The "write enable" to the Monitor Data FIFO is initiated by the DAV* signal to the HSRO. The Monitor Data FIFO is implemented as a single port edge triggered RAM and will not support simultaneous write and read. The Spark Monitor Data FIFO will function in the following way: o When enabled by a bit in a control register, the Capture Monitor Data signal will start the following sequence of events: - The Capture Monitor Data signal will immediately cause the the FIFO Address Counter to reset to zero. - Each DAV* to the HSRO will cause the associated 16 bits of HSRO Data to be written into the Monitor Data FIFO. - This operation will continue until 1000 nsec have gone by without a DAV* (i.e. without a write to the Monitor Data FIFO). - This period of 1000 nsec without a DAV* will be interpreted as "End of Event". - Once the End of Event has been detected, no further writes to the Monitor Data FIFO are allowed until another Capture Monitor Data signal has been received. o At some convenient time after the above sequence, TCC can cause the FIFO Address Counter to reset to zero. Note that at anytime TCC can read the current value of the FIFO Address Counter. So if it wants to, TCC can first verify that the Monitor Data FIFO has been written to with the expected number of words, before it resets this address counter back to zero in preparation for reading the Monitor Data. o By reading a normal register location (with a normal VME read cycle) TCC can read the data from the Monitor Data FIFO location that is currently pointed to by the FIFO Address Counter and at the conclusion of this read cycle the FIFO Address Counter will automatically increment. Note that the data in the Monitor Data FIFO is only lost when it is over-written. If TCC wants to it can re-read a given event. Notes: 26-SEPT-2003 Allow TCC to load any value into the FIFO Adrs Counter instead of just resetting it to zero. Add a counter comparator and register bit to the Spark so you know if it received the correct number of data strobes from the distributor cap. Move Spark so that it has the same type of error and control status register bits as the rest of the HSRO stuff in TFW has.