verilog simulation issues...

Guest
Hello all,

I am very close to completing a project; however, I am stuck with one
part that I cannot solve. I am building a simple counter system that
takes in two inputs: one from a fast pulse running at LEAST 50Mhz, and
the other one running at 50Khz. The 50Khz signal needs to be split to
two different signals: one for the high phase of the signal and the
other one for the low phase of the signal. So, in total, we have 3
signals needed by the FPGA device to function. The overall design
works as the following: the device counts up whenever the high phase
signal is active and counts downs whenever the low phase signal is
active--we basically turn the up or down the pulses from the 50Mhz,
depending on the phase of the 50Khz signal. The end value can be
either positive or negative depending on the phase. I am using a
Spartan 3 board, so it's a standard board. I have solved the issue of
splitting the 50Khz signal by using a verilog code provided below,
which does exactly what I want. The problem now is in the following
portion of the code, labeled MY PROBLEM. I cannot seem to count the
actual variable pulses that are coming in, however, if I use a
constant pulse clock, such as the 50Mhz clock, then the system works
gracefully, but this defeats the purpose of using the photons_in,
which is rated at least 50MHz—what I want to count. Is there something
wrong with the code, is this variable pulser too small to be sensed by
the flip flop ??? If I have confused you, please let me know so that I
can explain better....

module FF0(/*enable,*/photons_in, done, pem, /*leftsig, rightsig,*/
button1, clk_50Mhz, reset, LEDOUT, LEDSEL);
input reset;
input photons_in;
wire photons_out;
input clk_50Mhz; //leftsig, rightsig;
input button1;
reg [18:0] counter;
input pem;
reg [14:0] numcounter;
reg [3:0] difcount1, difcount2, difcount3, difcount4;
output reg done;
reg [15:0] leddisp;
wire clkbuf, s0, s1, s2, s3, s4, s5, s6, s8,s9,s10,s11,s12,s13,s14,
s15,s16,s17,s18,s19,s20;

supply1[7:0] vcc;
output [6:0] LEDOUT;
output [3:0] LEDSEL;
/*input enable;*/

Timer u8 (clkbuf, pem,leftsig , rightsig, reset, button1 );

//IBUF u9(.O (photons_out) , .I(photons_in) );
IBUFG u10(.O (clkbuf) , .I(clk_50Mhz));

always @ ( posedge photons_in or posedge reset )
begin
if(reset)
begin
counter <= 0;
numcounter <= 0;
done <= 0;
end
else if (button1) //control to start counting
begin
if(counter < 200000) //maximum counter value
begin
if (leftsig)
begin
numcounter <= numcounter + 1;
end
else if (rightsig)
begin
numcounter <= numcounter - 1;
end
counter <= counter + 1;
end
else
done <= 1;
end

end

always @ ( done )
begin
if(reset)
leddisp <= 4'bz;
else
leddisp <= numcounter;
end

always @ (leddisp)
begin
difcount1={leddisp[3], leddisp[2], leddisp[1],leddisp[0]};
difcount2={leddisp[7], leddisp[6], leddisp[5], leddisp[4]};
difcount3={leddisp[11], leddisp[10], leddisp[9], leddisp[8]};
difcount4={0, leddisp[14], leddisp[13], leddisp[12]};
end

led u3 (difcount1,s0, s1, s2, s3, s4, s5, s6);
led u4 (difcount2,s7, s8, s9, s10, s11, s12, s13);
led u5 (difcount3,s14, s15, s16, s17, s18, s19,s20);
led u6 (difcount4,s21, s22, s23, s24, s25, s26, s27);


LED_MUX u7 (/*clkbuf*/ done, reset, {s6, s5, s4, s3, s2, s1, s0},
{s13,s12,s11,s10,s9,s8,s7}, {s20,s19,s18,s17,s16,s15,s14},
{s27,s26,s25,s24,s23,s22,s21}, LEDOUT, LEDSEL );

endmodule


module testbench_tb_0;
wire done;
reg pem = 1'b0;
reg photons_in;
reg button1 = 1'b0;
reg clk_50Mhz = 1'b0;
reg reset = 1'b0;
integer PERIOD3;
wire [6:0] LEDOUT;
wire [3:0] LEDSEL;

parameter PERIOD2 = 20000;
parameter PERIOD = 20;
parameter real DUTY_CYCLE = 0.5;
parameter OFFSET = 0;

initial // Clock process for clk_50Mhz
begin
#OFFSET;
forever
begin
clk_50Mhz = 1'b0;
#(PERIOD-(PERIOD*DUTY_CYCLE)) clk_50Mhz = 1'b1;
#(PERIOD*DUTY_CYCLE);
end
end
initial // Clock process for clk_50Mhz
begin
#OFFSET;
forever
begin
pem = 1'b0;
#(PERIOD2-(PERIOD2*DUTY_CYCLE)) pem = 1'b1;
#(PERIOD2*DUTY_CYCLE);
end
end
initial
begin
#OFFSET;
forever
begin
photons_in = 1'b0;
PERIOD3 = (20 + {$random} % ( 80 - 20 ));
#(PERIOD3-(PERIOD3*DUTY_CYCLE)) photons_in = 1'b1;
#(PERIOD3*DUTY_CYCLE);
end
end

FF0 UUT (
.photons_in(photons),
.done(done),
.pem(pem),
.button1(button1),
.clk_50Mhz(clk_50Mhz),
.reset(reset),
.LEDOUT(LEDOUT),
.LEDSEL(LEDSEL));

initial begin
#50 reset = 1;
#30 reset = 0;
#59 button1 = 1;

end

endmodule
 
On 2008-10-29, uraniumore238@gmail.com <uraniumore238@gmail.com> wrote:
portion of the code, labeled MY PROBLEM. I cannot seem to count the
actual variable pulses that are coming in, however, if I use a
constant pulse clock, such as the 50Mhz clock, then the system works
gracefully, but this defeats the purpose of using the photons_in,
which is rated at least 50MHz?what I want to count. Is there something
wrong with the code, is this variable pulser too small to be sensed by
the flip flop ??? If I have confused you, please let me know so that I
can explain better....
You never state if your problem is with the simulation or the real hardware.

If it is with the hardware, think about the following:

* Is the input connected to a global clock signal?
* Is the input signal suitable as a clock signal?


Perhaps you could run your design at 200 MHz and sample the photons_in
signal instead? At 4 times the required rate it should be possible to do
this. (Perhaps you could use DDR flip-flops to sample the signal as well
for an increased sample rate.)

/Andreas
 
On Oct 28, 8:49 pm, Andreas Ehliar <ehliar-nos...@isy.liu.se> wrote:
On 2008-10-29, uraniumore...@gmail.com <uraniumore...@gmail.com> wrote:

portion of the code, labeled MY PROBLEM. I cannot seem to count the
actual variable pulses that are coming in, however, if I use a
constant pulse clock, such as the 50Mhz clock, then the system works
gracefully, but this defeats the purpose of using the photons_in,
which is rated at least 50MHz?what I want to count. Is there something
wrong with the code, is this variable pulser too small to be sensed by
the flip flop ??? If I have confused you, please let me know so that I
can explain better....

You never state if your problem is with the simulation or the real hardware.

If it is with the hardware, think about the following:

* Is the input connected to a global clock signal?
* Is the input signal suitable as a clock signal?

Perhaps you could run your design at 200 MHz and sample the photons_in
signal instead? At 4 times the required rate it should be possible to do
this. (Perhaps you could use DDR flip-flops to sample the signal as well
for an increased sample rate.)

/Andreas
Hi Adreas,

Thanks for replying. I am in the simulation phase. When I run the
xlinx sim, the photons_in variable signal doesn't get picked up in the
posedge statement in my verilog file. The count array stays at 0 as if
it wasn't counting. Since the signal doesn't provide constant pulsing
could be a reason to why it isn't getting picked up by the posedge
statement or could there some set-up-hold violation in the
simulation???
How can I determine if the input signal in hardware is suitable for my
design ? My board supposedly can handle a 50Mhz clock signal. I have
tested the board with the variable pulser at most 50MHz by itself,
using a simple verilog counter, and it counted. The only problem that
I faced was that when the pulsing stopped, the device still count very
slowly and stop without reaching the maximum count. Can you explain
why this counting will occur even after I am not driving the input..
 
On Oct 29, 1:38 am, uraniumore...@gmail.com wrote:
On Oct 28, 8:49 pm, Andreas Ehliar <ehliar-nos...@isy.liu.se> wrote:





On 2008-10-29, uraniumore...@gmail.com <uraniumore...@gmail.com> wrote:

portion of the code, labeled MY PROBLEM. I cannot seem to count the
actual variable pulses that are coming in, however, if I use a
constant pulse clock, such as the 50Mhz clock, then the system works
gracefully, but this defeats the purpose of using the photons_in,
which is rated at least 50MHz?what I want to count. Is there something
wrong with the code, is this variable pulser too small to be sensed by
the flip flop ??? If I have confused you, please let me know so that I
can explain better....

You never state if your problem is with the simulation or the real hardware.

If it is with the hardware, think about the following:

* Is the input connected to a global clock signal?
* Is the input signal suitable as a clock signal?

Perhaps you could run your design at 200 MHz and sample the photons_in
signal instead? At 4 times the required rate it should be possible to do
this. (Perhaps you could use DDR flip-flops to sample the signal as well
for an increased sample rate.)

/Andreas

Hi Adreas,

Thanks for replying. I am in the simulation phase. When I run the
xlinx sim, the photons_in variable signal doesn't get picked up in the
posedge statement in my verilog file. The count array stays at 0 as if
it wasn't counting. Since the signal doesn't provide constant pulsing
could be a reason to why it isn't getting picked up by the posedge
statement or could there some set-up-hold violation in the
simulation???
How can I determine if the input signal in hardware is suitable for my
design ? My board supposedly can handle a 50Mhz clock signal. I have
tested the board with the variable pulser at most 50MHz by itself,
using a simple verilog counter, and it counted. The only problem that
I faced was that when the pulsing stopped, the device still count very
slowly and stop without reaching the maximum count. Can you explain
why this counting will occur even after I am not driving the input..- Hide quoted text -

- Show quoted text -
....ps, MY PROBLEM is located ... here:

always @ ( posedge photons_in or posedge reset ) " ... I never seem to
enter this block of code, except for the reset, which always works!???
my frustration
 
uraniumore...@gmail.com wrote:
...ps, MY PROBLEM is located ... here:

always @ ( posedge photons_in or posedge reset ) " ... I never seem to
enter this block of code, except for the reset, which always works!???
my frustration
Casting of variable types has been something I've stayed away from.
I'd suggest you double check that the PERIOD3*DUTY_CYCLE doesn't end
up with DUTY_CYCLE cast to a value of 0 or 1.

Do a $display on the calculated value you're using in the delay.

You might try changing PERIOD3 to a real to see what happens or change
your DUTY_CYCLE manipulation to a fraction: multiply first then
divide.

- John_H
 
On Oct 29, 8:28 am, John_H <newsgr...@johnhandwork.com> wrote:
uraniumore...@gmail.com wrote:
...ps, MY PROBLEM is located ... here:

always @ ( posedge photons_in or posedge reset ) " ... I never seem to
enter this block of code, except for the reset, which always works!???
my frustration

Casting of variable types has been something I've stayed away from.
I'd suggest you double check that the PERIOD3*DUTY_CYCLE doesn't end
up with DUTY_CYCLE cast to a value of 0 or 1.

Do a $display on the calculated value you're using in the delay.

You might try changing PERIOD3 to a real to see what happens or change
your DUTY_CYCLE manipulation to a fraction: multiply first then
divide.

- John_H
Hi John

I got these output:

Period 14.000000
Period 38.500000
Period 28.500000
Period 33.500000
Period 38.500000
Period 18.500000
Period 12.500000
Period 21.000000
Period 20.500000
Period 34.500000
Period 19.000000
Period 18.500000
Period 14.500000
Period 36.000000
Period 34.500000
Period 13.000000
Period 28.500000
Period 31.000000
Period 32.500000
The output for DUTY CYCLE

Period 0.500000
Period 0.500000
Period 0.500000
Period 0.500000
Period 0.500000
Period 0.500000
Period 0.500000
Period 0.500000
Period 0.500000
Period 0.500000
Period 0.500000
Period 0.500000
Period 0.500000
Period 0.500000
Period 0.500000
Period 0.500000
Period 0.500000
Period 0.500000
Period 0.500000

....Any suggestions ??
 
uraniumore...@gmail.com wrote:
Hi John

I got these output:

Period 14.000000
Period 38.500000
Period 28.500000
Period 33.500000
Period 38.500000
Period 18.500000
Period 12.500000
Period 21.000000
Period 20.500000
Period 34.500000
Period 19.000000
Period 18.500000
Period 14.500000
Period 36.000000
Period 34.500000
Period 13.000000
Period 28.500000
Period 31.000000
Period 32.500000
The output for DUTY CYCLE

snip

Were these for the delay values in your code:
#(PERIOD3-(PERIOD3*DUTY_CYCLE)) photons_in = 1'b1;
#(PERIOD3*DUTY_CYCLE
??

You say your block is not executing yet you appear to go through the
photons_in cycling with the displays above. Do you have a $display in
that block that isn't executing to show that it really doesn't? Or is
there another way that you saw it wasn't executing?

Troubleshooting is the art of observing a problem and partitioning the
problem into smaller pieces. If the smaller pieces work like you
expect but the larger piece doesn't, the two pieces might not fit
together the way you expect. The alternative is that one piece
doesn't do what you want so you isolate what's going wrong with that
piece in a similar "divide and conquer" approach.

I don't want to load up your code into the simulator where I am to
find out why your code isn't doing what you want. I'd like you to get
further into your own code using $display statements or using
graphical outputs to zero in on what's strange with your code. It
could be as simple as an undefined value which doesn't let your "if"
statements work the way you expect they would given a high or low
signal.

Dig in! Find out.
 
On Oct 29, 1:47 pm, uraniumore...@gmail.com wrote:
On Oct 29, 8:28 am, John_H <newsgr...@johnhandwork.com> wrote:



uraniumore...@gmail.com wrote:
...ps, MY PROBLEM is located ... here:

always @ ( posedge photons_in or posedge reset ) " ... I never seem to
enter this block of code, except for the reset, which always works!???
my frustration

Casting of variable types has been something I've stayed away from.
I'd suggest you double check that the PERIOD3*DUTY_CYCLE doesn't end
up with DUTY_CYCLE cast to a value of 0 or 1.

Do a $display on the calculated value you're using in the delay.

You might try changing PERIOD3 to a real to see what happens or change
your DUTY_CYCLE manipulation to a fraction: multiply first then
divide.

- John_H

Hi John

I got these output:

Period 14.000000
Period 38.500000
Period 28.500000
Period 33.500000
Period 38.500000
Period 18.500000
Period 12.500000
Period 21.000000
Period 20.500000
Period 34.500000
Period 19.000000
Period 18.500000
Period 14.500000
Period 36.000000
Period 34.500000
Period 13.000000
Period 28.500000
Period 31.000000
Period 32.500000
The output for DUTY CYCLE

Period 0.500000
Period 0.500000
Period 0.500000
Period 0.500000
Period 0.500000
Period 0.500000
Period 0.500000
Period 0.500000
Period 0.500000
Period 0.500000
Period 0.500000
Period 0.500000
Period 0.500000
Period 0.500000
Period 0.500000
Period 0.500000
Period 0.500000
Period 0.500000
Period 0.500000

...Any suggestions ??
Well, never mind about that. How about hardware issues ? Is there
anything I need to consider when I program the board to count those
fast variable pulses. The fastest pulse that is coming in is 50Mhz...
 
On Oct 29, 1:15 am, uraniumore...@gmail.com wrote:
I am very close to completing a project; however, I am stuck with one
part that I cannot solve.
I expect that your problem is in the following line of code:

>                   .photons_in(photons),
 
On Oct 30, 12:35 pm, sh...@cadence.com wrote:
On Oct 29, 1:15 am, uraniumore...@gmail.com wrote:



I am very close to completing a project; however, I am stuck with one
part that I cannot solve.

I expect that your problem is in the following line of code:



                  .photons_in(photons),- Hide quoted text -

- Show quoted text -
Thanks! the code works now. When implimenting this on my spartan chip,
is there anything I have to watch out for. For example, I was
experiencing counting when the fpga device is connected to the pulser,
even when the pulser wasn't pulsing...Any advice ?
 

Welcome to EDABoard.com

Sponsor

Back
Top