[enjoy-digital]

Do not merge before testing on hardware. Refs #225.

On S7DDRPHY and USDDRPHY, the DQS preamble/postamble patterns are disabled with # FIXME lines: the output enable covers these cycles but DQS keeps toggling through them. This adds an opt-in with_dqs_preamble, off by default.

Why they could not simply be enabled

Measured with the real controller and PHY at the serializer inputs on current master, for one write (position of the data beat and of the output enable window, in sys_clk cycles):

PHY	Data beat at D	Output enable at T
A7 DDR3 (no ODELAY)	54	55 to 57
K7 DDR3	54	55 to 57
USP DDR4	55	55 to 57

So the data is not centered in the enable window at these inputs, and the difference must come from the OSERDES latencies and the write bitslip calibration. Connecting the patterns to the enable-aligned dqs_preamble/dqs_postamble signals would misplace them.

Changes

• DQSPreambleControl (common.py) generates the controls from wrdata_en and write_latency, aligned on the write data entering the PHY. The pattern goes through a bitslip with the same rst/slp controls as DQ, so the alignment holds with the bitslip set by the calibration.
• On A7 (with_odelay=False), DQSPattern's output register is bypassed when the option is on: with write_latency 1, the preamble is due in the cycle of wrdata_en, so a register would make it late. This also moves wlevel_strobe one cycle earlier on that path.
• S7DDRPHY asserts 1:4 when the option is on, since the patterns are 8-bit. DDR2 at 1:2 is not supported.
• The FIXME lines are removed.

Tested in simulation only

• test/test_dqs_preamble.py: controller and PHY, at the serializer inputs, on A7 DDR3, K7 DDR3 and USP DDR4, with 1 and 3 back-to-back writes. Preamble the cycle before the first beat, toggle on the beats, postamble the cycle after the last.
• test_s7ddrphy, test_usddrphy and test_controller_timing pass.
• Option off: digilent_arty and xilinx_kcu105 Verilog (--no-compile, no CPU) have the same logic as master. The only difference is the order of two hierarchy comment lines on KCU105.
• Option on: both targets elaborate. Timing was not checked (no Vivado run).

What simulation cannot tell, and what hardware has to answer

• Is the preamble inside the output enable window at the pads? The OSERDES are not simulated. The preamble enters 2 cycles before the window on S7 and 1 cycle before on USP. If the data is in the middle of the window at the pads, as the PHY comments intend, the preamble is in its first cycle. I could not confirm that, and the bitslip moves the pattern but not the window.
• Two writes one cycle apart: the postamble and the preamble fall in the same cycle and the postamble pattern wins. This case is not covered by the tests.
• The preamble cycle still toggles at first: 0b00010101 is sent LSB-first as 1,0,1,0,1,0,0,0, so it has about 1.5 tCK low before the burst, with three extra edges before that.

Hardware test plan

Pass with_dqs_preamble=True to the PHY in the target and use --load, on an Arty (A7 DDR3), a KCU105 (US DDR4) and a K7 board with ODELAY if available. Compare with the option off:

1. sdram_cal: write leveling and read windows should not shrink.
2. sdram_test, then a long memory test.
3. sdram_bist or mem_speed: throughput should not change.
4. If a scope or LiteScope is available, check the DQS shape around a write.

Written by Claude Code (AI agent), supervised by Florent Kermarrec.

🤖 Generated with Claude Code