<azonenberg>
size and relative positions of flash, eeprom, and ADC blocks (all visible at this magnification, you cant actualyl tell what they are but i've seen the chip up close so i know)
<rqou>
btw dips are actually more difficult than qfps
<azonenberg>
Yes they are
<azonenberg>
I normally pre-drill the top with an endmill
<azonenberg>
to get down to maybe 200um above the bond wires
<azonenberg>
then finish with acid
<azonenberg>
With a large QFP you can skip that and just etch all the way through
<rqou>
yeah
<azonenberg>
If i'm trying to recover a bare die, if at all possible, I'll use a QFN or WLCSP or something like that
<azonenberg>
while if i want it live, i'll use the largest package i reasonably can
<rqou>
also, i never realized just how space-constrained a standard dip is
<azonenberg>
just wait till you decap a large QFP
<azonenberg>
giant leadframe coming down to super tiny points near the die for wirebonding
<azonenberg>
try doing a tqfp144 with a small die :p
<rqou>
i did that before
<rqou>
that's how i ended up with an "unintended uncontrolled reaction"
<azonenberg>
Lol
<azonenberg>
what did you do, use piranha?
<rqou>
whole chip in hot sulfuric acid
<rqou>
that was the xc95288xl
<awygle>
Gonna guess piranha is a brand name or nickname or something, but I'll treasure that mental image
<rqou>
awygle: sulfuric acid+hydrogen peroxide
<rqou>
very strong oxidizer
<rqou>
your surface will definitely not have organic contaminants afterwards :P
soylentyellow has joined ##openfpga
rk[ghost] has quit [Ping timeout: 248 seconds]
Dolu has joined ##openfpga
rk[ghost] has joined ##openfpga
eduardo__ has joined ##openfpga
eduardo_ has quit [Ping timeout: 256 seconds]
ZipCPU|Laptop has quit [Quit: Warp drive ready at your command, Captain!]
inode has quit [Quit: ]
indy has quit [Ping timeout: 246 seconds]
pie_ has joined ##openfpga
pie__ has joined ##openfpga
indy has joined ##openfpga
m_t has joined ##openfpga
pie_ has quit [Ping timeout: 260 seconds]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<sorear>
Dolu: which is the fast one and which is the slow one?
<Dolu>
the fastest one is the compiled from sources riscv-gnu-toolchain
<Dolu>
by 30%
<sorear>
straw poll: of the people here who are into riscv stuff and aren't in #riscv, is it by choice or because we suck at advertising?
<cr1901_modern>
sorear: ETOOMANYCHANNELS
<Dolu>
advertising for me ^^
<cr1901_modern>
But seeing as I'd like to ask the boom_cpu creator some q's, I prob should at least idle/add it to my list
m_t has quit [Quit: Leaving]
<awygle>
whitequark: is instrumenting pcie using a vm a "standard" thing or would it involve e.g. qemu hacking?
<sorear>
so I'm hazy on the precise dates but dhrystone makes exceptionally heavy use of global variable access and 30% is about right for the difference between PC-relative and GP-relative accesses
<whitequark>
awygle: no idea
<whitequark>
it's just obviously possible
<awygle>
sure, it's a good solution
<sorear>
[more cynically I might describe the global pointer stuff as an almost dhrystone-specific optimization]
<Dolu>
sorear : XD
<Dolu>
Sadness that the dhrystone benchmark is is only about 300 instruction per loop too
<Dolu>
I will check tomorrow the GP/PC relative stuff
<cr1901_modern>
What level of pcie would a VM emulate? TLP? Link-Layer?
<whitequark>
none of it
<whitequark>
you just intercept memory accesses
<whitequark>
come to think of it this doesn't handle DMA by the device
<cr1901_modern>
I wouldn't be surprised if there's a opt-in way to do that in Linux (like UIO), but I know nothing about it
Dolu has quit [Ping timeout: 265 seconds]
<whitequark>
what?
<whitequark>
that makes no sense
<pie__>
yeah thats why the lot of s on the guessss :P
<gruetzkopf>
what do you want to do?
<cyrozap>
pie__: It's fairly straightforward to sniff PCIe, it just depends at what level you want to stiff at. If you want to see the TLP layer, you'll need some hardware, but it doesn't need to be particularyly fast--even RS232 speeds will work: https://media.ccc.de/v/33c3-7946-console_hacking_2016#t=465
<cyrozap>
pie__: To build on what whitequark was saying, if you just want enough information to, for example, write a driver, you can run the program in a VM and do PCIe passthrough, then log all the accesses from the VM.
<gruetzkopf>
if you need to look at a linux driver you don't have source for, mmiotrace is your friend
<cyrozap>
pie__: It is a _little_ tricky, since by default qemu will just let the VM mmap the PCIe device's address space, so you have to configure it to not do that.
<sorear>
yeah this whole thing depends on what you're actually trying to do
<awygle>
what if i wanted to develop pcie hardware that was drop-in compatible with an existing linux driver?
<cyrozap>
awygle: Then just read the driver sources and base your work on that :P
<awygle>
cyrozap: well yes :P but since you have to deal with TLPs in the hardware/HDL, it'd be nice (but not necessary) to be able to look at them
<awygle>
for debugging etc
smkz has joined ##openfpga
<cyrozap>
awygle: But the kernel doesn't care about TLP layer stuff, it's just memory reads and writes. I mean, yes, the lower layers of the stack care about that, but that's like saying you need to care about Ethernet frames when writing a userspace TCP/IP application--if you need to debug the lower layer protocols, that's done independently from the upper layer protocols.
<awygle>
cyrozap: sure but from wireshark you can get Ethernet, IP, TCP, or HTTP depending on what you need. it's true that you probably can't get TLPs from Linux or even qemu because of how pcie is, but it would be cool if you could.
<cyrozap>
awygle: Oh, yeah, it totally would. I use Wireshark for USB stuff all the time and it's fantastic. Doesn't help you with the USB PHY protocols, though--you still need a scope/LA/low-level protocol analyzer for that.
user10032 has quit [Quit: Leaving]
diamondm1n has quit [Remote host closed the connection]