BrianHG_DDR3_CONTROLLER open source DDR3 controller. NEW v1.60.

[BrianHG]

Note that the purpose of my multiport was to make my DDR3 controller's interface to appear exactly like a 16 port altsyncram FPGA blockram function.  You just need to be attentive to the CMD_busy when read or writing and wait for the CMD_read_ready to see your read request ohhh so may clock cycles later.  So, to get the full read performance, you need to remember to post a bunch of reads ahead of time.  My CMD_read vector in/out ports does some lifting offering you a means of delineating a destination for each posted read command.

[BrianHG]

Version 1.6 update...

  After 3 days of work and test compiles, I finally found my Quarter Rate setting bug.  And I flew by it a dozen times...

   I forgot to clock latch in the read_data_valid_toggle signal going from the half-rate clock domain to the quarter rate domain.  With heavy reads, that toggle signal may come in on the first or second half of the Quarter clock's period.  When operating in Half-rate, there is no Quarter rate and that latch always arrives by the next clock, so no problem.  At Quarter rate, usually, with slow memory single reads, or continuous evenly length bursts, that latch signal just happens to always be aligned at the beginning of the Quarter rate clock maintaining proper function.  But with bursts with just the right pacing and an odd length buried inside, like when my multi-window VGA generator has 2 super-imposed windows, one with an odd number of pixels just at the right position, then a read data valid may align itself to the second half of the Quarter-rate clock as the DDR3 controller may have an odd number of half-rate clock cycles until the read_data_valid_toggle.  This causes a loss of synchronization as that read is latched at the wrong time with the wrong vector data used by my multiport commander to know when a read arrives and which port the read data belongs to.

   After 3 days, I thought I had a fundamental architecture problem, but no...    However, along the way, I added a few new features and further improved the .sdc constraints rendering a further improvement in achieving a high level FMAX.

Full proper release DDR3 v1.6 with VGA controller will come in a day after I clean up my mess.

[BrianHG]

Arrrrgggg, ok, for my changes, once I removed my watch dog timer, it works fine for 30 seconds or so, but still seizes up.  Still superior to instantly seizing up, or garbage reads, but there must be another signal somewhere interrupting the system.  It also wont seize up if I use just the video channel, but start the RS232 debugger and it eventually craps out.  Yet in half-rate, everything runs AOK.

[BrianHG]

Release V1.6 Demo .sof programming files of DECA BrianHG_DDR3_Controller v1.6 and multi-window BrianHG_GFX_VGA_Window_System v1.6 for Arrow DECA eval board.

 
    500MHz/1GTPS! with 2x32bit 1080p60 video layers.   
    That's >1100 megabytes/sec just to show the image, 
    never mind simultaneously drawing all those ellipses. 
 

Just open your JTAG programmer and add one of the following 2 files:
1. 'BrianHG_DDR3_DECA_GFX_DEMO_v16_1_LAYER_500MHzQR.sof'
        -> Replaces and replicates the original Ellipse Generator now using the new BrianHG_GFX_VGA_Window_System.

2. 'BrianHG_DDR3_DECA_GFX_DEMO_v16_2_LAYERS_500MHzQR.sof'
        -> Improved original Ellipse Generator demo where a second translucent superimposed video window scrolls at different coordinates and speeds generating an LSD trip visual effect.  (Note that the scroll switch needs to be turned on long enough at least bounce off 1 window edge to view effect.)

Check-on the 'Program/Configure' and click 'Start' to program.
The DECA's HDMI should output a 1080p image.


IMPORTANT NOTE:
If the picture is still or scrolling noise, just press buttons 0 or 1, or flip 'Switch 0' to enable drawing ellipses.  You just powered up the demo in frozen picture mode and you are looking at the powered up random blank memory.

Switch 0 = Enable/Disable drawing of ellipses.
Switch 1 = Enable/Disable screen scrolling.
Button 0 = Draw data from random noise generator.
Button 1 = Draw color image data from a binary counter.

Full Github v1.6 source code.
https://github.com/BrianHGinc/BrianHG-DDR3-Controller

[BrianHG]

New VGA video system demo configured for up to 16 window layers driven by my RS232_Debugger. 

Code: [Select]

//****************************************************************************************************************
//
// Demo documentation.
//
// BrianHG_DDR3_DECA_GFX_HWREGS_v16_16_LAYERS which test runs the BrianHG_DDR3_CONTROLLER_top_v16
// DDR3 controller with the BrianHG_GFX_VGA_Window_System_DDR3_REGS.
//
// Version 1.60, June 9, 2022.
//
// Written by Brian Guralnick.
// For public use.
// Leave questions in the [url]https://www.eevblog.com/forum/fpga/brianhg_ddr3_controller-open-source-ddr3-controller/[/url]
//
//****************************************************************************************************************

A pre-built DECA compatible programming .sof file : BrianHG_DDR3_DECA_GFX_HWREGS_v16_16_LAYERS.sof should be used for this demo.

This demo requires a PC with a RS232 <-> 3.3v LVTTL converter and the use of my RS232 debugger to live edit window controls.
All necessary files are found in this project's sub-folder 'RS232_debugger'.

Wiring: On DECA PCB, connector P8.
    P8-Pin 2 - GND            <-> PC GND
    P8-Pin 4 - GPIO0_D[1] out --> PC LVTTL RXD
    P8-Pin 6 - GPIO0_D[3] in  <-- PC LVTTL TXD

See Readme.txt file in the .zip for full documentation.
See 'BrianHG_GFX_VGA_Window_System.txt' for address controls.
See 'BrianHG_GFX_VGA_Window_System.pdf' for system block diagram.

[BrianHG]

As of today, full Github v1.6 source code has now been released:

https://github.com/BrianHGinc/BrianHG-DDR3-Controller

Expect 300Mhz-350Mhz builds to always meet timing requirements.  (Even with a slow fabric -8.)
Expect 400Mhz builds to usually meet timing requirements with the occasional need to massage some compiler/fitter settings to aid in meeting timing requirements.  (Still easier than making Altera's paid Uniphy DDR3 controller achieve only 300Mhz.)
Expect Cyclone III/IV -6 can meet timing requirements at 450MHz.  Even 500MHz is possible with heavy massaging of fitter setting.

Expect my BrianHG_GFX_VGA_Window_System to run up to 32 windows in 480p, 16 in 720p, 8 in 1080p.
Also expect my BrianHG_GFX_VGA_Window_System to automatically simplify down to minimal gates when lowering layers down to 1, disabling palette / font/tile modes and hard-wiring numerous video/window setting.

[SpacedCowboy]

I just ordered one of these (apparently new) Gowin 20k boards. I'm going to see if I can port your design across, which is going to be ... challenging ... because I know little about DDR3 and nothing at all about Gowin, but if I can get it working, having a pre-built DDR3/FPGA board with that many GPIO for that price in an easily-embeddable DIMM is going to be kinda useful

[BrianHG]

I just ordered one of these (apparently new) Gowin 20k boards. I'm going to see if I can port your design across, which is going to be ... challenging ... because I know little about DDR3 and nothing at all about Gowin, but if I can get it working, having a pre-built DDR3/FPGA board with that many GPIO for that price in an easily-embeddable DIMM is going to be kinda useful

Begin with nothing more than implementing my simple 'BrianHG_DDR3_PHY_SEQ' controller.  It is half the size and once you got that working, implementing the multiport with everything else will be much easier as they have no special code and are only needed if you need 16 read/write ports.

So long as Gowin can deal with System Verilog, the only 2 HDL modules you will have to adapt will be:
BrianHG_DDR3_PLL.sv
BrianHG_DDR3_IO_PORT_ALTERA.sv

If Gowin uses or can use Modelsim, this will be a great help as I have already set all this up.  I still do recommend downloading Altera/Intel's free Quartus's v20.1 (not v21.x) and at least install that Modelsim as it has Altera's PLL and DDR_IO libraries so you can see what the original supposed to look like as I created setup_xxx.do script files which simulate everything individually.  Don't worry, you may have multiple versions of Modelsim in you system at the same time.

This link: https://github.com/BrianHGinc/BrianHG-DDR3-Controller/tree/main/BrianHG_DDR3_DECA_PHY_SEQ_only_v16

Contains my simple stand alone 'BrianHG_DDR3_PHY_SEQ' controller wired to my RS232 debugger allowing you to view and edit the DDR3 memory contents from a PC with a LVTTL <-> RS232 com port, and it will report DDR3 tuning status and you can leave it running while updating you Gowin firmware.  Documentation is on my Github's read-me.

Step #1 would be to see if you can simulate a Gowin PLL with the phase step up and phase step down controls my DDR3 controller requires.  This means concentrating exclusively on replicating nothing more than my 'BrianHG_DDR3_PLL.sv' and it's stand alone testbench with it's 4 clock outputs.  If you are lucky, Gowin should provide their own PLL library functions in their own simulator.

[SpacedCowboy]

Thanks Brian,

Step #1 would be to see if you can simulate a Gowin PLL with the phase step up and phase step down controls my DDR3 controller requires.  This means concentrating exclusively on replicating nothing more than my 'BrianHG_DDR3_PLL.sv' and it's stand alone testbench with it's 4 clock outputs.  If you are lucky, Gowin should provide their own PLL library functions in their own simulator.

So this just got harder..

'Gowin' and 'Simulator' seem to be words that do not exist in the same sentence, other than in sentences where "do not have one" also appear... And this is in the "licensed" (ie: please send us your email) version, not the 'educational'
one.

There used to be an option in the IDE (I've seen screenshots!) where you could call into a 3rd party simulator, but that seems to have been removed (why ?!) There is an option to generate .vo "post-PnR simulation model files" in the options, but other than that there's sweet Fanny Adams to help out.

Clearly it'd be useful to have the same simulation environment as you're using, but I don't have Modelsim, and I can't find out how expensive it is... I sent off an email to the 'contact us' page at Siemens, but I have a bad feeling about software that doesn't advertise its price *anywhere*... Even my most recent eye-wateringly-expensive purchase (Altium) had advertised prices...

On the upside, it looks as though System Verilog (2017) is supported. And the boards I bought have shipped straight away, which is nice. It's been many (many!) moons since I could claim a student version of anything (and anyway it looks as though they've removed the free student edition for now), so on the down-side, I may be using icarus verilog or something similar...

[BrianHG]

Clearly it'd be useful to have the same simulation environment as you're using, but I don't have Modelsim, and I can't find out how expensive it is... I sent off an email to the 'contact us' page at Siemens, but I have a bad feeling about software that doesn't advertise its price *anywhere*... Even my most recent eye-wateringly-expensive purchase (Altium) had advertised prices...

Modelsim is free.  It comes with Quartus 20.1 free web version and earlier.  (Includes Quartus Megafunction Libraries.)
It also comes with Lattice Diamond Design Software 3.12 and later.  (This version includes Lattice's library functions.)
I do not know about Gowin.

     If you do not include the appropriate -L xxxxx  on the compile line to include the vendor's library functions, then it's a basic Modelsim with over 90% functionality.  There are only 1 or 2 advanced post generation function views which arent available unless you buy the full Modelsim, but these are available in Quartus and Lattice itself.

     I personally begun to completely develop in Modelsim alone and then move my design to the FPGA tools as Modelsim's compile/build time is usually within a second.

Try googling:
HDL modelsim gowin fpga
and
HDL Active-HDL gowin fpga

Active-HDL is a somewhat close to but a cheaper experience than Modelsim.

Take a look at my https://github.com/BrianHGinc/SystemVerilog-TestBench-BPM-picture-generator as I made it work for both simulators.  Only difference is in the setup-xxx.do files.

You can look here:
https://www.intel.com/content/www/us/en/software-kit/661015/intel-quartus-prime-standard-edition-design-software-version-20-1-for-windows.html and click on 'Individual Files' where you will see Modelsim as a stand-alone download.

But the listed modelsim there only has the added Altera/Intel libraries, yet almost everything else works.

[SpacedCowboy]

A-ha! Ok, thanks

I knew about the bundled versions, but I’d assumed they were vendor-locked in some way. Well, that makes things simpler, at least to start with

[BrianHG]

If you can get Gowin to generate simulation libraries for their functions, like PLL and DDR IO buffers, you may be able to include those with Altera's Modelsim as a work around hack.

[BrianHG]

A-ha! Ok, thanks

I knew about the bundled versions, but I’d assumed they were vendor-locked in some way. Well, that makes things simpler, at least to start with

It's not that they are vendor locked, as you need to learn the command line stuff or use the menus instead of relying on the FPGA tool to 'auto setup and run your simulation'.

[SpacedCowboy]

It's not that they are vendor locked, as you need to learn the command line stuff or use the menus instead of relying on the FPGA tool to 'auto setup and run your simulation'.

That's no problem, trust me  To me, 'vi' is a luxury, it was 'ed' when I started command-line tools are A-OK with me 

[brucehoult]

It's not that they are vendor locked, as you need to learn the command line stuff or use the menus instead of relying on the FPGA tool to 'auto setup and run your simulation'.

That's no problem, trust me  To me, 'vi' is a luxury, it was 'ed' when I started command-line tools are A-OK with me

Ed? Pffft.  I used to work on a system where the best editor was an even more obscure and limited variant of TECO called SPEED.

[SpacedCowboy]

There was one time on a DECstation that had corrupted its usr partition, when I had to use only what was in /boot to get it to change how it booted. vi was in /usr/... head, cat and tail were in /bin... Took a while to get the boot config files how I wanted them. Worked in the end though

But I digress - sorry Brian, I'll keep it on-topic from now

[SpacedCowboy]

Brian, am I reading this correctly ? In your BrianHG_DDR3_PLL.sv code, it looks like the delay-shift for the Altera PLL's can take any number between 0 and 4000ps. Is that correct ?

Because looking at the Gowin version of what you can do with the PLL, there are 16 possible phase-tuning parameters (step of 22.5°), and another 16 possible delay parameters (step of 0.125ns):

Code: [Select]

///////////////////////////////////////////////////////////////////////////////
// Phase control values
// --------------------
// 0000 0°          0001 22.5°          0010 45°            0011 67.5°
// 0100 90°         0101 112.5°         0110 135°           0111 157.5°
// 1000 180°        1001 202.5°         1010 225°           1011 247.5°
// 1100 270°        1101 292.5°         1110 315°           1111 337.5°
//
// Duty cycle values
// -----------------
// 0010 2/16        0011 3/16           0100 4/16           0101 5/16
// 0110 6/16        0111 7/16           1000 8/16           1001 9/16
// 1010 10/16       1011 11/16          1100 12/16          1101 13/16
// 1110 14/16
//
// Delay parameters (below are in manual, looks like others work)
// ----------------
// 0111 0.875ns     1011 1.375ns        1101 1.625ns        1110 1.75ns
// 1111 1.875ns
//
///////////////////////////////////////////////////////////////////////////////

From what I can see, the duty-cycle is there to indicate when the falling edge of the signal should be in the waveform, which is dependent on the phase, so for a 50/50 duty cycle, I ought to just add 8 to the phase and take the modulus in base 16

There are also 'fine-tuning' (±50ps, ±100ps, ±150ps) options for the phased-clock output, but those are parameter-based, not dynamically tunable.

But in any event, my number of phase-discriminating steps is going to be a *lot* less than the Altera one if it can do 4000 of them, hopefully it'll still be useful enough...

[BrianHG]

For the fixed integer '270' deg, I specify the integer parameter DDR3_WDQ_PHASE in 'degrees'.  To tell Altera how to adjust it's PLL, I needed to convert it into PS.  If your rPLL accepts the integer 270, use that one.  It is 50:50.  Ignore the Cyclone V PLL as it is a mess.  Better look at the CycloneIV/MAX10 PLL as it has fewer controls.

As for the read clock user phase tunable output, it is 50:50.  When the system begins or reset is sent, it defaults to '0' degree.  The Altera PLL will accept 16 tuning steps before a full 360deg round trip has been made.  It stays at 50:50.  (looks the same as Gowin)

The parameter DDR3_RDQ_PHASE is actually never used.  I always have it set to '0'.

The 'trick pll' should never be used for Gowin.  I use it to bypass a cap in one of Altera's DDR_IO buffers.

The localparam 'DDR3_WDQ_PHASE_ps' is a translation of the user set DDR3_WDQ_PHASE  into a picosecond delay.

Ignore the Altera dummy string as it circumvents a bug in the Altera alt_pll functions where they wanted 'string' inputs.

[SpacedCowboy]

Ok, thanks Brian, I have both yours and my signals pretty much matching up initially. It looks as though the Gowin PLL takes longer to initialize. The internal 100MHz clock is slightly different - it's a cycle delayed (or ahead, I guess) of the Altera one but it's still in sync. Not sure if that's important because you've presumably got clock-crossing controls in place. Could alter some of the timing of those signals, though.


Presumably the phase_step signal is edge-triggered rather than level-triggered ? From the signaling, it certainly looks that way (see below). My WIP PLL module is going nuts at the moment, changing its phase on every (phase_sclk == 1'b1 and phase_step == 1'b1)...

[BrianHG]

Edge or level triggered doesn't matter.  As long as a single step is made anytime after the step goes high.  (That is still a single step even if the step is held high.)
What is important is the direction and that there are 16 steps for a full rotation.

When my DDR3 controller applies a step, it waits for ~ 1us for the PLL output to adapt, hence I basically ignore the 'phase_done' signal by just waiting a crap load of time.

As for the clock out, the phases once set better stay where they belong, even in simulation.  Otherwise, the sim will fail over time.

I am not sure how your rPLL clock output cannot be exactly 400MHz if you set your reference clock divider and multiplier correctly.  For example, when I generate the requested:

Code: [Select]

parameter int        CLK_KHZ_IN              = 50000,          // PLL source input clock frequency in KHz.
parameter int        CLK_IN_MULT             = 32,             // Multiply factor to generate the DDR MTPS speed divided by 2.
parameter int        CLK_IN_DIV              = 4,              // Divide factor.  When CLK_KHZ_IN is 25000,50000,75000,100000,125000,150000, use 2,4,6,8,10,12.

and synth the clock:

Code: [Select]

localparam       period  = 500000000/CLK_KHZ_IN ;

always #period                  CLK_IN = !CLK_IN; // create source clock oscillator

All the factors in the equations and delays hit dead on whole numbers.

In modelsim under menu 'wave/wave preferences / Grid & Timescale', if I set the grid preiod to a manual 2500ps and zoom in & scroll in the waveform output, you can see the 400MHz stays locked to the 50MHz source.


Do not worry about the initial PLL setup time.  I wait plenty of time for the PLL and other stuff to synchronize before running the system.  Also verify that Gowin provides a PLL locked signal out.  My DDR3 is held in reset during power-up until the locked signal is ready, then, there is a ton of other delays to accommodate the DDR3 startup sequence.

[SpacedCowboy]

Edge or level triggered doesn't matter.  As long as a single step is made anytime after the step goes high.  (That is still a single step even if the step is held high.)

Yep, I'm going to have to put some logic in there to wait for it to go low again - there is no "step" functionality in the Gowin PLLs, you just set the value for the phase directly - so I'm wrapping some logic around the step/updn signals to mimic the same interface.

What is important is the direction and that there are 16 steps for a full rotation.

I think you're actually running at 8 steps per full period. After four calls to phase_step, the DDR3_CLK_RDQ signal is 180° out of phase with the DDR3_CLK signal. I'm adding 2 to my 'out-of-16' phase value to match the Altera original (currently simulating the Cyclone V variant).

When my DDR3 controller applies a step, it waits for ~ 1us for the PLL output to adapt, hence I basically ignore the 'phase_done' signal by just waiting a crap load of time.

That's good, because I don't have a 'phase done' I was thinking I'd synthesize an interface to one but if you don't use it, that's easier

As for the clock out, the phases once set better stay where they belong, even in simulation.  Otherwise, the sim will fail over time.

I am not sure how your rPLL clock output cannot be exactly 400MHz if you set your reference clock divider and multiplier correctly.  For example, when I generate the requested:

Code: [Select]

parameter int        CLK_KHZ_IN              = 50000,          // PLL source input clock frequency in KHz.
parameter int        CLK_IN_MULT             = 32,             // Multiply factor to generate the DDR MTPS speed divided by 2.
parameter int        CLK_IN_DIV              = 4,              // Divide factor.  When CLK_KHZ_IN is 25000,50000,75000,100000,125000,150000, use 2,4,6,8,10,12.

and synth the clock:

Code: [Select]

localparam       period  = 500000000/CLK_KHZ_IN ;

always #period                  CLK_IN = !CLK_IN; // create source clock oscillator

All the factors in the equations and delays hit dead on whole numbers.

In modelsim under menu 'wave/wave preferences / Grid & Timescale', if I set the grid preiod to a manual 2500ps and zoom in & scroll in the waveform output, you can see the 400MHz stays locked to the 50MHz source.

Imprecise language here - the phases stay locked on, and the waves are exactly the correct periods/frequencies. What I meant was (if you look at 'initial-locked-state.png' two posts up), you can see

- the cursor is at 'gowin_clocks_locked' so we're just acheived stability.
- the red (DDR3_CLK and clk_ddrMain) signals are locked in sync
- same for the cyan DDR-write clocks (DDR3_CLK_WDQ and clk_ddrWrite)
- same for the blue DDR-read clocks (DDR3_CLK_RDQ and clk_ddrRead)
- same for the green client-interface clock (DDR3_CLK_50 and clk_ddrClient)

- the DDR3_CLK_25 and clk_ddrMgmt clocks both do have the same period/frequency, however the Gowin one (clk_ddrMgmt) is presenting a low->high (and high->low of course) transition one full DDR3_CLK period later than DDR3_CLK_25.

Do not worry about the initial PLL setup time.  I wait plenty of time for the PLL and other stuff to synchronize before running the system.  Also verify that Gowin provides a PLL locked signal out.  My DDR3 is held in reset during power-up until the locked signal is ready, then, there is a ton of other delays to accommodate the DDR3 startup sequence.

Sure, in the test bench the stop condition is now

Code: [Select]

always @(PLL_LOCKED & gowin_clocks_locked) #(endtime) $stop;            // Wait for both PLLs to start, then run the simulation until 1ms has been reached.

I figured there'd be a wait-for-the-signal to account any variation even in the Altera PLLs.

Cheers

[BrianHG]

Edge or level triggered doesn't matter.  As long as a single step is made anytime after the step goes high.  (That is still a single step even if the step is held high.)

Yep, I'm going to have to put some logic in there to wait for it to go low again - there is no "step" functionality in the Gowin PLLs, you just set the value for the phase directly - so I'm wrapping some logic around the step/updn signals to mimic the same interface.

It will then be a 4 bit up-down counter.
To decode the step:

always@(posedge clk_in) begin
step_dly<= step;
if (step && !step_dly) begin
     if (up_dn) phase_pos <= phase_pos + 4'd1;
     else phase_pos <= phase_pos - 4'd1;
end

I bet that will do what you want, though I may have the +/- backwards.

A cleaner method would be to have 2 step_dly's, and in the if()  check for a true step_dly1 and a false step_dly2.
This way, the unknown clock domain source 'step' is first transferred to the 'clk_in' domain for better metastability.

[BrianHG]

You should be able to insert a parameter value 'Gowin' to the 'FPGA_VENDOR' parameter and add your PLL to my 'BrianHG_DDR3_PLL.sv'.

Then temporarily edit my 'BrianHG_DDR3_PHY_SEQ_v16_tb.sv' so that just the PLL's FPGA_VENDOR is set to Gowin.  The execute my 'setup_phy_v16.do' script to see if the Gowin PLL will initialize the Mircon DDR3 model.
If you need to touch-up your code, to re-compile, just execute 'run_phy_v16.do'.  (You will need include Gowin's primitive lib to the setup_xxx.do)

If that works, then you can call that part a success.  Next, the DDR_IO buffers.

[SpacedCowboy]

Yep, my logic looked pretty similar to your counter-style, if a little less concise ...

Code: [Select]

    reg     [3:0]       duty;               // Duty cycle, 50/50 = 8 + phase
    reg     [3:0]       phase;              // Phase to present to PLL
    reg                 lastPhaseStep;      // Look for the level-transition

    always @ (posedge clk) 
        begin
            if (rst)
                begin
                    phase           <= 4'b0;
                    duty            <= 4'b0;
                    lastPhaseStep   <= 1'b0;
                end
            else   
                begin
                    if ((phase_step == 1'b1) && (lastPhaseStep == 1'b0))
                        if (phase_updn == 1'b0)
                            begin
                                phase   <= phase - 4'h2;
                                duty    <= phase + 4'h6;    // current phase + (8-2)
                            end
                        else
                            begin
                                phase   <= phase + 4'h2;
                                duty    <= phase + 4'hA;    // current phase + (8+2)

                            end

                    lastPhaseStep <= phase_step;
                end
        end

I did originally have 'phaseEdge' as a 3-bit detector, and I was checking for 'phaseEdge' being 3'b011 but the clk this is synced off is the slow clkIn (~27MHz in the eventual design) and three clocks took an eternity. Now that I know you wait for 1µs, I might just put that back

Looking at it, I can make the phase a 3-bit counter as well, since the last bit is always 0.

Anyway, it now matches up perfectly with the signals from your BrianHG_DDR3_PLL, apart from that phase offset between your DDR3_CLK_25 and my clk_ddrMgmt clock - and I don't *think* that'll be an issue. I'd have to burn another PLL to get the 180° phase-delay, so unless it turns out to be important, I'm going to leave it.

You should be able to insert a parameter value 'Gowin' to the 'FPGA_VENDOR' parameter and add your PLL to my 'BrianHG_DDR3_PLL.sv'.

Then temporarily edit my 'BrianHG_DDR3_PHY_SEQ_v16_tb.sv' so that just the PLL's FPGA_VENDOR is set to Gowin.  The execute my 'setup_phy_v16.do' script to see if the Gowin PLL will initialize the Mircon DDR3 model.
If you need to touch-up your code, to re-compile, just execute 'run_phy_v16.do'.  (You will need include Gowin's primitive lib to the setup_xxx.do)

If that works, then you can call that part a success.  Next, the DDR_IO buffers.

I might try and get around to that this evening, else tomorrow. Life, I'm reliably informed by 'er indoors doesn't *entirely* revolve around playing with electronics

[BrianHG]

My mistake, here is a snapshot of the tuning:



As you can see the time bars, I pulse the phase_step for 20ns.
Then I wait 100ns before analyzing the read data meaning the PLL's read clock needs to be ready in around 90ns.

These inherent delays can be adjusted in my DDR3 initialization sequence, though, 100ns is plenty.