pepijndevos changed the topic of #apicula to: Project Apicula: bitstream documentation and tooling for Gowin FPGAs https://github.com/YosysHQ/apicula -- logs https://freenode.irclog.whitequark.org/apicula
mmicko has quit [Quit: leaving]
mmicko has joined #apicula
FabM has joined #apicula
<pepijndevos> huh... just realized that in nextpnr generic getWireDelay just returns 0 and the pip delay is where the action happens.
<pepijndevos> In my current python target I basically set the pip delay to that of the destination wire... which is what the vendor provides
<pepijndevos> Would it be better to set the pip delay to 0 and use the wire delay?
<daveshah> In general, I've found pip delays more useful than wire delays when developing timing models
<pepijndevos> for any particular reason?
<pepijndevos> these are the delays Gowin provides https://github.com/YosysHQ/apicula/blob/master/apycula/tm_h4x.py#L247-L264
<daveshah> it may well be wire delays make more sense for gowin
<pepijndevos> Okay
* pepijndevos noms a sandwich
<pepijndevos> I'm just not really sure I understand the difference between the delay of a pip and the delay of the wire it drives.
<pepijndevos> welp I added timing info and routing is all wonky again, somewhere between "can't find a route" and "try every possible solution"
<pepijndevos> seems to be basically stuck in a loop now...
<pepijndevos> huhhhh https://bpa.st/ABXQ
<pepijndevos> here is a bit with the delay scaling cranked way up https://bpa.st/F7XA
<pepijndevos> something is seriously messed up...
<daveshah> the +4294966 means something is very odd with the delays
<daveshah> as does the final route delay: 0.00
<pepijndevos> what does the large number represent?
<daveshah> it's to do with the change in estimate
<pepijndevos> So basically the final route has zero delay, which suggests some delays are missing, but then there is this huge number, so... huh
<daveshah> afaik that huge number is to do with delay estimates
<pepijndevos> So basically the delay estimate is veeeery different from the actual delay?
<daveshah> I don't fully know what is going, but stuff is definitely very messed up
<pepijndevos> weird, weird, weird... okay, I will revert to hardcoded delays and see where it breaks.
<daveshah> it might also be worth checking that the epsilon and ripup penalty values are vaguely reasonable wrt the actual delays
<pepijndevos> I also went from float ns to in ps, so maybe that messed it up
<pepijndevos> Okay it's definitely the changes to DelayInfo rather than the actual timing stuff.
<pepijndevos> Is there like... --double-debug-extra-for-real...
<pepijndevos> It just does this now...
<pepijndevos> Routing arc 0 on net ctr[25]_DFF_Q_D_LUT2_F_I0[0] (1 arcs total):
<pepijndevos> source ... R3C11_F7
<pepijndevos> total number of visited nodes: 2
<pepijndevos> sink ..... R2C11_A3
<pepijndevos> no route found for this arc
<pepijndevos> Warning: Failed to find a route for arc 0 of net ctr[25]_DFF_Q_D_LUT2_F_I0[0].
<pepijndevos> ERROR: Routing design failed.
<daveshah> yes --double-debug-extra-for-real is the #ifdef 0 blocks
<daveshah> * #if 0 blocks
<pepijndevos> welp I made delayScale 100000 and now it runs... maybe I have my math backwards and am dealing with like gigaseconds now or something
<pepijndevos> evidently too derpy to think about that now... time for something else
FabM has quit [Ping timeout: 240 seconds]