Notices by Andrew Zonenberg (azonenberg@ioc.exchange), page 2

SPI plus an extra IO for flow control would work but of course now it's a 5 wire bus competing with 2. So difficult to justify the pin cost in most cases

Is there any way, in Vivado, to do "ex post facto timing analysis"?

In other words, can I take a post P&R design, write a new timing constraint, and (without attempting to change the existing design to meet it) get a timing report with the new constraint applied so I can see how far off I had been?

@whitequark ohhhh this is one of those weird FPGAs that get same-day air delivery to random farmers that didn't order them?

Almost as annoying as all the random armored vehicles in various states of disrepair getting left in clearly marked no-parking areas

@whitequark catherine it's not nice to hit your FPGAs if you haven't hooked up a SAFEWORD# GPIO they can asssert when they've had enough

@whitequark As of now I have a native sram interface to the memory (xilinx UltraRAM) but the latency is variable due to both the potential for me to add arbitration in front of it, and because I will likely be adding and removing pipeline stages for timing closure as the design evolves.

So i don't want my read-side logic to make any assumptions about latency

@whitequark This almost feels like it's going to turn into a task-flow architecture.

Where instead of reading data then processing the response, you issue a read request attached to a context object and then wherever it shows up gets the data along with instructions on what to do with said data

FPGA/ASIC people: when you have a complex state machine fetching data from a memory with unpredictable latency (e.g. AXI bus that may have contention, or external DRAM) how do you figure out what to do when the data comes in?

For my application there's no reordering possible within a single stream of requests so I'm thinking of having a FIFO of context objects that will "jog my memory" so that once data comes back, I know why it was read and how to handle it.

@dalias b... but then the public might be able to see that our code isn't perfect!

@mei GB vs GiB confusion somewhere in the stack?

@foone I've done this a lot especially in embedded stuff where you have an open source peripheral library or RTOS bolted onto closed source application code.

Find one xref to a SFR, match to the corresponding vendor HAL function, then you probably get 30 functions with minimal effort that are right before/after in the same order as the .c

@whitequark Is the URAM288 at the south end of a cascade chain a bottom (because of where it is) or a switch (because it can take either role with a new bitstream)?

I too like to put my RAM in a the middle instance

@ariadne Do you know what if any policy Debian has on this sort of thing?

I've found myself using flatpak builds of Firefox in a few cases to work around bugs that Bookworm didn't backport fixes for, but was not thrilled about crash reporting being (apparently) impossible to completely disable. You can make it not automatically submit, but it'll still save the crashdump and ask if you want to submit it (leaving potential for a user to accidentally say yes)

@0xabad1dea I used an XML-esque passphrase (something along the lines of <FooBarBaz/>) on PlentyOfFish circa 2013 because they demanded special characters even for absurdly long passphrases.

It worked fine.

Until my now-wife and I got serious enough I decided to delete my account. I had to type my password on the "delete account" page and for whatever reason on that page only (but not the login form or the creation page), it tripped the WAF and blocked the deletion.

I ended up experimenting a bit and discovered that I could still *change* my password and as soon as I had a password without angle brackets in it, I was able to delete the account.

@ireneista @stringlapse @glyph @steadilyebbing @xssfox (also, i can't stand when sites only let you enroll one TOTP authenticator. Bonus points if it's something that is absolutely not sensitive enough to need 2fa or that does not let me not use 2fa.

I generally avoid 2fa when I don't have to use it because I'm using strong per-site passwords and it just adds another layer of hassle. If you can steal my 16-character random alphanumeric password you've probably already RCE'd my endpoint or the server, and 2fa won't stop you. I mostly see it as a defense against password reuse which... i guess is probably helpful for the average consumer, maybe?

@whitequark @purpleidea @gsuberland Cool but not useful for my application (drying microscope samples, so I want very clean gas).

Even with high purity N2 I probably will want to add inline filters etc

@gsuberland yeah i dont want to deal with the noise and vibration nor do I have a lot of space for e.g. a cheap pancake compressor.

A little welding N2 tank is much more viable.

@gsuberland Fuuun.

You remind me I need to get a high flow rate CGA 580 regulator and some suitable tubing and connectors and a blow gun for my N2 tank (and maybe a larger tank). I wanted to stop using duster-gas cans for blowing samples dry after cleaning.

@gsuberland The cans work great from a contamination perspective, they're either HFC-134a (which I think I've entirely used up) or HFO-1234ze filtered to like 300 nm.

But they're expensive, not the most environmentally friendly (HFO-1234ze is lower GWP than HFC-134a but still not *great*), and during prolonged blowing the cans will freeze up and lose pressure so you have to round-robin several of them.

Even technical grade N2 is probably good enough, I can add an in-line dust filter or something if I see problems (will test), but I can always upgrade to UHP if I see issues. I don't have a compressor, nor do I have the space for one. I use little enough blow-gas that just driving a tank over to the lab makes more sense.

@whitequark Better than the debug hell I went through in my thesis work.

I was using a gdbserver I wrote to debug firmware I wrote, compiled against a libc I wrote, running on a CPU I wrote, hooked up to an interconnect I wrote, on a board I designed, using a FTDI-based debug dongle I designed.

And something was going wrong somewhere in the stack and the firmware was locking up (not a full deadlock, instructions were still executing, but it was stuck in a polling loop or something and not making any forward progress). I trusted nothing and had no idea where in the stack things were going wrong.

And it was on a very full xc6slx25 that had enough spare gates to fit *either* JTAG debug support on the CPU *or* a homebrew ILA to sniff a few internal signals. But not both.