I totally agree with this as a modeling person. There is a difference between an sc_prim_channel which would represent a hardware object that should not be instantiated after elaboration, and a simulation artifact that should be instantiable after elaboration.
The question here is if it would impact the synthesizability of SystemC code using sc_mutex/sc_semaphore. If it does, would it make sense to have a separate pair of classes for use as simulation objects?
Best regards,
Tor Jeremiassen
--- Tor Jeremiassen, Ph.D. Simulation and Modeling CTO SDO Foundational Tools Texas Instruments Ph: 281 274 3483 P.O. Box 1443, MS 730 Fax: 281 274 2703 Houston, TX 77251-1443 Email: tor@ti.com<mailto:tor@ti.com> ________________________________ From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of john.aynsley@doulos.com Sent: Thursday, March 25, 2010 9:17 AM To: systemc-p1666-technical@eda.org Subject: sc_mutex and sc_semaphore The two classes sc_mutex and sc_semaphore are derived from sc_prim_channel, implying that they cannot be instantiated dynamically during simulation. This has always seemed an unnecessary restriction which prevents the dynamic creation of mutexes and semaphores for use in synchronizing dynamic processes. How about we derive them from sc_object instead? This change would not break anything, except where someone had derived their own primitive channel from one of these classes, which seems unlikely. Then again, perhaps no-one cares either way. John A -- This message has been scanned for viruses and dangerous content by MailScanner<http://www.mailscanner.info/>, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Mar 25 07:53:31 2010
This archive was generated by hypermail 2.1.8 : Thu Mar 25 2010 - 07:53:33 PDT