04-17-2014 02:09 AM
I'm using Planahead 14.6 on Windows 7 x64. My system has 16GB RAM. I'm developing for a Kintex-7 XC7K325_G676.
Recently I partitioned my working design using the xilinx PDF 'Design Preservation Tutorial (UG747 14.1)'. I did the following:
The problem is I get the EXCEPTION_ACCESS_VIOLATION when trying to open the implemented design. Every time since implementing partitions. I've seen other threads about this and even the Answer record, but they commonly have this error associated with ISim.
I've changed Planahead settings to single core from Multicore with no joy.
Anyone got any ideas? Could it be that my partitioned module has a black box netlist inside it (PCS/PMA core), or the eval core being wrapped in a partition?
The pid#.dmp file is unreadable in Notepad++ so I'm not sure what format it's meant to be in.
04-17-2014 02:14 AM
04-17-2014 02:21 AM
Please try below parameter it might help.
1) Once you have set up the PR modules for the different blocks and the synthesized design is opened.
2) Could you closed the synthesis design before running Implementation and set up back the
“set_param funnel.forceHierarchy YES” and run the Implementation? This would enable again the parameter once the problem opening the netlist has been resolved.
04-17-2014 03:27 AM
thanks for the quick response.
I had come across that Answer record mentioned, but nothing applies to my situation. SAIF files don't come into it as this isn't related to simulation. I'm not using verilog (IP probably is but it's beyond my control). I don't have the software on my system mentioned in the AR.
Yashp: I synthesised my design, opened it, then closed it. I then ran the command you gave in the tcl console, which returned '1'. Then I ran implementation. Still the same problem though, I go to open the implemented design and it bombs out leaving an EXCEPTION_ACCESS_VIOLATION in the console. :-(
04-17-2014 05:20 AM
I suspect I may need to be more clinical in my approach to defining the boundary on my partitioned module with respect to constant drivers and unused ports. Will develop a wrapper and see how that goes..
04-17-2014 06:57 AM
One other suggestion would be to run this flow outside of PlanAhead. Refer to the Hierarchical Design Methodology Guide for more information, but you can manage the PXML file and the promoted implementation runs yourself. If the issue is related to PlanAhead, this may resolve it for you.
04-17-2014 07:03 AM
Do you mean via script/ command line?
The design seems to build all the way to bitstream, but opening the design is where the violation occurs. If I was to implement outside of Planahead would that just be the same as just never opening the implemented design in Planahead?
Or do you mean building the blocks seperatly and importing the netlists into the main project?
04-17-2014 07:17 AM
I meant ISE command line (ngdbuild, map, par), not planAhead commands (like launch_runs).
You could use PlanAhead for analysis purposes still by loading the NCD, but all implementations would be ISE command line.
If you can implement the initial implementation and the implementation with imported partition in PlanAhead, then maybe you don't need/want to switch flows. I thought you were only able to implement the inital implementation, but not any additional implemenations when the partitions are imported.
04-22-2014 12:42 AM
Yea I'm able to generate a working bit file that I can run in hardware.
I created a wrapper for the partitioned block in my design that takes care of unused ports across boundaries and constant drivers, and have a working design in hardware. I figured I could just leave the implemented design closed and work as normal but when I ran TRCE it bombed out with the same EXCEPTION_ACCESS_VIOLATION so I guess any tool that needs to work on the implemented design in memory is going to trigger this error.
Shifting my design practice from the Planahead GUI to ISE command line flow is quite a change that I'd rather not make. Is there any way Xilinx could let me know how I can look at the stack trace/ memory .dmp files Planahead spits out?
04-30-2014 08:36 AM
So, the user bitwiselannon has just left the company he was working at. I work at that company and am taking over his project for the foreseeable future. As such, I am now having exactly the same problem he was having!
Please bear in mind I am much less experience than him so finding a way around the issue is going to prove more tricky for me. Like him, I can build all the way to a bitstream but any time I click open implemented design it crashes. The error log provides no useful information and the dmp file is unreadable.
For the time being, we think the best way forward would be to try and remove the partition that was set up. I see the way to do this is in planahead is via the RTL view. However, opening the elaborated design also results in the same crash and error (EXCEPTION_ACCESS_VIOLATION). I have tried editing the .pxml file manually to remove details of the partition but it just regenerates as it is located in the run directory.
Can anyone help me do this?
04-30-2014 09:35 AM
You don't want to remove the partition. Just try taking the NCD from the <project>.runs/imp_1/ directory and load it into a new PlanAhead. Create a New Project and select the radio button "Import ISE Place & Route results" when selecting the project type. Follow the new project wizard to load in the EDIF and NCD from the impl_1 directory.
Hopefully this will allow you to load the NCD and do interactive timing analysis, etc.
05-07-2014 06:31 AM
Thanks for your reply. Since I posed I actually managed to rebuild the project from scratch, using all the same sources, but without partitions (we'd still like to proceed without partitioning...). I am able to generate all the way to bitstream, and open implement design, but planahead still crashes when I try to open the RTL eleaborated design.
I am going to continue for now as I don't need to fix this problem immediately. There is some timing closure to do which is why we wanted to clear the partitions and start from an unconstrained floorplan. We would obviously like to know what is causing it though so please feel free to suggest possible solutions/approaches.The annoying thing is this hasn't always been a problem. The very fact that my predecessor had managed to enable the partition at some point must mean he was able to open the elaborated design.
Is there anything I need to look for in the source files that could have caused this reaction? Is it a consequency of adding certain IP cores to the design maybe?
05-08-2014 03:44 AM
This is just to say that I have discovered the cause of the problem. The crash was due to a syntax error in one of the 50 or so source files associated with the project.
The offending line of code is as follows:
attribute ASYNC_REG of chain_begin: signal is "TRUE";
The error is that chain_begin is of class alias rather than signal.
Changing the line of code to the following fixes the issue.
attribute ASYNC_REG of chain_begin: alias is "TRUE";
I am now a able to open the elaborated design with no issues.
Whilst this is a syntax error on our part, I can't help but think that the Planahead software should have been able to detect this and provide an appropriate error message, even just identifying the source file would have been enough to find the problem.
Thanks for your help.
05-08-2014 06:57 AM
actually, slight error on my part. The new line actually gives a syntax error during synthesis.
Just to recap, the original full code segment was as follows:
signal reg_chain: std_logic_vector(CHAIN_LENGTH-1 downto 0) := (others => RST_VALUE);
alias chain_begin: std_logic is reg_chain(0);
alias chain_end: std_logic is reg_chain(reg_chain'high);
signal chain_end_reg: std_logic := RST_VALUE;
attribute ASYNC_REG: string;
attribute ASYNC_REG of chain_begin: signal is "TRUE";
This did not generate a syntax error and I could go all the way to bitstream with no problems. The issue was that planahead would crash when trying to open elaborated design.
It would seem the issue is when assigning an attribute to a single element (reg_chain(0)) of the arrange reg_chain. For some reason the tool that opens the elaborated design does not like it. I think the code should be valid and maybe this is a bug. However, I would welcome another viewpoint.
05-08-2014 08:07 AM - edited 05-08-2014 08:09 AM
You can remove the attribute declaration. It mainly informs the timing tools about the nature of the signal. Paths leading into that module should be ignored using timing constraints (if being used as a synchronizer chain from another domain/ asynchronous signal).
I had an issue with alias signals in Planahead a while back, and there is even a test project I created where the Xilinx tools were getting bit order of alias signals wrong for no reason. I held back using alias signals for about a year, and assumed the issue had been sorted. Could be related to that..
10-28-2015 02:40 AM
Try the following command after opening synthesized design.
set_param funnel.forceHierarchy FALSE
We have seen in many scenarios this switch helps.
Thanks and Regards,