*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 01:21 | |
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 01:47 | |
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 02:32 | |
*** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has quit IRC | 02:38 | |
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 03:04 | |
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 03:17 | |
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 03:46 | |
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 03:59 | |
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 04:27 | |
*** Ritish <Ritish!~Ritish@115.99.74.188> has joined #libre-soc | 04:29 | |
Ritish | lkcl, I understand, I have screenshots of the output only | 04:31 |
---|---|---|
Ritish | But I was running these set of commands | 04:31 |
Ritish | ## Building microwatt-verilator using the libre-soc core | 04:31 |
Ritish | 52 cd /path/to/soc | 04:31 |
Ritish | 53 make microwatt_external_core | 04:31 |
Ritish | 54 cp external_core_top.v /path/to/microwatt | 04:31 |
Ritish | 55 cd /path/to/microwatt | 04:31 |
Ritish | 56 export FPGA_TARGET=verilator | 04:31 |
Ritish | 57 export GHDLSYNTH=ghdl | 04:31 |
Ritish | 58 make microwatt-verilator | 04:31 |
Ritish | I think/assume it is related to "building the kernel" | 04:32 |
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 04:33 | |
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 04:37 | |
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 05:03 | |
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 05:51 | |
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 05:58 | |
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 06:08 | |
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 06:25 | |
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 06:28 | |
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 06:29 | |
*** toshywoshy <toshywoshy!~toshywosh@ptr-377wf33o3bnthuddmycb.18120a2.ip6.access.telenet.be> has quit IRC | 06:41 | |
*** toshywoshy <toshywoshy!~toshywosh@ptr-377wf33o3bnthuddmycb.18120a2.ip6.access.telenet.be> has joined #libre-soc | 06:41 | |
*** openpowerbot <openpowerbot!~openpower@94-226-187-44.access.telenet.be> has quit IRC | 06:43 | |
*** toshywoshy <toshywoshy!~toshywosh@ptr-377wf33o3bnthuddmycb.18120a2.ip6.access.telenet.be> has quit IRC | 06:53 | |
*** toshywoshy <toshywoshy!~toshywosh@ptr-377wf33o3bnthuddmycb.18120a2.ip6.access.telenet.be> has joined #libre-soc | 06:58 | |
*** ritish_ <ritish_!~Ritish@116.72.126.30> has joined #libre-soc | 07:03 | |
*** Ritish <Ritish!~Ritish@115.99.74.188> has quit IRC | 07:03 | |
*** toshywoshy <toshywoshy!~toshywosh@ptr-377wf33o3bnthuddmycb.18120a2.ip6.access.telenet.be> has quit IRC | 07:04 | |
*** toshywoshy <toshywoshy!~toshywosh@ptr-377wf33o3bnthuddmycb.18120a2.ip6.access.telenet.be> has joined #libre-soc | 07:06 | |
*** toshywoshy <toshywoshy!~toshywosh@ptr-377wf33o3bnthuddmycb.18120a2.ip6.access.telenet.be> has quit IRC | 07:11 | |
*** toshywoshy <toshywoshy!~toshywosh@ptr-377wf33o3bnthuddmycb.18120a2.ip6.access.telenet.be> has joined #libre-soc | 07:12 | |
*** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 07:18 | |
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 07:24 | |
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 07:24 | |
*** toshywoshy <toshywoshy!~toshywosh@ptr-377wf33o3bnthuddmycb.18120a2.ip6.access.telenet.be> has quit IRC | 07:28 | |
*** toshywoshy <toshywoshy!~toshywosh@ptr-377wf33o3bnthuddmycb.18120a2.ip6.access.telenet.be> has joined #libre-soc | 07:40 | |
*** ritish_ <ritish_!~Ritish@116.72.126.30> has quit IRC | 07:53 | |
*** ritish_ <ritish_!~Ritish@116.72.126.30> has joined #libre-soc | 07:56 | |
*** ritish_ is now known as Ritish | 07:57 | |
*** toshywoshy <toshywoshy!~toshywosh@ptr-377wf33o3bnthuddmycb.18120a2.ip6.access.telenet.be> has quit IRC | 08:33 | |
*** toshywoshy <toshywoshy!~toshywosh@ptr-377wf33o3bnthuddmycb.18120a2.ip6.access.telenet.be> has joined #libre-soc | 08:44 | |
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 08:55 | |
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 09:57 | |
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 10:14 | |
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 10:44 | |
lkcl | then if you need to actually build a linux 5.7 kernel, because you have the intention of running linux, you need to look up instructions online on how to build a linux kernel | 11:29 |
lkcl | as i said in the friday meeting: why are you building a microwatt linux 5.7 kernel? what do you need it for? | 11:32 |
*** doppo <doppo!~doppo@2604:180::e0fc:a07f> has quit IRC | 11:33 | |
*** doppo <doppo!~doppo@2604:180::e0fc:a07f> has joined #libre-soc | 11:36 | |
Ritish | oh no, I thought I was building a microwatt-verilator branch | 11:53 |
Ritish | my bad :/ | 11:57 |
Ritish | do we not require microwatt-verilator for what we're about to do? | 11:58 |
Ritish | I'd really like if we could schedule a meeting and I could clarify "all" my doubts LOL | 11:59 |
Ritish | because now it's just confusion kinda | 11:59 |
Ritish | x.x | 11:59 |
*** Ritish <Ritish!~Ritish@116.72.126.30> has quit IRC | 12:00 | |
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 12:00 | |
lkcl | microwatt-verilator is the HDL. | 12:12 |
lkcl | why would the linux kernel be included in the HDL??? | 12:12 |
lkcl | has someone converted the linux kernel into VHDL?? | 12:13 |
lkcl | and not told me, or told you? | 12:13 |
lkcl | why do you think that the VHDL source code of the microwatt-verilator branch has anything to do with a program that happens to be known by the name, "the linux kernel"? | 12:13 |
lkcl | can i suggest and recommend that you separate those two concepts in your mind? | 12:14 |
lkcl | it will then help you to understand that i have said, many times, that you need the microwatt-verilator branch *of the microwatt VHDL source code* | 12:14 |
lkcl | and to further understand that this does **NOT** repeat **NOT** imply "and also you then need the microwatt linux 5.7 application" | 12:15 |
lkcl | if there was a critical dependency for the application known as "the linux 5.7 kernel" as part of getting microwatt-verilator up and running, i would have explicitly said so, wouldn't i? | 12:19 |
lkcl | instead i've said i think five times over the past week, "do not compile the linux 5.7 kernel unless you absolutely need it" | 12:19 |
lkcl | at the pace that you get things running it will add 3-4 weeks to the completion time. | 12:20 |
*** Ritish <Ritish!~Ritish@202.131.158.114> has joined #libre-soc | 12:52 | |
Ritish | i understand. I will try revisiting things from the start and maybe do a miracle, thanks | 12:55 |
Ritish | I did not know that this code is involved in the creation or has something to do with the kernel | 12:56 |
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 12:57 | |
Ritish | I only mentioned that I "thought" the error was related to the kernel | 13:01 |
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 13:06 | |
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.160.75> has joined #libre-soc | 13:07 | |
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.160.75> has quit IRC | 13:31 | |
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.160.75> has joined #libre-soc | 13:36 | |
Ritish | That aside, I was just exploring open source verification tools, any good recommends? | 14:51 |
*** Ritish <Ritish!~Ritish@202.131.158.114> has quit IRC | 15:16 | |
*** octavius <octavius!~octavius@92.40.169.30.threembb.co.uk> has joined #libre-soc | 15:33 | |
octavius | lkcl, when you tested ls2 last week, were you able to program the arty a7-100t board? | 15:39 |
octavius | To make sure I'm following the scripts, I created a fresh chroot for programming. | 15:39 |
octavius | mk-deb-chroot, cp-scripts-to-chroot, then fpga-boot-load-prog-install inside chroot. | 15:39 |
octavius | After plugging in the arty a7-100t board (and copying generated bitstream from nextpnr-xilinx example, see libre-soc wiki page), trying programming by using xc3sprog. | 15:39 |
octavius | xc3sprog -c nexys4 attosoc.bit | 15:39 |
octavius | Could not open FTDI device (using libftdi): device not found | 15:39 |
octavius | Unable to access FTDI device with either libftdi or FTD2XX | 15:39 |
octavius | Have you encountered this issue with xc3sprog and libftdi? | 15:39 |
octavius | Or am I missing something with the board itself? I also tried while pressing down the PROG pushbutton. | 15:40 |
octavius | Checking devices, I can see ttyUSB0 and ttyUSB1 are present | 15:41 |
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.160.75> has quit IRC | 15:42 | |
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 15:42 | |
octavius | Figured it out, my user didn't have permissions, root worked | 15:45 |
octavius | As user, when trying openFPGALoader -b arty_a7_100t --detect, got | 15:46 |
octavius | unable to open ftdi device: -4 (usb_open() failed) | 15:46 |
octavius | JTAG init failed with: unable to open ftdi device | 15:46 |
octavius | I was able to get ls2 to build and upload bitstream (as root). Serial terminal is printing the Microwatt hello world :) | 16:15 |
*** octavius <octavius!~octavius@92.40.169.30.threembb.co.uk> has quit IRC | 16:27 | |
ghostmansd | programmerjake, could you, please, help me with the way to run only one UTF-8 tests? They take an eternity to complete. | 16:47 |
ghostmansd | I just would like to check whether the assembly I modified works (`def assemble(instructions, start_pc=0):` call) | 16:48 |
lkcl | ghostmansd, you can either hack the unit test to rename functions, leaving just the one that you want to run | 17:06 |
lkcl | or | 17:06 |
lkcl | there is a way to use pytest3 and/or nosetests3 to specify the exact function desired to be run for the purposes of test. | 17:06 |
ghostmansd | I wish I could follow this, it was naturally the very first idea I thought of. But... | 17:06 |
ghostmansd | The tests are generated. | 17:06 |
ghostmansd | Names are like test_caller_svp64_utf_8_validation.py::TestSVP64UTF8Validation1::test. | 17:07 |
lkcl | i find that so annoying that i prefer to simply hack out the function names, and have a vim macro for substituting "def test_/def tst_" and back again!! | 17:07 |
ghostmansd | Not even a slightest ida which place to hack. :-) | 17:07 |
ghostmansd | Anyway, I decided to go with an alternative way: `raise 1` at the function that generates the assembly. | 17:07 |
ghostmansd | Yay! | 17:07 |
lkcl | find . -name "*.py" | grep utf8 | 17:07 |
lkcl | awesome | 17:08 |
lkcl | best hacks are the ones you write yourself :) | 17:08 |
ghostmansd | I'm not sure what'd be the address for the label. Still checking this. | 17:08 |
ghostmansd | Say I have `final_check` at pc=0x130, and some `bc 12,2,final_check` instruction. The overall _correct_ code is printed as `beq 0x130` in assembly. | 17:18 |
ghostmansd | What'd be the right argument to `bc` instead of `final_check`, if we need to jump to 0x130? | 17:19 |
ghostmansd | `bc 12,2,0x130` leads to `beq 170 <final_check+0x40>` | 17:27 |
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 17:50 | |
*** octavius <octavius!~octavius@92.40.169.30.threembb.co.uk> has joined #libre-soc | 18:01 | |
lkcl | it's calculated relative to the address of the bc instruction | 18:19 |
lkcl | (not to the instruction *after* bc) | 18:19 |
lkcl | it's actually in the spec. | 18:19 |
lkcl | CIA - Current Instruction Address | 18:19 |
lkcl | not | 18:19 |
lkcl | NIA - Next Instruction Address | 18:19 |
lkcl | octavius, yes - you can create a udev rule to grant permissions. there's a number of examples already on the wiki. it's pretty standard practice, there are also plenty examples on the internet | 18:33 |
lkcl | search "udev rules ftdi" | 18:34 |
lkcl | use "lsusb" to find the ID | 18:34 |
octavius | Ah, thanks lkcl! | 18:40 |
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 19:01 | |
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 19:05 | |
ghostmansd | There's one important issue with both our assemblers: it should insert nops to align prefixed instructions correctly. | 19:49 |
ghostmansd | I recall I already met it, but now I had to spend almost hours debugging the generated UTF-8 assembly when I compiled it with -mlibresoc in gas. | 19:51 |
ghostmansd | I'm raising the issue; since I'm currently the only one who is annoyed by this I think the priority is not high. But we have to address it eventually. | 19:51 |
ghostmansd | Also, I'll raise issues on macros subsystem, and on labels. | 19:52 |
ghostmansd | Since both alignment and labels need some form of PC bookkeping, these are somewhat related. | 19:52 |
programmerjake | all we need is 4-byte alignment, and maybe the restriction that a svp64 instruction can't cross a 64-byte block boundary (imho that restriction should be relaxed since it makes compilers and assemblers easier and it reduces code size -- though it does make instruction fetch a little more complex in the specific case where L1 i-cache blocks are exactly 64 bytes no more no less, other cache block sizes still need most the additional | 19:59 |
programmerjake | circuitry) | 19:59 |
ghostmansd | I meant 64-byte block | 20:08 |
ghostmansd | gas inserts these, and I want our assembler to be on par at least in this regard | 20:08 |
ghostmansd | plus that's about being a good citizen :-) | 20:08 |
ghostmansd | https://bugs.libre-soc.org/show_bug.cgi?id=993 | 20:09 |
ghostmansd | https://bugs.libre-soc.org/show_bug.cgi?id=994 | 20:09 |
ghostmansd | https://bugs.libre-soc.org/show_bug.cgi?id=995 | 20:09 |
programmerjake | toshywoshy: afaict openpowerbot stopped relaying messages from/to oftc | 20:21 |
*** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc | 20:23 | |
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 20:30 | |
*** ibot <ibot!~supybot@libre-soc.org> has joined #libre-soc | 20:46 | |
lkcl | ghostmansd, i was not planning to have alignment. | 21:15 |
lkcl | EXT001 has alignment. | 21:15 |
lkcl | SVP64 does not | 21:15 |
programmerjake | maybe we should propose an extension that removes the alignment constraint for all >32-bit instructions? | 21:19 |
programmerjake | including ext001 | 21:19 |
programmerjake | then we could just say our cpu implements that extension | 21:20 |
programmerjake | if we so desired we could say svp64 depends on that extension | 21:20 |
lkcl | ghostmansd, could you remember to always cross-reference bugreports to at least one other bugreport, via "blocks/depends or see-also"? | 21:35 |
lkcl | otherwise bugs get utterly lost as noise, and the only way to find them is via a search. that's if you know they exist, at all. | 21:36 |
*** octavius <octavius!~octavius@92.40.169.30.threembb.co.uk> has quit IRC | 22:03 | |
lkcl | programmerjake, i know why IBM recommended 64-bit alignment: it massively simplifies multi-issue decoding. | 22:11 |
lkcl | trouble is, it has a binary-size penalty | 22:12 |
lkcl | plus, cache-line overlaps are extremely bad | 22:12 |
lkcl | a compromise may be to disallow mis-alignment every 16th word | 22:13 |
lkcl | something like that | 22:13 |
ghostmansd | lkcl, as for SVP64 behaving as non-prefix: it breaks the least astonishment principle | 22:15 |
ghostmansd | Because it's in fact is a prefixed one. Yes I know that officially only EXT001 is blessed for prefixed. | 22:15 |
ghostmansd | I can make binutils output the assembly so that we can cross 64-byte block boundary, but it seems somewhat unintuitive, considering that RM + PO + other bits do indeed constitute an opcode. | 22:17 |
ghostmansd | Anyway, the SVP64 assembly absolutely must be 1:1 between binutils and our home-grown assembler, dot. | 22:18 |
programmerjake | imho the solution to that is to have the 64-byte cache line be split into at least 2 parts where each part is a separate sram, then instruction fetch will read 2 parts at a time, so it's fine if an instruction crosses a cache line boundary because you can just have the first part read be the last part of one cache line and the second part read be the first part of the next cache line | 22:29 |
programmerjake | alternatively you could just store the last 4 bytes of a cache line and decode them when you fetch the next cache line | 22:30 |
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 23:04 | |
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 23:32 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!