04:45 <azonenberg> qu1j0t3: just because it can be done doesnt mean its a good fit to the paradigm

08:53 <tnt> mmm, 1.8ns for net delay between ajacent tiles (ice40) seems high. I could swear I've seen it at 1.2ns before.

08:53 <daveshah> It depends what routing resources are used

08:54 <daveshah> 1.8ns is plausible if it is using longer distance style routing or bouncing around a bit

08:55 <tnt> No according to the gui at least it seems to be using the direct connection between the 6 neighbors.

08:56 <daveshah> Hmm

08:56 <tnt> I'll try to make a small test case rather than the full design to see what's going on.

08:57 <daveshah> Running with --verbose should give you a timing report showing routing resources

08:57 <tnt> Oh, interesting, didn't know that.

08:58 <daveshah> LocalMux, which I think is what neighbours go through too, looks to be 1.2ns max

08:58 <daveshah> according to icebox

08:59 <tnt> https://pastebin.com/pnsFQDGD

09:01 <daveshah> so the 1.099 must be a LocalMux and the 0.662 an InMux

09:01 <daveshah> from https://github.com/cliffordwolf/icestorm/blob/master/icefuzz/timings_up5k.txt

09:01 <daveshah> (oops, I typed 1.2 and meant 1.1 for LocalMux before)

09:01 <daveshah> I'm not sure if it can be lower than that actually

09:04 <daveshah> Looking at icetime it seems like it would use the same combination of delays for that routing too

09:06 <tnt> mmm, ok, I'll recheck. Would the path from a FF to DOUT_x be the same ? I would think so but ...

09:07 <daveshah> Numerically yes (it would use an IoInMux rather than an InMux but it looks like those have the same delay for up5k at least)

09:08 <tnt> ok.

09:08 <tnt> All ice40 FFs are pos edge right ? they're not configurable that I could find. So I assume any negedge ff would end up using a LUT to invert the clock ?

09:09 <daveshah> No they are configurable

09:09 <daveshah> the DFFN variants are negedge

09:10 <daveshah> it's the NegClk bits in logic and IO tiles

09:10 <tnt> Oh I missed that. Ah and it's for all 8 LCs (kind of expected that)

09:11 <daveshah> Yep

09:35 <tnt> Mmm, looks like the higher fmax I'm seeing on the output path (FF -> DOUT) is because the DOUT setup time is (suspiciously) low.

09:36 <tnt> although I guess because there is no LUT in front it's not all that suspicious.

10:21 <tnt> No matter what I do, I don't see how I could pass back from the negedge domain into the posedge one. timing from FF to FF are worse than from the DIN1 to FF.

12:38 <lambda> hehe, fun with induction - turns out there's a distinct difference between PSL `s |=> t` and `s |=> t!`. I was using the former to assume my 'run' input is high all the way through a transation (`assume always run |=> run or valid`). The assertion `always not valid -> run` was inexplicably failing on the last cycle after 'run' just went low during a transaction, something the assumption should

12:38 <lambda> prevent. yep, without the force (!), not matching at the end of the trace is totally allowed.

13:06 <tnt> Is the router somehow biased against using the sp12_h ? Seems like when spannning 3 * sp4_h, using a sp_12 would be faster.

13:07 <daveshah> There's nothing particular that would encourage it to use sp4s

13:07 <daveshah> It's probably just some consequence of delay estimates

13:52 <tnt> mm, yeah, it might be right to use sp4. The sp12 are faster to cross long distances but getting on/off them is tricky, they're not super well connected compared to sp4s.

14:00 <tnt> So, as far as I can tell delays are 'bound' to PIPs and not wires. So doesn't it make any difference at which "point" you enter a span wire and at which point you exit ?

14:01 <daveshah> This is a bit of an approximation, it does matter slightly but I think claire never quite figured out the pattern icecube uses (this is equivalent to icetime -m)

14:08 <tnt> Oh, so it always use Span{4,12}Mux_{h,v}{4,12} and and never the 0..3 and 0...11 values.

14:09 <tnt> (although I'm not sure that the 0 values span issue is supposed to be really ?!)

14:10 <daveshah> Although it appears that the numbers correspond to length, icecube sometimes uses a higher number for higher fanouts

14:11 <daveshah> I think you can route on and off a span in the same tile

14:13 <tnt> Ok, I guess that can make sense.

14:13 <tnt> The up5k and u4k timings have two IOPATH lines for Span12Mux_v12 that looks like a bug in the icestorm db.

14:15 <daveshah> Based on how icefuzz dedups timings, that means that icecube must use different delay values in different places

14:15 <daveshah> Good catch, that's quite interesting

14:15 <daveshah> Seems like they must have changed the timing model from hx/lp

17:19 <grazfather> hey guys, I have a problem with verilator: I am trying to build the headers and source files, but it seems to quietly ignore my package with an enum in it

17:21 <grazfather> jumped the gun: https://www.veripool.org/boards/2/topics/2064-Verilator-Using-enumerated-values- I needed `/*verilator public*/` for some reason