Saturday, 2021-04-10

*** Ericounet <Ericounet!~Eric@2a01:e0a:d0:3c20:8961:6ba2:2300:cf41> has left #libre-soc08:42
Chips4Makerslkcl: 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
lkclChips4Makers, cxxrtl has code-paths that are well-tested, and others that aren't10:18
lkcli got all the VHDL to import, and managed to get a "write_verilog ls180_ghdl.v" - it was a million lines.10:19
Chips4Makerslkcl: 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
lkclthe 64-bit multiplier block is 10,000 lines long (as a verilog module)10:25
lkcli'm happy to try ghdl if there's a way to do explicit clock-driving10:26
lkclbear in mind though that ghdl compiled to an absolutely massive 160mb binary10:27
Chips4Makerslkcl: What do you mean with explicit clock-driving ?10:30
lkclthe simulation performing clock driving itself10:34
lkclnot over the VPI interface10:34
lkclmaybe with GHDL it would actually work though10:35
lkclthere is a way to "fix" cocotb to be able to run multiple posix threads10:35
Chips4MakersYes, 'clk <= ~clk after 10 ns;` should do the trick.10:35
lkclremember, i cannot actually write VHDL (i can read it)10:36
lkcland i can just about edit existing VHDL10:36
lkclcreating new VHDL code, i'm about 6-8 months away from being able to do that10:37
lkclcould you drop a (small, complete) clock-driving vhdl program into
Chips4MakersWas it actually verified that GHDL was too slow with clk driven from cocotb ?10:38
lkclGHDL was one that i didn't do yet.10:38
lkclboth verilator and iverilog locked up solid when sys_clk is driven over VPI10:39
Chips4MakersActually 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
Chips4MakersAlso, that the cause is the clock driving is an assumption of mine but not proven.10:44
lkcland that's before expanding out to gate-level10:44
lkclwhich will be at least 100 times slower10:45
Chips4MakersIt's one of the possible differences between how litex uses verilator and cocotb uses verilator.10:45
lkcllitex has a c++ clock-driving module10:46
lkclentirely without the VPI interface enabled.10:46
Chips4MakersAs 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
lkclit's much faster in certain circumstances10:47
lkclah here's a thought10:47
Chips4MakersFor verilator there could also be differences in complie time options for example.10:47
lkcli managed to re-import the GHDL back in as verilog.10:47
lkclit's a million lines long, but it's in verilog10:48
lkclthat means it can be put back into litex10:48
lkclit even pretty much has the exact same ls180 interface10:49
lkclChips4Makers: just compiling the ghdl cocotb now (to see if it works)12:02
Chips4Makerslkcl: 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
lkclChips4Makers, you'll need this:12:26
lkclthat's a new option12:27
lkclit tells to turn things like "dec_OE" into "dec_oueu" so that it doesn't clash with "dec_oe"12:27
lkclyes, otherwise, cmpt_dec_oe_173.vst with an input named "OE" and an output named "oe" that get merged.12:28
lkclarrrgh, the components also have been renamed12:29
lkcli've a little bit of sorting out / debugging there12:30
Chips4Makersclkgen VHDL block:
lkclChips4Makers: star12:43
Chips4MakersThis 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
lkclgot it12:43
lkcl"VPI loaded" message from cocotb-ghdl (that's with blif2vst, not P&R yet)12:43 is still borked, though, i need to sort that out12:44
lkcli'm starting to think that doing much smaller designs (multiple of them, different sections of the chip) would be a more achievable goal, here12:45
Chips4MakersIf you simulate that block alone you also have to specify end time to ghdl as otherwise it will go on forever.12:45
lkclahh ok12:46
lkcli just want to get to the same stage as when we first started: just run the JTAG clock first12:47
Chips4MakersI 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
Chips4MakersIf 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
lkcli'm thinking, "how to catch errors in coriolis2 inserting buffers", modifying the netlist, and doing so in a reasonable amount of time12:51
lkclrather than "this is the only procedure to follow, we refuse to consider doing the full synthesis at all at some point"12:52
lkclit's an application of Demster-Shafer Theory12:52
lkclif you perform multiple (and i mean lots) of smaller tests between multiple components, the probability that the "whole" will work is much higher12:53
lkclactually, Demster-Shafer theory says that you can add the (smaller) probabilities together, but you get the idea12:53
lkcli appreciate that as you go larger layouts, only then will certain features of coriolis2 "kick in"12:54
Chips4MakersAs 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 idea12:54
lkclthe only thing being, coriolis2 might not hit some of the things needed for larger designs12:55
lkcle.g. it may not hit the clock tree buffers code that Jean-Paul added for high-density DFF matrices12:55
Chips4MakersIn 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
lkcli remember you mentioned it12:57
* lkcl getting some lunch12:58
lkcljaezuss, it takes half an hour to complete loading the VPI module13:37
magellanichi, curious what is the status of this project? I saw updates section of the site, last article was Feb 2020.13:48
lkclmagellanic, hi13:53
lkclcurrently focussing on simulation cross-checking for a tape-out deadline in a few days13:54
lkclhell of a lot to get done in a very short remaining amount of time13:54
lkclhence why the status page hasn't been updated: someone has to spend the time doing that13:55
lkclit's one of those things :)13:55
magellanicunderstand, 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
lkclmagellanic, no problem.  basically we have a functional core with integer that's directly equivalent to microwatt14:02
lkcl(including being able to run the exact same unit tests, except for the MMU one)14:02
lkcland the SVP64 Vectorisation support is being slowly added to both the python-based simulator and the very-basic-test-core14:03
lkcljn__: no, i haven't had time14:03
magellanicah 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-soc14:04
lkclbecause each of the three people working in their respective areas is not getting enough help to do anything other than their tasks14:04
lkclmagellanic, nice.14:04
lkclafter the tape-out deadline we'll be able to focus on getting the RADIX MMU operational14:04
lkclthat has to be implemented in the python OpenPOWER simulator we're doing, first14:05
lkclat that point it'll be capable of running GNU/Linux OSes14:05
lkclbooting the exact same kernels as microwatt14:05
magellanicthe site mentioned one can get a stipend for helping, is that still the case?14:07
magellanicI can do python, but nothing else mentioned in the toolset on the site. I'd have to learn some14:08
lkclmagellanic, yes definitely14:08
magellanicnot 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 first14:09
lkclwell the simulator's entirely written in python14:09
lkcland strictly speaking doesn't need nmigen14:09
lkclalthough that's not entirely true: the PowerDecoder2 is used by the python-based simulator14:10
lkclbut its sole job is to decode the instruction, so is just "a one liner black box" to the simulator14:10
lkclhere's the implementation of the RADIX MMU that we're putting together:14:12
magellaniccool, going to try learn and get on my feet first. I'm starting from zero, with almost no hardware know how14:12
lkclthat's why i suggested a non-hardware-related task - a python-based simulator of OpenPOWER that has nothing to do with hardware14:13
lkclthere's about... four other implementations of RADIXMMU that we've been able to find14:13
magellanicah ok, checking the link14:13
lkclthree :)14:13
lkclwe've automated scripts for getting the dev-environment installed btw14:15
lkclso it's a one-or-two-liner not "several hundred lines"14:15
lkclamongst those, as a sysadmin, you'll likely appreciate this one:14:16
lkclthat's a general-purpose script for establishing a debian chroot14:17
lkcland automatically setting it up with schroot14:17
magellanicwill have a look thanks14:18
* lkcl is not a fan of dockkaaah :)14:18
lkcli can't believe they don't have proper version control in the config files.  utterly stupid14:18
lkcland 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 that14:19
lkclChips4Makers: unnnbelievable.  the cocotb-ghdl test (the very basic one) actually ran and passed14:26
lkclthat's after, not the full P&R14:26
lkclit takes half a frickin hour to load / start-up14:43
lkclChips4Makers: ah.  i think i know what it is.  it's likely the recursive discovery of the interface names14:55
lkcloh wait - nope.  the early version didn't use "wrap" technique14:55
lkclChips4Makers: unnnbelievable.  wishbone unit test works (up to the point where i made a mistake in the test)16:28
cesar[m]1Just implemented 1<<r3 mode on TestIssuer. Integer predication is now complete.21:57
cesar[m]1Now, to CR predication. Should be fun...21:58

Generated by 2.17.1 by Marius Gedminas - find it at!