- Contrassegnare come Nuovo
- Preferito
- Iscriversi
- Disattiva notifiche
- Iscriversi a feed RSS
- Evidenziare
- Stampare
- Segnalare contenuto inappropriato
I realized there is difference in output obtained from Altera-Modelsim simulation using .vho file (full compilation file from Quartus) and using the vhdl files directly.
Any explanations for this and which method should I go for? Thank youLink copiato
- Contrassegnare come Nuovo
- Preferito
- Iscriversi
- Disattiva notifiche
- Iscriversi a feed RSS
- Evidenziare
- Stampare
- Segnalare contenuto inappropriato
If the file from Quartus is a netlist, and you get differences in your simulation, then I suggest that you have a problem in your design.
Is your design fully synchronous? Does it have lots of asynchronous logic? Have you got all of the appropriate signals in sensitivity lists?- Contrassegnare come Nuovo
- Preferito
- Iscriversi
- Disattiva notifiche
- Iscriversi a feed RSS
- Evidenziare
- Stampare
- Segnalare contenuto inappropriato
--- Quote Start --- If the file from Quartus is a netlist, and you get differences in your simulation, then I suggest that you have a problem in your design. Is your design fully synchronous? Does it have lots of asynchronous logic? Have you got all of the appropriate signals in sensitivity lists? --- Quote End --- Hi, thanks for the reply. The design is asynchronous. and yes I do suspect something wrong with my design. Which one reflects the real outcome from my design? The simulation from VHO file or File Simulation. I also realized the waveform from VHO Simulation is one cycle delayed compared to the simulation directly from VHDL File :(
- Contrassegnare come Nuovo
- Preferito
- Iscriversi
- Disattiva notifiche
- Iscriversi a feed RSS
- Evidenziare
- Stampare
- Segnalare contenuto inappropriato
The simulation from the compiled VHO files will reflect what is likely to happen on the chip. If it is asynchronous then I suspect you didnt take into account logic path delays in your design.
Asynchronous designs are tricky to work with as they are full of race conditions and timing issues, and can be affected by PVT (process, voltage, temperature). I highly suggest you synchronise your design (what FPGAs are designed for) as it makes a design predictable. It might be worth posting your code to see if we can see any problems with it.- Contrassegnare come Nuovo
- Preferito
- Iscriversi
- Disattiva notifiche
- Iscriversi a feed RSS
- Evidenziare
- Stampare
- Segnalare contenuto inappropriato
--- Quote Start --- The simulation from the compiled VHO files will reflect what is likely to happen on the chip. If it is asynchronous then I suspect you didnt take into account logic path delays in your design. Asynchronous designs are tricky to work with as they are full of race conditions and timing issues, and can be affected by PVT (process, voltage, temperature). I highly suggest you synchronise your design (what FPGAs are designed for) as it makes a design predictable. It might be worth posting your code to see if we can see any problems with it. --- Quote End --- I will try to look into the codings again. The code is quite messy at the moment, however I have posted the top levels and also the simulation waveform using both VHO file and VHDL files. Hopefully someone can pinpoint my mistakes here. Thanks alot
- Contrassegnare come Nuovo
- Preferito
- Iscriversi
- Disattiva notifiche
- Iscriversi a feed RSS
- Evidenziare
- Stampare
- Segnalare contenuto inappropriato
What you have posted is fairly meaningless without the code. But you say they design was asynchronous, but every component uses a clock - is it not synchronous?
- Contrassegnare come Nuovo
- Preferito
- Iscriversi
- Disattiva notifiche
- Iscriversi a feed RSS
- Evidenziare
- Stampare
- Segnalare contenuto inappropriato
--- Quote Start --- What you have posted is fairly meaningless without the code. But you say they design was asynchronous, but every component uses a clock - is it not synchronous? --- Quote End --- Sorry I got mixed up with my another coding. Yea this one is synchronous system and the output are same for both VHO simulation and filesimulation but difference in the arrival of the outdata. VHO simulation produces an additional clock cycle compare to filesimulation.
- Contrassegnare come Nuovo
- Preferito
- Iscriversi
- Disattiva notifiche
- Iscriversi a feed RSS
- Evidenziare
- Stampare
- Segnalare contenuto inappropriato
Have you re-assigned the clock anywhere internally other than the port maps, like:
my_internal_clock_signal <= sys_clk;
Can you post the code for your testbench? Without the code - we can only guess.
- Contrassegnare come Nuovo
- Preferito
- Iscriversi
- Disattiva notifiche
- Iscriversi a feed RSS
- Evidenziare
- Stampare
- Segnalare contenuto inappropriato
--- Quote Start --- Have you re-assigned the clock anywhere internally other than the port maps, like:
my_internal_clock_signal <= sys_clk;
Can you post the code for your testbench? Without the code - we can only guess. --- Quote End ---
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
USE ieee.std_logic_unsigned.all;
USE ieee.numeric_std.ALL;
ENTITY SubBytes_TB IS
END SubBytes_TB;
ARCHITECTURE behavior OF SubBytes_TB IS
-- Component Declaration for the Unit Under Test (UUT)
COMPONENT SubBytes
PORT(
SubBytes_IN : IN std_logic_vector(127 downto 0);
SubBytes_OUT : OUT std_logic_vector(127 downto 0);
SYS_CLK : IN std_logic;
RST : IN std_logic
);
END COMPONENT;
--Inputs
signal SubBytes_IN : std_logic_vector(127 downto 0) := (others => '0');
signal SYS_CLK : std_logic := '0';
signal RST : std_logic := '0';
--Outputs
signal SubBytes_OUT : std_logic_vector(127 downto 0);
-- Clock period definitions
constant SYS_CLK_period : time := 20 ns;
SIGNAL CORRECT_OUTPUT : std_logic_vector(127 downto 0) := (others => '0');
BEGIN
-- Instantiate the Unit Under Test (UUT)
uut: SubBytes PORT MAP (
SubBytes_IN => SubBytes_IN,
SubBytes_OUT => SubBytes_OUT,
SYS_CLK => SYS_CLK,
RST => RST
);
-- Clock process definitions
SYS_CLK_process :process
begin
SYS_CLK <= '1';
wait for SYS_CLK_period/2;
SYS_CLK <= '0';
wait for SYS_CLK_period/2;
end process;
-- Stimulus process
stim_proc: process
begin
-- hold reset state for 100 ms.
wait for SYS_CLK_period*10;
SubBytes_IN <= X"193de3bea0f4e22b9ac68d2ae9f84808";
CORRECT_OUTPUT <= X"d42711aee0bf98f1b8b45de51e415230";
Wait for SYS_CLK_period*1;
SubBytes_IN <= X"000102030405060708090A0B0C0D0E0F";
CORRECT_OUTPUT <= X"637c777bf26b6fc53001672bfed7ab76";
wait;
end process;
END;
- Contrassegnare come Nuovo
- Preferito
- Iscriversi
- Disattiva notifiche
- Iscriversi a feed RSS
- Evidenziare
- Stampare
- Segnalare contenuto inappropriato
This is likely your problem:
wait for SYS_CLK_period*10;
Doing this means the SubBytes_IN and CORRECT_OUTPUT signals will change just before the clock changes, making it look like it a pipeline stage has dissapeared. Instead, do this:
for i in 1 to 10 loop
wait until rising_edge(SYS_CLK);
end loop;
While waiting in a testbench - if the inputs are related to the clock, always wait for the clock - dont wait for a specific time.
- Contrassegnare come Nuovo
- Preferito
- Iscriversi
- Disattiva notifiche
- Iscriversi a feed RSS
- Evidenziare
- Stampare
- Segnalare contenuto inappropriato
--- Quote Start --- This is likely your problem:
wait for SYS_CLK_period*10;
Doing this means the SubBytes_IN and CORRECT_OUTPUT signals will change just before the clock changes, making it look like it a pipeline stage has dissapeared. Instead, do this:
for i in 1 to 10 loop
wait until rising_edge(SYS_CLK);
end loop;
While waiting in a testbench - if the inputs are related to the clock, always wait for the clock - dont wait for a specific time. --- Quote End --- Yes you are right! The wait for period and wait for an event does make a difference here.

- Iscriversi a feed RSS
- Contrassegnare la discussione come nuova
- Contrassegnare la discussione come letta
- Sposta questo Discussione per l'utente corrente
- Preferito
- Iscriversi
- Pagina in versione di stampa