Giter VIP home page Giter VIP logo

f4pga / prjuray Goto Github PK

View Code? Open in Web Editor NEW
70.0 19.0 13.0 1.4 MB

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

Home Page: https://prjuray.rtfd.io

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

Project U-Ray

Project U-Ray is an attempt at documenting the bitstream format for the Xilinx Ultrascale and Ultrascale+ parts including all parts from the following lines;

  • Kintex Ultrascale
  • Virtex Ultrascale
  • Zynq UltraScale MPSoC
  • Kintex UltraScale+
  • Virtex UltraScale+
  • Zynq UltraScale+ MPSoC

It takes a lot of the learning from Project X-Ray and Project Trellis.

Target Parts

Ultrascale

Kintex UltraScale

Parts

  • TBD

Boards

  • TBD

Virtex UltraScale

Parts

  • TBD

Boards

  • TBD

Ultrascale+

Kintex UltraScale+

Parts

  • TBD - Targetting XCKU11P?

Boards

  • TBD

Virtex UltraScale+

Parts

  • TBD - Targetting XCVU13P?

Boards

  • TBD

Zynq UltraScale+

Parts

  • Zynq Ultrascale+ MPSoC - ZU3EG

Boards

Board Maker Price Part
Ultra96-V2 Zynq UltraScale+ ZU3EG Development Board (ULTRA96-V2-G) ??? Xilinx Zynq UltraScale+ MPSoC ZU3EG $USD249
Genesys ZU: Zynq Ultrascale+ MPSoC Development Board Digilent Xilinx Zynq UltraScale+ MPSoC ZU3EG $USD1,149

WebPack Parts

We have a goal of initially targeting parts supported by WebPack so that anyone can contribute.

WebPack supports the following parts;

  • Kintex UltraScale FPGA - XCKU025, XCKU035
  • Kintex UltraScale+ FPGA - XCKU3P, XCKU5P

Zynq UltraScale+ MPSoC -- UltraScale+ MPSoC

  • XCZU2EG, XCZU2CG, XCZU3EG, XCZU3CG, XCZU4EG, XCZU4CG, XCZU4EV, XCZU5EG, XCZU5CG, XCZU5EV, XCZU7EV, XCZU7EG, and XCZU7CG

Contributing

There are a couple of guidelines when contributing to Project U-Ray which are listed here.

Sending

All contributions should be sent as GitHub Pull requests.

License

All software (code, associated documentation, support files, etc) in the Project U-Ray repository are licensed under the very permissive Apache-2.0 License. A copy can be found in the LICENSE file.

All new contributions must also be released under this license.

Code of Conduct

By contributing you agree to the code of conduct. We follow the open source best practice of using the Contributor Covenant for our Code of Conduct.

Sign your work

To improve tracking of who did what, we follow the Linux Kernel's "sign your work" system. This is also called a "DCO" or "Developer's Certificate of Origin".

All commits are required to include this sign off and we use the Probot DCO App to check pull requests for this.

The sign-off is a simple line at the end of the explanation for the patch, which certifies that you wrote it or otherwise have the right to pass it on as a open-source patch. The rules are pretty simple: if you can certify the below:

    Developer's Certificate of Origin 1.1

    By making a contribution to this project, I certify that:

    (a) The contribution was created in whole or in part by me and I
        have the right to submit it under the open source license
        indicated in the file; or

    (b) The contribution is based upon previous work that, to the best
        of my knowledge, is covered under an appropriate open source
        license and I have the right under that license to submit that
        work with modifications, whether created in whole or in part
        by me, under the same open source license (unless I am
        permitted to submit under a different license), as indicated
        in the file; or

    (c) The contribution was provided directly to me by some other
        person who certified (a), (b) or (c) and I have not modified
        it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

then you just add a line saying

Signed-off-by: Random J Developer <[email protected]>

using your real name (sorry, no pseudonyms or anonymous contributions.)

You can add the signoff as part of your commit statement. For example:

git commit --signoff -a -m "Fixed some errors."

Hint: If you've forgotten to add a signoff to one or more commits, you can use the following command to add signoffs to all commits between you and the upstream master:

git rebase --signoff upstream/master

Contributing to the docs

In addition to the above contribution guidelines, see the guide to updating the Project U-Ray docs.

prjuray's People

Contributors

kgugala avatar litghost avatar mithro avatar mkurc-ant avatar wtatarski avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

prjuray's Issues

IOB fuzzer results are unstable

I've seen a couple different forms of instability in the IOB fuzzer results.

Examples:

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

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.

1/2/4/9/18 bit BRAM modes missing

Looks like the 1/2/4/9/18 bit BRAM width options are missing in the database. I can only see bits to enable the 36/72 bit SDP modes.

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:

Screenshot from 2020-07-22 14-46-39

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.

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.)

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

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.

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.

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 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

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

New family request

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

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.

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

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.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.