asynchronous reset coding technique

[Dave Dean]

I'm investigating the synthesis results of several different coding
techniques for an asynchronous reset, and was hoping to get some feedback,
particularly regarding the last method, which seems to work but I've never
seen used before. Anyway...

Method 1:
process(clk, reset)
begin
if (reset = '1') then
Q(0) <= '0';
Q(1) <= '0';
elsif (rising_edge(clk)) then
Q(0) <= D(0);
Q(1) <= D(1);
end if;
end process;
This results in two identical flip-flops, each with an asynchronous CLEAR
input. Good!

Method 2:
process(clk, reset)
begin
if (reset = '1') then
Q(0) <= '0';
--no reset for Q(1);
elsif (rising_edge(clk)) then
Q(0) <= D(0);
Q(1) <= D(1);
end if;
end process;
For Q(0), this results in the same flip-flop as method 1. For Q(1),
however, I get a flip-flop with no CLEAR input, but instead /reset is used
as a CE input. This makes sense, considering how the reset was coded.
Also, this is a fairly harmless result. I want reset to clear Q(0), and
have no effect on Q(1). Even with my accidental CE, my result will work.

But suppose I want to get rid of the CE? This would work:
Method 3:
process(clk, reset)
begin
if (reset = '1') then
Q(0) <= '0';
elsif (rising_edge(clk)) then
Q(0) <= D(0);
end if;
end process;
process(clk)
begin
if (rising_edge(clk)) then
Q(1) <= D(1);
end if;
end process;
This gives me what I really want. The same flip-flop again for Q(0), and a
flip-flop for Q(1) with no CLEAR or CE inputs.

Now, suppose I've already written up a fairly complex state machine in a
single process. However, I only want an asynchronous reset for the state
itself and a small handfull of registered outputs. One soultion, of course,
is to seperate the process into two - one with a reset for the registers
that need them, and one with no reset (like Method 3). The problem is, I
don't want to do that. It would become messy and too succeptible to
mistakes. But what about this solution (the one that seems to work but I've
never seen anywhere else)...

Method 5:
process(clk, reset)
begin
if (rising_edge(clk)) then
Q(0) <= D(0);
Q(1) <= D(1);
end if;
if (reset = '1') then
Q(0) <= '0';
end if;
end process;
This gives me exactly what I want - Q(0) gets an asynchronous reset, and
Q(1) has no clear or ce inputs.

The issue is - this frightens me because I've never seen it done this way,
and if it was a good technique, I would probably have seen someone do it
before.

Has anyone else ever tried writing a reset like this before?

Thanks,
Dave

 

[KJ]

Take a look at the thread titled "alternate synchronous process
template" that started on June 15 in this newsgroup (comp.lang.vhdl)
for a discussion on this exact topic.

KJ

 

[Mike Treseler]

Dave Dean wrote:

Method 5:
process(clk, reset)
begin
if (rising_edge(clk)) then
Q(0) <= D(0);
Q(1) <= D(1);
end if;
if (reset = '1') then
Q(0) <= '0';
end if;
end process;
This gives me exactly what I want - Q(0) gets an asynchronous reset, and
Q(1) has no clear or ce inputs.

I like all my flops to reset the same way for simulation,
but if this is exactly what you want, you are done.

The issue is - this frightens me because I've never seen it done this way,
and if it was a good technique, I would probably have seen someone do it
before.

Not true.
There are very few good examples of vhdl synthesis code.


-- Mike Treseler

 

[Kai Harrekilde-Petersen]

"Dave Dean" <dave.dean@xilinx.com> writes:

Method 5:
process(clk, reset)
begin
if (rising_edge(clk)) then
Q(0) <= D(0);
Q(1) <= D(1);
end if;
if (reset = '1') then
Q(0) <= '0';
end if;
end process;
This gives me exactly what I want - Q(0) gets an asynchronous reset, and
Q(1) has no clear or ce inputs.

The issue is - this frightens me because I've never seen it done this way,
and if it was a good technique, I would probably have seen someone do it
before.

Has anyone else ever tried writing a reset like this before?

I've seen exactly this method used for exactly the reasons you state.
However, I newer saw a chip coming back that was written in the style
suggested - the R&D team that used this technique got acquired by
another company and the project was terminated.

Kai
--
Kai Harrekilde-Petersen <khp(at)harrekilde(dot)dk>

 

[Mike Treseler]

Kai Harrekilde-Petersen wrote:

I've seen exactly this method used for exactly the reasons you state.
However, I newer saw a chip coming back that was written in the style
suggested - the R&D team that used this technique got acquired by
another company and the project was terminated.

I assume the project termination was
not correlated to coding style

-- Mike Treseler

 

[Kai Harrekilde-Petersen]

Mike Treseler <mike_treseler@comcast.net> writes:

Kai Harrekilde-Petersen wrote:

I've seen exactly this method used for exactly the reasons you state.
However, I newer saw a chip coming back that was written in the style
suggested - the R&D team that used this technique got acquired by
another company and the project was terminated.

I assume the project termination was
not correlated to coding style

Affirmative

Kai
--
Kai Harrekilde-Petersen <khp(at)harrekilde(dot)dk>

 

[KJ]

I assume the project termination was
not correlated to coding style

But no doubt the reason that the company was acquired in the first place WAS

because of the coding style...of that I'm sure

KJ

 

[Andy]

Mike Treseler wrote:

Dave Dean wrote:
The issue is - this frightens me because I've never seen it done this way,
and if it was a good technique, I would probably have seen someone do it
before.

Not true.
There are very few good examples of vhdl synthesis code.

Amen to that!

I've been using this method for several years now, and have had no
problems. Some FPGA resources do not have async resets (e.g. ram), and
this is the only way I've been able to code them in the same process
without getting a warning and extra circuitry to disable writes during
reset.

I only use it on processes that do not reset every flop. That keys me
to check more closely to make sure that I do reset the registers that I
wanted to be reset. (you don't get a warning about leaving a register
unreset using this method).

Andy