ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at https://github.com/nmigen · logs at https://freenode.irclog.whitequark.org/nmigen
<_whitenotifier-9> [nmigen] whitequark commented on issue #228: Reconsider simulator interface - https://git.io/JfYHI
Degi has quit [Ping timeout: 260 seconds]
Degi has joined #nmigen
cckonnok has joined #nmigen
chipmuenk has joined #nmigen
____ has joined #nmigen
cckonnok has quit [Ping timeout: 272 seconds]
cckonnok has joined #nmigen
Asu has joined #nmigen
lkcl has quit [Ping timeout: 260 seconds]
emily has quit [Quit: killed]
david-sawatzke[m has quit [Quit: killed]
jfng has quit [Quit: killed]
emily has joined #nmigen
david-sawatzke[m has joined #nmigen
jfng has joined #nmigen
lkcl has joined #nmigen
<anuejn_> is it possible to somehow get the frequency of a clockdomain in nmigen?
anuejn_ is now known as anuejn
<anuejn> eg. for building a serial peripheral that generates the right baudrate or if impossible raises an error during build
<whitequark> anuejn: not in a peripheral, no
<whitequark> consider that you can configure a PLL at runtime
<whitequark> or for example feed the FPGA with a reference clock source that isn't known in advance
<whitequark> there *is* platform.default_clk_period, for the simple case where all you have is a single onboard oscillator
<whitequark> but it's not sufficient for implementing a reusable peripheral
<anuejn> hm... ok
<anuejn> so you dont think that it would be useful to be able to mark a clockdomain as "stable" and attach a Clock object to it?
<whitequark> anuejn: no, don't think so
<whitequark> you'll be covering slightly more of the common case while making it way harder to cover the most generic case with variable clock rate
<whitequark> (plus the plumbing for this would be *nasty*, but that's secondary)
<whitequark> by the way, the main reason Clock() exists is actually physical layout
<whitequark> i.e. Clock exists so that P&R knows what timing target it has to meet
<whitequark> the fact that you also get default_clk_period is essentially a nice bonus rather than a primary outcome
<anuejn> hm... okay
cckonnok is now known as enok
<_whitenotifier-9> [nmigen] andresdemski commented on issue #228: Reconsider simulator interface - https://git.io/JfOLl
<lkcl> one thing that Bluespec has is a special template which provides a means for signals to cross over clock-domains
<lkcl> signal-in, clock1 on one side, signal-out, clock2 on the other
<lkcl> likewise another template for Reset signals which are from alternative domains
<lkcl> the reason for the existence of this "block" (template) is that if you get it wrong, you have digital sampling errors
<lkcl> i helped IIT Madras with a GPIO multiplexer 18 months ago, and we had to use this block to transfer the signals coming from a UART over to the main core
<lkcl> the UART obviously had a completely different clock from the core.
<lkcl> anuejn: i've seen somewhere a "sampling" PLL by dan gisselquist which can be used to create a UART isochronous clock from a faster (core-domain) clock
<lkcl> ultimately it's a countdown timer however it has auto-synchronisation, watching for the leading edge of the incoming UART RX signal as a way to adjust the "clock"
<lkcl> anuejn: that sounds more like what you actually need.
<lkcl> anuejn: i believe it was this - https://zipcpu.com/dsp/2017/12/14/logic-pll.html
<lkcl> and this is proooobably its implementation: https://github.com/ZipCPU/dpll/blob/master/rtl/sdpll.v
<lkcl> the "counter" effectively represents the "frequency"
<lkcl> actually 1 / frequency.
<lkcl> all HDL is at this level.
<lkcl> you don't get given "nice" things like "a frequency", because "frequency" is a man-made abstract concept representative of time, completely unsuited to representing in a binary gate-level (transistor) form
<lkcl> if you want a "frequency", you'll have to construct a hardware-level (binary, gate-level) representation of that abstract concept, yourself.
<lkcl> which dan successfully does in that code by using a "counter"
<_whitenotifier-9> [nmigen] whitequark commented on issue #228: Reconsider simulator interface - https://git.io/JfOtG
Asuu has joined #nmigen
Asu has quit [Ping timeout: 246 seconds]
Asu has joined #nmigen
Asuu has quit [Ping timeout: 246 seconds]
<vup> whitequark: did you see my question about clock constraints with vivado?
<whitequark> vup: nope. can you repeat?
<whitequark> lkcl: nmigen has FFSynchronizer and ResetSynchronizer for these tasks in lib.cdc
<vup> sure, for some signals platform.add_clock_constraint doesn't seem to work (meaning vivado complains it can't find the net specified in the constraints file)
<vup> adding KEEP=TRUE makes it work a bit better
<whitequark> vup: can you file an MCVE?
<whitequark> I believe this was reported and fixed before
<vup> this is for clocks ultimately coming from an instance, so maybe thats causing problems?
<whitequark> ahhh
<whitequark> #301 was the previous case
<vup> but yeah, I will try to create a MCVE
<_whitenotifier-9> [nmigen] rroohhh opened issue #373: platform.add_clock_constraint does not work for instances with vivado - https://git.io/JfOm5
<_whitenotifier-9> [nmigen] rroohhh commented on issue #373: platform.add_clock_constraint does not work for instances with vivado - https://git.io/JfOYl
<_whitenotifier-9> [nmigen] whitequark commented on issue #373: platform.add_clock_constraint does not work for instances with vivado - https://git.io/JfOYB
<_whitenotifier-9> [nmigen] rroohhh commented on issue #373: platform.add_clock_constraint does not work for instances with vivado - https://git.io/JfOYS
<_whitenotifier-9> [nmigen] whitequark commented on issue #373: platform.add_clock_constraint does not work for instances with vivado - https://git.io/JfOYp
<_whitenotifier-9> [nmigen] whitequark commented on issue #359: Python chokes on simulated memories of depth greater than ~3k - https://git.io/JfOOU
rohitksingh has quit [Ping timeout: 244 seconds]
<_whitenotifier-9> [nmigen] rroohhh opened issue #374: Bad error message when using Signal in add_clock_constraint not actually used in the design - https://git.io/JfOO4
<_whitenotifier-9> [nmigen] whitequark commented on issue #374: Bad error message when using Signal in add_clock_constraint not actually used in the design - https://git.io/JfOO6
<_whitenotifier-9> [nmigen] whitequark edited a comment on issue #374: Bad error message when using Signal in add_clock_constraint not actually used in the design - https://git.io/JfOO6
<_whitenotifier-9> [nmigen] whitequark commented on issue #373: platform.add_clock_constraint does not work for instances with vivado - https://git.io/JfOOH
<_whitenotifier-9> [nmigen] andresdemski commented on issue #228: Reconsider simulator interface - https://git.io/JfO3T
<_whitenotifier-9> [nmigen] rroohhh opened issue #375: Net names are not escaped properly for vivado tcl - https://git.io/JfO3L
<_whitenotifier-9> [nmigen] whitequark commented on issue #228: Reconsider simulator interface - https://git.io/JfO3Z
ademski has joined #nmigen
<_whitenotifier-9> [nmigen] rroohhh commented on issue #375: Net names are not escaped properly for vivado tcl - https://git.io/JfO3M
<_whitenotifier-9> [nmigen] rroohhh commented on issue #374: Bad error message when using Signal in add_clock_constraint not actually used in the design - https://git.io/JfO39
<_whitenotifier-9> [nmigen] whitequark commented on issue #375: Net names are not escaped properly for vivado tcl - https://git.io/JfO3A
chipmuenk has quit [Quit: chipmuenk]
<_whitenotifier-9> [nmigen] rroohhh commented on issue #375: Net names are not escaped properly for vivado tcl - https://git.io/JfOsa
<_whitenotifier-9> [nmigen] whitequark commented on issue #375: Net names are not escaped properly for vivado tcl - https://git.io/JfOsK
<_whitenotifier-9> [nmigen] rroohhh commented on issue #375: Net names are not escaped properly for vivado tcl - https://git.io/JfOGZ
ademski has quit [Remote host closed the connection]
chipmuenk has joined #nmigen
enok has quit [Remote host closed the connection]
enok has joined #nmigen
enok has quit [Remote host closed the connection]
enok has joined #nmigen
enok has quit [Ping timeout: 272 seconds]
<awygle> something which occasionally still trips me up in nmigen is the blurry line between comb-assigning two signals together and python-assigning one to the other
<awygle> idk why it makes me uneasy when it comes up but it does
enok has joined #nmigen
enok has quit [Remote host closed the connection]
enok has joined #nmigen
Asuu has joined #nmigen
Asu has quit [Ping timeout: 256 seconds]
<whitequark> awygle: yeah, it's unfortunate, and a common source of confusion
<whitequark> i should cover that in the doc i'm writing rn
<awygle> is there a preferred approach?
<whitequark> i'm not sure when the latter wouldn't be a mistake?
<whitequark> i.e. `a = Signal(); b = Signal(); a = b` is a bug with virtual certainty
<Sarayan> doesn't it blow up already?
<awygle> what about e.g. `b = rec.b`? as opposed to `b = Signal(); m.d.comb += b.eq(rec.b)`?
<awygle> i am sufficiently well-versed at this point not to make the mistake of thinking = means eq, but i do run into the "i want a subset of this <thing>, with a name" case pretty often
<whitequark> i would normally use the former if i want just a plain alias with no particular thought going into it
<whitequark> i would use the latter most notably if i want a separate vcd wire
<awygle> Mm I see
tnt has quit [*.net *.split]
chipmuenk has quit [Quit: chipmuenk]
tnt has joined #nmigen
<awygle> god i hate testing hdl
<whitequark> huge mood
<whitequark> (i wonder if we can make that better?..)
<awygle> yeah i was just thinking about what would help
<awygle> i wish i could click on a transition in the waveform view and it would take me to the source file of the line that lead to that transition, with all the variables annotated with their current values at the time of that transition
<whitequark> oh
<awygle> but now i'm talking about essentially a custom IDE lol
<whitequark> gtkwave can literally do that
<awygle> ... nani?
<whitequark> uh, moment
<whitequark> there's something called "verilog stems files"
<awygle> that seems cool
<awygle> a bit roundabout? but conceptually quite nice
<awygle> i'm assuming this is _not_ what the .gtkw files produced by nmigen are :p
<whitequark> nop
<whitequark> the whole affair is *possible* to go through but is kinda nightmarish to get to work really well
<awygle> "verilog source code must first be compiled with xml2stems" uhhh... does it get turned into xml at some point or...
<whitequark> verilator xml
<whitequark> ast dump
<awygle> ah. did not know such existed but i guess i'm not surprised
<whitequark> pretty damn cursed
<whitequark> you can get c++ ast dumps from gcc too
<whitequark> also in xml
<awygle> is any of this standardized at all, or just gtkwave and verilator working together on custom made-up stuff
<awygle> a la fst
<whitequark> verilator xml is def *not* standard
<awygle> (which don't get me wrong is pretty sweet)
<awygle> brief google suggests "stems" is not standard either
<whitequark> stems files appear to have been invented by rtlbrowser
<whitequark> which uses this frontend: https://www.systutorials.com/docs/linux/man/1-vermin/
<whitequark> very appropriate name imo
<awygle> mhm
<awygle> lol
<awygle> alternately maybe i should start using formal verification instead of simulation to test my hdl lol
____ has quit [Quit: Nettalk6 - www.ntalk.de]
<awygle> i'm sure that can only make things easier
<whitequark> some parts easier, some parts harder ime
<awygle> yeah same tbh
<whitequark> jesus christ xml2stems has its own XML lexer/parser
<hell__> i never knew you could compile the ascii representation of a box of lego technic pieces after it fell to the floor
<whitequark> awygle: ok so rtlbrowse can't be reused
<whitequark> it's tied to verilog
<whitequark> and also i find that codebase disturbing on a fundamnetal level
* hell__ runs away
<whitequark> it doesn't even bother to parse the output of its own emitter correctly
enok has quit [Ping timeout: 272 seconds]
<whitequark> awygle: ok so i kinda wanted to tell you "oh i can totally implement this for nmigen" but it turns out that the way gtkwave works is just completely batshit insane
<Sarayan> news at 11
<whitequark> rtlbrowse and gtkwave communicate through a chunk of shared memory, where gtkwave plops a bunch of random data into it, including a pointer to one of the 4 (four) raw representations of the file formats it can parse
<whitequark> and then rtlbrowse reuses gtkwave's code to decode whichever four of those is selected
<whitequark> you know things are going to be Good when you see a struct field "unsigned cygwin_remote_kill : 1;" and know it is placed squarely in shared memory between two C applications
* hell__ shakes in fear under a pile of mainboards
<Sarayan> nobody wants to take responsability? :-)
<awygle> it was fun to walk away for a couple minutes and come back to whitequark's progressively-more-serious "oh god"s
<awygle> whitequark: thanks for checking :) i didn't really expect you to just flip this out in a couple of minutes, no worries
<awygle> whitequark: is the way in which FHDLTestCase implements assertFormal the best way to do a formal test case in nmigen still? is it intended to be used by non-internal-nmigen code?
<Sarayan> when wq reaches "oh god" mode, it's always promising
<Sarayan> given she's seen pretty much everything
<awygle> i gotta admit, shared memory bitfields is Up There
<Sarayan> she could do a blade running monologue easy
<Sarayan> blade runner
<whitequark> awygle: do you know how the dual trace view in gtkwave works?
<sorear> expecting two different compilers to do the same thing with bitfields seems optimistic
<whitequark> it has a single host window that embeds two gtkwave processes that poke each other's GUIs through a shared memory block
<whitequark> it has a function called "strcpy2_into_new_context".
<awygle> C-Gates toggling asynchronously off the Sennheiser Bricks
<whitequark> GLOBALS->whoami=malloc_2(strlen(argv[0])+1);/* cache name in case we fork later */
<whitequark> yes it's a GUI program that forks.
<whitequark> on top of the shared memory shenanigans, it *also forks*
<sorear> C-elements?
<whitequark> the help text is constructed using about 300 lines of preprocessor, and *the amount of printf substitutions in the help text depends on the configure options*. in some cases it has more %s than in others
<awygle> i have always heard it called a "c-gate" but the wiki page is listed under "element" so you're more likely to be colloquially correct here i spose
<whitequark> i take my words back. "batshit insane" is far too mild to describe... this
<awygle> whitequark: you know what they say about abysses
<Sarayan> wq: almost... artistic
<whitequark> this is the most deranged code i've ever seen used in production
<whitequark> by a massive margin
<sorear> I think most of my point was to confirm the concept
<awygle> in that case yes, that is what i was referring to
<sorear> when you're writing code and you can't because %10$s isn't portable
<whitequark> you know, the thing where if you open an empty vcd file it does exponential backoff retrying that open while totally blocking the entire GUI thread should have been a sign
<Sarayan> it... what?
<Sarayan> just... what?
<awygle> sometimes you want to serve your vcd files over a TCP socket
<whitequark> it tries to open the file again and again at 2**n s intervals, with increasing n
<sorear> tail -f (GNOME edition)
<Sarayan> flblblbllblbblblbblblb?
<whitequark> so your only option at that point, besides killing it, is to give it a VCD file and hope the next timeout is still in seconds and not in minutes
<awygle> despite the utter lack of incrementality in vcd
<awygle> at one point i wrote a Rust FFI binding to the fst library, but i didn't actually read the code, and now i'm thinking maybe i should have
<Sarayan> is thta rfc1149-compatibility?
<jfng> gtkwave did that to me like yesterday
<jfng> it happens when you open a .gtkw that doesnt point to a valid .vcd
<awygle> whitequark: are you enjoying your dive into depravity, and/or is it possible to discuss what you'd like to see in a stream proposal at the present time?
<Sarayan> I need to go to bed, but you people are going to give me nightmares
<awygle> buenas noches
<whitequark> awygle: i actually have something relatively important to discuss with you wrt streams/dataflow but i've been far too busy to really give it a good thought
<whitequark> i'm going to need to finish what i'm doing with docs first
<awygle> mk, nbd :)
* awygle goes back to trying to write formal test cases
<hell__> and I complain about this memory initialization code...
<whitequark> awygle: I THOUGHT YOU WERE JOKING
<whitequark> WHY THE FUCK DOES IT READ ANYTHING OVER THE NETWORK
<whitequark> oh it uh
<whitequark> has a control socket that accepts tcl commands?
<awygle> on the one hand i was joking, on the other hand, that's the only reason it could possibly want to do exponential backoff
<whitequark> no it doesn't do that in the network path
<awygle> other than just pure stupidity which i assume is rare
<whitequark> #undef VCD_BSEARCH_IS_PERFECT/* bsearch is imperfect under linux, but OK under AIX */
<whitequark> what do you mean by "bsearch is imperfect".
<hell__> why do they know it's ok under AIX
<awygle> lulz
<awygle> hey real quick, how come i can't use Past on a record?
<whitequark> if(ch<=' ') continue;/* val<=' ' is a quick whitespace check */
<whitequark> break;/* (take advantage of fact that vcd is text) */
<whitequark> i uh
<awygle> do i need to lower it?
<whitequark> awygle: you should be able to
<awygle> E TypeError: Sampled value must be a signal or a constant, not (rec unslip_source.data data)
<whitequark> oh
<awygle> if i take the field specifically then it works, which makes sense
<whitequark> ok yeah i see why
<whitequark> it's a limitation of the existing SampleLowerer
<whitequark> it will be fixed with the other *Inserter improvements, immutable AST, etc
<whitequark> but probably no earlier
<awygle> mk
<whitequark> awygle: ok yeah it doesn't stream vcd over network
<whitequark> it's worse
<whitequark> it can stream vcd over shared memory
<awygle> i'm rapidly falling in love with this terrible program
<awygle> how many sins can you commit
<hell__> i think this pile of UEFI-style-after-clang-format C I am trying to make some sense out of is fine compared to gtkwave
<awygle> whitequark: i am pretty sure the nmigen design is flat-out incompatible with things like slides 33 and 34 here, even in the formal case. is that correct? http://www.clifford.at/papers/2017/smtbmc-sby/slides.pdf
<whitequark> awygle: yup. no ripple counters or sr gates in nmigen
<whitequark> other than as instances
<awygle> whitequark: well, i didn't expect it to be synthesizable, just looking for a convenient way to say "if X is true on a rising edge of Y, then Z must be true on the next rising edge of Y"
<awygle> i can do it with registers and whatnot though of course
<whitequark> Rose/Fell don't help?
<awygle> they help but they're not the whole story, i think. i have to do `if Rose(Y), store <register>. also, if Rose(Y) and <stored register> == X, then Assert(<register> == Z)`
<whitequark> right, that's true
<awygle> what i really want is like, `Past(<signal>, N, Rose(Y))` (pseudocode). the value of <signal> on the N-ago rising edge of Y
<whitequark> i'm not entirely sure what the nmigen verification story is going to be
<whitequark> hm
<whitequark> is that even expressible in SMT?
<awygle> it's not particularly critical, as i said i can just do it with registers
<whitequark> wait, what does "N-ago rising edge" mean?
<awygle> for example, in this pseudocode `Past(x, 2, Rose(y))` would return the value of X two rising edges of Y ago
<awygle> which, if y was the clock, would be the same as `Past(x, 2)`
<whitequark> would this add an implicit assumption that in your trace length there were two rising edges somewhere?
<whitequark> oh, i think i see what you mean
<awygle> i suppose it would? i think it would depend on the context in which it was used
<whitequark> you basically want Past clocked by y
<awygle> yes
<awygle> and in SVA you literally just do that. `assert property ((@ posedge SIGNAL) ...)` is totally fine
<awygle> and i think there's an equivalent version of $past
<whitequark> hmmm
<awygle> $past( expression1 [, number_of_ticks] [, expression2] [, clocking_event]) <- yeah it's the last argument to the full form of $past
<whitequark> i mean we could probably just extend Past to do that
<awygle> and also "expression2 is used as a gating expression for the clocking event" which could be a better way to accomplish the same thing
<awygle> since it's more in line with nmigen's model
<whitequark> ayup
<whitequark> awygle: oh btw, which editor do you use?
<whitequark> because i know how to add integration like that faaairly cheaply to sublime
<awygle> whitequark: vim
<awygle> but i could use sublime
<awygle> everybody tells me how great it is
<awygle> never had a reason to try ti
<whitequark> it's ok
Asuu has quit [Quit: Konversation terminated!]
<awygle> idk i like vim
<awygle> :( the formal counterexample traces don't give me FSM state names, just values :(
<awygle> i understand why but damn i was getting used to that lol
<whitequark> awygle: there is alreay about 2/3 of the infra
<whitequark> nmigen writes attributes for yosys
<whitequark> yosys deefines attributes for enums
<whitequark> just have to get sby to take those into account