spread of clock pulse in vhdl

I am trying to write a code in vhdl with a given time period of clock in testbench .When i execute it i get proper output , but if i modify the code slightly i.e including more functions (more operations) then although am not changing anything in the test bench , but still i the clock in the test bench waveform appears to have got spreaded , i.e it appears to have an increased time period. Please someone explain me ..

Without the code - we can only guess.
Is this a RTL simulation or gate level sim?

I advise you post both the code that "seems to work correctly" and the code that no longer "works as expected", otherwise we just have to guess as to why one works and the other doesn't.

Are you sure you are looking at everything with the same zoom level in the simulator, e.g. one simulation runs for twice as long so zooming out to show the entire simulation will show a clock toggling 2x as much.

p11 said:

I am trying to write a code in vhdl with a given time period of clock in testbench .When i execute it i get proper output , but if i modify the code slightly i.e including more functions (more operations) then although am not changing anything in the test bench , but still i the clock in the test bench waveform appears to have got spreaded , i.e it appears to have an increased time period. Please someone explain me ..

Click to expand...

Like @ads-ee mentioned, you also might want to place two cursors on riding edge of the clock that you are measuring (one after another) and measure the time period between both cursor (the tools will show the delta). Check for both cases.

xtcx said:

Like @ads-ee mentioned, you also might want to place two cursors on riding edge of the clock that you are measuring (one after another) and measure the time period between both cursor (the tools will show the delta). Check for both cases.

Click to expand...

ok ,it was my mistake . The time period remain same but the number of clks shown at the simulation output has decreased . I hope it works well if i implement it in FPGA.The entire code is really long . I m explaining the prog below . I have designed 2 LFSRs (linear feedback shift register ) using Xor gates and Dflipflop. Both of them are working well and are giving me random numbers .The first LFSR is run by a clock about which i was talking about above . The second LFSR is however is run by another clk , which is generated internally using above clock .Now along with generation of data am also trying to store them in a memory .Eg.A data D1 after generated by LFSR 1 is getting stored in a memory location of dat memory . When say 9 data have been stored in dat memory , all these 9 data are shifted parallely to another memory dats . THE GENERATION PROCESS is no doubt continuing at the background .Now as the GENERATION PROCESS is continuing at the background hence again after a certain time when 9 data fills the dat memory , again the process repeats and these 9 data gets shifted to dats memory so the current data in dats memory gets replaced by these new data set .So i am trying to separate those data from dats memory which are having the same values, and no dount i need to complete this before the arrival of the nest data set . The result showing at the simulation output is absolutely correct . But only the number of clocks shown at the output is decreasing .If i limit the operation upto the shifting of data in dats then the number of clock pulses showing at the output is say 30 but if i include the operation of separation of data having same value from dats then the number of clock pulses at the output is decreasing .So it is vierd . But the result showing at the output is absolutely correct .

p11 said:

The first LFSR is run by a clock about which i was talking about above . The second LFSR is however is run by another clk , which is generated internally using above clock .

Click to expand...

Unless this means using a PLL in the FPGA...generating clocks from the fabric logic is highly frowned upon by the majority of seasoned engineers.

It results in asynchronous paths between clock domains, overly tight timing constraints, or reproducibility problems (all because of skew variations between builds). The standard method is to generate a clock enable and use that to enable the clocking of the slower logic. Then simple multi-cycle constraints can be added to relax timing for that "clock domain".

ads-ee said:

Unless this means using a PLL in the FPGA...generating clocks from the fabric logic is highly frowned upon by the majority of seasoned engineers.

It results in asynchronous paths between clock domains, overly tight timing constraints, or reproducibility problems (all because of skew variations between builds). The standard method is to generate a clock enable and use that to enable the clocking of the slower logic. Then simple multi-cycle constraints can be added to relax timing for that "clock domain".

Click to expand...

will you please explain once more. Thank you.

p11 said:

will you please explain once more. Thank you.

Click to expand...

what part? I brought up more than one thing in post #6