sc_uint and unsigned int

[DS1701]

Dear all,

Can you explain the difference between ?

sc_signal<unsigned int > port1;

and

sc_signal<sc_uint<32> > port2;

When to use port1 and port2?

[Eyck]

unsigned int has always the length defined by the underlying platform while sc_uint<> lets you specify the exact bit with of the type. In your case case I would use 'unsigned int' as it is faster and has less overhead.

Best regards

[David Black]

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.

[DS1701]

Thanks. 

[Fides]

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

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

 

E.g.

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

Then

sc_signal<bus_width_t> data_path_;

 

Thanks.

[Andy Goodrich]

Yes, but you need to manage things based on those 4 64 bit values. The standard was of handling this would be to use

 

sc_signal<sc_biguint<256> >

 

[David Black]

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.