Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 154575

Article: 154575
Subject: Re: VHDL expert puzzle
From: Jan Decaluwe <jan@jandecaluwe.com>
Date: Thu, 29 Nov 2012 18:21:31 +0100
Links: << >>  << T >>  << A >>
On 11/29/2012 03:22 PM, rickman wrote:

> I think the "Just forget about it" comment was on the second page of
> comments and there were six when I read it.  So I guess he is getting
> beat up pretty badly.  I feel for him.

I wouldn't worry too much :-) Let me summarize.

Let's be clear about how bad this really is. He describes
the simulation with delays, and draws all kinds of
nonsensical conclusions from it. However, by simulating
his code, everybody can verify that it simply doesn't behave
in the way he describes. He makes his points while
misrepresenting his own (public!) code.

For days, I have been trying to point out that there is
something fundamentally wrong here :-) No reaction from
the community on APP on this particular point. In
the end, the OP came back and stated (screamed) that
he "just does not care whether his code works or not".
Those who do "are missing the point". (I think he means
that he should be praised for using the word "testbench").

Guess what: again no reaction to this date on APP.
The only behavior that has been criticized is my
own, for calling this article "sloppy". (I confess.)

In short, he is getting away with this.

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

Article: 154576
Subject: Re: VHDL expert puzzle
From: rickman <gnuarm@gmail.com>
Date: Thu, 29 Nov 2012 12:54:42 -0500
Links: << >>  << T >>  << A >>
On 11/29/2012 10:28 AM, Michael S wrote:
> On Nov 29, 4:50 pm, "Kerry Imming"<kcimm...@pobox.com>  wrote:
>>
>> I think the problem is not the LFSR, but that the XNOR operation can be
>> non-intuitive.
>>
>> For example:   a XNOR b XNOR c  is equivalent to a XOR b XOR c
>> Since there is an even number of inversions, the inversions cancel out.
>> In the given example, there is an odd number of XNORs, so it works as
>> written.
>>
>> My preferred style would be.    d<= NOT (a XOR b XOR c);
>>
>> - Kerry
>
> Yes, that's exactly what I meant to say.
>

Actually, this is an example why you *don't* want to convert to XOR. 
The example given was converted wrongly.

d <= NOT (a XOR b XOR c)
is not the same as
d <= a XNOR b XNOR c
which is what I believe Kerry is saying.

d <= a XOR b XOR c
would be the same as
d <= a XNOR b XNOR c

XNOR is only non-intuitive because you haven't worked with it much. 
Just like it is not uncommon to use NOR and NAND, I think XNOR has a 
place in the vocab of logic designers.

Rick

Article: 154577
Subject: Re: VHDL expert puzzle
From: rickman <gnuarm@gmail.com>
Date: Thu, 29 Nov 2012 13:18:13 -0500
Links: << >>  << T >>  << A >>
On 11/29/2012 12:21 PM, Jan Decaluwe wrote:
> On 11/29/2012 03:22 PM, rickman wrote:
>
>> I think the "Just forget about it" comment was on the second page of
>> comments and there were six when I read it. So I guess he is getting
>> beat up pretty badly. I feel for him.
>
> I wouldn't worry too much :-) Let me summarize.
>
> Let's be clear about how bad this really is. He describes
> the simulation with delays, and draws all kinds of
> nonsensical conclusions from it. However, by simulating
> his code, everybody can verify that it simply doesn't behave
> in the way he describes. He makes his points while
> misrepresenting his own (public!) code.
>
> For days, I have been trying to point out that there is
> something fundamentally wrong here :-) No reaction from
> the community on APP on this particular point. In
> the end, the OP came back and stated (screamed) that
> he "just does not care whether his code works or not".
> Those who do "are missing the point". (I think he means
> that he should be praised for using the word "testbench").
>
> Guess what: again no reaction to this date on APP.
> The only behavior that has been criticized is my
> own, for calling this article "sloppy". (I confess.)
>
> In short, he is getting away with this.

I read his blog and I read some of the responses, both at the start and 
at the current end (it looks like no one has posed in a couple of days 
now).  The blog thread is all about the mistake the guy made in 
analyzing the operation of the code.

What/where is APP?

As far as the guy "getting away with this" I don't get what you mean. 
Why is this an issue?

I think others may understand what you are saying.  It just isn't such a 
big deal if the response is not as dramatic as you may have expected.  I 
don't think anyone is really "criticizing" you.  They just don't agree 
that this is such a big issue.

I try to not get upset by things that happen on Internet forums.  Its 
like the quote from the movie Chinatown... "Forget it, Jake; it's 
Chinatown".

Rick

Article: 154578
Subject: Re: VHDL expert puzzle
From: "Kerry Imming" <kcimming@pobox.com>
Date: Thu, 29 Nov 2012 13:23:12 -0600
Links: << >>  << T >>  << A >>

"rickman" <gnuarm@gmail.com> wrote in message 
news:k987ht$94j$1@dont-email.me...
>
> Actually, this is an example why you *don't* want to convert to XOR. The 
> example given was converted wrongly.
>
> d <= NOT (a XOR b XOR c)
> is not the same as
> d <= a XNOR b XNOR c
> which is what I believe Kerry is saying.
>
> d <= a XOR b XOR c
> would be the same as
> d <= a XNOR b XNOR c
>
> XNOR is only non-intuitive because you haven't worked with it much. Just 
> like it is not uncommon to use NOR and NAND, I think XNOR has a place in 
> the vocab of logic designers.
>

Apologies... I should have used different variables for my "prefered style" 
example.

- Kerry



Article: 154579
Subject: Re: VHDL expert puzzle
From: Michael S <already5chosen@yahoo.com>
Date: Thu, 29 Nov 2012 11:30:49 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 29, 7:54=A0pm, rickman <gnu...@gmail.com> wrote:
> On 11/29/2012 10:28 AM, Michael S wrote:
>
>
>
>
>
>
>
>
>
> > On Nov 29, 4:50 pm, "Kerry Imming"<kcimm...@pobox.com> =A0wrote:
>
> >> I think the problem is not the LFSR, but that the XNOR operation can b=
e
> >> non-intuitive.
>
> >> For example: =A0 a XNOR b XNOR c =A0is equivalent to a XOR b XOR c
> >> Since there is an even number of inversions, the inversions cancel out=
.
> >> In the given example, there is an odd number of XNORs, so it works as
> >> written.
>
> >> My preferred style would be. =A0 =A0d<=3D NOT (a XOR b XOR c);
>
> >> - Kerry
>
> > Yes, that's exactly what I meant to say.
>
> Actually, this is an example why you *don't* want to convert to XOR.
> The example given was converted wrongly.
>
> d <=3D NOT (a XOR b XOR c)
> is not the same as
> d <=3D a XNOR b XNOR c
> which is what I believe Kerry is saying.
>
> d <=3D a XOR b XOR c
> would be the same as
> d <=3D a XNOR b XNOR c
>
> XNOR is only non-intuitive because you haven't worked with it much.
> Just like it is not uncommon to use NOR and NAND, I think XNOR has a
> place in the vocab of logic designers.
>
> Rick

Let's agree to disagree.
I think, that all three, XNOR, NOR and NAND are equally unacceptable
in HDL coding for FPGA.

Article: 154580
Subject: Re: VHDL expert puzzle
From: Jan Decaluwe <jan@jandecaluwe.com>
Date: Thu, 29 Nov 2012 20:30:50 +0100
Links: << >>  << T >>  << A >>
On 11/29/2012 07:18 PM, rickman wrote:

> I read his blog and I read some of the responses, both at the start
> and at the current end (it looks like no one has posed in a couple of
> days now).  The blog thread is all about the mistake the guy made in
> analyzing the operation of the code.
>
> What/where is APP?

The abbreviation for All Programmable Planet, the site
on which this blog is located.

> As far as the guy "getting away with this" I don't get what you mean.
> 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 - since some time I am also a blogger
on APP and I have spent lots of time trying to write high quality
blogs. That makes little sense if it turns out you can write
anything you want without having to worry about correctness.)

> I think others may understand what you are saying.  It just isn't
> such a big deal if the response is not as dramatic as you may have
> expected.  I don't think anyone is really "criticizing" you.  They
> just don't agree that this is such a big issue.

Apparently.

> I try to not get upset by things that happen on Internet forums.  Its
> like the quote from the movie Chinatown... "Forget it, Jake; it's
> Chinatown".

Good advice.

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

Article: 154581
Subject: Re: VHDL expert puzzle
From: Michael S <already5chosen@yahoo.com>
Date: Thu, 29 Nov 2012 11:39:56 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 29, 9:30=A0pm, Jan Decaluwe <j...@jandecaluwe.com> wrote:
> On 11/29/2012 07:18 PM, rickman wrote:
>
> > I read his blog and I read some of the responses, both at the start
> > and at the current end (it looks like no one has posed in a couple of
> > days now). =A0The blog thread is all about the mistake the guy made in
> > analyzing the operation of the code.
>
> > What/where is APP?
>
> The abbreviation for All Programmable Planet, the site
> on which this blog is located.
>
> > As far as the guy "getting away with this" I don't get what you mean.
> > 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 - since some time I am also a blogger
> on APP and I have spent lots of time trying to write high quality
> blogs. That makes little sense if it turns out you can write
> anything you want without having to worry about correctness.)
>
> > I think others may understand what you are saying. =A0It just isn't
> > such a big deal if the response is not as dramatic as you may have
> > expected. =A0I don't think anyone is really "criticizing" you. =A0They
> > just don't agree that this is such a big issue.
>
> Apparently.
>
> > I try to not get upset by things that happen on Internet forums. =A0Its
> > like the quote from the movie Chinatown... "Forget it, Jake; it's
> > Chinatown".
>
> Good advice.
>
> --
> Jan Decaluwe - Resources bvba -http://www.jandecaluwe.com
> =A0 =A0 =A0Python as a HDL:http://www.myhdl.org
> =A0 =A0 =A0VHDL development, the modern way:http://www.sigasi.com
> =A0 =A0 =A0World-class digital design:http://www.easics.com

I think, the logical mistake that he made in his second attempt and,
more importantly, the fact that he failed to notice it by manual
observation of simulation result give you an excellent opportunity to
evangelize self-checking testbenchs in your own blog.

Article: 154582
Subject: Re: VHDL expert puzzle
From: rickman <gnuarm@gmail.com>
Date: Thu, 29 Nov 2012 14:55:53 -0500
Links: << >>  << T >>  << A >>
On 11/29/2012 2:30 PM, Michael S wrote:
> On Nov 29, 7:54 pm, rickman<gnu...@gmail.com>  wrote:
>>
>> XNOR is only non-intuitive because you haven't worked with it much.
>> Just like it is not uncommon to use NOR and NAND, I think XNOR has a
>> place in the vocab of logic designers.
>>
>> Rick
>
> Let's agree to disagree.
> I think, that all three, XNOR, NOR and NAND are equally unacceptable
> in HDL coding for FPGA.

Ok, fair enough.

Rick

Article: 154583
Subject: Re: VHDL expert puzzle
From: rickman <gnuarm@gmail.com>
Date: Thu, 29 Nov 2012 15:05:26 -0500
Links: << >>  << T >>  << A >>
On 11/29/2012 2:30 PM, Jan Decaluwe wrote:
> On 11/29/2012 07:18 PM, rickman wrote:
>
>> As far as the guy "getting away with this" I don't get what you mean.
>> 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 - since some time I am also a blogger
> on APP and I have spent lots of time trying to write high quality
> blogs. That makes little sense if it turns out you can write
> anything you want without having to worry about correctness.)


I have a friend who is starting a non-profit regarding cold water 
safety.  He has a lot of trouble with people just not getting the idea 
that cold water is very dangerous and that it would save lives if the 
word is spread more widely.  But some continue to spout nonsense and 
post crap to websites and videos with silly (and wrong) rules about when 
the water is dangerous and how long you can survive in it.  He is trying 
to distance himself from the flotsam and jetsam.  So I feel *your* pain 
too.  lol

I think what would be best is to not push too hard, but just to give it 
time.  I am gradually learning that with most stuff Internet, much like 
they say to count to 10 before responding to spoken words, it is good to 
wait a day or even two before responding to things on the Internet.  I'm 
trying to learn that myself.

The bottom line is this guy won't impact you much really.  What blogs 
have you done?  I'd like to read them.

Rick

Article: 154584
Subject: V6 BUFR -> BUFG clocking structure (hold issue?)
From: mmihai <iiahim@yahoo.com>
Date: Thu, 29 Nov 2012 16:35:43 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi!

I have a Xilinx webcase for about 2mo about this that goes nowhere ... may be better luck here.

My problem:
 - V6 design
 - clocking structure with a IBUF to BUFR which drives a BUFG, so both BUFR/BUFG are on the same clock domain
 - the BUFR also clocks few flops
 - BUFG clocks main logic
 - par finishes w/o hold errs
 - I can detect data transfer errors between the flops clocked by BUFR and the flops clocked by BUFG (direction is data from BUFR flops -> BUFG flops, no logic, just data transfer).
 - timingan reports no hold errs on those paths
 - different runs (different placement) will produce a full working design
[- ISE 13.4... but it should not matter]

Anyone seen this? Any feedback about this structure?

Goal is to be able to produce predictable results... Now I have no way to do that unless I try it on HW ... but my confidence level is low (i.e. if it works on one device will it work on //all//?).

--
Thanks,
mmihai

Article: 154585
Subject: Re: VHDL expert puzzle
From: KJ <kkjennings@sbcglobal.net>
Date: Thu, 29 Nov 2012 18:40:47 -0800 (PST)
Links: << >>  << T >>  << A >>
On Thursday, November 29, 2012 2:30:50 PM UTC-5, Jan Decaluwe wrote:
> > Why is this an issue?=20

> It's not an issue. I was only pointing out that there is no need=20
> for you "to feel for him" :-) (For full disclosure and=20
> 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.

> - since some time I am also a blogger on APP and I have spent=20
> lots of time trying to write high quality blogs. That makes=20
> little sense if it turns out you can write anything you want=20
> without having to worry about correctness.)=20

I don't follow how you think it makes no sense for you to write high qualit=
y 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 ot=
her than the replies to the blog.  So you can't choose your fellow bloggers=
...but you can control that by blogging elsewhere if you so choose.

It seems to me that you took what probably looked to you at first to be an =
'interesting' problem and found that the author had (to be polite) a few er=
rors and that it was just a dud rather than something interesting.  Maybe y=
ou're put off by the time you invested in it...you seem to have taken offen=
se that the author basically blew it all off rather than taking the posting=
s as useful corrective feedback.  So what?  Don't make it any sort of perso=
nal (or non-personal) issue to you since that is something you can control.

Kevin Jennings

Article: 154586
Subject: Re: V6 BUFR -> BUFG clocking structure (hold issue?)
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 30 Nov 2012 03:32:03 +0000 (UTC)
Links: << >>  << T >>  << A >>
mmihai <iiahim@yahoo.com> wrote:
 
> I have a Xilinx webcase for about 2mo about this that 
> goes nowhere ... may be better luck here.
 
> My problem:
> - V6 design
> - clocking structure with a IBUF to BUFR which drives a BUFG, 
> so both BUFR/BUFG are on the same clock domain
> - the BUFR also clocks few flops
> - BUFG clocks main logic
> - par finishes w/o hold errs
> - I can detect data transfer errors between the flops clocked 
> by BUFR and the flops clocked by BUFG (direction is data from 
> BUFR flops -> BUFG flops, no logic, just data transfer).
> - timingan reports no hold errs on those paths
> - different runs (different placement) will produce a full working design
> [- ISE 13.4... but it should not matter]

Maybe I am missing something, but unless you tell the timing 
analysis the relative timing of the two clocks, it can't do 
setup/hold analysis on them. 

Is it supposed to follow the timing through that combination?

-- glen


Article: 154587
Subject: Re: V6 BUFR -> BUFG clocking structure (hold issue?)
From: mmihai <iiahim@yahoo.com>
Date: Thu, 29 Nov 2012 21:03:31 -0800 (PST)
Links: << >>  << T >>  << A >>
On Thursday, November 29, 2012 7:32:03 PM UTC-8, glen herrmannsfeldt wrote:

> Maybe I am missing something, but unless you tell the timing 
> analysis the relative timing of the two clocks, it can't do 
> setup/hold analysis on them. 

Both clocks are internal; no extra timing is required. Only the Xilinx's tools know the relative timing since it's the delay only through the FPGA itself.
 
> Is it supposed to follow the timing through that combination?

a) BUFR output is the input of BUFG; same clock domain.
b) the tool is propagating the clock through the design and is aware of the propagation delay through buffers (and routing?)

I can ask timingan to report the paths between the flops and nothing is obviously wrong and hold slack is >=0.

Unfortunately it is not that verbose on the clock propagation time but the clock timing looks like:

  Clock Path Skew:      1.851ns (2.677 - 0.826)
  Source Clock:         ipclk rising at 0.000ns
  Destination Clock:    pclk rising at 0.000ns
  Clock Uncertainty:    0.035ns

ipclk is the output of BUFR, pclk is the output of BUFG.
I guess 'Clock Path Skew' contains the added BUFG propagation delay and BUFR->BUFG routing.

As summary, for all I can say, the path is constrained in the tools and has non-negative slack as reported. But I can see the HW failing...

Anyone using a BUFR feeding a BUFG?

--
mmhai



Article: 154588
Subject: Re: VHDL expert puzzle
From: Bart Fox <bartfox@gmx.net>
Date: Fri, 30 Nov 2012 06:55:39 +0100
Links: << >>  << T >>  << A >>
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.

Bart Fox

Article: 154589
Subject: Re: VHDL expert puzzle
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 30 Nov 2012 06:27:12 +0000 (UTC)
Links: << >>  << T >>  << A >>
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

Article: 154590
Subject: Re: V6 BUFR -> BUFG clocking structure (hold issue?)
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 30 Nov 2012 06:32:10 +0000 (UTC)
Links: << >>  << T >>  << A >>
mmihai <iiahim@yahoo.com> wrote:

(snip, I wrote)

>> Maybe I am missing something, but unless you tell the timing 
>> analysis the relative timing of the two clocks, it can't do 
>> setup/hold analysis on them. 
 
> Both clocks are internal; no extra timing is required. 
> Only the Xilinx's tools know the relative timing since 
> it's the delay only through the FPGA itself.

You might look at

http://www.xilinx.com/support/documentation/user_guides/ug362.pdf

I looked some, but didn't see the answer. 

Just because two signals are internal doesn't guarantee that
the timing is known, though.

-- glen

Article: 154591
Subject: Re: VHDL expert puzzle
From: Jan Decaluwe <jan@jandecaluwe.com>
Date: Fri, 30 Nov 2012 09:26:41 +0100
Links: << >>  << T >>  << A >>
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

Article: 154592
Subject: Re: VHDL expert puzzle
From: Jan Decaluwe <jan@jandecaluwe.com>
Date: Fri, 30 Nov 2012 09:34:37 +0100
Links: << >>  << T >>  << A >>
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

Article: 154593
Subject: Re: VHDL expert puzzle
From: Jan Decaluwe <jan@jandecaluwe.com>
Date: Fri, 30 Nov 2012 09:55:08 +0100
Links: << >>  << T >>  << A >>
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

Article: 154594
Subject: Re: VHDL expert puzzle
From: Thomas Stanka <usenet_nospam_valid@stanka-web.de>
Date: Fri, 30 Nov 2012 00:56:33 -0800 (PST)
Links: << >>  << T >>  << A >>
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



Article: 154595
Subject: Re: VHDL expert puzzle
From: Thomas Stanka <usenet_nospam_valid@stanka-web.de>
Date: Fri, 30 Nov 2012 01:05:32 -0800 (PST)
Links: << >>  << T >>  << A >>
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

Article: 154596
Subject: Re: VHDL expert puzzle
From: Thomas Stanka <usenet_nospam_valid@stanka-web.de>
Date: Fri, 30 Nov 2012 01:10:33 -0800 (PST)
Links: << >>  << T >>  << A >>
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.

Article: 154597
Subject: Re: VHDL expert puzzle
From: Jan Decaluwe <jan@jandecaluwe.com>
Date: Fri, 30 Nov 2012 10:18:56 +0100
Links: << >>  << T >>  << A >>
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

Article: 154598
Subject: Re: V6 BUFR -> BUFG clocking structure (hold issue?)
From: Allan Herriman <allanherriman@hotmail.com>
Date: 30 Nov 2012 12:46:51 GMT
Links: << >>  << T >>  << A >>
On Thu, 29 Nov 2012 16:35:43 -0800, mmihai wrote:

> Hi!
> 
> I have a Xilinx webcase for about 2mo about this that goes nowhere ...
> may be better luck here.
> 
> My problem:
>  - V6 design - clocking structure with a IBUF to BUFR which drives a
>  BUFG, so both BUFR/BUFG are on the same clock domain - the BUFR also
>  clocks few flops - BUFG clocks main logic - par finishes w/o hold errs
>  - I can detect data transfer errors between the flops clocked by BUFR
>  and the flops clocked by BUFG (direction is data from BUFR flops ->
>  BUFG flops, no logic, just data transfer).
>  - timingan reports no hold errs on those paths - different runs
>  (different placement) will produce a full working design
> [- ISE 13.4... but it should not matter]
> 
> Anyone seen this? Any feedback about this structure?
> 
> Goal is to be able to produce predictable results... Now I have no way
> to do that unless I try it on HW ... but my confidence level is low
> (i.e. if it works on one device will it work on //all//?).


I understand that the circuit looks like this:


Pin--->IBUF--->BUFR--+--->BUFG---+-->
                     |           |
                     |           |
                     |           |
                     |           |
                  +-----+     +-----+
                  | FF Q|---->|D FF |
                  +-----+     +-----+
                            ^
                            |
                        hold time
                        errors here



I ran into that exact same problem a couple of years ago.  I was given 
the task of fixing (someone else's) design that featured a similar misuse 
of clock buffers in a Virtex 4.  I think the tools might have been ISE 
8.2.

PAR and Trace said it was fine.  Actual tests on the chip over 
temperature showed otherwise.

Moral: BUFGs have a large delay.  Don't expect PAR to be able to make up 
for that amount of hold time using routing.
You need to avoid going from your BUFR domain into the BUFG domain on the 
same clock edge.
One solution might be to insert FFs clocked from the other edge of the 
BUFG clock.
Another solution might be to connect the BUFG input to the IBUF output 
(not via the BUFR).


Regards,
Allan

Article: 154599
Subject: Re: V6 BUFR -> BUFG clocking structure (hold issue?)
From: jonesandy@comcast.net
Date: Fri, 30 Nov 2012 06:17:14 -0800 (PST)
Links: << >>  << T >>  << A >>

While I agree that there should be ways to avoid this with other design cho=
ices, the tool is clearly identifying the clocks as related (it reported sk=
ew and relavent edges), but apparently it does not always find/report some =
hold timing violations.=20

Are there options in Xilinx STA to run 4 corner vs 2 corner timing analysis=
? Or does it always run 4 corner? If it is not running 4 corner, that could=
 be the reason it is missing the hold time problem. I've seen other tools t=
hat offer the choice occasionally miss a timing problem in 2 corner timing =
mode. 2 vs 4 corner analysis has to do with whether all 4 combinations of m=
in/max clock and min/max data are analyzed. Tricks to make hold time analys=
es less pessimistic (by accounting for correlations in propagation delays) =
are always a potential issue.

Andy



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search