Pulse counter verification in vhdl

Hi all,

I am presently working on verification and validation of pulse counter
(where i am having such 8 counters)
When i wrote a testbench in VHDL and checking the results in Modelsim
i am not getting desired results.
Here are the steps for vhdl code for simulation.

1.setting the por_n = 0 for 100 ns and release to por_n =1 (power on
reset)
2. Setting up bit 20 of inhibit_1 register to which enables the
functionality of Pulse_counter_0_results register/counter
3. checking the all registers before setting up the values: READ
operation for ZERO values
4. wait for 10 ns
5.Set up register for software defined period for first two bits
6.set up same register for Time base 100 ns on other two bits
6.Load the count value to 10 in a register
7.set the register for start measurement
8. wait for 1000 ns

9. Read the pulse_counter_0_results register after waiting above time
10. As well read the loadable count register after this waiting time
(where i am giving a continues pulse_din signal as a clock of 40 ns,
so i need to get total pulse count in results register as : 1000 ns/40
ns = 25 = 19(Hex)
11 after waiting for 100 ns time also i should get same desired values
which leads holding correct values in correspond results registers.
12. Stop measurement

But i am not getting that desired value instead i am getting only 14
counts.

The whole simulation also depends on two clocks : fpga_clk = 50 MHz,
and dsp_clk = 100 MHz,....

So if anyone give me some exposure on this simulation desired
results ....it will be very helpful.

Sreenivas

MITC - Bangalore

JSreeniv

On Jun 16, 7:52*am, JSreeniv <sreenivas.jyo...@gmail.com> wrote:
> Hi all,
>
> I am presently working on verification and validation of pulse counter
> (where i am having such 8 counters)
> When i wrote a testbench in VHDL and checking the results in Modelsim
> i am not getting desired results.
> Here are the steps for vhdl code for simulation.
>
> 1.setting the por_n = 0 for 100 ns and release to por_n =1 (power on
> reset)
> 2. Setting up bit 20 of inhibit_1 register to which enables the
> functionality of Pulse_counter_0_results register/counter
> 3. checking the all registers before setting up the values: READ
> operation for ZERO values
> 4. wait for 10 ns
> 5.Set up register for software defined period for first two bits
> 6.set up same register for Time base 100 ns on other two bits
> 6.Load the count value to 10 in a register
> 7.set the register for start measurement
> 8. wait for 1000 ns
>
> 9. Read the pulse_counter_0_results register after waiting above time
> 10. As well read the loadable count register after this waiting time
> (where i am giving a continues pulse_din signal as a clock of 40 ns,
> so i need to get total pulse count in results register as : 1000 ns/40
> ns = 25 = 19(Hex)
> 11 after waiting for 100 ns time also i should get same desired values
> which leads holding correct values in correspond results registers.
> 12. Stop measurement
>
> But i am not getting that desired value instead i am getting only 14
> counts.
>
> The whole simulation also depends on two clocks : fpga_clk = 50 MHz,
> and dsp_clk = 100 MHz,....
>
> So if anyone give me some exposure on this simulation desired
> results ....it will be very helpful.
>
> Sreenivas
>
> MITC - Bangalore

My guess would be a thrown Johnson Rod or bad timing on the Spitzer
Valve.

But seriously, I think I can speak for the group. There is little
chance we are going to be able to help with out some indication the
problem code or something. We can't possibly guess at where the
missing semicolon is otherwise.

Shannon

Shannon

Sreenivas,
Add all signals to simulation waveform window.
Run simulation. Watch what did happen.
Start watching from the beginning. What went
right. What did not go right.
Postulate as to why. Add more signals if necessary
to prove your postulation.

Your counter may start running with an old value and not
load the new value until it rolls over. This would cause
a difference in startup than you may expect, but it may produce
correct steady state system behavior if it is tolerable
at the beginning to act this way. Often it is tolerable
because the software does not get to your programmable
counters right away anyway.

I usually make my programmable counters to have two
features. 1: Write counter, but do not reload until
roll over. 2: Write counter and reload immediately.
That way I have both possible features covered.

Best,
Jim

JimLewis