Gowin IP simulation

[ali_asadzadeh]

Hi,
After several emails requesting how to simulate Gowin IP they came up with this answer.

We don’t offer a simulator, so no tutorials are available.
We do provide a GOWIN stdcell simulation library (the primitive library that contain the GOWIN standard logic elements, flops, reset instances, logic functions etc).
This can be found in the GOWIN EDA tool install area E.g. Gowin_V1.9.5.05Beta\IDE\simlib\<device_family>\prim_sim.v

GOWIN IP CORE GENERATOR generates *.vo simulation models.
.vo files can be found under the design/src/<ip-name>/ directory in the GOWIN EDA build area e.g. ledtest/src/fifo_sc_top/fifo_sc_top.vo).
To perform timing simulation on your entire design, we generate a standard delay format (.SDF) file and post PnR simulation model file
Simply configure the Place and Route tool to turn on SDF generation and post PnR :

So the question is there a way to use some form of simulation to simulate the IP cores, How?

Also I will suggest all forum members who use Gowin chips, ask them directly for IP simulation, so they would see demand and would make it possible.

[SpacedCowboy]

I realize this is an ancient thread, but it's worth resurrecting for this, I think.

I just purchased some of the new (at least to me) Tang Primer 20k boards, and noticed the lack of any simulator. I pinged Gowin tech support...

I just downloaded the GUI environment for a Tang Primer 20k with a GW2A-LV18PG part on it.
I noticed there's no simulator in the package - what is the recommended simulator, and is there any user-guide for getting simulation to work with the Gowin parts?

and they replied with:

-----8< -----8< ----- Cut here -----8< -----8< -----

Metrics is GOWIN’s recommended Simulation Solution.
 
We’re working with a third-party provider called “Metrics” to add simulation support to our EDA tools.
 
Metrics offer a cloud-based simulator that is being offered free-of-charge to GOWIN customers for the next few months.
Moving forward you pay by the hour at very reasonable rates (~$2 an hour) for just the server time used.
 
Metrics - GOWIN’s Premier ODM Simulation Partner

• Full featured, high performance simulation environment
• Supports System Verilog, Verilog and VHDL
• Supports UVM & Vunit

Utilizes scalable cloud computing resources

• No limitations on performance
• No licensing restrictions
• Minimal local hardware requirements

For more details, please see https://metrics.ca/gowin-customers/

 
Gowin FPGA also support Third-Party and Open-Source simulation tools

• Modelsim, Aldec Active-HDL, Synopsys VCS, etc.
• Icarus Verilog

When generating IP cores using the GOWIN IP Core Generator simulation may be handled in 2-ways.
 

• The more complex IP cores will output a gate-level netlist for the IP core.
  This can be found in the src/<IP_core> output directory with a *.vg or *.vo extension.
  This is essentially a GOWIN Verilog netlist (model) of the complex IP core.
  Where this *.vg or *.vo file exists, use this in-place of the src/<IP_core>/*.v (or*.vhd) top-level IP Core module.
• Standard IP cores like PLLs or FIFOs output a top-level module *.v or *.vhd file
  This can be found in the src/<IP_core> output directory.
  

 
In addition, the associated GOWIN std_cell library (*.v or *.vhd) needs to be compiled along with the customer’s design modules.
The std_cell_library contains the behavioral HDL models needed to compile the design when running pre-synth HDL simulation or post-synth gate-level netlist simulation.
These files can be found in the GOWIN EDA install directory
 
E.g.  Path Gowin_V1.9.8.05\IDE\simlib\gw1n or Gowin_V1.9.8.05\IDE\simlib\gw2a
 
The prim_sim.v or prim_sim.vhd stdcell_library files are used for simulation without timing, the prim_tsim.v file is used for timing simulation with back annotated *.sdf
 
To simulate the design and testbench the customer will need to compile.
 

• The testbench and any supporting test components or functional models.
  
• The testcase(s).
  
• The HDL design, consisting of the top-level module and any additional sub-modules that have been added to the design using the GOWIN EDA tool.
  This includes any generated GOWIN IP which may require the *.vo gate-level simulation models in order to simulate these can be found under the design/src/<ip-name>/ directory in the GOWIN EDA build area e.g. ledtest/src/fifo_sc_top/fifo_sc_top.vo
• The GOWIN stdcell simulation library (the primitive library that contain the GOWIN standard logic elements, flops, reset instances, logic functions etc).
  
• This can be found in the GOWIN EDA tool install area E.g. Gowin_V1.9.3.01Beta\IDE\simlib\<device_family>\prim_sim.v
  

Find attached example SystemVerilog Modelsim Run Scripts for reference.
(I have attached these to this post, disguising the .do files as .do.txt to get past the attachment-filter).

-----8< -----8< ----- Cut here -----8< -----8< -----

I have to say that, as a first-ever impression of Gowin's tech support, to some nobody on the internet who just asked, this is pretty much an exemplary response It came from the Senior FAE manager at Gowin EMEA, also copied on the email was the US Director of Sales, and the US senior FAE manager.

Colour me impressed. Now to see how well it works

[ali_asadzadeh]

Thanks for sharing, it would be more useful if they go with the standard industry modelsim! Aso some tutorial videos would help a lot.

[SpacedCowboy]

Thanks for sharing, it would be more useful if they go with the standard industry modelsim! Aso some tutorial videos would help a lot.

The above attached files are for Modelsim ... I'm new to Gowin chips and also new to Modelsim (which I'm trying to learn so I can try and port BrianHG's DDR3 code to the Tang Primer 20k). With the above example, in a few hours I got Modelsim up and running and simulating a Gowin-IP rPLL instance, as below. The module itself is trivial, but I wanted to see if I could get the PLL to be simulated by Modelsim - it's the first step in porting the DDR3 IP, given that Brian uses Modelsim extensively for testing.


I set the input clock to be 27MHz (as on the board) and requested the closest to a 400 MHz clock that I could get out of the PLL (actually ~398MHz). The pllClk signal in the image is slightly faster than that, but that's probably down to the resolution of the timing in the test-bench.

[BrianHG]

Note about simulating a source clock in Modelsim, or any other, remember, you are requesting a #(delay) in picoseconds.

This means if you generate a supplied clock of 27MHz, this is 1000000/27 = 37037.03704 picosecond period.

Notice the .03704, this will be lost in the simulation and end up being an accumulated error after many cycles as when you do simulations which cover microseconds or milliseconds of time, that .03704 turns into -370.4 ns at the uS point and -370400ns at the ms point.  Even worse, the integer 37037 is an odd number meaning that when we delay 1/2 that for the high clock, then 1/2 again for the low clock, this adds another 5000ns of error at the uS point, or, 5000000ns at the ms point.

For this reason, it is better to choose clocks which divide evenly into 2x picosecond delays as you source simulated clock is 1/2 high time, 1/2 low time and you do not want rounding errors there.

So, a source clock of 25Mhz would generate 0 creep over time as its picosecond delay used to generate the reference clock is 20000 high, 20000 low, no odd fraction.

As for your PLL settings, especially when dealing with the requirement of a clean clock for the best DDR3 eye timing on the DQ buss, unless you designed your own PCB knowing the quality of the PLL's analog supply and layout, it is best to stick with even round integer multiply/divide output clocks.  IE, 25MHz x 16=400Mhz, x14=350Mhz, x18=450Mhz.  Or in the case of a 27MHz clock, I would stick with x16=432MHz, x14=378Mhz, even x15 should still be good at 405Mhz.  (x15 would usually internally set the loop filter to out divide by 30, reference divide by 2, so not a huge odd fraction like trying to generate 398Mhz.  In fact, Lattice's PLL demands the reference gets internally divided by beginning at 2 and only going up by even numbers.)

For simulation, stick with the round numbers for now like 25MHz and 400MHz PLL out.  Worry about the oddball frequencies later as there might not be a viable solution anyways.

Do not worry about how I managed/strong armed Altera's PLLs into doing what I like from provided parameters.  With Gowin, it is ok if you are left with no choice but to provide only a selection of source clocks and output clocks per-generated by Gowin's IP tool.  Just make sure Gowin provides you with an authentic PLL simulation library and not a dumb down tiny piece of fake code which only generates a fake clock by #(period) high/low approximation.

[SpacedCowboy]

So I'm seeing some of this, yes. If I set the PLL to produce a 250MHz output from a 25MHz input, I can see it just fine (see below). If I set it to be 400MHz from that same 25MHz input, I get a 500MHz output, and the same result in simulation (500MHz output) for setting it to produce 350MHz from 25MHz...

I'm putting that down to the output having to have a half-period of an integral number of nanoseconds in the simulation, thus limiting my options.

I tried using

    `timescale 100ps / 1ps

to see if that would help out, but that just gave me an error from Modelsim ("# ** Error: (vsim-3601) Iteration limit reached at time 5002 ns.")

FWIW, the Verilog code to simulate the PLL is non-trivial - it's about 390 lines of Verilog, and seems to read the parameterised module that is generated.

[BrianHG]

Did you use Gowin's PLL tool to generate it's factors?  Ore are you manually entering the factors you want?

Careful here as when I select multiply and divide VCO settings with Altera, they auto-correct my factors to make sure the PLL's internal VCO stays within its allowable range.

Maybe you are exceeding a minimum or maximum range for Gowin's internal VCO?
Maybe you made a mistake in your setup or math?

If you multiply 25MHz by 16, you should get 400MHz out.

But if Gowin's reference divider must be set to a minimum of 2, like with Cyclone V and Lattice ECP5 series FPGAs, even though you request 1, it will be pushed to 2 and if your feedback is set too small, like 16 instead of 32, your oscillator output may max out instead of giving you the right frequency.

Even more, if the PLL's phase detector needs to operates below 5MHz such as withing Lattice parts, this means you need to divide the source reference by at least 6, the adjust your feedback divider accordingly.

[SpacedCowboy]

Yes, this is using the tool to generate the Verilog model of the PLL, the below was for the 350MHz version:

Code: [Select]

//Copyright (C)2014-2022 Gowin Semiconductor Corporation.
//All rights reserved.
//File Title: IP file
//GOWIN Version: V1.9.8.07
//Part Number: GW2A-LV18PG256C8/I7
//Device: GW2A-18
//Created Time: Thu Aug 25 18:50:57 2022

module Gowin_rPLL (clkout, lock, reset, clkin);

output clkout;
output lock;
input reset;
input clkin;

wire clkoutp_o;
wire clkoutd_o;
wire clkoutd3_o;
wire gw_gnd;

assign gw_gnd = 1'b0;

rPLL rpll_inst (
    .CLKOUT(clkout),
    .LOCK(lock),
    .CLKOUTP(clkoutp_o),
    .CLKOUTD(clkoutd_o),
    .CLKOUTD3(clkoutd3_o),
    .RESET(reset),
    .RESET_P(gw_gnd),
    .CLKIN(clkin),
    .CLKFB(gw_gnd),
    .FBDSEL({gw_gnd,gw_gnd,gw_gnd,gw_gnd,gw_gnd,gw_gnd}),
    .IDSEL({gw_gnd,gw_gnd,gw_gnd,gw_gnd,gw_gnd,gw_gnd}),
    .ODSEL({gw_gnd,gw_gnd,gw_gnd,gw_gnd,gw_gnd,gw_gnd}),
    .PSDA({gw_gnd,gw_gnd,gw_gnd,gw_gnd}),
    .DUTYDA({gw_gnd,gw_gnd,gw_gnd,gw_gnd}),
    .FDLY({gw_gnd,gw_gnd,gw_gnd,gw_gnd})
);

defparam rpll_inst.FCLKIN = "25";
defparam rpll_inst.DYN_IDIV_SEL = "false";
defparam rpll_inst.IDIV_SEL = 0;
defparam rpll_inst.DYN_FBDIV_SEL = "false";
defparam rpll_inst.FBDIV_SEL = 13;
defparam rpll_inst.DYN_ODIV_SEL = "false";
defparam rpll_inst.ODIV_SEL = 2;
defparam rpll_inst.PSDA_SEL = "0000";
defparam rpll_inst.DYN_DA_EN = "true";
defparam rpll_inst.DUTYDA_SEL = "1000";
defparam rpll_inst.CLKOUT_FT_DIR = 1'b1;
defparam rpll_inst.CLKOUTP_FT_DIR = 1'b1;
defparam rpll_inst.CLKOUT_DLY_STEP = 0;
defparam rpll_inst.CLKOUTP_DLY_STEP = 0;
defparam rpll_inst.CLKFB_SEL = "internal";
defparam rpll_inst.CLKOUT_BYPASS = "false";
defparam rpll_inst.CLKOUTP_BYPASS = "false";
defparam rpll_inst.CLKOUTD_BYPASS = "false";
defparam rpll_inst.DYN_SDIV_SEL = 2;
defparam rpll_inst.CLKOUTD_SRC = "CLKOUT";
defparam rpll_inst.CLKOUTD3_SRC = "CLKOUT";
defparam rpll_inst.DEVICE = "GW2A-18";

endmodule //Gowin_rPLL

Input is 25MHz, output is (presumably) set to (1+13) * input, since 'rpll_inst.FBDIV_SEL' is always the multiple-1.

I'm setting the values in the tool, then clicking on 'calculate' to make sure that happens (and it says 'success' or tells me it can't do it), then agreeing to let it overwrite the files, and then running my Modelsim script which reads the new file. PLL config tool looks like the below in case I'm missing something.

I am only using the 'general' PLL mode, the advanced mode unlocks more of the options but doesn't add anything not on the page, AFAICT.

[BrianHG]

Sounds like buggy a buggy IP user interface code.
Take a look at gowins PLL VCO & phase comparitor's range and manually choose and enter your clock divider factors.  Maybe then you will get the right results.

[BrianHG]

I tried using

    `timescale 100ps / 1ps

I always use `timescale 1ps / 1ps.

Also, don't forget in the vsim line to use '-t 1ps', just to be explicit.

[SpacedCowboy]

And this, of course, was it. I'm not sure about "remembering" to use '-t 1ps' as much as "discovering" to use it, though

I used a mashup of your Modelsim setup.do file from the link in the other thread and the ones that the FAE sent above. Mine had "-t 1ns" in it, and I didn't realise what the argument did - I ought to have gone and checked...

So with '-t 1ps', I get a very long sample (and I can probably fix that), but after setting appropriate clock-delays in the verilog, now that things are in ps not ns, I get a full-wave output-clock period of 2.858 ns and a corresponding frequency of 349.895 MHz for my nominal 350MHz clock.

So, cool - I now have a simulated PLL
 

[BrianHG]

Excellent, but, remember your full goal.

You need to insert your gowin PLL into my 'BrianHG_DDR3_PLL_tb.sv' and get it to replicate what I made the Altera PLL do.  Maybe even just add it to my code running the 2 side by side to compare.

Remember, as an example, you need:
A master 0 deg 400MHz out. for the DDR3_CK.
A 400MHz with a 270 degrees phase shift for writing DDR3 data.
A 400MHz with user phase tuning controls for the read DDR3 data.
A 200Mhz at 0 deg from the 400MHz for the user interface.
A 100Mhz at 0 deg from the 400Mhz for the initialization and long period timer logic.

If you cannot do the 3 phases from the same PLL, then you will need to use a phase adjustable DLL or second PLL for the DDR3 read data.

[SpacedCowboy]

Yep, just the first step.

Looks like, from a single PLL, I can have

• a clock
• the same clock with variable or fixed phase & duty-cycle options
• the input clock divided by some number
• the input clock divided by 3

I have 4 PLLs, so to get your clocks would take:

PLL #1: Input = board clock
 - 400MHz @ 0 degrees
 - 400MHz @ 270 degrees fixed

PLL #2: Input = 400MHz @ 0 degrees
 - 400 MHz @ 0 degrees (useless duplicate)
 - 400 MHz @ <user> degrees
 - 200 MHz @ 0 degrees

PLL #3 : Input = 200MHz @ 0 degrees
 - 200 MHz @ 0 degrees (useless duplicate)
 - 100 MHz @ 0 degrees


Using 3 of 4 PLLs seems excessive unless there's no other way, and there's an HCLK primitive that I seem to have 8 of in the device, along with a CLKDIV2 primitive that takes an HCLK and (surprise!) divides it by 2. As long as I can source an HCLK from a PLL I might be able to get away with only 2 PLLs.

I also found the attached...

A fair amount more reading to do this weekend, I think

[BrianHG]

I do not use DQS port triggering.
I just use DDR out and IO buffers.


You should be able to get it down to 2 plls as I saw 4 outputs on each.

[ali_asadzadeh]

SpacedCowboy please share your gowin project and modelsim project on github or in here.

Thanks

[BrianHG]

Yep, just the first step.

Looks like, from a single PLL, I can have

• a clock
• the same clock with variable or fixed phase & duty-cycle options
• the input clock divided by some number
• the input clock divided by 3

I have 4 PLLs, so to get your clocks would take:

PLL #1: Input = board clock
 - 400MHz @ 0 degrees
 - 400MHz @ 270 degrees fixed

PLL #2: Input = 400MHz @ 0 degrees
 - 400 MHz @ 0 degrees (useless duplicate)
 - 400 MHz @ <user> degrees
 - 200 MHz @ 0 degrees

PLL #3 : Input = 200MHz @ 0 degrees
 - 200 MHz @ 0 degrees (useless duplicate)
 - 100 MHz @ 0 degrees


Using 3 of 4 PLLs seems excessive unless there's no other way, and there's an HCLK primitive that I seem to have 8 of in the device, along with a CLKDIV2 primitive that takes an HCLK and (surprise!) divides it by 2. As long as I can source an HCLK from a PLL I might be able to get away with only 2 PLLs.

I also found the attached...

A fair amount more reading to do this weekend, I think

Why cant PLL1 have your third output at 100MHz.
In fact, I would make #1 output 200MHz and #2 output 100Mhz as the timing on the 100MHz is least crucial compared to the 200MHz's timing compared to the master 400MHz.

[SpacedCowboy]

So, reading the fine manual, it seems that output 3 (CLKOUTD) is a divisor of either output 1 or 2, however using the tool, it seems to be slaved to the clock input instead, so playing with numbers I can get:

- Output 1 & 2 must be the same frequency, with #2 having an optional phase/duty-cycle modification
- Output 3 is based on the input clock, not outputs 1 or 2, and can only be divisions > 1 of that clock
- Output 4 is based on the input clock and is a fixed /3 of it.

If the input clock is 25MHz, and outputs 1,2 are both 400 MHz, enabling output 3 and selecting /2 gives me a 12.5MHz clock output for CLKOUTD in the tool UI 

Could be a UI bug, could be me not grokking it. I’ll play with the parameters a little more today and see if I can cajole it to only use 2 PLL’s. I also have a DLL with variable delay, so that could be a possibility too.

I haven’t got any actual hardware yet, so I can’t just slap a scope on it to see

[edit: reading the manual *more*, it’s likely I had ‘bypass’ enabled on CLKOUTD, which bypasses the PLL. I don’t recall that being the case but it was late last night…]

[SpacedCowboy]

Ok, looks like I was causing problems for myself. The CLKOUTD signal is available sourced from CLKOUT/CLKOUTP (outputs 1,2) if the PLL is set to 'General' mode rather than 'Advanced'. So I can get

PLL1: input from board clock

• CLKOUT = 400 MHz, phase 0°
• CLKOUTP = 400 MHz, phase 270°
• CLKOUTD = 200 MHz, phase 0°

PLL2: input from board clock

• CLKOUT = 400 MHz, phase 0° (not used)
• CLKOUTP = 400 MHz, phase under user control
• CLKOUTD = 100 MHz, phase 0°

Which ought to be sufficient

[BrianHG]

Unless you can guarantee PLL-PLL phase under all-extreme temp-co cases, it would be best to swap the user 'CLKOUTP = 400 MHz, phase under user control' from the second PLL to the first and vice-versa.

The write clock is fairly tolerable going to the DDR3, but you want the read relationship between the master DDR3_CK and the return path along the PCB traces to be as locked as possible.

[SpacedCowboy]

SpacedCowboy please share your gowin project and modelsim project on github or in here.

Thanks

Sure, here you go. Nothing fancy

[BrianHG]

I think he meant is where did you get the 'prim_sim.v' library file which simulates the 'rPLL' as well as what appears to be the rest of the Gowin primitives.


So, you now have enough to run my Altera PLL side/by/side with you equivalent dual 'rPLL' modules running my example test-bench, comparing the 5 outputs side by side to see if my tuning controls line up, or, if you need to adjust something like the number of tuning steps / step, or the tuning direction.

[SpacedCowboy]

I think he meant is where did you get the 'prim_sim.v' library file which simulates the 'rPLL' as well as what appears to be the rest of the Gowin primitives.

Ah! That's in the original email reply from Gowin, point 5 in the Modelsim instructions:
> This can be found in the GOWIN EDA tool install area E.g. Gowin_V1.9.3.01Beta\IDE\simlib\<device_family>\prim_sim.v

Depends where you install it, but on my machine it's in C:\Gowin\Gowin_V1.9.8.07\IDE\simlib\<architecture>\prim_sim.v

So, you now have enough to run my Altera PLL side/by/side with you equivalent dual 'rPLL' modules running my example test-bench, comparing the 5 outputs side by side to see if my tuning controls line up, or, if you need to adjust something like the number of tuning steps / step, or the tuning direction.

Yep. Before I do that, I configured them, with the read-clock having a 90° phase shift on the dynamic inputs, and the write-clock having a 270° fixed phase shift, just to make sure that they'd simulate correctly, which worked fine...

The timing report did tell me the fastest it could update a single 12-bit counter (which I'd slaved to the ddrMain clock, just to stop anything from being optimized away) was 372 MHz, which was a little disappointing, it will cope with an 8-bit counter at 400 MHz, but it may also be io-related, since it's the path that's trying to drive a pad ("led") on counter-overflow.

[BrianHG]

I think he meant is where did you get the 'prim_sim.v' library file which simulates the 'rPLL' as well as what appears to be the rest of the Gowin primitives.

Ah! That's in the original email reply from Gowin, point 5 in the Modelsim instructions:
> This can be found in the GOWIN EDA tool install area E.g. Gowin_V1.9.3.01Beta\IDE\simlib\<device_family>\prim_sim.v

Depends where you install it, but on my machine it's in C:\Gowin\Gowin_V1.9.8.07\IDE\simlib\<architecture>\prim_sim.v

So, you now have enough to run my Altera PLL side/by/side with you equivalent dual 'rPLL' modules running my example test-bench, comparing the 5 outputs side by side to see if my tuning controls line up, or, if you need to adjust something like the number of tuning steps / step, or the tuning direction.

Yep. Before I do that, I configured them, with the read-clock having a 90° phase shift on the dynamic inputs, and the write-clock having a 270° fixed phase shift, just to make sure that they'd simulate correctly, which worked fine...

The timing report did tell me the fastest it could update a single 12-bit counter (which I'd slaved to the ddrMain clock, just to stop anything from being optimized away) was 372 MHz, which was a little disappointing, it will cope with an 8-bit counter at 400 MHz, but it may also be io-related, since it's the path that's trying to drive a pad ("led") on counter-overflow.

LOL... You do not know how to make multi-level high speed clocked designs, do you?

Anyways, in my DDR3 core, all my 400MHz clocked logic has at most is a 3 bit counter.  Everything else is shift registers.

All 4 to 9 bit counters are in the 200MHz clock domain.

Anything in the 8-12bit counters and addressed memory can be assigned to the 200 or 100MHz clock domain through the interface speed parameter.

Any real complex state machines is locked in the 100MHz clock domain.

How do you think I got a Cyclone IV to run at above 400MHz?  Even over clockable to 500Mhz?  Cyclone's core blockram maxes out at only 200MHz.

[SpacedCowboy]

LOL... You do not know how to make multi-level high speed clocked designs, do you?

Nope. Absolutely not. FPGAs are at best a sometimes hobby for me - quite happy to admit my utter ignorance of most of the details.

Anyways, in my DDR3 core, all my 400MHz clocked logic has at most is a 3 bit counter.  Everything else is shift registers.


All 4 to 9 bit counters are in the 200MHz clock domain.

Anything in the 8-12bit counters and addressed memory can be assigned to the 200 or 100MHz clock domain through the interface speed parameter.

Any real complex state machines is locked in the 100MHz clock domain.

How do you think I got a Cyclone IV to run at above 400MHz?  Even over clockable to 500Mhz?  Cyclone's core blockram maxes out at only 200MHz.

That actually makes me feel a lot better - I was wondering if I was beating a dead horse here...

[BrianHG]

Look here:
https://github.com/BrianHGinc/BrianHG-DDR3-Controller/blob/main/Screenshots/FMAX_screenshots/Cyclone%20III-6_400MHz_EP3C40F484C6_GFX.png

Altera's 20 year old silicon.  Bottom of the line.
DDR3_PLL5[0..4] clock outputs, compiler FMAX results.
clk 0=DDR3_CK,1=270deg write clock, 2=tunable read clock, 3=1/2 speed, 4=1/4 speed.

Here is the slowest version of that FPGA:
https://github.com/BrianHGinc/BrianHG-DDR3-Controller/blob/main/Screenshots/FMAX_screenshots/Cyclone%20III-8_300MHz_EP3C40F484C8_GFX.png

I only requested 300Mhz for that one, but, I bet if I asked 350MHz, it would clear the bar.  Just like the top one where if I requested 450MHz, it would have cleared that bar.