|
From: Felix S. <fe...@sa...> - 2018-01-21 13:13:29
|
On Sun, Jan 21, 2018 at 01:29:14AM -0800, Kevin Cameron wrote: > I handed over working code (still have it around somewhere), got it back > converted to a "plugin" (unnecessarily), and not working. Hi Kevin. I have never seen the working (non-plugin?) version of this code. If you insist that it worked, and still have it around, then may I please ask you to share it? Beat, in particular could be interested. I presumably only know the code after you "got it back". I was not even around at earlier times. As the "conversion to plugin" usually does not affect functionality, your claim of having "working code" again pricks up my ears. and i must say, i am (naturally) skeptical. The code that I have seen tried to link (i.e. "cosimulate") two separate event queues. is that not the idea behind the "working code"? Now in reply to Beat, you write "simulation as co-simulation [it] generally doesn't go well"... if cosimulation does not go well (which i believe is true), it looks more promising to implement a tgt-$simulator for Icarus. this is off-topic in a cosimulation thread. but examples exist, these just dont fully work and need work. tgt-$simulator would turn a verilog module into a component the $simulator can pick up and run. there's no doubt that Icarus is the right tool, also gnucap-adms should be ported to Icarus, eventually. there should be just one that does all of ams. certainly, even tgt-xyce would be pretty neat, if somebody cares to do it. On Sat, Jan 20, 2018 at 04:00:42PM -0500, Beat Arnet wrote: > And is there a way to save all simulation states in Icarus in order to > revert a run back from the future? It is possible, but (was) pretty hard to do. i gave up on it, when it did not seem feasible without forking, either way. Or not worth it. best felix |