| *** Ericounet <Ericounet!~Eric@2a01:e0a:d0:3c20:8961:6ba2:2300:cf41> has left #libre-soc | 08:42 | |
| Chips4Makers | lkcl: It seems that the FreePDK45 VHDL model is OK as behavioural model but because the ghdl yosys plugin uses the synthesis option of GHDL it stumbles on unimplemented feature. Using the Verilog model will likely work for cxxrtl. | 08:51 |
|---|---|---|
| lkcl | Chips4Makers, cxxrtl has code-paths that are well-tested, and others that aren't | 10:18 |
| lkcl | https://bugs.libre-soc.org/show_bug.cgi?id=622 | 10:18 |
| lkcl | i got all the VHDL to import, and managed to get a "write_verilog ls180_ghdl.v" - it was a million lines. | 10:19 |
| Chips4Makers | lkcl: I am wondering if the cxxrtl route is the right approach for the tape-out simulation. I got the feeling we were close for post-layout with cocotb + ghdl and I think ghdl is much more stable code, especially the simulation part. | 10:22 |
| lkcl | the 64-bit multiplier block is 10,000 lines long (as a verilog module) | 10:25 |
| lkcl | i'm happy to try ghdl if there's a way to do explicit clock-driving | 10:26 |
| lkcl | bear in mind though that ghdl compiled to an absolutely massive 160mb binary | 10:27 |
| Chips4Makers | lkcl: What do you mean with explicit clock-driving ? | 10:30 |
| lkcl | the simulation performing clock driving itself | 10:34 |
| lkcl | not over the VPI interface | 10:34 |
| lkcl | maybe with GHDL it would actually work though | 10:35 |
| lkcl | there is a way to "fix" cocotb to be able to run multiple posix threads | 10:35 |
| Chips4Makers | Yes, 'clk <= ~clk after 10 ns;` should do the trick. | 10:35 |
| lkcl | remember, i cannot actually write VHDL (i can read it) | 10:36 |
| lkcl | and i can just about edit existing VHDL | 10:36 |
| lkcl | creating new VHDL code, i'm about 6-8 months away from being able to do that | 10:37 |
| lkcl | could you drop a (small, complete) clock-driving vhdl program into https://bugs.libre-soc.org/show_bug.cgi?id=620 | 10:38 |
| Chips4Makers | Was it actually verified that GHDL was too slow with clk driven from cocotb ? | 10:38 |
| lkcl | GHDL was one that i didn't do yet. | 10:38 |
| lkcl | both verilator and iverilog locked up solid when sys_clk is driven over VPI | 10:39 |
| Chips4Makers | Actually they are likely not locked, I did test with iverilog and the IDCODE test was not half through after 12 hours but it did progress but very slow. | 10:41 |
| lkcl | dang | 10:43 |
| Chips4Makers | Also, that the cause is the clock driving is an assumption of mine but not proven. | 10:44 |
| lkcl | and that's before expanding out to gate-level | 10:44 |
| lkcl | which will be at least 100 times slower | 10:45 |
| Chips4Makers | It's one of the possible differences between how litex uses verilator and cocotb uses verilator. | 10:45 |
| lkcl | litex has a c++ clock-driving module | 10:46 |
| lkcl | entirely without the VPI interface enabled. | 10:46 |
| Chips4Makers | As cxxrtl is also not optimized for ultimate speed you may also have problem with that on a full core. I think whitequark says it's still an order of magnitude slower than verilator. | 10:47 |
| lkcl | it's much faster in certain circumstances | 10:47 |
| lkcl | ah here's a thought | 10:47 |
| Chips4Makers | For verilator there could also be differences in complie time options for example. | 10:47 |
| lkcl | i managed to re-import the GHDL back in as verilog. | 10:47 |
| lkcl | it's a million lines long, but it's in verilog | 10:48 |
| lkcl | that means it can be put back into litex | 10:48 |
| lkcl | it even pretty much has the exact same ls180 interface | 10:49 |
| lkcl | Chips4Makers: just compiling the ghdl cocotb now (to see if it works) | 12:02 |
| Chips4Makers | lkcl: I got synthesis working on ls180 with FreePDK45 standard cells. This is the version without SRAM blocks. Now need to work on 'make lvx'. | 12:14 |
| lkcl | fantastic! | 12:25 |
| lkcl | Chips4Makers, you'll need this: | 12:26 |
| lkcl | https://git.libre-soc.org/?p=soclayout.git;a=commitdiff;h=f5f14901d41eda67b634e6d55b96200bf1cfb186 | 12:26 |
| lkcl | that's a new option | 12:27 |
| lkcl | it tells blif2vst.py to turn things like "dec_OE" into "dec_oueu" so that it doesn't clash with "dec_oe" | 12:27 |
| lkcl | yes, otherwise, cmpt_dec_oe_173.vst with an input named "OE" and an output named "oe" that get merged. | 12:28 |
| lkcl | (argh) | 12:28 |
| lkcl | arrrgh, the components also have been renamed | 12:29 |
| lkcl | i've a little bit of sorting out / debugging there | 12:30 |
| Chips4Makers | clkgen VHDL block: https://bugs.libre-soc.org/show_bug.cgi?id=620#c15 | 12:39 |
| lkcl | Chips4Makers: star | 12:43 |
| Chips4Makers | This is only for use in ghdl itself, it is not synthesizable so won't be able to go into yosys through the ghdl plugin. | 12:43 |
| lkcl | got it | 12:43 |
| lkcl | "VPI loaded" message from cocotb-ghdl (that's with blif2vst, not P&R yet) | 12:43 |
| lkcl | blif2vst.py is still borked, though, i need to sort that out | 12:44 |
| lkcl | i'm starting to think that doing much smaller designs (multiple of them, different sections of the chip) would be a more achievable goal, here | 12:45 |
| Chips4Makers | If you simulate that block alone you also have to specify end time to ghdl as otherwise it will go on forever. | 12:45 |
| lkcl | ahh ok | 12:46 |
| lkcl | i just want to get to the same stage as when we first started: just run the JTAG clock first | 12:47 |
| Chips4Makers | I disagree with separate subblocks. It always gives extra inefficiencies in synthesis and P&R, it also too late for current tape-out and after tape-out IMO we should focus on getting the post-layout simulation up to speed. Remember we are only signle core 180nm ATM and you are dreaming of multi-core 22nm designs... | 12:48 |
| Chips4Makers | If you want to go multi-core with cores being to be run on different clock speeds/voltage you will need to be able to do post-layout simulation on the full block to see if there are no cross clock domain timing problems. | 12:50 |
| lkcl | i'm thinking, "how to catch errors in coriolis2 inserting buffers", modifying the netlist, and doing so in a reasonable amount of time | 12:51 |
| lkcl | rather than "this is the only procedure to follow, we refuse to consider doing the full synthesis at all at some point" | 12:52 |
| lkcl | it's an application of Demster-Shafer Theory | 12:52 |
| lkcl | if you perform multiple (and i mean lots) of smaller tests between multiple components, the probability that the "whole" will work is much higher | 12:53 |
| lkcl | actually, Demster-Shafer theory says that you can add the (smaller) probabilities together, but you get the idea | 12:53 |
| lkcl | i appreciate that as you go larger layouts, only then will certain features of coriolis2 "kick in" | 12:54 |
| Chips4Makers | As last resort, one could assume that if it shows no bugs on arlet 6502 core, it also would work on libresoc; cross fingers of course. | 12:54 |
| lkcl | ... yeah, that's the general kind of idea | 12:54 |
| lkcl | the only thing being, coriolis2 might not hit some of the things needed for larger designs | 12:55 |
| lkcl | e.g. it may not hit the clock tree buffers code that Jean-Paul added for high-density DFF matrices | 12:55 |
| Chips4Makers | In commercial tools the pre-/post-layout verification is done using so-called LEC, logic equivalence check. This is similar to using formal to proof that both design are the same. | 12:57 |
| lkcl | i remember you mentioned it | 12:57 |
| * lkcl getting some lunch | 12:58 | |
| lkcl | jaezuss, it takes half an hour to complete loading the VPI module | 13:37 |
| magellanic | hi, curious what is the status of this project? I saw updates section of the site, last article was Feb 2020. | 13:48 |
| lkcl | magellanic, hi | 13:53 |
| lkcl | currently focussing on simulation cross-checking for a tape-out deadline in a few days | 13:54 |
| lkcl | http://lists.libre-soc.org/pipermail/libre-soc-dev/2021-April/002321.html | 13:54 |
| lkcl | hell of a lot to get done in a very short remaining amount of time | 13:54 |
| lkcl | hence why the status page hasn't been updated: someone has to spend the time doing that | 13:55 |
| lkcl | it's one of those things :) | 13:55 |
| magellanic | understand, will check the link. won't trouble you too much with that deadline :) | 13:56 |
| jn__ | is there a page (or email, etc.) about the 180nm tapeout? | 13:57 |
| lkcl | magellanic, no problem. basically we have a functional core with integer that's directly equivalent to microwatt | 14:02 |
| lkcl | (including being able to run the exact same unit tests, except for the MMU one) | 14:02 |
| lkcl | and the SVP64 Vectorisation support is being slowly added to both the python-based simulator and the very-basic-test-core | 14:03 |
| lkcl | https://libre-soc.org/openpower/sv/implementation/ | 14:03 |
| lkcl | jn__: no, i haven't had time | 14:03 |
| jn__ | ok | 14:04 |
| magellanic | ah ok thanks. I'm a sysadmin stumbled upon this proj thought it was interesting. I know near nothing about hardware, but keen to see a libre-soc | 14:04 |
| lkcl | because each of the three people working in their respective areas is not getting enough help to do anything other than their tasks | 14:04 |
| lkcl | magellanic, nice. | 14:04 |
| lkcl | after the tape-out deadline we'll be able to focus on getting the RADIX MMU operational | 14:04 |
| lkcl | that has to be implemented in the python OpenPOWER simulator we're doing, first | 14:05 |
| lkcl | at that point it'll be capable of running GNU/Linux OSes | 14:05 |
| lkcl | booting the exact same kernels as microwatt | 14:05 |
| magellanic | the site mentioned one can get a stipend for helping, is that still the case? | 14:07 |
| magellanic | I can do python, but nothing else mentioned in the toolset on the site. I'd have to learn some | 14:08 |
| lkcl | magellanic, yes definitely | 14:08 |
| magellanic | not sure I can do hardware stuff though, I might have a peek and then leave :p I'm gonna look to go through nmigen docs to learn that first | 14:09 |
| lkcl | well the simulator's entirely written in python | 14:09 |
| lkcl | and strictly speaking doesn't need nmigen | 14:09 |
| lkcl | although that's not entirely true: the PowerDecoder2 is used by the python-based simulator | 14:10 |
| lkcl | but its sole job is to decode the instruction, so is just "a one liner black box" to the simulator | 14:10 |
| lkcl | https://bugs.libre-soc.org/show_bug.cgi?id=604 | 14:10 |
| lkcl | here's the implementation of the RADIX MMU that we're putting together: | 14:12 |
| lkcl | https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/decoder/isa/radixmmu.py;hb=HEAD | 14:12 |
| magellanic | cool, going to try learn and get on my feet first. I'm starting from zero, with almost no hardware know how | 14:12 |
| lkcl | that's why i suggested a non-hardware-related task - a python-based simulator of OpenPOWER that has nothing to do with hardware | 14:13 |
| lkcl | there's about... four other implementations of RADIXMMU that we've been able to find | 14:13 |
| lkcl | qemu | 14:13 |
| lkcl | power-gem5 | 14:13 |
| lkcl | microwatt | 14:13 |
| magellanic | ah ok, checking the link | 14:13 |
| lkcl | three :) | 14:13 |
| lkcl | we've automated scripts for getting the dev-environment installed btw | 14:15 |
| lkcl | so it's a one-or-two-liner not "several hundred lines" | 14:15 |
| lkcl | https://git.libre-soc.org/?p=dev-env-setup.git;a=tree | 14:16 |
| lkcl | amongst those, as a sysadmin, you'll likely appreciate this one: | 14:16 |
| lkcl | https://git.libre-soc.org/?p=dev-env-setup.git;a=blob;f=mk-deb-chroot;hb=HEAD | 14:16 |
| lkcl | that's a general-purpose script for establishing a debian chroot | 14:17 |
| lkcl | and automatically setting it up with schroot | 14:17 |
| magellanic | will have a look thanks | 14:18 |
| * lkcl is not a fan of dockkaaah :) | 14:18 | |
| lkcl | i can't believe they don't have proper version control in the config files. utterly stupid | 14:18 |
| lkcl | and they break backwards compatibility. insane and terribly fragile. | 14:19 |
| * lkcl had a bitch of a job getting kubernetes up and running last year because of that | 14:19 | |
| lkcl | Chips4Makers: unnnbelievable. the cocotb-ghdl test (the very basic one) actually ran and passed | 14:26 |
| lkcl | that's after blif2vst.py, not the full P&R | 14:26 |
| Chips4Makers | Cheers! | 14:31 |
| lkcl | :) | 14:35 |
| lkcl | it takes half a frickin hour to load / start-up | 14:43 |
| lkcl | Chips4Makers: ah. i think i know what it is. it's likely the recursive discovery of the interface names | 14:55 |
| lkcl | oh wait - nope. the early version didn't use "wrap" technique | 14:55 |
| lkcl | Chips4Makers: unnnbelievable. wishbone unit test works (up to the point where i made a mistake in the test) | 16:28 |
| cesar[m]1 | Just implemented 1<<r3 mode on TestIssuer. Integer predication is now complete. | 21:57 |
| cesar[m]1 | Now, to CR predication. Should be fun... | 21:58 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!