Hi Mark,
I'm sorry it took me longer time to investigate all details because I didn't seen Vybrid and Driver Suite for more than year and half, but I have found following:
1) Property "Number of data bits" is defined by the external DRAM module configuration (see the selected value also within a "Reconfigure..." dialog under DRAM Settings) and it is intended mostly for the tool internal calculations of DDR timing parameters. When it changes it means like the DRAM module configuration has changed and re-calculation of timing parameters is performed which may lead to some register modifications.
2) In general, DDR dynamic timing parameters are all calculated using equations defined within Init_DDR_VYBRID component internal scripts (CHG) which is not originally intended for end user modifications. In fact it's encoded and included in the common PEx components files package inside the "ProcessorExpert\" structure. However, the errors reported by the component complaining about JEDEC can be easily overcome in "Ignore Constraints and non-Critical Errors" mode of Component inspector for the actual active component. When enabled, all reported component errors will change to "Ignored error: ..." and the code generation or DDR validation tests can be started as without those errors. Please note that this mode is intended for advanced users, because the tool accepts potentially wrong configuration (even false positive) and it's up to the user's responsibility what actions he takes with such configuration.
3) Unfortunately, there's no direct way in Driver Suite v10.4.x how to export any peripheral register values easily from the tool UI. However, DDR Validation tool creates some log during the processing (e.g. when operational test is performed regardless of the result), so the tool generates some temporary script and log files which can be found in host OS file system under the Driver Suite eclipse workspace respective project folder location. Name of such temporary folder starts with ".Init_DDR_VYBRID_" following the current device variant. There're log and scripts sub-folders inside that temporary folder and if you go to the "log" you can see some file like "test_operational_tests_0_0_.log" (see attached example) which have logged all writes to the device registers as they're applied to run the operational test on device. You can simply get the real values for DDRMC modified registers according to address out of this log. Maybe one more comment yet, only the writable and really modified registers are mentioned in this log file. It does mean that the unmodified registers (the ones that have the same init.value as the after reset displayed in the Registers view UI) are not listed here. Anyway, content of that log file still need further processing on the end user side in order to get the register values in a form suitable for u-boot processing.
Hope this helps.
Regards,
Petr Z.
