type conversion functions

[Altera_Forum]

1st...Merry Xmas & Happy New Year to all... 

 I've been trying to implmenet a count down counter with synchronous load and clock enable..The following is my code...Register WDT is type std_logic_vector holding the set value for the countdown counter. The code is as followed:  COUNTDOWN_PROC: process (reset, clkin) begin  if (clkin'event and clkin='1') then  if (sload = '1') then  timer <= to_integer (unsigned (WDT));  elsif clken = '1' then  timer <= timer - 1;  end if;  end if; end process;  I tried to simulate this and get very different results from both Functional simulation and Timing simulation. Functional simulation did what it suppose to do, everytime I have a sload, the timer load WDT and starts count down. From Timing simulation, it also load the value and counts down, but it loaded the value in a inverted way (i.e. all 1s -> 0s and all 0s -> 1s)..For example, if my WDT is X"000A", then Timing simulation will show as timer loaded the value X"FFF5". I suspect something to do with the type conversion function...but can't explaine why..anyone knows?

[Altera_Forum]

The timer signal definition is missing from your post. I wonder, why you used integer instead of unsigned for counter? 

 The bit inversion has to do neither with conversion function nor integer type but is normal operation of the VHDL compiler. The simulator is using the real signal polarity of synthesized logic in timing simulation. You have to check the logic functional behaviour, ignoring such implementation details. However, if you expose a signal to external pins, it will have correct polarity.

[Altera_Forum]

Simulation: 

 I don't know about the type conversion being the reason your functional-versus-timing simulation discrepancy manifests as an apparent unwanted inversion, but here are some basic things to consider when timing simulation does not behave as expected.  Did you fully constrain the timing and get no timing violations in static timing analysis? Does gate-level simulation report any setup or hold violations? Does your input stimulus satisfy the I/O timing requirements of the FPGA input pins? Your design and the inputs driven by the simulation stimulus must satisfy the timing requirements for timing simulation to work correctly. Depending on how the timing is violated and maybe depending on simulator settings, I think you can have the wrong 1 and 0 values (not merely Xs, which would be more obvious) propagate through the logic.  (I wrote this before FvM made his post. He's talking about this point.) Is your simulation looking at internal nodes (not output pins) where synthesis might be doing some extra inversions or moving inversions across register boundaries? It is completely acceptable for synthesis to do this kind of thing on internal nodes as long as the output device pins have the behavior required by the source files. When synthesis does this, it can make it confusing to look at a gate-level simulation or SignalTap during hardware debug. Perhaps your bus is inverted where you are looking at it in simulation because simulation inserted a couple of inversions that cancel out logically. The synthesis preserve attribute on the register might keep this from happening. The Quartus handbook says this attribute will keep registers from being synthesized away so that you can see them in simulation and SignalTap. It doesn't explicitly say whether it will keep an inversion from being pushed across a register boundary.  Are you using physical synthesis? If so, the Fitter might be changing the netlist in a way that looks like inverting a register. I would guess this would be most likely to happen on a bit-by-bit basis in the Fitter, but it could happen on an entire multibit register. When using physical synthesis in the Fitter or netlist optimizations in Analysis & Synthesis, set "Netlist Optimizations" to "Never Allow" in the Assignment Editor for the signals you want to look at in simulation or SignalTap.   Synchronous load and clock enable:  Your synchronous load and clock enable are in a priority order opposite of the recommended order.  The order you have should work as long as synthesis makes use of the clock enable available in silicon, but according the Quartus handbook, you need the opposite order to make use of both the synchronous load and the clock enable resources in silicon.  If the "Control Signals" table in the Fitter report lists the intended clock enable, then you should be OK functionally, and this isn't a big deal. It is important that you code correctly for synthesis to use the clock enable LAB control signal in silicon if your timing constraints have multicycle exceptions of n for setup and n-1 for hold to go with a clock enable that does a divide by n.  Even if you change to the recommended priority order, synthesis might choose to implement the synchronous load functionality without using that load LAB control signal in silicon. Synthesis sometimes makes this choice because using LAB control signals like synchronous load creates a placement limitation that the Fitter has to deal with. There is a limited number of each kind of special control signal available in each LAB, so this can add a challenge to the Fitter if the design has a huge number of unique LAB controls signals. If you use the recommended priority order, though, synthesis at least has a choice.  The Quartus handbook documentation on this is in Volume 1, Section II, Chapter 6, under "Secondary Register Control Signals Such as Clear and Clock Enable". The device handbook has a section on LAB control signals that says what special signals are available in your particular device.  An HDL example with the recommended priority order is in the Quartus text editor at "Edit --> Insert Template --> [Verilog HDL | VHDL] --> Logic --> Registers --> Full-Featured Positive Edge Register with All Secondary Signals".