| Chips4Makers | lkcl: 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 |
|---|---|---|
| Chips4Makers | I also disagree with duplicating the cocotb test.py and idcode.svf testbench files. There should only be one copy used for both pre- and post-layout simulation. | 09:25 |
| Chips4Makers | The 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 during | 09:43 |
| Chips4Makers | So the pre-layout testbench should be on the top cell used for synthesis and because it will have the same pins the test.py test bench can be reused. | 09:45 |
| cesar[m]1 | lkcl: On "sv.setb/pm=r3/sm=1<<r3 5, 31", "pm" is a typo, right? Found it on a SVP64 Assembler test case (https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/sv/trans/svp64.py;h=3ef1f37d6839666be1d46dc95cc6339495a4eda7;hb=HEAD) | 10:35 |
| cesar[m]1 | Line 634 to be more precise (https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/sv/trans/svp64.py;h=3ef1f37d6839666be1d46dc95cc6339495a4eda7;hb=HEAD#l634) | 10:36 |
| cesar[m]1 | Please 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 |
| lkcl | Chips4Makers: nuts, forgot about that | 10:59 |
| lkcl | (the co-author thing) | 10:59 |
| lkcl | Chips4Makers, yes it should not be duplicated - that's the next phase | 11:00 |
| cesar[m]1 | s/VSCATTER/VEXPAND/ | 11:01 |
| lkcl | cesar[m]1, yes dm=xx on single-predication should be forbidden, can you take care of it? | 11:01 |
| cesar[m]1 | Sure. | 11:01 |
| lkcl | Chips4Makers, corona.vst and corona_cts_r.vst do indeed have the same number of pins at the top cell | 11:03 |
| lkcl | cesar[m]1, like 634, setb, is a *twin* predicated. | 11:04 |
| lkcl | it is single-soruce, single-destination. but it should be dm=r3/sm=1<<r3 | 11:05 |
| lkcl | Chips4Makers: i'm ok with adding "Copyright (C) ..." notices at the top to fix that one | 11:06 |
| cesar[m]1 | Yes, 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]1 | Will fix. | 11:08 |
| Chips4Makers | Maybe 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 |
| lkcl | cesar[m]1, there's no "catch" for encmode unrecognised | 11:11 |
| lkcl | Chips4Makers, ahh ok. yes good idea | 11:11 |
| Chips4Makers | lkcl: 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 |
| Chips4Makers | This cell should have same pinout as corona(_cts_r) | 11:23 |
| Chips4Makers | The test bench should be able to run on ls180_top, cocona and corona_cts_r and exactly see where something goes wrong. | 11:23 |
| lkcl | yep got it, i like that | 11:45 |
| lkcl | it means creating something with "xxxx_to_pad" and "xxxx_from_pad" which should not be hard | 11:46 |
| Chips4Makers | lkcl: 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 |
| lkcl | Chips4Makers, i know. ideally it would be top-level Makefiles, run it, it does "everything" | 13:15 |
| cesar[m]1 | Are 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 |
| lkcl | cesar[m]1, specifying dm= and sm= on single-predication should be prohibited, yes. | 14:14 |
| cesar[m]1 | Good. 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 / VST | 15:24 | |
| lkcl | latest one is that capital-letter name OE and lower-case name oe are different in nmigen and verilog | 15:26 |
| lkcl | but, argh, conversion to VST makes them the same | 15:26 |
| cesar[m]1 | Are sm=xx and/or dm=xx allowed together with m=xx on twin-pred? | 15:36 |
| cesar[m]1 | I would think not. | 15:37 |
| lkcl | no | 15:42 |
| lkcl | m= overrides (takes precedence over) sm and dm because it specifies both | 15:42 |
| cesar[m]1 | Good. 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 |
| lkcl | yes | 16:22 |
| lkcl | m *means* "sm=dm=xx" | 16:22 |
| Chips4Makers | lkcl: yeah, VHDL is case insensitive, verilog is case sensitive. Conversion is thus often hit and miss. | 16:58 |
| cesar[m]1 | It 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 |
| lkcl | Chips4Makers, well, i'll work around it. don't mind "horrible looking names" :) | 19:09 |
| lkcl | cesar[m]1, no, it is a bit awkward, i know. CR-int is a single bit selection. this saves 1 bit | 19:10 |
| lkcl | a workaround is simply to load all 1s into one of the CRs. sigh. | 19:12 |
| cesar[m]1 | Got it. | 19:14 |
| Chips4Makers | lkcl: 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 |
| lkcl | Chips4Makers, ahh ok | 20:13 |
| lkcl | excellent | 20:13 |
| lkcl | i am investigating the naming issues in ghdl, just adding workarounds | 20:13 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!