f4pga / prjuray Goto Github PK
View Code? Open in Web Editor NEWDocumenting the Xilinx Ultrascale, Ultrascale+ and UltraScale MPSoC series bit-stream format.
Home Page: https://prjuray.rtfd.io
License: Apache License 2.0
Documenting the Xilinx Ultrascale, Ultrascale+ and UltraScale MPSoC series bit-stream format.
Home Page: https://prjuray.rtfd.io
License: Apache License 2.0
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
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.
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
It is my understanding that Antmicro want to support the KCU105 dev boards.
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.
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, 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.
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.
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:
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
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:
Case not understood:
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.)
In the current database build, it looks like xczu3eg-sbva484-1-e is missing the package pins data. It is present for xczu3eg-sfvc784-1-e, though.
I have an XCVU33P and would like to see the Virtex Ultrascale+ HBM parts supported!
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.
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
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
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.