08:12 <reces> litghost Yes thats true but since this does not appear in the bitstream how can you know that the block type changed ?

08:36 <sf-slack2> <tmichalak> @reces The fact that the address is auto-incremented doesn't mean it is not there. So the addresses are in the bitstream and as @litghost said the block type is encoded in the upper bits of the address.

08:37 <reces> tmichalak Oh so how can you recalculate them withouth seeing them ? is there any rule as to in which order they come ?

08:42 <_whitenotifier-9> [fpga-tool-perf] acomodi opened issue #108: Create DataFrame to have easy-accessible results data - https://git.io/Jfl3t

08:42 <sf-slack2> <tmichalak> @reces: they start with the last FAR address and then they are incremented every _number_of_words_per_frame_ words, which is 101 for Series7, 93 for US+ etc.

08:44 <sf-slack2> <tmichalak> @reces: the `part.yaml` file X-Ray tells you about the existing ranges of frames in a given part and also has to be taken into accout

08:45 <sf-slack2> <tmichalak> @reces: for example, if say column 0 has 10 frames then the next frame after column 0 frame 9 is column 1 frame 0

08:45 <reces> tmichalak so the minor address increments every time a frame changes. And the block type changes according to what ?

08:46 <reces> ohhh

08:46 <sf-slack2> <tmichalak> @reces a similar rule applies for rows and clock_regions etc

08:46 <reces> so by looking at the board you know in what order you expect to get them ?

08:47 <sf-slack2> <tmichalak> @reces: pretty much

08:47 <reces> I think I got it thanks

08:47 <reces> one last thing regarding that

08:47 <reces> Why is there only a limited number of supported boards by xray ?

08:48 <reces> there is a big workload that needs to be repeated for every board ?

08:54 <sf-slack2> <tmichalak> For X-Ray there is usually only few extra files that are necessary to add a new board, such as tilegrid, part.yaml and package_pins so in general board specific information

08:56 <reces> tmichalak tilegrid is any extremely useful one ^^ . So its generation needs time/effort right? What I want to say is reverse engineering a bitsream of an unsupported board is no easy task, right ?

09:00 <sf-slack2> <tmichalak> @reces tilegrid plays a big role in the fasm2bit translation process

09:01 <reces> But one would guess in the bit2fasm as well right ?

09:01 <reces> because it needs to map the frame content to the correct clbs that are being used

09:14 <sf-slack2> <tmichalak> @reces, yes this applies for both sides

09:47 <reces> tmichalak thanks :)

14:44 <_whitenotifier-9> [symbiflow-arch-defs] mkurc-ant opened issue #1479: Add support for IOBUFDS primitive - https://git.io/JflzV

15:24 <sf-slack2> <mkurc> mithro: Could you push the latest XRay database?

22:41 <sf-slack2> <timo.callahan> I'm debugging the prjxray db I generated for xc7a100t parts. • The bitstream for "buttons" kinda works on the board -- all LEDs except led[3] and led[4] work as expected.

22:41 <sf-slack2> <timo.callahan> • If I use fasm2bels, and read the .v and .v.tcl into Vivado, then regenerate the bitstream, it works 100%

22:42 <sf-slack2> <timo.callahan> • Diffing the fasm between symbiflow and vivado, one of the diffs is related to one of the outputs:

22:46 <sf-slack2> <timo.callahan> ```(only in symbiflow fasm: < RIOI3_X57Y101.IDELAY_Y0.IDELAY_TYPE_FIXED < RIOI3_X57Y101.IDELAY_Y1.IDELAY_TYPE_FIXED < RIOI3_X57Y101.OLOGIC_Y0.OMUX.D1 < RIOI3_X57Y101.OLOGIC_Y0.OQUSED < RIOI3_X57Y101.OLOGIC_Y0.OSERDES.DATA_RATE_TQ.BUF < RIOI3_X57Y101.OLOGIC_Y1.OMUX.D1 < RIOI3_X57Y101.OLOGIC_Y1.OQUSED < RIOI3_X57Y101.OLOGIC_Y1.OSERDES.DATA_RATE_TQ.BUF```

22:47 <sf-slack2> <timo.callahan> • This location happens to be something I had in the prjxray/settings/artix7_100t.sh file: • export XRAY_IOI3_TILES="RIOI3_X57Y101 LIOI3_X0Y101"

22:50 <sf-slack2> <timo.callahan> Also, there are unknown bits in the (fixed) Vivado bitstream:

22:50 <sf-slack2> <timo.callahan> ```> # In frame 0x00001c9e 1 bits were not converted. > { unknown_bit = "00001c9e_3_9", unknown_segment = "0x00001c80", unknown_segbit = "30_105" } > > # In frame 0x00001c9f 1 bits were not converted. > { unknown_bit = "00001c9f_4_22", unknown_segment = "0x00001c80", unknown_segbit = "31_150" } > > # In frame 0x00001ca0 2 bits were not converted. > { unknown_bit = "00001ca0_4_2", unknown_segment =

22:50 <sf-slack2> "0x00001c80", unknown_segbit = "32_130" } > { unknown_bit = "00001ca0_2_16", unknown_segment = "0x00001c80", unknown_segbit = "32_80" } > > # In frame 0x00001ca1 2 bits were not converted. > { unknown_bit = "00001ca1_5_15", unknown_segment = "0x00001c80", unknown_segbit = "33_175" } > { unknown_bit = "00001ca1_3_29", unknown_segment = "0x00001c80", unknown_segbit = "33_125" }```

22:53 <sf-slack2> <timo.callahan> Is the XRAY_IOI3_TILES coincidence just a coincidence, or something I messed up? Or should I just chase down the unknown bits?

23:30 <litghost> The unknown bits are probably the issue

23:30 <litghost> How many total?

23:31 <litghost> Which IOSTANDARD is being used?

23:41 <sf-slack2> <timo.callahan> Those are all the unknown bits, what I listed. The only diff not shown above is another RIOI3, X57Y109, that looked exactly like the X57Y101 shown above.

23:43 <litghost> Check if the unknown bits you see match what mkurc in https://github.com/SymbiFlow/prjxray/issues/1323

23:43 <tpb> Title: Document missing bits required by LiteX to run on A200T · Issue #1323 · SymbiFlow/prjxray · GitHub (at github.com)

23:44 <sf-slack2> <timo.callahan> IOSTANDARD -- Vivado says lvcmos33, after I re-import it.

23:44 <sf-slack2> <timo.callahan> Ok I will check #1323.

23:49 <mithro> litghost: Does https://github.com/mithro/prjxray-db/commit/be9ab47f83ca6fde0848663882bee0092bf6948f look okay?

23:50 <mithro> litghost: I think the SSTL135_SSTL15 thing is expected?

23:50 <litghost> Yes

23:50 <litghost> We are adding SSTL15 to the supported IO list

23:50 <mithro> @litghost There looks to still be some instability in the DSP SDF output?

23:51 <litghost> mithro: That has been there since the DSP timing output was added back

23:51 <litghost> Commit looks good

23:51 <mithro> I put the xc7a100t in a the next commit so github would render the diff

23:52 <mithro> https://github.com/mithro/prjxray-db/commit/405c3bc720466a9963f1c302de5f0c6b4ee18073

23:53 <mithro> litghost / @timo.callahan / @mkurc - New Project X-Ray DB has been pushed to master!