Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronic 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.

Register Log in

RTL Coding Style of sensitivity list

Status
Not open for further replies.

sakshi gupta

Full Member level 1
Joined
Jun 30, 2010
Messages
96
Helped
4
Reputation
8
Reaction score
4
Trophy points
1,288
Location
India
Activity points
1,810
In combinatorial always block ,is it good coding style to update the value of element present in the sensitivity list in always block .:?:

For example

always@(b or a)
begin
c=a ;
a=b; --(good or bad)
end
 

ebuddy

Full Member level 3
Joined
May 15, 2007
Messages
179
Helped
35
Reputation
70
Reaction score
34
Trophy points
1,308
Activity points
2,387
It is not only bad, it is one of those things you should avoid. The example you have here will form a timing loop. Essentially, you are designing a sequential circuit.
 

haykp

Member level 3
Joined
Oct 22, 2010
Messages
66
Helped
9
Reputation
18
Reaction score
9
Trophy points
1,288
Activity points
1,643
Certainly bad, first of all it is not synthesizabl. Second it can bring you to infinite loop. Consider this case:
always @ (a)
b = k

always@(b or a)
begin
c=a ;
a=b;
end
 

sakshi gupta

Full Member level 1
Joined
Jun 30, 2010
Messages
96
Helped
4
Reputation
8
Reaction score
4
Trophy points
1,288
Location
India
Activity points
1,810
Can you please explain this in more detail "The example you have here will form a timing loop. Essentially, you are designing a sequential circuit "

I have more query :
assign c=a;
assign a=b ;

The example written here does same thing as example mentioned above using sensitivity list . It's just the coding style then what's difference between two codes ?
 

FvM

Super Moderator
Staff member
Joined
Jan 22, 2008
Messages
47,995
Helped
14,149
Reputation
28,557
Reaction score
12,841
Trophy points
1,393
Location
Bochum, Germany
Activity points
278,361
As first point, can you please clarify, if the problem is about simulation or synthesis? (Or possibly code, that is required to give consistent results for both)

Level sensitive events in always blocks are generally ignored in synthesis. So we should assume a simulation problem, where the sensitivity list matters. I'm not sure, if the shown example isn't good or bad as such. Of course you are able to make it fail in conjunction with other code. If b isn't assigned depending on the value of c or a in another part of the code, there won't be a loop. If it is, it may still be a valid behavioral description of a latch. I'm not quite sure, but I'm under the impression, that a non-inverted logical loop without delay statements will result in a stable latch also in simulation.

P.S.:
It's just the coding style then what's difference between two codes ?
As long as you don't add a race condition in other parts of the code, there won't be a difference, I think.
 
Last edited:

sakshi gupta

Full Member level 1
Joined
Jun 30, 2010
Messages
96
Helped
4
Reputation
8
Reaction score
4
Trophy points
1,288
Location
India
Activity points
1,810
Yes u are right that code mentioned below may cause infinite loop in simulation

always@(b or a)
begin
c=a ;
a=b;
end

My question is then to avoid this situation , we should write code like this:

assign c=a;
assign a=b ;

Are two codes equivalent ?
 

FvM

Super Moderator
Staff member
Joined
Jan 22, 2008
Messages
47,995
Helped
14,149
Reputation
28,557
Reaction score
12,841
Trophy points
1,393
Location
Bochum, Germany
Activity points
278,361
Yes u are right that code mentioned below may cause infinite loop in simulation
I agree, that other code styles should be preferred, but if b stays constant, no further update event will occur.

P.S.: Thank you for mentioning IEEE 1364.1. In my understanding, it's objective is to avoid simulation mismatch and discussing the cases, where it can happen. It's not suggesting a particular coding style.

Related to the original problem, IEEE 1364.1 would mainly require a and c to be added to the sensitivity list to avoid simulation mismatch, which has been done. As the code itself doesn't introduce a race condition, it's neither "bad" as such nor contradicting IEEE 1364.1 in my opinion.
 
Last edited:

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Top