Open AnthonyVH opened 6 years ago
The main issue here is that ir/Constant
uses uint64_t
internally. Switching to boost::multiprecision::cpp_int
should be enough and can be done with reasonable effort. The downside is that things get a bit slower when you do not use types > 64-bit. I will try this in my next free slot.
That sounds very promising! This, the RAII, and the vector randomization issues are the only thing holding me back from proposing the use of CRAVE into all our future SysC testbench infrastructure, so I'm loving the quick responses to the issues I opened here :+1:.
I have added basic support for this in the branch experimental_bigint
, you need to use the experimental API though. There is also a new example https://github.com/hoangmle/crave-examples/blob/experimental_bigint/experimental_api/ex12_bigint/main.cpp
Can you try it out to see whether it suits your need and what is still missing? Thanks!
Awesome! I've been a bit swamped by other things, but as soon as I find this for this again I'll take a look at it (and put together a PR for issue #5).
Creating an e.g.
crave::randv<sc_dt::sc_bv<128>>
object works fine. However, whennext()
is called on this object, only bits 0-63 will be set, the remaining ones will all be zero. This is hardcoded in SystemC.hpp'snext
function, where anstd::int64
generator is used.I'm not sure how difficult it would be to fix this. Extending the random number generation to generate enough random bits seems doable. Modifying generated constraints to be correct seems like a more difficult task.
Alternatively, construction of such objects could be prevented with some SFINAE, e.g.: