Basically, what does this Synplify output mean:
#N: MT206 |Auto Constrain mode is enabled
#W: FX1039 :"c:\sftp_root\x002\tinyproc.v":61:3:61:8|User-specified initial value defined for instance tp.zf is being ignored.
#W: FX1039 :"c:\sftp_root\x002\tinyproc.v":61:3:61:8|User-specified initial value defined for instance tp.cf is being ignored.
#W: FX1039 :"c:\sftp_root\x002\tinyproc.v":61:3:61:8|User-specified initial value defined for instance tp.pc[7:0] is being ignored.
#W: FX1039 :"c:\sftp_root\x002\tinyproc.v":61:3:61:8|User-specified initial value defined for instance tp.intra[1:0] is being ignored.
#W: FX1039 :"c:\sftp_root\x002\tinyproc.v":61:3:61:8|User-specified initial value defined for instance tp.tv[15:0] is being ignored.
#W: FX1039 :"c:\sftp_root\x002\tinyproc.v":61:3:61:8|User-specified initial value defined for instance tp.port[3:0] is being ignored.
#W: FX1039 :"c:\sftp_root\x002\tinyproc.v":61:3:61:8|User-specified initial value defined for instance tp.instr[15:0] is being ignored.
Are initial register states not specifiable on FPGAs? I'm targeting iCE40 family (specifically, iCE40HX1K - the "icestick" platform).
This warning must mean that your target FPGA does not support initial values for registers. If you have a declaration like below, Synplify will ignore the initial value.
reg zf = 1'b0;
Synthesis will proceed as if the declaration is like the following.
reg zf;
The thing you can do is to initialize the registers by a reset signal. If you have already done that, you can ignore the warnings. Still, I would remove the initial values to avoid any potential mismatch between simulation and synthesis.
Related
I started working with CSS variables to try out making a modular sizing scale. But I quickly ran into problems where CSS values were ignored but I did not see any indication on what was wrong.
Let's see a minimal reproduction of the problem:
:root {
--ratio: 1.25;
--font-size-medium-heading: calc(var(--ratio) * 1rem);
--font-size-large-heading: calc(var(--font-medium-heading) * var(--ratio)); /* note the typo in the var */
}
h1 {
font-size: var(--font-size-large-heading);
}
I made a typo on purpose to see what will happen (I have left out -size from the variable name). Since my heading got mini I tried querying the value of my new CSS variable:
getComputedStyle(document.documentElement).getPropertyValue('--font-size-large-heading') === ''
It returned an empty string.
Let's head to Chrome's style inspector and see if I get the warning sign ⚠️:
MDN advises to use a CSS validator. So let's try out this: https://jigsaw.w3.org/css-validator/validator
My guess is that this validator is not really up-to-date (if anyone using it still).
Update
I understood that according to the spec it is a valid statement, but the computed-time value of it is invalid. I want to know about these as it is just hiding the true problem in a very frequent mistake (if you have ever spent a day on finding out that Angular expected a "'thing'" instead of "thing" in a template, you will understand how bad is having no output about invalid values).
Is there a way to get an error output about computed-time invalid CSS vars and calc values?
First the spec
If a property contains one or more var() functions, and those functions are syntactically valid, the entire property’s grammar must be assumed to be valid at parse time. It is only syntax-checked at computed-value time, after var() functions have been substituted.
This why you don't see the yellow triangle in chrome devtool, because syntax wise it's valid.
From the spec focus on the fourth rule
Otherwise, the property containing the var() function is invalid at computed-value time
Also
A declaration can be invalid at computed-value time if it contains a var() that references a custom property with the guaranteed-invalid value
The third line in your code contains a var() that references a css variable with the guaranteed-invalid value
Why?
The initial value of a custom property is a guaranteed-invalid value. As defined in § 3 Using Cascading Variables: the var() notation, using var() to substitute a custom property with this as its value makes the property referencing it invalid at computed-value time.
A none-existing css variables basically creates it and it's initial value is the guaranteed-invalid value.
What's that initial value compute to ?
This value serializes as the empty string, but actually writing an empty value into a custom property, like --foo: ;, is a valid (empty) value, not the guaranteed-invalid value. If, for whatever reason, one wants to manually reset a variable to the guaranteed-invalid value, using the keyword initial will do this.
This is why getComputedStyle(document.documentElement).getPropertyValue('--font-size-large-heading') returns an "empty string" (guaranteed-invalid value)
Somewhere I used
MPI_Comm_dup(row_comm, &bigger_row_comm);
and I noticed it caused 'fatal' error when row_comm was equal to MPI_COMM_NULL. I changed it with
if (row_comm != MPI_COMM_NULL)
MPI_Comm_dup(row_comm, &bigger_row_comm);
else
bigger_row_comm = MPI_COMM_NULL;
Now it works. I use MPICH and found this in its documentation in the entry for MPI_Comm_dup:
A common error is to use a null communicator in a call (not even allowed in MPI_Comm_rank).
I wonder if this behavior is standard and I should expect other implementations to do the same. Why haven't they just handled it like I did? One expects the duplicate of MPI_COMM_NULL to be a MPI_COMM_NULL.
The MPI standard does not specify what MPI_Comm_dup shall do when called with an null communicator (see section 6.4.2). Therefore, one cannot assume that such a call is allowed, especially since MPI_COMM_NULL is defined as "the value used for invalid communicator handles".
For what it's worth, OpenMPI 4.0.1 also treats the call as an error.
I found this in rtt-estimator.h the constructor sets the value for m_initialEstimatedRtt which I believe directly controls the Retransmit Timeout value.
I am not sure how to set the value for m_initialEstimatedRtt.
I see a method named SetCurrentEstimate that could be used to change that value but I am not sure at what stage in the simulation I should modify it if I use that so I prefer to control the initial.
Also I'm wondering what is the default value set in the examples and where can I find it?
There are many ways to set that variable, chiefly through the attribute system. The attriobute associated to that variable is ns3::RttEstimator::InitialEstimation from rtt-estimator.cc)
If you have followed the standard script layout, all you need is to use the following command-line argument:
--ns3::RttEstimator::InitialEstimation=1.0s
The tutorial gives a gentle introduction to the use of attributes through the command-line and environment variables:
http://www.nsnam.org/docs/release/3.19/tutorial/html/tweaking.html#using-command-line-arguments
There are more details there:
http://www.nsnam.org/docs/release/3.19/manual/html/attributes.html
You might find the ConfigStore useful too:
http://www.nsnam.org/docs/release/3.19/manual/html/attributes.html#configstore
I have a specification of a function that acts like a constructor. The specification of the function is
function Create_Controller return Type_Controller;
Also, in the specification file, I have the Type_Controller type, which is an access. I copy the relevant fragment:
type Type_Controller_Implementation;
type Type_Controller is access Type_Controller_Implementation;
So, this is what I've attempted:
function Create_Controller return Type_Controller
is
My_Controller : aliased Type_Controller_Implementation;
begin
return My_Controller'Access;
end Create_Controller;
I tried to compile the program without the aliased keyword, but then, the compiler says:
prefix of "Access" attribute must be aliased
So, I put the aliased keyword and the compiler now suggests that I should change the specification:
result must be general access type
add "all" to type "Controlador_De_Impresion" defined at controller.ads
The problem is that I'm not allowed to change the specification. I've read the chapter about access types in the Ada Programming Wikibook, but I still don't understand why my code doesn't work. What am I doing wrong?
The implementation of the Create_Controller function body is incorrect. Were it to work as coded, you'd be returning a pointer to a variable local to that function body's scope...which would be immediately lost upon returning from the function, leaving you with an invalid pointer.
No, an instance of the type needs to be allocated and returned. If there's no explicit initialization that needs to occur you can simply do:
return new Type_Controller_Implementation;
If there is some initialization/construction that has to occur, then:
function Create_Controller return Type_Controller
is
My_Controller : Type_Controller := new Type_Controller_Implementation;
begin
-- Set fields of My_Controller
...
return My_Controller;
end Create_Controller;
When you declare an access type as access T, you're saying that "this is a pointer to a T and it must point to objects of type T allocated from a pool". (That is, allocated with a new keyword.) When you declare an access type as access all T, you're saying that it can point either to a T allocated from a pool, or to an aliased variable of type T.
If the type is declared as access T and you can't change it, then all access values of the type have to point to something allocated with new. You can't make it point to a variable (even to a "global" variable that isn't located on the stack).
The reasons for this are historical, I think. The first version of Ada (Ada 83) only had "pool-specific types." You couldn't make an access value point to some other variable at all, without trickery. This meant that a compiler could implement access values as indexes into some storage block, or as some other value, instead of making them the actual address of an object. This could save space (an access value could be smaller than an address) or allow more flexibility in how pool memory was managed. Allowing access values to point directly to objects takes away some of that flexibility. I think that's why they decided to keep the old meaning, for backward compatibility, and require an all keyword to indicate the new kind of access.
I have a little problem I can't solve so far. In BPEL I want to create an onAlarm eventHandler which fires immediatly (i.e. the "for" element is set to 'PT0S') and repeats every 2 seconds. This eventHandler shall contain a counter which increments every time the alarm fires.
The question is: How to initialize the counter? If the variable will be initialized within the onAlarm scope the value would not increment anymore. In the "normal" control flow the value also cannot be initialized, because it is not defined if the process or the onAlarm scope runs first. So I would get every now and then an uninitializedVariable exception.
My solution would be to not initialize the variable neither in the process scope nor in the onAlarm scope, but create a faultHandler wherein the variable will be initialized and afterwards the onAlarm flow will be executed. Problem is every uninitializedVariable execution will be caught now by this faultHandler and there may be another too.
So is there another possibility to deal with this problem or can I somehow find out which variable wasn't initialized properly so the faultHandler can get two control flows?
The solution should work on every BPEL engine.
Thanks, Michael
You can initialize a variable with a default value on its definition using a from-spec just like in an assignment. See section 8.4.1 of the spec for the details.
A default initialization can look like this:
<variables>
<variable name="Default" type="xsd:int" >
<from>5</from>
</variable>
</variables>
This should work as eventHandlers are installed after the start activity of a process has completed. By then, the variables defined in the root scope have already been initialized. To quote the spec, section 12.1:
Scope initialization consists of instantiating and initializing the
scope's variables and partner links; ... If a scope contains an
initial start activity then the start activity MUST complete before
the event handlers are installed.
So much for spec. I think nobody can tell whether this "works on every BPEL engine". As far as I know, it works on bpel-g, Orchestra and EasyBPEL, but not on Apache ODE or OpenESB.