Tip/suppornt on debugging a VHDL project on Altera

Post the whole code, not just redacted sections. You most likely have a problem with your logic, but won't be able to tell unless everything is posted.

Kevin

Please post more code - the snippets you posted without indentation are rather confusing

On first glance - I worry whenever I see a signal called "clk" thats being checked in an if statement rather than being used as an actual clock.

Hello everybody

Thanks for answering that, and sorry if my mistakes were too basic.

Here follows the whole code for the process, if you may take a look. The signals are touched just after "WRITE OPERATION" comment.

In the meantime, I´m going to check the rst in the sensitivity list and see how it works.

Thanks again

-- Flash protocol handling process

flash_process(clk)

begin if(rst='1') thenflash_data <= "ZZZZZZZZ";

flash_opcode <= X"0";

flash_addr <= X"000000";

int_flash_en <= '0';

flash_erase_running <= '0';

flash_read_running <= '0';

flash_write_running <= '0';

etcmiv_data <= "ZZZZZZZZ";

etcmiv_data_rdy <= 'Z';

etcmiv_data_rdy_detected <= '0';

[/INDENT] -- ERASE OPERATION

elsif(rising_edge(clk)) thenif((etcmiv_flash_erase ='1') or (flash_erase_running= '1'))then

[/INDENT] if(etcmiv_flash_erase ='1') then -- first time

[/INDENT][/INDENT] flash_erase_running <= '1';

flash_addr <= erase_addr;

case(int_etcmiv_opcode) is

[/INDENT][/INDENT][/INDENT] when ERASE_INIT_PARAM_T | ERASE_DEF_PARAM_T | ERASE_AGC_T | ERASE_BPR_T =>

[/INDENT][/INDENT][/INDENT][/INDENT] flash_opcode <= ERASE_4K_OP;

[/INDENT][/INDENT][/INDENT][/INDENT] when ERASE_NUC_T | ERASE_MENU_T =>

[/INDENT][/INDENT][/INDENT][/INDENT] flash_opcode <= ERASE_64K_OP;

[/INDENT][/INDENT][/INDENT][/INDENT] when others => NULL;

[/INDENT][/INDENT][/INDENT][/INDENT] end case;

[/INDENT][/INDENT][/INDENT][/INDENT] else -- not first time, erase operation started

[/INDENT][/INDENT] if((clk_spi_flash = '1') and (int_flash_en = '0'))then -- flash_en should change only on a sck falling edge

[/INDENT][/INDENT][/INDENT] int_flash_en <= '1';

[/INDENT][/INDENT][/INDENT][/INDENT] elsif(flash_done = '1') then

[/INDENT][/INDENT][/INDENT] int_flash_en <= '0';

flash_erase_running <= '0';

end if;

[/INDENT][/INDENT][/INDENT][/INDENT] end if;

[/INDENT][/INDENT] -- WRITE OPERATION

elsif((etcmiv_flash_write = '1') or (flash_write_running = '1')) then

if(etcmiv_flash_write = '1') then -- first time

[/INDENT] flash_write_running <= '1';

flash_addr <= write_addr + operation_counter;

flash_opcode <= WRITE_FPGA_OP;

[/INDENT][/INDENT]else -- not first time, write operation started, but wait for data_rdy

[/INDENT] if((etcmiv_data_rdy = '1') and (int_flash_en = '0')) then

[/INDENT][/INDENT] etcmiv_data_rdy_detected <= '1';

end if;

[/INDENT][/INDENT][/INDENT] if((clk_spi_flash = '1') and (int_flash_en = '0') and (etcmiv_data_rdy_detected = '1'))then -- flash_en should change only on a sck falling edge

[/INDENT][/INDENT] int_flash_en <= '1';

flash_data <= etcmiv_data;

etcmiv_data_rdy_detected <= '0';

[/INDENT][/INDENT][/INDENT] elsif(flash_done = '1') then

[/INDENT][/INDENT] int_flash_en <= '0';

flash_write_running <= '0';

[/INDENT][/INDENT][/INDENT] end if;

[/INDENT][/INDENT] end if;

[/INDENT] -- READ OPERATION

elsif((etcmiv_flash_read = '1') or (flash_read_running = '1')) then

if(etcmiv_flash_read = '1') then -- first time

[/INDENT] flash_read_running <= '1';

flash_addr <= read_addr + operation_counter;

flash_opcode <= READ_FPGA_OP;

flash_data <= "ZZZZZZZZ";

[/INDENT][/INDENT] else -- not first time, read operation started

[/INDENT] if((clk_spi_flash = '1') and (int_flash_en = '0'))then -- flash_en should change only on a sck falling edge

[/INDENT][/INDENT] int_flash_en <= '1';

[/INDENT][/INDENT][/INDENT] elsif(flash_done = '1') then

[/INDENT][/INDENT] int_flash_en <= '0';

flash_read_running <= '0';

etcmiv_data <= flash_data;

etcmiv_data_is_ready<='1';etcmiv_data_rdy <= '0';

flash_data <= "ZZZZZZZZ";

[/INDENT][/INDENT][/INDENT] end if;

[/INDENT][/INDENT] end if;

[/INDENT] -- NO OPERATION

else

if(etcmiv_ready_to_get_data = '1') then

[/INDENT] etcmiv_data_rdy <= '1';

etcmiv_data_is_ready <= '0';

[/INDENT][/INDENT] elsif((etcmiv_data_rdy = '1') and (etcmiv_data_rdy_dly = '1') and (flash_data = "ZZZZZZZZ")) then -- assure etcmiv_data_rdy is active and stable, to assure etcmiv already got it

[/INDENT] etcmiv_data_rdy <= 'Z';

etcmiv_data <= "ZZZZZZZZ";

[/INDENT][/INDENT] end if;

flash_data <= "ZZZZZZZZ";

flash_opcode <= X"0";

flash_addr <= X"000000";

int_flash_en <= '0';

flash_erase_running <= '0';

flash_read_running <= '0';

flash_write_running <= '0';

[/INDENT] end if; -- operation

end if;

end process; -- flash_p

Hello cprodrigues, I see that there could be latches produced from the above code. This is because the signals are not assigned values in all reachable statements. Please correct that. Latches are not preferred in a very good logic design as they have unpredictable results or they generate glitches during the operation.

In the mean time you can design a state machine that does the above job in a very nice and glitch free way.

I see that int_flash_en signal will have very tight timing as you are checking the signal with in the process as well as assigning the same signal with different value. Please check your timing. This could be also a problem. all the best.

--- Quote Start ---

Hello cprodrigues, I see that there could be latches produced from the above code. This is because the signals are not assigned values in all reachable statements. Please correct that. Latches are not preferred in a very good logic design as they have unpredictable results or they generate glitches during the operation.

In the mean time you can design a state machine that does the above job in a very nice and glitch free way.

I see that int_flash_en signal will have very tight timing as you are checking the signal with in the process as well as assigning the same signal with different value. Please check your timing. This could be also a problem. all the best.

--- Quote End ---

There are no latches as it is a clocked process. When a signal is set, it's enable input is set high, with a mux selecting what input to use.

I will have a look at the code, and give my thoughts.

As for the reset, you probably didnt notice any difference. But you really should have it in the sensitivity list. Any inputs that affect outputs need to be in there. In the case of a clocked process, because things only change on clock edges, only the clock needs to be there.

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 Start ---

As for the reset, you probably didnt notice any difference. But you really should have it in the sensitivity list. Any inputs that affect outputs need to be in there. In the case of a clocked process, because things only change on clock edges, only the clock needs to be there.

--- Quote End ---

Not sure if I fully understood what you mean. Regarding rst, it´s ok, I got it. But I have more signals which affect outputs there (int_etcmiv_opcode, clk_spi_flash, just to name a few). Do they have to be in there also? But I just want my process to really do something on a clk edge (it means, inside a 'if(rising_edge(clk))' block), so it may have the same behavior with or without them on sensitivity list, or not?

Thanks for the support.