Re: [myhdl-list] Reset functionality "synthesis"
Brought to you by:
jandecaluwe
From: Jan D. <ja...@ja...> - 2012-07-03 21:05:09
|
On 07/03/2012 08:45 PM, Jan Decaluwe wrote: > On 07/03/2012 06:40 PM, Angel Ezquerra wrote: > >> >> Jan, >> >> given how contentious the asynchronous vs synchronous reset debate is >> I would argue that there should be no default value in this case, and >> that the reset type should always be set explicitly. > > I am quite surprized by this, is this really so contentious? > In my whole career as a design engineer, I don't recall one > single incident about this (many about other issues :-)). > > Actually, I have *always* used the mixed approach, where you > go into reset asynchronously, but come out of it synchronously. > In this method, the reset driver comes out of a ff that > is reset asychronously with the primary reset, and that > also synchronizes the primary reset. > > For this to work, the ffs in the design should have > an asynchronous reset, but that doesn't mean the > reset scheme itself is asynchronous, as described. > The big advantage of this method is that you don't > need the clock to be present to go into reset, > only to come out of it. So you avoid power-up issues > with clocks and pll's. > > I thought this was the standard practice, which is why > I intuitively made it the default. > > I'd like to hear more opinions. One more point: if the style is explicit, I think the active level should be also, for consistency. One could argue that it's not that bad, only once as opposed to scattered through the code as currently. But then again, I would think that active low and asynchronous covers 99% of the practical cases ... or not? Undecided. -- 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 |