06:18 <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 there

10:22 <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:24 <sf-slack> <pgielda> [those runners are, as you error suggest matvhe against a label "self-hosted"]

10:24 <sf-slack> <pgielda> *match

10:25 <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 fine

10:26 <sf-slack> <pgielda> And judging from the https://github.com/SymbiFlow/symbiflow-examples/pull/121 everything worked fine.

12:58 <_whitenotifier> [yosys-symbiflow-plugins] ajelinski opened issue #74: macOS: There's no `-D` switch in BSD `install` - https://git.io/JtcRv

16:02 <lambda> litghost: https://github.com/SymbiFlow/symbiflow-examples/issues/120, FYI

16:26 <litghost> I saw that, thanks!

16:27 <Lofty> kgugala: I just fixed a segfault in scc; you'll probably want to pull the quicklogic-sta branch again

16:28 <sf-slack> <kgugala> awesome

16:29 <sf-slack> <kgugala> thanks

16:29 <Lofty> I found it while looking at the bram testcase, actually

16:35 <Lofty> Definitely need to think of more things to do though

16:42 <LoneTech> well, 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:52 <litghost> prjuray-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 <litghost> In theory it supports all 4, but I only have confidence that it has been tested on 7/US/US+

16:53 <litghost> https://github.com/SymbiFlow/prjuray-tools

17:09 <LoneTech> thanks

17:17 <LoneTech> looks very similar. still went uint32_t, added xcu and xcup series folders.

17:20 <litghost> https://github.com/SymbiFlow/prjuray-tools/blob/cb5201be2c7078375cc3c069256ce05f9467fded/lib/include/prjxray/xilinx/architectures.h#L47-L49 ?

17:21 <litghost> I don't believe so?

17:21 <LoneTech> ah. found Architecture WordType. this has been started

17:21 <LoneTech> I'm slowly getting oriented, bound to misunderstand things to degrees

17:24 <LoneTech> so it translates to/from 32 bit internally through BigEndianSpan and out_bitstream_writer

17:34 <LoneTech> so what bitread is doing is trying to read past end of file through absl::span and not catching the out of range exception

17:35 <litghost> Sounds like a bug!

17:36 <LoneTech> definitely

17:36 <LoneTech> but what's the c++ way to fix it? as a poor Python programmer, I'm used to iterators that know when they end.

17:37 <litghost> Is bitread using an mmap?

17:37 <litghost> When the mmap was created, it used stat to determine the file length

17:38 <LoneTech> it reports the file length before failing

17:38 <litghost> Feel free to file an issue with a replicating test case. That makes it easier to answer questions

17:43 <LoneTech> got it. big_endian_span::end is wrong

17:44 <LoneTech> trying to fix

17:50 <LoneTech> ... if indeed it's failing in the place I think :/

17:50 <LoneTech> why doesn't even a debug build in a debugger give a halfway usable backtrace?

17:52 <litghost> Is it actually a debug build?

17:53 <litghost> If you run "file <exe>" does it report that debug symbols are present?

17:56 <LoneTech> looks like not quite. it's unstripped, not debug symbols. gonna want to resolve that

17:58 <LoneTech> huh. CMakeCache apparently overrode cmake command line for build type

17:58 <LoneTech> better, pie with debug_info

18:00 <litghost> Ya, whenever you don't get debugging symbols, use "file <x>" to ensure that debugging symbols are actually there

18:00 <litghost> Because some builds like to strip out stuff, even in debug modes

18:00 <LoneTech> much better

18:00 <litghost> Yay

18:08 <LoneTech> well this was silly. had to pass -architecture Spartan6

18:09 <LoneTech> now to build that part file it wants

18:16 <litghost> Ya, that is true

18:35 <nickoe> litghost: what do you think about https://github.com/SymbiFlow/symbiflow-arch-defs/pull/1972 ? Does it need more work?

18:35 <nickoe> or are we still giving kgugala a change to re-review?

18:36 <nickoe> ugh :D it seems you just merged it just now, 33 seconds ago

18:37 <sf-slack> <kgugala> :)

18:43 <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:44 <sf-slack> <kgugala> it's GitHub who tries to start the run

18:44 <sf-slack> <kgugala> and it does not provide an option to not start it if there is no runner available

18:46 <sf-slack> <timo.callahan> Interesting. At least they fail immediately and don't waste resources.

18:54 <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:56 <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...

22:23 <nickoe> How can "symbiflow" be used in nmigen? I mean for an xilinx board use the fasm stuff insted of vivado?

22:33 <litghost> Good question for kgugala. I believe that type of work has been started

22:36 <nickoe> I 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/c0807d845d2d3be3ae7c09ebc9cad80a12fdcbfb

22:36 <nickoe> litghost: ^

22:40 <tcal> Good 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 .

23:00 <nickoe> tcal: mm, thanks, but I am not sure how I can do that with the "python3 -m nmigen_boards.basys3" teset

23:13 <nickoe> tcal: I guess this is what is meant? https://dpaste.com/8NSZJWXCK

23:14 <tpb> Title: dpaste: 8NSZJWXCK (at dpaste.com)

23:16 <nickoe> I am not sure what path it needs

23:21 <nickoe> mmm, I made the vivado bitstream generation happy

23:21 <nickoe> mmm

23:24 <nickoe> and it blinks

23:52 <nickoe> Ahh, 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:54 <litghost> I think we want back and added the symbiflow_ prefix to avoid name collision

23:54 <litghost> And didn't update nmigen

23:55 <litghost> We should add a directly nmigen example to symbiflow examples to catch that type of error