New Contributor
New Contributorlets try to see if we can get some data coming and going on the reconfig_to/from_pll buses. For this, could you disable mgmt_byteenable? from the Reconfig IP GUI uncheck the add byteenable port
New ContributorWell I have some good news I hope. In parallel I was trying to create a simulation environment for the platform, since to date I had been using the Cyclone III simulation setup. This complete design was based on a fully functional Cyclone III design, and then ported to CycloneV. Part of the port was updating all PLLs and Reconfig IPs to CycloneV primitives. I could not get the tool to support simulating even the simplest of PLL primitives. In working with the FAE and support, it was discovered (and reproduced), that the Build 922 version of 22.1Std2 S/W has issues in creating the PLL simulation primitives. I was told to restart my efforts using version 917. I have just loaded the design and will verify my simulation capability here shortly. I am not sure if it is plausible that the 922 version has an issue in building a valid object file to support on H/W usage of the PLL and Reconfig modules. I am hoping that theory is plausible, since again following the appnote and instantiating the two IP modules is fairly straight forward and my timing matches the example identically. Let me know if you believe this makes sense, and I will keep you poste on the status here shortly. Thanks.
New ContributorInteresting, I am going to ask around to see if I can confirm that hypothesis, but seems to be right as even without the byteenable and asserting the reset of the reconfig ip, we should be seeing changes in the reconfig_to_pll bus. I created a simple design and tested a couple of things to see if I was able to replicate the issue and I saw that there is always some data going to the pll. But mine was started from scratch usign 22.1std.0 build 915
