| *** tpb has joined #yosys | 00:00 | |
| mwk | whitequark: I suppose the fine cells are out-of-scope for cxxrtl, right? | 00:10 |
|---|---|---|
| *** AdamHorden has quit IRC | 00:42 | |
| *** AdamHord- has joined #yosys | 00:42 | |
| *** AdamHorden has joined #yosys | 01:07 | |
| *** AdamHord- has quit IRC | 01:08 | |
| *** Degi has quit IRC | 02:05 | |
| *** Degi_ has joined #yosys | 02:05 | |
| *** Degi_ is now known as Degi | 02:06 | |
| *** AdamHorden has left #yosys | 02:09 | |
| *** AdamHorden has joined #yosys | 02:24 | |
| *** kraiskil has joined #yosys | 03:18 | |
| *** citypw has joined #yosys | 03:57 | |
| *** kraiskil has quit IRC | 04:05 | |
| whitequark | mwk: they're not explicitly out of scope | 04:36 |
| whitequark | i just don't see why would anyone use them | 04:36 |
| whitequark | we can add them if there's an actual use | 04:36 |
| mwk | fair enough | 04:36 |
| *** emeb has quit IRC | 04:45 | |
| anticw | so i got some ice1k 16-wlcsp parts as part of another order because i was curious | 04:45 |
| anticw | part of me things i should put them on a board | 04:45 |
| anticw | 0.35mm ball spacing, 4x4 so a cheap pcb would work even | 04:46 |
| anticw | but i'm also thinking that actually reflowing them at home will suck | 04:46 |
| anticw | so maybe i don't | 04:46 |
| whitequark | mwk: have you updated the manual yet? | 05:39 |
| *** emeb_mac has quit IRC | 06:00 | |
| whitequark | daveshah: tnt: poke | 06:04 |
| daveshah | hi! | 06:04 |
| whitequark | #457 is green now, do you think it's mergeable? | 06:07 |
| daveshah | Done! | 06:09 |
| daveshah | Thanks | 06:09 |
| whitequark | excellent | 06:11 |
| whitequark | so the next thing on my list is refactoring chipdb related code | 06:11 |
| whitequark | it's doing a lot of things and in a somewhat confused way currently | 06:11 |
| daveshah | mmm | 06:11 |
| whitequark | i'm going to try and lay out what i think are its goals to make sure that matches reality | 06:11 |
| daveshah | Yes, pinging mmicko too as he worked on some of the chipdb stuff | 06:12 |
| *** awordnot has quit IRC | 06:12 | |
| whitequark | the overall chipdb pipeline is something like: (external data) --python--> bba files --bbasm--> cc files --cc--> machine code | 06:16 |
| whitequark | or, with USE_C_EMBED, it becomes: (external data) --python--> bba files --bbasm e--> embed files --cc(+cc files)--> machine code | 06:17 |
| whitequark | or, with external chipdb, it becomes: (external data) --python--> bba files --bbasm e--> loadable file | 06:18 |
| whitequark | there's a lot of combinatorial complexity and i'm trying to understand what's actually important | 06:20 |
| * Lofty is paying attention to this in regards to Cyclone V chipdbs | 06:21 | |
| whitequark | it looks like people want both to be able to supply pregenerated bba files (to speed up builds), and pregenerated embeddable chipdb files (on msvc, to speed up linking, and so on) | 06:22 |
| whitequark | this interacts in interesting ways with cross-compilation. bba files themselves are arch-independent, and in fact must be generated with host tools, especially for libtrellis | 06:23 |
| whitequark | but the output of bbasm is always arch-dependent because of endianness | 06:23 |
| Sarayan | Hi people, what are bba files? | 06:24 |
| whitequark | you know flatbuffers or capnproto? | 06:26 |
| Sarayan | nope | 06:27 |
| whitequark | okay | 06:28 |
| whitequark | you know serialization formats in general? you have a structure in a file, you have some function that reads it? structure can have eg integers but also pointers to other structures | 06:28 |
| whitequark | if you try to make deserialization cheaper, eventually you arrive at a design where you cast the mmapped thing in the file to a C struct | 06:29 |
| whitequark | but this doesn't work with ordinary pointers because those aren't relocatable | 06:29 |
| whitequark | so instead of storing absolute addresses, you store relative addresses, relative to the struct the pointer is in | 06:29 |
| whitequark | people call this "zero cost deserialization" | 06:30 |
| awygle | i find zero cost deserialization viscerally satisfying and i wonder what a programming language with more first-class support for relative pointers would look like | 06:32 |
| whitequark | daveshah: okay, so my suggestion for the bba mess is as follows: | 06:33 |
| whitequark | 1. the arch-independent part of the process becomes runnable outside of the main nextpnr cmake root | 06:33 |
| whitequark | so you have a way to build "just the bba files" for cross-compilation | 06:33 |
| daveshah | Yes, that sounds good | 06:33 |
| daveshah | Yep, a few people are doing hacks to achieve this but it would be nice to have an official way | 06:34 |
| whitequark | 2. bbasm is always run as a part of the cross-build due to the endianness issue. it is not possible to give the main cmake files existing *products* of bbasm | 06:34 |
| whitequark | 3. you can pick whether the build (cross or not) invokes bba generation itself | 06:35 |
| *** awordnot has joined #yosys | 06:35 | |
| whitequark | 4. on suitable platforms (nix), you can pick whether the assembled bba files will be embedded in the binary or not | 06:36 |
| daveshah | The alternative would be mmap ? | 06:37 |
| whitequark | indeed, as it currently is | 06:37 |
| whitequark | I'll also make mmap lazy so you can ship only some chipdbs but that's a minor detail | 06:37 |
| daveshah | It would be nice to support binary relative paths for that, like Yosys | 06:37 |
| daveshah | I am happy to do that at some point though | 06:37 |
| Sarayan | wq: I tend to make the pointers relative to the start of the dump file, but sure | 06:38 |
| whitequark | Sarayan: same difference. I think flatbuffers does it relative to struct, bba makes it relative to start of file | 06:39 |
| whitequark | the latter is a bit faster if you can afford it | 06:39 |
| whitequark | daveshah: one thing I have a bit of doubt about is the change in behavior re: EXTERNAL_CHIPDB | 06:41 |
| Sarayan | I've made an unrelated system where the program can either load the dump, fix the pointers and use the data or mmap shared readonly and add the the pointers on use, with some template magic to write only one version of the code. Gives you the choice between startup time and runtime speed | 06:42 |
| whitequark | right now if you use that I think you would feed the nextpnr binary bbasm'd files you produced elsewhere | 06:42 |
| whitequark | so on eg your raspi you don't have to run even bbasm itself | 06:42 |
| whitequark | with my plan the bbasm would be run as a part of the build process, always | 06:43 |
| whitequark | afaik bbasm itself is not resource intensive though so this isn't really an issue | 06:43 |
| whitequark | daveshah: btw i think you can close #445 and #446 | 06:47 |
| whitequark | there's no difference and the whole approach was due to a misattribution of OOM | 06:47 |
| daveshah | Yeah bbasm isn't the slow bit at all so that's fine | 06:48 |
| daveshah | Yeah done that too | 06:50 |
| awygle | why does bba end up endian specific? too much of a performance hit to bswap it if needed? | 06:57 |
| *** promach3 has joined #yosys | 06:57 | |
| promach3 | How to use https://github.com/The-OpenROAD-Project/OpenROAD-flow with yosys ? | 06:58 |
| tpb | Title: GitHub - The-OpenROAD-Project/OpenROAD-flow: OpenROADs top level repo pointing to stable binaries, code, sample designs and an example flow (at github.com) | 06:58 |
| whitequark | awygle: why take the perf hit if you can avoid it? | 06:58 |
| awygle | so it doesn't end up arch specific lol | 06:58 |
| whitequark | does that help much? | 06:58 |
| awygle | but yeah if it's in the hot path, sure | 06:59 |
| awygle | which it sounds like it is | 06:59 |
| whitequark | most of the time it is embedded in the binary anyway | 06:59 |
| whitequark | it's not like you can download bba output from elsewhere or something | 06:59 |
| awygle | I'm not very informed about how all this works. I was just curious | 07:00 |
| whitequark | ah | 07:00 |
| Sarayan | where do I bitch because of contradictions in the nextpnr doc? ;-) | 07:00 |
| awygle | Like I said, I'm a big fan of zero copy techniques | 07:01 |
| whitequark | Sarayan: issues? | 07:01 |
| Lofty | promach3: they have their own Yosys fork at https://github.com/The-OpenROAD-Project/yosys | 07:01 |
| tpb | Title: GitHub - The-OpenROAD-Project/yosys: Logic synthesis and ABC based optimization (at github.com) | 07:01 |
| Sarayan | wq: ok | 07:01 |
| promach3 | Lofty: https://github.com/The-OpenROAD-Project/OpenROAD-flow/tree/master/flow#quick-start this quick-start instruction seems not correct | 07:02 |
| tpb | Title: OpenROAD-flow/flow at master · The-OpenROAD-Project/OpenROAD-flow · GitHub (at github.com) | 07:02 |
| Lofty | promach3: then file an issue about it | 07:03 |
| Sarayan | Ah no, it's me who's having understanding issues | 07:05 |
| whitequark | anyone knows what happened to gaffe-logic? | 07:25 |
| whitequark | github org and repo are gone | 07:25 |
| *** jakobwenzel has joined #yosys | 07:28 | |
| daveshah | No idea | 07:28 |
| daveshah | that was kc8apf's things | 07:29 |
| *** dys has quit IRC | 07:45 | |
| whitequark | okay, how many custom json readers/writers does yosyshq have now | 07:46 |
| whitequark | at least three? | 07:46 |
| daveshah | At least I got rid of the custom reader in nextpnr | 07:47 |
| daveshah | It was 4 at one point | 07:47 |
| whitequark | aaaah | 07:48 |
| whitequark | can we get rid of the custom writer in nextpnr too | 07:48 |
| daveshah | The post PnR netlists can be pretty large | 07:50 |
| daveshah | So I don't think a simple custom writer is that evil | 07:50 |
| whitequark | I see | 07:50 |
| whitequark | that's reasonable | 07:50 |
| daveshah | Although eventually I'd rather use flatbuffers or something for these | 07:51 |
| daveshah | I haven't had the space in my work queue to get to that yet | 07:51 |
| whitequark | aaaaargh, why would you use CMAKE_CURRENT_SOURCE_DIR but *also* include | 08:00 |
| whitequark | this almost defeats the purpose... | 08:00 |
| *** dys has joined #yosys | 08:07 | |
| whitequark | daveshah: can i ask a question | 08:26 |
| daveshah | sure | 08:26 |
| whitequark | why on earth does nextpnr use boost-iostreams to call mmap, given that on windows it embeds stuff in resources anyway? | 08:26 |
| whitequark | it's just like... mmap with more steps, and also more opportunity for error | 08:26 |
| daveshah | no idea, mmicko did that stuff | 08:26 |
| whitequark | sigh | 08:26 |
| whitequark | so now i see that there are 4 (four) different ways nextpnr can access resources | 08:27 |
| whitequark | one more than the OSes it supports! | 08:27 |
| whitequark | *access chipdbs | 08:27 |
| Sarayan | Miodrag Milanovic? | 08:27 |
| daveshah | yes | 08:27 |
| whitequark | and the build steps are all duplicated 4 times for no reason | 08:27 |
| Sarayan | huhu cool | 08:27 |
| whitequark | this is hell | 08:27 |
| daveshah | the resource vs string thing is because msvc doesn't allow long strings | 08:29 |
| daveshah | idek what the mmap thing was even | 08:29 |
| daveshah | for originally | 08:29 |
| whitequark | probably for external chipdb | 08:30 |
| daveshah | yes, although I'm not actually aware of anyone using that other than your wasm stuff | 08:30 |
| daveshah | I think it was an abandoned project | 08:30 |
| whitequark | wasm doesn't even have mmap! | 08:30 |
| whitequark | i use an mmap emulator wasi-libc has | 08:30 |
| whitequark | which uses ... malloc and read | 08:30 |
| daveshah | ah right | 08:30 |
| whitequark | there are so many useless layers here | 08:31 |
| daveshah | well, I'm just as fed up as being responsible for nextpnr as you are for having to fix it | 08:31 |
| whitequark | yeah, i'm not complaining at you, sorry if it came off like that | 08:32 |
| whitequark | actually if you give me commit bit i'll just shut up and fix it | 08:32 |
| daveshah | hmm, don't you have that already? | 08:32 |
| whitequark | nope | 08:32 |
| whitequark | i'm basically fine being the person who fixes nextpnr cmake if i actually have the power to do it properly | 08:33 |
| daveshah | done | 08:33 |
| daveshah | thanks! | 08:33 |
| whitequark | np | 08:33 |
| whitequark | by "responsible for nextpnr" do you mean being basically the maintainer of the whole thing? as in you'd rather work on the core algorithms? | 08:34 |
| * Sarayan looks at whitequark approaching dangerous territory | 08:35 | |
| whitequark | Sarayan: it is a lot easier to fix broken cmake crap at the root than it is to work around broken cmake crap at the point of use | 08:35 |
| daveshah | yes, just general burnout really | 08:35 |
| Sarayan | wq: You say that, you blink, and you end up maintainer on one more project :-) | 08:35 |
| whitequark | it's going to cause problems at *some* point in the build pipeline, might as well fix them at the point where it benefits everyone | 08:36 |
| whitequark | daveshah: ah yeah makes sense | 08:36 |
| daveshah | it's a shame that noone has wanted to pay Symbiotic for nextpnr development | 08:36 |
| whitequark | i can definitely help out with systems bits | 08:36 |
| daveshah | people have wanted to pay me, which is nice, but I can't replicate myself | 08:36 |
| daveshah | thanks | 08:36 |
| daveshah | if a quarter of resources going into VPR at the moment were going into nextpnr, things would doubtless be in a much better place | 08:38 |
| Sarayan | vpr? | 08:38 |
| daveshah | the other open source place and route tool | 08:38 |
| Sarayan | there are two? | 08:38 |
| Lofty | Verilog Place and Route | 08:38 |
| Lofty | There are unfortunately two | 08:38 |
| daveshah | versatile place and route | 08:38 |
| Lofty | Okay, I stand corrected there | 08:38 |
| Sarayan | ah, part of vtr | 08:39 |
| Lofty | Symbiflow want to use it for XC7 | 08:42 |
| Lofty | Because, uh | 08:42 |
| daveshah | There are good reasons for going to VPR | 08:43 |
| daveshah | But most of those could have been fixed if they put time into nextpnr instead | 08:43 |
| Lofty | And now they're trying to turn VPR into nextpnr, it seems | 08:44 |
| daveshah | The other big problem with nextpnr is that the whole thing was a bit rushed at the start, with an original two month deadline | 08:47 |
| daveshah | Unfortunately that created quite a bit of technical debt that is quite tiring to recover from | 08:47 |
| *** Asu has joined #yosys | 08:49 | |
| whitequark | daveshah: do you know how exactly search for pytrellis is supposed to work? | 09:17 |
| whitequark | there is some weird stuff where TRELLIS_INSTALL_PREFIX/lib might not match PYTRELLIS_LIBDIR | 09:18 |
| daveshah | It's been a long time since I last checked it | 09:18 |
| whitequark | okay, I'll keep it as-is for now | 09:19 |
| whitequark | might revisit once i'm working on yowasp-ecp5 | 09:19 |
| daveshah | I think it was partly because of various distro rules on where libraries went | 09:20 |
| whitequark | hm, makes sense | 09:21 |
| mwk | whitequark: what manual? | 09:22 |
| whitequark | mwk: yosys manual | 09:22 |
| mwk | with what, the new ff types? | 09:22 |
| whitequark | yep | 09:22 |
| mwk | yeah, it was in the base pr | 09:22 |
| whitequark | oh cool, thanks | 09:22 |
| whitequark | daveshah: I remember some discussion about nextpnr requiring a trellis *install* ie not being able to use a trellis build tree | 09:23 |
| whitequark | is that accurate? | 09:23 |
| daveshah | Yes that's correct now | 09:23 |
| daveshah | Overall that was the preferred option | 09:23 |
| whitequark | hmm | 09:23 |
| whitequark | any specific reason? | 09:23 |
| daveshah | and I didn't really want the complications of supporting both | 09:23 |
| daveshah | For iCE40 we also need a build tree | 09:24 |
| whitequark | also? | 09:24 |
| whitequark | I currently build nextpnr-ice40 with just ICEBOX_ROOT specified, seems to work well | 09:27 |
| mwk | whitequark: https://github.com/YosysHQ/yosys/pull/1818/files#diff-0ce1e98570376b7ff9a88132ba8c9e28 I added the new *FF* types, but left latches undocumented as before | 09:27 |
| mwk | should probably add those as well at some point | 09:27 |
| * whitequark nods | 09:27 | |
| whitequark | mhh I think I'll add the capability of building with a Trellis source tree while I'm at it, I wanted that for a while | 09:27 |
| whitequark | doesn't seem too invasive | 09:28 |
| daveshah | Oh sorry, I meant ice40 needs an install tree and not a build tree | 09:28 |
| daveshah | Sure, if you can do it in a clean way thats fine | 09:28 |
| whitequark | wait really? | 09:28 |
| whitequark | ice40 works just fine with a build tree | 09:29 |
| daveshah | Oh, hmm | 09:29 |
| daveshah | I thought the timing data wouldn't be found that way | 09:29 |
| whitequark | ohh | 09:29 |
| whitequark | nevermind, I screwed up a build script, it indeed finds an installed copy of icebox on my machine | 09:30 |
| whitequark | you're right | 09:30 |
| whitequark | okay, let's not change that for now then | 09:30 |
| whitequark | I thought it's inconsistent but if it isn't that's ok too I guess | 09:30 |
| daveshah | The build tree option also has issues with out of tree builds | 09:32 |
| daveshah | As it needs the compiled libraries from the build dir, and Python libraries and databases from the source dir | 09:32 |
| whitequark | you hit similar issues in cross compilation anyway | 09:32 |
| whitequark | as it is i'm going to build icestorm and prjtrellis twice, I think | 09:33 |
| whitequark | but yeah, I'll try not to change too many things at once | 09:33 |
| *** az0re has quit IRC | 09:36 | |
| *** kraiskil has joined #yosys | 09:58 | |
| *** nengel has joined #yosys | 10:04 | |
| *** anticw has quit IRC | 10:58 | |
| *** jaseg has joined #yosys | 12:01 | |
| *** daveshah has quit IRC | 12:54 | |
| *** daveshah has joined #yosys | 12:54 | |
| *** X-Scale has quit IRC | 13:01 | |
| *** jfcaron has joined #yosys | 13:18 | |
| *** FFY00 has quit IRC | 13:28 | |
| *** FFY00 has joined #yosys | 13:29 | |
| *** jfcaron has quit IRC | 14:00 | |
| mwk | so about yosys manual | 14:00 |
| mwk | is there some sort of CI that builds the manual from master and uploads it somewhere? or do you have to build that manually | 14:00 |
| mwk | because that uhhh severely limits its usefulness | 14:01 |
| *** jfcaron has joined #yosys | 14:01 | |
| daveshah | No I don't think there is any CI for the manual | 14:01 |
| mwk | (also building the manual is uhhhh an experience) | 14:01 |
| daveshah | in fact lambda pointed out the version on claire's website is from 0.8 not 0.9 | 14:01 |
| mwk | .. | 14:02 |
| mwk | alright | 14:02 |
| whitequark | we should absolutely do it on CI | 14:02 |
| whitequark | but... idfk how CI works in yosys | 14:02 |
| daveshah | we could probably add it as a release asset to https://github.com/open-tool-forge/fpga-toolchain | 14:02 |
| tpb | Title: GitHub - open-tool-forge/fpga-toolchain: Multi-platform nightly builds of open source FPGA tools (at github.com) | 14:02 |
| mwk | ... added to tomorrow's agenda | 14:06 |
| *** jfcaron has quit IRC | 14:24 | |
| *** jfcaron has joined #yosys | 14:32 | |
| cr1901_modern | whitequark: Surprisingly absolutely nobody, the TRELLIS_INSTALL_PREFIX logic goes to hell on Windows. I have to set both: | 14:36 |
| cr1901_modern | -DTRELLIS_INSTALL_PREFIX=/mingw64 -DPYTRELLIS_LIBDIR=/mingw64/lib/trellis | 14:36 |
| whitequark | no it goes to hell on *msys* | 14:37 |
| whitequark | if you use windows please for the love of god at least stick to msvc | 14:37 |
| whitequark | msys is like the worst parts of *nix and windows combined in one convenient package | 14:38 |
| whitequark | anyway | 14:38 |
| whitequark | i'm almost done with the updated logic | 14:38 |
| whitequark | i think it should suck less on windows in general, including msys | 14:38 |
| whitequark | you won't need to compile those hundred-megabyte-sized cc files anymore, it should just use resource files | 14:38 |
| cr1901_modern | https://github.com/YosysHQ/nextpnr/blob/master/ecp5/family.cmake#L12 This line will succeed in MSVC? | 14:43 |
| tpb | Title: nextpnr/family.cmake at master · YosysHQ/nextpnr · GitHub (at github.com) | 14:43 |
| cr1901_modern | Does cmake know to strip the .so and conver to .dll? | 14:44 |
| whitequark | oh, the *PYTRELLIS_LIBDIR* logic goes to hell, you mean | 14:44 |
| whitequark | yeah that's a different question. no it doesn't do that | 14:44 |
| *** X-Scale has joined #yosys | 14:44 | |
| whitequark | i don't think the suffix is even necessary | 14:44 |
| cr1901_modern | Oh, well I probably should've tested that, but I think I was irritated at the time and just wanted to get something working. | 14:46 |
| whitequark | I noticed. | 14:46 |
| whitequark | that's how most of nextpnr's cmake files are written | 14:46 |
| whitequark | and i hate every single line of them | 14:47 |
| whitequark | working on build systems is just shoveling shit someone else was too lazy to fix properly, day in, day out | 14:47 |
| whitequark | i've spent 11 hours straight today working on just the family.cmake refactor | 14:48 |
| cr1901_modern | :( | 14:48 |
| whitequark | there is a pervasive culture of making build systems the problem of the next person who is unlucky enough to work on them | 14:51 |
| whitequark | scratch your own itch, who gives a fuck what happens next? | 14:51 |
| whitequark | well usually what happens next is i have to fix that code | 14:51 |
| cr1901_modern | Ever work on someone else's meson project? I think that's not so terrible. But otherwise I relate. >> | 14:52 |
| cr1901_modern | CMake: "At least it's not autotools" (tm) | 14:52 |
| whitequark | meson is like cmake but less bad | 14:53 |
| whitequark | i've never used it yet | 14:53 |
| whitequark | the problem isn't the tools per se | 14:53 |
| whitequark | i mean, some tools make it actively harder to write good build systems (see: make), but for the most part it is the lack of trying | 14:53 |
| whitequark | what people commonly do is apply the absolute lowest bar to build system changes, which is "it works in my machine right now" | 14:57 |
| whitequark | and leave the consequences to someone else | 14:57 |
| whitequark | bonus points for sprinking various conditionals without turning your brain on | 14:57 |
| whitequark | "hopefully that still works elsewhere with these" | 14:57 |
| cr1901_modern | I test "it works on my machine*s* right now". All 2 archs- x86 and ARM- and 2 OSes- Windows and Debian. Perhaps sometime in the far future, I should do something similar to japaric's cross, and run a bunch of qemu and docker instances locally. | 15:00 |
| whitequark | well, that's much better than usua | 15:00 |
| whitequark | *usual | 15:00 |
| cr1901_modern | (Not relevant to cargo, since things basically are self-contained there due to lack of shared libs) | 15:00 |
| *** jfcaron has quit IRC | 15:11 | |
| *** solidtux has joined #yosys | 15:19 | |
| whitequark | so the .so suffix is actually necessary in this case | 15:36 |
| whitequark | i'm not sure if the find_library() logic does anything useful on windows even in principle | 15:37 |
| cr1901_modern | ... huh | 15:37 |
| whitequark | okay, i'm essentially done, just need to write a description of the changes... | 15:41 |
| cr1901_modern | Is setting PYTRELLIS_LIBDIR is mandatory on Windows then? | 15:41 |
| *** citypw has quit IRC | 15:42 | |
| whitequark | I think so | 15:42 |
| whitequark | I mean, do you install pytrellis system-wide? | 15:43 |
| cr1901_modern | yes; the logic for using a local copy of pytrellis disappeared in the commit that PYTRELLIS_LIBDIR was introduced | 15:43 |
| whitequark | hmm | 15:44 |
| whitequark | how does that even work on windows? | 15:44 |
| whitequark | where does pytrellis go? | 15:44 |
| cr1901_modern | C:/msys64/mingw64/lib/trellis. I don't think it matter where it goes in the grand scheme of things. C:/msys64/mingw64/lib is only special for the C/C++ compiler search path, and .dlls, of course, normally go into a directory visible on the system path | 15:46 |
| cr1901_modern | Still need to set up PYTHONPATH to find pytrellis even if you use PYTRELLIS_LIBDIR | 15:46 |
| whitequark | oh, you don't install it on *windows*, you install it on *msys* | 15:47 |
| whitequark | msys isn't windows | 15:47 |
| whitequark | it's more like gnu/windows | 15:47 |
| whitequark | okay, i'll use CMAKE_SHARED_LIBRARY_SUFFIX there | 15:48 |
| cr1901_modern | They are native Windows exes without pretending they are running on *nix (like cygwin1.dll binaries do), so that's why I call it Windows. | 15:48 |
| cr1901_modern | Ack | 15:48 |
| *** dys has quit IRC | 16:06 | |
| tnt | Does yosys have something to set the "primary" name of a net ? | 16:16 |
| whitequark | no | 16:16 |
| tnt | outstanding .... :/ | 16:17 |
| whitequark | see #2165 | 16:17 |
| whitequark | what are you hitting? | 16:17 |
| whitequark | constraint issues? | 16:17 |
| tnt | Yeah. The eblif refers to the net as "usb_I.uc_clk". It has a ".names usb_I.uc_clk wb_clk" marking the "alias" but VPR apparently doesn't care for min/max delay constrainst and just uses the primary name. | 16:19 |
| tnt | If it's gotta pick a name it could at least pick the shortest one. | 16:19 |
| whitequark | there is some logic to do that | 16:20 |
| whitequark | it's probably broken, hence #2165 | 16:20 |
| cr1901_modern | What is the "primary" name of a net? | 16:23 |
| tnt | whatever is used in the eblif when connecting .subckt ports. | 16:23 |
| whitequark | does eblif not contain all net aliases? | 16:25 |
| whitequark | that seems like a bug | 16:25 |
| tnt | It does. | 16:26 |
| tnt | VPR ignores them for max_delay / min_delay constraints AFAICT. | 16:26 |
| whitequark | okay, so that seems like a vpr bug then | 16:26 |
| whitequark | nextpnr has the same bug, actually | 16:26 |
| whitequark | I should fix it sometime | 16:26 |
| whitequark | ah, wait, I think the logic to choose the shortest net name that I added was in nextpnr, not vpr | 16:27 |
| tnt | yeah, I remember that logic in nextpnr. | 16:28 |
| daveshah | nextpnr can use all aliases now | 16:29 |
| daveshah | at least all the ones that Yosys retains | 16:29 |
| tnt | yup. But it at least still pick the shortest one for "display" purposes. | 16:30 |
| whitequark | ah, good | 16:30 |
| tnt | Here with VPR my timing re[port ends up for clock domain "usb_I.tx_pkt_I.crc_16_I.clk" instead of "clk_usb" ... | 16:31 |
| *** jfcaron has joined #yosys | 16:34 | |
| *** dys has joined #yosys | 16:37 | |
| *** anticw has joined #yosys | 16:42 | |
| *** dys has joined #yosys | 16:44 | |
| whitequark | cr1901_modern: please test https://github.com/YosysHQ/nextpnr/pull/459 | 17:36 |
| tpb | Title: CMake: rewrite chipdb handling from ground up by whitequark · Pull Request #459 · YosysHQ/nextpnr · GitHub (at github.com) | 17:36 |
| whitequark | everyone else is encouraged, too | 17:36 |
| daveshah | CI looks unhappy | 17:50 |
| daveshah | perhaps a CMake version issue, or does the command line need changing? | 17:51 |
| *** jfcaron has quit IRC | 17:52 | |
| whitequark | let's see | 17:53 |
| daveshah | Google suggests this commit adds that functionality to CMake https://gitlab.kitware.com/cmake/cmake/commit/3e774ad78c49cde1f47e1d7285bffef622859d64 which presumably won't be in Ubuntu 16.04. However much I'd like to change it, I think 16.04 should probably stay supported | 17:53 |
| tpb | Title: objlib: Allow other libraries to link to `OBJECT` libraries. (3e774ad7) · Commits · CMake / CMake · GitLab (at gitlab.kitware.com) | 17:53 |
| whitequark | yes, cmake version issue. let's just use a STATIC library instead | 17:53 |
| whitequark | there's no downside beyond wasting disk space | 17:53 |
| whitequark | oh, hm | 17:54 |
| whitequark | my version of cmake actually *does* link the files in the object libraries | 17:54 |
| whitequark | so it might be an even newer change? | 17:54 |
| daveshah | What OS are you running? | 17:54 |
| whitequark | debian | 17:54 |
| whitequark | cmake 3.13.4 here | 17:55 |
| daveshah | Looks like 16.04 provides 3.5 | 17:55 |
| daveshah | which is presumably what CI will use as it just apt-gets it iirc | 17:55 |
| whitequark | okay, let's target that | 17:55 |
| daveshah | That seems reasonable | 17:56 |
| daveshah | I know it previously broke with the version of CMake in Ubuntu 14.04, so no need to worry about that | 17:56 |
| whitequark | okay, pushed | 17:57 |
| somlo | daveshah, whitequark: I'll try to test this on Fedora and mock (the build process for RPMs), tonight or tomorrow | 17:57 |
| daveshah | thanks! | 17:58 |
| *** jfcaron has joined #yosys | 17:59 | |
| *** kraiskil has quit IRC | 18:38 | |
| *** az0re has joined #yosys | 19:21 | |
| *** maartenBE has quit IRC | 20:05 | |
| *** maartenBE has joined #yosys | 20:12 | |
| cr1901_modern | whitequark: Sorry I fell asleep. I will test now | 20:26 |
| *** emeb_mac has joined #yosys | 20:26 | |
| *** DaKnig has quit IRC | 20:43 | |
| *** jfcaron has quit IRC | 20:51 | |
| *** jfcaron has joined #yosys | 20:51 | |
| *** jfcaron_ has joined #yosys | 20:58 | |
| *** jfcaron has quit IRC | 21:01 | |
| cr1901_modern | Err, I'll test within the hour* | 21:07 |
| *** jfcaron_ has quit IRC | 21:16 | |
| *** thehardway is now known as bwidawsk | 21:18 | |
| *** jfcaron has joined #yosys | 21:28 | |
| *** Asuu has joined #yosys | 22:12 | |
| *** Asu has quit IRC | 22:12 | |
| *** bzztploink has quit IRC | 22:22 | |
| *** bzztploink has joined #yosys | 22:24 | |
| cr1901_modern | With this hour* (woooow, today is irritating) | 22:25 |
| *** Asuu has quit IRC | 22:32 | |
| *** jaseg has quit IRC | 23:09 | |
| *** awordnot has quit IRC | 23:10 | |
| *** awordnot has joined #yosys | 23:11 | |
| az0re | Isn't "within the hour" just as correct as "with[in] this hour", and more commonly used, too? | 23:25 |
| qu1j0t3 | i would say so | 23:25 |
| qu1j0t3 | as a native speaker | 23:26 |
| az0re | I am also a native speaker, and I'm guessing cr1901_modern is, too | 23:26 |
| az0re | Which is why I'm a bit confused | 23:26 |
| az0re | There's for sure a difference between "within the hour" (i.e. by the end of the current wall-clock hour) and "within one hour" (i.e. within 59 minutes + 60 seconds) | 23:28 |
| az0re | But "cr1901_modern> With this hour* (woooow, today is irritating)" <--- I don't understand this correction | 23:28 |
| qu1j0t3 | fwiw i usually say "within the hour" to mean "within one hour" *shrug* | 23:28 |
| qu1j0t3 | but it's very approximate anyway and i am sure i usually break the promise | 23:29 |
| az0re | Yeah well I guess there's some room for interpretation there | 23:29 |
| az0re | But I'm still confused :) | 23:29 |
| qu1j0t3 | i'm equally confused by the correction but maybe it's a typo | 23:29 |
| az0re | Anyway it's irrelevant | 23:29 |
| az0re | Not worth worrying about lol | 23:29 |
| cr1901_modern | az0re: It was a typo. No doubt caused by a bunch of little things being irritating cascading into my day being irritating | 23:35 |
| cr1901_modern | So I'm not really concentrating on proper preposition usage lmao | 23:35 |
| qu1j0t3 | :) | 23:36 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!