14:25 <sb0> whitequark, how is the si chip programming coming along?

14:25 <whitequark> figuring out the SoC right now

15:18 <britton> ARTIQ hardware FAQ posted to mailing list on April 8 to the mailing list. It states "The FPGA used in Sayma boards is XC7K325T (resource requirements: 28 kLUT, 14% of the chip per DAC IQ channel pair at 1.25 GS/s, 16 bit)." I assume the worst-case resource utilization for a single arbitrary (not IQ) channel is 28 kLUT. If planning on 8 such DAC channels 8*28 = 224 kLUT which is only 69% of XC7K325T. Right?

15:29 <sb0> britton, that chip has 203K LUTs

15:30 <sb0> for 7-series, the LUT count is CLB flip-flop divided by two. thank xilinx marketing for messing that up.

15:31 <sb0> look at XC7K410T or 420T

15:33 <sb0> and that's for 1.25GS/s, for 2.5 the resource requirements double

15:33 <sb0> (unless we do some clever tricks)

16:03 <sb0> wow

16:03 <sb0> I'm usually pissed with the state of linux hardware support, but this time it deserves credit

16:04 <sb0> had to scan some paperwork, scanner had a "out of order" label on it, after fiddling around with it a bit i notice the windows driver looks flaky

16:04 <sb0> so I connect the USB cable to my laptop, run xsane, click "scan", AND IT WORKS!!!

16:04 <sb0> amazing

16:05 <whitequark> this is my typical experience with linux hardware

16:06 <kristianpaul> indeed

16:41 <whitequark> sb0: ERROR:Xst:1817 - Invalid target device 'xc7k325t'.

16:41 <whitequark> does it not find the license file or something?

16:55 <britton> Thanks!

16:55 <britton> Somehow my IRC client froze.

16:58 <sb0> whitequark, you need to install the full version

16:58 <sb0> not webpack

16:58 <whitequark> urgh

16:58 <sb0> you can also just compile on the buildserver?

16:59 <sb0> this will also take care of licensing bullshit

16:59 <whitequark> that's too annoying

16:59 <whitequark> some sshfs bullshit that will crash my machine every time this ADSL decides that it doesn't want to put any packets through

16:59 <sb0> automate it with a script? the network delays should be small enough compared to the runtime of the xilinx bloatware

16:59 <whitequark> guess i could use rsync instead

17:00 <sb0> yes

21:26 <whitequark> why does xst infer both INV and LUT1?

21:26 <whitequark> isn't LUT1 either an inverter or a wire?

21:27 <whitequark> why does minisoc has 64 ISERDESE2 and 107 OSERDESE2?

21:28 <whitequark> oh, ethernet

22:05 <_florent_> whitequark: the ISERDESE2 and OSERDESE2 are instanciated in the DDR3 PHY

22:15 <whitequark> oh

22:15 <GitHub127> [si5324_test] whitequark created master (+1 new commit): https://github.com/m-labs/si5324_test/commit/1daacf06cac8

22:15 <GitHub127> si5324_test/master 1daacf0 whitequark: Initial commit.

22:15 <whitequark> where do 43 more OSERDESE2 come from?

22:41 <whitequark> sb0: I see this in i2c_halfperiod: timer_kernel_load_write(CONFIG_CLOCK_FREQUENCY/10000);

22:41 <whitequark> that means i2c is running at 5000Hz? or is timer not clocked with the system clock?

22:43 <whitequark> also, why is the update_value CSR register needed for the timer?

23:08 <GitHub36> si5324_test/master f9b2715 whitequark: Add I2C stuff.

23:08 <GitHub36> [si5324_test] whitequark pushed 1 new commit to master: https://github.com/m-labs/si5324_test/commit/f9b2715f49660fea209f3f225263be4b4fa77490