Re: [myhdl-list] Reset functionality "synthesis"
Brought to you by:
jandecaluwe
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. |