Generic socket2 - Merged Generic Socket with master and added some features.

[coreyeng]

This PR adds a generic toolchain/vendor option, in the same way the #10 did, but uses the options generic_run_cmd now, since post_run_start_block isn't really correct anymore.

E.g.:

OrigenSim.generic(startup_timeout: 900) do |sim|
  sim.testbench_top 'na_origen'
  sim.generic_run_cmd do |s|
    "ncsim na_origen -loadpli origen.so:bootstrap +socket+#{s.socket_id}"
  end
end

All the other changes still exist as before.

This command will be run in the same way as a supported vendor's would, i.e., using #9 's enhancements.

A few additions that I made:

• -d wasn't working correctly, that is fixed now.
• Differentiated between fails from stderr and stdout. It took me a while to track down some pesky fails that was actually a Verilog file writing log info to stderr for... reasons. Now, it will say if the log failed and/or if stdout failed. I didn't differentiate between them in the log though. Maybe I should? I thought it might get in the way of the actual output line.
• The default for stderr is to log everything as a fail and exceptions can be added to OrigenSim.stderr_string_exceptions, similarly to stdout.
• Line from either stdout or stderr that would normally be flagged as errors, but aren't anymore due to user intervention, are no longer logged as errors (turn red). I think this was already true for stdout, but added it for stderr.
• Added a post_process_run_cmd option that can post process the command from any vendor.
• Updated the README with these features and with the ncsim example, per feedback.

I'm not sure what to do with post/pre_run_start_block. I don't think these are relevant anymore, but not sure if it would be good to keep since they are already there. Thoughts?

[coreyeng]

Added a slight differentiator to STDERR and STDOUT fails. I think it looks pretty out of the way and shouldn't be confused with raw output.

[coreyeng]

Then how this looks at the end:

[coreyeng]

Thanks! I even proofread these and still had mistakes... I'll fix the Readme.

What do you think about just removing the pre/post_run_start_block options? I'm not sure what use they would have now, since those are still run in the parent process, not the testbench process.

I've kinda gone the way of over-rejecting and being quick to fail the simulation. Since the condition strings are different for stderr and stdout, I thought we should have two separate exception strings and maintain them independently. My thought is that if I originally only removed some string from stdout, then it all of a sudden started appearing in stderr, I'd want to know about it. Not sure if this is easier than just maintaining a base array and concatenating it with both.

What about a middle ground of error_exception_strings that apply to both, then having stdout_exception_strings and stderr_exception_strings. I also think we should add error, Error, *E to the list of default error strings as well, but was planning to do that later.

Maybe too much detail, but I've gone the way of over-rejecting since I don't see our design taking over the snapshot generation here anytime soon. Having to at least look at a bunch of Verilog errors forces us to understand what we're skipping and what it means, especially since I'm just a makeshift verification engineer for this and its real easy to just look a block of text, get a pass result, and not look at it again. Examples of things that I could have fixed in the past with this were:

• the pin setup from a few months ago
• an incorrect path causing my RAM contents not to load (its an error, but not a E, since E would kill it)

Not much, but enough to where a forced check of 'what does this error actually mean' would have, I think, been helpful. Then of course they can always just disable everything if they want.

[ginty]

Agree with losing the pre/post run start blocks.

I don't have a strong opinion on the error handling, I think your experience is better and if you prefer the current way I'm fine with that.