Timing requirement not met during design compilation - fpga

I have created a design and would like to compile the design in order to create a binary file for the CPLD. However when I try to compile the design, it outputs a warning saying that the timing requirements not met. It seems like it is complaining about the following VHDL component where the external clock is divided into a lower clock frequency that is used by the other VHDL components in the design:
entity clk_divider is
generic (COUNTER_MAX : integer := 256000);
port(
clk_in : in std_logic;
reset : in std_logic;
clk_out : out std_logic
);
end clk_divider;
architecture Behavioral of clk_divider is
signal signal_level : std_logic := '0';
signal counter : integer range 0 to COUNTER_MAX := 0;
begin
clk_divider : process (clk_in, reset)
begin
if (reset = '1') then
signal_level <= '0';
counter <= 0;
elsif rising_edge(clk_in) then
if (counter = COUNTER_MAX) then
signal_level <= not(signal_level);
counter <= 0;
else
counter <= counter + 1;
end if;
end if;
end process;
clk_out <= signal_level;
end Behavioral;
The critical warning message shown during design compilation is shown below:
Critical Warning (332012): Synopsys Design Constraints File file not found: 'monitor.sdc'.
A Synopsys Design Constraints File is required by the TimeQuest Timing Analyzer to get proper timing constraints.
Without it, the Compiler will not properly optimize the design.
Info (332142): No user constrained base clocks found in the design. Calling "derive_clocks -period 1.0"
Info (332105): Deriving Clocks
Info (332105): create_clock -period 1.000 -name clk clk
Info (332105): create_clock -period 1.000 -name clk_divider:clk_module|signal_level clk_divider:clk_module|signal_level
Info: Found TIMEQUEST_REPORT_SCRIPT_INCLUDE_DEFAULT_ANALYSIS = ON
Info: Can't run Report Timing Closure Recommendations. The current device family is not supported.
Critical Warning (332148): Timing requirements not met
Info (332146): Worst-case setup slack is -7.891
Info (332119): Slack End Point TNS Clock
Info (332119): ========= =================== =====================
Info (332119): -7.891 -123.541 clk
Info (332119): -1.602 -5.110 clk_divider:clk_module|signal_level
Info (332146): Worst-case hold slack is -0.816
Info (332119): Slack End Point TNS Clock
Info (332119): ========= =================== =====================
Info (332119): -0.816 -0.816 clk
Info (332119): 1.732 0.000 clk_divider:clk_module|signal_level
Info (332146): Worst-case recovery slack is -4.190
Info (332119): Slack End Point TNS Clock
Info (332119): ========= =================== =====================
Info (332119): -4.190 -20.950 clk_divider:clk_module|signal_level
Info (332119): -3.654 -76.734 clk
Info (332146): Worst-case removal slack is 4.320
Info (332119): Slack End Point TNS Clock
Info (332119): ========= =================== =====================
Info (332119): 4.320 0.000 clk
Info (332119): 4.856 0.000 clk_divider:clk_module|signal_level
Info (332146): Worst-case minimum pulse width slack is -2.289
Info (332119): Slack End Point TNS Clock
Info (332119): ========= =================== =====================
Info (332119): -2.289 -2.289 clk
Info (332119): 0.247 0.000 clk_divider:clk_module|signal_level
Info (332001): The selected device family is not supported by the report_metastability command.
Info (332102): Design is not fully constrained for setup requirements
Info (332102): Design is not fully constrained for hold requirements
What is the reason for this warning message and how can I solve it? Also what does the slack numbers say about my design?

Since monitor.sdc cannot be found, Quartus tries to synthesize your circuit at 1GHz (period=1ns) as far as the logs reveal the following constraints.
create_clock -period 1.000 -name clk clk
create_clock -period 1.000 -name clk_divider:clk_module|signal_level clk_divider:clk_module|signal_level
The first line is for clk port (it must be in the top-level module/entity) and the second line is for signal_level signal. You can modify the periods appropriately and put the constraints into monitor.sdc. Then you should add that file to the project.
A slack value tells you the difference between the target and the actual. If a path meets the timing requirement, it has a positive slack. If doesn't meet, the slack is negative.
Your target clock period was 1ns, but you got -7.891ns slack for the critical (worst) path. The actual period achievable can be calculated as follows.
actual period = target period - setup slack = 1.000 - (-7.891) = 8.891ns
According to the results above, 8.9ns can be an achievable period for clk. I would also try smaller values, but there is no need if your real input clock (clk) is not faster than 100MHz.
The period of signal_level depends on the minimum value of COUNTER_MAX. Actually the rest of the circuit already seems faster than clk_divider module, because the slack (-1.602) of signal_level is better. You can set the same period with clk.

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.

Can we use two wait statements in a single process in 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.

Resources