cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Adventurer
Adventurer
14,218 Views
Registered: ‎02-08-2013

EXCEPTION_ACCESS_VIOLATION

Hello all,

 

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:

 

  • opened elaborated design
  • selected hierarchical module I wanted to partition (a 10G fiber interface that has the PCS/PMA core and 10G MAC - eval version)
  • Created partitions
  • I Created a pBlock covering 3 CMT tiles alongside the tranceiver I'm using.
  • Design compiled, created bitstream - design worked.
  • Promoted the partitions.

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.

 

 

Thanks.

0 Kudos
15 Replies
Highlighted
Community Manager
Community Manager
14,216 Views
Registered: ‎07-23-2012

Refer to this http://www.xilinx.com/support/answers/30913.htm
-----------------------------------------------------------------------------------------------
Please mark the post as "Accept as solution" if the information provided answers your query/resolves your issue.

Give Kudos to a post which you think is helpful.
0 Kudos
Highlighted
Moderator
Moderator
14,213 Views
Registered: ‎01-16-2013

Hello,

 

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.

 

Thanks,

Yash 

0 Kudos
Highlighted
Adventurer
Adventurer
14,208 Views
Registered: ‎02-08-2013

Hi guys,

 

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. :-(

 

 

 

0 Kudos
Highlighted
Adventurer
Adventurer
14,200 Views
Registered: ‎02-08-2013

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..

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
14,194 Views
Registered: ‎04-16-2008

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.

0 Kudos
Highlighted
Adventurer
Adventurer
14,192 Views
Registered: ‎02-08-2013

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?

 

Cheers.

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
14,190 Views
Registered: ‎04-16-2008

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.

 

0 Kudos
Highlighted
Adventurer
Adventurer
14,170 Views
Registered: ‎02-08-2013

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?

0 Kudos
Highlighted
Scholar
Scholar
14,130 Views
Registered: ‎04-04-2014

Hi all,

 

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?

 

Thanks

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
11,210 Views
Registered: ‎04-16-2008

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.

 

0 Kudos
Highlighted
Scholar
Scholar
11,173 Views
Registered: ‎04-04-2014

Hi,

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?

 

 

0 Kudos
Highlighted
Scholar
Scholar
11,164 Views
Registered: ‎04-04-2014

Hi,

 

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.

 

 

0 Kudos
Highlighted
Scholar
Scholar
11,157 Views
Registered: ‎04-04-2014

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.

 

Thanks

 

0 Kudos
Highlighted
Adventurer
Adventurer
11,153 Views
Registered: ‎02-08-2013

Hi Coffee!

 

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..

 

 

BWL,

0 Kudos
Highlighted
Moderator
Moderator
8,401 Views
Registered: ‎07-01-2015

Hi All,

 

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,
Arpan

Thanks,
Arpan
----------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------------
0 Kudos