Wednesday, 2021-09-15

Las[m]lkcl: In the libresoc-litex repository, uses the migen module, but where does this come from? I took a look at the dev env scripts, and it doesn't seem like Migen is installed anywhere.11:39
lkclLas[m], it comes from litex.12:30
Las[m]Ah, I can't see where that is installed either lkcl12:31
lkclwhich is a whole bundle-of-fun to install, having appx.... 30-40 components, it has its own installer12:31
lkclyou install litex by following litex's install instructions12:31
Las[m]Sounds like fun12:31
lkcli did a manual process, one by one12:31
Las[m]I thought there was some Migen-nMigen compatibility layer12:32
Las[m]Couldn't you use that?12:32
lkcli'd recommend just following their install procedure12:32
lkcldon't even remotely think about it :)12:32
Las[m]Is it not usable?12:32
lkclit may have been, 18-24 months ago12:32
Las[m]lkcl: How is your fork of litex different from upstream?15:53
Las[m]Also, once I've run `make` in the `libresoc-litex` repository, what files should I copy over to `experiments9`?16:26
Las[m]If I were to integrate the code for building the GDS-II files on the soc repository, should experiments9 be the template? Or are the higher numbered experiments better?16:53
lkclLas[m], i didn't actually create a fork.16:54
lkcli took carbon copies of some peripherals and updated them to be suitable for use in ASICs16:54
Las[m]So it's just an old commit then?16:54
lkcli used an older version of litex, if that's what you mean16:55
Las[m]I mean BW16:55
Las[m]It is, thanks16:55
Las[m]I think you've forked nmigen? It doesn't build with the upstream nmigen after all.16:56
lkclah yes right, yes - litex is a constantly-moving-target16:56
lkclso for stability reasons i took a snapshot and worked against that16:56
lkcli remember you asked a week-or-so ago what files are copied over16:56
lkcli answered then with the location of the instructions16:57
Las[m]Great to know, thanks!16:57
Las[m]Ah, really?16:57
Las[m]I'll look through the logs16:57
lkclagain, there's a tag for the version of nmigen that i stuck with, due, again, to nmigen being a moving target16:57
lkclgiven how little help i was getting those tags date back some considerable time16:58
lkclplus, to create a stable ASIC you never arbitrarily move dependencies, it causes too much aggravation16:58
lkclyou literally end up changing the HDL by changing the tool, and all the "review" and testing done up until that point is completely invalidated and has to start again16:59
lkcli'm trying to find where i wrote about running "make ls1804k"17:01
lkcluse the *verilog* files - not the ILANG files.17:02
lkclso after running "make ls1804k", copy the *verilog* files over17:02
lkclbut, as Staf mention, you have to hand-edit the ls180.v top module from the name "ls1804k" to just "ls180"17:02
lkcl/ Auto-generated by Migen (7bc4eb1) & LiteX (35929c0f) on 2021-03-12 13:46:3117:04
lkclmodule ls180(17:04
lkcl    input wire [15:0] gpio_i,17:04
lkcl    output reg [15:0] gpio_o,17:04
lkclthat one looks like i've already hand-edited it (from "module ls1804k")17:05
lkcli didn't automate this because it's copying over to a chroot.17:05
lkclthe files go into the non_generated directory.17:12
lkclmatch them up by inspecting each17:12
lkcllook at build_full_4ksram_recon.sh17:14
lkclcp non_generated/full_core_4_4ksram_ls180.v ls180.v17:14
lkclcp non_generated/full_core_4_4ksram_litex_ls180_recon.v litex_ls180.v17:14
lkclcp non_generated/full_core_4_4ksram_libresoc_recon.v libresoc.v17:14
lkcltherefore, you want ls180.v to be copied to litex_ls180.v17:14
lkclls180.v to be copied to non_generated/full_core_4_4ksram_litex_ls180_recon.v17:14
lkcland libresoc.v to be copied to non_generated/full_core_4_4ksram_libresoc_recon.v17:15
lkclsuch that17:15
lkcl*when* you run the script17:15
lkclyou *end up* with the two files in their original names17:15
lkcldo inspect the contents of non_generated/full_core_4_4ksram_ls180.v17:15
lkclyou will see it says17:15
lkcl`include litex_ls180.v17:16
lkcl`include libresoc.v17:16
lkclit should be obvious why that is and what it does17:16
Las[m]So that ilang files generated are not used at all then?17:21
Las[m]e.g. `yosys -p 'read_verilog libresoc.v' -p 'write_ilang'` is done17:21
lkclremember: i explained that yosys is broken17:25
lkclconversion multiple times from ilang to verilog to ilang destroys important information17:25
Las[m]Yeah I remember that, I just don't understand why it's still there then17:26
lkcldon't know, don't care!17:26
lkclthe "solution" - use verilog.17:26
lkclno point worrying about it when there's a workaround, and you're under massive time-pressure17:26
lkclwe had a massive discussion about it, there's a bugreport somewhere17:28
lkcltried a number of different things17:29
lkclit's a known problem related to how yosys handles SRAMs and memory cells in general17:29
kylelHolds head in shame with another yield issue.  Seems unit tests are blown off with use of yield from.17:51
lkclkylel, loovely :)19:35
lkcldo you mean, they're not properly run?19:35
lkcllet me test that by actually breaking one of the unit tests :)19:35
* lkcl picks a victim muhahaah19:36
lkclhmm how am i going to do this...19:37
lkcli actually need to break *ISACaller* to get it to create the wrong answer19:37
lkclor mod the HDL19:38
* lkcl chooses ISACaller19:38
lkclkylel, nope, that definitely "works"19:39
lkclif i "break" e.g. subf by making it return ~RA+RB-119:39
lkclit definitely gets spotted by the (new) test infrastructure, the new version of check_regs19:39
lkclso what's the issue you're encountering?19:40
kylelwas looking to use new state module, with an expected vs simulated in say shift_rot_caller19:42
lkclthen remember, you need to make them look like "fake" yielders19:43
lkcluse that trick "if False: yield"19:43
kylelyeah I remember19:43
lkcljust like in the... the... SimState19:43
lkclexcept here, those functions wouldn't actually do anything19:44
lkclthey'd literally be:19:44
lkcl    def get_int_regs(self): if False: yield19:44
kylelproblem is when I use a yield from inside the unit test, it will just totally ignore the test19:45
kylelmaybe (probably) missing something from that angle19:45
lkclcan you do a "diff -u" (and attach to the bugreport) or commit to a branch, so i can take a look?19:46
lkcli'll likely spot it straight away and there's not a huuge amount of point banging your head against a brick wall just for the sake of it :)19:46
lkcli mean, if you *really want* to... :)19:47
kylelheh, i hate to admit defeat sometimes.19:47
kyleli'll commit something up in a little bit19:49
kylelok, state and test_caller_shift_rot pushed20:44
lkclright, yep, you can't yield from an instance21:01
lkclit's just "e = ExpectedState()"21:01
lkclor, what i was actually expecting would be21:01
lkcle = ExpectedState(int_regs=[list, of, expected, values])21:02
lkclwhere the *constructor* then drops those directly into self.int_regs21:02
lkclinitialises self.pc from its (corresponding, optional) argument21:02
lkcland self.get_intregs() (etc) are _literally_ a one-liner "if False: yield"21:03
lkclas a way to get them to do absolutely nothing at all but still be part of the API21:03
lkcllike i said on the bugreport: _brutally_ simple.21:03
kylelah, ok, makes sense, thanks.  Yeah I was getting there to use the constructor.  overthought it on that one thinking to be congruent with the api21:24

Generated by 2.17.1 by Marius Gedminas - find it at!