| * lkcl_ is now just wondering if SVSTATE should not be considered to be like MSR | 09:40 | |
| lkcl_ | mtsvstate, mfsvstate, just like mtmsr and mfmsr | 10:21 |
|---|---|---|
| lkcl_ | hmm | 10:21 |
| lkcl_ | ahh i think i know why IBM has sc in an entire major opcode even though there's nothing in it | 11:37 |
| lkcl_ | it may be because it's "simple" to decode and consequently can be in the instruction fetch phase | 11:38 |
| lkcl_ | doesn't need to be part of the instruction decoder | 11:38 |
| * lkcl_ added the pseudocode for subvl | 12:07 | |
| lkcl_ | nobody do a git submodule update, i haven't checked it! | 12:08 |
| lkcl_ | https://libre-soc.org/openpower/isa/simplev/ | 12:08 |
| lkcl_ | syntax errors pass... | 12:19 |
| lkcl_ | programmerjake, arg you were right, adding RT_OR_ZERO will be a royal nuisance | 16:06 |
| lkcl_ | the pseudocode parser can't cope, and it's sufficiently complex i can't be arsed to edit it :) | 16:07 |
| lkcl_ | but more than that, Rc=1 mode would otherwise be completely different | 16:07 |
| lkcl_ | if however RT is always written to then Rc=1 mode is no different | 16:07 |
| lkcl_ | pain in the neck but hey | 16:07 |
| lxo | http://www.zerocat.org/ seems like a project we could collaborate with. it would be nice to have libre-soc among the hardware designs they're working with | 16:33 |
| lkcl_ | lxo: nice find! | 16:47 |
| lkcl_ | the single-core gigabit ethernet router IC would qualify because we'll be using entirely libre-licensed RTL. | 16:48 |
| lkcl_ | opencores SDRAM | 16:48 |
| lkcl_ | which is only 133 mhz SDR1 but is entirely libre | 16:49 |
| lxo | lkcl_, can't take credit for it. ricardo morte ferrer pointed me at it. he's in touch with Kai Mertens (who's involved/leading? the project), and I suppose Ricardo could get us all in touch | 16:51 |
| lkcl_ | i'll email him, cc you | 16:53 |
| lxo | oh, so no introductions needed. cool | 16:53 |
| lkcl_ | sent, let's see how it goes | 16:57 |
| lkcl_ | yeah the gigabit router ASIC needs no proprietary HDL at all, including the PLL | 16:58 |
| lkcl_ | which i think the Freedom U310 did actually have to have closed-source PLL and Analog ADC/DAC cells | 16:58 |
| lkcl_ | and that's listed on their site | 16:58 |
| awygle | lkcl_: is it safe to assume that any PartitionedSignals which are participating in an operation must have the same partition bits set? | 23:38 |
| awygle | meaning you won't have "a + b" where a is a1/a2/a3/a4 and b is b1b2b3/b4? | 23:39 |
| lkcl_ | awygle, yes absolutely | 23:41 |
| awygle | ok. and for the m.If stuff, is it safe to assume that any PartitionedSignal referenced in the body will have the same partition bits set as the signal(s) in the condition? | 23:42 |
| lkcl_ | ohh yes | 23:42 |
| awygle | ok. and for the m.If stuff, is it safe to assume that every signal in the body will be a PartitionedSignal? | 23:42 |
| lkcl_ | in fact, now that i think about it, there should really be some checking (if that's practical) | 23:42 |
| awygle | mhm | 23:42 |
| lkcl_ | ahh... no, that's not safe | 23:43 |
| lkcl_ | shift is a good example | 23:43 |
| awygle | in that case what behavior should occur if you have m.If(x == 5): a.eq(b) where some parts of x are 5 and other aren't (where a and b are not partitioned)? | 23:43 |
| lkcl_ | the shift amount can be a Const, Signal, or another PartitionedSignal | 23:43 |
| lkcl_ | err... let me think that through :) | 23:44 |
| awygle | ah ok, i should have restricted my statement more - can we assume all LHS signals, all driven signals, in the bodies will be PartitionedSignals? | 23:44 |
| lkcl_ | yes that's very reasonable | 23:45 |
| lkcl_ | that's a perfectly reasonable assumption, to the point where it might make sense to make it a hard requirement | 23:45 |
| awygle | i agree, i'm not sure there's any way to make this make sense without that assumption | 23:46 |
| lkcl_ | yehyeh | 23:46 |
| lkcl_ | one thing: anything involving m.If() should basically assume that booleans are now arrays-of-booleans | 23:46 |
| lkcl_ | in effect | 23:47 |
| lkcl_ | but | 23:47 |
| lkcl_ | rather than (say) a 2x32 being 0b00010001 in the underlying signal | 23:47 |
| lkcl_ | it should be 0b11111111 | 23:47 |
| lkcl_ | or | 23:47 |
| lkcl_ | 0bAAAABBBB | 23:47 |
| lkcl_ | where AAAA is boolean[1] and BBBB is boolean[0] | 23:48 |
| lkcl_ | the reason is this: | 23:48 |
| lkcl_ | it then becomes possible to use each bit in the PartitionedMux *without* any complications | 23:49 |
| awygle | i was thinking it might make sense to introduce a ParititonedBool or similar as the result of a PartitionedSignal comparison, to track such cases. it will be easier to deal with if the invariant is encoded in the type system rather than just a promise among developers | 23:49 |
| lkcl_ | yes that idea popped into my head a couple months back | 23:49 |
| lkcl_ | i didn't verbalise it / write it down / give it due attention | 23:50 |
| lkcl_ | it's a good idea | 23:50 |
| lkcl_ | ah i know why i didn't pursue it: it's because there's no equivalent in nmigen | 23:50 |
| lkcl_ | there's no Bool in nmigen | 23:51 |
| awygle | that's true | 23:51 |
| lkcl_ | because Signal(1) performs double-duty | 23:51 |
| * lkcl_ thinks | 23:51 | |
| lkcl_ | if Bool existed this would be a no-brainer decision | 23:52 |
| lkcl_ | inventing PartitionedBool without it expands the scope somewhat | 23:53 |
| lkcl_ | would you be happy to defer that one until later? | 23:53 |
| awygle | it may become a requirement for detecting the "PartitionedSignal If" case, but if it doesn't, then sure | 23:53 |
| lkcl_ | ok yes makes sense | 23:54 |
| awygle | (that is, the easiest way to detect "is this a ParititionedSignal If" is "what is the type of the condition", but there may be other ways) | 23:54 |
| lkcl_ | yeah there's some code i glossed over in m.If that involved assessing if the input is a boolean | 23:54 |
| awygle | yup | 23:55 |
| awygle | but it's not as easy as "if len(sig) > 1" because of bool coercions | 23:55 |
| lkcl_ | yehyeh | 23:56 |
| lkcl_ | it'd involve, "is this of type PartitionedSignal" | 23:56 |
| lkcl_ | or | 23:56 |
| lkcl_ | ah i know | 23:56 |
| lkcl_ | a function as part of Value which tests if something is "bool-like" | 23:57 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!