00:23 <_whitenotifier-1> [YoWASP/nextpnr] whitequark pushed 1 commit to develop [+0/-0/±1] https://git.io/JsCzE

00:23 <_whitenotifier-1> [YoWASP/nextpnr] whitequark 6582e7d - Update dependencies.

01:06 <_whitenotifier-1> [YoWASP/yosys] whitequark pushed 1 commit to develop [+0/-0/±1] https://git.io/JsCwl

01:06 <_whitenotifier-1> [YoWASP/yosys] whitequark 42b9d0f - Update dependencies.

09:14 <d1b2> <mubes> That doesn't seem to be an option since the protocol requires immediate response to what you've received...for example, if you receive a WAIT response to your read request then you have to abort that read request and re-submit it immediately...I don't see how to do that with synced inputs. In fairness the signals are in response to my synchronous clock output, and they've gone through the IO pin processing, so they shouldn't be too bad (and this

09:14 <d1b2> does work up to 25Mhz!).

09:16 <d1b2> <mubes> I did try using the DDR cells (xdr=2) which, if I wire o1 and o2 together and use the i1 output, I would expect to do what I want, but the clocking is subtly different to the xdr=1 case in ways I don't understand and didn't expect....I end up with a cycle delay.

13:57 <agg> mubes: using xdr=2 instead of feeding an inverted clock seems like a better option if you can make it work, i didn't think there was an extra latency cycle in ddr instead of sdr (unlike ice40 where one is added to fix timings)

13:58 <agg> another option is to run the ecp5 logic at 100MHz and keep all the IO as SDR, which might also give you more time to do processing and get around extra register latency

13:59 <agg> (and might make it easier to support lower clock rates by just dividing down the output clock from 100MHz without having to change pll settings on the fly or whatever...)

14:01 <d1b2> <mubes> We do divide down a 100MHz clock to be able to support any 100/(2(n+1) MHz clock speed....the 100MHz is a limitation of the logic thats in there, in reality it can/ will be more like 160MHz but it's a pain when a build doesn't complete, so I've got it set low right now

14:03 <agg> in that case, why not run the IO at SDR and your system clock speed?

14:03 <agg> (btw you can also just tell nextpnr to ignore timing failures if you want it to carry on with generating a bitstream etc)

14:03 <agg> assuming you don't want the swd/jtag to go >50MHz or so (which at least for the low end stuff i work with tends to be the practical limit)

14:04 <d1b2> <mubes> In respect of (i) It's a good idea and (ii) I don't want to chase phantom problems

14:05 <d1b2> <mubes> I'm sure I've tried the clock before, no recollection what the problem was

14:05 <agg> fair enough yea

14:05 <d1b2> <mubes> I'll go give that a try though...

14:05 <agg> inverting the clock going to the output seems like asking for more trouble since it would need to come off a clock net and go through logic to get inverted

14:06 <agg> (unless the iologic has an inverted clock config bit? not sure)

14:06 <agg> uh, going to the input register*

21:22 <d1b2> <mubes> lkyl , agg, whitequark Thanks for the sounding board. We have 50MHz. Not perfect yet, but a big step forward from where I was;

21:22 <d1b2> <mubes> https://cdn.discordapp.com/attachments/726185180599156796/843599233458372648/unknown.png

21:34 <agg> Yay! How did you do it in the end?

21:34 <agg> And how are you sampling for that screenshot? Looks a bit low bandwidth maybe

21:38 <d1b2> <mubes> I used an unregistered clock output which is at 50MHz and clocked the swdio at 100MHz directly. I'll probably look at registering the clock output against the 100MHz just to square up any jitter as a next step, but I need to get the transmit side working first...this is just reception (but the received value is correct).

21:39 <kbeckmann> i have a question regarding Reset and multiple clock domains. it seems that signals belonging to clock domains other than 'sync' are not properly being reset. i tied the same signal to the ResetSignal() of each clock domain. i am probably just doing something wrong but i don't know what, so any help is appreciated. i have a test case here:

21:39 <kbeckmann> https://gist.github.com/kbeckmann/cb627dd75cd78c4d15ce30f0f9efa704

21:40 <d1b2> <mubes> That sample has 350MHz alleged b/w but it's 1GS/s and a 10MS frame, zoomed a long way in. Now we're one stage firther on I can trigger more accurately for better resolution, but it's not been the core problem until now.

22:29 <kbeckmann> oh. if i create the second clock domain with async_reset=True, i am able to reset it properly.

22:37 <kbeckmann> now i also understand why my test case didn't reset the second counter - since the second clock was generated from the sync domain, there was never a clock pulse while the reset signal for the second domain was asserted. learned something today!

22:37 <d1b2> <DX-MON> IIRC you want to use FFSynchroniser to take your ResetSignal() which is synchronous to the sync domain, and resync it to your target domain, and have the re-synchronised reset signal feed the new domain

22:38 <whitequark[m]> there's ResetSynchronizer as well

22:38 <d1b2> <DX-MON> *FFSynchronizer as I think it's actually spelt with a z

22:38 <d1b2> <DX-MON> ah, neat

22:38 <d1b2> <DX-MON> multiple clock domain designs are Tricky™

22:46 <kbeckmann> thanks! will check it out.

22:54 <kbeckmann> in my case i would just need to do `m.submodules += ResetSynchronizer(reset, domain="second")` and remove my manual assignment of `ResetSignal(domain="second").eq(reset)`. seems to work, and introduces some expected latency. thanks again.

23:24 <DX-MON> that looks about right, yes