problems with inputs vs. constants

[Altera_Forum]

Hi all, 

 I am having problems using Input ports to control a function in VHDL. I think it may be a synthesis problem, but I am not sure. I could just not be understanding something or doing something stupid.    In this case I have inputs to a state machine which iterates a signal a number of time based on the values. When the "constant" values are applied, the SM works fine. When the values are from the input ports it crashes. Here is the code. They are both std_logic_vectors of the same length. Anyone have any idea what's going on?   Thanks.    Entity TIMING_GEN is  generic  (  constant A : std_logic_vector(15 downto 0) := x"0144;  constant B : std_logic_vector(15 downto 0) := x"0148";  );  port (  XValue : in std_logic_vector(15 downto 0):= x"0144";   YValue : in std_logic_vector(15 downto 0):= x"0148";  RENA : in std_logic_vector;  ); End entity;   architecture rtl of TIMING_GEN is  signal rows, columns : std_logic_vector(15 downto 0); begin  if RENA = '1' then  rows <= XValue;  columns <= YValue;  else  rows <= A;  columns <= B;  end if;   after this there is a state machine which does some loops based on these values..

[Altera_Forum]

When it comes to inputs, compilers make two types of response. 

If your input is a constant then it reduces logic to the case of constant value only. If your input is not constant then it has to cater for all possibilities. This is possible in the sense of logic decisions but compilers do not support synthesizing different circuits per input value. For example in the case of 16 bits then it will need to create 2^16 circuits !!  Thus for a given build, the compiler needs to settle with one case of build.  the reverse is also true. If you have a variable input and decided to fix it as constant for testing stage then the compiler will remove a lot of logic that will be needed at sign off and may cause trouble to you with your manager at the end.

[Altera_Forum]

Nevertheless, it's legal VHDL code. You didn't tell what crashing of FSM means. I would expect the problem in the state machine code.  

 P.S.: You also didn't clarify, how you tested that code. What you show is an entity without any output signals that synthesizes to nothing, so you are talking apparently about a ModelSim simulation. I assume, that the variable inputsh ave been stimulated somehow.

[Altera_Forum]

Thanks for your replies. kaz, I see your point. These input bits are from a bus external to the FPGA and registered in a bdf file before being taken into the VHDL code. It seems like the synthesizer should simply see these values as the q port of a DFF that goes to the outside world. Indeed, I tried bringing the register into the VHDL and that didn't work either.  

 In this situation, I want the constants to be there as a setting in one mode, and then have a user mode that is variable, so not just for testing. It should synthesize as a busmux.   FvM, I am still trying to track down what the "crash" really is myself. What happens is that when I run with RENA turned off, my PC console application can read and write the Xval and Yval registers (that I mentioned are external to the VHDL), but when the RENA bit is set, the console application indicates that the register is no longer writable. Bringing the q port of that register to the logic analyzer shows that the register is actually being updated. I expect you are right about the state machine being the problem, and honestly I don't know enough about VHDL state machines to know how they handle variable inputs.   There are outputs to the full code, and is synthesizable, but I just cut and pasted excerpts for simplicity since the entire file is rather large. Also, speaking of simulation, I still use Quartus 9.0 since I haven't had the time to face the learning curve on the ModelSim simulator. The code simulates fine on the old Simulator Tool.

[Altera_Forum]

that still doesnt clear anything up. Why not post the other code where the prioblem is?

[Altera_Forum]

Tricky, I originally didn't post the entire code since it is long and ugly. Truthfully I am more of an embedded programmer and not a HDL guy. :confused: I'm sure that my coding style needs work. I appreciate any hints you can give me. Also, sorry for not following up on this thread very quickly, I get pulled away for other things quite frequently.

[Altera_Forum]

The code isn't really visual. :( 

 I found one place where asynchronous input signals can bring up illegal FSM states. It's related to the signals row and column (in fact very near to your initial post), that in return depends on the input signals UPDATE and RENA. If these signals are changed asynchronous to clock, curren_state can fall into a non-existing state encoding with multiple bits set. At worst case, it won't recover from this state without a reset.  Possible solutions: - synchronizing all input signals, that are direct or indirect inputs to the next_state logic - enforcing safe state machine encoding by synthesis attributes or settings.  Why can this happen? Consider that the state variable current_state is represented by multiple DFFs, one for each state according to the default one state hot encoding. Each DFF samples the input signals independently. If an input condition changes at the clock edge, it may be inconsistenly seen by the individual state bit DFFs. As a result, illegal state bit combinations can occur. Depending on the conditions in the state locgic, the FSM can be stuck in this illegal state. Safe state machine logic generates transitions to a legal state for all state bit combinations.

[Altera_Forum]

Sorry, I know the code isn't very readable:oops:. Are you referring to the process: ROISELECT?

[Altera_Forum]

--- Quote Start ---  Are you referring to the process: ROISELECT?  --- Quote End ---   Yes. UPDATE can cause timing violations if it's asynchronous to CLK. Other than said in my previous post, RENA can't, because it's sampled by UPDATE.