04:20 <rjo> sb0: i would like to see a good week of work focused on docstrings, documentation and unittests. then i would suggest looking at the area of exceptions, queue management, and adding another controller for e.g. the pdq2.

04:21 <rjo> sb0: during that part the required language and compiler refinements should become apparent.

04:25 <rjo> sb0: which aspect of the SYNCLK skew? skew between the SYNCLKs of the different chips due to their dividers is handled by the master reset synchronizing the clocks. skew between synclk and fud does not matter since it is constant between pll relocks and the plls originate from a common source.

05:01 <sb0> well, yes, but theoretically you need to meet the 4ns setup requirement of FUD wrt SYNCLK

05:04 <sb0> otherwise you can get a jitter of 1 SYNCLK cycle, or maybe even metastability

05:21 <rjo> yes. that is not ensured. the alignment between fud and synclk is fixed so it's either always or never. but i don't think anyone ever measured whether we actually meet setup.

05:21 <rjo> if we don't meet it and there is jitter, iirc we live with it. same for metastability.

05:24 <rjo> i vaguely remember seeing a measurement that showed that synclk actually rises _half_ a synclk cycle offset after falling reset. and that consistently. we might be consistently fud-ing 4ns before synclk rises.

05:26 <sb0> let's fix this small problem then... all it'd take is clock the core device from SYNCLK and then adjust the delay while measuring FUD and SYNCLK at the DDS chip with a scope

05:28 <rjo> that would make resetting the dds a bit complicated.

05:29 <rjo> and that is required to align the synclks.

05:29 <sb0> we can try to have the core device dynamically switch clocks

05:30 <sb0> the main issue would be the SDRAM which needs a stable clock for refreshes and for keeping its DLL locked

05:31 <sb0> if we're not careful, while the FPGA is switching clocks and re-locking its PLLs, the SDRAM might get its data corrupted and/or its DLL messed up

05:31 <rjo> i would just hook up synclk to a rtio input and measure where it falls, then factor in cable delays (calibrated).

05:32 <sb0> hmm, but then we need constant software-based recalibration

05:32 <rjo> why?

05:33 <sb0> because the core device's system clock and the synclk will drift

05:33 <rjo> they come from the same source and are plls. you mean temperature/vcc drifts?

05:33 <sb0> ah

05:35 <sb0> ok, then we just need a constant delay between the system clock and FUD. it's the same situation as when clocking the core device with SYNCLK...

05:35 <rjo> yes.

11:08 <sb0> rjo, isn't the reset signal also gated by the selection signal in the DDS boxes?

11:09 <sb0> it also goes through U1 in your schematics...

11:10 <ysionneau> sb0 hi :) Just received your stickers ;) Thanks!

11:11 <sb0> the current DDS routine in the runtime does "DDS_WRITE(DDS_GPIO, 1 << 7)", which is incorrect then. I see you're doing "DDS_GPIO |= 1 << 7" in dds-ttl-tester... not sure where the error is coming from. I might have overlooked that when copying the code...

11:17 <sb0> ysionneau, cool

11:17 <sb0> btw are you going to orconf?

11:22 <ysionneau> I was motivated to go there yes

11:22 <ysionneau> as visitor (not speaker)

11:22 <ysionneau> but haven't booked anything yet

11:24 <ysionneau> last orconf in Cambrige was pretty cool :)

11:27 <GitHub110> [ARTIQ] sbourdeauducq pushed 1 new commit to master: http://git.io/PzcJSA

11:27 <GitHub110> ARTIQ/master 800096f Sebastien Bourdeauducq: soc/runtime: fix DDS reset

11:29 <ysionneau> if you want me to go poke stekern irl to say the core is bloated ;)

11:30 <ysionneau> I might get into troubles though, he's taller than me

12:04 <stekern> :)

12:05 <stekern> I think we're about the same size in the other direction though

12:06 <ysionneau> ahah sure

12:15 <stekern> besides, I don't get upset about legitimite criticism.

12:22 <ysionneau> yes I think we could all see that

12:22 <ysionneau> I was just joking :)

12:24 <stekern> I know :)

12:25 <stekern> I'm actually doing some investigation of where the 'bloat' comes from, so sb0 whining strategy give results ;)

12:31 <ysionneau> stekern: I cannot find back the page about ORCONF where it says "conference start at XXh on saturday and ends on XXh on sunday to let everyone travel during the week-end without taking day off"

12:32 <stekern> I don't think the schedule is set in stone yet

12:33 <ysionneau> but at least I think I've read somewhere the start time and end time

12:33 <ysionneau> but I don't remember where

12:33 <stekern> I think that was for last year

12:34 <ysionneau> ah, the eventbrite gives some hours : https://www.eventbrite.co.uk/e/orconf-2014-tickets-12592710135

12:35 <stekern> look, you know more than me ;)

12:52 <stekern> interesting, disabling the shifter shaves away 460 LUTs...

12:53 <FabM> BO00021

12:57 <FabM> oups

13:23 <_florent_> hi

13:23 <_florent_> sb0, thanks for the stickers :)

13:24 <_florent_> stekern, from what I saw some time ago on the mor1kx:

13:25 <_florent_> you can optimize the shifter as it's done on the LM32:

13:25 <_florent_> https://github.com/m-labs/lm32/blob/master/rtl/lm32_shifter.v

13:25 <_florent_> instead of shifting in the 2 directions, you reverse the bit at the input and output and shift only in one direction

13:26 <_florent_> (sorry hadn't find time to do it and add a simulation env working)

13:28 <_florent_> on the store buffer, I also find strange that you have to save the fifo_dout in fifo_dout_r

13:29 <_florent_> fifo_dout is already registred at the output of the ram

13:29 <_florent_> and it's a large register

13:30 <_florent_> it's probably possible to change the control of the ram (or use a specific ram) to avoid that

13:38 <_florent_> but it's easy to say that... less to do it and find time for it...

13:44 <ysionneau> sb0: I just booked my flight so I will go to orconf

14:08 <stekern> _florent_: i had completely forgot about that, yes adding a read enable to the ram would render that unnecessary

14:09 <stekern> but, I'm adding an option to disable the store buffer too

15:13 <GitHub163> [ARTIQ] sbourdeauducq pushed 5 new commits to master: http://git.io/wePkrQ

15:13 <GitHub163> ARTIQ/master 1b58e15 Sebastien Bourdeauducq: soc/rtio: mini-channels

15:13 <GitHub163> ARTIQ/master 7efc28e Sebastien Bourdeauducq: soc/ad9858: do not drive FUD by default

15:13 <GitHub163> ARTIQ/master 202284d Sebastien Bourdeauducq: soc/rtio: software-controlled replace

15:16 <GitHub105> [ARTIQ] sbourdeauducq pushed 1 new commit to master: http://git.io/YTWt9A

15:16 <GitHub105> ARTIQ/master 10d796e Sebastien Bourdeauducq: runtime: add rtio_replace syscall

19:10 <stekern> oh, ISE you silly old chap... map report claims an *increase* in LUTs after this commit: https://github.com/openrisc/mor1kx/commit/2440fab3531931a5b06f12ed873d1c041a009428