Trouble with rising edge signals in functional simulation

Hi,

I have a FF in my design whose reset and set are separate conditions:

process( rst, clk ) begin if ( rst = '1' ) then output

Reply to
arkaitz
Loading thread data ...

"arkaitz" escribió en el mensaje news: snipped-for-privacy@posting.google.com...

you have two resets on the same FF? one synchronous and another one asynchronous, but i guess you know that :) what are you using "output" for?

so you want to reset the first FF on a rising edge of "input"? then why dont you write the code like that then?

if you think it'd work in the reality because of the delays, you could use "after" on the signal assignations.

you could also try using the asynchronous reset of the first FF

but still, i dont think i understand what you're trying to do

Reply to
paris

Ask yourself: "What happens when both set and reset are simultaneously asserted?" You may have a problem here.

I notice that the second process doesn't have "elsif (clk'event ...)," rather, it's simply an "if" in parallel with the async reset. What does the signal "aux" look like in your simulation?

No, it looks like a coding error to me.

Reply to
Andy Peters

Arkaitz,

Logic looks OK except I would have used elsif clause. I suspect that your "input" signal, although synchronous, is external to the block you're simulating. If so, assert it _in_the_simulation_ on a falling clock edge. Think of it this way. Label the rising edges T=0,1,2,3. Then if input goes high on clk T=2, it really goes high "a little while after" T=2 but well before T=3 (we hope! but timing is outside the scope of functional simulation). So by asserting it at T=2.5 (ie falling edge) you're telling the simulator that "input" was low at T=2 but high at T=3... which is (hopefully) what you want. I found it confusing at first but got used to it after a while. Other people may think of it differently and perhaps more elegantly.

Hope this helps,

-rajeev-

Reply to
Rajeev

Hi,

Sorry. Was my fault when typewriting; I also use "elsif" clause in the second process instead of "if" clause.

Yes, the input signal is external to my block, it's a clock divider output and 3 clock period wide.

It could be a solution; I'll try it. But I cannot see why doesn't my design work. I have created another design where the input signal is an input port instead of an output of an internal register. I have simulated it functionally changing the input value from 0 to 1 together with a rising edge of the clock. As in the other case a glitch is appeared in the functional simulation but now the design works and the FF is reseted.

I cannot see why ModelSim works fine with an input port and not with the output of an internal FF.

Thanks in advance, Arkaitz.

--------------------------- Electronics Area IKERLAN Pº J. M. Arizmendiarrieta, 2

20500 Arrasate (Gipuzkoa)

---------------------------

Reply to
arkaitz

Back to your code:

I re-iterate again: Ask yourself: "What happens when both set and reset are simultaneously asserted?" You may have a problem here.

Does your simulation drive both set and reset at the same time?

Reply to
Andy Peters

Hi Andy,

No, firstly is driven the set signal and later (after some clk periods the reset signal). I now what I am doing when writing like this; in my design the reset has more priority than the set signal.

Thanks,

Arkaitz.

Reply to
arkaitz

"arkaitz" escribió en el mensaje news: snipped-for-privacy@posting.google.com...

in that case wouldnt be the reset "if" before the set "if"?

Reply to
paris

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.