Subject: Re: [vhdl-200x] RE: Posix Threads
From: vhdl-200x@grfx.com
Date: Thu Jun 12 2003 - 09:58:12 PDT
> From: Evan Lavelle <eml@riverside-machines.com>
>
> vhdl-200x@grfx.com wrote:
>
> > We were talking about threads that belong to the simulation kernel, not
> > threads created by the user controlled from the simulation kernel. As
> > Peter suggests they would be on a par with regular VHDL processes just
> > created dynamically. What you are suggesting is more like co-simulation
> > (not that I object to that).
>
> Ok.. (and presumably you mean "controlled from the *OS* kernel" rather
> than the 'simulator' kernel). This thread's subject and the Posix
> references lead me to believe that people are actually interested in
> real pthreads-style threads, rather than extensions to process-creation
> semantics, which are two completely different things.
>
> What about the people who wanted 'fork/join'? Are they happy with
> dynamic processes? My guess is that they were looking for something else.
The new fork/join syntax in SystemVerilog came directly from Vera, and most
of the Vera stuff added to SystemVerilog was not modified much - mostly so
it could be released for DAC 2003 rather than it was the best syntax/semantics.
A number of Vera users and myself complained about the lack of thread control.
SV 3.0 had a process creation statement seperate from fork/join (from Superlog)
but it got removed in 3.1.
I suggested looking at pthreads for a list of the control functions needed
to manage dynamic threads (kill, suspend, wakeup etc.) the actual creation
mechanism I'm less bothered about. The fork/join syntax doesn't lend itself
to getting handles (thread ids) for the threads created that are need for
the control functions, so I'd rather not see it repeated in VHDL.
> >>As an aside, SystemC doesn't specify how the scheduler is implemented.
> >>The reference OSCI implementation is a normal
> >>single-process/single-thread app; it doesn't use threads. Using threads
> >>for HDL processes would be bizarre; it would be far too expensive
> >>(particularly on Linux, where a thread is actually a process). If you
> >>have the OSCI sources, you can find the evaluate/update code in the
> >>'crunch' routine in sc_simcontext.cpp.
> >
> >
> > The last person I talked to about this said they were using "quickthreads"
> > (http://www.cs.washington.edu/research/compiler/papers.d/quickthreads.html,
> > http://sources.redhat.com/ml/cygwin/1999-12/msg00390.html).
> >
> > All HDLs are just multi-threaded programing languages. Verilog and VHDL
> > are constructed to avoid placing data on the processor stack so that they
> > can switch threads (processes) without having the processor change context.
> > C++ compilers are not designed to do that, so moving control from one C++
> > model to another often requires a context save and restore to maintain the
> > stack for each model - you can write C++ that doesn't need to do that but
> > it's going to be awkward.
> >
> > Kev.
>
> This is getting OT, but I guess it does have some relevance. The OSCI
> reference implementation does use the QuickThreads code for some
> processes (thread processes). QuickThreads is a fast and lightweight
> user-level thread abstraction, which is not kernel-aware. It provides no
> synchronisation or scheduling, and basically just does context switching
> by changing the stack pointer.
I doubt all it does is just change the stack pointer. NB: each thread needs
enough stack for its maximum call depth permanently allocated, the default
in Solaris is 2Mb - it's pretty inefficient in virtual memory if you have
a lot of them. Verilog has different semantics for tasks and functions to
avoid requiring permanent stack space.
> The term 'threads', as far as I'm aware, is normally used to refer Posix
> threads, which are very different. The kernel has to know about threads,
> for various reasons - threads can be placed on different processors in a
> multi-processor system, the kernel has to assist with the
> synchronisation primitives, threads must be signal-aware, and so on. In
> this context, SystemC is single-threaded. When I run gdb on my SystemC
> code I see one thread for the thread manager, one for SystemC, and all
> my own explicitly-created threads.
>
> Evan
There is a difference between multi-threaded and parallel-processing.
Most simulator/SystemC implementations only have one active thread at a time
which is "single thread of control", quickthreads may be using a single OS
thread to handle multiple user threads so you would only see one thread in
the debugger (the same would be true for most Verilog/VHDL simulators).
A C++/backplane based verification platform at Nat. Semi. using Solaris
threads normally had ~ 30 seperate threads visible in gdb - but only one
was ever active.
From a specification standpoint I'd prefer to assume the threads are active
concurrently (parallel processing).
BTW, I think SystemC would be a good solution if you could get a specialised
compiler that was aware of the highly multi-threaded nature of the problem,
but I'm not sure anyone is going to build that :-(
Kev.
This archive was generated by hypermail 2b28 : Thu Jun 12 2003 - 10:00:41 PDT