in UVM e Reference document is written:
You can call read_reg_field or write_reg_field for registers whose fields
are defined as single_field_access (see “vr_ad_port_unit Syntax and Examples”).
...
For example:
write_reg_fields tx_mode_reg {.resv = 4; .dest = 2};
But there is no example for using read_reg_field...
Could you please explain how should it be used?
(I've tried the next code, but it gives compilation error:
some_var = read_reg_field my_reg_file.my_reg {.my_reg_field} )
Thank you for your help.
As far as I know there is no read_reg_fieds macro. If you want to do a read to a register and then save the value of a certain field, do this:
read_reg my_reg;
value = my_reg.my_reg_field;
Normally, when you read register, you read them completely. Reading only individual fields makes sense if your bus protocol allows narrow transfers (i.e. your data width is 32 bits, but you can do 16 bit transfers on it). I haven't seen such a thing implemented in vr_ad (could be there and I just don't know of it), but UVM RAL (the SystemVerilog register package) supports it.
Long story short, if you just care about getting your data from your DUT, using read_reg is enough.
When the Design Under Test is implemented in verilog or vhdl - you can read the register as a whole, you cannot "read just some of its fields".
A register is at a specific address, reading this register -> read from this address.
The quote of the spec about fields access is when the DUT is a SystemC model.
Connecting to SC models is done using ports. If the model defines a port for each field - you can read a field.
Related
I want to write to the holding registers an actuator of mine has, but I've only recently started using pymodbus and I'm a little uncertain about some of its commands. As far as I've understand the primary write command looks like this:
write_register(address, value, **kwargs)
But I'm uncertain about how I "define" which kind of register I write too. Unlike other modbus libraries I've used, in pymodbus I can't define which kind of register I write too. As far as I understand of modbus there's coils, input registers and holding registers. I've read that you can't write to input registers, but how can I be certain I write to holding registers? If I write 1 in address in the write_register will that always be a holding register with that address?
Thank you in advance.
You need to know a little bit more about your actuator. Do you have a datasheet about it? If yes, you need to find a map registers where all the addresses are given for registers where the actuator's information are stored. Here an example where you can find this kind of registers map : SIMEAS Pxxx Com-Modbus Datasheet.
Be careful, sometimes you need to add or subtrace 1 to your register address because the guys who implement this did in this way. Read your datasheet carefully.
So if you need to write something in a particular register, you need the correct address of the register, the value you want to write in the correct format, and the client of the library ModbusClient.
You should have something like this :
client = ModbusClient(host='YOUR_IP_ADRESS', port=xxx)
client.connect()
client.write_register(REGISTER_ADRESS, PAYLOAD, UNIT)
Hope this will help a little. You can also go further by reading the Pymodbus documentation.
In the documentation it is indicated, that cardinality() function is deprecated and should no longer be used. However, it is still used in the libraries such as ThermoSysPro.
e.g.
if (cardinality(C) == 0) then
some code
end if;
where C is FluidInlet or FluidOutlet
Could anyone give a simple example of how it could be replaced?
The usual solution is to make the connector conditional, and if enabled you require that it is connected.
For physical connectors you can see how heatports and support is handled in:
Modelica.Electrical.Analog.Interfaces.ConditionalHeatPort
Modelica.Mechanics.Rotational.Interfaces.PartialElementaryOneFlangeAndSupport2
For control signals you can see how p_in, h_in etc are handled in
Modelica.Fluid.Sources.Boundary_pT
Modelica.Fluid.Sources.Boundary_ph
However, the connectors of ThermoSysPro belong in neither of those categories and that should ideally also be cleaned up.
The only thing I know, that could be used in this regard, is the connectorSizing annotation. It is described in the MLS chapter 18.7.
It is used a number of times in the Modelica Standard Library, e.g. in Modelica.Blocks.Math.MinMax via the parameter nu. When using it, the tool automatically sets the modifier for nu according to the number of connections to it.
parameter Integer nu(min=0) = 0 "Number of input connections"
annotation (Dialog(connectorSizing=true));
Modelica.Blocks.Interfaces.RealVectorInput u[nu];
In the example below, nu=2 is generated by Dymola automatically when creating a connection in the graphical layer. I have removed the graphical annotations, to make the code more readable.
model ExCS
Modelica.Blocks.Math.MinMax minMax(nu=2);
Modelica.Blocks.Sources.Sine sine(freqHz=6.28);
Modelica.Blocks.Sources.Constant const(k=0.5);
equation
connect(sine.y, minMax.u[1]);
connect(const.y, minMax.u[2]);
end ExCS;
The cardinality() operator is used in Modelica.Fluid.Sources.BaseClasses.PartialSource, and in a similar way in other fluid libraries (IBSPA, AixLib, Buildings, BuildingSystems and IDEAS), in the form
// Only one connection allowed to a port to avoid unwanted ideal mixing
for i in 1:nPorts loop
assert(cardinality(ports[i]) <= 1,"
each ports[i] of boundary shall at most be connected to one component.
If two or more connections are present, ideal mixing takes
place with these connections, which is usually not the intention
of the modeller. Increase nPorts to add an additional port.
");
end for;
I occasionally had models from users who somehow ended up with more than one connection to a ports[i]. How this happened was not clear, but I find the use of cardinality() useful to catch such situations, which otherwise can yield to mixing in the fluid port which the user did not intent and which are hard to detect.
Suppose that I have a program that takes a pointer as its input. Without prior knowledge about the structure of the pointee, how does a fuzzer create valid inputs that can actually hits the internal of the program? To make this more concrete, imagine an artificial C program
int myprogram (unknow_pointer* input){
printf("%s", input->name);
}
In some situations, the tested program first checks the input format. If the input format is not good, it raises an exception. In such situations, how can a fuzzer reach program points beyond that exception-raising statement?
Most fuzzers don't know anything about the internal structure of the program. Different fuzzers dealt with this in a various ways:
Not deal with it at all. Just throw random inputs and hope to produce an input that will pass some/all checks. (for example - radamasa)
Mutate a valid input - take a known valid input, and mutate it (flip bits, remove parts, add parts, etc.) in many cases it will be valid enough to pass some or all of the checks. For example - if you want to fuzz VLC, you will take a valid movie file as the input for the fuzzer, which will provide mutations of it to VLC. Those are often called mutation based fuzzers. (for example - zzuf)
If you have prior knowledge of the input's structure, build a model of the input, and then mutate specific fields within it. A big advantage of such method is the ability to deal with very specific types of fields - checksums, hashes, sizes, etc. Those are often called generation based fuzzers. (for example - spike, sulley and their successors, peach)
However, in recent years a new kind of fuzzers was evolved - feedback based fuzzers - these fuzzers perform mutations on a valid (or not) input, and based on feedback they receive from the fuzzed program they decide how and what to mutate next. The feedback is received by instrumenting the program execution, either by injection tracing in compile time, injecting the tracing code by patching the program in runtime, or using hardware tracing mechanisms. First among them is AFL (you can read more about it here).
A fuzzer throws every sort of random combination of inputs at the attack surface. The intention is to look for any opportunity for a "golden BB" to get past the input checks and get a response that can be further explored.
I was wondering,
Is there anyway to force writing on a 'Read-Only' Modbus Register?
Does defining a Register as a 'Read-Only' is secure enough or can be bypassed??
Thanks for the answers!
The correct way to define a "read-only" analog variable in Modbus is to map it as an input register. There is no function code defined in Modbus to write to an input register.
For historical reasons, several vendors maps all their variables as holding registers, which are theoretically read/write, i.e, there's a Write Multiple Registers function. Whenever they map a read only variable as a holding register, they must assert that the write functions fail. However, there's no standard exception code for this, as a holding register should be read/write. This is only one of Modbus' idiosyncrasies.
Getting back to your question, if you map your variable as an input register, you can be sure that the protocol will not allow a master to write to it. If, for interoperability issues you map it as a holding register, the protocol will allow the master to use a write funcion to change its value, and it is up to you to block in your device implementation.
OK, I've been struggling with this for a while. What is the best way to accomplish the following:
where Reaction Wheel 1-4 are links to the same block in a library. When the Speed Counter, Speed Direction and Current signals are added to the final bus output as shown, MATLAB (rightfully) complains:
Warning: Signals 9, 10, 11, 12 entering Bus Creator
'myAwesomeModel' have duplicated names 'Current'. These are being made unique
by appending "(signal #)" to the signals within the resulting bus. Please
update the labels of the signals such that they are all unique.
Until now I've been using a "solution" like this:
that is, place a size-1-mux/gain-of-1/other-dummy block in the middle, so the signals can be renamed into something unique. However, I really like to believe that The MathWorks has thought of a better way to do this...
What is the "proper" way to construct bus signals like this? It feels rather like I'm being pushed to adopt a particular design/architecture, but what that is precisely, eludes me for the moment...
It was quite a challenge for me but looks like I kinda sorted it out. Matlab R2007a here. I'll do the example with an already done subsystem, with its inputs, outputs, ...
1- In Block Properties, add a tag to the block. This will be done to identify the block and its "siblings" among the system. MY_SUBSYSTEM for this example.
2- Block Properties again. Add the following snippet in CopyFcn callback:
%Find total amount of copies of the block in system
len = length(find_system(gcs,'Tag','MY_SUBSYSTEM'));
%Get handle of the block copied/added and name the desired signal accordingly
v = get_param(gcb,'PortHandles');
set(v.Outport(_INDEX_OF_PORT_TO_BE_RENAMED_),'SignalNameFromLabel',['BASENAME_HERE' num2str(len)]);
3- In _INDEX_OF_PORT_TO_BE_RENAMED_ you should put the port signal index (starting from 1) that you want to have renamed for each copy of the block. For a single output block this should be 1. BASENAME_HERE should be the port basename, in this case "Current" for you.
4- Add the block to the desired library, and delete the instance you used to create this example. From there on, as you add from the library or copy an existing block, the outport should name Current1, Current2, Current3, and so on. Notice that you could apply any convention or formatting.
Hope this helps. It worked for me, don't hesitate to ask/criticize!
Note: Obviously, as the model grows, this method may be computer-demanding as find_system will have to loop through the entire model, however looks like a good workaround for me in small-medium sized systems.
Connect a Bus Selector to each Data Output. Select the signals you want and set "Output as bus". Then connect all Bus Selectors to a Bus Creator.
simulink model