I want to write some e code that is conditioned by the used specman architecture (64/32 bit).
What i need will look like:
if (specman 64 bit) {
do something
} else {
do something else
};
One can do so, by using the predefinef SN_64_BIT define.
I.e , one can condition the appearance of code by this define, for example:
<'
extend sys {
run() is also{
#ifdef SN_64_BIT then
{ out("64 bit"); }
#else
{ out("32 bit "); }
};
};
'>
Related
When re-generating a particular structure is there an easy way to make it not generate a previous value until all possible values satisfying the constraints have been generated?
For example, when (re)generating:
Start as:
specman -c 'define TRIES 16; load x;run;'
<'
struct x {
data[2] : list of uint(bits:2);
};
extend sys {
fu : x;
run() is also {
for i from 1 to TRIES do {
gen fu;
print fu.data;
};
};
};
'>
There are a possible 4*4 = 16 combinations of data and the question is about being able to gen 16 times and get 16 different values.
Thanks.
all_different() can help here. It's a bit tricky, because the field is a list. So this can be done using an auxiliary field. For example:
struct x {
data[2] : list of uint(bits:2);
data_as_one : uint(bits:4);
keep data[0] == data_as_one[1:0];
keep data[1] == data_as_one[3:2];
};
extend sys {
fu : x;
fus[TRIES] : list of x;
keep fus.all_different(.data_as_one);
run() is also {
for each in fus {
out(it.data);
};
};
};
I am considering port of a complex code from boost::python to pybind11, but I am puzzled by the absence of something like boost::python::extract<...>().check(). I read pybind11::cast<T> can be used to extract c++ object from a py::object, but the only way to check if the cast is possible is by calling it and catching the exception when the cast fails. Is there something I am overlooking?
isinstance will do the job (doc) :
namespace py = pybind11;
py::object obj = ...
if (py::isinstance<py::array_t<double>>(obj))
{
....
}
else if (py::isinstance<py::str>(obj))
{
std::string val = obj.cast<std::string>();
std::cout << val << std::endl;
}
else if (py::isinstance<py::list>(obj))
{
...
}
What do --modules inline and --modules register options do?
https://github.com/google/traceur-compiler/wiki/Options-for-Compiling.
Using 2ality.com's lib.js example module:
//------ lib.js ------
export const sqrt = Math.sqrt;
export function square(x) {
return x * x;
}
export function diag(x, y) {
return sqrt(square(x) + square(y));
}
//------ main.js ------
import { square, diag } from 'lib';
console.log(square(11)); // 121
console.log(diag(4, 3)); // 5
inline wraps the module in an anonymous function, assigned to an auto-generated variable by the looks, it would be interesting to know what this is all about, the technique can be used to bundle modules without actually using a module system, but the var assigned the object returned would have to be known:
var $__src_47_lib_46_js__ = (function() {
"use strict";
var __moduleName = "src/lib.js";
var sqrt = Math.sqrt;
function square(x) {
return x * x;
}
function diag(x, y) {
return sqrt(square(x) + square(y));
}
return {
get sqrt() {
return sqrt;
},
get square() {
return square;
},
get diag() {
return diag;
}
};
})();
//# sourceMappingURL=lib.js.map
System.register is a draft module format:
System.registerModule("src/lib.js", [], function() {
"use strict";
var __moduleName = "src/lib.js";
var sqrt = Math.sqrt;
function square(x) {
return x * x;
}
function diag(x, y) {
return sqrt(square(x) + square(y));
}
return {
get sqrt() {
return sqrt;
},
get square() {
return square;
},
get diag() {
return diag;
}
};
});
System.get("src/lib.js" + '');
//# sourceMappingURL=lib.js.map
Once the module has been registered, then the System.module( ... ) can be called to load the module. Currently I know traceur (though not the runtime) has the System object polyfilled, presumably also babel.
The System.register format has some useful advantages I would suggest, more than one module can be included in a file which suits a collection of smaller closely coupled modules (typically classes); there is no need to buy in to another module system, e.g., including vanilla JS (test data, shims attached to the global object, etc.) in a node module requires additional boilerplate code adding overhead to the workflow, etc.
The System object though is technology still in development (not included the current draft standard).
Is there a way that a virtual sequence can directly call a vr_ad write_reg or read_reg macro without me having to create a vr_ad_sequence that does the same thing?
To illustrate more clearly, here is my current implementation:
<'
extend vr_ad_sequence_kind : [WR_DMA_POLL];
extend WR_DMA_POLL vr_ad_sequence {
!dma_poll : DMA_POLL vr_ad_reg;
body() #driver.clock is only {
write_reg dma_poll val 0xdeadbeef;
};
};
extend MAIN soc_tb_virtual_sequence {
!write_dma_poll : WR_DMA_POLL vr_ad_sequence;
body() #driver.clock is only {
message(LOW, "TEST START");
do write_dma_poll on driver.reg_driver;
};
};
'>
Why can't it be, or is it possible to implement this way?
extend MAIN soc_tb_virtual_sequence {
!dma_poll : DMA_POLL vr_ad_reg;
body() #driver.clock is only {
message(LOW, "TEST START");
write_reg {.dest_driver == driver.reg_driver} dma_poll;
read_reg {.dest_driver == driver.reg_driver} dma_poll;
};
};
Thank you in advance for any explanation.
This is possible starting with vr_ad 13.20 (or maybe slightly older). You almost had it in your question. The correct syntax is:
extend MAIN soc_tb_virtual_sequence {
!dma_poll : DMA_POLL vr_ad_reg;
body() #driver.clock is only {
message(LOW, "TEST START");
write_reg {.driver == driver.reg_driver} dma_poll;
read_reg {.driver == driver.reg_driver} dma_poll;
};
};
The first set of {...} delimits the operation generate block, where you can constrain how to access the register. These constraints will be passed to the vr_ad_operation that gets generated as part of the access.
Hy,
I expanding an existing specman test where some code like this appears:
struct dataset {
!register : int (bits:16);
... other members
}
...
data : list of dataset;
foo : dataset;
gen foo;
foo.register = 0xfe;
... assign other foo members ...
data.push(foo.copy());
is there a way to assign to the members of the struct in one line? like:
foo = { 0xff, ... };
I currently can't think of a direct way of setting all members as you want, but there is a way to initialize variables (I'm not sure if it works on struct members as well). Anyway something like the following may fit for you:
myfunc() is {
var foo : dataset = new dataset with {
.register = 0xff;
.bar = 0xfa;
}
data.push(foo.copy());
}
You can find more information about new with help new struct from the specman prompt.
Hope it helps!
the simple beuty of assigning fields by name is one language feature i've always found usefull , safe to code and readable.
this is how i'd go about it:
struct s {
a : int;
b : string;
c : bit;
};
extend sys {
ex() is {
var s := new s with {.a = 0x0; .b = "zero"; .c = 0;};
};
run() is also {
var s;
gen s keeping {.a == 0x0; .b == "zero"; .c == 0;};
};
};
i even do data.push(new dataset with {.reg = 0xff; bar = 0x0;}); but you may raise the readablity flag if you want.
warning: using unpack() is perfectly correct (see ross's answer), however error prone IMO. i recommend to verify (with code that actually runs) every place you opt to use unpack().
You can directly use the pack and unpack facility of Specman with "physical fields" ( those instance members prefixed with the modifier %).
Example:
define FLOODLES_WIDTH 47;
type floodles_t : uint(bits:FLOODLES_WIDTH);
define FLABNICKERS_WIDTH 28;
type flabnickers_t : uint(bits:FLABNICKERS_WIDTH);
struct foo_s {
%!floodle : floodles_t;
%!flabnicker : flabnickers_t;
};
extend sys {
run() is also {
var f : foo_s = new;
unpack(packing.low,64'hdeadbeefdeadbeef,f);
print f;
unpack(packing.low,64'hacedacedacedaced,f);
print f;
};
setup() is also {
set_config(print,radix,hex);
};
};
When this run, it prints:
Loading /nfs/pdx/home/rbroger1/tmp.e ...
read...parse...update...patch...h code...code...clean...
Doing setup ...
Generating the test using seed 1...
Starting the test ...
Running the test ...
f = foo_s-#0: foo_s of unit: sys
---------------------------------------------- #tmp
0 !%floodle: 0x3eefdeadbeef
1 !%flabnicker: 0x001bd5b
f = foo_s-#0: foo_s of unit: sys
---------------------------------------------- #tmp
0 !%floodle: 0x2cedacedaced
1 !%flabnicker: 0x00159db
Look up packing, unpacking, physical fields, packing.low, packing.high in your Specman docs.
You can still use physical fields even if the struct doesn't map to the DUT. If your struct is already using physical fields for some other purpose then you'll need to pursue some sort of set* method for that struct.