VHDL expert puzzle

>On 11/30/2012 12:55 AM, Bart Fox wrote:
>> rickman wrote:
>
>I have no idea why you say an async reset won't work in a sync design. 
>Do I misunderstand your statement?  I am talking about FPGAs where every 
>chip has an async reset during configuration.  You can choose to use 
>this in your design or not, but it is there and it works no matter what 
>you do.  I supposed I should have qualified my statement to FPGAs that 
>use RAM configuration and have to be configured.  There aren't a lot of 
>true flash based device that come up instantly without a configuration 
>process.
>
>Rick
>

Indeed. Altera recommends using the reset async port but with sync signal
pre-synchronised. Xilinx, I believe, recommends using synchronous sync. But
again we need to be careful about our wording. Synchronous sync is actually
applied to input D through logic and does not mean necessarily it is
pre-synchronised. Whether you name it async or sync, the signal be default
is not pre-synchronised and for sake of timing at release, they have to be
generated from flip's clock domain before applying it.

With today's large designs I prefer not to apply reset unless absolutely
needed. I know many of us will apply it as routine to masses of buses at
every node but I believe it puts massive burden on fitter to meet
removal/recovery timing when such effort better be directed somewhere more
critical.

Kaz 	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

>>On 11/30/2012 12:55 AM, Bart Fox wrote:
>>> rickman wrote:
>>
>>I have no idea why you say an async reset won't work in a sync design. 
>>Do I misunderstand your statement?  I am talking about FPGAs where every

>>chip has an async reset during configuration.  You can choose to use 
>>this in your design or not, but it is there and it works no matter what 
>>you do.  I supposed I should have qualified my statement to FPGAs that 
>>use RAM configuration and have to be configured.  There aren't a lot of 
>>true flash based device that come up instantly without a configuration 
>>process.
>>
>>Rick
>>
>
Indeed. Altera recommends using the reset async port but with sync signal
pre-synchronised. Xilinx, I believe, recommends using synchronous sync.
But
again we need to be careful about our wording. Synchronous sync is
actually
applied to input D through logic and does not mean necessarily it is
pre-synchronised. Whether you name it async or sync, the signal be default
is not pre-synchronised and for sake of timing at release, they have to be
generated from flip's clock domain before applying it.

With today's large designs I prefer not to apply reset unless absolutely
needed. I know many of us will apply it as routine to masses of buses at
every node but I believe it puts massive burden on fitter to meet
removal/recovery timing when such effort better be directed somewhere more
critical.

Note also the resource difference between the case of using async port(just

routing) and sync reset(logic).

Kaz 	   
					
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

>> On 11/30/2012 4:05 AM, Thomas Stanka wrote:=20
> > You are right, that clock gateing might destory a bit the=20
> > story, but in general clock skew is handled during layout and=20
> > checked by STA. During simulation of rtl code I have to assume,=20
> > that layout does not destroy my functionality, otherwise I=20
> > could stop simualtion anyway.=20

Short of required hand placement, there is no way to 'handle' clock skew in=
 layout in an FPGA/CPLD.  Logic induced skew between any two clocks creates=
 two clock domains.  If the design is such that the two clocks are treated =
as unrelated (for example if data only moves from one domain to the other t=
hrough a dual clock fifo) then the design will work.  You might get lucky, =
you might not if you think that any place and route tool will help you out =
here.  Most likely you will encounter the 'bad' sort of luck, not the 'good=
 luck'.

> On Friday, November 30, 2012 3:07:17 PM UTC-5, rickman wrote:
> My understanding is that logic delays in FPGAs are always longer
> than clock delays on the clock trees so that you can't have a=20
> hold time violation. If the clock is routed on the signal routing=20
> then all bets are off. I don't know how well the timing analysis=20
> does with verifying clock delays on the signal routing because I=20
> have never needed to use it that I can remember

It doesn't need to depend on routing.  Thomas' example introduced a logic d=
elay between the two clocks.  The implementation of that logic will create =
a race condition.

Kevin Jennings

On 11/30/2012 3:36 PM, kaz wrote:
>> On 11/30/2012 12:55 AM, Bart Fox wrote:
>>> rickman wrote:
>>
>> I have no idea why you say an async reset won't work in a sync design.
>> Do I misunderstand your statement?  I am talking about FPGAs where every
>> chip has an async reset during configuration.  You can choose to use
>> this in your design or not, but it is there and it works no matter what
>> you do.  I supposed I should have qualified my statement to FPGAs that
>> use RAM configuration and have to be configured.  There aren't a lot of
>> true flash based device that come up instantly without a configuration
>> process.
>>
>> Rick
>>
>
> Indeed. Altera recommends using the reset async port but with sync signal
> pre-synchronised.

That only makes sense if the delay in the async reset path is short 
enough and properly analyzed by the tools.  There have been any number 
of discussions in these groups about how to properly reset a design and 
there is no consensus on the best way to do it.


> Xilinx, I believe, recommends using synchronous sync. But
> again we need to be careful about our wording. Synchronous sync is actually
> applied to input D through logic and does not mean necessarily it is
> pre-synchronised. Whether you name it async or sync, the signal be default
> is not pre-synchronised and for sake of timing at release, they have to be
> generated from flip's clock domain before applying it.

The best way to do a reset is design specific.  As I said above, there 
are many ways and no agreement on which is "best".


> With today's large designs I prefer not to apply reset unless absolutely
> needed. I know many of us will apply it as routine to masses of buses at
> every node but I believe it puts massive burden on fitter to meet
> removal/recovery timing when such effort better be directed somewhere more
> critical.

That depends on why you are using the reset.  If you are only using it 
to establish the configuration values you can apply an async reset and 
not be concerned with routing since it will use only the dedicated async 
reset network.

Rick

On 11/30/2012 3:49 PM, kaz wrote:
>
> Note also the resource difference between the case of using async port(just
>
> routing) and sync reset(logic).

I'm not clear on this.  I believe some architectures provide sync reset 
inputs separate from the D input and so use no logic.

Rick

On 11/30/2012 9:25 PM, KJ wrote:
>> On Friday, November 30, 2012 3:07:17 PM UTC-5, rickman wrote:
>> My understanding is that logic delays in FPGAs are always longer
>> than clock delays on the clock trees so that you can't have a
>> hold time violation. If the clock is routed on the signal routing
>> then all bets are off. I don't know how well the timing analysis
>> does with verifying clock delays on the signal routing because I
>> have never needed to use it that I can remember
>
> It doesn't need to depend on routing.  Thomas' example introduced a logic delay between the two clocks.  The implementation of that logic will create a race condition.

I didn't see anything in Thomas' example that required "logic".  Here is 
what I read.  Did I read the wrong post?

> To demonstrate your point though you simply need to generate the new clock as this:
>
> clk1 <= clk;

This is not logic.  In VHDL it inserts a delta delay which is a zero 
amount of time but treated as a delay in the simulator.  By adding a 
delta delay it will disrupt signals from the earlier clk domain that 
drive FFs in the later clk1 domain.  In a real chip there will be no delay.

Rick

rickman <gnuarm@gmail.com> wrote:
> On 11/30/2012 3:49 PM, kaz wrote:

>> Note also the resource difference between the case of using async port(just
>> routing) and sync reset(logic).
 
> I'm not clear on this.  I believe some architectures provide 
> sync reset inputs separate from the D input and so use no logic.

Well, it will still take some resources, but maybe not much.

-- glen

>rickman <gnuarm@gmail.com> wrote:
>> On 11/30/2012 3:49 PM, kaz wrote:
>
>>> Note also the resource difference between the case of using async
port(just
>>> routing) and sync reset(logic).
> 
>> I'm not clear on this.  I believe some architectures provide 
>> sync reset inputs separate from the D input and so use no logic.
>
>Well, it will still take some resources, but maybe not much.
>
>-- glen
>

I am not aware of this type of architecture. I assume it synchronises
reset
per flip and thus seems a waste of silicon compared to the case of user
pre-syncing it once for all relevant flips.

Kaz	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

On 12/1/2012 2:05 AM, kaz wrote:
>> rickman<gnuarm@gmail.com>  wrote:
>>> On 11/30/2012 3:49 PM, kaz wrote:
>>
>>>> Note also the resource difference between the case of using async
> port(just
>>>> routing) and sync reset(logic).
>>
>>> I'm not clear on this.  I believe some architectures provide
>>> sync reset inputs separate from the D input and so use no logic.
>>
>> Well, it will still take some resources, but maybe not much.
>>
>> -- glen
>>
>
> I am not aware of this type of architecture. I assume it synchronises
> reset
> per flip and thus seems a waste of silicon compared to the case of user
> pre-syncing it once for all relevant flips.

I don't know the Altera devices as intimately as others, but I learned 
the Xilinx stuff pretty well once.  They have (had) two inputs to each 
FF, one for reset and one for set, which were configurable between sync 
and async.

My point is that if this is built in, which is not uncommon I think, 
there are no "used" resources other than dedicated resources for logic 
in the case sync reset and nothing for async.

I prefer to design my resets in a customized way where each section of 
logic is reset and released from reset asynchronously and each logic 
section separately takes care of the problems of cleanly starting up. 
That way there is no global reset competing for either routing or logic. 
  Often nothing special needs to be done for a finite state machine 
(FSM) because it starts by waiting for some trigger signal anyway. 
Counters often use an enable which is disabled by default, etc.  I pay 
attention to how my circuits operate from reset and so far this has not 
bitten me.

Rick

On Saturday, December 1, 2012 1:47:06 AM UTC-5, rickman wrote:
> On 11/30/2012 9:25 PM, KJ wrote:=20
> > It doesn't need to depend on routing. Thomas' example introduced a=20
>> logic delay between the two clocks. The implementation of that logic=20
>> will create a race condition.=20
> I didn't see anything in Thomas' example that required "logic". Here is=
=20
> what I read. Did I read the wrong post?=20

The post that I referring to has the following...
    Clk1 <=3D Clk when Selected else Other_Clk';=20
    [..]=20
    Clk2 <=3D Clk1 when Enabled else '0';=20
    [..]=20
    process (Clk)=20
      if rising_edge(Clk) then=20
         A <=3D B;=20
    [..]=20
    process (Clk2)=20
      if rising_edge(Clk2)=20
         B<=3D A;=20

I believe the point he was trying to make was that because of the simulatio=
n delta delay between Clk1 and Clk2 the two processess would not be clocked=
 at the same time.  While it is true that the processes would clock at diff=
erent times, it's not really because of the simulation delta delay.  An act=
ual implementation of the above would have the same problem because it woul=
d need to synthesize the logic to create the gated clock.  The propogation =
delay and additional routing delay in creating the additional clock would c=
reate a race condition for signals generated in the 'clk' domain and captur=
ed in the 'clk1' or 'clk2' domains.

> > clk1 <=3D clk;=20

> This is not logic. In VHDL it inserts a delta delay which is a zero=20
> amount of time but treated as a delay in the simulator. By adding a=20
> delta delay it will disrupt signals from the earlier clk domain that
> drive FFs in the later clk1 domain. In a real chip there will be no=20
> delay.

And that was my point.

Kevin Jennings