Subject: Re: More Thoughts on Jeda
From: Kevin Cameron x3251 (dkc@galaxy.nsc.com)
Date: Wed Nov 21 2001 - 18:08:38 PST
> From owner-vlog-pp@eda.org Tue Nov 20 22:47:30 2001
>
> More things to think of.
>
> Jeda has an assert statement, it would be good to analyze. But additional
> features I found interesting is the software/hardware modeling aspect.
> Multi-threaded, control, priority, semaphore, and mailbox.
> Although ESS is supposed to be synthesiable, many constructs are
> verification-oriented. Since Get-2Chip has not been active in this
> committee, we have not analyzed the semantics of many of the constructs
> in the synthesis fashion. The focus so far is on verification and assertion.
>
> 1- Fork:
> a- Fork-knife: Move forward without a child.
> b- Fork-Spoon: Wait until one of the threads finish execution.
> c- Terminate statement can be used to terminate a thread and descendant. The terminate
> can also provide level of control on a nested thread.
> 2- Thread Execution:
> - The thread execution is done in pseudo concurrent manner, that is, there's only one thread actually running at a given time. Also, the thread execution is done in non preemptive manner, that is, a thread that is running will not give up it's execution until it reaches to a code that suspends the thread itself.
> - Cloned variables to allow local control inside a specific thread instance.
> - Thread Pause.
> - Thread join.
> 3- Event: Jeda defines several additional events.
> 4- Semaphore (not existing in System Verilog yet): Semaphore class object provides the mutex mechanism and synchronization mechanism among threads.
> 5- Mailbox: List variables to be sent among threads.
> - Receive: FIFO type list.
> - Send (data):
> - Num Element.
> - Timeout:
> 6- Region: enter, exit, etc.
>
[While we are looking at other languages]
HDLs are essentially multi-threaded programming languages, the main difference
between an HDL and regular programming language is that an HDL has a static structure,
while regular programming languages are dynamic, also where a language like C uses
shared memory and semaphores for communicating between threads HDL processes use
signals with resolution. The programming language I know that is most like an HDL
is Occam which was designed for programming "transputers" - which didn't have
virtual memory, so the language used a static mapping of threads to hardware.
Occam was based on the "Communicating Sequential Processes" (CSP) paradigm -
Personally I think the CSP model is friendlier and more scalable than the shared
memory/semaphore approach. CSP uses "channels" for communication between processes
and doesn't let them share data - it's a lot easier to debug. CSP style channels
are like Unix "pipes" and are effectively language neutral, so provide an easy
bridge between system-level (untimed) simulation and Verilog (RTL).
I would prefer to see a mechanism for feeding CSP style channels into System
Verilog "interface" objects than introduce semaphores etc., that would allow
a top-down design flow where I can model data processing elements (CPUs, MPEG
decoders etc.) in C/C++ as seperate (parallel) processes and then map their
communication channels to hardware busses (interfaces) in System Verilog, and
then map the processes themselves into something synthesizable.
I can do some more work on this if people are interested.
Regards,
Kev.
This archive was generated by hypermail 2b28 : Wed Nov 21 2001 - 18:09:33 PST