"Correct design" and practical trouble and simulation trouble but why

Hi,

I wonder why this results in undefined values for some time:

---------------------------------- library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL;

-- Uncomment the following lines to use the declarations that are

-- provided for instantiating Xilinx primitive components.

--library UNISIM;

--use UNISIM.VComponents.all;

entity trigger_level is Port ( clk : in std_logic; prescale : in std_logic; din : in std_logic_vector(7 downto 0); level : in std_logic_vector(7 downto 0); rf : in std_logic; hold : in std_logic; trig : out std_logic); end trigger_level;

architecture Behavioral of trigger_level is type samples_buffer is array(9 downto 0) of std_logic_vector(7 downto 0);

signal samples : samples_buffer; begin

process(clk) begin if rising_edge(clk) and prescale = '1' and hold = '0' then -- no reset circuit (not needed) for reducing the number of slices to 1 instead of 5 for i in 9 downto 1 loop samples(i)

Reply to
Preben Holm
Loading thread data ...

The simulation shows that your getting unknown values, not uninitialised

The code seems Ok for me. A simulation of the code itself should show no error.

The simulation shows a timing violation. It is likely that the timing violation leads to an X. You should check the timing of your design, maybe you didnt reach the used clock frequency or you have trouble with asynchronous inputs.

bye Thomas

Reply to
Thomas Stanka

Does the plot show a functional or a timing simulation ?

Rgds André

Reply to
ALuPin

It's a post-map simulation

But I don't think the functional error of the design is a problem in the implemented version (but anyway I would like it to simulate perfectly, for future faster implementation (only running 50/7 MHz on real design)).

Thanks for helping Preben Holm

Reply to
Preben Holm

Looks like it's a functional simulation. Are you sure you don't drive trig from the test bench _also_ ??? or don't you drive trig by two sources ?

btw : you should adopt a more robust coding style : use async reset, do not mix enable and clock in the same test etc...

Reply to
Bert Cuzeau

Post-map (but only for the single module) I haven't really found out how to write a testbench that "looks" into a single module of a whole design - the module should work stand alone.

Yes I'm sure.

Async reset? Why not sync reset?

And you mean

if rising_edge(clk) and hold = '1' then ... end if; is worse than if rising_edge(clk) then if hold = '1' then ... end if; end if;

Thanks for your expertise!

Preben Holm

Reply to
Preben Holm

What do you mean ? You have a test bench and do a post-map pre-layout unitary timing simulation ? Did you attach the sdf file properly ? (I don't see delays in the output)

Did you perform functional sim and did it work ?

Seems you simulate a 100Mhz clock. What does the Static timing Analysis report (when you P&R) ?

BTW: Didn't you change the inputs at the same time as the rising edge of the clock ? The zoom of the waveform wasn't high but it looked like you did. A simple (& better) idea is to change (apply) the inputs on the inactive (falling) edge of the clock. Simpler to understand in functional sim, and definitely more friendly in timing sim !

Anyway, the weirdest things often have the simplest explanations ! I guess this is the case here and the solution could be trivial. If you post all your code, we could help you.

Long debate, refer to previous posts. Sync reset isn't bad intrinsically. Your call.

Yes ! Definitely worse !

Some synthesis tool may believe that you want a gated clock. I'm sure you don't want this, do you ???

I published a VHDL coding style guide which probably would have avoided these issues. See

formatting link
and
formatting link

Bert Cuzeau

Reply to
info_

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.