strange register behavior in Verilog blocks under Quartus II
Started by ●March 17, 2005
Hello,
I'm quite new to FPGAs and SoC Design. My original working area was
hig level simulation and SW programming.
To get an insight of FPGA and SoC design I downloaded the risc16f84 IP
core from opencores.org and tried to get the small version of the
PIC16F84 running on our an Altera FPGA board with a Flex 10K FPGA
using the Quartus II Webedition software.
I got the problem, that simulation of the verilog code with a verilog
simulator (icarus verilog simulator) differs completely from Quartus'
simulation, because Quartus does nonblocking (and sometimes blocking)
assignments within an always block only on changes of the signal of
the sensivity list. That means on state changes of the internal FSM
which occur on every rising clock edge. Therefore addresses on the
addressbus of the RAM were assigned too late and all got messed up. I
solved this by inserting extra clock cycle(s) between the stages of
the instruction execuction (e.g. Q1-Qextra-Q2-Q3-Q4). It works for
now, but slows down the maximum performance by at least one fourth.
I'm asking myself now, what is the correct interpretation of the
behavioral Verilog code? Is both correct in terms of discrete event
vs. cycle driven simulation? Can the Quartus behavior be altered or is
it inherent to the FPGA technology?
While I worked around this problem it now complains about a gated
clock on one bit of the first ALU input.
Quartus Output:
Warning: Found 4 node(s) in clock paths which may be acting as ripple
and/or gated clocks -- node(s) analyzed as buffer(s) resulting in
clock skew
Info: Detected ripple clock "risc16f84_small:inst|state_reg[2]" as
buffer
Info: Detected gated clock "risc16f84_small:inst|aluinp1_reg[3]~2674"
as buffer
Info: Detected ripple clock "risc16f84_small:inst|state_reg[0]" as
buffer The strange thing is, that the net feeding the ALU input carries the
correct value (data from ram). The net is assigned to the register in
stage Q2. After a state change (rising clock, ->Q3), the register gets
an unknown (X) value.
After enabling the Design assistant It tells me the following during
compilation:
Critical Warning: Design Assistant warning: Combinational logic used
as clock signal should be implemented according to Altera standard
scheme. Found 1 node(s) related to this rule.
Critical Warning: Node "risc16f84_small:inst|aluinp1_reg[3]~2674"
I can not see any differences in the implementation of the ALU input
register and other internal registers.
I tried to move around the critical node in the floorplan and did
timing assignments to clocks and pins, but either the problem became
even worse or another bit of the ALU input register was the cause of
the problem.
Has anybody had similar problems or suggestions of how to overcome
this problem?
I'm appreciate for any help.
Regards Maik
