Jump to content

sc_uint and unsigned int


Recommended Posts

First, let me say that I would never use sc_signal<unsigned int>. Instead use sc_signal<std::uint32_t> for portability reasons.

There are two considerations:

  1. sc_signal<uint32_t> is likely to be significantly faster than sc_signal<sc_uint<32>>. Especially if using the PoC implementation.
  2. sc_signal<sc_uint<32>> may be required by some synthesis tools if that is something you care about.

If you want to be agnostic to both situations, you could set up a typedef header for your project and use your own names.

Link to comment
Share on other sites

  • 3 years later...

Say for instance, I have a 256-bit data path,

Would it also be valid if I define a struct of uint64t's?



struct bus_width_t {
	uint64_t d1;
	uint64_t d2;
	uint64_t d3;
	uint64_t d4;


sc_signal<bus_width_t> data_path_;



Link to comment
Share on other sites

I agree with @andy for dealing with sc_signal or sc sc_fifo. If using TLM, you would use a tlm_generic_payload with a pointer to your data, an appropriate data length and a socket width of 256. The data for that case would be arranged in its natural order. It really depends on what the model is doing with the data. If you don’t need to do arithmetic with the 256 bits, you might be better off using sc_bv<256> instead, which still supports logic operations. sc_lv<256> would be useful if modeling a tristate bus with sc_signal_resolved. 

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.

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...