Cyclone 10 GX Dev Board - Bad Hash and Usercode

[RayHaynes1]

I have the Cyclone 10 gx development kit and running Quartus 22.4 (the version the collateral files were created with). When I run the Board Test System software everything is good. I can modify the upper verilog file (reassign LEDs for example) and everything still works. But if I make any changes to the qsys files, specifically the transceiver block, the BTS complains the hash and usercodes don't match expected values. I found where the usercode was being created by a checksum so forced it to the correct value but BTS still complains about the hash. Is there any way around this? Are we not expected to make changes to the qsys subsystems? I'm hoping for a switch to disable this check and put the owness on me to ensure any design changes are compatible with BTS.  Any suggestions? 

[sstrell]

I don't use BTS very often, but if you are taking an example design used by the BTS and editing it, you have to recompile it.  You can then use the BTS or the Quartus Programmer to program the device with the updated design (the .sof file), but it will no longer be a "BTS-compatible" design.  Is this what you mean?

[RayHaynes1]

I think so. I was hoping to use the BTS-GUI to modify parameters of my core serdes design. But even changing the bit rate makes BTS report it as incompatible. Seems like that makes the development part of the development board pretty useless.

[sstrell]

I'm of the opinion that BTS is really meant as a starting point for development and an introduction to the kit.  You really have to move over to development in Quartus at some point.  Many people try to rely on BTS but I don't think it's meant for regular development.

Since you're able to use Quartus Pro with the C10GX, you can use the new board-aware flow in Quartus and Platform Designer so your I/O (locations, I/O standards, etc.) gets set up for this board when you create a new project and there are IP presets specific for the board as well.

[RayHaynes1]

Despite the Novice tag, I've been doing FPGA design for many decades. Long before a PCB comes into my possession it's nice to be testing some initial blocks on actual hardware. Using BTS would have allowed me to begin that testing my serdes core without having our Nios design with software all written and tested. The BTS has the hooks to already to BER testing and between BTS and Platform Designer any necessary tweaks could have been done. Now what I thought was a quick (couple of days) verification of my serdes core now has to wait for the Nios design to be up and running (an area handled by different folks).

Personally I think the checksum via the usercode should have been all the checking done. If you modify that then it's on the designer after that. I was really hoping someone had run across this and had discovered a quick hack to bypass the hash check.