07:29 <GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1142: It's just a nicer UI.... https://github.com/m-labs/artiq/issues/1142#issuecomment-441955788

12:02 <GitHub-m-labs> [artiq] klickverbot commented on issue #1142: In terms of injection, what would be higher priority in my opinion than a nice UI would be working override functionality similar to what we have for TTLs, where one can pin the channel to a fixed frequency/phase setting regardless of what the experiment is doing. (This is motivated by diagnosing issues with both DDS hardware and the experiment attached to it over t

13:46 <acathla> whitequark, i'm trying to use your UART in migen, with another FSM to store the received bytes in a FIFO. Nothing works as expected, sometimes the UART FSM is in no known state and crash. My FSM do strange loops while it should not...

13:47 <whitequark> acathla: do you use MultiReg to synchronize inputs?

13:47 <acathla> Hum, no, what is that?

13:49 <whitequark> acathla: https://moodle.epfl.ch/pluginfile.php/466321/mod_resource/content/0/Presentation_ES_A2008/DFF_Synchronization.pdf

13:49 <whitequark> http://webee.technion.ac.il/~ran/papers/Metastability%20and%20Synchronizers.posted.pdf

13:50 <whitequark> tl;dr unless you synchronize asynchronous inputs to your clock, nothing will work as intended.

13:59 <acathla> Your UART (here: https://lab.whitequark.org/notes/2016-10-18/implementing-an-uart-in-verilog-and-migen/) does not use any of this and seems to be synchronized to the sys clock

14:01 <whitequark> acathla: oh

14:02 <whitequark> oh yeah, I was just starting out with FPGA design when I wrote that

14:02 <whitequark> it needs to be fixed or at least have a note attached

14:02 <whitequark> thanks

14:03 <whitequark> acathla: that said

14:03 <acathla> I am also starting with migen...

14:03 <whitequark> it does that because the point was to write the UART core itself and not to show how it integrates into a larger design

14:03 <whitequark> but I entirely agree that it can be confusing and misleading, so i'll fix that

14:04 <acathla> Which UART should I use then? rewrite my own? Try to understand those overcomplicated UART in misoc with wishbone interface I don't need (yet)?

14:06 <whitequark> no no

14:06 <whitequark> just add a synchronizer

14:06 <whitequark> it's like one line

14:06 <whitequark> so you have serial.rx, right?

14:06 <whitequark> do this:

14:07 <whitequark> rx = Signal()

14:07 <whitequark> self.specials += MultiReg(serial.rx, rx)

14:07 <whitequark> then give `rx` to the UART instead of `serial.rx`

14:07 <whitequark> `MultiReg` is in `migen.genlib.cdc`

14:10 <acathla> Ok, thank you.

14:14 <acathla> Hum, same behavior :(

14:18 <acathla> Oh, slight improvement !

14:21 <whitequark> show me the complete code

14:27 <acathla> it's not online... yet

14:27 <whitequark> gist.github.com or something

14:37 <acathla> https://framagit.org/acathla/migen-on-terasic-de2 top file is asserv.py but framing.py is the one trying to synchronize with UART.py

14:41 <whitequark> acathla: so it's a multiple clock domain design?

14:41 <acathla> Not really, unless you talk about the VGA part

14:41 <whitequark> then why are you using multireg between uart and framing?

14:43 <acathla> Because... i did it before adding it to the uart part only (between physical serial and UART part then)

14:43 <whitequark> hrm

14:44 <whitequark> i'm pretty sure it's not the uart, i've used that specific uart in many designs (with synchronization) and it works flawlessly

14:44 <whitequark> but i can't point at anything specific in yourdesign, it's pretty large and somewhat hard to navigate

14:44 <whitequark> what are the symptoms anyway

14:46 <acathla> In the STORE state, I just added a counter, and I monitor it with 7 segments. With the first character sent (after the start byte), it counts to 0x61

14:47 <whitequark> smething you could try is adding an explicit reset

14:48 <whitequark> not all FPGAs come out of configuration in a well defined state in all cases

14:48 <whitequark> e.g. nontrivial ice40 designs all but require a reset

14:48 <whitequark> self.submodules += CRG(clk50) or something

14:49 <whitequark> also, it passes timing, right?

14:51 <acathla> At 9600 bauds? I guess so. I think it's not right configured

14:51 <whitequark> no, 9600 is not relevant.

14:51 <acathla> Critical Warning (332012): Synopsys Design Constraints File file not found: 'asserv.sdc'.

14:51 <acathla> like that?

14:51 <whitequark> your design runs at 50 mhz clock, that is what it should pass timing at

14:52 <acathla> I don't know how to configure that with migen

14:52 <whitequark> platform.add_period_constraint(clk, period)

14:54 <acathla> I have a "default_clk_period = 20

14:54 <acathla> " in the platform I created. I add it to the git...

14:56 <whitequark> you create cd_sys explicitly

14:56 <whitequark> this means default_clk_period is ignored

14:56 <whitequark> so, you need to constrain cd_sys and cd_pix yourself

15:10 <acathla> I have two "Critical Warning (332148): Timing requirements not met

15:10 <acathla> " from Quartus

15:24 <whitequark> well, that explains why your design doesn't work

15:26 <acathla> Warnings are mostly because of the fullHD signal, it's a bit too high for the device and absolutely not optimized

15:40 <acathla> Ok, same problem without the clk_pix :(

15:41 <whitequark> passes timing now?

15:42 <whitequark> is the frequency in quartus logs correct? i.e. 50 MHz

15:43 <acathla> yes

15:44 <whitequark> can you try adding a reset

15:47 <acathla> with self.submodules += CRG(clk50) ?

15:52 <whitequark> yes

15:52 <whitequark> and removing explicit cd_sys instantiation

15:53 <acathla> Ok, did it, but it still complains about timing requirements not met

15:54 <whitequark> well, you need to fix timing

15:54 <whitequark> that's not really migen-specific and i don't really have time to help with that

15:55 <acathla> You already helped a lot, thank you

18:08 <GitHub-m-labs> [artiq] jordens commented on issue #1063: Since at it's core it is about exiting cleanly when requested, we can circumvent issues with signals and windows/unix differences.... https://github.com/m-labs/artiq/issues/1063#issuecomment-442159438

18:14 <GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1063: What about exiting from the client/dashboard instead? Then it's just using the existing sockets.... https://github.com/m-labs/artiq/issues/1063#issuecomment-442161497

18:21 <GitHub-m-labs> [artiq] jordens commented on issue #1063: That's a different feature. This one applies to other tools than master as well. And as long as you can't start the master from the dashboard I'm not that interested in being able to shut it down. If a tool is started from the command line it should be possible to end it cleanly right there as well.... https://github.com/m-labs/artiq/issues/1063#issuecomment-4421635

18:29 <GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1063: Threads, and also it's easy to inadvertently press Enter.... https://github.com/m-labs/artiq/issues/1063#issuecomment-442166316

18:49 <marmelada> hey

18:49 <sb0> marmelada: hi

18:49 <marmelada> is there a way to clean flash memory of sayma/kasli etc. with artiq_flash or openocd?

18:50 <sb0> openocd yes

18:50 <marmelada> I've had this issue happen to me few times, when after flash ARTIQ wouldn't boot, clearing flash from vivado helped

18:54 <sb0> you should be able to modify the artiq_flash openocd script, or patch artiq_flash, to erase the flash from there as wwell

19:31 <marmelada> sb0: should something like this work?

19:32 <marmelada> https://hastebin.com/gasolagema.rb

19:32 <marmelada> and call it with bankname "spi0" and then "spi1" for sayma

23:55 <GitHub-m-labs> [artiq] dhslichter commented on issue #1142: @klickverbot yes this would be nice, but definitely requires more mucking around with the guts on the FPGA in a serious way. @sbourdeauducq is there a reasonable way to maintain the DDS state in gateware or is this a nightmare? https://github.com/m-labs/artiq/issues/1142#issuecomment-442264085