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

[Jan D. <ja...@ja...>]

On 07/04/2012 11:27 AM, Angel Ezquerra wrote:
> 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).

I define "what the user described" as the I/O behavior. Within
that constraint, a synthesi tool has all the freedom, e.g. by
optimizing away redundancy. That's what it does all the time, e.g.
when you describe two additions, it doesn't necessarily infer
two adders if it can prove exclusivity. Or when a bit of some
register is driven by a constant value (not always trivial to
spot in arithmetic), it is optimized away.

>> 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?

Yes.

> 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?

Yes - with this caveat: that reset signal should feed into the
asynchronous reset of a ff for the scheme to work.

> 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.

Correct.

The terminology can be confusing as we use synchronous/asynchronous
at two levels: global and at the ff level, and the two don't coincide
completely.

> 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.

When you use it as a synchronous reset at the ff level, you lose the
advantage, as the power-on-reset problem is not solved.

>>> 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 start to like it. By require explicit settings, we draw attention
to the fact that it is trivial to support various schemes, in
contrast to current art. A marketing decision, as it were :-)

Also, an active high reset may be more common than the sync style?

> 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?

Not sure what you mean. The output of a "reset bridge"
as described in the Xilinx article should be a ResetSignal
instance, so that is supported.

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com