Continue to Site

# Claim in attached paper not understood

Status
Not open for further replies.

#### ASIC_int

In page no. 9 of attached document, in the third paragraph, it has been claimed:

"While the enable is in this unknown state, the case selector will
erroneously match one of the case conditions, based on the value of addr".

There is no case option with the enable in unknown state. So how can it erroneously match one of the case items?

What does the second paragraph in page no. 10 try to mean?

#### Attachments

• Mills_Final.pdf
43.3 KB · Views: 29
Last edited:

#### ASIC_int

What does the second paragraph in page no. 10 try to mean?

#### permute

x is treated as "this is either 0 or 1, match either" within the casex structure. so:
Code:
casex (mysig)
1'b0:  y <= 1'b0;
1'b1:  y <= 1'b1;
endcasex
the above will have a defined meaning for the 'x' case, as an x on the input will match a 1 or a 0. IIRC, it will set y to 0 in this case, as 1'b0 is the first "matched" case. casez has the same issue with the 'z' case.

This is an example of a design construct that was not designed for its actual use. Most people use casex/casez to have cases with don't-cares but must accept the dangerous "wildcard tokens" that can now be in the input.

#### ASIC_int

permute

You need to read carefully what I asked. What you stated does not match to what is claimed in page no. 9 of attached document, in the third paragraph. It has been claimed that:

"While the enable is in this unknown state, the case selector will
erroneously match one of the case conditions, based on the value of addr".

Regards

#### lostinxlation

There is no case option with the enable in unknown state. So how can it erroneously match one of the case items?
You should read the document more carefully.

The second sentence says "A casex treats X as don't cares if they are in either the case expression or the case item".

permute

You need to read carefully what I asked. What you stated does not match to what is claimed in page no. 9 of attached document, in the third paragraph. It has been claimed that:
What Permute stated is exactly what the attached document implies.

---------- Post added at 06:35 ---------- Previous post was at 05:56 ----------

What does the second paragraph in page no. 10 try to mean?

How many times have you seen the tristate logic used inside the chip ?
That's what it tries to say.

Last edited:

#### ASIC_int

"A casex treats X as don't cares if they are in either the case expression or the case item".

What is case expression? I think case items are items that are there at the left side for every case expressions. Am I correct ?

---------- Post added at 07:07 ---------- Previous post was at 06:40 ----------

Ok an 'x' can be any value like '0', '1' or any non logical voltage level. In this exapmle in the attached paper in page no. 9 one of the case items will match if enable is unknown and this unknown is '1'. It will not match any case items if this unknown is zero or any non-logical vale. Am I correct?

But what does this sentence "In the pre-synthesis
design, this might mask a reset initialization problem that would only be visible in post-synthesis
simulations." in the third paragraph in page number 9 mean?

I also do not understand what does the last sentence in first paragraph in page no. 9 ". The equivalent post-synthesis simulation will propagate ‘X’s through the gate-level
model, if that condition is tested." mean?

I also do not understand from that discussion in page no. 9 , the problem that is there with casex for which it should not be used.

Regards

---------- Post added at 07:41 ---------- Previous post was at 07:07 ----------

PERMUTE
The 'x' is unknown. It can be eith '1' or '0' or any other voltage value not representing '0' or '1'. In your example if mysignals is 'x' and that 'x' is '0' then , it will match the first case option and if the unknown is '1', then it will match the second case option. Is not it?

Regards

Last edited:

#### lostinxlation

Ok an 'x' can be any value like '0', '1' or any non logical voltage level. In this exapmle in the attached paper in page no. 9 one of the case items will match if enable is unknown and this unknown is '1'. It will not match any case items if this unknown is zero or any non-logical vale. Am I correct?
do you really understand what x is, and what casex does ? Unknown is unknown, not 0, not 1. No you aren't correct.

But what does this sentence "In the pre-synthesis
design, this might mask a reset initialization problem that would only be visible in post-synthesis
simulations." in the third paragraph in page number 9 mean?
you don't get x with pre-synthesis, but get x with post-synthesis and you can catch the initiizalization issue.
Understand what casex is.

I also do not understand what does the last sentence in first paragraph in page no. 9 ". The equivalent post-synthesis simulation will propagate ‘X’s through the gate-level
model, if that condition is tested." mean?
Condition doesn't match, then x propagates.

The 'x' is unknown. It can be eith '1' or '0' or any other voltage value not representing '0' or '1'. In your example if mysignals is 'x' and that 'x' is '0' then , it will match the first case option and if the unknown is '1', then it will match the second case option. Is not it?

Regards
Completely misunderstood what X is. There is no such interpretation like unknown is 1 or unknown is 0. Unknown is unknown.

#### ASIC_int

lostinxlation

Can u please explain what you mean by 'x'.

See, in a real chip when we drive the inputs with real signals, the signals can be '0' or '1' or a voltage value which is neither '1' nor '0'. This voltage value which is neither '1' nor '0' is unknown. In reality for signals there is no value called 'x'. The 'x' is a voltage value which is neither '1' nor '0'. Sometimes in one particular input the signal that should come should be always '1' but it may wrongly be driven '0'. In that case '0' is unknown. Correct me if I am wrong.

What do u mean by 'x' then?

I am confident about my understanding of casex. For casex, the synthesis tool synthesizes the netlist in such an way that even if there is unknown, it will land up to a known value because of casex where casesx always prduces known outputs against unknown inputs.

You still did not reply the following:
"A casex treats X as don't cares if they are in either the case expression or the case item".

What is case expression? I think case items are items that are there at the left side for every case expressions. Am I correct ?

Last edited:

#### std_match

I am confident about my understanding of casex. For casex, the synthesis tool synthesizes the netlist in such an way that even if there is unknown, it will land up to a known value because of casex where casesx always prduces known outputs against unknown inputs.
You have not understood that there is a difference between simulation and a real circuit. For simulation, 'X' is a separate value which is different from both '0' and '1'. This means that casex works like you think only in simulation.

In a real circuit, 'X' is '0' or '1', so the probability for a mismatch between simulation and a real circuit is very high.

#### ASIC_int

This means that casex works like you think only in simulation.

What do u mean bu this? PLease explain in detail.

#### lostinxlation

See, in a real chip when we drive the inputs with real signals, the signals can be '0' or '1' or a voltage value which is neither '1' nor '0'. This voltage value which is neither '1' nor '0' is unknown. In reality for signals there is no value called 'x'. The 'x' is a voltage value which is neither '1' nor '0'. Sometimes in one particular input the signal that should come should be always '1' but it may wrongly be driven '0'. In that case '0' is unknown. Correct me if I am wrong.

You have never talked about silicon in this thread. All you talked about was verilog and simulation. X is X, not 0, not 1, UNKNOWN in simulation.
I don't know why you bring the topic of silion out of nowhere, while we have been talking about simulation.

I am confident about my understanding of casex. For casex, the synthesis tool synthesizes the netlist in such an way that even if there is unknown, it will land up to a known value because of casex where casesx always prduces known outputs against unknown inputs.
This understanding is not correct either. If you get unknown inputs, you can easily get 'x' on outputs of the netlist regardless of that it's from casex, or case. When the netlist generated from 16 bit case items in casex gets 0xXXXX as an input, do you think the netlist can generate a known value on the output with the simulation ? Please tell me what kind of synthesis tool does it.

Last edited:

#### ASIC_int

lostinxlation

I am talking of simulatio at gate level. How will 'x' be propagated in simulation at gate level?

If I use casex, then gate level simulation should also match with RTL simulation. Why is noy it so?

Regards

---------- Post added at 10:48 ---------- Previous post was at 10:40 ----------

STD_MATCH

Hi

I have send an query to you in my earlier thread titled "x-propagation and z-propagation in digital system design". PLease reply.

Thanks[/COLOR]

---------- Post added at 11:02 ---------- Previous post was at 10:48 ----------

lostinxlation and others

I HAVE ANOTHER QUESTION

If we use casex, then there should not be any simuation and synthesis mismatch. Because the synthesis tool will synthesize the gate level netlist in such a way so that for an unknown input the output will be a known state. Please provide explanation to correct me if I am wrong here. I find that the attached paper in this case talks of simulation and synthesis mismatch for using casex and casez. But why?

#### lostinxlation

lostinxlation

I am talking of simulatio at gate level. How will 'x' be propagated in simulation at gate level?

If I use casex, then gate level simulation should also match with RTL simulation. Why is noy it so?
Read the document you attached VERY CAREFULLY. It clearly explains gate level simulation and casex dont' match in certain situation and it even showed the example code.

#### ASIC_int

lostinxlation

I HAVE ANOTHER QUESTION

If we use casex, then there should not be any simuation and synthesis mismatch. Because the synthesis tool will synthesize the gate level netlist in such a way so that for an unknown input the output will be a known state. Please provide explanation to correct me if I am wrong here. I find that the attached paper in this case talks of simulation and synthesis mismatch for using casex and casez. But why?

In the same attached document at page no. 9 in third paragraph it writes "In the pre-synthesis design, this might mask a reset initialization problem that would only be visible in post-synthesis simulations." How is it possible? Because the synthesis tool when synthesizes the given code it will synthesize the gate level netlist in such a way that it produces one of those three outputs even with unknown as inputs. Is not IT?

You still did not reply the following:
"A casex treats X as don't cares if they are in either the case expression or the case item".

What is case expression? I think case items are items that are there at the left side for every case expressions. Am I correct ?

You wrote "This understanding is not correct either. If you get unknown inputs, you can easily get 'x' on outputs of the netlist regardless of that it's from casex, or case. When the netlist generated from 16 bit case items in casex gets 0xXXXX as an input, do you think the netlist can generate a known value on the output with the simulation ? Please tell me what kind of synthesis tool does it. "

I agree if the case items are of 16 bits and you have an input of 6 digits that is 0xXXXX then the output should be an unknown if only we pot and default clause of unknown in casex statement. But it is not with the casex example in the paper. In that paper there is no default clause.

Last edited:

#### lostinxlation

lostinxlation

I HAVE ANOTHER QUESTION

If we use casex, then there should not be any simuation and synthesis mismatch. Because the synthesis tool will synthesize the gate level netlist in such a way so that for an unknown input the output will be a known state. Please provide explanation to correct me if I am wrong here. I find that the attached paper in this case talks of simulation and synthesis mismatch for using casex and casez. But why?

In the same attached document at page no. 9 in third paragraph it writes "In the pre-synthesis design, this might mask a reset initialization problem that would only be visible in post-synthesis simulations." How is it possible? Because the synthesis tool when synthesizes the given code it will synthesize the gate level netlist in such a way that it produces one of those three outputs even with unknown as inputs. Is not IT?

How is it possible ?
OK, why don't you create a netlist equivalent to the code provided in the document, put X on the input, and see what happens by yourself instead of asking question ? It won't take 15 minutes to find the answer.

#### ASIC_int

You wrote "This understanding is not correct either. If you get unknown inputs, you can easily get 'x' on outputs of the netlist regardless of that it's from casex, or case. When the netlist generated from 16 bit case items in casex gets 0xXXXX as an input, do you think the netlist can generate a known value on the output with the simulation ? Please tell me what kind of synthesis tool does it. "
.

I agree if the case items are of 16 bits and you have an input of 6 digits that is 0xXXXX then the output should be an unknown if only we pot and default clause of unknown in casex statement. But it is not with the casex example in the paper. In that paper there is no default clause

---------- Post added at 11:24 ---------- Previous post was at 11:20 ----------

How is it possible ?
OK, why don't you create a netlist equivalent to the code provided in the document, put X on the input, and see what happens by yourself instead of asking question ? It won't take 15 minutes to find the answer.

Without doing this I want to get a theoretical knowledge. Even seeing the cide in the paper we can understand theoretically that it should produce a known state with 'x' as input. Is not it. Please reply to my question which was posted earlier instead of requesting me to do the experiment.

#### lostinxlation

Well, you are not understanding the theoretical part of this, that's why you need experiment by yourself. If you refuse to make your hands dirty, good luck in your career.

#### ASIC_int

Well, you are not understanding the theoretical part of this, that's why you need experiment by yourself. If you refuse to make your hands dirty, good luck in your career.

The code that is there is not a code that can be taken for simulation and synthesis as you can see because that is not a complete code. However We do not have simulator now to do a gate level simulation and even I do not have experimental idea of gate level simulation. So it will be better if you kindly provide theoretical ideas kindly.

lostinxlation

You still did not reply the following:
"A casex treats X as don't cares if they are in either the case expression or the case item".

What is case expression? I think case items are items that are there at the left side for every case expressions. Am I correct ?

Last edited:

#### lostinxlation

Why you need a simulation ? The definition of casex is clear and you can find the output without running simulation.

casex(in)
1'b0 : y = 1'b0;
1'b1 : y = 1'b1;
endcase

1) What would be Y if in = x on RTL.
2) what would be Y if in=x on the netlist generated from this RTL.

tell me what you get for (1) and (2).

BTW, you don't need to know the exact netlist to answer (2). You only need a common sense of digital design.

Status
Not open for further replies.