10-11-2018 12:43 AM
My design is based on a delayed row using the Carry4 primitive, where each execution is connected to a trigger D to sample the value of the delay line.(TDC design image) I am delaying the system clock, sampling the values on the delay chain each time a hit signal arrives (a thermometer code is stored in FF).The output from FF is passed to a decoder, which converts the thermometer code into binary code.Then, I can calculate the hit signal arrival time by multiplying the binary value of the carry primitive's delay value.
Because I call a lot of carry4 directly, and then I connect the f-f directly behind their respective, and then I process the output of FF.But now get the output, there will be a lot of noise, want, for example, 0000000011111111111 high (low continuous 1, 0), the code, but the actual is like 000000011010111111111100000 of the code, I think there are three reasons:
1: is it the reason that carry4 builds advanced carry, resulting in some output, which is output ahead of time, resulting in the occurrence of 00000000111000111100000...
2: it is not because of the wire delay between the device connections, because the wire length is different when the devices are connected, which leads to some output that goes through a long delay.
3: on the basis of the second reason, do you need to make some restrictions to put carry4 and FF attached after it in the closest place, so that you can guarantee that there will be an orderly output.The point is, I don't know what to do with these restrictions yet, and I'd like to ask the teachers to help me try out a solution.
10-11-2018 03:01 PM - edited 10-11-2018 03:13 PM
First of all, open implemented design (in Vivado) and see how your design is implemented. Check if your flip-flops are connected directly to carry4 in Slice (not by extra nets out of Slice). Make sure that your "Signal" is distributed by clock network (that ensures low-skew signal). If your carry chain is longer than 200 elements (4 carry mux multiplied by 50 slices) then you cross clock regions and might have problems with "signal" distribution (different skew to different clock regions).
From my practical experiance: initiating carry4 primitive ensures at least proper carry chain implementation (i.e. subsequent elements are implemented in a chain). And if I good remember flip-flops are automatically implemented in a proper way (next to carry4, in the same slices). The only thing that I did was to ensure that my TDC is implemented in a single clock region (it is also possible, at least in series-7, to find two adjacent clock regions with similar clock signal skew).
There is a lot of information about TDC implementation in FPGA in scientific journals. Just have a look at IEEE publication base. You may also find this project interesting: https://www.ohwr.org/projects/tdc-core/wiki
By the way, I dont see a reason way you clock your code converter - it can be implemented as a combinational circuit.
10-11-2018 07:36 PM
10-12-2018 07:00 PM - edited 10-12-2018 10:40 PM
During MMCM configuration you can choose how the output signal will be distibuted and normally it is through global glock buffer (BUFG). If you did not change it then it is ok.
And about clock regions - please have a look on that picture. The yellow and purple lines indicate the signal that can be distributed by the same BUFG to neighboring clock regions (X0Y2, X0Y3). As you can see both signals' paths are a bit different but in this particular case have more or less the same skew. In other cases you will see that the skew may differ even more than 100 ps. In terms of TDC implementations you will either see in the result so called ultra wide bins (much wider bin size than usuall) or loss transfer characteristic monotonicity (raw output code in a form of e.g. 00000111111000001111111). While you can improve tranfer function linearity using e.g. flip-flops realigment, you have to be aware of the ultra wide bins.