Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

unexpected behavior of disable in RTL for loop when ran with Incisiv simulator

Status
Not open for further replies.

shubham_dce

Newbie level 2
Joined
Mar 26, 2013
Messages
2
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,281
Location
new delhi
Activity points
1,311
Hi,

I am very new to this forum, so please pardon any decorum that i may have violated.

Here is the reference code :


Code Verilog - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
always @(posedge clk or negedge resetn)
begin
  if(~resetn)
  begin
    for(int j=0; j<64; j++)
      enable_data[j] <= 1'b1;
  end
  else
  begin
    if(data_accepted) 
      begin: ENABLE_DATA_BLOCK
         --> event_1;
         for (int k=0; k<64; k++)
           begin
              --> event_2;
              if (enable_data[k] && queue_pos_available[k])
                 begin
                     --> event_3;
                     enable_data [k] <=0;
                     --> event_4;
                     disable ENABLE_DATA_BLOCK;
                 end
           end // for loop
       end // if(data_accepted)
   end // else block
end // always...



While running the above code in incisiv (version incisiv/15.20.016) i am facing the following issue:
with all the condition being true that is data_accepted=1, enable_data[k]=1 and queue_pos_available[k]=1
enable_data[k] is not taking the assignment 0. event_3 and event_4 both are triggering.

I ran the code by removing disable to break and the code ran correctly. So, i think there is a problem by using disable. I can't go with this fix as break is not synthesisable. My lint-run is not passing with the change of break.

Thinking that there is a problem with the use of disable, i tried breaking the loop by setting the loop variable to its maximum value as:
.
.
.

Code Verilog - [expand]
1
2
3
4
5
6
7
if (enable_data[k] && queue_pos_available[k])
                 begin
                     --> event_3;
                     enable_data [k] <=0;
                     --> event_4;
                     k=64;  // i am using blocking statement as i wanted to break the loop immediately.
                 end


.
.

I want to add a point that the code is running fine with VCS and modelsim simulators.

If any-one can direct me of what can be the issue here, it will be of real help.
Thanks for your time.
 
Last edited by a moderator:

I can't help with the issue at hand, but this seems like a rather unusual coding style. disables are like jump statements in software. you simply don't use them. period.
 

I can't help with the issue at hand, but this seems like a rather unusual coding style. disables are like jump statements in software. you simply don't use them. period.

I was thinking the same thing when I saw this post yesterday, but I was thinking this was some kind of SV methodology being used.

In 20+ years of writing Verilog I've never seen disable being used in synthesizable code before (I wasn't even aware it was synthesizable).

I'm sure this is just your typical issue with most of the students that frequent this forum (they think Verilog/VHDL are software languages and take their software paradigm and apply it to digital hardware implementation).
 

It seems to me that the disable statement operation is well defined in Verilog LRM, in so far there should be no doubts how about the working of this code block. Apparently a bug of your simulator.

To stop the iteration of a single loop, you would normally use a break statement. Does it also fail in incisiv?

I see a useful purpose of break (or the equivalent VHDL exit) statement e.g. in the behavioral description of priority encoders.
 

Yes FvM.
Though usage of break helped me move ahead in simulation i am getting BLDSTP (Build Stop) error while i am running the code on Lint. It seems break is not synthesizable.
I have given it a run on Palladium, awaiting results.

I am trying to take up the issue to Incisiv team to get better insight.
 

I've done a bit of research on this subject of using disable and it appears to be universally recommended as not to be used for synthesis, besides there seems to be only partial support for synthesis. The primary use for disable is to disable tasks (i.e. end a task early based on some condition).

I've seen on other sites people trying to use disable to create counters that stop on a value, etc. All of these cases appear to be non-hardware oriented software coders that use Verilog like it was a programming language. Regardless of what FvM says I see no useful purpose even in a priority encoder to using the disable statement. I'm not entirely sure how it should affect the synthesis results. And if it did I would be very worried about that. This appears to be similar to the misconception of using // synthesis parallel_case in your code (if it actually does something during synthesis you are screwed, because now your sim/synth don't match).

With my very hardware oriented thinking I see stuff like code that generates enables that turn on turn off the clocking of FFs in the code, so they don't update, not disabling a named block.

- - - Updated - - -

Looking over the OPs code again I get the distinct impression the code is trying to do a sequence of tests for the first bit of enable_data and queue_pos_available are both high on a 64-bit bus starting from bit-0 and stop on the first bit that are both high together. This is not what the code synthesizes to, there is no sequential checking done, it does all of the checks in parallel. FYI for loops are unrolled during synthesis, using disable doesn't end the loop for synthesis all of the logic is still synthesized in parallel, so I'm not even sure if disable does anything here.

I'm not even sure at this point if the OP even understands what hardware they have coded.
 

Yes FvM.
Though usage of break helped me move ahead in simulation i am getting BLDSTP (Build Stop) error while i am running the code on Lint. It seems break is not synthesizable.
I have given it a run on Palladium, awaiting results.

I am trying to take up the issue to Incisiv team to get better insight.

If you have a Palladium, I am sure you are in an industry context. Whoever you reach out to, they will tell you not to use break -- that is the right answer. Just code it differently and avoid the issue.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top