01:22 <sb0> hartytp: might try https://digicom.org/ - they're doing radio astronomy boards for CASPER

01:23 <sb0> similar complexity as sayma or more

02:35 <sb0> vadatech also sounds interested, but idk about their experience with sci projects

03:57 <GitHub-m-labs> [artiq] sbourdeauducq commented on commit dbf4e78: Thanks! https://github.com/m-labs/artiq/commit/dbf4e78087999f7d492fd461be27eab58563611e#commitcomment-30586534

05:21 <GitHub-m-labs> [migen] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/migen/commit/56f359d6dc5fff01b36796c8667dd4b58c0428c9

05:21 <GitHub-m-labs> migen/master 56f359d Piotr Esden-Tempski: Added icebreaker platform. (#135)

05:27 <bb-m-labs> build #316 of migen is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/migen/builds/316

05:38 <cr1901_modern> Gives me a warm and fuzzy feeling when someone adds a board to Migen

05:38 <cr1901_modern> Add All The Boards

05:46 <cr1901_modern> esden: In practice I've used "user_led" even for different colored LEDs. The "_n" is def a good idea tho (and I would've missed that had I been porting icebreaker)

05:48 <esden> Yeah I have seen that in the other platform files. We had a back and forth with Clifford regarding the negative and positive logic led... and decided to have both on the board as a good opportunity for a student to learn the difference and why it is done in practice. :)

05:48 <esden> I am trying to cover a reasonable area of supported "toolchains" migen is definitely quite high on that list. :)

05:51 <cr1901_modern> This isn't high on anyone's list, but I'd like to see exceptions to the consistent naming scheme changed to be consistent at some point...

05:51 <cr1901_modern> Not that the consistent naming scheme is even documented anywhere

08:01 <hartytp> _florent_: thanks

08:01 <hartytp> but, any idea what can cause that?

08:02 <hartytp> is this likely to be SI?

08:02 <hartytp> am I right in thinking that both the DACs and FPGA must be receiving a clock at the correct frequency for the PLLs to lock? So this error isn't due to an incorrect clock

12:02 <hartytp> rjo: why is there a runt clock cycle at the end of each spi write?

12:02 <hartytp> e.g. why do 1 get 12 clock cycles for a 11-bit SPI transaction?

12:03 <hartytp> aah, is the length param 1+ the number of bits written?

14:55 <rjo> hartytp: spi2? the gateware param length is number of bits minus 1

14:57 <hartytp> thanks, figured that out

14:57 <hartytp> should have checked the source more carefully before asking

15:38 <rjo> hartytp: np.