11:55 <sb0> whitequark: ping re. compiler FP slowness issue

11:56 <sb0> hartytp: did you sort out the kasli crash with your bitstream builds?

12:33 <rjo> hartytp: but incrementing it only in the cpld code breaks it as well.

13:22 <hartytp> rjo: sorry, yes. I'd changed that to a >= but forgot to push that commit. will do on monday when I test on hw

13:22 <hartytp> sb0: currently on the board I was testing on the slow cpu crashes, I assume to the ram issue

13:22 <hartytp> the faster cpu fails to meet timing but seems to work

13:23 <hartytp> Techno sytem are sending me a Kasli with faster FPGA. If I can get that in time, I'll test on that with the higher CPU speed, otherwise I'll test on a build that fails timing but doesn't seem to crash...

13:24 <hartytp> I'm having trouble getting su-servo to meet timing on satellites as well. Coming to the conclusion that I should should just upgrade all the Kaslis we have to the -3 speed grade

13:28 <rjo> hartytp: that will break when there is an incompatible cpld version in the future.

13:30 <sb0> strangely enough, changing the idelay reference frequency to 300 or 400mhz doesn't increase the reported window, but makes it disappear completely

13:34 <sb0> ah, but that's because the range is reduced

13:34 <sb0> and it never reaches the working region

13:35 <sb0> how does the idelay tap calibration work? is there a good reason for limiting the "tap" count to 32 in all cases?

14:11 <hartytp> rjo: yes

14:12 <hartytp> worse it seems to me is that if someone is shipped v1.3 hw with the old cpld release then no error will be flagged

14:12 <hartytp> do you have a preferred solution to this? I'd rather not make everyone update their urukuls

14:13 <hartytp> another option would be to add a hw-rev entry to the urukul device db (defaults to v1.2) and then check for a different cold version for each hw rev

14:14 <hartytp> s /cold /cpld

15:19 <sb0> well that ram issue isn't supposed to happen...

15:23 <sb0> hartytp: can't the driver simply probe the cpld version and then act accordingly?

15:23 <sb0> i.e. support the two versions, with autodetection

15:27 <sb0> hartytp: the preferred solution is a hardware revision encoded by setting some cpld pins

15:43 <rjo> hartytp: artiq needs to handle both cpld code versions and prevent anything else. i need to point out that you said it's trivial and you'd take care of it. the cpld gateware doesn't necessarily need to be compatible with both hardware versions.

15:48 <rjo> existing device_db and user code impact should be kept ALARA.