<sb0>
whitequark: arguably not the same problem, since you could stop and think whether the number you are shifting (1) is a 32- or 64-bit integer. but the compiler had no reason at all to make the large constant 32-bit.
Gurty has quit [Ping timeout: 268 seconds]
<whitequark>
yes. i agree the issue i just fixed was a compiler bug. i haven't noticed that it is.
<_whitenotifier-e>
[nmigen] sam-falvo synchronize pull request #22: Updated user guide introduction for nmigen. - https://git.io/fhszI
<kc5tja>
Greetings -- hoping someone can please review my PR, in particular the Memories section? I've marked two spots in particular which I need clarification on.
<kc5tja>
whitequark: I think you reviewed text which was from the legacy documentation. I hadn't finished all of hdl.rst yet. :P But, the input is valuable.
<whitequark>
kc5tja: ah, okay!
<kc5tja>
Regarding transparent terminology, this use of the term is new to me. When I searched for transparent RAM online, everything I found was about transparent latches. It makes sense; I just remember seeing a different term is all. It helps explain a lot though. Thank you for the feedback.
<whitequark>
you might find the Yosys manual helpful
<whitequark>
it is not required, but as nMigen in many ways borrows from Yosys, it may be helpful
<kc5tja>
Sorry it's taking as long as it is. I get only a few hours on weekends, and I'm still learning nMigen as well.
<kc5tja>
Awesome, thanks. I'll add that to my consulting/reference documents list.
<whitequark>
it's fine. there is no particular rush
_whitelogger has joined #m-labs
<sb0>
whitequark: as for rust kernels, they could potentially exist alongside the existing ones. the questions are, who will use it, who will fund it, and who will implement and maintain it.
<whitequark>
sb0: what i am saying is, i can maintain the existing ARTIQ Python compiler. i can make its semantics less bad. but i cannot fix things that are bad because of fundamental properties of the semantics we chose
<whitequark>
the closest thing to fixing integer literals would be to enable overflow checking on mor1kx
<sb0>
fixing what exactly?
<whitequark>
fixing the fact that they will silently overflow with no tools that could show that
<whitequark>
ubsan shows that both signed and unsigned overflows are rarely desired outside of certain classes of programs, like cryptographic algorithms
<sb0>
or phase computations...
<whitequark>
sure
<whitequark>
or well, we don't even have to go to ubsan, rust panics on overflow
<sb0>
what is the best option in your opinion? regular integers throw an exception on overflow, and add another type for power-of-two modular arithmetic that disables the exception?
<_whitenotifier-e>
[nmigen] sam-falvo synchronize pull request #22: Updated user guide introduction for nmigen. - https://git.io/fhszI
<whitequark>
I think adding another type would work rather poorly with our inference and Python's implicit conversion rules
<whitequark>
I think the two options that would work best are either a) methods like .overflowing_add() a la rust
<kc5tja>
whitequark: I seem to recall from a previous discussion here that specials are not supported in nMigen. Am I remembering correctly? There are no examples making use of specials that I can find.
<whitequark>
there are no specials in nMigen
<whitequark>
there are only memories and instances, as special cases (but not a specific entity. just special cases in general.P)
<attie>
specials were just a workaround for "this needs a description that can't be generated with regular migen code", right?
<kc5tja>
Roger that. I'll strip my copy of the docs of specials. I suspect submodules is pretty consistent between Migen and nMigen.
<whitequark>
attie: yeah
<whitequark>
in migen, everything is a fragment, some fragments are also instances, and some instances are also memories
<whitequark>
instances and memories can (and in case of memories, always do) contain behavioral logic for simulation
<whitequark>
hmm, adding Tristate with this scheme will probably require native support for 'z
<whitequark>
I guess I can do that without ever exposing it to user
<kc5tja>
whitequark: Is there a place I can reference to learn how clock domains are used in nMigen? Perhaps an example HDL listing?
<whitequark>
not at the moment, but it should be very similar to Migen
rohitksingh has quit [Ping timeout: 272 seconds]
<kc5tja>
Forgive me if I'm asking
<kc5tja>
oops
<kc5tja>
Forgive me if I'm asking repeated questions; I see in Migen, m.sync.<domain> += statements is a valid construct. However, i've not seen a similar construct for nMigen. Unit tests show creation of multiple domains, and adding them to the domains member of a module, but they're never used.
<kc5tja>
How would one use these multiple domains?
<whitequark>
so let's say you added a domain called foo
<whitequark>
you would use it with `m.d.foo +=`
<whitequark>
`sync` is just the default domain
<whitequark>
(like `sys` was in migen)
rohitksingh has joined #m-labs
<kc5tja>
Ahh, thanks!
_whitelogger has joined #m-labs
<_whitenotifier-e>
[m-labs/nmigen] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fhnw2
<_whitenotifier-e>
[m-labs/nmigen] whitequark 06faeee - back.verilog: better error message if Yosys is not found.
<_whitenotifier-e>
[nmigen] whitequark closed issue #17: Add a more user-friendly error message when the yosys binary can't be found - https://git.io/fht2R
<_whitenotifier-e>
[nmigen] whitequark commented on pull request #19: Fix #17 (Add a more user-friendly error message when the yosys binary can't be found) - https://git.io/fhnwa
<_whitenotifier-e>
[nmigen] whitequark closed pull request #19: Fix #17 (Add a more user-friendly error message when the yosys binary can't be found) - https://git.io/fhnwV
<d_n|a>
Hmm, this seems like slightly weird behaviour ^. Passing self.channel to an int64 parameter apparently makes it be inferred as int64, even though it is assigned an int32. (whitequark: No idea whether that behaviour has only just changed, though.)
<d_n|a>
bb-m-labs: force build --branch=pull/1244/merge artiq
<bb-m-labs>
build forced [ETA 58m23s]
<bb-m-labs>
I'll give a shout when the build finishes