<lkcl_>
float ("nan") only works in python 3.5 and below
<lkcl_>
DaKnig: which version of python are you using?
<lkcl_>
the reason i ask is because nmigen only works with python 3.6, and according to that stackoverflow report, float("nan") was deprecated after 3.5
<DaKnig>
wdym python 3.5 and below
<DaKnig>
I use python 3.6
<lkcl_>
python3.6 and above
<lkcl_>
then according to that stackoverflow, float("nan") should not work
<lkcl_>
it says to use math.nan
<lkcl_>
Python 3.7.2 (default, Jan 3 2019, 02:55:40)
<lkcl_>
>>> float("nan")
<lkcl_>
nan
<DaKnig>
see? works just fine
<lkcl_>
well that worked :)
<DaKnig>
same for infinity
<DaKnig>
float("inf")
* lkcl_
sigh gotta love incorrect stackoverflow answers...
<miek>
it's not incorrect..
<miek>
it's saying that math.nan was new in 3.5, before that you could use float("nan") instead
<lkcl_>
hmm interestingly we can't use this capability in the nmigen-based ieee754fpu library, because python nan/inf still relies on the underlying processor definition of ieee754.
* lkcl_
tracked down nmigen_soc wishbone InterconnectShared.
<lkcl_>
i *think* i can do what i need with that. create a 32-bit wishbone.Interface record and add it as the output...
<DaKnig>
> implying there's only one type of NaN :)
<lkcl_>
DaKnig: yes. signalling NaNs and quiet NaNs
<lkcl_>
and don't get me started on the differences between x86, PowerISA, ARM and RISC-V
<lkcl_>
urrr....
<lkcl_>
jon dawson's verilog ieee754 fp implementation, the unit tests use a c library.
<lkcl_>
so of course, when you compile the unit tests on an ARM machine or a POWER9 machine, you get *different test answers*
<lkcl_>
we're trying to develop a nmigen-based POWER9-compliant IEEE754, doing the development predominantly on x86 hardware.
<lkcl_>
wark-wark :)
<DaKnig>
you can test that on your phone using ARM :) Im sure if somebody was able to run this on the rpi0 then running it in termux is not out of the question
<DaKnig>
modern smartphones' processors are pretty fast (ofc not as fast as your PC) expecially if you can use all the cores
<lkcl_>
the point is that if we try to rely on the ARM definition of IEEE754FP by calling an ARM FP instruction to produce the result of a calculation
<lkcl_>
it's going to produce a *different answer* than if we called an x86 FP instruction
<lkcl_>
and in some cases, the instruction might not exist at all (IEEE754 FP16 for example)
Asu has quit [Read error: Connection reset by peer]
<lkcl_>
or... some hardware might have FP80, some might have FP128.
<DaKnig>
I got that, but you can compare that to both x86 and ARM to get uh a better idea about if it works well or not
<lkcl_>
ah that's the point: we have to be absolutely dead-accurate to POWER9, under all circumstances: we already know it'll be incompatible
<lkcl_>
POWER9 has extra rounding modes for example that x86 doesn't have
<DaKnig>
ah. I see. do you have a POWER9 machine?
<lkcl_>
sponsored access to a TALOS-II workstation, thanks to Raptor Engineering, yes
* lkcl_
whew
<DaKnig>
very cool!
<lkcl_>
so - believe it or not - we actually have to write an ieee754 software-emulation library
Asu has joined #nmigen
<lkcl_>
running its unit tests on POWER9 first, to check that they're compatible in all possible combinations / modes
<lkcl_>
*then* run the same tests against the nmigen HDL
<lkcl_>
urrr... :)
<lkcl_>
i'm mentioning this as a cautionary tale if you are planning to use python's "nan" as a "verification" of a nmigen-based HDL implementation of FP :)
<lkcl_>
or... anything like that
<DaKnig>
thanks for that; I hope I wont have to deal with implementing 754 accurately
<lkcl_>
lol consider yourself lucky :)
<DaKnig>
Im having enough trouble with HDMI and htat is not even supposed to be hard :(
<lkcl_>
mmm didn't enjoydigital do something called litehdmi?
<DaKnig>
I have to make my own though
<lkcl_>
ah i was thinking of something to look at, comparatively
<lkcl_>
ok so there's a protocol "on top of" TMDS?
<DaKnig>
more like 10 protocols on top of TMDS
<lkcl_>
dang
<DaKnig>
all called HDMI together
<DaKnig>
well that's not true
<DaKnig>
TMDS itself is many protocols together
<DaKnig>
o wait I messed up; HDMI is back comp with DVI/D, is what I meant.
<DaKnig>
its internal encoding is called TMDS
<lkcl_>
it sounds very much like the story "hello i want a samba", where people have no idea that samba is about 25 different services over *seven* separate networking protocols
<DaKnig>
TMDS has many protocols inside it, and HDMI adds a few more
<lkcl_>
is this how you can do things like get ethernet-over-hdmi, and USB3-over-hdmi?
<DaKnig>
I have no idea
<DaKnig>
but when you add scary words like USB to HDMI it makes me feel uncomfortable
<lkcl_>
:)
<DaKnig>
;-)
<DaKnig>
basically DVI-D maps parallel 8-bit VGA signals to serial 10-bit that are then transmitted at 10x the speed. when data transfer is active, you encode the pixels in one scheme, when its not active, there's another scheme for encoding the [vh]sync signals
<DaKnig>
that's not that hard; just a LUT plus a tiny bit of logic (or what they did here, actually implementing this in pure logic)
<DaKnig>
then comes HDMI- you start by asking the screen what modes it supports, place your bets on one of them (because screens lie), add some guard bands and preambles before and after the active video data; but then you have to send data packets (audio and such) encoded in TERC4 which is now the 4th protocol I mentioned so far
<lkcl_>
jaezz
<lkcl_>
does the monitor you have support DVI-D?
<DaKnig>
not as complex as floats in 754 :)
<DaKnig>
nope; my monitor doesnt support DVI-D
<lkcl_>
urr that's a pity. it sounds like a simpler first target
<DaKnig>
I learned that the hard way, tinkering with my code and seeing that it doesnt work
<lkcl_>
from what i understand, it's still possible to do EDID though with DVI-D, right? or... that's over the I2C interface that's not actually part of the hi-speed Tx/Rx but is part of the 19 pins
<lkcl_>
something like that?
<DaKnig>
I am not sure actually; Im just assuming a constant resolution that most monitors support
<DaKnig>
800x600
<DaKnig>
at 8bit per channel
<_whitenotifier-3>
[nmigen-soc] jfng opened pull request #25: periph: add a ConstantMap container for configuration constants. - https://git.io/JJFQT
<DaKnig>
the what the heck? I can not import nmigen..?
<DaKnig>
NameError: name 'nmigen' is not defined
<DaKnig>
I get this error when nmigen tries to compile my design
<DaKnig>
not on the line where I import it
<DaKnig>
ah oops. nvm me.
emeb has joined #nmigen
<awygle>
oo, intersting paper wq
a72 has joined #nmigen
a72 has quit [Remote host closed the connection]
emeb has quit [Ping timeout: 260 seconds]
emeb has joined #nmigen
emeb has quit [Ping timeout: 240 seconds]
emeb has joined #nmigen
<pepijndevos>
how does an IRC meeting work?
<awygle>
we show up, wq has an agenda usually, and we talk about various issues and design questions.the idea is to do a kind of tick/tock between design and implementation. this week would be on the implementation side but i suspect since wq was out last week we'll do design instead. if you have something you want the team to discuss, feel free to bring it up and it'll get put into the agenda.
<whitequark>
i was out for two weeks, right?
<awygle>
because of the async, talk-over-each-other nature of IRC (and because there's lots to talk about) things tend to run a bit long so far but hopefully we'll get in a groove
<awygle>
were you? totally possible, i don't recall. time has no meaning.
<awygle>
to clarify i know you were on vacation for 2 weeks but i don't remember if we skipped two meetings
<whitequark>
ah hm
<whitequark>
we had a meeting on 3rd so we skipped one
<pepijndevos>
Yea wq mentioned discussing one of the bugs I found, which actually turned out to be not really a bug but more of a design question.
<awygle>
yeah so that "meta:nominated" label is new for tagging issues to talk about at upcoming meetings
<pepijndevos>
And uh... if the conclusion is "document it" fine, but if it leads to reconsidering array design, I have a larger problem in building abstractions on top of Array.
hitomi2507 has quit [Quit: Nettalk6 - www.ntalk.de]
<whitequark>
anyone has a strong preference either way?
<whitequark>
right now we have:
<whitequark>
- PulseSynchronizer (both i_domain and o_domain, no way around that)
<whitequark>
- ResetSynchronizer (just domain; specifies the domain to be reset, of course)
<whitequark>
- AsyncFFSynchronizer (just domain; this is basically the same functionally as ResetSynchronizer, but it doesn't specifically require you to use the synchronized signal as a reset)
<whitequark>
- FFSynchronizer (just o_domain)
<awygle>
i kind of like "just domain" but i can see the "o_domain" argument
<awygle>
basically the Reset and AsyncFF synchronizers synchronizer from "no domain" (async) to "some domain"
<whitequark>
the way we ended up here is by making FFSynchronizer consistent with PulseSynchronizer (both have i/o), and then AsyncFFSynchronizer with ResetSynchronizer
<awygle>
whereas the PulseSynchronizer and FFSynchronizer synchronize from "one domain" to "another domain"
<whitequark>
wait
<whitequark>
FFSynchronizer *absolutely* can synchronize async signals
<whitequark>
that's what you do with async inputs!
<awygle>
yeah the analogy doesn't really work
<awygle>
i'm just saying i think that's how it came to be
<whitequark>
ahh yea
<awygle>
actually i think i'm talking myself into o_domain
<whitequark>
hrm
<whitequark>
so, do you think o_domain is clearer?
<awygle>
i think that's debatable but i think consistency is desirable, and as you say pulse synchronizer must have o_domain (and we have it in lots of other places too like AsyncFIFO)
<awygle>
i don't think o_domain is _less_ clear, and i think it's more consistent
<awygle>
the counterargument is breakage, esp. for ResetSynchronizer
<whitequark>
right, and we already have the thing where SyncFIFO aliases level as r_level/w_level
<whitequark>
hmmm
<whitequark>
i actually think we don't necessarily need to change ResetSynchronizer
<whitequark>
it's special
<whitequark>
it can just... stay special
<awygle>
i'm ok with that
<_whitenotifier-3>
[nmigen] whitequark commented on issue #467: Inconsistency between a parameter name for AsyncFFSynchronizer and FFSynchronizer - https://git.io/JJbeH
<whitequark>
awygle: hm, you did a bit of nmigen issue triage in the past, right?
<whitequark>
i think github has permissions for that specifically, so i think i can give you that
<whitequark>
if you want, anyway
<awygle>
sure
<awygle>
i have the sysadmin's curse, i always want all the powers and forget that comes with responsibilities :P
<pepijndevos>
lol
<ktemkin>
I've gone past that into running the hell away from (or heavily disclaimer'ing) most things
<awygle>
you are wiser than i
<whitequark>
i think it's done. github is weird but whatever
<pepijndevos>
The counterpoint is that currently just Array([Const(0xff, signed(8))]) is *also* signed(9) for no apparent reason
<whitequark>
yes
<whitequark>
I was about to mention that
<whitequark>
*that* seems to be a clear bug
<whitequark>
absolutely no reason for it
<whitequark>
regarding the former case.
<whitequark>
i'm certain of two things:
<whitequark>
- first, any answer that makes Array([Const(0xff, unsigned(8)), Const(0xff, signed(8))])[Const(0)] return a negative number is wrong (and seriously backwards-incompatible too)
<whitequark>
so, unsigned(8) is out
<whitequark>
- second, any answer that makes Array([-1, 0, 1]) not work is user-hostile (and seriously backwards-incompatible, too)
<whitequark>
so we can't raise an exception if you have heterogeneous elements in an array
<whitequark>
do we have any other choices?
<pepijndevos>
I would say that Array([-1, 0, 1]) is kinda homogeneous in intent, and I would not be surprised if all of these got cast to the largest type
<pepijndevos>
Which is what probably ends up happening on usage
<pepijndevos>
So I think for the mixed case the current behaviour is correct
<whitequark>
well, ArrayProxy.shape() specifically casts to the largest type
<whitequark>
so yes
lkcl__ has joined #nmigen
<whitequark>
what do we want to change here, besides the case of arrays of purely-signed elements that currently spuriously extends?
<pepijndevos>
I have one tangentially related suggestion...
<whitequark>
the one you mentioned earlier?
emeb_mac has joined #nmigen
<pepijndevos>
if all elements of an array have the same attribute, Array could just return that attribute rather than a proxy.
lkcl_ has quit [Ping timeout: 256 seconds]
<pepijndevos>
But regarding this bug, I don't think anything else needs changing
<whitequark>
you mean, a proxy could return that attribute rather than another proxy?
<pepijndevos>
yea, and that extends to array as well. Say you have a homogeneous array and there is no special case for shape(), it would call shape on the entire array, find it's a fixed value and return that shape.
<whitequark>
but... that's what already happens
<whitequark>
max(n,n,n,n...)=n
<whitequark>
(save for the bug re: signed-only contents)
<pepijndevos>
yea, but now shape is a special case, I'm thinking if it's possible to generalise
<pepijndevos>
My concrete issue is that my fixed point class specifies the fractional bits and it require tricky wrapping with a special array wrapper
<whitequark>
i don't like your idea very much for one reason: what is "equality"?
<pepijndevos>
Maybe a super specific problem I have abstracting over Values, but if the shape behaviour were generic to other attributes it would be useful to me hehe
<whitequark>
i need something reflexive and transitive to be able to rely on it in ArrayProxy
<whitequark>
but __eq__ doesn't have to be
<whitequark>
in fact for floats it won't be
<pepijndevos>
not sure I understand
<whitequark>
well
<whitequark>
wait, i think i understand what you want here, moment
<pepijndevos>
(don't want to take too much time with my fringe problem, also ok with just fixing the signed shape problem and moving on)
<whitequark>
no, i think it's reasonable to discuss
<pepijndevos>
okay
<whitequark>
your use case of building a HLS-y thing on top of nMigen is very much in scope, and I'd have nominated it myself if you weren't here
<whitequark>
- for first solution, well, you lose type safety benefits, since now Q can be misused anywhere a Value can go. pretty bad
<whitequark>
- for second solution, implementing ArrayProxy through ValueCastable is inherently inefficient^W^W actually just not possible right now
<pepijndevos>
What if Array had an overridable method that allows modifying the returned ArrayProxy?
<whitequark>
modifying how?
<pepijndevos>
More like wrapping
<whitequark>
... well
<whitequark>
that... would certainly work
<pepijndevos>
just spewing more ideas... not sure what the implications are
<pepijndevos>
And if you *then* subclass ArrayProxy to have special cased methods for your custom type, you can feed that to Array and it'll return wrappers that look like your type
<whitequark>
yeah, that's the classic OO solution: just add more inheritance
<pepijndevos>
lol
<whitequark>
my counter-proposal is to add more composition
<whitequark>
the way i see the core of the problem is
<pepijndevos>
composition is always good
<whitequark>
there is a language *primitive* inside Array that's much smaller than Array itself. the primitive is basically "Mux() but it can be used on LHS"
<pepijndevos>
hm
<pepijndevos>
I see
<whitequark>
you've seen Switch, right?
<pepijndevos>
yea yea it makes sense go on
<whitequark>
Switch works on statements. this hypothetical primitive would work on values.
<pepijndevos>
So you're saying, expose the primitive and build your own array around it?
<whitequark>
basically.
<pepijndevos>
Sounds good
<whitequark>
this is more of a medium term solution though
<whitequark>
on one hand, it would be a really nice cleanup for some nmigen internals
<whitequark>
there was also uh...
<pepijndevos>
As long as I don't need to assign to my array I could actually just use Mux I guess
<_whitenotifier-3>
[nmigen] whitequark commented on issue #73: Expand semantics of Array from MutableSequence to MutableMapping - https://git.io/JJbfB
<_whitenotifier-3>
[nmigen] whitequark reopened issue #73: Expand semantics of Array from MutableSequence to MutableMapping - https://git.io/Jfzam
<whitequark>
if we had a multiplexer primitive, it would be super simple to build whatever containers and proxies we want on top of that, without touching the nMigen core
<awygle>
that sounds quite nice to me, given how many questions we get about, like, Array.any()
<whitequark>
... do we?
<lkcl__>
reading / following the discussion: one of the long-term things that we would like to do with libre-soc is to be able to use PartitionedSignal in exactly the same way as Signal is used right now
<whitequark>
lists don't have .any() either
<whitequark>
what is PartitionedSignal?
<lkcl__>
including in Mux()
<lkcl__>
it's a dynamic SIMD variant of Signal
<awygle>
every time somebody asks about extending Array's semantics you say "why do people keep wanting to extend Array's semantics, list() doesn't have those semantics" lol. it's happened at least three times
<whitequark>
awygle: point taken
<awygle>
i do get your point ofc, but it does come up pretty often
<lkcl__>
associated with every PartitionedSignal is a "mask / gate".
<lkcl__>
we have __gt__, __lt__, __add__ etc. implemented (__div__ and more complex ones still TODO)
<lkcl__>
however where it all goes pear-shaped is Mux(), and in m.If() and m.Switch()
<whitequark>
do __gt__ etc just delegate to nmigen < etc directed to the right part of the signal?
<lkcl__>
we had to implement it at the bit-level, i think
<whitequark>
i can't say i understand how it works
Sarayan has joined #nmigen
<lkcl__>
the reason i bring it up is because we kinda have the same issue as pepijn
<pepijndevos>
So... can I implement a read-only array with Switch?
<whitequark>
pepijndevos: you can only put statements into Switch, unfortunately
<whitequark>
you *can* implement a read-only array with Mux
<whitequark>
at the cost of producing some really ugly verilog
<pepijndevos>
Yea I looked at Mux and it's only two-way. If it were N-way that would be something heh
<awygle>
(OT: i'm heading home for lunch, but i do have something i want to talk about, so please ping me when this discussion is wrapped assuming folks aren't too worn out)
<pepijndevos>
Not sure what it means that I can only put statement into a switch
<lkcl__>
there are partition points that, if they are entirely "open", PartitionedSignal behaves exactly like Signal
<whitequark>
pepijndevos: basically, you can only put .eq() in a Switch
<whitequark>
and a Switch doesn't have a value
jaseg has joined #nmigen
<whitequark>
it's similar to the If/Elif/Else construct in Python
<pepijndevos>
hm I see...
<lkcl__>
if the ppts are "split in half", it behaves exactly like a pair of Signals of half the width, as if you had a for-loop (of size 2) around absolutely everything
<whitequark>
pepijndevos: let me write an issue for the multiplexer feature
<whitequark>
i think you have some really valuable insight here, thanks for raising it
<pepijndevos>
more than welcome :)))
<whitequark>
it fills a hole in the language i've been looking at with dissatisfaction for quite a while, and in a rather elegant way
<pepijndevos>
It's getting a bit late here, so I'll leave you to the rest of your meeting
* lkcl__
is glad to see MutableMapping reopened
<whitequark>
lkcl__: oh, I simply forgot to reopen it at 3rd. I did tell you that I'll reconsider it, that kinda takes priority over the GH issue status
<lkcl__>
it means being able to express lookup tables in a one-liner
<lkcl__>
oh! :)
<jeanthom-mobile>
Can we have a look at #427 (Assert in simulations)?
<whitequark>
yes. give me a moment to write down the issue we just discussed
<_whitenotifier-3>
[nmigen] whitequark commented on issue #476: Possible bug in ArrayProxy for signed values - https://git.io/JJbJO
<_whitenotifier-3>
[nmigen] whitequark edited issue #476: ArrayProxy shape does not equal element shape for a homogeneous array of signed values - https://git.io/JJ5j1
<whitequark>
... two issues we just discussed
<jeanthom-mobile>
Ok so I started implementing assert in #465
Asuu has joined #nmigen
<whitequark>
yeah, please just go ahead discussing it
<whitequark>
i'll join in a minute
<jeanthom-mobile>
I'm not sure what behaviour we should have when it fails
<whitequark>
ah yes
<whitequark>
this is a bit complicated
<jeanthom-mobile>
because throwing an exceptions breaks the VCD generation
<jeanthom-mobile>
also we have to decide what we show to the user when an assertion fails
<awygle>
(OT: back mostly)
<jeanthom-mobile>
and how should we handle Assume statements?
<awygle>
i agree with the previous resolution, nice job team
<awygle>
position: violating assumptions should fail
Asu has quit [Ping timeout: 256 seconds]
<whitequark>
i agree that violating assumptions should fail
<whitequark>
Assert/Assume only differ in property testing
<jeanthom-mobile>
ok
<whitequark>
regarding failing asserts
<whitequark>
we should definitely show the actual location of the assert in the source code (which is recorded just fine in src_loc)
<whitequark>
can you append items to Python tracebacks yet?
<whitequark>
like, without horrible ctypes hacks
<jeanthom-mobile>
I have to check that
<daveshah>
If you want to mirror Verilog, you could also have Restrict which is Assume but doesn't fail in sim
<whitequark>
our property testing support is essentially all cribbed from SVA
<whitequark>
intentionally; I think SVA is pretty nice
<whitequark>
it's also really minimal at the moment, and i think i'd like to keep it that way for at least a bit of time
<whitequark>
i'd rather have an incomplete API than a poorly thought out complete-looking API
<whitequark>
that said Restrict doesn't seem like it would pose a hazard
<daveshah>
The only problem is Yosys doesn't have $restrict
<daveshah>
afaik the frontend turns restrict into $assume because it is written for FV
<awygle>
yosys doesn't have restrict? weird, i swear i read about it first in a yosys formal blog post
<whitequark>
it doesn't have a $restrict cell
<whitequark>
which is different from the keyword
<awygle>
right
<_whitenotifier-3>
[nmigen] whitequark opened issue #480: Add a minimal value-addressable multiplexer primitive valid on LHS and RHS - https://git.io/JJbJj
<_whitenotifier-3>
[nmigen] whitequark edited issue #480: Add a minimal value-addressable multiplexer primitive valid on LHS and RHS - https://git.io/JJbJj
<whitequark>
done with issues, paying more attention now
<whitequark>
if you're reducing a testcase, you'll be tripping many thousands of assertions per second
<whitequark>
this isn't software, where the deliverable isn't supposed to raise exceptions a lot
<jeanthom-mobile>
btw how should pysim handle the assert failure event?
<whitequark>
so the usual assumptions behind "zero-cost" EH don't apply
<jeanthom-mobile>
should pysim raise an Exception? if so, which exception?
<awygle>
hm, interesting point. not sure how different the percentage of taken exceptions is actually (assuming you're fuzzing or reducing in both cases0 but i'll take your word for it.
<whitequark>
jeanthom-mobile: well, if you can modify the traceback, AssertionError is a natural choice
<awygle>
raise(SIGINT) has the same problems, and also, it was a joke suggestion i was gonna make
<whitequark>
jeanthom-mobile: so. i guess what we can do is use AssertionError and rewrite the traceback nicely (if we can) or with violence (if we're forced to)
<whitequark>
oh yeah, VCD file
<jeanthom-mobile>
whitequark, I'm not sure AssertionError would be an appropriate choice since that would mix assertions failures coming from Python code execution and assertion failures triggered by the gateware
<jeanthom-mobile>
jfng suggested that, and I think he's right
<jeanthom-notmobi>
whitequark: that would be problematic in unittests, when you want to trigger a specific exception (eg. testing your elaboratable with the wrong parameter type or size)
<whitequark>
I'm confused
<jeanthom-notmobi>
let me rephrase this
<whitequark>
why would you ever test for an assertion? (outside of very specific circumstances)
<whitequark>
you test parts of your user interface. if it's a part of your UI/API, it shouldn't be an `assert`, it should be an explicit raise, like what nmigen does
jeanthom-mobile has quit [Ping timeout: 256 seconds]
<whitequark>
I mean, I'm not strongly opposed to making a new exception type, not the hill I'll die on, I just genuinely don't understand the benefit
<whitequark>
awygle: can we discuss what you had in mind in the meantime?
<whitequark>
would probably the last item for today, besides the assert stuff
<awygle>
just because i ran into it a few days ago
<whitequark>
oh, yeah, go ahead
<awygle>
i'm trying to keep my DDR2 controller at 200 MHz on my EPC5 -6, and i kept failing that timing. turned out that i had assigned two signals which were inputs to a Switch to the same source (oops) which turned it into a priority encoder and tanked my fmax
<awygle>
if i had the unique case option i would have caught that earlier, and i think the semantics of it are _relatively_ uncontroversial, so i wanted to bump it and get your take
<whitequark>
so... from this description of an issue, it sounds like you are looking for a lint
<whitequark>
do you agree?
<awygle>
mm. i agree that a lint could solve my problem, how about that?
<whitequark>
i mean
<whitequark>
that's good to know, but if making it a lint is suboptimal, i want to know that too
<awygle>
i think it kinda depends how you look at it
<whitequark>
sure
<awygle>
on the one hand yes, a lint would have caught my bug
<awygle>
on the other hand, fundamentally i wanted a non-priority mux
<whitequark>
i see
<awygle>
so i'm expressing my desire incorrectly
<whitequark>
yes, i think this is actually a great argument
<whitequark>
here lies the problem
<whitequark>
i'm sure people will say "i want every switch in my codebase to be full/unique"
<whitequark>
and they won't be happy with having to manually insert those qualifies each time
<awygle>
i agree with that
<whitequark>
scope inheritance is one of the usefulness of lints
<whitequark>
the other being that you can turn them into warnings, which in this case is probably not important
<whitequark>
i mean, i can imagine cases where i want to be warned about non-full cases rather than have it as an outright error
<whitequark>
but they're not super important
<awygle>
i kind of like doubling up, and having a Switch(mode="unique") and also a with Lint("unique-switches"), and letting the user choose which they want
<awygle>
but it does admit confusion
<awygle>
actually let me un-weasel that - i like the idea of doubling up, and i don't think the potential confusion is that large.
<whitequark>
i... agree
<whitequark>
we can just have both, they express different concepts
<whitequark>
"i want this switch specifically to be a non-priority mux" vs "i've heard non-priority muxes are slow, do i have any"
<awygle>
yes
<whitequark>
great. write a (small) RFC for it then?
<awygle>
heh, sure. i still owe you two from last week(?) tho
<whitequark>
- bikeshed the syntax
<whitequark>
- it's not trivial to display good errors in presence of wildcards
<whitequark>
mostly the latter needs discussion
<awygle>
yep
<awygle>
and also, is there a case where a lint and a keyword argument would conflict, and what do we do if there is
<jeanthom-notmobi>
whitequark: I had second thoughts about creating a new exception type for asserts. I can't think for now of a situation where we would have to check for an nmigen assertion failure, let's use AssertionError then
<whitequark>
jeanthom-notmobi: yup. and if such a situation arises, we can make our own exception that inherits from AssertionError
<jeanthom-notmobi>
yep
<whitequark>
awygle: hm, good question
<awygle>
whitequark: one last thing, does this decision also apply to "full"? full feels much more optimization-focused than unique, which is fundamentally a different thing, to me, but i also like having them be symmetrical
<awygle>
(or well, pre-decision)
<whitequark>
i think that the keyword argument should always take precedence
<awygle>
i agree with that
jeanthom-mobile has joined #nmigen
<whitequark>
because, well, you're describing what kind of switch you want *right there*
<whitequark>
moreover, it should be silent, in other words, a valid way to temporarily override whatever lint is active globally
<whitequark>
because, sure, you can do `with Lint()`, but Switch() already has hella rightward drift
<awygle>
i actually can't think of a reason you'd lint "warn me if i accidentally have a switch with unique cases, i want them all to be priority", so it may not actually come up
<awygle>
but if it does, i agree the kwarg should win
jeanthom-notmobi has quit [Ping timeout: 256 seconds]
<_whitenotifier-3>
[nmigen] whitequark commented on issue #451: `Switch` attribute for unique and/or full `Case`s - https://git.io/JJbTz
<whitequark>
phew, done for today
<awygle>
nice job :)
<whitequark>
:)
<whitequark>
yeah, we went through quite a lot
<awygle>
and i'm quite happy with at least two of the decisions we made (and unhappy with 0)
* cr1901_modern
looks at the date
<cr1901_modern>
hooooly crap I forgot there was a meeting today ._.
<_whitenotifier-3>
[nmigen-soc] jfng synchronize pull request #25: periph: add a ConstantMap container for configuration constants. - https://git.io/JJFQT
<_whitenotifier-3>
[nmigen-soc] jfng closed issue #24: Communicating constants from the peripheral to the BSP generator - https://git.io/JJDfN
<_whitenotifier-3>
[nmigen/nmigen-soc] jfng pushed 1 commit to master [+0/-0/±2] https://git.io/JJbIr
<_whitenotifier-3>
[nmigen/nmigen-soc] jfng b405880 - periph: add a ConstantMap container for configuration constants.
<_whitenotifier-3>
[nmigen-soc] jfng closed pull request #25: periph: add a ConstantMap container for configuration constants. - https://git.io/JJFQT
emeb_mac has joined #nmigen
<_whitenotifier-3>
[nmigen-soc] jfng commented on pull request #25: periph: add a ConstantMap container for configuration constants. - https://git.io/JJbIy
Asuu has quit [Read error: Connection reset by peer]
Asu has joined #nmigen
Asu has quit [Client Quit]
emeb_mac has quit [Ping timeout: 264 seconds]
emeb_mac has joined #nmigen
<miek>
doh, i just found the difference between << and `shift_left`. len(C(0, 14) << 2) does not equal 16 :p (which, to be fair, is documented, but i hadn't read closely enough)
<lkcl__>
whitequark, jeanthom... oh, jeanthom's offline - about Display() redirecting to print() or to an event handler class, i'd advocate definitely an event handler class
<lkcl__>
one option worth considering is the standard python logger system
<whitequark>
i mean, it should clearly print *by default*
<lkcl__>
defaulting to stdout... yes
<lkcl__>
one of the advantages of hooking into the standard python logging system is that it brings the concept of reporting levels, without that having to be reinvented
<whitequark>
except we don't have reporting levels, we just have Display
<lkcl__>
indeed. i was thinking, "what would the implications be if Display had a reporting level argument"
<lkcl__>
would it be possible, what would the implications be?
<whitequark>
well, cxxrtl supports the $display Yosys cell, so it would not support this unless yosys gained a reporting level argument
<lkcl__>
and would it break anything / break expectations? in particular, if someone sets the debug level to "critical" (minimal reporting) ...
<lkcl__>
right. so _all_ logging would be sent out (regardless of the requested level), which would mean it would need filtering somehow
<whitequark>
frankly, i don't see a particular need for this feature
<lkcl__>
and, thinking it through, i'm not seeing that it's practical, either
<whitequark>
if you wanted to add loglevels, you could always do it in python
<lkcl__>
"nice-to-have" and "fits python paradigm" however...
<whitequark>
i.e. `if loglevel >= logging.INFO: m.d.sync += Display(...)`
<lkcl__>
something like that, yeah.
<whitequark>
this even works for verilog export
<lkcl__>
yeah
<whitequark>
interestingly, SVA actually does include a feature similar to what you propose
<lkcl__>
my initial thought was, it'd be nice to hook into a readily-available system which has redirection
<lkcl__>
oh?
<whitequark>
for some reason it is only for assertions
<lkcl__>
system verilog assertions
<lkcl__>
oh, quick question: i've a 64 bit wishbone slave device that needs to be converted to 32-bit (without changing the bus width)
<lkcl__>
is there a recipe anywhere that does that?
<whitequark>
without changing the bus width?
<lkcl__>
i've started trying to use nmigen-soc InterconnectShared however i'm running into confusion over what's master and what's slave
<whitequark>
do you want something that would take two 32-bit writes and combine them into a single 64-bit write, for example?
<lkcl__>
as in, i can't change the size of the actual wishbone slave Record of the CPU
<lkcl__>
yes.
<lkcl__>
the CPU has to remain at 64-bit
<whitequark>
misoc has an UpConverter module
<lkcl__>
but has to interface to a 32-bit-wide RAM (actually, litex)
<lkcl__>
ahh
<whitequark>
you can try porting that
<lkcl__>
that's what i was looking for, thank you
<whitequark>
np
<lkcl__>
i'm running into difficulties with litex, i wanted to try to eliminate its upconversion as a possible source of problems by eliminating upconversion in nmigen