| *** tpb has joined #yosys | 00:00 | |
| tedx | is this IRC channel or /r/yosys the better place for yosys newbie questions? | 00:27 |
|---|---|---|
| *** jfcaron has quit IRC | 01:37 | |
| ZipCPU | tedx: Both should work | 01:46 |
| ZipCPU | Both daveshah and I try to monitor the /r/yosys reddit for newbie questions to make certain they get answers | 01:46 |
| ZipCPU | This channel works as well, as long as you are willing to wait across timezones for an answer to your question | 01:47 |
| ZipCPU | I will admit that ... without anyone asking questions in /r/yosys, I've stopped checking as often as I used to | 01:47 |
| cr1901_modern | whitequark: https://github.com/YosysHQ/nextpnr/pull/459#issuecomment-649165236 | 01:51 |
| tpb | Title: CMake: rewrite chipdb handling from ground up by whitequark · Pull Request #459 · YosysHQ/nextpnr · GitHub (at github.com) | 01:51 |
| *** cr1901_modern has quit IRC | 01:52 | |
| *** Degi has quit IRC | 02:02 | |
| *** Degi has joined #yosys | 02:05 | |
| az0re | cr1901_modern: I see. No worries lol | 02:08 |
| *** cr1901_modern has joined #yosys | 02:10 | |
| *** Cerpin has quit IRC | 02:13 | |
| *** Cerpin has joined #yosys | 04:02 | |
| *** rektide has quit IRC | 04:11 | |
| *** m4ssi has joined #yosys | 04:42 | |
| *** emeb_mac has quit IRC | 06:10 | |
| *** citypw has joined #yosys | 06:53 | |
| *** jhol` has joined #yosys | 07:07 | |
| *** jhol has quit IRC | 07:10 | |
| *** filt3r has quit IRC | 07:10 | |
| *** filt3r has joined #yosys | 07:15 | |
| *** FFY00 has quit IRC | 07:17 | |
| *** citypw has quit IRC | 07:23 | |
| *** citypw has joined #yosys | 07:36 | |
| *** dys has quit IRC | 07:38 | |
| *** FFY00 has joined #yosys | 08:13 | |
| *** Asu has joined #yosys | 08:27 | |
| *** mkru has joined #yosys | 08:29 | |
| *** dys has joined #yosys | 08:44 | |
| *** adjtm_ has joined #yosys | 09:09 | |
| *** adjtm has quit IRC | 09:11 | |
| *** kraiskil has joined #yosys | 09:22 | |
| *** kraiskil has quit IRC | 09:38 | |
| *** kraiskil has joined #yosys | 09:44 | |
| *** m4ssi has quit IRC | 11:29 | |
| *** anishathalye has quit IRC | 12:20 | |
| whitequark | daveshah: poke re: #459 | 12:55 |
| whitequark | i think it's generally ready to merge, what remains is small tweaks to cmake discovery code | 12:55 |
| whitequark | and i have most of the next PR | 12:55 |
| whitequark | you know what's funny? making nextpnr resilient to missing chipdbs actually involved *removing* code moreso than *adding* | 12:56 |
| daveshah | so do you want me to review and merge and then do another PR, or just review for now? | 12:56 |
| *** kraiskil has quit IRC | 12:59 | |
| whitequark | former | 12:59 |
| *** jakobwenzel1 has joined #yosys | 13:32 | |
| *** mkru has quit IRC | 13:39 | |
| *** Asu has quit IRC | 13:45 | |
| *** Asu has joined #yosys | 13:45 | |
| somlo | whitequark, daveshah: after latest force-push (3f450ed and a9224bf), build still works for me in fedora | 14:06 |
| somlo | (re. nextpnr PR 459) | 14:06 |
| whitequark | cool | 14:08 |
| *** jakobwenzel1 has quit IRC | 14:27 | |
| *** Cerpin has quit IRC | 14:33 | |
| *** Cerpin has joined #yosys | 14:34 | |
| daveshah | merged! | 14:40 |
| whitequark | sweet! | 14:40 |
| whitequark | i'm almost done with the embedding improvements | 14:40 |
| *** X-Scale` has joined #yosys | 14:41 | |
| *** X-Scale has quit IRC | 14:42 | |
| *** X-Scale` is now known as X-Scale | 14:42 | |
| *** mecrisp has joined #yosys | 14:59 | |
| *** emeb has joined #yosys | 15:47 | |
| *** maartenBE has quit IRC | 16:07 | |
| *** maartenBE has joined #yosys | 16:10 | |
| *** citypw has quit IRC | 16:23 | |
| az0re | So, whitequark, I find myself once again wanting access to `statdata_t` in a different context. | 16:29 |
| az0re | I thought it was a one-off but maybe this is a sign... | 16:30 |
| az0re | Can you remind me what we determined was bad about breaking it out from the `stat` private namespace? And IIRC we did a little brainstorming; do you have any idea for making a Cell/Module `statdata_t`-like interface available for internal Yosys stuff? | 16:33 |
| az0re | Oh, right, the point was about the cell costs, how not all costs are created equal (e.g. logic area vs. memories used), and how config files are the way to go. | 16:36 |
| az0re | So is there actually an objection to breaking out `statdata_t` and adding a `CellCosts::unit_gate_cost()`? I agree it's not the ideal way to go in the long run but it's a minor albeit useful change now. | 16:38 |
| whitequark | az0re: yes, there is; I don't think breaking out the existing code in `stat` is acceptable at all | 16:40 |
| az0re | Frankly I could just iterate over `module->cells()` directly and calculate my own stats, but it seems that the above way is more elegant--that's what it's designed to do, even if the design is currently not so great. | 16:40 |
| whitequark | I would rather have bad code contained in a bunch of passes on its own than have it gain more users over time | 16:41 |
| whitequark | if we explicitly take a step to expose some code to all Yosys passes we should first make sure that code is actually good | 16:41 |
| whitequark | I'd be 100% fine with you doing your own stats for now and migrating that over to shared infrastructure for cell costs later | 16:42 |
| az0re | It's not really a big deal either way, but doesn't that ease the maintenance burden? It gives one nice target to improve instead of a bunch of different bits strewn about here and there | 16:42 |
| whitequark | nope | 16:42 |
| whitequark | if you have a bad API that's used by multiple passes you have to change all of those passes in lockstep when improving that API | 16:43 |
| whitequark | if the passes are just doing the bad thing in a self-contained way you can do it one by one | 16:43 |
| az0re | True | 16:44 |
| az0re | In any case, right now there obviously aren't any other users, and my use case is very simple, so while it's unnecessary code I wouldn't exactly call it "bad code" anyway | 16:44 |
| whitequark | "bad" is a poor choice of word on my part | 16:45 |
| az0re | So, fine, I can calculate my own stats | 16:45 |
| whitequark | too strong | 16:45 |
| az0re | No, it's a fine word | 16:45 |
| az0re | I get it | 16:45 |
| whitequark | right, okay | 16:45 |
| az0re | Code that we would rather not exist | 16:45 |
| Sarayan | suboptimal? too specialized for generalizing the use? | 16:45 |
| az0re | Something like that | 16:46 |
| sorear | .oO( the role of gene duplication in evolution ) | 16:48 |
| whitequark | heh | 16:50 |
| whitequark | daveshah: any comment on the general approach? name bikeshed? https://github.com/YosysHQ/nextpnr/pull/460/files | 16:52 |
| tpb | Title: [WIP] Simplify and improve chipdb embedding/loading by whitequark · Pull Request #460 · YosysHQ/nextpnr · GitHub (at github.com) | 16:52 |
| daveshah | Looks good, and a nice cleanup too | 17:01 |
| whitequark | cool, let me finish the *nix embed part | 17:03 |
| whitequark | what i have in mind right now is a global static map populated with individual chipdb files by linking them in | 17:03 |
| whitequark | any objections? | 17:03 |
| whitequark | an alternative would be to generate a get_chipdb function in cmake or something | 17:04 |
| whitequark | I don't really have an opinion one way or another | 17:04 |
| daveshah | The global static map seems good | 17:05 |
| whitequark | 'kay, thanks | 17:05 |
| whitequark | this is the last thing needed for yowasp to be functionally complete... | 17:05 |
| daveshah | Great! | 17:08 |
| cr1901_modern | whitequark: Is this a typo? https://github.com/YosysHQ/nextpnr/blob/master/ecp5/family.cmake#L40 | 17:19 |
| tpb | Title: nextpnr/family.cmake at master · YosysHQ/nextpnr · GitHub (at github.com) | 17:19 |
| whitequark | oops | 17:19 |
| cr1901_modern | (the ICE40_CHIPDB part in ecp5) | 17:19 |
| cr1901_modern | I'm not sure what that line is doing anyway, tbh... {ICE40, ECP5}_CHIPDB is a directory, correct? And add_library wants source files? | 17:32 |
| whitequark | it's there so that add_library() doesn't choke if there are no actual sources to build | 17:33 |
| whitequark | such as with external chipdb | 17:33 |
| whitequark | it's a bit of a hack, but i'm not sure if there's a better way. it was there before my refactor, too | 17:33 |
| whitequark | there is one subtle benefit | 17:33 |
| whitequark | if you specify -DICE40_CHIPDB and that dir doesn't exist, this will break in a nicer way | 17:33 |
| whitequark | daveshah: when the chipdb is not present, should the corresponding option disappear, or should it return an error at runtime, or something else? | 17:41 |
| whitequark | I'm leaning towards the former, it makes it more clear which chips are available from --help text | 17:41 |
| whitequark | but you could argue it's confusing | 17:41 |
| daveshah | Yeah, the former is probably best | 17:42 |
| cr1901_modern | Are there recent chipdbs available anywhere? I could've sworn there was some daily CI set up for them | 17:42 |
| whitequark | I could also mark them as (disabled) or (chipdb missing) but leave them present | 17:43 |
| whitequark | in --help text | 17:43 |
| whitequark | hm, it's kind of obnoxious to do that in c++... | 17:44 |
| Sarayan | What would you two recommend for a big chip description for nextpnr like the cyclone v? If I manage to create a small-ish program that generates the lists, should I use the program at compile time to generate the data, at runtime to generate the data in memory then use it, or generate on the fly with the costs that represents? | 17:44 |
| whitequark | let's go with a simple choice for now | 17:44 |
| cr1901_modern | whitequark: Just to be explicit, if you _are_ building your own chipdbs as part of the nextpnr build, then "{ICE40,ECP5}_CHIPDB" and "${family}/chipdb" will be the same directory, correct? | 17:44 |
| *** kraiskil has joined #yosys | 17:44 | |
| whitequark | yes | 17:44 |
| cr1901_modern | Okay, I think I got a grasp on everything now | 17:45 |
| daveshah | Sarayan: ideally, you use a data structure that can be iterated over without ever fully flattenin | 17:46 |
| daveshah | this is unfortunately non-trivial to design, and I haven't ever really succeeded | 17:46 |
| Sarayan | dave: since you're going to go over everything at least once anyway, isn't it better to flatten? | 17:46 |
| cr1901_modern | If add_library doesn't see any valid .cpp files, it won't add them to the "chipdb-${family}" library | 17:46 |
| whitequark | yeah | 17:46 |
| daveshah | Sarayan: no because of cache | 17:46 |
| Sarayan | I mean more than once, things like bitlists for firmware generation should be used only once | 17:47 |
| whitequark | daveshah: okay, that's ready for review | 17:48 |
| Sarayan | Ok, I'll see if I manage to make generators in the first place :-) | 17:48 |
| *** dys has quit IRC | 17:56 | |
| cr1901_modern | https://github.com/YosysHQ/nextpnr/blob/master/ecp5/resource/chipdb.rc#L5 Introducing the ECP 88K, including a state-of-the-art RISC CPU from Motorola on die :D | 17:58 |
| tpb | Title: nextpnr/chipdb.rc at master · YosysHQ/nextpnr · GitHub (at github.com) | 17:58 |
| whitequark | ouch | 17:58 |
| cr1901_modern | (I have no idea why this didn't break when I was building) | 17:59 |
| whitequark | tnt: I think your icestorm patch breaks nextpnr master... | 18:14 |
| whitequark | --up5k --test fails, and all designs just hang in placement | 18:14 |
| daveshah | This one https://github.com/YosysHQ/icestorm/pull/257/files ? | 18:16 |
| tpb | Title: icebox: Add support for the bit 1 of SHIFTREG_DIV_MODE by smunaut · Pull Request #257 · YosysHQ/icestorm · GitHub (at github.com) | 18:16 |
| whitequark | I think so yeah | 18:17 |
| daveshah | Huh | 18:17 |
| whitequark | the corresponding patch in nextpnr went in 23 days ago | 18:17 |
| whitequark | and it looked ok on today's meeting | 18:17 |
| whitequark | no idea why it breaks | 18:17 |
| daveshah | Me neither | 18:18 |
| daveshah | I will have a look now | 18:18 |
| whitequark | daveshah: huh I think I'm wrong | 18:24 |
| whitequark | it seems to fail integrity check even with that commit reverted | 18:24 |
| daveshah | Hmm, for me integrity check passes and some simple designs seem to work | 18:25 |
| *** jfcaron_ has joined #yosys | 18:26 | |
| whitequark | weird | 18:26 |
| whitequark | ERROR: Assert `usedz.empty()' failed in /home/whitequark/Projects/nextpnr/common/archcheck.cc:112. | 18:26 |
| whitequark | this is how it fails for me | 18:26 |
| daveshah | Maybe this is a determinism issue | 18:27 |
| whitequark | anything I can do to help with this? | 18:27 |
| daveshah | Oh, fails for me for up5k too | 18:27 |
| whitequark | yeah it's up5k specifically | 18:27 |
| daveshah | I don't know if it ever worked, tbh | 18:28 |
| whitequark | hm, u4k broken too | 18:28 |
| whitequark | I'm pretty sure pnr for up5k used to work for me | 18:28 |
| whitequark | with glasgow | 18:28 |
| daveshah | Yeah the pnr may well be a different issue | 18:28 |
| daveshah | Hmm | 18:28 |
| *** kmehall_ has quit IRC | 18:29 | |
| *** kmehall has joined #yosys | 18:29 | |
| tnt | whitequark: huh ... "works for me" ... | 18:30 |
| tnt | I mean I obviously built plenty of up5k bitstream after that patch. | 18:31 |
| whitequark | tnt: yeah it's unrelated to your patch | 18:31 |
| whitequark | sorry for the noise | 18:31 |
| whitequark | just a coincidence | 18:31 |
| daveshah | Can you post the failing json/pcf ? | 18:33 |
| whitequark | picorv32.json from ice40/picorv32..sh | 18:33 |
| daveshah | Yeah that won't work it has too many IOs | 18:34 |
| whitequark | nextpnr-ice40 --up5k --json picorv32.json hangs forever | 18:34 |
| whitequark | oh | 18:34 |
| daveshah | It should timeout eventually | 18:34 |
| whitequark | ok that's uh | 18:34 |
| daveshah | but IO are a special case so maybe I forgot to consider that | 18:34 |
| whitequark | that's kinda silly | 18:34 |
| whitequark | I totally thought it's a bug... | 18:34 |
| daveshah | Hang on, I think it is just the IO placer that's broken | 18:34 |
| daveshah | It doesn't get tested much as 99% of stuff uses constrained pins | 18:34 |
| daveshah | I have worked out what the check issue is too, it is to do with locations with no bel at z=0 | 18:35 |
| whitequark | right | 18:35 |
| daveshah | OK, pushed a fix for the IO issue | 18:43 |
| daveshah | The archcheck fix will be more involved | 18:43 |
| whitequark | fix works, thank you! | 18:44 |
| *** futarisIRCcloud has quit IRC | 18:54 | |
| *** dys has joined #yosys | 19:04 | |
| lambda | well, this is one way of modeling transparency ;) https://github.com/YosysHQ/yosys/blob/master/backends/firrtl/firrtl.cc#L876 | 19:07 |
| tpb | Title: yosys/firrtl.cc at master · YosysHQ/yosys · GitHub (at github.com) | 19:07 |
| whitequark | ouch | 19:11 |
| *** az0re has quit IRC | 19:17 | |
| *** indy has quit IRC | 19:19 | |
| *** kraiskil has quit IRC | 20:06 | |
| *** indy has joined #yosys | 20:09 | |
| *** m4ssi has joined #yosys | 20:32 | |
| *** emeb_mac has joined #yosys | 20:38 | |
| *** kraiskil has joined #yosys | 20:38 | |
| *** jfcaron_ has quit IRC | 20:45 | |
| *** tedx has quit IRC | 20:59 | |
| *** kraiskil has quit IRC | 21:05 | |
| *** jakobwenzel has quit IRC | 21:28 | |
| *** mirage335 has quit IRC | 21:29 | |
| *** mirage335 has joined #yosys | 21:46 | |
| *** m4ssi has quit IRC | 22:33 | |
| *** az0re has joined #yosys | 23:27 | |
| *** Asu has quit IRC | 23:28 | |
| *** emeb has quit IRC | 23:30 | |
| mithro | I just got a nice email from Xilinx -- "The request for the Xilinx Unisim Library to be published as open source has been hosted on GitHub with the Apache 2.0 license here: https://github.com/Xilinx/XilinxUnisimLibrary -- The repo is marked as ‘archived’, but it obviously can be forked for further development by the community. " | 23:53 |
| tpb | Title: GitHub - Xilinx/XilinxUnisimLibrary (at github.com) | 23:53 |
| cr1901_modern | So this is like an inverse-RapidWright? | 23:57 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!