> 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. 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'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. 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? 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. This would be lighter weight in terms of operating system overhead since instead of very many small lightweight threads, you have fewer processes each managing a large number of passive VHDL structures that must be examined to enqueue events that they would generate. In either case there would likely still be some shared memory event queue, but the many-threaded way would involve much more interprocessor communications but it would be truly general. The other way, with few processes managing many VHDL structures might run better on 4-8 processor systems because such systems would run out of processor resources relatively quickly anyway, and would spend more time context switching hundreds or thousands of threads for large simulations. Assuming I am not too far wrong with visualizing how delta cycle simulations work, is there any way to tell which would be the better way of doing this? > I think parallelizing loops won't be very effective as there aren't big > loops. > Yes, I am talking about those sorts of things which can be done safely and automatically by a good compiler that knows the system its compiling for. For example, the Sun compiler can take into account cache sizes and specific features of the processor its targeting to minimize things like cache misses and make best use of register allocations and things like that. Things like loop unrolling and stuff is fairly standard now, if you don't mind larger binaries. > Thanks. I will try to finish the transition to multi threads. > I wish it were possible to help more... but Ada is not something I know too well. Perhaps there are others who do know it well enough to lend a hand? S. _______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
