Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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: 154576On 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. RickArticle: 154577
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". RickArticle: 154578
"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. - KerryArticle: 154579
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
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: 154581On 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
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. RickArticle: 154583
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. RickArticle: 154584
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, mmihaiArticle: 154585
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 JenningsArticle: 154586
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? -- glenArticle: 154587
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? -- mmhaiArticle: 154588
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 FoxArticle: 154589
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. -- glenArticle: 154590
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. -- glenArticle: 154591
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
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
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: 154594On 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 ThomasArticle: 154595
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 ThomasArticle: 154596
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
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
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: 154599While 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:
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