<whitequark[cis]>
so, 11 out of 13 comments are guys talking irrelevant shit at each other
<whitequark[cis]>
typical hacker news thread
<Darius>
I only saw 1 actually relevant comment
<Darius>
I guess the bottom one is at least slightly informative
<whitequark[cis]>
the bottom two contain information that may cause someone else to undergo learning
<whitequark[cis]>
the rest are just noise
<Darius>
hey the top one has a link to the project!
<Darius>
that photo of the dead bug BGA, oof that looks painful to solder
<jn>
hacker news. not even once.
<jn>
the original article looks good though
josHua[m] has joined #glasgow
<josHua[m]>
the other comment is also hilariously wrong
<jn>
Darius: microsoldering becomes a lot easier under a stereoscopic microscope
<josHua[m]>
like I guess there is learning to be done but solidly like 30% of that comment is confidently orangely wrong
<Darius>
jn: sadly we don't have one at work :(
<Darius>
lol "orangely wrong"
<joshua_>
I would like a stereoscopic microscope though I will say that even a decent low latency digital microscope is a lot better than unaided eyes
<joshua_>
or, in my case, a cheap and mediocre low latency digital microscope
<Darius>
the hacker space I sometimes go to has one and it was very nice to use for fixing up boards for sure
esden[m] has joined #glasgow
<esden[m]>
Ohh that is coflynn (@_discord_604738130318458891:catircservices.org) 's blog post! He mentioned that he is trying to read out the nand chip not so long ago.
<esden[m]>
But the comments are mostly trash 😬
<esden[m]>
josHua (@_discord_256468461818085377:catircservices.org) most of the comments are "association word salad"
<joshua_>
Hey, I resemble that remark!
<whitequark[cis]>
calling someone a hacker news commenter is one of the most savage insults i can think of
<joshua_>
interesting choice to intentionally use gtkwave when you have Verdi available
<whitequark[cis]>
i know, right?
<whitequark[cis]>
although I haven't used Verdi, my headmate did, and while it's certainly not without its flaws (not least of which is that she had to use it via VNC that goes through an RDP jumphost, as is tradition) it's definitely an upgrade from gtkwave
<whitequark[cis]>
on the flipside, I finally understand what gtkwave's incomprehensible Verilog source mapping feature was patterned off of
<whitequark[cis]>
(it requires first preprocessing your Verilog files into tokens and then saving the token streams. unsurprisingly, literally nobody uses it)
<joshua_>
'via VNC that goes through an RDP jumphost, as is tradition', by the way, is something that some of you who have not worked for semiconductor companies will think is a joke, or hyperbole. it is not. it is in fact traditional.
<joshua_>
(the only surprising thing about that is that the Verdi is not X-forwarded from a compute farm machine into the interactive login VNC machine, which is then accessed from the RDP jumphost.)
<whitequark[cis]>
it was a small ASIC company, the entire FE team was like a dozen people
<whitequark[cis]>
well, the company wasn't small, but the ASIC division was
<whitequark[cis]>
(though I don't think I'll be sharing much if any details about it, it would be rude to violate an NDA she signed, I think)
<whitequark[cis]>
(it's a shame, there are certainly Stories. i think the NDA might expire in five years? maybe then)
<whitequark[cis]>
it's also how I learned to stop worrying and love Vivado
<whitequark[cis]>
by which I mean that I used to avoid using the Vivado GUI or Tcl interface as much as humanly feasible but after watching her edit a post-routing design in ECO mode, unroute a few wires, then use incremental routing to get something in 30 seconds instead of the 8 hours the bitstream would normally take to build, I've realized that actually both of those are really powerful tools that are thoughtfully designed
<whitequark[cis]>
though she definitely benefited from my knowledge of FPGA toolchain internals while doing that, because if you use Vivado like that, the error messages can go from "obscure" to "literally zero hits on google and the only way to even guess as to what goes wrong is by using your mental model of FPGA PnR algorithms and a guesstimate of how the Vivado architects probably designed their database"
<whitequark[cis]>
anyway, now I sincerely believe that the FOSS FPGA toolchain should be more like Vivado
<whitequark[cis]>
<joshua_> "(the only surprising thing about..." <- actually, going through those memories, this is *exactly* how it worked
<whitequark[cis]>
(this is a response to Verdi/X-forwarding message)
<Darius>
wow that sounds hideous
<Darius>
I've used Xpra to run X stuff remotely on radar systems which are far away, that is painful enough
<whitequark[cis]>
(image by Diego, but those who worked on ASICs will find it painfully relatable)
<joshua_>
yeah, that's correct
<Darius>
if only they would spend some money on making their tools/IP/etc less insanely hostile rather than jumping on the AI bandwagon
<joshua_>
the duality of the past and the future in the ASIC world always amused me
<joshua_>
like the ASIC (and, broadly, digital logic) world has debugging capabilities that are far superior (IMO) to linear-step-forward-and-print debuggers for debugging software
<whitequark[cis]>
... most of which FOSS HDL developers never see
<joshua_>
and the ASIC world *aggressively* uses formal verification for approximately every single thing they do, including to prove that the output of an extremely complex program transformation is identical to the input, both tasks that would be absolutely unheardof in the software development universe
<whitequark[cis]>
this isn't entiiiiirely true
<whitequark[cis]>
or rather, it's true but there are caveats that make this blanket statement misleading
<whitequark[cis]>
yes, you can and do LEC between every step, but this is because most steps don't touch registers
<joshua_>
they do all of this while using gigantic chunks of C++ that are astonishingly slow for no readily apparent reason, using workflows that involve latencies indeed comparable to Mars Curiosity
<whitequark[cis]>
the moment you start doing retiming you can no longer easily do LEC
<joshua_>
and, broadly, the ASIC world has not heard of niceties that grace software development like "types", or indeed, anything other than "bits"
<whitequark[cis]>
and if you try to, you end up deeply in a nightmare that is the same kind of nightmare as formal verification of software
<whitequark[cis]>
for the same basic reasons
<Darius>
joshua_: they sure do love their warnings though
<Darius>
which ones are important? who can say..
<whitequark[cis]>
also Verdi for example isn't that slow? I mean, yes, there were verification workflows involving starting the simulation on monday and examining the results on friday, but those were a large number of cycles on a large number of gates
<joshua_>
yeah, I think with modern flows LEC is maybe a little less pervasive. on the other hand, it is not just common but a requirement for, for instance, hand-synthesized ECOs, to have LEC to prove that the hand-designed ECO is equivalent to the input RTL
<whitequark[cis]>
we have LEC-style... things in software too
<whitequark[cis]>
for example Alive2 in LLVM
<whitequark[cis]>
it's actually more interesting because it's higher-order, proving not just a specific transformation but the entire class
<whitequark[cis]>
> Clang drop-in replacement with translation validation (alivecc and alive++)
<joshua_>
yeah, I think the slow tools I am dunking on are mostly Xilinx's and Lattice's, which spend multiple minutes serializing and deserializing databases between steps, whereas Yosys et al prove that it is feasible to, for instance, build for similarly complex parts in an amount of time that would allow you to, say, build it as part of a logic analyzer workflow
<joshua_>
we have it but it is not absolutely pervasive
<whitequark[cis]>
I remember once asking somebody who was using FPGAs in space which formal verification tool they were using
<whitequark[cis]>
they DM'd me with an answer which boiled down to "lol. lmao"
<whitequark[cis]>
while that's not ASICs, it's interesting that despite similar amounts of money being at stake people are much more cowboy about it in that area
<joshua_>
yeah, that's correct
<joshua_>
I think part of it in that case is "well we can update it", and, at least, for the other space-hardware FPGA company that I ahve talked with, their claim is mostly 'sure, but we launch 234982934 of these, and if they die they die'
<whitequark[cis]>
this is your brain on amazon
<joshua_>
or on cubesat, or something
<whitequark[cis]>
anyway, leaving Lattice aside for a moment (whose tools still derive from NeoCAD), Xilinx is something that's not supported by nextpnr for example
<whitequark[cis]>
and for good reason: nextpnr would die on a moderately sized Artix part, much less something like vu19p
<whitequark[cis]>
for which the uncompressed bitstream alone approaches something like 200 MB (that's bytes)
<Darius>
cripes
<whitequark[cis]>
vu19p is a very, very large three FPGAs in a stacked silicon interconnect structure
<joshua_>
afk, preparing an enormous amount of marinade so that I can attend Latchup this weekend while friends parallelize preparing dinner for passover on Monday night...
<joshua_>
contrast Decadence Palladium, which is three very, very, large FPGAs in a trenchcoat
<whitequark[cis]>
or maybe for?
<whitequark[cis]>
* or maybe four?
<whitequark[cis]>
four, apparently. my headmate used that for prototyping. it's a sight to behold indeed
icb has quit [Ping timeout: 256 seconds]
icb has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
FFY00 has quit [Read error: Connection reset by peer]
FFY00 has joined #glasgow
FFY00 has quit [Read error: Connection reset by peer]
FFY00 has joined #glasgow
FFY00 has quit [Read error: Connection reset by peer]
<whitequark[cis]>
well, there's still some cleanup in order
<whitequark[cis]>
Info: Max frequency for clock 'multiplexer.U$$0.U$$0.phy_clk_$glb_clk': 139.76 MHz (PASS at 125.00 MHz)
<whitequark[cis]>
Info: Max frequency for clock 'cd_sync_clk_if_0__i': 74.21 MHz (PASS at 48.00 MHz)
<whitequark[cis]>
I think I might be good at this "HDL" thing
<whitequark[cis]>
this applet would work for 1GBASE-T basically unmodified if not for the fact that the clock is half as fast as it needs to be (in 10/100 mode it's SDR, not DDR, and it's written for 10/100)
<whitequark[cis]>
(RGMII runs at 2.5/25 MHz for 10/100, so the constraint is just as high as it is to make sure the fast domain code remains fast)
notgull has quit [Ping timeout: 268 seconds]
omnitechnomancer has joined #glasgow
<omnitechnomancer>
I am somewhat amused by the method SGMII uses for 10/100 rate adaption
<whitequark[cis]>
that's the reasonable way to do it!
<whitequark[cis]>
meanwhile GMII does something bizarre
helle has joined #glasgow
<omnitechnomancer>
Well while it does keep the SerDes running at the same baud rate there is something a bit silly about repeating every byte 10/100 times
jstein has joined #glasgow
balrog has quit [Remote host closed the connection]
balrog has joined #glasgow
<smkz>
that's adorable..
jstein has quit [Quit: quit]
sauce has quit [Remote host closed the connection]
sauce has joined #glasgow
sapphire_arches[ has joined #glasgow
<sapphire_arches[>
vu19p is 4 logic dies that are I think reticle limited East/West and then stacked north/south on a silicon interposer with even more routing on the package substrate
<sapphire_arches[>
the next gen devices (VP1902) are 4 dies arranged as quadrants with over 2x the resources in pretty much every important axis (logic cells, io bandwidth and transceiver count)
<sapphire_arches[>
AMD did a talk about the high level architecture at HotChips 2023 that's a fun watch if you like drooling over obscene silicon
<sapphire_arches[>
it's explicitly targeted at being the foundation of accelerated presilicon RTL sim
<whitequark[cis]>
<omnitechnomancer> "Well while it does keep the..." <- think of it as being the logical extension of Dual Data Rate and Single Data Rate: One Hundredth Data Rate