kristianpaul has quit [Read error: Connection reset by peer]
_whitelogger has joined #yosys
az0re has joined #yosys
kristianpaul has quit [Ping timeout: 240 seconds]
kristianpaul has joined #yosys
cr1901_modern has quit [Ping timeout: 240 seconds]
guytout37 has quit [Remote host closed the connection]
emeb_mac has quit [Ping timeout: 240 seconds]
emeb_mac has joined #yosys
Degi has quit [Ping timeout: 256 seconds]
Degi has joined #yosys
citypw has quit [Quit: Leaving]
sth0R has joined #yosys
sth0R has quit [Client Quit]
citypw has joined #yosys
emeb_mac has quit [Quit: Leaving.]
Asu has joined #yosys
cr1901_modern has joined #yosys
citypw has quit [Ping timeout: 240 seconds]
Asuu has joined #yosys
Asu has quit [Ping timeout: 240 seconds]
Asu has joined #yosys
Asuu has quit [Ping timeout: 240 seconds]
citypw has joined #yosys
X-Scale` has joined #yosys
X-Scale has quit [Ping timeout: 240 seconds]
X-Scale` is now known as X-Scale
kristianpaul has quit [Ping timeout: 240 seconds]
kristianpaul has joined #yosys
bzztploink has quit [Read error: Connection reset by peer]
sorear has quit [Ping timeout: 244 seconds]
thoughtpolice has quit [Ping timeout: 244 seconds]
tannewt has quit [Ping timeout: 244 seconds]
ovf has quit [Ping timeout: 244 seconds]
pointfree has quit [Ping timeout: 244 seconds]
rjeli has quit [Ping timeout: 244 seconds]
ric96 has quit [Ping timeout: 244 seconds]
lukego has quit [Write error: Connection reset by peer]
svenn has quit [Read error: Connection reset by peer]
tannewt has joined #yosys
sorear has joined #yosys
thoughtpolice has joined #yosys
lukego has joined #yosys
svenn has joined #yosys
bzztploink has joined #yosys
ric96 has joined #yosys
ovf has joined #yosys
rjeli has joined #yosys
Xark has quit [Ping timeout: 258 seconds]
Xark has joined #yosys
xtro has quit [Ping timeout: 256 seconds]
pointfree has joined #yosys
nengel has quit [Ping timeout: 264 seconds]
nengel has joined #yosys
tmiw has quit [Ping timeout: 272 seconds]
tmiw has joined #yosys
pointfree has quit [Ping timeout: 244 seconds]
FL4SHK has quit [Ping timeout: 240 seconds]
pointfree has joined #yosys
FL4SHK has joined #yosys
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
pointfree has quit [Ping timeout: 240 seconds]
pointfree has joined #yosys
cr1901_modern has quit [Quit: Leaving.]
cr1901_modern has joined #yosys
klotz has joined #yosys
cr1901_modern has quit [Quit: Leaving.]
klotz has quit [Quit: klotz]
cr1901_modern has joined #yosys
Asu has quit [Ping timeout: 240 seconds]
rjeli has quit [Ping timeout: 265 seconds]
rjeli has joined #yosys
thardin has quit [Ping timeout: 256 seconds]
Asu has joined #yosys
Asu has quit [Quit: Konversation terminated!]
Asu has joined #yosys
fevv8[m] has joined #yosys
emeb has joined #yosys
gmc has joined #yosys
cr1901_modern has quit [Ping timeout: 240 seconds]
cr1901_modern has joined #yosys
kristianpaul has quit [Read error: Connection reset by peer]
kristianpaul has joined #yosys
Asu has quit [Ping timeout: 240 seconds]
Asu has joined #yosys
citypw has quit [Ping timeout: 240 seconds]
emeb has quit [Ping timeout: 240 seconds]
emeb has joined #yosys
xtro has joined #yosys
emeb_mac has joined #yosys
strobokopp has joined #yosys
cr1901_modern has quit [Quit: Leaving.]
cr1901_modern has joined #yosys
DaKnig has quit [Ping timeout: 264 seconds]
DaKnig has joined #yosys
oldtopman has joined #yosys
DaKnig has quit [Ping timeout: 264 seconds]
DaKnig has joined #yosys
cr1901_modern has quit [Ping timeout: 256 seconds]
cr1901_modern has joined #yosys
N2TOH has joined #yosys
N2TOH_ has quit [Read error: Connection reset by peer]
Asu has quit [Quit: Konversation terminated!]
N2TOH_ has joined #yosys
N2TOH has quit [Ping timeout: 240 seconds]
ross_s has joined #yosys
<ross_s>
Was debugging a slow path the other day, and noticed that the output json from yosys tracks (at least some amount) of source information for each net - what do people think of using this info to give some pointers in the nextpnr critical path report output?
<ross_s>
Is this something that people would find useful? Or is there a better way of identifying which part of a potentially complex design is bogging down the clock?
<DaKnig>
that would be amazing if this works. what if the path was heavily modified by the optimizers though?
<DaKnig>
if there would be a version that's a bit less verbose that would help too...
<ross_s>
I'm not super knowledgable about the internal workings of yosys, but my guess is that the nets with no 'src' attribute are ones that have been mangled by the optimizer? Depending on the design I see more or less of those
<whitequark>
ross_s: i think this is a valuable contribution, personally
<whitequark>
what DaKnig says is correct to some degree, optimizers can and will mangle your code
<ross_s>
yeah, the verbosity is something I might tweak... having it be stateful and not print source lines that have already been printed is probably an easy optimization
<whitequark>
... some optimizers! for example, my flowmap LUT mapper preserves all debug information
<whitequark>
I second the verbosity feedback
<whitequark>
that'd be the first thing I'd suggest
<DaKnig>
I think having different verbosity levels would help too
<DaKnig>
sometimes you really care about all the different layers; sometimes just having a pointing finger is enough.
<ross_s>
yeah, I'm just wary of adding too many tunables... perhaps by default it just prints the file stack (or only the deepest file in the stack, though this has a risk of only printing stuff from e.g. arith_map), and there is another option for source printing?
<whitequark>
if i remember correctly how yosys manages src attributes, that's not a stack
<whitequark>
it's a set
<whitequark>
so you definitely should print all files, logically speaking
<ross_s>
ah interesting, I guess it's just chance that it seems to always be in order
<DaKnig>
look, other things that output large quantities of info have this --verbose option.
<whitequark>
yeah i think it's implemented as a vector
<whitequark>
tbh, i think it probably shouldn't print the arith_map etc stuff by default at all
<whitequark>
but this will need fixes on yosys side
<ross_s>
hmm, yeah there's no flags in the json currently for 'real source' vs 'toolchain source'
<whitequark>
something like -fdebug-prefix-map
<whitequark>
it's not clear to me what's the best path forward
<whitequark>
i might raise that on the next yosys meeting, assuming i don't forget
<whitequark>
seems we can work something out
<whitequark>
i'm super excited about all and any improvements in usability/debuggability
<whitequark>
this one has been on my todo list for a while. i mostly abandoned it because abc used to shred all debug info anyway
<whitequark>
but i think abc got better (&dress or something?) so we can do it now \o/
<whitequark>
ross_s: actually, there's a related issue i was going to ask about
<whitequark>
you have relative paths there. how's that works?
<ross_s>
the current implementation is pretty dumb - it just attempts to open whatever path is in the json, and if it fails just doesn't print the source
<ross_s>
so in this case, it's relative, but since the files are in that folder, it's fine
<whitequark>
right we gotta do something about that, too
<ross_s>
well, I thought about that but it's tricky where to draw the line - the verilog sources aren't really necessary for nextpnr, you could just give it a json file in a vacuum and even if it had absolute paths to files that don't exist it can't print them
<ross_s>
unless you mean embedding more data in the yosys json
<whitequark>
yeah, i'm thinking yosys side
<whitequark>
it's tricky, because i can see both absolute and relative paths being valuable
<whitequark>
for example, suppose you build through ssh on a different machine (nmigen supports that as a first-class build strategy, for example)
<whitequark>
then you *really* want relative paths
<whitequark>
i think what you're doing on nextpnr side wrt relative paths is actually just fine for the moment
<whitequark>
whatever fix we end up applying will be on the yosys side
<ross_s>
yeah, that will definitely be more robust. If you pass absolute paths to yosys that's what shows up in the json too, so if the build system for whatever project is set up like that it should work even if you're running nextpnr from some other working directory
<ross_s>
It sounds like there's some discussion to be had with more yosys people - shall I hold off on changes til there's a good consensus on what exactly we want out of a feature like this? Or are there some verbosity flags we think would be worth having now?
<whitequark>
ross_s: nope, i think your nextpnr changes should not be blocked on these concerns
<whitequark>
for verbosity, what if we print backtraces only as it is, and backtraces with context with --verbose?
<whitequark>
tbh, i'm not that convinced about the utility of context in this case
<whitequark>
it's not a diagnostic after all
<ross_s>
yeah, filename:line is really enough for a pointer
<whitequark>
you're not going to be able to spot the issue from those 2 lines most likely
<whitequark>
so i think if you drop all the stuff that reads from files it'd be a very easy merge
<ross_s>
cool, can do
<whitequark>
we can always add it later
<whitequark>
also
<whitequark>
why not just print it unconditionally?
<whitequark>
or at least on-by-default
<ross_s>
If we've shortened it to just the filenames I think that's fine with me
<whitequark>
i'd say print unconditionally though i'm not opposed to a flag
<ross_s>
Alright, pr should be updated
<whitequark>
ross_s: lgtm, i'd rather get a second opinion before merging though