Different results on hardware compared to simulator

I was able to eliminate the latch warnings. Code running on the hardware is still working illogically (or rather not working).

Is this warning a real concern:

Warning (13004): Presettable and clearable registers converted to equivalent circuits with latches. Registers power-up to an undefined state, and DEVCLRn places the registers in an undefined state.

I eliminated this warning on a couple of registers at a lower level. Should I pursue this more?

I also get a bunch of warnings in the timing analysis of this type:

Warning (332060): Node: uart:rs485_port|baud_clk[0] was determined to be a clock but was found without an associated clock assignment.

It seems to occur for every signal that is used as an edge trigger to a always_ff block, like this:

always_ff @ (posedge reset_n, posedge baud_clk[0])

begin

blah,....

end

In that particular example the baud_clk is a 4 bit counter that is just being clocked by the main system clock (after it goes through another counter I use for deriving the desired baud rate * 16).

Is there a quick and easy way to set up the timing analysis so that it checks things properly?

I did try setting up timing yesterday and used the wizard to generate an sdc file. It looks much like what you sent me, but with a couple of different set_false_path statements that I don't fully understand:

set_false_path -from  -to 
set_false_path -from  -to 

TimeQuest does not indicate any failures.

I will work on the latches.

Also I see there is a new version 12.0 SP1 for Quartus. I'm going to download and try that.

--- Quote Start ---

I have not done timing. Since the chip is running at such a slow clock rate (14 MHz, about 70 ns period)

--- Quote End ---

Try including a minimal .sdc file, eg., here's one I've copied and then edited to reflect your clock, edit the port name for the clock, and then edit the names of the reset and outputs that you do not care about (with regards to meeting clock-to-output delays):

#  -----------------------------------------------------------------#  Clock#  -----------------------------------------------------------------# #  14MHz clock (70ns period)
set clk_period 70
#  External clock (internal logic clock)
set clk clkin_14MHz
create_clock -period $clk_period -name $clk 
#  -----------------------------------------------------------------#  Cut timing paths#  -----------------------------------------------------------------# #  The timing for the I/Os in this design is arbitrary, so cut all#  paths to the I/Os, even the ones that are used in the design,#  i.e., reset and the LEDs.# 
#  External asynchronous reset
set_false_path -from  -to *
#  LED output path
set_false_path -from * -to 

The latch warning is also a worry. Fix your logic so that registers are used, not latches.

--- Quote Start ---

At this point SignalTap would be difficult because I don't have access to the JTAG port without hacking the board (a flaw which I will correct on the board in the future).

--- Quote End ---

Lesson learned then, eh :)

Cheers,

Dave

Its a single clock domain. I am using a reset synchronizer design that was recommended by Altera (reset does not appear to be the problem). As far as warnings, I have warnings about objects that are assigned but never read (features not yet implemented).

I have some "inferring latches for variable ... which holds its previous value in one or more paths through the always construct".

I have some bits that I'm not using yet which have no driver (using default initial value of 0)

I have some Tri-state nodes which do not directly drive top level pins. In my internal modules there are some bi-directional busses, which is why there are tri-states that don't drive the outside world.

Clock multiplexers found and protected.

All the warnings seem non-consequential to me.

I have not done timing. Since the chip is running at such a slow clock rate (14 MHz, about 70 ns period) and I am setting up data and then waiting at least one clock cycle before I clock it into the next register I thought there would be no problem with that. Could it be that I need to provide more setup time? Delay it another clock cycle?

At this point SignalTap would be difficult because I don't have access to the JTAG port without hacking the board (a flaw which I will correct on the board in the future).

--- Quote Start ---

What am I missing here that makes the code work incorrectly on the actual hardware?

--- Quote End ---

Missing synchronization logic between clock domains? Missing reset synchronizer logic. Timing constraints?

Does Quartus warn you about anything? Make sure all synthesis warning messages are resolved.

Does TimeQuest indicate all timing is met?

Rather than using LEDs to probe your design, use SignalTap II - this logic analyzer allows you to see much more of the internals of the design.

Cheers,

Dave