Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
14 years ago

Combinatorial minimization

Dear all,

I tried a simple Verilog code for a combinatorial function with 6bit input and 7bit output.

I describe the logic with a case statement. Since only six input cases are significant (the circuit referes to an encoder without priority) I set the output to x using the default statement.

The code is the following 

module prova2 (A,Y);
input  A; output  Y;
wire  A; //wire  Y;
reg  Y;
// Using this case results in 13 LE used 5.6 ns delay
always @(A)
begin
case (A)
6'b000001 : Y <= 7'b1000000;
6'b000010 : Y <= 7'b1111001;
6'b000100 : Y <= 7'b0100100;
6'b001000 : Y <= 7'b0110000;
6'b010000 : Y <= 7'b0011001;
6'b100000 : Y <= 7'b0010010;
default   : Y <= 7'bxxxxxxx;
endcase
end
/*
// Using the minimized functions results in 4 LE usage with 5.6 ns delay
assign Y=A|A;
assign Y=A|A|A;
assign Y=A|A|A|A;
assign Y=A|A;
assign Y=A;
assign Y=A;
assign Y=A|A;
*/
endmodule

The resulting logic is 13 LE. If I minimize the functions by hand, a not difficult task, and describe the logic with boolean functions, I obtain the same circuit that only uses 4 LE and is also faster.

It looks like the "default" statement is not working properly. In fact the testbench that I use shows that in every not specified case the output is fixed to a single value (actually 7'b0010010).

This is very starnge. How is it possible that Quartus does not understand that y[2] is always equal to A[2]?

Thanks for your help.

11 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    I think this has to do with the fact that all the default cases (i.e. everything that doesn't decode in the case statement) needs to be handled and the underlining technology are lookup tables. A is the input to the lookup table, Y is the output and the output cases are defined within the lookup table by the various outputs you coded. When you manually encoded the Y outputs you created functions that don't have default fall-throughs and as a result that didn't need to be encoded into the LUTs. I recommend reading the HDL synthesis guidelines in the Quartus II handbook, it probably does a better job explaining this that I just did.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    In VHDL either a 'select' or a 'case' statement delivers a result in 4 LE and 5.158 ns in a Cyclone II EP2C5T144C6. 

    	with A select 
		Y <= 	"1000000" when "000001" ,
			"1111001" when "000010" ,
			"0100100" when "000100" ,
			"0110000" when "001000" ,
			"0011001" when "010000" ,
			"0010010" when "100000" ,
			"XXXXXXX" when others ;
	process( A ) 
		begin
			case A is
				when "000001"  => Y <= 	"1000000" ;
				when "000010"  => Y <= 	"1111001" ;
				when "000100"  => Y <= 	"0100100" ;
				when "001000"  => Y <= 	"0110000" ;
				when "010000"  => Y <= 	"0011001" ;
				when "100000"  => Y <= 	"0010010" ;
				when others    => Y <= 	"XXXXXXX" ;
			end case ;
		end process ;
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Thank you for your answer.

    For josyb. Do you think that the poor result for my code is due to an error in the description or you think that this is a problem with Quartus synthesizer when dealing with Verilog?

    Should I file a SR?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Thanks to josyb for re-establishing my confidence in the Quartus synthesis tool.

    Apparently, it's less smart in handling Verilog code. I'm not that familiar to Verilog, but it seems to me that the behaviour reported by nplttr is not required by the Verilog specification. You can however make Quartus minimize the construct by applying a full_case synthesis attribute and commenting the default statement. To avoid simulation mismatch, the default statement must be enabled for simulation only. 

    (* full_case *) 
case (A)
6'b000001 : Y <= 7'b1000000;
6'b000010 : Y <= 7'b1111001;
6'b000100 : Y <= 7'b0100100;
6'b001000 : Y <= 7'b0110000;
6'b010000 : Y <= 7'b0011001;
6'b100000 : Y <= 7'b0010010;
// synthesis translate_off
default   : Y <= 7'bxxxxxxx;
// synthesis translate_on
endcase
end
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Personally, I wouldn't worry about how tools behave. At the end of the day it is the employers who will buy what the market trends suggest to the managers and they wouldn't listen to sporadic proofs from field engineers.

    I doubt Altera will change their software outside their systematic approach.

    Moreover, with automated code technology already in force, there is really "little" future left for HDL coding skills in my opinion. But I do look at this trend positively because coding skills and the tons of code take us really away from actual scientific knowledge and the fascination it creates.

    Sorry for my off topic comment.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    --- Quote Start ---

    Personally, I wouldn't worry about how tools behave. ...

    --- Quote End ---

    I'm not sure what you want to tell regarding the present question?

    If we use automated code technology, we won't care, if a particular construct compiles to 4 or 400 LEs, as long as it fits the intended device. And if it doesn't, just choose the next larger one. Or?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    What I want to say is this; I will follow the general rules of the purchased tool for minimising resource and there are plenty of coding styles that produce varying areas for the same task. But I wouldn't waste time (and hence money) on challenging the tool...

    Saving resource is not only a matter of coding styles. Imagine you are to give the task of a "fractional upsampler" to some 100 new graduates or junior HDL engineers then wait and see how it is going to be implemented. The variation of time (and resource) could range from a couple of days to months. The resource will be vastly different. The code could range from one single readable short structured module to a hierrachy of multiple modules and submodules and subsubmodules. What I want to say here is that the human style is far more important than coding style. It is something that managers have no clear idea and no control.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    I do not really agree with the comments that tend to underestimate the importance of coding styles.

    I think that good and widely known good coding rules are important for an engineers (I do not design product, I teach HDL languages).

    Good software design and coding rules is exactly what leads to modern high performance software.

    In this particulkar example, it happens that the 'full case statement' is something that many HDL designers do not suggest to use.

    If Quartus requires this kind of coding, this is something that will bring me to use other synthesizers (and good coding styles) when I need to obtain high performance circuits.

    I hope that Altera is able either to explain this behaviour or modify it.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    --- Quote Start ---

    What I want to say here is that the human style is far more important than coding style.

    --- Quote End ---

    I'll clearly agree. It's obvious, that you can easily waste hundreds and thousands LEs by an unreasonable design structure, so you must not necessarily care about 9 of them. On the other hand, the capability of the synthesis tool to reduce a behavioral description to the respective minimal logic equations, is an important feature that we should be able to trust in.

    --- Quote Start ---

    In this particulkar example, it happens that the 'full case statement' is something that many HDL designers do not suggest to use. If Quartus requires this kind of coding, this is something that will bring me to use other synthesizers (and good coding styles) when I need to obtain high performance circuits.

    --- Quote End ---

    In fact, also IEEE 1364.1 ieee standard for verilog register transfer level synthesis suggests

    --- Quote Start ---

    The use of the full_case and parallel_case attributes is generally not recommended.

    --- Quote End ---

    The reason for this suggestion is quite simple - avoiding simulation mismatch. For the time being, it can be handled by the alternative default statement, as in my example.

    But I agree, that the behaviour of the Quartus synthesis tool in this point is unreasonable and should be fixed. I also don't exactly understand how it's brought up. I'm curious to hear the answer to your service request.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    The response of the SR has been:

    "

    Synthesizer wills use a series of common algorithm to optimize the design, sometimes synthesizer will not fully optimize the function to minimize logic. These behaviors are common for all of the synthesizer tools in the market.

    Designer should write the RTL code in optimize method.

    "

    It seems that there's no intention to improve the synthesizer.