From colepoirier at gmail.com Mon Mar 1 17:53:20 2021 From: colepoirier at gmail.com (Cole Poirier) Date: Mon, 1 Mar 2021 09:53:20 -0800 Subject: [Libre-soc-dev] Luke: jtag testing Message-ID: Hi Luke, A reminder that I need your input on the jtag setup (https://bugs.libre-soc.org/show_bug.cgi?id=517) and jtag testing (https://bugs.libre-soc.org/show_bug.cgi?id=605) bug reports and cannot proceed any further until you comment. Cole From libre-soc at platen-software.de Mon Mar 1 18:04:58 2021 From: libre-soc at platen-software.de (Tobias Platen) Date: Mon, 1 Mar 2021 19:04:58 +0100 Subject: [Libre-soc-dev] daily kan-ban update 01mar2021 Message-ID: <20210301190458.ce64a3741594e1c0a2118cf3@platen-software.de> today: more work on MMU integration -- Tobias Platen From lkcl at lkcl.net Mon Mar 1 18:55:05 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 1 Mar 2021 18:55:05 +0000 Subject: [Libre-soc-dev] Luke: jtag testing In-Reply-To: References: Message-ID: On Mon, Mar 1, 2021 at 5:53 PM Cole Poirier wrote: > A reminder that I need your input on the jtag setup > (https://bugs.libre-soc.org/show_bug.cgi?id=517) and jtag testing > (https://bugs.libre-soc.org/show_bug.cgi?id=605) bug reports and > cannot proceed any further until you comment. got it. the FPGA and ASIC variant is near-identical, it should be clear to substitute "FPGA" for "sim.py". also there are soc.debug utils such as this https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/debug/firmware_upload.py;hb=HEAD l. From lkcl at lkcl.net Mon Mar 1 19:08:30 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 1 Mar 2021 19:08:30 +0000 Subject: [Libre-soc-dev] daily kan-ban update 01mar2021 In-Reply-To: <20210301190458.ce64a3741594e1c0a2118cf3@platen-software.de> References: <20210301190458.ce64a3741594e1c0a2118cf3@platen-software.de> Message-ID: On Mon, Mar 1, 2021 at 6:05 PM Tobias Platen wrote: > > today: more work on MMU integration great. my feeling is that it's going to be easier to have something side-by-side to compare against (ISACaller) you _could_ stare manually for hours at debug logs. an alternative is to get ISACaller RADIX support added, then let simulations do all the work. l. From libre-soc at platen-software.de Mon Mar 1 19:22:16 2021 From: libre-soc at platen-software.de (Tobias Platen) Date: Mon, 1 Mar 2021 20:22:16 +0100 Subject: [Libre-soc-dev] daily kan-ban update 01mar2021 In-Reply-To: References: <20210301190458.ce64a3741594e1c0a2118cf3@platen-software.de> Message-ID: <20210301202216.32275832650b303122706813@platen-software.de> On Mon, 1 Mar 2021 19:08:30 +0000 Luke Kenneth Casson Leighton wrote: > On Mon, Mar 1, 2021 at 6:05 PM Tobias Platen > wrote: > > > > today: more work on MMU integration > > great. my feeling is that it's going to be easier to have something > side-by-side to compare against (ISACaller) you _could_ stare > manually for hours at debug logs. an alternative is to get ISACaller > RADIX support added, then let simulations do all the work. > > l. After adding the RADIX support, I can do faster debugging. Today I found out that the "fix" for #607 causes my unit test to break. I also know that there are more bugs in my code, that need to be debugged first. > _______________________________________________ > Libre-soc-dev mailing list > Libre-soc-dev at lists.libre-soc.org > http://lists.libre-soc.org/mailman/listinfo/libre-soc-dev From lkcl at lkcl.net Mon Mar 1 19:36:12 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 1 Mar 2021 19:36:12 +0000 Subject: [Libre-soc-dev] daily kan-ban update 01mar2021 In-Reply-To: <20210301202216.32275832650b303122706813@platen-software.de> References: <20210301190458.ce64a3741594e1c0a2118cf3@platen-software.de> <20210301202216.32275832650b303122706813@platen-software.de> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Mon, Mar 1, 2021 at 7:22 PM Tobias Platen wrote: > > On Mon, 1 Mar 2021 19:08:30 +0000 > Luke Kenneth Casson Leighton wrote: > > > On Mon, Mar 1, 2021 at 6:05 PM Tobias Platen > > wrote: > > > > > > today: more work on MMU integration > > > > great. my feeling is that it's going to be easier to have something > > side-by-side to compare against (ISACaller) you _could_ stare > > manually for hours at debug logs. an alternative is to get ISACaller > > RADIX support added, then let simulations do all the work. > > > > l. > After adding the RADIX support, I can do faster debugging. > Today I found out that the "fix" for #607 causes my unit test to break. 2730d379d0 - rom mmu test works (doesn't end, but works) > I also know that there are more bugs in my code, that need to be debugged first. understood. ok what's going on. lkcl at fizzy:~/src/libresoc/soc/src/soc$ grep -r mmu0_spr_dec simple/core.py: self.decoders["mmu0"].mmu0_spr_dec = self.decoders["spr0"] ah. right. this is a bad hack :) it needs special commenting and an explanation. i've reverted this below for now: - if self.fn_name=="MMU": - # mmu is special case: needs SPR opcode as well - mmu0 = self.mmu0_spr_dec - with m.If(((mmu0.dec.op.internal_op == MicrOp.OP_MTSPR) | - (mmu0.dec.op.internal_op == MicrOp.OP_MFSPR))): - comb += self.do_copy("insn_type", mmu0.op_get("internal_op")) - with m.Else(): - comb += self.do_copy("insn_type", self.op_get("internal_op")) - else: - comb += self.do_copy("insn_type", self.op_get("internal_op")) + # FIX https://bugs.libre-soc.org/show_bug.cgi?id=607 + comb += self.do_copy("insn_type", self.op_get("internal_op")) From colepoirier at gmail.com Mon Mar 1 19:48:39 2021 From: colepoirier at gmail.com (Cole Poirier) Date: Mon, 1 Mar 2021 11:48:39 -0800 Subject: [Libre-soc-dev] Luke: jtag testing In-Reply-To: References: Message-ID: On Monday, March 1, 2021, Luke Kenneth Casson Leighton wrote: > > jtag setup > > (https://bugs.libre-soc.org/show_bug.cgi?id=517) > > got it. the FPGA and ASIC variant is near-identical, it should be > clear to substitute "FPGA" for "sim.py". also there are soc.debug > utils such as this > https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/ > debug/firmware_upload.py;hb=HEAD > Great thank you! Before I proceed to jtag testing can you please review and mark the above jtag setup wiki page bug as resolved if you are satisfied that the instructions there will not lead to the fpga shorting and releasing it’s magic computer gas ;) Cole From lkcl at lkcl.net Mon Mar 1 23:12:13 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 1 Mar 2021 23:12:13 +0000 Subject: [Libre-soc-dev] nlnet cryptorouter through to interactive 1st round Message-ID: the crypto-router application is through to the interactive round. this means putting together a set of project milestones will be needed in a few weeks, in the meantime there will be questions to answer after first phase review. l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From luke.leighton at gmail.com Tue Mar 2 11:05:47 2021 From: luke.leighton at gmail.com (lkcl) Date: Tue, 2 Mar 2021 11:05:47 +0000 Subject: [Libre-soc-dev] New instruction In-Reply-To: <20210302101421.GB2606@phcomp.co.uk> References: <20210302101421.GB2606@phcomp.co.uk> Message-ID: (top-posting to preserve message, hope you don't mind alain) we shouuuuld already have that covered, through v3.0 Floating Round to Integer Nearest X-form 4.6.7.3 Floating Round to Integer Instructions v3.0C p163 On Tuesday, March 2, 2021, Alain D D Williams wrote: > This is one for the TODO bucket but it does suggest that a look at what other > processor vendors are doing might be useful. > > ARMv8.3-A has a new instruction that is supposed to make Javascript 0.5% to 2% faster. > > FJCVTZS - Floating-point Javascript Convert to Signed fixed-point, rounding toward Zero. > > It converts Javascript numbers (doubles - IEEE754 64 bit) to 32 bit int and > sets the condition registers on overflow, ... especially good when doing AES & > SHA256 (not that I thought that a lot of that was done in Javascript, but > apparently it is). > > https://developer.arm.com/documentation/dui0801/g/A64-Floating-point-Instructions/FJCVTZS > > https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/armv8-a-architecture-2016-additions > > https://bugzilla.mozilla.org/show_bug.cgi?id=1433126 > > https://www.worksonarm.com/blog/woa-issue-70/ > > -- > Alain Williams > Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. > +44 (0) 787 668 0256 https://www.phcomp.co.uk/ > Parliament Hill Computers Ltd. Registration Information: https://www.phcomp.co.uk/Contact.html > #include > From luke.leighton at gmail.com Tue Mar 2 16:05:52 2021 From: luke.leighton at gmail.com (lkcl) Date: Tue, 2 Mar 2021 16:05:52 +0000 Subject: [Libre-soc-dev] New instruction In-Reply-To: References: <20210302101421.GB2606@phcomp.co.uk> Message-ID: Floating Round to Integer Toward Zero X-form friz FRT,FRB (Rc=0) lol. great name. friz. like the hairdo. my numbers have been frizzed :) On Tuesday, March 2, 2021, lkcl wrote: > (top-posting to preserve message, hope you don't mind alain) > > we shouuuuld already have that covered, through v3.0 > > > Floating Round to Integer Nearest X-form > > 4.6.7.3 Floating Round to Integer Instructions > > v3.0C p163 > > > > On Tuesday, March 2, 2021, Alain D D Williams wrote: >> This is one for the TODO bucket but it does suggest that a look at what other >> processor vendors are doing might be useful. >> >> ARMv8.3-A has a new instruction that is supposed to make Javascript 0.5% to 2% faster. >> >> FJCVTZS - Floating-point Javascript Convert to Signed fixed-point, rounding toward Zero. >> >> It converts Javascript numbers (doubles - IEEE754 64 bit) to 32 bit int and >> sets the condition registers on overflow, ... especially good when doing AES & >> SHA256 (not that I thought that a lot of that was done in Javascript, but >> apparently it is). >> >> https://developer.arm.com/documentation/dui0801/g/A64-Floating-point-Instructions/FJCVTZS >> >> https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/armv8-a-architecture-2016-additions >> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1433126 >> >> https://www.worksonarm.com/blog/woa-issue-70/ >> >> -- >> Alain Williams >> Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. >> +44 (0) 787 668 0256 https://www.phcomp.co.uk/ >> Parliament Hill Computers Ltd. Registration Information: https://www.phcomp.co.uk/Contact.html >> #include >> From libre-soc at platen-software.de Tue Mar 2 17:23:46 2021 From: libre-soc at platen-software.de (Tobias Platen) Date: Tue, 2 Mar 2021 18:23:46 +0100 Subject: [Libre-soc-dev] daily kan-ban update 02mar2021 Message-ID: <20210302182346.18ecb00e956a5e410b8995ac@platen-software.de> today: having a look into ISACaller. I want to get ISACaller RADIX support added, then let simulations do all the work. -- Tobias Platen From programmerjake at gmail.com Tue Mar 2 17:52:49 2021 From: programmerjake at gmail.com (Jacob Lifshay) Date: Tue, 2 Mar 2021 09:52:49 -0800 Subject: [Libre-soc-dev] New instruction In-Reply-To: References: <20210302101421.GB2606@phcomp.co.uk> Message-ID: On Tue, Mar 2, 2021, 03:06 lkcl wrote: > (top-posting to preserve message, hope you don't mind alain) > > we shouuuuld already have that covered, through v3.0 > > > Floating Round to Integer Nearest X-form > the one you wanted is the round towards zero version, though even that is not correct for javascript. > 4.6.7.3 Floating Round to Integer Instructions > > v3.0C p163 > Except that Javascript has different semantics for conversion from f64 -> i32: it is a wrapping conversion instead of the saturating conversion used by most cpus. https://262.ecma-international.org/#sec-toint32 translation to C (assuming I didn't make a mistake): int32_t js_cvt(double v) { if(!isfinite(v)) return 0; v = trunc(v); v = fmod(v, 1LL << 32); if(v < 0) v += 1LL << 32; // now v is an integer in the range 0 to 2^32 - 1 if(v >= (1LL << 31)) v -= 1LL << 32; // now v is an integer in the range -(2^31) to 2^31 - 1 return (int32_t)v; } Jacob From lkcl at lkcl.net Tue Mar 2 17:53:30 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 2 Mar 2021 17:53:30 +0000 Subject: [Libre-soc-dev] daily kan-ban update 02mar2021 In-Reply-To: <20210302182346.18ecb00e956a5e410b8995ac@platen-software.de> References: <20210302182346.18ecb00e956a5e410b8995ac@platen-software.de> Message-ID: On Tuesday, March 2, 2021, Tobias Platen wrote: > today: having a look into ISACaller. I want to get ISACaller > RADIX support added, then let simulations do all the work. excellent. do add it as a function or separate class, one that has the same API as the Mem class: https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/decoder/isa/caller.py;h=acaac1f7212c68c9c631d1626adc470f7fa5751f;hb=HEAD#l78 do not add RADIX *to* class Mem, treat that as physical RAM used *BY* the (new) RADIX Mem class. give RADIX Mem class the exact same API as Mem. the RADIX Mem class *calls* Mem.ld and Mem.st this is exactly how qemu does it. then it is possible to drop in either and none of the unit tests get disrupted. l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From lkcl at lkcl.net Tue Mar 2 17:55:37 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 2 Mar 2021 17:55:37 +0000 Subject: [Libre-soc-dev] New instruction In-Reply-To: References: <20210302101421.GB2606@phcomp.co.uk> Message-ID: On Tuesday, March 2, 2021, Jacob Lifshay wrote: > >> 4.6.7.3 Floating Round to Integer Instructions >> >> v3.0C p163 >> > > Except that Javascript has different semantics for conversion from f64 -> > i32: > it is a wrapping conversion instead of the saturating conversion used by > most cpus. urr fer god's sake. that means it's running a divide operation. and everyone loves javascript, don't they. sigh :) l . -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From libre-soc at platen-software.de Tue Mar 2 18:05:20 2021 From: libre-soc at platen-software.de (Tobias Platen) Date: Tue, 2 Mar 2021 19:05:20 +0100 Subject: [Libre-soc-dev] daily kan-ban update 02mar2021 In-Reply-To: References: <20210302182346.18ecb00e956a5e410b8995ac@platen-software.de> Message-ID: <20210302190520.c0d4a0145b1849023a266f81@platen-software.de> On Tue, 2 Mar 2021 17:53:30 +0000 Luke Kenneth Casson Leighton wrote: > On Tuesday, March 2, 2021, Tobias Platen > wrote: > > today: having a look into ISACaller. I want to get ISACaller > > RADIX support added, then let simulations do all the work. > > excellent. > > do add it as a function or separate class, one that has the same API as the > Mem class: > > https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/decoder/isa/caller.py;h=acaac1f7212c68c9c631d1626adc470f7fa5751f;hb=HEAD#l78 > > do not add RADIX *to* class Mem, treat that as physical RAM used *BY* the > (new) RADIX Mem class. > > give RADIX Mem class the exact same API as Mem. > > the RADIX Mem class *calls* Mem.ld and Mem.st > > this is exactly how qemu does it. > > > then it is possible to drop in either and none of the unit tests get > disrupted. > > l. > I'll make it so. > > -- > --- > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 > _______________________________________________ > Libre-soc-dev mailing list > Libre-soc-dev at lists.libre-soc.org > http://lists.libre-soc.org/mailman/listinfo/libre-soc-dev -- Tobias Platen From programmerjake at gmail.com Tue Mar 2 18:11:19 2021 From: programmerjake at gmail.com (Jacob Lifshay) Date: Tue, 2 Mar 2021 10:11:19 -0800 Subject: [Libre-soc-dev] New instruction In-Reply-To: References: <20210302101421.GB2606@phcomp.co.uk> Message-ID: On Tue, Mar 2, 2021, 09:56 Luke Kenneth Casson Leighton wrote: > On Tuesday, March 2, 2021, Jacob Lifshay wrote: > > > > >> 4.6.7.3 Floating Round to Integer Instructions > >> > >> v3.0C p163 > >> > > > > Except that Javascript has different semantics for conversion from f64 -> > > i32: > > it is a wrapping conversion instead of the saturating conversion used by > > most cpus. > > urr fer god's sake. that means it's running a divide operation. > no... it turns into a single shift and mask operation at the HW level...such is the fate of division by a constant power of 2. > > and everyone loves javascript, don't they. sigh :) Yup. Wasm adoption should help there somewhat...though not right now. Jacob From lkcl at lkcl.net Tue Mar 2 18:23:03 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 2 Mar 2021 18:23:03 +0000 Subject: [Libre-soc-dev] New instruction In-Reply-To: References: <20210302101421.GB2606@phcomp.co.uk> Message-ID: On Tuesday, March 2, 2021, Jacob Lifshay wrote: > no... it turns into a single shift and mask operation at the HW > level...such is the fate of division by a constant power of 2. v = fmod(v, 1LL << 32); ah wheww. a subtract on the exponent, looping minus 32 each time. that's tolerable. still absolutely dreadful, mind. l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From programmerjake at gmail.com Tue Mar 2 19:45:05 2021 From: programmerjake at gmail.com (Jacob Lifshay) Date: Tue, 2 Mar 2021 11:45:05 -0800 Subject: [Libre-soc-dev] New instruction In-Reply-To: References: <20210302101421.GB2606@phcomp.co.uk> Message-ID: On Tue, Mar 2, 2021, 10:23 Luke Kenneth Casson Leighton wrote: > On Tuesday, March 2, 2021, Jacob Lifshay wrote: > > > no... it turns into a single shift and mask operation at the HW > > level...such is the fate of division by a constant power of 2. > > v = fmod(v, 1LL << 32); > > ah wheww. > > a subtract on the exponent, looping minus 32 each time. that's tolerable. > still absolutely dreadful, mind. > umm...that's still waay less efficient than can be done with a shift: https://gcc.godbolt.org/z/4KPxxh int32_t js_cvt(double v) { union { double f; uint64_t i; } u; u.f = v; const uint64_t EXPONENT_FIELD = 0x7FF0'0000'0000'0000ULL; const int EXPONENT_BIAS = 0x3FF; const int EXPONENT_MAX = 0x7FF; const int MANTISSA_FIELD_WIDTH = 52; const uint64_t MANTISSA_FIELD = (1ULL << MANTISSA_FIELD_WIDTH) - 1; int exponent = (u.i & EXPONENT_FIELD) >> MANTISSA_FIELD_WIDTH; if(exponent == EXPONENT_MAX) // inf, -inf, or nan return 0; uint64_t mantissa = (u.i & MANTISSA_FIELD) | (1ULL << MANTISSA_FIELD_WIDTH); int mantissa_shift = exponent - EXPONENT_BIAS - MANTISSA_FIELD_WIDTH; if(mantissa_shift <= -64) // shift all bits out, leaving only zeros return 0; if(mantissa_shift >= 64) // shift all bits out, leaving only zeros return 0; if(mantissa_shift < 0) mantissa >>= -mantissa_shift; else mantissa <<= mantissa_shift; if(v < 0) mantissa = -mantissa; return (int32_t)mantissa; // wrap to int32_t } Jacob From libre-soc at platen-software.de Wed Mar 3 17:12:34 2021 From: libre-soc at platen-software.de (Tobias Platen) Date: Wed, 3 Mar 2021 18:12:34 +0100 Subject: [Libre-soc-dev] daily kan-ban update 03mar2021 Message-ID: <20210303181234.026700213bac99d0139b843b@platen-software.de> today: working on a class RADIX that looks like this class RADIX: def __init__(self,mem): self.mem = mem def ld(self, address, width=8, swap=True, check_in_mem=False): print("RADIX: ld from addr 0x{:x} width {:d}".format(address, width)) -- Tobias Platen From lkcl at lkcl.net Wed Mar 3 18:02:54 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 3 Mar 2021 18:02:54 +0000 Subject: [Libre-soc-dev] daily kan-ban update 03mar2021 In-Reply-To: <20210303181234.026700213bac99d0139b843b@platen-software.de> References: <20210303181234.026700213bac99d0139b843b@platen-software.de> Message-ID: On Wednesday, March 3, 2021, Tobias Platen wrote: > today: working on a class RADIX that looks like this cool. you will also need to pass in the ISACaller itself, to be able to access the SPRs. also to be able to call the ISACaller.TRAP function on LD/ST exceptions. > class RADIX: > def __init__(self,mem): > self.mem = mem ..... (self, mem, caller) self.caller = caller > > def ld(self, address, width=8, swap=True, check_in_mem=False): > print("RADIX: ld from addr 0x{:x} width {:d}".format(address, width)) perfect > > -- > Tobias Platen > > _______________________________________________ > Libre-soc-dev mailing list > Libre-soc-dev at lists.libre-soc.org > http://lists.libre-soc.org/mailman/listinfo/libre-soc-dev > -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From libre-soc at platen-software.de Wed Mar 3 18:28:15 2021 From: libre-soc at platen-software.de (Tobias Platen) Date: Wed, 3 Mar 2021 19:28:15 +0100 Subject: [Libre-soc-dev] daily kan-ban update 03mar2021 In-Reply-To: References: <20210303181234.026700213bac99d0139b843b@platen-software.de> Message-ID: <20210303192815.3e5a95a83876ca267cbce8b5@platen-software.de> On Wed, 3 Mar 2021 18:02:54 +0000 Luke Kenneth Casson Leighton wrote: > will also need to pass in the ISACaller itself, to be able to access > the SPRs. also to be able to call the ISACaller.TRAP function on LD/ST > exceptions. > > > class RADIX: > > def __init__(self,mem): > > self.mem = mem pushed a first skeleton and unittest -- Tobias Platen From lkcl at lkcl.net Wed Mar 3 19:10:33 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 3 Mar 2021 19:10:33 +0000 Subject: [Libre-soc-dev] daily kan-ban update 03mar2021 In-Reply-To: <20210303192815.3e5a95a83876ca267cbce8b5@platen-software.de> References: <20210303181234.026700213bac99d0139b843b@platen-software.de> <20210303192815.3e5a95a83876ca267cbce8b5@platen-software.de> Message-ID: On Wednesday, March 3, 2021, Tobias Platen wrote: > On Wed, 3 Mar 2021 18:02:54 +0000 > Luke Kenneth Casson Leighton wrote: > >> will also need to pass in the ISACaller itself, to be able to access >> the SPRs. also to be able to call the ISACaller.TRAP function on LD/ST >> exceptions. >> >> > class RADIX: >> > def __init__(self,mem): >> > self.mem = mem > pushed a first skeleton and unittest https://git.libre-soc.org/?p=soc.git;a=commitdiff;h=c9f3eb6eca6ef3e7de44e8cb9dd01a84ec3d55b7 nice. hey, the next increment, perhaps you could just pass-through to self.mem.ld and self.mem.st. then it should be a matter of changing the address parameter, later. exceptions are going to be a bit fun. l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From libre-soc at platen-software.de Thu Mar 4 17:03:45 2021 From: libre-soc at platen-software.de (Tobias Platen) Date: Thu, 4 Mar 2021 18:03:45 +0100 Subject: [Libre-soc-dev] daily kan-ban update 04mar2021 Message-ID: <20210304180345.57a0414f7716ec6bb293606d@platen-software.de> today: next increment -- Tobias Platen From lkcl at lkcl.net Thu Mar 4 17:29:19 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 4 Mar 2021 17:29:19 +0000 Subject: [Libre-soc-dev] daily kan-ban update 04mar2021 In-Reply-To: <20210304180345.57a0414f7716ec6bb293606d@platen-software.de> References: <20210304180345.57a0414f7716ec6bb293606d@platen-software.de> Message-ID: On Thursday, March 4, 2021, Tobias Platen wrote: > today: next increment cool. i went over the various implementations https://bugs.libre-soc.org/show_bug.cgi?id=604#c0 replied on the bugtracker. i have had 2 days of calls going over the investor memorandum. almost done. l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From libre-soc at platen-software.de Thu Mar 4 18:03:58 2021 From: libre-soc at platen-software.de (Tobias Platen) Date: Thu, 4 Mar 2021 19:03:58 +0100 Subject: [Libre-soc-dev] daily kan-ban update 04mar2021 In-Reply-To: References: <20210304180345.57a0414f7716ec6bb293606d@platen-software.de> Message-ID: <20210304190358.be2d767f88045fb9366c8857@platen-software.de> On Thu, 4 Mar 2021 17:29:19 +0000 Luke Kenneth Casson Leighton wrote: > On Thursday, March 4, 2021, Tobias Platen > wrote: > > today: next increment > > cool. i went over the various implementations > https://bugs.libre-soc.org/show_bug.cgi?id=604#c0 > > replied on the bugtracker. > > i have had 2 days of calls going over the investor memorandum. almost done. > > l. > Just noticed the last two commits. > -- > --- > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 > _______________________________________________ > Libre-soc-dev mailing list > Libre-soc-dev at lists.libre-soc.org > http://lists.libre-soc.org/mailman/listinfo/libre-soc-dev -- Tobias Platen From lkcl at lkcl.net Thu Mar 4 18:18:45 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 4 Mar 2021 18:18:45 +0000 Subject: [Libre-soc-dev] daily kan-ban update 04mar2021 In-Reply-To: <20210304190358.be2d767f88045fb9366c8857@platen-software.de> References: <20210304180345.57a0414f7716ec6bb293606d@platen-software.de> <20210304190358.be2d767f88045fb9366c8857@platen-software.de> Message-ID: On Thu, Mar 4, 2021 at 6:04 PM Tobias Platen wrote: > Just noticed the last two commits. https://bugs.libre-soc.org/show_bug.cgi?id=604#c6 i wondered why you were using SPR 720 :) i've added PRTBL (a non-standard SPR) to the sprs.csv file, you'll need a git submodule update l. From libre-soc at platen-software.de Fri Mar 5 16:02:17 2021 From: libre-soc at platen-software.de (Tobias Platen) Date: Fri, 5 Mar 2021 17:02:17 +0100 Subject: [Libre-soc-dev] daily kan-ban update 05mar2021 Message-ID: <20210305170217.7337fb678d06652af95a0bce@platen-software.de> today: continue working on https://bugs.libre-soc.org/show_bug.cgi?id=604 I'll start looking at _decode_prte first. -- Tobias Platen From lkcl at lkcl.net Fri Mar 5 16:18:31 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 5 Mar 2021 16:18:31 +0000 Subject: [Libre-soc-dev] daily kan-ban update 05mar2021 In-Reply-To: <20210305170217.7337fb678d06652af95a0bce@platen-software.de> References: <20210305170217.7337fb678d06652af95a0bce@platen-software.de> Message-ID: On Fri, Mar 5, 2021 at 4:02 PM Tobias Platen wrote: > > today: continue working on https://bugs.libre-soc.org/show_bug.cgi?id=604 > I'll start looking at _decode_prte first. ah, i've done it, sorry :) also the _segment_check. do you want to do the perm_check one? bear in mind these have to be in *BE* order because SelectableInt does BE. you have to subtract (WIDTH-1-NNN) l. From lkcl at lkcl.net Fri Mar 5 16:29:35 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 5 Mar 2021 16:29:35 +0000 Subject: [Libre-soc-dev] daily kan-ban update 05mar2021 In-Reply-To: References: <20210305170217.7337fb678d06652af95a0bce@platen-software.de> Message-ID: remember to keep a close eye on the bugtracker comments, tobias, and "git pull" regularly. https://bugs.libre-soc.org/show_bug.cgi?id=604#c7 comment 7 you can see i already mentioned i had completed _decode_prte a couple of hours before your message. l. --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Fri, Mar 5, 2021 at 4:18 PM Luke Kenneth Casson Leighton wrote: > > On Fri, Mar 5, 2021 at 4:02 PM Tobias Platen > wrote: > > > > today: continue working on https://bugs.libre-soc.org/show_bug.cgi?id=604 > > I'll start looking at _decode_prte first. > > ah, i've done it, sorry :) also the _segment_check. > > do you want to do the perm_check one? > > bear in mind these have to be in *BE* order because SelectableInt does > BE. you have to subtract (WIDTH-1-NNN) > > l. From libre-soc at platen-software.de Fri Mar 5 16:40:29 2021 From: libre-soc at platen-software.de (Tobias Platen) Date: Fri, 5 Mar 2021 17:40:29 +0100 Subject: [Libre-soc-dev] daily kan-ban update 05mar2021 In-Reply-To: References: <20210305170217.7337fb678d06652af95a0bce@platen-software.de> Message-ID: <20210305174029.4f10c89fac561cc927dfbc30@platen-software.de> On Fri, 5 Mar 2021 16:29:35 +0000 Luke Kenneth Casson Leighton wrote: > remember to keep a close eye on the bugtracker comments, tobias, and > "git pull" regularly. > https://bugs.libre-soc.org/show_bug.cgi?id=604#c7 > > comment 7 you can see i already mentioned i had completed _decode_prte > a couple of hours before your message. I was busy with other things at that time. I keep my mail program open, and do a git pull regularly. > > l. > > --- > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 > > On Fri, Mar 5, 2021 at 4:18 PM Luke Kenneth Casson Leighton > wrote: > > > > On Fri, Mar 5, 2021 at 4:02 PM Tobias Platen > > wrote: > > > > > > today: continue working on https://bugs.libre-soc.org/show_bug.cgi?id=604 > > > I'll start looking at _decode_prte first. > > > > ah, i've done it, sorry :) also the _segment_check. > > > > do you want to do the perm_check one? > > > > bear in mind these have to be in *BE* order because SelectableInt does > > BE. you have to subtract (WIDTH-1-NNN) > > > > l. > > _______________________________________________ > Libre-soc-dev mailing list > Libre-soc-dev at lists.libre-soc.org > http://lists.libre-soc.org/mailman/listinfo/libre-soc-dev -- Tobias Platen From lkcl at lkcl.net Sun Mar 7 13:24:51 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 7 Mar 2021 13:24:51 +0000 Subject: [Libre-soc-dev] Libre-SOC SVP64 first Cray-style Vector loop successful Message-ID: with many thanks and congratulations to Cesar for getting the first basic Cray-style Vector Loop operational in HDL, on top of OpenPOWER v3.0B and passing its first unit tests. https://git.libre-soc.org/?p=soc.git;a=commitdiff;h=97136d71397f420479d601dcb80f0df4abf73d22 the Simulator ISACaller was functional three weeks ago and has been used to verify the HDL's functionality through co-simulation: https://git.libre-soc.org/?p=soc.git;a=commitdiff;h=9078b2935beb4ba89dcd2af91bb5e3a0bcffbe71 the unit tests for the ADD pipeline will build up progressively over time to give operational confidence (extended later with Formal Correctness Proofs). other pipelines will have their own extensive tests as well. https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/fu/alu/test/svp64_cases.py;hb=HEAD the unit tests which are deliberately well-commented serve as examples to demonstrate the SVP64 Vectorisation principle. however the hardware unit tests themselves rely on the python-based Simulator, ISACaller, which is co-simulated (above) and so iw not immediately obvious what is occurring. for more explicit unit tests, these are more appropriate: https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/decoder/isa/test_caller_svp64.py;hb=HEAD above is "sv.add." for example which enables Vectorised Rc=1, producing a *Vector* of CR fields that are explicitly verified in the test. this allows, (unlike VSX which only creates CR6) inherently far greater parallelism (64 computations per clock cycle per issue) without Condition Register Hazards occurring. with the ISACaller Simulator having rigorous explicit checking of output, this engenders confidence in co-simulation to simply extract and compare the entire contents of all regfiles from both ISACaller and HDL, after each step. an identical co-simulation process is planned to be applied for qemu, power-gem5 and Microwatt when adding SVP64. qemu co-simulation of OpenPOWER v3.0B is *already* performed (and has found obscure bugs in qemu!) our next steps are to add: * LD/ST and other pipeline unit tests * Single and Twin Predication * Polymorphic Element Width overrides (uint8/16/32, FP16, BF16) * Saturation, Mapreduce, and other advanced modes medium term: * Scalar v3.0B Bitmanipulation extensions suitable for cryptographic, Audio and Video and other uses (Vectorisation of these now comes "for free"!) * Scalar v3.0B IEEE754 FP Transcendentals (SIN, COS, ATAN2, LOG1P) which again become inherently and automatically Vectorised * 3D Texturisation opcodes suitable for Vulkan Khronos Group Compliance longer term: * SV-REMAP provides 2D and 3D Matrix register remapping * Instruction Prefix remapping similar to hardware compression A particularly fascinating and powerful combination of the above involves the planned general-purpose Galois Field multiply operation in the bitmanipulation extension, with REMAP Matrix applied, from which Rijndael (AES) "MixColumns" functionality emerges *as a single instruction* without requiring that to be added as an explicit opcode as would normally be done in any other ISA. all of this is achieved without modifying the Scalar OpenPOWER v3.0B ISA in any way, without requiring (eliminating and superceding) any of the SIMD (VSX) ISA, merely adding a new "Vector Context" inside v3.1 style EXT01 64 bit prefixes. we are tracking the implementation progress here, including gcc, power-gem5 and would love to see Microwatt as well, as time permits: https://libre-soc.org/openpower/sv/implementation l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From ganesana at in.ibm.com Sun Mar 7 13:38:14 2021 From: ganesana at in.ibm.com (Ganesan Narayanasamy) Date: Sun, 7 Mar 2021 13:38:14 +0000 Subject: [Libre-soc-dev] Libre-SOC SVP64 first Cray-style Vector loop successful In-Reply-To: Message-ID: Luke and team Amazing and looking forward for more contributions from world wide researchers and developers Sent from my iPhone > On Mar 7, 2021, at 6:55 PM, Luke Kenneth Casson Leighton wrote: > >  > This Message Is From an External Sender > This message came from outside your organization. > with many thanks and congratulations to Cesar for getting the first basic Cray-style Vector Loop operational in HDL, on top of OpenPOWER v3.0B and passing its first unit tests. > > https://git.libre-soc.org/?p=soc.git;a=commitdiff;h=97136d71397f420479d601dcb80f0df4abf73d22 > > the Simulator ISACaller was functional three weeks ago and has been used to verify the HDL's functionality through co-simulation: > > https://git.libre-soc.org/?p=soc.git;a=commitdiff;h=9078b2935beb4ba89dcd2af91bb5e3a0bcffbe71 > > the unit tests for the ADD pipeline will build up progressively over time to give operational confidence (extended later with Formal Correctness Proofs). other pipelines will have their own extensive tests as well. > > https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/fu/alu/test/svp64_cases.py;hb=HEAD > > the unit tests which are deliberately well-commented serve as examples to demonstrate the SVP64 Vectorisation principle. however the hardware unit tests themselves rely on the python-based Simulator, ISACaller, which is co-simulated (above) and so iw not immediately obvious what is occurring. for more explicit unit tests, these are more appropriate: > > https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/decoder/isa/test_caller_svp64.py;hb=HEAD > > above is "sv.add." for example which enables Vectorised Rc=1, producing a *Vector* of CR fields that are explicitly verified in the test. > > this allows, (unlike VSX which only creates CR6) inherently far greater parallelism (64 computations per clock cycle per issue) without Condition Register Hazards occurring. > > with the ISACaller Simulator having rigorous explicit checking of output, this engenders confidence in co-simulation to simply extract and compare the entire contents of all regfiles from both ISACaller and HDL, after each step. > > an identical co-simulation process is planned to be applied for qemu, power-gem5 and Microwatt when adding SVP64. qemu co-simulation of OpenPOWER v3.0B is *already* performed (and has found obscure bugs in qemu!) > > our next steps are to add: > > * LD/ST and other pipeline unit tests > * Single and Twin Predication > * Polymorphic Element Width overrides (uint8/16/32, FP16, BF16) > * Saturation, Mapreduce, and other advanced modes > > medium term: > > * Scalar v3.0B Bitmanipulation extensions suitable for cryptographic, Audio and Video and other uses (Vectorisation of these now comes "for free"!) > * Scalar v3.0B IEEE754 FP Transcendentals (SIN, COS, ATAN2, LOG1P) which again become inherently and automatically Vectorised > * 3D Texturisation opcodes suitable for Vulkan Khronos Group Compliance > > longer term: > > * SV-REMAP provides 2D and 3D Matrix register remapping > * Instruction Prefix remapping similar to hardware compression > > A particularly fascinating and powerful combination of the above involves the planned general-purpose Galois Field multiply operation in the bitmanipulation extension, with REMAP Matrix applied, from which Rijndael (AES) "MixColumns" functionality emerges *as a single instruction* without requiring that to be added as an explicit opcode as would normally be done in any other ISA. > > all of this is achieved without modifying the Scalar OpenPOWER v3.0B ISA in any way, without requiring (eliminating and superceding) any of the SIMD (VSX) ISA, merely adding a new "Vector Context" inside v3.1 style EXT01 64 bit prefixes. > > we are tracking the implementation progress here, including gcc, power-gem5 and would love to see Microwatt as well, as time permits: > > https://libre-soc.org/openpower/sv/implementation > > l. > > > > -- > --- > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 > From vklr at vkten.in Sun Mar 7 16:31:11 2021 From: vklr at vkten.in (Veera) Date: Sun, 7 Mar 2021 22:01:11 +0530 Subject: [Libre-soc-dev] Libre-SOC SVP64 first Cray-style Vector loop successful In-Reply-To: References: Message-ID: <20210307163103.GA5840@lily.local> On Sun, Mar 07, 2021 at 01:24:51PM +0000, Luke Kenneth Casson Leighton wrote: > with many thanks and congratulations to Cesar for getting the first basic > Cray-style Vector Loop operational in HDL, on top of OpenPOWER v3.0B and > passing its first unit tests. > Congratulations to Cesar and team! > the Simulator ISACaller was functional three weeks ago and has been used to > verify the HDL's functionality through co-simulation: > > an identical co-simulation process is planned to be applied for qemu, > power-gem5 and Microwatt when adding SVP64. qemu co-simulation of > OpenPOWER v3.0B is *already* performed (and has found obscure bugs in qemu!) > > our next steps are to add: > > * LD/ST and other pipeline unit tests > * Single and Twin Predication > * Polymorphic Element Width overrides (uint8/16/32, FP16, BF16) > * Saturation, Mapreduce, and other advanced modes > > medium term: > > * Scalar v3.0B Bitmanipulation extensions suitable for cryptographic, Audio > and Video and other uses (Vectorisation of these now comes "for free"!) > * Scalar v3.0B IEEE754 FP Transcendentals (SIN, COS, ATAN2, LOG1P) which > again become inherently and automatically Vectorised > * 3D Texturisation opcodes suitable for Vulkan Khronos Group Compliance > > longer term: > > * SV-REMAP provides 2D and 3D Matrix register remapping > * Instruction Prefix remapping similar to hardware compression > > all of this is achieved without modifying the Scalar OpenPOWER v3.0B ISA in > any way, without requiring (eliminating and superceding) any of the SIMD > (VSX) ISA, merely adding a new "Vector Context" inside v3.1 style EXT01 64 > bit prefixes. > > we are tracking the implementation progress here, including gcc, power-gem5 > and would love to see Microwatt as well, as time permits: > > https://libre-soc.org/openpower/sv/implementation > > l. > Regards, Veera From lkcl at lkcl.net Sun Mar 7 16:50:46 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 7 Mar 2021 16:50:46 +0000 Subject: [Libre-soc-dev] Libre-SOC SVP64 first Cray-style Vector loop successful In-Reply-To: <20210307163103.GA5840@lily.local> References: <20210307163103.GA5840@lily.local> Message-ID: On Sun, Mar 7, 2021 at 4:31 PM Veera wrote: > > On Sun, Mar 07, 2021 at 01:24:51PM +0000, Luke Kenneth Casson Leighton wrote: > > with many thanks and congratulations to Cesar for getting the first basic > > Cray-style Vector Loop operational in HDL, on top of OpenPOWER v3.0B and > > passing its first unit tests. > > > > Congratulations to Cesar and team! it's quite understated, this is a bid damn deal. l. From cestrauss at gmail.com Sun Mar 7 17:39:42 2021 From: cestrauss at gmail.com (Cesar Strauss) Date: Sun, 7 Mar 2021 14:39:42 -0300 Subject: [Libre-soc-dev] Libre-SOC SVP64 first Cray-style Vector loop successful In-Reply-To: References: Message-ID: Em 07/03/2021 10:24, Luke Kenneth Casson Leighton escreveu: > with many thanks and congratulations to Cesar for getting the first basic > Cray-style Vector Loop operational in HDL, on top of OpenPOWER v3.0B and > passing its first unit tests. I'm glad for giving my small contribution, but it was really a team effort, congratulation to us all. Especially after Luke lead all the preparatory work on the Python Assembler, Simulator, HDL Decoder, Test Cases, etc., so I started with most supporting pieces already in place. I really only helped placing the last remaining piece of this current milestone (improve an existing HDL State Machine to run a For-Loop on the Fetch and Execute stages). Also, of course, thanks to everyone else on the team for helping the project get this far, with the OpenPOWER Simple-V specification in place, the Computation Units, Pipelines, the Decoder, Simulator, IEEE 754 Floating Point, the project infrastructure, documentation, as well as well as the ongoing work on GCC and Binutils, Vulkan drivers, Caches, MMU, FPGA testing, unit testing, formal verification, nMigen improvements, general support, helpful insights and pointers, experience, etc. Looking forward for the way still to follow. Regards, Cesar From colepoirier at gmail.com Sun Mar 7 17:45:41 2021 From: colepoirier at gmail.com (Cole Poirier) Date: Sun, 7 Mar 2021 09:45:41 -0800 Subject: [Libre-soc-dev] Libre-SOC SVP64 first Cray-style Vector loop successful In-Reply-To: References: <20210307163103.GA5840@lily.local> Message-ID: On Sun, Mar 7, 2021 at 8:51 AM Luke Kenneth Casson Leighton wrote: > > On Sun, Mar 7, 2021 at 4:31 PM Veera wrote: > > > > On Sun, Mar 07, 2021 at 01:24:51PM +0000, Luke Kenneth Casson Leighton wrote: > > > with many thanks and congratulations to Cesar for getting the first basic > > > Cray-style Vector Loop operational in HDL, on top of OpenPOWER v3.0B and > > > passing its first unit tests. > > > > > > > Congratulations to Cesar and team! > > it's quite understated, this is a bid damn deal. Very exciting, and a very big deal! Congratulations Luke and Cesar and all of us project members!! Cole From cestrauss at gmail.com Sun Mar 7 17:51:10 2021 From: cestrauss at gmail.com (Cesar Strauss) Date: Sun, 7 Mar 2021 14:51:10 -0300 Subject: [Libre-soc-dev] Libre-SOC SVP64 first Cray-style Vector loop successful In-Reply-To: References: Message-ID: <03ab0621-98c6-60fa-abf4-58a7fe2ed854@gmail.com> Em 07/03/2021 14:39, Cesar Strauss escreveu: > Also, of course, thanks to everyone else on the team for helping the > project get this far, with the OpenPOWER Simple-V specification in > place, the Computation Units, Pipelines, the Decoder, Simulator, IEEE > 754 Floating Point, the project infrastructure, documentation, as well > as well as the ongoing work on GCC and Binutils, Vulkan drivers, Caches, > MMU, FPGA testing, unit testing, formal verification, nMigen > improvements, general support, helpful insights and pointers, > experience, etc. ... also ASIC Design, Investor relations, the list goes on and on... Regards, Cesar From programmerjake at gmail.com Sun Mar 7 22:16:41 2021 From: programmerjake at gmail.com (Jacob Lifshay) Date: Sun, 7 Mar 2021 14:16:41 -0800 Subject: [Libre-soc-dev] Libre-SOC SVP64 first Cray-style Vector loop successful In-Reply-To: References: Message-ID: On Sun, Mar 7, 2021, 09:40 Cesar Strauss wrote: > Em 07/03/2021 10:24, Luke Kenneth Casson Leighton escreveu: > > with many thanks and congratulations to Cesar for getting the first basic > > Cray-style Vector Loop operational in HDL, on top of OpenPOWER v3.0B and > > passing its first unit tests. > > I'm glad for giving my small contribution, but it was really a team > effort, congratulation to us all. > Congrats All! Jacob From eduardo.pires at protonmail.com Sun Mar 7 22:19:18 2021 From: eduardo.pires at protonmail.com (Eduardo Pires) Date: Sun, 07 Mar 2021 22:19:18 +0000 Subject: [Libre-soc-dev] Intro Message-ID: <6fFUJ-WxNpkBhFGIcW5IGmkuYq7raKjvS_RABATHjWjboKl8cRAYwKUbwfGgHB8yYBLILJAj81dLMB5-earOZuYQsefcFgiYJ1BQrIfeUhw=@protonmail.com> Hi all! I've been hanging around at the IRC (as mopar_ed) asking questions and trying to setup the toolchain on my machine, and I figured it would make sense if I introduced myself. I'm actually still trying to figure out if I can help this project, so fell free to give me a hint. a bit about myself. For the last 5 years I've been a QA / DevOps engineer, and before that I've worked as a firmware engineer. I'm mostly comfortable with C, C++, bash scripting, but have no problems with python as it was our main choice when testing the hardware that used my firmware. Currently I'm refreshing my assembly skills, porting one of my first games (space invaders clone) to work on MikeOS. From the main page section 5.3 Needed Skills I noticed that you need some help with the MESA 3D driver and because of my interest in 3D technology (after university I did a 2 year game developer TAFE in AU), I thought that it would be an interesting challenge. Anyway, that is it for now, and hope to see you around. Ed Sent with [ProtonMail](https://protonmail.com/) Secure Email. From lkcl at lkcl.net Mon Mar 8 03:16:40 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 8 Mar 2021 03:16:40 +0000 Subject: [Libre-soc-dev] Intro In-Reply-To: <6fFUJ-WxNpkBhFGIcW5IGmkuYq7raKjvS_RABATHjWjboKl8cRAYwKUbwfGgHB8yYBLILJAj81dLMB5-earOZuYQsefcFgiYJ1BQrIfeUhw=@protonmail.com> References: <6fFUJ-WxNpkBhFGIcW5IGmkuYq7raKjvS_RABATHjWjboKl8cRAYwKUbwfGgHB8yYBLILJAj81dLMB5-earOZuYQsefcFgiYJ1BQrIfeUhw=@protonmail.com> Message-ID: On Sunday, March 7, 2021, Eduardo Pires wrote: > > > From the main page section 5.3 Needed Skills I noticed that you need some > help with the MESA 3D driver and because of my interest in 3D technology > (after university I did a 2 year game developer TAFE in AU), I thought that > it would be an interesting challenge. nice to hear from you, am ccing you (not subscribed) added you approved send. late here, brief: vivek has been working on mesa, intro above, do catch up with him. please do remember we do all development and technical discussion through libre-soc resources for transparency and audit purposes for our sponsors, NLnet. therefore if you collaborate on source code you need to use git.libre-soc.org not gitlab not github, and if you need a mailing list i can arrange for one on lists.libre-soc.org more tomorrow when it is not 3am > > Anyway, that is it for now, and hope to see you around. > > Ed > > Sent with [ProtonMail](https://protonmail.com/) Secure Email. > _______________________________________________ > Libre-soc-dev mailing list > Libre-soc-dev at lists.libre-soc.org > http://lists.libre-soc.org/mailman/listinfo/libre-soc-dev > -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From vivekvpandya at gmail.com Mon Mar 8 14:42:26 2021 From: vivekvpandya at gmail.com (vivek pandya) Date: Mon, 8 Mar 2021 20:12:26 +0530 Subject: [Libre-soc-dev] Intro In-Reply-To: References: <6fFUJ-WxNpkBhFGIcW5IGmkuYq7raKjvS_RABATHjWjboKl8cRAYwKUbwfGgHB8yYBLILJAj81dLMB5-earOZuYQsefcFgiYJ1BQrIfeUhw=@protonmail.com> Message-ID: Hello Eduardo, I am happy to help you get started! Here is source code https://git.libre-soc.org/?p=mesa.git;a=shortlog;h=refs/heads/libresoc_dev >From this bug (Thanks to Cole!) https://bugs.libre-soc.org/show_bug.cgi?id=472 you should get all required help to setup development environment I am using. At very high level the project aims ( Luke please correct if required) to experimental driver which can allow testing libresoc instruction on desktop environment till a simulator/silicon is available. So this is software rasterizer based on mesa environment. where currently everything is just done on CPU (like storing image memory in simple array rather than access it on actual HW through linux abstraction) And hopefully when this becomes more mature we have switches at few places like MapMemory etc so that we can execute things on actual HW. Current Status: I am trying to run https://software.intel.com/content/www/us/en/develop/articles/api-without-secrets-introduction-to-vulkan-part-3.html and as of now I can run part 2 which just displays a simple color in the window. The Driver can generate NIR/LLVM/x86 assembly for very simple shaders. To make something drawn with a simple VS and FS I need to implement a fake GPUState to hold indexBuffer and VertexBuffers. Implement command buffer and on receiving draw command execute sw rasterizer (which is to be implemented) which can just process triangles through LLVM's ORCjit and followed by them fragment shader can process 3 vertex batch and shade them. This is all based on https://github.com/baldurk/visor Please ask any questions you have while getting started. If I get time this month I will try to complete a few things from above. Once a simple triangle is ready we can add more graphics related processing algorithms. My knowledge is limited in that area , you can see how I just implemented ClearColorImage https://git.libre-soc.org/?p=mesa.git;a=blobdiff;f=src/libre-soc/vulkan/libresoc_meta_clear.c;h=80ed9904080fb948bce271d77fa53d58ea7ddb3c;hp=5650d3e94a96f201551fea7a0be72c909f37ea7f;hb=ed7212f4d2407f38d4b9fb7cd86a8a5226c8d678;hpb=df494d9287f13d4cd7802909bf385b48b619421b We also need to think how actual HW will be represented and interact with the Linux environment (but yes that can be done later). Hope this helps! -Vivek On Mon, Mar 8, 2021 at 8:47 AM Luke Kenneth Casson Leighton wrote: > > > On Sunday, March 7, 2021, Eduardo Pires > wrote: > >> >> >> From the main page section 5.3 Needed Skills I noticed that you need some >> help with the MESA 3D driver and because of my interest in 3D technology >> (after university I did a 2 year game developer TAFE in AU), I thought that >> it would be an interesting challenge. > > > nice to hear from you, am ccing you (not subscribed) added you approved > send. late here, brief: vivek has been working on mesa, intro above, do > catch up with him. > > please do remember we do all development and technical discussion through > libre-soc resources for transparency and audit purposes for our sponsors, > NLnet. > > therefore if you collaborate on source code you need to use > git.libre-soc.org not gitlab not github, and if you need a mailing list i > can arrange for one on lists.libre-soc.org > > more tomorrow when it is not 3am > > >> >> Anyway, that is it for now, and hope to see you around. >> >> Ed >> >> Sent with [ProtonMail](https://protonmail.com/) Secure Email. >> _______________________________________________ >> Libre-soc-dev mailing list >> Libre-soc-dev at lists.libre-soc.org >> http://lists.libre-soc.org/mailman/listinfo/libre-soc-dev >> > > > -- > --- > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 > > From eduardo.pires at protonmail.com Mon Mar 8 15:42:49 2021 From: eduardo.pires at protonmail.com (Eduardo Pires) Date: Mon, 08 Mar 2021 15:42:49 +0000 Subject: [Libre-soc-dev] Intro In-Reply-To: References: <6fFUJ-WxNpkBhFGIcW5IGmkuYq7raKjvS_RABATHjWjboKl8cRAYwKUbwfGgHB8yYBLILJAj81dLMB5-earOZuYQsefcFgiYJ1BQrIfeUhw=@protonmail.com> Message-ID: Hi Vivek! yes, that helps a lot, I'll dig into those links you sent tonight. I've been reading through the bug tickets as well (like this one https://bugs.libre-soc.org/show_bug.cgi?id=251 for example), they have a ton of info and helps to understand where things are at. best regards, Ed Sent with [ProtonMail](https://protonmail.com/) Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Monday, March 8th, 2021 at 3:42 PM, vivek pandya wrote: > Hello Eduardo, > > I am happy to help you get started! > > Here is source code https://git.libre-soc.org/?p=mesa.git;a=shortlog;h=refs/heads/libresoc_dev > > From this bug (Thanks to Cole!) https://bugs.libre-soc.org/show_bug.cgi?id=472 you should get all required help to setup development environment I am using. > > At very high level the project aims ( Luke please correct if required) to experimental driver which can allow testing libresoc instruction on desktop environment till a simulator/silicon is available. > So this is software rasterizer based on mesa environment. where currently everything is just done on CPU (like storing image memory in simple array rather than access it on actual HW through linux abstraction) > And hopefully when this becomes more mature we have switches at few places like MapMemory etc so that we can execute things on actual HW. > > Current Status: > I am trying to run https://software.intel.com/content/www/us/en/develop/articles/api-without-secrets-introduction-to-vulkan-part-3.html > and as of now I can run part 2 which just displays a simple color in the window. > The Driver can generate NIR/LLVM/x86 assembly for very simple shaders. > > To make something drawn with a simple VS and FS I need to implement a fake GPUState to hold indexBuffer and VertexBuffers. > Implement command buffer and on receiving draw command execute sw rasterizer (which is to be implemented) which can just process triangles through LLVM's ORCjit and followed by them fragment shader can process 3 vertex batch and shade them. > This is all based on https://github.com/baldurk/visor > > Please ask any questions you have while getting started. If I get time this month I will try to complete a few things from above. > Once a simple triangle is ready we can add more graphics related processing algorithms. > My knowledge is limited in that area , you can see how I just implemented ClearColorImage https://git.libre-soc.org/?p=mesa.git;a=blobdiff;f=src/libre-soc/vulkan/libresoc_meta_clear.c;h=80ed9904080fb948bce271d77fa53d58ea7ddb3c;hp=5650d3e94a96f201551fea7a0be72c909f37ea7f;hb=ed7212f4d2407f38d4b9fb7cd86a8a5226c8d678;hpb=df494d9287f13d4cd7802909bf385b48b619421b > > We also need to think how actual HW will be represented and interact with the Linux environment (but yes that can be done later). > > Hope this helps! > > -Vivek > On Mon, Mar 8, 2021 at 8:47 AM Luke Kenneth Casson Leighton wrote: > >> On Sunday, March 7, 2021, Eduardo Pires wrote: >> >>> From the main page section 5.3 Needed Skills I noticed that you need some help with the MESA 3D driver and because of my interest in 3D technology (after university I did a 2 year game developer TAFE in AU), I thought that it would be an interesting challenge. >> >> nice to hear from you, am ccing you (not subscribed) added you approved send. late here, brief: vivek has been working on mesa, intro above, do catch up with him. >> >> please do remember we do all development and technical discussion through libre-soc resources for transparency and audit purposes for our sponsors, NLnet. >> >> therefore if you collaborate on source code you need to use git.libre-soc.org not gitlab not github, and if you need a mailing list i can arrange for one on lists.libre-soc.org >> >> more tomorrow when it is not 3am >> >>> Anyway, that is it for now, and hope to see you around. >>> >>> Ed >>> >>> Sent with [ProtonMail](https://protonmail.com/) Secure Email. >>> _______________________________________________ >>> Libre-soc-dev mailing list >>> Libre-soc-dev at lists.libre-soc.org >>> http://lists.libre-soc.org/mailman/listinfo/libre-soc-dev >> >> -- >> --- >> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From lkcl at lkcl.net Mon Mar 8 16:43:35 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 8 Mar 2021 16:43:35 +0000 Subject: [Libre-soc-dev] Intro In-Reply-To: References: <6fFUJ-WxNpkBhFGIcW5IGmkuYq7raKjvS_RABATHjWjboKl8cRAYwKUbwfGgHB8yYBLILJAj81dLMB5-earOZuYQsefcFgiYJ1BQrIfeUhw=@protonmail.com> Message-ID: On Mon, Mar 8, 2021 at 2:42 PM vivek pandya wrote: > > Hello Eduardo, > > I am happy to help you get started! > > Here is source code > https://git.libre-soc.org/?p=mesa.git;a=shortlog;h=refs/heads/libresoc_dev > > From this bug (Thanks to Cole!) > https://bugs.libre-soc.org/show_bug.cgi?id=472 you should get all required > help to setup development environment I am using. > > At very high level the project aims ( Luke please correct if required) to > experimental driver which can allow testing libresoc instruction on desktop > environment till a simulator/silicon is available. actually, ultimately i want it to run *in* a simulator (power-gem5) where we will then experiment by implementing *actual* (simulated) opcodes that the NIR/LLVM-IR/ppc64 would *actually* use. for example, we would add a hardware-simulated SIN opcode, then modify LLVM-IR to emit that, then (going back down the chain) modify the MESA-3D Vulkan driver that you're doing to emit that too, and so on. *then* we check, in the simulator, if performance actually increases or not. if it does, we implement it in HDL and, ultimately, try it out in an FPGA. that's all under future bugs, listed here: https://bugs.libre-soc.org/show_bug.cgi?id=140#c0 repeat, repeat, repeat. > So this is software rasterizer based on mesa environment. the critically important thing here is that the Vectorisation Contexts (predication, swizzle, vec2/3/4) are preserved *right* the way through to LLVM-IR. this is really really important. all the other Vulkan Soft-Shader Compilers (google SwiftShader) **DESTROY** that information as quickly as possible. the roadmap is, here: * software renderer in LLVM-IR/x86 * software renderer in LLVM-IR/ppc64 (OpenPOWER v3.0) * software renderer in LLVM-IR/ppc64-with-Simple-V including predication, Cray-style Vectors, swizzle and vec2/3/4 * software renderer in LLVM-IR/ppc64-with-Simple-V *with custom 3D opcodes* at *all times* it appears to be a software renderer. but it is actually a software renderer with a 3D augmented Vector ISA > where currently > everything is just done on CPU (like storing image memory in simple array > rather than access it on actual HW through linux abstraction) > And hopefully when this becomes more mature we have switches at few places > like MapMemory etc so that we can execute things on actual HW. at some point we will need to add special Texture Cache and LOAD/STORE instructions to the custom OpenPOWER opcodes. this because Texture LD/ST is so data heavy it will overload the normal L1 and L2 cache for no good reason. > Current Status: > I am trying to run > https://software.intel.com/content/www/us/en/develop/articles/api-without-secrets-introduction-to-vulkan-part-3.html > and as of now I can run part 2 which just displays a simple color in the > window. > The Driver can generate NIR/LLVM/x86 assembly for very simple shaders. fantastic! this is brilliant, and worthwhile of a "declared completed milestone" for which we can put in an NLnet donation for you. can you put in a bugreport under here: https://bugs.libre-soc.org/show_bug.cgi?id=251 just put a single sentence and cross-reference this... y'know what? i'll do it :) https://bugs.libre-soc.org/show_bug.cgi?id=613 what - rouglhy - would you say percentage-wise we're towards 251 (the parent)? https://bugs.libre-soc.org/show_bug.cgi?id=251 > We also need to think how actual HW will be represented and interact with > the Linux environment (but yes that can be done later). i'd like to get power-gem5 into shape enough so that compilation and simulations can actually be done under that, even if it is horribly slow, either producing images in the VM or firing up X-Windows remotely, something, anything. > Hope this helps! this is great, Vivek. l. From libre-soc at platen-software.de Mon Mar 8 17:03:01 2021 From: libre-soc at platen-software.de (Tobias Platen) Date: Mon, 8 Mar 2021 18:03:01 +0100 Subject: [Libre-soc-dev] daily kan-ban update 08mar2021 Message-ID: <20210308180301.84e850a12770e48ae9c7356a@platen-software.de> today: implement lookup of root entry using SPSs PIDR and PRTBL -- Tobias Platen From lkcl at lkcl.net Mon Mar 8 17:29:27 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 8 Mar 2021 17:29:27 +0000 Subject: [Libre-soc-dev] daily kan-ban update 08mar2021 In-Reply-To: <20210308180301.84e850a12770e48ae9c7356a@platen-software.de> References: <20210308180301.84e850a12770e48ae9c7356a@platen-software.de> Message-ID: On Mon, Mar 8, 2021 at 5:03 PM Tobias Platen wrote: > > today: implement lookup of root entry using SPSs PIDR and PRTBL fantastic! does it match the example in experimental-gem5 or what's in microwatt? https://github.com/power-gem5/gem5/blob/gem5-experimental/src/arch/power/radix_walk_example.txt l. From lkcl at lkcl.net Mon Mar 8 17:37:13 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 8 Mar 2021 17:37:13 +0000 Subject: [Libre-soc-dev] daily kan-ban update 08mar2021 In-Reply-To: References: <20210308180301.84e850a12770e48ae9c7356a@platen-software.de> Message-ID: On Mon, Mar 8, 2021 at 5:29 PM Luke Kenneth Casson Leighton wrote: > > On Mon, Mar 8, 2021 at 5:03 PM Tobias Platen > wrote: > > > > today: implement lookup of root entry using SPSs PIDR and PRTBL > > fantastic! > > does it match the example in experimental-gem5 or what's in microwatt? > https://github.com/power-gem5/gem5/blob/gem5-experimental/src/arch/power/radix_walk_example.txt oh, only thing is, PIDR is non-standard so have to adapt from that example. l. p.s. git push! :) From libre-soc at platen-software.de Mon Mar 8 17:56:48 2021 From: libre-soc at platen-software.de (Tobias Platen) Date: Mon, 8 Mar 2021 18:56:48 +0100 Subject: [Libre-soc-dev] daily kan-ban update 08mar2021 In-Reply-To: References: <20210308180301.84e850a12770e48ae9c7356a@platen-software.de> Message-ID: <20210308185648.05e7e633722d20a336e9b307@platen-software.de> On Mon, 8 Mar 2021 17:37:13 +0000 Luke Kenneth Casson Leighton wrote: > oh, only thing is, PIDR is non-standard so have to adapt from that example. I'm aware of since I watched "Microwatt grows up" at FOSDEM. -- Tobias Platen From lkcl at lkcl.net Mon Mar 8 17:58:18 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 8 Mar 2021 17:58:18 +0000 Subject: [Libre-soc-dev] daily kan-ban update 08mar2021 In-Reply-To: <20210308185648.05e7e633722d20a336e9b307@platen-software.de> References: <20210308180301.84e850a12770e48ae9c7356a@platen-software.de> <20210308185648.05e7e633722d20a336e9b307@platen-software.de> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Mon, Mar 8, 2021 at 5:56 PM Tobias Platen wrote: > I'm aware of since I watched "Microwatt grows up" at FOSDEM. yeah that was a really informative talk paul gave. From lkcl at lkcl.net Mon Mar 8 19:27:56 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 8 Mar 2021 19:27:56 +0000 Subject: [Libre-soc-dev] new mode in issuer Message-ID: to cut down LUT4s i added an option to disable SVP64 decoding. it saves 1000 LUT4s when building for the ECP5. l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From programmerjake at gmail.com Tue Mar 9 02:59:09 2021 From: programmerjake at gmail.com (Jacob Lifshay) Date: Mon, 8 Mar 2021 18:59:09 -0800 Subject: [Libre-soc-dev] SoC reset Message-ID: Found this interesting thread about what a SoC should implement around reset functionality: https://groups.google.com/a/groups.riscv.org/d/msgid/hw-dev/BY5PR20MB3202858A796FDACC2B652C9EF0939%40BY5PR20MB3202.namprd20.prod.outlook.com Jacob From libre-soc at platen-software.de Tue Mar 9 16:08:45 2021 From: libre-soc at platen-software.de (Tobias Platen) Date: Tue, 9 Mar 2021 17:08:45 +0100 Subject: [Libre-soc-dev] daily kan-ban update 09mar2021 Message-ID: <20210309170845.61a94f9a3fd1a915f546f6c1@platen-software.de> today: continuing to work on soc/src/soc/decoder/isa/radixmmu.py where I left yesterday yesterday: understanding how microwatt uses pidr and prtbl, therefore no commit yet. I did a git pull and saw the update at 2021-03-09 13:10:45 GMT on https://bugs.libre-soc.org/show_bug.cgi?id=604. -- Tobias Platen From libre-soc at platen-software.de Tue Mar 9 16:50:54 2021 From: libre-soc at platen-software.de (Tobias Platen) Date: Tue, 9 Mar 2021 17:50:54 +0100 Subject: [Libre-soc-dev] daily kan-ban update 09mar2021 In-Reply-To: <20210309170845.61a94f9a3fd1a915f546f6c1@platen-software.de> References: <20210309170845.61a94f9a3fd1a915f546f6c1@platen-software.de> Message-ID: <20210309175054.b4c2dfcdbf9a2e55eec67b54@platen-software.de> On Tue, 9 Mar 2021 17:08:45 +0100 Tobias Platen wrote: > today: continuing to work on soc/src/soc/decoder/isa/radixmmu.py where I left yesterday > yesterday: understanding how microwatt uses pidr and prtbl, therefore no commit yet. > > I did a git pull and saw the update at 2021-03-09 13:10:45 GMT on https://bugs.libre-soc.org/show_bug.cgi?id=604. > > -- > Tobias Platen > > _______________________________________________ > Libre-soc-dev mailing list > Libre-soc-dev at lists.libre-soc.org > http://lists.libre-soc.org/mailman/listinfo/libre-soc-dev After running an git pull, I get the following error. AttributeError: 'ISA' object has no attribute 'spr' -- Tobias Platen From lkcl at lkcl.net Tue Mar 9 17:28:36 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 9 Mar 2021 17:28:36 +0000 Subject: [Libre-soc-dev] daily kan-ban update 09mar2021 In-Reply-To: <20210309175054.b4c2dfcdbf9a2e55eec67b54@platen-software.de> References: <20210309170845.61a94f9a3fd1a915f546f6c1@platen-software.de> <20210309175054.b4c2dfcdbf9a2e55eec67b54@platen-software.de> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Tue, Mar 9, 2021 at 4:50 PM Tobias Platen wrote: > After running an git pull, I get the following error. > AttributeError: 'ISA' object has no attribute 'spr' ah yeah SPRs need initialising in ISACaller first. what unit tests are you running? i can't see any. l. From libre-soc at platen-software.de Tue Mar 9 17:32:41 2021 From: libre-soc at platen-software.de (Tobias Platen) Date: Tue, 9 Mar 2021 18:32:41 +0100 Subject: [Libre-soc-dev] daily kan-ban update 09mar2021 In-Reply-To: References: <20210309170845.61a94f9a3fd1a915f546f6c1@platen-software.de> <20210309175054.b4c2dfcdbf9a2e55eec67b54@platen-software.de> Message-ID: <20210309183241.94b2eb4187c54b23eeb90351@platen-software.de> On Tue, 9 Mar 2021 17:28:36 +0000 Luke Kenneth Casson Leighton wrote: > --- > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 > > On Tue, Mar 9, 2021 at 4:50 PM Tobias Platen > wrote: > > > After running an git pull, I get the following error. > > AttributeError: 'ISA' object has no attribute 'spr' > > ah yeah SPRs need initialising in ISACaller first. > > what unit tests are you running? i can't see any. soc/src/soc/decoder/isa/test_caller_radix.py > > l. > > _______________________________________________ > Libre-soc-dev mailing list > Libre-soc-dev at lists.libre-soc.org > http://lists.libre-soc.org/mailman/listinfo/libre-soc-dev -- Tobias Platen From lkcl at lkcl.net Tue Mar 9 17:49:23 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 9 Mar 2021 17:49:23 +0000 Subject: [Libre-soc-dev] daily kan-ban update 09mar2021 In-Reply-To: <20210309183241.94b2eb4187c54b23eeb90351@platen-software.de> References: <20210309170845.61a94f9a3fd1a915f546f6c1@platen-software.de> <20210309175054.b4c2dfcdbf9a2e55eec67b54@platen-software.de> <20210309183241.94b2eb4187c54b23eeb90351@platen-software.de> Message-ID: On Tue, Mar 9, 2021 at 5:32 PM Tobias Platen wrote: > soc/src/soc/decoder/isa/test_caller_radix.py ok got it. From libre-soc at platen-software.de Tue Mar 9 19:10:58 2021 From: libre-soc at platen-software.de (Tobias Platen) Date: Tue, 9 Mar 2021 20:10:58 +0100 Subject: [Libre-soc-dev] daily kan-ban update 09mar2021 In-Reply-To: References: <20210309170845.61a94f9a3fd1a915f546f6c1@platen-software.de> <20210309175054.b4c2dfcdbf9a2e55eec67b54@platen-software.de> <20210309183241.94b2eb4187c54b23eeb90351@platen-software.de> Message-ID: <20210309201058.48437ca8722b3a21ae62a775@platen-software.de> I just had a look at _get_prtable_addr which takes an argument shift. I guess shift depends on the page size. From Paul's talk I know that Microwatt supports different page sizes. def _get_prtable_addr(self, shift, prtbl, addr, pid): """ if r.addr(63) = '1' then effpid := x"00000000"; else effpid := r.pid; end if; x"00" & r.prtbl(55 downto 36) & ((r.prtbl(35 downto 12) and not finalmask(23 downto 0)) or (effpid(31 downto 8) and finalmask(23 downto 0))) & effpid(7 downto 0) & "0000"; """ finalmask = genmask(shift, 44) finalmask24 = finalmask[20:44] ...... -- Tobias Platen From lkcl at lkcl.net Tue Mar 9 19:31:24 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 9 Mar 2021 19:31:24 +0000 Subject: [Libre-soc-dev] daily kan-ban update 09mar2021 In-Reply-To: <20210309201058.48437ca8722b3a21ae62a775@platen-software.de> References: <20210309170845.61a94f9a3fd1a915f546f6c1@platen-software.de> <20210309175054.b4c2dfcdbf9a2e55eec67b54@platen-software.de> <20210309183241.94b2eb4187c54b23eeb90351@platen-software.de> <20210309201058.48437ca8722b3a21ae62a775@platen-software.de> Message-ID: On Tue, Mar 9, 2021 at 7:11 PM Tobias Platen wrote: > > I just had a look at _get_prtable_addr which takes an argument shift. > I guess shift depends on the page size. how far down the page-table walk things are progressing, something like that. let's look... here, right at the beginning of mmu.vhdl: -- rts == radix tree size, # address bits being translated rts := unsigned('0' & pgtbl(62 downto 61) & pgtbl(7 downto 5)); -- mbits == # address bits to index top level of tree mbits := unsigned('0' & pgtbl(4 downto 0)); -- set v.shift to rts so that we can use finalmask for the segment check v.shift := rts; ahhh that's interesting. that code starting at line 235 is a duplication of _decode_rte(). https://github.com/antonblanchard/microwatt/blob/6523acc74344b95e7cceb83611fb8cb2a030c1a3/mmu.vhdl#L235 is a duplication of this: https://github.com/antonblanchard/microwatt/blob/master/mmu.vhdl#L318 which has already been done as a function here: https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/decoder/isa/radixmmu.py;h=f860e417e9f22597c44294c6ab35e698c65baa01;hb=HEAD#l315 l. From lkcl at lkcl.net Tue Mar 9 19:37:05 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 9 Mar 2021 19:37:05 +0000 Subject: [Libre-soc-dev] daily kan-ban update 09mar2021 In-Reply-To: References: <20210309170845.61a94f9a3fd1a915f546f6c1@platen-software.de> <20210309175054.b4c2dfcdbf9a2e55eec67b54@platen-software.de> <20210309183241.94b2eb4187c54b23eeb90351@platen-software.de> <20210309201058.48437ca8722b3a21ae62a775@platen-software.de> Message-ID: moving to the bugtracker, it is more appropriate than under an unnamed "daily status update" --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Tue, Mar 9, 2021 at 7:31 PM Luke Kenneth Casson Leighton wrote: > > On Tue, Mar 9, 2021 at 7:11 PM Tobias Platen > wrote: > > > > I just had a look at _get_prtable_addr which takes an argument shift. > > I guess shift depends on the page size. > > how far down the page-table walk things are progressing, something > like that. let's look... > > here, right at the beginning of mmu.vhdl: > > -- rts == radix tree size, # address bits being translated > rts := unsigned('0' & pgtbl(62 downto 61) & pgtbl(7 downto 5)); > -- mbits == # address bits to index top level of tree > mbits := unsigned('0' & pgtbl(4 downto 0)); > -- set v.shift to rts so that we can use finalmask for the > segment check > v.shift := rts; > > ahhh that's interesting. that code starting at line 235 is a > duplication of _decode_rte(). > https://github.com/antonblanchard/microwatt/blob/6523acc74344b95e7cceb83611fb8cb2a030c1a3/mmu.vhdl#L235 > > is a duplication of this: > https://github.com/antonblanchard/microwatt/blob/master/mmu.vhdl#L318 > > which has already been done as a function here: > https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/decoder/isa/radixmmu.py;h=f860e417e9f22597c44294c6ab35e698c65baa01;hb=HEAD#l315 > > l. From programmerjake at gmail.com Wed Mar 10 00:32:45 2021 From: programmerjake at gmail.com (Jacob Lifshay) Date: Tue, 9 Mar 2021 16:32:45 -0800 Subject: [Libre-soc-dev] scalar instructions and SVP64 Message-ID: https://libre-soc.org/irclog/%23libre-soc.2021-03-10.log.html#t2021-03-10T00:11:21 lkcl and lxo, making sure you see this: > lkcl: i think svp64 instructions without any vector arguments *should* be not dependent on VL==0 or not, they are used for purely scalar operations and are needed to access out-of-32-bit-range registers. > after all, svp64 != vector instruction example: int f(int a, int *b, size_t len) { while(1) { size_t vl = setvl(len, ...); if(vl == 0) break; auto v = sv_load(b, vl); v = sv_add(v, 1, vl); sv_store(b, v, vl); b += vl; len -= vl; } return a; } say the compiler decides `a` should be stored in register 127 since the other registers are in-use or something...now, since VL is left set to 0 at the end of the loop, when the compiler uses the scalar svp64 instruction (since svp64 instructions are the only kind that can access register 127) to move `a` back to the return value register, the instruction should obviously actually move `a` and not decide that "oh, you really mean vector move here, just limited to 1 element, so VL = 0 means do nothing". You see why we need VL to be ignored when there aren't any vector arguments? Jacob From lkcl at lkcl.net Wed Mar 10 00:49:38 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 10 Mar 2021 00:49:38 +0000 Subject: [Libre-soc-dev] scalar instructions and SVP64 In-Reply-To: References: Message-ID: On Wednesday, March 10, 2021, Jacob Lifshay wrote: > https://libre-soc.org/irclog/%23libre-soc.2021-03-10.log. > html#t2021-03-10T00:11:21 > > You see why we need VL to be ignored when there aren't any vector > arguments? late (1am), the short answer is no. VL=0 is defined as "all and any sv ops are NOP". scalar in SV is defined as "element zero of a vector" not "scalar because it's scalar i.e. not a vector" it's DEFINED as being "element zero of the Vector". ALL sv instructions ARE vector. the misnamed-thing-we-call-sv-scalar is not actually a scalar. it *is* "the zeroth element of the vector". therefore by definition it falls under the vector loop therefore when VL=0 it shall be skipped because all sv instructions *are* skipped when VL=0 Period. if you want scalar instructions you do not put them into SV. you use the v3.0B scalar instructions because those are categorically scalar. RVV has the exact same thing. all RVV instructions categorically become NOPs when VL==0 l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From lkcl at lkcl.net Wed Mar 10 01:03:44 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 10 Mar 2021 01:03:44 +0000 Subject: [Libre-soc-dev] scalar instructions and SVP64 In-Reply-To: References: Message-ID: On Wednesday, March 10, 2021, Jacob Lifshay wrote: > return a; > } > > say the compiler decides `a` should be stored in register 127 since the > other registers are in-use or something...now, since VL is left set to 0 at > the end of the loop, this will be unacceptable to do that (leave VL setvto zero) it will be required to set VL=1. sounds tough, but it is.. well... tough. in the old version this is precisely why in the 64 bit variant i added the ability to set VL *in* the 64 bit prefix. as we could not do combined 48 and 64 we cannot do that and had to sacrifice the capability. it is a frickin nuisance because embedding VL setting into the prefix allowed things like LDST Multi to be one single 64 bit instruction. but... tough. and no, i made it clear multiple times: compromising SV by adding in exceptions to the rules are not ok. future versions we may work out a way to set VL in the old way. if VL=0 means "scalar is expected" then we just destroyed any hope of that. so no. not happening. algorithm does not set VL=1 ==> algorithm is flawed. call setvli 1 and algorithm is now correct. l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From programmerjake at gmail.com Wed Mar 10 01:05:02 2021 From: programmerjake at gmail.com (Jacob Lifshay) Date: Tue, 9 Mar 2021 17:05:02 -0800 Subject: [Libre-soc-dev] scalar instructions and SVP64 In-Reply-To: References: Message-ID: On Tue, Mar 9, 2021, 16:50 Luke Kenneth Casson Leighton wrote: > On Wednesday, March 10, 2021, Jacob Lifshay > wrote: > > > https://libre-soc.org/irclog/%23libre-soc.2021-03-10.log. > > html#t2021-03-10T00:11:21 > > > > You see why we need VL to be ignored when there aren't any vector > > arguments? > > > late (1am), the short answer is no. > Well, then we need to change the spec since a "no" answer is effectively unworkable from a SW perspective, as (poorly) illustrated by that example code. in compilers, and most the rest of SW, vector and scalar are two different classes of operations/types/values/etc. SV needs to be modified to account for that. scalar being just element 0 of a vector is deceptively alluring, but is really a trap. We can discuss in further detail after you get some sleep. Jacob From lkcl at lkcl.net Wed Mar 10 01:16:19 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 10 Mar 2021 01:16:19 +0000 Subject: [Libre-soc-dev] scalar instructions and SVP64 In-Reply-To: References: Message-ID: On Wednesday, March 10, 2021, Jacob Lifshay wrote: > On Tue, Mar 9, 2021, 16:50 Luke Kenneth Casson Leighton > wrote: > > > On Wednesday, March 10, 2021, Jacob Lifshay > > wrote: > > > > > https://libre-soc.org/irclog/%23libre-soc.2021-03-10.log. > > > html#t2021-03-10T00:11:21 > > > > > > You see why we need VL to be ignored when there aren't any vector > > > arguments? > > > > > > late (1am), the short answer is no. > > > > Well, then we need to change the spec not happening. clarification only. > since a "no" answer is effectively > unworkable from a SW perspective, as (poorly) illustrated by that example > code. code was flawed (wrong). missing absolutely critical setvli vl=1 > in compilers, and most the rest of SW, vector and scalar are two > different classes of operations/types/values/etc. SV needs to be modified > to account for that. too late. not happening. > scalar being just element 0 of a vector is deceptively > alluring, but is really a trap. i said "considered to be". it is a blurred line. > > We can discuss in further detail after you get some sleep. solution is to add the missing instruction to algorithm. setvli vl=1. then r127 is accessible. don't like it, tough, algorithm should have arranged for result to be in r0-31. l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From programmerjake at gmail.com Wed Mar 10 01:22:06 2021 From: programmerjake at gmail.com (Jacob Lifshay) Date: Tue, 9 Mar 2021 17:22:06 -0800 Subject: [Libre-soc-dev] scalar instructions and SVP64 In-Reply-To: References: Message-ID: On Tue, Mar 9, 2021, 17:05 Jacob Lifshay wrote: > On Tue, Mar 9, 2021, 16:50 Luke Kenneth Casson Leighton > wrote: > >> On Wednesday, March 10, 2021, Jacob Lifshay >> wrote: >> >> > https://libre-soc.org/irclog/%23libre-soc.2021-03-10.log. >> > html#t2021-03-10T00:11:21 >> > >> > You see why we need VL to be ignored when there aren't any vector >> > arguments? >> >> >> late (1am), the short answer is no. >> > > Well, then we need to change the spec since a "no" answer is effectively > unworkable from a SW perspective, as (poorly) illustrated by that example > code. in compilers, and most the rest of SW, vector and scalar are two > different classes of operations/types/values/etc. SV needs to be modified > to account for that. scalar being just element 0 of a vector is deceptively > alluring, but is really a trap. > > We can discuss in further detail after you get some sleep. > https://libre-soc.org/irclog/%23libre-soc.2021-03-10.log.html#t2021-03-10T01:14:27 I guess you can summarize what I envision for svp64 as: prefix for accessing stuff added with SV. one of the features is vector operation, another independent feature is accessing registers > r31, another one is predication, and so on. using svp64 doesn't automatically enable everything always, so why should vector/scalar be any different? or, at least svp64 shouldn't automatically enable everything, all it does is provide the instruction fields with which all the new features can be independently enabled Jacob > From hendrik at topoi.pooq.com Wed Mar 10 03:10:26 2021 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Tue, 9 Mar 2021 22:10:26 -0500 Subject: [Libre-soc-dev] scalar instructions and SVP64 In-Reply-To: References: Message-ID: <20210310031026.bkozdrtoryjummrc@topoi.pooq.com> On Wed, Mar 10, 2021 at 01:03:44AM +0000, Luke Kenneth Casson Leighton wrote: > > and no, i made it clear multiple times: compromising SV by adding in > exceptions to the rules are not ok. uniformity is extremely important for object code generators. Every exception needs to be programmed around and introduces potential code generation bugs. -- hendrik From adam at vany.ca Wed Mar 10 03:39:35 2021 From: adam at vany.ca (Adam Van Ymeren) Date: Tue, 09 Mar 2021 19:39:35 -0800 Subject: [Libre-soc-dev] scalar instructions and SVP64 In-Reply-To: References: Message-ID: On March 9, 2021 5:05:02 p.m. PST, Jacob Lifshay wrote: >On Tue, Mar 9, 2021, 16:50 Luke Kenneth Casson Leighton >wrote: > >> On Wednesday, March 10, 2021, Jacob Lifshay > >> wrote: >> >> > https://libre-soc.org/irclog/%23libre-soc.2021-03-10.log. >> > html#t2021-03-10T00:11:21 >> > >> > You see why we need VL to be ignored when there aren't any vector >> > arguments? >> >> >> late (1am), the short answer is no. >> > >Well, then we need to change the spec since a "no" answer is >effectively >unworkable from a SW perspective, as (poorly) illustrated by that >example >code. Can you outline in more detail why it is unworkable from a SW perspective? It seems from a cursory look easily workable by just setting VL=1 and element size to 64-bit. I can see it being a bit of extra work for compilers to know that accessing high numbered registers requires a bit of extra work but that really doesn't sound unworkable to me. I can however imagine that adding a special case for VL==0 could result in many more gates/complication for the OoO/scoreboard execution engine. From lkcl at lkcl.net Wed Mar 10 03:52:09 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 10 Mar 2021 03:52:09 +0000 Subject: [Libre-soc-dev] scalar instructions and SVP64 In-Reply-To: References: Message-ID: On Wednesday, March 10, 2021, Jacob Lifshay wrote: > > https://libre-soc.org/irclog/%23libre-soc.2021-03-10.log. > html#t2021-03-10T01:14:27 > > I guess you can summarize what I envision for svp64 as: prefix for > accessing stuff added with SV. one of the features is vector operation, > another independent feature is accessing registers > r31, another one is > predication, and so on. yeah, i understand. it explains the many ideas that you suggest, all of which break the underlying simplicity unfortunately [which then in turn make explaining SV harder *and* make implementation.harder in simulators, compilers and HDL] every idea that you come up with that is based on this misapprehension of the fundamental principle creates an interaction between the prefix and its suffix that makes comprehension harder, implementation harder, and many other detrimental implications. even just the idea "why not have scalar-in-SV-when-VL=0" means that hardware can no longer rely on VL=0 to skip SVP64 operations, it has to do a FULL decode in order to determine which registers are marked as scalar before being able to determine if it can be skipped. the rule is: when SV activates, it activates the for-loop. that's it. that's why it's called SimpleV, not ComplexV. the complete lack of connection and interaction between the for-loop and the v3.0B instruction *within* that for-loop is very, very deliberate. remember Tim Forsyth's talk. you have to think *everything* through, together. > using svp64 doesn't automatically enable everything always, so why should > vector/scalar be any different? i'm having difficulty parsing this within the context of "VL is an abstracted independent for-loop around scalar instructions". the prefix bits (modes) *augment* the scalar behaviour. the ones i am not too happy about are the ones that create hazards (mapreduce, ffirst). but, their benefit is clear. the others (saturate, pred-result) augment the *individual* scalar instructions, those modes get passed to MULTIPLE independent parallel execution engines. remember, it's a Sub Program Counter. you don't go "if PC == arbitrarymagicconstant then instruction behaviour equals different" ok for LD/ST in some architectures you do :) l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From lkcl at lkcl.net Wed Mar 10 13:37:58 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 10 Mar 2021 13:37:58 +0000 Subject: [Libre-soc-dev] scalar instructions and SVP64 In-Reply-To: References: Message-ID: right. ok. the simple perspective that VL is strictly a Sub-Program-Counter (actually SVSTATE.srcstep and dststep) is one thal allows multi-issue and speculative execution for high performance designs. right now the identification of length and of SVP64 is extremely simple and will be dead easy to do a high performance multi-issue fetch and issue. SV lives between issue and execute and as such is going to meet with some resistance due to it extending the number of pipeline stages by one. given that in POWER9 they have a *two stage* instruction decode phase it will meet SERIOUS resistance but they will grumble and get over it, because they will be able to implement high performance designs. if however we introduce a hard dependency between prefix and suffix of the types that you keep suggesting, Jacob, because of the perspective that you hold, then it will utterly kill SV stone dead. why? because the suggestions you keep making are by definition and through that perspective 100% creating an interlink between prefix and suffix, where the number of decode stages *has* to be only two (or do something stupid like Intel did with their speculative decoders), and those two stages are so complex that they can in no way be high performance. with the decoders in OpenPOWER being FIVE THOUSAND OR GREATER gates each if we tried Intel's stupid trick we would be laughed at. remember that to get the EXTRA2/3 info you literally have to do a full instruction decode. even the "simple obvious sounding" idea to do different scalar opcodes from v3.0B "because it's SVP64 prefixed" automatically and inherently create problematic pergormance-killing interdependencies between these two decode levels (prefix, suffix) in v3.1 prefixes they have "extra bits" which identify sub-types. these bits can be decoded in a 1st phase decoder that feeds into the 2nd phase of POWER10 without compromising performance. *we do not have space to do that* because we need the bits for modes. therefore the decoding *has* to be done fully by a 2nd stage and by that time it is too late to go back in time and tell issue "hey you shouldn't have issued me with this because of conditions X Y and Z". i trust that this explains clearly why all and any suggestions to create interdependency between prefix and suffix have to be rejected, no matter if we otherwise think they might be a good idea. in practical terms it means that setvl vl=1 has to be called in order to establish scalar-like context (or compilers ensure that regs intended as scalar are allocated to r0-31)and this is just a price that has to be paid. it does however occur to me that setvl could be "context propagated". https://libre-soc.org/openpower/sv/propagation/ this in theory *might* save some proliferation of setvli vl=1 instructions all over the place. l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From lkcl at lkcl.net Wed Mar 10 13:53:02 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 10 Mar 2021 13:53:02 +0000 Subject: [Libre-soc-dev] scalar instructions and SVP64 In-Reply-To: References: Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Wed, Mar 10, 2021 at 3:39 AM Adam Van Ymeren wrote: > I can see it being a bit of extra work for compilers to know that accessing high numbered registers requires a bit of extra work but that really doesn't sound unworkable to me. i would really love that we had the old SVP64 format, where VL and MAXVL were embedded into 12 bits of the prefix. that would solve this... but the trade-off is: we lose *all* of the modes which have been added instead. > I can however imagine that adding a special case for VL==0 could result in many more gates/complication for the OoO/scoreboard execution engine. yes, basically. no design of any kind could ever be high-performance. On Wed, Mar 10, 2021 at 3:10 AM Hendrik Boom wrote: > uniformity is extremely important for object code generators. > > Every exception needs to be programmed around and introduces potential > code generation bugs. yes. this is *another* detrimental consequence of what is best termed "Complex-V". there will be permutations that don't "make sense". it looks on the face of it like these could, surely, be used "for other purposes"? and the answer's no, they can't. l. From programmerjake at gmail.com Wed Mar 10 18:15:15 2021 From: programmerjake at gmail.com (Jacob Lifshay) Date: Wed, 10 Mar 2021 10:15:15 -0800 Subject: [Libre-soc-dev] scalar instructions and SVP64 In-Reply-To: References: Message-ID: On Tue, Mar 9, 2021, 19:39 Adam Van Ymeren wrote: > On March 9, 2021 5:05:02 p.m. PST, Jacob Lifshay > wrote: > >On Tue, Mar 9, 2021, 16:50 Luke Kenneth Casson Leighton > >wrote: > > > >> On Wednesday, March 10, 2021, Jacob Lifshay > > > >> wrote: > >> > >> > https://libre-soc.org/irclog/%23libre-soc.2021-03-10.log. > >> > html#t2021-03-10T00:11:21 > >> > > >> > You see why we need VL to be ignored when there aren't any vector > >> > arguments? > >> > >> > >> late (1am), the short answer is no. > >> > > > >Well, then we need to change the spec since a "no" answer is > >effectively > >unworkable from a SW perspective, as (poorly) illustrated by that > >example > >code. > > Can you outline in more detail why it is unworkable from a SW > perspective? It seems from a cursory look easily workable by just setting > VL=1 and element size to 64-bit. > The reason is that GPU code has scalar and vector code mixed together everywhere, so SV not having separate scalar instructions could increase instruction count by >10% due to the additional setvl instructions, also it could greatly increase pipeline stalls on dynamic setvl, since the VL-loop stage has to wait for the setvl execution to know what VL to use (for setvli a stall isn't needed since the decoder can just use the value from the immediate field, no wait required). This comes from the basic compiler optimization of using scalar instructions to do an operation once, then splat if needed, instead of using vector instructions when all vector elements are known to be identical. Basically all modern GPUs have that optimization, also described as detecting the difference between uniform and varying SIMT variables before the whole-function-vectorization pass. If that optimization isn't done, it will increase power consumption substantially and will take longer to run due to the many additional instructions jamming up the issue width. Decoding should only take a few more gates (around 10, less than 100) since you just have a few separate gates to OR all vector/scalar SVP64 bits together for each SVP64 prefix kind (there's only around 5 kinds) and use a mux based on the decoded number of registers (which I expect the decoder to need anyway for dependency matrix stuff) to select which OR gate's output to use. This produces a vector_and_not_scalar signal that should be easy to add to the VL-loop stage. if the VL-loop logic is a stage after the decoder instead of merged into the last stage of the decoder, we won't need any of the speculative decode logic in the following paragraph since all the required information already propagated the previous clock cycle or has plenty of time to propagate in the current clock cycle if just the vector/scalar part is decoded in the VL-loop logic stage. This would be on the order of 10 gates with a propagation delay of 2-3 gates from the beginning of the clock cycle -- easily achievable. If the above doesn't work, we can fall back to the more complex implementation: decoding still won't take longer since the decoder can speculatively issue max(1, min(issue_width, VL)) instructions and cancel all but 1 the next cycle if it determines that the instruction is scalar -- the canceled instructions may not even need to be scheduled since they can be removed before getting to the scheduler if there's enough pipeline time. Though, > I can see it being a bit of extra work for compilers to know that > accessing high numbered registers requires a bit of extra work but that > really doesn't sound unworkable to me. > Technically that would work, it would just mean that scalar code could be severely limited. > > I can however imagine that adding a special case for VL==0 could result in > many more gates/complication for the OoO/scoreboard execution engine. > That's handled in the fetch pipeline before the scheduler in the VL-loop stage, so the stuff after that doesn't know/care since the instructions are removed before then. Also, in my mind SV should have always had full separate scalar arguments/instructions, since otherwise we get a half-done attempt at having scalar code that makes the compiler *more* complex -- the compiler already has to handle having separate codepaths for scalar and vector instructions, just, without the ISA-level concept of scalar SVP64 instructions, it adds many more special cases to translating scalar instructions, since they may need to be converted to effectively vector instructions with VL needing to be guaranteed non-zero, often requiring saving VL (if it was modified from fail-on-first), overwriting VL, running the scalar op, then overwriting VL again to restore VL for the surrounding vector ops. Jacob > From lkcl at lkcl.net Wed Mar 10 18:19:28 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 10 Mar 2021 18:19:28 +0000 Subject: [Libre-soc-dev] scalar instructions and SVP64 In-Reply-To: References: Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Wed, Mar 10, 2021 at 6:15 PM Jacob Lifshay wrote: > stage has to wait for the setvl execution to know what VL to use (for > setvli a stall isn't needed since the decoder can just use the value from > the immediate field, no wait required). setvli is a pseudo-op for setvl. https://libre-soc.org/openpower/sv/setvl/ l. From lkcl at lkcl.net Wed Mar 10 18:20:37 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 10 Mar 2021 18:20:37 +0000 Subject: [Libre-soc-dev] scalar instructions and SVP64 In-Reply-To: References: Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Wed, Mar 10, 2021 at 6:15 PM Jacob Lifshay wrote: > > I can however imagine that adding a special case for VL==0 could result in > > many more gates/complication for the OoO/scoreboard execution engine. > > > > That's handled in the fetch pipeline before the scheduler in the VL-loop > stage, so the stuff after that doesn't know/care since the instructions are > removed before then. this is factually wrong. explained already. l. From libre-soc at platen-software.de Wed Mar 10 18:47:16 2021 From: libre-soc at platen-software.de (Tobias Platen) Date: Wed, 10 Mar 2021 19:47:16 +0100 Subject: [Libre-soc-dev] daily kan-ban update 10mar2021 Message-ID: <20210310194716.f5e5f58c0b3c60011bb1c6b8@platen-software.de> today: implement read access to page table, now I need to define a mock page table for testing. -- Tobias Platen From lkcl at lkcl.net Wed Mar 10 19:20:14 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 10 Mar 2021 19:20:14 +0000 Subject: [Libre-soc-dev] scalar instructions and SVP64 In-Reply-To: References: Message-ID: jacob i suspect what has happened is that gmail has marked messages as read without your consent and knowledge. it did this to me and i saw neither hendrik nor adam's message until i reviewee the archives. could you go back and check because i wrote a comprehensive description of how the hardware will be performance compromised yet only 30 minutes ago you advocated exactly such a compromised idea. l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From lkcl at lkcl.net Wed Mar 10 19:25:40 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 10 Mar 2021 19:25:40 +0000 Subject: [Libre-soc-dev] daily kan-ban update 10mar2021 In-Reply-To: <20210310194716.f5e5f58c0b3c60011bb1c6b8@platen-software.de> References: <20210310194716.f5e5f58c0b3c60011bb1c6b8@platen-software.de> Message-ID: On Wednesday, March 10, 2021, Tobias Platen wrote: > today: implement read access to page table, > now I need to define a mock page table for testing. using the same ones in the mmu tests would be good. the same dictionary for wb_get. the only thing is that class Mem it is imperative that it be changed to use a sparse array (aka a "dict") if you ttry to pass it an initial_mem with entries up to 0x1000000000 etc etc it will literally allocate a list of size 0x100000000 entries. clearly that's not going to work. l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From programmerjake at gmail.com Wed Mar 10 19:40:58 2021 From: programmerjake at gmail.com (Jacob Lifshay) Date: Wed, 10 Mar 2021 11:40:58 -0800 Subject: [Libre-soc-dev] scalar instructions and SVP64 In-Reply-To: References: Message-ID: On Wed, Mar 10, 2021, 11:20 Luke Kenneth Casson Leighton wrote: > jacob i suspect what has happened is that gmail has marked messages as read > without your consent and knowledge. it did this to me and i saw neither > hendrik nor adam's message until i reviewee the archives. > > could you go back and check because i wrote a comprehensive description of > how the hardware will be performance compromised yet only 30 minutes ago > you advocated exactly such a compromised idea. > I saw that, I wrote in my email exactly how the hardware won't have an issue for the fetch/decode/VL-loop pipe because what I described (not the speculative issue then cancel paragraph) shows exactly how the decoder won't need additional pipeline stages: I'd expect the additional gate cost to be on the order of 10 gates in the decoder and 20-30 gates in the VL-loop stage (which I'm assuming comes after the decoder). It should add 1-2 gate delays to the last decode stage if on the critical path (unlikely), otherwise 0 delay. Depending on implementation strategy, it should add 1-2 gate delays to the VL-loop stage, which I expect to not have tight timing due to it being mostly just muxes. Also, remember that the overall scalar/vector is an output of the decoder, none of the rest of the decoder needs to know/care what value it has, so it can be easily decoded in parallel with the rest of the instruction -- not serially like you feared. Jacob From lkcl at lkcl.net Wed Mar 10 19:53:09 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 10 Mar 2021 19:53:09 +0000 Subject: [Libre-soc-dev] scalar instructions and SVP64 In-Reply-To: References: Message-ID: On Wednesday, March 10, 2021, Jacob Lifshay wrote: > > I'd expect the additional gate cost to be on the order of 10 gates in the > decoder and 20-30 gates in the VL-loop stage (which I'm assuming comes > after the decoder). no! please see the test issuer source code and discussions which have been ongoing for several weeks now. the instruction decoder is *after* the VL identification because VL is part of the same state including SVSTATE MSR and PC. the instruction is *not* decoded - at all - at the point where SVP64 has been identified. PowerDecoder2 is 4,000+ gates and is so big it has to be divided into 2 separate pipeline stages (12 individual satellite decoders one per pipeline) that 4,000 gates is a massive long mux cascade where it is COMPLETELY unacceptable to make anything critically depend on it. and everything that you suggest due to this fundamental misunderstanding of what SV is categorically requires exactly that. therefore the answer is and will always remain "no". l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From programmerjake at gmail.com Wed Mar 10 20:47:10 2021 From: programmerjake at gmail.com (Jacob Lifshay) Date: Wed, 10 Mar 2021 12:47:10 -0800 Subject: [Libre-soc-dev] scalar instructions and SVP64 In-Reply-To: References: Message-ID: On Wed, Mar 10, 2021, 11:53 Luke Kenneth Casson Leighton wrote: > On Wednesday, March 10, 2021, Jacob Lifshay > wrote: > > > > > I'd expect the additional gate cost to be on the order of 10 gates in the > > decoder and 20-30 gates in the VL-loop stage (which I'm assuming comes > > after the decoder). > > > no! please see the test issuer source code and discussions which have been > ongoing for several weeks now. > yes...that can be changed relatively easily since you can/have-to-anyway decode instructions before incrementing register numbers -- the decoder stage can go before the VL-loop FSM. > > the instruction decoder is *after* the VL identification because VL is part > of the same state including SVSTATE MSR and PC. > VL and SVSTATE don't affect how the instruction decodes...therefore the instruction can be decoded (at least enough to determine SV/scheduling properties -- the rest can be done in the execution pipelines like usual) before the SV loop FSM, the SV loop FSM only needs to increment register numbers and count up to VL (only for vector ops). The SV loop FSM becomes a no-op pass-through for scalar instructions, SVP64 or not. > > the instruction is *not* decoded - at all - at the point where SVP64 has > been identified. > > PowerDecoder2 is 4,000+ gates and is so big it has to be divided into 2 > separate pipeline stages (12 individual satellite decoders one per > pipeline) > > that 4,000 gates is a massive long mux cascade where it is COMPLETELY > unacceptable to make anything critically depend on it. > > and everything that you suggest due to this fundamental misunderstanding of > what SV is categorically requires exactly that. > Well, I'm saying that SV should be changed if we want efficiency, rather than piling more and more kludges on the ISA to force scalar ops to fit in the vector-shaped hole that you seem to have conflated with SVP64. Also, take another look at the old SVP48/SVP64 for RISC-V, pay attention and note that it specifically includes scalar ops for all prefixed instructions: https://libre-soc.org/simple_v_extension/sv_prefix_proposal/ the scalar ops are when all vs#/vd fields are set to scalar. An alternative option that achieves the same end goal without needing to move the decoder is to use the scalar/vector-bit for the first/dest reg (which is always in the same spot -- instruction forms without a dest reg can have their SVP64 register fields moved one reg field over to make space) as a whole-instruction scalar/vector-bit, the operations that that removes (those with scalar dest but vector arguments -- which are not common instructions) can be effectively substituted with scalar mv.x. Since the bit is always in the same spot and all instructions have that bit, decoding it from the SVP64 prefix then becomes utterly trivial. This also simplifies the logic for the SV loop FSM since it no longer needs to implement the write-once-then-finish logic which I expect to be quite complex. Jacob From lkcl at lkcl.net Wed Mar 10 20:48:55 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 10 Mar 2021 20:48:55 +0000 Subject: [Libre-soc-dev] scalar instructions and SVP64 In-Reply-To: References: Message-ID: ok i'll go through it. here's the 3 FSMs, intended to be indicative for future designs of pipeline stages and to make multi issue clear https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/simple/issuer.py;h=e0bd35951644d10041c7635d3ee0f252879639ee;hb=HEAD#l613 they are named fetch, issue and execute. * fetch performs fetch and also identifies length through bare minimum identification of SVP64. it also reads PC MSR and SVSTATE. it is also supposed to (apart from trap and branch) be the only place that updates PC but hey. * issue receives PC MSR and SVSTATE. it also receives SVP64 RM and insn. it is responsible for going "if 32 bit fire execute immediately" else "if SVP64 run a loop firing one instruction per SVSTATE.srcstep". here is where the core state PC MSR and SVSTATE are passed into a "global" PowerDecoder2 which will performs the addition of srcstep onto RA, RB, RS, RT, all CRs and all SPR numbers (TODO, that one) PowerDecoder2 has just enough to identify which pipeline should decode and process the instruction. * execute is where (because this is a Test Issuer) one and ONLY one pipeline receives the instruction. by this point it is PURELY a 32 bit instruction, register data has already been read. a SATELLITE PowerDecoderSubset performs decoding UNIQUE and SPECIFIC to that Function Unit. now let's do that again, this time in a multi issue environment * multiple instructions are fetched. they are all length-decoded in parallel (using that superb carry-lookahead-like algorithm you devised, Jacob) any 32 bit instructions are sent through to the next phase along with an incremented "PC+0" PC+4 PC+8 etc. when a 64 bit instruction is encountered it has to be the last one sent on (for now, optimisations come later) * any 32 bit instructions get further decoded and sent to relevant pipelines. however 64 bit ones the SVSTSTE.srcstep is autoincremented INSTEAD of the PC, their PowerDecoder2s then have all the information they need, and proceed just like the 32 bit ones. * all pipelines receive ONLY 32 bit instructions just like in the FSM case. now. can you see that by adding in a BACKWARDS dependency between the PowerDecoder2s, which are the ONLY PLACES where the EXTRA2/3 information may be decoded, and where there are MASSIVE mux cascades, the above forward structure which is otherwise completely independent and (apart from PC and setvl changes which use precise speculation and branch prediction to solve), is completely compromised? the only way to get what you are advocating is to combine two of the 3 stages above, introduce huge latency, which completely compromises high performance. can you see that? l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From programmerjake at gmail.com Wed Mar 10 23:35:42 2021 From: programmerjake at gmail.com (Jacob Lifshay) Date: Wed, 10 Mar 2021 15:35:42 -0800 Subject: [Libre-soc-dev] scalar instructions and SVP64 In-Reply-To: References: Message-ID: On Wed, Mar 10, 2021, 12:49 Luke Kenneth Casson Leighton wrote: > ok i'll go through it. here's the 3 FSMs, intended to be indicative for > future designs of pipeline stages and to make multi issue clear > > > https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/simple/issuer.py;h=e0bd35951644d10041c7635d3ee0f252879639ee;hb=HEAD#l613 > > they are named fetch, issue and execute. > > * fetch performs fetch and also identifies length through bare minimum > identification of SVP64. it also reads PC MSR and SVSTATE. > > it is also supposed to (apart from trap and branch) be the only place that > updates PC but hey. > > * issue receives PC MSR and SVSTATE. it also receives SVP64 RM and insn. > > it is responsible for going "if 32 bit fire execute immediately" else "if > SVP64 run a loop firing one instruction per SVSTATE.srcstep". > And all that changes is it gets changed to "if 32-bit or SVP64-scalar then execute immediately else loop..." > > here is where the core state PC MSR and SVSTATE are passed into a "global" > PowerDecoder2 which will performs the addition of srcstep onto RA, RB, RS, > RT, all CRs and all SPR numbers (TODO, that one) > Aside: I'd argue that SPR numbers shouldn't be incremented, that'd be more like incrementing the opcode than a register number, since every SPR does something totally different. That's a different discussion though... > > PowerDecoder2 has just enough to identify which pipeline should decode and > process the instruction. > This is where the decoder has enough info to identify the number of register fields in the SVP64 prefix, so we just add the few extra gates to OR the vector/scalar bits here. > > * execute is where (because this is a Test Issuer) one and ONLY one > pipeline receives the instruction. > > by this point it is PURELY a 32 bit instruction, register data has already > been read. a SATELLITE PowerDecoderSubset performs decoding UNIQUE and > SPECIFIC to that Function Unit. > > > now let's do that again, this time in a multi issue environment > > * multiple instructions are fetched. they are all length-decoded in > parallel (using that superb carry-lookahead-like algorithm you devised, > Jacob) > > any 32 bit instructions are sent through to the next phase along with an > incremented "PC+0" PC+4 PC+8 etc. > > when a 64 bit instruction is encountered it has to be the last one sent on > (for now, optimisations come later) > all the 32-bit vs. 64-bit here gets changed to 32-bit/64-bit scalar vs. 64-bit vector. > > * any 32 bit instructions get further decoded and sent to relevant > pipelines. > > however 64 bit ones the SVSTSTE.srcstep is autoincremented INSTEAD of the > PC, their PowerDecoder2s then have all the information they need, and > proceed just like the 32 bit ones. > > * all pipelines receive ONLY 32 bit instructions just like in the FSM case. > > > now. > > can you see that by adding in a BACKWARDS dependency between the > PowerDecoder2s, which are the ONLY PLACES where the EXTRA2/3 information > may be decoded, and where there are MASSIVE mux cascades, the above forward > structure which is otherwise completely independent and (apart from PC and > setvl changes which use precise speculation and branch prediction to > solve), is completely compromised? > > the only way to get what you are advocating is to combine two of the 3 > stages above, introduce huge latency, which completely compromises high > performance. > If we instead go with the alternative encoding described in my previous email: "...scalar/vector-bit for the first/dest reg...as a whole-instruction scalar/vector-bit", since that encoding has the whole-instruction-level scalar/vector bit in every SVP64 instruction and it's always in the same place, that allows us to trivially change the vector vs. scalar determination to vector 64-bit vs. scalar 32/64-bit instead of what we currently have -- vector 64-bit vs. scalar 32-bit. > > can you see that? > I can see what you're fearing, *however*: > the alternative scheme with the whole-instruction-level scalar/vector bit working just fine is clearly visible :) Also, the non-alternative scheme I'm proposing with OR-ing together vector/scalar-bits will work just fine: the fetch pipeline (everything before instructions are added to the dep. matrixes) *has* to at some point decode the instructions enough to know which registers are read/written -- I'm saying we just move that decoding to sometime after length decode and before SV looping because that *exact* information that we need to decode anyway *is the same info.* that's required to decide which SVP64 bits to OR together to form the whole-instruction scalar/vector bit, which then tells the SV looping stage to pass the instruction unvectorized (scalar 32/64-bit) or to loop VL*SUBVL times. Basically, we re-order the stages somewhat to get a trivially-small dependency graph, not add massive dependency messes because we used the wrong order. Jacob From lkcl at lkcl.net Wed Mar 10 23:40:53 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 10 Mar 2021 23:40:53 +0000 Subject: [Libre-soc-dev] scalar bitmanip openpower extension draft Message-ID: https://libre-soc.org/openpower/sv/bitmanip/ Toshaan, hi above is a very early draft of a scalar bitmanip extension. it's... comprehensive, shall we say. combining variants on the ternary op from AVX512 some of which have not been seen before in any ISA and would allow emulation of FPGA LUT4 behaviour for example. general-purpose Galois Field arithmetic (multiply is a *four* operand input although a case could be made for setting a "mode" just like in VSX Matrix "accumulator" operations) the usual suspects grevi, bpermd, bitmatxor, crc32, many of which come from RV bitmanip. it is a mish-mash basically and yet the case for many of them thanks in particular to RV research is very clear. some of them have to be added because they are in VSX (only), and of course if no VSX then performance suffers. integer minmax is a good example there. there is a VSX minmax, there is FP scalar minmax, but no *integer* scalar minmax. quite an odd omission. the only downside is, i wasn't kidding that they're comprehensive, i.e. expensive in terms of opcode space. these will need an entire major opcode of their own. l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From lkcl at lkcl.net Thu Mar 11 00:08:21 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 11 Mar 2021 00:08:21 +0000 Subject: [Libre-soc-dev] scalar instructions and SVP64 In-Reply-To: References: Message-ID: On Wednesday, March 10, 2021, Jacob Lifshay wrote: > On Wed, Mar 10, 2021, 12:49 Luke Kenneth Casson Leighton > wrote: > > > ok i'll go through it. here's the 3 FSMs, intended to be indicative for > > future designs of pipeline stages and to make multi issue clear > > > > > > https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/ > simple/issuer.py;h=e0bd35951644d10041c7635d3ee0f252879639ee;hb=HEAD#l613 > > > > they are named fetch, issue and execute. > > > > * fetch performs fetch and also identifies length through bare minimum > > identification of SVP64. it also reads PC MSR and SVSTATE. > > > > it is also supposed to (apart from trap and branch) be the only place > that > > updates PC but hey. > > > > * issue receives PC MSR and SVSTATE. it also receives SVP64 RM and insn. > > > > it is responsible for going "if 32 bit fire execute immediately" else "if > > SVP64 run a loop firing one instruction per SVSTATE.srcstep". > > > > And all that changes is it gets changed to "if 32-bit or SVP64-scalar then > execute immediately else loop..." "and all that". *think it through* jacob. i have said this about three times in 12 hours and you still haven't got it. *where does the detection of bits required to detect that operands are marked scalar come from* > > > > here is where the core state PC MSR and SVSTATE are passed into a > "global" > > PowerDecoder2 which will performs the addition of srcstep onto RA, RB, > RS, > > RT, all CRs and all SPR numbers (TODO, that one) > > > > Aside: I'd argue that SPR numbers shouldn't be incremented, that'd be more > like incrementing the opcode than a register number, since every SPR does > something totally different. That's a different discussion though... briefly, it's for saving batches of SPRs in context switches for SV state information. those *will* be contiguously allocated. > > > > PowerDecoder2 has just enough to identify which pipeline should decode > and > > process the instruction. > > > > This is where the decoder has enough info to identify the number of > register fields in the SVP64 prefix, so we just add the few extra gates to > OR the vector/scalar bits here. and it is TOO LATE. the forward chain (pipeline) has ALREADY COMMITTED to the decision. pipelines CANNOT GO BACKWARDS IN TIME. what you are asking requires the MERGING of two already-close-to-the-limit pipeline stages. do you understand? it is quite surreal to repeat this three times. > > > > * execute is where (because this is a Test Issuer) one and ONLY one > > pipeline receives the instruction. > > > > by this point it is PURELY a 32 bit instruction, register data has > already > > been read. a SATELLITE PowerDecoderSubset performs decoding UNIQUE and > > SPECIFIC to that Function Unit. > > > > > > now let's do that again, this time in a multi issue environment > > > > * multiple instructions are fetched. they are all length-decoded in > > parallel (using that superb carry-lookahead-like algorithm you devised, > > Jacob) > > > > any 32 bit instructions are sent through to the next phase along with an > > incremented "PC+0" PC+4 PC+8 etc. > > > > when a 64 bit instruction is encountered it has to be the last one sent > on > > (for now, optimisations come later) > > > > all the 32-bit vs. 64-bit here gets changed to 32-bit/64-bit scalar vs. > 64-bit vector i have no idea what you are referring to here. > > > > > * any 32 bit instructions get further decoded and sent to relevant > > pipelines. > > > > however 64 bit ones the SVSTSTE.srcstep is autoincremented INSTEAD of the > > PC, their PowerDecoder2s then have all the information they need, and > > proceed just like the 32 bit ones. > > > > * all pipelines receive ONLY 32 bit instructions just like in the FSM > case. > > > > > > now. > > > > can you see that by adding in a BACKWARDS dependency between the > > PowerDecoder2s, which are the ONLY PLACES where the EXTRA2/3 information > > may be decoded, and where there are MASSIVE mux cascades, the above > forward > > structure which is otherwise completely independent and (apart from PC > and > > setvl changes which use precise speculation and branch prediction to > > solve), is completely compromised? > > > > the only way to get what you are advocating is to combine two of the 3 > > stages above, introduce huge latency, which completely compromises high > > performance. > > > > If we instead go with the alternative encoding NO. far, far too late. raise it as a bugreport, document it, then please drop it and help with implementation. i have said this a number of times, we are under time and funding pressure and need to get the implementation done. > described in my previous > email: "...scalar/vector-bit for the first/dest reg...as a > whole-instruction scalar/vector-bit", since that encoding has the > whole-instruction-level scalar/vector bit in every SVP64 instruction and > it's always in the same place, this is far too late! this should have been raised 20 months ago! certainly not right smack in the middle of implementation! certainly not when i have made it repeatedly clear that we are under both time and funding pressure *and have code already written* we cannot request twice the money from NLnet for throwing away code and implementing something else at this late stage. that allows us to trivially change the > vector vs. scalar determination to vector 64-bit vs. scalar 32/64-bit > instead of what we currently have -- vector 64-bit vs. scalar 32-bit. > > > > > can you see that? > > > > I can see what you're fearing, *however*: > > > the alternative scheme with the whole-instruction-level scalar/vector bit > working just fine is clearly visible :) > > Also, the non-alternative scheme I'm proposing with OR-ing together > vector/scalar-bits will work just fine: the fetch pipeline i have no idea what you are talking about because the focus is on implementation and on getting the spec implemented. spec design phase ended MONTHS ago. new spec design ideas *actively* interfere with the completion of implementation because they require abandoning working knowledge that is in people's heads. it is too much, Jacob. i have repeated this many times and you do not seem to respect it. > (everything > before instructions are added to the dep. matrixes) *has* to at some point > decode the instructions enough to know which registers are read/written -- > I'm saying we just move that decoding to sometime after length decode and no! this completely destroys SV by creating a massive gate chain! this would completely destroy SV's chances by creating a hard limit on the maximum clock rate regardless of geometry. how many times do i have to say NO! > before SV looping because that *exact* information that we need to decode > anyway *is the same info.* that's required to decide which SVP64 bits to OR > together to form the whole-instruction scalar/vector bit, which then tells > the SV looping stage to pass the instruction unvectorized (scalar > 32/64-bit) or to loop VL*SUBVL times. Basically, we re-order the stages > somewhat to get a trivially-small dependency graph, no. again, no. this is *far* too late Jacob. we are in IMPLEMENTATION mode. NOT specification total redesign mode. *please* help with the IMPLEMENTATION so that we can fulfil our obligations and promises to customers and to NLnet. i have asked quietly several times now. we are under an obligation to NLnet under their MoU to work on this full time, and there are no source code commits or status update reports from you in several weeks. this has me concerned for some time. l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From lkcl at lkcl.net Thu Mar 11 00:25:47 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 11 Mar 2021 00:25:47 +0000 Subject: [Libre-soc-dev] scalar instructions and SVP64 In-Reply-To: References: Message-ID: On Wednesday, March 10, 2021, Jacob Lifshay wrote: Also, in my mind SV should have always had full separate scalar > arguments/instructions, unfortunately this also destroys the benefits of SV by doubling the number of instructions. again: these are ideas that should have been raised and discussed 20 months ago. the focus is now on implementation. which needs urgent help. l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From lkcl at lkcl.net Thu Mar 11 11:21:06 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 11 Mar 2021 11:21:06 +0000 Subject: [Libre-soc-dev] scalar instructions and SVP64 In-Reply-To: References: Message-ID: ok. so let's go through what is needed to implement this idea. * first, we would need everyone to stop what they are doing. that includes world-wide IBM personnel whom Ganesan very kindly notified, because the specification is now declared "invalid", also Paul who is on holiday needs to be notified to stop looking at it. * second the specification needs to be updated. this will require a minimum 3 weeks possibly 4 involving discussion of whether it's appropriate, because some of the RM-NN-NNNN combinations are not going to be possible. * third, we need to start again with sv_analysis.py. this will be 2 weeks of comprehensive detailed study of the entire v3.0B scalar ISA to ensure that each instruction fits with the proposed change, and approximately one week of implementation time. * then the SVP64Asm class needs to be changed. 2-3 days * then the SVP64RM class needs to be changed and associated power_enum.py constants updated. about 2-3 days. * then PowerDecoder2 needs to be changed. another week. you get the idea. questions: 1) do we have time to do that right now? answer: no 2) do we have the funding to do that right now? answer: no 3) what would be the impact of the above delays our completion schedules? answer: really bad. you get the general idea? if you were talking about a small incremental non-disruptive change, i would not have any difficulty with this. however the combinations of EXTRA2/3 here: https://libre-soc.org/openpower/sv/svp64/ they include MASK_SRC in two of them which takes up some of the bits. this makes it basically flat-out impossible to do what you propose without a massive disruptive rewrite. so please. can you please. document the idea, raise a bugreport and then please, help with implementation. l. From libre-soc at platen-software.de Thu Mar 11 17:06:41 2021 From: libre-soc at platen-software.de (Tobias Platen) Date: Thu, 11 Mar 2021 18:06:41 +0100 Subject: [Libre-soc-dev] daily kan-ban update 11mar2021 In-Reply-To: References: <20210310194716.f5e5f58c0b3c60011bb1c6b8@platen-software.de> Message-ID: <20210311180641.e008412cf24cf01e4edae9af@platen-software.de> On Wed, 10 Mar 2021 19:25:40 +0000 Luke Kenneth Casson Leighton wrote: > On Wednesday, March 10, 2021, Tobias Platen > wrote: > > > today: implement read access to page table, > > now I need to define a mock page table for testing. > > > using the same ones in the mmu tests would be good. the same dictionary > for wb_get. > > the only thing is that class Mem it is imperative that it be changed to > use a sparse array (aka a "dict") > > if you ttry to pass it an initial_mem with entries up to 0x1000000000 etc > etc it will literally allocate a list of size 0x100000000 entries. > > clearly that's not going to work. > > l. > > > > -- > --- > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 > _______________________________________________ > Libre-soc-dev mailing list > Libre-soc-dev at lists.libre-soc.org > http://lists.libre-soc.org/mailman/listinfo/libre-soc-dev I' start having a look at the class mem, and how the interface can be unified. From programmerjake at gmail.com Thu Mar 11 17:07:58 2021 From: programmerjake at gmail.com (Jacob Lifshay) Date: Thu, 11 Mar 2021 09:07:58 -0800 Subject: [Libre-soc-dev] scalar instructions and SVP64 In-Reply-To: References: Message-ID: On Thu, Mar 11, 2021, 03:21 Luke Kenneth Casson Leighton wrote: > document the idea, raise a bugreport and then please, > > help with implementation. Sure. Jacob From libre-soc at platen-software.de Thu Mar 11 17:36:39 2021 From: libre-soc at platen-software.de (Tobias Platen) Date: Thu, 11 Mar 2021 18:36:39 +0100 Subject: [Libre-soc-dev] daily kan-ban update 11mar2021 Message-ID: <20210311183639.455d1e695ed8ce201622bc35@platen-software.de> today: had a look at class Mem, testing access to first entry class Mem: def __init__(self, row_bytes=8, initial_mem=None): self.mem = {} -- Tobias Platen From lkcl at lkcl.net Thu Mar 11 17:49:55 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 11 Mar 2021 17:49:55 +0000 Subject: [Libre-soc-dev] scalar instructions and SVP64 In-Reply-To: References: Message-ID: On Thursday, March 11, 2021, Jacob Lifshay wrote: > > > > Sure. thanks jacob. we have a ridiculous amount to get done. l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From lkcl at lkcl.net Thu Mar 11 17:51:50 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 11 Mar 2021 17:51:50 +0000 Subject: [Libre-soc-dev] daily kan-ban update 11mar2021 In-Reply-To: <20210311183639.455d1e695ed8ce201622bc35@platen-software.de> References: <20210311183639.455d1e695ed8ce201622bc35@platen-software.de> Message-ID: On Thursday, March 11, 2021, Tobias Platen wrote: > today: had a look at class Mem, testing access to first entry > > class Mem: > def __init__(self, row_bytes=8, initial_mem=None): > self.mem = {} yes, see bug #604 can we please transfer the conversation there it should be fine to pass the full mmu page table dictionary into class Mem without running out of memory. l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From libre-soc at platen-software.de Thu Mar 11 17:55:51 2021 From: libre-soc at platen-software.de (Tobias Platen) Date: Thu, 11 Mar 2021 18:55:51 +0100 Subject: [Libre-soc-dev] daily kan-ban update 11mar2021 Message-ID: <20210311185551.3a4d03b3f26dd7d78439f893@platen-software.de> today: had a look at class Mem, testing access to first entry class Mem: def __init__(self, row_bytes=8, initial_mem=None): self.mem = {} -- Tobias Platen From libre-soc at platen-software.de Thu Mar 11 18:55:03 2021 From: libre-soc at platen-software.de (Tobias Platen) Date: Thu, 11 Mar 2021 19:55:03 +0100 Subject: [Libre-soc-dev] Test Message-ID: <20210311195503.b6b0197fb36a06397f3894a0@platen-software.de> is the mailing list working? -- Tobias Platen From lkcl at lkcl.net Thu Mar 11 19:03:03 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 11 Mar 2021 19:03:03 +0000 Subject: [Libre-soc-dev] Test In-Reply-To: <20210311195503.b6b0197fb36a06397f3894a0@platen-software.de> References: <20210311195503.b6b0197fb36a06397f3894a0@platen-software.de> Message-ID: On Thursday, March 11, 2021, Tobias Platen wrote: > is the mailing list working? yes. except sometimes you have to check spam. l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From lkcl at lkcl.net Thu Mar 11 19:06:28 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 11 Mar 2021 19:06:28 +0000 Subject: [Libre-soc-dev] Test In-Reply-To: References: <20210311195503.b6b0197fb36a06397f3894a0@platen-software.de> Message-ID: tobias your server is rejecting with a 451 error "Server configuration problem" --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Thu, Mar 11, 2021 at 7:03 PM Luke Kenneth Casson Leighton wrote: > > > > On Thursday, March 11, 2021, Tobias Platen wrote: >> >> is the mailing list working? > > > yes. except sometimes you have to check spam. > > l. > > > > -- > --- > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 > From libre-soc at platen-software.de Thu Mar 11 19:25:06 2021 From: libre-soc at platen-software.de (Tobias Platen) Date: Thu, 11 Mar 2021 20:25:06 +0100 Subject: [Libre-soc-dev] Test Message-ID: <20210311202506.f112227e24a3fb481cddadab@platen-software.de> Just testing the mailserver -- Tobias Platen From libre-soc at platen-software.de Thu Mar 11 19:28:25 2021 From: libre-soc at platen-software.de (tpl00-libresoc) Date: Thu, 11 Mar 2021 20:28:25 +0100 Subject: [Libre-soc-dev] Test from webmail Message-ID: <7a2adc8022c279a2ffd368ca357ecd83@platen-software.de> Test From lkcl at lkcl.net Thu Mar 11 19:49:04 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 11 Mar 2021 19:49:04 +0000 Subject: [Libre-soc-dev] Test In-Reply-To: <20210311202506.f112227e24a3fb481cddadab@platen-software.de> References: <20210311202506.f112227e24a3fb481cddadab@platen-software.de> Message-ID: 2021-03-11 19:47:42 1lKOnE-0001uK-Lt H=mailin1.hostsharing.net [2a01:37:1000::53df:5fcb:0]: SMTP error from remote mail server after RCPT TO:: 451 4.3.5 : Recipient address rejected: Server configuration problem there is no need to send additional messages. when you have resolved the above problem with hostsharing.net all of the messages (approximately 20 currently in the mail queue) will be delivered. there is no need to send additional test messages. l. --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Thu, Mar 11, 2021 at 7:25 PM Tobias Platen wrote: > > Just testing the mailserver > > -- > Tobias Platen > > _______________________________________________ > Libre-soc-dev mailing list > Libre-soc-dev at lists.libre-soc.org > http://lists.libre-soc.org/mailman/listinfo/libre-soc-dev From lkcl at lkcl.net Thu Mar 11 21:44:12 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 11 Mar 2021 21:44:12 +0000 Subject: [Libre-soc-dev] synchronised incremental SV development planning In-Reply-To: References: <90c89296-ebd2-89ed-1db9-ea5b4b4722b8@gmail.com> Message-ID: latest fun and games: LD/ST when RA==0 of course needs to know if the *full* 7 bit is zero / nonzero or not. sigh. i added decoding/recognition of LD/ST immediates to SVP64Asm successfully, not the modes yet though. these are different from non-LDST in that mapreduce is not supported and unit/elstride can be specified. that allowed me to test sv.stw and i ran smack into RA==0 only testing 5 bits not 7. l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From lkcl at lkcl.net Fri Mar 12 14:01:49 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 12 Mar 2021 14:01:49 +0000 Subject: [Libre-soc-dev] libresoc-litex (moved litex integration to separate repo) Message-ID: i've moved all litex-related code to a separate repository, because it's not clear that litex integration has absolutely nothing to do with libresoc (or microwatt). this will require a git submodule update l. --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From programmerjake at gmail.com Sat Mar 13 00:11:41 2021 From: programmerjake at gmail.com (Jacob Lifshay) Date: Fri, 12 Mar 2021 16:11:41 -0800 Subject: [Libre-soc-dev] setvl immediate field definition broken Message-ID: In the wiki: https://libre-soc.org/openpower/sv/setvl/ > Note that the immediate (SVi) spans 7 bits (16 to 22), and that bit 22 and 23 is > reserved and must be zero. Setting bit 22 or 23 causes an illegal exception. keep in mind that bit 0 is the MSB and 31 is the LSB... Umm, the reserved bits are at the wrong end of the field, they should be at the MSB end, they are at the LSB end. being at the LSB end causes the immediate to only be valid for even values, rather than values < 64 as was intended, keeping in mind that immedate field values are 1 less than the corresponding MAXVL, since MAXVL==0 makes no sense. I suggest redefining the immediate field to be bits 16:23 inclusive, and setting bits 16 or 17 causes an illegal exception. fields.text will need to be modified too. What do the rest of you think? Jacob From lkcl at lkcl.net Sat Mar 13 00:30:45 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sat, 13 Mar 2021 00:30:45 +0000 Subject: [Libre-soc-dev] setvl immediate field definition broken In-Reply-To: References: Message-ID: On Saturday, March 13, 2021, Jacob Lifshay wrote: > > I suggest redefining the immediate field to be bits 16:23 inclusive, > and setting bits 16 or 17 causes an illegal exception. fields.text > will need to be modified too. numbers in MSB0 format are a damn nuisance. can i suggest just using all bits then saying "values greater than 63 are reserved"? that would have the desired effect without complicating things and without confusing thr hell out of me about which damn end the MSBs are in. it also makes it clear what the bits are for (larger VL, later) l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From programmerjake at gmail.com Sat Mar 13 01:04:53 2021 From: programmerjake at gmail.com (Jacob Lifshay) Date: Fri, 12 Mar 2021 17:04:53 -0800 Subject: [Libre-soc-dev] setvl immediate field definition broken In-Reply-To: References: Message-ID: On Fri, Mar 12, 2021 at 4:31 PM Luke Kenneth Casson Leighton wrote: > > On Saturday, March 13, 2021, Jacob Lifshay wrote: > > > > > I suggest redefining the immediate field to be bits 16:23 inclusive, > > and setting bits 16 or 17 causes an illegal exception. fields.text > > will need to be modified too. > > > numbers in MSB0 format are a damn nuisance. > > can i suggest just using all bits then saying "values greater than 63 are > reserved"? Sounds good, as long as we explicitly mention that reserved values *must* trap, since otherwise we end up with the OpenPower bad default of ignoring reserved valued. Also, we should disambiguate between values of the bits in the field and values of the assembly text level field, since they are off-by-one. > > it also makes it clear what the bits are for (larger VL, later) Yup, though I'm planning on using at least some of them for enabling increased register-file size, allowing easy backwards compatibility. In any case, non-zero bits are reserved for the future. I'll let you or whoever gets to it first to make the changes, I'm done for the day. Jacob From jules at penuchot.com Sat Mar 13 13:31:31 2021 From: jules at penuchot.com (Jules Penuchot) Date: Sat, 13 Mar 2021 14:31:31 +0100 Subject: [Libre-soc-dev] Introduction Message-ID: <027aa569-9baa-eefc-cb41-470a8a2d2f7c@penuchot.com> Hi everyone, I'm just introducing myself, my name is Jules Penuchot, I'm doing a PhD thesis at Paris-Saclay University on generative programming for parallel computing. My work basically consists in finding ways to leverage generative programming techniques (from template meta-programming to more bleeding edge techniques like compile-time fragment injection) to write high performance software that's as portable and maintainable as possible. I've been developing clang frontend tools for source transformation recently, and I saw you needed a C++ dev with compiler experience to work on a MESA 3D driver. I don't consider myself experienced enough to take the lead on such a project, but I'd be more than glad to assist. There is a lot for me to learn in the process, and I'd be more than happy to contribute to a project like Libre-SOC. Kind regards, Jules From whygee at f-cpu.org Sat Mar 13 13:44:09 2021 From: whygee at f-cpu.org (whygee at f-cpu.org) Date: Sat, 13 Mar 2021 14:44:09 +0100 Subject: [Libre-soc-dev] Introduction In-Reply-To: <027aa569-9baa-eefc-cb41-470a8a2d2f7c@penuchot.com> References: <027aa569-9baa-eefc-cb41-470a8a2d2f7c@penuchot.com> Message-ID: <5f3cbf7832e6a442af589cc0def8a496@f-cpu.org> On 2021-03-13 14:31, Jules Penuchot wrote: > Hi everyone, Bienvenue Jules ! :-) > Kind regards, > Jules yg From lkcl at lkcl.net Sat Mar 13 13:52:03 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sat, 13 Mar 2021 13:52:03 +0000 Subject: [Libre-soc-dev] Introduction In-Reply-To: <027aa569-9baa-eefc-cb41-470a8a2d2f7c@penuchot.com> References: <027aa569-9baa-eefc-cb41-470a8a2d2f7c@penuchot.com> Message-ID: (cc'ing eduardo and vivek, see http://lists.libre-soc.org/pipermail/libre-soc-dev/2021-March/002087.html ) On Sat, Mar 13, 2021 at 1:31 PM Jules Penuchot wrote: > > Hi everyone, > > I'm just introducing myself, my name is Jules Penuchot, I'm doing a PhD > thesis at Paris-Saclay University on generative programming for parallel > computing. oo :) > My work basically consists in finding ways to leverage > generative programming techniques (from template meta-programming to > more bleeding edge techniques like compile-time fragment injection) to > write high performance software that's as portable and maintainable as > possible. nice. did you see the latest by Xilinx? https://www.eetimes.com/xilinx-opens-up-vitis-hls-tool-for-fpgas/ they haven't released the LLVM-IR-to-netlist conversion part (that's still proprietary) but it is a good start. > I've been developing clang frontend tools for source transformation > recently, and I saw you needed a C++ dev with compiler experience to > work on a MESA 3D driver. yes. vivek is the lead on this. > I don't consider myself experienced enough to > take the lead on such a project, but I'd be more than glad to assist. > There is a lot for me to learn in the process, and I'd be more than > happy to contribute to a project like Libre-SOC. fantastic, great to hear from you. so as you can see i posted just last week about the roadmap for this driver: http://lists.libre-soc.org/pipermail/libre-soc-dev/2021-March/002089.html it's a progressive series of steps that has some interesting side-effects: a general-purpose software-rendered 3D MESA driver is one of them. i'll let vivek respond: if you're happy with the plan then we can move to the next step(s), are you happy with the Charter, you've found the mailing list already, etc. etc. warmest, l. From jules at penuchot.com Sat Mar 13 14:58:00 2021 From: jules at penuchot.com (Jules Penuchot) Date: Sat, 13 Mar 2021 15:58:00 +0100 Subject: [Libre-soc-dev] Introduction In-Reply-To: References: <027aa569-9baa-eefc-cb41-470a8a2d2f7c@penuchot.com> Message-ID: On 3/13/21 2:44 PM, whygee at f-cpu.org wrote: > On 2021-03-13 14:31, Jules Penuchot wrote: >> Hi everyone, > > Bienvenue Jules ! :-) Merci ! :) On 3/13/21 2:52 PM, Luke Kenneth Casson Leighton wrote: > nice. did you see the latest by Xilinx? > https://www.eetimes.com/xilinx-opens-up-vitis-hls-tool-for-fpgas/ > they haven't released the LLVM-IR-to-netlist conversion part > (that's still proprietary) but it is a good start. Haven't heard of that! I'm not familiar with FPGA development yet, but moving FPGA development into C++ sounds quite interesting to me, especially if you combine that to metaprogramming techniques... I should definitely dig that, thank you! >> I've been developing clang frontend tools for source transformation >> recently, and I saw you needed a C++ dev with compiler experience to >> work on a MESA 3D driver. > > yes. vivek is the lead on this. > >> I don't consider myself experienced enough to >> take the lead on such a project, but I'd be more than glad to assist. >> There is a lot for me to learn in the process, and I'd be more than >> happy to contribute to a project like Libre-SOC. > > fantastic, great to hear from you. so as you can see i posted just last week > about the roadmap for this driver: > http://lists.libre-soc.org/pipermail/libre-soc-dev/2021-March/002089.html > > it's a progressive series of steps that has some interesting side-effects: > a general-purpose software-rendered 3D MESA driver is one of them. I'm looking into it thanks! I'm scanning through this to get an idea of what the whole project is all about. > i'll let vivek respond: if you're happy with the plan then we can move to > the next step(s), are you happy with the Charter, you've found the mailing > list already, etc. etc. > > warmest, Happy with the plan, happy with the charter, thanks for the info! Regards, Jules From lkcl at lkcl.net Sat Mar 13 15:48:17 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sat, 13 Mar 2021 15:48:17 +0000 Subject: [Libre-soc-dev] Introduction In-Reply-To: References: <027aa569-9baa-eefc-cb41-470a8a2d2f7c@penuchot.com> Message-ID: On Sat, Mar 13, 2021 at 2:58 PM Jules Penuchot wrote: > On 3/13/21 2:52 PM, Luke Kenneth Casson Leighton wrote: > > http://lists.libre-soc.org/pipermail/libre-soc-dev/2021-March/002089.html > > > > it's a progressive series of steps that has some interesting side-effects: > > a general-purpose software-rendered 3D MESA driver is one of them. > > I'm looking into it thanks! I'm scanning through this to get an idea of > what the whole project is all about. basically, we're not doing "totally separate GPU totally separate ISA connect over shared-memory do some insane full-blown Inter-Process-System with massive queues and god knows what else" instead: 1) the shader is compiled. 2) the 3D instructions are ***NATIVE*** to the CPU. not, "native to a foreign GPU where the main CPU driver has to communicate with a competely alien system over shared memory" consequently, we are *actually* adding *actual* 3D opcodes to OpenPOWER, *and* adding predication, *and* adding Vectorisation, *and* adding Swizzle, *and* adding vec2/3/4 *and* adding Matrix operations and many more. but because this has never been done before, none of the existing Vulkan MESA drivers are of any use to us, and neither is google SwiftShader. therefore we need an incremental approach. > > i'll let vivek respond: if you're happy with the plan then we can move to > > the next step(s), are you happy with the Charter, you've found the mailing > > list already, etc. etc. > > > > warmest, > > Happy with the plan, happy with the charter, thanks for the info! excellent, ok so when you're ready send me an ssh public key. you can get set up with these: https://git.libre-soc.org/?p=dev-env-setup.git;a=blob;f=install-mesa-apt-reqs;hb=HEAD https://git.libre-soc.org/?p=dev-env-setup.git;a=blob;f=lsoc-mesa-dev-env-setup;hb=HEAD that will save you a lot of time l. From lkcl at lkcl.net Sat Mar 13 17:58:34 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sat, 13 Mar 2021 17:58:34 +0000 Subject: [Libre-soc-dev] synchronised incremental SV development planning In-Reply-To: References: <90c89296-ebd2-89ed-1db9-ea5b4b4722b8@gmail.com> Message-ID: thank you jacob for adding setvl yesterday, i added the pseudocode to the wiki and a couple of unit tests. next it can be added as a pipeline. i am actually wondering if, given that SVSTATE is a peer of MSR, if it might be better to add mfsvstate and mtsvstate. thoughts? l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From vivekvpandya at gmail.com Sun Mar 14 12:49:33 2021 From: vivekvpandya at gmail.com (vivek pandya) Date: Sun, 14 Mar 2021 18:19:33 +0530 Subject: [Libre-soc-dev] Introduction In-Reply-To: References: <027aa569-9baa-eefc-cb41-470a8a2d2f7c@penuchot.com> Message-ID: Hi Jules, Nice to meet you! I have been working on this experimental driver for sometime now. What I have been trying to do is inspired from https://github.com/baldurk/visor , as I only work on this on weekends and I am not an expert in mesa codebase or SwiftShader I am referring to simple implementations like visor. As this is a software rasterizer it has a GPUStatus struct to hold indexBuffer and vertexBuffer , image is also stored as a pointer to bytes. Basically no hw abstraction in linux driver space to use actual memory on a device , everything is on CPU memory. The driver is able to execute a simple DrawTriangle function which executes vertex shader and fragment shader through LLVM's ORCJit but it does not generate meaningful results. Because codegeneration is not yet aware about the GPUStatus struct, that is the next thing I have to do to get the first triangle. Current code generation is all code copied from AMD's radv driver implementation which is not a software rasterizer. The resterization is a bit slower but it can be improved by threads but not a priority for now. However since the driver is able to receive the Draw command that means lots of vkCreate... functions are implemented to do basic stuff that is required to get up to this point. Also I am able to run https://software.intel.com/content/www/us/en/develop/articles/api-without-secrets-introduction-to-vulkan-part-2.html that means driver is able to use image from a CPU memory and present it on display with mesa's WSI layers. And hopefully that means I am on the right path. Once I update codegen to use GPUStruct and get a triangle on screen it should be sufficient to prove that this is the correct way. The codebase is in C so it's a bit painful to work with. Also I have to use LLVM's C bindings to create IR an and that is very painful compared to LLVM's C++ API. The code has lots of unused code as I started copying things from other implementations, I will clean up things but not a priority. An experienced mesa/vulkan driver engineer may not have taken this path but once I get a triangle on screen I will be more confident about my approach. Hope this helps and if you dig into the codebase please feel free to send email to my email address (CC list) . I will be happy to explain. Thanks! Vivek On Sat, Mar 13, 2021 at 9:19 PM Luke Kenneth Casson Leighton wrote: > On Sat, Mar 13, 2021 at 2:58 PM Jules Penuchot wrote: > > > On 3/13/21 2:52 PM, Luke Kenneth Casson Leighton wrote: > > > > > http://lists.libre-soc.org/pipermail/libre-soc-dev/2021-March/002089.html > > > > > > it's a progressive series of steps that has some interesting > side-effects: > > > a general-purpose software-rendered 3D MESA driver is one of them. > > > > I'm looking into it thanks! I'm scanning through this to get an idea of > > what the whole project is all about. > > basically, we're not doing "totally separate GPU totally separate ISA > connect over shared-memory do some insane full-blown > Inter-Process-System with massive queues and god knows what else" > > instead: > > 1) the shader is compiled. > 2) the 3D instructions are ***NATIVE*** to the CPU. > > not, "native to a foreign GPU where the main CPU driver has to > communicate with a competely alien system over shared memory" > > consequently, we are *actually* adding *actual* 3D opcodes to > OpenPOWER, *and* adding predication, *and* adding Vectorisation, *and* > adding Swizzle, *and* adding vec2/3/4 *and* adding Matrix operations > and many more. > > but because this has never been done before, none of the existing > Vulkan MESA drivers are of any use to us, and neither is google > SwiftShader. > > therefore we need an incremental approach. > > > > i'll let vivek respond: if you're happy with the plan then we can move > to > > > the next step(s), are you happy with the Charter, you've found the > mailing > > > list already, etc. etc. > > > > > > warmest, > > > > Happy with the plan, happy with the charter, thanks for the info! > > excellent, ok so when you're ready send me an ssh public key. > > you can get set up with these: > > https://git.libre-soc.org/?p=dev-env-setup.git;a=blob;f=install-mesa-apt-reqs;hb=HEAD > > https://git.libre-soc.org/?p=dev-env-setup.git;a=blob;f=lsoc-mesa-dev-env-setup;hb=HEAD > > that will save you a lot of time > > l. > > _______________________________________________ > Libre-soc-dev mailing list > Libre-soc-dev at lists.libre-soc.org > http://lists.libre-soc.org/mailman/listinfo/libre-soc-dev > From colepoirier at gmail.com Sun Mar 14 20:59:33 2021 From: colepoirier at gmail.com (Cole Poirier) Date: Sun, 14 Mar 2021 13:59:33 -0700 Subject: [Libre-soc-dev] LibreSOC sim Message-ID: Hi Luke, I had to modify the Makefile in litex to get jtagremote to work when running litex/florent/sim.py. Is there a way that jtag remote can be added as a module without modifying upstream litex by adding ‘jtagremote’ to the litex/litex/build/sim/core/Makefile MODULES array? Cole From lkcl at lkcl.net Sun Mar 14 21:47:37 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 14 Mar 2021 21:47:37 +0000 Subject: [Libre-soc-dev] LibreSOC sim In-Reply-To: References: Message-ID: On Sunday, March 14, 2021, Cole Poirier wrote: > Hi Luke, > > I had to modify the Makefile in litex to get jtagremote to work when > running litex/florent/sim.py. yes. > Is there a way that jtag remote can be added > as a module without modifying upstream litex by adding ‘jtagremote’ to the > litex/litex/build/sim/core/Makefile MODULES array? no. not easily. do submit a request on their issue tracker, attach a patch. > > Cole > _______________________________________________ > Libre-soc-dev mailing list > Libre-soc-dev at lists.libre-soc.org > http://lists.libre-soc.org/mailman/listinfo/libre-soc-dev > -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From c.deguzman547 at gmail.com Sun Mar 14 21:30:13 2021 From: c.deguzman547 at gmail.com (Chris DeGuzman) Date: Sun, 14 Mar 2021 11:30:13 -1000 Subject: [Libre-soc-dev] New to the dev scene Message-ID: Hi, My name is Chris DeGuzman and I'd like to contribute to this project. I'm currently a computer engineering student at the University of Hawaii and I'm very new to the dev scene. Jacob suggested that I join the team to get some experience under my belt. I don't know how useful I'll be to this project or if I'll be able to contribute a significant amount, but if you guys will have me then I'm more than willing to give my all to get up to speed. I may have a rough time starting out since I am still a student, and it'll take some time to find a good balance between this project and school. I look forward to hearing back from you guys. Thanks, Chris From lkcl at lkcl.net Sun Mar 14 21:54:18 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 14 Mar 2021 21:54:18 +0000 Subject: [Libre-soc-dev] New to the dev scene In-Reply-To: References: Message-ID: On Sun, Mar 14, 2021 at 9:49 PM Chris DeGuzman wrote: > Hi, > My name is Chris DeGuzman and I'd like to contribute to this project. allo chris great to hear from you. > I'm > currently a computer engineering student at the University of Hawaii and > I'm very new to the dev scene. ooo, hawaiii, niiice :) my stepfather used to live there, got a 2nd hand Beetle given to him after getting one of the other 3 working. that was 30 years ago: chances are high that those VW Beetles are still there :) > Jacob suggested that I join the team to get > some experience under my belt. I don't know how useful I'll be to this > project or if I'll be able to contribute a significant amount, but if you > guys will have me then I'm more than willing to give my all to get up to > speed. totally cool. so what do you want to do? i mean, what do you want to learn about? l. From programmerjake at gmail.com Sun Mar 14 22:01:39 2021 From: programmerjake at gmail.com (Jacob Lifshay) Date: Sun, 14 Mar 2021 15:01:39 -0700 Subject: [Libre-soc-dev] New to the dev scene In-Reply-To: References: Message-ID: On Sun, Mar 14, 2021, 14:49 Chris DeGuzman wrote: > Hi, > My name is Chris DeGuzman and I'd like to contribute to this project. Welcome! Glad to have more people helping out! I'm > currently a computer engineering student at the University of Hawaii and > I'm very new to the dev scene. Jacob suggested that I join the team to get > some experience under my belt. I don't know how useful I'll be to this > project or if I'll be able to contribute a significant amount, but if you > guys will have me then I'm more than willing to give my all to get up to > speed. I may have a rough time starting out since I am still a student, and > it'll take some time to find a good balance between this project and > school. I look forward to hearing back from you guys. Luke (lkcl) will probably be the best one to find some good tasks for you to work on. Also, read through the charter and let us know if you agree: https://libre-soc.org/charter/ Jacob From programmerjake at gmail.com Sun Mar 14 22:57:51 2021 From: programmerjake at gmail.com (Jacob Lifshay) Date: Sun, 14 Mar 2021 15:57:51 -0700 Subject: [Libre-soc-dev] Fwd: New to the dev scene In-Reply-To: References: Message-ID: forgot to reply all instead of reply... ---------- Forwarded message --------- From: Chris DeGuzman Date: Sun, Mar 14, 2021, 15:47 Subject: Re: [Libre-soc-dev] New to the dev scene To: Jacob Lifshay Hi, I took the time to read the charter and I agree with it. It sounds like a very welcoming environment. Thanks, Chris On Sun, Mar 14, 2021 at 12:01 PM Jacob Lifshay wrote: > On Sun, Mar 14, 2021, 14:49 Chris DeGuzman > wrote: > >> Hi, >> My name is Chris DeGuzman and I'd like to contribute to this project. > > > Welcome! Glad to have more people helping out! > > I'm >> currently a computer engineering student at the University of Hawaii and >> I'm very new to the dev scene. Jacob suggested that I join the team to get >> some experience under my belt. I don't know how useful I'll be to this >> project or if I'll be able to contribute a significant amount, but if you >> guys will have me then I'm more than willing to give my all to get up to >> speed. I may have a rough time starting out since I am still a student, >> and >> it'll take some time to find a good balance between this project and >> school. I look forward to hearing back from you guys. > > > Luke (lkcl) will probably be the best one to find some good tasks for you > to work on. > > Also, read through the charter and let us know if you agree: > https://libre-soc.org/charter/ > > Jacob > From jules at penuchot.com Mon Mar 15 13:33:24 2021 From: jules at penuchot.com (Jules Penuchot) Date: Mon, 15 Mar 2021 14:33:24 +0100 Subject: [Libre-soc-dev] Introduction In-Reply-To: References: <027aa569-9baa-eefc-cb41-470a8a2d2f7c@penuchot.com> Message-ID: Hi Vivek, On 3/14/21 1:49 PM, vivek pandya wrote: > Hi Jules, > > Nice to meet you! Nice to meet you too :) > I have been working on this experimental driver for sometime now. > What I have been trying to do is inspired from > https://github.com/baldurk/visor , as > I only work on this on weekends and I am not an expert in mesa codebase > or SwiftShader I am referring to simple implementations like visor. > As this is a software rasterizer it has a GPUStatus struct to hold > indexBuffer and vertexBuffer , image is also stored as a pointer to > bytes.  Basically no hw abstraction in linux driver space to use actual > memory on a device , everything is on CPU memory. I'll look into it, thanks! > The driver is able to execute a simple DrawTriangle function which > executes vertex shader and fragment shader  through LLVM's ORCJit but it > does not generate meaningful results. Because codegeneration is not yet > aware about the GPUStatus struct, that is the next thing I have to do to > get the first triangle. Current code generation is all code copied from > AMD's radv driver implementation which is not a software rasterizer. > The resterization is a bit slower but it can be improved by threads but > not a priority for now. > > However since the driver is able to receive the Draw command that means > lots of vkCreate... functions are implemented to do basic stuff that is > required to get up to this point. > Also I am able to run > https://software.intel.com/content/www/us/en/develop/articles/api-without-secrets-introduction-to-vulkan-part-2.html > > that means driver is able to use image from a CPU memory and present it > on display with mesa's WSI layers. And hopefully that means I am on the > right path. Once I update codegen to use GPUStruct and get a triangle on > screen it should be sufficient to prove that this is the correct way. Sounds pretty nice already! > The codebase is in C so it's a bit painful to work with. Also I have to > use LLVM's C bindings to create IR an and that is very painful compared > to LLVM's C++ API. Could some parts of that codebase be turned into C++? I should be able to help with that if you want. > The code has lots of unused code as I started copying things from other > implementations, I will clean up things but not a priority. > > An experienced mesa/vulkan driver engineer may not have taken this path > but once I get a triangle on screen I will be more confident about my > approach. > > Hope this helps and if you dig into the codebase please feel free to > send email to my email address (CC list) . I will be happy to explain. I'll dig into it this week! I might not be as active as you during the weekends however. I consider this work to be a good fit for my thesis so I'll spend time on it during weekdays. Awesome work so far. Regards, Jules From vivekvpandya at gmail.com Mon Mar 15 14:36:49 2021 From: vivekvpandya at gmail.com (vivek pandya) Date: Mon, 15 Mar 2021 20:06:49 +0530 Subject: [Libre-soc-dev] Introduction In-Reply-To: References: <027aa569-9baa-eefc-cb41-470a8a2d2f7c@penuchot.com> Message-ID: On Mon, Mar 15, 2021 at 7:03 PM Jules Penuchot wrote: > Hi Vivek, > > On 3/14/21 1:49 PM, vivek pandya wrote: > > Hi Jules, > > > > Nice to meet you! > > Nice to meet you too :) > > > I have been working on this experimental driver for sometime now. > > What I have been trying to do is inspired from > > https://github.com/baldurk/visor , > as > > I only work on this on weekends and I am not an expert in mesa codebase > > or SwiftShader I am referring to simple implementations like visor. > > As this is a software rasterizer it has a GPUStatus struct to hold > > indexBuffer and vertexBuffer , image is also stored as a pointer to > > bytes. Basically no hw abstraction in linux driver space to use actual > > memory on a device , everything is on CPU memory. > > I'll look into it, thanks! > > > The driver is able to execute a simple DrawTriangle function which > > executes vertex shader and fragment shader through LLVM's ORCJit but it > > does not generate meaningful results. Because codegeneration is not yet > > aware about the GPUStatus struct, that is the next thing I have to do to > > get the first triangle. Current code generation is all code copied from > > AMD's radv driver implementation which is not a software rasterizer. > > The resterization is a bit slower but it can be improved by threads but > > not a priority for now. > > > > However since the driver is able to receive the Draw command that means > > lots of vkCreate... functions are implemented to do basic stuff that is > > required to get up to this point. > > Also I am able to run > > > https://software.intel.com/content/www/us/en/develop/articles/api-without-secrets-introduction-to-vulkan-part-2.html > > < > https://software.intel.com/content/www/us/en/develop/articles/api-without-secrets-introduction-to-vulkan-part-2.html> > > > that means driver is able to use image from a CPU memory and present it > > on display with mesa's WSI layers. And hopefully that means I am on the > > right path. Once I update codegen to use GPUStruct and get a triangle on > > screen it should be sufficient to prove that this is the correct way. > > Sounds pretty nice already! > > > The codebase is in C so it's a bit painful to work with. Also I have to > > use LLVM's C bindings to create IR an and that is very painful compared > > to LLVM's C++ API. > > Could some parts of that codebase be turned into C++? I should be able > to help with that if you want. > That is nice to have but could take decent time because you need to rewrite things. So better we do that once we can run a triangle. One thing might interest you is write GetVertexAttributeData() from spirv_compiler.cpp from visor and load that compiled code from the driver library and make it available for ORCJit. Basically JIT is not aware about the layout of the whole GPUState struct instead whenever it adds a function call like GetVertexAttributeData() and gets required things. So that will be a very low level but interesting opportunity to load code from a driver shared library and for now just print LLVM IR and see things as per expectations. If we try to implement GetVertexAttributeData() like function in LLVM IR itself it will be tedious and error prone so above seems the correct approach to tackle this problem. > > The code has lots of unused code as I started copying things from other > > implementations, I will clean up things but not a priority. > > > > An experienced mesa/vulkan driver engineer may not have taken this path > > but once I get a triangle on screen I will be more confident about my > > approach. > > > > Hope this helps and if you dig into the codebase please feel free to > > send email to my email address (CC list) . I will be happy to explain. > > I'll dig into it this week! I might not be as active as you during the > weekends however. I consider this work to be a good fit for my thesis so > I'll spend time on it during weekdays. > > Awesome work so far. > > Regards, > Jules > Thanks, Vivek From vivekvpandya at gmail.com Mon Mar 15 14:38:49 2021 From: vivekvpandya at gmail.com (vivek pandya) Date: Mon, 15 Mar 2021 20:08:49 +0530 Subject: [Libre-soc-dev] Introduction In-Reply-To: References: <027aa569-9baa-eefc-cb41-470a8a2d2f7c@penuchot.com> Message-ID: * correction > Basically JIT is not aware about the layout of the whole GPUState struct instead whenever it adds a function call like GetVertexAttributeData() and gets required things. Basically JIT is not aware about the layout of the whole GPUState struct. Instead, whenever it is required to access GPUState it adds a function call like GetVertexAttributeData() and gets required things. On Mon, Mar 15, 2021 at 8:06 PM vivek pandya wrote: > > > On Mon, Mar 15, 2021 at 7:03 PM Jules Penuchot wrote: > >> Hi Vivek, >> >> On 3/14/21 1:49 PM, vivek pandya wrote: >> > Hi Jules, >> > >> > Nice to meet you! >> >> Nice to meet you too :) >> >> > I have been working on this experimental driver for sometime now. >> > What I have been trying to do is inspired from >> > https://github.com/baldurk/visor , >> as >> > I only work on this on weekends and I am not an expert in mesa codebase >> > or SwiftShader I am referring to simple implementations like visor. >> > As this is a software rasterizer it has a GPUStatus struct to hold >> > indexBuffer and vertexBuffer , image is also stored as a pointer to >> > bytes. Basically no hw abstraction in linux driver space to use actual >> > memory on a device , everything is on CPU memory. >> >> I'll look into it, thanks! >> >> > The driver is able to execute a simple DrawTriangle function which >> > executes vertex shader and fragment shader through LLVM's ORCJit but >> it >> > does not generate meaningful results. Because codegeneration is not yet >> > aware about the GPUStatus struct, that is the next thing I have to do >> to >> > get the first triangle. Current code generation is all code copied from >> > AMD's radv driver implementation which is not a software rasterizer. >> > The resterization is a bit slower but it can be improved by threads but >> > not a priority for now. >> > >> > However since the driver is able to receive the Draw command that means >> > lots of vkCreate... functions are implemented to do basic stuff that is >> > required to get up to this point. >> > Also I am able to run >> > >> https://software.intel.com/content/www/us/en/develop/articles/api-without-secrets-introduction-to-vulkan-part-2.html >> > < >> https://software.intel.com/content/www/us/en/develop/articles/api-without-secrets-introduction-to-vulkan-part-2.html> >> >> > that means driver is able to use image from a CPU memory and present it >> > on display with mesa's WSI layers. And hopefully that means I am on the >> > right path. Once I update codegen to use GPUStruct and get a triangle >> on >> > screen it should be sufficient to prove that this is the correct way. >> >> Sounds pretty nice already! >> >> > The codebase is in C so it's a bit painful to work with. Also I have to >> > use LLVM's C bindings to create IR an and that is very painful compared >> > to LLVM's C++ API. >> >> Could some parts of that codebase be turned into C++? I should be able >> to help with that if you want. >> > That is nice to have but could take decent time because you need to > rewrite things. So better we do that once we can run a triangle. > One thing might interest you is write GetVertexAttributeData() from > spirv_compiler.cpp from visor and load that compiled code from the driver > library and make it available for ORCJit. > Basically JIT is not aware about the layout of the whole GPUState struct > instead whenever it adds a function call like GetVertexAttributeData() and > gets required things. > So that will be a very low level but interesting opportunity to load code > from a driver shared library and for now just print LLVM IR and see things > as per expectations. > > If we try to implement GetVertexAttributeData() like function in LLVM IR > itself it will be tedious and error prone so above seems the correct > approach to tackle this problem. > > >> > The code has lots of unused code as I started copying things from other >> > implementations, I will clean up things but not a priority. >> > >> > An experienced mesa/vulkan driver engineer may not have taken this path >> > but once I get a triangle on screen I will be more confident about my >> > approach. >> > >> > Hope this helps and if you dig into the codebase please feel free to >> > send email to my email address (CC list) . I will be happy to explain. >> >> I'll dig into it this week! I might not be as active as you during the >> weekends however. I consider this work to be a good fit for my thesis so >> I'll spend time on it during weekdays. >> >> Awesome work so far. >> >> Regards, >> Jules >> > > Thanks, > Vivek > From libre-soc at platen-software.de Mon Mar 15 17:31:17 2021 From: libre-soc at platen-software.de (Tobias Platen) Date: Mon, 15 Mar 2021 18:31:17 +0100 Subject: [Libre-soc-dev] daily kan-ban update 15mar2021 Message-ID: [Libre-soc-dev] daily kan-ban update 15mar2021 today: more work on radixmmu.py, likely implementing _next_level() On the weekend I was busy with Chemnitz Linux Days, next weekend will be LibrePlanet. From libre-soc at platen-software.de Tue Mar 16 20:01:15 2021 From: libre-soc at platen-software.de (Tobias Platen) Date: Tue, 16 Mar 2021 21:01:15 +0100 Subject: [Libre-soc-dev] daily kan-ban update 16mar2021 Message-ID: <20210316210115.8d56715144cfa2483403d05f@platen-software.de> today: more work on radix mmu -- Tobias Platen From lkcl at lkcl.net Tue Mar 16 20:38:20 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 16 Mar 2021 20:38:20 +0000 Subject: [Libre-soc-dev] daily kan-ban update 16mar2021 In-Reply-To: <20210316210115.8d56715144cfa2483403d05f@platen-software.de> References: <20210316210115.8d56715144cfa2483403d05f@platen-software.de> Message-ID: On Tuesday, March 16, 2021, Tobias Platen wrote: > today: more work on radix mmu excellent. saw the notes about those leaf and etc functions. yes, SelectableInt is entirely BE. l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From libre-soc at platen-software.de Wed Mar 17 18:14:21 2021 From: libre-soc at platen-software.de (Tobias Platen) Date: Wed, 17 Mar 2021 19:14:21 +0100 Subject: [Libre-soc-dev] daily kan-ban update 17mar2021 Message-ID: <20210317191421.f009d6bd2bcfcbccbcbc3028@platen-software.de> today: first looking into todays changes, then continue working on radixmmu From programmerjake at gmail.com Wed Mar 17 18:21:56 2021 From: programmerjake at gmail.com (Jacob Lifshay) Date: Wed, 17 Mar 2021 11:21:56 -0700 Subject: [Libre-soc-dev] add asm field to all isatables csv files Message-ID: what do you think of me adding an asm field for the actual assembler instruction name? the idea is that field is a single instruction name that can be used as a unique key as well as in generated assembly code. Jacob From lkcl at lkcl.net Wed Mar 17 19:09:56 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 17 Mar 2021 19:09:56 +0000 Subject: [Libre-soc-dev] add asm field to all isatables csv files In-Reply-To: References: Message-ID: On Wednesday, March 17, 2021, Jacob Lifshay wrote: > what do you think of me adding an asm field for the actual assembler > instruction name? mm we kinda get away with it at the moment by stripping the comment field of extraneous crud > the idea is that field is a single instruction name that > can be used as a unique key doesn't work. look at isel. l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From lkcl at lkcl.net Wed Mar 17 19:12:07 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 17 Mar 2021 19:12:07 +0000 Subject: [Libre-soc-dev] daily kan-ban update 17mar2021 In-Reply-To: <20210317191421.f009d6bd2bcfcbccbcbc3028@platen-software.de> References: <20210317191421.f009d6bd2bcfcbccbcbc3028@platen-software.de> Message-ID: On Wednesday, March 17, 2021, Tobias Platen wrote: > today: first looking into todays changes, then continue working on radixmmu you can see, i am breaking out snippets from microwatt behind functions, very deliberately, so that the name of the function gives meaning to what is being done. l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From programmerjake at gmail.com Wed Mar 17 19:15:31 2021 From: programmerjake at gmail.com (Jacob Lifshay) Date: Wed, 17 Mar 2021 12:15:31 -0700 Subject: [Libre-soc-dev] add asm field to all isatables csv files In-Reply-To: References: Message-ID: On Wed, Mar 17, 2021 at 12:10 PM Luke Kenneth Casson Leighton wrote: > > On Wednesday, March 17, 2021, Jacob Lifshay > wrote: > > > what do you think of me adding an asm field for the actual assembler > > instruction name? > > > mm we kinda get away with it at the moment by stripping the comment field > of extraneous crud yeah, well that's not a very sustainable solution. > > > > the idea is that field is a single instruction name that > > can be used as a unique key > > > doesn't work. look at isel. all those lines can be replaced with the single line: 0b-----01111,CR,OP_ISEL,RA_OR_ZERO,RB,NONE,RT,BC,NONE,0,0,ZERO,0,NONE,0,0,0,0,0,0,NONE,0,1,isel,A so, afaict that should work. Jacob From libre-soc at platen-software.de Wed Mar 17 19:31:45 2021 From: libre-soc at platen-software.de (Tobias Platen) Date: Wed, 17 Mar 2021 20:31:45 +0100 Subject: [Libre-soc-dev] daily kan-ban update 17mar2021 In-Reply-To: References: <20210317191421.f009d6bd2bcfcbccbcbc3028@platen-software.de> Message-ID: <20210317203145.c93291e5c8c4eb31cd039593@platen-software.de> On Wed, 17 Mar 2021 19:12:07 +0000 Luke Kenneth Casson Leighton wrote: > On Wednesday, March 17, 2021, Tobias Platen > wrote: > > > today: first looking into todays changes, then continue working on radixmmu > > > you can see, i am breaking out snippets from microwatt behind functions, > very deliberately, so that the name of the function gives meaning to what > is being done. > > l. > This really looks good. I now changed one of the functions that it reads the pagetables, I'm now verifying what I've written. > > -- > --- > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 > _______________________________________________ > Libre-soc-dev mailing list > Libre-soc-dev at lists.libre-soc.org > http://lists.libre-soc.org/mailman/listinfo/libre-soc-dev -- Tobias Platen From lkcl at lkcl.net Wed Mar 17 19:48:25 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 17 Mar 2021 19:48:25 +0000 Subject: [Libre-soc-dev] add asm field to all isatables csv files In-Reply-To: References: Message-ID: On Wednesday, March 17, 2021, Jacob Lifshay wrote: > On Wed, Mar 17, 2021 at 12:10 PM Luke Kenneth Casson Leighton > wrote: > > > > On Wednesday, March 17, 2021, Jacob Lifshay > > wrote: > > > > > what do you think of me adding an asm field for the actual assembler > > > instruction name? > > > > > > mm we kinda get away with it at the moment by stripping the comment field > > of extraneous crud > > yeah, well that's not a very sustainable solution. the other ones i stripped the crud, i left the 9/blah in for now because we are not doing FP yet. > > > > > > > the idea is that field is a single instruction name that > > > can be used as a unique key > > > > > > doesn't work. look at isel. > > all those lines can be replaced with the single line: > 0b-----01111,CR,OP_ISEL,RA_OR_ZERO,RB,NONE,RT,BC,NONE,0,0, > ZERO,0,NONE,0,0,0,0,0,0,NONE,0,1,isel,A > > so, afaict that should work. give it a shot. see if the same trick works for rotate (minor 30) as well. apologies i usually comment out lines in test_issuer.py to reduce completion time. l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From programmerjake at gmail.com Wed Mar 17 20:56:01 2021 From: programmerjake at gmail.com (Jacob Lifshay) Date: Wed, 17 Mar 2021 13:56:01 -0700 Subject: [Libre-soc-dev] add asm field to all isatables csv files In-Reply-To: References: Message-ID: On Wed, Mar 17, 2021 at 12:49 PM Luke Kenneth Casson Leighton wrote: > > On Wednesday, March 17, 2021, Jacob Lifshay > wrote: > > yeah, well that's not a very sustainable solution. > > > the other ones i stripped the crud, i left the 9/blah in for now because we > are not doing FP yet. Ok, though I'd appreciate adding an option to the decoder to load the FP opcodes too, that way I can add them to the generated C++ header. > > > doesn't work. look at isel. > > > > all those lines can be replaced with the single line: > > 0b-----01111,CR,OP_ISEL,RA_OR_ZERO,RB,NONE,RT,BC,NONE,0,0, > > ZERO,0,NONE,0,0,0,0,0,0,NONE,0,1,isel,A > > > > so, afaict that should work. > > > give it a shot. see if the same trick works for rotate (minor 30) as well. Ok. I'm assuming just generating the IL for the decoder should be enough for testing (assuming I don't accidentally use the wrong opcode). I modified the generate_headers.py file from simplev-cpp to list duplicate comment fields: duplicate comment field: 'rldic' subdecoder.pattern=30 duplicate comment field: 'rldicl' subdecoder.pattern=30 duplicate comment field: 'rldicr' subdecoder.pattern=30 duplicate comment field: 'rldimi' subdecoder.pattern=30 duplicate comment field: 'extswsli' subdecoder.pattern=31 duplicate comment field: 'isel' subdecoder.pattern=31 duplicate comment field: 'isel' subdecoder.pattern=31 duplicate comment field: 'isel' subdecoder.pattern=31 duplicate comment field: 'isel' subdecoder.pattern=31 duplicate comment field: 'mulhd' subdecoder.pattern=31 duplicate comment field: 'mulhdu' subdecoder.pattern=31 duplicate comment field: 'mulhw' subdecoder.pattern=31 duplicate comment field: 'mulhwu' subdecoder.pattern=31 duplicate comment field: 'sradi' subdecoder.pattern=31 Jacob From lkcl at lkcl.net Wed Mar 17 21:15:50 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 17 Mar 2021 21:15:50 +0000 Subject: [Libre-soc-dev] add asm field to all isatables csv files In-Reply-To: References: Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Wed, Mar 17, 2021 at 8:56 PM Jacob Lifshay wrote: > > On Wed, Mar 17, 2021 at 12:49 PM Luke Kenneth Casson Leighton > wrote: > > > > On Wednesday, March 17, 2021, Jacob Lifshay > > wrote: > > > yeah, well that's not a very sustainable solution. > > > > > > the other ones i stripped the crud, i left the 9/blah in for now because we > > are not doing FP yet. > > Ok, though I'd appreciate adding an option to the decoder to load the > FP opcodes too, that way I can add them to the generated C++ header. sure, go for it. > > > > doesn't work. look at isel. > > > > > > all those lines can be replaced with the single line: > > > 0b-----01111,CR,OP_ISEL,RA_OR_ZERO,RB,NONE,RT,BC,NONE,0,0, > > > ZERO,0,NONE,0,0,0,0,0,0,NONE,0,1,isel,A > > > > > > so, afaict that should work. > > > > > > give it a shot. see if the same trick works for rotate (minor 30) as well. > > Ok. I'm assuming just generating the IL for the decoder should be > enough for testing not a cat in hell's chance that's enough :) you'll need to run test_issuer.py at the very minimum, saving time by commenting out the unit tests that don't need to be run. > I modified the generate_headers.py file from simplev-cpp to list > duplicate comment fields: excellent > duplicate comment field: 'mulhd' subdecoder.pattern=31 > duplicate comment field: 'mulhdu' subdecoder.pattern=31 > duplicate comment field: 'mulhw' subdecoder.pattern=31 > duplicate comment field: 'mulhwu' subdecoder.pattern=31 those i wasn't expecting. ah right. yes, they have patterns 0b0001001011,MUL, 0b1001001011,MUL, which are ok. the rest need careful checking as well. what we can't have is a pattern that is more than a single bit change, unless it can be demonstrated that all patterns are covered, such as isel which has 32 patterns in the same 5 bits, all of which can be covered by 5 "-"s l. From lkcl at lkcl.net Wed Mar 17 22:36:06 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 17 Mar 2021 22:36:06 +0000 Subject: [Libre-soc-dev] single and twin-predication added to python-based LibreSOC simulator Message-ID: https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/decoder/isa/test_caller_svp64_predication.py;h=cd4df1e929d4c6250139e61840339ed19e2e7b02;hb=HEAD#l45 to be followed up in HDL over the next couple of weeks, the above successful unit test illustrates how twin-predication works. single-predication is just below, and includes both an INT (GPR) mask as well as a CR-Field mask unit test. "normal" Vector ISAs only have single-predication. every element in source and dest of the vector matches up: for i in range(VL): if mask & (1< References: <20210317191421.f009d6bd2bcfcbccbcbc3028@platen-software.de> Message-ID: Today: working on simplev-cpp cleaned up csv files so all files have their opcode fields in binary with a 0b... prefix -- all CSV files are now parsed in opint=True mode, which is now required. This will allow easier removal of the Subdecoder.opint field since it now doesn't do anything useful. Jacob From lkcl at lkcl.net Thu Mar 18 06:20:59 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 18 Mar 2021 06:20:59 +0000 Subject: [Libre-soc-dev] daily kan-ban update 17mar2021 In-Reply-To: References: <20210317191421.f009d6bd2bcfcbccbcbc3028@platen-software.de> Message-ID: On Thursday, March 18, 2021, Jacob Lifshay wrote: > Today: > working on simplev-cpp > cleaned up csv files so all files have their opcode fields in binary > with a 0b... prefix -- all CSV files are now parsed in opint=True > mode, which is now required. This will allow easier removal of the > Subdecoder.opint field since it now doesn't do anything useful. it keeps the files in line with microwatt so that the output from sv_analysis.py when generating a VHDL file is identical in format. also that prevents major opcodes from being readable. i did say that there are multiple purposes to the CSV files and this change will now unfortunately need to be reverted. unfortunately we cannot do things because they make "things cleaner" or "look better", there are a half dozen different uses for these files and that is set to increase. l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From lkcl at lkcl.net Thu Mar 18 06:48:05 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 18 Mar 2021 06:48:05 +0000 Subject: [Libre-soc-dev] daily kan-ban update 17mar2021 In-Reply-To: References: <20210317191421.f009d6bd2bcfcbccbcbc3028@platen-software.de> Message-ID: ok so i have things to do this morning which are prevented by the change to 0bNNN format, so where normally it would be you who would have to sort out the reversion, jacob, i have to do it. it'll be a force master push so you'll need to resolve that locally, and let's hope that nobody else in the team has done a "git pull" in the meantime. if they have, i leave it to you to give them the advice and instructions to restore their repos. one additional clear and simple reason why the files were not originally created "0bNNN": nobody in the OpenPOWER community discusses "major opcode 0bNNNN", they all say "major opcode 19". these files are documentation as much as anything else. l. From programmerjake at gmail.com Thu Mar 18 06:56:27 2021 From: programmerjake at gmail.com (Jacob Lifshay) Date: Wed, 17 Mar 2021 23:56:27 -0700 Subject: [Libre-soc-dev] daily kan-ban update 17mar2021 In-Reply-To: References: <20210317191421.f009d6bd2bcfcbccbcbc3028@platen-software.de> Message-ID: On Wed, Mar 17, 2021, 23:48 Luke Kenneth Casson Leighton wrote: > ok so i have things to do this morning which are prevented by the > change to 0bNNN format, so where normally it would be you who would > have to sort out the reversion, jacob, i have to do it. > I'll change those back to decimal now, but I think we should still have 0b on all binary opcodes. no force pushing From programmerjake at gmail.com Thu Mar 18 07:20:52 2021 From: programmerjake at gmail.com (Jacob Lifshay) Date: Thu, 18 Mar 2021 00:20:52 -0700 Subject: [Libre-soc-dev] daily kan-ban update 17mar2021 In-Reply-To: References: <20210317191421.f009d6bd2bcfcbccbcbc3028@platen-software.de> Message-ID: On Wed, Mar 17, 2021, 23:56 Jacob Lifshay wrote: > On Wed, Mar 17, 2021, 23:48 Luke Kenneth Casson Leighton > wrote: > >> ok so i have things to do this morning which are prevented by the >> change to 0bNNN format, so where normally it would be you who would >> have to sort out the reversion, jacob, i have to do it. >> > > I'll change those back to decimal now, but I think we should still have 0b > on all binary opcodes. > I changed just the PO field back to decimal, the rest only went up to 2 so binary's plenty readable imho. pushed: https://git.libre-soc.org/?p=libreriscv.git;a=commit;h=cee0f91050c0843ac297951edb34b1006846abf3 https://git.libre-soc.org/?p=soc.git;a=blobdiff;f=src/soc/decoder/power_decoder.py;h=ace1ae280c6334bc9ca30b17c3da0379ef949d06;hp=2b52cf5fbc19f156a3020576e0fee59aabee27d5;hb=3600675075bae0f9b2895f78efdfd7b2cb046597;hpb=4fcd97f399ae9cb4bc651b1ddccff3598cd83fd9 Jacob > From lkcl at lkcl.net Thu Mar 18 07:54:54 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 18 Mar 2021 07:54:54 +0000 Subject: [Libre-soc-dev] daily kan-ban update 17mar2021 In-Reply-To: References: <20210317191421.f009d6bd2bcfcbccbcbc3028@platen-software.de> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Thu, Mar 18, 2021 at 7:21 AM Jacob Lifshay wrote: > I changed just the PO field back to decimal, the rest only went up to 2 so > binary's plenty readable imho. > > pushed: > https://git.libre-soc.org/?p=libreriscv.git;a=commit;h=cee0f91050c0843ac297951edb34b1006846abf3 again: i am reerting this with a forced push master. this is now in progress and looks like it's going to take 15 minutes to complete. please listen: the changes that you are making are too low-level and have far too many implications and ramifications. i already told you on the irc channel yesterday: these are used for microwatt auto-generation and have to be as close to decode1.vhdl as possible, they're for documentation, critical to SV and many more purposes. if you wish to make low-level critical changes that impact microwatt, making their life difficult to consider adding SV to it then you will need to learn VHDL, submit corresponding patches to microwatt upstream, and *then* update the CSV files. we are also under intense pressure to get things done and you are creating extra work which we do not need right now. l. From lkcl at lkcl.net Thu Mar 18 07:57:14 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 18 Mar 2021 07:57:14 +0000 Subject: [Libre-soc-dev] daily kan-ban update 17mar2021 In-Reply-To: References: <20210317191421.f009d6bd2bcfcbccbcbc3028@platen-software.de> Message-ID: diff --git a/openpower/isatables/extra.csv b/openpower/isatables/extra.csv index bf08093..7625aff 100644 (file) --- a/openpower/isatables/extra.csv +++ b/openpower/isatables/extra.csv @@ -1,4 +1,4 @@ opcode,unit,internal op,in1,in2,in3,out,CR in,CR out,inv A,inv out,cry in,cry out,ldst len,BR,sgn ext,upd,rsrv,32b,sgn,rc,lk,sgl pipe,comment,form -000000---------------0100000000-,NONE,OP_ATTN,NONE,NONE,NONE,NONE,NONE,NONE,0,0,ZERO,0,NONE,0,0,0,0,0,0,RC,0,1,attn,NONE -01100000000000000000000000000000,NONE,OP_NOP,NONE,NONE,NONE,NONE,NONE,NONE,0,0,ZERO,0,NONE,0,0,0,0,0,0,NONE,0,0,nop,D -000001---------------0000000011-,NONE,OP_SIM_CONFIG,NONE,NONE,NONE,RT,NONE,NONE,0,0,ZERO,0,NONE,0,0,0,0,0,0,NONE,0,1,sim_cfg,NONE +0b000000---------------0100000000-,NONE,OP_ATTN,NONE,NONE,NONE,NONE,NONE,NONE,0,0,ZERO,0,NONE,0,0,0,0,0,0,RC,0,1,attn,NONE +0b01100000000000000000000000000000,NONE,OP_NOP,NONE,NONE,NONE,NONE,NONE,NONE,0,0,ZERO,0,NONE,0,0,0,0,0,0,NONE,0,0,nop,D +0b000001---------------0000000011-,NONE,OP_SIM_CONFIG,NONE,NONE,NONE,RT,NONE,NONE,0,0,ZERO,0,NONE,0,0,0,0,0,0,NONE,0,1,sim_cfg,NONE this will cause the pattern matching in power_decode.py to fail. From lkcl at lkcl.net Thu Mar 18 07:58:38 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 18 Mar 2021 07:58:38 +0000 Subject: [Libre-soc-dev] daily kan-ban update 17mar2021 In-Reply-To: References: <20210317191421.f009d6bd2bcfcbccbcbc3028@platen-software.de> Message-ID: ------00010,1,addpcis: 5 upper bits are part of constant +0b-----00010,1,addpcis: 5 upper bits are part of constant this will cause the pattern matching in power_decode.py to fail. From lkcl at lkcl.net Thu Mar 18 07:59:22 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 18 Mar 2021 07:59:22 +0000 Subject: [Libre-soc-dev] daily kan-ban update 17mar2021 In-Reply-To: References: <20210317191421.f009d6bd2bcfcbccbcbc3028@platen-software.de> Message-ID: these no longer match microwatt decode1.vhdl constant decode_op_58_array : minor_rom_array_2_t := ( -- unit fac internal in1 in2 in3 out CR CR inv inv cry cry ldst BR sgn upd rsrv 32b sgn rc lk sgl rpt -- op in out A out in out len ext pipe 0 => (LDST, NONE, OP_LOAD, RA_OR_ZERO, CONST_DS, NONE, RT, '0', '0', '0', '0', ZERO, '0', is8B, '0', '0', '0', '0', '0', '0', NONE, '0', '0', NONE), -- ld 1 => (LDST, NONE, OP_LOAD, RA_OR_ZERO, CONST_DS, NONE, RT, '0', '0', '0', '0', ZERO, '0', is8B, '0', '0', '1', '0', '0', '0', NONE, '0', '0', DUPD), -- ldu 2 => (LDST, NONE, OP_LOAD, RA_OR_ZERO, CONST_DS, NONE, RT, '0', '0', '0', '0', ZERO, '0', is4B, '0', '1', '0', '0', '0', '0', NONE, '0', '0', NONE), -- lwa others => decode_rom_init ); +++ b/openpower/isatables/minor_58.csv @@ -1,4 +1,4 @@ opcode,unit,internal op,in1,in2,in3,out,CR in,CR out,inv A,inv out,cry in,cry out,ldst len,BR,sgn ext,upd,rsrv,32b,sgn,rc,lk,sgl pipe,comment,form -0,LDST,OP_LOAD,RA_OR_ZERO,CONST_DS,NONE,RT,NONE,NONE,0,0,ZERO,0,is8B,0,0,0,0,0,0,NONE,0,1,ld,DS -1,LDST,OP_LOAD,RA_OR_ZERO,CONST_DS,NONE,RT,NONE,NONE,0,0,ZERO,0,is8B,0,0,1,0,0,0,NONE,0,1,ldu,DS -2,LDST,OP_LOAD,RA_OR_ZERO,CONST_DS,NONE,RT,NONE,NONE,0,0,ZERO,0,is4B,0,1,0,0,0,0,NONE,0,1,lwa,DS +0b00,LDST,OP_LOAD,RA_OR_ZERO,CONST_DS,NONE,RT,NONE,NONE,0,0,ZERO,0,is8B,0,0,0,0,0,0,NONE,0,1,ld,DS +0b01,LDST,OP_LOAD,RA_OR_ZERO,CONST_DS,NONE,RT,NONE,NONE,0,0,ZERO,0,is8B,0,0,1,0,0,0,NONE,0,1,ldu,DS +0b10,LDST,OP_LOAD,RA_OR_ZERO,CONST_DS,NONE,RT,NONE,NONE,0,0,ZERO,0,is4B,0,1,0,0,0,0,NONE,0,1,lwa,DS From programmerjake at gmail.com Thu Mar 18 08:10:41 2021 From: programmerjake at gmail.com (Jacob Lifshay) Date: Thu, 18 Mar 2021 01:10:41 -0700 Subject: [Libre-soc-dev] daily kan-ban update 17mar2021 In-Reply-To: References: <20210317191421.f009d6bd2bcfcbccbcbc3028@platen-software.de> Message-ID: On Thu, Mar 18, 2021, 00:58 Luke Kenneth Casson Leighton wrote: > diff --git a/openpower/isatables/extra.csv b/openpower/isatables/extra.csv > index bf08093..7625aff 100644 (file) > --- a/openpower/isatables/extra.csv > +++ b/openpower/isatables/extra.csv > @@ -1,4 +1,4 @@ > opcode,unit,internal op,in1,in2,in3,out,CR in,CR out,inv A,inv > out,cry in,cry out,ldst len,BR,sgn ext,upd,rsrv,32b,sgn,rc,lk,sgl > pipe,comment,form > > -000000---------------0100000000-,NONE,OP_ATTN,NONE,NONE,NONE,NONE,NONE,NONE,0,0,ZERO,0,NONE,0,0,0,0,0,0,RC,0,1,attn,NONE > > -01100000000000000000000000000000,NONE,OP_NOP,NONE,NONE,NONE,NONE,NONE,NONE,0,0,ZERO,0,NONE,0,0,0,0,0,0,NONE,0,0,nop,D > > -000001---------------0000000011-,NONE,OP_SIM_CONFIG,NONE,NONE,NONE,RT,NONE,NONE,0,0,ZERO,0,NONE,0,0,0,0,0,0,NONE,0,1,sim_cfg,NONE > > +0b000000---------------0100000000-,NONE,OP_ATTN,NONE,NONE,NONE,NONE,NONE,NONE,0,0,ZERO,0,NONE,0,0,0,0,0,0,RC,0,1,attn,NONE > > +0b01100000000000000000000000000000,NONE,OP_NOP,NONE,NONE,NONE,NONE,NONE,NONE,0,0,ZERO,0,NONE,0,0,0,0,0,0,NONE,0,0,nop,D > > +0b000001---------------0000000011-,NONE,OP_SIM_CONFIG,NONE,NONE,NONE,RT,NONE,NONE,0,0,ZERO,0,NONE,0,0,0,0,0,0,NONE,0,1,sim_cfg,NONE > > this will cause the pattern matching in power_decode.py to fail. > no...I made the matching changes in power_decode.py. all the tests you instructed me to run on irc pass, except for that 1 expected failure. Jacob From lkcl at lkcl.net Thu Mar 18 08:14:29 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 18 Mar 2021 08:14:29 +0000 Subject: [Libre-soc-dev] git forced master reversion on wiki and soc Message-ID: i've just had to do a forced master push onto the wiki and the soc repositories to revert changes that are simply too disruptive at this critical point when we are under such intense time pressure. anyone who has done a "git pull" in the past 10 hours will need to abandon their work and re-check-out those two repositories unless you know how to sort out locally deleting the master branch from your local checked out repo and how to re-add it at the correct (remote) branch point. changes at this low level jacob we *cannot* do without extreme care and consideration. i have not said anything very deliberately for some time, so that you would see what happens as a result: you've not been keeping up-to-date with software development and consequently, now that you've started contributing again, are unfamiliar with the background of over a year's work and so are not cognizant of the full implications of changes that you'd like to make. if you would like to make low-level changes they need to be planned *extremely* carefully. please be more careful in future. l. --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From lkcl at lkcl.net Thu Mar 18 08:20:36 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 18 Mar 2021 08:20:36 +0000 Subject: [Libre-soc-dev] daily kan-ban update 17mar2021 In-Reply-To: References: <20210317191421.f009d6bd2bcfcbccbcbc3028@platen-software.de> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Thu, Mar 18, 2021 at 8:10 AM Jacob Lifshay wrote: > no...I made the matching changes in power_decode.py. all the tests you > instructed me to run on irc pass, except for that 1 expected failure. i hadn't finished thinking through the full implications, and given that you'd said "i will leave things as they are and resolve it in the c++ code" i did not expect you to make extensive changes overnight. i also made it very clear that we have much higher priority tasks to do. i've therefore also reverted those changes because they're too extensive and disruptive right now, due to the implications for microwatt, plus i'm in the middle of other work that i would have to stop - dead - and think through. sorry: this is one area where we simply cannot make rapid changes without *extensive* review of all impacted projects. we have something like five or six separate projects relying on thesse files, that's going to go up to eight or nine. can you please therefore raise a bugreport about it so that some time in the future this can be evaluated when we are not under extreme time pressure. l. From lkcl at lkcl.net Thu Mar 18 08:29:17 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 18 Mar 2021 08:29:17 +0000 Subject: [Libre-soc-dev] git forced master reversion on wiki and soc In-Reply-To: References: Message-ID: i've made both soc and the wiki temporarily read-only until i hear from everybody that they've not done an overnight "git pull" and/or that they have restored master branch to the following (or later) soc b467827f51016fa5c8c96faa25b4e0790197a9f7 wiki 9784ecefb8a9b0e8e7aeae4c92fc1a622ac45325 the reason for making them read-only is to ensure that people do not push against the wrong master branch. jacob i will leave it with you to coordinate this with everybody and to explain it to them. once you have restored to the correct master branch point and have followed up with everyone to ensure that they have not done a pull overnight, please let me know and i will restore everybody's write access. l. From programmerjake at gmail.com Thu Mar 18 08:30:38 2021 From: programmerjake at gmail.com (Jacob Lifshay) Date: Thu, 18 Mar 2021 01:30:38 -0700 Subject: [Libre-soc-dev] daily kan-ban update 17mar2021 In-Reply-To: References: <20210317191421.f009d6bd2bcfcbccbcbc3028@platen-software.de> Message-ID: On Thu, Mar 18, 2021, 01:21 Luke Kenneth Casson Leighton wrote: > --- > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 > > On Thu, Mar 18, 2021 at 8:10 AM Jacob Lifshay > wrote: > > > no...I made the matching changes in power_decode.py. all the tests you > > instructed me to run on irc pass, except for that 1 expected failure. > > i hadn't finished thinking through the full implications, and given > that you'd said "i will leave things as they are and resolve it in the > c++ code" i did not expect you to make extensive changes overnight. > > i also made it very clear that we have much higher priority tasks to do. > > i've therefore also reverted those changes because they're too > extensive and disruptive right now, due to the implications for > microwatt, plus i'm in the middle of other work that i would have to > stop - dead - and think through. > k. please push the master pre-revert to some git tags so we don't lose it -- or I can create the tags if you like. > > sorry: this is one area where we simply cannot make rapid changes > without *extensive* review of all impacted projects. > > we have something like five or six separate projects relying on thesse > files, that's going to go up to eight or nine. > > can you please therefore raise a bugreport about it so that some time > in the future this can be evaluated when we are not under extreme time > pressure. > will do that in the morning. Jacob From colepoirier at gmail.com Thu Mar 18 08:39:57 2021 From: colepoirier at gmail.com (Cole Poirier) Date: Thu, 18 Mar 2021 01:39:57 -0700 Subject: [Libre-soc-dev] git forced master reversion on wiki and soc In-Reply-To: References: Message-ID: >> On Mar 18, 2021, at 1:29 AM, Luke Kenneth Casson Leighton wrote: > i've made both soc and the wiki temporarily read-only until i hear > from everybody that they've not done an overnight "git pull" and/or > that they have restored master branch to the following (or later) I have not done an overnight git pull. Cole From lkcl at lkcl.net Thu Mar 18 09:01:54 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 18 Mar 2021 09:01:54 +0000 Subject: [Libre-soc-dev] git forced master reversion on wiki and soc In-Reply-To: References: Message-ID: On Thu, Mar 18, 2021 at 8:40 AM Cole Poirier wrote: > > >> On Mar 18, 2021, at 1:29 AM, Luke Kenneth Casson Leighton wrote: > > i've made both soc and the wiki temporarily read-only until i hear > > from everybody that they've not done an overnight "git pull" and/or > > that they have restored master branch to the following (or later) > > I have not done an overnight git pull. ok good i've added you back with write-perms. From cestrauss at gmail.com Thu Mar 18 11:09:56 2021 From: cestrauss at gmail.com (Cesar Strauss) Date: Thu, 18 Mar 2021 08:09:56 -0300 Subject: [Libre-soc-dev] git forced master reversion on wiki and soc In-Reply-To: References: Message-ID: <6939884e-3bd2-db33-f649-0a75869c7d6c@gmail.com> On 03/18/2021 05:29, Luke Kenneth Casson Leighton wrote: > i've made both soc and the wiki temporarily read-only until i hear > from everybody that they've not done an overnight "git pull" and/or > that they have restored master branch to the following (or later) > > soc b467827f51016fa5c8c96faa25b4e0790197a9f7 > wiki 9784ecefb8a9b0e8e7aeae4c92fc1a622ac45325 I'm good. Cesar From lkcl at lkcl.net Thu Mar 18 11:11:02 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 18 Mar 2021 11:11:02 +0000 Subject: [Libre-soc-dev] git forced master reversion on wiki and soc In-Reply-To: <6939884e-3bd2-db33-f649-0a75869c7d6c@gmail.com> References: <6939884e-3bd2-db33-f649-0a75869c7d6c@gmail.com> Message-ID: On Thu, Mar 18, 2021 at 11:10 AM Cesar Strauss wrote: > > soc b467827f51016fa5c8c96faa25b4e0790197a9f7 > > wiki 9784ecefb8a9b0e8e7aeae4c92fc1a622ac45325 > > I'm good. ok great, re-added. From lkcl at lkcl.net Thu Mar 18 11:32:07 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 18 Mar 2021 11:32:07 +0000 Subject: [Libre-soc-dev] adding an extra field to sv_analysys.py output (out2) Message-ID: we've a situation where, from following microwatt decode1.vhdl format, there is no "out2" register column. some register information, rather than being in the VHDL files / CSV files, was still done by hand. we followed that... somewhat: https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/decoder/power_decoder2.py;h=3813295c5142786202bca8c2f220ecd0d246a179;hb=1ebec3c8d403a74a495d317d9c722aa4243bd279#l411 this is where, rather than there being a column that identifies the 2nd output, it's detected "is LDST update mode set", which to be honest is probably more gate-efficient but also a damn nuisance. https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/decoder/power_decoder2.py;h=3813295c5142786202bca8c2f220ecd0d246a179;hb=1ebec3c8d403a74a495d317d9c722aa4243bd279#l1185 here, we again follow what microwatt does, and really shouldn't. however the advantages of being closer to what microwatt does outweigh the disadvantages.... except when we're auto-generating code for adding SVP64 to microwatt. to that end what i'm going to do is add an extra column to the RM (SVP64) output CSV files, called "out2". i'm not going to alter the v3.0B CSV files themselves: one other idea is to change the get_csv function to *add* that column (based on "if upd == LDSTMode.update"). the reason is because this column is missing: https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/decoder/power_decoder2.py;h=3813295c5142786202bca8c2f220ecd0d246a179;hb=1ebec3c8d403a74a495d317d9c722aa4243bd279#l1089 consequently we can't properly decode SVP64 EXTRA2/3 for the 2nd output register. l. --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From lkcl at lkcl.net Thu Mar 18 11:49:41 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 18 Mar 2021 11:49:41 +0000 Subject: [Libre-soc-dev] salsa.debian.org is currently down Message-ID: i just encountered this: fatal: unable to access 'https://salsa.debian.org/Kazan-team/nmigen-type-annotations.git/': The requested URL returned error: 503 Unable to fetch in submodule path 'nmigen-type-annotations' the reason: https://salsa.debian.org/ Service Unavailable The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later. Additionally, a 503 Service Unavailable error was encountered while trying to use an ErrorDocument to handle the request. Apache Server at salsa.debian.org Port 443 an external dependency has crept in, which i wasn't aware of, which therefore hasn't been added here: https://git.libre-soc.org/ this emphasises why it is important that we not depend on external resources for development of the project. i'll remove it temporarily whilst it's down: now that i know the project exists i've added it to git.libre-soc.org, jacob can you re-add it after first doing a git push of nmigen-type-annotations to git.libre-soc.org? thx, l. From lkcl at lkcl.net Thu Mar 18 12:48:51 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 18 Mar 2021 12:48:51 +0000 Subject: [Libre-soc-dev] SVP64 auto-generated table for microwatt decoding In-Reply-To: References: Message-ID: i've updated the microwatt auto-generated sv_decode.vhdl file with two things: 1) the RS field is now back in "in3" (we moved it to "in1" in LibreSOC) 1) a new "out2" column and corresponding "sv_out2" column has been added the sv_out2 column is critically important, and the "out2" column was implicitly added by "is this a LD/ST-with-update" instruction, which is hard-coded in microwatt. with that missing, it wasn't possible to auto-generate the corresponding sv_out2 column. each of the columns sv_in* and sv_out* as well as the CR field versions all say: "for this openpower v3.0B instruction, if you want to know which bits of the SVP64 Re-Map to get the "EXTRA" information (whether the register is Vectorised), go to THIS part of the field". -- insn Ptype Etype in1 in2 in3 out out2 CR in CR out sv_in1 sv_in2 sv_in3 sv_out sv_out2 sv_cr_in sv_cr_out 0 => (P2, EXTRA3, RA_OR_ZERO, NONE, NONE, RT, NONE, NONE, NONE, Idx1, NONE, NONE, Idx0, NONE, NONE, NONE), -- ld 2 => (P2, EXTRA3, RA_OR_ZERO, NONE, NONE, RT, NONE, NONE, NONE, Idx1, NONE, NONE, Idx0, NONE, NONE, NONE), -- lwa 1 => (P2, EXTRA2, RA_OR_ZERO, NONE, NONE, RT, RA, NONE, NONE, Idx2, NONE, NONE, Idx0, Idx1, NONE, NONE), -- ldu here you can see for ldu: * out=RT * out2=RA (LD-with-update) and that: * sv_out=Idx0 and * sv_out2=Idx1 this means, "if you want to know if RA - as the 2nd output - has been Vectorised and altered to be *different* from RA-as-a-src, please look in EXTRA field Indexed 1" the "normal" v3.1 64-bit prefixing system actually has bits in it which tell you what to do. unfortunately, we have so little space that we can't do that, and consequently it's the decode1.vhdl which has to be extended on a per-operation basis. l. From hendrik at topoi.pooq.com Thu Mar 18 12:57:16 2021 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 18 Mar 2021 08:57:16 -0400 Subject: [Libre-soc-dev] git forced master reversion on wiki and soc In-Reply-To: References: Message-ID: <20210318125716.hgk5hcj7milm7wc5@topoi.pooq.com> On Thu, Mar 18, 2021 at 08:29:17AM +0000, Luke Kenneth Casson Leighton wrote: > > jacob i will leave it with you to coordinate this with everybody and > to explain it to them. once you have restored to the correct master > branch point and have followed up with everyone to ensure that they > have not done a pull overnight, please let me know and i will restore > everybody's write access. Just in ase it's not obvious, I have not done a git pull. -- hendrik From lkcl at lkcl.net Thu Mar 18 13:53:30 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 18 Mar 2021 13:53:30 +0000 Subject: [Libre-soc-dev] git forced master reversion on wiki and soc In-Reply-To: <20210318125716.hgk5hcj7milm7wc5@topoi.pooq.com> References: <20210318125716.hgk5hcj7milm7wc5@topoi.pooq.com> Message-ID: On Thu, Mar 18, 2021 at 12:57 PM Hendrik Boom wrote: > Just in case it's not obvious, I have not done a git pull. ok thx hendrik. i don't have an ssh public key for you. l. From vklr at vkten.in Thu Mar 18 15:23:38 2021 From: vklr at vkten.in (Veera) Date: Thu, 18 Mar 2021 20:53:38 +0530 Subject: [Libre-soc-dev] git forced master reversion on wiki and soc In-Reply-To: References: Message-ID: <20210318152336.GB6126@lily.local> On Thu, Mar 18, 2021 at 08:29:17AM +0000, Luke Kenneth Casson Leighton wrote: > i've made both soc and the wiki temporarily read-only until i hear > from everybody that they've not done an overnight "git pull" and/or > that they have restored master branch to the following (or later) > > soc b467827f51016fa5c8c96faa25b4e0790197a9f7 > wiki 9784ecefb8a9b0e8e7aeae4c92fc1a622ac45325 > > the reason for making them read-only is to ensure that people do not > push against the wrong master branch. > I have not pulled overnight. So I am safe. Regards, Veera From programmerjake at gmail.com Thu Mar 18 16:07:43 2021 From: programmerjake at gmail.com (Jacob Lifshay) Date: Thu, 18 Mar 2021 09:07:43 -0700 Subject: [Libre-soc-dev] git forced master reversion on wiki and soc In-Reply-To: References: Message-ID: On Thu, Mar 18, 2021, 01:29 Luke Kenneth Casson Leighton wrote: > i've made both soc and the wiki temporarily read-only until i hear > from everybody that they've not done an overnight "git pull" and/or > that they have restored master branch to the following (or later) > > soc b467827f51016fa5c8c96faa25b4e0790197a9f7 > wiki 9784ecefb8a9b0e8e7aeae4c92fc1a622ac45325 > > the reason for making them read-only is to ensure that people do not > push against the wrong master branch. > > jacob i will leave it with you to coordinate this with everybody and > to explain it to them. once you have restored to the correct master > branch point and have followed up with everyone to ensure that they > have not done a pull overnight, please let me know and i will restore > everybody's write access. > Ok. I recreated my master branches for soc.git and libreriscv.git after creating git tags. I checked who all has made any commits in the last week or so, I'm assuming that everyone else is not likely to have pulled last night. We still need to hear back from Alain, rwilbur, and Tobias (CCed). Jacob From programmerjake at gmail.com Thu Mar 18 16:22:28 2021 From: programmerjake at gmail.com (Jacob Lifshay) Date: Thu, 18 Mar 2021 09:22:28 -0700 Subject: [Libre-soc-dev] git forced master reversion on wiki and soc In-Reply-To: <20210318161514.GA16258@phcomp.co.uk> References: <20210318161514.GA16258@phcomp.co.uk> Message-ID: On Thu, Mar 18, 2021, 09:15 Alain Williams wrote: > On Thu, Mar 18, 2021 at 09:07:43AM -0700, Jacob Lifshay wrote: > > On Thu, Mar 18, 2021, 01:29 Luke Kenneth Casson Leighton > > wrote: > > > > > i've made both soc and the wiki temporarily read-only until i hear > > > from everybody that they've not done an overnight "git pull" and/or > > > that they have restored master branch to the following (or later) > > > > > > soc b467827f51016fa5c8c96faa25b4e0790197a9f7 > > > wiki 9784ecefb8a9b0e8e7aeae4c92fc1a622ac45325 > > > > > > the reason for making them read-only is to ensure that people do not > > > push against the wrong master branch. > > > > > > jacob i will leave it with you to coordinate this with everybody and > > > to explain it to them. once you have restored to the correct master > > > branch point and have followed up with everyone to ensure that they > > > have not done a pull overnight, please let me know and i will restore > > > everybody's write access. > > > > > > > Ok. I recreated my master branches for soc.git and libreriscv.git after > > creating git tags. > > > > I checked who all has made any commits in the last week or so, I'm > assuming > > that everyone else is not likely to have pulled last night. We still need > > to hear back from Alain, rwilbur, and Tobias (CCed). > > I pulled a couple of hours ago. I pushed something a couple of hours ago. > > I have several local changes - not pushed. > > What do I need to do to get synched with the right tree ? > Run git log in both soc and libreriscv (both the soc/libreriscv submodule and any other repos): if all repos don't have either of the following commits in their git history, then your good: libreriscv: aa92a1fa572dbe317bce3d6289c6f9128350fa2f Author: Jacob Lifshay Date: Wed Mar 17 19:17:30 2021 -0700 convert all opcodes to binary soc: commit 3f8a17ca49a1cc9636b85b41b84a0a88476cbdf8 Author: Jacob Lifshay Date: Wed Mar 17 19:32:07 2021 -0700 update submodule Jacob From richard.wilbur at gmail.com Thu Mar 18 16:32:34 2021 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Thu, 18 Mar 2021 10:32:34 -0600 Subject: [Libre-soc-dev] git forced master reversion on wiki and soc In-Reply-To: References: Message-ID: I have yet to pull anything. I was working on the wiki and stuff I got off FTP, PowerISA pdf documentation to distill VSX instructions specifications into machine-readable form (bug 602). From programmerjake at gmail.com Thu Mar 18 16:45:35 2021 From: programmerjake at gmail.com (Jacob Lifshay) Date: Thu, 18 Mar 2021 09:45:35 -0700 Subject: [Libre-soc-dev] salsa.debian.org is currently down In-Reply-To: References: Message-ID: On Thu, Mar 18, 2021, 04:50 Luke Kenneth Casson Leighton wrote: > i just encountered this: > > fatal: unable to access > 'https://salsa.debian.org/Kazan-team/nmigen-type-annotations.git/': > The requested URL returned error: 503 > Unable to fetch in submodule path 'nmigen-type-annotations' > > the reason: > > https://salsa.debian.org/ > > Service Unavailable > The server is temporarily unable to service your request due to > maintenance downtime or capacity problems. Please try again later. > Additionally, a 503 Service Unavailable error was encountered > while trying to use an ErrorDocument to handle the request. > Apache Server at salsa.debian.org Port 443 > > an external dependency has crept in, which i wasn't aware of, which > therefore hasn't been added here: > https://git.libre-soc.org/ > > this emphasises why it is important that we not depend on external > resources for development of the project. > > i'll remove it temporarily whilst it's down: now that i know the > project exists i've added it to git.libre-soc.org, jacob can you > re-add it after first doing a git push of nmigen-type-annotations to > git.libre-soc.org? > pushed to nmigen-type-annotations. yup, I'll re-add it once I can push to soc.git! Jacob From lkcl at lkcl.net Thu Mar 18 17:37:53 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 18 Mar 2021 17:37:53 +0000 Subject: [Libre-soc-dev] git forced master reversion on wiki and soc In-Reply-To: References: Message-ID: On Thu, Mar 18, 2021 at 4:32 PM Richard Wilbur wrote: > I have yet to pull anything. I was working on the wiki and stuff I got off FTP, yes i saw (you're fine). and you've yet to send me an ssh public key. l. From lkcl at lkcl.net Thu Mar 18 17:38:31 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 18 Mar 2021 17:38:31 +0000 Subject: [Libre-soc-dev] salsa.debian.org is currently down In-Reply-To: References: Message-ID: On Thu, Mar 18, 2021 at 4:45 PM Jacob Lifshay wrote: > > On Thu, Mar 18, 2021, 04:50 Luke Kenneth Casson Leighton > wrote: > pushed to nmigen-type-annotations. > yup, I'll re-add it once I can push to soc.git! excellent. you're added. l. From addw at phcomp.co.uk Thu Mar 18 16:15:14 2021 From: addw at phcomp.co.uk (Alain Williams) Date: Thu, 18 Mar 2021 16:15:14 +0000 Subject: [Libre-soc-dev] git forced master reversion on wiki and soc In-Reply-To: References: Message-ID: <20210318161514.GA16258@phcomp.co.uk> On Thu, Mar 18, 2021 at 09:07:43AM -0700, Jacob Lifshay wrote: > On Thu, Mar 18, 2021, 01:29 Luke Kenneth Casson Leighton > wrote: > > > i've made both soc and the wiki temporarily read-only until i hear > > from everybody that they've not done an overnight "git pull" and/or > > that they have restored master branch to the following (or later) > > > > soc b467827f51016fa5c8c96faa25b4e0790197a9f7 > > wiki 9784ecefb8a9b0e8e7aeae4c92fc1a622ac45325 > > > > the reason for making them read-only is to ensure that people do not > > push against the wrong master branch. > > > > jacob i will leave it with you to coordinate this with everybody and > > to explain it to them. once you have restored to the correct master > > branch point and have followed up with everyone to ensure that they > > have not done a pull overnight, please let me know and i will restore > > everybody's write access. > > > > Ok. I recreated my master branches for soc.git and libreriscv.git after > creating git tags. > > I checked who all has made any commits in the last week or so, I'm assuming > that everyone else is not likely to have pulled last night. We still need > to hear back from Alain, rwilbur, and Tobias (CCed). I pulled a couple of hours ago. I pushed something a couple of hours ago. I have several local changes - not pushed. What do I need to do to get synched with the right tree ? -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 https://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: https://www.phcomp.co.uk/Contact.html #include From programmerjake at gmail.com Thu Mar 18 17:39:49 2021 From: programmerjake at gmail.com (Jacob Lifshay) Date: Thu, 18 Mar 2021 10:39:49 -0700 Subject: [Libre-soc-dev] salsa.debian.org is currently down In-Reply-To: References: Message-ID: On Thu, Mar 18, 2021, 04:50 Luke Kenneth Casson Leighton wrote: > i just encountered this: > > fatal: unable to access > 'https://salsa.debian.org/Kazan-team/nmigen-type-annotations.git/': > The requested URL returned error: 503 > Unable to fetch in submodule path 'nmigen-type-annotations' > > the reason: salsa is down due to a security issue, once the admins update it later today it'll be re-enabled: https://lists.debian.org/debian-infrastructure-announce/2021/03/msg00000.html Jacob From lkcl at lkcl.net Thu Mar 18 17:47:10 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 18 Mar 2021 17:47:10 +0000 Subject: [Libre-soc-dev] git forced master reversion on wiki and soc In-Reply-To: <20210318161514.GA16258@phcomp.co.uk> References: <20210318161514.GA16258@phcomp.co.uk> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Thu, Mar 18, 2021 at 5:39 PM Alain Williams wrote: > I pulled a couple of hours ago. I pushed something a couple of hours ago. this looks fine: https://git.libre-soc.org/?p=libreriscv.git;a=summary > I have several local changes - not pushed. > > What do I need to do to get synched with the right tree ? the "normal" solution is to blow away the entire tree (without checking if that's necessary) the not-so-normal solution which is a horrible hack that works successfully (other people will scream in horror and say how it's "supposed" to be done) * edit .git/config and keep it there * git checkout {some commit dating back before the forced master push} * git branch -D master * git checkout -b master * save the **OLD** version of .git/config over the top (the -D will have deleted the [master] section) * git pull origin master been using that for several years now, no problzYYzzkrrrrt From libre-soc at platen-software.de Thu Mar 18 18:26:50 2021 From: libre-soc at platen-software.de (Tobias Platen) Date: Thu, 18 Mar 2021 19:26:50 +0100 Subject: [Libre-soc-dev] daily kan-ban update 18mar2021 Message-ID: <20210318192650.97fbde6d98921bf52a4cac9d@platen-software.de> today: test case for radix mmu -- Tobias Platen From lkcl at lkcl.net Thu Mar 18 18:35:12 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 18 Mar 2021 18:35:12 +0000 Subject: [Libre-soc-dev] daily kan-ban update 18mar2021 In-Reply-To: <20210318192650.97fbde6d98921bf52a4cac9d@platen-software.de> References: <20210318192650.97fbde6d98921bf52a4cac9d@platen-software.de> Message-ID: On Thu, Mar 18, 2021 at 6:26 PM Tobias Platen wrote: > > today: test case for radix mmu yeah good idea, it's starting to get to the kind of size where one's needed, isn't it. l. From lkcl at lkcl.net Thu Mar 18 18:54:32 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 18 Mar 2021 18:54:32 +0000 Subject: [Libre-soc-dev] cryptographic ASICs Message-ID: just wanted to make sure this isn't lost: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018412.html l. --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From adam at vany.ca Thu Mar 18 19:44:34 2021 From: adam at vany.ca (Adam Van Ymeren) Date: Thu, 18 Mar 2021 12:44:34 -0700 Subject: [Libre-soc-dev] git forced master reversion on wiki and soc In-Reply-To: References: <20210318161514.GA16258@phcomp.co.uk> Message-ID: <8b5e8018-0974-afcb-e332-e2987faa08ab@vany.ca> On 2021-03-18 10:47 a.m., Luke Kenneth Casson Leighton wrote: > --- > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 > > On Thu, Mar 18, 2021 at 5:39 PM Alain Williams wrote: > >> I pulled a couple of hours ago. I pushed something a couple of hours ago. > this looks fine: > https://git.libre-soc.org/?p=libreriscv.git;a=summary > > >> I have several local changes - not pushed. >> >> What do I need to do to get synched with the right tree ? > the "normal" solution is to blow away the entire tree (without > checking if that's necessary) > > the not-so-normal solution which is a horrible hack that works > successfully (other people will scream in horror and say how it's > "supposed" to be done) > > * edit .git/config and keep it there > * git checkout {some commit dating back before the forced master push} > * git branch -D master > * git checkout -b master > * save the **OLD** version of .git/config over the top (the -D will > have deleted the [master] section) > * git pull origin master > > been using that for several years now, no problzYYzzkrrrrt I think the easiest and safest solution is to just rename your current branch to hold on to it, and check out a new master from origin $ git fetch $ git branch -m master broken-master $ git checkout -b master origin/master Now you have the option of cherry-picking any work you want to keep from broken-master. > > _______________________________________________ > Libre-soc-dev mailing list > Libre-soc-dev at lists.libre-soc.org > http://lists.libre-soc.org/mailman/listinfo/libre-soc-dev From lkcl at lkcl.net Thu Mar 18 19:51:14 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 18 Mar 2021 19:51:14 +0000 Subject: [Libre-soc-dev] git forced master reversion on wiki and soc In-Reply-To: <8b5e8018-0974-afcb-e332-e2987faa08ab@vany.ca> References: <20210318161514.GA16258@phcomp.co.uk> <8b5e8018-0974-afcb-e332-e2987faa08ab@vany.ca> Message-ID: On Thursday, March 18, 2021, Adam Van Ymeren wrote: > > > I think the easiest and safest solution is to just rename your current > branch to hold on to it, and check out a new master from origin ahh much better :) > > -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From libre-soc at platen-software.de Thu Mar 18 19:58:19 2021 From: libre-soc at platen-software.de (Tobias Platen) Date: Thu, 18 Mar 2021 20:58:19 +0100 Subject: [Libre-soc-dev] daily kan-ban update 18mar2021 In-Reply-To: References: <20210318192650.97fbde6d98921bf52a4cac9d@platen-software.de> Message-ID: <20210318205819.670bb6872dc3210a9d229b84@platen-software.de> On Thu, 18 Mar 2021 18:35:12 +0000 Luke Kenneth Casson Leighton wrote: > On Thu, Mar 18, 2021 at 6:26 PM Tobias Platen > wrote: > > > > today: test case for radix mmu > > yeah good idea, it's starting to get to the kind of size where one's > needed, isn't it. > > l. > > _______________________________________________ > Libre-soc-dev mailing list > Libre-soc-dev at lists.libre-soc.org > http://lists.libre-soc.org/mailman/listinfo/libre-soc-dev found a bug in _get_pgtable_addr -- Tobias Platen From lkcl at lkcl.net Thu Mar 18 20:03:19 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 18 Mar 2021 20:03:19 +0000 Subject: [Libre-soc-dev] daily kan-ban update 18mar2021 In-Reply-To: <20210318205819.670bb6872dc3210a9d229b84@platen-software.de> References: <20210318192650.97fbde6d98921bf52a4cac9d@platen-software.de> <20210318205819.670bb6872dc3210a9d229b84@platen-software.de> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Thu, Mar 18, 2021 at 7:58 PM Tobias Platen wrote: > found a bug in _get_pgtable_addr nice! yeah it's really hard to read / translate between LE and BE modes *sigh* l. From libre-soc at platen-software.de Thu Mar 18 20:06:13 2021 From: libre-soc at platen-software.de (Tobias Platen) Date: Thu, 18 Mar 2021 21:06:13 +0100 Subject: [Libre-soc-dev] daily kan-ban update 18mar2021 In-Reply-To: References: <20210318192650.97fbde6d98921bf52a4cac9d@platen-software.de> <20210318205819.670bb6872dc3210a9d229b84@platen-software.de> Message-ID: <20210318210613.083d2cfb1ee20d8719e79675@platen-software.de> On Thu, 18 Mar 2021 20:03:19 +0000 Luke Kenneth Casson Leighton wrote: > nice! yeah it's really hard to read / translate between LE and BE modes *sigh* this is not the only bug, there was an undeclared variable which I oversaw. -- Tobias Platen From programmerjake at gmail.com Fri Mar 19 01:44:33 2021 From: programmerjake at gmail.com (Jacob Lifshay) Date: Thu, 18 Mar 2021 18:44:33 -0700 Subject: [Libre-soc-dev] salsa.debian.org is currently down In-Reply-To: References: Message-ID: On Thu, Mar 18, 2021, 10:39 Jacob Lifshay wrote: > On Thu, Mar 18, 2021, 04:50 Luke Kenneth Casson Leighton > wrote: > >> i just encountered this: >> >> fatal: unable to access >> 'https://salsa.debian.org/Kazan-team/nmigen-type-annotations.git/': >> The requested URL returned error: 503 >> Unable to fetch in submodule path 'nmigen-type-annotations' >> >> the reason: > > > salsa is down due to a security issue, once the admins update it later > today it'll be re-enabled: > > https://lists.debian.org/debian-infrastructure-announce/2021/03/msg00000.html > It's apparently back online. Jacob > From libre-soc at platen-software.de Fri Mar 19 19:03:52 2021 From: libre-soc at platen-software.de (Tobias Platen) Date: Fri, 19 Mar 2021 20:03:52 +0100 Subject: [Libre-soc-dev] daily kan-ban update 19mar2021 Message-ID: <20210319200352.e47864b8862162a73cbfe7b7@platen-software.de> today: testcase for _get_pgtable_addr, I've found that the the address calculated by _get_pgtable_addr is wrong. It returns 0x4000000, but the RADIX_SECOND_LEVEL is at 0x40000 in the test I used. I tried to push my changes but I got the following error. FATAL: W any soc tobias DENIED by fallthru (or you mis-spelled the reponame) fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. -- Tobias Platen From lkcl at lkcl.net Fri Mar 19 19:11:26 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 19 Mar 2021 19:11:26 +0000 Subject: [Libre-soc-dev] daily kan-ban update 19mar2021 In-Reply-To: <20210319200352.e47864b8862162a73cbfe7b7@platen-software.de> References: <20210319200352.e47864b8862162a73cbfe7b7@platen-software.de> Message-ID: On Fri, Mar 19, 2021 at 7:03 PM Tobias Platen wrote: > > today: testcase for _get_pgtable_addr, I've found that the the address > calculated by _get_pgtable_addr is wrong. It returns 0x4000000, but the > RADIX_SECOND_LEVEL is at 0x40000 in the test I used. I tried to push > my changes but I got the following error. yes, you'll need to check the following (do keep up-to-date on the mailing list posts) http://lists.libre-soc.org/pipermail/libre-soc-dev/2021-March/002187.html can you please check that you have the correct git master branch for soc. there should be no problems doing "git pull" for example. once you've confirmed that i can re-enable write access. l. From libre-soc at platen-software.de Fri Mar 19 19:28:20 2021 From: libre-soc at platen-software.de (Tobias Platen) Date: Fri, 19 Mar 2021 20:28:20 +0100 Subject: [Libre-soc-dev] daily kan-ban update 19mar2021 In-Reply-To: References: <20210319200352.e47864b8862162a73cbfe7b7@platen-software.de> Message-ID: <20210319202820.f397804d8d0abd188f7f3b72@platen-software.de> On Fri, 19 Mar 2021 19:11:26 +0000 Luke Kenneth Casson Leighton wrote: > On Fri, Mar 19, 2021 at 7:03 PM Tobias Platen > wrote: > > > > today: testcase for _get_pgtable_addr, I've found that the the address > > calculated by _get_pgtable_addr is wrong. It returns 0x4000000, but the > > RADIX_SECOND_LEVEL is at 0x40000 in the test I used. I tried to push > > my changes but I got the following error. > > yes, you'll need to check the following (do keep up-to-date on the > mailing list posts) > http://lists.libre-soc.org/pipermail/libre-soc-dev/2021-March/002187.html > > can you please check that you have the correct git master branch for soc. > there should be no problems doing "git pull" for example. > > once you've confirmed that i can re-enable write access. > > l. > > _______________________________________________ > Libre-soc-dev mailing list > Libre-soc-dev at lists.libre-soc.org > http://lists.libre-soc.org/mailman/listinfo/libre-soc-dev Git pull works, I only made changes in radixmmu.py this has no impact on the rest of the soc. remote: Enumerating objects: 13, done. remote: Counting objects: 100% (13/13), done. remote: Compressing objects: 100% (7/7), done. remote: Total 7 (delta 5), reused 0 (delta 0) Unpacking objects: 100% (7/7), done. >From ssh://git.libre-riscv.org:922/soc 9f638f41..e537f99b master -> origin/master Merge made by the 'recursive' strategy. src/soc/consts.py | 4 ++-- src/soc/decoder/power_svp64_rm.py | 45 +++++++++++++++++++++++++++++++++++++-------- 2 files changed, 39 insertions(+), 10 deletions(-) -- Tobias Platen From lkcl at lkcl.net Fri Mar 19 19:33:52 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 19 Mar 2021 19:33:52 +0000 Subject: [Libre-soc-dev] daily kan-ban update 19mar2021 In-Reply-To: <20210319202820.f397804d8d0abd188f7f3b72@platen-software.de> References: <20210319200352.e47864b8862162a73cbfe7b7@platen-software.de> <20210319202820.f397804d8d0abd188f7f3b72@platen-software.de> Message-ID: On Fri, Mar 19, 2021 at 7:28 PM Tobias Platen wrote: > Git pull works, I only made changes in radixmmu.py this has no impact on the rest of the soc. ok we risk it: write's now enabled. l. From libre-soc at platen-software.de Fri Mar 19 19:36:29 2021 From: libre-soc at platen-software.de (Tobias Platen) Date: Fri, 19 Mar 2021 20:36:29 +0100 Subject: [Libre-soc-dev] daily kan-ban update 19mar2021 In-Reply-To: References: <20210319200352.e47864b8862162a73cbfe7b7@platen-software.de> Message-ID: <20210319203629.4fae724cf6ec17e9aa6cb186@platen-software.de> On Fri, 19 Mar 2021 19:11:26 +0000 Luke Kenneth Casson Leighton wrote: I cloned the repository again (using git clone ssh://gitolite3 at git.libre-riscv.org:922/soc.git) then applied my last git diff. I assume that this is the correct method. I'm currently reading PowerISA_public.v3.0B.pdf, I don't expect any more commits today. > On Fri, Mar 19, 2021 at 7:03 PM Tobias Platen > wrote: > > > > today: testcase for _get_pgtable_addr, I've found that the the address > > calculated by _get_pgtable_addr is wrong. It returns 0x4000000, but the > > RADIX_SECOND_LEVEL is at 0x40000 in the test I used. I tried to push > > my changes but I got the following error. > > yes, you'll need to check the following (do keep up-to-date on the > mailing list posts) > http://lists.libre-soc.org/pipermail/libre-soc-dev/2021-March/002187.html > > can you please check that you have the correct git master branch for soc. > there should be no problems doing "git pull" for example. > > once you've confirmed that i can re-enable write access. > > l. > > _______________________________________________ > Libre-soc-dev mailing list > Libre-soc-dev at lists.libre-soc.org > http://lists.libre-soc.org/mailman/listinfo/libre-soc-dev -- Tobias Platen From libre-soc at platen-software.de Fri Mar 19 19:39:36 2021 From: libre-soc at platen-software.de (Tobias Platen) Date: Fri, 19 Mar 2021 20:39:36 +0100 Subject: [Libre-soc-dev] daily kan-ban update 19mar2021 In-Reply-To: References: <20210319200352.e47864b8862162a73cbfe7b7@platen-software.de> <20210319202820.f397804d8d0abd188f7f3b72@platen-software.de> Message-ID: <20210319203936.55b8b474a4bf08dfa2f8298f@platen-software.de> On Fri, 19 Mar 2021 19:33:52 +0000 Luke Kenneth Casson Leighton wrote: > ok we risk it: write's now enabled. I pushed the changes, and everything is as expected. https://git.libre-soc.org/?p=soc.git;a=commit;h=921e3d3fe0ae18fc648d773d9ab3b531d84ee0a2 -- Tobias Platen From lkcl at lkcl.net Fri Mar 19 19:40:07 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 19 Mar 2021 19:40:07 +0000 Subject: [Libre-soc-dev] daily kan-ban update 19mar2021 In-Reply-To: <20210319203629.4fae724cf6ec17e9aa6cb186@platen-software.de> References: <20210319200352.e47864b8862162a73cbfe7b7@platen-software.de> <20210319203629.4fae724cf6ec17e9aa6cb186@platen-software.de> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Fri, Mar 19, 2021 at 7:36 PM Tobias Platen wrote: > > On Fri, 19 Mar 2021 19:11:26 +0000 > Luke Kenneth Casson Leighton wrote: > > I cloned the repository again (using git clone ssh://gitolite3 at git.libre-riscv.org:922/soc.git) > then applied my last git diff. I assume that this is the correct method. that's the safest method. good choice. > I'm currently reading PowerISA_public.v3.0B.pdf, I don't expect any more commits today. all good. will take a look later. l. From lkcl at lkcl.net Sun Mar 21 13:09:02 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 21 Mar 2021 13:09:02 +0000 Subject: [Libre-soc-dev] [RFC] svp64 "source zeroing" makes no sense Message-ID: as i'm implementing the source- and dest- predication zeroing, it's not making sense: if not src_zeroing: while (((1< References: Message-ID: On Sun, Mar 21, 2021 at 7:09 AM Luke Kenneth Casson Leighton wrote: > > as i'm implementing the source- and dest- predication zeroing, it's not > making sense: > > if not src_zeroing: > while (((1< print (" skip", bin(1< srcstep += 1 Does this mean that if we are not doing source zeroing with the predication, then we skip the operation on vector elements where the source predication mask is 0 from least significant bit up till the least significant 1 in the source predication mask? > if not dest_zeroing: > # same for dststep > while (((1< print (" skip", bin(1< dststep += 1 This seems to say that if we are not doing destination zeroing with predication, then we skip the operation on vector elements where the destination predication mask is 0 from least significant bit up till the least significant 1 in the destination predication mask? In both of the above, what seems to be most important in the predication masks is the position of the least significant bit set to 1. Any 0 bits above that don't seem to have any effect on skipping the operation. > if src_zeroing and ((1< RA = 0 > RB = 0 > else: > RA = get_register_RA > RB = get_register_RB > > result, Condition_Register = calc_operation(RA, RB) > > if dest_zeroing and ((1< result = 0 > Condition_Register = EQzero > > store_result(result) > if Rc=1: store_cr(Condition_Register) This section seems to mean that: 1. If there is a higher significance (than the least significant 1 bit) 0 bit in the predication mask and source zeroing is not active we still perform the operation on that vector element regardless of the source or destination predication masks. 2. If source zeroing is active and the source predication mask bit is 0 then we use 0 for the source operands. 3. If destination zeroing is active and the destination element's bit of the source(?) predication mask bit is 0 then we overwrite the effect of performing the operation by setting result to 0 and the Condition_Register to EQzero. If result and Condition_Register were the only effects of the operation, we just wasted our time (and energy). This has several issues: 1. The operation is predicated only on the bits of the source or destination predication mask from the least significant bit up to the least significant 1. And then only if we aren't source zeroing or destination zeroing. 2. Above that (the least significant set bit of the predication mask) the operation is always performed but the result is thrown away if destination zeroing and the bit of the source predication mask corresponding to the destination element is 0? This seems like it should refer to the destination predication mask. 3. If we skip an operation we intended to destination zero, it doesn't look like it gets zeroed because we skip storing the result. 4. If we perform the operation and destination zero the result and Condition_Register, we have just wasted our time and energy by wiping out the results, unless there is an un-enumerated side effect. Here's a reimplementation of the above that, I believe, addresses the issues I saw: if not src_zeroing: while (srcstep != vl): if ((1< > i'm more inclined towards this: > > if (src_zeroing and ((1< (dest_zeroing and ((1< result = 0 > Condition_Register = EQzero > else: > RA = get_register_RA > RB = get_register_RB > result, Condition_Register = calc_operation(RA, RB) > > *now* that makes more sense, particularly when thought through from LD/ST. > > thoughts? For some reason this second version is still using the source predication mask for determining destination zeroing. This also never performs the operation with source operands zero! From lkcl at lkcl.net Sun Mar 21 19:19:41 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 21 Mar 2021 19:19:41 +0000 Subject: [Libre-soc-dev] [RFC] svp64 "source zeroing" makes no sense In-Reply-To: References: Message-ID: On Sunday, March 21, 2021, Richard Wilbur wrote: > On Sun, Mar 21, 2021 at 7:09 AM Luke Kenneth Casson Leighton > wrote: > > > > as i'm implementing the source- and dest- predication zeroing, it's not > > making sense: > > > > if not src_zeroing: > > while (((1< > print (" skip", bin(1< > srcstep += 1 > > Does this mean that if we are not doing source zeroing with the > predication, then we skip the operation on vector elements where the > source predication mask is 0 from least significant bit up till the > least significant 1 in the source predication mask? skip the operations plural. then repeat on the next iteration, which will have unconditionally incremented both srcstep and dststep by 1. from the next iteration it will continue not from the LSB but from where things left off. > > > if not dest_zeroing: > > # same for dststep > > while (((1< > print (" skip", bin(1< > dststep += 1 > > This seems to say that if we are not doing destination zeroing with > predication, then we skip the operation on vector elements where the > destination predication mask is 0 from least significant bit up till > the least significant 1 in the destination predication mask? same corrections, same statement as above. > In both of the above, what seems to be most important in the > predication masks is the position of the least significant bit set to > 1. Any 0 bits above that don't seem to have any effect on skipping > the operation. that's incorrect. the pseudocode is per loop, repeatedly called until either srcstep or dststep hits VL. rest of writing below is invalid, skipping. sorry, i do appreciate that it was quite a lot of analysis work you did. l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From richard.wilbur at gmail.com Sun Mar 21 19:51:28 2021 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Sun, 21 Mar 2021 13:51:28 -0600 Subject: [Libre-soc-dev] [RFC] svp64 "source zeroing" makes no sense In-Reply-To: References: Message-ID: <7D27F703-1CAC-4FB4-A219-77485E780A08@gmail.com> > On Mar 21, 2021, at 13:20, Luke Kenneth Casson Leighton wrote: > > skip the operations plural. then repeat on the next iteration, which will > have unconditionally incremented both srcstep and dststep by 1. from the > next iteration it will continue not from the LSB but from where things left > off. > > that's incorrect. the pseudocode is per loop, repeatedly called until > either srcstep or dststep hits VL. So there is a loop with the aforementioned source code as the body? That would explain my lack of understanding—I was missing significant context. So does the print “ skip”, bin(1<<{src|dst}step) statement just serve for debugging purposes and not actually change the operation of the code? From lkcl at lkcl.net Sun Mar 21 19:55:36 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 21 Mar 2021 19:55:36 +0000 Subject: [Libre-soc-dev] [RFC] svp64 "source zeroing" makes no sense In-Reply-To: <7D27F703-1CAC-4FB4-A219-77485E780A08@gmail.com> References: <7D27F703-1CAC-4FB4-A219-77485E780A08@gmail.com> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Sun, Mar 21, 2021 at 7:51 PM Richard Wilbur wrote: > > > On Mar 21, 2021, at 13:20, Luke Kenneth Casson Leighton > wrote: > > > > skip the operations plural. then repeat on the next iteration, which > will > > have unconditionally incremented both srcstep and dststep by 1. from the > > next iteration it will continue not from the LSB but from where things > left > > off. > > > > that's incorrect. the pseudocode is per loop, repeatedly called until > > either srcstep or dststep hits VL. > > So there is a loop with the aforementioned source code as the body? yes. single-stepping like this: https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/decoder/isa/test_caller.py;h=4ed0577c0fd22a52503c818f371d323e82b8ef7c;hb=HEAD#l49 note the call simulator.setup_one() then at line 63 simulator.execute_one(). That would explain my lack of understanding—I was missing significant > context. > > So does the > print “ skip”, bin(1<<{src|dst}step) > statement just serve for debugging purposes and not actually change the > operation of the code? > https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/decoder/isa/caller.py;hb=HEAD#l950 https://www.w3schools.com/python/ref_func_print.asp From richard.wilbur at gmail.com Sun Mar 21 20:11:16 2021 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Sun, 21 Mar 2021 14:11:16 -0600 Subject: [Libre-soc-dev] [RFC] svp64 "source zeroing" makes no sense In-Reply-To: References: Message-ID: <2E0ADC4A-089C-4548-9ADB-4B40740DBE59@gmail.com> The original post made no mention of the file or the language and I guessed (incorrectly) that this was some pseudocode reminiscent of Python in which you were writing the design. Thank you for supplying the context. I am familiar with python and the semantics of the print statement therein. From lkcl at lkcl.net Sun Mar 21 20:21:56 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 21 Mar 2021 20:21:56 +0000 Subject: [Libre-soc-dev] [RFC] svp64 "source zeroing" makes no sense In-Reply-To: <2E0ADC4A-089C-4548-9ADB-4B40740DBE59@gmail.com> References: <2E0ADC4A-089C-4548-9ADB-4B40740DBE59@gmail.com> Message-ID: On Sun, Mar 21, 2021 at 8:11 PM Richard Wilbur wrote: > The original post made no mention of the file or the language soorryyy :) and I guessed (incorrectly) that this was some pseudocode reminiscent of > Python in which you were writing the design. > funny that python's actually readable that way. i don't know many other programming languages that are. Thank you for supplying the context. I am familiar with python and the > semantics of the print statement therein. > :) ok so does it make more sense, now? l. From lkcl at lkcl.net Sun Mar 21 22:13:13 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 21 Mar 2021 22:13:13 +0000 Subject: [Libre-soc-dev] [RFC] svp64 "source zeroing" makes no sense In-Reply-To: References: <2E0ADC4A-089C-4548-9ADB-4B40740DBE59@gmail.com> Message-ID: so on each iteration, here are the four options, assume predicates on both src and dest: * no zeroing. this is a back-to-back VREDUCE-VEXPAND * source-predicate zeroing this is a VREDUCE with zeros inserted into the output * dest-predicate zeroing, this is a VEXPAND, but again anything that has zeros in the *dest* predicate, rather than expand-insert a result a zero is inserted instead * src-and-dest zeroing, the only one that is slightly odd: it is a straight linear element-matching operation where *either* src *or* dest zeros result in a zero output. the last one is the only one that is kinda redundant, you might as well just AND the two predicate masks together. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From richard.wilbur at gmail.com Sun Mar 21 22:30:32 2021 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Sun, 21 Mar 2021 16:30:32 -0600 Subject: [Libre-soc-dev] [RFC] svp64 "source zeroing" makes no sense In-Reply-To: References: <2E0ADC4A-089C-4548-9ADB-4B40740DBE59@gmail.com> Message-ID: On Sun, Mar 21, 2021 at 2:22 PM Luke Kenneth Casson Leighton wrote: > > On Sun, Mar 21, 2021 at 8:11 PM Richard Wilbur > wrote: > > > The original post made no mention of the file or the language > > > soorryyy :) I forgive you and thank you for supplying the context. > ok so does it make more sense, now? It definitely makes more sense now. I still have some comments: What is the maximum value of VL (or similarly, the maximum length of the predication masks)? I have in mind an optimization that avoids iterating through the 0 bits of the predication masks with logic that will generate the {src|dst}step pointing to the next non-zero bit in the mask provided there is at least one bit set. if not src_zeroing: srcstep += skip_zeros(srcmask, srcstep, vl) if (srcstep == vl): break if not dest_zeroing: dststep += skip_zeros(dstmask, dststep, vl) if (dststep == vl): break if dest_zeroing and ((1< References: <2E0ADC4A-089C-4548-9ADB-4B40740DBE59@gmail.com> Message-ID: On Sunday, March 21, 2021, Richard Wilbur wrote: > On Sun, Mar 21, 2021 at 2:22 PM Luke Kenneth Casson Leighton > wrote: > > > > On Sun, Mar 21, 2021 at 8:11 PM Richard Wilbur > > > wrote: > > > > > The original post made no mention of the file or the language > > > > > > soorryyy :) > > I forgive you and thank you for supplying the context. > > > ok so does it make more sense, now? > > It definitely makes more sense now. I still have some comments: > > What is the maximum value of VL y4. > (or similarly, the maximum length of > the predication masks)? integer. 64. > I have in mind an optimization that avoids > iterating through the 0 bits of the predication masks with logic that > will generate the {src|dst}step pointing to the next non-zero bit in > the mask provided there is at least one bit set. this will be possible as a choice for individual implementors where it makes sense based on gate count, performance and power consumption for their needs. it will be helpful to record such optimisations for when there is time to implement them. right now the priority question is "does ORing the src and dest zeroing to put zeros in the output make sense" if dest_zeroing and ((1< result = 0 > Condition_Register = EQzero > else: > if src_zeroing and ((1< RA = 0 > RB = 0 > else: > RA = get_register_RA > RB = get_register_RB > result, Condition_Register = calc_operation(RA, RB) this is still the old behaviour which is passing zeros into the pipelines as input. this behaviour makes no sense and must be replaced. 4. If there are un-enumerated side effects that we wish to reproduce > from calc_operation() pipelined designs should not have such side effects because they require complex hazard detection to coordinate and it severely impacts opportunities for parallelism (performance) thus, logically, if there is a choice "compromising performance to maintain some arbitrary side-effect" the side-effect gets quashed with prejudice. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From richard.wilbur at gmail.com Sun Mar 21 22:48:52 2021 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Sun, 21 Mar 2021 16:48:52 -0600 Subject: [Libre-soc-dev] [RFC] svp64 "source zeroing" makes no sense In-Reply-To: References: <2E0ADC4A-089C-4548-9ADB-4B40740DBE59@gmail.com> Message-ID: On Sun, Mar 21, 2021 at 4:13 PM Luke Kenneth Casson Leighton wrote: > > so on each iteration, here are the four options, assume predicates on both > src and dest: > > * no zeroing. this is a back-to-back VREDUCE-VEXPAND > > * source-predicate zeroing this is a VREDUCE with zeros inserted into the > output I guess it escapes me why this is called source predicate zeroing if it only affects the output. That seems like a separate/secondary destination zeroing mask. From lkcl at lkcl.net Sun Mar 21 23:06:53 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 21 Mar 2021 23:06:53 +0000 Subject: [Libre-soc-dev] [RFC] svp64 "source zeroing" makes no sense In-Reply-To: References: <2E0ADC4A-089C-4548-9ADB-4B40740DBE59@gmail.com> Message-ID: On Sunday, March 21, 2021, Richard Wilbur wrote: > On Sun, Mar 21, 2021 at 4:13 PM Luke Kenneth Casson Leighton > wrote: > > > > so on each iteration, here are the four options, assume predicates on > both > > src and dest: > > > > * no zeroing. this is a back-to-back VREDUCE-VEXPAND > > > > * source-predicate zeroing this is a VREDUCE with zeros inserted into > the > > output > > I guess it escapes me why this is called source predicate zeroing if > it only affects the output. i know. odd, isn't it. the clue is in if (src_zeroing and ((1< References: <2E0ADC4A-089C-4548-9ADB-4B40740DBE59@gmail.com> Message-ID: On Sun, Mar 21, 2021 at 4:40 PM Luke Kenneth Casson Leighton wrote: > > On Sunday, March 21, 2021, Richard Wilbur wrote: > > What is the maximum value of VL > > y4. > > > (or similarly, the maximum length of > > the predication masks)? > > integer. 64. > > > I have in mind an optimization that avoids > > iterating through the 0 bits of the predication masks with logic that > > will generate the {src|dst}step pointing to the next non-zero bit in > > the mask provided there is at least one bit set. The optimization is very simple. How sparse do you expect these predication masks to be? > > this will be possible as a choice for individual implementors where it > makes sense based on gate count, performance and power consumption for > their needs. > > it will be helpful to record such optimisations for when there is time to > implement them. I'm happy to do that. It's just so simple that I was thinking it sounded like an easy win if we expect predication masks to be fairly sparse as you save the cycles every time you perform an instruction. > right now the priority question is "does ORing the src and dest zeroing to > put zeros in the output make sense" With the code, I would suggest: if dest_zeroing and src_zeroing: dstmask &= srcmask > > if dest_zeroing and ((1< > result = 0 > > Condition_Register = EQzero > > else: > > if src_zeroing and ((1< > RA = 0 > > RB = 0 > > else: > > RA = get_register_RA > > RB = get_register_RB > > result, Condition_Register = calc_operation(RA, RB) > > > this is still the old behaviour which is passing zeros into the pipelines > as input. > > this behaviour makes no sense and must be replaced. I guess that's because I don't understand the intent. To me, source zeroing just passes 0's into whatever you were going to do. > 4. If there are un-enumerated side effects that we wish to reproduce > > from calc_operation() > > > pipelined designs should not have such side effects because they require > complex hazard detection to coordinate and it severely impacts > opportunities for parallelism (performance) > > thus, logically, if there is a choice "compromising performance to maintain > some arbitrary side-effect" the side-effect gets quashed with prejudice. Good! From richard.wilbur at gmail.com Sun Mar 21 23:21:05 2021 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Sun, 21 Mar 2021 17:21:05 -0600 Subject: [Libre-soc-dev] [RFC] svp64 "source zeroing" makes no sense In-Reply-To: References: <2E0ADC4A-089C-4548-9ADB-4B40740DBE59@gmail.com> Message-ID: On Sun, Mar 21, 2021 at 5:07 PM Luke Kenneth Casson Leighton wrote: > > On Sunday, March 21, 2021, Richard Wilbur wrote: > > I guess it escapes me why this is called source predicate zeroing if > > it only affects the output. > > > i know. odd, isn't it. the clue is in > > if (src_zeroing and ((1< (dest_zeroing and ((1< result = 0 Why isn't it: if (src_zeroing and ((1< > it's not > > if (dest_zeroing and ((1< (dest_zeroing and ((1< result = 0 > > it's not > > if (src_zeroing and ((1< (src_zeroing and ((1< result = 0 > > it's > > if (src_zeroing and ((1< (dest_zeroing and ((1< result = 0 For some reason, whether src_zeroing or dest_zeroing, in all of these examples you compare against only srcmask. Why are you ignoring dstmask? From lkcl at lkcl.net Sun Mar 21 23:44:26 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 21 Mar 2021 23:44:26 +0000 Subject: [Libre-soc-dev] [RFC] svp64 "source zeroing" makes no sense In-Reply-To: References: <2E0ADC4A-089C-4548-9ADB-4B40740DBE59@gmail.com> Message-ID: On Sunday, March 21, 2021, Richard Wilbur wrote: > > > The optimization is very simple. it's not going to be as simple as a single bit test inside a loop. that is the absolute top priority right now because we have people waiting on the critical path for working hardware and simulators. > > How sparse do you expect these > predication masks to be? literally absolutely all and anything. complete arbitrary all set, one bit not set right the way down to single bit set, at any point. all and anything, from 0/1 when VL=1 right the way to all and any possible permutations 2^64 when VL=64. trying to optimise for one particular workload of predicate masks is guaranteed to backfire, basically. > > > this will be possible as a choice for individual implementors where it > > makes sense based on gate count, performance and power consumption for > > their needs. > > > > it will be helpful to record such optimisations for when there is time to > > implement them. > > I'm happy to do that. It's just so simple that I was thinking it > sounded like an easy win if we expect predication masks to be fairly > sparse as you save the cycles every time you perform an instruction all and any spent on optimisations prevents and prohibits people waiting from proceeding. this is a critical path right now and we cannot afford the luxury at this time. please do record it so that as i already said, when there is time, it may be examined, and at that point, further time will be saved because we have a procedure. bear in mind that i have been planning this for a long while. the predicate masks when element width overrides are implemented will go directly into the PartitionedSignal as well as into the byte-level write-enable lines on the register file. > right now the priority question is "does ORing the src and dest zeroing to > > put zeros in the output make sense" > > With the code, I would suggest: > > if dest_zeroing and src_zeroing: > dstmask &= srcmask that's effectively what's happening, yes. or, destmask = srcmask = (destmask&srcmask) > > I guess that's because I don't understand the intent. To me, source > zeroing just passes 0's into whatever you were going to do. yes, that was the old behaviour, which is "nice and logical". the problem is, it makes no sense for e.g. LD or ST to try to LD or ST from address 0 when the input parameters have zero-predication, does it? in fact it would be dangerous to try because it will throw exceptions or worse produce garbage. and for divide operations this will cause overflow, garbage, or in FP it will cause spurious exceptions. etc etc. the task of going through "what does it mean for inputs to be zero" on each and every single operation is a very large one. worse than that it is necessary to define a procedure for people in the future. worse than that it interferes with the logic for reading operands, in ways that i am not looking forward to implementing. by contrast skipping the pipeline and inserting a zero into the outputs is relatively straightforward. l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From richard.wilbur at gmail.com Mon Mar 22 01:13:24 2021 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Sun, 21 Mar 2021 19:13:24 -0600 Subject: [Libre-soc-dev] [RFC] svp64 "source zeroing" makes no sense In-Reply-To: References: <2E0ADC4A-089C-4548-9ADB-4B40740DBE59@gmail.com> Message-ID: On Sun, Mar 21, 2021 at 5:44 PM Luke Kenneth Casson Leighton wrote: > > On Sunday, March 21, 2021, Richard Wilbur wrote: > > The optimization is very simple. > > it's not going to be as simple as a single bit test inside a loop. that is > the absolute top priority right now because we have people waiting on the > critical path for working hardware and simulators. Pretty close to that simple, here's the idea: Load a 64-bit shift register with the value of the mask (bits 0 to VL-1) with all bits at and above VL set. Connect the lowest 32 bits of shift register to zero-detector = 32-input NOR whose output runs a MUX { 0 := passes the 64 bits through, 1 := shifts them down 32 bits (and passes 1's in the high 32 bits of output)}. Connect to the output of the previous stage a stage of half the test and shift size: 16, 8, 4, 2, 1. The output of the zero detectors is the increment to the {dst|src}step (providing a value between 0-63). After the step has been incremented to point to the next non-zero bit of the mask, the shift register is reloaded from the MUX output of the last stage. In the outside loop, when the step is incremented by one after we finish the operation we shift the register down 1 bit (shifting in a 1 at the top). The only other thing would be to have logic to detect when the mask is all zeros and skip to the next instruction because there really isn't anything to do in that case (all inputs and/or all outputs excluded). > > How sparse do you expect these > > predication masks to be? > > > literally absolutely all and anything. complete arbitrary all set, one bit > not set right the way down to single bit set, at any point. > > all and anything, from 0/1 when VL=1 right the way to all and any possible > permutations 2^64 when VL=64. > > trying to optimise for one particular workload of predicate masks is > guaranteed to backfire, basically. This is not an optimization for a particular workload. It will never be slower than the comparison loop. I only ask about the expected sparseness in order to gauge how much of an improvement to expect. > > > this will be possible as a choice for individual implementors where it > > > makes sense based on gate count, performance and power consumption for > > > their needs. > > > > > > it will be helpful to record such optimisations for when there is time to > > > implement them. > > > > I'm happy to do that. It's just so simple that I was thinking it > > sounded like an easy win if we expect predication masks to be fairly > > sparse as you save the cycles every time you perform an instruction > > > all and any spent on optimisations prevents and prohibits people waiting > from proceeding. > > this is a critical path right now and we cannot afford the luxury at this > time. > > please do record it so that as i already said, when there is time, it may > be examined, and at that point, further time will be saved because we have > a procedure. > > bear in mind that i have been planning this for a long while. the > predicate masks when element width overrides are implemented will go > directly into the PartitionedSignal as well as into the byte-level > write-enable lines on the register file. It wouldn't necessarily change how the predicate masks are used anywhere else. Just in determining the next value of {src|dst}step in the vector execution loop. > > I guess that's because I don't understand the intent. To me, source > > zeroing just passes 0's into whatever you were going to do. > > > yes, that was the old behaviour, which is "nice and logical". the problem > is, it makes no sense for e.g. LD or ST to try to LD or ST from address 0 > when the input parameters have zero-predication, does it? in fact it would > be dangerous to try because it will throw exceptions or worse produce > garbage. > > and for divide operations this will cause overflow, garbage, or in FP it > will cause spurious exceptions. > > etc etc. > > the task of going through "what does it mean for inputs to be zero" on each > and every single operation is a very large one. > > worse than that it is necessary to define a procedure for people in the > future. > > worse than that it interferes with the logic for reading operands, in ways > that i am not looking forward to implementing. > > by contrast skipping the pipeline and inserting a zero into the outputs is > relatively straightforward. I guess I was thinking of vector sums and multiplies. What if we made the semantics be that by default an instruction ignores the src_zeroing flag and only considered the src_zeroing flag for instructions for which it made sense? I guess the other question is, "What advantage is there to having two output zeroing masks, one of which could be the source predication mask you just used for some other operation?" If that is a useful semantic, I'm all for it. I agree that for a number of operations feeding in zeros for the input is setting ourselves up for a world of hurt. From lkcl at lkcl.net Mon Mar 22 04:12:25 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 22 Mar 2021 04:12:25 +0000 Subject: [Libre-soc-dev] [RFC] svp64 "source zeroing" makes no sense In-Reply-To: References: <2E0ADC4A-089C-4548-9ADB-4B40740DBE59@gmail.com> Message-ID: On Monday, March 22, 2021, Richard Wilbur wrote: > > This is not an optimization for a particular workload. It will never > be slower than the comparison loop. I only ask about the expected > sparseness in order to gauge how much of an improvement to expect. we have no idea, it's literally impossible to say. bear in mind two things. 1) Dynamic Partitioned ALUs will require receiving MULTIPLE predicate mask bits i.e. cover multiple src/dest steps. 2) Multi-issue will require multiple src/dest steps per clock. > > It wouldn't necessarily change how the predicate masks are used > anywhere else. Just in determining the next value of {src|dst}step in > the vector execution loop. high petformance implementations cannot stall just because of a few mask bits being zero. the only reason for doing it that way right now is because it is about 5 lines of code even in HDL. there is an instruction which hunts for the next 1 after a trigger point, "set before first" and a twin "set after first". also there is a count leading zeros instruction. aka a "Priority Encoder". we need "count leading zeros starting from bit X". for multi issue and Dynamic Partitioned SIMD, multiple of those are required. > by contrast skipping the pipeline and inserting a zero into the outputs is > > relatively straightforward. > > I guess I was thinking of vector sums and multiplies. the normal Vector processor only has zeroing. ORing in parallel is done to merge bit-inverted-masked operations together to do parallel if then else. it works even for FP if you use add because zero is FP Zero. > > What if we made the semantics be that by default an instruction > ignores the src_zeroing flag and only considered the src_zeroing flag > for instructions for which it made sense? this requires going through every single instruction and marking it with a CSV File entry. will probably take about a week. we don't have a week to waste. > > I guess the other question is, "What advantage is there to having two > output zeroing masks, one of which could be the source predication > mask you just used for some other operation?" see the 4 combinations i described. now combine them with the fact that if then else is done as a parallel construct using masks. even not having to do the AND of two mask sets is useful as it will save one instruction l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From richard.wilbur at gmail.com Mon Mar 22 08:31:08 2021 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Mon, 22 Mar 2021 02:31:08 -0600 Subject: [Libre-soc-dev] [RFC] svp64 "source zeroing" makes no sense In-Reply-To: References: <2E0ADC4A-089C-4548-9ADB-4B40740DBE59@gmail.com> Message-ID: On Sun, Mar 21, 2021 at 10:13 PM Luke Kenneth Casson Leighton wrote: > > On Monday, March 22, 2021, Richard Wilbur wrote: > > > > > This is not an optimization for a particular workload. It will never > > be slower than the comparison loop. I only ask about the expected > > sparseness in order to gauge how much of an improvement to expect. > > > we have no idea, it's literally impossible to say. > > bear in mind two things. > > 1) Dynamic Partitioned ALUs will require receiving MULTIPLE predicate mask > bits i.e. cover multiple src/dest steps. Will the Dynamic Partitioned ALUs be receiving more than a source and destination mask? Will the mask size be related to the partitioned size of the ALU? > 2) Multi-issue will require multiple src/dest steps per clock. How many predicate masks are we talking about per operation? The code you posted had two: source and destination. Each ALU sounds like they might have a unique pair. > > It wouldn't necessarily change how the predicate masks are used > > anywhere else. Just in determining the next value of {src|dst}step in > > the vector execution loop. > > > high petformance implementations cannot stall just because of a few mask > bits being zero. the only reason for doing it that way right now is > because it is about 5 lines of code even in HDL. > > there is an instruction which hunts for the next 1 after a trigger point, > "set before first" and a twin "set after first". > > also there is a count leading zeros instruction. aka a "Priority Encoder". > > we need "count leading zeros starting from bit X". If I'm not mistaken, the logic design I mentioned implements the "count leading zeros starting from bit X". That is basically what I outlined. It also is ready for the next iteration right after you use the count of leading zeros because it generates its next state while generating the count. Here is an improved, simplified implementation of what I described earlier: Load a 64-bit register with the value of the mask (bits 0 to VL-1) with all bits at and above VL set to 1. Connect the lowest 32 bits of register to zero-detector = 32-input NOR whose output runs a MUX { 0 := passes the 64 bits through, 1 := shifts them down 32 bits (and passes 1's in the high 32 bits of output)}. Connect the output of the previous stage to a stage of half the test and shift size: 16, 8, 4, 2. The last stage has a slightly more complex test, if (mask.LSB == 0 && mask.NLSB == 1): zero1 = 1 if (mask.LSB == 0 && mask.NLSB == 0): zero64 = 1 where LSB = Least Significant Bit, NLSB = Next to Least Significant Bit zero64 flags the situation when VL is a power of 2 (twice the first zero-detector width) and the whole mask is zero. (This will happen only on the first iteration, as after the first update the mask register will always have removed all counted zeros.) The MUX on the 64-bit mask runs as follows { zero1 = 0 => the 64 bits are shifted down 1 bit with a 1 passed in the MSB, zero1 = 1 => the 64 bits are shifted down 2 bits with 1's passed in the 2 most significant bits}. (We don't worry about updating the register if zero64 = 1 as we have counted the whole register as 0 and thus are done.) {dst|src}step increment output: If zero64 is 1 a mux is set to output the bit pattern 0b100000 = 64, otherwise (zero64 = 0) the mux connects the other zero detectors to the output (providing a value between 0-63). After the step has been incremented to point to the next non-zero bit of the mask, the register is reloaded from the MUX output of the last stage if zero64 = 0, otherwise we're done. > for multi issue and Dynamic Partitioned SIMD, multiple of those are > required. A pair of source and destination predication masks for each ALU, right? > > by contrast skipping the pipeline and inserting a zero into the outputs is > > > relatively straightforward. > > > > I guess I was thinking of vector sums and multiplies. > > > the normal Vector processor only has zeroing. ORing in parallel is done to > merge bit-inverted-masked operations together to do parallel if then else. By this do you mean "the normal Vector processor only has" output "zeroing"? I guess I can see that if you don't want certain elements of a vector to be multiplied or added you can simply exclude them from the source predication mask, no need to send it zero operands! > > What if we made the semantics be that by default an instruction > > ignores the src_zeroing flag and only considered the src_zeroing flag > > for instructions for which it made sense? > > > this requires going through every single instruction and marking it with a > CSV File entry. > > will probably take about a week. > > we don't have a week to waste. I realize we don't have a lot of time to do this design. I also realize we will have plenty of time to regret the mistakes we make at this stage--especially the ones that can't be corrected easily in a compatible fashion. From lkcl at lkcl.net Mon Mar 22 11:01:16 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 22 Mar 2021 11:01:16 +0000 Subject: [Libre-soc-dev] [RFC] svp64 "source zeroing" makes no sense In-Reply-To: References: <2E0ADC4A-089C-4548-9ADB-4B40740DBE59@gmail.com> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Mon, Mar 22, 2021 at 8:28 AM Richard Wilbur wrote: > > 1) Dynamic Partitioned ALUs will require receiving MULTIPLE predicate > mask > > bits i.e. cover multiple src/dest steps. > > Will the Dynamic Partitioned ALUs be receiving more than a source and > destination mask? neither. Will the mask size be related to the partitioned > size of the ALU? > not at all. https://libre-soc.org/3d_gpu/architecture/dynamic_simd/?updated > > 2) Multi-issue will require multiple src/dest steps per clock. > > How many predicate masks are we talking about per operation? https://libre-soc.org/openpower/sv/overview/ for multi-operand-src operations, only one. named "single predication" for single-src single-dest operations, two. named "twin predication" The code > you posted had two: source and destination. Each ALU sounds like > they might have a unique pair. > that would be incorrect. the front-end (ISA decoder and issuer) is divorced, separated from, and abstracted away from, the back-end (ALUs) entirely. this is the point of using Cray-Style Vector ISAs: the front-end allows variable-length, the back-end is fixed width hardware (obviously: you cannot dynamically allocate more silicon). therefore element operations are "fed" to the back-end in groups. if there is room at the back-end ALUs to fit 8 operations, then srcstep and dststep can theoretically advance by up to 8 at a time per clock cycle. If I'm not mistaken, the logic design I mentioned implements the > "count leading zeros starting from bit X". That is basically what I > outlined. It also is ready for the next iteration right after you use > the count of leading zeros because it generates its next state while > generating the count. > excellent. now bear in mind that for high-performance implementations, *multiple* srcsteps and dststeps will need to be covered. at some point the complexity of detecting multiple bits and the regfile routing involved with doing so becomes so great that we will have to make compromises. > Here is an improved, simplified implementation of what I described earlier: > Load a 64-bit register with the value of the mask (bits 0 to > VL-1) with all bits at and above VL set to 1. > Connect the lowest 32 bits of register to zero-detector = > 32-input NOR whose output runs a MUX { 0 := passes the 64 bits > through, 1 := shifts them down 32 bits (and passes 1's in the high 32 > bits of output)}. > Connect the output of the previous stage to a stage of half the test > and shift size: 16, 8, 4, 2. > just so you know, there's a countzero module based on microwatt, here https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/fu/logical/countzero.py;hb=HEAD you can see it's directly equivalent to PriorityEncoder because the correctness proof passes: https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/fu/logical/formal/proof_main_stage.py;h=e7cf254a8f31be2a2a783b47027261a7a9116ae1;hb=HEAD#l119 a masked equivalent would be handy. zero-detector width) and the whole mask is zero. (This will happen > only on the first iteration, as after the first update the mask > register will always have removed all counted zeros.) > bear in mind that the only state information that can be stored is SVSTATE. anything else has to be re-created if returning from an interrupt into the middle of a loop. > for multi issue and Dynamic Partitioned SIMD, multiple of those are > > required. > > A pair of source and destination predication masks for each ALU, right? > slightly-incorrect. the fixed-width back-end ALUs know nothing about the variable-length front-end ISA. the ALUs currently know nothing about predication in any way, shape or form. there is absolutely no intention to pass the two predicate masks down through the ALUs: what would be the point, when *bypassing* the ALU entirely and directly writing zeros as outputs is quicker and uses less power? this can however get complicated when dynamic SIMD back-ends are involved. By this do you mean "the normal Vector processor only has" output "zeroing"? > the original Cray Vector system for example. I guess I can see that if you don't want certain elements of a vector > to be multiplied or added you can simply exclude them from the source > predication mask, no need to send it zero operands! > exactly. the reason why this is not done in "normal" Vector engines is because it introduces a READ-MODIFY-WRITE cycle if the width of the element operation is not equal to the write-width of the regfile hardware. for such legacy ("normal") Vector engines, it is "easier" to say "screw it" and write say a 32-bit zero in masked-out elements along-side a 32-bit result which fits into a 64-bit regfile entry than it is to do "argh this element was masked out, err read the regfile, modify the top 32 bits, write that out". we solved this with byte-level write-enable lines on the regfile. > I realize we don't have a lot of time to do this design. I also > realize we will have plenty of time to regret the mistakes we make at > this stage--especially the ones that can't be corrected easily in a > compatible fashion. > you're coming into this cold where i have had 2+ years to think about pretty much nothing else at both the hardware, ISA, and software level combined. the key insight raised here is that even dst-zero and src-zero both set is actually useful because it saves one instruction where ANDing of masks would otherwise be necessary. l. From cestrauss at gmail.com Mon Mar 22 13:23:03 2021 From: cestrauss at gmail.com (Cesar Strauss) Date: Mon, 22 Mar 2021 10:23:03 -0300 Subject: [Libre-soc-dev] RFC: Make sm=m by default on twin predication for SVP64 assembly Message-ID: Greetings, In SVP64 assembly, on twin predication, srcmask (sm) seems to be set to "always" by default, if not specified. This is in contrast to single predication, where srcmask is implicitly set to destmask (m). So, this will trigger a VEXPAND: sv.extsb/m=r3 5.v, 9.v ... which is not obvious by just looking at it. I propose to have to explicitly state that sm=~0 or sm=all1, when we do want a VEXPAND: sv.extsb/m=r3/sm=all1 5.v, 9.v ... and make the first example identical to: sv.extsb/m=r3/sm=r3 5.v, 9.v ... which corresponds to single predication. In other words, twin predication only happens when "sm" is explicitly present in the instruction (and different from "m"). Otherwise, it is simple predication, even if the instruction is twin-predication capable. Regards, Cesar From lkcl at lkcl.net Mon Mar 22 16:37:26 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 22 Mar 2021 16:37:26 +0000 Subject: [Libre-soc-dev] RFC: Make sm=m by default on twin predication for SVP64 assembly In-Reply-To: References: Message-ID: On Monday, March 22, 2021, Cesar Strauss wrote: > Greetings, > > In SVP64 assembly, on twin predication, srcmask (sm) seems to be set to > "always" by default, if not specified. the four combinations are: * no masks (both always) * sm set, dm=always * sm=always, dm set * both set. basically if one of the masks is not specified, they must each independently be set to "always". > This is in contrast to single > predication, where srcmask is implicitly set to destmask (m). > > So, this will trigger a VEXPAND: > > sv.extsb/m=r3 5.v, 9.v yes it's odd, the *source* triggers VEXPAND, the *dest* triggers VREDUCE. > > ... which is not obvious by just looking at it. > > I propose to have to explicitly state that sm=~0 or sm=all1, when we do > want a VEXPAND: > > sv.extsb/m=r3/sm=all1 5.v, 9.v this is muuch longer, which will result in more processing power used, some of the options alreafy take up an alarming line length i don't have a problem with adding both those syntaxes for clarity / convenience. > ... and make the first example identical to: > > sv.extsb/m=r3/sm=r3 5.v, 9.v > > ... which corresponds to single predication. > > In other words, twin predication only happens when "sm" is explicitly > present in the instruction (and different from "m"). twin predication is a property of the instruction. > Otherwise, it is > simple predication, even if the instruction is twin-predication capable. hmm ok so one solution is to introduce this: m=XX # 2pred sets both sm source dm dedt sm and dm are only possible to set on 2pred. l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From cestrauss at gmail.com Mon Mar 22 17:07:17 2021 From: cestrauss at gmail.com (Cesar Strauss) Date: Mon, 22 Mar 2021 14:07:17 -0300 Subject: [Libre-soc-dev] RFC: Make sm=m by default on twin predication for SVP64 assembly In-Reply-To: References: Message-ID: On 03/22/2021 13:37, Luke Kenneth Casson Leighton wrote: > ok so one solution is to introduce this: > > m=XX # 2pred sets both > sm source > dm dedt > > sm and dm are only possible to set on 2pred. This is great, much better. Works for me, agreed. Thanks, Cesar From libre-soc at platen-software.de Mon Mar 22 19:20:50 2021 From: libre-soc at platen-software.de (Tobias Platen) Date: Mon, 22 Mar 2021 20:20:50 +0100 Subject: [Libre-soc-dev] daily kan-ban update 22mar2021 Message-ID: <20210322202050.476908fc6595bd0af760cd46@platen-software.de> today: after reading the powerisa documentation I found out what was going wrong. continue to work on radixmmu.py, fixing bugs and verification. From lkcl at lkcl.net Mon Mar 22 22:04:23 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 22 Mar 2021 22:04:23 +0000 Subject: [Libre-soc-dev] daily kan-ban update 22mar2021 In-Reply-To: <20210322202050.476908fc6595bd0af760cd46@platen-software.de> References: <20210322202050.476908fc6595bd0af760cd46@platen-software.de> Message-ID: On Monday, March 22, 2021, Tobias Platen wrote: > today: after reading the powerisa documentation I found out what was going > wrong. > continue to work on radixmmu.py, fixing bugs and verification. superb. l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From richard.wilbur at gmail.com Tue Mar 23 18:28:20 2021 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Tue, 23 Mar 2021 12:28:20 -0600 Subject: [Libre-soc-dev] [RFC] svp64 "source zeroing" makes no sense In-Reply-To: References: <2E0ADC4A-089C-4548-9ADB-4B40740DBE59@gmail.com> Message-ID: On Mon, Mar 22, 2021 at 5:02 AM Luke Kenneth Casson Leighton wrote: > > --- > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 > > > On Mon, Mar 22, 2021 at 8:28 AM Richard Wilbur > wrote: > > > > > 1) Dynamic Partitioned ALUs will require receiving MULTIPLE predicate > > mask > > > bits i.e. cover multiple src/dest steps. > > > > Will the Dynamic Partitioned ALUs be receiving more than a source and > > destination mask? > > > neither. What "predicate mask bits" will the "Dynamic Partitioned ALUs" be receiving? > > Will the mask size be related to the partitioned > > size of the ALU? > > > > not at all. > https://libre-soc.org/3d_gpu/architecture/dynamic_simd/?updated Ok. I read that and a bit more. I think I have a conceptual understanding of the dynamically partitioned ALUs. Very cool. > > > 2) Multi-issue will require multiple src/dest steps per clock. > > > > How many predicate masks are we talking about per operation? > > > https://libre-soc.org/openpower/sv/overview/ > for multi-operand-src operations, only one. named "single predication" > for single-src single-dest operations, two. named "twin predication" > > The code > > you posted had two: source and destination. Each ALU sounds like > > they might have a unique pair. > > > > that would be incorrect. the front-end (ISA decoder and issuer) is > divorced, separated from, and abstracted away from, the back-end (ALUs) > entirely. this is the point of using Cray-Style Vector ISAs: the front-end > allows variable-length, the back-end is fixed width hardware (obviously: > you cannot dynamically allocate more silicon). > > therefore element operations are "fed" to the back-end in groups. if there > is room at the back-end ALUs to fit 8 operations, then srcstep and dststep > can theoretically advance by up to 8 at a time per clock cycle. > > If I'm not mistaken, the logic design I mentioned implements the > > "count leading zeros starting from bit X". That is basically what I > > outlined. It also is ready for the next iteration right after you use > > the count of leading zeros because it generates its next state while > > generating the count. > > > > excellent. > > now bear in mind that for high-performance implementations, *multiple* > srcsteps and dststeps will need to be covered. at some point the > complexity of detecting multiple bits and the regfile routing involved with > doing so becomes so great that we will have to make compromises. Yes, I would use one of the proposed modules for the source predication mask and a separate one for the destination predication mask. > just so you know, there's a countzero module based on microwatt, here > https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/fu/logical/countzero.py;hb=HEAD > > you can see it's directly equivalent to PriorityEncoder because the > correctness proof passes: > https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/fu/logical/formal/proof_main_stage.py;h=e7cf254a8f31be2a2a783b47027261a7a9116ae1;hb=HEAD#l119 > > a masked equivalent would be handy. What do you mean? Masked equivalent of the PriorityEncoder, the countzero module? > bear in mind that the only state information that can be stored is > SVSTATE. anything else has to be re-created if returning from an interrupt > into the middle of a loop. What information is stored in SVSTATE? Where in the loop is the valid exit point if an interrupt occurs? While shovelling snow and ice this morning (storm last night) I realized that the only things the module I proposed needs to recover state are the initial predication mask (our starting point) and the last value of the step. > > for multi issue and Dynamic Partitioned SIMD, multiple of those are > > > required. > > > > A pair of source and destination predication masks for each ALU, right? > > > > slightly-incorrect. the fixed-width back-end ALUs know nothing about the > variable-length front-end ISA. the ALUs currently know nothing about > predication in any way, shape or form. there is absolutely no intention to > pass the two predicate masks down through the ALUs: what would be the > point, when *bypassing* the ALU entirely and directly writing zeros as > outputs is quicker and uses less power? > > this can however get complicated when dynamic SIMD back-ends are involved. Yes, having read a bit about the dynamic SIMD it sounds like predication could be complicated in that instance. It seems that dynamic SIMD determines how you process an operand once you get it and predication has to do with which operand we send and where we store the result. > By this do you mean "the normal Vector processor only has" output "zeroing"? > > > > the original Cray Vector system for example. > > I guess I can see that if you don't want certain elements of a vector > > to be multiplied or added you can simply exclude them from the source > > predication mask, no need to send it zero operands! > > > > exactly. the reason why this is not done in "normal" Vector engines is > because it introduces a READ-MODIFY-WRITE cycle if the width of the element > operation is not equal to the write-width of the regfile hardware. > > for such legacy ("normal") Vector engines, it is "easier" to say "screw it" > and write say a 32-bit zero in masked-out elements along-side a 32-bit > result which fits into a 64-bit regfile entry than it is to do "argh this > element was masked out, err read the regfile, modify the top 32 bits, write > that out". > > we solved this with byte-level write-enable lines on the regfile. Good choice! I am planning to read about the Cray Vector system soon (today). > > I realize we don't have a lot of time to do this design. I also > > realize we will have plenty of time to regret the mistakes we make at > > this stage--especially the ones that can't be corrected easily in a > > compatible fashion. > > > > you're coming into this cold where i have had 2+ years to think about > pretty much nothing else at both the hardware, ISA, and software level > combined. Yes, I am working to come up to speed by reading the wiki (and several of the external links referenced). Quite interesting stuff! > the key insight raised here is that even dst-zero and src-zero both set is > actually useful because it saves one instruction where ANDing of masks > would otherwise be necessary. Saving instructions is great! From lkcl at lkcl.net Tue Mar 23 19:48:45 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 23 Mar 2021 19:48:45 +0000 Subject: [Libre-soc-dev] [RFC] svp64 "source zeroing" makes no sense In-Reply-To: References: <2E0ADC4A-089C-4548-9ADB-4B40740DBE59@gmail.com> Message-ID: On Tuesday, March 23, 2021, Richard Wilbur wrote: > > What "predicate mask bits" will the "Dynamic Partitioned ALUs" be > receiving? one option is: absolutely none whatsoever. you may not have realised the significance of "bypass the ALU entirely". conceptually however for 8 16 and 32 bit the bytelevel write-enable lines are "expanded predicate mask bits only not really". anything passed in to the ALUs in positions which are not going to be written we simply don't give a damn. when clock gating becomes possible this is an entirely different matter. each dynamic lane *at the byte level* will need gating. > > > > > Will the mask size be related to the partitioned > > > size of the ALU? > > > > > > > not at all. > > https://libre-soc.org/3d_gpu/architecture/dynamic_simd/?updated > > Ok. I read that and a bit more. I think I have a conceptual > understanding of the dynamically partitioned ALUs. Very cool. frickin awesome more like. saves hugely on gate count and massively reduces complexity. > a masked equivalent would be handy. > > What do you mean? start from a position other than the start. basically shift the value down, trash N bits, then count. > > > What information is stored in SVSTATE? https://libre-soc.org/openpower/sv/sprs/ https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/sv/svstate.py;hb=HEAD > Where in the loop is the valid exit point if an interrupt occurs? at any time. it's a Sub-Program-Counter and should be treated as such. > > While shovelling snow and ice this morning as you do. hey it's better than shovelling s*** at any temperature > (storm last night) I > realized that the only things the module I proposed needs to recover > state are the initial predication mask (our starting point) which is re-read on restarting the instruction if it's an INT predicate. > and the > last value of the step. and the sub-step. and the dest step. see SVSTATE. > this can however get complicated when dynamic SIMD back-ends are involved. > > Yes, having read a bit about the dynamic SIMD it sounds like > predication could be complicated in that instance. It seems that > dynamic SIMD determines how you process an operand operands plural. > once you get it and > predication has to do with which operand we send and where we store > the result. correct. > > Good choice! I am planning to read about the Cray Vector system soon > (today). > > it's fun (awesome) but different. Cray vectors actually have vector registers and therefore have vector instructions. in SV there are no vector registers. just loops that "oh look this sequence can be sent to a massive wide SIMD backend" this confuses the hell out of anyone who believes that vector registers are The One True Way. l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From libre-soc at platen-software.de Tue Mar 23 20:15:16 2021 From: libre-soc at platen-software.de (Tobias Platen) Date: Tue, 23 Mar 2021 21:15:16 +0100 Subject: [Libre-soc-dev] daily kan-ban update 23mar2021 Message-ID: <20210323211516.672e309a74470200f1e9c026@platen-software.de> today: add addrshift function (based on microwatt) to radixmmu.py -- Shift address bits 61--12 right by 0--47 bits and -- supply the least significant 16 bits of the result. From lkcl at lkcl.net Tue Mar 23 20:36:26 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 23 Mar 2021 20:36:26 +0000 Subject: [Libre-soc-dev] daily kan-ban update 23mar2021 In-Reply-To: <20210323211516.672e309a74470200f1e9c026@platen-software.de> References: <20210323211516.672e309a74470200f1e9c026@platen-software.de> Message-ID: On Tuesday, March 23, 2021, Tobias Platen wrote: > -- Shift address bits 61--12 right by 0--47 bits and > -- supply the least significant 16 bits of the result. https://git.libre-soc.org/?p=soc.git;a=commitdiff;h=HEAD blegh :) these microwatt functions are awful. they are heavily optimised for Xilinx FPGA toolchains (which are s***) to specifically target Xilinx LUT6 FPGAs. we should not in any way try to replicate or use them. just replace with shift and mask. x = addr >> shift return x[0:16] # but convert to MSB0 -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From libre-soc at platen-software.de Tue Mar 23 20:43:32 2021 From: libre-soc at platen-software.de (Tobias Platen) Date: Tue, 23 Mar 2021 21:43:32 +0100 Subject: [Libre-soc-dev] daily kan-ban update 23mar2021 In-Reply-To: References: <20210323211516.672e309a74470200f1e9c026@platen-software.de> Message-ID: <20210323214332.9a21bce186ca31b0a2424577@platen-software.de> On Tue, 23 Mar 2021 20:36:26 +0000 Luke Kenneth Casson Leighton wrote: > On Tuesday, March 23, 2021, Tobias Platen > wrote: > > > > -- Shift address bits 61--12 right by 0--47 bits and > > -- supply the least significant 16 bits of the result. > > > https://git.libre-soc.org/?p=soc.git;a=commitdiff;h=HEAD > > blegh :) > > these microwatt functions are awful. they are heavily optimised for Xilinx > FPGA toolchains (which are s***) to specifically target Xilinx LUT6 FPGAs. > > we should not in any way try to replicate or use them. > > just replace with shift and mask. > > x = addr >> shift > return x[0:16] # but convert to MSB0 I'm going to fix that now. > > > -- > --- > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 > _______________________________________________ > Libre-soc-dev mailing list > Libre-soc-dev at lists.libre-soc.org > http://lists.libre-soc.org/mailman/listinfo/libre-soc-dev -- Tobias Platen From lkcl at lkcl.net Tue Mar 23 21:32:52 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 23 Mar 2021 21:32:52 +0000 Subject: [Libre-soc-dev] daily kan-ban update 23mar2021 In-Reply-To: <20210323214332.9a21bce186ca31b0a2424577@platen-software.de> References: <20210323211516.672e309a74470200f1e9c026@platen-software.de> <20210323214332.9a21bce186ca31b0a2424577@platen-software.de> Message-ID: On Tuesday, March 23, 2021, Tobias Platen wrote: > > I'm going to fix that now. + x = addr.value >> shift.value + return SelectableInt(x,16) totally cheating, bypassing SelectableOnt. very funny, but works well. l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From richard.wilbur at gmail.com Wed Mar 24 02:09:04 2021 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Tue, 23 Mar 2021 20:09:04 -0600 Subject: [Libre-soc-dev] [RFC] svp64 "source zeroing" makes no sense In-Reply-To: References: <2E0ADC4A-089C-4548-9ADB-4B40740DBE59@gmail.com> Message-ID: On Tue, Mar 23, 2021 at 1:49 PM Luke Kenneth Casson Leighton wrote: > > On Tuesday, March 23, 2021, Richard Wilbur wrote: > > > > What "predicate mask bits" will the "Dynamic Partitioned ALUs" be > > receiving? > > > one option is: absolutely none whatsoever. you may not have realised the > significance of "bypass the ALU entirely". I think I have a pretty good handle on "bypass the ALU entirely" as being similar to "just store 0 in the destination". I asked the above question because of something you said in an E-mail message in this thread which I received on 21 Mar (you sent on 22 Mar), "bear in mind two things. 1) Dynamic Partitioned ALUs will require receiving MULTIPLE predicate mask bits i.e. cover multiple src/dest steps. 2) Multi-issue will require multiple src/dest steps per clock." I attempted to directly ask about thing #1. In an intervening message I had asked if the Dynamic Partitioned ALUs would be receiving source and destination predication masks, to which you replied, "neither." This was a follow-up question to try and clarify things. > conceptually however for 8 16 and 32 bit the bytelevel write-enable lines > are "expanded predicate mask bits only not really". anything passed in to > the ALUs in positions which are not going to be written we simply don't > give a damn. > > when clock gating becomes possible this is an entirely different matter. > each dynamic lane *at the byte level* will need gating. So, it sounds like the source and destination predication masks are important to the issuer in determining which parts of the source vector to read and process and which parts of the destination vector to write. The byte-level write-enable lines look like they have more to do with how the SIMD ALUs are partitioned and store their results. > > > a masked equivalent would be handy. > > > > What do you mean? > > start from a position other than the start. basically shift the value > down, trash N bits, then count. Latest revision has that as well. That is what is required to start where we left off after returning from an interrupt. > > Where in the loop is the valid exit point if an interrupt occurs? > > at any time. it's a Sub-Program-Counter and should be treated as such. I don't see the "Sub-Program-Counter" in the SVSTATE documentation. I see the srcstep, dststep, and svstep. Do we always finish an issue in progress? In other words, after we update srcstep, if we get an interrupt (hardware) before we update dststep, do we jump out of the loop before we update dststep? If this is how it works, this could be difficult to restart at that particular spot. Whereas, if we jump out of the loop at the bottom, after issuing the instruction and incrementing srcstep and dststep. From lkcl at lkcl.net Wed Mar 24 04:49:36 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 24 Mar 2021 04:49:36 +0000 Subject: [Libre-soc-dev] [RFC] svp64 "source zeroing" makes no sense In-Reply-To: References: <2E0ADC4A-089C-4548-9ADB-4B40740DBE59@gmail.com> Message-ID: On Wednesday, March 24, 2021, Richard Wilbur wrote: > > being similar to "just store 0 in the destination". I asked the above > question because of something you said in an E-mail message in this > thread which I received on 21 Mar (you sent on 22 Mar), > "bear in mind two things. > > 1) Dynamic Partitioned ALUs will require receiving MULTIPLE predicate mask > bits i.e. cover multiple src/dest steps. right. sorry. wrong words. because 64 bit DynamicPartitioned ALUs can represent / compute multiple elements (8 in the case of elwidth=8 overrides) this is *effectively* multi-issue. therefore @ ew=8 you need to shove 8 lots of elements into each one. therefore that requires 8 src/dest steps where the squishy brown (blue in the case of myrhbusters because it was easier for the cameras) hits the axially rotating bladed device is in routing arbitrary data from regfiles in different lanes. it may be easier if the predicate masks are full of holes to just go "screw it" and run say 50% of the 8 bit DynamicPartitions empty. however if there happens to be a masked parallel if-then-else construct, these typically use the exact same predicate just with inverted mask. if those parallel then-else clauses *happen* to require the exact same ALU *and* the registers are in the same lanes we *might* be able to.match up the opposing masks and fill the ALUs to run 100%. i stress might. > > So, it sounds like the source and destination predication masks are > important to the issuer in determining which parts of the source > vector to read and process and which parts of the destination vector > to write. ahh yes, very. > The byte-level write-enable lines look like they have more > to do with how the SIMD ALUs are partitioned > ahh no. the partition sizes are determined by the element-width overrides. as the element widths are 8, 16, 32 and 64 this tells you *how many* byte-write lines to enable per element, where the mask bits apply *per element*. > and store their results. yes. > > start from a position other than the start. basically shift the value > > down, trash N bits, then count. > > Latest revision has that as well. That is what is required to start > where we left off after returning from an interrupt. to cope with reentrancy, my feeling is the algirithm should be like this: * already_done = (1< > > > Where in the loop is the valid exit point if an interrupt occurs? > > > > at any time. it's a Sub-Program-Counter and should be treated as such. > > I don't see the "Sub-Program-Counter" in the SVSTATE documentation. it's a conceptual one. > I > see the srcstep, dststep, that's the concrptual Sub-PC > and svstep. that's the conceptual Sub-Sub-PC > Do we always finish an issue in > progress? no choice there. at least not until we add OperationCancellation (Shadowing) > In other words, after we update srcstep, if we get an > interrupt (hardware) before we update dststep, do we jump out of the > loop before we update dststep? yes... where the interrupt handling is REQUIRED to save SVSTATE along with MSR and PC. > If this is how it works, this could be > difficult to restart at that particular spot. nope. not at all. the rfid instruction restores SVSTATE PC and MSR from the SPRs. l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From lkcl at lkcl.net Thu Mar 25 15:47:07 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 25 Mar 2021 15:47:07 +0000 Subject: [Libre-soc-dev] draft letter to OPF re ISA WG proposal Message-ID: https://libre-soc.org/openpower/ISA_WG/Board_letter_26mar2021/?updated 'WIP -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From programmerjake at gmail.com Thu Mar 25 18:59:09 2021 From: programmerjake at gmail.com (Jacob Lifshay) Date: Thu, 25 Mar 2021 11:59:09 -0700 Subject: [Libre-soc-dev] draft letter to OPF re ISA WG proposal In-Reply-To: References: Message-ID: On Thu, Mar 25, 2021, 08:47 Luke Kenneth Casson Leighton wrote: > https://libre-soc.org/openpower/ISA_WG/Board_letter_26mar2021/?updated > > 'WIP > looks pretty good so far, I fixed some typos and added libre-soc-isa to the cc list. Jacob From lkcl at lkcl.net Thu Mar 25 19:22:14 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 25 Mar 2021 19:22:14 +0000 Subject: [Libre-soc-dev] draft letter to OPF re ISA WG proposal In-Reply-To: References: Message-ID: On Thursday, March 25, 2021, Jacob Lifshay wrote: > On Thu, Mar 25, 2021, 08:47 Luke Kenneth Casson Leighton > wrote: > > > https://libre-soc.org/openpower/ISA_WG/Board_letter_26mar2021/?updated > > > > 'WIP > > > > looks pretty good so far, I fixed some typos and added libre-soc-isa to the > cc list. oh great idea. you can see where it's going. > > -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From libre-soc at platen-software.de Thu Mar 25 19:41:51 2021 From: libre-soc at platen-software.de (Tobias Platen) Date: Thu, 25 Mar 2021 20:41:51 +0100 Subject: [Libre-soc-dev] daily kan-ban update 25mar2021 Message-ID: <20210325204151.ad0beedcdb73dff6b4eb9426@platen-software.de> today: fixed a bug in _get_prtable_addr, removed various debug outputs -- Tobias Platen From richard.wilbur at gmail.com Thu Mar 25 20:39:46 2021 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Thu, 25 Mar 2021 14:39:46 -0600 Subject: [Libre-soc-dev] draft letter to OPF re ISA WG proposal In-Reply-To: References: Message-ID: Building off Jacob's work, I made a small grammatical fix in the third(?) paragraph. (Begins with "From reading ...") From lkcl at lkcl.net Thu Mar 25 20:56:12 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 25 Mar 2021 20:56:12 +0000 Subject: [Libre-soc-dev] daily kan-ban update 25mar2021 In-Reply-To: <20210325204151.ad0beedcdb73dff6b4eb9426@platen-software.de> References: <20210325204151.ad0beedcdb73dff6b4eb9426@platen-software.de> Message-ID: On Thursday, March 25, 2021, Tobias Platen wrote: > today: fixed a bug in _get_prtable_addr, removed various debug outputs great. there are quite a few shall we say :) doing unit tests is much better, i am however a fan of print statements as you can probably tell > > -- > Tobias Platen > > _______________________________________________ > Libre-soc-dev mailing list > Libre-soc-dev at lists.libre-soc.org > http://lists.libre-soc.org/mailman/listinfo/libre-soc-dev > -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From lkcl at lkcl.net Thu Mar 25 20:57:16 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 25 Mar 2021 20:57:16 +0000 Subject: [Libre-soc-dev] draft letter to OPF re ISA WG proposal In-Reply-To: References: Message-ID: On Thursday, March 25, 2021, Richard Wilbur wrote: > Building off Jacob's work, I made a small grammatical fix in the > third(?) paragraph. (Begins with "From reading ...") star. l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From lkcl at lkcl.net Thu Mar 25 22:08:06 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 25 Mar 2021 22:08:06 +0000 Subject: [Libre-soc-dev] daily kan-ban update 25mar2021 In-Reply-To: References: <20210325204151.ad0beedcdb73dff6b4eb9426@platen-software.de> Message-ID: class TestRadixMMU(unittest.TestCase): def test_genmask(self): @@ -705,6 +703,7 @@ class TestRadixMMU(unittest.TestCase): shift = rts result = mem._walk_tree(addr, pgbase, mode, mbits, shift) print(" walking tree result", result) + print("should be",testresult) here tobias you can add self.assertEqual(result, testresult) then, use a for-loop to put in multiple potential values, if that is appropriate. for result, testresult in [ (nn, mm), (nn2, mm2), ... ] l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From lkcl at lkcl.net Fri Mar 26 18:11:34 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 26 Mar 2021 18:11:34 +0000 Subject: [Libre-soc-dev] draft letter to OPF re ISA WG proposal In-Reply-To: References: Message-ID: ok am done writing, any thoughts? the key thing to get across is that we're not exactly fitting expectations but qualify with the "intent" if you know what i mean. l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From programmerjake at gmail.com Fri Mar 26 20:12:22 2021 From: programmerjake at gmail.com (Jacob Lifshay) Date: Fri, 26 Mar 2021 13:12:22 -0700 Subject: [Libre-soc-dev] draft letter to OPF re ISA WG proposal In-Reply-To: References: Message-ID: On Fri, Mar 26, 2021, 13:02 Luke Kenneth Casson Leighton wrote: > ok am done writing, any thoughts? the key thing to get across is that we're > not exactly fitting expectations but qualify with the "intent" if you know > what i mean. > looks good, though if possible I (and probably others) would like to participate in said conference call (or other communication), though probably mostly just to listen. Jacob From lkcl at lkcl.net Fri Mar 26 21:39:49 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 26 Mar 2021 21:39:49 +0000 Subject: [Libre-soc-dev] draft letter to OPF re ISA WG proposal In-Reply-To: References: Message-ID: On Friday, March 26, 2021, Jacob Lifshay wrote: > > looks good, though if possible I (and probably others) would like to > participate in said conference call (or other communication), though > probably mostly just to listen. i was thinking along the lines of inviting them to one of the biweekly jitsi meetings. it'll be fun. chais, but fun :) l. > Jacob > _______________________________________________ > Libre-soc-dev mailing list > Libre-soc-dev at lists.libre-soc.org > http://lists.libre-soc.org/mailman/listinfo/libre-soc-dev > -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From programmerjake at gmail.com Fri Mar 26 22:21:30 2021 From: programmerjake at gmail.com (Jacob Lifshay) Date: Fri, 26 Mar 2021 15:21:30 -0700 Subject: [Libre-soc-dev] draft letter to OPF re ISA WG proposal In-Reply-To: References: Message-ID: On Fri, Mar 26, 2021, 14:40 Luke Kenneth Casson Leighton wrote: > On Friday, March 26, 2021, Jacob Lifshay wrote: > > > > > looks good, though if possible I (and probably others) would like to > > participate in said conference call (or other communication), though > > probably mostly just to listen. > > > i was thinking along the lines of inviting them to one of the biweekly > jitsi meetings. > sounds good! (hopefully the jitsi app has fixed my keyboard issues by then, though if I remember I may use my desktop instead) Jacob From lkcl at lkcl.net Sun Mar 28 13:30:01 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 28 Mar 2021 12:30:01 +0000 Subject: [Libre-soc-dev] fighting litex and yosys for pin mapping Message-ID: i've spent the past week dealing with litex and yosys to get the JTAG boundary scan connected up. litex provides absolutely no help whatsoever in determining the direction of wires: it is purely a naive "generator of verilog by outputting text fragments that happen to be in verilog". ordinarily, yosys would be useful to help determine whether those directions are correct... except that there are also *bugs in yosys* which leave it unable in all cases to correctly determine port direction. so it's been 4 days to track down the problem (hidden by another problem that had to be tracked down) followed by 3 days iterating solutions. i've finally got something that might be correct. l. --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From lkcl at lkcl.net Sun Mar 28 16:49:30 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 28 Mar 2021 15:49:30 +0000 Subject: [Libre-soc-dev] fighting litex and yosys for pin mapping In-Reply-To: References: Message-ID: PLEASE NOTE - to get the gate count down for the ls180 tape-out i've had to make some rather invasive changes to the size of the SPR regfile. as that is driven by an enum (used to be Enum SPR) covered by SPRMap (which converts from OpenPOWER9 SPR numbers to internal) that had to be changed to a *compile-time-selectable* Enum. in theory this should not cause problems (not be noticed), i've re-run the full test_issuer.py unit test and it's fine. l. On Sun, Mar 28, 2021 at 1:30 PM Luke Kenneth Casson Leighton wrote: > i've spent the past week dealing with litex and yosys to get the JTAG > boundary scan connected up. > > litex provides absolutely no help whatsoever in determining the direction > of wires: it is purely a naive "generator of verilog by outputting text > fragments that happen to be in verilog". > > ordinarily, yosys would be useful to help determine whether those > directions are correct... except that there are also *bugs in yosys* which > leave it unable in all cases to correctly determine port direction. > > so it's been 4 days to track down the problem (hidden by another problem > that had to be tracked down) followed by 3 days iterating solutions. > > i've finally got something that might be correct. > > l. > > --- > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 > From lkcl at lkcl.net Sun Mar 28 19:13:51 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 28 Mar 2021 18:13:51 +0000 Subject: [Libre-soc-dev] fighting litex and yosys for pin mapping In-Reply-To: References: Message-ID: On Sunday, March 28, 2021, Luke Kenneth Casson Leighton wrote: > > in theory this should not cause problems (not be noticed), i've re-run the > full test_issuer.py unit test and it's fine. > the coriolis2 layout also completes, and is about appx 10% smaller. hopefully this will be enough to get it into the available space. l. From umbertocerrato at outlook.it Sun Mar 28 19:31:58 2021 From: umbertocerrato at outlook.it (Umberto Cerrato) Date: Sun, 28 Mar 2021 18:31:58 +0000 Subject: [Libre-soc-dev] git guide Message-ID: Hello everybody, Luke suggested me I could write some documentation for the libre-soc website about git usage. What do you think about it? PS: Lkcl: about the .DS_Store files, I should have removed them. From lkcl at lkcl.net Sun Mar 28 19:37:38 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 28 Mar 2021 18:37:38 +0000 Subject: [Libre-soc-dev] git guide In-Reply-To: References: Message-ID: On Sunday, March 28, 2021, Umberto Cerrato wrote: > Hello everybody, > > Luke suggested me I could write some documentation for the libre-soc > website about git usage. https://libre-soc.org/HDL_workflow/git_checklist/ something that is, "if you want to do X, then run commands Y Z and W" with some explanation underneath. What do you think about it? > > PS: > Lkcl: about the .DS_Store files, I should have removed them. star. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From umbertocerrato at outlook.it Sun Mar 28 20:29:20 2021 From: umbertocerrato at outlook.it (Umberto Cerrato) Date: Sun, 28 Mar 2021 19:29:20 +0000 Subject: [Libre-soc-dev] git guide In-Reply-To: References: Message-ID: <8A628F4B-CFBE-413F-B47F-C5A4ACB9EDE4@outlook.it> I wrote something in the page. Anyway I think I do not like very much the way the template render the markdown. Is it only me? I find it difficult to read the text. > Il giorno 28 mar 2021, alle ore 20:37, Luke Kenneth Casson Leighton ha scritto: > > On Sunday, March 28, 2021, Umberto Cerrato > wrote: > >> Hello everybody, >> >> Luke suggested me I could write some documentation for the libre-soc >> website about git usage. > > > https://libre-soc.org/HDL_workflow/git_checklist/ > > something that is, "if you want to do X, then run commands Y Z and W" > > with some explanation underneath. > > > What do you think about it? >> >> PS: >> Lkcl: about the .DS_Store files, I should have removed them. > > > star. > > > > -- > --- > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 > _______________________________________________ > Libre-soc-dev mailing list > Libre-soc-dev at lists.libre-soc.org > http://lists.libre-soc.org/mailman/listinfo/libre-soc-dev From umbertocerrato at outlook.it Sun Mar 28 20:36:00 2021 From: umbertocerrato at outlook.it (Umberto Cerrato) Date: Sun, 28 Mar 2021 19:36:00 +0000 Subject: [Libre-soc-dev] git guide In-Reply-To: <8A628F4B-CFBE-413F-B47F-C5A4ACB9EDE4@outlook.it> References: <8A628F4B-CFBE-413F-B47F-C5A4ACB9EDE4@outlook.it> Message-ID: <64013EEA-405C-4CAB-B5C0-CBD1178E59C7@outlook.it> Never mind anyway :) > Il giorno 28 mar 2021, alle ore 21:29, Umberto Cerrato ha scritto: > > I wrote something in the page. > > Anyway I think I do not like very much the way the template render the markdown. Is it only me? I find it difficult to read the text. > >> Il giorno 28 mar 2021, alle ore 20:37, Luke Kenneth Casson Leighton ha scritto: >> >> On Sunday, March 28, 2021, Umberto Cerrato >> wrote: >> >>> Hello everybody, >>> >>> Luke suggested me I could write some documentation for the libre-soc >>> website about git usage. >> >> >> https://libre-soc.org/HDL_workflow/git_checklist/ >> >> something that is, "if you want to do X, then run commands Y Z and W" >> >> with some explanation underneath. >> >> >> What do you think about it? >>> >>> PS: >>> Lkcl: about the .DS_Store files, I should have removed them. >> >> >> star. >> >> >> >> -- >> --- >> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 >> _______________________________________________ >> Libre-soc-dev mailing list >> Libre-soc-dev at lists.libre-soc.org >> http://lists.libre-soc.org/mailman/listinfo/libre-soc-dev > > > _______________________________________________ > Libre-soc-dev mailing list > Libre-soc-dev at lists.libre-soc.org > http://lists.libre-soc.org/mailman/listinfo/libre-soc-dev From lkcl at lkcl.net Sun Mar 28 20:41:50 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 28 Mar 2021 19:41:50 +0000 Subject: [Libre-soc-dev] git guide In-Reply-To: <8A628F4B-CFBE-413F-B47F-C5A4ACB9EDE4@outlook.it> References: <8A628F4B-CFBE-413F-B47F-C5A4ACB9EDE4@outlook.it> Message-ID: On Sunday, March 28, 2021, Umberto Cerrato wrote: > I wrote something in the page. good start. Like "I added the test.png file". ahh no :) "added this file, deleted that file", these things can all be seen with "git diff" so there is no need to put that in the git message the git message is for WHY you did what you did. not what ACTION was done on what file. > Anyway I think I do not like very much the way the template render the > markdown. Is it only me? I find it difficult to read the text. you get used to it. it is deliberately designed not to be "fancy". this is invariably how wikis are. if you have ideas for improving the css do try thrm out locally. l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From umbertocerrato at outlook.it Sun Mar 28 21:07:00 2021 From: umbertocerrato at outlook.it (Umberto Cerrato) Date: Sun, 28 Mar 2021 20:07:00 +0000 Subject: [Libre-soc-dev] git guide In-Reply-To: References: <8A628F4B-CFBE-413F-B47F-C5A4ACB9EDE4@outlook.it> Message-ID: <6D06D5F5-427F-4395-A7DF-6E085F3719E5@outlook.it> > Il giorno 28 mar 2021, alle ore 21:41, Luke Kenneth Casson Leighton ha scritto: > > On Sunday, March 28, 2021, Umberto Cerrato > wrote: > >> I wrote something in the page. > > > good start. > > Like "I added the test.png file". > > ahh no :) xD > > "added this file, deleted that file", these things can all be seen with > "git diff" so there is no need to put that in the git message > > the git message is for WHY you did what you did. > > not what ACTION was done on what file. Good, I am going to update it. > > > >> Anyway I think I do not like very much the way the template render the >> markdown. Is it only me? I find it difficult to read the text. > > > you get used to it. > > it is deliberately designed not to be "fancy". this is invariably how > wikis are. I like it not being fancy. I do not very much like the difference between headers and paragraphs font sizes. Too much imo, specially for few words pages like the git one f.e. > > if you have ideas for improving the css do try thrm out locally. Yes. Do you mean from the browser or from the local repo? Anyway, where css files are stored? (I would like to make a change that does not affect the actual look of the website) > > l. > > > > > -- > --- > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 > _______________________________________________ > Libre-soc-dev mailing list > Libre-soc-dev at lists.libre-soc.org > http://lists.libre-soc.org/mailman/listinfo/libre-soc-dev From lkcl at lkcl.net Sun Mar 28 21:09:09 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 28 Mar 2021 20:09:09 +0000 Subject: [Libre-soc-dev] git guide In-Reply-To: References: <8A628F4B-CFBE-413F-B47F-C5A4ACB9EDE4@outlook.it> Message-ID: https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=edf0ccb2dffb43adadf9f78d3881a2e5cf1ffee6 i mean, "in your local browser, enable developer mode and either redirect local.css or edit the DOM in your local browser and test changes there" if you want to do extensive local modifications and tests you can install ikiwiki locally on your own machine and test things there. l. On Sunday, March 28, 2021, Luke Kenneth Casson Leighton wrote: > > > On Sunday, March 28, 2021, Umberto Cerrato > wrote: > >> I wrote something in the page. > > > good start. > > Like "I added the test.png file". > > ahh no :) > > "added this file, deleted that file", these things can all be seen with > "git diff" so there is no need to put that in the git message > > the git message is for WHY you did what you did. > > not what ACTION was done on what file. > > > >> Anyway I think I do not like very much the way the template render the >> markdown. Is it only me? I find it difficult to read the text. > > > you get used to it. > > it is deliberately designed not to be "fancy". this is invariably how > wikis are. > > if you have ideas for improving the css do try thrm out locally. > > l. > > > > > -- > --- > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 > > -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From umbertocerrato at outlook.it Sun Mar 28 21:14:39 2021 From: umbertocerrato at outlook.it (Umberto Cerrato) Date: Sun, 28 Mar 2021 20:14:39 +0000 Subject: [Libre-soc-dev] git guide In-Reply-To: References: <8A628F4B-CFBE-413F-B47F-C5A4ACB9EDE4@outlook.it> Message-ID: <6B1AE5CD-1EFC-4187-BD14-A5B220F02655@outlook.it> Yes > Il giorno 28 mar 2021, alle ore 22:09, Luke Kenneth Casson Leighton ha scritto: > > https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=edf0ccb2dffb43adadf9f78d3881a2e5cf1ffee6 > > i mean, "in your local browser, enable developer mode and either redirect > local.css or edit the DOM in your local browser and test changes there" > > if you want to do extensive local modifications and tests you can install > ikiwiki locally on your own machine and test things there. > > l. > > > > On Sunday, March 28, 2021, Luke Kenneth Casson Leighton > wrote: > >> >> >> On Sunday, March 28, 2021, Umberto Cerrato >> wrote: >> >>> I wrote something in the page. >> >> >> good start. >> >> Like "I added the test.png file". >> >> ahh no :) >> >> "added this file, deleted that file", these things can all be seen with >> "git diff" so there is no need to put that in the git message >> >> the git message is for WHY you did what you did. >> >> not what ACTION was done on what file. >> >> >> >>> Anyway I think I do not like very much the way the template render the >>> markdown. Is it only me? I find it difficult to read the text. >> >> >> you get used to it. >> >> it is deliberately designed not to be "fancy". this is invariably how >> wikis are. >> >> if you have ideas for improving the css do try thrm out locally. >> >> l. >> >> >> >> >> -- >> --- >> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 >> >> > > -- > --- > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 > _______________________________________________ > Libre-soc-dev mailing list > Libre-soc-dev at lists.libre-soc.org > http://lists.libre-soc.org/mailman/listinfo/libre-soc-dev From umbertocerrato at outlook.it Sun Mar 28 22:15:51 2021 From: umbertocerrato at outlook.it (Umberto Cerrato) Date: Sun, 28 Mar 2021 21:15:51 +0000 Subject: [Libre-soc-dev] TOC to the HDL workflow doc page Message-ID: <9EBBEF63-301E-472B-B37A-DEB23C6EDF02@outlook.it> May I add a short auto generated t.o.c. to the HDL workflow page in the website? From lkcl at lkcl.net Sun Mar 28 23:24:43 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Sun, 28 Mar 2021 22:24:43 +0000 Subject: [Libre-soc-dev] TOC to the HDL workflow doc page In-Reply-To: <9EBBEF63-301E-472B-B37A-DEB23C6EDF02@outlook.it> References: <9EBBEF63-301E-472B-B37A-DEB23C6EDF02@outlook.it> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Sun, Mar 28, 2021 at 10:15 PM Umberto Cerrato wrote: > May I add a short auto generated t.o.c. to the HDL workflow page in the > website? > by putting [[!toc]] or [[!toc level=2]] at an appropriate point in the page.... yes of course. by manually typing it out? don't do that :) l. From umbertocerrato at outlook.it Sun Mar 28 23:25:54 2021 From: umbertocerrato at outlook.it (Umberto Cerrato) Date: Sun, 28 Mar 2021 22:25:54 +0000 Subject: [Libre-soc-dev] TOC to the HDL workflow doc page In-Reply-To: References: <9EBBEF63-301E-472B-B37A-DEB23C6EDF02@outlook.it> Message-ID: > Il giorno 29 mar 2021, alle ore 00:24, Luke Kenneth Casson Leighton ha scritto: > > --- > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 > > > On Sun, Mar 28, 2021 at 10:15 PM Umberto Cerrato > wrote: > >> May I add a short auto generated t.o.c. to the HDL workflow page in the >> website? >> > > by putting [[!toc]] or [[!toc level=2]] at an appropriate point in the > page.... yes of course. Yes > > by manually typing it out? don't do that :) > > l. > _______________________________________________ > Libre-soc-dev mailing list > Libre-soc-dev at lists.libre-soc.org > http://lists.libre-soc.org/mailman/listinfo/libre-soc-dev From umbertocerrato at outlook.it Mon Mar 29 09:17:33 2021 From: umbertocerrato at outlook.it (Umberto Cerrato) Date: Mon, 29 Mar 2021 08:17:33 +0000 Subject: [Libre-soc-dev] Logic2 Message-ID: <3D339A24-D73E-49DE-9B30-27CC9761CB03@outlook.it> Few months ago, when I was searching for a program to simulate circuits and stuff, I found this https://github.com/dkilfoyle/logic2 IDK if I can be helpful. I think it is very powerful in a way. Best From lkcl at lkcl.net Mon Mar 29 09:29:07 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 29 Mar 2021 08:29:07 +0000 Subject: [Libre-soc-dev] Logic2 In-Reply-To: <3D339A24-D73E-49DE-9B30-27CC9761CB03@outlook.it> References: <3D339A24-D73E-49DE-9B30-27CC9761CB03@outlook.it> Message-ID: On Mon, Mar 29, 2021 at 9:17 AM Umberto Cerrato wrote: > Few months ago, when I was searching for a program to simulate circuits > and stuff, I found this https://github.com/dkilfoyle/logic2 > IDK if I can be helpful. I think it is very powerful in a way. > excellent - it would be good to add to the resources page (if it's not already there). the page is quite long, search for circuitjs. https://libre-soc.org/resources/ l. From lkcl at lkcl.net Mon Mar 29 10:56:30 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 29 Mar 2021 09:56:30 +0000 Subject: [Libre-soc-dev] git guide In-Reply-To: <6B1AE5CD-1EFC-4187-BD14-A5B220F02655@outlook.it> References: <8A628F4B-CFBE-413F-B47F-C5A4ACB9EDE4@outlook.it> <6B1AE5CD-1EFC-4187-BD14-A5B220F02655@outlook.it> Message-ID: ok, so the picture i had in my mind for the git guide is: # what to do if you want to modify some pages here is the checklist for making changes. if you do not intend to complete the work right the way through to "git push" immediately (at least by end of day), or do not "have time", reconsider and find a way to make the work smaller. if unsure, ask on the mailing list. * run "git pull" * edit files, making sure only one "purpose" * save them * run unit tests and make sure they pass * fix errors * run "git status | more", review the output * run "git diff", review the output * run "git commit -a -m 'useful description' " * run "git pull" * run "git push" now an explanation of those. # what to do if "git pull" results in conflict ... .... # what to do if you want to add files. ... this one, "git status" is very important, to check files that should have been added but have not etc etc etc. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From umbertocerrato at outlook.it Mon Mar 29 11:42:01 2021 From: umbertocerrato at outlook.it (Umberto Cerrato) Date: Mon, 29 Mar 2021 10:42:01 +0000 Subject: [Libre-soc-dev] Logic2 In-Reply-To: References: <3D339A24-D73E-49DE-9B30-27CC9761CB03@outlook.it> Message-ID: <88C2925D-86F8-4403-B8B6-76D6923005F1@outlook.it> Done > Il giorno 29 mar 2021, alle ore 10:29, Luke Kenneth Casson Leighton ha scritto: > > On Mon, Mar 29, 2021 at 9:17 AM Umberto Cerrato > wrote: > >> Few months ago, when I was searching for a program to simulate circuits >> and stuff, I found this https://github.com/dkilfoyle/logic2 >> IDK if I can be helpful. I think it is very powerful in a way. >> > > excellent - it would be good to add to the resources page (if it's not > already there). the page is quite long, search for circuitjs. > > https://libre-soc.org/resources/ > > l. > _______________________________________________ > Libre-soc-dev mailing list > Libre-soc-dev at lists.libre-soc.org > http://lists.libre-soc.org/mailman/listinfo/libre-soc-dev From umbertocerrato at outlook.it Mon Mar 29 11:44:26 2021 From: umbertocerrato at outlook.it (Umberto Cerrato) Date: Mon, 29 Mar 2021 10:44:26 +0000 Subject: [Libre-soc-dev] Logic2 In-Reply-To: <88C2925D-86F8-4403-B8B6-76D6923005F1@outlook.it> References: <3D339A24-D73E-49DE-9B30-27CC9761CB03@outlook.it> <88C2925D-86F8-4403-B8B6-76D6923005F1@outlook.it> Message-ID: <80F5AA2B-8B02-4158-99D4-2543493E5C21@outlook.it> I couldn’t write anything more because I really do not know what the thing is supposed to do. I see you compose the component in the editor and the program generates the schematics and the simulation on the right sidebar. > Il giorno 29 mar 2021, alle ore 12:42, Umberto Cerrato ha scritto: > > Done > >> Il giorno 29 mar 2021, alle ore 10:29, Luke Kenneth Casson Leighton ha scritto: >> >> On Mon, Mar 29, 2021 at 9:17 AM Umberto Cerrato >> wrote: >> >>> Few months ago, when I was searching for a program to simulate circuits >>> and stuff, I found this https://github.com/dkilfoyle/logic2 >>> IDK if I can be helpful. I think it is very powerful in a way. >>> >> >> excellent - it would be good to add to the resources page (if it's not >> already there). the page is quite long, search for circuitjs. >> >> https://libre-soc.org/resources/ >> >> l. >> _______________________________________________ >> Libre-soc-dev mailing list >> Libre-soc-dev at lists.libre-soc.org >> http://lists.libre-soc.org/mailman/listinfo/libre-soc-dev > > > _______________________________________________ > Libre-soc-dev mailing list > Libre-soc-dev at lists.libre-soc.org > http://lists.libre-soc.org/mailman/listinfo/libre-soc-dev From umbertocerrato at outlook.it Mon Mar 29 11:55:49 2021 From: umbertocerrato at outlook.it (Umberto Cerrato) Date: Mon, 29 Mar 2021 10:55:49 +0000 Subject: [Libre-soc-dev] git guide In-Reply-To: References: <8A628F4B-CFBE-413F-B47F-C5A4ACB9EDE4@outlook.it> <6B1AE5CD-1EFC-4187-BD14-A5B220F02655@outlook.it> Message-ID: <11BA7273-86C7-405C-9715-F75443F0DD95@outlook.it> > Il giorno 29 mar 2021, alle ore 11:56, Luke Kenneth Casson Leighton ha scritto: > > ok, so the picture i had in my mind for the git guide is: > > # what to do if you want to modify some pages “Pages”? Shouldn’t this be useful for the entire workflow? > > here is the checklist for making changes. if you do not intend to complete > the work right the way through to "git push" immediately (at least by end > of day), or do not "have time", reconsider and find a way to make the work > smaller. if unsure, ask on the mailing list. > > * run "git pull" > * edit files, making sure only one “purpose" I think I understand what you mean here, but I would like a bit deeper explanation. > * save them > * run unit tests and make sure they pass > * fix errors > * run "git status | more", review the output I think that is the vertical bar character, right? > * run "git diff", review the output > * run "git commit -a -m 'useful description' " > * run "git pull" > * run "git push" > > now an explanation of those. > > # what to do if "git pull" results in conflict > I do not know sincerely. > ... > .... > > # what to do if you want to add files. > > … Neither this… “git add “ ? > > this one, "git status" is very important, to check files that should have > been added but have not > > > etc etc etc. > > I will start embedding this in the page. > > -- > --- > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 > _______________________________________________ > Libre-soc-dev mailing list > Libre-soc-dev at lists.libre-soc.org > http://lists.libre-soc.org/mailman/listinfo/libre-soc-dev From umbertocerrato at outlook.it Mon Mar 29 11:59:07 2021 From: umbertocerrato at outlook.it (Umberto Cerrato) Date: Mon, 29 Mar 2021 10:59:07 +0000 Subject: [Libre-soc-dev] Website clarity Message-ID: <45F0C6E6-655E-4EFC-9055-52D899E508F0@outlook.it> I find the website not very easy to navigate. (I often jump from a page to another to find stuff.) May I think of a way to solve this? From lkcl at lkcl.net Mon Mar 29 12:24:08 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 29 Mar 2021 11:24:08 +0000 Subject: [Libre-soc-dev] Logic2 In-Reply-To: <80F5AA2B-8B02-4158-99D4-2543493E5C21@outlook.it> References: <3D339A24-D73E-49DE-9B30-27CC9761CB03@outlook.it> <88C2925D-86F8-4403-B8B6-76D6923005F1@outlook.it> <80F5AA2B-8B02-4158-99D4-2543493E5C21@outlook.it> Message-ID: On Monday, March 29, 2021, Umberto Cerrato wrote: > I couldn’t write anything more because I really do not know what the thing > is supposed to do. I see you compose the component in the editor and the > program generates the schematics and the simulation on the right sidebar. it's good to have, and evaluate. l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From lkcl at lkcl.net Mon Mar 29 12:33:44 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 29 Mar 2021 11:33:44 +0000 Subject: [Libre-soc-dev] Website clarity In-Reply-To: <45F0C6E6-655E-4EFC-9055-52D899E508F0@outlook.it> References: <45F0C6E6-655E-4EFC-9055-52D899E508F0@outlook.it> Message-ID: On Monday, March 29, 2021, Umberto Cerrato wrote: > I find the website not very easy to navigate. (I often jump from a page to > another to find stuff.) it is actually not designed to be "navigated". it is designed to kep notes, and information, as an aide to developers. look at this page for example: https://libre-soc.org/openpower/sv/implementation/ see how it cross-references progress across multiple completely separate projects? an how it lists the bugs associated with each? now go to one of those bugs. how about this one https://bugs.libre-soc.org/show_bug.cgi?id=583 see the URL, how it links back to the page? then, in the actual code, is cross-references to bugs and to wiki pages. so this is how and what the wiki is for. it is to provide context and links to documentation and working knowledge. > May I think of a way to solve this? sure. remember there is "sitemap". also remember, you cannot move or rename pages without a massive review because of the extensive crossreferencing. l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From lkcl at lkcl.net Mon Mar 29 12:37:45 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 29 Mar 2021 11:37:45 +0000 Subject: [Libre-soc-dev] git guide In-Reply-To: <11BA7273-86C7-405C-9715-F75443F0DD95@outlook.it> References: <8A628F4B-CFBE-413F-B47F-C5A4ACB9EDE4@outlook.it> <6B1AE5CD-1EFC-4187-BD14-A5B220F02655@outlook.it> <11BA7273-86C7-405C-9715-F75443F0DD95@outlook.it> Message-ID: On Monday, March 29, 2021, Umberto Cerrato wrote: > > > # what to do if "git pull" results in conflict > > > > I do not know sincerely. then what would you do? if you didn't know, what would you do? > ... > > .... > > > > # what to do if you want to add files. > > > > … > > Neither this… “git add “ ? this is why i asked you to write this page, because "just git add" caused you to add binary files to the repository. plus, only "git add", the file will sit there in working tree, won't it? you need the *full* series of commands, as the checklist. l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From umbertocerrato at outlook.it Mon Mar 29 12:57:04 2021 From: umbertocerrato at outlook.it (Umberto Cerrato) Date: Mon, 29 Mar 2021 11:57:04 +0000 Subject: [Libre-soc-dev] Website clarity In-Reply-To: References: <45F0C6E6-655E-4EFC-9055-52D899E508F0@outlook.it> Message-ID: > Il giorno 29 mar 2021, alle ore 13:33, Luke Kenneth Casson Leighton ha scritto: > > On Monday, March 29, 2021, Umberto Cerrato > wrote: > >> I find the website not very easy to navigate. (I often jump from a page to >> another to find stuff.) > > > it is actually not designed to be "navigated". it is designed to kep > notes, and information, as an aide to developers. > > look at this page for example: > https://libre-soc.org/openpower/sv/implementation/ > > see how it cross-references progress across multiple completely separate > projects? an how it lists the bugs associated with each? > > now go to one of those bugs. how about this one > https://bugs.libre-soc.org/show_bug.cgi?id=583 > > see the URL, how it links back to the page? Yes > > then, in the actual code, is cross-references to bugs and to wiki pages. > > so this is how and what the wiki is for. it is to provide context and links > to documentation and working knowledge. > > >> May I think of a way to solve this? > > > sure. > > remember there is "sitemap”. > > also remember, you cannot move or rename pages without a massive review > because of the extensive crossreferencing. o.o (I will move nothing) > > l. > > > > -- > --- > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 > _______________________________________________ > Libre-soc-dev mailing list > Libre-soc-dev at lists.libre-soc.org > http://lists.libre-soc.org/mailman/listinfo/libre-soc-dev From lkcl at lkcl.net Mon Mar 29 13:09:38 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 29 Mar 2021 12:09:38 +0000 Subject: [Libre-soc-dev] Website clarity In-Reply-To: References: <45F0C6E6-655E-4EFC-9055-52D899E508F0@outlook.it> Message-ID: On Mon, Mar 29, 2021 at 12:57 PM Umberto Cerrato wrote: > > o.o (I will move nothing) > > basically what you are doing is very useful precisely because you are not familiar. you might find this useful: https://ikiwiki.info/plugins/map/ it can list pages by tags as well. look for "standards" tag: lkcl at fizzy:~/src/libresoc/libresoc/openpower$ grep standards * sv.mdwn:[[!tag standards]] then, see this page: https://libre-soc.org/standards/ so there are tools to automate navigation. l. From umbertocerrato at outlook.it Mon Mar 29 15:59:52 2021 From: umbertocerrato at outlook.it (Umberto Cerrato) Date: Mon, 29 Mar 2021 14:59:52 +0000 Subject: [Libre-soc-dev] git guide In-Reply-To: References: <8A628F4B-CFBE-413F-B47F-C5A4ACB9EDE4@outlook.it> <6B1AE5CD-1EFC-4187-BD14-A5B220F02655@outlook.it> <11BA7273-86C7-405C-9715-F75443F0DD95@outlook.it> Message-ID: <96F42160-EA16-4635-A0DC-13195E3E5564@outlook.it> > Il giorno 29 mar 2021, alle ore 13:37, Luke Kenneth Casson Leighton ha scritto: > > On Monday, March 29, 2021, Umberto Cerrato > wrote: > >> >>> # what to do if "git pull" results in conflict >>> >> >> I do not know sincerely. > > > then what would you do? if you didn't know, what would you do? Usually when something happens, I do a search on the web. It didn’t happen yet to have been stuck there. (I did check other things though in these two days) > > >> ... >>> .... >>> >>> # what to do if you want to add files. >>> >>> … >> >> Neither this… “git add “ ? > > > this is why i asked you to write this page, because "just git add" caused > you to add binary files to the repository. > > plus, only "git add", the file will sit there in working tree, won't it? > > you need the *full* series of commands, as the checklist. > > l. > > > > -- > --- > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 > _______________________________________________ > Libre-soc-dev mailing list > Libre-soc-dev at lists.libre-soc.org > http://lists.libre-soc.org/mailman/listinfo/libre-soc-dev From lkcl at lkcl.net Mon Mar 29 16:06:03 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 29 Mar 2021 15:06:03 +0000 Subject: [Libre-soc-dev] git guide In-Reply-To: <96F42160-EA16-4635-A0DC-13195E3E5564@outlook.it> References: <8A628F4B-CFBE-413F-B47F-C5A4ACB9EDE4@outlook.it> <6B1AE5CD-1EFC-4187-BD14-A5B220F02655@outlook.it> <11BA7273-86C7-405C-9715-F75443F0DD95@outlook.it> <96F42160-EA16-4635-A0DC-13195E3E5564@outlook.it> Message-ID: On Mon, Mar 29, 2021 at 3:59 PM Umberto Cerrato wrote: > Usually when something happens, I do a search on the web. > It didn’t happen yet to have been stuck there. > (I did check other things though in these two days) > and the other thing would be: contact the mailing list :) so, the advice that needs to go on the page? * put a link to a good git conflict tutorial * put "if you are unsure what to do please ask for advice on IRC or the mailing list" :) l. From umbertocerrato at outlook.it Mon Mar 29 16:11:27 2021 From: umbertocerrato at outlook.it (Umberto Cerrato) Date: Mon, 29 Mar 2021 15:11:27 +0000 Subject: [Libre-soc-dev] git guide In-Reply-To: References: <8A628F4B-CFBE-413F-B47F-C5A4ACB9EDE4@outlook.it> <6B1AE5CD-1EFC-4187-BD14-A5B220F02655@outlook.it> <11BA7273-86C7-405C-9715-F75443F0DD95@outlook.it> <96F42160-EA16-4635-A0DC-13195E3E5564@outlook.it> Message-ID: <9550D860-119E-4BE8-9D41-AA647B28FCFA@outlook.it> Nice, will do. > Il giorno 29 mar 2021, alle ore 17:06, Luke Kenneth Casson Leighton ha scritto: > > On Mon, Mar 29, 2021 at 3:59 PM Umberto Cerrato > wrote: > > >> Usually when something happens, I do a search on the web. >> It didn’t happen yet to have been stuck there. >> (I did check other things though in these two days) >> > > and the other thing would be: contact the mailing list :) > > so, the advice that needs to go on the page? > > * put a link to a good git conflict tutorial > * put "if you are unsure what to do please ask for advice on IRC or the > mailing list" > > :) > > l. > _______________________________________________ > Libre-soc-dev mailing list > Libre-soc-dev at lists.libre-soc.org > http://lists.libre-soc.org/mailman/listinfo/libre-soc-dev From libre-soc at platen-software.de Mon Mar 29 19:58:37 2021 From: libre-soc at platen-software.de (Tobias Platen) Date: Mon, 29 Mar 2021 20:58:37 +0200 Subject: [Libre-soc-dev] daily kan-ban update 29mar2021 Message-ID: <20210329205837.bb2b54712a55e8a7d870f9b6@platen-software.de> having a look at SEGMENT_CHECK before RADIX_LOOKUP in both microwatt source code and PowerISA_public.v3.0B.pdf -- Tobias Platen From lkcl at lkcl.net Mon Mar 29 20:09:34 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 29 Mar 2021 19:09:34 +0000 Subject: [Libre-soc-dev] daily kan-ban update 29mar2021 In-Reply-To: <20210329205837.bb2b54712a55e8a7d870f9b6@platen-software.de> References: <20210329205837.bb2b54712a55e8a7d870f9b6@platen-software.de> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Mon, Mar 29, 2021 at 7:58 PM Tobias Platen wrote: > > having a look at SEGMENT_CHECK before RADIX_LOOKUP in both > microwatt source code and PowerISA_public.v3.0B.pdf doesn't look like gem5 radixwalk.cc does that segment check. https://github.com/power-gem5/gem5/blob/gem5-experimental/src/arch/power/radixwalk.cc btw there's an off-by-one (do git pull) l. From libre-soc at platen-software.de Mon Mar 29 20:21:43 2021 From: libre-soc at platen-software.de (Tobias Platen) Date: Mon, 29 Mar 2021 21:21:43 +0200 Subject: [Libre-soc-dev] daily kan-ban update 29mar2021 In-Reply-To: References: <20210329205837.bb2b54712a55e8a7d870f9b6@platen-software.de> Message-ID: <20210329212143.279f1cdd3df982171cbc33b3@platen-software.de> On Mon, 29 Mar 2021 19:09:34 +0000 Luke Kenneth Casson Leighton wrote: > --- > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 > > On Mon, Mar 29, 2021 at 7:58 PM Tobias Platen > wrote: > > > > having a look at SEGMENT_CHECK before RADIX_LOOKUP in both > > microwatt source code and PowerISA_public.v3.0B.pdf > > doesn't look like gem5 radixwalk.cc does that segment check. > https://github.com/power-gem5/gem5/blob/gem5-experimental/src/arch/power/radixwalk.cc > > btw there's an off-by-one (do git pull) > > l. > > _______________________________________________ > Libre-soc-dev mailing list > Libre-soc-dev at lists.libre-soc.org > http://lists.libre-soc.org/mailman/listinfo/libre-soc-dev I did the git pull, and now I'm trying to find the segment check in PowerISA_public.v3.0B.pdf. Until now I did not find something that matches the microwatt implementation. -- Tobias Platen From lkcl at lkcl.net Mon Mar 29 20:28:17 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 29 Mar 2021 19:28:17 +0000 Subject: [Libre-soc-dev] daily kan-ban update 29mar2021 In-Reply-To: <20210329212143.279f1cdd3df982171cbc33b3@platen-software.de> References: <20210329205837.bb2b54712a55e8a7d870f9b6@platen-software.de> <20210329212143.279f1cdd3df982171cbc33b3@platen-software.de> Message-ID: On Mon, Mar 29, 2021 at 8:21 PM Tobias Platen wrote: > I did the git pull, and now I'm trying to find the segment check > in PowerISA_public.v3.0B.pdf. Until now I did not find something > that matches the microwatt implementation. just call it. the reason is that Paul and the team know what they are doing. and send a question to openpower-hdl-cores to ask. l. From libre-soc at platen-software.de Mon Mar 29 20:32:01 2021 From: libre-soc at platen-software.de (Tobias Platen) Date: Mon, 29 Mar 2021 21:32:01 +0200 Subject: [Libre-soc-dev] daily kan-ban update 29mar2021 In-Reply-To: <20210329212143.279f1cdd3df982171cbc33b3@platen-software.de> References: <20210329205837.bb2b54712a55e8a7d870f9b6@platen-software.de> <20210329212143.279f1cdd3df982171cbc33b3@platen-software.de> Message-ID: <20210329213201.70e4fc0562525ada12bd0b58@platen-software.de> On Mon, 29 Mar 2021 21:21:43 +0200 Tobias Platen wrote: > On Mon, 29 Mar 2021 19:09:34 +0000 > Luke Kenneth Casson Leighton wrote: > > > --- > > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 > > > > On Mon, Mar 29, 2021 at 7:58 PM Tobias Platen > > wrote: > > > > > > having a look at SEGMENT_CHECK before RADIX_LOOKUP in both > > > microwatt source code and PowerISA_public.v3.0B.pdf > > > > doesn't look like gem5 radixwalk.cc does that segment check. > > https://github.com/power-gem5/gem5/blob/gem5-experimental/src/arch/power/radixwalk.cc > > > > btw there's an off-by-one (do git pull) > > > > l. > > > > _______________________________________________ > > Libre-soc-dev mailing list > > Libre-soc-dev at lists.libre-soc.org > > http://lists.libre-soc.org/mailman/listinfo/libre-soc-dev > I did the git pull, and now I'm trying to find the segment check > in PowerISA_public.v3.0B.pdf. Until now I did not find something > that matches the microwatt implementation. > > -- > Tobias Platen > > _______________________________________________ > Libre-soc-dev mailing list > Libre-soc-dev at lists.libre-soc.org > http://lists.libre-soc.org/mailman/listinfo/libre-soc-dev I've found some the location which I was looking for: 5.7.6.1 Partition Table 5.7.6.2 Process Table -- Tobias Platen From lkcl at lkcl.net Mon Mar 29 20:35:07 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Mon, 29 Mar 2021 19:35:07 +0000 Subject: [Libre-soc-dev] daily kan-ban update 29mar2021 In-Reply-To: <20210329213201.70e4fc0562525ada12bd0b58@platen-software.de> References: <20210329205837.bb2b54712a55e8a7d870f9b6@platen-software.de> <20210329212143.279f1cdd3df982171cbc33b3@platen-software.de> <20210329213201.70e4fc0562525ada12bd0b58@platen-software.de> Message-ID: --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Mon, Mar 29, 2021 at 8:32 PM Tobias Platen wrote: > > On Mon, 29 Mar 2021 21:21:43 +0200 > Tobias Platen wrote: > > > On Mon, 29 Mar 2021 19:09:34 +0000 > > Luke Kenneth Casson Leighton wrote: > > > > > --- > > > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 > > > > > > On Mon, Mar 29, 2021 at 7:58 PM Tobias Platen > > > wrote: > > > > > > > > having a look at SEGMENT_CHECK before RADIX_LOOKUP in both > > > > microwatt source code and PowerISA_public.v3.0B.pdf > > > > > > doesn't look like gem5 radixwalk.cc does that segment check. > > > https://github.com/power-gem5/gem5/blob/gem5-experimental/src/arch/power/radixwalk.cc > > > > > > btw there's an off-by-one (do git pull) > > > > > > l. > > > > > > _______________________________________________ > > > Libre-soc-dev mailing list > > > Libre-soc-dev at lists.libre-soc.org > > > http://lists.libre-soc.org/mailman/listinfo/libre-soc-dev > > I did the git pull, and now I'm trying to find the segment check > > in PowerISA_public.v3.0B.pdf. Until now I did not find something > > that matches the microwatt implementation. > > > > -- > > Tobias Platen > > > > _______________________________________________ > > Libre-soc-dev mailing list > > Libre-soc-dev at lists.libre-soc.org > > http://lists.libre-soc.org/mailman/listinfo/libre-soc-dev > I've found some the location which I was looking for: > 5.7.6.1 Partition Table > 5.7.6.2 Process Table page numbers. always quote: * v3.0B * Book I / II / III * section number * page number From lkcl at lkcl.net Tue Mar 30 18:53:58 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 30 Mar 2021 17:53:58 +0000 Subject: [Libre-soc-dev] [Libre-soc-bugs] pagereader.py In-Reply-To: <20210330173919.GO16258@phcomp.co.uk> References: <20210330173919.GO16258@phcomp.co.uk> Message-ID: alain, libre-soc-bugs is intended for one-way-broadcast-push / reporting / transparency-auditing, as an output from bugzilla: nobody actually "interacts" with it. transferring to libre-soc-dev On Tue, Mar 30, 2021 at 6:39 PM Alain D D Williams via libre-soc-bugs wrote: > > I have pushed many markdown files back to git (eg fixedload.mdwn) excellent. just saw them >... I need to > push pagereader.py back as well -- so that it ignores comments** errr... butbutbut... i added that already! https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/decoder/pseudo/pagereader.py;h=8e9b0be39b66cc70afd45cbe09cca793c03a901c;hb=5785c6948a5735d9568e3358798bb213de33d472#l94 err ahh ok, that was in a *separate* place. ok so i assume you have cut/paste that and added it at line.... 181 or so. > but git does > not seem to know about it ??? > > git ls-files pagereader.py -- shows nothing in which repository? you of course want this: https://git.libre-soc.org/?p=soc.git not this: https://git.libre-soc.org/?p=libreriscv.git once you have committed that - to the repository in which pagereader.py exists rather than a repository in which it does not, then it will be safe to update the git submodules for the soc repo. *not before* l. From richard.wilbur at gmail.com Wed Mar 31 00:24:55 2021 From: richard.wilbur at gmail.com (Richard Wilbur) Date: Tue, 30 Mar 2021 17:24:55 -0600 Subject: [Libre-soc-dev] [RFC] svp64 "source zeroing" makes no sense In-Reply-To: References: <2E0ADC4A-089C-4548-9ADB-4B40740DBE59@gmail.com> Message-ID: > On Mar 23, 2021, at 22:50, Luke Kenneth Casson Leighton wrote: > > On Wednesday, March 24, 2021, Richard Wilbur > wrote: >> >> being similar to "just store 0 in the destination". I asked the above >> question because of something you said in an E-mail message in this >> thread which I received on 21 Mar (you sent on 22 Mar), >> "bear in mind two things. >> >> 1) Dynamic Partitioned ALUs will require receiving MULTIPLE predicate mask >> bits i.e. cover multiple src/dest steps. > > > right. sorry. wrong words. > > because 64 bit DynamicPartitioned ALUs can represent / compute multiple > elements (8 in the case of elwidth=8 overrides) this is *effectively* > multi-issue. > > therefore @ ew=8 you need to shove 8 lots of elements into each one. > > therefore that requires 8 src/dest steps This implies we have 8 byte-size adds that are called for in the code. If this were a couple of vectors of 8 bytes the operation fits the ALU perfectly but the operands are also likely stored in a couple 64-bit registers making the job of marshalling the arguments very straight-forward. What seems significantly less likely is having several unrelated 8-bit (byte-sized) adds to marshal together. Do you have a particular algorithm in mind? Likewise, having a dynamically partitioned ALU is great for changing width of parameters but my guess is we are still running the same instruction across the whole business at one time. > where the squishy brown (blue in the case of myrhbusters because it was > easier for the cameras) hits the axially rotating bladed device is in > routing arbitrary data from regfiles in different lanes. > > it may be easier if the predicate masks are full of holes to just go "screw > it" and run say 50% of the 8 bit DynamicPartitions empty. > > however if there happens to be a masked parallel if-then-else construct, > these typically use the exact same predicate just with inverted mask. > > if those parallel then-else clauses *happen* to require the exact same ALU > *and* the registers are in the same lanes we *might* be able to.match up > the opposing masks and fill the ALUs to run 100%. > > i stress might. I guess here it would be wonderful to consider what applications we might have that could use these constructs to good effect. If they are something the compiler could be expected to generate, what code constructs would be translated this way? If not, would this amount to a significant optimisation for a particular algorithm, in which case we could hand-code the assembly and provide it to implementers as a C function call. […] >>> start from a position other than the start. basically shift the value >>> down, trash N bits, then count. >> >> Latest revision has that as well. That is what is required to start >> where we left off after returning from an interrupt. > > > to cope with reentrancy, my feeling is the algirithm should be like this: > > * already_done = (1< * temp = predicatemask | already_done > * startfrom_srcstep = cntlzero(temp) According to my understanding of cntlzero(mask) it is "count leading zero's in mask": start counting zero's from least-significant bit to first set bit (=1). If that is the case, the method you outline above isn't likely to work. It erases the zero's that have all been already counted but then starts over at the bottom. For predicatemask = 0x00ffff00, srcstep = 8 already_done = (1<<8) -1 = 0x000000ff temp = 0x00ffff00 | 0x000000ff = 0x00ffffff startfrom_srcstep = cntlzero(0x00ffffff) -> 0 With my proposed solution: initialize(mask = 0x00ffff00, count = 8): register = mask # next_state = register >> count, shifting in 1's from above next_state = 0x00ffff00 >> 8 = 0xff00ffff register = next_state # load new state into register >>>> Where in the loop is the valid exit point if an interrupt occurs? >>> >>> at any time. it's a Sub-Program-Counter and should be treated as such. >> >> I don't see the "Sub-Program-Counter" in the SVSTATE documentation. > > > it's a conceptual one. Is there a state-transition diagram for this? From hendrik at topoi.pooq.com Wed Mar 31 12:33:52 2021 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Wed, 31 Mar 2021 07:33:52 -0400 Subject: [Libre-soc-dev] [RFC] svp64 "source zeroing" makes no sense In-Reply-To: References: Message-ID: <20210331113352.pz5hshacsyug7j3c@topoi.pooq.com> On Tue, Mar 30, 2021 at 05:24:55PM -0600, Richard Wilbur wrote: > > On Mar 23, 2021, at 22:50, Luke Kenneth Casson Leighton wrote: > > > > On Wednesday, March 24, 2021, Richard Wilbur > > wrote: > >> > >> being similar to "just store 0 in the destination". I asked the above > >> question because of something you said in an E-mail message in this > >> thread which I received on 21 Mar (you sent on 22 Mar), > >> "bear in mind two things. > >> > >> 1) Dynamic Partitioned ALUs will require receiving MULTIPLE predicate mask > >> bits i.e. cover multiple src/dest steps. > > > > > > right. sorry. wrong words. > > > > because 64 bit DynamicPartitioned ALUs can represent / compute multiple > > elements (8 in the case of elwidth=8 overrides) this is *effectively* > > multi-issue. > > > > therefore @ ew=8 you need to shove 8 lots of elements into each one. > > > > therefore that requires 8 src/dest steps > > This implies we have 8 byte-size adds that are called for in the code. > If this were a couple of vectors of 8 bytes the operation fits the ALU > perfectly but the operands are also likely stored in a couple 64-bit > registers making the job of marshalling the arguments very > straight-forward. > > What seems significantly less likely is having several unrelated 8-bit > (byte-sized) adds to marshal together. Do you have a particular > algorithm in mind? > > Likewise, having a dynamically partitioned ALU is great for changing > width of parameters but my guess is we are still running the same > instruction across the whole business at one time. > > > where the squishy brown (blue in the case of myrhbusters because it was > > easier for the cameras) hits the axially rotating bladed device is in > > routing arbitrary data from regfiles in different lanes. > > > > it may be easier if the predicate masks are full of holes to just go "screw > > it" and run say 50% of the 8 bit DynamicPartitions empty. > > > > however if there happens to be a masked parallel if-then-else construct, > > these typically use the exact same predicate just with inverted mask. > > > > if those parallel then-else clauses *happen* to require the exact same ALU > > *and* the registers are in the same lanes we *might* be able to.match up > > the opposing masks and fill the ALUs to run 100%. > > > > i stress might. > > I guess here it would be wonderful to consider what applications we > might have that could use these constructs to good effect. If they > are something the compiler could be expected to generate, what code > constructs would be translated this way? If not, would this amount to > a significant optimisation for a particular algorithm, in which case > we could hand-code the assembly and provide it to implementers as a C > function call. > > […] > > >>> start from a position other than the start. basically shift the value > >>> down, trash N bits, then count. > >> > >> Latest revision has that as well. That is what is required to start > >> where we left off after returning from an interrupt. > > > > > > to cope with reentrancy, my feeling is the algirithm should be like this: > > > > * already_done = (1< > * temp = predicatemask | already_done > > * startfrom_srcstep = cntlzero(temp) > > According to my understanding of cntlzero(mask) it is "count leading > zero's in mask": > start counting zero's from least-significant bit to first set bit (=1). I find these two sentences confusing. Aren't the leading zeros the most significant bits, not the least significant bits? -- hendrik > > If that is the case, the method you outline above isn't likely to work. > > It erases the zero's that have all been already counted but then > starts over at the bottom. > For predicatemask = 0x00ffff00, srcstep = 8 > already_done = (1<<8) -1 = 0x000000ff > temp = 0x00ffff00 | 0x000000ff = 0x00ffffff > startfrom_srcstep = cntlzero(0x00ffffff) -> 0 > > With my proposed solution: > initialize(mask = 0x00ffff00, count = 8): > register = mask > # next_state = register >> count, shifting in 1's from above > next_state = 0x00ffff00 >> 8 = 0xff00ffff > register = next_state # load new state into register > > >>>> Where in the loop is the valid exit point if an interrupt occurs? > >>> > >>> at any time. it's a Sub-Program-Counter and should be treated as such. > >> > >> I don't see the "Sub-Program-Counter" in the SVSTATE documentation. > > > > > > it's a conceptual one. > > Is there a state-transition diagram for this? > > _______________________________________________ > Libre-soc-dev mailing list > Libre-soc-dev at lists.libre-soc.org > http://lists.libre-soc.org/mailman/listinfo/libre-soc-dev From lkcl at lkcl.net Wed Mar 31 12:56:25 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 31 Mar 2021 11:56:25 +0000 Subject: [Libre-soc-dev] NGI POINTER grant deadline apr 1st Message-ID: folks i have submitted an NGI0 POINTER grant request for EUR 200,000 for advancing the single core SoC, validating the cryptoprimitives, and putting them into a shuttle run. also doing advanced SRAMs for regfiles and some RGMII, USB PIPE PHYs and so on. hilariously there is *another* deadline of *today* for a UK Grant, where GNSS GPS accuracy is of interest. so i will scramble to do that within a few hours :) l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 From libre-soc at platen-software.de Wed Mar 31 20:34:38 2021 From: libre-soc at platen-software.de (Tobias Platen) Date: Wed, 31 Mar 2021 21:34:38 +0200 Subject: [Libre-soc-dev] daily kan-ban update 31mar2021 Message-ID: <20210331213438.3fbd40fe96dc3461c6fae169@platen-software.de> today: reading PROCESS_TABLE_3 from memory (correct values), then calling _segment_check(addr, mbits, shift) but with wrong args. Trying to understand what I'm doing wrong here? -- Tobias Platen From lkcl at lkcl.net Wed Mar 31 23:47:47 2021 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Wed, 31 Mar 2021 22:47:47 +0000 Subject: [Libre-soc-dev] daily kan-ban update 31mar2021 In-Reply-To: <20210331213438.3fbd40fe96dc3461c6fae169@platen-software.de> References: <20210331213438.3fbd40fe96dc3461c6fae169@platen-software.de> Message-ID: On Wednesday, March 31, 2021, Tobias Platen wrote: > today: reading PROCESS_TABLE_3 from memory (correct values), then calling > _segment_check(addr, mbits, shift) but with wrong args. > Trying to understand what I'm doing wrong here? will take a look tomorrow, prbtl3 is i think kernel one rather than userspace, something like that, and i think the microwatt team decided to set a rule that anything with the MSB of the address set to 1 is kernel and anything with 0 is userspace. we really have to ask on openpower-hdl-cores, there is no point guessing or struggling, we don't gave time to do that. l. -- --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68