I have received a verilog project, with a key component in it being encrypted.
The performance on a FPGA varies depending on build environment and configuration[Note 1] and I suspect this is caused by insufficient timing constraints [Note 2].
In the TimeQuest timing analyzer I can see the names of the pins, nets, registers, ports within the encrypted core, but without looking at the actual code I don't know exactly what they mean.
So how should I start writing a SDC timing constraint in this situation?
Note 1:
The component is a MIPI-CSI2 TX. On the test RX side I constantly get SoT error(SoT error and sync not achieved), and sometimes ECC errors.
For a while, to make it "work" on an FPGA the code has to built on a Windows Machine. Then a few minor and unrelated changes are made to the code, it could work if built on a Linux machine. Then very recently a Linux build machine seems to perform better than a Windows machine.
Also changing optimization parameters seems to break the code very badly. E.g. currently only "Balanced" mode works. "Performance" and "Aggressive Performance" modes, which should improve performance, causes a lot of errors in the received signals. Memory contents of a upstream signal processing block also affect the MIPI-CSI2 TX this way.
Above all make me think there are some uncertainties not fully constrained by the SDC timing constraints.
Note 2:
I'm not able to fully verify this theory because I don't have the equipment to fully test signal, nor could I do gate-level simulation because the encrypted code does not allow me to generate EDA netlist.
So in general, there are two types of constraints I am usually concerned with up front. One is the IO constraints which in the event of signals going off chip, you want to control the relationship between the data and the clock that is being used to transmit data and of course the receive clock and the receive data. The second type is the clock constraint. You want to validate that the clocks themselves are specified correctly. Depending on the tool, once you have done that, there is generally a process of deriving clocks that occurs to get any PLL derivative clocks... that part may be automatic, or if it is like Altera, you just need to call derive_clocks and you are on your way.
There are other kinds of constraints of course, but most of those are for specifying exceptions. "Make this a multi-cycle, or false path that.." etc.. Those are probably not what you want here. Constrain to the clock and that should be pretty tight.
If it is an input/output constraint issue, you can vary the relationship between the RX and TX clocks and associated data.
Beyond that, if this encrypted IP is provided by a vendor, they will usually provide any additional constraints that are required beyond just basic input clock constraint that you need.
One strategy, if you really think it is a clock variation issue, you can spec the input clock to be a little faster than it really is. This would technically cause timing to get tougher to meet, but you will gain margin in your final image.
Another thing to think about, depending on your technology you are building to, you need to correctly specify the device part number, because of the speed grade. You might have a slow part, and are compiling to a fast part. This will wreak havoc. Some vendors guard against loading the wrong image on the wrong part, but some will let you hang yourself.
Finally, check your I/O signaling standard and termination specs. If you think signal integrity is at play here, then these will have to be considered. Make sure if you are using LVDS or CML when you should be using HSSL or you might need to add pullups to the signaling pins...etc.