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.

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
 

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.
 

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
 

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 ?
 

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:

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 ?
 

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

Back
Top