14:36 <larsc> do you know if Xilinx publishes the trace length/delay for the FMC header signals for their boards?

14:50 <sb0> they publish gerbers I think

15:24 <larsc> yeah, that seems to be the only source

15:44 <sb0> iirc hyperlynx can compute that from the gerbers, i would assume ADI has a license for that

15:45 <sb0> not sure if there are free tools for this nowadays. let me know if you find one

15:55 <larsc> I usually just do it by hand by selecting the traces, works ok if it's only a handful

15:56 <sb0> you can also probably hack up some python script if there is a good gerber library

16:02 <larsc> That would be a nice task for the intern, if I only had one ;)

16:14 <cr1901_modern> Famous last words, but... how hard could it be to write a crappy script?

16:23 <sb0> considering the HK interns I have interviewed, extremely hard

16:24 <sb0> well, those I interviewed at all

16:25 <sb0> I have received amazing CVs (also not from potential interns). "achievements: mounted at least 12 hard disks on a busy day"

16:28 <larsc> that's impressive!

16:31 <cr1901_modern> I'm lucky if I can mount 2 hard disks... in a week.

16:32 <mumptai> and so relevant

16:33 <cr1901_modern> To be fair, anything involving image processing in my experience gets ugly fast

16:34 <mumptai> yes, and if it involves a webcam it will never work on demo-day ;)

17:36 <larsc> depends on the project, if it just a snapchat filter

17:38 <rjo> could be a good emva1288 implementation. or an optical transfer function measurement for a lens. ;)

17:43 <cr1901_modern> Optical transfer function. Do I even want to know?

17:43 <cr1901_modern> Probably some highly nonlinear "fun"

17:44 <whitequark> sb0: can you answer a few questions about lwip?

17:44 <whitequark> sb0: my main issue right now is that lwip wants me to do something with the data it provides inside a callback, but any given thread is not guaranteed to wait on that particular tcp connection

17:45 <whitequark> so in case no one waits on it, I want to tell lwip "save this data somewhere and wait until it's needed"

17:45 <whitequark> can I legally do that? the API docs are unclear

17:55 <sb0> isn't what tcp_recved() is for?

17:55 <sb0> this gets you flow control too

17:57 <whitequark> sb0: so what do I return from the callback, such that it doesn't free the memory?

17:57 <whitequark> oh nevermind, the callback frees the pbuf. clear now

17:58 <whitequark> on the other hand, maybe not

17:58 <whitequark> it says: If there are no errors and the callback function is to return ERR_OK, then it must free the pbuf. Otherwise, it must not free the pbuf so that lwIP core code can store it.

17:59 <whitequark> it looks like, unless I return some error from this callback, lwip won't store the pbuf... so I'll have to keep it myself

18:00 <whitequark> tcp_recved doesn't touch any pbufs. the only thing it does is advertises a larger window

18:00 <sb0> as I understand it: if you return ERR_OK, you are still responsible for freeing the pbuf. so you can keep it and free it outside the callback

18:02 <whitequark> ok, I can work with that, 

21:03 <cr1901_modern> sb0: Suppose I have three flip-flops connected in series. One of them is clocked at frequency "f", and the next is clock at "10f", and the third is clocked at "f". The 10f clk is generated from a PLL and thus IDEALLY are phase coherent. Will I get setup/hold time violations in practice?

21:03 <cr1901_modern> ideally the two clocks are phase coherent/have a small phase error*. Idk how small it is tho, nor am I sure it will cause problems

21:06 <sb0> timing analyzer sg

21:06 <sb0> should deal with that

21:06 <cr1901_modern> SG?

21:06 <sb0> but you may not meet 10f timing due to routing delays, maybe

21:07 <sb0> typo.

21:08 <cr1901_modern> Most flip flops actually receive their clock signal at the same exact time, so flip flops in series must have a small setup/hold time violation. But I guess there must be models that account for signal prop delay on the data path

21:09 <cr1901_modern> Curious how those are calculated (transmission line eq)

21:09 <cr1901_modern> Most flip flops DON'T actually receive* typo

21:11 <sb0> i wonder why you need such a design though

21:14 <cr1901_modern> sb0: I wanted to put an IIR filter one of the ice40 FPGAs. My sampling freq was 16 MHz, but the actual required bandwidth of my filter was a couple-hundred Hz. When I did bilinear transform and then a fixed point analysis I concluded I needed at least a 28-bit mantissa for my filter to work! >>

21:15 <cr1901_modern> Yea, I'm not trying to fit a 64-bit multiplier onto an FPGA. One way to reduce the precision was to downsample my master clock

21:15 <cr1901_modern> and I wanted to do this in the least painful way possible and have my master clock and filter clock phase coherent

21:16 <cr1901_modern> Idk if running the clock through a clock divider will keep the two clocks sufficiently in phase so clock domain crossing effects are negligible

21:19 <cr1901_modern> Something I've noticed about most of my design failures: It's like the entire digital world forgot how to do things on limited resources. They expect copious amounts of resources (clock speed, FPGA LUTs, functional units) to be a given.

22:07 <sb0> bah they are - and i don't even find them fast enough *g*

22:07 <sb0> maybe have a fake slow clock, i.e. CE. and serialize things to save resources.

23:38 <cr1901_modern> sb0: "bah they are - and i don't even find them fast enough *g*" Maybe I'm just too minimalist :P. Part of the reason I try to avoid bigger FPGAs is to be creative under limits. Mulling over the serialization route. That is probably doable, if it turns out I truly need the filter. And I can calculate the product of the filter one bit per cycle.