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.

x-propagation and z-propagation in digital system design

Status
Not open for further replies.

ASIC_int

Advanced Member level 4
Joined
May 14, 2011
Messages
118
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,296
Activity points
2,234
What is the necessity of x-propagation (unknown propagation) or z-propagation while designing a digital circuit? How does it help in bug fixing?
 

x-propagation happens because of unknown values at the port or any intermediate register. One of the goal of post-layout simulations is to check whether there are any x's propagating even when ports are given Low or High.
 

How there can be an unknown at the port when ports are given Low or High?

How can x-propgate when ports are given Low or High?
 

'X' is a signal with conflicting outputs connected to it. An 'X' will propagate to all other signals that depend on it.

'U' is an uninitialized flip-flop. It will propagate to all signals that depend on it.

'Z' is an undriven signal. It will propagate as 'X' to all other signals that depend on it.
 

Hi ASIC_int,

Just look at the below example :

module test (input a,output b);

wire c;

assign b = a & c;

endmodule

Now tell me what will port "b" generate when you have tied port "a" to high?

Regards,
dcreddy
 

dcreddy

The output will be 'x'. But you have not answered what I asked?

What is the need for x-propagation? How does it help in bug fixing? What should one designer do for x-propagation?
 

My earlier post was reply to third post of the thiread where you have said "How can x-propgate when ports are given Low or High?"

Coming back to your original question :

Lets take a small example(mux module) :

There is a 2-bit select signal where valid combinations are : 00,01,10

and "11" is forbidden

Assume this submodule exists in a big design and they have decided that "11" shouldnt be provided or not passed on to our mux module.

The designer can put "x" on the mux o/p for "11" combination.

Have seen in the past that you will not be satisfied with the answers provided by the members. Its better you start providing answers to your questions to see where you stand
 

When the selection is '11' the output of the mux will be 'x' and that 'x' will propagate through other logic in the system to the output of the chip. So that o/p of the chip will be 'x'. What is the benefits of this 'x' propagation? What would happen if I would have put '1' when selection line had forbidden inputs like '11'?

My questions are very preliminary as I ma novice in this issue. Can u please elaborate the need of 'x' propagation more?
 

Debugging can be done differently by different persons, Its easy to say at first look when u see "x" rather than a valid value that something went wrong for the above scenario.
 

dcreddy

How is debugging related to x-propagation? What type of debugging are u talking of? What is tried to debug by engineers so that it needs x-propagation is necessary.

I think I need to understand the basic things. Please explain the basics.
 

When you used a waveform viewer and you see 'x' state on some signal after the reset, any designer will start to think and want to know, why this 'x' state is present, to solve it.
Normally, a design after a clean reset will not propagated any X state.
If you did some netlist simulation, you will prefers to see 1/0 than x state on your waveform.
 

How there can be an unknown at the port when ports are given Low or High?

How can x-propgate when ports are given Low or High?
:arrow:similar question!

**broken link removed**
believe myself.
**broken link removed**
 

How there can be an unknown at the port when ports are given Low or High?

How can x-propgate when ports are given Low or High?

If you accidentally connect two gate outputs together, and they are driving different values, the combined output signal will be 'X' in simulation. In a real circuit, the output can be '0', '1' or something in between, so maybe you don't see anything wrong with the output signal, but there is an error in the design.

If an illegal state or signal combination is detected, it is easy in simulation to explicitly assign 'X' to some output signal, or print a debug message. In real hardware, it is much more difficult to detect such errors.

If you use 'X' and 'U' in a good way, every 'X' or 'U' in the output signals is a bug that should be fixed.

This explains why it is important to do simulations, and to verify that there are no 'X' or 'U' in the output signals, after reset is asserted.
 

Hello std_match

Will the x also be realized in gate level simulation? Is it that in this case of two outputs shorted together, the gate level simulation will also produce 'x' as the RTL simulation produce 'x' ?

Regards
 

Hello std_match

Will the x also be realized in gate level simulation? Is it that in this case of two outputs shorted together, the gate level simulation will also produce 'x' as the RTL simulation produce 'x' ?

Regards
I don't have much experience with gate level simulation, but for shorted outputs I think it will be identical to RTL simulation.

I think that there can be some differences for 'X'-propagation, but I don't have an example for that.
If there is a difference, the gate level simulation is correct.
 

std_match

Then how do the page 9 in attached paper talk about simulation and synthesis mismatch for casex and casez?

To us it seems there should not be any synthesis & simulation mismatch because we are saying RTL simulation and gate level simulation will be same.

Regards
 

Attachments

  • Mills_Final.pdf
    43.3 KB · Views: 93

Then how do the page 9 in attached paper talk about simulation and synthesis mismatch for casex and casez?
There are no shorted outputs in that code. It is only about 'X'-propagation, and it seems to be a case where a difference between RTL simulation and gate level simulation is expected.

I normally don't use verilog for coding, but it seems to be a bad thing that casex is accepted for synthesis. I also dislike the blocking vs. non-blocking stuff.

I prefer VHDL! It will stop you from doing that kind of mistakes.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top