Testbench using Modelsim/VHDL - simple signal generation problem

I'm not sure if this is VHDL or Modelsim issue (other than operator issue), so I'm posting in both groups. It looks like too simple a case to ask someone online, but I've been scratching my head too long on this. I'm relatively new to VHDL (and Modelsim as well).

In a testbench, I'm doing a simple signal generation :

- assert 'sig1' at a rising edge of a free running clock at some point

- deassert 'sig1' at the next rising edge

- and on the 3rd edge, do some checking, and so on...

However, the simlation waveform shows that 'sig1' is asserted from 2nd to 3rd clock edge, instead of being asserted from 1st to 2nd edge.

What am I doing wrong? I've included both snippets from the testbench and the debug output. I expected 'sig1' asserted from 314 to 318ns. Simulation waveform shows assertion from 318 to 322 ns instead. Any help would be appreciated.

# ---------------- in a test bench ------------------- # Wait for a rising edge, and bring 'sig1' high wait until rising_edge(clk); write (L, string'("1st rising edge : " & image(now))); writeline (output, L); sig1

Reply to
fastgreen2000
Loading thread data ...

Not seeing more of your testbench, it is difficult to diagnose, but maybe, your "free-running clock" is something like this:

process begin loop clock

Reply to
Zara

Try it again with the signal assignments before the waits.

-- Mike Treseler

Reply to
Mike Treseler

Yes, I'm doing just that for creating clock, and your post shed some light on what I wasn't paying attention to, but...

I'm still confused. In the following testbench code, shouldn't it wait for a certain rising edge (whatever time it might correspond to), and assert 'sig1', at the time reported by 'now'? What I see is 'sig1' get asserted one clock after that.

line 1 : wait until rising_edge(clk); line 2 : write (L, string'("1st rising edge : " & image(now))); line 3 : writeline (output, L); line 4 : sig1

Reply to
fastgreen2000

Sure thing. But when I do that, I expect the signal assertion duration has shifted as well. I can fiddle the code to do whatever I want it to do, but I'm trying to figure out why it mismatches with my expected behavior... maybe I wasn't clear in my original posting...

Reply to
fastgreen2000

So you tell me that now is printed as 314 ns, but sig1 rises at 318 ns? If that is so, it is unexpected for me too!

Reply to
Zara

If you can boil down what you are seeing to under 20 lines of code, and post the 20 lines, I think people will be in a better position to identify the issue.

-Newman

Reply to
Newman

I simulated your code with modelsim, and aside from different times:

1st rising edge : 1015000 ps 1st rising edge (again) : 1015000 ps 2nd rising edge : 1023000 ps 3rd rising edge : 1031000 ps I see sig 1 asserted from 1015000 ps to 1023000 ps. So something else appears to be going on in your case.
Reply to
Duane Clark

I'm glad you don't see the same problem, because that would've puzzled others as well.

Would you mind posting what your testbench looks like? I initially suspected my clock generation as Zara suggested, but that doesn't quite make sense to me. I'll use process of elimination on differences and see what's causing this. I'll post the result as well.

TIA.

Reply to
fastgreen2000

Watch out for line wrap...

library ieee ; use ieee.std_logic_1164.all ; use ieee.std_logic_textio.all ; use std.textio.all ;

entity test is end entity test;

architecture tester of test is constant CLK_PRD : Time := 10 nS; signal Clk : std_logic; signal sig1 : std_logic; begin

tester_p: process is file output : text open write_mode is "test.out"; variable L : line; begin sig1

Reply to
Duane Clark

It would be a case if delta cycle in simulator is set to the sam value as clk period

Reply to
perica

If you see it go high late.. then it would tend to disagree with the results you printed on the first page.

In saying that.. if you are looking in the wrong place this is quite possible if you are peeking in a process.. then check the sensitivity list.. that's the usual culprit when things don't happen when you expect.

Simon

Reply to
Simon Peacock

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.