| Las[m] | lkcl: In the libresoc-litex repository, ls180soc.py 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 |
|---|---|---|
| lkcl | Las[m], it comes from litex. | 12:30 |
| Las[m] | Ah, I can't see where that is installed either lkcl | 12:31 |
| lkcl | which is a whole bundle-of-fun to install, having appx.... 30-40 components, it has its own installer | 12:31 |
| Las[m] | lol | 12:31 |
| lkcl | you install litex by following litex's install instructions | 12:31 |
| Las[m] | Sounds like fun | 12:31 |
| lkcl | yes. | 12:31 |
| lkcl | i did a manual process, one by one | 12:31 |
| Las[m] | I thought there was some Migen-nMigen compatibility layer | 12:32 |
| Las[m] | Couldn't you use that? | 12:32 |
| lkcl | i'd recommend just following their install procedure | 12:32 |
| lkcl | don't even remotely think about it :) | 12:32 |
| Las[m] | Is it not usable? | 12:32 |
| lkcl | it may have been, 18-24 months ago | 12: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 |
| lkcl | Las[m], i didn't actually create a fork. | 16:54 |
| lkcl | i took carbon copies of some peripherals and updated them to be suitable for use in ASICs | 16:54 |
| Las[m] | So it's just an old commit then? | 16:54 |
| lkcl | i used an older version of litex, if that's what you mean | 16:55 |
| Las[m] | I mean https://git.libre-soc.org/?p=litex.git BW | 16:55 |
| Las[m] | It is, thanks | 16:55 |
| Las[m] | I think you've forked nmigen? It doesn't build with the upstream nmigen after all. | 16:56 |
| lkcl | ah yes right, yes - litex is a constantly-moving-target | 16:56 |
| lkcl | so for stability reasons i took a snapshot and worked against that | 16:56 |
| lkcl | i remember you asked a week-or-so ago what files are copied over | 16:56 |
| lkcl | i answered then with the location of the instructions | 16:57 |
| Las[m] | Great to know, thanks! | 16:57 |
| Las[m] | Ah, really? | 16:57 |
| Las[m] | I'll look through the logs | 16:57 |
| lkcl | again, there's a tag for the version of nmigen that i stuck with, due, again, to nmigen being a moving target | 16:57 |
| lkcl | given how little help i was getting those tags date back some considerable time | 16:58 |
| lkcl | plus, to create a stable ASIC you never arbitrarily move dependencies, it causes too much aggravation | 16:58 |
| lkcl | you 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 again | 16:59 |
| lkcl | i'm trying to find where i wrote about running "make ls1804k" | 17:01 |
| lkcl | https://git.libre-soc.org/?p=libresoc-litex.git;a=blob;f=Makefile;hb=HEAD | 17:01 |
| lkcl | use the *verilog* files - not the ILANG files. | 17:02 |
| lkcl | so after running "make ls1804k", copy the *verilog* files over | 17:02 |
| lkcl | but, 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:31 | 17:04 |
| lkcl | /-------------------------------------------------------------------------------- | 17:04 |
| lkcl | module ls180( | 17:04 |
| lkcl | input wire [15:0] gpio_i, | 17:04 |
| lkcl | output reg [15:0] gpio_o, | 17:04 |
| lkcl | that one looks like i've already hand-edited it (from "module ls1804k") | 17:05 |
| lkcl | i didn't automate this because it's copying over to a chroot. | 17:05 |
| lkcl | the files go into the non_generated directory. | 17:12 |
| lkcl | match them up by inspecting each | 17:12 |
| lkcl | look at build_full_4ksram_recon.sh | 17:14 |
| lkcl | cp non_generated/full_core_4_4ksram_ls180.v ls180.v | 17:14 |
| lkcl | cp non_generated/full_core_4_4ksram_litex_ls180_recon.v litex_ls180.v | 17:14 |
| lkcl | cp non_generated/full_core_4_4ksram_libresoc_recon.v libresoc.v | 17:14 |
| lkcl | therefore, you want ls180.v to be copied to litex_ls180.v | 17:14 |
| lkcl | sorry | 17:14 |
| lkcl | ls180.v to be copied to non_generated/full_core_4_4ksram_litex_ls180_recon.v | 17:14 |
| lkcl | and libresoc.v to be copied to non_generated/full_core_4_4ksram_libresoc_recon.v | 17:15 |
| lkcl | such that | 17:15 |
| lkcl | *when* you run the build_full_4ksram_recon.sh script | 17:15 |
| lkcl | you *end up* with the two files in their original names | 17:15 |
| lkcl | but | 17:15 |
| lkcl | do inspect the contents of non_generated/full_core_4_4ksram_ls180.v | 17:15 |
| lkcl | you will see it says | 17:15 |
| lkcl | `include litex_ls180.v | 17:16 |
| lkcl | `include libresoc.v | 17:16 |
| lkcl | it should be obvious why that is and what it does | 17:16 |
| Las[m] | Thanks! | 17:20 |
| 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 libresoc_cvt.il'` is done | 17:21 |
| lkcl | correct | 17:25 |
| lkcl | remember: i explained that yosys is broken | 17:25 |
| lkcl | conversion multiple times from ilang to verilog to ilang destroys important information | 17:25 |
| Las[m] | Yeah I remember that, I just don't understand why it's still there then | 17:26 |
| lkcl | don't know, don't care! | 17:26 |
| lkcl | the "solution" - use verilog. | 17:26 |
| lkcl | no point worrying about it when there's a workaround, and you're under massive time-pressure | 17:26 |
| lkcl | we had a massive discussion about it, there's a bugreport somewhere | 17:28 |
| lkcl | tried a number of different things | 17:29 |
| lkcl | it's a known problem related to how yosys handles SRAMs and memory cells in general | 17:29 |
| kylel | Holds head in shame with another yield issue. Seems unit tests are blown off with use of yield from. | 17:51 |
| lkcl | kylel, loovely :) | 19:35 |
| lkcl | do you mean, they're not properly run? | 19:35 |
| lkcl | let me test that by actually breaking one of the unit tests :) | 19:35 |
| * lkcl picks a victim muhahaah | 19:36 | |
| lkcl | hmm how am i going to do this... | 19:37 |
| lkcl | i actually need to break *ISACaller* to get it to create the wrong answer | 19:37 |
| lkcl | or mod the HDL | 19:38 |
| * lkcl chooses ISACaller | 19:38 | |
| lkcl | kylel, nope, that definitely "works" | 19:39 |
| lkcl | if i "break" e.g. fixedarith.py subf by making it return ~RA+RB-1 | 19:39 |
| lkcl | it definitely gets spotted by the (new) test infrastructure, the new version of check_regs | 19:39 |
| lkcl | so what's the issue you're encountering? | 19:40 |
| kylel | was looking to use new state module, with an expected vs simulated in say shift_rot_caller | 19:42 |
| lkcl | ok | 19:43 |
| lkcl | then remember, you need to make them look like "fake" yielders | 19:43 |
| lkcl | use that trick "if False: yield" | 19:43 |
| kylel | yeah I remember | 19:43 |
| lkcl | just like in the... the... SimState | 19:43 |
| lkcl | except here, those functions wouldn't actually do anything | 19:44 |
| lkcl | they'd literally be: | 19:44 |
| lkcl | def get_int_regs(self): if False: yield | 19:44 |
| kylel | right... | 19:45 |
| kylel | problem is when I use a yield from inside the unit test, it will just totally ignore the test | 19:45 |
| kylel | maybe (probably) missing something from that angle | 19:45 |
| lkcl | ehhhmmmm.... | 19:45 |
| lkcl | can you do a "diff -u" (and attach to the bugreport) or commit to a branch, so i can take a look? | 19:46 |
| lkcl | i'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 |
| lkcl | i mean, if you *really want* to... :) | 19:47 |
| kylel | heh, i hate to admit defeat sometimes. | 19:47 |
| kylel | i'll commit something up in a little bit | 19:49 |
| kylel | ok, state and test_caller_shift_rot pushed | 20:44 |
| lkcl | right, yep, you can't yield from an instance | 21:01 |
| lkcl | it's just "e = ExpectedState()" | 21:01 |
| lkcl | or, what i was actually expecting would be | 21:01 |
| lkcl | e = ExpectedState(int_regs=[list, of, expected, values]) | 21:02 |
| lkcl | where the *constructor* then drops those directly into self.int_regs | 21:02 |
| lkcl | initialises self.pc from its (corresponding, optional) argument | 21:02 |
| lkcl | etc. | 21:02 |
| lkcl | etc. | 21:03 |
| lkcl | etc. | 21:03 |
| lkcl | and self.get_intregs() (etc) are _literally_ a one-liner "if False: yield" | 21:03 |
| lkcl | as a way to get them to do absolutely nothing at all but still be part of the API | 21:03 |
| lkcl | like i said on the bugreport: _brutally_ simple. | 21:03 |
| kylel | ah, ok, makes sense, thanks. Yeah I was getting there to use the constructor. overthought it on that one thinking to be congruent with the api | 21:24 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!