Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation on 06/15/2017 in all areas

  1. 1 point
    NOTE: Edited to update closing date for the Public Review Period On behalf of the Portable Stimulus Working Group (PSWG), welcome to the public review forum for the Portable Stimulus Early Adopter Draft Specification. The Public Review Period for this version of the Portable Stimulus Specification will close on Friday, September 15Monday, October 30, 2017. Members of the PSWG will be actively monitoring this forum to respond with answers, clarification questions or other general feedback to your comments. We will also let you know when a specific issue has been entered into our Mantis issue-tracking database. To facilitate us tracking your issue, please be sure to include the following information when posting: Descriptive title Page number (please use PDF page #) Section number Line number (listed on the side of the page) Detailed description of the issue This will enable us to locate your issue and facilitate the discussion. We thank you for your contribution to the success of this important new standard. The Early Adopter specification provides a comprehensive explanation of the new Portable Stimulus Domain Specific language and equivalent C++ Class Library. This declarative language is designed for abstract behavioral description using actions; their inputs, outputs and resource dependencies; and their composition into use cases including data and control flows. These use cases capture test intent that can be analyzed to produce a wide range of possible legal scenarios for multiple execution platforms (e.g., virtual platforms, simulation, emulation, prototypes, silicon, etc.). The Early Adopter specification also includes a preliminary mechanism to capture the programmer’s view of a peripheral device, independent of the underlying platform, further enhancing portability.
  2. 1 point
    No, multiple inheritance is not supported in this case Here is quote from IEEE 1666-2011 So you have two options: Use composition instead of inheritance : in SystemC case this means you need to instantiate modules and bind their ports In some cases you can put some sc_objects in pure C++ classes (not sc_modules). This technique is commonly used for "port bundles". For example: struct clock_reset_if { sc_in_clk clk{"clk"}; sc_in<bool> rstn{"rstn"}; } struct some_module: sc_module, clock_reset_if { // ... } Unfortunately this approach does not work with SC_METHOD/SC_THREAD macros. But I think it should work with sc_spawn.
×
×
  • Create New...