On Mon, 2013-06-03 at 20:33 -0700, Jon Taylor wrote: > > > > On Mon, Jun 3, 2013 at 5:35 PM, David Koontz <[email protected]> > wrote: > > On 4 Jun 2013, at 6:13 AM, Jon Taylor <[email protected]> > wrote: > > > Setting stop-delta to 2 billion seems to make the simulation > > run long enough to enable me to test my code - the native > > sockets I'm using to emulate a bus aren't timing out any > > more.
I would echo and reinforce David's opinion that increasing or removing the delta limit per simulation timestep is almost certainly the wrong approach, as well as restricting people to using GHDL only. If your process are self-timed, it is probably more appropriate to approximate reality by adding some sense of timing to them; for example by adding after clauses - even "after 1 ps" to your synchronisation signal updates (all other updates can remain "immediate"). This would reset the delta cycle count and allow the delta cycle mechanism to catch and help identify any unexpected loops. > I actually would prefer to use a separately-threaded back-end for > general-purpose I/O and bus management (interrupts, exceptions, > mcopy(), mmap(), etc) when running on a CPU-based system. It sounds to me that Ada 2005 or 2012 would be a good match for the software levels of your design, with its close compatibility to VHDL helping ease the transition between hardware and software levels. You may not need the full extent of its multitasking capabilities, a relatively lightweight subset like Ravenscar might be all you need. - Brian _______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
