Tuesday, 2021-01-26

*** tpb has joined #symbiflow00:00
*** citypw_ has joined #symbiflow01:24
*** maartenBE has quit IRC01:29
*** maartenBE has joined #symbiflow01:35
*** ym_ has quit IRC02:12
*** ym has joined #symbiflow02:12
*** Degi_ has joined #symbiflow03:46
*** Degi has quit IRC03:48
*** Degi_ is now known as Degi03:48
*** _whitelogger has quit IRC06:12
*** _whitelogger has joined #symbiflow06:14
sf-slack<kgugala> tcal: you need to have custom runners registered for the repo - those are registered for Symbiflow repo. To make it work in your fork you'd need to add a custom runner there06:18
*** kraiskil has joined #symbiflow07:51
*** kraiskil has quit IRC08:06
*** hansfbaier has joined #symbiflow08:15
*** kraiskil has joined #symbiflow09:56
*** kraiskil has quit IRC10:02
*** kraiskil has joined #symbiflow10:08
sf-slack<pgielda> @tcal custom runners are used because some of the jobs require more resources (like disk space or RAM) than normal GA runners provide.10:22
sf-slack<pgielda> But @kgugala is right that they are only provided in the Symbiflow organization on github (more precisely, just in symbiflow-examples repo)10:22
sf-slack<pgielda> [those runners are, as you error suggest matvhe against a label "self-hosted"]10:24
sf-slack<pgielda> *match10:24
sf-slack<pgielda> If you open a PR to Symbiflow/symbiflow-examples, then your fork will be run in the Symbiflow org context and the runners should work fine10:25
sf-slack<pgielda> And judging from the https://github.com/SymbiFlow/symbiflow-examples/pull/121 everything worked fine.10:26
*** kraiskil has quit IRC10:43
*** kraiskil has joined #symbiflow10:45
*** hansfbaier has quit IRC10:46
*** hansfbaier has joined #symbiflow10:48
*** kraiskil has quit IRC10:53
*** kraiskil has joined #symbiflow11:13
*** hansfbaier has quit IRC11:13
*** promach3 has quit IRC11:19
*** xobs has quit IRC11:19
*** unrznbl[m] has quit IRC11:19
*** abeljj[m] has quit IRC11:19
*** Niklas[m]1 has quit IRC11:20
*** maartenBE has quit IRC11:21
*** lopsided98 has quit IRC11:24
*** maartenBE has joined #symbiflow11:24
*** lopsided98 has joined #symbiflow11:26
*** promach3 has joined #symbiflow11:31
*** tpb has joined #symbiflow11:40
*** xobs has joined #symbiflow11:55
*** abeljj[m] has joined #symbiflow11:55
*** unrznbl[m] has joined #symbiflow11:55
*** Niklas[m]1 has joined #symbiflow11:55
*** lopsided98 has quit IRC12:07
*** lopsided98 has joined #symbiflow12:10
-_whitenotifier- [yosys-symbiflow-plugins] ajelinski opened issue #74: macOS: There's no `-D` switch in BSD `install` - https://git.io/JtcRv12:58
*** kraiskil has quit IRC13:01
*** bjorkint0sh has quit IRC15:07
*** citypw_ has quit IRC15:10
lambdalitghost: https://github.com/SymbiFlow/symbiflow-examples/issues/120, FYI16:02
litghostI saw that, thanks!16:26
Loftykgugala: I just fixed a segfault in scc; you'll probably want to pull the quicklogic-sta branch again16:27
sf-slack<kgugala> awesome16:28
sf-slack<kgugala> thanks16:29
LoftyI found it while looking at the bram testcase, actually16:29
*** mkru has joined #symbiflow16:30
LoftyDefinitely need to think of more things to do though16:35
LoneTechwell, seems I may have found my first stumbling block for adding Spartan 6 to project x-ray. Not a very worrying one, really. prjxray assumes 32-bit words in the bitstream, but spartan6 uses 16-bit. in addition, they're byte aligned in the file.16:42
litghostprjuray-tools might be a better starting place, as it was an attempt to generalize the 7-series tools for 6/7/US/US+16:52
litghostIn theory it supports all 4, but I only have confidence that it has been tested on 7/US/US+16:52
litghosthttps://github.com/SymbiFlow/prjuray-tools16:53
LoneTechthanks17:09
*** dnltz has joined #symbiflow17:14
LoneTechlooks very similar. still went uint32_t, added xcu and xcup series folders.17:17
*** gvb has joined #symbiflow17:20
litghosthttps://github.com/SymbiFlow/prjuray-tools/blob/cb5201be2c7078375cc3c069256ce05f9467fded/lib/include/prjxray/xilinx/architectures.h#L47-L49 ?17:20
litghostI don't believe so?17:20
LoneTechah. found Architecture WordType. this has been started17:21
LoneTechI'm slowly getting oriented, bound to misunderstand things to degrees17:21
*** gvb has quit IRC17:22
LoneTechso it translates to/from 32 bit internally through BigEndianSpan and out_bitstream_writer17:24
*** kgugala has quit IRC17:25
*** mkru has quit IRC17:28
LoneTechso what bitread is doing is trying to read past end of file through absl::span and not catching the out of range exception17:34
litghostSounds like a bug!17:35
LoneTechdefinitely17:36
LoneTechbut what's the c++ way to fix it? as a poor Python programmer, I'm used to iterators that know when they end.17:36
litghostIs bitread using an mmap?17:37
litghostWhen the mmap was created, it used stat to determine the file length17:37
LoneTechit reports the file length before failing17:38
litghostFeel free to file an issue with a replicating test case.  That makes it easier to answer questions17:38
LoneTechgot it. big_endian_span::end is wrong17:43
LoneTechtrying to fix17:44
LoneTech... if indeed it's failing in the place I think :/17:50
LoneTechwhy doesn't even a debug build in a debugger give a halfway usable backtrace?17:50
*** gvb has joined #symbiflow17:52
litghostIs it actually a debug build?17:52
litghostIf you run "file <exe>" does it report that debug symbols are present?17:53
*** gvb has quit IRC17:54
LoneTechlooks like not quite. it's unstripped, not debug symbols. gonna want to resolve that17:56
LoneTechhuh. CMakeCache apparently overrode cmake command line for build type17:58
LoneTechbetter, pie with debug_info17:58
litghostYa, whenever you don't get debugging symbols, use "file <x>" to ensure that debugging symbols are actually there18:00
litghostBecause some builds like to strip out stuff, even in debug modes18:00
LoneTechmuch better18:00
litghostYay18:00
LoneTechwell this was silly. had to pass -architecture Spartan618:08
LoneTechnow to build that part file it wants18:09
litghostYa, that is true18:16
*** gromero__ is now known as gromero18:20
*** kraiskil has joined #symbiflow18:30
nickoelitghost: what do you think about https://github.com/SymbiFlow/symbiflow-arch-defs/pull/1972 ? Does it need more work?18:35
nickoeor are we still giving kgugala a change to re-review?18:35
nickoeugh :D it seems you just merged it just now, 33 seconds ago18:36
sf-slack<kgugala> :)18:37
*** kgugala has joined #symbiflow18:38
sf-slack<timo.callahan> @kgugala @pgielda thanks for the info about runners.   I'll ignore the errors.   Would it be easy to suppress the run when the runners aren't available?18:43
*** dkozel has quit IRC18:43
sf-slack<kgugala> it's GitHub who tries to start the run18:44
sf-slack<kgugala> and it does not provide an option to not start it if there is no runner available18:44
sf-slack<timo.callahan> Interesting.    At least they fail immediately and don't waste resources.18:46
sf-slack<pgielda> its just that on your account (github.com/tcal-x) you are your own org ("tcal-x") and on your org there are no runners that match the set of tags ("self-hosted", "Linux", "X64")18:54
sf-slack<pgielda> github is not smart to figure out that maybe you forked but did not want to run things on your own org. I think in fact that its not smart that GitHub autoenables CIs on forks. but well...18:56
*** kraiskil has quit IRC19:02
*** kraiskil_ has joined #symbiflow19:02
*** davidlattimore has quit IRC20:13
*** davidlattimore has joined #symbiflow20:14
*** jopdorp_ has quit IRC20:15
*** jopdorp_ has joined #symbiflow20:18
*** kraiskil_ has quit IRC20:19
*** kraiskil_ has joined #symbiflow20:32
*** kraiskil_ has quit IRC21:57
nickoeHow can "symbiflow" be used in nmigen? I mean for an xilinx board use the fasm stuff insted of vivado?22:23
litghostGood question for kgugala.  I believe that type of work has been started22:33
nickoeI tried to add the basys3 board to it but it fails to build, probably caused by some issye with the board definition, but it would be nice if I could easily add support for FOSS synth or whatever you call it, see https://github.com/nickoe/nmigen-boards/commit/c0807d845d2d3be3ae7c09ebc9cad80a12fdcbfb22:36
nickoelitghost: ^22:36
tcalGood question I agree.   I was going to say "Just dump Verilog out of nMigen, then feed that into Symbiflow (see SymbiFlow Examples)".   But then I remembered that yosys  can maybe read nMigen directly(?).   And I kind of remember nmigen scripts having a --toolchain option.  So I don't have any real answers and would like to know.   Google turns up this: https://github.com/nmigen/nmigen/pull/463 .22:40
nickoetcal: mm, thanks, but I am not sure how I can do that with the "python3 -m nmigen_boards.basys3" teset23:00
nickoetcal: I guess this is what is meant? https://dpaste.com/8NSZJWXCK23:13
tpbTitle: dpaste: 8NSZJWXCK (at dpaste.com)23:14
nickoeI am not sure what path it needs23:16
nickoemmm, I made the vivado bitstream generation happy23:21
nickoemmm23:21
nickoeand it blinks23:24
nickoeAhh, I guess it wants https://github.com/nmigen/nmigen/blob/b466b724fe9f62140062afc9ecde9a920a261487/nmigen/vendor/xilinx_7series.py#L185-L192 but with the symbiflow-examples setuup the binaries are prefixed with symbiflow_ so they are not accepted in this case. :/23:52
litghostI think we want back and added the symbiflow_ prefix to avoid name collision23:54
litghostAnd didn't update nmigen23:54
litghostWe should add a directly nmigen example to symbiflow examples to catch that type of error23:55

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