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

[Tom D. <td...@di...>]

On 07/04/2012 04: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).
>
>> 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.

In my experience, sometimes you want the registers in the DSP48 block 
and other times not.

Again though, nothing we are talking about will box you into a certain 
type of reset and I think we are just talking about the default cases?

There I times when I want no reset, so shift registers can use the 
distributed memory in Xilinx FPGAs, but as long as I can control that 
from the logic description I am OK.