<Degi_>
SyncFIFOBuffered sometimes seems to give doubled outputs (and where the doubling was, it forgets an element), huh
Degi has quit [Ping timeout: 272 seconds]
Degi_ is now known as Degi
<whitequark>
Degi: i highly doubt that this is an issue with SyncFIFOBuffered
<whitequark>
more likely you are violating some timing constraint
<d1b2>
<edbordin> whitequark sorry to keep bugging you about this. I feel like I might have misunderstood what the issues currently are with sby on windows. I thought a lot of it was about stopping zombie processes but seems like actually the main problem used to be that select() would return immediately and make the task loop hog the cpu?
<whitequark>
edbordin: i actually was under the same impression...
<d1b2>
<edbordin> like, basically with that sleep(0.1) workaround it seems to work passably so it is still tempting to ship it now and keep working on improving it upstream in the background
<whitequark>
mhm, i guess that works
<d1b2>
<edbordin> I was getting the impression that SEDA might not be comfortable merging that PR unless there are regression tests to prove it works reliably, so it is probably going to be a pretty long term effort in that case
zignig_ has joined #nmigen
zignig has quit [Ping timeout: 240 seconds]
<_whitenotifier-3>
[nmigen-soc] jfng opened pull request #26: Make optional properties return None while uninitialized. - https://git.io/JUeJu
<_whitenotifier-3>
[nmigen-soc] jfng commented on pull request #26: Make optional properties return None while uninitialized. - https://git.io/JUeJz
<cr1901_modern>
>i actually was under the same impression...
<cr1901_modern>
https://github.com/YosysHQ/SymbiYosys/pull/39 My PR which solves the "select is borked on Windoze" problem, but introduces the "subprocess.terminate doesn't actually work" problem
electronic_eel has quit [Ping timeout: 258 seconds]
electronic_eel has joined #nmigen
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #nmigen
<d1b2>
<edbordin> Thanks for the recap cr1901_modern. So if I'm understanding correctly it's fair to say it does sort of work on windows atm, just without as much parallelism as it could have with your PR
<cr1901_modern>
and with lots of busy-waiting (because when you do long proofs, each step can take a while. Would be better to sleep during those times)
<cr1901_modern>
But yes otherwise correct
<d1b2>
<edbordin> Did you see someone put sleep(0.1) in the loop for windows at some point?
<d1b2>
<edbordin> Not ideal but at least stops it spinning around too much
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #nmigen
<cr1901_modern>
No I didn't. I guess that's alright, but I wish it would be fixed properly (and that there was a wrapper that enables selecting on fds for Windows or something)
<cr1901_modern>
Anyways, I think I'm done for now working on this, sorry.
<cr1901_modern>
Everyone else can work out the details, and I'll test.
<d1b2>
<edbordin> Not a problem, thanks for helping me better understand what problems needed solving
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 272 seconds]
PyroPeter_ is now known as PyroPeter
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #nmigen
_florent__ has joined #nmigen
_florent_ has quit [Ping timeout: 256 seconds]
_florent__ is now known as _florent_
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #nmigen
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #nmigen
<d1b2>
<edbordin> I'm actually curious now. Claire doesn't seem very interested in supporting windows, does that mean it's not that popular in the EDA field? Anecdotally, other parts of engineering are surprisingly dependent on Windows.
<d1b2>
<edbordin> (for better or worse. personally I also dislike it as a platform but for practical reasons I'm unable to ignore it)
proteus-guy has joined #nmigen
emeb_mac has quit [Quit: Leaving.]
<daveshah>
Surprisingly, a lot of ASIC stuff is Linux (RHEL/CentOS) only
<daveshah>
That doesn't mean supporting Windows isn't important in general, but why there hasn't been a massive commercial reason to do so
<d1b2>
<edbordin> ok yeah, that makes sense. definitely if there isn't strong commercial incentive it's a win to not have to support windows
<d1b2>
<edbordin> but it's still nice if the open source community can help make it happen 🙂
<sorear>
and it's like, motif stuff that was obviously originally for SunOS or something
_whitelogger has joined #nmigen
electronic_eel has quit [Ping timeout: 240 seconds]
electronic_eel has joined #nmigen
jaseg has quit [Ping timeout: 272 seconds]
jaseg has joined #nmigen
Asu has joined #nmigen
Asu has quit [Ping timeout: 240 seconds]
Asuu has joined #nmigen
Asuu has quit [Read error: Connection reset by peer]
Asuu has joined #nmigen
Asu has joined #nmigen
Asuu has quit [Ping timeout: 258 seconds]
<Degi>
whitequark: nevermind, I forgot that the FIFO needed to be on the right clock domain
<Chips4Makers>
edbordin: the ASIC EDA tools actually started on UNIX and then migrated to Linux. I still remember time when a lot of development in house was done on Linux but the release versions of the software was still done for the 'professional' UNIX OSes (SunOS, AIX, HPUX).
lkcl_ has quit [Ping timeout: 265 seconds]
lkcl_ has joined #nmigen
<cr1901_modern>
In uni, we used SunOS/UltraSPARC dumb terminals to run the Mentor tools
<hell__>
O_o
cr1901_modern1 has joined #nmigen
cr1901_modern has quit [Ping timeout: 258 seconds]
peeps[zen] has quit [Ping timeout: 256 seconds]
peeps[zen] has joined #nmigen
FFY00 has quit [Quit: dd if=/dev/urandom of=/dev/sda]
FFY00 has joined #nmigen
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined #nmigen
Asu has quit [Ping timeout: 258 seconds]
emeb has joined #nmigen
Asu has joined #nmigen
Asu has quit [Ping timeout: 258 seconds]
Asu has joined #nmigen
<d1b2>
<DX-MON> @edbordin a lot of ASIC stuff, as far as I understand, is run on supercomputers.. windows doesn't HPC and the schedulers don't support windows well because it is hard to support well. IIRC this drove the ASIC software to Linux
<d1b2>
<DX-MON> (correct me anyone if I'm wrong)
<emeb>
I started doing chip design about 30yrs ago - it's always been on *ix systems. Initially on AIX, then SunOS, then on Linux. When I worked at Intel it was all done on x86 Linux servers, although sometimes we had older Sun systems on our desks, mostly for the graphics.
Asuu has joined #nmigen
<emeb>
While everyone at Intel carries company provided laptops running Windows for meetings, email, etc. the actual design work is done on the Linux systems, usually via VNC sessions.
Asu has quit [Ping timeout: 246 seconds]
<d1b2>
<DX-MON> sounds about right..
<d1b2>
<DX-MON> I was under the impression from things I've read and seen that the big work in converting RTL to an ASIC is done on a supercomputer however due to the shear size of the P&R operation requiring a lot of compute and RAM to complete in anything like a reasonable amount of time
<d1b2>
<DX-MON> hence the tools running quite so well on Linux
<Ultrasauce>
oh i see the project simply doesn't have docs yet, nevermind
<Lofty>
Ultrasauce: I'm not entirely sure there's much to document in nmigen-boards
<Ultrasauce>
well presumably that link was added with some kind of intent
<lkcl_>
dlb2, DXMON: i visited Rudi from ASICs.ws last year. he was just putting together a top-of-the-line dual-socket PC with 128mb DDR4 DRAM. the motherboard: USD $1200. each processor: USD $1000+
<_whitenotifier-3>
[YoWASP/nextpnr] whitequark pushed 1 commit to develop [+0/-0/±1] https://git.io/JUvcw
<_whitenotifier-3>
[YoWASP/nextpnr] whitequark 4605da0 - Don't require maintainer action for updating the develop branch.
<tpw_rules>
i hope you used the wrong unit
<lkcl_>
this was to run synopsis P&R tools for a 7nm ASIC
<lkcl_>
bottom line: what used to be considered a "supercomputer" has become accessible to anyone working at home.
<_whitenotifier-3>
[YoWASP/nextpnr] whitequark pushed 1 commit to develop [+0/-0/±1] https://git.io/JUvci
<_whitenotifier-3>
[YoWASP/nextpnr] whitequark 28cd4e6 - [skip ci] Don't require maintainer action for updating the develop branch.
<_whitenotifier-3>
[YoWASP/nextpnr] whitequark pushed 1 commit to develop [+0/-0/±1] https://git.io/JUvcQ
<_whitenotifier-3>
[YoWASP/nextpnr] whitequark 20e3abe - [skip ci] Don't require maintainer action for updating the develop branch.
<_whitenotifier-3>
[YoWASP/yosys] whitequark pushed 1 commit to develop [+0/-0/±2] https://git.io/JUvc7
<d1b2>
<DX-MON> lkcl_: Interesting; and yes, while I understand that, so have supercomputers kept moving on and growing larger as have CPU and GPU designs; it interests and excites me however that with just 128GiB RAM and a couple of decent processors you can have a decent ASIC P&R computer
<d1b2>
<DX-MON> I say "just", as that's small-fry in my world..
<d1b2>
<DX-MON> (we baseline individual nodes in our supers at 256GiB RAM..)
<lkcl_>
dlb2, DX-MON: i've a dell laptop with 64gb DDR4 RAM and an 8-core 4.8ghz i9 (!)
<lkcl_>
and i can run coriolis2 to P&R 140,000 gates in about... 40 minutes.
<d1b2>
<DX-MON> this machine is 64GiB RAM and 16 core..
<lkcl_>
but
<d1b2>
<DX-MON> ah, that's awesome and way better than it used to be
<lkcl_>
there's a single-threaded design limitation in coriolis2. it _could_ be 8x faster
<d1b2>
<DX-MON> mmmm, that's fair
<lkcl_>
frankly i'm amazed i can even consider it at all
<d1b2>
<DX-MON> for reference, btw.. Damson [the name of one of the supers at work] has 36 cores per node, 256GiB RAM per node and around 3000 nodes
* lkcl_
splutter
<d1b2>
<DX-MON> that is the level of hardware I was under the impression it still took
<d1b2>
<DX-MON> ohyeah, the toys I get to sysadmin are truely huge
<lkcl_>
Jean-Paul (LIP6.fr) tells me that some people using alliance / coriolis2 run P&R for several days. however the point is: it's not "weeks" or "months".
<d1b2>
<DX-MON> sure, that's good to hear 🙂
* lkcl_
has to return to debugging a POWER9 nmigen core... :)
<d1b2>
<DX-MON> (or are you doing full PPC9 so it's both?)
<lkcl_>
both, yes.
<lkcl_>
the "byte-reversing" logic is there, might as well use it
<lkcl_>
btw can i recommend moving to #libre-soc on irc.freenode.net for a discussion of POWER9?
<lkcl_>
to be fair to people here, this is for nmigen
<d1b2>
<DX-MON> I.. am connected in via Discord, but after I've streamed today and perhaps found the spoons to sort my IRC client back out, then yeah, that sounds good to me
<_whitenotifier-3>
[YoWASP/nextpnr] whitequark pushed 1 commit to develop [+0/-0/±1] https://git.io/JUvWf
<_whitenotifier-3>
[YoWASP/nextpnr] whitequark ace958e - [skip ci] Don't require maintainer action for updating the develop branch.
<_whitenotifier-3>
[YoWASP/nextpnr] whitequark pushed 1 commit to develop [+0/-0/±1] https://git.io/JUvWq
<_whitenotifier-3>
[YoWASP/nextpnr] whitequark 6a3ec50 - [skip ci] Don't require maintainer action for updating the develop branch.
<_whitenotifier-3>
[YoWASP/nextpnr] whitequark pushed 1 commit to develop [+0/-0/±1] https://git.io/JUvWO
<_whitenotifier-3>
[YoWASP/nextpnr] whitequark 3d2760d - [skip ci] Don't require maintainer action for updating the develop branch.
<_whitenotifier-3>
[YoWASP/nextpnr] whitequark pushed 1 commit to develop [+0/-0/±1] https://git.io/JUvWG
<_whitenotifier-3>
[YoWASP/nextpnr] whitequark 8f1b4f5 - [skip ci] Don't require maintainer action for updating the develop branch.
<_whitenotifier-3>
[YoWASP/nextpnr] whitequark pushed 1 commit to develop [+0/-0/±1] https://git.io/JUvWl
<_whitenotifier-3>
[YoWASP/nextpnr] whitequark 3306a2a - [skip ci] Don't require maintainer action for updating the develop branch.
<_whitenotifier-3>
[YoWASP/nextpnr] whitequark pushed 1 commit to develop [+0/-0/±2] https://git.io/JUvW8
<tpw_rules>
i wasn't sure how up to date those were.
<DaKnig>
it ... kinda works
<tpw_rules>
ok so i can yield .eq()s and Tick to advance the clock and Settle to wait for the combinatorial logic to be ready and arbitrary Signals at that point
<tpw_rules>
or just an empty yield in a sync process instead of Tick. alright that seems like what i was looking for
<whitequark>
yup
<whitequark>
at some point later (there's been a simplified/improved simulator interface planned for a while), Settle will become implicit, because forgetting it is kind of a major footgun
<whitequark>
so in general, .eq();Settle() is a very good pattern to use
<tpw_rules>
is that meaningfully different from .eq();Tick() if there's nothing in between
<whitequark>
nop
<tpw_rules>
ok cool. thank you!
<whitequark>
the one thing that is a hazard is `yield x.eq(y); yield x`
<whitequark>
this is actually useful in some circumstances and even necessary for determinism
<whitequark>
but it's basically never what you want when writing *testbenches*
<tpw_rules>
when are you not writing a testbench
<whitequark>
when you are replacing a bunch of synchronous logic with a behavioral model
<whitequark>
imagine replacing a CPU core with a Python or C++ one