- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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 :(
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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;
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page