search

Origen-SDK / origen_sim

Plugin to enable Origen patterns to be run in a dynamic Verilog simulation
MIT License
1 stars 4 forks source link

Update to support long logger messages to the VPI. Messages need to b… #36

Closed coreyeng closed 5 years ago

coreyeng commented 5 years ago

Hello,

I've had to put off updating my application to the latest OrigenSim due to some odd issues with hanging simulations and what appeared to be losing STDOUT, which was true, but not for the reasons I originally thought.

With the logging changes between 0.14 and 0.16, using Origen.log(…) now routes through the simulator to keep things in sync, which is great! However, the VPI has a limit of how much input data it can take: 1024 characters to be precise. If you try to send, say 1024 'a's, you'll crash the VPI, stop being able to send/receive stuff from the simulator, but still keep the simulator running. Since I don't really make use of syncs and those features (yet), I'd just see my sims got silent after a certain point.

I imposed a limit on the size of the logger messages going through the VPI. Its a config option since I'm not sure if the 1024 limit is a Cadence limitation or part of the spec. Other vendors may be more or less. This update support longer messages by splitting them into chunks the VPI can handle and appending a 'multi-part message' token, !<>!, to indicate that there's more message incoming. The stdout reader was updated to watch for this token. With this change, I'm able to get my long messages through the simulator as before without having to change any other dependencies or manually split them. I didn't notice that the stderr reader ever gets input from the VPI, so I didn't make any equivalent change there.

A few other small changes I needed:

  1. I had previously added a post_process_sim_cmd that I hadn't used for a while, but started to again to throw in sim_args based on the target/environment options. However, when Origen tries to save the configuration, it can't do so for Procs and raises an error. So, I just added an exception for this. The save config still works as normal, it just ignores any config settings listed in the NON_DATA_CONFIG_ATTRIBUTES array. Since these aren't saved in the session's store anyway, the end result is the same.
  2. I'm not sure if this is a testbench or a design thing, but I had some trouble with what I think is a model checker failing even if no drive occurs on one of my pins. The pin stays X the entire time, and since its a ground pin for the IOs, it ends up causing everything to fail. The only way I was able to get my snapshots to work was to disconnect the pin entirely, so I added an option for that during sim:build.
  3. Reloading the target during the probe compilation was causing some device setup done before Pattern.create to be lost. Since I'm not sure why reloading the target is necessary I added the option to preserve the target.
coreyeng commented 5 years ago

After I typed this up, I realized I mostly made change to the VPI side so I could get some experience with the VPI but, in retrospect, this really should just be a Ruby-side change. The Ruby side can chop up the message and send the multiline token through.

I'm going to update the PR to do this on the Ruby side...

coreyeng commented 5 years ago

I suppose I could also update the VPI to support a !k+! token at the beginning, but the way it is now is only on the Ruby side and won't require and snapshot spins. It'll just be a bug fix for everything OrigenSim 0.15+.

ginty commented 5 years ago

Looks good @coreyeng, is it possible to add something to pattern/test.rb to send a long message so that we have a test case for this?