Tristan Gingold wrote: > 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. > Here's a paper describing issues on Parallel Discrete Event Simulation (PDES) in VHDL:
http://citeseer.ist.psu.edu/571811.html Parallel and Distributed VHDL Simulation (2000) Dragos Lungeanu, C.J. Richard Shi There's also this one providing background: http://citeseer.ist.psu.edu/naroska98parallel.html Parallel VHDL Simulation (1998) E. Naroska Computer Engineering Institute University of Dortmund 44221 Citeseer is a good place to look, I'm not an IEEE or ACM member, and don't currently have access to Springer-Verlag. >> 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. It may be worth looking at Tyvis on top of WARPED in Savant now from Clifton Labs. I don't think its is being actively maintained or developed, but it may be a worth while reference. The Internal Intermediate Rrepresentation (IIR) format came from AIRE/CE IIR (Advanced Intermediate Representation with Extensibility/Common Environment) done for Savant. The intent of IIR appears to have always been a model transformation suitable for parallel simulation. Historically multi-threaded meant different systems or at least different CPUs. > >> 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. > See the first paper listed above. >> 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. Dynamic Multi-Threading (DMT) doesn't cure everything. Perhaps more of an optimization for a class of platform targets. It's cheaper to do a bunch of PDES simulations on low cost boxes than buy even small numbers of heavy iron like Niagara servers. Depending on an OS for maximum concurrency is well and fine until you need more cores and threads than you can fit in a box you can afford, you'll eventually need PDES anyway. There are obvious ways of tarting up PDES for a Core Multi-Threaded processor (CMP - multicore). For instance you could peel off the network transport layer and do just the share memory interface between processes, just like classical Symmetrical Multiprocessors. The second paper listed above may help with insight on how to divy up the model for efficiency. There's also Ada Tasks as mentioned by Mr. Leake. I'd imagine you might get lucky in ghdl and not go any further back than elaboration, with the majority of work in the simulator (grt - ghdl run time library, today) when implementing PDES. There are other reasons to work on the simulator. Today ghdl can't compete directly with commercial offerings, I remember when Haneef Mohammed (VHDL Simili) was in the same boat or even a little further back when Modelsim wasn't seen as a serious contender around 1991. I'd imagine you could set priorities for capturing user mind from commercial products, the priority order something like this: LRM features/compliance Simulator features Modeling Features Tool Integration Performance The order could easily change, too. I can imagine for instance multi HDL support driving performance because the 'market' is different. Priority is driven by who you can attract to using ghdl, and why. There are lots of reasons to not try and overspecialize ghdl. In addition to the user base currently comprised of us freeloaders and ghdl not yet being a mature tool system, the state of commodity platforms has been evolving fast enough to stick with the herd. ghdl hasn't been evolving fast enough to put a stake in the ground with bleeding edge technology which may have reached it's use by date by then. I've personally had all sorts of fancy toys over the years, SGI workstations, SPARCs, Alpha processors and UltraSPARCs. The return on investment hasn't been there, and I currently use a notebook (albeit running Linux). Maybe we could get Tristan to tell us where and how he sees ghdl going? He's commented privately in the past on what he'd like to see worked on. _______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
