12-09-2009 03:47 AM
I am new to FPGA design, but my first schematic design seems to do what I want (at least, the behavioral simulation works as expected).
But now, I am fighting with understanding timing constraints as I am trying to work through the "Timing Constraints User Guide) from Xilinx (UG612 (v 11.1.1) April 29, 2009). Especially, I don't understand many things in page 50 of this book. I would be very grateful if somebody could look at figures 3-15 and 3-16 on this page and could help me out here.
At first, figure 3-16 (Hold violation waveform) must be wrong: In the 6th row (DATA_OUT at destination output FF), DATA_OUT changes from DATA0 to DATA1 when CLK raises at _SOURCE_ FF. I don't understand this since the input clock of the destination FF is skewed by 2ns against that of the source FF and the destination FF should change its output data only when its own clock raises (i.e. 2ns after CLK at the source FF raises).
Similarly, in the 5th row (DATA at destination input FF) DATA also changes from DATA0 to DATA1 with the raising CLK at the source FF. I don't understand this: When the clock at source FF raises, the data at source FF output changes, but according to figure 3-15, the change should need 1ns to arrive at the input of destination FF, an so there should be a delay of 1ns between the raising edge of CLK at source FF and the data change at input of destination FF.
Now some more important principal questions:
There is a formula on this page: "Hold Time = Clock Path Skew + Synchronous Element Hold Time - Data Path Delay". I think I have understood what the Clock Path Skew and the Data Path Delay are, but could someone explain what exactly the Hold Time (left side of the formula) and the Synchronous Element Hold Time (right side of the formula) are, perhaps by example of figure 3-15?
Besides this formula, I can't see where the problem is in figure 3-15. I think the circuit would work correctly and well-defined if we could rely on the clock skew being 2ns exactly and the data path delay being 1ns exactly or with a maximum jitter of 10%. Now imagine we had a data delay of 0 and a clock skew of 0 (which at a first glance may be considered the ideal situation): In this case, I think the output of the circuit would be undefined, because the source FF and the destination FF would transfer the input data to their outputs at the very same moment. But what does "very same" mean? You would not know if the "old" data or the "new" data is at the input of the destination FF when the clock raises. So I think you even need a clock skew for the circuit to work correctly (for example, you could invert the clock signal for the destination FF which could be considered as a skew of 50%).
Could someone please shed some light on this and correct me if I am wrong?
12-09-2009 06:20 AM - edited 12-09-2009 06:22 AM
Although i'm not an expert i'll try to help. Something is certainly not ok whit that figure (3-16). DATA1 can't be at the destination input (row 5) before it left source output (row 4) so i'm not trying to decode that further.
Regarding your quesstion on hold time the key is the sentence on the top of the page: "Note: The data must stay valid at its input pins at least a hold time after the arrival of the active clock edge at its pin."
So Hold Time the time the data mast stay valid after the clock edge on the input = Clock Path Skew the delay of the clock + Sync Element Hold Time most inportant part! the actual requirement of the element reciving the data probably a FF (see datasheet) - Data Path Delay the delay of the data loosens a bit the requirement since the new data will arrive later so the old data remains longer.
Clock jitter can be added to clock path skew, since in the worst case the clock edge arrives later, it tightens the requirement.
12-09-2009 06:47 AM
that picture looks also strange to me....anyway. To your more important question:
rules for hold time analysis: fastest Data path vs. slowest clock path.
and just the opposite,
rules for setup analysis: slowest data path vs fastest clock path.
Tool calculates the number for fastest and slowest values using Process,Voltage and Temperature characteristics
of the given device.
So, now you can draw a imaginary danger zone around the rising edge of clock.
Left side of it is the Setup zone, right is the hold zone.
I think, with the "hold time" in your question is meant the slack.
Hold time analysis between 2 FFs is done like: the data the first FF(FF1) is so fast that it can reach the second FF just
after the same clock edge(the edge FF1 used). Now think about the danger zone(hold time) of the FF2. The data should
not toggle inside that zone.
To be pessimistic, tool takes the + sign for clock skew, this makes it harder not to violate the hold time of 2nd sync. element.
Making things ideal, than you have the same situation as if you are doing a functional simulation.
There are new zero delta delay used. And even the data delays and skew are zero, simulation works as intended.
I hope i could help you little to understand things.
The formulas xilinx uses also little strange for me to understand sometimes.
For example, following is a hold time analyis between 2 register, taken from timing analysis report.
Can you build a bridge between the formula you gave below and the one used here?
Slack (hold path): 0.065ns (requirement - (clock path skew + uncertainty - data path))
Source: I_WBtoI2C_uut/reg_txr_to_fifo(0) (FF)
Destination: I_WBtoI2C_uut/wr_buffer/BU8.SLICEM_G (RAM)
Data Path Delay: 0.065ns (Levels of Logic = 1)
Clock Path Skew: 0.000ns
Source Clock: s_wb_clk rising at 15.000ns
Destination Clock: s_wb_clk rising at 15.000ns
Clock Uncertainty: 0.000ns
Data Path: I_WBtoI2C_uut/reg_txr_to_fifo(0) to I_WBtoI2C_uut/wr_buffer/BU8.SLICEM_G
Delay type Delay(ns) Logical Resource(s)
Tcko 0.174 I_WBtoI2C_uut/reg_txr_to_fifo(0)
net (fanout=1) 0.108 I_WBtoI2C_uut/txr_to_fifo(0)
Tdh (-Th) 0.217 I_WBtoI2C_uut/wr_buffer/BU8.SLICEM_G
Total 0.065ns (-0.043ns logic, 0.108ns route)
(-66.2% logic, 166.2% route)
12-09-2009 09:18 AM
thank you very much for your answers. In the meantime, I still have tried to figure things out, and I am now convinced that the misunderstanding occurred due to errors and ambiguous writing in the Xilinx Timing Constraints User Guide. For those who are suffering like me:
I think the key sentence at the top of the page is wrong at the most important place. The more I think over it, the less it makes sense to me. First, the hold time AFAIK always refers to OUTPUT pins. Second, by definition, the data at the INPUT pin of a register has to be valid only for a very small time frame before and after the corresponding raising edge clock (I think this is the setup time and perhaps the synchronous element hold time). So why should the the data be valid at its INPUT pin for such a long hold time that the respective formula suggests?
I am quite sure that this is a typical cut-and-paste-error (from the corresponding sentence on page 49). Thus, the key sentence on page 50 should read: "The data must stay valid at its OUTPUT pins at least a hold time after the arrival of the active clock edge at its pin." Then, the formula for the Hold Time (a few lines below) would perfectly make sense because the NEXT FF in the chain would not work as expected if the formula would not be satisfied.
It then also would be clear why the software had to report a hold time violation if the formula would not be satisfied: If the OUTPUT of a FF changed within the hold time (calculated according to the formula), the NEXT FF would have the NEW data at its input when it got the active clock edge; thus, the OLD data would be lost.
The User Guide should state clearly that it obviously is the INTENTION of the circuit shown in figure 3-15 to DELAY the input by TWO raising clock edges (a sort of serial shift). If then the clock skew would be 2ns and the data propagation time would be 1ns, the second FF would transfer its input data with the SAME raising clock edge as the first FF, so the circuit would not work as expected. In my original naive thoughts, I assumed that it would be the intention of the circuit to transfer the input data through both FFs to the output with the SAME raising clock edge; I still think that this would work without problems if the skew and propagation time would be reliable.
Could someone comment on my theories?
12-09-2009 11:02 AM
Hi timing is a big issue,
and how it's specified is changing over time.
If you can raise a web case, this might get fixed.
Do you want to post your ucf file ( the timing parts ) and we'll have a look
12-10-2009 12:10 AM
Hello and thanks for the offer of having a look to my UCF file.
To my regrets, I even don't have an UCF file yet since I wanted to understand the basics before I do the real work. All of my questions solely refer to page 50 of the Xilinx Timing Constraints User Guide.
12-10-2009 01:37 AM
Can I make a bold comment here, and I am expecting to be flamed any minute.
Don't worry !
just go for it.
You would be amazed at how many designs I see where there is no timming in the UCF file, it only contains pin information.
people just look at the timing report to check it will work as they want !
When you do do a UCF file.
build it up in stages.
First, and most inportant, have a period constraint for every clock into the device.
all internal clocks defined by these will then have automatic timing generated.
Next look at offset in and off set out for all the IO pins.
specify the one that you think are timmign critical, then the rest, if you want..
Only then if you have problems go deeper into timing specifying.
But honestly, you could well find that just the period is all you need.
Have a go, the most important thing is to understand the timing out put report, that tells you how to change your code .
12-10-2009 06:05 PM - edited 12-10-2009 06:10 PM
First of all i share John's opinion. Start a design. You'll learn by doing. It will be much easyer in small steps and you'll understand why these constraint are required. For the first few, you'll need just the pin assignement.
Now about hold time. The hold time requirement is for an output pin but because of the input pin it is connected to. (They are usually in pairs :) )
You're not right when you state that "data at the INPUT pin of a register has to be valid only for a very small time frame before and after the corresponding raising edge clock". It depends. Inside the FPGA for example a Spartan 3 it is true. If you see the datasheet there is 0 hold time specified for logic blocks. It means that the data do not have to be valid at the input of that block after the clock edge. However this is not always the case especially if you're connecting to some external circuitry. Go and check a few digital ic datasheets.
For example AD9772A is 14bit DAC from Analog Devices. In one configuration it requires 1.5ns of setup time and 1.3ns of hold time on it's data inputs. This means you'll have to send data to it that is valid on it's inputs at least before 1.5ns of the clock edge and it remains valid at least 1.5ns after it. Note that the clock edge specifies the moment when it arrives to the input and not when it leaves the output. If in your design this DAC is connected to the FPGA you'll have to make sure these timing specifications are met otherwise the DAC is not guaranteed to work and you can do this by adding constraint to your outputs.
If i haven't confused you enough :) i'll mention the other mode of the same DAC when the input timing requirement is -0.7ns setup time and 3.3ns hold time. This means that the data do not have to be valid at the clock edge just 0.7ns after it and it has to be valid for 2.6ns.
It is not alway easy if you're clocking at 160MHz and the period is just 6.25ns :) and it is still nowhere compared to really high speed stuff.
Start some design, you'll see for yourself :)
12-11-2009 12:51 AM
thanks for confirming the hold time issue - what you say is what I wrote on 12-09-2009. It's clear that the hold time requirement arises due to the next member in the chain. But the formula given on page 50 of the user guide is definitely from the output's point of view, and the clock edge (from which the hold time is measured) also is the clock edge at the source FF.
That having said, the following senctence (at the top of page 50 of the user guide) is not only confusing, but false: "The data must stay valid at its input pins at least a hold time after the arrival of the active clock edge at its pin." The hold time is counted from the clock edge of the source FF and ensures that the destination FF can read the data, so the data must stay valid at the output pin of the source FF for the hold time and not at some input. On the contrary, the time for which data has to be valid at the INPUT of the destination FF is calculated in another way (described on page 49 of the user guide) and is designated another name.
I really would appreciate if Xilinx could correct these error in the user guide - when you are a newbie, such things can cost you some days...
Secondly, regarding the time frames at the input: my questions related to the situations inside the FPGA. I have already done some "discrete" designs, and therefore I know about the setup and hold requirements for most external ICs.
Learning by doing may be the appropriate method in many cases. But I think I even would not be able to understand the timing reports without having understood the most basic theory. Furthermore, due to the nature of the project we are doing at the moment, just doing and then checking if it works is not enough. What the software produces, be it the placement or the timing reports, must be understood to the last detail in this case, backed by theory and compared to results obtained manually in random sample tests.
Thank you very much for all your help!
12-11-2009 07:31 AM
Ok, now it think i do understand what you're talking about. I think the problem is that the definition of hold time (as if such thing exists) is what that note says on the top of the page. It is an input related thing. The misleading is to call the result of the equation the same way.
Anyhow if you're familiar with discrete designs internals of the FPGA are the same. The only thing about hold time is to know the specification for the input of the receiver and then you can calculate the requirement for the transmitter output based on that equation let's call that whatever you want.
I really appreciate you approach that you want to have a general knowledge first. Maybe it's a better way, i don't know. This is just a little weird to argue about a few lines in a shomewhat crappy document rather than arguing about what the device does or not does.
Keep it up!
12-15-2009 02:29 AM - edited 12-15-2009 03:00 AM
after spending the weekend with thinking about the problems described in this thread, I have to apologize and to admit that some of the things I have written are definitely wrong. I hope the community will excuse this as a newbie's fault. The good thing is that I now think I finally have got it. So I will try to make clear the terms and the calculation method for the hold path calculation from scratch, and I will provide an example for this. I hope that this will help others because I did not find a Xilinx user guide, white paper or application note where this is explained cleanly from the beginning on.
The example situation: The FPGA is an xc1400a-4ft256, the circuit implemented is very simple (see following image).
CLK_IN has a period constraint (10 ns, 50% duty); there are no other constraints. We now want to understand the timing report for this situation.
At first, some basics: The intention of the circuit is to transfer the data at DATA_IN to DATA_OUT, but it is crucial to understand that there has to be a delay of 1 clock cycle for this, i.e. it's a sort of serial shift. With the raising edge of the clock, FF1 should output the data at it's D input to it's Q output, but FF2 should transfer this data with the NEXT raising clock edge. This requirement could be split in two sub-requirements.
1) Beginning with the raising clock edge at FF1, the NEW data must flow from the input of FF1 to the input of FF2 in such a manner that it arrives and stables there before the NEXT raising clock edge occurs at the clock input of FF2. If that would not be the case, the NEW data could not be transferred from the D input of FF2 to the Q output of FF2 with this next raising clock edge, and the circuit would not work like intended.
Checking of this requirement is done by the SETUP PATH ANALYSIS.
2) Beginning with the raising clock edge at FF1, the NEW data must NOT flow from the input of FF1 to the input of FF2 in a manner that it arrives there before or with the SAME raising clock edge. If that would be the case, the data would be transferred through FF1 and then through FF2 with the SAME raising clock edge, and the circuit would not work as intended.
That means: With the raising clock edge at FF1, FF1 transfers the NEW data from D to Q. But at the same time, the OLD data (data before the raising clock edge) must eventually be held at Q for a certain time to ensure that the OLD data remains valid at the INPUT of FF2, i.e. that FF2 transfers this OLD data from D to Q with the very same raising clock edge. The NEW data at FF2 should only be transferred with the NEXT raising clock edge.
So, indeed, hold time analysis is about the INPUT of FF2, and I was wrong regarding this in my previous posts. The sentence at the top of page 50 of the Timing Contstraints User Guide is not wrong, and there is no cut-and-paste error. Apologizes to the Xilinx people!
At FF1, transferring the new data with the raising clock edge and at the same time holding the old data at the output for a certain time is a contradiction. It is not possible. We will see later how this contradiction is resolved.
Checking of this second requirement is done by the HOLD PATH ANALYSIS.
I will concentrate on the hold path analysis only since this is the thing which was the most difficult for me. First of all, we have to clarify some definitions, thereby referring to the Timing Contraints User Guide, page 50:
Hold time: This is the time that the OLD data must be held at the OUTPUT of FF1 after the raising clock edge (which actually should transfer the new data from D to Q) to fulfill the hold path requirement. I will denominate this time span Toh (oh stand for output hold; the Xilinx software and manuals are sometimes talking about a Th which is a different thing - see below).
Synchronous Element Hold Time: This is an ambigious term. To make it clear, it is what is called Tckdi in other Xilinx manuals, for example UG384 (Spartan-6 FPGA Configurable Logic Block User Guide), page 36. It's the time that the D input of FF2 must be held stable AFTER the raising clock edge to guarantee a reliable data transfer from input D of FF2 to it's output Q. I will stay with the Xilinx convention (although it's referred to, but defined nowhere in the manuals and guide for the Spartan-3) and call this time Tckdi also. To even increase the confusion, the Xilinx software timing reports state Tckdi = -Th; as usual, there is no definition of this Th anywhere in the manuals or the help files, so I'll avoid this term.
Data path delay: This is the time that the data needs to flow from FF1 to the input of FF2. It is counted from the raising clock edge at FF1. I will denominate this time span Tp (p stands for propagation).
Clock path skew: This is the time that the raising clock edge takes to propagate from FF1 to FF2. I will denominate this time Ts (obviously, s stands for skew).
We also need some definitions which are not from the Xilinx manuals:
T1, T2: These are the points in time when the raising clock edge arrives at the clock inputs of FF1 and FF2, respectively.
Finally, we get to the interesting stuff. For a moment, let us suppose that there is such a thing like an output hold time Toh at FF1. Then the following inequation would describe the hold path requirements:
(1) T1 + Toh + Tp > T2 + Tckdi
The left side is the point in time when the NEW data will arrive at the INPUT of FF2; the raising clock edge at FF1 occurs at T1 by definition, then the OLD data is held for Toh at the output of FF1; at (T1 + Toh), the output of FF1 becomes the NEW data. The new data then need the time Tp to flow to the input of FF2.
The right side is the earliest point in time when the data at the INPUT of FF2 may change from the OLD data to the NEW data (we remember that FF2 should transfer the old data in this cycle). The old data must still be at the input of FF2 when the raising clock arrives and must eventually remain stable for some additional time after the clock edge to enable a reliable data transfer between D and Q; so the earliest point in time when the data at the input may change from OLD to NEW is (T2 + Tckdi).
Note: We here neglect the clock uncertainity. It would be very easy not to neglect it, the calculation would be nearly the same. Since this post should help newbies like me, i will keep it as simple as possible, and we don't loose anything here because the uncertainity will be 0 anyway, see below.
Let's do some very simple transforms of (1). I'll show them step by step and won't comment further on them.
(2) Toh + Tp > T2 - T1 + Tckdi
(3) Toh > T2 - T1 + Tckdi - Tp
(4) Toh > (T2 - T1) + Tckdi - Tp
(T2 - T1), by definition, is the clock skew between FF1 and FF2, so (4) can be written as:
(5) Toh > Ts + Tckdi - Tp
As mentioned above, at FF1, there is a contradiction: transferring the NEW data with the raising clock edge from D to Q and at the same time holding the OLD at Q for Toh is impossible. So the requirement for the hold time is:
(6) Toh <= 0
That means that there must not be such an output hold time at FF1. When you combine (5) and (6), you get:
(7) 0 > Ts + Tckdi - Tp
exactly the formula at the top of page 50 of the user guide. We now
understand also what a hold time violation is: When (skew + Tckdi) gets
greater than Tp, inequation (7) isn't fulfilled any more, and thus the
circuit would not work as intended.
The attentive reader may state that the definition of a hold time violation on page 50 is slightly different: "A hold time violation occurs when the positive clock skew is greater than the data path delay". This is wrong or at least ambigious since Tckdi is neglected in this definition. The contradiction resolves by knowing that the Xilinx software, by convention, sums up Tp and Tckdi in one number and calls this number the data path delay. So the user guide seems to use the nomenclature of the software at one moment and its own, "clean" definitions at the other (please note that the FORMULA at the top of page 50 does not neglect Tckdi, the "synchronous element hold time", but the verbal definition of the hold time violation does).
Let's the theory make clear by an example. The following is a part of the timing report which was generated from the configuration and circuit mentioned above (ISE WebPack 11.3).
Slack (hold path): 1.040ns (requirement - (clock path skew + uncertainty - data path))
Source: FF1 (FF)
Destination: FF2 (FF)
Data Path Delay: 1.042ns (Levels of Logic = 0)
Clock Path Skew: 0.002ns (0.006 - 0.004)
Source Clock: CLK_IN_BUFGP rising at 10.000ns
Destination Clock: CLK_IN_BUFGP rising at 10.000ns
Clock Uncertainty: 0.000ns
Minimum Data Path: FF1 to FF2
Location Delay type Delay(ns) Physical Resource
SLICE_X66Y84.YQ Tcko 0.541 FF1_TO_FF2
SLICE_X67Y85.BY net (fanout=1) 0.361 FF1_TO_FF2
SLICE_X67Y85.CLK Tckdi (-Th) -0.140 DATA_OUT_OBUF
Total 1.042ns (0.681ns logic, 0.361ns route)
(65.4% logic, 34.6% route)
Let's analyze this step-by-step: source and destination are self-explanatory.The requirement for Toh is 0 since there could not be such a thing like an output hold time related to the raising clock edge. The clock path skew is 2ps in this case.
As we can see, the source clock raising and the destination clock raising are assumed to be the same. This has nothing to to with the real situation (we have already seen that there is a clock skew), but must be understood as a theoretical ideal. Just take it as a sign that this part of the report is about HOLD analysis (remember that hold analysis is about the timing of ONE and the SAME raising clock edge at FF1 and FF2 while setup analysis is about the timing of two sequential raising clock cycles).
Likewise, for this type of report, the clock uncertainity is 0. This is not obvious at a first glance since the the jitter we had given in the period constraint was 10ps. Once again, remember that we are talking about one single raising clock edge and it's associated data flowing from FF1 to FF2. If the clock edge came to FF1 with jitter, the jitter would remain the same while the clock edge would flow to FF2, There is only a skew, namely the time the clock edge needs to flow from FF1 to FF2, but this skew is well-known and always the same, and no additional jitter is added on the way between FF1 and FF2. The jitter we have given in the timing constraint applies to DIFFERENT clock edges and so applies to setup analysis, for example, but this is outside the scope of this post.
The only thing which remains to understand is the data path delay, and that was hard, at least for me. First of all, please note that the software indeed defines Tckdi as part of the data path delay, as mentioned above. Now let's examine every line:
Tcko is the "clock-to-output" time of the source FF, namely FF1. It's not too difficult to understand that a register needs some time to drive its output stable after the data has been transferred with the raising clock edge. Furthermore, it is clear that this time span INCREASES the data path delay.
net is just the time that the data need to flow through the "wires" which connect the output of FF1 to the input of FF2. It should be needless to say that this also increases the data path delay.
Now the real difficult part: To understand how Tckdi is absorbed into the data path delay calculation, we have to do a last transformation of inequation (7):
(8) 0 > Ts - (Tp - Tckdi)
(9) 0 > Ts - (data_path),
(10) data_path = Tp - Tckdi = Tcko + net - Tckdi
By comparing these (in-) equations to the formulae of the timing report above, we note that they are the same (uncertainity neglected).
The important thing here is that we have to subtract Tckdi from Tp to calculate what the software calls the data_path; just see it as "effective data path delay". This is natural: A high Tp is good for our situation; the longer Tp is, the smaller we could make our output hold time Toh - and we have to make it as small as possible; effectively, it would suffice to make it smaller than 0, but the smaller we can make it, the bigger is the resulting safety margin. But if there is a positive Tckdi, we would have to hold the old data stable at the input of FF2 for this additional time, i.e. we would also have to hold the output of FF1 stable with the old data for this additional time, so it would DECREASE our "effective data path delay".
So far so good, but personally, I have been surprised when I saw that Tckdi was negative in the timing report and thus even increased the "effective data path delay". I was chewing on this for a day or so. Having done a few discrete designs, I was used to thinking the following: Nearly every clocked IC indeed needs it data input to be stable for some time AFTER the clock event which latches / transfers the data into the IC, so I didn't get to understand what was going on here.
Finally, I have found the explanation (at least, I hope so): there is no such a thing as a pure register or pure FF in an FPGA (at least, not in Xilinx FPGAs). Every combinatorial logic, every storage element, every FF is part of slice, every slice is part of a CLB and so on. A newbie will only understand this if he is ready to read the user manuals of the respective FPGA family. Within a slice, the clock signal to the elements of the slice is routed on the fastest possible paths, so it flows much faster from the clock entry of the slice to its destinations than the associated data.
The clock signal within a slice is so much faster that this indeed leads to a NEGATIVE Tckdi. Although the destination FF in a slice by itself may need a positive Tckdi (and I am pretty sure that this is the case, although this Tckdi may be very small), the data input at the ENTRY of the SLICE may change even BEFORE it's raising clock edge since the NEW data needs to flow through the slice before getting at the input of it's destination, and that data flow takes much more time than the flow of the clock edge. During this time, of course, the OLD data will remain at the input of the destination FF although the NEW data is already at the data input (and on it's way to the destination element) of the destination SLICE.
Having said that, what the timing report calls "net" obviously is the time it takes the data to flow from the output of the SLICE with the source FF to the input of the SLICE with the destination FF; likewise, the clock skew is the delay of the raising clock edge measured between the clock input of the source SLICE to the clock input of the destination SLICE, and all other measurement categories have to be handled this way, too.
To summarize, Tckdi refers to the inputs of the desination SLICE and not to the inputs of the single destination element. Measured in this way, it indeed can become negative and thus "help" the hold path requirement by increasing the effective data path delay.
Please note that in the timing report you can see where the logical elements are placed. In our case, the two FFs are indeed placed in different slices (but in the same CLB). Please refer to the Spartan 3 user guides if you are interested in this.
I hope that this post will help other newbies to understand what
is done by the software when it comes to timing analysis, and that it
will perhaps motivate the Xilinx people to write a fundamental article
about that topic or, first of all, clearly define and harmonize the
terms which are used throughout the different manuals and guides. I can
say that, from a newbie's point of view, I am enthusiastic and grateful
about their free software which, in my eyes, is of very high quality,
but it cost me nearly a week to understand the timing analysis of the
most simple circuit shown above, and this was very unsatisfying becaus
it did not arise from my dullness (at least I hope so), but from the
many terms which are referred to in the manuals and guides but which
are defined nowhere, and by other ambiguities and inconsequences in
these manuals and guides. We newbies really need it explained from the
03-19-2010 01:00 AM
EXCELLENT explanation thanks. The hold time of FF2 being considered in the data path and the reason for it being negative were very illuminating.
How about one on setup analysis in a similar vein (i.e. pertaining to Xilinx tool-specific methods/nomenclatures)? That would make it 2 very useful bookmarks :)