This feature resolves issue #115 by adding a histogram block to DragonPHY. This is intended to be used to study ADC noise, examine the bimodal distribution of data at the FFE output, and possibly to construct eye diagrams. Users can specify the histogram input to be: (1) any ADC output (including replicas), (2) any FFE output, and (3) an on-chip data generator. This last option can produce data with various distributions, for histogram.
The implementation includes two small SRAMs (each 256x64). I thought about instantiating the exact same SRAM that is already used for waveform capture (1024x144), but since that SRAM is 9x larger than what is needed for the histogram, I figured it would be worth it to generate another SRAM. I updated the mflowgen steps accordingly through synthesis, but affected PnR steps such as floorplanning will have to be updated by someone with process access (that person should also take a look at the new mc-gen-sram-small step to make sure it's right).
Note: this PR is independent from PR #114 and they can be merged in either order.
Details
The histogram is implemented using SRAM, where each memory address corresponds to one possible value of the ADC output. Since the SRAM is single-port, incrementing the value at a particular memory address is a two-cycle process. Hence, two SRAMs are used in an alternating fashion to log all of the incoming data. When the user reads the histogram value at a particular address, the outputs of both SRAMs at that address are summed.
The histogram feature is used by setting hist_mode to RESET, then CLEAR for a short period of time to clear the SRAMs (1us is plenty), and finally RUN to capture data. When the user is ready to read the histogram, they change hist_mode to FREEZE, which stops the histogram from updating. The hist_count at each address can be read out, as well as the hist_total of all addresses. These values are 64-bit, which would allow for hundreds of years of operation without overflowing (for the true aficionados of distribution tails :-)). Each 64-bit value is split into 32-bit upper and lower JTAG registers.
Histogram addresses should be interpreted in twos-complement when working with ADC or FFE data, which is signed. So the address 8'b11111111 (255) refers to an ADC output of -1.
The source of histogram data can be selected using the hist_source and hist_src_idx JTAG registers. For hist_source, 0 means "ADC", 1 means FFE, and 3 means the data generator used for BIST. (If we have any outputs from MLSD that could be logged using a histogram, those could be mapped to 2). The hist_src_idx setting only applies when the source is "ADC" or "FFE", in which case it references to the ADC slice / FFE channel. For the ADC, indices 16 and 17 are replica ADCs. It might be interesting to monitor the noise histogram of a replica with and without the other ADCs running to study power supply noise.
The BIST data generator is mainly controlled by JTAG registers data_gen_mode, data_gen_in_0, and data_gen_in_1. When data_gen_mode is UNIFORM, the data generator produces a uniform distribution between 0-255. This data stream is not pseudorandom; the values are simply produced sequentially. Another mode is CONSTANT, where the data generator produces a steady value of data_gen_in_0. INCL is a more general version of UNIFORM, producing a uniform distribution between data_gen_in_0 and data_gen_in_1. EXCL is the opposite of INCL, producing values outside the interval between data_gen_in_0 and data_gen_in_1. Finally, ALT alternates between data_gen_in_0 and data_gen_in_1 on every cycle of clk_adc.
I added new mflowgen steps to generate the smaller SRAM: openram-gen-sram-small and mc-gen-sram-small. The openram-gen-sram-small step is exercised through our regression testing flow, but I do not have a way to test mc-gen-sram-small myself, since I do not have process access.
I am using the System clock domain for all of the JTAG registers (input and output) related to the histogram. I am assuming this synchronizes I/O to clk_adc -- it is particularly important that hist_mode is synchronized, since otherwise the transitions in the histogram state machine could be messed up. (We should confirm what synchronization is being done -- maybe @zamyers would know?)
Summary
This feature resolves issue #115 by adding a histogram block to DragonPHY. This is intended to be used to study ADC noise, examine the bimodal distribution of data at the FFE output, and possibly to construct eye diagrams. Users can specify the histogram input to be: (1) any ADC output (including replicas), (2) any FFE output, and (3) an on-chip data generator. This last option can produce data with various distributions, for histogram.
The implementation includes two small SRAMs (each 256x64). I thought about instantiating the exact same SRAM that is already used for waveform capture (1024x144), but since that SRAM is 9x larger than what is needed for the histogram, I figured it would be worth it to generate another SRAM. I updated the mflowgen steps accordingly through synthesis, but affected PnR steps such as floorplanning will have to be updated by someone with process access (that person should also take a look at the new
mc-gen-sram-smallstep to make sure it's right).Note: this PR is independent from PR #114 and they can be merged in either order.
Details
hist_modetoRESET, thenCLEARfor a short period of time to clear the SRAMs (1us is plenty), and finallyRUNto capture data. When the user is ready to read the histogram, they changehist_modetoFREEZE, which stops the histogram from updating. Thehist_countat each address can be read out, as well as thehist_totalof all addresses. These values are 64-bit, which would allow for hundreds of years of operation without overflowing (for the true aficionados of distribution tails :-)). Each 64-bit value is split into 32-bitupperandlowerJTAG registers.8'b11111111(255) refers to an ADC output of-1.hist_sourceandhist_src_idxJTAG registers. Forhist_source,0means "ADC",1means FFE, and3means the data generator used for BIST. (If we have any outputs from MLSD that could be logged using a histogram, those could be mapped to2). Thehist_src_idxsetting only applies when the source is "ADC" or "FFE", in which case it references to the ADC slice / FFE channel. For the ADC, indices16and17are replica ADCs. It might be interesting to monitor the noise histogram of a replica with and without the other ADCs running to study power supply noise.data_gen_mode,data_gen_in_0, anddata_gen_in_1. Whendata_gen_modeisUNIFORM, the data generator produces a uniform distribution between 0-255. This data stream is not pseudorandom; the values are simply produced sequentially. Another mode isCONSTANT, where the data generator produces a steady value ofdata_gen_in_0.INCLis a more general version ofUNIFORM, producing a uniform distribution betweendata_gen_in_0anddata_gen_in_1.EXCLis the opposite ofINCL, producing values outside the interval betweendata_gen_in_0anddata_gen_in_1. Finally,ALTalternates betweendata_gen_in_0anddata_gen_in_1on every cycle ofclk_adc.openram-gen-sram-smallandmc-gen-sram-small. Theopenram-gen-sram-smallstep is exercised through our regression testing flow, but I do not have a way to testmc-gen-sram-smallmyself, since I do not have process access.Systemclock domain for all of the JTAG registers (input and output) related to the histogram. I am assuming this synchronizes I/O toclk_adc-- it is particularly important thathist_modeis synchronized, since otherwise the transitions in the histogram state machine could be messed up. (We should confirm what synchronization is being done -- maybe @zamyers would know?)