f4pga / prjuray Goto Github PK

Documenting the Xilinx Ultrascale, Ultrascale+ and UltraScale MPSoC series bit-stream format.

License: Apache License 2.0

Shell 2.50% XSLT 0.20% Python 22.04% Makefile 2.94% Tcl 7.69% Verilog 4.79% Smarty 1.19% SystemVerilog 57.50% GDB 0.01% C++ 1.12% Pawn 0.01%

fpga xilinx xilinx-fpga ultrascale ultrascale-plus bitstream fuzzer vivado symbiflow

prjuray's Introduction

FOSS Flows For FPGA (F4PGA) project

This is the top-level repository for the F4PGA project, which is a Workgroup under the CHIPS Alliance; consisting of members from different backgrounds, including FPGA vendors, industrial users and academia (see Documentation > Community); who collaborate to build a more open source and software-driven FPGA ecosystem (IP, tools and workflows) to drive the adoption of FPGAs in existing and new use cases, and eliminate barriers of entry.

Documentation > Getting started (for everyone)
F4PGA Examples (for users)
F4PGA Architecture Definitions (for developers)

prjuray's People

Contributors

Stargazers

Watchers

Forkers

mithro litghost daveshah1 201934744 benglines tmichalak antmicro mfkiwl 0xbadcoffe common-config-bot midhatn gawadinc telantan

prjuray's Issues

HPIO config settings needed for litedram

Being able to build litedram through this would be a medium-term target for me, as I already had it working with the nextpnr+RapidWright flow (subject to bitrot, it may still even be working).

This will require the following extra HPIO modes/options to be fuzzed:

DIFF_POD12_DCI input/output (DQS), DIFF_SSTL12_DCI output (DRAM clock)
PRE_EMPHASIS
EQUALIZATION
INTERNAL_VREF

Reference: https://github.com/litex-hub/litex-boards/blob/master/litex_boards/platforms/zcu104.py and https://github.com/litex-hub/litex-boards/blob/master/litex_boards/platforms/mercury_xu5.py

Add and document support for the ZCU10[45] dev boards

It is my understanding that Antmicro want to support the ZCU10[45] dev boards.

ZCU104 - Zynq UltraScale+ XCZU7EV-2FFVC1156 MPSoC
ZCU102 - Zynq UltraScale+ XCZU9EG-2FFVB1156 MPSoC

Add option to bit2fasm to skip emitting empty CLE sites

daveshah: UltraScale+ devices have all unused LUTs set to output 1 by default, to save power
daveshah: this results in loads of extra set bits in the FASM
daveshah: it might be nice to have a bit2fasm option that skips these

Add license checking github action

https://github.com/SymbiFlow/actions/tree/main/checks

Should probably replace the scripts at;

ECC check in bitread failing on good bitstreams

Bitstreams from Vivado are failing the ECC check in bitread. This likely indicates there is something about the ECC calculation that is misunderstood. For now, ECC checking has been disabled. Once bitread is fixed, the checks should be re-enabled:

The -E flag disables errors on ECC check failures. There are two locations where the -E is being added:

https://github.com/SymbiFlow/prjuray/blob/02b31b5d7c19f66f50b3a28218921433df8a9af8/utils/bit2fasm.py#L38-L41

https://github.com/SymbiFlow/prjuray/blob/02b31b5d7c19f66f50b3a28218921433df8a9af8/utils/environment.sh#L35

Add and document support for KCU105

It is my understanding that Antmicro want to support the KCU105 dev boards.

KCU104 - XCKU040-2FFVA1156E FPGA

Bitread Architecture Error Message

Currently when using the bitread tool, the architecture defaults to the 7 series. When a bitstream is given of a different architecture such as Ultra Scale, this is the error messgae:

Part file not found or invalid

Perhaps the message could be changed to show that the architecture could also be the reason of the error. Or maybe a separate error message when the architecture is incorrect but the part is actually recognized? I don't know how hard that would be, or how resource intensive that would be.

Clocking bits status

CMT_RIGHT contains the PLL and MMCM blocks, along with the BUFGCTRL and BUFGCE_DIV blocks. CMT_RIGHT's interconnect is fairly complicated, so a more focused fuzzer is likely required to document those pips.

HDIO IO config bits not maching

Running the following small Ultra96 design through Vivado 2019.2 (xczu3eg-sbva484-1-i device):

module top(
    output led0,
    output led1
    );
    
    wire [3:0] plclk;
    PS8 ps8_i(.PLCLK(plclk));
    
    wire clk;
    BUFG_PS bufg_i (.I(plclk[0]), .O(clk));
    
    reg [23:0] ctr;
    
    always @(posedge clk)
        ctr <= ctr + 1'b1;
        
    assign {led1, led0} = ctr[23:22];
endmodule

set_property PACKAGE_PIN A9 [get_ports led0]
set_property PACKAGE_PIN B9 [get_ports led1]
set_property IOSTANDARD LVCMOS18 [get_ports led0]
set_property IOSTANDARD LVCMOS18 [get_ports led1]

and then running bit2fasm.py --verbose on the bitstream, there are some unknown bits:

# In frame 0x00081e00 12 bits were not converted.
{ unknown_bit = "00081e00_132_3", unknown_segment = "0x00081e00", unknown_segbit = "00_2115" }
{ unknown_bit = "00081e00_134_5", unknown_segment = "0x00081e00", unknown_segbit = "00_2149" }
{ unknown_bit = "00081e00_134_6", unknown_segment = "0x00081e00", unknown_segbit = "00_2150" }
{ unknown_bit = "00081e00_138_3", unknown_segment = "0x00081e00", unknown_segbit = "00_2211" }
{ unknown_bit = "00081e00_134_8", unknown_segment = "0x00081e00", unknown_segbit = "00_2152" }
{ unknown_bit = "00081e00_140_5", unknown_segment = "0x00081e00", unknown_segbit = "00_2245" }
{ unknown_bit = "00081e00_140_6", unknown_segment = "0x00081e00", unknown_segbit = "00_2246" }
{ unknown_bit = "00081e00_140_8", unknown_segment = "0x00081e00", unknown_segbit = "00_2248" }
{ unknown_bit = "00081e00_134_13", unknown_segment = "0x00081e00", unknown_segbit = "00_2157" }
{ unknown_bit = "00081e00_140_13", unknown_segment = "0x00081e00", unknown_segbit = "00_2253" }
{ unknown_bit = "00081e00_139_13", unknown_segment = "0x00081e00", unknown_segbit = "00_2237" }
{ unknown_bit = "00081e00_133_13", unknown_segment = "0x00081e00", unknown_segbit = "00_2141" }

# In frame 0x00081e01 14 bits were not converted.
{ unknown_bit = "00081e01_138_1", unknown_segment = "0x00081e00", unknown_segbit = "01_2209" }
{ unknown_bit = "00081e01_138_2", unknown_segment = "0x00081e00", unknown_segbit = "01_2210" }
{ unknown_bit = "00081e01_138_3", unknown_segment = "0x00081e00", unknown_segbit = "01_2211" }
{ unknown_bit = "00081e01_132_1", unknown_segment = "0x00081e00", unknown_segbit = "01_2113" }
{ unknown_bit = "00081e01_132_2", unknown_segment = "0x00081e00", unknown_segbit = "01_2114" }
{ unknown_bit = "00081e01_132_3", unknown_segment = "0x00081e00", unknown_segbit = "01_2115" }
{ unknown_bit = "00081e01_140_1", unknown_segment = "0x00081e00", unknown_segbit = "01_2241" }
{ unknown_bit = "00081e01_140_5", unknown_segment = "0x00081e00", unknown_segbit = "01_2245" }
{ unknown_bit = "00081e01_140_7", unknown_segment = "0x00081e00", unknown_segbit = "01_2247" }
{ unknown_bit = "00081e01_140_13", unknown_segment = "0x00081e00", unknown_segbit = "01_2253" }
{ unknown_bit = "00081e01_134_1", unknown_segment = "0x00081e00", unknown_segbit = "01_2145" }
{ unknown_bit = "00081e01_134_5", unknown_segment = "0x00081e00", unknown_segbit = "01_2149" }
{ unknown_bit = "00081e01_134_7", unknown_segment = "0x00081e00", unknown_segbit = "01_2151" }
{ unknown_bit = "00081e01_134_13", unknown_segment = "0x00081e00", unknown_segbit = "01_2157" }

It looks like these are the location of the two IO pins in the HDIO_TOP_RIGHT tile, and they are "unknown" because for some reason it isn't matching any of the IO types in the database - I haven't looked into why yet.

XIPHY clock routing bits missing

The data for RCLK_XIPHY_OUTER_RIGHT is missing the bits for the pips that select the clocks going out to the XIPHYs:

This isn't a massive blocker at the moment as the CMT should probably be a bigger priority, but just making sure this isn't forgotten.

Add zu7ev part?

I, and I suspect quite a few others out there too, am currently using a zcu104 for UltraScale+ testing which is 7ev based. This board was one of the easiest to get hold of UltraScale+ boards for a while.

Although the 3eg is a better device to start with due to its smaller size being easier to grapple with, it would be nice to have a 7ev database being built sooner rather than later. As well as just rerunning the tilegrid/tileconn stuff, it's also notable that it uses CMT_L rather than CMT_RIGHT, HPIO_L rather than HPIO_RIGHT, etc so some re-running of fuzzers would be needed too.

060-rclk sometimes fails with routing conflicts

Example:

2020-07-20T19:40:10 - xczu3eg-sfvc784-1-e/060-rclk-seed     - 3h01m: ERROR: [DRC RTSTAT-6] Partial route conflicts: 2 net(s) have a partial conflict. The problem bus(es) and/or net(s) are clk_IBUF[4]_inst/O, GLOBAL_LOGIC1.
2020-07-20T19:40:10 - xczu3eg-sfvc784-1-e/060-rclk-seed     - 3h01m: ERROR: [Vivado 12-1345] Error(s) found during DRC. Bitgen not run.
2020-07-20T19:40:10 - xczu3eg-sfvc784-1-e/060-rclk-seed     - 3h01m: make[3]: *** [build/specimen_371/design.dcp] Error 1
2020-07-20T19:40:10 - xczu3eg-sfvc784-1-e/060-rclk-seed     - 3h01m: make[2]: *** [run] Error 2

New family request

I have an XCVU33P and would like to see the Virtex Ultrascale+ HBM parts supported!

CLE bit documentation status

Most CLE bits are documented, however there is at least 1 bit that is not documented, and 1 case that is not understood.

Undocumented bits:

LCLKINV bit is not solved for

Case not understood:

The bits around DI4 <-> DI4/EX and CI_TOP.EX don't behave in an obvious many.

Add PIP inversion property to tile type JSON

This is the IS_INVERTED property in Vivado and is essential for correct clocking configuration, as some PIPs are inverted and this must be compensated for using the leaf clock buffer programmable inversion.

Example PIPs that are inverted (a small subset of get_pips -filter { IS_INVERTED == TRUE }):

RCLK_CLEM_L_X4Y149/RCLK_CLEM_L.CLK_CMT_MUX_2TO1_1_CLK_OUT->>CLK_HROUTE_CORE_OPT 
RCLK_CLEL_L_L_X5Y149/RCLK_CLEL_L_L.CLK_BUFCE_ROW_FSR_0_CLK_OUT->>CLK_TEST_BUF_SITE_1_CLK_IN 
RCLK_CLEL_L_L_X5Y149/RCLK_CLEL_L_L.CLK_CMT_MUX_3TO1_0_CLK_OUT->>CLK_VDISTR_BOT 
RCLK_CLEL_L_L_X5Y149/RCLK_CLEL_L_L.CLK_CMT_MUX_3TO1_1_CLK_OUT->>CLK_VDISTR_TOP 
RCLK_CLEL_L_L_X5Y149/RCLK_CLEL_L_L.CLK_CMT_MUX_3TO1_2_CLK_OUT->>CLK_VROUTE_BOT 
RCLK_CLEL_L_L_X5Y149/RCLK_CLEL_L_L.CLK_CMT_MUX_3TO1_3_CLK_OUT->>CLK_VROUTE_TOP 
RCLK_CLEL_L_L_X5Y149/RCLK_CLEL_L_L.CLK_CMT_MUX_2TO1_1_CLK_OUT->>CLK_HROUTE_CORE_OPT 
RCLK_CLEM_L_X6Y149/RCLK_CLEM_L.CLK_BUFCE_ROW_FSR_0_CLK_OUT->>CLK_TEST_BUF_SITE_1_CLK_IN 
RCLK_CLEM_L_X6Y149/RCLK_CLEM_L.CLK_CMT_MUX_3TO1_0_CLK_OUT->>CLK_VDISTR_BOT 
RCLK_CLEM_L_X6Y149/RCLK_CLEM_L.CLK_CMT_MUX_3TO1_1_CLK_OUT->>CLK_VDISTR_TOP 
RCLK_CLEM_L_X6Y149/RCLK_CLEM_L.CLK_CMT_MUX_3TO1_2_CLK_OUT->>CLK_VROUTE_BOT 
RCLK_CLEM_L_X6Y149/RCLK_CLEM_L.CLK_CMT_MUX_3TO1_3_CLK_OUT->>CLK_VROUTE_TOP 
RCLK_CLEM_L_X6Y149/RCLK_CLEM_L.CLK_CMT_MUX_2TO1_1_CLK_OUT->>CLK_HROUTE_CORE_OPT 
RCLK_CLEL_L_L_X7Y149/RCLK_CLEL_L_L.CLK_BUFCE_ROW_FSR_0_CLK_OUT->>CLK_TEST_BUF_SITE_1_CLK_IN 
RCLK_CLEL_L_L_X7Y149/RCLK_CLEL_L_L.CLK_CMT_MUX_3TO1_0_CLK_OUT->>CLK_VDISTR_BOT

Fuzz BUFCE_ROW_FSR configuration

Looks like half the work is done: https://github.com/SymbiFlow/prjuray/blob/3f5736237309e0670b4351f39fad8b4bd9cb6dd0/tools/dump_features.tcl#L646

but this isn't actually appearing in the databases yet presumably because nothing actually fuzzes this.

I believe this is needed to correctly clock-route a design that spans multiple clock regions in the vertical direction, see p245 of https://www.xilinx.com/support/documentation/sw_manuals/xilinx2019_2/ug949-vivado-design-methodology.pdf

However, this is not yet a blocking issue for me as nextpnr's UltraScale+ clock routing is still very simplistic and wouldn't be able to use this in any case.

I have an XCVU33P and would like to help.

I have an XCVU33P on a board which allows it to draw a lot of power (6x20A of 0.85V to VCCINT), and would like to help.

Inconsistent use of 'V' value prefix

Most of the 1/0 choices in https://github.com/SymbiFlow/prjuray-db/blob/master/zynqusp/segbits_clem.db use .V1/.V0 to distinguish value possibilities.

e.g.

CLEM.ABCDFF.CEUSED.V0 !14_07
CLEM.ABCDFF.CEUSED.V1 14_07
CLEM.ABCDFF.CLKINV.V0 !08_19
CLEM.ABCDFF.CLKINV.V1 08_19
CLEM.AFF.INIT.V0 12_02
CLEM.AFF.INIT.V1 !12_02

but WA[789]USED seems to be an exception:

CLEM.WA7USED.0 !08_23
CLEM.WA7USED.1 08_23
CLEM.WA8USED.0 !11_22
CLEM.WA8USED.1 11_22
CLEM.WA9USED.0 !09_22
CLEM.WA9USED.1 09_22

It would simplify things generating/parsing FASM if one convention could be established here (I personally don't mind either way.)

Transpose of LVCMOS18 I6 <-> I8:

-HPIO_RIGHT.IOB_X0Y12.IOSTANDARD_OUT.LVCMOS15_IDRIVE_I6_SLEW_SLEW_FAST_LVCMOS18_IDRIVE_I6_SLEW_SLEW_FAST_LVCMOS18_IDRIVE_I8_SLEW_SLEW_FAST !02_689 !02_703 !02_745 !02_746 02_778 03_688 !03_693 !03_696 !03_700 !03_734 !03_745 03_777 03_778 !03_779 !03_780
+HPIO_RIGHT.IOB_X0Y12.IOSTANDARD_OUT.LVCMOS15_IDRIVE_I6_SLEW_SLEW_FAST_LVCMOS18_IDRIVE_I8_SLEW_SLEW_FAST_LVCMOS18_IDRIVE_I6_SLEW_SLEW_FAST !02_689 !02_703 !02_745 !02_746 02_778 03_688 !03_693 !03_696 !03_700 !03_734 !03_745 03_777 03_778 !03_779 !03_780

New bit coming or going:

-HPIO_RIGHT.IOB_X0Y19.IOSTANDARD_OUT.LVCMOS15_IDRIVE_I12_SLEW_SLEW_SLOW 00_987 00_988 00_989 00_990 00_991 !00_993 !00_994 !00_996 !00_997 !00_998 00_1065 !00_1066 00_1067 01_976 !01_981 !01_982 !01_984 !01_985 01_986 01_987 01_988 01_989 01_990 !01_992 !01_993 !01_994 !01_996 !01_997 !01_1022 01_1065 01_1066 !01_1067 !01_1068 !02_706 !02_709 !02_1163 !03_705 !03_709 03_972
+HPIO_RIGHT.IOB_X0Y19.IOSTANDARD_OUT.LVCMOS15_IDRIVE_I12_SLEW_SLEW_SLOW 00_987 00_988 00_989 00_990 00_991 !00_993 !00_994 !00_996 !00_997 !00_998 00_1065 !00_1066 00_1067 01_976 !01_981 !01_982 !01_984 !01_985 01_986 01_987 01_988 01_989 01_990 !01_992 !01_993 !01_994 !01_996 !01_997 !01_1022 01_1065 01_1066 !01_1067 !01_1068 01_1123 !02_706 !02_709 !02_1163 !03_705 !03_709 03_972