Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change main fuzzed device to A100T #1382

Closed
rw1nkler opened this issue Jun 30, 2020 · 3 comments · Fixed by #1381
Closed

Change main fuzzed device to A100T #1382

rw1nkler opened this issue Jun 30, 2020 · 3 comments · Fixed by #1381

Comments

@rw1nkler
Copy link
Contributor

To provide support for A200T, we need to change the main device for fuzzing from A50T to A100T or A200T. This change will allow obtaining new bits that are related to the features that are absent in A50T.

Related issue:
f4pga/f4pga-arch-defs#1494

The diff generated from changes in #1381:
diff.log

@rw1nkler
Copy link
Contributor Author

rw1nkler commented Jul 7, 2020

Database diff

After generating a new database based on A100T, the following fasm features disappeared:

-CMT_TOP_L_UPPER_T.PLLE2.COMP.ZHOLD_NO_CLKIN_BUF_TOP 28_06
-CMT_TOP_L_UPPER_T.PLLE2.COMPENSATION.ZHOLD_NO_CLKIN_BUF_NO_TOP 29_06
-CMT_TOP_R_UPPER_T.PLLE2.COMP.ZHOLD_NO_CLKIN_BUF_TOP 28_06
-CMT_TOP_R_UPPER_T.PLLE2.COMPENSATION.ZHOLD_NO_CLKIN_BUF_NO_TOP 29_06

and one bit was removed from fasm features:

-INT_R.IMUX43.LOGIC_OUTS23 origin:051-pip-imuxlout-bypalts !22_30 !23_30 !25_30 20_00 21_30 24_30
+INT_R.IMUX43.LOGIC_OUTS23 origin:051-pip-imuxlout-bypalts !22_30 !23_30 !25_30 21_30 24_30

CMT_TOP_L_UPPER_T bits

Both CMT_TOP_L_UPPER_T.PLLE2.COMP.ZHOLD_NO_CLKIN_BUF_TOP and CMT_TOP_L_UPPER_T.PLLE2.COMPENSATION.ZHOLD_NO_CLKIN_BUF_NO_TOP are missing in the newly created database. They are produced by fuzzer 032.

However, the mentioned bits are present in the .rdb fuzzer file:

CMT_UPPER_T.PLLE2.COMP.ZHOLD_NO_CLKIN_BUF_TOP <0 candidates>
CMT_UPPER_T.PLLE2.COMPENSATION.ZHOLD_NO_CLKIN_BUF_NO_TOP <0 candidates>

The features have only two positive representatives in the generated specimens.
The small amount of representatives might be related to restrictions provided in generate.py file:

 98     segmk.add_site_tag(
 99             site, 'COMPENSATION.ZHOLD_NO_CLKIN_BUF_NO_TOP', match and \
100                     not bufg_on_clkin and \
101                     site != "PLLE2_ADV_X0Y2" 
102                     )
103     segmk.add_site_tag(
104             site, 'COMP.ZHOLD_NO_CLKIN_BUF_TOP', match and \
105                     not bufg_on_clkin and \
106                    site == "PLLE2_ADV_X0Y2"
107                     )

Possible solutions:

  • generate more specimens
  • ?provide additional sites in the restriction above?

@litghost Do you know why the CMT_TOP_*_UPPER_T bits disappeared or how should I change the fuzzer to fix this issue?

@rw1nkler
Copy link
Contributor Author

rw1nkler commented Jul 9, 2020

  • The changes introduced in d909857 fix the issue with missing CMT_UPPER_T bits (PR Change main fuzzed device to A100T #1381).

  • I was also trying to check why the 20_00 bit is removed from the INT_R.IMUX43.LOGIC_OUTS23 fasm feature. I increased the number of specimens generated by the fuzzer 051 from 20 to 50. However, the 20_00 bit is still absent in the generated segbits file. I figured out that the 20_00 bit is not present in any other feature in the generated file, whereas other bits from the INT_R.IMUX43.LOGIC_OUTS23 are used in many places. Maybe the feature should not contain that bit.
    Currently, we are not using the mentioned fasm feature. I checked all the fasms generated by the make all_xc7 target.

  • Changing the main part for fuzzing causes a small difference in the DSP timing files. The difference is related to changing the ?port name? in DSP SDF file from A to D:

         (INSTANCE DSP48E1)
         (DELAY
             (ABSOLUTE
-                (IOPATH A CARRYCASCOUT (0.596::2.268)(1.345::5.400))
-                (IOPATH A CARRYOUT (0.580::2.133)(1.334::5.046))
-                (IOPATH A MULTSIGNOUT (0.592::2.140)(1.323::5.029))
-                (IOPATH A P (0.587::2.142)(1.346::5.070))
-                (IOPATH A PATTERNBDETECT (0.628::2.339)(1.430::5.636))
-                (IOPATH A PATTERNDETECT (0.628::2.339)(1.430::5.636))
-                (IOPATH A PCOUT (0.580::2.133)(1.334::5.046))
+                (IOPATH D CARRYCASCOUT (0.596::2.268)(1.345::5.400))
+                (IOPATH D CARRYOUT (0.580::2.133)(1.334::5.046))
+                (IOPATH D MULTSIGNOUT (0.592::2.140)(1.323::5.029))
+                (IOPATH D P (0.587::2.142)(1.346::5.070))
+                (IOPATH D PATTERNBDETECT (0.628::2.339)(1.430::5.636))
+                (IOPATH D PATTERNDETECT (0.628::2.339)(1.430::5.636))
+                (IOPATH D PCOUT (0.580::2.133)(1.334::5.046))
             )
         )
     )
     (CELL
         (CELLTYPE "DSP48E1_ADREG_0_DREG_0_MREG_1_USE_DPORT_TRUE_USE_MULT_MULTIPLY")
         (INSTANCE DSP48E1)
         (TIMINGCHECK
-            (HOLD A (posedge CLK) (-3.158::-0.249))
-            (SETUP A (posedge CLK) (0.249::3.158))
+            (HOLD D (posedge CLK) (-3.158::-0.249))
+            (SETUP D (posedge CLK) (0.249::3.158))
         )
     )

The whole diff can be found here: DIFF HTML.

@litghost: Do you know if these changes related to INT_R.IMUX43.LOGIC_OUTS23 and the generated DSP timings are valid or how to check their correctness?

@litghost
Copy link
Contributor

litghost commented Jul 9, 2020

@litghost: Do you know if these changes related to INT_R.IMUX43.LOGIC_OUTS23 and the generated DSP timings are valid or how to check their correctness?

Your link does work, just link to the PR or GCS status page.

I'm guess that the change to INT_R.IMUX43.LOGIC_OUTS23 is a valid change, but it's hard to say. Typically bit removal is a good thing, and bit additions are instabilities.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants