Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add PLL pads. #241

Merged
merged 1 commit into from
May 3, 2024
Merged

Add PLL pads. #241

merged 1 commit into from
May 3, 2024

Conversation

yrabbit
Copy link
Collaborator

@yrabbit yrabbit commented Apr 8, 2024

Whenever possible, we arrange the PLL so as to use a direct connection of pins to the inputs of the primitive. The main work happens in nextpnr-himbaechel, here we only prepare data about which pin corresponds to which PLL.

Also added an example for Tangnano4k where two PLLs compete for one input pin. Only one of them can win, but both must function.

Whenever possible, we arrange the PLL so as to use a direct connection
of pins to the inputs of the primitive. The main work happens in
nextpnr-himbaechel, here we only prepare data about which pin
corresponds to which PLL.

Also added an example for Tangnano4k where two PLLs compete for one
input pin. Only one of them can win, but both must function.

Signed-off-by: YRabbit <rabbit@yrabbit.cyou>
@yrabbit
Copy link
Collaborator Author

yrabbit commented Apr 8, 2024

This is just placement and is compatible in all options, but we are waiting
YosysHQ/nextpnr#1309
after which it is possible that Tec0117 will be able to use its quartz at 100 MHz :)

@pepijndevos
Copy link
Member

pepijndevos commented Apr 28, 2024

If you've tested this on the boards that you have access to, feel free to merge. I will get back to testing the DSP and PLL stuff in ouisician2 at some point but my availability will get worse before it will get better.

@yrabbit
Copy link
Collaborator Author

yrabbit commented May 3, 2024

I checked the operation of PLL pads on a board close to tec0117 - szfpga GW1N-9.
To do this, I corrected the femto-riscv-15 example so that a PLL was used and the MSB LED showed a LOCKED signal.

   wire lock;
   assign led = ~{lock, x10[4:0]};
module Clockworks (
    input  wire CLK,
    input  wire RESET,
    output wire clk,
    output wire resetn,
    output lock
);
    parameter SLOW = 0;

    assign resetn = RESET ^ `INV_BTN;
    generate
        if (SLOW != 0) begin
         rPLL #(
            .FCLKIN("50.0"),
            .IDIV_SEL(12), // -> PFD = 3.8461538461538463 MHz (range: 3-400 MHz)
            .FBDIV_SEL(6), // -> CLKOUT = 26.923076923076923 MHz (range: 400-600 MHz)
            .ODIV_SEL(16) // -> VCO = 430.7692307692308 MHz (range: 600-1200 MHz)
        ) pll (.CLKOUTP(), .CLKOUTD(), .CLKOUTD3(), .RESET(1'b0), .RESET_P(1'b0), .CLKFB(1'b0), .FBDSEL(6'b0), .IDSEL(6'b0), .ODSEL(6'b0), .PSDA(4'b0), .DUTYDA(4'b0), .FDLY(4'b0),
            .CLKIN(CLK), // 50.0 MHz
            .CLKOUT(clk), // 26.923076923076923 MHz
            .LOCK(lock)
        );

On the board, the external crystal generates 50MHz which is fed to pin 27, but I connected it to the PLL PAD (pin 35):

shot-1

RISCV successfully worked at 27 MHz taken from the PLL output + LOCKED LED is on

szfpga-rpll-riscv.mp4

( I will store the changed test files in the branch https://github.com/yrabbit/apicula/tree/gw1n9-pll-pads)

@yrabbit yrabbit merged commit 14efe42 into YosysHQ:master May 3, 2024
12 of 14 checks passed
@yrabbit yrabbit deleted the pll-pads branch May 20, 2024 23:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants