Jump to content

Why SC_MANY_WRITERS is not default SC_DEFAULT_WRITER_POLICY?


Roman Popov

Recommended Posts

Hello,

Why SC_MANY_WRITERS is not default SC_DEFAULT_WRITER_POLICY in SystemC? In my opinion SC_ONE_WRITER does more harm then profit.  Sooner or later every user faces the fact that he will need to change this default during the SystemC compilation. So why not to change it out-of-the-box?

Link to comment
Share on other sites

Because this detects early common errors when describing the behavior of digital circuits, which would be fatal if they get implemented through logic synthesis. If two gates (represented by different processes, i.e., SC_THREAD or SC_METHOD) drive the same signal line, the resulting behavior in hardware is hard to predict and depends heavily from the used technology. Correct logic levels on the signal line are not anymore guaranteed and high currents flowing constantly through the same wires from VDD to GND can damage the IC. If different gates shall drive the same line (common to model signal busses), they need to have tristate outputs and the logic has to guarantee that driving the line is mutually exclusive.

If we come to writing test benches, activating SC_MANY_WRITERS in certain selected cases may be necessary to, e.g., easily inject faults inside the DUT. So, IMHO, the default of SystemC is sane and protects the user.

Link to comment
Share on other sites

14 minutes ago, maehne said:

Because this detects early common errors when describing the behavior of digital circuits, which would be fatal if they get implemented through logic synthesis. If two gates (represented by different processes, i.e., SC_THREAD or SC_METHOD) drive the same signal line, the resulting behavior in hardware is hard to predict and depends heavily from the used technology. Correct logic levels on the signal line are not anymore guaranteed and high currents flowing constantly through the same wires from VDD to GND can damage the IC. If different gates shall drive the same line (common to model signal busses), they need to have tristate outputs and the logic has to guarantee that driving the line is mutually exclusive.

I have used two SystemC HLS synthesis tools in practice:

  1. First one had  SC_MANY_WRITERS as default. So every sc_signal<T> is in fact sc_signal<T,SC_MANY_WRITERS> in this tool
  2. Second tool allows synthesis of sc_signal<T,SC_MANY_WRITERS>

SC_MANY_WRITERS is safe for synthesis and have a clearly defined representation in multiple SC_CTHREAD drivers case: a register with a multiplexer.  Unlike SC_UNCHECKED_WRITERS, when two SC_CTHREADS write to signal in same delta cycle error will be detected and reported.

I agree that two SC_METHODs driving same sc_signal has no clear HW representation.

If we come to writing test benches, activating SC_MANY_WRITERS in certain selected cases may be necessary to, e.g., easily inject faults inside the DUT. So, IMHO, the default of SystemC is sane and protects the user.

 

Test-benches are main reason why I think it should be SC_MANY_WRITERS by default.  In testbenches sc_spawn dynamic processes are commonly used to model complex test scenarios. As soon as dynamic thread touches sc_signal your simulation immediately fails. 

So you have two options:

  • Manually replace all top-level DUT pins to sc_signal<T, SC_MANY_WRITERS>
  • Compile with  SC_MANY_WRITERS by default.

Most likely users will chose second path. So why not making it as default?

Verilog/SystemVerilog has "SC_MANY_WRITERS" by default and I don't hear any complains about it (multiple drivers are detected by synthesis tools, but is ok for SV testbenches).  Verilog authors in theory can make "SC_ONE_WRITER" behavior a default and offer some keyword to override it. But no one asks for it.

So in my view common industry knowledge is that SC_MANY_WRITERS by default is ok. Because there are so many practical cases when you need it.

 

 

Link to comment
Share on other sites

Two things are to be noted here:

  • IEEE 1666-2011 added support for writer policies, IEEE 1666-2005 required to have conflict detection. So keeping the default behavior was a natural choice back then
  • SC_DEFAULT_WRITER_POLICY is not part of the IEEE Std. 1666-2011, but an extension in the proof-of-concept implementation

Last but not least, you can always use your own signal template alias:

template<typename T>
using sc_signal_mw = sc_core::sc_signal<T, sc_core::SC_MANY_WRITERS>

Hope that helps,
 Philipp

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...