VHDL expert puzzle

In comp.arch.fpga Bart Fox <bartfox@gmx.net> wrote:
> rickman wrote:
>> I think for FPGAs it is very common to specify an async reset to assign
>> the configuration value of each FF,  so I have come to expect async
>> resets.
> Dream on. It ist *not* common to use asnchronous resets on every flipflop.
 
> This is your opinion or the opinion of the academic VHDL book you read.
 
> In synchronous designs an asynchronous reset has no right.
> Make an synchronous reset from your asynchronous reset input on one 
> place, and all will work.

Yes, FPGAs usually have an asynchronous reset. 

They at least usually have a reset when they come out of
configuration, which tends to be asynchronous to your clock.

Usually it is easy to also put your own signal into the same
reset line, but you don't have to do that.

So, it is common to have one, it may or may not be common
to use it, other than at the end of configuration.

-- glen

On 11/30/2012 03:40 AM, KJ wrote:
> On Thursday, November 29, 2012 2:30:50 PM UTC-5, Jan Decaluwe wrote:
>>> Why is this an issue?
>
>> It's not an issue. I was only pointing out that there is no need
>> for you "to feel for him" :-) (For full disclosure and information
>> only: it is actually an issue for me personally
>
> But now you're letting this guy's postings bother you so much that
> the two sentences you just wrote contradict each other.

It's a personal issue for me, but it shouldn't become one for
anybody else here. I was looking for technical feedback and
confirmation of my findings, and I got it.

Jan

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

On 11/29/2012 09:05 PM, rickman wrote:

> What blogs have you done?  I'd like to read them.

My MyHDL blog on APP (APP uses no tags, sorry):

http://www.programmableplanet.com/author.asp?section_id=2438&doc_id=250236&

My HDL design blog on Sigasi:

http://www.sigasi.com/tag/janhdl

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

On 11/30/2012 03:40 AM, KJ wrote:

> I don't follow how you think it makes no sense for you to write high
> quality blogs alongside someone who you (and apparently others) think
> writes low quality ones.  If APP has no editorial board or peer
> review process (which is what it looks like to me), then there is no
> quality control mechanism other than the replies to the blog.

 From those replies (or lack of replies) I infer, perhaps
incorrectly, whether I have an audience myself. If there's no
interest or support to correct even the most basic and flagrant
errors, I admit that I have some doubts.

> So you can't choose your fellow bloggers...but you can control that by
> blogging elsewhere if you so choose.

Correct. So the question I have to answer for myself is whether
APP is giving me the short-term added value (a large interested
audience) that I thought it would give me. The site has significant
disadvangages too: it's hard to find old posts back, and the
comment section's threading mechanism doesn't work well.

Jan

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

On 30 Nov., 06:55, Bart Fox <bart...@gmx.net> wrote:
> rickman wrote:
> > I think for FPGAs it is very common to specify an async reset to assign
> > the configuration value of each FF, =A0so I have come to expect async
> > resets.
>
> Dream on. It ist *not* common to use asnchronous resets on every flipflop=
.
>
> This is your opinion or the opinion of the academic VHDL book you read.
>
> In synchronous designs an asynchronous reset has no right.
> Make an synchronous reset from your asynchronous reset input on one
> place, and all will work.

At least a asynchronous asserting but synchronous deasserting reset is
very reasonable in synchronous design.

Those who ignore reset when designing for vandor x or a often forget
that good code should be as much as possible vendor independant, as
you never know, when part of your code is reused on different
technology in which you have no guraanteed start-up value at power up.

regards Thomas

On 29 Nov., 02:43, KJ <kkjenni...@sbcglobal.net> wrote:
> Actually your example does not quite demonstrate the point you were makin=
g. =A0In your example, you have actual function (the muxing and enabling) b=
etween the clocks so you're describing a gated clock system. =A0That system=
, if built, could very well behave exactly as you have described but not be=
 what the designer intended simply because the designer did not account for=
 the clock skew. =A0The simulation without the added delay very well may de=
scribe the actual hardware. =A0In this case, adding the delay 'to fix the s=
imulation' would be sweeping the design error under the rug until it eventu=
ally is uncovered in real hardware.
>
> To demonstrate your point though you simply need to generate the new cloc=
k as this:
>
> clk1 <=3D clk;
>
> Then clock things with 'clk' and 'clk1' and watch them not work. =A0In th=
is instance the 'clk1 <=3D clk;' assignment would not be implemented in any=
 hardware but the simulator would be off by a delta cycle.

You are right, that clock gateing might destory a bit the story, but
in general clock skew is handled during layout and checked by STA.
During simulation of rtl code I have to assume, that layout does not
destroy my functionality, otherwise I could stop simualtion anyway.

regards Thomas

On 28 Nov., 09:55, Jan Decaluwe <j...@jandecaluwe.com> wrote:
> On 11/28/2012 09:34 AM, Thomas Stanka wrote:
> > I can only guess, that the simulator the author is using messes up
> > with this two lines
>
> >> =A0 =A0process(clk,clk_i,lfsr,rst) begin
> >> =A0 =A0 =A0 =A0 =A0 if rising_edge(clk) then
>
> > and execute the code inside the if rising_edge clause also in delta
> > cycles that have no rising clock edge.
>
> A VHDL simulator broken in this way? Hard to imagine.

I agree it is hard to imagine.
If I would have got a penny for every bug I detected within EDA-Tools,
I would be rich. And there are sometimes issues real hard to believe
that I'm the first to detect. So I'm no longer surprised, if another
major bug happens in EDA-World.

On 11/30/2012 10:10 AM, Thomas Stanka wrote:
> On 28 Nov., 09:55, Jan Decaluwe <j...@jandecaluwe.com> wrote:
>> On 11/28/2012 09:34 AM, Thomas Stanka wrote:
>>> I can only guess, that the simulator the author is using messes up
>>> with this two lines
>>
>>>>     process(clk,clk_i,lfsr,rst) begin
>>>>            if rising_edge(clk) then
>>
>>> and execute the code inside the if rising_edge clause also in delta
>>> cycles that have no rising clock edge.
>>
>> A VHDL simulator broken in this way? Hard to imagine.
>
> I agree it is hard to imagine.
> If I would have got a penny for every bug I detected within EDA-Tools,
> I would be rich. And there are sometimes issues real hard to believe
> that I'm the first to detect. So I'm no longer surprised, if another
> major bug happens in EDA-World.

I fully agree with that, and I have been through that experience
myself.

Unfortunately, it looks like were not going to find out
in this case ;-)

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

On 11/30/2012 12:55 AM, Bart Fox wrote:
> rickman wrote:
>> I think for FPGAs it is very common to specify an async reset to assign
>> the configuration value of each FF, so I have come to expect async
>> resets.
> Dream on. It ist *not* common to use asnchronous resets on every flipflop.

I didn't say it was common to specify an async reset on *every* FF.  I 
said it is common to specify an async reset so that the configuration 
value is assigned.  You can do that on all of the FFs in the design or 
you can do that one the twelve FFs that control your design or you can 
do it on none.  But if you want set a configuration value it is very 
common to use an async reset to do that.

I think some or perhaps most vendors now provide a non-portable method 
of setting the configuration value and some even will use an 
initialization value in the declaration to do that.  But I don't believe 
this is very portable as of yet.


> This is your opinion or the opinion of the academic VHDL book you read.

This is based on my experience with the tools and looking at other's code.


> In synchronous designs an asynchronous reset has no right.
> Make an synchronous reset from your asynchronous reset input on one
> place, and all will work.

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

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

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.

Rick