01:36 <Astro-_> zc706 qspi flash status: implemented on the device but crashes it :/

01:37 <sb0> Astro-_: crashes how?

01:37 <sb0> even if there's no DMA or anything?

02:18 <sb0> in a basic PLL (e.g. 4046-based), the frequency is proportional to the control voltage, and a simple RC low-pass loop filter is often used. now I have a system where the *rate* of frequency change is proportional to the control voltage. is there a simple modification that I can make to the loop filter to get the PLL to lock?

02:22 <sb0> I'd guess putting something like a proportional+derivative circuit after the low-pass filter that smooths out the the phase detector output?

02:24 <sb0> maybe just another RC?

03:32 <cr1901_modern> sb0: Put an integrator between the system output and the feedback signal of the PLL to convert from rate of freq change to frequency?

09:24 <mtrbot-ml> [mattermost] <hartytp> Try writing down the phase transfer function for the open loop system. Also write down the tf you want it to have. Then it’s easy to design a compensator to map one onto the other

12:32 <Astro-_> sb0: I was trying linear address mode to map it into memory space. the alternative is programmed I/O mode.

13:10 <sb0> Astro-_: seems there's a lot of on-chip memory, so the bootloader can be executed from there and we don't really need execute-in-place

13:11 <sb0> the Zynq ROM can copy an arbitrary program from the flash into OCM and then run it, right?

13:13 <sb0> hm the artiq firmware config.rs uses the memory-mapped flash

13:13 <whitequark> sb0: so here's an interesting issue with (n)migen simulators

13:13 <whitequark> let's say you write a process that replaces some piece of sync logic

13:14 <whitequark> if you have some HDL sync logic, then a testbench can reach in and overwrite the register values with whatever it wants. that is deterministic in both migen and nmigen simulators because they both run HDL processes first and bench processes second

13:15 <whitequark> but if you replaced that HDL sync logic with a Python process, now it's no longer deterministic because you're relying on the order in which those run

13:16 <whitequark> two different processes assigning a single signal to different values in the same delta cycle is always a (possibly latent) bug

13:16 <whitequark> different values to a single signal*

22:34 <Astro-_> the rust libunwind situation is still very unsatisfying...

22:36 <Astro-_> maybe I should leave cargo-xbuild and return to the nix approach that already works well in artiq-fast

22:40 <whitequark> Astro-_: which situation?

22:44 <Astro-_> it's neither exposed nor built with xbuild

22:44 <whitequark> ah, and backtraces depend on it?

22:44 <whitequark> oh right, exceptions in ksupport as well