Multi-line comments and other general improvements

[ginty]

This PR adds the following:

• Support for multi-line comments per issue #8
• Improves error messages in crashed simulation runs rather than falling back to the 'broken pipe' error.
• Adds the ability to override the socket directory at runtime (a system debug feature rather than a user feature)
• Improves documentation per issue #23

More details:

Adding support for multiple comments at a given stage proved to be more difficult than simply concatenating them together - this approach quickly ran into issues with exceeding the size allocation of messages and the VPI structs used to set the comment register. This then drove me down a different path than originally envisaged and instead of simply concatenating multiple comment lines together, they are now captured by multiple comment line registers in the simulation, here is an example from a test case:

Overall, I think this makes for a more user-friendly solution, it is much more readable than simply extending a single comment line/variable. I've chosen 10 lines as an arbitrary number which seems to strike the right balance between providing enough information while not taking up too much in terms of screen real estate. Any additional lines will be discarded, so you will always see the first 10 and additional messages will not overwrite like they did before.

All of the starter wave configuration files have been updated to put all 10 registers into a group called Comments within the existing debug group.

@coreyeng, I've added a few things that might help with debug of your LSF issues. Instead of just saying broken pipe it will now try and differentiate between communication going down because the socket is broken (and the simulator process is still running), or because the simulator process has stopped.

I also added a sleep for 2 seconds before exiting in the event of communications going down, this was just to keep the stdout/stderr loggers alive a bit longer in case the simulator had any last words that we were missing by exiting immediately.

Finally I added the ability to specify a different socket directory at runtime instead of /tmp, which is the default. So you could do: origen g my_pattern --socket_dir tmp/sockets to use the tmp dir in the application instead. This may or may not do much, but it will at least allow you to rule out whether the problem is due to the use of /tmp or not.

@priyavadan, when I sat down to implement the changes discussed in #23 I came to the conclusion that the current behavior is the correct one and that this was more of a documentation issue.

I've updated the example with the done pin in the guides to show it being set to dont care afterwards.

The reason for not adding the auto-rollback is that it would introduce an inconsistency between sim_delay and how Origen works in general (i.e. pin states normally persist), and with match loop blocks which don't do a similar auto-rollback. Also I think in many application cases continuing to enforce the assertion established by the delay block would be the desired behavior.

So, I've left this up to the application and improved the docs to hopefully avoid others getting caught out like you were.

[redxeth]

@ginty very nice. Will try to take a look today.

It just occured to me that a "neat" feature of multiline would be to interpret '\n' in a comment as a desire to do multiline-- so not just having multiple comment commands. Would that be an easy update to your solution?

[ginty]

@redxeth, I wouldn't add that here, that should be handled upstream in Origen core, e.g. in the ss method to split it internally into multiple comments if the given message contains newlines. If implemented there though, it would work fine downstream in OrigenSim as it is.

[redxeth]

@ginty Yeah that makes sense. '\n' become equivalent to calling 'ss' twice. Can add that as an 'issue/feature' or Origen core then.

[priyavadan]

@ginty LGTM!