cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
4,258 Views
Registered: ‎03-16-2015

regarding clock frequency

Jump to solution


module ADD1( input [15:0] a,b,c,d,e,f,g,h,
                input clock,
                output reg [15:0] sum
                 );
        
        reg [15:0] a1,b1,c1,d1,e1,f1,g1,h1;

        reg clock1;
        
        wire [15:0] sum1;
        
        assign sum1 = ((a1 + b1) + ( c1 + d1)) + ((e1 + f1) + (g1 + h1));
        
        always @( posedge clock)
        begin
            clock1 <= ~clock1;
        end
        
        always @( posedge clock1)
        begin
            a1 <= a;
            b1 <= b;
            c1 <= c;
            d1 <= d;
            e1 <= e;
            f1 <= f;
            g1 <= g;
            h1 <= h;    
            sum <= sum1;
        end

endmodule

 



module ADD2( input [15:0] a,b,c,d,e,f,g,h,
                input clock,
                output reg [15:0] sum
               
      );
        
        reg [15:0] a1,b1,c1,d1,e1,f1,g1,h1;
        
        wire [15:0] sum1;
        
        assign sum1 = ((a1 + b1) + ( c1 + d1)) + ((e1 + f1) + (g1 + h1));       
             
        always @( posedge clock)
        begin
            a1 <= a;
            b1 <= b;
            c1 <= c;
            d1 <= d;
            e1 <= e;
            f1 <= f;
            g1 <= g;
            h1 <= h;    
            sum <= sum1;
        end

endmodule

 

i have synthesized both of above module and its showing that both of them having same clock speed. my thinking is that as i divided the clock in module <add1> by 2 that must show the double speed. eg if module 2 is 100MHZ then module1 200MHZ.  but that is not happening

as i m new to this field. please help. 

0 Kudos
1 Solution

Accepted Solutions
avrumw
Expert
Expert
8,142 Views
Registered: ‎01-23-2009

A whole bunch of things...

 

First, using a fabric divider to divide your clock is not recommended in an FPGA. The structure of the FPGA has dedicated clock structures, including clock buffers that drive clock networks as well as clock modifying blocks like MMCMs and PLLs. These should be used for modifying the clocks, not flip-flops in the fabric.

 

Second, I am not sure what you are looking at to determine the speed of your design. If you are just looking at the FMAX from synthesis, it will say the same thing - the clock driving the adder cannot run faster than a certain speed. It will not "back propagate" this to the clock input.

 

Timing is supposed to be done the other way around - you tell the synthesis tool how fast the clock is running, and it will try and make the circuit run that fast. It may or may not succeed based on the logic and the frequency requested. The frequency is specified to the tool as constraints - in ISE these are UCF constraints (the PERIOD constraint), and in VIvado, these are XDC constraints (create_clock).

 

When a clock reaches a known clock modifying block (MMCM, PLL, DCM, BUFR), the tools understand the clock modification - if you had programmed any of these to do the divide by 2 then it would have understood that clock1 is running at 1/2 the rate of clock, and hence if you constrained clock to be 200MHz, then the adder would have 10ns (two clock periods) to be performed. However, with a clock modified in the fabric, it does not understand the relationships between the two clocks - you would have to tell it with a different constraint; in ISE you would need to use a FROM TO constraint, and in VIvado you would need a create_generated_clock to tell the tool that the output of the FF driving clock1 is a clock running at half the rate of clock.

 

I will also point out that this circuit will not simulate since the clock1 <= ~clock1 will never resolve. At time 0, clock1 will be an x (unknown) and doing the inversion on every clock period will simply set it to ~x, which is also x. To make this work in simulation, you need to initialize clock1 - changing the definition to

 

reg clock1 = 0;

 

will fix that.

 

Finally, your sum does not have enough bits. You are summing eight 16 bit numbers. The maximum value for each is input is 2^16-1, and hence the maximum value for the sum is 8*(2^16-1), which is 2^19-8; you would need 19 bits for the sum  and sum1 wire/reg to not drop most significant bits.

 

Avrum

View solution in original post

0 Kudos
4 Replies
u4223374
Advisor
Advisor
4,252 Views
Registered: ‎04-26-2015

If it's anything like it was in the ISE 10.1 days, you need to use the hardware clock management (ie the DCM modules) to do the clock division.

 

Otherwise, the synthesis tool isn't smart enough to recognise that clock1 will only change at half the speed of the input clock, and therefore that the other block can take twice as long to update. If you use the DCM modules then it gets the correct result.

0 Kudos
david.hoffman
Explorer
Explorer
4,238 Views
Registered: ‎07-18-2011

The signal clock1 in ADD1 will toggle at one half the frequency of clock as you expect. However, if you want ADD2's clock input to be driven by clock1 then you need to make clock1 an output of ADD1 and attach it to ADD2's clock input port. In the code you've posted clock1 is generated in ADD1 and doesn't leave ADD1.

 

I suspect that in the code which instantiates ADD1 and ADD2 you have connected the same signal to both of their clock input ports. That would exaplin why you see them toggle at the same frequency.

 

David

 

0 Kudos
avrumw
Expert
Expert
8,143 Views
Registered: ‎01-23-2009

A whole bunch of things...

 

First, using a fabric divider to divide your clock is not recommended in an FPGA. The structure of the FPGA has dedicated clock structures, including clock buffers that drive clock networks as well as clock modifying blocks like MMCMs and PLLs. These should be used for modifying the clocks, not flip-flops in the fabric.

 

Second, I am not sure what you are looking at to determine the speed of your design. If you are just looking at the FMAX from synthesis, it will say the same thing - the clock driving the adder cannot run faster than a certain speed. It will not "back propagate" this to the clock input.

 

Timing is supposed to be done the other way around - you tell the synthesis tool how fast the clock is running, and it will try and make the circuit run that fast. It may or may not succeed based on the logic and the frequency requested. The frequency is specified to the tool as constraints - in ISE these are UCF constraints (the PERIOD constraint), and in VIvado, these are XDC constraints (create_clock).

 

When a clock reaches a known clock modifying block (MMCM, PLL, DCM, BUFR), the tools understand the clock modification - if you had programmed any of these to do the divide by 2 then it would have understood that clock1 is running at 1/2 the rate of clock, and hence if you constrained clock to be 200MHz, then the adder would have 10ns (two clock periods) to be performed. However, with a clock modified in the fabric, it does not understand the relationships between the two clocks - you would have to tell it with a different constraint; in ISE you would need to use a FROM TO constraint, and in VIvado you would need a create_generated_clock to tell the tool that the output of the FF driving clock1 is a clock running at half the rate of clock.

 

I will also point out that this circuit will not simulate since the clock1 <= ~clock1 will never resolve. At time 0, clock1 will be an x (unknown) and doing the inversion on every clock period will simply set it to ~x, which is also x. To make this work in simulation, you need to initialize clock1 - changing the definition to

 

reg clock1 = 0;

 

will fix that.

 

Finally, your sum does not have enough bits. You are summing eight 16 bit numbers. The maximum value for each is input is 2^16-1, and hence the maximum value for the sum is 8*(2^16-1), which is 2^19-8; you would need 19 bits for the sum  and sum1 wire/reg to not drop most significant bits.

 

Avrum

View solution in original post

0 Kudos
4,198 Views
Registered: ‎03-16-2015

@avrumw thank you sir...thanks for ur kind reply...

sir was doing  post PAR simulation thats why i have not initialized clock1.

 

and this simulation was an example to clarify the matter what i exactly want to ask..thats why i have not focusses on "sum" size.

 

anyway thanks once again..it was really help full for me

 

0 Kudos