On Mon, Jul 21, 2008 at 01:28:53AM -0400, Sanjay Singh wrote: > > > Making the simulator multi-thread is not very hard. I did a try a few years > > ago. > > > > I'm glad you think its relatively tractable. Its been a while since I > last sat in on the lecture of how delta cycle simulations work. I'll > have to dig into it again.
The delta cycle algorithm is described in LRM chapter 12. Roughly speaking it consists in two phases: * processes are run * signals are updated and the list of processes to run is updated. > In some sense the uniprocessor case is easiest since one knows that in > some kind of event queue, there is nothing else going on by any other > process or thread. > > But to parallelize it, I surmise that what you would do is have an event > queue that is populated in parallel by asynchronous threads? Each of > these threads would be created by mapping independent VHDL constructs to > their own threads and then they sort of just hang out and wait for > things to happen? I my first implementation, processes were simply run in parallel. This is rather easy to do as there is almost no interractions between processes while they are run. > I'm probably not quite correct here, but I'm thinking that since the > VHDL is intended to model independently operating chunks of hardware, > the right thing to do if you have parallel computer hardware available > is to sort of mimic the actual system by spreading out the VHDL > components to be simulated across the extra processors, ie. parallel > hardware = parallel running simulation with shared event queue. Yes, this is the first step. > I am just not sure about whether there could be unexpected problems with > any kind of thread synchronization as these. Would the event queue have > to be some kind of linked list so that as the asynchronous threads run, > events can be inserted as needed until they are all resolved and then > the simulation is complete? There must be a synchronisation when time is updated. Trying to remove this synchronization is harder but there were a few attempts to do so in some simulators. Might be worth to search and read articles. > The other question is whether it makes more sense to implement a > multi-threaded simulator where the operating system scheduler manages > the many threads (potentially thousands) and their interaction. Or > whether the simulator should instead have multiple processes, each of > which acts like the single threaded simulator, which can support any > number of VHDL entities to be simulated in parallel, but uses > interprocess communication to talk to the others until all events are > resolved. Much harder because of VHDL semantics. Tristan. _______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
