01:08 <_whitenotifier-e> [YoWASP/yosys] whitequark pushed 1 commit to develop [+0/-0/±1] https://github.com/YoWASP/yosys/compare/358a9db22d45...e554c466c8a9

01:08 <_whitenotifier-e> [YoWASP/yosys] whitequark e554c46 - Update dependencies.

11:55 <dicethrow> Hello all, I have a question about why I have such low allowable clock frequencies. I'm trying to make a ~143 MHz clock for a SDRAM driver for my ULX3S board.  What sort of thing could cause or fix this?

11:55 <dicethrow> For context, this error is happening within this project: https://github.com/dicethrow/amaram

11:55 <dicethrow> See line 215 of tests/ulx3s_gui_test/fpga_gateware/test_sdram_n_fifo_interface_IS42S16160G/test6_modified_ila_with_sdram_fifo.py

11:55 <dicethrow> thanks for the help!

11:55 <dicethrow> _________________________________

11:55 <dicethrow> The error:

11:55 <dicethrow> ERROR: Max frequency for clock '$glbnet$dut.U$$1.ila.fifo.sdram_clk': 56.87 MHz (FAIL at 141.68 MHz)

11:55 <dicethrow> ________________________________

11:55 <dicethrow> The code:

11:55 <dicethrow> # Clock generation

11:56 <dicethrow> # PLL - 143MHz for sdram

11:56 <dicethrow> sdram_freq = int(143e6)

11:56 <dicethrow> self.m.domains.sdram = cd_sdram = ClockDomain("sdram")

11:56 <dicethrow> # self.m.domains.sdram_clk = cd_sdram_clk = ClockDomain("sdram_clk")

11:56 <dicethrow> if platform != None:

11:56 <dicethrow>     self.m.submodules.ecp5pll = pll = ECP5PLL()

11:56 <dicethrow>     pll.register_clkin(platform.request(platform.default_clk),  platform.default_clk_frequency)

11:56 <dicethrow>     pll.create_clkout(cd_sdram, sdram_freq)

12:06 <dicethrow> (sorry for the repost, just realised I posted on the wrong side of midnight earlier)

12:06 <dicethrow> Hello all, I have a question about why I have such low allowable clock frequencies. I'm trying to make a ~143 MHz clock for a SDRAM driver for my ULX3S board.  What sort of thing could cause or fix this?

12:06 <dicethrow> For context, this error is happening within this project: https://github.com/dicethrow/amaram

12:06 <dicethrow> See line 215 of tests/ulx3s_gui_test/fpga_gateware/test_sdram_n_fifo_interface_IS42S16160G/test6_modified_ila_with_sdram_fifo.py

12:06 <dicethrow> thanks for the help!

12:06 <dicethrow> _________________________________

12:06 <dicethrow> The error:

12:06 <dicethrow> ERROR: Max frequency for clock '$glbnet$dut.U$$1.ila.fifo.sdram_clk': 56.87 MHz (FAIL at 141.68 MHz)

12:06 <dicethrow> ________________________________

12:06 <dicethrow> The code:

12:06 <dicethrow> # Clock generation

12:06 <dicethrow> # PLL - 143MHz for sdram

12:06 <dicethrow> sdram_freq = int(143e6)

12:06 <dicethrow> self.m.domains.sdram = cd_sdram = ClockDomain("sdram")

12:06 <dicethrow> # self.m.domains.sdram_clk = cd_sdram_clk = ClockDomain("sdram_clk")

12:06 <dicethrow> if platform != None:

12:06 <dicethrow>     self.m.submodules.ecp5pll = pll = ECP5PLL()

12:06 <dicethrow>     pll.register_clkin(platform.request(platform.default_clk),  platform.default_clk_frequency)

12:08 <dicethrow> Whoops, sorry about the clutter

12:11 <adamgreig[m]> dicethrow: is this a RAM controller you expect to be faster and something weird/unexpected is making it slow, or a novel design and it's not as fast as you'd like and you want to know why?

12:14 <dicethrow> I think that answers the question - so the reason the clock has this limit is because of the fanout etc to the rest of the design that the clock is connected to?

12:14 <dicethrow> In that case, It sounds like I need to have a think about how to make it faster, any general tips on how to do that?

12:15 <adamgreig[m]> the "max frequency for clock" report means "this is the fastest this clock domain can run, given the length of the longest logic chain between two registers", so yea, it's about the rest of the design rather than some intrinsic limit on the PLL or anything like that

12:16 <dicethrow> That makes a lot of sense, thanks

12:16 <adamgreig[m]> the nextpnr output will show you the longest (critical) path, which might give you some clues as to what's causing it

12:16 <adamgreig[m]> in general the goal is to limit how much logic and routing is in a row is between two registers, because that's what limits the frequency

12:17 <adamgreig[m]> sometimes it's just something easy you can add and sometimes it's really hard and you have to rearchitecture the whole idea 😭

12:17 <adamgreig[m]> I don't know of any particular guides on this and the nextpnr critical path might or might not be super helpful in finding the main problems - there's a histogram so you can get an idea of it it's just one or two paths that need fixing or like the whole design is slow

12:18 <adamgreig[m]> lots of fanout might give you high routing delays and perhaps adding some registers will help, complicated logic functions will give higher logic delays and maybe you can pipeline them...

12:19 <dicethrow> Ok sweet, that definitely gives me a direction to work in, thanks!

12:20 <adamgreig[m]> good luck!