In ButterPHY, we used a custom nettype for modeling the Vcal net, which can be driven externally or internally by a bias generator. In DragonPHY, we're trying to support Xcelium and Vivado for most simulations, so this feature had to be temporarily removed (Vivado does not yet support a custom nettype). In most cases, this level of modeling detail is not needed, so it would be fine to have a "simple modeling" mode that supports Vivado and Xcelium, along with a "detailed modeling mode" that supports Xcelium only. But we would need to do this in a way that doesn't require keeping two sets of code (since that's not maintainable).

If I run python make.py --view fpga and then cancel in the middle (or if one of the steps errors out), it looks like previously built steps are re-built. Since some build steps are a little time-consuming, it would be nice if they did not have to be rebuilt.

Example showing adapt_fir being rebuilt:

> python make.py --view fpga
BUILDING: jtag_config
BUILDING: test_loopback_config
BUILDING: clk_delay
BUILDING: rx_adc
BUILDING: tx
BUILDING: osc_model
BUILDING: chan
BUILDING: rx_adc_core
BUILT: /home/steven/Code/dragonphy/build/fpga_models/rx_adc_core/rx_adc_core.sv
BUILDING: osc_model_core
Running model generator for osc_model_core...
BUILT: /home/steven/Code/dragonphy/build/fpga_models/osc_model_core/osc_model_core.sv
BUILDING: adapt_fir
/home/steven/Code/dragonphy/build/all/adapt_fir/chan.npy
BUILT: /home/steven/Code/dragonphy/build/all/adapt_fir/ffe_gpack.sv
BUILT: /home/steven/Code/dragonphy/build/all/adapt_fir/weights_pack.sv
BUILT: /home/steven/Code/dragonphy/build/all/adapt_fir/chan.npy
BUILT: /home/steven/Code/dragonphy/build/all/adapt_fir/step_resp_pack.sv
BUILT: /home/steven/Code/dragonphy/build/all/adapt_fir/constant_gpack.sv
BUILDING: clk_delay_core
BUILT: /home/steven/Code/dragonphy/build/fpga_models/clk_delay_core/clk_delay_core.sv
BUILDING: tx_core
BUILT: /home/steven/Code/dragonphy/build/fpga_models/tx_core/tx_core.sv
BUILDING: jtag
<<<Ctrl-C to cancel>>>
> python make.py --view fpga
BUILDING: tx
BUILDING: rx_adc
BUILDING: chan
BUILDING: clk_delay
BUILDING: test_loopback_config
BUILDING: osc_model
BUILDING: jtag_config
BUILDING: rx_adc_core
BUILT: /home/steven/Code/dragonphy/build/fpga_models/rx_adc_core/rx_adc_core.sv
BUILDING: clk_delay_core
BUILT: /home/steven/Code/dragonphy/build/fpga_models/clk_delay_core/clk_delay_core.sv
BUILDING: jtag
BUILDING: osc_model_core
Running model generator for osc_model_core...
BUILT: /home/steven/Code/dragonphy/build/fpga_models/osc_model_core/osc_model_core.sv
BUILDING: adapt_fir

When I enable the external max mux sel, the PI test reports that there is non-monotonic behavior. It seems this behavior always occurs at one point and to me, it looks like a linearity issue.

You can reproduce this by enabling the external max mux select in the ffe_dev branch.

-Zach

Based on our discussion today, we want to make sure that there is not a start-up issue here (x's or values that prevent proper starting of clk_adc)

Currently we don't have a way to do this and have to go through various scale factors, additions, and shifts.

The inc_delay module in PI is two output shorted tri-state buffers.
Currently, it does not have synthesizable netlist but only have its cpu model

With the automation provided by JusTAG, we're very close to being able to do push-button updates to the register map (i.e., edit markdown files and regenerate the JTAG implementation.) However, there is still one manual step, which wiring between interfaces in jtag/jtag.sv. I think this could be automated because we know the destination interface for each register by the name of the markdown file it came from. Adding this automation would eliminate a potential source of error while making it easier to add/change debug features of the chip.

I noticed that there is a least one bit of combo logic in jtag.sv, which is the reset gating of the analog core reset signal:
https://github.com/StanfordVLSI/dragonphy/blob/59089d659f54544086bb62c012f9d1c128826431/vlog/old_chip_src/jtag/jtag.sv#L15
Maybe we could handle this with an optional column in the Markdown file that specifies whether reset gating should be applied?

(I'm not sure if this automation belongs in JusTAG or DragonPHY, but thought I would add it as a task here to start.)

There seems to be an issue where clk_adc is "X" if the en_gf defaults to 1. I think the problem seems to be in V2T_clock_gen, although I haven't investigated this issue much. Having en_gf default to 0 solves the problem, but then we have to remember to write en_gf to 1 once the chip starts up. It would be good to get to the bottom of this problem in case it is masking a more serious issue.

Based on our group discussion today

Order seems to be 0, 5, 10, 15, 1, 6, 11, 12, etc. instead of 0, 4, 8, 12, 1, 5, 9, 13, etc. as I would expect. It looks like this is due to the way that the sampling sequence is initialized. I could be mistaken, because there are several places where the data are reordered, but when I re-order the data this way I get reasonable-seeming results.

Currently we have new_chip_src and an FPGA implementation. In order to merge these two while keeping the existing tests working, we need to complete some open issues:

1. Add PRBS checker to new_chip_src (#44)
2. Get LOOPBACK CPU simulation test working (#63). This test itself depends on a couple of open issues.

It is also important to note that the FPGA implementation has the new FFE code while new_chip_src does not. (We have a separate task for adding an FFE to new_chip_src, issue StanfordVLSI/dragonphy#42)

This issue refers to using fixture to generate the CPU simulation model used for the phase interpolator.

If we want to test the MLSD block with the PRBS checker, then we need a block that merges corrected bits back into the raw bitstream.

This test involves checking that default values are read back properly over JTAG. As a CPU simulation, it's mostly a spot-check of JTAG automation. It could be expanded into a more general test of all default JTAG values, but that should be done using emulation.

At the moment, parsing of FPGA models is a little clunky because they import svreal.sv, which defines several modules. Since get_deps is set up for a file structure in which there is one module definition per file (where the file name is related to the module name), this include file scheme requires modules instantiated from svreal.sv to be included in the skip argument of get_deps. We could fix this by searching for a module definition first in the same file, and then outside by view name.

This is dependent on a JusTAG task: StanfordVLSI/JusTAG#4
Once the JusTAG feature is ready, we can add the JTAG ID when make.py is run to build the chip. (The current git commit hash can be retrieved with git rev-parse HEAD.)

We have 31 bits available in the JTAG ID, and I suggest that we use the 28 most significant bits for the git commit hash, since it is customary to reference git commits using 7 nibbles. I suggest we use the three remaining bits to represent additional information about the repository state. For now, the main thing that comes to mind is the clean/dirty status of the repository to indicate whether the user has uncommitted changes (that can be automatically determined by checking if git status --porcelain is a non-empty string)

We can then encode this information in the version, part, and man_num variables:

• version[3:0] = (git_hash >> 24) & 0xf
• part[15:0] = (git_hash >> 8) & 0xffff
• man_num[10:0] = {(git_hash & 0xff), 1'b0, 1'b0, git_is_clean}

For example, suppose the output of git rev-parse HEAD is

1abc49b8ec66bad372e5728d2a2f42ab1b1264fa

git_hash would then be the most significant 7 nibbles (1abc49b). Further assuming that the git repository is clean (git_is_clean = 1'b1), we have:

• version[3:0] = 4'h1 = 4'b0001
• part[15:0] = 16'habc4 = 16'b1010101111000100
• man_num[10:0] = {8'h9b, 1'b0, 1'b0, 1'b1} = 11'b10011011001

The full JTAG ID (including the LSB that is always set to "1" by the TAP) would then be

jtag_id = 32'b00011010101111000100100110110011 = 32'h1ABC49B3

The nice thing about this format is that we can immediately read off the git commit has using the most significant 7 nibbles, while the git status is encoded in the least significant nibble ("3" means clean, "1" means dirty). We even have two more bits left over for other purposes if we can think of something :-)

This tests the internal PFD offset calibration loop. The external PFD_OFFSET is disabled and internal internal delays are adjusted so there would be a gap between positive and negative values. The ADC output is then measured to ensure that the gap has been corrected.

Depends on issue StanfordVLSI/dragonphy#42. As with the FFE:

1. Need a path to configure the MLSD externally (e.g., setting thresholds and coffecients)
2. Need to be able the bypass MLSD when sending data to the SRAM, PRBS checker, etc.
   I would also suggest that we have registers for monitoring the activation rate of this feature (start monitoring, stop monitoring, monitor duration, etc.)

I'm seeing some odd behavior in the PI beyond ext_pi_ctl_offset codes of 450 or so (see attached image). The exact code where this occurs is dependent on the delay of del_pi. In particular, when del_pi has a delay of 15ps, issues occur around code 450, whereas with a delay of 30ps, issues occur around 350. As a result, I suspect that this has to do with Qperi calibration and/or PI decoding.

This task includes both determining what memory size is needed, in addition to integrating the new macro(s) into the design.

For a starting point (translated from schematics), please see the corresponding models in vlog/new_chip_models

This test involves testing the behavior of the PI as a digital-to-time converter, using both idealized measurement (PI) and internal measurement (PI_PM).

Based on our discussion today, the order is:

1. ext_rstb -> "1"
2. int_rstb -> "1"
3. en_gf -> "1"
4. en_v2t -> "1"

For example, when the input select code is changed from "0" to "2", a glitch with two positive edges is seen. This is particularly critical because it can cause sampler sequence to slip in an unpredictable way, breaking the ordering of the retimer.

Details of this feature:

• Need path to set coefficients externally
• Need to be able to bypass FFE when sending data to the MLSD, SRAM, PRBS checker

These tests involve testing AC performance of the ADC using ENOB as a metric. Issues StanfordVLSI/dragonphy#58 and StanfordVLSI/issue_staging#18 are a prerequisites.

This test involves measuring the delay of the TDC chain by routing input and output signals of the delay chain to external pins of the chip.

I noticed that some build graph outputs are not rebuilt when the corresponding YML configs or Python sources are edited. For now, my workaround is to clean the build folder and rebuild everything, but it would be nice if the tool could automatically rebuild as necessary.
Examples:

• Build everything, then edit a parameter in an FPGA model *.yml config -- model does not get rebuilt
• Build everything, then edit the Python code of an FPGA model -- model does not get rebuilt (similar comment for adapt_fir; in that case dependent products like the channel model would have to be rebuilt as well)

This test exercises loopback functionality by sending random bits through the link and recovering them from SRAM over JTAG. With the addition of a PRBS checker, the internal loopback test status could be checked as well. (Previously this test was implemented using CPU simulation, but it was too slow.)

I noticed that the delay control signals for the V2T early and late clocks are both zero by default. Is this expected? In my simulations I'm seeing that clk_v2t, clk_v2t_early, and clk_v2t_late all happen at the same time.

(Once they have any process-specific information removed, of course). Please also include some instructions on how to run the scripts so that we can add a pass/fail test for these scripts to the repository.

As I understand it, this would make lab testing easier

Previously this test was implemented with CPU simulation, but it was very slow. Should be much faster in emulation.

1. All test related to ADC should be repeated for the case of PR (TDC phase reversed)
2. Now, each channel of ADC can be turned on/off individually and a test to check with this feature should be added.

This test involves getting the loopback testing working when the receiver starts at phase offset from the transmitter. The test should show that the MM CDR locks and passes a loopback test. The initial phase offset should be set far enough from the optimal point that the loopback test is failing. Prerequisite: Issue StanfordVLSI/dragonphy#25

Simulated ENOB is currently ~4.85 for the AC test (Fstim=1.023GHz). Could be a modeling, testing, or design issue, but it's important to log here because this is an important performance metric.

11/22

• Make multibit error correct happen properly
• How Fault handles analog signals
• Have the adaptation running on the Phy
• Have the new mProbo working to characterize a cell
• Make the emulation useable for software development (might push this)
• ACORE
• System Model
  • Add bad channel model
  • Phase interpolator with correct fixed codes

12/6

• Have complete templates for the selected type of cells
• System Model:
  • Use stochastic ADC
  • Add the CDR implementation

12/13

• System Model:
  • Memory and test hardware
  • JTAG

12/20

• Have a demo for DaVE, and complete Dragon Phy, and emulation Dragon Phy

12/27 -- Work will happen individually from here to meeting

1/3

Done

11/8 -

• Take back-end blocks and push to master - To be done today!
  • No adaptation, forward path with MLSD
• How to link software into our system, to make emulation better (olivia)
  - Not as pressing an issue, since first tests won't need it
  • For tests that do need it, there are two options
    • Emulated time on the software. Or not
    • We will chose not, and just read the data when the processor is ready
• Extracting parameters from simulation data (daniel) Done
• Create a list of circuit templates that you want to create by Jan Done
  • Phase blender
  • V2T
  • Sample and hold
  • Bias gen
• Create a plan for moving design over to real design Done
  ○ Low-loss channel model
  ○ Connect digital back end
  ○ Add bad channel model
  ○ Phase interpolator with correct fixed codes
  ○ Swap out ADC for one with real TI hierarchy
  ○ Use stochastic ADC
  ○ Add the CDR implementation
  ○ Memory and test hardware
  ○ JTAG

Since en_v2t is on the JTAG test clock, we need to make sure that it is synchronized in ADC slice 0.

This pertains to the MLSD and FFE blocks. Since they have a large number of weight registers, it would take a long time to update each individually over JTAG. Instead the plan is to increment 16 weights at once by amount of -1/0/+1 (each encoded in 2 bits, for a total of 32 bits). We would also want to be able to read/write individual weights directly (as a backup), so this task entails adding some registers that control access to MLSD and FFE weights, along with the logic that implements the controls.

This issue refers to using fixture to generate the CPU simulation model used for the sample-and-hold.

The old chip source does include an MM-CDR, but it has not really been tested (ButterPHY simulation test failed and it has not been exercised in the lab). This task involves updating the CDR as necessary to get it working in simulation. From the ButterPHY design, we know that we need to be careful about where modulus operations take place.

PR StanfordVLSI/dragonphy#78 contains the first pass of a PRBS checker, but more features are needed to improve testing capabilities and make debug easier. I'm recording these features here in rough priority order:

1. Add FREEZE command for PRBS checker so that the number of total and correct bits are frozen while being read back over JTAG (essential feature).
2. Add mode for manually adjusting the fine and coarse delay of the PRBS checker. This is important since it would allow us to do manual alignment, at least for relatively short PRBS sequences.
3. Make the ALIGN mode more robust to errors in the RX data stream. The current implementation assumes that errors happen only rarely, but we should be prepared for more frequent errors (particularly when we are taking data directly from the ADC)
4. Add capability to single-step the PRBS generators and read back the PRBS generator output.
5. Add capability to produce simpler test patterns (e.g., square wave) to ease initial bringup.
6. Add more comprehensive gating to shut off the power consumption of the PRBS checker when not in use.
7. Support multiple LFSR lengths and equations (currently PRBS-7 is used, but it would be nice to support longer LFSRs too)
8. Add bit-twiddling escape hatches (e.g., invert RX data going into checker, invert PRBS pattern, reverse RX data)

Based on our discussion today, when we make a large change to PI codes, en_v2t should be pulsed low and then high, so that the counters in the ADC slices are reinitialized in the updated order.

This test should show that adjusting the gain of each ADC channel works. Each channel should be started with a random gain error and and trimmed to correct for that error. Prerequisite: issue StanfordVLSI/dragonphy#58.

This test involves sending random bits through the link while recovering them directly from the ADC output. Prerequisites: StanfordVLSI/dragonphy#58, StanfordVLSI/dragonphy#59, StanfordVLSI/dragonphy#60.

From the behavioral model of the input buffer (transcribed from a schematic), It looks like bypass_inbuf_div = 0 means that the input buffer divider should be bypassed, which seems inverted to me. I'm not sure if this is a model issue or present in the implementation as well, so it is worth checking this polarity as well as the default register value. This should be clarified somewhat by the completion of issue StanfordVLSI/dragonphy#55, which should eliminate behavioral models for input and output buffers.