carry lookahead generator

[vickyuet]

Dear All,

I had written a verilog hdl code for carry lock ahead generator.The equations for generate,propagate,carry and sum are implemented through for loop using gate level as well as behavioral level.If anyone can tell that my code is professionally ok or any modification still required.

I had shown here only main part of full code.
//////////////////////////////////////////////////////////////////////////////////////////////////
c[0] =carry_in; //store input carry
for(i=0; i < data_width; i=i+1)
begin
gen = reg_data1&reg_data2; // generate function
prop = reg_data1^reg_data2 ; // propogate function

c[i+1] = gen|(prop&c) ; // carry function
// sum function
sum_cla = prop^c;
end

carry_out = c[data_width] ; //carry_out is taken from MSB of c(carry function)
/////////////////////////////////////////////////////////////////////////////////////////////////

I had modified to use behavioral level for above.
/////////////////////////////////////////////////////////////////////////////////////////////////

for(i=0; i < data_width; i=i+1)
begin
//generate function
if (reg_data1 && reg_data2)
gen = 1'b1;
else
gen = 1'b0;
// propogate function
if (reg_data1==reg_data2)
prop =1'b0;
else
prop =1'b1;

c[i+1] = gen|(prop&c) ; // carry function
// sum function
sum_cla = prop^c;
end

carry_out = c[data_width] ; //MSB for
////////////////////////////////////////////////////////////////////////////////////////////////

The results of both are same.Can we modify c[i+1] = gen|(prop&c) ; using if/else or any other behavioral statements?

 

[permute]

have you tried any basic simulation/synthesis of the code. I seem to remember some syntax issues with such code with some simulator or synthesizer.

obviously you can turn all of the logic functions into behavioral statements. basically in the same manner you did before.
old: x = (logic expression);
new: if (logic expression) x = 1; else x = 0;
or for the specific case:
old x = (logic) | (more logic);
new: if (logic) x = 1; else if (more logic) x = 1; else x = 0;
It probably makes the code more difficult to read. Likewise, it may have some implications for the don't care cases. I'd have to double check what "if (1'bx) y = ..." does to y.

Is this for an FPGA? if so, keep in mind that alternative adder architectures tend to work poorly. The FPGA has good routing resources for the adders inferred by just a+b. Other methods result in a large amount of general routing, which is significantly slower. The result can be an adder that is larger, slower, and consumes more power than just using "a+b".

 

[vickyuet]

Yes i had simulated and synthesized it using modelsim and xilinx it worked except one or two warnings in case of synthesis.
But theoretically if we use a+b, synthesizer will infer a ripple carry adder from library for this logic which is the slowest adder you know bcz of carry ripple effect(more dominant for bigger adder).I had studied that Carry look ahead is very faster than ripple so i had implemented that,though it do for the sake of additional logic and power requirements.

one thing more i had to check the timing of ripple and CLA adder after synthesis to ensure which works faster....How can i do that??????plz help on this.I had synthesized CLA and got following timing from xilinx synthesis report (Maximum combinational path delay: 12.791ns)Is this parameter tells about the speed of adder...if else then do let me the process....regards.

 

[FvM]

But theoretically if we use a+b, synthesizer will infer a ripple carry adder from library for this logic which is the slowest adder you know bcz of carry ripple effect(more dominant for bigger adder).I had studied that Carry look ahead is very faster than ripple so i had implemented that,though it do for the sake of additional logic and power requirements.

Depending on the FPGA family, the devices implement carry look-ahead in dedicated hardware. In any case, the propagation delay of the carry chains is only a fraction of regular logic cells. Thus your assumptions may turn out wrong. I would in contrast expect the synthesis tool to infer a maximum speed adder from a simple behavioural expression "a + b". Related to usual FPGA design problems, construction of special adder circuits is more an academic activity, I think.

But doing benchmark tests is the best way to find out.

I had synthesized CLA and got following timing from xilinx synthesis report (Maximum combinational path delay: 12.791ns)Is this parameter tells about the speed of adder

Depends on your overall design structure, basically yes. A simple method to set unequivocal timing conditions is to extend the adder to an accumulator by supplementing a register bank. Then the maximum count frequency is measures design speed.