florolf has quit [Ping timeout: 264 seconds]
_whitelogger_ has joined ##openfpga
emily_ has joined ##openfpga
ormiret_ has joined ##openfpga
jhol` has joined ##openfpga
emily_ has quit [Client Quit]
swedishhat[m] has quit [*.net *.split]
scream has quit [*.net *.split]
X-Scale has quit [*.net *.split]
Thorn has quit [*.net *.split]
oeuf has quit [*.net *.split]
wpwrak has quit [*.net *.split]
lexano has quit [*.net *.split]
implr has quit [*.net *.split]
horizon has quit [*.net *.split]
Lord_Nightmare has quit [*.net *.split]
duck2 has quit [*.net *.split]
bsilvereagle has quit [*.net *.split]
sgstair has quit [*.net *.split]
linzhi-sonia has quit [*.net *.split]
_whitelogger has joined ##openfpga
Bike has joined ##openfpga
pie_ has quit [Ping timeout: 250 seconds]
Asu` has quit [Quit: Konversation terminated!]
emeb has quit [Quit: Leaving.]
<ZirconiumX> Reposting from #yosys:
<ZirconiumX> What's the difference between `always @(*) A = B;` and `assign A = B;`?
<TD-Linux> none
<whitequark> there is
<cr1901_modern> Prob some stupid simulation difference that requires you to read the spec
<TD-Linux> now I hate verilog again
<whitequark> delta cycles
<whitequark> hell if i remember which way it actually goes
<ZirconiumX> And this is why I asked in a channel with WQ in it
<whitequark> oh
<whitequark> i mean, besides that,
<whitequark> in the first case A must be a reg and in the second case A must be a wire
<ZirconiumX> It was raised by me looking at some code by pepijndevos and going "shouldn't that use `assign` instead of `always @(*)`?"
<whitequark> i'm trying to figure out exactly what the difference between continuous assignmetn and procedural continuous assignment is and my conclusion is that verilog is bad
<whitequark> ohhh oh yeah
<whitequark> so
<whitequark> ZirconiumX: let's say you write `assign A = 0;`. this works.
<whitequark> let's say you write `always @(*) A = 0;`. this doesn't do anything at all.
<ZirconiumX> So if the RHS is a constant don't ever use `always @(*)`?
<ZirconiumX> This is the diff that raised the question for me
<whitequark> ZirconiumX: yes if the RHS is a constant always @(*) will not work
<whitequark> nmigen emits a workaround for this case
<whitequark> you can add a `reg x; always @(*) begin ... x = x; end`
<whitequark> does abslutely nothing except for tricking the verilog simulators into not being braindead
<ZirconiumX> (* keep *) reg mycarry; always @(*) mycarry = DUT.carry;
<whitequark> that's probably fine
<ZirconiumX> And I was wondering if here "assign" would be okay
<whitequark> in this case i think it doesn't make any difference
azonenberg_work has quit [Ping timeout: 268 seconds]
<whitequark> interesting
<ZirconiumX> I thought Power had a reputation for being power hungry? Though I don't see how much the ISA design could feed into that.
* ZirconiumX is uninformed, having not kept up with PowerPC since their iMac G3 died
<kc8apf> IBM is good at making power-hungry monsters
<kc8apf> Freescale e500v2 is pretty light on power though
<TD-Linux> power8 and power9 are actually pretty ok power consumtion wise
<TD-Linux> my talos II is super quiet while idling
<TD-Linux> probably not good enough for a laptop
<ZirconiumX> Don't they have the Forza chips which are heavily cut down from the Big Iron?
<emily> i'm always skeptical of people who refer to random big workstations as "super quiet"/"practically silent"/...
<Zorix> talos workstation is damn near unaffordable
<TD-Linux> emily, I'm super paranoid about it and it is
<emily> there was a lobste.rs thread about the talos II and the floodgap fanboy guy was like "it's way quieter than my Quad G5!!"
<TD-Linux> Zorix, yeah. they are doing cheaper mobos now though
<Zorix> yep
<TD-Linux> Blackbird is almost affordable
pie_ has joined ##openfpga
<Zorix> i keep an eye on them
<Zorix> power and riscv are going places
<emily> it still seems less interesting than both risc-v and arm64 to me
<emily> i guess more relevant now that it's actually properly open
<emily> but like, not exactly a ton of ppc64 jits out there
<emily> so how much do you even get from having an "existing" architecture
<TD-Linux> a lot. risc-v compilers suck
<TD-Linux> and its single threaded perf is still >> arm64
<TD-Linux> I think risc-v will eventually eclipse it though
<TD-Linux> pretty obvious why they open sourced the isa
<kc8apf> there are quite a few ppc64 JITs
<ZirconiumX> ARM themselves don't seem to be fighting the server market; the ARM ISA chips seem to be custom companies with a lot invested in them
<emily> i mean yeah, i meant in that like, risc-v seems like it'd win long-term and arm64 seems like the more reasonable compromise option for now
<ZirconiumX> Falkor sounded interesting but apparently was quickly axed and written off
<emily> I wonder how power9 compares to the server arm chips performance-wise
<kc8apf> arm64 has a messy firmware story
<whitequark> acpi!
<emily> isn't even risc-v acpi/uefi bullshit now
<TD-Linux> yes
<TD-Linux> risc-v messed up a tad there I think
<ZirconiumX> PE format on RISC-V
<TD-Linux> power9 has the best ever firmware
* ZirconiumX shudders
<kc8apf> there's a particular person at RedHat that keeps pushing things toward EFI
<emily> what's power9's firmware like? I don't actually know
<TD-Linux> it uses petitboot
<emily> but I like openfirmware
<TD-Linux> aka it just boots linux from a spi flash
<TD-Linux> and then you get a menu to kexec() whatever kernel
<TD-Linux> so it can boot off any filesystem linux can read
<emily> while it's true that most firmware and bootloaders are more cursed than linux i have Feelings about everyone just deciding that the solution is to put linux in everything
<emily> it sure is practical though I guess
<TD-Linux> I mean you can kexec() bsd or whatever
<kc8apf> everything is open for p9; even the "backstage cast" of processors that just manage the chip
<ZirconiumX> That's the "open" part of OpenPOWER
<kc8apf> kinda
<kc8apf> OpenPOWER has changed quite a bit over time in terms of what is actually open
<ZirconiumX> I realised they opened the actual ISA now
<emily> TD-Linux: yeah i know. but i still don't super enjoy the idea of millions of lines of linux kernel code being your firmware root of trust
<emily> seL4 bootloader pls
<ZirconiumX> Also I think IBM did try to build low-power chips (see the Nintendo consoles between the GCN and Wii U)
<ZirconiumX> But they're based on the G3 I think
<TD-Linux> you could flash anything else on the spi chip I guess
<kc8apf> ZirconiumX: they'll make them if you promise to buy them
<ZirconiumX> Still, it seemed like they were less innovating and more die-shrinking an old architecture
<ZirconiumX> Not that they're the first to do that though.
<kc8apf> around 2009, they took a huge u-turn from POWER4 and built an in-order processor for game consoles
<TD-Linux> sux that that power core is in vhdl
<kc8apf> it wasn't until POWER7(?) that they went back to a big, ooo design
<TD-Linux> want to try vhd2vl'ing it a bit
<ZirconiumX> kc8apf: I think the PPE was an in-order G5
<ZirconiumX> And it Sucked.
<kc8apf> in-order and G5 don't go together
<kc8apf> G5 was POWER4 w/ Altivec
<kc8apf> POWER5 / Cell was a whole separate thing
<ZirconiumX> They needed the die space for the SPEs
<ZirconiumX> So they threw away the OOE capabilities of the G5
<kc8apf> no, quite the opposite
<zignig> kc8apf: wasn't the PS3 running Cell?
<kc8apf> they decided to make an in-order processor and those SPEs on to make it fast
<kc8apf> it was very much targeted to Sony's whims
<TD-Linux> very early on the SPEs were supposed to do graphics too
<kc8apf> Apple evaluated it and realized it would suck
<kc8apf> macOS on x86 started for real shortly after
<ZirconiumX> It kind of makes sense if you look at the philosophy of the PS2
<TD-Linux> ^ literally typing that
<TD-Linux> they had an extra couple of mips cores that worked basically as a vertex shader
<ZirconiumX> They're not MIPS
<TD-Linux> so they looked at that and thought "more"
<TD-Linux> mipsish
<ZirconiumX> Actually a 2-way VLIW
<ZirconiumX> So MIPSish if you throw away most of the things that made it MIPS
<TD-Linux> yeah
<TD-Linux> I just looked it up
<TD-Linux> dunno why I thought they were mips
<ZirconiumX> Because the main processor *is* MIPS
<TD-Linux> but yeah I guess that makes them even more SPU like
<ZirconiumX> Though what revision of MIPS? Nobody knows.
<ZirconiumX> The R5900 is a bit horrifying.
<ZirconiumX> Well-intentioned, but horrifying.
<ZirconiumX> TD-Linux: how do you like your IEEE 754 FPU?
<ZirconiumX> Because they didn't include one.
<whitequark> lol mips
<ZirconiumX> Anyway, it's 1am. I won't bore you all with the details of a chip I have spent entirely too much time obsessing over.