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

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

On Wed, Jul 4, 2012 at 1:46 PM, Jan Decaluwe <ja...@ja...> wrote:
> 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.

I see. It seems that there is no perfect solution for Xilinx FPGAs
then, unless you design your system to somehow guarantee that you'll
always get a stable clock before the reset.

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

Probably.

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

I see. I misunderstood how the ResetSignal would be used in that scenario.

Angel