| *** tpb has joined #symbiflow | 00:00 | |
| *** citypw has joined #symbiflow | 01:51 | |
| *** siriusfox has quit IRC | 02:42 | |
| *** Degi has quit IRC | 03:33 | |
| *** Degi has joined #symbiflow | 03:37 | |
| *** citypw has quit IRC | 03:52 | |
| *** siriusfox has joined #symbiflow | 04:20 | |
| *** az0re has joined #symbiflow | 04:26 | |
| *** craigo has quit IRC | 05:06 | |
| *** citypw has joined #symbiflow | 05:20 | |
| *** Bertl_zZ is now known as Bertl | 05:30 | |
| *** OmniMancer has joined #symbiflow | 07:01 | |
| *** OmniMancer1 has quit IRC | 07:04 | |
| *** kraiskil has joined #symbiflow | 07:23 | |
| *** kraiskil has quit IRC | 07:51 | |
| *** kraiskil has joined #symbiflow | 08:05 | |
| *** reces has joined #symbiflow | 08:09 | |
| *** Ultrasauce_ has joined #symbiflow | 08:10 | |
| reces | litghost Yes thats true but since this does not appear in the bitstream how can you know that the block type changed ? | 08:12 |
|---|---|---|
| *** Ultrasauce has quit IRC | 08:15 | |
| *** kraiskil has quit IRC | 08:17 | |
| *** kraiskil has joined #symbiflow | 08:30 | |
| *** futarisIRCcloud has quit IRC | 08:32 | |
| 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:36 |
| reces | tmichalak Oh so how can you recalculate them withouth seeing them ? is there any rule as to in which order they come ? | 08:37 |
| -_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:42 |
| *** Ultrasauce_ is now known as Ultrasauce | 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| reces | there is a big workload that needs to be repeated for every board ? | 08:48 |
| 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:54 |
| 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 ? | 08:56 |
| sf-slack2 | <tmichalak> @reces tilegrid plays a big role in the fasm2bit translation process | 09:00 |
| 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:01 |
| sf-slack2 | <tmichalak> @reces, yes this applies for both sides | 09:14 |
| reces | tmichalak thanks :) | 09:47 |
| *** FFY00 has quit IRC | 10:43 | |
| *** reces has quit IRC | 10:54 | |
| *** kraiskil has quit IRC | 11:22 | |
| *** kraiskil has joined #symbiflow | 11:34 | |
| *** citypw has quit IRC | 12:12 | |
| *** citypw has joined #symbiflow | 12:12 | |
| *** craigo has joined #symbiflow | 12:17 | |
| *** kraiskil has quit IRC | 12:41 | |
| *** kraiskil has joined #symbiflow | 12:55 | |
| *** FFY00 has joined #symbiflow | 12:59 | |
| *** OmniMancer has quit IRC | 13:28 | |
| *** OmniMancer has joined #symbiflow | 13:29 | |
| *** gnufan has joined #symbiflow | 14:28 | |
| -_whitenotifier-9- [symbiflow-arch-defs] mkurc-ant opened issue #1479: Add support for IOBUFDS primitive - https://git.io/JflzV | 14:44 | |
| *** citypw has quit IRC | 14:50 | |
| *** gnufan has quit IRC | 15:16 | |
| sf-slack2 | <mkurc> mithro: Could you push the latest XRay database? | 15:24 |
| *** kraiskil has quit IRC | 15:43 | |
| *** kraiskil has joined #symbiflow | 15:56 | |
| *** OmniMancer has quit IRC | 16:06 | |
| *** adjtm_ has quit IRC | 17:28 | |
| *** adjtm_ has joined #symbiflow | 17:29 | |
| *** kraiskil has quit IRC | 18:16 | |
| *** craigo has quit IRC | 19:11 | |
| *** OmniMancer has joined #symbiflow | 21:15 | |
| *** gsmecher has quit IRC | 21:32 | |
| *** somlo has joined #symbiflow | 21:36 | |
| *** gsmecher has joined #symbiflow | 21:36 | |
| 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:41 |
| sf-slack2 | <timo.callahan> • Diffing the fasm between symbiflow and vivado, one of the diffs is related to one of the outputs: | 22:42 |
| 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:46 |
| 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:47 |
| 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:50 |
| 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? | 22:53 |
| *** daddesio has joined #symbiflow | 23:18 | |
| litghost | The unknown bits are probably the issue | 23:30 |
| litghost | How many total? | 23:30 |
| litghost | Which IOSTANDARD is being used? | 23:31 |
| 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:41 |
| 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:43 |
| 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:44 |
| mithro | litghost: Does https://github.com/mithro/prjxray-db/commit/be9ab47f83ca6fde0848663882bee0092bf6948f look okay? | 23:49 |
| 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:50 |
| 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:51 |
| mithro | https://github.com/mithro/prjxray-db/commit/405c3bc720466a9963f1c302de5f0c6b4ee18073 | 23:52 |
| mithro | litghost / @timo.callahan / @mkurc - New Project X-Ray DB has been pushed to master! | 23:53 |
| *** _whitenotifier-9 has quit IRC | 23:56 | |
| *** FFY00 has quit IRC | 23:57 | |
| *** FFY00 has joined #symbiflow | 23:57 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!