Re: [myhdl-list] Reset functionality "synthesis"

[Angel E. <ang...@gm...>]

On Wed, Jul 4, 2012 at 11:05 AM, Jan Decaluwe <ja...@ja...> wrote:
> On 07/04/2012 07:57 AM, Angel Ezquerra wrote:
>
>> Particularly, on section "Use of Resets and Performance" it describes
>> why synchronous reset should be used. It summarizes its advice as
>> follows:
>>
>> "Avoid asynchronous reset because it prevents packing of registers
>> into dedicated
>> resources and affects performance, utilization, and tool optimizations."
>
> I believe what is what Xilinx is doing here is pushing its own
> problem to designers. Of course I understand that using a synchronous
> reset or no reset can result in a more "optimal" design.
> What I don't understand is why a synthesis tool wouldn't be able
> to prove that some resets in dedicated resources are unnecessary,
> e.g. in a shift register.

I guess the synthesis tool tries to implement what the user described
in code, even if it does not make much sense. That is, if you try to
use an asynchronous reset on a DSP48 block, whose builtin registers do
not have one, the synthesis tool must choose between using extra logic
or implementing something that is not exactly that the user described.
IMHOW it makes sense for it to follow what the user asked (and show a
warning, as Xilinx ISE does).

> As for synchronous reset, my question remains: what if your system
> is such that you don't have reliable clocks during power-on-reset?
>
> Altera agrees, because they document the scheme I described
> as "preferred when designing an FPGA circuit" here:
>
> http://www.altera.com/literature/hb/qts/qts_qii51006.pdf
>
>> As for the technique that you described to use an asynchronous reset
>> whose deassert is synchronous with the clock, I'm unsure how that
>> would work with a Xilinx FPGA. In our system we have an external,
>> asynchronous (by definition) signal which we register on each our our
>> clock domains, converting it into a synchronous signal which we use as
>> a synchronous reset. So the global reset is asynchronous, but the
>> different module resets are synchronous.
>
> Here is an article from a Xilinx application engineer that describes
> that technique exactly. It seems Xilinx has caught up with
> the real world :-)
>
> http://www.eetimes.com/design/programmable-logic/4218673/How-do-I-reset-my-FPGA-

The funny thing is that one of the quotes on my previous reply came
from that very same article :-)

If I understand what you and that article are proposing, this scheme
is a valid answer to the question that you asked: what if your system
is such that you don't have reliable clocks during power-on-reset?

To do so, it takes take an external, asynchronous reset, and generate
a "synchronous deassert" reset signal that is then used by all the
entities on a given clock domain. Is that correct?

In a sense, you could say that this is neither a synchronous nor an
asynchronous reset, since it is asynchronous when the reset is
asserted, but synchronous when deasserted.

Once you have this "safe" reset, you feed it into the blocks on the
corresponding clock domain where you use it synchronously or
asynchronously. Even if it is "clock safe" that does not change the
fact that you can still not use an asynchronous reset on a DSP48 block
for example, unless you want to pay the price in terms of extra logic
and timing.

>> So I personally would make both the reset type and the active high/low
>> settings explicit. Given that as you said this will probably be done
>> only once I think it would probably even make the code more readable.
>
> Yes, I can see that point. And of course, we can turn the whole
> thing to our advantage by showing that you can switch between the
> various styles without changing the code, by merely changing the
> reset constructor.

That is a very good point.

I wonder, if you feel that the scheme that you and the article you
linked described are such a good practice (and I agree), perhaps the
ResetSignal class could somehow support it as well?

Angel