Timing violation

Why can the  FPGA still work well even if there are a few violation inside timing report?

Timing checks are done across all combinations of process, voltage and temperature (PVT). Each device will have different real timing characteristics based on the individual device (there is variation from device to device), the voltage of your board and the temperature the device is at.
The goal of static timing analysis is to verify that a design will work across all devices at all legal voltages and all legal temperatures. This will only be the case (assuming your constraints are correct) when the design passes static timing analysis. However, a small timing failure in static timing analysis will only show up as a system failure if you get close to the worst combination of process, temperature and voltage. On any one board at lab temperatures, small timing violations are not likely to matter.
However, that has to remain in context - if you are planning to build a fair number of systems and use them under real world conditions, then you must get timing closure (static timing analysis passing with no violations) to ensure a reliable system.
Avrum

Similar Messages

  • "LabVIEW FPGA: The compilation failed due to timing violations, but there is no path information because the timing violations are not of type PERIOD

    The compilation of my labview fpga vi fails with the error message "LabVIEW FPGA:  The compilation failed due to timing violations, but there is no path information because the timing violations are not of type PERIOD".
    In the 'final timing (place and route)' report, the requested frequencies are all below the maximum frequencies and the compilation error message is only displayed at the very end on the 'summary' page.
    I tried to optimize my labview fpga vi with pipelining, but had no success.
    Can anybody offer some advice on how to debug fpga code with this error? Is this really a timing error or something else?
    Software:
    Labview 2011, fpga 2011, xilinx tools 12.4 sp1
    Hardware:
    NI PXIe-1071 Chassis
    NI PXIe-8108 Embedded controller
    NI PXIe-7965R FPGA FlexRIO FPGA module
    NI 5761 250 MS/s 14 bit Analog input digitizer
    The Xilinx log of the compilation run is attached.
    Also, this issue was already discussed in this thread ~6 months ago, but no satisfying answer was offered so far...
    Thanks,
    Fabrizio
    Attachments:
    xilinxlogc.txt ‏2313 KB

    Hi Kyle,
    the problem is: I have one computer which compiles the VI successfully and a second one which shows that error. Both use the same software setup (LV2011SP1+RT+FPGA from DS2012-01). Both use the same project file - atleast SVN shows no difference.
    - You can have one FPGA VI where one computer is compiling successful and a second one complains. (Btw. I have a SRQ running in Germany on this topic.)
    - More problems: After successful compiling on first computer and transferring all to second computer (using SVN, including the full project folder with all files like bitfiles, lvproj, and everything) the second computer is unable to start the RT executable due to error "FPGA VI needs to recompile". Solution so far: Call the FPGA-OpenReference with the bitfile instead of the VI (as I used to do until now)...
    - More problems: After modifying the FPGA-OpenReference to use the bitfile (on the 2nd computer) and transferring all the files back to the 1st computer (using SVN as before, including the whole project) the 1st computer complains: FPGA-OpenReference is creating a different reference than is used in the VI. So what happens here? On one computer my VI is ok, the reference is typed correctly. Transferring all the files to a different computer the VI isn't ok anymore due to changes of the reference??? You know: all files are the same: lvproj, FPGA bitfile didn't change, cRIO reference didn't change...
    All those problems didn't occur on my RT-FPGA projects in LV2010SP1. I'm not pleased...
    Best regards,
    GerdW
    CLAD, using 2009SP1 + LV2011SP1 + LV2014SP1 on WinXP+Win7+cRIO
    Kudos are welcome

  • FPGA Compile Error: Timing Violation

    All,
    I've got an issue here I've been struggling with for a couple days now. I'm trying to implement a very watered down Kalman filter in the FPGA (I wanted it to run faster than I had it running in the RT.) After quite a bit of optimization, I'm still stuck to no avail. This first thing I tried was simply using the filter I had and changing my math to use fixed point instead of floating point. However this was about 20 operations in series (multiplies, adds, subtracts, and one inverse, (( what's the most efficient way to do an inverse in the FPGA? ))) and the FPGA did not like that at all. So I tried to pipeline the operation. Now mind you this isn't a true pipline because new data cannot be introduced to the pipe in each cycle (I need the output of the last cycle before I can introduce new data,) but I was simply trying to split up the math and have the FPGA only do part of it on each iteration of the while loop, because I thought the FPGA would be able to run this filter way faster than I needed to.
    Here's the error I'm getting...
    Status: Compilation failed due to timing violations.
    Click the Investigate Timing Violation button to display the Timing Violation Analysis window.
    Device Utilization
    Total Slices: 59.0% (12084 out of 20480)
    Flip Flops: 28.5% (11692 out of 40960)
    Total LUTs: 45.9% (18788 out of 40960)
    Block RAMs: 0.0% (0 out of 40)
    Timing
    MiteClk (Used by non-diagram components): 33.04 MHz (69.24 MHz maximum)
    40 MHz Onboard Clock: 40.41 MHz (30.29 MHz maximum)
    Actual Xilinx Options
    Synthesis Optimization Goal: Speed
    Synthesis Optimization Effort: High
    Map Overall Effort Level: High
    Place and Route Overall Effort Level: High
    Start Time: 6/6/2010 10:11:47 PM
    End Time: 6/6/2010 10:57:33 PM 
    And then when I try to investigate the timing violations the "Timing Violation Investigator???" gives me this!!:
    Possible reason(s):
    An internal error occurred. Please try again or contact National Instruments.
    Details:
    Error Code --> -61499
    Error Text --> <APPEND>
    Additional Information: There is no matching tag in Xilinx twx file
    There is no matching tag in Xilinx twx file
    Also,
    I was able to successfully run the "Timing Violation Investigator" a couple times. The first time it pointed to a multiply operation which i replaced with high throughput math and pipelined. The second time it pointed to "non-diagram components," how am I supposed to fix that?
    I've attached the code and the xflow.log! Thanks for your time!
    Thanks!
    Ken 
    Attachments:
    FPGA.zip ‏778 KB
    xflow.txt ‏1138 KB

    Hey Ken!
    If you hit the "Investigate Timing Violation" button and go to the analysis page, it looks like there are a couple of math functions that are taking longer than expected.
    If you replace them with high-throughput math equivalents (from the FPGA Math & Analysis palette) and manually configure the inputs and output FXP word/integer lengths, you might be able to get them within the timing requirements.
    Let me know if that works!
    Caleb Harris
    National Instruments | Mechanical Engineer | http://www.ni.com/support

  • Compilation failed due to timing violations, Getting Xflow error and resources over use.

    Hi,
    I am extensively using Fixed point math library functions which i have downloaded from NI website in my FPGA application.I am getting following errors while compiling the code.
    I would like to know is there any limitations in using fixed point functions?
    I am configuring all funtions as a 64 bit word length and 32 bit integer length in cofig parameter set up and all are outside the timed loop.
    Apart from below error it is occupieng LUT's 300% in one simple VI (mathematical calculations using fixed point functions).
    So i would like to know is there any way to optimize the code?.
    Status: Compilation failed due to timing violations.
    The compile process reported a timing violation.
    Suggestions for eliminating the problem:
      * For Timed Loops with timing violations
          - Reduce long arithmetic/combinatorial paths
          - Use pipelining within Timed Loops
          - Reduce the number of nested case structures
      * Reduce clock rates if possible
      * Recompile
    Refer to the LabVIEW Help for more information about resolving compilation errors. Click the Help button to display the LabVIEW Help.
    Compilation Summary
    Device Utilization Summary:
       Number of BUFGMUXs                        2 out of 16     12%
       Number of External IOBs                 214 out of 484    44%
          Number of LOCed IOBs                 214 out of 214   100%
       Number of MULT18X18s                     69 out of 96     71%
       Number of SLICEs                       4387 out of 14336  30%
    Clock Rates: (Requested rates are adjusted for jitter and accuracy)
      Base clock: 40 MHz Onboard Clock
          Requested Rate:      40.408938MHz
          Achieved Rate:       36.974044MHz    <<<=== Timing Violation

    lion-o wrote:
    The Fixed Point Library is certainly not a demo, and we encourage you to use it extensively.
    Really? "Demo" is perhaps too strong a word, but the NI Labs page says that the toolkits there "aren't quite ready for release" and are "experimental prototype"s. My understanding was that they work, but are only meant to show potential future products and get feedback on them. If this is not the case, perhaps the wording needs to be changed.
    I know I wouldn't want to be using something throughout my code and then find out that it is not supported when the next LV version came out because it was only a prototype. Can you promise support into the future for these? If you can't, that should be clearly stated.
    Try to take over the world!

  • Timing violation on NI 9149 but not on cRIO

    I get the Timing Violations error when compiling an acquisition using the NI 9205 module on my NI 9149.
    I have tried compiling on the 40, 80 and 120MHz clocks with same results. I am not performing any complex tasks as yet so why am I getting this issue.
    When I compile same on my cRIO, it compiles fine with no issues
    I have copied the timing violations details here and theFPGA file 
    Path 1
    This non-diagram component is required in the design. Internal name: /Crio9233Resource3/Crio9233ResourceCorex/Crio9233x/Crio9233AdcSyncHandlerx/cSync_n_reg.
    This non-diagram component is required in the design. Internal name: /dio25_INST_0/O.
    Path 2
    This non-diagram component is required in the design. Internal name: /cRio9205_Resource2/Crio9205ResourceCorex/cRio9205x/cRio9205CommSmx/cShiftReg_reg[15].
    This non-diagram component is required in the design. Internal name: /dio13_INST_0/O.

    So I have solved the problem.
    I created a new project. Added my ethernet RIO and modules then recoded the failing VI in the new project. I also did not add a loop count. I compiled as I added more functionality to try and be aware of what could trigger the error. I noticed that at the early stage of coding, the presence of Loop Count gave the same error.
    The strangest thing is that when the coding was almost completed, I added a Loop Count and no error was thrown. Strange indeed.
    Hope this helps someone. 

  • NI5640R FPGA non-diagram component compilation timing error

    I've tried to rebuild the NI5640R example "ni5640R Template" without adding or changing anything.
    Got timing error (see below), saying that requirement missed by 0.16ns, because of some non-diagram components: /sDac0Reset, /aDac0Reset_or00001, /aDac0Reset. Xilinx options were set to "use recommended settings".
    I've tried this several times, always getting almost the same result. Another example: requirements missed by 0.40ns, because of /sDacSimultReset, /aDac0Reset_or00001, /aDac0Reset. This is still with recommended settings.
    Then I tried to compile with design strategy "Timing Performance". 5 out of 6 times compilation failed with timing violation 0.30-0.50ns.
    Then I tried to compile with design strategy "Balanced". This time it failed only 2 times out of 6 with timing violation 0.02-0.04ns.
    I guess using the "Balanced" strategy works more or less, but maybe there is some better way to address this? I don't even need DAC in my project, so maybe there is a way to exclude it?
    Solved!
    Go to Solution.

    hey thu^^,
    I tried this with LabVIEW2013, FPGA module, NI5640R v1.7 drivers, and successfully compiled the example template. I'm attatching my screenshots. Please let me know if there is any difference between my experiment and yours.
    Attachments:
    XilinxOptions.png ‏15 KB
    compilationSummary.png ‏23 KB
    finalTiming.png ‏24 KB

  • Design does not meet the timing constraints of the specified clock

    Hi,
    I am using labVIEW FPGA 2011 and FlexRIO 7965R (virtex 5 SX95T). I am trying to use multiple simple dual port RAMs (generated through xilinx coregen tool) in cascade. The data read from one memory block is written to the next memory block and so on. I want the design to run as fast as possible. I have used SCTL rate of 346MHz in my design. But when i compile the code, timing violation error occurs. And the maximum clock rate achieved is 291.25MHz. The timing vilation analysis window always show the feedback node and controller as paths which failed to meet the timing contraints. I have also used DMA and VI Scoped FIFOs in my design for data input and output. 
    I have attached the code and images for xilinx block memory generator IP configuration settings. Kindly have a look at my code and tell me what is it that i am doing wrong? what are the considerations for pipelining the design? cause i have tried placing registers after every stage in my code but this reduces the clock rate to even below 291.25MHz.
    Thanks
    Attachments:
    Projec_Memory Block.zip ‏309 KB
    Block Memory Generator_GUI.zip ‏236 KB

    Have you taken a look around the forums?
    http://forums.ni.com/t5/LabVIEW/Compile-Error-in-FlexRIO-FPGA-when-using-derived-clock/td-p/1617226
    What is the exact timing violation error you receive?  Depending on how your feedback nodes are used it can slow down the clock rate from the desired clock rate.  This is what I normally use as a reference for making my code operate more quickly:
    http://zone.ni.com/reference/en-XX/help/371599G-01/lvfpgaconcepts/registers/#Register_Timing
    http://zone.ni.com/reference/en-XX/help/371599G-01/lvfpga/fpga_timed_loop/
    http://zone.ni.com/reference/en-XX/help/371599G-01/lvfpgaconcepts/fpga_pipelining/

  • Fpga:timin​g violation

    Hola,
    Dispongo de un cRIO 9074, con una FPGA spartan-3 2M. He diseñado una VI para generar una chirp desde la FPGA. La primera compilación no me generó error alguno, sin embargo, después he añadido la función de interrupción (adjunto VI), y por lo tanto un "sequence", y me ha dado error temporal (adjunto imagen con el error). Es extraño, porque la ocupación de la FPGA es baja (adjunto imagen con el resumen). No comprendo las ventanas donde se informa de los errores.
    1.- Qué significa Non-diagram component? A qué ahace referencia?
    2.- En base a qué se calculan los valores que aparecen en Cloks Maximun (Mhz)?
    Se que para mejorar los tiempos hay que hacer pipeline, pero me gustaría comprender el origen de estos errores. He buscado información pero no doy con ella,
    Gracias,
    Attachments:
    error con irq.jpg ‏149 KB
    ocupacion.jpg ‏53 KB
    chirp_FPGA.vi ‏48 KB

    Hola aino!
    Antes de nada, para conseguir que tu VI compile, te paso un link:
    http://digital.ni.com/public.nsf/allkb/EE940C191DD​CE9CE86256E5500783A4D?OpenDocument
    Después, lo primero que resalta de tu VI son los puntos de coerción (puntos rojos pequeños a la entrada). Para evitarlos, podrías poner todos los controles con la misma representación.
    Para entender mejor lo que preguntas, hay un artículo en la ayuda de LV que te puede ayudar mejor que yo. El artículo se llama Timing Violation Analysis Window (de hecho hay un link a otro artículo que se llama Fixing Timing Violations que te puede ser de ayuda).
    Ese parámetro del Clock Maximum se calcula con el la frecuencia de reloj mínima que necesita un determinado componente y la frecuencia máxima que tu placa le puede dar.
    Espero haberte sido de aydua, un saludo!!
    Applications Engineer - Certified LabVIEW Developer & Certified TestStand Developer

  • Timing Error by non diagram component

    Hi All,
    I am facing an issue while compiling my FPGA VI for rotational test durability of a shaft.
    Error is given below
    Compilation failed due to timing violations.
    Click the Investigate Timing Violation button to display the Timing Violation Analysis window.
    & when i opened timing violation analysis window it is given as attachment.
    Now in this window show element & show path button are not active.
    How can i know error is due to which block of my coding?
    I am attching my coding also.
    Kindly help?
    Regards,
    Vipin Ahuja
    Attachments:
    Error window.png ‏151 KB
    rotationalfp10.vi ‏293 KB

    hey thu^^,
    I tried this with LabVIEW2013, FPGA module, NI5640R v1.7 drivers, and successfully compiled the example template. I'm attatching my screenshots. Please let me know if there is any difference between my experiment and yours.
    Attachments:
    XilinxOptions.png ‏15 KB
    compilationSummary.png ‏23 KB
    finalTiming.png ‏24 KB

  • How do i know if my fpga vi timing before i compile

    Hi,
    Is there way to know that my FPGA VI is not going to give me a timing violation before i compile the code?

    Hi,
    There actually are some little-known problems that you can try to avoid that will prevent timing violations.
    1. If you are using the old fixed-point (FXP) math VI's within a single-cycle timed loop (SCTL), you have options when double-clicking the VI's to pipeline the data through multiple iterations of the FPGA clock. If you don't set the right setting, you'll get a timing violation.
    2. In general, if you use FXP data in a SCTL, a good idea would be to make sure that it is 32-bit or less. Otherwise, timing errors.
    3. Keep your code efficient and pipeline data.
    Hope this helps,
    Dan Richards
    Certified LabVIEW Developer

  • Top level clock timing error 0.00 ns

    I am working with Ni 9146 chassis in FPGA.  When the top-level clock was set to default (40 MHz) and the VI was compiled with Xilinx a timing error comes back which states the the time that the code took would be ~0.05 ns, but the expected time was 0.00ns.  Since it was 40 MHz the time required should have been 25ns.  I had the work around that I created a derived clock of 40 MHz, and this makes the compiler think the code needs to run in less than 25ns.  
    I do need to know why the default clock does not work though.  
    Thank you for your time
    Mitchell

    I have received similar errors in a few of my projects, typically in the past I have simply changed the "Implementation Strategy" from "default" to "reduced compile time". Although I just received the same error 3 times consecutively now and I'm not sure why. I have the exact same VI implemented on another FPGA of the same type which compiles without problem.
    I have received two 50pS timing violations and one 980pS timing violation.
    Attached are the screen shots of the two most recent errors. Any insight as to the cause?
    I just changed the "Implementation Strategy" to "optimize performance" hopefully this rectifies the issue.
    Attachments:
    5pS.jpg ‏201 KB
    98pS.jpg ‏224 KB

  • Issue in Post Route Simulation related with critical path

    I am using ISE14.4. I got critical path value 1.704 ns for my system. In post route simulation I gave clock period 1.705 ns, It should work as clock period is greater than critical path but in post route simulation I am getting this warning in ISIM
    at 104057 ps, Instance /test/uut/count_0/ : Warning: /X_FF HOLD Low VIOLATION ON I WITH RESPECT TO CLK; Expected := 0.19 ns; Observed := 0.174 ns; At : 104.002 ns.
     I checked my system is working without this warning at 2.37 ns clock period. Any time period less than this value gives "XX" output.
    Is my understanding is right?  

    Is this an internal path ie from a register to register within the uut or is it from testbench to uut. If latter, make sure you are giving the data correctly. If former, this shows that xilinx timing results are not accurate which is unlikely.
    Also your 1.705 is a setup timing result but the timing violation is a hold violation. Hold violations don't get resolved by increasing the clock period. So this path is probably a external path (which may include synchronization). Take a timing report of this specific path and post here.

  • Some questions about FIFO implementation

    Hi, I'm working on a project to control an industrial manipulator using Labview. At this stage, I'm able to transmit linear and angular velocities from the compactRIO through the LAN to the actual robot, which processes the data and then moves accordingly. The data is transmitted as a char string. I'm looking to implement a FIFO so that the processes of reading user input and sending can run in parallel.
    What is the difference between adding a new FIFO from target and using the available FIFO vis in the functions palette? Also any tips or mistakes people commonly make when using this approach?
    Just to be clear, my current solution works well enough, but I need it a bit faster. Also english is not my first language so please excuse any mistake I made.
    Thanks a lot, any help is really appreciated

    Hey Jcarellanov,
    There are only a few differences between implementing a FIFO either through the target instantiation in the library and instantiating them explicitly on the block diagram. 
    Difficulty of Implementation - As you have seen, to implement the FIFO explicitly on the block diagram you have to manage the connection in your code. This will result in a much messier looking block diagram and will force you to code in such a way to allow appropriate access to the stored information. There also comes in some complexity when you try to refer to the FIFOs from different targets.
    Efficiency - When creating the FIFO via the Project Library, it gives you a simpler implementation but as you are delegating the task of maintaining the FIFO to LabVIEW, it results in the use of more FPGA gates and Look Up Tables (LUTs) than if you were to create the FIFO explicitly. LabVIEW will produce a FIFO structure which is suitable for all scenarios (How the FIFO data will be shared), but if you instantiate the FIFO explicitly you will only make use of the scenarios which apply to your code, therefore you will avoid using up FPGA space unnecessarily. 
    In terms of any tips I have for using the FIFO, I'd recommend for most projects that the use of the Project Library based implementation should be perfectly fine. It's really helpful to have LabVIEW do a lot of the hard work for you at the expense of some extra gates; although if space is a constraint, it may be better to define it in your block diagram. I'd suggest only using as few FIFOs on your block diagram as you can because it's easy to get lost in a mess of wire; you can try concatenating data and using a For Loop to write all of the data to a FIFO of a particular kind, for shared information, which is great for using one FIFO for data of a particular type.
    If you're finding that your FIFO is slow, try increasing the number of elements to read and write in your FIFO; but this will still only be limited to the rate at which you're acquiring data. For some modules can try and increasing the data rate through a property node of an I/O node in order to increase the amount of samples acquired. You can use a DCM (Clock multiplier) to drive some operations faster, but you must be wary that you don't incur any timing violations in your code (This is when your code ends up driving the clock source of the FPGA to such a speed that the configured circuitry can't keep up) and you can try to make use of Single Cycled Time Loops (SCTLs) to increase the clocking speed of certain sections of your code phenominally. You can find a good explanation of SCTLs here. There are also great examples in the NI Example Finder (LabVIEW > Help > Find Examples...) for different interesting FPGA configurations.
    Also your English is great! I hope this helps.
    Regards,
    Alex Thomas, University of Manchester School of EEE LabVIEW Ambassador (CLAD)

  • FIFO across clock domains

    I'm using a FlexRIO 7966R for digital signal manipulation and need to buffer data across clock domains. By buffer I mean I need to be able to store in memory a variable amount of data before it's read back out in order to achieve a data delay. I can successfully write to the FIFO in one clock domain and read data from the FIFO in another clock domain, but as soon as I introduce the "Get Number of Elements to Read" function the compilation fails with a timing violation. It appears that this method cannot execute quickly enough:
    I tried moving the "Get Number of Elements to Read" function into another slower clock domain SCTL but the compiler then states that it has to be in the same clock domain as the Read FIFO function, so that doesn't help.
    Any thoughts anyone?
    Thoric (CLA, CLED, CTD and LabVIEW Champion)

    Intaris wrote:
    Correct, BRAM does not cross clock domains. This is why i proposed splitting the work into two parts, domain crossing and delay.
    Using the BRAM on the receivinG side only you can implement a circular buffer of size x with write index incremented each cycle and the read position is relative to this.  By changing the offset between write and read (all on the receiver side) you can implement any delay up to x.  Your receiver order would be read FIFO (in every cycle), write to BRAM, read from BRAM and continue.
    That way your FIFO for crossing domains can be much smaller, saving LUTs and registers.
    Regarding recucing the delay: If your sender is sending data as fast as your receiver can read them, reducing the delay sounds like it is always going to be lossy.  You can do this with the BRAM by adjusting the offset between write and read accordingly, effectively skipping data.
    Im in the mountains on holiday so i cant post code for another week.....
    Other topic.... I though the max clock on a 7966 was 326 MHz? I know on a 7965 its listed as 326 MHz.
    Thanks for the insight Intaris.
    My FIFOs are set to use BRAM, so will your proposal of creating a small FIFO for crossing the clock domains plus a separate BRAM block for buffering achieve much saving in fabric? Isn't that the same amount of BRAM, plus a bit for your FIFO? I might go ahead and create a test implementation to see the difference in FPGA resource usage...
    I'm using a 5782 Module with independent 500MHz clock.
    Thoric (CLA, CLED, CTD and LabVIEW Champion)

  • Best way to implement confirm button in conjunction with menu ring selections

    So basically I have a series of menu rings that implement different cases of a structure that adjusts PWMs and other timing signals.  I have received a request to add in a confirmation button/dialog that pops up to make sure the operator wants to perform the selected operation.  I'm doing this on a PXI 7831R FPGA board and have run into timing violations in the past, so the less timing critical, the better.  If there is some way to offload this onto the host VI, even better.  Thanks in advance for the help.

    If there is some way to offload this onto the host VI, even better.
    Considering the FPGA does not support dialogue boxes or event structures, you will have to implement this into a host VI.
    My suggestion? Have a case structure with a latch boolean control on it (ie. update config). Your host VI will have an Open FPGA VI reference and run the FPGA this way. When you want to update the config, you can change your items, then hit 'update'. Include the dialogue box for confirmation if you wish. When this is done, it will use a read/write control to update the boolean 'update config' on the FPGA. Your FPGA VI will then read that case structure with the config data in it once(since it is a latched boolean) and then continue on its merry way.
    Rob K
    Measurements Mechanical Engineer (C-Series, USB X-Series)
    National Instruments
    CompactRIO Developers Guide
    CompactRIO Out of the Box Video

Maybe you are looking for