sb0 changed the topic of #m-labs to: https://m-labs.hk :: Mattermost https://chat.m-labs.hk :: Logs http://irclog.whitequark.org/m-labs
<_whitenotifier> [smoltcp] Success. The Travis CI build passed - https://travis-ci.org/m-labs/smoltcp/builds/595376424?utm_source=github_status&utm_medium=notification
harryho has joined #m-labs
cr1901_modern1 has joined #m-labs
cr1901_modern has quit [Ping timeout: 240 seconds]
_whitelogger has joined #m-labs
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined #m-labs
m4ssi has joined #m-labs
harryho has quit [Remote host closed the connection]
Stary has quit [Quit: ZNC - http://znc.in]
cr1901_modern has quit [Quit: Leaving.]
jfng has quit [Ping timeout: 250 seconds]
Stary has joined #m-labs
lynxis has quit [Ping timeout: 250 seconds]
jryans has quit [Ping timeout: 250 seconds]
lynxis has joined #m-labs
marble[m] has quit [Ping timeout: 240 seconds]
xobs has quit [Ping timeout: 250 seconds]
jayaura has quit [Ping timeout: 240 seconds]
xobs has joined #m-labs
jryans has joined #m-labs
marble[m] has joined #m-labs
jfng has joined #m-labs
jayaura has joined #m-labs
jfng has quit [Ping timeout: 248 seconds]
jfng has joined #m-labs
marble[m] has quit [Ping timeout: 250 seconds]
marble[m] has joined #m-labs
jryans has quit [Ping timeout: 248 seconds]
jryans has joined #m-labs
X-Scale` has joined #m-labs
edef_ has joined #m-labs
edef has quit [Killed (wolfe.freenode.net (Nickname regained by services))]
stekern_ has joined #m-labs
X-Scale has quit [Ping timeout: 268 seconds]
kristianpaul has quit [Ping timeout: 268 seconds]
Astro- has quit [Ping timeout: 268 seconds]
felix_ has quit [Ping timeout: 268 seconds]
stekern has quit [Ping timeout: 268 seconds]
remote_user__ has quit [Ping timeout: 268 seconds]
cyrozap has quit [Ping timeout: 268 seconds]
fengling has quit [Ping timeout: 268 seconds]
nurelin has quit [Ping timeout: 268 seconds]
kristian1 has joined #m-labs
felix___ has joined #m-labs
X-Scale` is now known as X-Scale
nurelin has joined #m-labs
Astro-_ has joined #m-labs
fengling has joined #m-labs
cyrozap has joined #m-labs
felix___ is now known as felix_
sb0 has joined #m-labs
kristian1 has quit [Quit: WeeChat 1.9.1]
kristianpaul has joined #m-labs
<mtrbot-ml_> [mattermost] <weidazhang> @sb10q
<mtrbot-ml_> [mattermost] <weidazhang> >>* what exactly should be done with the result of the frequency counter.
<mtrbot-ml_> [mattermost] <weidazhang> Please give me a formal algorithm with detailed equations that take as
<mtrbot-ml_> [mattermost] <weidazhang> input the raw value from the frequency counter and produce values that
<mtrbot-ml_> [mattermost] <weidazhang> can be put directly into the Si549 and/or at designated places in the
<mtrbot-ml_> [mattermost] <weidazhang> filter algorithms.
<mtrbot-ml_> [mattermost] <weidazhang>
<mtrbot-ml_> [mattermost] <weidazhang> Do you mean the when running how do the tags go to filter?
<mtrbot-ml_> [mattermost] <weidazhang> Or do you mean when calibration (starting), how do the register values calculated from the tags?
<mtrbot-ml_> [mattermost] <sb10q> what are "tags"?
<mtrbot-ml_> [mattermost] <sb10q> also I still don't know how you are doing the frequency counting
<sb0> whitequark: doesn't seem to crash with "sys.stdout.buffer.write(b".")"
<whitequark> ZirconiumX: so i'm looking at your altera PR
<sb0> also the CPU usage from glasgow has gone down a lot
<ZirconiumX> Mmm?
<ZirconiumX> What did I fuck up?
<whitequark> sb0: yes, so the problem here is that the writes to stdout are synchronous
<whitequark> you might actually have a much better time if you used sockets instead
<whitequark> (synchronous and limited by PIPE_BUF at a time)
<sb0> isn't it possible to put stdout in asyncio?
<sb0> and is asyncio performance really better than regular i/o in python?
<whitequark> probably? your attempt at it is as good as mine
<whitequark> throughput? no. latency? in this case, yes
<whitequark> latency spikes due to PIPE_BUF and scheduling cause the entire asyncio domain to stop for that much time
<sb0> I've used asyncio quite a lot and iirc it is possible to write to stdout (or any other fds) on linux asynchronously, however it is slow
<whitequark> which causes it to miss transfers
<whitequark> that's not the case unfortunately, linux AIO is completely broken
<whitequark> you're better off using epoll for sockets, and for non-sockets you can only use it with O_DIRECT on files
<mtrbot-ml_> [mattermost] <weidazhang> @sb10q the two beat signals are fed into "deglitch", then pulses that indicate edges of the beat are given. The tags are the (time-wise) location of these pulses on a counter driven by the helper.
<whitequark> so in practice glibc uses a thread pool to implement POSIX AIO
<sb0> isn't python asyncio using select()/poll()?
<whitequark> epoll, yes
<mtrbot-ml_> [mattermost] <sb10q> @weidazhang I am talking about the frequency counter that is used to preinitialize the PLLs, not DDMTD
<whitequark> try replacing the stdout write with `return await asyncio.run_in_executor(None, sys.stdout.write, data)`
<whitequark> sys.stdout.buffer.write or something
<whitequark> could also run it in pypy, glasgow should work on pypy now
<whitequark> but that shouldn't be necessary, i think
<whitequark> or you could go for the nuclear option and just use libusb from rust.
<whitequark> i have some sample code for that somewhere, sec
<mtrbot-ml_> [mattermost] <weidazhang> @sb10q for preinitialize the pll, tags are used.@sb10q for preinitialize the pll, tags are used.:
<whitequark> of course, you still have to be careful with it, because if you use it the obvious way, you'll still blow your latency budget
<mtrbot-ml_> [mattermost] <sb10q> so there is no additional frequency counter?
<mtrbot-ml_> [mattermost] <weidazhang> @sb10q I don't think so.
<whitequark> except it requires a fork of rust-libusb: https://github.com/whitequark/gameboy-grabber/blob/master/Cargo.toml#L12
<mtrbot-ml_> [mattermost] <sb10q> @weidazhang what do you mean "don't think so"? didn't you write that code?
<mtrbot-ml_> [mattermost] <weidazhang> I wrote the code, I didn't add a "frequency counter" for preinitialize.
<whitequark> ZirconiumX: oh right, so i'm looking at altiobuf and altddio
<whitequark> you're using altddio_bidir for the single ended case
<ZirconiumX> Mmm?
<whitequark> but altddio_out and altddio_in for the differential case
<mtrbot-ml_> [mattermost] <weidazhang> I'm trying to think where this frequency counter come from.
<whitequark> i'm wondering if maybe the latter would work just fine for single ended too?
<mtrbot-ml_> [mattermost] <sb10q> @weidazhang @hartytp mentioned a frequency counter
<mtrbot-ml_> [mattermost] <sb10q> that's all. i don't know more
<mtrbot-ml_> [mattermost] <sb10q> but that equation is definitely not what you are running in the FPGA, there's a floating point number here
<mtrbot-ml_> [mattermost] <sb10q> and what exactly is is fMain and TAGdiff?
<ZirconiumX> whitequark: I don't see why it wouldn't, and I think I know where you're going with that
<mtrbot-ml_> [mattermost] <sb10q> and fOSC
<ZirconiumX> My mental model of altddio_bidir is kinda like a tee pipe fitting, with the I/O pin in the middle
<ZirconiumX> So I couldn't think of a way to get it to work in the DDR case
<whitequark> yeah, neither do I
<ZirconiumX> *differential case
<whitequark> I'm guessing it's partially redundant with altiobuf
<ZirconiumX> Quite possibly.
<sb0> whitequark: what's a good place to do "await loop.connect_write_pipe" on stdout? run()?
<mtrbot-ml_> [mattermost] <weidazhang> No, I didn't run it on FPGA. It is one-time process at the start.
<mtrbot-ml_> [mattermost] <sb10q> so where did you run it?
<mtrbot-ml_> [mattermost] <weidazhang> matlab
<whitequark> sb0: interact
<mtrbot-ml_> [mattermost] <weidazhang> fosc is si549 xo frequency, fmain is 125MHz
<mtrbot-ml_> [mattermost] <sb10q> what is si549 xo frequency? which si549?
<mtrbot-ml_> [mattermost] <sb10q> how did you run that into matlab? manually? and then hardcoded the result?
<mtrbot-ml_> [mattermost] <sb10q> how did you extract the tag info from the prototype?
<sb0> whitequark: seems to have solved the problem
<mtrbot-ml_> [mattermost] <weidazhang> fosc is 152.5MHz
<mtrbot-ml_> [mattermost] <sb10q> 152.5MHz??
<mtrbot-ml_> [mattermost] <sb10q> why?
<mtrbot-ml_> [mattermost] <weidazhang> fosc is 152.6MHz
<mtrbot-ml_> [mattermost] <weidazhang> datasheet says so
<mtrbot-ml_> [mattermost] <sb10q> what's that si549?
<mtrbot-ml_> [mattermost] <weidazhang> sorry typo 152.6MHz
<mtrbot-ml_> [mattermost] <sb10q> is that even on sayma/kasli?
<mtrbot-ml_> [mattermost] <sb10q> I thought those oscillators were running at 125MHz
<ZirconiumX> wq: my contributions to nMigen might be on hold for a little bit because I want to spend my hyperfocus on Mistral stuff.
<mtrbot-ml_> [mattermost] <weidazhang> the dcxo is si549
<mtrbot-ml_> [mattermost] <sb10q> aaah
<whitequark> ZirconiumX: i'll just rewrite it myself the way i think it should be done, based on your code
<mtrbot-ml_> [mattermost] <sb10q> you mean the internal reference of the si549
<mtrbot-ml_> [mattermost] <sb10q> ok I see
<whitequark> already halfway there, actually
<mtrbot-ml_> [mattermost] <weidazhang> it has an internal xo runs at 152.6MHz
<ZirconiumX> whitequark: sure
<mtrbot-ml_> [mattermost] <weidazhang> yes, you right
<whitequark> btw, shouldn't it be vendor.intel
<whitequark> i just realized
<mtrbot-ml_> [mattermost] <sb10q> ok and what about fMain?
<sb0> whitequark: ah no, still crashes
<mtrbot-ml_> [mattermost] <weidazhang> fmain is 125MHz
<sb0> but after a longer time
<ZirconiumX> whitequark: vendor.altera_part_of_intel :P
<whitequark> ZirconiumX: ouch
<whitequark> sb0: what's the current code
<whitequark> sb0: you could try using https://linux.die.net/man/1/buffer to make sure PIPEBUF is not a factor
<mtrbot-ml_> [mattermost] <weidazhang> @sb10q your previous question, yes, manually read it, I've got xilinx ila and used to have a uart connection
<whitequark> but you can't easily change pipe buffer size, which is why i suggested a socket
<whitequark> or rather, PIPESIZE is important here, i think, PIPEBUF only affects atomicity or something like that
<sb0> I'm just doing "| pv > /dev/null" atm
<sb0> glasgow run logic -V 3.3 --pins-d 0,1 | pv > /dev/null
<whitequark> ok
<whitequark> does loop.connect_write_pipe set O_ASYNC ?
<whitequark> With SelectorEventLoop event loop, the pipe is set to non-blocking mode.
<whitequark> but you're not using SelectorEventLoop, are you?
<whitequark> oh i see, epoll is also SelectorEventLoop
<whitequark> that's interesting
<sb0> maybe this is also why sigrok crashed...
<whitequark> sigrok crashed for me since forever whereas glasgow generally does not
<whitequark> i've left a similar applet (RGB capture) on for many minutes
<whitequark> i'd need to reproduce this locally to continue
<whitequark> yep, reproduced it
<whitequark> let's see
<whitequark> sb0: can you run `glasgow run benchmark latency`
<sb0> I: g.applet.internal.benchmark: running benchmark mode latency for 8.000 MiB
<sb0> I: g.applet.internal.benchmark: mode latency: mean: 396.43 µs stddev: 190.72 µs worst: 4632.86 µs
<whitequark> sb0: so that means 128k in flight at most
<whitequark> try setting `_packets_per_xfer = 256` in demultiplexer.py
<whitequark> that seems to work much better for me
<whitequark> # To try and balance these effects, we choose a medium buffer size that should work well with most
<whitequark> # applications. It's possible that this will need to become customizable later, but for now
<whitequark> # a single fixed value works.
<whitequark> prophetic words.
<whitequark> ok, it still crashes with that value
<whitequark> how annoying
<whitequark> aha
<whitequark> sb0: the combination of _packets_per_xfer = 256 and using iface.read() (without size argument) works much better
<whitequark> because this way it doesn't slice buffers in python
<sb0> okay, that works now
<sb0> thanks
<sb0> less CPU usage too
<whitequark> as you have noticed, getting low latency with USB bulk transfers at 1/2 HS bandwidth is not trivial
<whitequark> to be honest i'm surprised it works at all (not your specific case, just in general)
<whitequark> given how badly designed USB is
<sb0> hmm can still get it to crash if I load the CPU
<sb0> well
<whitequark> yes
<sb0> I guess I should move the processing to the FPGA
<whitequark> at least add RLE or something
<whitequark> or move processing there, yeah.
<whitequark> you can increase the buffer sizes further but since the latency is not bounded it'll never work 100% reliably
<sb0> bah. probably works well enough for that prototype
<whitequark> _max_packets_per_ep = 2048; _packets_per_xfer = 512
m4ssi has quit [Remote host closed the connection]
<sb0> eventually this will move to a FPGA
<sb0> also increase iface.get_in_fifo depth I suppose?
<whitequark> that probably matters only marginally
<whitequark> since the overflow is by dozens or hundreds of kb
cr1901_modern has joined #m-labs
mumptai has joined #m-labs
<sb0> okay that's quite stable now
<sb0> nice
sb0 has quit [Quit: Leaving]
<whitequark> eventually i'll rewrite the glasgow demultiplexer in rust
<whitequark> and have it run with elevated priority i think
<whitequark> ionice that is
<whitequark> i'm not entirely sure if preempt-rt could be used to make it hard realtime instead, but i'll try that too
<mtrbot-ml_> [mattermost] <hartytp> @sb10q yes, so the "counter" is just the tag output of the DDMTD core
<mtrbot-ml_> [mattermost] <hartytp> the idea is to do a one-off calibration during lock acquisition, doing some basic maths in firmware
<mtrbot-ml_> [mattermost] <hartytp> previously Weida did this by hand and hard-coded the results, but that's not ideal as not guaranteed to work over PVT so best to do each lock
<mtrbot-ml_> [mattermost] <hartytp> IIRC @weidazhang sent you a document a while back (around 06/08/2019) with a step by step explanation of the lock acquisition process including calibration
<mtrbot-ml_> [mattermost] <hartytp> and we talked it though in detail then. Is there something that doesn't make sense?
<mtrbot-ml_> [mattermost] <hartytp> the DDMTD TAG stuff was in the original pseudo code @weidazhang sent you that described his DDMTD core.
lkcl has quit [Ping timeout: 240 seconds]
<ZirconiumX> whitequark: so I realise the current code is not great because it was mostly a proof of concept, but what would you suggest I work on in terms of code?
<whitequark> ZirconiumX: you don't need to do anything, i'll finish updating it and then verify it on my cyclone-iii board
<whitequark> oh, you could add FFSynchronizer and ResetSynchronizer overrides
<whitequark> using whichever alt* thing they recommend using
<ZirconiumX> Didn't you mention the ResetSynchroniser stuff could be done in pure nMigen?
<_whitenotifier> [smoltcp] Gymmasssorla commented on issue #267: Tokio integration - https://git.io/JeWye
<whitequark> ZirconiumX: yes, and this works if you don't care about timing analysis or timing-driven synthesis
<_whitenotifier> [smoltcp] Gymmasssorla edited a comment on issue #267: Tokio integration - https://git.io/JeWye
<ZirconiumX> Judging by the comments, Altera certainly don't :P
<whitequark> what, really?
<whitequark> the reset synchronizer you linked (some verilog code) mentioned that the alt* thing marked the timing paths appropriately
<whitequark> which sounds like something we want
<whitequark> what was the link again?
<ZirconiumX> Trying to find it
<whitequark> The advantage of using the altera_std_synchronizer is that
<whitequark> it takes care of the quartus properties to preserve the registers of the shift
<whitequark> chain and apply the SDC constraints for us.
<whitequark> yeah i'm pretty sure nmigen needs to use this.
<whitequark> (* altera_attribute = {"-name SYNCHRONIZER_IDENTIFICATION FORCED_IF_ASYNCHRONOUS; -name DONT_MERGE_REGISTER ON; -name PRESERVE_REGISTER ON "} *) reg din_s1;
<whitequark> right, so you'll use reset_n as input for ResetSynchronizer, and din for FFSynchronizer
<whitequark> ZirconiumX: i think your DDR code can't work correctly
<whitequark> you're inserting an inverter between altddio and altiobuf
<whitequark> this is just FYI, i'm reviewing it to find and fix issues like thi
<whitequark> *this
<ZirconiumX> Mmm, fair enough
<ZirconiumX> It should definitely be tested
<ZirconiumX> I'm also pretty bad at commenting my code, sorry ^^;;
<whitequark> that's not an issue really
<whitequark> i just read it side by side with intel docs
<ZirconiumX> Given the width arguments, it shouldn't need the for loop
<whitequark> yes, i fixed that too
<ZirconiumX> So presumably the ResetSynchroniser stuff is an override of create_missing_domain?
<whitequark> no
<whitequark> look at xilinx_7series code
<whitequark> get_ff_sync / get_reset_sync
<whitequark> ZirconiumX: is there a "dff with width" primitive in altera?
<ZirconiumX> Sadly not
<whitequark> that's kind of obnoxious
<whitequark> hm
<ZirconiumX> You can get all sorts of fun things like a J-K flip-flop
<whitequark> i guess we could use $dff
<ZirconiumX> Would Yosys lower that?
<whitequark> yeah
<ZirconiumX> whitequark: https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_low_level.pdf <-- altera primitive reference, for your collection
<whitequark> yep, found it
<whitequark> btw
<whitequark> should we be using alt_* io stuff instead of altiobuf_*?
<whitequark> i forget what the difference is
<ZirconiumX> whitequark: altiobuf_* gets you width parameters
<whitequark> ah right ok
<ZirconiumX> You'd have to instantiate one of these manually
<ZirconiumX> Per bit
<ZirconiumX> I'm pretty sure altiobuf_X lowers to alt_X plus some flops if necessary
<whitequark> what would altiobuf_x use flops for?
<_whitenotifier> [m-labs/nmigen] whitequark pushed 1 commit to vendor.altera [+1/-0/±0] https://git.io/JeWy6
<_whitenotifier> [m-labs/nmigen] whitequark b70c836 - vendor.intel: add Quartus support. (WIP)
<_whitenotifier> [nmigen] whitequark synchronize pull request #178: vendor.altera: add Quartus support (WIP) - https://git.io/fjbbr
<_whitenotifier> [nmigen] Success. Coverage not affected when comparing 2512a9a...29f7a3c - https://codecov.io/gh/m-labs/nmigen/compare/2512a9a12d2c062b8f34330c379ec523b125f38d...29f7a3c6182a320c3b2199e14f2b5872ea575b84
<ZirconiumX> whitequark: things like the delay chain that altiobuf offers
<whitequark> i'm pretty sure those are hard logic
<ZirconiumX> whitequark: It's possibly worth noting that Quartus treats (* useioff *) as a guide, not a rule
<whitequark> ZirconiumX: did you ever *not* get the Extra Info (176219): No registers were packed into other blocks message ?
<_whitenotifier> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/595747701?utm_source=github_status&utm_medium=notification
<_whitenotifier> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/595747697?utm_source=github_status&utm_medium=notification
<_whitenotifier> [nmigen] Success. 82.34% remains the same compared to 2512a9a - https://codecov.io/gh/m-labs/nmigen/compare/2512a9a12d2c062b8f34330c379ec523b125f38d...b70c836b96c7a3ce00d8499b33ba5e932271894d
<_whitenotifier> [nmigen] Success. Coverage not affected when comparing 2512a9a...b70c836 - https://codecov.io/gh/m-labs/nmigen/compare/2512a9a12d2c062b8f34330c379ec523b125f38d...b70c836b96c7a3ce00d8499b33ba5e932271894d
<whitequark> ok hm
<whitequark> so the *input* of the DFF is constrained.
<whitequark> i'm so confuse
<whitequark> ok i see, it should be on the module ports actually
<whitequark> that works i guess
<whitequark> wow holy shit
<whitequark> you *have* to provide (*useioff=1*) and (*keep=1*) with a number specifically, but,
<whitequark> it will actually complain that the value is invalid or something
<_whitenotifier> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/595747701?utm_source=github_status&utm_medium=notification
<ZirconiumX> If it doesn't think it's a legal option, it'll accept but ignore it
<whitequark> nope, it actually packs the registers
<whitequark> and keeps the net i want to keep
<ZirconiumX> Huh, that's handy
<whitequark> it looks like i need write_verilog -decimal to make quartus happy
<ZirconiumX> But yeah it fails silently if you put the annotation outside of the module ports
<ZirconiumX> And I think it also complains if you don't put the buffers in the top-level module
<whitequark> of course it does.
<whitequark> i was thinking just today "maybe stuffing all the buffers in the top-level module is kind of a hack"
<ZirconiumX> I suggest you test though :P
<whitequark> nah i'm sure some vendor will fuck it up.
<whitequark> ok, -decimal makes it shut up *and* do the register packing
<whitequark> christ. how do people cope with this without building their own HDL
<ZirconiumX> For some reason I don't think I'll be buying another Altera dev board
<ZirconiumX> By the way, whitequark, remember the headaches we had trying to build a bitstream that worked on my board?
<whitequark> yea?
<whitequark> by the way, most toolchains are like that.
<whitequark> altera is only like
<ZirconiumX> Turns out GENERATE_RBF_FILE ON silently enables bitstream compression
<whitequark> very slightly worse than usual
<ZirconiumX> This is not documented anywhere
<whitequark> vivado is slightly better than usual.
<ZirconiumX> And the chip doesn't appear to boot with an uncompressed bitstream
<whitequark> what.
<whitequark> ????
<ZirconiumX> The chip _requires_ bitstream compression
<whitequark> ??????
<ZirconiumX> This is also not documented anywhere
<ZirconiumX> But thankfully the compression algorithm itself *appears* to be documented in a patent
<_whitenotifier> [m-labs/nmigen] whitequark pushed 1 commit to vendor.altera [+1/-0/±2] https://git.io/JeWSk
<ZirconiumX> So you can't actually implement a bootable bitstream without giving Altera grounds to sue on patent infringement
<_whitenotifier> [m-labs/nmigen] whitequark 8b315f8 - vendor.intel: add Quartus support. (WIP)
<_whitenotifier> [nmigen] whitequark synchronize pull request #178: vendor.altera: add Quartus support (WIP) - https://git.io/fjbbr
<whitequark> ZirconiumX: ok i mean all this stuff is patented from beginning to end anyway
<whitequark> you're not losing much
<ZirconiumX> Unfortunately it's a patent, which means it's vague as all fuck
<_whitenotifier> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/595767743?utm_source=github_status&utm_medium=notification
<_whitenotifier> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/595767704?utm_source=github_status&utm_medium=notification
<ZirconiumX> You get a warning if that is left unset because it's "underutilising" your hardware
<_whitenotifier> [nmigen] Success. 82.34% remains the same compared to 2512a9a - https://codecov.io/gh/m-labs/nmigen/compare/2512a9a12d2c062b8f34330c379ec523b125f38d...8b315f8d34dd2a887c086c2dd335372181d193b0
<_whitenotifier> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/595767704?utm_source=github_status&utm_medium=notification
<ZirconiumX> Except that I have yet to see Quartus get any meaningful benefit from parallel processing
<ZirconiumX> /rant
<whitequark> i get this warning: Warning (18236): Number of processors has not been specified which may cause overloading on shared machines. Set the global assignment NUM_PARALLEL_PROCESSORS in your QSF to an appropriate value for best performance.
<ZirconiumX> Yep
<ZirconiumX> That one
<whitequark> underutilizing or overloading?
<ZirconiumX> *sigh*
<ZirconiumX> Okay so there's a *different* warning for underutilising
<ZirconiumX> Warning (12473): User specified to use only one processors but 6 processors were detected which could be
<ZirconiumX> used to decrease run time.
<whitequark> ahahaha
<ZirconiumX> So the correct default to get it to very definitely shut up is "ALL"
<ZirconiumX> You can't fucking win
<_whitenotifier> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/595767743?utm_source=github_status&utm_medium=notification
<ZirconiumX> Is this Schadenfreude: the compiler?
<whitequark> catch-22 the toolchain
<ZirconiumX> I'm just glad Quartus doesn't have something like -Werror, because zero-warning compilation on this would be a nightmare
<whitequark> brutal
<ZirconiumX> Wow
<_whitenotifier> [m-labs/nmigen] whitequark pushed 1 commit to vendor.altera [+1/-0/±2] https://git.io/JeWSw
<_whitenotifier> [m-labs/nmigen] whitequark 0b1afa2 - vendor.intel: add Quartus support. (WIP)
<_whitenotifier> [nmigen] whitequark synchronize pull request #178: vendor.altera: add Quartus support (WIP) - https://git.io/fjbbr
<whitequark> aha, finally found a toolchain using *not* / to separate hierarchical names
<ZirconiumX> whitequark: So, the altera_std_synchronizer thing takes in a clock. Would that be ff_sync.i_clk in get_ff_sync?
<_whitenotifier> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/595780439?utm_source=github_status&utm_medium=notification
<_whitenotifier> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/595780447?utm_source=github_status&utm_medium=notification
<whitequark> ClockSignal(ff_sync._o_domain)
<_whitenotifier> [nmigen] Success. 82.34% remains the same compared to 2512a9a - https://codecov.io/gh/m-labs/nmigen/compare/2512a9a12d2c062b8f34330c379ec523b125f38d...0b1afa28cbd89c6963282e5a3532ba7035756223
<_whitenotifier> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/595780439?utm_source=github_status&utm_medium=notification
<_whitenotifier> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/595780447?utm_source=github_status&utm_medium=notification
<_whitenotifier> [nmigen] ZirconiumX opened pull request #246: vendor.intel: reset synchronisers - https://git.io/JeW9e
<ZirconiumX> whitequark: ^
<_whitenotifier> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/595793115?utm_source=github_status&utm_medium=notification
<_whitenotifier> [nmigen] codecov[bot] commented on pull request #246: vendor.intel: reset synchronisers - https://git.io/JeW9Y
<_whitenotifier> [nmigen] Success. Coverage not affected when comparing 0b1afa2...c52a2c1 - https://codecov.io/gh/m-labs/nmigen/compare/0b1afa28cbd89c6963282e5a3532ba7035756223...c52a2c15995f78a105ae34c915314a655ccd30ab
<_whitenotifier> [nmigen] Success. 82.34% remains the same compared to 0b1afa2 - https://codecov.io/gh/m-labs/nmigen/compare/0b1afa28cbd89c6963282e5a3532ba7035756223...c52a2c15995f78a105ae34c915314a655ccd30ab
<_whitenotifier> [m-labs/nmigen] whitequark pushed 1 commit to master [+0/-0/±4] https://git.io/JeW9C
<_whitenotifier> [m-labs/nmigen] whitequark b9e57fd - build.plat,vendor: always synchronize reset in default sync domain.
<_whitenotifier> [nmigen] whitequark reviewed pull request #246 commit - https://git.io/JeW9l
<_whitenotifier> [nmigen] whitequark reviewed pull request #246 commit - https://git.io/JeW94
<_whitenotifier> [nmigen] ZirconiumX reviewed pull request #246 commit - https://git.io/JeW9g
<_whitenotifier> [nmigen] ZirconiumX synchronize pull request #246: vendor.intel: reset synchronisers - https://git.io/JeW9e
<_whitenotifier> [nmigen] whitequark reviewed pull request #246 commit - https://git.io/JeW9w
<_whitenotifier> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/595802652?utm_source=github_status&utm_medium=notification
<_whitenotifier> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/595798158?utm_source=github_status&utm_medium=notification
<_whitenotifier> [nmigen] Success. Coverage not affected when comparing 0b1afa2...0f8effa - https://codecov.io/gh/m-labs/nmigen/compare/0b1afa28cbd89c6963282e5a3532ba7035756223...0f8effaee52ba74ac2754eca9f2a618752815ce6
<_whitenotifier> [nmigen] Failure. 82.33% (-0.01%) compared to 2512a9a - https://codecov.io/gh/m-labs/nmigen/commit/b9e57fd67baae74f4063965ce51a1baa8743d9d2
<_whitenotifier> [nmigen] Failure. 50% of diff hit (target 82.34%) - https://codecov.io/gh/m-labs/nmigen/commit/b9e57fd67baae74f4063965ce51a1baa8743d9d2
<_whitenotifier> [nmigen] ZirconiumX synchronize pull request #246: vendor.intel: reset synchronisers - https://git.io/JeW9e
<_whitenotifier> [nmigen] ZirconiumX reviewed pull request #246 commit - https://git.io/JeW9K
<_whitenotifier> [nmigen] whitequark reviewed pull request #246 commit - https://git.io/JeW9i
<_whitenotifier> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/595803991?utm_source=github_status&utm_medium=notification
<_whitenotifier> [nmigen] Success. Coverage not affected when comparing 0b1afa2...2eac10e - https://codecov.io/gh/m-labs/nmigen/compare/0b1afa28cbd89c6963282e5a3532ba7035756223...2eac10e16bfcbbda563181f1cc1416c3801f1dae
<_whitenotifier> [nmigen] Success. 82.34% remains the same compared to 0b1afa2 - https://codecov.io/gh/m-labs/nmigen/compare/0b1afa28cbd89c6963282e5a3532ba7035756223...2eac10e16bfcbbda563181f1cc1416c3801f1dae
<_whitenotifier> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/595803991?utm_source=github_status&utm_medium=notification
<_whitenotifier> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/595802652?utm_source=github_status&utm_medium=notification
mumptai has quit [Quit: Verlassend]
<_whitenotifier> [m-labs/nmigen] whitequark pushed 1 commit to vendor.altera [+1/-0/±2] https://git.io/JeW91
<_whitenotifier> [m-labs/nmigen] whitequark ddcff57 - vendor.intel: add Quartus support. (WIP)
<_whitenotifier> [nmigen] whitequark synchronize pull request #178: vendor.altera: add Quartus support (WIP) - https://git.io/fjbbr
<_whitenotifier> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/595806423?utm_source=github_status&utm_medium=notification
<_whitenotifier> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/595806447?utm_source=github_status&utm_medium=notification
<_whitenotifier> [nmigen] Success. 82.33% remains the same compared to b9e57fd - https://codecov.io/gh/m-labs/nmigen/compare/b9e57fd67baae74f4063965ce51a1baa8743d9d2...ddcff57f6a0180cd7d5e7ff6a1345b54ac30bc7f
<_whitenotifier> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/595806423?utm_source=github_status&utm_medium=notification
gnufan_home has joined #m-labs
<_whitenotifier> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/595806447?utm_source=github_status&utm_medium=notification
<_whitenotifier> [nmigen] ZirconiumX synchronize pull request #246: vendor.intel: reset synchronisers - https://git.io/JeW9e
<_whitenotifier> [nmigen] ZirconiumX synchronize pull request #246: vendor.intel: reset synchronisers - https://git.io/JeW9e
<_whitenotifier> [m-labs/nmigen] whitequark pushed 1 commit to vendor.altera [+0/-0/±1] https://git.io/JeWHI
<_whitenotifier> [m-labs/nmigen] ZirconiumX 7dbd822 - vendor.intel: reset synchronisers (#246)
<_whitenotifier> [nmigen] whitequark closed pull request #246: vendor.intel: reset synchronisers - https://git.io/JeW9e
<_whitenotifier> [nmigen] whitequark synchronize pull request #178: vendor.altera: add Quartus support (WIP) - https://git.io/fjbbr
<_whitenotifier> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/595815056?utm_source=github_status&utm_medium=notification
<_whitenotifier> [m-labs/nmigen] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JeWHs
<_whitenotifier> [m-labs/nmigen] whitequark 27a32f0 - build.plat: don't create default sync domain as reset-less.
<_whitenotifier> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/595815056?utm_source=github_status&utm_medium=notification
<_whitenotifier> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/595814609?utm_source=github_status&utm_medium=notification
<_whitenotifier> [nmigen] Success. Coverage not affected when comparing ddcff57...0613f5a - https://codecov.io/gh/m-labs/nmigen/compare/ddcff57f6a0180cd7d5e7ff6a1345b54ac30bc7f...0613f5a2ef9c7aca05de9311410110ca6a743c4d
<_whitenotifier> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/595815075?utm_source=github_status&utm_medium=notification
<_whitenotifier> [nmigen] Success. 82.33% remains the same compared to b9e57fd - https://codecov.io/gh/m-labs/nmigen/compare/b9e57fd67baae74f4063965ce51a1baa8743d9d2...7dbd822b8a1b09cf6b1b42395bbaa5b2f69e39b3
<_whitenotifier> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/595815075?utm_source=github_status&utm_medium=notification
<_whitenotifier> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/595816156?utm_source=github_status&utm_medium=notification
<_whitenotifier> [nmigen] Success. 82.52% (+0.18%) compared to b9e57fd - https://codecov.io/gh/m-labs/nmigen/commit/27a32f021894889f8516ba5ddee567f1b67d8ba4
<_whitenotifier> [nmigen] Failure. 0% of diff hit (target 82.33%) - https://codecov.io/gh/m-labs/nmigen/commit/27a32f021894889f8516ba5ddee567f1b67d8ba4
<_whitenotifier> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/595816156?utm_source=github_status&utm_medium=notification
<_whitenotifier> [nmigen] Success. 82.33% remains the same compared to b9e57fd - https://codecov.io/gh/m-labs/nmigen/commit/27a32f021894889f8516ba5ddee567f1b67d8ba4
<whitequark> ZirconiumX: Info (332114): Typical MTBF of Design is 1e+09 years or 3.15e+16 seconds.
<ZirconiumX> whitequark: So they mean it's going to break by tomorrow?
<whitequark> hm?
<whitequark> Info (332164): Evaluating HDL-embedded SDC commands
<whitequark> huh
<whitequark> that's one way to do it
<whitequark> ZirconiumX: ah, you should have used altera_std_synchronizer_bundle for the FFSynchronizer
<whitequark> which is the same thing but n times anyway
<_whitenotifier> [m-labs/nmigen] whitequark pushed 1 commit to master [+0/-0/±2] https://git.io/JeWHj
<_whitenotifier> [m-labs/nmigen] whitequark 7257c20 - build.plat: elaborate result of create_missing_domain() against platform.
<_whitenotifier> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/595828712?utm_source=github_status&utm_medium=notification
<_whitenotifier> [nmigen] Success. 82.52% (+0.18%) compared to 27a32f0 - https://codecov.io/gh/m-labs/nmigen/commit/7257c20a6a71f1102ddef8282c042b99d772b368
<_whitenotifier> [nmigen] Failure. 66.66% of diff hit (target 82.33%) - https://codecov.io/gh/m-labs/nmigen/commit/7257c20a6a71f1102ddef8282c042b99d772b368
<_whitenotifier> [nmigen] Success. 82.33% remains the same compared to 27a32f0 - https://codecov.io/gh/m-labs/nmigen/commit/7257c20a6a71f1102ddef8282c042b99d772b368
<_whitenotifier> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/595828712?utm_source=github_status&utm_medium=notification
<_whitenotifier> [m-labs/nmigen] whitequark pushed 1 commit to vendor.altera [+1/-0/±2] https://git.io/JeW7m
<_whitenotifier> [m-labs/nmigen] whitequark edc21df - vendor.intel: add Quartus support. (WIP)
<_whitenotifier> [nmigen] whitequark synchronize pull request #178: vendor.altera: add Quartus support (WIP) - https://git.io/fjbbr
<_whitenotifier> [nmigen] Success. 82.33% remains the same compared to 7257c20 - https://codecov.io/gh/m-labs/nmigen/compare/7257c20a6a71f1102ddef8282c042b99d772b368...7dbd822b8a1b09cf6b1b42395bbaa5b2f69e39b3
<_whitenotifier> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/595841315?utm_source=github_status&utm_medium=notification
<_whitenotifier> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/595841303?utm_source=github_status&utm_medium=notification
<_whitenotifier> [nmigen] Success. 82.33% remains the same compared to 7257c20 - https://codecov.io/gh/m-labs/nmigen/compare/7257c20a6a71f1102ddef8282c042b99d772b368...edc21df1e6b9139f104f2f4bb3d453116daa1124
<_whitenotifier> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/595841303?utm_source=github_status&utm_medium=notification
<_whitenotifier> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/595841315?utm_source=github_status&utm_medium=notification
<_whitenotifier> [m-labs/nmigen] whitequark pushed 1 commit to vendor.altera [+1/-0/±2] https://git.io/JeW5J
<_whitenotifier> [m-labs/nmigen] whitequark ace10a6 - vendor.intel: add Quartus support. (WIP)
<_whitenotifier> [nmigen] whitequark synchronize pull request #178: vendor.intel: add Quartus support (WIP) - https://git.io/fjbbr
<_whitenotifier> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/595853491?utm_source=github_status&utm_medium=notification
<_whitenotifier> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/595853485?utm_source=github_status&utm_medium=notification
<_whitenotifier> [nmigen] Success. 82.33% remains the same compared to 7257c20 - https://codecov.io/gh/m-labs/nmigen/compare/7257c20a6a71f1102ddef8282c042b99d772b368...ace10a6b29fa1e778d4bcfe14fb8c6981cdc8184
<_whitenotifier> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/595853485?utm_source=github_status&utm_medium=notification
<_whitenotifier> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/595853491?utm_source=github_status&utm_medium=notification
<_whitenotifier> [m-labs/nmigen-boards] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JeW54
<_whitenotifier> [m-labs/nmigen-boards] whitequark b785b7c - test.blinky: invert LED status when button/switch is active.
<_whitenotifier> [m-labs/nmigen-boards] whitequark pushed 1 commit to master [+0/-0/±2] https://git.io/JeW50
<_whitenotifier> [m-labs/nmigen-boards] whitequark 5ab2151 - de0{,cv}: {Altera→Intel}Platform
gnufan_home has quit [Quit: Leaving.]
<_whitenotifier> [m-labs/nmigen] whitequark pushed 1 commit to master [+2/-1/±0] https://git.io/JeW5h
<_whitenotifier> [m-labs/nmigen] whitequark 7dfd7fb - examples: update blinky, add some explanatory text about domains.
<_whitenotifier> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/595868888?utm_source=github_status&utm_medium=notification
<_whitenotifier> [nmigen] Success. 82.33% remains the same compared to 7257c20 - https://codecov.io/gh/m-labs/nmigen/commit/7dfd7fb12a722398358869ebe5fdbd6788c1c0c6
<_whitenotifier> [nmigen] Success. Coverage not affected when comparing 7257c20...7dfd7fb - https://codecov.io/gh/m-labs/nmigen/commit/7dfd7fb12a722398358869ebe5fdbd6788c1c0c6