| *** tpb <[email protected]> has joined #yosys | 00:00 | |
| *** gsmecher <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 00:25 | |
| *** kaji <kaji!~kajiryoji@2001:470:69fc:105::405b> has quit IRC (Quit: Reconnecting) | 00:36 | |
| *** kaji <kaji!~kajiryoji@2001:470:69fc:105::405b> has joined #yosys | 00:36 | |
| *** kaji <kaji!~kajiryoji@2001:470:69fc:105::405b> has quit IRC (Client Quit) | 00:36 | |
| *** kaji <kaji!~kajiryoji@2001:470:69fc:105::405b> has joined #yosys | 00:37 | |
| *** GenTooMan <GenTooMan!~cyberman@2601:547:437f:e5c6:21f:5bff:fefe:a883> has quit IRC (Ping timeout: 255 seconds) | 01:20 | |
| *** GenTooMan <GenTooMan!~cyberman@2601:547:437f:e5c6:21f:5bff:fefe:a883> has joined #yosys | 01:21 | |
| *** GenTooMan <GenTooMan!~cyberman@2601:547:437f:e5c6:21f:5bff:fefe:a883> has quit IRC (Ping timeout: 255 seconds) | 01:35 | |
| *** GenTooMan <GenTooMan!~cyberman@2601:547:437f:e5c6:21f:5bff:fefe:a883> has joined #yosys | 01:36 | |
| *** ecs <ecs!ecs@sourcehut/interns/ecs> has joined #yosys | 05:02 | |
| *** FabM <FabM!~FabM@armadeus/team/FabM> has joined #yosys | 05:21 | |
| *** diadatp is now known as diadatp_irccloud | 07:09 | |
| *** diadatp <diadatp!~diadatp@user/diadatp> has joined #yosys | 07:10 | |
| *** diadatp <diadatp!~diadatp@user/diadatp> has quit IRC (Client Quit) | 07:12 | |
| *** diadatp_irccloud <[email protected]> has quit IRC () | 07:12 | |
| *** diadatp <diadatp!uid508601@user/diadatp> has joined #yosys | 07:12 | |
| *** vidbina <[email protected]> has joined #yosys | 09:17 | |
| Sarayan | whitequark: just tried top-of-tree on m68k.v, it's not entirely working but it's close. I'll try to find out what's going on (looks like it's trying to do a memory read, which is good, but never sets as/uds/lds) | 11:13 |
|---|---|---|
| whitequark | oh sweet! | 11:13 |
| whitequark | did you ever get it working before? (is this a regression?) | 11:13 |
| Sarayan | No | 11:13 |
| Sarayan | it's a progression :-) | 11:13 |
| whitequark | try using `write_cxxrtl -nohierarchy` | 11:14 |
| Sarayan | there was the issue with the array of clocks, dunno if the PR has been taken into account (not a PR by me) | 11:14 |
| whitequark | it has been | 11:14 |
| Sarayan | cool | 11:15 |
| Sarayan | compiling lalala | 11:15 |
| Sarayan | (it generates a *big* c++ file :-) | 11:15 |
| whitequark | sure does | 11:15 |
| Sarayan | I'm always amused at having to raise the bracket-depth | 11:16 |
| Sarayan | no visible change | 11:16 |
| whitequark | ah, so not that then | 11:16 |
| whitequark | please let me know what the issue is! | 11:16 |
| Sarayan | yeah, when I find it :-) | 11:17 |
| Sarayan | but I shall | 11:17 |
| *** mewt <[email protected]> has quit IRC (Read error: Connection reset by peer) | 11:18 | |
| Sarayan | funnily enough, a lot more stuff happens when you actually raise (disable) the HALTn pin | 12:13 |
| Sarayan | there's a fair chance the 68k actually works | 12:13 |
| whitequark | oooh | 12:16 |
| Sarayan | I wouldn't have guessed that the halt pin halted on the next memory access | 12:16 |
| Sarayan | and not immediately | 12:16 |
| Sarayan | the 68k does 5 micro-ops at reset before starting to read the vectors | 12:16 |
| Sarayan | ok, not only the 68k is working, but it's executing a stream of nops at roughly 200KHz on my laptop | 12:49 |
| whitequark | is that good? | 12:50 |
| Sarayan | well, you tell me, but for that level of emulation I suspect it is | 12:51 |
| Sarayan | 1/400th of real time for a typical 8MHz 68k | 12:51 |
| Sarayan | 1/40th of real time for a typical 8MHz 68k | 12:51 |
| Sarayan | stop the zero inflation :-) | 12:51 |
| whitequark | seems like there are feedback arcs | 12:52 |
| Sarayan | yeah | 12:52 |
| Sarayan | plan to do a nmigen version at some point. Didn't write that one | 12:52 |
| Sarayan | Just want to be able to bisimulate with a know good low-level core | 12:53 |
| whitequark | run `-p 'hierarchy -auto-top; proc; flatten; splitnets -driver; clean -purge; splitnets -driver; clean -purge' -b cxxrtl` | 12:54 |
| Sarayan | okay | 12:54 |
| * Sarayan adds the black magic | 12:54 | |
| Sarayan | I put that as a yosys command between hierarchy and write_cxxrtl? | 12:55 |
| whitequark | can you show me your current script? | 12:55 |
| Sarayan | oh, I see, it's a series of commands in fact | 12:55 |
| whitequark | I'll adjust it | 12:55 |
| Sarayan | yosys <<EOF | 12:55 |
| Sarayan | read -vlog95 m68k.v | 12:55 |
| Sarayan | hierarchy -top fx68k | 12:55 |
| Sarayan | write_cxxrtl m68k.cc | 12:55 |
| Sarayan | EOF | 12:55 |
| whitequark | that'd be simpler | 12:55 |
| whitequark | https://paste.debian.net/1204568/ | 12:56 |
| tpb | Title: debian Pastezone (at paste.debian.net) | 12:56 |
| Sarayan | compiling | 12:57 |
| Sarayan | crashed... | 12:57 |
| whitequark | hm, crashed? | 12:57 |
| Sarayan | main.cc:79:8: error: no member named 'p_microAddr' in 'cxxrtl_design::p_fx68k' | 12:57 |
| Sarayan | m68k.p_microAddr.get<uint32_t>()); | 12:57 |
| Sarayan | ~~~~ ^ | 12:57 |
| Sarayan | main.cc:105:8: error: invalid argument type 'wire<1>' to unary expression | 12:57 |
| Sarayan | if(!m68k.p_ASn) { | 12:57 |
| Sarayan | ^~~~~~~~~~~ | 12:57 |
| Sarayan | main.cc:123:8: error: value of type 'wire<1>' is not contextually convertible to 'bool' | 12:57 |
| Sarayan | if(m68k.p_ASn) { | 12:57 |
| Sarayan | ^~~~~~~~~~ | 12:57 |
| whitequark | ohh | 12:57 |
| Sarayan | hmmm, miroaddr is debug stuff I read, I can remove it | 12:58 |
| whitequark | and for the others use .get<bool>() | 12:58 |
| Sarayan | running... | 12:59 |
| Sarayan | twice faster, 400KHz | 13:00 |
| whitequark | yep | 13:00 |
| whitequark | should be able to get to 600 KHz at least but this requires some ideas i have in development | 13:00 |
| Sarayan | very nice | 13:00 |
| Sarayan | you want me to package that code for benching? | 13:01 |
| whitequark | sure why not | 13:01 |
| Sarayan | I'll do that | 13:02 |
| whitequark | thank you ^^ | 13:03 |
| *** Max-P5 <Max-P5!~Max-P@thelounge/maintainer/Max-P> has joined #yosys | 13:11 | |
| *** Lord_Nightmare2 <Lord_Nightmare2!Lord_Night@user/lord-nightmare/x-3657113> has joined #yosys | 13:12 | |
| *** lkcl- <[email protected]> has joined #yosys | 13:13 | |
| *** Lord_Nightmare <Lord_Nightmare!Lord_Night@user/lord-nightmare/x-3657113> has quit IRC (*.net *.split) | 13:18 | |
| *** Max-P <Max-P!~Max-P@thelounge/maintainer/Max-P> has quit IRC (*.net *.split) | 13:18 | |
| *** kbeckmann <[email protected]> has quit IRC (*.net *.split) | 13:18 | |
| *** TFKyle <[email protected]> has quit IRC (*.net *.split) | 13:18 | |
| *** lkcl <[email protected]> has quit IRC (*.net *.split) | 13:18 | |
| *** philtor <[email protected]> has quit IRC (*.net *.split) | 13:18 | |
| *** Lord_Nightmare2 is now known as Lord_Nightmare | 13:18 | |
| *** Max-P5 is now known as Max-P | 13:18 | |
| *** TFKyle <[email protected]> has joined #yosys | 13:19 | |
| *** kbeckmann <[email protected]> has joined #yosys | 13:22 | |
| *** philtor <[email protected]> has joined #yosys | 13:26 | |
| Sarayan | whitequark: https://og.kervella.org/fx68k-bench.zip | 13:29 |
| *** vidbina <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 13:30 | |
| whitequark | you can use `-I$(yosys-config --datdir/include)` to make it not dependent on your $HOME | 13:31 |
| whitequark | (not an issue, just something you might find useful) | 13:31 |
| whitequark | and the conventional extension for yosys scripts is `.ys` | 13:31 |
| Sarayan | /usr/local/share/yosys/include | 13:31 |
| Sarayan | nope | 13:31 |
| Sarayan | not picking the correct one | 13:31 |
| whitequark | hmm how'd you install yosys? | 13:31 |
| Sarayan | probably a compile issue, installed with make install PREFIX=/people/galibert | 13:32 |
| Sarayan | I should have used PREFIX at compile? config? time too? | 13:32 |
| *** vidbina <[email protected]> has joined #yosys | 13:34 | |
| whitequark | ~430 kHz here | 13:41 |
| Sarayan | nice | 13:44 |
| whitequark | 2.73 IPC according to `perf stat` | 13:47 |
| Sarayan | not bad | 13:47 |
| Sarayan | not bad at all | 13:47 |
| Sarayan | ok, after recompiling yosys with PREFIX= all the time, --datdir is correct | 13:48 |
| Sarayan | Just fyi fx68k itself is gpl, I've put the exact commit/ref at the start of m68k.v. My code is whatever you need it to be | 13:50 |
| whitequark | for comparison, minerva runs at ~2 MHz and has 2.61 IPC | 13:50 |
| Sarayan | what's minerva? | 13:50 |
| whitequark | https://github.com/lambdaconcept/minerva | 13:51 |
| whitequark | RISC-V CPU | 13:51 |
| Sarayan | ahhhh ok | 13:51 |
| Sarayan | the 68000 has never been designed to be good in a fpga-similar setup :-) | 13:52 |
| whitequark | lemme look at the m68k disassembly | 13:52 |
| whitequark | (yes, i can actually get useful insight from looking at disassembly of C++ templates stacked dozens of levels deep) | 13:53 |
| Sarayan | yeah, but you're special :-P | 13:54 |
| Sarayan | more seriously, I'm not even surprised. The point of the template is to have as little code generated as possible in the first place | 13:54 |
| Sarayan | handholding the compiler in a way | 13:54 |
| whitequark | strangely, no | 13:55 |
| Sarayan | no? | 13:55 |
| whitequark | the way CXXRTL is designed it actually expects the C++ compiler to be very clever | 13:55 |
| Sarayan | It's often to point of my templates, but heh | 13:55 |
| whitequark | like, CXXRTL doesn't really work well without really aggressive loop unrolling and constant propagation | 13:55 |
| Sarayan | ahhh hok I see what you mean | 13:56 |
| Sarayan | I consider that basic, today. It's telling the compiler that "here, that's a constant" that is important | 13:56 |
| Sarayan | we don't have automatic method duplication on various possible values of a variable yet, except for some special cases like memcpy | 13:57 |
| whitequark | yeah, i see what you mean | 13:59 |
| whitequark | that's one way to look at it | 13:59 |
| Sarayan | anyway, *very* *very* happy to have fx68k run under cxxrtl | 14:01 |
| whitequark | the silliest part is that you didn't need to wait since january | 14:02 |
| whitequark | could have just lowered the debug level a bit | 14:02 |
| Sarayan | I wasn't waiting, I was doing a thousand other things :-) | 14:02 |
| whitequark | but no one told you that in the issue, it seems | 14:02 |
| whitequark | ahh okay | 14:02 |
| Sarayan | it's you closing the issue that pushed me into testing | 14:03 |
| Sarayan | in fact you put something back on my todo list, so technically I should hate you ;-) | 14:03 |
| Sarayan | been mapping the m10k tiles on the cyclone v lately, which makes we wonder how one handles specialized blocks like that in nmigen/yosys/nextpnr | 14:05 |
| Sarayan | and in cxxrtl for the matter | 14:05 |
| whitequark | nmigen has Instance, yosys has black boxes, nextpnr knows how to interpret these black boxes | 14:06 |
| whitequark | in cxxrtl you can load the simulation model of the black box | 14:06 |
| Sarayan | nice | 14:07 |
| Sarayan | lots of plumbing on the horizon, but very nice to see all the pieces are there | 14:07 |
| tnt | whitequark: can cxxrtl use the cells_sim.v ? | 14:08 |
| tnt | or do you need to write custom models ? | 14:08 |
| lofty | Sarayan: Yosys handles them as MISTRAL_M10K blocks, which nextpnr would then put in the correct BELs | 14:09 |
| whitequark | tnt: it really depends on the cell | 14:09 |
| whitequark | but generally, yes | 14:09 |
| whitequark | iirc, i've simulated post-synthesis netlists? | 14:09 |
| whitequark | actually let me just do that right now | 14:09 |
| Sarayan | lofty: does yosys correctly handle the quartus verilog constructs for them? | 14:10 |
| lofty | Yes | 14:10 |
| Sarayan | nice | 14:10 |
| lofty | They get inferred from Verilog | 14:10 |
| lofty | The models are...maybe a bit trickier, because the Quartus boxes are hell, but | 14:11 |
| Sarayan | annoyingly, an altsyncram may map to multiple m10k | 14:11 |
| Sarayan | so there probably will need to be some layer of "synthesys" at the yosys level if you want to cope with quartus-acceptable constructs | 14:12 |
| lofty | Fortunately, I won't. | 14:13 |
| lofty | I took a long hard look in the mirror | 14:13 |
| lofty | And genuinely: fuck the Quartus boxes | 14:13 |
| Sarayan | mwahahahaha | 14:13 |
| Sarayan | you should put that on a t-shirt, or a mug | 14:13 |
| cr1901 | Sarayan: Yes, always pass PREFIX to make when building yosys | 14:17 |
| *** mewt <[email protected]> has joined #yosys | 14:18 | |
| *** kristianpaul <kristianpaul!~paul@user/kristianpaul> has quit IRC (Quit: WeeChat 2.3) | 14:38 | |
| *** piegames <[email protected]> has quit IRC (Quit: WeeChat 3.1) | 15:08 | |
| Sarayan | when it runs in 400KHz mode, can I get the internal signals still by calling something specific? | 15:17 |
| whitequark | yes | 15:20 |
| whitequark | you can use the debug info | 15:21 |
| whitequark | do you know how? | 15:21 |
| Sarayan | Not yet | 15:21 |
| Sarayan | (Insert upload sequence and me going I know kung fu.... wrong tape) | 15:22 |
| whitequark | Sarayan: https://tomverbeure.github.io/2020/08/08/CXXRTL-the-New-Yosys-Simulation-Backend.html#design-introspection | 15:24 |
| tpb | Title: CXXRTL, a Yosys Simulation Backend | Electronics etc… (at tomverbeure.github.io) | 15:24 |
| Sarayan | Is -Og implicit at this point? | 15:26 |
| whitequark | it's gone | 15:26 |
| whitequark | you get all the visibility and all the optimization | 15:26 |
| Sarayan | beautiful | 15:26 |
| Sarayan | so I can keep using p_thing for the external interface of the top module, but it's considered a good idea to go through the debug items for what's internal? | 15:28 |
| whitequark | can you keep using p_thing for the ports: yes | 15:28 |
| Sarayan | (I noticed I can get the "uRom microAddr" variable as p_uRom_2e_microAddr) | 15:28 |
| whitequark | you can just use p_uRom_2e_microAddr if you want | 15:29 |
| whitequark | it's purely a matter of your convenience in this case | 15:29 |
| Sarayan | _2e_ is '.' in fact, right? | 15:29 |
| whitequark | other than for ports, CXXRTL does not guarantee that the signals will be exposed as members, and if they do, what name the member will have | 15:29 |
| whitequark | yes | 15:29 |
| Sarayan | microAddr being a port of the uRom submodule that's why it's visible? or it's just pure luck? | 15:30 |
| whitequark | most likely, the net you're looking at has many HDL names | 15:31 |
| whitequark | on many levels of hierarchy, and possibly within a single module, too | 15:31 |
| whitequark | only one of these names ends up as the name of the class member | 15:31 |
| whitequark | and it's kind of arbitrary now | 15:31 |
| Sarayan | cute | 15:31 |
| whitequark | the debug info has all of the names | 15:32 |
| Sarayan | got it grepping the .cc, as one does | 15:32 |
| whitequark | and they alias a single physical wire<> or value<> | 15:32 |
| whitequark | that's what it is: a precise mapping from HDL level names to the physical storage | 15:32 |
| Sarayan | and I get the list through debug_items(items). Surprised you didn't use RVO | 15:35 |
| whitequark | look at the implementation | 15:35 |
| whitequark | consider also that for hierarchical designs (perhaps with blackboxes) you'd have a tree of debug_items functions in the model | 15:36 |
| Sarayan | ok, if you have a tree, ok | 15:36 |
| Sarayan | otherwise it would just have been debug_items items; at the start and return items; at the end | 15:37 |
| Sarayan | I use RVO a lot, it's so natural code-wise | 15:37 |
| whitequark | sure | 15:38 |
| Sarayan | ah, one can't copy debug_item around | 15:39 |
| whitequark | oh, that's unintentional | 15:40 |
| Sarayan | oh cool. it would be nice to make it possible to have global/member ones, which you init at start and use whenever | 15:41 |
| whitequark | it's POD | 15:41 |
| Sarayan | no default constructor though | 15:41 |
| Sarayan | references are POD? | 15:42 |
| whitequark | hm? | 15:42 |
| whitequark | take a look at its definition | 15:42 |
| whitequark | it's a bit weird | 15:42 |
| whitequark | because it inherits all the fields from the struct in the C API, just adds a few methods | 15:42 |
| Sarayan | oh, it's not reference, it's inheritance | 15:43 |
| Sarayan | so the only issue is the lack of default constructor I guess | 15:44 |
| whitequark | well | 15:44 |
| whitequark | it doesn't have a default state | 15:44 |
| whitequark | arguably a design defect, there should've been CXXRTL_INVALID in the type enum or something | 15:44 |
| Sarayan | that means you must have pointers and ensure the lifetime of the items structure you passed debug_items | 15:45 |
| Sarayan | that's unfortunate | 15:45 |
| whitequark | yeah | 15:45 |
| whitequark | you could also cast it to the base class and use that directly | 15:46 |
| whitequark | that's definitely default-constructible | 15:46 |
| Sarayan | cast to a reference to cxxrtl_object before assigning? | 15:47 |
| whitequark | yeah | 15:47 |
| Sarayan | note that if cxxrtl_object is default-constructible debug_item has no reason not to be, since it has no extra fields | 15:48 |
| whitequark | well | 15:48 |
| whitequark | cxxrtl_object cannot not be default-constructible because it's a C struct | 15:48 |
| whitequark | but semantically it still doesn't have a default state | 15:49 |
| Sarayan | but it shouldn't be decause it doesn't have a default state? | 15:49 |
| Sarayan | yeah | 15:49 |
| Sarayan | damned it you do, damned it you don't | 15:49 |
| whitequark | it's an oversight | 15:49 |
| Sarayan | well, knowing you it'll be fixed at some point :-) | 15:49 |
| whitequark | the "right" approach is perhaps to break the ABI and define CXXRTL_INVALID = 0 | 15:49 |
| whitequark | sigh. yes | 15:49 |
| whitequark | you're not wrong | 15:49 |
| *** vidbina <[email protected]> has quit IRC (Ping timeout: 240 seconds) | 15:50 | |
| *** gsmecher <[email protected]> has joined #yosys | 15:50 | |
| Sarayan | no get<> in debug_item? | 15:50 |
| whitequark | debug_item itself doesn't really have anything user-facing added to it | 15:51 |
| whitequark | get<> and set<> would absolutely be handy | 15:51 |
| Sarayan | yeah, if you have a C++ wrapper make it cool :-) | 15:51 |
| whitequark | please file an issue | 15:52 |
| Sarayan | sure | 15:52 |
| *** lexano <lexano!~lexano@2607:fea8:5bc0:12:12c3:7bff:fe95:9fc1> has quit IRC (Remote host closed the connection) | 16:02 | |
| Sarayan | added two issues | 16:04 |
| Sarayan | (default-init and get<>/set<>) | 16:06 |
| Sarayan | yep, managed to read the microAddr through the debug_item, nice | 16:07 |
| *** FabM <FabM!~FabM@armadeus/team/FabM> has quit IRC (Quit: Leaving) | 16:08 | |
| whitequark | \o/ | 16:17 |
| *** Klotz <Klotz!~Klotzoman@gateway/tor-sasl/klotz> has joined #yosys | 16:37 | |
| *** lexano <lexano!~lexano@2607:fea8:5bc0:12:12c3:7bff:fe95:9fc1> has joined #yosys | 16:41 | |
| *** kristianpaul <[email protected]> has joined #yosys | 16:51 | |
| *** Kamilion <Kamilion!~kvirc@user/kamilion> has quit IRC (Ping timeout: 252 seconds) | 17:10 | |
| *** Armleo <[email protected]> has joined #yosys | 17:16 | |
| *** Armleo <[email protected]> has quit IRC (Ping timeout: 246 seconds) | 17:27 | |
| *** Kamilion <Kamilion!~kvirc@user/kamilion> has joined #yosys | 17:55 | |
| *** Klotz <Klotz!~Klotzoman@gateway/tor-sasl/klotz> has quit IRC (Quit: Klotz) | 18:14 | |
| *** vidbina <[email protected]> has joined #yosys | 18:18 | |
| *** kristianpaul <kristianpaul!~paul@user/kristianpaul> has quit IRC (Quit: WeeChat 2.3) | 19:31 | |
| *** kristianpaul <[email protected]> has joined #yosys | 19:36 | |
| *** vidbina <[email protected]> has quit IRC (Ping timeout: 255 seconds) | 20:05 | |
| *** Guest4 <[email protected]> has joined #yosys | 20:15 | |
| *** Guest4 <[email protected]> has quit IRC (Client Quit) | 20:18 | |
| *** RaitoBezarius <RaitoBezarius!~Raito@wireguard/tunneler/raito-bezarius> has joined #yosys | 20:42 | |
| *** Raito_Bezarius <Raito_Bezarius!~Raito@wireguard/tunneler/raito-bezarius> has quit IRC (Ping timeout: 240 seconds) | 20:42 | |
| *** Raito_Bezarius <Raito_Bezarius!~Raito@wireguard/tunneler/raito-bezarius> has joined #yosys | 20:45 | |
| *** RaitoBezarius <RaitoBezarius!~Raito@wireguard/tunneler/raito-bezarius> has quit IRC (Ping timeout: 255 seconds) | 20:47 | |
| *** Raito_Bezarius <Raito_Bezarius!~Raito@wireguard/tunneler/raito-bezarius> has quit IRC (Client Quit) | 20:47 | |
| *** Raito_Bezarius <Raito_Bezarius!~Raito@wireguard/tunneler/raito-bezarius> has joined #yosys | 20:47 | |
| *** gsmecher <[email protected]> has quit IRC (Ping timeout: 268 seconds) | 23:07 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!