| programmerjake | i published v0.3.0 of algebraics, thanks to some generous contributors who ported it to newer dependency versions so it works on stable rust | 02:29 |
|---|---|---|
| programmerjake | (used by simple-soft-float, the library i wrote as a reference for testing our fpu) | 02:29 |
| programmerjake | https://github.com/programmerjake/algebraics/pull/3 | 02:30 |
| programmerjake | https://salsa.debian.org/Kazan-team/algebraics/-/tags/v0.3.0 | 02:35 |
| markos | hello, I could not fix the sv.ld error yesterday, thought I had an old tree so did a git pull everywhere, and now getting a sphinx missing module error: | 08:04 |
| markos | Could not import extension sphinxcontrib_verilog_diagrams (exception: No module named 'sphinxcontrib_verilog_diagrams') | 08:04 |
| markos | I could not find such a package | 08:05 |
| programmerjake | apparently it was renamed: | 08:09 |
| programmerjake | https://readthedocs.org/projects/sphinxcontrib-verilog-diagrams/ | 08:09 |
| programmerjake | > Renamed to https://github.com/SymbiFlow/sphinxcontrib-hdl-diagrams | 08:09 |
| markos | the build environment seems too fragile imho, too many things can break | 08:43 |
| programmerjake | yeah, i agree, but we don't really have time right now to redo everything to make it better | 08:44 |
| markos | and I'm not entirely sure in what order I am supposed to fix those | 08:44 |
| markos | I would suggest a small debian repo with CI built packages | 08:44 |
| programmerjake | I'm working on setting up CI right now... | 08:44 |
| markos | great! | 08:44 |
| markos | having a CI that builds newer versions of the packages would be a great boost -they don't have to follow all strict Debian guidelines, but they would certainly help in development | 08:46 |
| markos | we had a similar system at my previous company | 08:46 |
| markos | if a PR would pass all CI tests, the CI itself would build and upload a new version of the package | 08:46 |
| programmerjake | can you submit a bug so we don't forget to set up something like that? | 08:46 |
| markos | ie, no need for manual uploads | 08:46 |
| markos | sure | 08:47 |
| programmerjake | thx | 08:47 |
| markos | https://bugs.libre-soc.org/ ? | 08:47 |
| programmerjake | yup! | 08:47 |
| markos | ok, I can see the login page, but where is the register page? :) | 08:48 |
| programmerjake | icr if just anyone can make an account, or if an admin has to make you an account...let me know... | 08:48 |
| markos | I've used bugzilla in other projects, I could definitely register, there is/was a "New Account" link right next to Log In | 08:50 |
| markos | so I guess it's disabled | 08:50 |
| markos | lkcl, ^ | 08:50 |
| programmerjake | ah, i'll make you a user account... | 08:51 |
| programmerjake | icr what your email is... | 08:52 |
| programmerjake | markos: ^ | 08:53 |
| markos | konstantinos@vectorcamp.gr | 08:54 |
| programmerjake | @markos you should be able to reset your password now...let me know if it works | 08:58 |
| markos | programmerjake, done, which component would you like this bug reported to? | 09:09 |
| programmerjake | libre-soc website should be good enough, we can move it to a better one if there is one | 09:11 |
| programmerjake | thx! | 09:11 |
| markos | https://bugs.libre-soc.org/show_bug.cgi?id=793 | 09:13 |
| programmerjake | thx | 09:14 |
| markos | now to fix my own problem, after doing a git pull on all projects, how do I update the build system? I still get the sphinxcontrib_verilog_diagrams error and I still get the unrecognized opcode 'sv.ld' even though I'm 100% certain that the instruction is correct | 09:15 |
| programmerjake | i'd suspect you just have to change sphinxcontrib_verilog_diagrams to sphinxcontrib_hdl_diagrams... | 09:16 |
| programmerjake | for the 'sv.ld' problem...that needs to be passed through SVP64Asm which converts it into instructions debian's version of gas understands: | 09:20 |
| programmerjake | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/sv/trans/svp64.py;hb=6f6b52c92f0bfadce05a071a698a93ff4afd2b7c#l153 | 09:20 |
| markos | yes, I know, some instructions do get translated fine | 09:20 |
| markos | it's just this particular one that fails | 09:20 |
| programmerjake | it's possible sv.ld wasn't yet added to SVP64Asm | 09:20 |
| programmerjake | i didn't see it, though I didn't go through SVP64Asm in detail rn | 09:21 |
| programmerjake | all the load/store instructions need to be translated differently than the alu instructions, so that's probably why it doesn't work | 09:21 |
| markos | I see that "sv.ld 5.v, 4(1.v)" already in src/openpower/sv/trans/svp64.py | 09:22 |
| markos | and I'm trying 'sv.ld 10.v, 0(5.v)' | 09:23 |
| programmerjake | hmm....weird | 09:24 |
| programmerjake | it appears to work for me when i edit it into the main stuff at the bottom of svp64.py | 09:29 |
| programmerjake | it gives `['.long 0x5403500', 'ld 2, 0(1)']` | 09:29 |
| markos | this is the snippet that fails here: | 09:30 |
| markos | .loop1: | 09:30 |
| markos | setvl 0,0,17,0,1,1 | 09:30 |
| markos | sv.ld 10.v, 0(5.v) | 09:30 |
| markos | and this gets translated to: | 09:30 |
| markos | .loop1: | 09:30 |
| markos | .long 0x58002180 # setvl 0,0,17,0,1,1 | 09:30 |
| markos | sv.ld 10.v, 0(5.v) | 09:30 |
| markos | which obviously fails | 09:30 |
| markos | something in the parser? | 09:31 |
| programmerjake | ah, it expects one line per list element, not several instructions in one list element | 09:31 |
| programmerjake | lst = [... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/6f0edaaa6f9b177c11d941818fd41f20fb082e24) | 09:31 |
| programmerjake | gives `['.loop1:', '.long 0x58002180', '.long 0x5403500', 'ld 2, 0(1)']` | 09:32 |
| programmerjake | hopefully that fixes it for you markos | 09:34 |
| markos | the message was cropped, due to matrix | 09:34 |
| programmerjake | k, i'll re-paste it as smaller sections... | 09:35 |
| programmerjake | lst = [ | 09:35 |
| programmerjake | '.loop1:', | 09:35 |
| programmerjake | 'setvl 0,0,17,0,1,1', | 09:35 |
| programmerjake | 'sv.ld 10.v, 0(5.v)' | 09:35 |
| programmerjake | ] | 09:36 |
| markos | ok, I see, that means it can translate the instruction, but why not inside the original asm source? | 09:36 |
| programmerjake | all i can think of is you might have done `["insn1\ninsn2\ninsn3"]` rather than `["insn1","insn2","insn3"]` | 09:37 |
| programmerjake | idk if it affects anything, but SVP64Asm was called with the macros arg: | 09:38 |
| programmerjake | `macros={'win2': '50', 'win': '60'}` | 09:39 |
| programmerjake | if that doesn't fix it, you'd probably have to ask lkcl | 09:40 |
| programmerjake | or debug it... | 09:40 |
| programmerjake | sorry. | 09:41 |
| markos | ok, I'll try to do some debugging, see why it fails | 09:42 |
| markos | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/sv/trans/svp64.py;hb=6f6b52c92f0bfadce05a071a698a93ff4afd2b7c#l1152 | 10:18 |
| markos | I see the op parsed and then it goes into that and it doesn't get translated | 10:18 |
| markos | s/that/that if case/ | 10:19 |
| markos | I don't know though why the special casing for len != 2, I'm probably missing the logic here | 10:20 |
| markos | but the bottom line is that the instruction just gets skipped | 10:21 |
| markos | lkcl, ^ fyi | 10:24 |
| programmerjake | idk, git blame just leads to https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=ca04665a7b9f54230eb5b8708af9f3e9b446b9f0 | 10:25 |
| programmerjake | (too bad gitweb has a terrible UI...) | 10:25 |
| programmerjake | maybe just append a `#` to all your assembly lines? :P | 10:27 |
| programmerjake | oh, I think i figured out why... | 10:28 |
| programmerjake | it's so you can have an asm file like: | 10:28 |
| programmerjake | `.long 123, 456 # sv.instr` | 10:28 |
| programmerjake | each line would look something like that, allowing it to be assembled by gas without needing to go through SVP64Asm | 10:29 |
| markos | what about real comments then? | 10:48 |
| markos | yes, that seemed to work | 10:48 |
| programmerjake | maybe put them on the line above? | 10:48 |
| markos | ok, to comment an sv instruction I have to use double '#' | 10:49 |
| markos | this seems to work: | 10:50 |
| markos | setvl 0,0,17,0,1,1 | 10:50 |
| markos | # sv.ld 10.v, 0(5.v) | 10:50 |
| markos | # # sv.fadds/mrr in.v, in.v, in.v | 10:50 |
| markos | it's counter-intuitive though | 10:51 |
| programmerjake | yeah...it needs to be fixed... | 10:51 |
| markos | ie setvl will also not be parsed by gas | 10:51 |
| markos | I'd suggest some other form of annotation, not a plain '#' | 10:53 |
| lkcl | markos: https://libre-soc.org/irclog/%23libre-soc.2022-03-28.log.html#t2022-03-28T21:09:51 | 10:55 |
| lkcl | markos: we had a nice advert for juniper network devices created on bugzilla, which was the point where trust was eroded and i had to disable account creation | 10:57 |
| lkcl | markos: you also need to align the vector register numbers to a power of 4 | 10:58 |
| markos | lkcl, yes, I remember that comment, but it needed something extra apparently | 10:58 |
| lkcl | correct, setvl will not get parsed by gas, it also has to go through svtrans.py. ghostmansd[m] is working on a new version of binutils gas | 10:59 |
| markos | you mean, sv.ld 8.v, 0(5.v)? | 10:59 |
| lkcl | sv.ld 8.v, 0(4.v) | 10:59 |
| lkcl | try that | 11:00 |
| markos | but 0(5.v) is just a pointer, why would that need alignment also? | 11:00 |
| lkcl | ... i'm half-awake at the moment | 11:00 |
| markos | I get the first | 11:00 |
| lkcl | there's only a certain amount of space to store the "extension" of the SVP64 registers to 128 | 11:01 |
| lkcl | there are 5 bits to store the register number in the RA/RB/RC/RT field in the original v3.0B 32-bit opcode | 11:01 |
| lkcl | and there are either 2 or 3 bits to store the rest | 11:02 |
| lkcl | one of those is "is this a vector or scalar" bit | 11:02 |
| lkcl | that leaves 1 remaining | 11:02 |
| lkcl | 5+1=6 | 11:02 |
| lkcl | 2<<6 is not 128, it is 64 | 11:02 |
| lkcl | therefore we have to put a zero in the LSB of the Vector Register Number | 11:02 |
| lkcl | therefore, you can only have 0.v 2.v 4.v 6.v 8.v .... | 11:03 |
| markos | yeah, I'm definitely misunderstanding something, what I want is to load 17 (as per the setvl) 'vectors' starting from the memory pointed by register 4, offset 0, to the 'vector' registers starting from 8.v | 11:04 |
| markos | does it matter if the address is in register 4 or 5 or whatever? | 11:05 |
| markos | actually I should have mentioned register 5, instead of 4, as that's the input register | 11:05 |
| lkcl | you can't. | 11:06 |
| lkcl | it will have to be 4.v as explained above | 11:06 |
| lkcl | but hang on | 11:06 |
| markos | if for some reason it is 5, what will happen? a hardware trap? should that be caught by the assembler? | 11:07 |
| lkcl | you've combined/confused LD-with-immediate with the LD-indexed format | 11:07 |
| markos | yes, I said I'm misunderstanding something :D | 11:08 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/test_caller_svp64_ldst.py;hb=HEAD | 11:08 |
| lkcl | you know the names for the different vector forms? | 11:08 |
| lkcl | unit-strided, element-strided, etc? | 11:09 |
| markos | yeah, I admit I didn't read it thoroughly | 11:10 |
| lkcl | which one do you want? i suspect you want unit-strided | 11:10 |
| lkcl | "memory pointed by register 4" is a scalar | 11:10 |
| lkcl | and you want a sequential packed-load from that memory location? | 11:10 |
| markos | yes | 11:10 |
| lkcl | ok that's termed "unit-strided" | 11:11 |
| markos | so in the end I think I want sv.ld 8.v, 0(4) | 11:11 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/test_caller_svp64_ldst.py;hb=HEAD#l83 | 11:11 |
| lkcl | if they're 32-bit you want sv.lwz 8.v, 0(4) | 11:11 |
| markos | yes | 11:11 |
| markos | ok, I was certain I misunderstood something and I was right | 11:12 |
| lkcl | just as in that example. | 11:12 |
| lkcl | you can see at line 88 how it's calculated | 11:12 |
| lkcl | 88 for i in range(VL): | 11:13 |
| lkcl | 89 EA = (RA|0) + EXTS(D) + LDSTsize * i | 11:13 |
| lkcl | where D-Form is "lwz RT,D(RA)" | 11:13 |
| lkcl | https://libre-soc.org/openpower/isa/fixedload/ | 11:13 |
| lkcl | but you have to have RA be a scalar for unit-stride to activate | 11:14 |
| lkcl | basically the problem is that we have to shoe-horn a shed-load of "traditional Vector ISA Modes" on top of a scalar ISA that was never designed with Vectorisation in mind | 11:15 |
| lkcl | all without adding any new 32-bit LD/ST instructions | 11:19 |
| markos | ok, understood | 11:21 |
| markos | what I'm doing right now, is I've modified the C code to only do a few steps at a time and converting the svp64 asm to generate the same output in the same steps | 11:22 |
| markos | in theory, I should be able to match the routine soon, in practice, I'm pretty sure I will hit a corner case where one step will generate the same output, but the next step will be completely different :) | 11:23 |
| *** alMalsamo is now known as lumberjack123 | 11:42 | |
| lkcl | :) | 11:46 |
| lkcl | btw please do commit what you're doing as you go along | 11:47 |
| lkcl | if nobody can see what you're doing, then it's guess-work and i (literally) don't have time to go through that | 11:48 |
| markos | lkcl, of course, but only when I get something worthy commiting, I'm against commiting all my debug steps | 11:51 |
| lkcl | markos, that's exactly what the basic policy of this project is: to commit all debug steps | 11:53 |
| lkcl | please *don't* "only commit what you consider worthy" | 11:53 |
| lkcl | we are under Audit and Transparency Conditions apart from anything | 11:53 |
| lkcl | plus, the "learning" steps - with appropriate commit messages - are just as equally important | 11:54 |
| lkcl | "i made this mistake and here's the change needed to fix it and here's a link to the public discussion which showed what was needed" becomes something that we can use to educate others | 11:54 |
| lkcl | so for example, when committing the sv.ld fix you should cross-reference to the IRC channel logs | 11:55 |
| lkcl | https://libre-soc.org/irclog/%23libre-soc.2022-03-29.log.html#t2022-03-29T11:11:00 | 11:56 |
| markos | lkcl, that just generates huge git commit logs for no good reason, I have never been in favour of such development processes, I want to be able to read git logs and get the idea behind the actual change, not what was in the coder's mind at the time of development | 12:01 |
| markos | plus it requires extra overhead | 12:01 |
| lkcl | markos, doesn't matter. this is in part an education project | 12:01 |
| lkcl | i do appx 30 commits a day. | 12:02 |
| lkcl | it also prevents and prohibits collaboration | 12:02 |
| markos | I do less, but I have 4 projects that I need to work on currently | 12:02 |
| markos | if I had to do that, I would have to work 20h/day | 12:03 |
| lkcl | ok - then putting the code in with a brief commit message is more important than the explanation | 12:03 |
| lkcl | please: this is really important. | 12:03 |
| lkcl | there are about 6 separate different reasons | 12:03 |
| lkcl | 1) if you are unable for any reason to commit then we have lost everything | 12:04 |
| lkcl | 2) we are under audit / transparency conditions | 12:04 |
| lkcl | 3) nobody else can properly help - we have to "guess" and that takes up my time and everyone else's time | 12:04 |
| lkcl | 4) the "learning curve" is lost | 12:04 |
| lkcl | 5) other people cannot help you by providing commits | 12:05 |
| lkcl | 6) although your time is valuable for you, and it could slow you down, me having to "guess" because i can't see your screen means that overall the project does less because i end up being able to do less | 12:07 |
| lkcl | i've a deadline for completing the FPGA of only 2 days remaining. | 12:07 |
| markos | 1) I have multiple backups so I'm good there, 2) I know how auditing works, no auditor will care to check each and every print statement, 3) the help part I agree with, but that's what IRC and mails are for, 4) that, plus docs, 5) I wouldn't ask other people to commit stuff on my behalf | 12:07 |
| lkcl | please, markos, this is important. | 12:08 |
| lkcl | auditors are not going to look at this | 12:09 |
| markos | I also have 3 contracts running, I also have deadlines for my other projects, I have agreed to work on this not because of financial reasons, but because I really find it fascinating and I think it will be a very important technological evolution in CPU architectures in the next 5 years | 12:10 |
| lkcl | we have a basic and fundamental principle of trust | 12:10 |
| markos | I have committed myself to working on this and learning how this will work | 12:10 |
| lkcl | ok | 12:11 |
| lkcl | i need to walk away from the keyboard, i am in distress. | 12:11 |
| markos | but you also have to allow me to work my own way | 12:11 |
| markos | I am not just going to drop a multi-MB commit | 12:11 |
| markos | but otoh, I cannot commit each and every print statement | 12:12 |
| lkcl | sorry about that. i appreciate the help you can give. | 12:18 |
| markos | I don't think we disagree in essence, I *will* give detailed commits and explain all that is done, so people *will* actually be able to follow the code | 12:19 |
| lkcl | let's go over it tonight. | 12:19 |
| markos | ok | 12:19 |
| lkcl | which hm i am going to float the idea of moving it hr earlier (to 21:00 UTC) | 12:20 |
| lkcl | because otherwise it is a mad time for you | 12:20 |
| markos | yes please | 12:20 |
| markos | sleeping at 2am because of coding I don't mind, but because of meetings... :-D | 12:21 |
| tplaten | I had a look at external_core_top.v:282587 | 17:45 |
| tplaten | (* src = "nmutil/src/nmutil/iocontrol.py:97" *) | 17:45 |
| tplaten | input spr1__wen; | 17:45 |
| tplaten | (* syn_ramstyle = "block_ram" *) | 17:45 |
| tplaten | reg [63:0] memory [23:0]; | 17:45 |
| tplaten | initial begin | 17:45 |
| tplaten | memory[0] = 64'h0000000000000000; | 17:45 |
| tplaten | Am I using the wrong version of nmutil? | 17:46 |
| tplaten | In the last few weeks I was only working on microwatt, so I did not update any python packages. My current nmutil version is about one month old. | 17:50 |
| lkcl | tplaten, https://git.libre-soc.org/?p=nmutil.git;a=tree | 18:02 |
| lkcl | latest commit is this https://git.libre-soc.org/?p=nmutil.git;a=commit;h=2ef87c06d25b692ede35aa6340a108ba410b440a | 18:02 |
| lkcl | although there's not been a lot of commits so you should be fine | 18:03 |
| lkcl | tplaten: http://lists.libre-soc.org/pipermail/libre-soc-dev/2022-March/004644.html | 18:03 |
| tplaten | I had a look at both nmutil and the last link. All software versions are correct. Upgrading nmutil did not resolve anything | 18:06 |
| lkcl | including verilator? | 18:07 |
| lkcl | where *exactly* is the error? | 18:07 |
| lkcl | which program is reporting an error? | 18:07 |
| tplaten | The error is on yosys, before verilator is invoked | 18:08 |
| lkcl | "13. Executing Verilog backend" i cannot tell what is reporting that | 18:08 |
| lkcl | ok. | 18:08 |
| tplaten | write_verilog in yosys | 18:08 |
| lkcl | which commit are you on for nmigen? | 18:09 |
| lkcl | it should be this | 18:09 |
| lkcl | https://gitlab.com/nmigen/nmigen/-/commit/37b7d9a9a78fa48042391bf62245a24c2e4d55dc | 18:09 |
| tplaten | $(YOSYS) $(GHDLSYNTH) -p "ghdl --std=08 --no-formal $(GHDL_IMAGE_GENERICS) $(synth_files) -e toplevel; write_verilog $@" | 18:09 |
| lkcl | which commit for *nmigen*? | 18:10 |
| lkcl | that's "re-importing" | 18:10 |
| lkcl | that's *re-importing* the nmigen-generated verilog file comprising external_core_top.v | 18:10 |
| lkcl | which was *generated* by nmigen | 18:10 |
| tplaten | commit 37b7d9a9a78fa48042391bf62245a24c2e4d55dc | 18:10 |
| tplaten | Author: Luke Kenneth Casson Leighton <lkcl@lkcl.net> | 18:10 |
| tplaten | Date: Thu Mar 24 13:41:27 2022 +0000 | 18:10 |
| tplaten | nextpnr-xilinx can cope with the various IBUF/OBUFs, | 18:10 |
| tplaten | no need to fall back to standard platform Instance("$tristate") etc. | 18:10 |
| lkcl | ok great | 18:10 |
| lkcl | let me check | 18:10 |
| tplaten | commit 37b7d9a9a78fa48042391bf62245a24c2e4d55dc | 18:11 |
| lkcl | got it | 18:11 |
| lkcl | 1 sec just checking | 18:11 |
| lkcl | 2. Executing Verilog backend. | 18:12 |
| lkcl | Dumping module `\clock_generator_50000000_50000000'. | 18:12 |
| lkcl | not getting any problem here with the microwatt_verilator branch | 18:13 |
| lkcl | please can you check that specific branch | 18:13 |
| lkcl | https://git.libre-soc.org/?p=microwatt.git;a=shortlog;h=refs/heads/verilator_trace | 18:13 |
| tplaten | I'll check that again, last week it was working | 18:14 |
| tplaten | How does dropping in an external_core work with verilator | 18:14 |
| tplaten | maybe one change in my branch broke everything | 18:15 |
| lkcl | ok i get the exact same eror | 18:15 |
| lkcl | therefore you've broken something in the porting | 18:15 |
| tplaten | I agree, most likely I have misunderstood something | 18:16 |
| tplaten | microwatt.v: $(synth_files) $(RAM_INIT_FILE) | 18:16 |
| tplaten | 242 $(YOSYS) -m $(GHDLSYNTH) -p "ghdl --std=08 --no-formal $(GHDL_IMAGE_GENERICS) $(GHDL_TARGET_GENERICS) $(synth_files) -e toplevel; write_verilog $@" | 18:16 |
| lkcl | let me take a look | 18:16 |
| tplaten | this is the make rule in the verilator_trace branch | 18:17 |
| lkcl | basically you musn't try to actually do the BRAM "memory" in verilog/vhdl/nmigen but instead let the verilator c++ do it | 18:17 |
| tplaten | I understand | 18:18 |
| lkcl | upstream microwatt tries to convert hexadecimal files into "RAM_INIT_FILE" | 18:18 |
| lkcl | sorry | 18:18 |
| lkcl | takes RAM_INIT_FILE and turns it into a sequence of registers | 18:18 |
| lkcl | i replaced that with a c++ *emulation* of a RAM. | 18:18 |
| tplaten | Does verilator read the external_core_top.v file, | 18:19 |
| lkcl | that could then be "pre-populated" with the contents of the file to be executed | 18:19 |
| lkcl | yes it has to | 18:19 |
| tplaten | I saw that c++ *emulation* of a RAM. | 18:19 |
| lkcl | $ make -n microwatt-verilator | 18:19 |
| lkcl | yosys -m ghdl.so -p "ghdl --std=08 --no-formal -gMEMORY_SIZE=536870912 -gRAM_INIT_FILE=dtbImage.microwatt.hex -gRESET_LOW=true -gCLK_INPUT=50000000 -gCLK_FREQUENCY=50000000 -gSIM_MAIN_BRAM=false -gSIM_BRAM_CHAINBOOT=6291456 -gEXTERNAL_CORE=true decode_types.vhdl common.vhdl wishbone_types.vhdl utils.vhdl core_dummy.vhdl fpga/soc_reset.vhdl fpga/pp_fifo.vhd fpga/pp_soc_uart.vhd fpga/main_bram.vhdl nonrandom.vhdl wishbone_arbiter.vhdl | 18:19 |
| lkcl | wishbone_bram_wrapper.vhdl sync_fifo.vhdl wishbone_debug_master.vhdl xics.vhdl syscon.vhdl soc.vhdl spi_rxtx.vhdl spi_flash_ctrl.vhdl fpga/clk_gen_bypass.vhd fpga/top-generic.vhdl dmi_dtm_dummy.vhdl -e toplevel; write_verilog microwatt.v" | 18:19 |
| lkcl | that's in the microwatt-verilator branch | 18:20 |
| lkcl | $ make -n microwatt-verilator | 18:20 |
| lkcl | yosys -m ghdl -p "ghdl --std=08 --no-formal -gMEMORY_SIZE=8192 -gRAM_INIT_FILE=hello_world/hello_world.hex -gRESET_LOW=true -gCLK_INPUT=50000000 -gCLK_FREQUENCY=50000000 -gICACHE_NUM_LINES=4 decode_types.vhdl common.vhdl wishbone_types.vhdl utils.vhdl core_dummy.vhdl helpers.vhdl gpio.vhdl cache_ram.vhdl fpga/soc_reset.vhdl fpga/pp_fifo.vhd fpga/pp_soc_uart.vhd fpga/main_bram.vhdl nonrandom.vhdl wishbone_arbiter.vhdl wishbone_bram_wrapper.vh | 18:20 |
| lkcl | dl sync_fifo.vhdl wishbone_debug_master.vhdl xics.vhdl syscon.vhdl soc.vhdl spi_rxtx.vhdl spi_flash_ctrl.vhdl plru_dummy.vhdl fpga/clk_gen_bypass.vhd fpga/top-generic.vhdl dmi_dtm_dummy.vhdl -e toplevel; read_verilog uart16550/raminfr.v uart16550/uart_defines.v uart16550/uart_receiver.v uart16550/uart_regs.v uart16550/uart_rfifo.v uart16550/uart_sync_flops.v uart16550/uart_tfifo.v uart16550/uart_top.v uart16550/uart_transmitter.v | 18:20 |
| lkcl | uart16550/uart_wb.v external_core_top.v; write_verilog microwatt.v" | 18:20 |
| lkcl | that's in your branch | 18:20 |
| lkcl | you're missing: | 18:21 |
| lkcl | * -gSIM_MAIN_BRAM=false | 18:21 |
| lkcl | * -gSIM_BRAM_CHAINBOOT (which is only needed for linux-5.7 dtbImage so that's ok) | 18:21 |
| lkcl | * having the uart16550 instead of potato is [probably] ok | 18:22 |
| lkcl | and you have also added external_core_top.v | 18:25 |
| lkcl | which i believe verilator will pick up automatically through its "includes" system | 18:27 |
| tplaten | I first check if the verilator version is correct, undo the adding of external_core_top.v, then retry | 18:28 |
| lkcl | basically you musn't randomly add things that "appear to be missing" | 18:28 |
| lkcl | for example -Iuart16550 \ in the Makefile on the microwatt-verilator target | 18:29 |
| lkcl | that says to verilator, "if you encounter an object named uart_16550 then when you are performing the hunting in *.v files looking for it please also search the uart16550 subdirectory as well" | 18:30 |
| lkcl | exactly like #includes for c/c++ | 18:30 |
| lkcl | therefore if you explicitly added the uart16550/*.v files (because you thought "hm these are missing i'll add them") i suggest removing them | 18:31 |
| tplaten | Some time ago when I tried to install verilator v4.106, I got weird errors such as error: 'cerr' is not a member of 'std' where I gave up and used apt-get install verilator | 18:38 |
| tplaten | That gave me a version that is too old. | 18:38 |
| tplaten | I was able to build all other packages that I need. | 18:38 |
| lkcl | did you build it from a debian/10 schroot? | 18:38 |
| tplaten | yes I did | 18:40 |
| lkcl | that's very odd | 18:42 |
| tplaten | On the host system I can install verilator, I have all other tools in schroots, including one for coriolis2 | 18:51 |
| lkcl | this is on amd64 or ppc64le? | 18:51 |
| tplaten | ppc64le | 18:52 |
| tplaten | While compiling verilator I was reading on crowdsupply.com | 18:55 |
| tplaten | I saw that a HyperRAM controller is used for USB analysis in LUNA. | 18:56 |
| tplaten | I assume 32 MBytes of HyperRAM is barely enough for a small linux. I knew that Linus Torwalds had 4 MBytes when he wrote linux (from his book). | 19:01 |
| tplaten | Build completed, now running make test | 19:03 |
| lkcl | yes it's just about manageable. openwrt linux kernels and the OSes typically fit into 16 mbytes. just | 19:03 |
| lkcl | i actually have 2 of them and there are 4x PMOD ports (2 per HyperRAM) so if absolutely necessary i can put the 2nd one onto the Arty A7 | 19:05 |
| tplaten | Tests passed! | 19:08 |
| lkcl | excellent. that's a verilator build? | 19:09 |
| tplaten | Yes, verilator. I ran make test before make install | 19:10 |
| lkcl | brilliant. | 19:10 |
| tplaten | In verilator_trace I did a grep: microwatt.v: external_core_top \processor_external.processor ( | 20:21 |
| tplaten | this is clearly missing in my branch | 20:21 |
| lkcl | i had to add it to soc.vhdl | 20:25 |
| lkcl | lkcl@fizzy:~/src/libresoc/microwatt-orangecrab$ grep external_core *.vhdl | 20:26 |
| lkcl | lkcl@fizzy:~/src/libresoc/microwatt-orangecrab$ | 20:26 |
| lkcl | lkcl@fizzy:~/src/libresoc/microwatt2$ grep external_core *.vhdl | 20:26 |
| lkcl | soc.vhdl: component external_core_top port ( | 20:26 |
| lkcl | soc.vhdl: processor: external_core_top | 20:26 |
| lkcl | it's a bit of a pain: you also need to add a "dummy" version so that when compiling EXTERNAL_CORE=false for microwatt it can go "ok i found an external_core instance" | 20:27 |
| lkcl | which *later* it goes "hey that's not needed... now i can delete it" | 20:27 |
| lkcl | sigh | 20:27 |
| tplaten | I found out already out, I have a dummy version | 20:27 |
| lkcl | :) | 20:28 |
| lkcl | core_dummy.vhdl | 20:30 |
| lkcl | although... | 20:30 |
| * lkcl thinks | 20:30 | |
| lkcl | processor_external: if EXTERNAL_CORE generate | 20:30 |
| lkcl | processor: external_core_top | 20:31 |
| lkcl | 25 lines above that, if putting something similar | 20:31 |
| lkcl | processor_internal: if NOT EXTERNAL_CORE generate | 20:31 |
| lkcl | processor: entity work.core | 20:31 |
| lkcl | i think that might do away with the need for creating core_dummy.vhdl | 20:31 |
| markos | lkcl, so, is the meeting at 21UTC? | 20:46 |
| markos | apparently not... | 21:04 |
| lkcl | 22:00 UTC :) | 21:06 |
| lkcl | which is... errr... i make that 2 hours from now. 1h54m | 21:06 |
| markos | 2? | 21:06 |
| lkcl | BST... err... | 21:07 |
| markos | crap, DST | 21:07 |
| lkcl | BST==err... | 21:07 |
| lkcl | sigh yes | 21:07 |
| markos | that's going to be 1am here | 21:07 |
| lkcl | hence discussing moving it 1hr earlier from next week | 21:07 |
| markos | I don't think I will make it this time, it's just too late | 21:07 |
| markos | so I'll just mention some progress here | 21:08 |
| lkcl | no problem, will discuss about moving earlier | 21:08 |
| lkcl | oh, sure, great | 21:08 |
| markos | so I've done -at least I think I have- the first for loop in SVP64 | 21:09 |
| markos | and I'm writing a tiny test program to compare the result, the actual mp3_1_test actually compares to the data files and I'm a long way from that | 21:09 |
| lkcl | cool! | 21:10 |
| markos | but I am monitoring the simulator and I see that the lwz, fadds/mrr and the stw (that I'm doing afterwards to store the resulting buffer for comparison) are executing exactly 17 times as per the setvl | 21:10 |
| lkcl | great. | 21:10 |
| * lkcl thinks | 21:11 | |
| markos | I have no reason to expect wrong results from such trivial instructions, but I will write the tiny test tomorrow and will grow on that | 21:11 |
| lkcl | perhaps the mp3_1_test (with c-converted-to-assembler) would be a way to confirm, first | 21:11 |
| markos | since you care about the educational aspect of this, I was planning to suggest that I commit this part in steps | 21:11 |
| markos | but I know this one already passes the test | 21:11 |
| lkcl | then do incremental changes converting to svp64? | 21:11 |
| lkcl | ahh :) | 21:12 |
| markos | that's what I'll do | 21:12 |
| lkcl | yes please | 21:12 |
| lkcl | the commit messages don't need to be massive / detailed. | 21:12 |
| markos | I will convert the svp64 in parts, but I will have to partially disable the respective parts of the C code, and compare | 21:12 |
| markos | no, but they have to be explanatory | 21:12 |
| lkcl | true :) | 21:12 |
| lkcl | ohh i see. actually take out the corresponding parts in the original c algorithm and compare that way? | 21:13 |
| markos | yes exactly | 21:13 |
| lkcl | ahh neat. like it | 21:13 |
| markos | it will also help me understand the incremental process of porting to SVP64 | 21:13 |
| markos | I would never hope to convert in one single pass :D | 21:14 |
| lkcl | :) | 21:14 |
| markos | now that I at least figured out how to make this work, I can make gradual progress | 21:14 |
| markos | even a couple of lines per day will do | 21:14 |
| lkcl | if you need to, feel free to add to any of the svp64 unit tests | 21:14 |
| markos | yes, that's a good idea | 21:14 |
| lkcl | with even just 1 instruction, input registers/memory, and "expected results" | 21:15 |
| markos | I will ask you for commit access one of these days | 21:15 |
| lkcl | i do that all the time | 21:15 |
| lkcl | yeah that would help :) | 21:15 |
| markos | quite :) | 21:15 |
| markos | ok, I'm going to call it a night, I'm beat, the past days I've been waking super early and sleeping very late, I would stay for the meeting if it was now-ish, but I can't wait 2 hours :) | 21:16 |
| lkcl | alright | 21:16 |
| lkcl | yehh totally understand | 21:16 |
| lkcl | till next time | 21:17 |
| programmerjake | lkcl: so the meeting hasn't been moved for today? | 21:48 |
| octavius | Is the meeting at 22:00UTC? | 21:53 |
| octavius | oops XD | 21:53 |
| programmerjake | afaict it's in 1hr5min | 21:55 |
| programmerjake | i'm assuming lkcl will move it next week if it gets moved | 21:55 |
| octavius | Ah ok, thanks | 21:57 |
| lkcl | 10m or so | 22:47 |
| lkcl | cesar, lx0 jn octavius programmerjake toshywoshy | 22:47 |
| lkcl | but i'm on now | 22:47 |
| lkcl | if i can find the right URL that is | 22:47 |
| programmerjake | definitely shouldn't have stayed up till 5am ... i'll be there in a few min | 22:51 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!