Sorry for getting this in late, but I have two requests for consideration:
1. [Most important] Make sc_event::request_update() thread-safe. This would allow safer interactions between systemc and external software. I don't think this is very hard to do after looking at the OSCI implementation code. It means that when processing update requests, we add a provision to ensure that makes the exchange safe. A Pthread mutex is one approach. To reduce the performance impact, there can be a special 'request_update_r()' procedure added for those channels requiring safety. There would still be some overhead in the kernel to support this, but I believe it can be minimal.
2. Add the no_clock primitive channel. At NASCUG 12 (DVCon) this year, I presented an idea for a channel I called 'no_clock'. It is an implementation providing the interface of 'sc_clock', plus additional methods that allow use of clock semantics without the overhead of clock events every period for a large number of situations. For example, in a lot of situations it is important to delay N clock periods, but it is a acceptable to simply 'wait(N*clock.period())' rather than 'for (int i=0; i!=N; ++i) wait(clock.posedge_event())'. I added a number of methods supporting this methodology including the ability to wait for select clocks without the penalties. I would like to donate this channel with it's extended interface to P1666 if acceptable. I also understand if folks would prefer me to take this to the OSCI LWG first.
------------------------------------------------------
David C Black, XtremeEDA ESL Practice Leader
http://www.Xtreme-EDA.com
(Consulting, Services & Training for all your ESL, verification and DFT needs)
Voice: 512.850.4322 Skype:dcblack FAX: 888.467.4609
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Mon May 17 16:03:39 2010
This archive was generated by hypermail 2.1.8 : Mon May 17 2010 - 16:03:42 PDT