[SOLVED] nested case for sequential and combinational logic

[fragnen]

Can we nest case statements in Verilog to write synthesizable rtls in Verilog for sequential logic and combinational logic?

 

[barry]

Yes.

 

[dave_59]

These are questions that can be easily answered by trying it, or searching examples. You are not going to get far learning Verilog by asking one question at time.

 

[barry]

These are questions that can be easily answered by trying it, or searching examples. You are not going to get far learning Verilog by asking one question at time.

Don’t expect @fragnen to do that. Welcome to the world obtuse fragnen posts.

 

[fragnen]

Does it mean the below always block with the nested case statement synthesize to a D-flipflop with an enable?

always @ (posedge clock or negedge rst)
case (rst)
begin
0: q = 1'b0;
1: case (enable)
    begin
    0: q = q;
    1: q = d;
    end
end

 

[FvM]

I like dave_59's suggestion to try the code.

You'll find out that it has syntax errors. After correcting it, you can check if a register is inferred.
I'd guess: not necessarily.

If not, it's not a problem of nested case statements but of this very special construct. Quoting ThisIsNotSam:

this style goes against typical coding styles. synthesis tools might complain or might even misinterpret the intent (unlikely). in short, there is no good reason why anyone would ever write this freakshow of a code.

 

[barry]

Instead of just throwing some gobblydegook out there, maybe you should:
1) Figure out exactly what you’re trying to accomplish.
2) learn the proper way of coding it. There are many appropriate coding styles for a given task; yours is not one of them.
3) Again, just try it.

 

[fragnen]

FvM & dave_59

While writing big synthesizable rtl codes, sometimes it becomes helpful if we can use nested case statements and use of conditional operator. But the problem is we are not sure whether the such written rtl with nested case and conditional operators used inside various always blocks will synthesize to intended logic or not. It is not possible to synthesize and check the netlist whether the netlist has the intended logic or not as the rtl is a big rtl and hence the netlist is a big netlist. So with these threads idea was to see if we can use such nested case or conditional operators in synthesizable rtl or not somehow.

For the above flipflop it can be checked whether it synthesizes to a flipflop or not. But that was not the intention to show the code of flipflop with nested else, but the purpose was to see whether such nested case can be used in big synthesizable rtl codes or not. The posts are not for learning Verilog but more of improving skill of writing synthesizable rtl codes in Verilog.

If possible, your thinking on using such nested case, such conditional operators in big synthesizable rtl codes are requested.

Regards

 

[FvM]

I believe the question has been already answered. Nested case statements in general are fully synthesizable. But your construct ignores the template for register inference, as said not a problem of nested case statements.

 

[fragnen]

But your construct ignores the template for register inference, as said not a problem of nested case statements.

Do you want to mean the following as the template for register interference when you mentioned of register interference?

always@(posedge clock or negedge rst)
if(!rst)
q<=1'b0;
else
q<=d;

If the answer of the above question is yes by you, then this above template is one of the fundamental template that is used for coding many types of sequential logic and hence for sequential logic coding in many of the scenarios we cannot use nested case as the usual template for sequential coding is the above template and not the nested case.

 

[barry]

Do you want to mean the following as the template for register interference when you mentioned of register interference?

always@(posedge clock or negedge rst)
if(!rst)
q<=1'b0;
else
q<=d;

If the answer of the above question is yes by you, then this above template is one of the fundamental template that is used for coding many types of sequential logic and hence for sequential logic coding in many of the scenarios we cannot use nested case as the usual template for sequential coding is the above template and not the nested case.

Your willful ignorance is simply astounding.

There is nothing in the above construct that precludes using case statements, you just can’t use the tangled mess you originally had.
And the word is inference, not interference.

 

[ThisIsNotSam]

Do you want to mean the following as the template for register interference when you mentioned of register interference?

always@(posedge clock or negedge rst)
if(!rst)
q<=1'b0;
else
q<=d;

If the answer of the above question is yes by you, then this above template is one of the fundamental template that is used for coding many types of sequential logic and hence for sequential logic coding in many of the scenarios we cannot use nested case as the usual template for sequential coding is the above template and not the nested case.

it's almost as if you are making an effort to incorrectly understand what we are saying to you over and over. jesus.

 

[fragnen]

Do you want to mean that if the above code is corrected as below it will be a correct synthesizable code for a D-flipflop with an Enable?

---

Code Verilog - [expand]
1
2
3
4
5
6
7
8
9
10
always @ (posedge clock or negedge rst)
case (!rst)
begin
0: q = 1'b0;
1: case (enable)
    begin
    0: q = q;
    1: q = d;
    end
end

---

 

[barry]

Do you want to mean that if the above code is corrected as below it will be a correct synthesizable code for a D-flipflop with an Enable?

---

Code Verilog - [expand]
1
2
3
4
5
6
7
8
9
10
always @ (posedge clock or negedge rst)
case (!rst)
begin
0: q = 1'b0;
1: case (enable)
    begin
    0: q = q;
    1: q = d;
    end
end

---

I’m done with you, @fragnen.

’The definition of stupidity is doing the same thing over and over again and expecting a different result.’

 

[dpaul]

@barry
I’m done with you, @fragnen.
Better late than never!

I hope other members will also follow.

But this fragnen has a clever strategy. My oberrvation says, this member will go for hibernation for a couple of months or even quarter of a year and then spring back again with this same behavior/attitude.
It is really time that the forum Moderators (@FvM?, @ads-ee?) should send the member "heavy infractions" that should not expire.