Are actions permitted on rising *and* falling edge of clock?

[Anon Anon]

I have a test-bed that is exercising my entity, setting some inputs and
then setting an 'Execute' bit to force the entity to do its stuff. The
entity is designed to begin execution on the leading edge of the Execute
bit, which clearly means that the test-bed has to reset this at some
convenient time. Unfortunately, the test-bed doesn’t really include any
slack time in which to do this, so I have coded it along these lines:


Testbed:

process exercise_the_entity(clk)
begin
if rising_edge(clk) then
<set up data etc for the entity>
Execute <= ‘1’; -- start the processing
Else -- must be falling edge of CLK
Execute <= ‘0’; -- clear the flag, in case it’s set
End if;
end process;

This doesn’t feel right to me, since it means that I’m making changes on
the falling edge of the clock – which I understand to be a bad thing.
Can anybody suggest a better approach?

In addition, is this likely to be synthesisable?

Thanks

 

[Paul Uiterlinden]

Testbed:

process exercise_the_entity(clk)
begin
if rising_edge(clk) then
<set up data etc for the entity>
Execute <= ‘1’; -- start the processing
Else -- must be falling edge of CLK
Execute <= ‘0’; -- clear the flag, in case it’s set
End if;
end process;

In a testbed (testbench) you usually write behavioral code, so there are no
restriction on constructs you can use. This includes using both edges of a
clock.

This doesn’t feel right to me, since it means that I’m making changes on
the falling edge of the clock – which I understand to be a bad thing.

Things are not bad "per definition". Using the falling edge of a clock in a
testbench is one of those things.

In addition, is this likely to be synthesisable?

No, but does that matter? As I understand, this is testbench code, which
normally is not synthesized. Unless you are trying to load part of the
testbench in an emulator.

 

[Andy]

Synplify Pro, and I believe others, can synthesize descriptions of DDR
output registers (in the IOB's). However, I would not use just else,
but "elsif falling_edge(clk)" even in testbench code, since there are
events on signals that may not be either edge (transition from H to 1,
etc.) The template may require the second edge condition, not just an
else, especially if there is an async reset.

Finally, at least synplify pro, precision and I think Quartus allow
both edges in one process regardless of whether it can be targetted to
a DDR IOB register, but you cannot assign to the same variable/signal
on both edges.

If you truly need dual edge functionality in the body of the FPGA
(with only SDR flops), something like the following will work without
glitches and with no clock gating:

qr <= d xor qf when rising_edge(clk);
qf <= d xor qr when falling_edge(clk);
q <= qr xor qf;

Synplify pro and quartus allow the above to be rewritten in a single
process with variables. The last time I tried it (several months ago,
they may have it fixed by now), Precision did not implement the
following correctly. XST does not allow this style.

process (clk) is
variable qr, qf : std_logic;
begin
if rising_edge(clk) then
qr := d xor qf; -- registered encode
elsif falling_edge(clk) then
qf := d xor qr; -- registered encode
end if;
q <= qr xor qf; -- combinatorial decode
end process;

Andy