Friday, 2021-04-02

Chips4Makerslkcl: I don't mind reorganising repos but I would like proper authorship to be maintainded if you do. You should at least use the co-authored-by: tag when commiting code contributed to by somebody else; ideally 'git commit --author'09:25
Chips4MakersI also disagree with duplicating the cocotb and idcode.svf testbench files. There should only be one copy used for both pre- and post-layout simulation.09:25
Chips4MakersThe problem seems to be that the top cell used for synthesis is not right. The top cell used for synthesis should have exactly the same pins as the corona cell after P&R. Optimization during synthesis will only look at the top cell. Any logic that is not needed to generate the outputs or inouts of the top cells may be removed during optimization. This may explain why you had so much problems of disappearing signals during09:43
Chips4MakersSo the pre-layout testbench should be on the top cell used for synthesis and because it will have the same pins the test bench can be reused.09:45
cesar[m]1lkcl: On "sv.setb/pm=r3/sm=1<<r3 5, 31",  "pm" is a typo, right? Found it on a SVP64 Assembler test case (;a=blob;f=src/soc/sv/trans/;h=3ef1f37d6839666be1d46dc95cc6339495a4eda7;hb=HEAD)10:35
cesar[m]1Line 634 to be more precise (;a=blob;f=src/soc/sv/trans/;h=3ef1f37d6839666be1d46dc95cc6339495a4eda7;hb=HEAD#l634)10:36
cesar[m]1Please consider "sv.add/dm=r3 1.v, 5.v, 9.v". This looks like a VSCATTER operation, but it is not (sv.add is not capable of twin-predication). Could we forbid this case (dm on single pred), to avoid confusion?10:58
lkclChips4Makers: nuts, forgot about that10:59
lkcl(the co-author thing)10:59
lkclChips4Makers, yes it should not be duplicated - that's the next phase11:00
lkclcesar[m]1, yes dm=xx on single-predication should be forbidden, can you take care of it?11:01
lkclChips4Makers, corona.vst and corona_cts_r.vst do indeed have the same number of pins at the top cell11:03
lkclcesar[m]1, like 634, setb, is a *twin* predicated.11:04
lkclit is single-soruce, single-destination.  but it should be dm=r3/sm=1<<r311:05
lkclChips4Makers: i'm ok with adding "Copyright (C) ..." notices at the top to fix that one11:06
cesar[m]1Yes, but what is "pm=r3"? Ah, should that be "dm"? I guess it's a typo, but the SVP64 Assembler didn't catch it.11:06
cesar[m]1Will fix.11:08
Chips4MakersMaybe put it in README and co-author that commit. For my C4M repos I did not want to be burdened anymore with having to maintain proper copyright statements in files so switched totally to git authorship as reference.11:10
lkclcesar[m]1, there's no "catch" for encmode unrecognised11:11
lkclChips4Makers, ahh ok.  yes good idea11:11
Chips4Makerslkcl: I think the best approach is that when generating the pinmux you also generate a top cell with nmigen, let's say ls180_top that is then used for synthesis in the alliance-check-toolkit flow.11:22
Chips4MakersThis cell should have same pinout as corona(_cts_r)11:23
Chips4MakersThe test bench should be able to run on ls180_top, cocona and corona_cts_r and exactly see where something goes wrong.11:23
lkclyep got it, i like that11:45
lkclit means creating something with "xxxx_to_pad" and "xxxx_from_pad" which should not be hard11:46
Chips4Makerslkcl: I am also not much fan of the copying of the output files between the different submodules. It introduces the (additional) risk of mismatch between the tested version and the version send to tape-out.13:06
lkclChips4Makers, i know. ideally it would be top-level Makefiles, run it, it does "everything"13:15
cesar[m]1Are we going to accept "sv.add/dm=r3/sm=r3 1.v, 5.v, 9.v", or even "sv.add/dm=r3/m=r3 1.v, 5.v, 9.v"? Technically, it is correct, I guess, since dm=sm=m on single-pred. But, it seems confusing to me, to allow it.14:13
lkclcesar[m]1, specifying dm= and sm= on single-predication should be prohibited, yes.14:14
cesar[m]1Good. I will make sure the SVP64 Assembler enforces it, and look for test cases doing this.14:17
* lkcl investigating name-conflict issues in GHDL / VST15:24
lkcllatest one is that capital-letter name OE and lower-case name oe are different in nmigen and verilog15:26
lkclbut, argh, conversion to VST makes them the same15:26
cesar[m]1Are sm=xx and/or dm=xx allowed together with m=xx on twin-pred?15:36
cesar[m]1I would think not.15:37
lkclm= overrides (takes precedence over) sm and dm because it specifies both15:42
cesar[m]1Good. So, "sv.setb/m=xx/sm=xx" and "sv.setb/dm=xx/m=xx" should both be rejected, right? If so, I'll add an assertion for this.15:50
lkclm *means* "sm=dm=xx"16:22
Chips4Makerslkcl: yeah, VHDL is case insensitive, verilog is case sensitive. Conversion is thus often hit and miss.16:58
cesar[m]1It seems to me that "sv.setb/sm=ne 5, 31" cannot be encoded in SVP64, since "sm=ne" is CR predication, dm=ALWAYS (the default) is INT predication, and you can't mix INT and CR in twin-pred. Seems a little odd.18:33
lkclChips4Makers, well, i'll work around it.  don't mind "horrible looking names" :)19:09
lkclcesar[m]1, no, it is a bit awkward, i know. CR-int is a single bit selection.  this saves 1 bit19:10
lkcla workaround is simply to load all 1s into one of the CRs.  sigh.19:12
cesar[m]1Got it.19:14
Chips4Makerslkcl: Just commit update to pre_pnr test bench, where full io ring is loaded with values through boundary scan. It shows that *pad_oe signals show x where they should be 1. Likely multiple driver problem. I will look at it further tomorrow.19:32
lkclChips4Makers, ahh ok20:13
lkcli am investigating the naming issues in ghdl, just adding workarounds20:13

Generated by 2.17.1 by Marius Gedminas - find it at!