Thread: Re: [myhdl-list] Reset functionality "synthesis" (Page 2)
Brought to you by:
jandecaluwe
Menu
▾
▴
myhdl-list
|
From: Angel E. <ang...@gm...> - 2012-07-05 15:50:34
|
On Thu, Jul 5, 2012 at 5:27 PM, Jan Decaluwe <ja...@ja...> wrote: > On 07/04/2012 09:21 PM, Christopher Felton wrote: > >>> >> >> I'm getting to this conversation a little late. It sounds >> like we decided explicitly listing the /level/ and /async/ >> is preferred. I am ok with this. > > I think that's how it's going to be. > >> If it wasn't enforced >> (I am ambivalent if is should be enforced) I would adopt >> the style to always list, I like how it looks. >> >> reset = ResetSignal(0, level=False, async=True) > > Make that 'active' instead of 'level', e.g. active=LOW > >> I use the common async assert, sync release type resets, >> as well. >> >> With the /always_seq/ something that might be worth discussing >> is the inclusion of clock gating. Clock gating is used >> frequently in ASIC designs and is becoming more common in >> FPGA designs. A clock gating description might look like the >> following with the original @always construct. >> >> @always(clock.posedge, reset.negedge) >> def hld(): >> if not reset: >> ... >> else: >> if(enable) : # clock gate signal >> x.next = somethingAwesome or somethingGreat > > I guess the intention is that dff's with enables are inferred > when available. We should find out what the exact templates are > in Verilog and VHDL that support this e.g. probably the enable > condition should be and'ed with the clock edge condition in > VHDL. I believe that if you do "if enable = '1' then" right after your "if rising_edge(CLK) then" Xilinx ISE will properly infer the clock enable. I can confirm it tomorrow. Cheers, Angel |
|
From: Tom D. <td...@di...> - 2012-07-05 16:28:09
|
On 07/05/2012 10:50 AM, Angel Ezquerra wrote: > On Thu, Jul 5, 2012 at 5:27 PM, Jan Decaluwe <ja...@ja...> wrote: >> On 07/04/2012 09:21 PM, Christopher Felton wrote: >> >>> I'm getting to this conversation a little late. It sounds >>> like we decided explicitly listing the /level/ and /async/ >>> is preferred. I am ok with this. >> I think that's how it's going to be. >> >>> If it wasn't enforced >>> (I am ambivalent if is should be enforced) I would adopt >>> the style to always list, I like how it looks. >>> >>> reset = ResetSignal(0, level=False, async=True) >> Make that 'active' instead of 'level', e.g. active=LOW >> >>> I use the common async assert, sync release type resets, >>> as well. >>> >>> With the /always_seq/ something that might be worth discussing >>> is the inclusion of clock gating. Clock gating is used >>> frequently in ASIC designs and is becoming more common in >>> FPGA designs. A clock gating description might look like the >>> following with the original @always construct. >>> >>> @always(clock.posedge, reset.negedge) >>> def hld(): >>> if not reset: >>> ... >>> else: >>> if(enable) : # clock gate signal >>> x.next = somethingAwesome or somethingGreat >> I guess the intention is that dff's with enables are inferred >> when available. We should find out what the exact templates are >> in Verilog and VHDL that support this e.g. probably the enable >> condition should be and'ed with the clock edge condition in >> VHDL. > I believe that if you do "if enable = '1' then" right after your "if > rising_edge(CLK) then" Xilinx ISE will properly infer the clock > enable. I can confirm it tomorrow. That would work if we are talking about trying to use the clock enable on the DFFs. But when I hear clock gating that makes me think you are trying to actually stop the clock to the DFF? Could be to save power? The synthesis tools try hard to utilize the clock enable inputs. |
|
From: Jan D. <ja...@ja...> - 2012-07-06 10:45:24
|
On 07/06/2012 05:00 AM, Christopher Felton wrote: > From my understanding (and what I agree with) is that the > /@always_seq/ requires a reset. If you don't want a reset > you will need to use the /@always(clock.posedge)/. If you > use the /@always_seq/ it requires a reset. That's not quite right. The @always_seq decorator needs a reset *argument*, that is correct. However it can be 'None' to indicate explicitly that you don't want a reset: @always_seq(clock.posedge, reset=None) ... A reviewer will have no doubt what the intention is. In the case of a traditional always block, he may think you have delayed the reset coding (e.g. because it's boring) and forgotten about it. -- 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 |
|
From: Christopher F. <chr...@gm...> - 2012-07-06 14:01:44
|
On Friday, July 6, 2012, Jan Decaluwe wrote: > On 07/06/2012 05:00 AM, Christopher Felton wrote: > > > > From my understanding (and what I agree with) is that the > > /@always_seq/ requires a reset. If you don't want a reset > > you will need to use the /@always(clock.posedge)/. If you > > use the /@always_seq/ it requires a reset. > > That's not quite right. > > The @always_seq decorator needs a reset *argument*, that is > correct. However it can be 'None' to indicate explicitly that > you don't want a reset: > > @always_seq(clock.posedge, reset=None) > ... > > A reviewer will have no doubt what the intention is. > In the case of a traditional always block, he may think > you have delayed the reset coding (e.g. because it's > boring) and forgotten about it. > > How quickly I forget. Thanks for the correction, it all makes sense. Chris |
|
From: Tom D. <td...@di...> - 2012-07-05 16:20:15
|
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. |
|
From: Jan D. <ja...@ja...> - 2012-07-06 10:38:57
|
On 07/05/2012 06:20 PM, Tom Dillon wrote: > > In my experience, sometimes you want the registers in the DSP48 block > and other times not. Ok. > Again though, nothing we are talking about will box you into a certain > type of reset Exactly. > I think we are just talking about the default cases? Actually we are considering whether we should have default case or not for a ResetSignal. I'm convinced now that having no defaults at all is the best option. > 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. Ok. -- 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 |
|
From: Christopher F. <chr...@gm...> - 2012-07-06 03:44:37
|
On 7/5/12 11:28 AM, Tom Dillon wrote: > > On 07/05/2012 10:50 AM, Angel Ezquerra wrote: >> On Thu, Jul 5, 2012 at 5:27 PM, Jan Decaluwe <ja...@ja...> wrote: >>> On 07/04/2012 09:21 PM, Christopher Felton wrote: >>> >>>> I'm getting to this conversation a little late. It sounds >>>> like we decided explicitly listing the /level/ and /async/ >>>> is preferred. I am ok with this. >>> I think that's how it's going to be. >>> >>>> If it wasn't enforced >>>> (I am ambivalent if is should be enforced) I would adopt >>>> the style to always list, I like how it looks. >>>> >>>> reset = ResetSignal(0, level=False, async=True) >>> Make that 'active' instead of 'level', e.g. active=LOW >>> >>>> I use the common async assert, sync release type resets, >>>> as well. >>>> >>>> With the /always_seq/ something that might be worth discussing >>>> is the inclusion of clock gating. Clock gating is used >>>> frequently in ASIC designs and is becoming more common in >>>> FPGA designs. A clock gating description might look like the >>>> following with the original @always construct. >>>> >>>> @always(clock.posedge, reset.negedge) >>>> def hld(): >>>> if not reset: >>>> ... >>>> else: >>>> if(enable) : # clock gate signal >>>> x.next = somethingAwesome or somethingGreat >>> I guess the intention is that dff's with enables are inferred >>> when available. We should find out what the exact templates are >>> in Verilog and VHDL that support this e.g. probably the enable >>> condition should be and'ed with the clock edge condition in >>> VHDL. >> I believe that if you do "if enable = '1' then" right after your "if >> rising_edge(CLK) then" Xilinx ISE will properly infer the clock >> enable. I can confirm it tomorrow. > > That would work if we are talking about trying to use the clock enable > on the DFFs. But when I hear clock gating that makes me think you are > trying to actually stop the clock to the DFF? Could be to save power? > > The synthesis tools try hard to utilize the clock enable inputs. > Yes, clock gating is used to reduce dynamic power consumption. Clock gating is too low-level of a description it should be modeled as an enable. I should have simply said a clock enable and not clock gating. How the enable is implemented is technology dependent. Functionally, a FF with a clock enable, an input mux, or clock gate should all act the same. Synthesis settings can decide how the enable is implemented. I am having been having second thoughts if this is really useful with the /@always_seq/ decorator. It only removes 1 line in the current /@always_seq/, maybe it is not as beneficial as the reset. Regards, Chris |
|
From: Jan D. <ja...@ja...> - 2012-07-06 10:06:52
|
On 07/06/2012 05:44 AM, Christopher Felton wrote: > I am having been having second thoughts if this is really useful > with the /@always_seq/ decorator. It only removes 1 line in > the current /@always_seq/, maybe it is not as beneficial as the > reset. Yes, let's wait with this for the moment until everything is crystal clear about the current proposal. -- 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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X