Open hansfbaier opened 2 years ago
Have a look and see if Vivado has set-faulted or run out of memory on a previous target. If you have a lot of parallel jobs this could be some way back in the terminal. Moreover, invalid coordinates in the environment will cause this, for example RAMB32 coordinates are half the corresponding RAMB16 from the layout view.
Yes, I did.. I disabled it, since I hadn't been sure how to resolve it, cf.
Looks like I should review my settings.sh ...
OK, I think I got to the bottom of why it isn't working (perhaps you already noticed something like this). If we examine a working I/O, such as LED[0] which is assigned to LIOB33_X0Y127, we find the following in tilegrid.json:
"LIOB33_X0Y127": {
"bits": {
"CLB_IO_CLK": {
"baseaddr": "0x00400000",
"frames": 42,
"offset": 55,
"words": 4
}
},
"clock_region": "X0Y2",
"grid_x": 0,
"grid_y": 231,
"pin_functions": {
"IOB_X0Y127": "IO_L11N_T1_SRCC_14",
"IOB_X0Y128": "IO_L11P_T1_SRCC_14"
},
"prohibited_sites": [],
"sites": {
"IOB_X0Y127": "IOB33S",
"IOB_X0Y128": "IOB33M"
},
"type": "LIOB33"
},
all well and good, but if we look at a bad site, such as the 200MHz differential clock input (assigned to RIOB18_X95Y75), we see this:
"RIOB18_X95Y75": {
"bits": {},
"clock_region": "X1Y1",
"grid_x": 236,
"grid_y": 285,
"pin_functions": {
"IOB_X1Y75": "IO_L12N_T1_MRCC_33",
"IOB_X1Y76": "IO_L12P_T1_MRCC_33"
},
"prohibited_sites": [],
"sites": {
"IOB_X1Y75": "IOB18S",
"IOB_X1Y76": "IOB18M"
},
"type": "RIOB18"
},
The bits section is empty, meaning that there is no logic turned on the bitstream corresponding to this selection in the fasm. So we just need to find the fuzzer that elaborates this setting and fix it (or patch it manually for now). QED
It looks like LIOB33 sites are dumped out in the 030-iob fuzzer but RIO18 is not mentioned.
I modified the .tcl for 030-iob fuzzer and will leave it running overnight to see if it fixes the problem.
` python3 process_rdb.py build/segbits_xiob33.rdb > build/segbits_xiob33_processed.rdb python3 /home/jonathan/prjxray/utils/dbfixup.py --db-root build --zero-db bits.dbf --groups tag_groups.txt --seg-fn-in build/segbits_xiob33_processed.rdb --seg-fn-out build/segbits_xiob33.db CLB INT mode: False Segbit groups: 0 Traceback (most recent call last): File "/home/jonathan/prjxray/utils/dbfixup.py", line 153, in add_tag_bits assert len(self.tag_to_groups[tag]) == 1 AssertionError
The error by itself doesn't ring a bell for me. Which section does this issue pop up in? Could this be related to the number of clock regions > 1?
This is in fuzzer/030-iob when extra cases are added to the python to detect IOB18 cases. I probably got it wrong, feel free to investigate
The existing script seems to BARF when an invalid combination of I/O types is put on a differential capable I/O. These constraints need tightening up, we do not need to cover every possible case at this stage. See fuzzer/030-iob/top.py
This is in fuzzer/030-iob when extra cases are added to the python to detect IOB18 cases. I probably got it wrong, feel free to investigate
Do you refer to https://github.com/kintex-chatter/prjxray/blob/k325/fuzzers/030-iob/top.py#L37? Can you push your branch to make things more clear, please?
Please refer to this branch k325-iob18, where I have created a new fuzzer. This is just for review, it does not actually work.
I'm haven't verified that the prjxray fork that we have works before my modifications, so I need to run that first before trying to modify it.
Hi @jrrk2 and @unbtorsten, did you encounter this error while fuzzing that the mentioned fuzzer generates empty verilog files, because it cannot find
prjxray/database/kintex7/xc7k160t/tilegrid.json
?