myhdl-list — Mailing list for discussions on MyHDL

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

[Jan D. <ja...@ja...>]

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

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

[Jan D. <ja...@ja...>]

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

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

[Jan D. <ja...@ja...>]

On 07/05/2012 06:16 PM, Tom Dillon wrote:
>
> On 07/04/2012 04:05 AM, Jan Decaluwe 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.
>
> Aren't we just talking about the default case?

Here we were just speculating about possible synthesis
optimizations, nothing very important.

>  I will still be able to
> use no reset if I prefer?

Of course. Nothing changes from what you could do
previously. There will be more and better options, that's all.

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

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

[Jan D. <ja...@ja...>]

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

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

[Christopher F. <chr...@gm...>]

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

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

[Christopher F. <chr...@gm...>]

On 7/5/12 11:16 AM, Tom Dillon wrote:
>
> On 07/04/2012 04:05 AM, Jan Decaluwe 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.
>
> Aren't we just talking about the default case? I will still be able to
> use no reset if I prefer?
>

 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.

Regards,
Chris

Re: [myhdl-list] Simplifying Interfaces

[Christopher F. <chr...@gm...>]

On 7/5/12 11:29 AM, Tom Dillon wrote:
>
> On 07/04/2012 02:22 PM, Christopher Felton wrote:
>> <snip>
>>>> Anyone else have an idea for an example?  I think for the example to be
>>>> useful, you would want a design that you would use multiple modules and
>>>> have some interface between.  But the interface would be small (limited
>>>> number of signals in the class) so the the example would be digestible.
>>> Maybe something based on complex numbers, as Tom D has
>>> hinted. One could represent them as a class instance,
>>> or even as a tuple.
>>>
>>>
>> I was worried if the complex number example was used some
>> might expect operator overload.  I have been waffling if
>> this would be a good example.
>
> I think the example would have to show why we would not try to overload
> operators.
>

I agree, which, IMO, requires a little bit of *ART*.
There are many concepts that need to pulled together and
succinctly explained.  I do not want set incorrect
expectations.

I don't know if I see a good way to explain that operator
overloading is appropriate for a sequence of instructions
but not for a hardware description (concurrent processes).
Or if it is absent if it will raise questions.

I don't if a plain "signal container" example would be a
better fit.

Regards,
Chris

Re: [myhdl-list] Simplifying Interfaces

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

On 07/04/2012 02:22 PM, Christopher Felton wrote:
> <snip>
>>> Anyone else have an idea for an example?  I think for the example to be
>>> useful, you would want a design that you would use multiple modules and
>>> have some interface between.  But the interface would be small (limited
>>> number of signals in the class) so the the example would be digestible.
>> Maybe something based on complex numbers, as Tom D has
>> hinted. One could represent them as a class instance,
>> or even as a tuple.
>>
>>
> I was worried if the complex number example was used some
> might expect operator overload.  I have been waffling if
> this would be a good example.

I think the example would have to show why we would not try to overload 
operators.

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

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

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.

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.

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

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

On 07/04/2012 04:05 AM, Jan Decaluwe 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.

Aren't we just talking about the default case? I will still be able to 
use no reset if I prefer?

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

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

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

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

[Jan D. <ja...@ja...>]

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.

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

Re: [myhdl-list] Incorrect conclusions in TSConIT paper

[Christopher F. <chr...@gm...>]

On 7/3/12 5:26 AM, Norbo wrote:
> Am 01.07.2012, 03:47 Uhr, schrieb Christopher Felton
> <chr...@gm...>:
>
>> On 6/30/12 2:11 PM, Norbo wrote:
>>> def firfilt(sig_in, sig_out, coef, clk):
>>>             bufferVal = [Signal(intbv(0, min=sig_in.min, max=sig_in.max))
>>> for ii in range(len(coef))]
>>>             coefs = [Signal(intbv(ii, min=min(coef), max=max(coef)+1))
>>> for
>>> ii in coef]
>>>             mshift = len(sig_in)-1
>>>             @always(clk.posedge)
>>>             def hdl_sop():
>>>               sop = (bufferVal[0] * coefs[0])
>>>               # Note this adds an extra delay! (Group delay N/2+2)
>>>               bufferVal[0].next=sig_in
>>> 	
>>>               for ii in range(len(coef)-1):
>>>                  bufferVal[ii+1].next = bufferVal[ii]
>>>                  sop = sop + (bufferVal[ii+1] * coefs[ii+1])
>>>               sig_out.next = (sop >> mshift)
>>>
>>>             return hdl_sop
>>
>>
>> It should be noted, that the above doesn't work with any current version
>> of code.  I think you (Norbo) might have some local changes to create
>> the initial values for a RAM and they probably will be added with the
>> initial value changes but there are a bunch of tools that need to be
>> tested/verified.
>>
>> The above will not work with ROM extraction but appears to work with RAM
>> extraction, but RAM extraction requires initial values (only applicable
>> for FPGAs and not currently implemented) or some method to program the
>> RAM with the initial values.
>
> Using a singal (probably declared as constant) which has initialvalues is
> to my knowledge the number
> one way to describe some indexable constants in VHDL. I dont think the
> switch case construct which maps the values is
> in any way preferable to that other than for the Xilinx tool ROM inference.

The statement wasn't a /for/ or /against/ it simply was pointing out the 
limitations so that others would not be surprised if they tried the 
initial value approach with the latest release or latest development.

>
> It is a very basic way to describe some constant values in VHDL. If a tool
> doesn't support this i personaly would not use
> it. If there is no ROM or RAM for the device for which the synthesis is
> done the tool should at least could implement your constant signals with
> some Vcc or Ground connections wheater it is for an ASIC or an FPGA. Realy
> if the tool can't do this, its game over.
>
> Thats for the VHDL side.
>
>
> The way i have done it in myhdl with the code above is not the preferably
> way, because a extra signals is missused to implement it altought the list
> of tuple is allready here as a port input. Mapping a integer list of
> tuples to the switch case construct is not preferable too i think, because
> then you need the extra line to map the coef's.
> 		 c = coef[ii]
>                    sop = sop + (buffer[ii] * c)
>
> this also creates the variable "c" and as we have seen with the
> right_shift, convertion, implementation an usage of varibles
> in a description can easily become a pain.
> Why risk it when the list of tuple can "easly" be implemented in vhdl or
> verilog with a signal array with initial values.
>
>
> greetings
> Norbo

For the most part I agree, I like the initial value method and not 
introducing the separate variable.  I am not sure if *all* tools support 
this method for Verilog and VHDL, though.

In addition I don't know if this approach is general enough.  These are 
the problems I see or questions I have:

1.  ASIC tools don't have an equivalent RAM/ROM mapping.  But you might 
do the logic implementation.  In that case, if you had a tuple of ints 
or LoS of ints and wanted them implemented in logic, I don't know if the 
initial value (IV) method would synthesize.  ASIC tools will have an 
external tool (ROM builder) that is used for ROMs but, as stated, if you 
wanted it in logic I don't know if the IV would work.

2. Does there need to be a method to disable?  What if a synthesis tool
does not support the IV method.  Is it expected that all tools would 
support IV.

3. What if you want to use logic and not memory? (kinda the same 
question as the disable).  For small lists (tuples) of ints you might 
not want (or can't) to use a BRAM block.

I think it comes down to tool support.  For the tuple of ints and/or 
list of signal with initial value (converts to switch/case and initial 
values assignments respectively) which tools support which method.  The 
switch/case will be supported by all tools (even if not optimal) but I 
don't know if the IV is supported by all tools?

You have a valid point, the current tuple of its will only convert to a 
ROM for the Xilinx synthesis tools and not the Altera tools.  But it 
will work for both tools even if not optimal for Altera.

Regards,
Chris


>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>

Re: [myhdl-list] Simplifying Interfaces

[Christopher F. <chr...@gm...>]

<snip>
>>
>> Anyone else have an idea for an example?  I think for the example to be
>> useful, you would want a design that you would use multiple modules and
>> have some interface between.  But the interface would be small (limited
>> number of signals in the class) so the the example would be digestible.
>
> Maybe something based on complex numbers, as Tom D has
> hinted. One could represent them as a class instance,
> or even as a tuple.
>
>

I was worried if the complex number example was used some
might expect operator overload.  I have been waffling if
this would be a good example.

Regards,
Chris

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

[Christopher F. <chr...@gm...>]

<snip>
>
> I think this is going to be a great feature. My code becomes
> so much smaller in one pass, and you get "to the point"
> immediately instead of being distracted by all those reset
> assignments.  At first, it looks a little suprizing
> (where are my reset values?) but I think it's a matter of
> getting used to the concept.
>
> Note that you can construct "local" signals close to the
> generator where they are used, not necessarily all in
> the beginning.
>
> Example usage:
>
>       ...
>       reset = ResetSignal(0)
>       ...
>       ready = Signal(bool(0))
>       s0, s1, s2 = [Signal(bool(0)  for i in range(3)]
>
>       @always_seq(clock.posedge, reset=reset)
>       def synchronizer():
>           s0.next = ready_toggle
>           s1.next = s0
>           s2.next = s1
>           ready.next = s2 != s1
>
> When reset goes low, the signals are asynchronously reset to
> their initial values.
>

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

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

Most @always blocks would have the if-else:if pattern.  With
the /always_seq/ this could look like

         @always_seq(clock.posedge, reset=reset, clock_gate=enable)
         def hdl():
             x.next = somethingAwesome or somethingGreat

The /clock_gate/ would be optional since it is not as
common (required) as a reset.

Regards,
Chris

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

[Dan W. <eti...@gm...>]

On Wed, Jul 4, 2012 at 6:46 AM, 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:
>>> 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 :-)


Don't do much FPGA work here, but the explicit specification for the
ResetSignal constructor would keep the code more clear; this
especially since the active state is no longer specified directly in
the @always block as before.

I like the active low default, but not "hiding" the exact desired
reset behavior and throwing an exception seems the pythonic way.

Dan


-- 
SDG
www.whiteaudio.com

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

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

[Jan D. <ja...@ja...>]

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.

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

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

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

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

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

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.

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

Angel

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

[Jan D. <ja...@ja...>]

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.

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-

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

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

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

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

On Tue, Jul 3, 2012 at 11:04 PM, Jan Decaluwe <ja...@ja...> wrote:
> 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

That is actually not right for Xilinx FPGAs. The Xilinx manuals
actually encourage you to use active high reset because "the SR
control port on Xilinx registers is active high. If the RTL code
describes active-low set / reset / preset / clear functionality, the
synthesis tool will infer an inverter before it can directly drive the
control port of a register. You must accomplish this inversion with a
lookup table, thus taking up a LUT input. The additional logic that
active-low control signals infers may lead to longer runtimes and
result in poorer device utilization. It will also affect timing and
power."

As for the asynchronous vs synchronous reset, I suggest you guys have a look at:
http://www.xilinx.com/support/documentation/white_papers/wp231.pdf

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

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.

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.

Cheers,

Angel

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

[Jan D. <ja...@ja...>]

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

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

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

On 07/03/2012 01: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.

I would prefer to have a default value and would vote for async.


>

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

[Jan D. <ja...@ja...>]

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.

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