Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
15 years ago

Tip/suppornt on debugging a VHDL project on Altera

Hi

I have some experience on hdl coding, but none on FPGA debugging.

(which does not necessarily mean the problem may not be in my HDL coding... ;) )

I´m facing a weird (imho) situation in which two signals are touched within an 'if' block. In simulation everything is doing fine, but when I got it programmed and running on FPGA, only one of them is touched.

The piece of VHDL code is the following:

flash_process(clk)

begin

if(rst='1') then

............

int_flash_en <= '0';

etcmiv_data_rdy_detected <= '0';

............

elsif(rising_edge(clk)) then

if (..........) then

............

elsif(......) then

if(.....) then

.....

else

if((etcmiv_data_rdy = '1') and (int_flash_en = '0')) then

etcmiv_data_rdy_detected <= '1';

end if;

if((clk_spi_flash = '1') and (int_flash_en = '0') and (etcmiv_data_rdy_detected = '1'))then

int_flash_en <= '1';

etcmiv_data_rdy_detected <= '0';

........

.......

else

......

int_flash_en <= '0';

.......

The only places in code where these two signals (int_flash_en and etcmiv_data_rdy_detected) are touched are listed above. When running on FPGA, I got a positive pulse on etcmiv_data_rdy_detected, but int_flash_en remains untouched ('0'). I was supposing etcmiv_data_rdy_detected should only go down together with int_flash_en assertion. Is my assumption wrong?

Can anybody help me with some light on that?

I am using Quartus II 9.1 web edition and ModelSim Altera Starter Edition 6.5b. My FPGA is a CycloneIII EP3C25Q240C8N

Thanks in advance

Cristiano

13 Replies

Show More
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    --- Quote Start ---

    Here are my concerns:

    1. It looks like you're using "clk_spi_flash" in logic - is this really a clock, or is it some form of synchronised signal? This can cause all sorts of problems if it really is a clock, which wont be apparent in simulation

    2. You cannot compare signals to 'Z' on real hardware. What kind of logic circuit can detect that? Again, this would work fine in simulation, but not work in hardware.

    --- Quote End ---

    Regarding (1): Yes, it is really a clock. I need to synchronize the setting of int_flash_en with its edge. clk_spi_flash is about 4x slower than clk. Is there a better/correct way to handle this synchronizing? May it be my problem's root?

    Regarding (2): Ok, shame on myself... :(

    Yet, do you think I should try to code a state machine to ease coding and analysis? I thought it would be a simple code so I decided not to build a state machine, but it got more complex now I'm about to reconsider it.

    Thanks and regards
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    --- Quote Start ---

    Here are my concerns:

    1. It looks like you're using "clk_spi_flash" in logic - is this really a clock, or is it some form of synchronised signal? This can cause all sorts of problems if it really is a clock, which wont be apparent in simulation

    2. You cannot compare signals to 'Z' on real hardware. What kind of logic circuit can detect that? Again, this would work fine in simulation, but not work in hardware.

    --- Quote End ---

    Regarding (1): Yes, it is really a clock. I need to synchronize the setting of int_flash_en with its edge. clk_spi_flash is about 4x slower than clk. Is there a better/correct way to handle this synchronizing? May it be my problem's root?

    Regarding (2): Ok, shame on myself...

    Yet, do you think I should try to code a state machine to ease coding and analysis? I thought it would be a simple code so I decided not to build a state machine, but it got more complex now I'm about to reconsider it.

    Thanks and regards
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    Regarding sensitivity lists:

    sensitivity lists are there for simulation purposes. Synthesisors ignore them, but will probably warn you when something it missing. They tells the simulator when to re-analyse the process. Any event on the signals in the sensitivity list trigger it.

    This means that for a clocked process, because you only want outputs to change when the click rises, you only need to put clock in the sensitivity list. But if you wanted to build something like an asynchronous mux, you need to have all inputs in there: 

    
process(s, s0, s1);
begin
  case s is
    when 0 => 
      output <= s0;
    when 1 =>
      output <= s1;
  end case;  
end process;

    Here, you change output whenever s changes, but also if S=0, you need the change the ouput whenever s0 changes.

    Now, if it was a clocked mux, you'd just have clock in there, because you only reasses "output" when the clock changes.

    Now to your problems:

    The problem with sampling clocks is that unless they are synchronised or related, they are most likely going to drift in and out of phase. So you could sample it at 0, or 1, or somewhere in between and get meta stability. Always use normal logic outputs in any other logic, never clocks or asynchronous signals.

    As for your question about state machines - its up to you. If it's easier for other people (and yourself when you come back to this code in 6 months time) to understand whats going on, then do it.