Wednesday, 2020-03-04

« Tuesday, 2020-03-03 Index Thursday, 2020-03-05 »
*** tpb has joined #symbiflow00:00
*** Vonter_ has quit IRC01:18
*** Vonter has joined #symbiflow01:31
*** Vonter has joined #symbiflow01:38
*** Vonter has quit IRC01:46
*** proteusguy has joined #symbiflow01:58
*** citypw_ has joined #symbiflow02:13
*** Vonter has joined #symbiflow02:49
*** citypw has joined #symbiflow02:57
*** citypw_ has quit IRC03:00
*** Vonter has quit IRC03:22
*** Vonter has joined #symbiflow03:23
*** Vonter has joined #symbiflow03:30
*** Vonter has quit IRC03:51
*** titanbiscuit has quit IRC04:04
*** titanbiscuit has joined #symbiflow04:06
*** Vonter has joined #symbiflow04:30
*** Vonter has joined #symbiflow04:32
*** OmniMancer has joined #symbiflow06:07
*** OmniMancer1 has joined #symbiflow06:10
*** OmniMancer has quit IRC06:12
*** _whitelogger has quit IRC06:36
*** _whitelogger has joined #symbiflow06:38
*** AAGandomi has joined #symbiflow07:06
*** AAGandomi has quit IRC07:07
*** Bertl is now known as Bertl_zZ07:07
*** ZipCPU|afk has quit IRC07:28
*** ZipCPU_ has joined #symbiflow07:43
*** OmniMancer1 has quit IRC08:55
*** OmniMancer has joined #symbiflow08:56
*** celadon has quit IRC09:00
*** celadon has joined #symbiflow09:00
*** clay_1 has joined #symbiflow09:56
clay_1Hello !10:23
OmniMancerHi11:30
clay_1how are you doing ?11:30
ZirconiumXHello11:46
ZirconiumXclay_1: ^11:48
clay_1hey hey :)11:49
clay_1Does anyone know why I might be getting the following ?11:51
clay_1Traceback (most recent call last):  File "bit2fasm.py", line 8, in <module>    import fasmModuleNotFoundError: No module named 'fasm'11:51
sf-slack<kgugala> clay_1: you don't have fasm python module installed11:52
clay_1have I skipped some installation part or smthing ?11:52
sf-slack<kgugala> https://github.com/SymbiFlow/fasm11:52
tpbTitle: GitHub - SymbiFlow/fasm: FPGA Assembly (FASM) Parser and Generator (at github.com)11:52
clay_1will check out, thanks11:53
clay_1So I cloned and did "sudo python setup.py install"12:00
clay_1now I get Traceback (most recent call last):  File "bit2fasm.py", line 9, in <module>    import fasm.outputModuleNotFoundError: No module named 'fasm.output'12:01
sf-slack<acomodi> clay_1: have you sourced the target part under settings/ in xray?12:02
clay_1source settings/artix7.sh12:02
clay_1you mean that line ?12:02
sf-slack<acomodi> Yep12:02
clay_1I think I have, yes, I followed the installation guidelines in the github page12:03
clay_1sf-slack turns out I have changed terminal dumb me12:10
clay_1now i get the error that starts with Bitstream does not appear to be for this part12:11
clay_1which make me wonder 2 things12:11
clay_1is that due to the fact that this bitstream is created with later vivado version ?12:12
clay_1OR I have an unsupported part? I am sure that the fpga is an artix 7 but I am not sure about the exact part, doesnt the tools support artix7 in general ?12:13
sf-slack<acomodi> That is because you produced a bitstream for another part. Check what exact part you used in Vivado and than you can run the following to get the fasm output12:14
sf-slack<acomodi> $XRAY_BIT2FASM --part <part> <bitfile> > <fasm_output>12:14
sf-slack<acomodi> And make sure actually that the part used is supported, you can check that under database/artix7. The directories with the name of the parts are the one currently supported12:15
clay_1I see, looks like mine is not supported though. I still can experiment with bitstreams though12:17
clay_1I was under the impression that all artix7s have the same bitstream format12:18
clay_1or maybe the differences are that they have different number of clock regions etc ?12:19
sf-slack<tmichalak> clay_1: what part do you have exactly?12:24
clay_1I have a xc7a100t-csg32412:25
clay_1I have a nexys4 ddr board12:26
clay_1I tried using a bitstream file I found in the prjxray named device.bit and I got the following12:32
clay_1Can't open input file 'device.bit' for reading!12:33
sf-slack<acomodi> clay_1: So, for now, if you want to see how fasm works, you could set your Vivado project to target a supported board. Ofc it won't work on your board, but at least you can see what features are being set12:35
clay_1yes and get a better understanding of how the tool/utils work12:36
sf-slack<acomodi> *supported part12:37
sf-slack<acomodi> Exactly12:37
clay_1But I am still wondering which features are shared among all the 7 series12:39
clay_1the frame structure for example, shouldnt it be the same ?12:39
*** celadon has quit IRC12:39
sf-slack<tmichalak> The frame structure may be the same12:40
sf-slack<tmichalak> but the addresses may not, since there are more clock regions12:40
clay_1true, so the only thing they differ is how big its part is ?12:40
sf-slack<tmichalak> yes, different/bigger tilegrid means different base addresses hence different frame addresses12:41
clay_1nice12:42
clay_1so from the bit2fasm, I expect to get a file that will be identifying logic components and pips used12:43
clay_1along with the prjxray defined coordinates /12:43
clay_1?12:43
sf-slack<tmichalak> exactly, the fasm file is all there is needed to generate a full valid bitstream12:43
clay_1cool !12:44
sf-slack<tmichalak> and the coordinates are expressed in tiles12:44
clay_1how about the following12:44
clay_1is there a script that takes a bitstream as an input and partitions it to frames without changing the format of the bitstream data ?12:45
clay_1I tried the bitread but it just counted me how many words i have without giving an output file12:46
sf-slack<acomodi> What you want to obtain are the frames related to a bitstream, correct? In this case, you could produce a fasm first and from there use fasm2frames.py12:48
clay_1nice ! I will try to do that12:48
clay_1thank you !12:48
*** perillamint has quit IRC12:55
*** perillamint has joined #symbiflow12:56
sf-slack<tmichalak> clay_1: that's is strange that you can't get the frames and their content with bitread, by default it should print out everything to stdout13:03
clay_1Bitstream size: 3825897 bytesConfig size: 956434 words13:04
clay_1I also get the not found part thing so that should be why13:05
clay_1will try with a compatible bitstream again13:05
*** celadon has joined #symbiflow13:05
sf-slack<tmichalak> exactly, you need to pass the part_file13:05
sf-slack<tmichalak> if you sourced the environment the --part_file is added to the XRAY_BITREAD variable, but you can specify it explicitly and set to the correct part, e.g. ...database/artix7/xc7a50tfgg484-1/part.yaml13:07
clay_1hmm still got the same error, do i have to generate it from vivado 17.2 as well ? or version doesnt matter ?13:07
sf-slack<tmichalak> for the bitstream the vivado version doesn't matter13:08
clay_1"if you sourced the environment the --part_file is added to the XRAY_BITREAD variable, but you can specify it explicitly and set to the correct part, e.g. ...database/artix7/xc7a50tfgg484-1/part.yaml"13:09
clay_1so probably i should do that13:09
clay_1should I change the line in environment.sh to look like export XRAY_BITREAD="database/artix7/xc7a50tfgg484-1/part.yaml" ?13:14
sf-slack<tmichalak> No, you need the whole command, ie path to the bitread tool and the the --part-yaml switch with the correct path.13:17
clay_1so like that ? export XRAY_BITREAD="${XRAY_TOOLS_DIR}/bitread database/artix7/xc7a50tfgg484-1/part.yam"13:25
clay_1or  export XRAY_BITREAD="${XRAY_TOOLS_DIR}/bitread --part_file ${database/artix7/xc7a50tfgg484-1/part.yam}"13:28
clay_1damn I suck :P13:28
clay_1ohhh i change nothing there but i change the export XRAY_PART_YAML= value, ritght ?13:35
sf-slack<acomodi> clay_1: you are targetting the xc7a50tfgg484-1 part now correct? I mean, the bitstream that is generated by Vivado13:35
clay_1actually no I was just repeating your example, i do /database/artix7/xc7a35tcpg236-1/part.yaml13:36
sf-slack<acomodi> Ok, so try to change the XRAY_PART in the /settings/artix7.sh to `xc7a35tcpg236-1`  and than source it again13:39
clay_1I still get the not found :/13:41
sf-slack<acomodi> Can you please print the full error output?13:43
clay_1sure13:43
clay_1Bitstream size: 2192120 bytesConfig size: 547990 wordsPart file not found or invalid13:44
clay_1i made the change you asked me and removed all the changes I did to the environment file13:44
sf-slack<acomodi> `Part file not found or invalid` This suggests two things. The part.yaml file is not there, but I doubt this is the issue, or, second option which is the most probable, is that the part.yaml is not compatible with the bitstream you are reading13:46
sf-slack<acomodi> To solve this you could generate the bitstream once again for the `xc7a35tcpg236-1` and try once again to read it.13:47
clay_1will do that13:48
clay_1regarding to that13:48
clay_1xc7a35tcpg236-113:48
clay_1is used in basys 3 from digilent and I am using the board instead of part in the vivado settings but those two should be identical, ritght ?13:49
sf-slack<acomodi> You can use one among the supported parts, but you need to make sure that the XRAY_PART_YAML points to the part you used to generate the bitstream13:49
clay_1If I do the XRAY_PART in the /settings/artix7.sh to `xc7a35tcpg236-1`  , this will happen automatically, right?13:50
sf-slack<acomodi> Should be ok13:50
sf-slack<acomodi> Yeah, but you need to source it again13:51
clay_1yes I do that13:51
clay_1I will try with a fresh bitstream now13:52
clay_1still the same13:55
clay_1so what i do pretty much is change the artix.sh file13:56
clay_1then I open terminal in prjxray13:56
clay_1source it13:56
clay_1cd tools13:56
clay_1and run the bitread13:56
sf-slack<acomodi> So, you can run bitread with $XRAY_BITREAD without doing cd tools. Just to make sure, the part.yaml that is used in XRAY_BITREAD is there right?14:00
clay_1yes it is there along with 3 json files and a csv file14:03
clay_1you mean like that14:05
clay_1prjxray$ XRAY_BITREAD 2.bit14:06
clay_1?14:06
sf-slack<acomodi> `$XRAY_BITREAD 2.bit > 2.frames` This must be done within the terminal that has the active environment (where you sourced artix7.sh)14:08
clay_1prjxray$ $XRAY_BITREAD 1.bit > 2.framesCan't open input file '1.bit' for reading!14:09
clay_1same would happen with 2.bit file14:09
clay_1silly me, these bitstreams are in toold directory14:11
sf-slack<acomodi> Is the bitfile in the current directory where you are calling bitread?14:11
clay_1It works now!14:13
sf-slack<acomodi> Cool14:14
clay_1thank you !14:14
clay_1I tried the bit2fasm now14:31
clay_1without cd-ing and it worked14:31
clay_1do you know how can I output the results to a file though? and what extension it has to have ?14:32
sf-slack<acomodi> like that `$XRAY_BIT2FASM bitfile.bit > outfile.fasm` Extension is not important but fasm file should have the .fasm extension for clarity14:33
clay_1thanks !14:38
clay_1for the record, this also worked now14:39
clay_1prjxray$ ./utils/bit2fasm.py 2.bit > 2.fasm14:39
clay_1In the results I got the following14:44
clay_1CLBLL_L_X2Y11.SLICEL_X0.AFF.ZINICLBLL_L_X2Y11.SLICEL_X0.AFF.ZRSTCLBLL_L_X2Y11.SLICEL_X0.AFFMUX.O6CLBLL_L_X2Y11.SLICEL_X0.ALUT.INIT[59:0] =14:44
clay_160'b111100001111000011110000111111110000111100001111000011110000CLBLL_L_X2Y11.SLICEL_X0.FFSYNCCLBLL_L_X2Y11.SLICEL_X0.NOCLKINVCLBLL_L_X2Y11.SLICEL_X0.PRECYINIT.C0CLBLL_L_X2Y11.SLICEL_X1.NOCLKINVCLBLL_L_X2Y11.SLICEL_X1.PRECYINIT.C014:44
clay_1oh damn this doesnt look good, I will upload a screenshot14:45
clay_1em looks like I cant, thats wierd because i could yesterday, anyway I will write only the important (imo) line14:47
clay_1CLBLL_L_X2Y11.SLICEL_X0.ALUT.INIT[59:0] = 60'b11110000111100001111000011111111000011110000111100001111000014:47
clay_1So the info from here should be that in the design there is a lut with a trut table of 60'b11110000111100001111000011111111000011110000111100001111000014:48
clay_1this lut is slice L14:48
clay_1A14:48
clay_1and in the slice X2Y1114:48
clay_1correct ?14:48
sf-slack<acomodi> In the CLBLL_L_X2Y11 actually14:50
sf-slack<acomodi> Which is formed by two SLICES, in this case you are using the bottom one14:50
clay_1and by bottom we mean the left right ?14:51
clay_1(when looking in vivado implemented design)14:52
sf-slack<acomodi> `CLBLL_L_X2Y12`  has two SLICES within it: `SLICE_X0Y12` and `SLICE_X1Y12`14:53
sf-slack<acomodi> By bottom I intend the `SLICE_X0Y12`14:54
clay_1sweet :)14:54
clay_1my only issue here is possibly with the  60'b11110000111100001111000011111111000011110000111100001111000014:54
clay_1it should be partitioned into 4 words each of them in a different frame14:55
clay_1right ?14:55
*** citypw has quit IRC14:59
OmniMancerwhy would the LUT init be split up?15:22
clay_1@omn15:23
clay_1OmniMancer Thats the way luts are represented on the bitstream15:23
clay_1I think I got my answer to that though15:24
clay_1it also looks by "60" that if it starts with 0s they are omitted15:24
clay_1since we expect all words to be 64 bits long15:25
OmniMancerFasm represents the settings, not the details of where the bits happen to fall in the bitstream15:25
clay_1yes so its rather the logical output of the lut6 truthtable, right ?15:25
OmniManceryes15:26
clay_1awesome ^^15:26
litghostclay_1:  FYI, if you wanted to add xc7a100t-csg324 to the supported list, it isn't too hard.  See15:27
litghosthttps://github.com/SymbiFlow/prjxray/blob/master/Makefile#L15115:27
litghostand15:27
litghosthttps://github.com/SymbiFlow/prjxray/blob/master/settings/artix200t.sh15:27
tpbTitle: prjxray/Makefile at master · SymbiFlow/prjxray · GitHub (at github.com)15:27
tpbTitle: prjxray/artix200t.sh at master · SymbiFlow/prjxray · GitHub (at github.com)15:27
clay_1@litghost Thanks I will take a look later, right now i am mesmerized by the tools and want to play with them haha15:29
litghostlol15:29
clay_1:p15:29
litghostJust for reference, the data underlying the LUT init is here (ish): https://github.com/SymbiFlow/prjxray-db/blob/master/artix7/segbits_clbll_l.db#L13-L2015:30
tpbTitle: prjxray-db/segbits_clbll_l.db at master · SymbiFlow/prjxray-db · GitHub (at github.com)15:30
litghostYou mentioned that the LUT is split amount two frames, you can see that in the underlying bit definitions clearly15:30
*** OmniMancer has quit IRC15:33
clay_1litghost actually i think its 4 frames. oh it is implied by the 32_xx,33_xx,34_xx,35_xx ?15:33
litghostYes15:33
clay_1nice, thanks !15:34
litghostThat first part in front of the "_" is the frame offset15:34
litghostThe second part is the bit offset within the frame15:34
litghostThe frame and bit offset for the tile is located within tilegrid.json15:34
clay_1    "CLBLL_L_X2Y11": {        "bits": {            "CLB_IO_CLK": {                "baseaddr": "0x00400100",                "frames": 36,                "offset": 22,                "words": 2            }15:39
clay_1so when i do a bitread here15:39
clay_1i will find CLBLL_L_X2Y11 contents in the frames with offset 0x00400100 untill 0x00400136 ?15:40
clay_1the words 2 means that each entry in the frames will be 8 hexes long15:43
clay_1and the offset 22 means that the first 22 sets of 2 words in each of the frames are unused ?15:43
litghostbitread doesn't use tilegrid.  bitread just converts the bitstream to frames, which have a frame address, a word address (0-100/whatever is valid for the part), and a bit offset (0-31)15:56
litghostbit2fasm aligns those (frame, word, bit) with both tilegrid and the segbits to determine what FASM feature the underlying bit(s) represent15:57
clay_1Even if it doesnt use it, you can make associations with the two, right ?16:00
litghostNo16:01
clay_1I am trying to map this16:01
litghostBecause tiles are interleaved16:01
clay_1https://github.com/SymbiFlow/prjxray-db/blob/master/artix7/segbits_clbll_l.db#L13-L2016:01
tpbTitle: prjxray-db/segbits_clbll_l.db at master · SymbiFlow/prjxray-db · GitHub (at github.com)16:01
litghostSo within 1 frame, there can be more than one tile data present16:01
clay_1so the 33_ is the minor adress in the frame file right ?16:01
clay_1oh16:02
litghostConcretely, the INT_[LR] tiles and the CLB tiles share frame addresses16:02
clay_1meaning that some of the frame bits are for INT_[LR] and some for the CLB, right ?16:02
*** mkru has joined #symbiflow16:16
*** mkru has quit IRC16:19
*** mkru has joined #symbiflow16:19
*** clay_1 has quit IRC16:24
*** proteus-guy has joined #symbiflow16:48
*** mkru has quit IRC17:00
litghostclay_1: Yes17:09
*** Bertl_zZ is now known as Bertl17:43
litghostclay_1: This is a little out of date, but https://symbiflow.github.io/prjxray-db/artix7/ might be useful for you?17:50
tpbTitle: X-Ray ARTIX7 Database (at symbiflow.github.io)17:50
litghostclay_1: The reason I mention it is out of date is that IO tiles are not reflected correctly17:50
-_whitenotifier-3- [prjxray-bram-patch] nelsobe opened issue #1: Binary vs. Hex init.mem Files - https://git.io/JvVTR18:50
-_whitenotifier-3- [prjxray-bram-patch] nelsobe opened issue #2: Should add generation of the alt.fasm file to the generate_tests.py script - https://git.io/JvVTg18:53
*** clay_1 has joined #symbiflow18:55
-_whitenotifier-3- [prjxray-bram-patch] mithro opened issue #3: Add LICENSE file - https://git.io/JvVT618:56
clay_1litghost I have seen this before but I wasnt able to make any sense out of it but the more I understand using the tools the more likely it becomes that it will be helpful, thanks !18:57
-_whitenotifier-3- [prjxray-bram-patch] mithro opened issue #4: Please make sure all commits have signoff lines - https://git.io/JvVTS19:02
*** adjtm_ has joined #symbiflow19:21
*** adjtm has quit IRC19:24
*** _whitelogger has quit IRC19:48
*** adjtm_ has quit IRC19:48
*** adjtm_ has joined #symbiflow19:49
*** _whitelogger has joined #symbiflow19:50
*** _whitelogger has quit IRC20:04
*** _whitelogger has joined #symbiflow20:07
*** clay_1 has quit IRC20:25
*** benelson has joined #symbiflow20:29
*** benelson has quit IRC20:41
*** benelson has joined #symbiflow20:42
-_whitenotifier-3- [prjxray-bram-patch] nelsobe opened issue #5: Change how ONE_TEST and LAST_TEST is specified in run_tests.py - https://git.io/JvVtX21:04
benelsonHi All, a new repo [prjxray-bram-patch] has been created.  It can patch the BRAM initialization values in bitstreams for 7 Series.  Fairly basic at this point but students are continuing to work on it.  Feedback appreciated.21:08
-_whitenotifier-3- [prjxray-bram-patch] nelsobe opened issue #6: Add ability to patch just selected BRAMs in a bitstream rather than all of them - https://git.io/JvVtj21:13
-_whitenotifier-3- [prjxray-bram-patch] nelsobe opened issue #7: Add ability to patch memories in hierarchical designs - https://git.io/JvVqJ21:15
*** ZipCPU_ is now known as ZipCPU21:32
*** benelson has quit IRC21:52
*** benelson has joined #symbiflow22:00
*** benelson has joined #symbiflow22:01
*** benelson has quit IRC22:05
*** benelson has joined #symbiflow22:09
*** benelson has quit IRC22:14
*** benelson has joined #symbiflow22:15
*** benelson has quit IRC22:17
*** benelson has joined #symbiflow22:19
*** benelson has quit IRC22:24
*** benelson has joined #symbiflow22:27
*** benelson has quit IRC22:31
*** benelson has joined #symbiflow22:35
*** benelson has quit IRC22:39
*** HEGAZY has joined #symbiflow22:40
*** benelson has joined #symbiflow22:41
*** benelson has joined #symbiflow22:41
*** HEGAZY has quit IRC22:48
*** benelson has quit IRC22:49
*** HEGAZY has joined #symbiflow22:51
*** benelson has joined #symbiflow22:55
*** benelson has quit IRC23:01
*** benelson has joined #symbiflow23:03
*** benelson has quit IRC23:07
*** benelson has joined #symbiflow23:09
*** benelson has quit IRC23:13
*** benelson has joined #symbiflow23:14
*** benelson has quit IRC23:19
*** benelson has joined #symbiflow23:19
*** benelson has joined #symbiflow23:20
*** benelson_ has joined #symbiflow23:23
*** benelson has quit IRC23:23
*** brent has joined #symbiflow23:26
*** benelson_ has quit IRC23:37
*** benelson has joined #symbiflow23:38
*** benelson has quit IRC23:43
« Tuesday, 2020-03-03 Index Thursday, 2020-03-05 »

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!