1. Zero–suppressed FIFO architecture: functionality and performance Sara Marconi, Pisana Placidi

2. OUTLIN E 2/19 Intro: the VEPIX53 framework –Block diagram and interfaces –Simulation of digital blocks Zero-suppressed FIFO architecture in details –Block diagrams –Timing diagrams Performance study (focus on PR 4x4 and zero-suppressed FIFO architecture) –Buffer occupancy and locations –Loss due to deadtime –Other considerations (other architectures/PR configurations) Conclusions

3. 3/19 TLM port TLM exportTLM analysis port/export TEST SCENARIO TESTBENCH TOP MODULE virtual sequencer hit UVC trigger UVC test library output UVC analysis UVC reference model scoreboard Design Under Test (DUT) hit_if trigger_if analysis_if output_if sequencer driver subscriber monitor driver sequencer monitor subscribers monitor Top-module: system (DUT) connected to environment through a set of interfaces Testbench: UVM re-usable verification components Test Scenario: defines configuration of verification components and the tests to be run during simulation The VEPIX53 framework - Block diagram and interfaces (I)

4. 4/19 SystemVerilog interfaces between UVM components and DUT for: – hit generation and injection – monitoring of pixel chip input and output – conformity checks and statistics collection Interfaces and transactions currently defined: TRANSACTION LEVEL Hit interface Analog input hit signal Trigger interface Input trigger signal Output data interface Pixel chip output Analysis interface (optional) Virtual flag signals related to DUT status for statistical information collection (dead time, buffer occupancy, …) hit_trans +time_ref: int +hits: hit [] hit struct: +charge: unsigned int +delay: unsigned int +col: unsigned int +row: unsigned int trigger_trans +time_ref: int ouput_data_trans ouput_data_trans_hits +time_ref: int +hits: hit [] analysis_trans... DUT-specific data members... The VEPIX53 framework - Block diagram and interfaces (II)

5. 5/19 Digital blocks DUT: specific digital blocks to be inserted in the complete system Identification of metrics of interest on which collect statistics (deadtime, buffer occupancy..) Interfaces: specific analysis and output data monitors Goal: study of first level trigger latency buffering architectures for Pixel Regions (PR) System level simulation and verification – Simulation of digital blocks

6. 6/19 Zero-suppressed FIFO architecture - Block diagrams – Pixel Region Pixel Region (PR) input hits Write logic token in trigger mask_in PUC … parallel_out[3:0] r_edge/pixel_idle/ pixel_ready Buffer (FIFO) Deram packet_out (ToA+hitmap +ToT) trigger matching logic external counter dout (ToA,hitmap+ ToT) ack we token out request … clk reset ack r_edge_or Pulse generator (abstract) disc Config reg Digital PUC PUC Pulse generator (abstract) disc Config reg Digital PUC Pulse generator (abstract) disc Config reg Digital PUC NxM Pixel Unit Cells (PUCs) analog interface (behavioural conversion from charge/ToT to discr output) digital hit logic Common write and storage logic manages common access to FIFO parallel signals to buffer (ToA, hitmap, NxM ToT) FIFO (behavioral –SV queue) Trigger matching logic (behavioral – part of buffer module) match, delete or store based on trigger and external counter Derandomizer (behavioral –SV queue) signals “anticipating” a basic token passing scheme output packet still containing ToA and hitmap

7. 7/19 Zero-suppressed FIFO architecture – Block diagrams – Digital PUC Config reg discr sync logic FSM (states: IDLE,COUNTING, READY, BLIND) clk reset mask in mask out ack/r_edge_or r_edge pixel_idle pixel_ready ToT counter count enable/ clear parallel out [3:0] Digital Pixel Unit Cell Pixel config register: only 1 bit (masking) Synchonization logic (one flip flop, see timing diagram) Finite State Machine (FSM) defined per pixel 4 states communicates with PR write logic 4-bit ToT counter (binary) with parallel out to common PR logic

8. 8/19 Zero-suppressed FIFO architecture – Block diagrams – Digital PUC Config reg discr sync logic FSM (states: IDLE,COUNTING, READY, BLIND) clk reset mask in mask out ack/r_edge_or r_edge pixel_idle pixel_ready ToT counter count enable/ clear parallel out [3:0] Digital Pixel Unit Cell Pixel config register: only 1 bit (masking) Synchonization logic (one flip flop, see timing diagram) Finite State Machine (FSM) defined per pixel 4 states communicates with PR write logic 4-bit ToT counter (binary) with parallel out to common PR logic Note: no clock gating implemented in the code (clock always running)

9. 9/19 Zero-suppressed FIFO architecture – PUC Finite State Machine Rising edge (from synch logic) starts COUNTING Falling edge (from synch logic) leads to READY  ready to be read from write logic Ack signal from write logic brings back to IDLE NB: if another pixel in PR counting from previous BXs, pixel is BLIND  limit of the architecture

10. 10/19 Zero-suppressed FIFO architecture – Timing diagrams - PUC Finite State Machine Timing diagram of FSM behavior for 2 pixels First pixel processes a short (1 clock cycle) hit pulse: rising edge COUNTING enable count clear count to 0 (back to 1 only after ToT reading) flags: pixel idle, pixel ready ack from PR logic Second pixel is BLIND during COUNTING and READY of the other

11. 11/19 Zero-suppressed FIFO architecture – Block diagrams – Write logic Rising edges from pixels control storage of ToA (from external counter) in PR local register Rising edge OR also going back to pixels to provoke BLIND state if necessary PUC flags (pixel ready) used to control global write enable to buffer hit map generator «labels» pixels which have been hit additional bit (inefficient) Output packet (described as a SV struct): single ToA parallel ToT from each pixel (additional) hit map r_edge ToA register EXT CNT ToA_out PR Write Logic hit map generator combinational logic PUC flags (pixel_idle, pixel_ready) wr_en_global ToT_out r_edge_or HIT PACKET ack_in ack_out

12. 12/19 Zero-suppressed FIFO architecture – Timing diagrams – Write logic … Example with a 2x2 PR (for clarity) Rising edge from pixels control load of ToA (from external counter) in PR local register pixel not ready When all pixels ready packet output is complete with ToA, ToTs (and hit map) write enable to buffer ack to all the pixels

13. 13/19 Zero-suppressed FIFO architecture – Timing diagrams – FIFO and deran Examples of buffer functionality: −write enable from write logic puts (push_front) elements in the queue −ack sent back to pixels −buffer content is deleted when ToA gets too old and no trigger match seen −buffer content is sent to dout if trigger match seen (pop_back) – not shown Examples of derandomizer arbitration (synchronous token passing scheme): −request if anything received from buffer_in −token_in −writing to buffer_out −token_out to next PR

14. 14/19 Performance study – Buffer occupancy and locations (I) DUT (subset under study): 4 x 4 PR, zero-suppressed FIFO architecture Hit rate: 2 GHz/cm 2, trigger latency: 10 µs Full pixel matrix (hit generation): 512 x 512 pixels, pixel size 50 x 50 µm 2 Sensor thickness: 100 µm Simulation run for 500,000 BX cycles (10,000 hit packets into PR buffer) Class of hits generated: internal (tracks, track angle 90° with charge sharing, 38% hit pixels)

15. 15/19 Performance study – Buffer occupancy and locations (II) Goal: determining number of buffer locations needed to keep buffer overflow probability under a certain % Note: results on hit rate 3 GHz/cm 2 with Montecarlo data to be produced (not presented so far for the zero- suppressed FIFO architecture) DUT (subset under study): 4 x 4 PR, zero-suppressed FIFO architecture Hit rate: 2 GHz/cm 2, trigger latency: 10 µs Full pixel matrix (hit generation): 512 x 512 pixels, pixel size 50 x 50 µm 2 Sensor thickness: 100 µm Simulation run for 500,000 BX cycles (10,000 hit packets into PR buffer) Class of hits generated: internal (tracks, track angle 90° with charge sharing, 38% hit pixels)

16. 16/19 Performance study – Buffer occupancy and locations (III) Optimum configurations in terms of buffer locations (at behavioral level): between 2x2 and 4x4 for both architectures DUT (subset under study): zero-suppressed FIFO and distributed latency counters architecture, different pixel region configurations Hit rate: 2 GHz/cm 2, trigger latency: 10 µs Full pixel matrix (hit generation): 512 x 512 pixels, pixel size 50 x 50 µm 2 Sensor thickness: 100 µm Simulation run for 500,000 BX cycles (10,000 hit packets into PR buffer); + comparison with analytical results Class of hits generated: internal (tracks, track angle 90° with charge sharing, 38% hit pixels)

17. 16/19 Performance study – Buffer occupancy and locations (III) DUT (subset under study): zero-suppressed FIFO and distributed latency counters architecture, different pixel region configurations Hit rate: 2 GHz/cm 2, trigger latency: 10 µs Full pixel matrix (hit generation): 512 x 512 pixels, pixel size 50 x 50 µm 2 Sensor thickness: 100 µm Simulation run for 500,000 BX cycles (10,000 hit packets into PR buffer); + comparison with analytical results Class of hits generated: internal (tracks, track angle 90° with charge sharing, 38% hit pixels)  Important role of implementation related considerations (type of storage resources, area, routing, power…) Optimum configurations in terms of buffer locations (at behavioral level): between 2x2 and 4x4 for both architectures

18. 17/19 Performance study – Loss due to pixel deadtime Zero-suppressed FIFO and distributed latency counters architecture Pixel region configurations investigated for each architecture: 1x1, 2x2, 4x4 10 µs trigger latency Simulations with external hit patterns from simulation data Hit loss rate due to pixel/pixel region dead time Limit of the architecture (as implemented in VEPIX53) due to common management/writing to single FIFO: hit loss due to pixel region deadtime is not negligible and gets worse with increasing PR size.

19. 18/19 Performance study – Other considerations Comparison with other architectures: Distributed latency counters (FEI4-like) −Advantage: TOT storage distributed in single pixels (each pixels contains a number of register for TOT equal to the number of locations in the PR buffer)  not single memory to be written all at once but memory locations always accessible through addresses  NO BLIND problem −Disadvantage: regional use of counters (as many as the buffer locations)  power FE65P2 (Bonn prototype): scheme not too different from classical trigger matching −Advantages: −same TOT storage distributed in single pixels as FEI4  NO BLIND problem − no counters in regions, but 2 latency counters  routed from cores (multi-column) −Disadvantage: use of flip-flops for storage  more area and power compared to latches Final considerations/questions: Zero suppressed FIFO has also advantages related to absence of regional counters (power) Potential further improvements: use latches for storage (power, area); create more compact 4 or 8-bit latches and profit from grouping storage elements… (extimated gain ~ 20-30% with static logic) BLIND problem for the zero-suppressed FIFO scheme for relatively big PRs: −Using smarter pixel/PR logic to overcome the problem?

20. CONCLUSIONS Zero-suppressed FIFO architecture in VEPIX53 –Behavioral description of the pixel region (parametrized size) implemented as a digital block in one version of the DUT (wrapper) –FIFO, derandomizer implemented in a strongly behavioral fashion (not synthesizable) –Block diagrams and timing diagrams of current implementation presented –Performance study performed at behavioral level presented Choice of number of buffer locations needed depends on such simulations PR deadtime: main problem of the zero-suppressed FIFO architecture Further developments: –Importance of implementation-related issues  need to move to RTL description and synthesis Expected gain from use of latches (level-sensitive logic in RTL): to be implemented and simulated (also in terms of power profile after synthesis and P&R  work in progress on getting such a machinery) Optimization of architecture to overcome PR deadtime problem Somebody working on compact layout of bigger latches 19/19

21. BACKUP 21

22. 22/19 Project organization Verification environment contains TESTBENCH classes (re-usable) As for other trigger latency buffering architectures (for PRs), the zero suppressed FIFO architecture uses a separate directory for: DUT files UVM test files (defining the TEST SCENARIO) custom UVM classes (overriding the verification environment components if needed) … VEPIX53 verification environment independent pixels architecture zero suppressed fifo architecture fei4 distributed latency counters architecture hit output data analysis trigger top verification environment hit, trigger, output data, analysis: corresponding to interfaces to DUT a UVM verification component (UVC) for each of them in the environment top level UVM verification components The VEPIX53 framework – Simulation of digital blocks (II)

23. 23 System level simulation and verification – Full chip simulation (II) Need to adapt DUT-specific interfaces: –hit interface: matrix of pixels directly connected –trigger interface: –both configuration and trigger commands –adapted overriding classes though UVM factory (sequence, tlm2sig driver) –output data interface: –conversion of multiple FEI4-specific HIT output packets to a unique generic output data hit transaction –adapted overriding the sig2tlm monitor Top level coordination: –virtual sequence launches automatically the new trigger sequence (overridden in test)

24. 24 System level simulation and verification – Full chip simulation (II) Need to adapt DUT-specific interfaces: –hit interface: matrix of pixels directly connected –trigger interface: –both configuration and trigger commands –adapted overriding classes though UVM factory (sequence, tlm2sig driver) –output data interface: –conversion of multiple FEI4-specific HIT output packets to a unique generic output data hit transaction –adapted overriding the sig2tlm monitor Top level coordination: –virtual sequence launches automatically the new trigger sequence (overridden in test) FEI4 DUT-specific classes overriding basic ones kept separate in the DUT-specific directory (not in reusable VE) define UVM custom classes tests harness work (simulation folder)

25. 25 System level simulation and verification – Full chip simulation (II) Need to adapt DUT-specific interfaces: –hit interface: matrix of pixels directly connected –trigger interface: –both configuration and trigger commands –adapted overriding classes though UVM factory (sequence, tlm2sig driver) –output data interface: –conversion of multiple FEI4-specific HIT output packets to a unique generic output data hit transaction –adapted overriding the sig2tlm monitor Top level coordination: –virtual sequence launches automatically the new trigger sequence (overridden in test) Overridden through the tests: class top_test3 extends top_base_test; … virtual function void build_phase(uvm_phase phase); … trigger_master_driver_tlm2sig::type_id::set_type_override (cmd_driver_fei4_tlm2sig::get_type()); trigger_monitor_sig2tlm::type_id::set_type_override (trigger_monitor_fei4_sig2tlm::get_type()); trigger_sequence::type_id::set_type_override (conf_sequence_fei4::get_type()); output_data_monitor_sig2tlm::type_id::set_type_override (output_data_monitor_fei4_sig2tlm::get_type()); … endfunction: build_phase … endclass: top_test3

26. 26 USERGUIDE: How to run a simulation System level simulation and verification - How to run a simulation (I) VEPIX53 up and running on GIT repository: –clone project from https://USER@git.cern.ch/reps/VEPIX53 (request access for new USERs)https://USER@git.cern.ch/reps/VEPIX53 –web interface: https://git.cern.ch/web/VEPIX53.githttps://git.cern.ch/web/VEPIX53.git Software tools needed: –Cadence Incisive (13.2 currently used) –ROOT (if importing ROOT inputs is of interest) define UVM custom classes tests harness work (simulation folder) DUTx Relevant files: –Makefile and Makefiles.defs contain environment variables, command definitions, pointers to files to be compiled, simulation options… –in the work directory: DUT-specific Launching a simulation: go to work directory (of one DUT) make clean (removes previous simulation files,...) make plib (compiles design library) make run1 (generates primary snapshot – saving elaboration time) make run2 (generates secondary snapshot and runs) OR make rungui to open GUI interface and run from there

27. 27 System level simulation and verification - How to run a simulation (II) Modifying test scenario (I): –in the test, configuration object fields are set –a configuration object is used for the different UVCs (can be found in the corresponding UVC directory) –example: analysis configuration object –such fields are read by the analysis UVC at the beginning of the simulation (can be accessed/modified at any time) –code is commented class top_test3 extends top_base_test; … virtual function void build_phase(uvm_phase phase); … m_analysis_cfg.add_master("m_analysis_agent", // name of the analysis master agent UVM_PASSIVE, // no driver in the agent 1 // monitoring internal DUT status ON (1) 1, // dump buffer occupancy ON (1) 0, // dump classification of lost hits ON (1) ); endfunction: build_phase … endclass: top_test3

28. 28 System level simulation and verification - How to run a simulation (III) Modifying test scenario (II): –in the test, also sequences are configured –top level, hit and trigger sequence: i.e. you configure inputs –example: some fields of the hit sequence –a remark: UVM allows you to set in the test any field of any component of the environment (not only sequences) class top_test3 extends top_base_test; … virtual function void build_phase(uvm_phase phase); … uvm_config_db#(hit_config) ::set(this, "*.*.m_hit_seq", "m_hit_cfg", m_hit_cfg); uvm_config_db#(int) ::set(this, "*.*.m_hit_seq", "num_bx_cycles", 50000); uvm_config_db#(int) ::set(this, "*.*.m_hit_seq", "particle_angle_deg", `PARTICLE_ANGLE_DEG); uvm_config_db#(real) ::set(this, "*.*.m_hit_seq", "sensor_thickness", `SENSOR_THICKNESS_um); uvm_config_db#(real) ::set(this, "*.*.m_hit_seq", "pixel_pitch", 50); uvm_config_db#(csharing_level_t)::set(this, "*.*.m_hit_seq", "csharing_level", LEV_ZERO); … endclass: top_test3

29. 29 System level simulation and verification - How to run a simulation (III) Modifying test scenario (II): –in the test, also sequences are configured –top level, hit and trigger sequence: i.e. you configure inputs –example: some fields of the hit sequence –to make test more readable often configuration values are set through `DEFINES (instead of directly numbers) –`DEFINES related to the verification environment are listed in the class_defines.sv file in the DUT-specific define directory class top_test3 extends top_base_test; … virtual function void build_phase(uvm_phase phase); … uvm_config_db#(hit_config) ::set(this, "*.*.m_hit_seq", "m_hit_cfg", m_hit_cfg); uvm_config_db#(int) ::set(this, "*.*.m_hit_seq", "num_bx_cycles", 50000); uvm_config_db#(int) ::set(this, "*.*.m_hit_seq", "particle_angle_deg", `PARTICLE_ANGLE_DEG); uvm_config_db#(real) ::set(this, "*.*.m_hit_seq", "sensor_thickness", `SENSOR_THICKNESS_um); uvm_config_db#(real) ::set(this, "*.*.m_hit_seq", "pixel_pitch", 50); uvm_config_db#(csharing_level_t)::set(this, "*.*.m_hit_seq", "csharing_level", LEV_ZERO); … endclass: top_test3 define UVM custom classes tests harness work (simulation folder) DUTx

30. Arbitration scheme and main features/differences of FE-I4 and FE65P2 Sara Marconi

31. OUTLIN E 2 FE65P2 pixel region –Architecture and main signals FEI4/FE65P2 arbitration scheme –Hierarchical structure –Read control FSM (from FE65P2) Main differences with respect to FE-I4 –Region level –Full chip

32. 32 FE65P2 pixel region – Architecture (I) 2x2 PR: −Each PUC: analog, pixel pre-input (SR for configuration), pixel input (ToT counting+storing) −pixel local memory −controls write/read of ToT count −receives and produces trigger and token-related signals −controls writing of hit data to data bus −Data Bus of 16 bits implemented as daisy- chained OR gates (to avoid to drive large wire load) −Hit-OR propagated to higher hierarchy Pixel Region (PR) input hits (L/R) analog0 (abstract) analog1 (abstract) analog2 (abstract) analog3 (abstract) pixel pre-input1 pixel pre-input2 pixel pre-input3 TestHit disc pixel input0 pixel input1 pixel input2 pixel input3 disc HitOr pixel local memory TokIn/LE/L1Trig (active low – L1TrigInv active high)/TrigId[3:0] /TrigIdReq [3:0] /Read LatCnt[8:0]/ LatCnt2[8:0] DataFrom Top[15:0] DataTo Bottom [15:0] enableOutput (&PixOffCnfg) data[3:0] LEaddr, read (to control output from local reg) TokOut enBusBuf TokPos pixel pre-input0 clkSR,EnableSR,InSr,DefCo nf, InjEnLd,SignLd,TDacLd, PixConfLd trigger and token related signals

33. Pixel Pre Input PixCnfgLatches TDacLatches SignLatch InjEnLatch OutSR reg

34. 34 Pixel Input clk/reset LE disc read (from local mem) wLE data [3:0] Pixel Input −4-bit asynchronous counter (toggle FF) started by count enable −7 4-bit registers for saving ToT value −Delay controls sequence of operations −free LE_addr copied in local mem_addr −starts count enable −controls copying counter value to free TOT register in mem_addr reg) −readout controlled by read from the local memory in PR −wLE ORed in PR providing regional LE disc delay (cascade 3FF) clk gating 4-bit asynch counter (TT- FF) 4-bit registers (tot_mem) read[0] … mem_addr reg LE_addr (from local mem) read[6] tot cnt cnt_en wsTeN wLE FE65P2 pixel region – Architecture (II)

35. 35 Pixel Local Memory −7 pixel memory cells: −with clock gating (cloked only if writing LatCnfg or when latency expires) −save LatCnfg in a register and when latency expires, i.e. LatCnfg=LatCnfg2, trigger id (L1in) saved in same reg −trigger matching: when trigger L1 arrives, L1req (trigger being examined by read control) compared with L1in in cells where hits have been triggered −addr decoder looks for empty memories and produces free addr −read decoder (1 bit/memory) tells which memory to read from PUCs (if many triggered, priority based on order ) FE65P2 pixel region – Architecture (III) Pixel Local Memory clk, reset LE L1,L1in[3:0]/ L1req [3:0] LatCnfg [8:0] LatCnfg2[8:0] TokOut 7 pixel memory cells TokIn read[6:0] LE_addr[M EM-1:0] readData en_out enBusBuf triggered full free LE address output enable logic token rise token save Read decoder clk gating … addr decoder … trigger and token related signals −Token “passing” (daisy-chain of OR gates): −token rise if any memory cell triggered −if TokIn = 0 (no previous PR raised it) enable output to write to data bus (when readData received) −token is dropped only when every pixel memory cell has been read (e.g. if previous PR is being served, waits high) −propagation time = OR chain propagation delay −token position identified through token save (sent through enBusBuf)

36. 36 Multi column −contains 64 regions (multi-column: 4x64 pixels per column) −OR gates for Token and data bus signals just connected in a chain −contains row address encoder (address derived from TokPos) Chip core −Column control (one for each column) same OR mechanism (token chain) for TokInChip and TokInCol to produce TokOutChip (priority for “previous” columns) from readChip, ReadCol generated for identifying multi-column to be read (if no previous column being read) column address (4-bit for 16 multi columns) also propagated through OR-chain FEI4/FE65P2 arbitration – Hierarchical structure (I) Simplified schematic end of column signal routing in EODCL [FE-I4 manual] from previous multi column OR-ed with “token rise” from current column and propagated to next multi-column Multi column Chip core token rise (last region of this col)

37. 37 FEI4/FE65P2 arbitration – Hierarchical structure (II) (…) Chip core −contains 2x9bit latency gray counters (shifted by latency) −OR of Data [15:0] from columns (written if ReadCol) −OR of row address [5:0] from columns −output data [NOT LOOKED INTO IN DETAILS] −fifo: data sent at once are Col, Row, 2xToT −FSM −framing/encoding 8b10b −serializer −Read control −FSM manages: waiting trigger, waiting token and enabling chip read signal −Relevant signals: −TriggerBcId (from 24-bit BC-ID counter) −TriggerId (corresponding to last trigger received) −TriggerIdReq (corresponding to trigger being processed: while waiting token rise or during readout) −Read same for all columns and regions

38. 38 FEI4/FE65P2 arbitration – Read control FSM Read control Finite State Machine of FE65P2 −DelayCnt counter: −waiting time to enable token wait and readout −set to 0 in START states −Read signal to all chip: enabled from negedge READ START to end of READ (posedge) −until there is a token raised from one PR → staying in READ for the same TriggerIdReq −if no further Token: TriggerId ≠ TriggerIdReq → new trigger already received, directly go in TOKEN WAIT START; otherwise → go back to TRIGGER WAIT TRIGGER WAIT TOKEN WAIT START READ START READ DelayCnt=0 can exit only when DelayCnt==2 and if output fifo Ready 2.TriggerIdReq ≠TriggerId 1. Token can exit only when DelayCnt==2 and if output fifo Ready 1. Token 2.TriggerIdReq ≠TriggerId 3. Trigger

39. 39 Main differences between FE-I4 and FE65P2: at the region level: −in FE-I4 daisy-chain of OR gates triplicated for redundancy with majority voting (i.e. TokIn, TokOut were 3-bit signals) −RTL from FE65P2 does not have such a triplication −in FE-I4 pixel memory cells contained a latency counter (TT-FF) −in FE-I4 pixel memory cells were less (5 vs 7) −in FE-I4 there was some “neighbor” logic FE65P2 has simplified readout: −output data bus was 25 bit (16 + 4 for neighbors + 5 for hamming error protection)  more complex row address encoder −address bus was 11 bit (8 + 4 protection bits) organized with thermal gray encoding to minimize number of gates used to produce address  more complex column encoder Chip inputs for slow/fast controls −FEI4 with serial link for both −prototype with separate trigger + multiple signals for configuring pixel reg Redundancy + majority voting in FE65P2: in RTL, seen only in FSM for data output (also NOT in readout control) Main differences with respect to FE-I4