search

ominux / vtr-verilog-to-routing

Automatically exported from code.google.com/p/vtr-verilog-to-routing
0 stars 0 forks source link

run_vtr_flow.pl error reporting is vague #26

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
run_vtr_flow.pl gives essentially no information about why a circuit fails.  If 
there is an error, an error message appears of the form:
circuitname/circuitname...failed: stage
which gives no information about the actual cause of the error, even though 
more detailed information is available in the log files.  
Is there some way to get the perl script to return the same terminal output as 
the individual stages would return if they were run manually?

Original issue reported on code.google.com by mikewain...@gmail.com on 11 May 2012 at 9:18

GoogleCodeExporter commented 9 years ago 
Everyone benefits from better error reporting.  I'll assign this over to 
Nooruddin.  Since he will be setting up our automatic build/regression 
infrastructure, he will need to deal with error reporting when the regression 
script (run_vtr_flow.pl) discovers a problem.

Original comment by JasonKai...@gmail.com on 11 May 2012 at 9:36

GoogleCodeExporter commented 9 years ago

Original comment by JasonKai...@gmail.com on 11 May 2012 at 9:36

GoogleCodeExporter commented 9 years ago 
Yes, it would be more convenient to not have to look into the log files, but 
the errors in log files do not follow a consistent pattern so it is not trivial 
to parse for them. I think outputting all of the log files would be way too 
much information, and would flood the output making it difficult to tell which 
tests failed where.

Personally, I like the format as it is a clear overview and have found it very 
helpful. Obviously  providing just the error would be nice, but we would need 
to change all of the executable to have.  standardized error messages. This 
definitely would be nice to have, but would be some work. Also we don't really 
control ABC, although we could hack it.

Original comment by jeffrey....@gmail.com on 12 May 2012 at 1:22

GoogleCodeExporter commented 9 years ago 
We can do something as simple as state whether a crash occurred or parse for an 
"error" tag.  It doesn't have to catch all cases as the developer will need to 
look into it regardless.  

I'll leave it up to Nooruddin then to decide how much detail to report.  
Nooruddin, place the auto-build infrastructure at higher priority than this 
issue.  You'll eventually come to this issue as you start to deploy and test 
your auto-build infrastructure.

Original comment by JasonKai...@gmail.com on 12 May 2012 at 1:30

GoogleCodeExporter commented 9 years ago 
Sounds good. I will look into it.

Original comment by ahmed...@gmail.com on 12 May 2012 at 3:51

GoogleCodeExporter commented 9 years ago 
You guys are working late!   Nooruddin, go ahead and put some thought into 
this, but it may take a lot of revamping of code which you shouldn't be doing 
right now.  This issue - error reporting - is something we can discuss in the 
VTR meeting (the thursday meeting).

Original comment by Jonathan...@gmail.com on 12 May 2012 at 3:23

GoogleCodeExporter commented 9 years ago 
It would be good to have the Odin II standard error stream report to the 
console. It normally contains nothing, except when there is an error in 
elaborating the circuit. Not sure if the other tools follow this convention, 
but they certainly could. 

I also notice that the standard error from Odin II gets mangled amongst the 
standard output in the log files.

Original comment by andy16...@gmail.com on 12 May 2012 at 6:36