Subject: Re: [sv-ec] Asychronous mailbox proposal
From: Arturo Salz (Arturo.Salz@synopsys.com)
Date: Fri Dec 13 2002 - 15:03:02 PST
Hi Kevin.
Just a clarification. I didn't mean <mailbox>.wait() (a new mailbox method). I
meant
using the Verilog wait construct as in wait( <mailbox> ). The reason for this
is the
different semantics between @ and wait. @ always blocks, whereas wait() does a
check before blocking and can thus be applied to Boolean expressions.
Arturo
----- Original Message -----
From: "Kevin Cameron x3251" <Kevin.Cameron@nsc.com>
To: <sv-ec@eda.org>; <Arturo.Salz@synopsys.COM>
Cc: <david.smith@synopsys.COM>; <Mehdi.Mohtashemi@synopsys.COM>
Sent: Friday, December 13, 2002 2:38 PM
Subject: Re: [sv-ec] Asychronous mailbox proposal
> From Arturo.Salz@synopsys.com Fri Dec 13 11:54:32 2002
>
> Kevin,
>
> One quick note. If indeed lm has bit behavior (persistent ON state as long as
there's
> a message in the queue) then one can't use @(lm) because @ is always blocking.
> For that a more appropriate use would be wait(). Also, I don't see much
difference
> between this form and Mehdi's suggestion of doing a get followed by a clock
sync.
I fail to see how <mailbox>.wait() is better than @(<mailbox>) - get() does an
implicit wait() anyway. The testbench stuff also includes new events with that
kind
of behavior.
> By the way, I believe that the problem you are trying to solve is a real issue
and
> much more general than just mailboxes. The problem is how to synchronize two
> events with one another (in this case one event a message arrival and the
other
> is the clock edge). Perhaps a general solution would be more useful and then
> apply that to this instance.
>
> Arturo
Actually that was just a suggested application. The problem I'm trying to solve
is the decoupling of data processing from clocks. I.e. the presence of the clock
is a consequence of design style/methodology and not really part of the
algorithm
that is being implemented. Mailboxes/channels allow a clockless definition of
how data is to be processed, and consequently give tools more freedom to select
an implementation.
E.g. an asynchronous adder:
mailbox #(int) i_mbx;
a_mbx a = new,
b = new,
c = new; // sum
int a_tmp,b_tmp;
always @ (a or b) begin
a.try_get(a_tmp);
b.try_get(b_tmp);
c.put(a_tmp + b_tmp); // c = a + b
end
SV is a language for event-driven modelling, data arriving in a mailbox is
definitely (IMO) an event and should be handled the same way as other events
in the language.
This approach makes it easier to define
globally-asynchronous/locally-synchronous
designs, and also to do hardware/software trade-off.
Kev.
> ----- Original Message -----
> From: "Kevin Cameron x3251" <Kevin.Cameron@nsc.com>
> To: <sv-ec@eda.org>; <Arturo.Salz@synopsys.COM>
> Cc: <david.smith@synopsys.COM>; <Mehdi.Mohtashemi@synopsys.COM>
> Sent: Friday, December 13, 2002 11:25 AM
> Subject: Re: [sv-ec] Asychronous mailbox proposal
>
>
> > From: "Arturo Salz" <Arturo.Salz@synopsys.com>
> >
> > Kevin,
> >
> > Since mailbox is a class, you can inherit and add the functionality you need
> in a fairly straight forward manner, as shown below. Note that in this code,
> the @ uses the additional boolean bit that indicates if there is any message
in
> the mailbox waiting to be read. This could be done in a very nice way if we
had
> a way to specify read-only members, so that one could wait on a member boolean
> that can only be set internally by the class (but we don't have that).
> >
>
> Partially true, but why can't we just say that it's part of the base class
> and just use @(lm && posedge clock) as shorthand. Actually I should have
> written my original example as:
>
> always @(lm) begin
> lm.get(l_val2);
> @(posedge clock2);
> ...
> end
>
> Which is more efficient to process if lm data occurs less frequently than
> the clock (event expression evaluation isn't usually implemented with
> proper shortcutting). That form is not supported by your suggestion.
>
> Also, I would like there to be a common understanding of @(<mailbox>)
> rather than it being a user-defined extension.
>
>
> If you want to support it properly in a class then I think you need to
> be able to declare events or signals in a class so that you can wait
> for them. Which is probably not allowed at the moment because classes are
> only dynamic.
>
> Given the choice I'd say it's more important to fix the declaration
> mechanism so that you can have static/permanent class objects, and that
> you can be sensitive to them.
>
> Maybe we could add a generic 'event' class and multiple inheritance, then
> I could just inherit that and the mailbox class to create the what's
> needed :-)
>
> Kev.
>
>
>
>
>
> >
>
> ------------------------------------------------------------------------------
> --
> >
> > class kmbox extends mailbox#(logic);
> > bit has_message = 0;
> >
> > function new();
> > fork logic lval; forever begin
> > lm.peek(lval); has_message = 1; // wait for message but
> leave it in the queue
> > wait( has_message == 0 );
> > join none
> > endfunction
> >
> > task get(var logic v);
> > super.get(v);
> > if( num() == 0 ) has_message = 0; // empty mailbox -> reset
> bit
> > endtask
> > endclass
> >
> > // The code below is almost identical to Kevin's original
> >
> > kmbox lm = new;
> > logic l_val1;
> > always @(posedge clock1) lm.put(l_val1) // write data on clock1
> >
> > logic l_val2;
> > always @(posedge clock2 && lm.has_message) lm.get(l_val2); // sync data
> to clock2
> >
> >
>
> ------------------------------------------------------------------------------
> --
> >
> >
> > Arturo
> >
> > ----- Original Message -----
> > From: "Kevin Cameron" <sv-xx@grfx.com>
> > To: <sv-ec@eda.org>
> > Cc: <david.smith@synopsys.COM>; <Mehdi.Mohtashemi@synopsys.COM>
> > Sent: Thursday, December 12, 2002 9:25 PM
> > Subject: RE: [sv-ec] Asychronous mailbox proposal
> >
> >
> >
> > > From: "Mehdi Mohtashemi" <Mehdi.Mohtashemi@synopsys.com>
> > >
> > > Hi Kevin,
> > > The mailbox get method is blocking statement as you realize, however,
> > > the handle does not act as an event, therefore one can not wait on
> > > the change in the mailobx handle as it is indicated in your mail.
> > > The second statement [always @(lm && posedge clock2) lm.get(l_val2);]
> > > intends to qualify a blocking statement, i.e, the get method. This
> > > does not work.
> >
> > It's not that big a deal, there is no syntactic problem with using
> > @(<mailbox>) - a bare mailbox name has no significance at the moment.
> >
> > >From an implementation point-of-view you just create a dummy signal/event
> > that you trigger when the mailbox gets written to, and do a try_get before
> > suspending again.
> >
> > >
> > > The clock-boundry-synchronization mechanism is a general synchronization
> > > issue within SystemVerilog, we can think of incorporating an extra bit
> > > variable to the mailbox type that allows updates once a put is executed.
> > > One has to be carefull with multiple readers of the mailbox as well.
> > > Obviously when there is only one to one reading/updating then the
> > > problem is more managable. One can also extend a mailbox to add
> > > the second level synchronization [i.e, this clock synchronizer, or
> asynchronous
> > > communication].
> > > A possible SV code would be:
> > > typedef mailbox #(logic) l_mbox;
> > > l_mbox lm = new; //global synchroizer defined
> > > logic l_val1;
> > > logic l_val2; ...
> > >
> > > // ... some processes in clock1 domain
> > > always @(posedge clock1) lm.put(l_val1); // write data on
> clock1
> > >
> > > // synchronizer be a re-entrant task as well if we wanted it
> > > // ... another process in clock2 domain...
> > > logic l_temp;
> > > lm.get(l_temp); //blocks here
> > > @(posedege clock2) l_val2= l_temp; // then synchronize to the
edge
> of clock2,
> > > .................
> > > You can also define a method for this:
> > > // a generalized synchronizer between two known clocks can be:
> > > task sync_two (l_mbox l_in, output logic l_out)
> > > begin
> > > logic l_val_a;
> > > l_in.get(l_val_a); // this blocks, insures proper data in the mailbox
is
> recieved
> > > @(posedege clock2) l_out= l_val_a; // then synchronize to the edge of
> clock2, now we
> > > endtask
> > >
> > > - Mehdi
> >
> >
> > The problem with just using the blocking get function is that it's difficult
> > to prioritize reads in different threads e.g.:
> >
> > forever begin
> > l_in.get(l1);
> > @(clock1) ...
> > end
> >
> > forever begin
> > l_in.get(l2);
> > @(clock2) ...
> > end
> >
> > Vs:
> >
> > always @ (l_in && posededge clock1) begin
> > l_in.get(l1);
> > ..
> > end
> >
> > always @ (l_in && posededge clock2) begin
> > l_in.get(l2);
> > ...
> > end
> >
> > In the top version you can't tell which clock edge will take an
> > item of data, in the bottom version it's the first one that occurs.
> >
> > BTW, can the argument to get() be a reg?
> >
> > Kev.
> >
> >
> > >
> > > -----Original Message-----
> > > From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org]On Behalf Of Kevin
> > > Cameron x3251
> > > Sent: Thursday, December 12, 2002 4:41 PM
> > > To: stuart@sutherland-hdl.com; david.smith@synopsys.COM
> > > Cc: sv-ec@eda.org
> > > Subject: RE: [sv-ec] Asychronous mailbox proposal
> > >
> > >
> > > > From: "David W. Smith" <david.smith@synopsys.com>
> > > >
> > > > Hi Kevin,
> > > > I would request that any additions like this go through me before going
to
> > > > Stu. I believe there may be some problems with what you suggest and
would
> > > > prefer to have the discussion first.
> > > >
> > > > Stu, please wait on adding this.
> > > >
> > > > Regards
> > > > David
> > > >
> > > > David W. Smith
> > > > Synopsys Scientist
> > >
> > > Since it's only a small extension to mailbox functionality, can we clear
up
> > > any issues with it over the reflector?
> > >
> > > BTW, when was striking out dynamic processes approved?
> > >
> > > Kev.
> > >
> > >
> > > > -----Original Message-----
> > > > From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
Kevin
> Cameron
> > > > Sent: Thursday, December 12, 2002 12:30 PM
> > > > To: Stuart Sutherland
> > > > Cc: sv-ec
> > > > Subject: [sv-ec] Asychronous mailbox proposal
> > > >
> > > >
> > > > Stu,
> > > >
> > > > I was wondering if you could paste the section below into the LRM for
> review
> > > > with the mailbox stuff, it's the only functionality from the channels
> > > > proposal that isn't handled by mailboxes (the rest is handled by
DirectC):
> > > >
> > > > 12.5.1 Asynchronous Mailbox Communication
> > > >
> > > > Data arriving at a mailbox generates an event. The event is true while
> data
> > > > remains in the mailbox. As with signal events these events can be waited
> for
> > > > with the @ operator. The following code could be used to replace a wire
of
> > > > type logic with a FIFO to safely cross clock domains:
> > > >
> > > > typedef mailbox #(logic) l_mbox;
> > > >
> > > > l_mbox lm = new;
> > > >
> > > > logic l_val1;
> > > > always @(posedge clock1) lm.put(l_val1) // write data on clock1
> > > >
> > > > logic l_val2;
> > > > always @(lm && posedge clock2) lm.get(l_val2); // sync data
to
> > > > clock2
> > > >
> > > > -------------------------------------------
> > > >
> > > >
> > > > Note: the alternative code without @(lm) would poll on every "posedge
> > > > clock2" and do a try_get - which is a lot more inefficient.
> > > >
> > > > Regards,
> > > > Kev.
> > > >
> > > > --
> > > > National Semiconductor, Tel: (408) 721 3251
> > > > 2900 Semiconductor Drive, Mail Stop D3-500, Santa Clara, CA 95052-8090
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
>
>
>
>
>
This archive was generated by hypermail 2b28 : Fri Dec 13 2002 - 15:02:17 PST