Subject: RE: [vhdl-200x] RE: Posix Threads
From: Jayaram Bhasker (JBhasker@esilicon.com)
Date: Wed Jun 11 2003 - 12:09:13 PDT
Jay:
I think what you are saying is that implementing dynamic processes in VHDL should not be a
problem, correct?
- bhasker
------
J. Bhasker, eSilicon Corp
1605 N. Cedar Crest Blvd, Ste 615, Allentown, PA 18104
jbhasker@esilicon.com, 610.439.6831, 610.770.9634(fax)
-----Original Message-----
From: Jay Lawrence [mailto:lawrence@cadence.com]
Sent: Wednesday, June 11, 2003 2:49 PM
To: vhdl-200x@grfx.com; vhdl-200x@eda.org
Cc: sc@vcc.com; peter@ashenden.com.au
Subject: RE: [vhdl-200x] RE: Posix Threads
I believe vendors already do dynamic driver creation for the most part.
Most 'C' APIs support this so that foreign models can be integrated at
runtime.
Jay
===================================
Jay Lawrence
Senior Architect
Functional Verification
Cadence Design Systems, Inc.
(978) 262-6294
lawrence@cadence.com
===================================
> -----Original Message-----
> From: vhdl-200x@grfx.com [mailto:vhdl-200x@grfx.com]
> Sent: Wednesday, June 11, 2003 2:28 PM
> To: vhdl-200x@eda.org
> Cc: sc@vcc.com; peter@ashenden.com.au
> Subject: RE: [vhdl-200x] RE: Posix Threads
>
>
>
> > From: "Peter Ashenden" <peter@ashenden.com.au>
> >
> > I'd just like to reinforce the view that VHDL already has
> threads - they're
> > called processes. The issue is that they're statically
> created and there is
> > no form of abstraction (ie, no declaration and
> instantiation). An proposal
> > to add dynamic thread should build on the existing
> concurrency model in the
> > language so as to main conceptual consistency. Hence the
> approach we took
> > in SUAVE - see www.ashenden.com.au/suave.html.
> >
> > Cheers,
> > PA
>
> I certainly agree with that, but I think the implementation
> issues associated
> with dynamically creating drivers for signals may put some
> folks off. I
> suggested elsewhere that we add explicit driver declaration
> so that multiple
> processes can share one driver (similar to a reg in Verilog)
> - that would
> allow a driver (which usually maps to a hardware object) to
> persist beyond
> (short lived) dynamic processes that are just behavioral models.
>
> Kev.
>
>
> >
> > --
> > Dr. Peter J. Ashenden peter@ashenden.com.au
> > Ashenden Designs Pty. Ltd. www.ashenden.com.au
> > PO Box 640 Ph: +61 8 8339 7532
> > Stirling, SA 5152 Fax: +61 8 8339 2616
> > Australia Mobile: +61 414 70 9106
> >
> >
> > > -----Original Message-----
> > > From: owner-vhdl-200x@eda.org
> > > [mailto:owner-vhdl-200x@eda.org] On Behalf Of vhdl-200x@grfx.com
> > > Sent: Wednesday, 11 June 2003 11:51
> > > To: vhdl-200x@eda.org
> > > Cc: sc@vcc.com
> > > Subject: Re: [vhdl-200x] RE: Posix Threads
> > >
> > >
> > > > From: Steve Casselman <sc@vcc.com>
> > > >
> > > > I like the synchronization aspects of Posix threads. "The
> > > Mutexes are simple
> > > > lock primitives that can be used to control access to a
> > > shared resource and
> > > > the condition variable which supplements mutexes by
> > > allowing threads to
> > > > block and await a signal from another thread" (ripped off
> > > from somewhere on
> > > > the net). Threads are used in Java and many other
> "latest greatest
> > > > languages." We should make sure that we cover both Verilog
> > > style Fork/Join
> > > > and Posix threads.
> > > >
> > > > Steve
> > >
> > > I don't think you need both, the fork/join stuff is just a
> > > subset of the
> > > p-threads functionality. A lot of the syntax in
> SystemVerilog (3.1) is
> > > inconsistent and hard to extend - I'd try to avoid
> copying the style.
> > >
> > > Kev.
> > >
> >
>
>
This archive was generated by hypermail 2b28 : Wed Jun 11 2003 - 12:10:08 PDT