Beginner needs help...

O

Olaf Kaluza

Guest
Hi to everyone,

I am learning Verilog now....

Level: Beginner
Sublevel: Desperated.
Hardware: Xilinx XC3S100E Demoboard with 4Led, 4x7Segment, 4Keys,
33Mhz Clock
Software: Webpack 8.2i (Windows), Ikarus (Linux)

It was my idea to write SPI-bus data transfer. When it is working,
I will connect a AD-converter (MAX1248).
Until now there is no ADC, I only connect LED for Dataout and Clock,
so I can look what happens.

Unfortunatly it is not working now.

If I examine my program with a testbench with Ikarus, everything
looks okay. If you like to examine it:

http://www.criseis.ruhr.de/verilog/Source1_Ikarus.v Source
http://www.criseis.ruhr.de/verilog/testbench.v Testbench
http://www.criseis.ruhr.de/verilog/aout.txt Output

When I compile with Webpack and install in real FPGA this happens:

1. My LED for Clock starts flashing and never stops.
My LED for DataOut flash, too.

2. When I press my Key (Taste1) flashing of Clk-LED Stops.

3. If I release the key, Clk-LED starts flashing forever,
and the same is true for Dataout.

4. I can decide if LED for Dataout is flashing by the level
at DataIn.

Sourceode for Webpack:

http://www.criseis.ruhr.de/verilog/Source1.v

There is also some source inside for writing number to my
7segment-led, but it is not used now.

A piece of source for people who feel to lazy to download:

reg [3:0] state;
reg [3:0] next_state;

parameter S_0 = 4'b0000;
parameter S_1 = 4'b0001;
parameter S_2 = 4'b0010;

parameter S_3 = 4'b0011,
S_4 = 4'b0100,
S_5 = 4'b0101,
S_6 = 4'b0110,
S_7 = 4'b0111;

reg clockout;
reg datenout;
reg [7:0] tmp;
integer bitcounter;

//Ausgabe eines Datenbit und generierung des notwendigen Clocks
//Ausserdem bei Reset das Datenregister initialisieren
always@(state)
begin
case (state)
S_0 : begin
$display("S_0");
tmp <= {tmp[6:0], 1'b1 /* MAX_DOUT*/ }; // I cheat DataInput for test
next_state <= S_1;
end
S_1 : begin
$display("S_1");
clockout <= 1'b1; //Clock to High
next_state <= S_2;
end

S_2 : begin
$display("S_2");
clockout <= 1'b0; //Clock to Low
bitcounter = bitcounter +1;
if (bitcounter == 7) next_state <= S_7;
else next_state <= S_0;
end

S_6 : begin
$display("S_6");
tmp <= 8'b11110000; //At reset load commandoword
bitcounter = 0;
next_state <= S_0; //start statemachine
end
S_7 : begin //stop statemachine
$display("S_7");
next_state <= S_7;
end
endcase
end

Question: Why it never reach state: S_7 with Xilinx, but works well
with Ikarus?
Why my Dataout at Led1 is wrong?

//My Led for testing needs inverting so 1=led on.
assign Led1 = !tmp[7];
assign Led2 = !clockout;

//Haelt unser Statemachine in Schwung
always @(posedge SPI_CLK)
begin
if (Taste1 == 1'b1) //Das ist erstmal unsere Resettaste
begin
state <= S_6;
$display("Reset!");
end
else
begin
$display("Tick-Tack");
state <= next_state; //Statemachine triggern
end
end

SPI_CLK comes from a counter to provide 10Hz Clock from my 33Mhz XTal.


Any ideas?

Olaf
 
Mike Treseler <mike_treseler@comcast.net> wrote:


Modelsim gives me the same sim output you have.
I found the reason for my problem. It is important to define the state
of a variable in every part of a case-command. If I do not, the
compiler made a latch from this variable and for some reason I did not
understand a latch is impossible.
There was a warning from the compiler that he made latches from my
register variable, but I thought a warning is not so important than an
error, so I can ignore them now.
I also thought: "A latch? Why not, a latch sounds fine"

Perhaps that was a mistake by me. :)

But I think it is strange that I can write so easy things in a
language that looking good, but are very bad. And I can not understand
why it is only a warning and not a mistake when it is impossible for
the compiler to synthesize it for my FPGA.

Consider using a waveform viewer rather than flashing LEDs.
I installed gtkwave and can view waveform now. I agree it made the
live a little bit easier.

Do your debugging in simulation.
That was the problem with my problem. At debugging everythink looked
okay.

Olaf
 
Mike Treseler <mike_treseler@comcast.net> wrote:


Modelsim gives me the same sim output you have.
I found the reason for my problem. It is important to define the state
of a variable in every part of a case-command. If I do not, the
compiler made a latch from this variable and for some reason I did not
understand a latch is impossible.
There was a warning from the compiler that he made latches from my
register variable, but I thought a warning is not so important than an
error, so I can ignore them now.
I also thought: "A latch? Why not, a latch sounds fine"

Perhaps that was a mistake by me. :)

But I think it is strange that I can write so easy things in a
language that looking good, but are very bad. And I can not understand
why it is only a warning and not a mistake when it is impossible for
the compiler to synthesize it for my FPGA.

Consider using a waveform viewer rather than flashing LEDs.
I installed gtkwave and can view waveform now. I agree it made the
live a little bit easier.

Do your debugging in simulation.
That was the problem with my problem. At debugging everythink looked
okay.

Olaf
 
Olaf Kaluza wrote:

It was my idea to write SPI-bus data transfer. When it is working,
I will connect a AD-converter (MAX1248).
Until now there is no ADC, I only connect LED for Dataout and Clock,
so I can look what happens.
Modelsim gives me the same sim output you have.
Your longest pulse is 30nS.
Consider using a waveform viewer rather than flashing LEDs.
Write a model for the MAX1248 interface
and get your testbench waves to match the data sheet waves.
Do your debugging in simulation.
Good luck.

-- Mike Treseler
 
Olaf Kaluza wrote:

I also thought: "A latch? Why not, a latch sounds fine"
Perhaps that was a mistake by me. :)
But I think it is strange that I can write so easy things in a
language that looking good, but are very bad. And I can not understand
why it is only a warning and not a mistake when it is impossible for
the compiler to synthesize it for my FPGA.
FPGA tools work best with synchronous designs.
Here are some examples to play with on your tools:

http://mysite.verizon.net/miketreseler/


-- Mike Treseler
 
On Jun 18, 1:13 pm, Mike Treseler <mike_trese...@comcast.net> wrote:
Olaf Kaluza wrote:
I also thought: "A latch? Why not, a latch sounds fine"
Perhaps that was a mistake by me. :)
But I think it is strange that I can write so easy things in a
language that looking good, but are very bad. And I can not understand
why it is only a warning and not a mistake when it is impossible for
the compiler to synthesize it for my FPGA.

FPGA tools work best with synchronous designs.
Here are some examples to play with on your tools:

http://mysite.verizon.net/miketreseler/

-- Mike Treseler
I agree with Mike, avoid combinatorial processes (in favor of clocked
processes), and you won't get any latches.

Most FPGA tools will try to build a latch out of LUTS (feedback), but
they are not generally reliable (prone to glitches on inputs causing
unlatching).

If combinatorial processes are unavoidable, always assign default
values to ALL variables at the beginning of the always block, before
any conditional statements and/or assignments, to avoid latches.

Andy
 

Welcome to EDABoard.com

Sponsor

Back
Top