Can we use two wait statements in a single process in VHDL? - vhdl

I have to create a delay of say 20 ms in a process waiting in an input button.
I wrote the following code and it gives an error
wait until clk'EVENT and clk='1';
wait for 20 ms;
Or, can I use a construct like:
wait for 20 ms until clk'EVENT and clk='1';
Any help is highly appreciated.

You can wait for an event, for time, or for both (or neither--but that is a unique case).
Now, I'm not quite sure why your first example gives an error since it is a valid sequential statement. But you have not provided a complete example nor the error code. So, my answer here will be pretty basic.
First, a wait statement can only occur as a sequential statement, essentially meaning only in a process (or called from a process). So, if you are trying to use it concurrently, it is a problem.
Now, if you are using it from a process, it must be in a process without a sensitivity list. That is, the following is illegal:
process(clk)
begin
wait until clk'EVENT and clk='1';
end process;
It must be a bare process, such as:
process
begin
wait until clk'EVENT and clk='1';
end process;
A bit more on your first example (properly placed in a sequential context and does compile):
process
begin
wait until clk'EVENT and clk='1';
wait for 20 ms;
end process;
This code waits for a rising edge on clk, and then waits for 20ms. These are sequentially executed (hence the sequential context in a process).
Your second statement needs to be tweaked to compile. Generally, a wait statement has the form wait until <event> for <time>, where both event and time are optional. For example:
process
begin
wait; -- No event, no time. Wait forever.
wait until clk'event and clk='1'; -- Wait forever for a rising edge on 'clk'
wait for 20 ms; -- Wait for 20 ms
wait until clk'event and clk='1' for 20 ms; --Wait for up to 20 ms for a rising edge on 'clk'
end process;
So, your second example has the order backward for event and time.
Finally, your introductory text indicates you are waiting for 20ms for a push button. This hints that you are trying to create real logic. The wait statement is synthesizable only in very limited use cases. And one of the cases specifically excluded is waiting for a period of time. If you need to wait for 20 ms, you'll need to do it some other way (such as counting clocks). And if you are trying to wait up to 20 ms for the button, it'll have to be a combination of detecting the change on the pushbutton and counting clocks.

Related

SystemVerilog Assertion does not fail when it should

I have a simple assertion as follows:
$rose(req) |=> !req[*1:10] until ack ##1 !ack;
As I understand, on detection of $rose(req), the assertion should check for !req to be low consecutively for max 10 clocks OR -until- ack arrives (ack=1). Once ack is true, it should de-assert the very next clock.
My test starts with $rose(req); then keep !req asserted for a few clocks (less than 10) and then drives ack=1. Then, I keep ack=1 for 4 clocks. It does not go low the very next clock, as the assertion requires. Still, the assertion does not fail. The thread "!req[*1:10] until ack" seems to keep firing, even after ack has arrived and the 'until' condition is satisfied.
Any ideas why the assertion does not fail?
Here's the EDA playground link that simulates the scenario.
EXAMPLE
You assertion is totally valid!
You are giving no information about ack signal during the !req[*1:10] phase.
The simulator finds a sequence where req=0 for some clock cycles (max 10), then find ack=1 followed by ack=0;
What you want can be obtained with:
$rose(req) |=> (!ack throughout !req[*1:10]) ##1 ack ##1 !ack;
I would not use until ack here, just ##1 ack
G.C.'s solution works.
I found another solution as well.
#(posedge clk) $rose(req) |=> first_match(!req[*1:10] ##1 ack) ##1 !ack;

Wait-Notify for parallel & sequential processing in Nifi

I have a requirement where I need to execute 4 jobs parallel and when same items job is done in all 4 processors parallely then trigger the next processor for this I have used wait-notify
Flow is like
4 parallel jobs -> notify (release signal identifier = ${itemid}, signal counter name = ${processorname}) -> wait (release signal identifier = ${itemid}, target signal count = 4) and wait relationship is connected to the same wait processor-> next processor
This works for first time but I have noticed that wait queue is not cleared even after the target signal count condition is met and i guess that is the problem it is not working for subsequent flows.
It should clear the waiting queue once the criteria is met right?

Pause between hazelcast EntryProcessor process method calls

I faced behaviour of EntryProcessor that seemed a bit strange for me.
First of all what I was doing.
My task is to use EntryProcessor to fill cache B from data of another cache A.
Cache A could contain from 100K to 1M entries. So I had no choice but loop through it create B cache key from A data entry and run EntryProcessor on such key to create entry of B cache.
I found when I run such loop and build B cache from A and call EntryProcessor many times (number equals to number of entries in cache A) overall duration changes from time to time.
So I've started to write log in every step of procedure. Sometimes entry processor run with a pause between execution on several entries, see log
16:47:17.773 ce23b7a [thread-7] AppendingProcessor process process; enter
16:47:17.773 7d9a120 [thread-7] AppendingProcessor process process; exit
Pause between two threads (invocation on different keys) is about 10ms (which could give us 100s on 100k keys!)
16:47:17.782 ce23b7a [thread-0] AppendingProcessor process process; enter
16:47:17.782 7d9a120 [thread-0] AppendingProcessor process process; exit
Sometimes we could see another behaviour, without any pause or with very small pause between execution on different entries.
14:38:42.685 ce23b7a [thread-0] AppendingProcessor process - process; enter
14:38:42.685 7d9a120 [thread-0] AppendingProcessor process - process; exit
14:38:42.686 ce23b7a [thread-1] AppendingProcessor process - process; enter
14:38:42.686 7d9a120 [thread-1] AppendingProcessor process - process; exit
14:38:42.686 ce23b7a [thread-6] AppendingProcessor process - process; enter
14:38:42.686 7d9a120 [thread-6] AppendingProcessor process - process; exit
I thought it could be related to partitioning, so it could be related how much partitions I have and whether entryprocessor works with entries from same partition or not, but now I don't think that's the case.
Sometimes when I run the code it works on many entries with no pause, then pause (typically 10ms), then again work with no pause at all
2016-10-25 18:23:34.486 [thread-2] AppendingProcessor - process.exit; partId = 114
....
about 500 entries processed in 1 ms
...
2016-10-25 18:23:34.486 [thread-3] AppendingProcessor - process.exit; partId = 115
....
about 250 entries processed in 1 ms
...
2016-10-25 18:23:34.487 [thread-3] AppendingProcessor - process.exit; partId = 115
My question is what could be the cause of the pause between processing entries in EntryProcessor, especially if pause occurs between each two calls of process method.
Cause such 10 ms pauses don't seem right, what could be the case?
I can't provide real example of code due to NDA but I write an example of the code, see AddressMapBean#process method
and appropriate AddressBookProcessor entry processor.
Any help would be appreciated!
Do you read from A and put into B inside the processor? If so this has a risk of deadlock. See:
https://groups.google.com/forum/#!topic/hazelcast/27_6iS4oaSY
also see:
https://github.com/hazelcast/hazelcast/issues/3146
Another (maybe) possible cause can be thread contention. From documentation:
NOTE: Entry Processors run via Operation Threads that are dedicated to
specific partitions. Therefore, with long running Entry Processor
executions, other partition operations such as map.put(key) cannot be
processed. With this in mind, it is good practice to make your Entry
Processor executions as quick as possible.

VHDL: Help understanding time steps/states and concurrency

I'm normally a C#/Java programmer and I'm still having trouble fully wrapping my head around hardware description.
I have a register that loads in a value. Afterwards, a comparator compares the output of the register with the value '16'. If the value is less than or equal, I go to State_0, if it's greater than, I go to State_3.
I have a 'controlsignals' process running concurrently to my statetable process. For my control signals, I know that I have to set the enable for the register to high when I'm in State_2, so:
controlsignals: PROCESS (Tstep_Q)
BEGIN
.... initialisation ...
CASE Tstep_Q IS
.... other states ....
WHEN T2 => --define signals in time step T2
enRegister = '1';
For my state table:
statetable: PROCESS (Tstep_Q, regOutput)
BEGIN
CASE Tstep_Q IS
.... other states ....
WHEN T2 =>
IF ((regOutput - 16) > 0)
THEN Tstep_D <= T3;
ELSE Tstep_D <= T0;
END IF;
And near the end of my code I have:
fsmflipflops: PROCESS (Clock)
BEGIN
IF Clock'EVENT AND Clock = '1' THEN
Tstep_Q <= Tstep_D;
END IF;
END PROCESS;
reg: regn PORT MAP (somevalue, enReg, Clock, regOutput);
Since my state table and my control signals are concurrent blocks, my confusion is... will I first enable the register and then run the comparator to determine my next state, like I want my circuit to run (since the statetable is sensitive to regOutput)? Or would it be safer to create a new state after T2 where I have my comparator? Thank you in advance.
Concurrency of the comparator
Imagine that right after the clock edge, the state signal has been updated. You've got one clock period to do a comparison and set the next state.
Your 'statetable' is being evaluated at all times.
Timing of enRegister
Doing the comparison in T2 only makes sense if you can read the output of the register in the same clock cycle as you are setting the enable. This may be a problem, but your question does not contain the information to check that.
Sensitivity list of statetable
You want this process to run concurrently, so all its inputs need to go in the sensitivity list.
It looks like you are working from a decent reference and structuring your code well. I suspect that the sensitivity list is really the problem you are having - causing odd behaviour in simulation, so I'll keep this answer short and let you try to fix that.

setrlimit in Ruby

I am trying to limit the execution time of a ruby process using the following code:
trap("XCPU") do
abort "Max Time exceeded"
end
Process.setrlimit(:CPU, 5)
loop do
end
The process does end but the trap code does not run (I just get 'killed' on the command line). However when I set the hard limit to a value greater than 5 the trap code runs
trap("XCPU") do
abort "Max Time exceeded"
end
Process.setrlimit(:CPU, 5, 6)
loop do
end
Why is the first code not working?
The XCPU signal (SIGXCPU) is only sent upon a soft limit. When the hard limit is reached, a KILL signal (SIGKILL) is sent instead. KILL signals cause the program to terminate immediately, and cannot be caught.
Taken from here:
The XCPU signal is sent to a process when it has used up the CPU for a
duration that exceeds a certain predetermined user-settable value. The
arrival of an XCPU signal provides the receiving process a chance to
quickly save any intermediate results and to exit gracefully, before
it is terminated by the operating system using the SIGKILL signal.
The KILL signal is sent to a process to cause it to terminate
immediately. In contrast to SIGTERM and SIGINT, this signal cannot be
caught or ignored, and the receiving process cannot perform any
clean-up upon receiving this signal.
By calling Process.setrlimit without a second parameter, the hard limit defaults to being equal to the soft limit. As such, at least on your operating system, it seems the SIGKILL is being sent before a SIGXCPU can be handled by your trap block.
Here is a quick demo to show why the second approach always works:
t = Time.now
trap("XCPU") do
abort "Max Time exceeded. Total running time: #{(Time.now - t).round} seconds"
end
Process.setrlimit(:CPU, 2, 5)
loop do
end
# => "Max Time exceeded. Total running time: 2 seconds"
The hard limit is not reached before the trap block executes, so the code runs as you expect.

Resources