Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > asynchronous reset coding technique

Reply
Thread Tools

asynchronous reset coding technique

 
 
Dave Dean
Guest
Posts: n/a
 
      07-17-2006
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


 
Reply With Quote
 
 
 
 
KJ
Guest
Posts: n/a
 
      07-17-2006
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

 
Reply With Quote
 
 
 
 
Mike Treseler
Guest
Posts: n/a
 
      07-17-2006
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
 
Reply With Quote
 
Kai Harrekilde-Petersen
Guest
Posts: n/a
 
      07-18-2006
"Dave Dean" <(E-Mail Removed)> 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>
 
Reply With Quote
 
Mike Treseler
Guest
Posts: n/a
 
      07-18-2006
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
 
Reply With Quote
 
Kai Harrekilde-Petersen
Guest
Posts: n/a
 
      07-18-2006
Mike Treseler <(E-Mail Removed)> 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>
 
Reply With Quote
 
KJ
Guest
Posts: n/a
 
      07-18-2006
> 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


 
Reply With Quote
 
Andy
Guest
Posts: n/a
 
      07-19-2006

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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
asynchronous reset, simulator doesn't support Clunixchit VHDL 9 09-05-2007 09:37 PM
LOAD on asynchronous RESET patrick.melet@dmradiocom.fr VHDL 4 11-23-2006 04:29 PM
THE BEHAVIOR CODE FOR 24-BITUP/DOWN COUNTER WITH PARALLEL LOAD AND ASYNCHRONOUS RESET coldplay112 VHDL 2 09-25-2006 10:06 AM
Reset asynchronous assertion synchronous deassertion arant VHDL 1 08-15-2006 07:00 PM
Coding an Asynchronous state machine Jamie VHDL 13 10-23-2003 08:41 AM



Advertisments