Different results on hardware compared to simulator

I understand that any signal used as the edge to clock a register is considered a clock. I am getting warnings that the launch and latch times between source clock: ale and destination clock: clk are outside legal time range. Ale is basically asynchronous with the main clk. How can I tell it that? I used create_clock not create_generated_clock since ale has nothing to do with the main clk. I guess that is considered another clock domain.

Bidirectional Busses: OK, Got it. Don't use bidirectional busses inside the FPGA to communicate between modules. Just use a data_in and a data_out bus.

I will rewrite my code to do this.

I am beginning to see improvement with even partial timing constraints set. So far the hardware is working correctly. I will see if it behaves properly as more design changes are made.

As I understood you have used wr, rd as clocks. It does not matter to the compiler if they are regular pulses or not. It will be clocks if used with clock edge assignment.

for bidirectional bus: you don't have to think of bidirectionality. just use two buses, one for each direction until such a point you interface them to actual bidir pins.

--- Quote Start ---

The most important issue is that a signal is viewed as clock if it is used to edge trigger any register since it will be connected to clk port of flips.

The safest thing for a beginner is one clock for all registers.

As to tristating inside fpga: you don't need that as it is going to be implemented as muxes and will complicate coding on you.

--- Quote End ---

Basically I have used the main clock to clock all the registers. But then the data in registers is decoded and enables lower level logic.

So, how can I implement a bi-directional bus?

The most important issue is that a signal is viewed as clock if it is used to edge trigger any register since it will be connected to clk port of flips.

The safest thing for a beginner is one clock for all registers.

As to tristating inside fpga: you don't need that as it is going to be implemented as muxes and will complicate coding on you.

I have gone through the TimeQuest online course and I understand the basics. I am working through the main Quartus Interactive Tutorial on timing. But still have some puzzles.

My design uses a multiplexed address/data bus (data_io) with an address latch enable (ale), wr and rd signals. There is also a 14.7456 MHz clock coming into the FPGA which I use to run the internal processes.

A cycle of writing to the FPGA would start with placing an address on the data_io, then set the ale high, then low again. The high time is about 1us so its much slower than the clock. The data_io is valid about 1us before the rising edge of the ale. A write cycle is virtually the same but uses the wr signal going high for 1 us.

In TimeQuest I created the 14 MHz clock just fine. Now it thinks that ale and wr and rd are also clocks and I need to constrain them. Of course, they do not have a regular repeating cycle. There is only those 1us pulses occuring when we want to communicate with the FPGA. So how does one define that in terms of a clock? Also, I cannot control the relationship of the fast clock signal to the ale, wr, or rd signals. I created a "clock" that is the ale input port with a period of 2000ns (1us high time). So my clocks look like this:

create_clock -name {clk_14Mhz} -period 67.817 -waveform { 0.000 33.908 } [get_ports {clk}]

create_clock -name {ale} -period 2000.000 -waveform { 0.000 1000.000 } [get_ports {ale}]

Should I just lengthen the period of the ale and set the fall time to 1000 to simulate closer to what the ale would be doing?

I have eliminated the latches.

I'm a bit puzzled about your comment about not using tristate nodes inside the design. I am trying to implement bi-directional data busses. Of course at the ports of the device that is required to interface with a multiplexed address/data bus. But inside when communicating with the modules are you suggesting that it would be better to implement it as data_input bus and data_output bus? Keep them separate (which doubles the interface pins for the data between modules). I can do that if you believe that is a recommended better practice.

Clock multiplexers are created by the synthesis, I did not code them. Its probably because I have so many different registers being clocked by the main input clock, but I don't really know.

When I talked about setting up data and clocking it one cycle later I was not referring to coding it down at the lowest registers. I meant that I have data coming in that is enabled by an external write signal. The rising edge of that write signal should clock the data into an input register. Then internally I need to decode that data (it can be an address). So to give the decode logic time to operate I wait one clock cycle then clock it into the internal register where I need to put it. I assume that you cannot expect to clock data, decode it with comb logic and then clock it into a final register all at the same external clock edge. So thats why I created state machines to sequence the logic in a well defined manner. Am I wrong in this?

I wish I had an experienced FPGA designer around. We are a very small startup company and I do all the hardware engineering and just got my first FPGA boards back about 3 weeks ago. I have a design that needs to get shipped by the end of this weekend so I'm up against a real time pressure to figure this out. This is actually the second FPGA design. The first one I did a week ago and got it working but I cannot predict what happens when I make a small change in the logic. I know now that its because I did not do the timing and that affects the fitter results tremendously. So, here I am learning timing.

--- Quote Start ---

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

--- Quote End ---

Don't use latches.

--- Quote Start ---

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.

--- Quote End ---

There's no tri-state functionaltiy in the FPGA so why code as if there is and rely on the tools 'fixing' things for you?

Convert to multiple busses, one for each Tx point.

--- Quote Start ---

Clock multiplexers found and protected.

--- Quote End ---

If you're using a single clock domain why is it being multiplexed?

Use clock enables instead!

--- Quote Start ---

I am setting up data and then waiting at least one clock cycle before I

clock it into the next register

--- Quote End ---

That isn't the usual approach for synchronous design. If you're using the same clock to launch and capture signals and the tools know how fast the clock is things _should_ work. (You can have multi-cycle paths but that's the exception rather than rule). You're not doing board design, let the tools worry about timing while you worry about finctionality.

Can you get some input from an experienced FPGA designer? When you've seen how things should be done (no latches, proper synchronous process templates, clock enables etc) it's much easier to get things working.

As long as you're getting signals into and out of the FPGA OK your simulation results should match real world results.

I hope this helps a bit,

Nial.

This will be because the registers in the cyclone III have no asynchronous set and preset inputs, unlike earlier chips. So this behavious has to be emulated.

I suspect the problem is nothing to do with timing exactly, but poor design practice in the source code. If latches are being created then the problem will be timing issues that occur with such designs that cannot be looked at with time quest. Latches and asynchronous logic will also make the design unreliable and suseptable to temperature variations.

--- Quote Start ---

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?

--- Quote End ---

I've never seen this one, so I suspect your code is just not particular synthesizeable. Create a minimal code example that generates this error, and post it, or just post the section of code you're getting the error with, and members of the forum can review it.

--- Quote Start ---

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

--- Quote End ---

Right, all 'clocks' need clock constraints. What you want for this one, is the create_generated_clock constraint. Alternatively, you could code your UART to operate at the FPGA clock frequency, and use the baud-rate divider as an enable to that logic. The code ultimately works the same, however, there's one less clock ... but the logic has to operate at a faster clock rate ... Nothing comes for free :)

Older generation FPGAs did not have PLLs and could not route logic element outputs back into the clock network, so your only coding option was to use enable pulses. In your case, creating a slow clock for the UART is fine, you just need to use create_generated_clock to tell TimeQuest the characteristics of that clock.

--- Quote Start ---

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

--- Quote End ---

Not so much 'quick and easy', but you can set it up to properly analyze the timing. The way you are doing it is fine, i.e., iteratively ...

synthesize -> look at warnings -> add constraints -> repeat

Where you repeat until there are no warnings, or at least until you understand why the warnings are occurring and that they can be ignored, eg., signal assigned a value that is not read, and warnings like that.

Cheers,

Dave