<whitequark> daveshah: poke?
<whitequark> what timezone are you in, anyway
mumptai has quit [Quit: Verlassend]
tlwoerner has quit [Quit: Leaving]
tlwoerner has joined ##openfpga
Miyu has joined ##openfpga
Miyu has quit [Ping timeout: 250 seconds]
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
Adluc has quit [Quit: ZNC - http://znc.in]
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
dj_pi has joined ##openfpga
dj_pi has quit [Ping timeout: 258 seconds]
Adluc has joined ##openfpga
pie__ has joined ##openfpga
pie_ has quit [Ping timeout: 268 seconds]
unixb0y has quit [Ping timeout: 258 seconds]
unixb0y has joined ##openfpga
futarisIRCcloud has joined ##openfpga
eightdot has quit [Ping timeout: 250 seconds]
m4ssi has joined ##openfpga
m4ssi has quit [Remote host closed the connection]
m4ssi has joined ##openfpga
m4ssi has quit [Remote host closed the connection]
_whitelogger has joined ##openfpga
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
hl has joined ##openfpga
zng has quit [Quit: ZNC 1.8.x-nightly-20181211-72c5f57b - https://znc.in]
zng has joined ##openfpga
_whitelogger has joined ##openfpga
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
rohitksingh has joined ##openfpga
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
s_frit has quit [Read error: Connection reset by peer]
_whitelogger has joined ##openfpga
catplant is now known as tnalptac
tnalptac is now known as catplant
rohitksingh has quit [Ping timeout: 244 seconds]
<azonenberg> swetland: vacuum all of the sensor intakes
<azonenberg> dust and cobwebs are prone to causing false alarms
<azonenberg> if that doesn't work, and you continue to have false alarms, try to ID the one at fault
<azonenberg> and replace it
rohitksingh has joined ##openfpga
<tnt> azonenberg: wrt to your phy issues. If the signal transitions looks fine, maybe it's the timing ? Is the clock good / within spec ?
<zkms> can you capture a long trace with the misbehaving DUT and then capture a trace with the same equipment with a working ethernet device and look for a difference?
<azonenberg> zkms: i've done eyes of 100M mode on the bad board out to 10M points and not seen any obvious defects
<azonenberg> i'm trying to catch the actual link drop in progress now
<azonenberg> adding some state pins on the fpga so i can trigger the scope off them
<azonenberg> The osc is a DSC61xx MEMS oscillator, 25 PPM
<azonenberg> the PHY allows up to 50 ppm
jcreus has joined ##openfpga
<daveshah> whitequark: pong (I'm in UTC)
eightdot has joined ##openfpga
oter has quit [Ping timeout: 245 seconds]
rohitksingh has quit [Ping timeout: 240 seconds]
rohitksingh has joined ##openfpga
_whitelogger has joined ##openfpga
rohitksingh has quit [Ping timeout: 258 seconds]
Miyu has joined ##openfpga
octycs has joined ##openfpga
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
<whitequark> does this look understandable to you?
rohitksingh has joined ##openfpga
<daveshah> whitequark: yeah, looks good
Flea86 has quit [Quit: Goodbye and thanks for all the dirty sand ;-)]
<whitequark> mmkay
<whitequark> looking at df-map right now
<whitequark> it involves spanning trees
<whitequark> daveshah: i can't tell if there is a graph library in that pass trying to get out
<whitequark> or, if i should continue writing it in an ad-hoc way like that
<whitequark> i feel like the latter, so far
<daveshah> I tend to prefer ad hoc graph stuff too
<whitequark> okay
<whitequark> daveshah: can you read part V of https://sci-hub.tw/10.1109/92.285741 ?
<whitequark> i'm currently trying to understand it and i'd like to compare notes with someone
<daveshah> sure
<daveshah> while reading I found https://www.seas.upenn.edu/~andre/courses/CS294S97/notes/day19/day19.html, brief but quite a nice diagram
<whitequark> daveshah: ah interesting. half time images don't load for me though
<daveshah> yeah, they don't for me either (404)
octycs has quit [Ping timeout: 260 seconds]
cr1901_modern1 has joined ##openfpga
cr1901_modern has quit [Ping timeout: 258 seconds]
octycs has joined ##openfpga
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined ##openfpga
__rob2 has joined ##openfpga
Laksen has joined ##openfpga
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
<whitequark> daveshah: hm, i'm not sure i grasp how df-map works
<whitequark> do you?
emeb has joined ##openfpga
<daveshah> whitequark: not enough to really implement it
<daveshah> also found http://courses.cms.caltech.edu/cs137/2005/fall/slides/day3_6up.pdf but without notes its quite hard to understand. but it does have an example of df-map
<daveshah> inside RASP; sis-1.2/sis/ucla_fpga/flowmap/dfmap.c
<daveshah> not sure how much that helps though
rohitksingh has quit [Ping timeout: 244 seconds]
rohitksingh has joined ##openfpga
<whitequark> daveshah: hmmm
<whitequark> can you explain what you do understand to me?
<whitequark> maybe we're missing different parts
<daveshah> I understand the broad concept - split to MFFCs, then try and build up an optimal mapping using DP for each MFFC
<daveshah> starting from the PIs
<whitequark> do you split LUTs (after initial packing and depth relaxation) into MFFCs, or do you split nodes?
<daveshah> It seems to be nodes
<whitequark> hmm
<whitequark> but how does this relate to depth relaxation, then?
<whitequark> if it's nodes anyway
<whitequark> the node graph is intact
<daveshah> hmm
<daveshah> it feels like this might be done on the nodes that were unmapped during depth relaxation
<daveshah> if that makes any sense at all
<whitequark> but nodes aren't unmapped during depth relaxation!
<whitequark> they're split
<whitequark> so you still have LUTs after depth relaxation
<whitequark> this is important because depth relaxation happens up to a given depth bound
<whitequark> and continues until the slack on each LUT is zero
<daveshah> I'm trying to understand the algorithm in III.D
<daveshah> whitequark: thinking some more, I don't think depth relaxation leaves the node graph intact as it might merge duplicated nodes?
<whitequark> daveshah: hmm
<whitequark> daveshah: that depends on whether you explicitly duplicate nodes, i guess
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
rohitksingh has quit [Remote host closed the connection]
rohitksingh has joined ##openfpga
octycs has quit [Ping timeout: 268 seconds]
octycs has joined ##openfpga
X-Scale has quit [Ping timeout: 245 seconds]
X-Scale` has joined ##openfpga
X-Scale` is now known as X-Scale
Laksen has quit [Remote host closed the connection]
octycs has quit [Ping timeout: 268 seconds]
<tnt> come on ... wtf ... why does v_cnt[1] have a different CE than all the other bits of that vector.
octycs has joined ##openfpga
pie__ has quit [Ping timeout: 258 seconds]
tmeissner has joined ##openfpga
mwk has quit [Read error: Connection reset by peer]
mwk has joined ##openfpga
<whitequark> daveshah: oooh i think i see it
<whitequark> lemma 3
<daveshah> Hmm
<whitequark> daveshah: so I think it goes something like this
<whitequark> it works on gate level, but in granularity of FFCs that are already mapped to LUTs, maybe?
<daveshah> whitequark: Lemma 3 reads like a property of the solution though?
<whitequark> mhm
<whitequark> right
<whitequark> red herring maybe
<whitequark> daveshah: ooooh
<whitequark> i think ido see it now
<whitequark> theorem 2
<whitequark> every K-feasible MFFC is collapsed into its root before DF-mapping
<whitequark> orr in part E
<whitequark> "Since every new LUT generated by DF-Map covers at least one node of initial network"...
pie__ has joined ##openfpga
<whitequark> daveshah: wtf
<whitequark> that code is absolutely incomprehensible
<daveshah> It's good old K&R too
<whitequark> daveshah: ok, so i think i sort of understand df-map conceptually now, on a low level
<whitequark> i still don't fully see how it fits with the results of flowmap
<daveshah> Yeah, I feel about the same
<daveshah> Algorithm in IIID suggests it being run in a loop with depth relaxation
<whitequark> yes
<whitequark> on page 146 it says that depth relaxation prepares an advantageous initial network for DF-Map
<whitequark> daveshah: so looking again
<whitequark> "Fig 5(c) consists of a single MFFC which is not 5-feasible"
<whitequark> and it says that it consists of 3 nodes
<whitequark> these 3 nodes are LUTs
<whitequark> moreover, there is no duplication going on at all
<whitequark> both 5(c) top and 5(c) bottom have the exact same gate network
<whitequark> therefore, it seems quite clear that DF-Map works on the network of LUTs and not on the network of gates
<whitequark> "MFFCv consists of 3 nodes" is unambiguous
<daveshah> OK, that makes sense
rohitksingh has quit [Ping timeout: 268 seconds]
<daveshah> My rough feeling then is that FlowMap first to LUTs, then depth relaxation without any repacking, then DFMap on LUTs
<daveshah> The latter two parts in the loop
<whitequark> yes
<whitequark> that's definitely what it does
<whitequark> mmmkay
<whitequark> i think i can do this
<daveshah> Awesome
<whitequark> daveshah: btw, does abc have a depth/area tradeoff functionality?
<daveshah> It has some settings to this effect
<daveshah> Probably not as fine grained as here, more like optimise for delay or optimise for area
<whitequark> ahh
<whitequark> but that's useless
<whitequark> you never want to just optimize for area
<daveshah> I think you can give it required times for POs too
<whitequark> aha
<daveshah> And then it will optimise to meet those
<daveshah> This is probably only useful with greyboxes, otherwise stuff like carry chains end up as POs too
octycs has quit [Remote host closed the connection]
tmeissner has quit [Quit: Textual IRC Client: www.textualapp.com]
<whitequark> hmmm
<whitequark> i have a bug where (on logic.v) a node has nonzero slack but an output on its critical path has zero slack
<whitequark> :S
<whitequark> the problem is that it happens after like 14 relaxation steps
<whitequark> daveshah: ahahahahaha
<whitequark> so i had this elaborate caching set up
<whitequark> to avoid recalculating potoentials
<whitequark> and a worklist parameter
<whitequark> ... that i ignored and recomputed all potentials for all nodes each single iteration
<whitequark> "why is it slow" because you are a dumbass whitequark
<goran-mahovlic> we have new website for ulx3s ;) http://radiona.org/ulx3s/
<whitequark> daveshah: hmmm
<whitequark> so I have a situation where a node with slack 1 feeds a node with slack 0
<whitequark> this feels like a bug
<whitequark> daveshah: but, i can't tell where
<whitequark> daveshah: ahaha holy shit
<whitequark> so iwrote bugpoint for yosys
<whitequark> it is EXTREMELY effective
<whitequark> it can rapidly minimize designs with hundreds of cells to designs with single cells
<whitequark> daveshah: you obviously can use it with nextpnr as well