Status for BUFFER MANAGEMENT Firmware FPGA Centric Dataflow Erdem Motuk 17 October 2019
• Current status • Immediate plans • Proposed changes 2
• The buffer management block has been developed and debugged independently from the other parts of the firmware • Assuming a 40-way(pipeline) input as the event data from the compression block and another input as the event selection request from trigger selection block • The inputs and outputs follow the AXI-stream designations for the Upstream DAQ firmware • The first version of the firmware has been added to the GIT repository • It is to be tested again independently but by using more realistic input data supplied by the IPBUS • It is instantiated as a module in the payload section of the framework-1fibre project source code 3
• Block diagram for testing the buffer management 4
• Block diagram showing the actual position of the buffer management in the Upstream DAQ firmware 5
• Entity declaration showing inputs and outputs to the firmware block 6
• Wave diagram showing the event data input 7
• Wave diagrams showing the event selection commands (input) and the event data fragments (output) • The structure of the payload 8
• The resource usage for the buffer management block (for the FPGA on the ZCU102 board): BRAM Tile : 82 out of 912 CLB LUTs : 23788 out of 274080 CLB Regs: 25237 out of 548160 CLBs : 4861 out of 34260 DSPs : 3 out of 2520 9
• The two proposed changes to the current firmware are : 1. Adding a TUSER(1) signal to delineate every 64-channel sequence (64 wires assigned to each processing block/pipeline) • 64 packets each having 64 ticks of ADC data makes a “super packet”. • These “super packets” will be stored in the memory intact • An integer number of super packets will form a block in the memory (for writing and reading) • This will increase the BlockRAM usage in the firmware slightly • The input FIFOs currently have the size 16-bit x 512 – 1 36K BRAM • The new size should be 16-bit x 4096 – 2 36K BRAMs 10
2. Adding a FIFO to index the super packet blocks (event fragments) • Previously discarded because the blocks were smaller • This simplifies the write and read address generation • If the smallest event fragment is defined to be 8 then a several MBits of FPGA memory would be needed • This number is big for the ZCU102’s FPGA but could be ok for the actual upstream DAQ FPGA • Size of event fragments can be increased? 11
• Next steps • Adding IPBUS input/output FIFOs for event selection requests, event data and event fragments • Adding the proposed changes to the firmware • Integration with the compression block • Implementation on the final FPGA 12
Recommend
More recommend