Monday, 2023-01-23

*** ghostmansd[m] <ghostmansd[m]!> has quit IRC01:21
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc01:47
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC02:32
*** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has quit IRC02:38
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc03:04
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC03:17
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc03:46
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC03:59
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc04:27
*** Ritish <Ritish!~Ritish@> has joined #libre-soc04:29
Ritishlkcl, I understand, I have screenshots of the output only04:31
RitishBut I was running these set of commands04:31
Ritish## Building microwatt-verilator using the libre-soc core04:31
Ritish  52         cd /path/to/soc04:31
Ritish  53         make microwatt_external_core04:31
Ritish  54         cp external_core_top.v /path/to/microwatt04:31
Ritish  55         cd /path/to/microwatt04:31
Ritish  56         export FPGA_TARGET=verilator04:31
Ritish  57         export GHDLSYNTH=ghdl04:31
Ritish  58         make microwatt-verilator04:31
RitishI think/assume it is related to "building the kernel"04:32
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc04:33
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC04:37
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc05:03
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC05:51
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc05:58
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC06:08
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc06:25
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC06:28
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc06:29
*** toshywoshy <toshywoshy!> has quit IRC06:41
*** toshywoshy <toshywoshy!> has joined #libre-soc06:41
*** openpowerbot <openpowerbot!> has quit IRC06:43
*** toshywoshy <toshywoshy!> has quit IRC06:53
*** toshywoshy <toshywoshy!> has joined #libre-soc06:58
*** ritish_ <ritish_!~Ritish@> has joined #libre-soc07:03
*** Ritish <Ritish!~Ritish@> has quit IRC07:03
*** toshywoshy <toshywoshy!> has quit IRC07:04
*** toshywoshy <toshywoshy!> has joined #libre-soc07:06
*** toshywoshy <toshywoshy!> has quit IRC07:11
*** toshywoshy <toshywoshy!> has joined #libre-soc07:12
*** ghostmansd <ghostmansd!> has joined #libre-soc07:18
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC07:24
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc07:24
*** toshywoshy <toshywoshy!> has quit IRC07:28
*** toshywoshy <toshywoshy!> has joined #libre-soc07:40
*** ritish_ <ritish_!~Ritish@> has quit IRC07:53
*** ritish_ <ritish_!~Ritish@> has joined #libre-soc07:56
*** ritish_ is now known as Ritish07:57
*** toshywoshy <toshywoshy!> has quit IRC08:33
*** toshywoshy <toshywoshy!> has joined #libre-soc08:44
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC08:55
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc09:57
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC10:14
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc10:44
lkclthen 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 kernel11:29
lkclas 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 IRC11:33
*** doppo <doppo!~doppo@2604:180::e0fc:a07f> has joined #libre-soc11:36
Ritishoh no, I thought I was building a microwatt-verilator branch11:53
Ritishmy bad :/11:57
Ritishdo we not require microwatt-verilator for what we're about to do?11:58
RitishI'd really like if we could schedule a meeting and I could clarify "all" my doubts LOL11:59
Ritishbecause now it's just confusion kinda11:59
*** Ritish <Ritish!~Ritish@> has quit IRC12:00
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC12:00
lkclmicrowatt-verilator is the HDL.12:12
lkclwhy would the linux kernel be included in the HDL???12:12
lkclhas someone converted the linux kernel into VHDL??12:13
lkcland not told me, or told you?12:13
lkclwhy 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
lkclcan i suggest and recommend that you separate those two concepts in your mind?12:14
lkclit 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
lkcland to further understand that this does **NOT** repeat **NOT** imply "and also you then need the microwatt linux 5.7 application"12:15
lkclif 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
lkclinstead 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
lkclat the pace that you get things running it will add 3-4 weeks to the completion time.12:20
*** Ritish <Ritish!~Ritish@> has joined #libre-soc12:52
Ritishi understand. I will try revisiting things from the start and maybe do a miracle, thanks12:55
RitishI did not know that this code is involved in the creation or has something to do with the kernel12:56
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc12:57
RitishI only mentioned that I "thought" the error was related to the kernel13:01
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC13:06
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc13:07
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC13:31
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc13:36
RitishThat aside, I was just exploring open source verification tools, any good recommends?14:51
*** Ritish <Ritish!~Ritish@> has quit IRC15:16
*** octavius <octavius!> has joined #libre-soc15:33
octaviuslkcl, when you tested ls2 last week, were you able to program the arty a7-100t board?15:39
octaviusTo make sure I'm following the scripts, I created a fresh chroot for programming.15:39
octaviusmk-deb-chroot, cp-scripts-to-chroot, then fpga-boot-load-prog-install inside chroot.15:39
octaviusAfter 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
octaviusxc3sprog -c nexys4 attosoc.bit15:39
octaviusCould not open FTDI device (using libftdi): device not found15:39
octaviusUnable to access FTDI device with either libftdi or FTD2XX15:39
octaviusHave you encountered this issue with xc3sprog and libftdi?15:39
octaviusOr am I missing something with the board itself? I also tried while pressing down the PROG pushbutton.15:40
octaviusChecking devices, I can see ttyUSB0 and ttyUSB1 are present15:41
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC15:42
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc15:42
octaviusFigured it out, my user didn't have permissions, root worked15:45
octaviusAs user, when trying openFPGALoader -b arty_a7_100t --detect, got15:46
octaviusunable to open ftdi device: -4 (usb_open() failed)15:46
octaviusJTAG init failed with: unable to open ftdi device15:46
octaviusI was able to get ls2 to build and upload bitstream (as root). Serial terminal is printing the Microwatt hello world :)16:15
*** octavius <octavius!> has quit IRC16:27
ghostmansdprogrammerjake, could you, please, help me with the way to run only one UTF-8 tests? They take an eternity to complete.16:47
ghostmansdI just would like to check whether the assembly I modified works (`def assemble(instructions, start_pc=0):` call)16:48
lkclghostmansd, you can either hack the unit test to rename functions, leaving just the one that you want to run17:06
lkclthere 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
ghostmansdI wish I could follow this, it was naturally the very first idea I thought of. But...17:06
ghostmansdThe tests are generated.17:06
ghostmansdNames are like
lkcli 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
ghostmansdNot even a slightest ida which place to hack. :-)17:07
ghostmansdAnyway, I decided to go with an alternative way: `raise 1` at the function that generates the assembly.17:07
lkclfind . -name "*.py" | grep utf817:07
lkclbest hacks are the ones you write yourself :)17:08
ghostmansdI'm not sure what'd be the address for the label. Still checking this.17:08
ghostmansdSay 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
ghostmansdWhat'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]!> has quit IRC17:50
*** octavius <octavius!> has joined #libre-soc18:01
lkclit's calculated relative to the address of the bc instruction18:19
lkcl(not to the instruction *after* bc)18:19
lkclit's actually in the spec.18:19
lkclCIA - Current Instruction Address18:19
lkclNIA - Next Instruction Address18:19
lkcloctavius, 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 internet18:33
lkclsearch "udev rules ftdi"18:34
lkcluse "lsusb" to find the ID18:34
octaviusAh, thanks lkcl!18:40
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc19:01
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC19:05
ghostmansdThere's one important issue with both our assemblers: it should insert nops to align prefixed instructions correctly.19:49
ghostmansdI 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
ghostmansdI'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
ghostmansdAlso, I'll raise issues on macros subsystem, and on labels.19:52
ghostmansdSince both alignment and labels need some form of PC bookkeping, these are somewhat related.19:52
programmerjakeall 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 additional19:59
ghostmansdI meant 64-byte block20:08
ghostmansdgas inserts these, and I want our assembler to be on par at least in this regard20:08
ghostmansdplus that's about being a good citizen :-)20:08
programmerjaketoshywoshy: afaict openpowerbot stopped relaying messages from/to oftc20:21
*** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc20:23
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc20:30
*** ibot <ibot!> has joined #libre-soc20:46
lkclghostmansd, i was not planning to have alignment.21:15
lkclEXT001 has alignment.21:15
lkclSVP64 does not21:15
programmerjakemaybe we should propose an extension that removes the alignment constraint for all >32-bit instructions?21:19
programmerjakeincluding ext00121:19
programmerjakethen we could just say our cpu implements that extension21:20
programmerjakeif we so desired we could say svp64 depends on that extension21:20
lkclghostmansd, could you remember to always cross-reference bugreports to at least one other bugreport, via "blocks/depends or see-also"?21:35
lkclotherwise 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!> has quit IRC22:03
lkclprogrammerjake, i know why IBM recommended 64-bit alignment: it massively simplifies multi-issue decoding.22:11
lkcltrouble is, it has a binary-size penalty22:12
lkclplus, cache-line overlaps are extremely bad22:12
lkcla compromise may be to disallow mis-alignment every 16th word22:13
lkclsomething like that22:13
ghostmansdlkcl, as for SVP64 behaving as non-prefix: it breaks the least astonishment principle22:15
ghostmansdBecause it's in fact is a prefixed one. Yes I know that officially only EXT001 is blessed for prefixed.22:15
ghostmansdI 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
ghostmansdAnyway, the SVP64 assembly absolutely must be 1:1 between binutils and our home-grown assembler, dot.22:18
programmerjakeimho 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 line22:29
programmerjakealternatively you could just store the last 4 bytes of a cache line and decode them when you fetch the next cache line22:30
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC23:04
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc23:32

Generated by 2.17.1 by Marius Gedminas - find it at!