| *** tpb <[email protected]> has joined #symbiflow | 00:00 | |
| *** ec <ec!~ec@gateway/tor-sasl/ec> has quit IRC (Quit: ec) | 03:45 | |
| sf-slack | <pepermont> Hello, is there a way to get the exact hex symbol in the bitstream that indicates the beginning of a a LUT initialization vector given that you know, CLB coordinates, slice, and LUT identifier (e.g. BLUT of the upper slice of CLB X28Y55)? | 07:12 |
|---|---|---|
| sf-slack | <pepermont> (without having to turn the bitstream in .frames first) | 07:15 |
| *** cr1901 <cr1901!~William@2601:8d:8600:911:35ce:6bfb:461f:1853> has quit IRC (Read error: Connection reset by peer) | 07:57 | |
| *** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 08:04 | |
| *** TMM_ <[email protected]> has joined #symbiflow | 08:05 | |
| ssb | hi! what is the status of spartan6 support in nextpnr? (someone demoed it on youtube: youtu.be/YE54Kozd1iE , but no useful details can be googled offhand) | 11:30 |
| sf-slack | <fahrenkrog> Hi all, I'm also curious about the status of the 7 series. I have an Artix board, and I remember a conference where mithro was talking about the current status back then (CCC maybe?), and I think only DSP and SERDES blocks were missing. That was November 2019, what's the status of Xilinx's FPGAs now? Is there a place where we can find information about that? | 13:33 |
| sf-slack | <kgugala> @fahrenkrog you can take a look at https://symbiflow-examples.readthedocs.io/en/latest/ | 13:37 |
| tpb | Title: Welcome to SymbiFlow examples! — SymbiFlow examples documentation (at symbiflow-examples.readthedocs.io) | 13:37 |
| sf-slack | <tmichalak> @pepermont there is a way to get the data you are interested in. Start with looking up the base address of the CLB in the tilegrid (e.g. https://raw.githubusercontent.com/SymbiFlow/prjxray-db/master/artix7/xc7a50t/tilegrid.json) ``` "CLBLL_L_X2Y0": { "bits": { "CLB_IO_CLK": { "baseaddr": "0x00400100", "frames": 36, "offset": 0, | 13:50 |
| sf-slack | "words": 2 } }, "clock_region": "X0Y0", "grid_x": 10, "grid_y": 155, "pin_functions": {}, "prohibited_sites": [], "sites": { "SLICE_X0Y0": "SLICEL", "SLICE_X1Y0": "SLICEL" }, "type": "CLBLL_L" },``` Next you can extract the data for a range of non zero frames with: ```$XRAY_BITREAD -F 0x00400100:0x00400180 -z | 13:50 |
| sf-slack | design.bit``` or a single frame ```$XRAY_BITREAD -f 0x00400124 -z design.bit``` the offset and words tell you which 32bit word you should be looking at. Now to tell which bit is responsible for configuring the BLUT you should refere to `segbits_clbll_l.db` in the database, e.g. ```CLBLL_L.SLICEL_X0.BLUT.INIT[00] 32_31``` this tells you that the 31st bit of the 32nd frame is responsible for setting INIT[0] which translates into | 13:50 |
| sf-slack | frameaddress 0x00400120, 31st bit of the 0th word as the words are numbered from 0, so ```$XRAY_BITREAD -f 0x00400120 -z design.bit``` should get you the frame. Here is an example output I had for a different frame ```Frame 0x00400027 (Type=0 Top=1 Row=0 Column=0 Minor=39): 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 | 13:50 |
| sf-slack | 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00a00000 20820000 00000000 00000000 00000000 00000000 00000000 00000000 | 13:50 |
| sf-slack | 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 20a00000 20820000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000200 00000202 ``` The very first word is the one I am talking about so in this case it's 0x00000000, but since the data is | 13:50 |
| sf-slack | presented LE a `0b1` on the 31st bit would be presented as 0x00008000 | 13:50 |
| sf-slack | <tmichalak> @fahrenkrog SymbiFlow does support SERDES blocks for 7 Series. We have a basic fuzzer for the DSP bits | 13:59 |
| sf-slack | <pepermont> @tmichalak Thanks for the reply! Actually what I would like is to modify specific LUT initialization vectors so I would like to know the bit position in the actual bitstream not in the formatted file that `bitread` will give me. To be more specific for my use-case, I want for example to start with a given bitstream and then generate X bitstreams from in, where each bitstream will differ from the other in the | 14:04 |
| sf-slack | initialization vector of 1-3 LUTs. What I do so far is create the appropriate fasm files and then turn them into bitstreams. But this process takes a lot of time and it feels like overkill since I do such a small modification. | 14:04 |
| sf-slack | <tmichalak> @pepermont yeah, so there is nothing out-of-the-box for your use case. But if you have an idea how such a tool/script would be useful you are always welcome to open an issue and then a PR with what you come up with | 14:10 |
| sf-slack | <pepermont> Oh, I see, thanks @tmichalak ! :) | 14:11 |
| gatecat | bitstreams also have CRCs by default, so just patching the bits for the LUT isn't enough, you also have to recalculate the CRC as well | 14:12 |
| sf-slack | <pepermont> @gatecat(IRC) Or alternatively I can disable the CRC during the bitstream generation in vivado, right? | 14:14 |
| gatecat | Not sure if Vivado let's you totally turn it off but it's hypothetically possible (albeit perhaps a bad idea) | 14:14 |
| sf-slack | <pepermont> I usually use the following command `set_property BITSTREAM.GENERAL.CRC DISABLE [current_design]` and it seems to work, meaning that I am able to modify and load bitstreams successfully | 14:19 |
| sf-slack | <kgugala> does the device check the CRC? | 14:20 |
| sf-slack | <kgugala> or is it checked only by the loading SW? | 14:20 |
| sf-slack | <pepermont> That I dont know, it has been some time since the last time I did that but when I was loading crc protected bitstreams that I had applied modifications on from the vivado interface, it was failing to load | 14:22 |
| sf-slack | <pepermont> but with the above command they were loading like usual | 14:22 |
| sf-slack | <tmichalak> It's the device that calculates the CRC when loading the configuration data packets. However, since it's actually the configuration bitstream that can, but doesn't have to issue a Check CRC command the CRC check can be disabled. Of course with the risk of damaging your board with an incorrect configuration. | 14:34 |
| *** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 15:10 | |
| *** TMM_ <[email protected]> has joined #symbiflow | 15:10 | |
| *** ec <ec!~ec@gateway/tor-sasl/ec> has joined #symbiflow | 15:52 | |
| *** cr1901 <cr1901!~William@2601:8d:8600:911:9d2c:cc23:b169:e830> has joined #symbiflow | 15:59 | |
| *** ec <ec!~ec@gateway/tor-sasl/ec> has quit IRC (Quit: ec) | 17:34 | |
| *** ec <ec!~ec@gateway/tor-sasl/ec> has joined #symbiflow | 17:34 | |
| *** ec <ec!~ec@gateway/tor-sasl/ec> has quit IRC (Remote host closed the connection) | 17:50 | |
| *** ec <ec!~ec@gateway/tor-sasl/ec> has joined #symbiflow | 17:51 | |
| *** ec <ec!~ec@gateway/tor-sasl/ec> has quit IRC (Remote host closed the connection) | 18:43 | |
| *** ec <ec!~ec@gateway/tor-sasl/ec> has joined #symbiflow | 18:44 | |
| *** ec <ec!~ec@gateway/tor-sasl/ec> has quit IRC (Ping timeout: 276 seconds) | 19:03 | |
| *** ec <ec!~ec@gateway/tor-sasl/ec> has joined #symbiflow | 19:05 | |
| *** ec <ec!~ec@gateway/tor-sasl/ec> has quit IRC (Quit: ec) | 19:35 | |
| *** ec <ec!~ec@gateway/tor-sasl/ec> has joined #symbiflow | 19:54 | |
| *** ec <ec!~ec@gateway/tor-sasl/ec> has quit IRC (Ping timeout: 276 seconds) | 20:18 | |
| *** adjtm <[email protected]> has quit IRC (Remote host closed the connection) | 20:35 | |
| *** adjtm <[email protected]> has joined #symbiflow | 20:36 | |
| *** ec <ec!~ec@gateway/tor-sasl/ec> has joined #symbiflow | 21:23 | |
| *** ec <ec!~ec@gateway/tor-sasl/ec> has quit IRC (Ping timeout: 276 seconds) | 23:09 | |
| *** ec <ec!~ec@gateway/tor-sasl/ec> has joined #symbiflow | 23:57 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!