Verilog/LEC trick question

[Shahzad40]

lec verilog

Hi,

look at the following code:
input TX_IN;
reg [12:0] Rx;
always @ (posedge CLK)
begin
if(CLR)
....
....
Rx <= ~TX_IN;
..
else
...
end
Can anyone tell me with authority will the Rx[0] will get the inverted of TX_IN or all the bits of Rx will get inverted of TX_IN ?
The reason i am asking is cause i thought only the LSB gets inverted so i changed the code to
Rx [12:1] = 12'b0;
Rx[0] = ~TX_IN;
and when I LEC the two code, the LEC reported that the two codes are unequivalent
Regards,

 

[rberek]

hindi trick question

I don't know if I consider myself an authority, and you've shown almost no code, but I see nothing in the original code that sets Rx[12:1] to 12'b0;

Thus, your modification, which does set Rx[12:1] to 12'b0, can't be equivalent to the old one.

Its not good practice to load a multi-bit register with a single bit value and assume the other bits will have a determinate value.

r.b.

 

[jbeniston]

lec verilog tools

Make your code explict:

rx <= {13{~TX_IN}};

Or

rx <= {12'd0, ~TX_IN};

Or

rx[0] <= ~TX_IN;

depending upon what you want.

 

[Shahzad40]

cadence rtl compiler tricks

Thanks for the replies:
So am i right in saying that the first part of the code where:
Rx <= ~TX_IN;
means that the Rx[0] will have the inverted of TX_IN and the rest of the bits Rx[12:1] are uninitiallized UNLIKE Rx[0] . And this is not good. The question becomes why this is not good.

and the modified version where:
Rx [12:1] = 12'b0;
Rx[0] = ~TX_IN;
explicitly initializes the Rx[12:0]

 

[rberek]

verilog inversion

means that the Rx[0] will have the inverted of TX_IN and the rest of the bits Rx[12:1] are uninitiallized UNLIKE Rx[0] . And this is not good. The question becomes why this is not good.

As a chip designer, you always need to know what each bit is doing all the time. Undetermined bits can lead to undetermined results.

As well, synthesis tools may make their own assumptions about what you are doing if it is uncertain, and you can get circuitry on your FPGA that is not what you had intended. A classic outcome of not specifying every register in every condition is inferred latches rather than flip flops. This also leads to differences between your simulation and the actual performace of your circuit.

In chip design, the devil really is in the details. A good chip designer specifies everything!

r.b.

 

[Shahzad40]

verilog tricky questios

Please read on as I have resolved this and I was surprised that NO ONE was able to answer a simple verilog question (I am a newbie of Verilog). I performed synthesis and the did LEC to come out with an important conclusion:
My original question:

input TX_IN;
reg [12:0] Rx;
always @ (posedge CLK)
begin
if(CLR)
....
....
Rx <= ~TX_IN;
..
else
...
end
Can anyone tell me with authority will the Rx[0] will get the inverted of TX_IN or all the bits of Rx will get inverted of TX_IN ?

The answer is that Rx[0] will get the inverted of TX_IN but Rx[12:1] will all get a value of 1 and not 0 and the reason is that the tool is stuffing 0s with TX_IN to make it 13 bit wide and then applying an inversion. If you remove the inversion, Rx[12:1] gets 0s.
I have checked this thoroughly
Regards

 

[rberek]

how do i remove my rx12 chip from my phone

But you didn't really answer a Verilog question. The question you answered was "What does my tool chain do if I incompletely specify an operation in Verilog?"

You spent days figuring out what the tools assumed when you failed to explicitly specify your circuit's operation. The tools should never have to assume anything. You have to tell them everything.

You should know exactly what the synthesis tool or simulator will do with every line you write, because the code is written in such a way that nothing is ambiguous to you, to other designers, or the tool.

In the end, is this functionality what you'd expect to be implemented? Even if it is, its dangerous to let any part of the tool chain make guesses. It might guess differently next time. Or a different tool might treat it differently.

In this case, the tool has added leading zeros, which is common. But letting it do this on a vector that is undergoing a logical operation is pretty dangerous.

There's no great mystery revealed here. Writing code this way is a common newbie mistake. And I've made that mistake myself too. Its very poor coding technique. However, part of my income depends on people continuing to make that mistake, so maybe I shouldn't be correcting people ;-)

r.b.

 

[Shahzad40]

lec chip

Don't take things to your heart. If you read my question, I asked a simple and a straight question and I did not get an answer from any one. I will repeat the question:
"Can anyone tell me with authority will the Rx[0] will get the inverted of TX_IN or all the bits of Rx will get inverted of TX_IN ?
The reason i am asking is cause i thought only the LSB gets inverted so i changed the code to
Rx [12:1] = 12'b0;
Rx[0] = ~TX_IN;
and when I LEC the two code, the LEC reported that the two codes are unequivalent "

It was not my code and it was a part of a chip working for 10 years as a CHIP. Also, it has been written by a guru, I have noticed that gurus does these sort of things to hide or prove themselves when things could be done in a very simple way. I HATE THAT. I know that it should have been explicit and simple. Having said that, the code lies within the Verilog LRM specifications.
To prove the point, I quote the Verilog 2001 LRM sec 4.1.10 Bit-wise operators page 48
"When the operands are of unequal bit length, the shorter operand is zero-filled in the most significant bit"
Here the code is stuffing zeros in the MSBs and then performing the inversion and that is the reason we get flip-flops which are set upon reset.
So the reason why LEC was showing unequivalent is that I specified Rx[12:1] to be 0 and if you change them to all 1s the LEC passes.

You suggested the following in your previous message.
- ambiguity in the code
- tool will make any sort guesses
- It is dangerous
- It is a mistake and
- It is not very poor coding technique.
All your suggestions are plain WRONG according to the LRM. The LRM nowhere suggests not to use this style while on many ocassion it does say not to do blah-blah
It is perfect, legal and explicit from the tool point of view. From readability point of view, i agree this is poor.
I have checked this code and experemented using the follwoing:
Verilog LRM
Cadence LEC (did rtl-to-rtl and rtl-to-netlist check)
Design Compiler (synthesis)
Synplicity
VCS
Xilinx XST
I saw consistency with what I am saying

This might not be a mystery for you but for me it was and I am glad that I spent days on it (not my official time).

In the end, please do not make suggestions as you did without some concrete knowledge, we are logical community and logic shall prevail.