The remaining timing path domain is the Maximum output required time after clock. According to Xilinx toolbox, it is the maximum path from inputs to outputs. Gabor from Xilinx forums has a concise explanation on this.
..."Maximum output required time after clock" refers to the delay from the clock to external outputs of the top-level design for the worst case pins.
The second domain in the Timing Summary (Design Summary, Synthesis Report) is the Minimum input arrival time before clock. Based on Xilinx toolbox, it is the maximum path from the sequential elements to all primary outputs. Again, Gabor has a very good explanation on this one.
"Minimum input arrival before clock" is the required setup time from the worst case top-level design input to the clock...Again after synthesis these are only estimates, you need to place and route the design to get hard numbers. Also if your design as synthesized represents only a portion of a larger design, the input and output timings may be significantly different, as they may not represent signals going on or off of the FPGA.
He also stressed that if the time indicated in "Minimum input arrival before clock" is less than the time in the "Minimum Period", it may be possible to run the design at the maximum clock frequency specified.
The first item in the list is the Minimum period, one of the domains of timing paths. According to Xilinx toolbox, it is the maximum path from all primary inputs to the sequential elements. One good explanation is given by, again, gszakacs in a Xilinx forum.
Minimum period" after synthesis is an estimate of the clock period for signals inside the design. Thus you can invert this to get a feel for maximum clock frequency. This is not a hard actual number, as you can only see the true numbers after place&route. Also this may not be the actual minimum period for the design if you are limited by input and output timing. It only calculates the worst case path timing from clock edge to clock edge for flip-flops within the design. So if you have a path consisting of external input to flip-flop through look-up table to another flip-flop to an external output, only the path from the first flip-flop through the look-up table to the second flip-flop is measured for "Minimum period".
He also added
The minimum clock period depends on paths that go from the Q output of a flip-flip to the D input of another flip-flop in the design...The worst case path may in fact not be connected at the top level. You would need to look at a static timing report to see what the path is and whether you use it...Also note that the timing reported by synthesis is a best-guess estimate of the achievable timing after place and route. This is usually only useful when designing reusable IP for example or some other subsystem you would like to know the possible best case speed of. The real timing performance of a design is only known after place & route and can be found in the post P&R static timing report. Using the advanced properties for static timing report generation you can get a verbose report that includes uncovered paths in case there are critical paths that have not been constrained.
Maximum combinational path delay...is the maximum delay for signal propagation in your design, so changing signals faster than [this] will result in unexpected behavior.
They have an example there (Timing Simulation: Combinational Logic Section 2), where they made the signal transition faster which resulted in simulation failure - the output signals do not match the input signals because the inputs change too fast.
I heard of 'critical path' for the first time yesterday during a meeting. Our project leader was asking about an incorrect output in the main block. My teammate explained about a part in his design that is asynchronous. Then the proj leader mentioned 'critical path'. I do not know what it is so I did some reading. According to Design Recipes for FPGAs, during analysis of static timing, the delay from each input to each output of all devices is computed. The delays are then added up along each path through the circuit to get the critical path through the design. The fastest design speed is therefore obtained. The critical path is an approach to logic optimization.
(1) Wilson, P., Design Recipes for FPGAs, 2007, pp. 40 and187, Elsevier.
I feel so terribly burdened by having to do documentation. I had already spent 4 days with it (still counting) and I'm so slow in doing it. I know this is important in reconfigurable computing advocacy but my problem is, I'm not so good with words. I especially hate highfalutin techie words that only geeks will understand but not the common people. There. That's my problem. How do I relay such a beautiful thing as accelerated computing to young people without them being terrified that this is something they might not be able to grasp? I don't know how to start with this so I need at least a reference. I want a book that will give me just what I need. I don't want to spend too much time in writing. I want to practice coding. So I checked amazon for a guide to writing with good reviews. I saw "Writing for Computer Science" by Justin Zobel has excellent reviews (5 reviews only :)).
I'm excited to quickly read this one since it only has less than 200 pages. There's a relatively high probability I'll be able to finish this tomorrow. Hope this could speed me up and help me finish writing within this week.
Addendum (Oct. 03, 2008):
The book is very good! I just have to finish documenting one block. Hopefully, I'll be able to go back to coding this weekend!
I used UART to check my outputs bit-by-bit for the previous project that I did. Unfortunately, since I needed only a transmitter, the VHDL code that I have is only for the TX. I would like to settle first the answer to my question, "What is UART?" I found a very clear and simple discussion from the site of Rose-Hulman Institute of Technology. UART stands for Universal Asynchronous Receiver Transmitter. It is a parallel to serial data transmitter and a serial to parallel data receiver. The 'Asynchronous' term is there because of the fact that the clock for the UART need not be synchronized to either transmit or receive system clocks. I needed this UART to send my data outputs to my CPU's buffer and have MATLAB® check those bits. My input ports are clock, reset, my input data (from 1 to n depending on the number of outputs that I need to read, remember number of outputs not the number of bits) and of course, my output which is just a std_logic type. The simple technique my teammate taught me is to use a counter that is triggered by a synchronous enable. For example, I need to read 4 outputs from my main block. This 4 bit vectors will be fed to the input of my UART. Those 4-bit vectors are, say, 8 bits each. The first count of the counter (my UART) will be for the start bit, the next 8 contains the data, the last bit, the tenth bit will be the stop bit. The start and stop bits are necessary for every UART. This repeats for all my data. For every count, these bits will be fed to the 1-bit output. I show below a sample portion, taken from the middle of my code.
when 111=>output<='0';--this is the start bit
when 112=> output <=input10(0);
when 113=> output <=input10(1);
when 114=> output <=input10(2);
when 115=> output <=input10(3);
when 116=> output <=input10(4);
when 117=> output <=input10(5);
when 118=> output <=input10(6);
when 119=> output <=input10(7);
when 120=> output <='1';--this is the stop bit
For instance, my count ended at 120. After closing my case statement I added an if-end if statement that just says if the counter is less than 200 then increment the counter. I was adviced to have larger number for my counter. Notice that I used 200 instead of 120 as my upper limit.
Like all FPGA starters, I also struggled for a book that will serve as an FPGA tutorial. It was only this year (copyright of this book is February 2008) that I found one. This is for me (so far) the best introductory FPGA book--FPGA Prototyping by VHDL Examples, authored by Pong Chu. Learning by doing is the most effective pedagogical style and this book did not fail to deliver that one. I find Pong Chu's writing style very easy to understand because the discussions are clear. That is the most essential thing in relaying knowledge to a beginner -- clarity. That's enough for me. I don't need to say more about it.
I think one of the more promising applications of FPGA is in real-time visualization. To be able to have a solid foundation on this, I need to study graphics first or say, Digital Image Processing. I am currently reading a documentation of the Master's thesis (March 2005) entitled An FPGA-based 3D Graphics System by Niklas Knutsson of Linköping Institute of Technology. His abstract goes like this.
This report documents the work done by the author to design and implement a 3D graphic system on an FPGA (Field Programmable Gate Array). After a preamble with a background presentation to the project, a very brief introduction in computer graphics techniques and computer graphics theory is given. Then, the hardware available to the project, along with an analysis of general requirements is examined. The following chapter contains the proposed graphics system design for FPGA implementation. A broad approach to separate the design and the eventual implementation was used. Two 3D pipelines are suggested - one fully capable high-end version and one which use minimal resources. The documentation of the effort to implement the minimal graphics system previously discussed then follows. The documentation outlines the work done without going too deep into detail, and is followed by the largest of the tests conducted. Finally, chapter seven concludes the project with the most important project conclusions and some suggestions for future work.
I am after knowing the framework of such an application since there are already lots of books that discuss the physics of real-time graphics. I find quite few papers, much less books, that discusses the implementation of image processing on FPGA.
I find debouncing circuits very handy. Not only when I checked the test vector outputs of my design, but whenever I need to use a signal's event to trigger another signal. Debouncing solves the problem I encountered whenever I use the mechanical switches in the FPGA board particularly the push buttons. Mechanical switch bounces that when I push it once, the output could be three times the supposed signal. Good thing, I tried the Xilinx ISE 9.2i in-depth guide before, I learned that ISE has a template for a debouncer. Templates are accessed by the icon below.
On the tree at the left of the Language Templates subwindow, expand VHDL, then Synthesis Constructs > Coding Examples > Misc > Debounce Circuits. I played with the code trying to put the statement for the output within the clock statement. I also inverted the signals used to solve the output. Debouncers have been very useful to me.
“...it is impossible to explain honestly the beauties of the laws of nature in a way that people can feel, without their having some deep understanding of mathematics. I am sorry, but this seems to be the case." - R Feynman