<clay_1>
So I cloned and did "sudo python setup.py install"
<clay_1>
now I get Traceback (most recent call last): File "bit2fasm.py", line 9, in <module> import fasm.outputModuleNotFoundError: No module named 'fasm.output'
<sf-slack>
<acomodi> clay_1: have you sourced the target part under settings/ in xray?
<clay_1>
source settings/artix7.sh
<clay_1>
you mean that line ?
<sf-slack>
<acomodi> Yep
<clay_1>
I think I have, yes, I followed the installation guidelines in the github page
<clay_1>
sf-slack turns out I have changed terminal dumb me
<clay_1>
now i get the error that starts with Bitstream does not appear to be for this part
<clay_1>
which make me wonder 2 things
<clay_1>
is that due to the fact that this bitstream is created with later vivado version ?
<clay_1>
OR 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 ?
<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 output
<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 supported
<clay_1>
I see, looks like mine is not supported though. I still can experiment with bitstreams though
<clay_1>
I was under the impression that all artix7s have the same bitstream format
<clay_1>
or maybe the differences are that they have different number of clock regions etc ?
<sf-slack>
<tmichalak> clay_1: what part do you have exactly?
<clay_1>
I have a xc7a100t-csg324
<clay_1>
I have a nexys4 ddr board
<clay_1>
I tried using a bitstream file I found in the prjxray named device.bit and I got the following
<clay_1>
Can't open input file 'device.bit' for reading!
<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 set
<clay_1>
yes and get a better understanding of how the tool/utils work
<sf-slack>
<acomodi> *supported part
<sf-slack>
<acomodi> Exactly
<clay_1>
But I am still wondering which features are shared among all the 7 series
<clay_1>
the frame structure for example, shouldnt it be the same ?
celadon has quit [Ping timeout: 260 seconds]
<sf-slack>
<tmichalak> The frame structure may be the same
<sf-slack>
<tmichalak> but the addresses may not, since there are more clock regions
<clay_1>
true, so the only thing they differ is how big its part is ?
<sf-slack>
<tmichalak> yes, different/bigger tilegrid means different base addresses hence different frame addresses
<clay_1>
nice
<clay_1>
so from the bit2fasm, I expect to get a file that will be identifying logic components and pips used
<clay_1>
along with the prjxray defined coordinates /
<clay_1>
?
<sf-slack>
<tmichalak> exactly, the fasm file is all there is needed to generate a full valid bitstream
<clay_1>
cool !
<sf-slack>
<tmichalak> and the coordinates are expressed in tiles
<clay_1>
how about the following
<clay_1>
is there a script that takes a bitstream as an input and partitions it to frames without changing the format of the bitstream data ?
<clay_1>
I tried the bitread but it just counted me how many words i have without giving an output file
<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.py
<clay_1>
nice ! I will try to do that
<clay_1>
thank you !
perillamint has quit [Read error: Connection reset by peer]
perillamint has joined #symbiflow
<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 stdout
<clay_1>
Bitstream size: 3825897 bytesConfig size: 956434 words
<clay_1>
I also get the not found part thing so that should be why
<clay_1>
will try with a compatible bitstream again
celadon has joined #symbiflow
<sf-slack>
<tmichalak> exactly, you need to pass the part_file
<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.yaml
<clay_1>
hmm still got the same error, do i have to generate it from vivado 17.2 as well ? or version doesnt matter ?
<sf-slack>
<tmichalak> for the bitstream the vivado version doesn't matter
<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"
<clay_1>
so probably i should do that
<clay_1>
should I change the line in environment.sh to look like export XRAY_BITREAD="database/artix7/xc7a50tfgg484-1/part.yaml" ?
<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.
<clay_1>
so like that ? export XRAY_BITREAD="${XRAY_TOOLS_DIR}/bitread database/artix7/xc7a50tfgg484-1/part.yam"
<clay_1>
or export XRAY_BITREAD="${XRAY_TOOLS_DIR}/bitread --part_file ${database/artix7/xc7a50tfgg484-1/part.yam}"
<clay_1>
damn I suck :P
<clay_1>
ohhh i change nothing there but i change the export XRAY_PART_YAML= value, ritght ?
<sf-slack>
<acomodi> clay_1: you are targetting the xc7a50tfgg484-1 part now correct? I mean, the bitstream that is generated by Vivado
<clay_1>
actually no I was just repeating your example, i do /database/artix7/xc7a35tcpg236-1/part.yaml
<sf-slack>
<acomodi> Ok, so try to change the XRAY_PART in the /settings/artix7.sh to `xc7a35tcpg236-1` and than source it again
<clay_1>
I still get the not found :/
<sf-slack>
<acomodi> Can you please print the full error output?
<clay_1>
sure
<clay_1>
Bitstream size: 2192120 bytesConfig size: 547990 wordsPart file not found or invalid
<clay_1>
i made the change you asked me and removed all the changes I did to the environment file
<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 reading
<sf-slack>
<acomodi> To solve this you could generate the bitstream once again for the `xc7a35tcpg236-1` and try once again to read it.
<clay_1>
will do that
<clay_1>
regarding to that
<clay_1>
xc7a35tcpg236-1
<clay_1>
is 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 ?
<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 bitstream
<clay_1>
If I do the XRAY_PART in the /settings/artix7.sh to `xc7a35tcpg236-1` , this will happen automatically, right?
<sf-slack>
<acomodi> Should be ok
<sf-slack>
<acomodi> Yeah, but you need to source it again
<clay_1>
yes I do that
<clay_1>
I will try with a fresh bitstream now
<clay_1>
still the same
<clay_1>
so what i do pretty much is change the artix.sh file
<clay_1>
then I open terminal in prjxray
<clay_1>
source it
<clay_1>
cd tools
<clay_1>
and run the bitread
<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?
<clay_1>
yes it is there along with 3 json files and a csv file
<clay_1>
you mean like that
<clay_1>
prjxray$ XRAY_BITREAD 2.bit
<clay_1>
?
<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)
<clay_1>
prjxray$ $XRAY_BITREAD 1.bit > 2.framesCan't open input file '1.bit' for reading!
<clay_1>
same would happen with 2.bit file
<clay_1>
silly me, these bitstreams are in toold directory
<sf-slack>
<acomodi> Is the bitfile in the current directory where you are calling bitread?
<clay_1>
It works now!
<sf-slack>
<acomodi> Cool
<clay_1>
thank you !
<clay_1>
I tried the bit2fasm now
<clay_1>
without cd-ing and it worked
<clay_1>
do you know how can I output the results to a file though? and what extension it has to have ?
<sf-slack>
<acomodi> like that `$XRAY_BIT2FASM bitfile.bit > outfile.fasm` Extension is not important but fasm file should have the .fasm extension for clarity
<clay_1>
So the info from here should be that in the design there is a lut with a trut table of 60'b111100001111000011110000111111110000111100001111000011110000
<clay_1>
this lut is slice L
<clay_1>
A
<clay_1>
and in the slice X2Y11
<clay_1>
correct ?
<sf-slack>
<acomodi> In the CLBLL_L_X2Y11 actually
<sf-slack>
<acomodi> Which is formed by two SLICES, in this case you are using the bottom one
<clay_1>
and by bottom we mean the left right ?
<clay_1>
(when looking in vivado implemented design)
<sf-slack>
<acomodi> `CLBLL_L_X2Y12` has two SLICES within it: `SLICE_X0Y12` and `SLICE_X1Y12`
<sf-slack>
<acomodi> By bottom I intend the `SLICE_X0Y12`
<clay_1>
sweet :)
<clay_1>
my only issue here is possibly with the 60'b111100001111000011110000111111110000111100001111000011110000
<clay_1>
it should be partitioned into 4 words each of them in a different frame
<clay_1>
right ?
citypw has quit [Ping timeout: 258 seconds]
<OmniMancer>
why would the LUT init be split up?
<clay_1>
@omn
<clay_1>
OmniMancer Thats the way luts are represented on the bitstream
<clay_1>
I think I got my answer to that though
<clay_1>
it also looks by "60" that if it starts with 0s they are omitted
<clay_1>
since we expect all words to be 64 bits long
<OmniMancer>
Fasm represents the settings, not the details of where the bits happen to fall in the bitstream
<clay_1>
yes so its rather the logical output of the lut6 truthtable, right ?
<OmniMancer>
yes
<clay_1>
awesome ^^
<litghost>
clay_1: FYI, if you wanted to add xc7a100t-csg324 to the supported list, it isn't too hard. See
<clay_1>
i will find CLBLL_L_X2Y11 contents in the frames with offset 0x00400100 untill 0x00400136 ?
<clay_1>
the words 2 means that each entry in the frames will be 8 hexes long
<clay_1>
and the offset 22 means that the first 22 sets of 2 words in each of the frames are unused ?
<litghost>
bitread 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)
<litghost>
bit2fasm aligns those (frame, word, bit) with both tilegrid and the segbits to determine what FASM feature the underlying bit(s) represent
<clay_1>
Even if it doesnt use it, you can make associations with the two, right ?
<litghost>
clay_1: The reason I mention it is out of date is that IO tiles are not reflected correctly
<_whitenotifier-3>
[prjxray-bram-patch] nelsobe opened issue #1: Binary vs. Hex init.mem Files - https://git.io/JvVTR
<_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/JvVTg
<clay_1>
litghost 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 !
<_whitenotifier-3>
[prjxray-bram-patch] mithro opened issue #4: Please make sure all commits have signoff lines - https://git.io/JvVTS
adjtm_ has joined #symbiflow
adjtm has quit [Ping timeout: 256 seconds]
_whitelogger has joined #symbiflow
_whitelogger has quit [Ping timeout: 256 seconds]
_whitelogger has joined #symbiflow
clay_1 has quit [Ping timeout: 260 seconds]
benelson has joined #symbiflow
benelson has quit [Ping timeout: 256 seconds]
benelson has joined #symbiflow
<_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/JvVtX
<benelson>
Hi 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.
<_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/JvVtj
<_whitenotifier-3>
[prjxray-bram-patch] nelsobe opened issue #7: Add ability to patch memories in hierarchical designs - https://git.io/JvVqJ
ZipCPU_ is now known as ZipCPU
benelson has quit [Remote host closed the connection]
benelson has joined #symbiflow
benelson has quit [Remote host closed the connection]
benelson has joined #symbiflow
benelson has quit [Remote host closed the connection]
benelson has joined #symbiflow
benelson has quit [Remote host closed the connection]
benelson has joined #symbiflow
benelson has quit [Remote host closed the connection]
benelson has joined #symbiflow
benelson has quit [Ping timeout: 240 seconds]
benelson has joined #symbiflow
benelson has quit [Remote host closed the connection]
benelson has joined #symbiflow
benelson has quit [Remote host closed the connection]
HEGAZY has joined #symbiflow
benelson has joined #symbiflow
benelson has quit [Read error: Connection reset by peer]
benelson has joined #symbiflow
HEGAZY has quit [Remote host closed the connection]
benelson has quit [Remote host closed the connection]
HEGAZY has joined #symbiflow
benelson has joined #symbiflow
benelson has quit [Remote host closed the connection]
benelson has joined #symbiflow
benelson has quit [Remote host closed the connection]
benelson has joined #symbiflow
benelson has quit [Remote host closed the connection]
benelson has joined #symbiflow
benelson has quit [Remote host closed the connection]
benelson has joined #symbiflow
benelson has quit [Remote host closed the connection]
benelson has joined #symbiflow
benelson_ has joined #symbiflow
benelson has quit [Read error: Connection reset by peer]
brent has joined #symbiflow
benelson_ has quit [Remote host closed the connection]