12:30 <maikmerten> awesome, seems nextpnr now also takes posedge/negedge timing into account

12:30 <maikmerten> Info: Max frequency for clock 'uart_inst.CLK_I_$glb_clk': 26.25 MHz

12:30 <daveshah> yes, it does now

12:30 <maikmerten> so my fmax is *not* 50+ Mhz

12:31 <maikmerten> and with 25.125 MHz, I'm awfully close

12:31 <daveshah> currently it doesn't take into account duty cycle either

12:31 <daveshah> if your clock's duty cycle isn't 50% that eats into your margin further

12:31 <daveshah> that isn't a problem for same edges paths

12:31 <maikmerten> it *should* be 50%

12:31 <maikmerten> but who knows ;-)

12:32 <maikmerten> but at least that would perhaps explain the "some seeds work, some not" problem I encountered a week ago

12:36 <maikmerten> (of all the components, I wouldn't have guess that the UART may be the limiting thing)

12:36 <maikmerten> *guessed

12:37 <daveshah> is that actually on the critical path?

12:37 <daveshah> the name of the clock doesn't tell you what's limiting Fmax

12:38 <daveshah> it's just to do with how Yosys resolves names

12:41 <maikmerten> seems it's not actually the UART itself - if I comment that out another peripheral just takes its place

12:42 <maikmerten> I guess its just a bad idea to have the CPU control logic on the negative edge

12:42 <daveshah> nextpnr should print a critical path report telling you what is limiting Fmax

12:42 <daveshah> however, abc tends to mangle net names badly

12:44 <maikmerten> https://paste.debian.net/1052102/

12:44 <tpb> Title: debian Pastezone (at paste.debian.net)

12:45 <maikmerten> Info: Max delay <async> -> posedge uart_inst.CLK_I_$glb_clk: 6.30 ns

12:45 <daveshah> that one isn't so important - that's the delay to/from IO to a register

12:45 <daveshah> the important one is the long posedge -> negedge report

12:45 <daveshah> *negedge -> posedge

12:46 <daveshah> looks like it starts around cpu_inst.instr[3] and ends around cpu_inst.alu_inst.sub[32]

12:46 <daveshah> with a big carry chain in between

12:46 <maikmerten> ooh, right

12:47 <maikmerten> 18.4 ns accumulated delay, if I read things right

12:47 <daveshah> yes

12:49 <maikmerten> I must confess I find that long one hard to read, because that all seems to be autogenerated fluff ( ;-) ) that I can't directly map to design names

12:49 <maikmerten> ah, no, I see cpu_inst.instr[3]

12:50 <maikmerten> that's the CPU's instruction register

12:51 <maikmerten> and then later cpu_inst.alu_inst.sub[32]

12:51 <maikmerten> which is the subtraction result in the ALU

12:51 <maikmerten> okay, that explain a lot

12:53 <maikmerten> the instruction is fetched from the data bus and stored in the instruction register. From there, my asynchronous decoder will assemble the immediate value. That goes through some muxer to the second ALU input, and goes into asynchronous subtraction logic

12:53 <maikmerten> so the asynchronous logic path is long. Really long.

12:58 <maikmerten> actually s/asynchronous/combinatorial