ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at · logs at · IRC meetings each Monday at 1800 UTC · next meeting August 24th
Yehowshua has joined #nmigen
<Yehowshua> whitequark, I think you can use subsequent to allow you to start writing a VCD when you hit a certain condition
<Yehowshua> Is there a more natural way?
<Yehowshua> No wait, that doesn't work
<Yehowshua> `Cannot start writing waveforms after advancing simulation time`
Yehowshua has quit [Remote host closed the connection]
<whitequark> Yehowshua: (assuming you read logs) yeah this is actually something that isn't possible at all at the moment
<whitequark> we can fix it
<moony> how can I tie a signal's reset line to some other signal? (I want to reset a particular signal to it's default on command)
<whitequark> so, bad news: there's no such thing as a "signal's reset line"
<whitequark> good news: you can just assign to it at the very end of a module
<moony> ah, alright. I'll handle this some other way then.
<whitequark> in fact, this is how synchronous resets are implemented internally
<whitequark> it's simply an `m.If(ResetSignal()): m.d.sync += s.eq(s.reset)` for every signal driven by the module
<moony> mk
<moony> anyone know a good way to get the index of the most significant set bit?
<whitequark> there was one, let me dig it out
<awygle> whitequark: porting Record to ValueCastable and all the tests pass but one :( specifically test_iter, because it does repr(r[0]), which somehow used to give (slice (rec r data stb) 0:1) but now because we cast in the Slice constructor we get a slice of the lowered ValueCastable instead
<whitequark> awygle: just change the test
<awygle> really? representations aren't stable?
<whitequark> i don't consider the precise representations of returned AST fragments a part of stability guarantee
<whitequark> yeah
<awygle> oh good
<awygle> so much easier lol
<whitequark> i mean, take a look at how many internal AST nodes we have
<whitequark> if representations were stable we couldn't change those
<awygle> yup
<whitequark> it is also just generally unlikely to break anything in first place
<awygle> i agree
jaseg has quit [Ping timeout: 240 seconds]
jaseg has joined #nmigen
peepsalot has joined #nmigen
<whitequark> awygle: poke
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 258 seconds]
PyroPeter_ is now known as PyroPeter
Degi has quit [Ping timeout: 240 seconds]
Degi has joined #nmigen
* whitequark stares at awygle
<whitequark> did i miscount 9 hours
hitomi2507 has joined #nmigen
<awygle> no, i miscounted my ability to remain awake
<whitequark> ah
<whitequark> happens!
<awygle> more and more, unfortunately
* awygle looks forward to his vacation
<d1b2> <edbordin> welp, I caved and started shipping sby in my nightly builds
<d1b2> <edbordin> not sure what will happen with the ascyncio pr upstream. have to admit I'm not sure if I have the energy to persist with it long term
<whitequark> it does seem like there's a sort of impasse at the moment
<whitequark> so i don't blame you for it one bit
<whitequark> if something it's probably now on me to figure that out with sby maintainers
<whitequark> so, feel free to just abandon it, at least for the moment
<d1b2> <edbordin> it sounded like really what they need is more test coverage. but I'm not sure I am the right person to help with that
<d1b2> <edbordin> given a lot of the bugs around that stuff aren't deterministic idk how to reliably reproduce them in a test anyway
<whitequark> yeah, it's challenging
<d1b2> <edbordin> but I can very much sympathise with "it works for our customers, it is not in our interest to risk breaking it"
<whitequark> anyway, thanks for working on it so far! i appreciate it, and i think that, at worst, your PR would be a solid foundation for mine, if I ever get around toit
<d1b2> <edbordin> np, likewise thanks for all your work on... basically every tool in this ecosystem 😛
<whitequark> hehe :)
<Lofty> moony: still need to know the MSB?
<Lofty> Hopefully that sent
<moony> Lofty: It'd be nice, would make the dumb thing i'm doing slightly faster
<whitequark> oh sorry i completely forgot about it
<Lofty> Do you need the *number*, or the actual bit?
<moony> (I implemented circle-circle/circle-rect/rect-rect collision detection in hardware. It somehow works as intended.) the number.
<Lofty> You could probably metaprogram it and let the synthesiser optimise it
<Lofty> De Bruijn multiplication is an option, although it probably doesn't map well to hardware
<moony> I'll probably think it over while taking a look at the current sqrt algorithm i'm using (an iterative integer approximation. Effectively floor(sqrt(n)))
<DaKnig> Yehowshua: workaround for gtkwave- you can have a signal that indicates "condition met" - then you can click on it (on the left side of the screen) and press "right" - this would bring you to the next state change.
Asu has joined #nmigen
emeb_mac has quit [Quit: Leaving.]
hitomi2507 has quit [*.net *.split]
PyroPeter has quit [*.net *.split]
DaKnig has quit [*.net *.split]
falteckz_ has quit [*.net *.split]
happycube has quit [*.net *.split]
d1b2 has quit [*.net *.split]
TiltMeSenpai has quit [*.net *.split]
MadHacker has quit [*.net *.split]
hitomi2507 has joined #nmigen
falteckz_ has joined #nmigen
PyroPeter has joined #nmigen
MadHacker has joined #nmigen
DaKnig has joined #nmigen
TiltMeSenpai has joined #nmigen
happycube has joined #nmigen
d1b2 has joined #nmigen
Asu has quit [Quit: Konversation terminated!]
Asu has joined #nmigen
feldim2425 has quit [Quit: ZNC 1.8.x-git-91-b00cc309 -]
feldim2425 has joined #nmigen
chipmuenk has joined #nmigen
chipmuenk1 has joined #nmigen
chipmuenk1 has quit [Client Quit]
chipmuenk has quit [Ping timeout: 244 seconds]
chipmuenk has joined #nmigen
jeanthom has joined #nmigen
lkcl_ has quit [Ping timeout: 264 seconds]
lkcl has joined #nmigen
chipmuenk1 has joined #nmigen
chipmuenk has quit [Ping timeout: 240 seconds]
chipmuenk has joined #nmigen
chipmuenk2 has joined #nmigen
chipmuenk1 has quit [Ping timeout: 260 seconds]
chipmuenk2 is now known as chipmuenk1
chipmuenk has quit [Ping timeout: 244 seconds]
chipmuenk1 is now known as chipmuenk
chipmuenk has quit [Read error: Connection reset by peer]
chipmuenk has joined #nmigen
chipmuenk has quit [Quit: chipmuenk]
chipmuenk1 has joined #nmigen
chipmuenk1 has quit [Client Quit]
chipmuenk has joined #nmigen
chipmuenk has quit [Client Quit]
chipmuenk has joined #nmigen
chipmuenk1 has joined #nmigen
chipmuenk1 has quit [Client Quit]
chipmuenk has quit [Ping timeout: 244 seconds]
chipmuenk has joined #nmigen
<moony> was talking with someone, and they got confused about `The core nMigen project provides an open-source toolchain for developing hardware based on synchronous digital logic using the Python programming language` specifically saying synchronous (they thought nMigen didn't support async logic). Anyone know what that's actually supposed to mean?
<cr1901_modern> D-latches aren't supported
lkcl_ has joined #nmigen
lkcl has quit [Ping timeout: 240 seconds]
<DaKnig> in VHDL/Verilog you can describe any digital haradware . in nmigen you cant.
<DaKnig> you have sync/async distinction on the level of the lang
<daveshah> If you _really_ need D-latches et al., you can still instantiate whatever device-specific primitive you need for that in nMigen, but this loses the safety/determinism guarantees
<daveshah> Unlike Verilog and VHDL, you can't accidentally create a D-latch
<d1b2> <DX-MON> arguably, in modern systems there is no reason for a D-latch considering D flip-flops exist and are cheap
<moony> what'd be the best way to create an all-ones value for any length signal? (working with some signal-width-generic code)
<moony> i.e. generate 0x1FFFF for a 17 bit signal
<DaKnig> the old C trick
<DaKnig> `-1`
<DaKnig> `C(-1,17)`
<DaKnig> that'd give you an unsigned signal with 17 bits , all 1
<moony> alright, i was going to do that but wasn't 100% sure it'd behave as I wanted :p
<miek> i'm pretty sure that'll give you a signed signal
<DaKnig> if you want to have it 100% defined (im not sure it is) you can use signed signal
<DaKnig> signed Value I mean
<DaKnig> yes its signed, does it matter :)
<DaKnig> if it does, just use `C(-1,unsigned(17))`
chipmuenk has quit [Quit: chipmuenk]
chipmuenk has joined #nmigen
chipmuenk has quit [Client Quit]
chipmuenk has joined #nmigen
chipmuenk has quit [Client Quit]
chipmuenk has joined #nmigen
cr1901_modern has quit [Ping timeout: 258 seconds]
cr1901_modern has joined #nmigen
chipmuenk1 has joined #nmigen
chipmuenk has quit [Ping timeout: 256 seconds]
chipmuenk1 has quit [Ping timeout: 244 seconds]
chipmuenk has joined #nmigen
chipmuenk has quit [Client Quit]
chipmuenk has joined #nmigen
chipmuenk has quit [Ping timeout: 260 seconds]
emeb has joined #nmigen
emeb_mac has joined #nmigen
chipmuenk has joined #nmigen
hitomi2507 has quit [Quit: Nettalk6 -]
chipmuenk1 has joined #nmigen
chipmuenk has quit [Ping timeout: 244 seconds]
chipmuenk1 is now known as chipmuenk
<DaKnig> for what Im doing I need an integer divider that takes the least number of cycles possible per div, even if it means greatly sacrificing the max clock speed; what should I use?
<DaKnig> div by a Signal, I mean.
<DaKnig> I cant expect `a/b` to just compile, right
<moony> ack. Anyone know how to properly stringify fixed point numbers? The method to do so seems ti be absolutely buried under cruft. (this is for debugging, so no i'm not doing string stuff in hardware like a madman)
<DaKnig> if you have a pythoninteger `i` that is actually 16.8 fixed point number, just use `str(i/(1<<8))`
<moony> DaKnig: will that work for 64.32 by just removing the 8 and putting in 32?
<DaKnig> think about it for a second
<DaKnig> think how fixed point works
<DaKnig> I think the answer would be immediately obvious
<DaKnig> if you have ever implemented fixed point in C on top of int, you already get used to <<8 for 24.8 fixed point
<moony> DaKnig: Yea the answer seemed obvious to me (yes, it would), just wanted to make sure :P
emeb_mac has quit [Quit: Leaving.]
<d1b2> <TiltMeSenpai> is there a way to have a sim-only string "signal" to help with debugging a CPU design
<DaKnig> @TiltMeSenpai a better solution- why not use an enum?
<DaKnig> and have a function that prints the enum when you want it? can attach this to the sim too
<d1b2> <TiltMeSenpai> bc some bits in the opcodes are being used to determine registers/etc
<DaKnig> yeah; just set that enum signal to the message you want to pass (and let it be just "nothing" for most of the time) and assign it the value you'd assign a string
<d1b2> <TiltMeSenpai> I mean I could have a signal holding an Enum and only add it during simulation maybe?
<DaKnig> wdym "just add it during sim"?
<DaKnig> if its not exposed and used by other things in synth, its gonna be optimized out
<d1b2> <TiltMeSenpai> I don't need the enum when an actual design is synthesized
<d1b2> <TiltMeSenpai> oh, that's a good point
<DaKnig> dont underestimate the synth tool :)
<DaKnig> its a tool; if you know it well, you can depend on it.
<d1b2> <TiltMeSenpai> I trust wq and I'm not meaning to disparage nmigen, but "rely on the optimization" inherently makes me feel uncomfortable
<awygle> TiltMeSenpai: if you want to visualize a signal in a semantically meaningful way, you can give it a custom display function and it'll use that when outputting to vcd
<awygle> is that what you're after?
<DaKnig> TiltMeSenpai nmigen doesnt optimize tho
<DaKnig> it's the backend
<d1b2> <TiltMeSenpai> wouldn't doing that mean I need to write a second instruction decoder?
<awygle> you can probably share code lol
<DaKnig> well; you need that for your string idea too
<ktemkin> TiltMeSenpai: I wouldn't even necessarily call "removed because unused" an optimization, strictly
<awygle> alternately if platform is null you can be reasonably sure you're in sim
<awygle> although I don't think that's guaranteed
<ktemkin> TiltMeSenpai: imagine yourself netlisting / routing -- in a very simplified sense, you'd be traversing a graph from output to input
<awygle> (I support your discomfort with "the backend will remove it", personally, although I'm pretty sure it is true it makes me feel icky)
<ktemkin> building and optimizing the nets that fan into a final signal (the whole structure of which is often called the "logic cone")
<d1b2> <TiltMeSenpai> hmm that does make me feel better
<d1b2> <TiltMeSenpai> I mean opcodes are 8 bits, so even if the debug signal ends up in a physical design somehow, I guess it's not the end of the world?
<ktemkin> things that don't wind up connected in that graph wind up not translating into logic as a necessary consequence of routing
<DaKnig> if you want to be 100% sure that something is implemented in the intended way, go and do everything explicitly; you probably dont wanna use Verilog or VHDL- use whatever it compiles into.
<d1b2> <TiltMeSenpai> if I create a Signal(enum), that decodes into a String in the vcd right? (I can just check this with my own code)
<DaKnig> if you are making a CPU you want an assembler; and probably a simple disassembler wouldnt be too hard :)
<DaKnig> so reversing the meaning from your 8bit opcodes wouldnt be that hard
<awygle> yes, enums have a display function by default
<awygle> (that's not the right word... Whatever it's called they have it)
<d1b2> <TiltMeSenpai> I have a disassembler, sorta, but it doesn't correlate the internal cpu state
<ktemkin> awygle: decoder?
chipmuenk has quit [Ping timeout: 244 seconds]
<awygle> prolly
<d1b2> <TiltMeSenpai> whoo that works
<d1b2> <TiltMeSenpai> now to figure out why the heck I'm randomly returning to 0x0 😦
chipmuenk has joined #nmigen
chipmuenk has quit [Ping timeout: 244 seconds]
chipmuenk has joined #nmigen
chipmuenk1 has joined #nmigen
chipmuenk has quit [Ping timeout: 244 seconds]
chipmuenk1 is now known as chipmuenk
jeanthom has quit [Ping timeout: 258 seconds]
Ultrasauce has quit [Quit: Ultrasauce]
Ultrasauce has joined #nmigen
chipmuenk has quit [Quit: chipmuenk]
Asu has quit [Quit: Konversation terminated!]
_whitelogger has joined #nmigen
electronic_eel_ has joined #nmigen
electronic_eel has quit [Quit: No Ping reply in 180 seconds.]
<DaKnig> is there a construct that's like a queue, where I can put multiple things in at the same clock and then take them out one at a time?
<DaKnig> well I guess a shift register would do this; shift registers seem to solve everything for me recently.
<DaKnig> is there something more elegant for this?
<DaKnig> maybe some kinda FIFO?
aaaa has quit [Ping timeout: 246 seconds]
aaaa has joined #nmigen
<cesar[m]> TiltMeSenpai: You can create Signals at simulation time, outside any Modules, and use them in your simulation process.
<cesar[m]> When calling write_vcd, pass the new signals as a list in the traces parameter.
<cesar[m]> See:;a=blob;f=src/nmutil/test/;h=525cb85259591c24fa49934b31008b1b5b300dd8;hb=HEAD#l385
<cesar[m]> Here are some examples of custom decoders for string traces:
emeb has quit [Quit: Leaving.]