03:20 <zyp> is the Memory-class supposed to work with xilinx ise?

03:20 <zyp> «INFO:Xst:738 - HDL ADVISOR - 2048 flip-flops were inferred for signal <mem>. You may be trying to describe a RAM in a way that is incompatible with block and distributed RAM resources available on Xilinx devices, or with a specific template that is not supported. Please review the Xilinx resources documentation and the XST user manual for coding guidelines. Taking advantage of RAM resources will lead to improved device usage and reduced synthesis time.»

03:22 <rjo> zyp: i have seen it spit out that warning if the memory was just small but still implementable with bram. but if yours is large you are likely using asynchronous reads. just add a register.

03:22 <zyp> I'm trying to use the wishbone.SRAM wrapper

03:23 <rjo> IME that works fine

03:25 <rjo> is it small?

03:25 <zyp> I've tried multiple sizes

03:25 <zyp> and none seems to work

03:25 <rjo> what's your wishbone interconnect?

03:26 <zyp> currently connecting it directly to a master that I've written myself

03:26 <sb0> zyp, what ise version are you using, and for what fpga?

03:27 <sb0> I've used Memory/wishbone.sram on many different versions and with s6 and k7, and used the same memory coding style on v4 before with no problem...

03:27 <zyp> latest, s3a

03:29 <rjo> zyp: how does the sythesis describe the inferred ram?

03:29 <rjo> synthesis even.

03:30 <sb0> zyp, try on a simple case - just create a Memory, export to verilog, run through ISE

03:31 <sb0> oh wait... could be a problem with the byte-wide write enables

03:31 <sb0> iirc s3a doesn't have those

03:31 <zyp> it does

03:33 <zyp> I've already tried making an instance of the RAMB16BWE primitive and hooking that up, which works

03:34 <zyp> but I don't like losing flexibility/portability in that way

03:36 <sb0> well, it should work really... the migen output for Memory is almost straight from the xst coding guide...

03:37 <sb0> there's also a transform that removes the byte-write enables and breaks the 32-bit memory into four 8-bit memories

03:38 <sb0> because synthesizers have problems with BWE sometimes

03:38 <zyp> okay, it's great to hear that it should work, now if it only would work too, I'd be happy :)

03:38 <sb0> try on simple cases

03:39 <sb0> start with a basic memory, check that ise compiles it correctly, and add features until it breaks

03:39 <zyp> how would I go about compiling only a basic memory?

03:40 <sb0> this generates verilog that you can run through xst: https://github.com/m-labs/migen/blob/master/examples/basic/memory.py

03:41 <sb0> remove most memory features and check that it compiles it correctly

03:41 <sb0> you only need xst - no need to bother with par and pin constraints

03:46 <zyp> same result

04:01 <sb0> well edit the verilog and get it to work

04:01 <zyp> working on that

04:02 <sb0> is that will all the options, or did you make a simple memory?

04:02 <sb0> the example uses a lot of options

04:02 <zyp> I simplified the example and got it to work

04:02 <zyp> adding byte lane enables broke it again

04:06 <sb0> https://github.com/m-labs/migen/blob/master/migen/fhdl/simplify.py#L6

04:07 <sb0> you can apply that globally in misoc with a make.py command line arg

04:07 <sb0> or find some BWE coding style that xst groks for all fpga families ...

04:08 <sb0> or hook the code generator for s3a if you can't find something that also works for k7/s6

04:11 <rjo> sb0: i added slides: https://github.com/nist-ionstorage/artiq/commits/taaccs-slides

04:15 <sb0> rjo, nice!

04:15 <sb0> thanks!

04:16 <sb0> rjo, btw quick question about those DDS - each DDS chip has a different SYNC_CLK phase, right?

04:16 <sb0> so we can't just sync the whole experiment to a SYNC_CLK pulse as Daniel suggests

04:21 <zyp> http://www.xilinx.com/support/documentation/sw_manuals/xilinx14_7/xst.pdf <- page 162

04:22 <zyp> «XST currently supports this method only.»

04:22 <rjo> sb0: we have no indication that the sync_clks are actually synced. they nominally do synchronize (somewhat, see later) at reset. but we don't have a synchronous reset across all boards (and there is wire-length-skew). the more interesting problem is the 1ghz phase. there is some indication that even if the divide-by-2 is disabled at all times, the 1ghz clock phase is undefined inside the dds.

04:22 <rjo> there was a thesis that i quoted some time ago that explores that.

04:26 <sb0> yes, I read it. so you confirm that we need one SYNC_CLK per DDS chip, and proper FUD timing can't be done by simply syncing the whole experiment to one SYNC_CLK?

04:27 <sb0> this new board uses the AD9914 ...

04:29 <rjo> sb0: yes. there would need to be a few changes to the hardware to sync the synclks. parallel and matched resets.

04:29 <sb0> yes, and this sync would not even be guaranteed by the DDS chip specs, right?

04:30 <rjo> people will want to use their old ad9858 cards as well

04:31 <rjo> is the pcb is changed as in that thesis, it should work afaict.

04:32 <sb0> but those old cards don't send SYNC_CLK through the backplane anyway, right?

04:32 <rjo> yes.

04:34 <sb0> I think Daniel is talking about new DDS cards, so those can have SYNC_CLK synchronization

04:34 <sb0> so what we can do is

04:34 <sb0> 1) when using the old cards, do like it's done now (with jitter and FUD setup violations)

04:34 <rjo> sb0: you could mux the synclks onto one and then have dds-dependend fud-shifts.

04:35 <rjo> mux the synclks and a feedback for fud.

04:35 <sb0> 2) when using the new cards, sync all SYNC_CLKs into one, and time the experiment to a SYNC_CLK edge

04:36 <sb0> rjo, mux the synclks of the old cards (with an additional cable and multiplexer board), or the new ones?

04:38 <rjo> whether we can sync the synclks into one remains to be shown. till's measurements from a while ago indicated that for the ad9858 (1ghz clock), the synclk jittered 3.5ns relative to the reset (which i believe was synchronized/derived from the 1ghz clock).

04:39 <sb0> <rjo> is the pcb is changed as in that thesis, it should work afaict. <<< so no?

04:39 <rjo> sb0: old ones. for the new ones on the new backplane there are enough pins.

04:40 <rjo> sb0: never for the old ones. maybe for the new ones if their behavior is different.

04:41 <rjo> (the first answer was re mux, the second re syncing synclks)

04:42 <sb0> ok. so we should implement something that assumes different synclk phase for each dds chip, right?

04:42 <sb0> and not bother with trying to synchronize the synclks

04:46 <rjo> well. there seems to be a way to synchronize multiple ad9914, (vaguely) described in the datasheet.

04:47 <rjo> for the ad9858 i don't think that there is any way to synchronize them without pcb changes.

04:48 <rjo> https://ez.analog.com/message/76546 analog is also starting to write datasheets in the form of moderated forum replies.

04:48 <sb0> so what should we do? assume non-synchronized synclk in the software/gateware for now, but keep the synchronization option open in the hardware?

04:49 <sb0> zyp, I wonder how they managed to mess up their code in a way that the other coding style works for k7/s6 and breaks for s3a

04:49 <sb0> I'm glad I'm not on the xst development team

04:50 <rjo> sb0: gimme a minute. need to think about this.

04:51 <rjo> looks like some of the secrets of the ad9914 are explained in the ad9915 (sic) datasheet...

04:51 <rjo> oh lord: "If you need to run faster than 2.5 GHz, then the AD9914 cannot be synchronized reliably/repeatably. We excluded the synchronization section from the data sheet to avoid the issue where users try to synchronize at higher speeds and find that it isn't working."

04:52 <rjo> i guess that answers it.

04:53 <rjo> can i have the satisfaction to post that?

04:53 <stekern> sb0: RAM instantiation is a big mess. byte enable and different sized data ports are especially painful.

04:54 <stekern> and remember that you should always use write-before-read

04:57 <rjo> sb0: ok?

05:00 <sb0> ok

05:04 <rjo> sb0: but measuring them individually beafore each experiment has a penalty afaict. the timings will not be known at compile time. otoh, doing it once after each reset could work.

05:05 <sb0> we can have the runtime compute the exact timing of the FUD pulse dynamically (in the dds_program function) based on the measured synclk phase at initialization

05:05 <rjo> sb0: that reminds me. did we discuss making the data path for the dds RT as well?

05:06 <sb0> this will still cause a FUD jitter of 1 synclk, but will fix the FUD setup violation problem

05:06 <rjo> won't that break e.g. inlining?

05:06 <rjo> sorry interleacing

05:06 <rjo> interleaving.

05:07 <sb0> we didn't discuss it, but I'm not sure if it's needed

05:07 <sb0> the main advantage over the current software solution is you can queue several updates in advance

05:08 <sb0> if you need short bursts with many frequency updates, then yes, that would help

05:08 <rjo> sb0: on the output side we tend to do about as many dds register updates as ttl pulses.

05:09 <sb0> RTIO data bus would only help with the burst performance, not really with the sustained performance

05:11 <rjo> sb0: i would estimate that we want peak FTW+POW rate close to the max rate across that bus.

05:14 <rjo> sb0: the worst case are back-to-back microwave pulses with different phases.

05:23 <rjo> sb0: re fud shifting, do you mean ignoring the shifts at compile time and then tweaking pulses at runtime?

05:25 <rjo> the other question is the FUD layout of the new boards. i believe the "addressable fuds" as they are now are not the future. we either need individual fuds or a single parallel one.

08:38 <ysionneau> morning

08:43 <sj_mackenzie> morning

08:45 <sb0_> rjo, yes, the compiled kernel just sends the current time counter value into the runtime's dds_program, and the latter adjusts it to the closest value for which the setup time is met

08:46 <sb0_> runtime-level knowledge of FUD timing enables it to initialize the DDS (which requires FUD) independently from the compiler infrastructure

08:48 <sb0_> stekern, recognizing a RAM pattern from HDL and extracting it should be an independent pattern than mapping a parameterized RAM to a FPGA architectures. synthesizers like xst with which it is apparently not the case look cheesy to me.

08:48 <sb0_> *an independent problem

09:50 <stekern> sb0_: I agree, it's just that it's not the way things are.

09:52 <stekern> I see that my note on write-before-read was confusing too, I got rushed by the busschedule. What it was supposed to say was that you have to *explicitly* describe write-before-read with bypass registers, XST might otherwise silently implement them as read-before-write

09:52 <sb0_> one day we should support synthesis directly from migen ;) if you want to help with that, zyp, you can also solve your problem by writing python code that takes a migen fragment and replaces Memory with instances of S3A block RAM primitives

09:53 <stekern> which is 'oh so fun' since it doesn't match the simulations

09:53 <sb0_> also, rewrite the simulator so it does not depend on icarus verilog and the fucked up event model of Verilog/VHDL

09:55 <sb0_> though another way to solve the current simulation bugs is to turn the representation into semi-SSA form, which can also help writing a synthesizer...

11:08 <GitHub21> [artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/F8fmKA

11:08 <GitHub21> artiq/master 97329b7 Sebastien Bourdeauducq: transforms/inline: offload some work to remove_inter_assigns/remove_dead_code

11:35 <sb0> rjo, there's also the "attentuators" on lab_hardware.jpg, but it's harder to fix... do you have the editable file?

11:35 <GitHub19> [artiq] sbourdeauducq pushed 3 new commits to master: http://git.io/9OcYRA

11:35 <GitHub19> artiq/master 397f373 Sebastien Bourdeauducq: Merge branch 'master' of github.com:m-labs/artiq

11:35 <GitHub19> artiq/master 2a00229 Sebastien Bourdeauducq: slices/taaccs: fix typo and permissions

11:35 <GitHub19> artiq/master b78e0b3 Robert Jordens: add TAACCS seminar talk

14:57 <larsc> yeay, labview

14:58 <sb0> high viscosity language :-)

15:03 <ysionneau> crazy picture with all the hw stuff =)

15:59 <sb0> larsc, do you know what happens if the 2ns setup time of the IO_UPDATE pin of the AD9914 is not respected? only jitter (if the pulse spans several cycles), or can more nasty things happen?

16:04 <larsc> no... I have no idea

20:55 <rjo> sb0: re fud shifting. i'

20:56 <rjo> ... ll have to think about what that means for the experiments. the impact is a bit hard to gauge.

20:58 <rjo> sb0: re slide. yes that was a 3am hack and i didn't have time to do a nice tikz picture for it... thanks for pointing it out. i'll do the tikz picture. that'll also shave of a few 100kB.

22:07 <rjo> sb0: https://github.com/nist-ionstorage/artiq/tree/taaccs-slides