6.25 MHz reference clock for CP2100 PLL

[aspdigital]

I saw this in your clock manager code:

6.25MHz generator signal declarations

signal clk_625MHz_cnt							: integer range 15 downto 0;
signal clk_625MHz								: std_logic;

and in the architecture:

process (clk100_i)
begin
  if (rising_edge(clk100_i) then
    if (rst_i = '1') then
      clk_625MHz_cnt <= 0;
    else
      clk_625MHz_cnt <= clk_625MHz_cnt + 1;
      if (clk_625MHz_cnt < 8) then
        clk_625MHz <= '1';
      else
        clk_625MHz <= '0';
      end if;
    end if;
  end if;
end process;

There are two problems here.

1. clk_625MHz_cnt is reset in the process but clk_625MHz is not. Synthesis tools like Synplify and Vivado will do weird things when your process has a reset but signals assigned in that process are not reset. Either you reset everything in the process or nothing.
2. You constrained the range of your counter, which is correct, although I do not understand the 15 downto 0. It should be natural range 0 to 15. However, the real issue is that your counter is not checked for overflow, and in simulation, when its value is 15 and it increments, the simulation will fail when it increments to an invalid value. You always want simulation and synthesis to match. Yes, the synthesizer will see that you've set a range for that integer and use only four flip-flops, but that's not the point.

You need to test for the overflow and reset the counter when it happens:

if clk_625MHz_cnt = 15 then
  clk_625MHz_cnt <= 0;
else
  clk_625MHz_cnt <= clk_625MHz_cnt + 1;
end if;

and it's instructive to look at the synthesized code to see whether the overflow test added any extra logic.

[YetAnotherElectronicsChannel]

Hi aspdigital,

thanks for the feedback.
You are right, having a correct reset is always good to have. I will fix this in the code for the next commit (whenever this might happen).

In comparison to the other modules where I tested against testbenches, the clock-manager was mostly try&error coded as there is too much dynamic behavior ongoing and I just tested the functions against real hardware and using scope.

Therefore I might have overlooked that.

But I can confirm the Trion T20 is giving a correct 6.25 MHz clock out of this pin and I assume that this integer is also constructed as a 4-Bit register.

Before moving to Trion I prototyped this on a custom board with an Artix-7 (CMOD A7 board) and also did not had issues (which is of course no excuse for not doing it correctly).