<mithro> litghost: The python module for talking to the Make jobserver I was working on is here -> https://github.com/mithro/python-make-jobserver
<tpb> Title: GitHub - mithro/python-make-jobserver: Library for integrating Python applications with Makes jobserver. (at github.com)
<Bertl_oO> 'make env' fails with:
<Bertl_oO> Command "/fast/FPGA/PRJXRAY/prjxray.git/env/bin/python3 -c "import setuptools, tokenize;__file__='/tmp/pip-build-57v4z0_7/scipy/setup.py';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record /tmp/pip-j0vyaa6v-record/install-record.txt --single-version-externally-managed --compile --install-headers /fast/FPGA/PRJXRAY/prjxray.git/env/include/site/python3.5/scipy" failed with error code
<Bertl_oO> any suggestions how to make that work?
<litghost> I would start by pasting the error properly formatted into a pastebin or equiv
<litghost> Bertl_oO: https://github.com/numpy/numpy/issues/8697 , Google is your friend
<tpb> Title: import numpy error: undefined symbol: zgelsd_ · Issue #8697 · numpy/numpy · GitHub (at github.com)
<Bertl_oO> not sure what that should tell me though
<Bertl_oO> this is an error on the build in the virtenv, no?
<Bertl_oO> do I need to install special version of numpy? if so, which one?
<mithro> Bertl_oO: "The catch is that both atlas and lapack provide liblapack.so.3. I assume from the naming that lapack is the canonical one and the one in atlas is intended to be an optimized one or something. The two are incompatible at the moment which is where the problem arises."
<Bertl_oO> so get rid of atlas should help?
<Bertl_oO> *getting
<mithro> Bertl_oO: Dunno - but it seems like it is something to do with your system and atlas / lapack
<Bertl_oO> how do I rerun the 'make env' so that it tries again?
<Bertl_oO> i.e. how do I undo 'make env'?
<mithro> Bertl_oO: "rm -rf env" ?
<elms> Bertl_oO: are you on step 5 and taking option 1 I assume?
<elms> `make env -B` should work too
<tpb> Title: prjxray/Makefile at acf7aafce16a7f37e248e1403d8ef01b250116d0 · SymbiFlow/prjxray · GitHub (at github.com)
<Bertl_oO> elms: yep, step 5, option 1
proteusguy has joined #symbiflow
<Bertl_oO> for the record, removing atlas seems to have done the trick
<Bertl_oO> still a bunch of 'Errors' on the way but it seems to have finished now
<Bertl_oO> moving on to step 7, option 2
proteusguy has quit [Ping timeout: 245 seconds]
<tpb> Title: Support for shorthand to specify all pins on one edge · Issue #475 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com)
citypw has joined #symbiflow
proteusguy has joined #symbiflow
kprasadvnsi has joined #symbiflow
kprasadvnsi has left #symbiflow [#symbiflow]
proteusguy has quit [Ping timeout: 245 seconds]
Bertl_oO is now known as Bertl_zZ
ritikchanna has joined #symbiflow
ritikchanna has quit [Client Quit]
proteusguy has joined #symbiflow
OmniMancer has joined #symbiflow
OmniMancer has quit [Quit: Leaving.]
OmniMancer has joined #symbiflow
proteusguy has quit [Ping timeout: 240 seconds]
OmniMancer has quit [Read error: Connection reset by peer]
OmniMancer has joined #symbiflow
proteusguy has joined #symbiflow
OmniMancer has quit [Ping timeout: 245 seconds]
OmniMancer has joined #symbiflow
citypw has quit [Ping timeout: 244 seconds]
duck2 has quit [Ping timeout: 256 seconds]
_whitelogger has joined #symbiflow
proteusguy has quit [Remote host closed the connection]
proteusguy has joined #symbiflow
proteusguy has quit [Remote host closed the connection]
Bertl_zZ is now known as Bertl
OmniMancer has quit [Quit: Leaving.]
<Bertl> hmm ... the xc7z020clg400 database build is still ongoing ... but I'm curious, how can I use the database (once it finishes) to figure out the frame address/location/mask from a given tile?
<Bertl> s/from/for/
<sf-slack> <kgugala> hi Bertl
<sf-slack> <kgugala> you can check the tilegrid.json file within the db
<Bertl> yeah, I'm looking at that right now
<Bertl> but it only contains grid coordinates?
<Bertl> (looking at the xc7z010clg400-1 for now)
<sf-slack> <kgugala> you can find there baseaddreses
<sf-slack> <kgugala> in bits sections
<sf-slack> <kgugala> (not every tile has it filled)
<Bertl> ah, I see, didn't scroll down far enough
<sf-slack> <kgugala> :slightly_smiling_face:
<Bertl> so, for example, CLBLL_L_X16Y93 has an entry in the bits section
<Bertl> it says CLB_IO_CLK (what does that mean?)
<Bertl> and it reports two SLICEL sites (which looks like what I'm looking for)
duck2 has joined #symbiflow
<Bertl> what does the 'frames: 36' mean?
<kgugala> how many frames there are in the bitstream for this type of column
<kgugala> you may want to check fuzzer 005-tilegrid
<kgugala> the json is generated by this fuzzer
<Bertl> hmm, so what does 'offset: 40' in a context of 36 frames mean?
<Bertl> the offset in a frame or the offset to the given baseaddress?
<tpb> Title: Introduction Project X-Ray documentation (at prjxray.readthedocs.io)
<Bertl> I guess the documentation is not up-to-date, but thanks for the link
<sf-slack> <kgugala> yeah, it needs an update
<Bertl> so most likely the 'offset' is the inter-frame offset originally in the same tuple as the baseaddr
<sf-slack> <kgugala> but the json format descritption should be OK
<Bertl> so this is what I see in the database: https://pastebin.com/raw/ry8RdQV6
<Bertl> I presume the '99' from the docs corresponds to the 38 in the paste
<sf-slack> <kgugala> yep
<Bertl> so I would find the SLICE_X40Y19 and SLICE_X41Y19 config data at frame 0x00401A00, offset 38 and 39
<Bertl> now how do the 36 frames factor into this?
<Bertl> ah, the database build for the xc7z020clg400-1 just failed :(
<sf-slack> <kgugala> on what?
<sf-slack> <kgugala> on which fuzzer?
<sf-slack> <kgugala> can you paste the log?
<Bertl> is there a complete log generated somewhere?
<kgugala> yes
<kgugala> each fuzzer should have `log` folder
<kgugala> inside you can find the full log
<Bertl> there are quite a number of files there, how to narrow it down to the relevant one(s)?
<kgugala> grep for erorrs?
<kgugala> *errors
<kgugala> in stdout files you have all the output
<tpb> Title: Index of /Stuff/PRJXRAY/logs/ (at vserver.13thfloor.at)
<Bertl> any idea what the problem could be?
<sf-slack> <acomodi> What version of vivado are you using?
refpga has joined #symbiflow
<Bertl> the suggested 2017.2
<sf-slack> <acomodi> Ok, could you zip all the logs?
<Bertl> of this particular fuzzer or of all fuzzers?
<sf-slack> <acomodi> For now the 005 will be fine
<sf-slack> <acomodi> https://pastebin.com/mvEM2aP6
<tpb> Title: 0_sponge_log.xml:3820:OSError: [Errno 28] No space left on device 0_sponge_log. - Pastebin.com (at pastebin.com)
<sf-slack> <acomodi> found this, could it be that your system run out of space?
<Bertl> that was yesterday
<Bertl> made more space on the partition and ran make again
<sf-slack> <kgugala> so Bertl, can you provide the recent logs?
<Bertl> the zip contains all logs in the folder (as does the link)
<tpb> Title: Index of /Stuff/PRJXRAY/ (at vserver.13thfloor.at)
<Bertl> # zip 005-tilegrid-logs.zip 005-tilegrid/logs
<sf-slack> <kgugala> can you filter them to contain only the most recent ones?
<sf-slack> <kgugala> the out of space error was in the logs
<Bertl> click on 'Last Modified' and they will be sorted according to the date
<sf-slack> <kgugala> you have a bunch of critical warnings in the logs
<sf-slack> <kgugala> I see you run it for 7020
<Bertl> yup
<sf-slack> <kgugala> as @litghost said yestarday - the soft was not tested on this chip
citypw has joined #symbiflow
<sf-slack> <kgugala> there is a bunch of critical warnings like:
<sf-slack> <kgugala> Cannot loc instance 'idelay_IDELAY_X0Y2' at site IDELAY_X0Y2, Site IOB_X0Y2 is not bonded. Place terminal di[15] and connected instances in a site with a PAD
<Bertl> so how to get the database for 7020? what needs to be modified?
<sf-slack> <kgugala> also in `stdout.2019-03-05T12:38:38.534252.log` at line 8833 Vivado fails
<sf-slack> <kgugala> to get the database you have to set the part as you did and run fuzzers
<Bertl> note: I'm only interested in the frame addresses for tiles, specifically slices
<sf-slack> <kgugala> since they were not tested on 7020 they may fail
<sf-slack> <kgugala> as they did
<Bertl> how to fix them?
<sf-slack> <kgugala> you'd need to dive a little into the fuzzer code and check what exactly is happening there
<sf-slack> <kgugala> I assume that tailoring the settings in settings.sh file for Zynq will be required to get the 7020 to work
<Bertl> so it's a problem with the XRAY_ROI_* settings?
citypw has quit [Ping timeout: 245 seconds]
<litghost> Bertl: Tile grid ignored ROI to map all the base addresses. If you only care about slices, you can disable the IOB and IOB_INT tile fuzzers and file an issue.
<litghost> Bertl: IDELAY's are only used by tilegrid when trying get addresses for IOB tiles and IOB INT tiles
<Bertl> how do I do that?
<litghost> Bertl: Comment it out from the 005 makefile depedencies
<tpb> Title: prjxray/Makefile at master · SymbiFlow/prjxray · GitHub (at github.com)
<Bertl> okay, then just run make again?
<litghost> Bertl: Just run make in the 005 directory
<litghost> Otherwise it will restart the fuzzer, which will take significantly longer
<litghost> For info on how the tilegrid and segbits are related, https://github.com/SymbiFlow/prjxray/blob/master/prjxray/tile_segbits.py
<tpb> Title: prjxray/tile_segbits.py at master · SymbiFlow/prjxray · GitHub (at github.com)
<litghost> Bertl: What are you interested in doing?
<Bertl> I'm interested in mapping specific (marked) slices to frame addresses so that they can be modified at runtime
<litghost> Bertl: Sure, then tilegrid and the CLB segbits are what you want
<litghost> Bertl: You will also likely want INT segbits, but the CLB and INT segbits appear to be common across all 7-series parts
<litghost> Bertl: Only tilegrid.json and tileconn.json are expected to be part specific
<sf-slack> <kgugala> @Bertl you may also want to take a look on the xc7patch tool (in the tools folder)
<Bertl> litghost: okay, tx
<Bertl> kgugala: what does it do?
<sf-slack> <kgugala> it can patch the bitstream in the selected region with a data from another bitstream
<Bertl> ah, got it, tx
<litghost> The circle flow is bit2fasm.py, fasm2frames.py and then xc7patch
<sf-slack> <kgugala> you, after some modifications it can be helpful in your case
<sf-slack> <kgugala> s/you/so
<Bertl> yeah, might come handy for testing ...
<Bertl> litghost: make failed with https://pastebin.com/raw/rM00W5mt
<sf-slack> <kgugala> this is easy to fix
<sf-slack> <kgugala> just change the assert condition
<sf-slack> <kgugala> if you look at the code it will alway if the part is not 7010
<Bertl> assert os.getenv('XRAY_PART') in ("xc7z010clg400-1", "xc7z020clg400-1") ?
<litghost> Yes, that's good
<Bertl> I read in the docs that BRAM frame to memory is not currently understood ... is that still correct?
<litghost> bertl: Incorrect. We believe to have all BRAM bits understood
<litghost> bertl: If you are interested in creating a BRAM patching tool, we have an outstanding issue to do just that!
<Bertl> okay, because the assignment didn't seem that unusual/unexpected last time I checked
<tpb> Title: Create tool to patch blockram (BRAM) contents in bitstream · Issue #181 · SymbiFlow/prjxray · GitHub (at github.com)
<litghost> assignment?
<litghost> Sorry, I don't parse that
<Bertl> frame address to memory locations
<Bertl> the correlation I mean
<litghost> 005 will output BRAM base addresses for BRAM configuration and BRAM data. We have used the both to create designs that use BRAM's outside of vivado, so I have pretty good confidence that it is work
<Bertl> excellent, any documentation available on this?
<Bertl> most recent error: https://pastebin.com/raw/BzXyWEnK
<litghost> The most straight forward way to deal with BRAM data is via FASM directives and fasm2frames.py
<litghost> That error is very weird
<Bertl> well, there is no INT_L_X0Y50 in build/basicdb/tilegrid.json
<litghost> Ya, but then how did dsp_int output that!!! dsp_int uses basicdb as well
<litghost> Run "make clean" in the dsp_int folder and try again
<litghost> Any chance you ran 005 with another part at some point
<Bertl> not that I can remember
<litghost> odd
<Bertl> rerunning now (after clean)
<litghost> k
<Bertl> so, back to the BRAM ... the idea is to generate FASM input and then use fasm2frames.py and xc7patch to make the changes?
<litghost> Ya.
<litghost> Most of the work is actually mapping pre-synthesis addresses to tiles, which is an open question.
<litghost> So if the BRAM is simple, e.g. one tile, then it is easy
<Bertl> is there some FASM documentation available?
<tpb> Title: fasm/specification.rst at master · SymbiFlow/fasm · GitHub (at github.com)
<Bertl> tx
<litghost> FASM itself is a language for writing out features
<Bertl> so for a BRAM tile, there would be a single line specifying the tile and the assigned data, yes?
<Bertl> (a rather long line probably :)
<litghost> In the BRAM case, something like:
<litghost> BRAM_L_X6Y125.RAMB18_Y1.INIT_2E[255:0]=256'b0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
<litghost> You can split it up as needed
<Bertl> ah, so have a bunch of 'sub' ranges
<litghost> so [63:0], [127:64], etc etc
<Bertl> yeah, got it
<litghost> Even that line is a 256 subrange
<litghost> We are currently using the INIT_xx syntax from the RAMB18E1
<Bertl> okay, does the data need to be binary?
<litghost> bertl: Not sure I understand your question. FASM supports an verilog integer constant
<Bertl> ah, no, I see, 'h should be fine as well
<litghost> any*
<Bertl> so and the data generated by fasm2frames.py is what format?
<litghost> fasm2frames.py is a frame words CSV, first column is frame address, followed by 101 32-bit words
<litghost> xc7patch can read frame words CSV
<Bertl> okay, makes sense
<Bertl> well, clean and make did result in the very same error
<Bertl> KeyError: 'INT_L_X0Y50
<Bertl> Makefile:108: recipe for target 'build/tilegrid_tdb.json' failed
<Bertl> anything I should upload?
<litghost> File an issue with replication instructions.
<mithro> kgugala: The image on https://symbiflow.github.io/ for GSoC is broken
<tpb> Title: SymbiFlow - the GCC of FPGAs (at symbiflow.github.io)
<Bertl> litghost: hmm, I started from scratch and just focused on the 005-tilegrid
<Bertl> for some reason, vivado seems to be using the xc7a50t-fgg484 as part despite of the source settings/artix7.sh
<litghost> ah, that would totally cause a problem
<Bertl> ah, sorry, I might have messed up
<Bertl> let me recheck
ritikchanna has joined #symbiflow
ritikchanna has quit [Quit: Page closed]
<Bertl> okay, I messed up before but now the process is like this:
<Bertl> it seems that the xc7z020clg400-1.yaml is missing, how do I generate that without running all the 8+ hours of fuzzer builds?
<litghost> run 001
<Bertl> k, tx
refpga` has joined #symbiflow
refpga has quit [Ping timeout: 240 seconds]
<Bertl> hmm, didn't really help as it seems ... 005 still complains after running make in 001
<Bertl> maybe make pushdb ?
<litghost> ya
<litghost> When running a fuzzer, you can do "make -j<N> run" and it will do the pushdb for you
<Bertl> ah, okay
refpga` has quit [Remote host closed the connection]
<litghost> word of warning, "make run" does perform a "make clean", so partial results will be removed
<litghost> which may or may not be what you want
<Bertl> yeah, just saw it in the makefile
<sf-slack> <mgielda> @mithro we know, we are in the process of fixing it
anuejn has joined #symbiflow
<tpb> Title: Add missing GSoC logo by kgugala · Pull Request #25 · SymbiFlow/symbiflow-website · GitHub (at github.com)
<tpb> Title: 005-tilegrid fails for Zynq 7020 · Issue #697 · SymbiFlow/prjxray · GitHub (at github.com)
<Bertl> btw, it seems the INT_L_X0Y50 is related to the fake ps7 entry
<litghost> Ya
<litghost> You could try removing the ps7_int fuzzer too
<Bertl> could it be that just the location changed between 7010 and 7020?
<litghost> Comment out the dependency, same as iob
<litghost> Likely
<Bertl> because otherwise I think the ps7 is identical between 7010 and 7020
<litghost> the ps7_int fuzzer likely needs to use the basicdb grid rather than hard coding a tile
<litghost> Anyways, if you don't need INT base addresses near the PS7 block, you don't need to fix this
<Bertl> okay, so sed -i '/TILEGRID.*ps7/ s/^/#/' Makefile
<Bertl> but I do not think that changes much
<Bertl> I'll just remove the entry from ../005-tilegrid/ps7_int/build/segbits_tilegrid.tdb for now
<Bertl> which brings me to the next error:
<Bertl> AssertionError: BRKH_INT_PSS
<litghost> That isn't enough information
<litghost> You can likely add BRKH_INT_PSS to the assertion list. That assertion is sanity checking the structure of the INT columns
<litghost> If you want to be sure, open up Vivado and see that there are no INT tiles "beyond" BRKH_INT_PSS
<tpb> Title: prjxray/generate_full.py at master · SymbiFlow/prjxray · GitHub (at github.com)
<Bertl> well, adding BRKH_INT_PSS to the assertion list results in a new KeyError
<litghost> That's a side affect of removing the IOB fuzzer
<Bertl> any suggestion how to work around that?
<litghost> Remove the call to propagate_IOB_SING
<Bertl> great! that worked
<Bertl> thanks for the help so far!
<Bertl> so I have the tilegrid database now ... do I just take the segbit stuff from 7010?
<litghost> You can, it should work. As far as we can tell, all the 7-series segbits are the same
<Bertl> okay, anything else I need to build for the tools?
<Bertl> (i.e. fasm2frames.py and xc7patch)
<litghost> xc7patch is build via CMake
<litghost> fasm2frames.py just needs a database and the prjxray python lib
<litghost> bit2fasm.py needs a database and the tools built
<Bertl> looks like I'm getting there :)
<Bertl> what is the syntax of the segbits_* files?
<tpb> Title: prjxray/tile_segbits.py at master · SymbiFlow/prjxray · GitHub (at github.com)
<Bertl> hmm, okay ... so what does 30_00 !30_01 30_02 !30_03 mean?
<elms> Bertl: That's the bits to set and clear. So set bit 30_00 and 30_02 and clear 30_01 and 30_03 The tuple is a coordinate of a specific bit for that tile.
<Bertl> okay, how does that map to the frame location?
<Bertl> let's say I have SLICE_X28Y68 in tile CLBLL_L_X20Y68
<Bertl> I know the base address is 0x00400A00 and the offset is 36
<Bertl> the slice(s) cover two words there (accroding to the database)
<Bertl> now the segbits_clbll_l.db tells me that
<Bertl> CLBLL_L.SLICEL_X0.AFFMUX.AX !30_00 30_01 !30_02 !30_03
<Bertl> or let's make it simpler, for INIT[00] it tells me:
<Bertl> CLBLL_L.SLICEL_X0.ALUT.INIT[00] 32_15
<Bertl> which means the 'bit' at coordinate (32,15)?
<elms> That's my understanding, but I'm not familiar with the details of mapping with address and offset.
<Bertl> okay, tx
tpb has quit [Remote host closed the connection]
tpb has joined #symbiflow
Bertl is now known as Bertl_zZ