03-12-2012 05:39 PM - edited 03-14-2012 08:43 AM
[Title updated as we figured out the verilog generation was the issue]
I've been trying to generate a pcore using AXI4 architecture and while the PLB version is working, the AXI is crashing in one of the perl script (see under). I used my own design, then for the test I grabbed the standard rgb2gray.plb example (joined).
I've tried to clear the cache with xlCache('clearall') without effect.
Has anyone encounter this bug?
Thanks for your help, cheers
My config is: Win XP 32bits, Matlab R2011a, ISE 13.4
Simulink reports and error in the block addsub:
standard exception: XNetlistEngine:
An exception was raised:
c:/plop/netlist/C:\: Invalid argument at
The block addsub is not the cause, as when I delete all addsub, the error is moved back to BConvert, so I guess it's the first block name.
From the perl function, it seems the call
my $dir = buildPath($dstDir, &dirname($file));
Has a bad $file value (empty?) and the resulting $dir is corrupted (c:/plop/netlist/C:\)
I'm not a perl specialist so I couldn't push the investigation much further, so if anyone can help me out I'd gladly appreciate.
03-12-2012 06:38 PM
Seems like somethin strange is going on.
Where is your project directory located? Where do TMP and TEMP environment variables point? What directory are you trying to export the pcore to?
03-13-2012 08:22 AM - edited 03-13-2012 09:49 AM
Good day bwiec,
I just checked the environment variables:
TMP is: C:\Documents and Settings\XXXX\Local Settings\Temp
TEMP is : C:\Documents and Settings\XXXX\Local Settings\Temp
(where XXXX my user name without space/strange characters)
The project is in a short directory without spaces (here c:/test/) and I'm exporting in the ./netlist/.
I've changed the TMP/TEMP global variable to C:\TEMP, to avoid the spaces, and I still have the same crash in the SgPass2Netlist.pm script.
When looking at the error message there seems to be some confusion between "/" and "\" in the system, the only question is why it does not happen with PLB option...
===> mkdir C:/test/netlist/C:\: Invalid argument at ... <===
Actually I've scoured the net to find a way to replace all the \ to / in perl and even by inserting:
$dstDir =~ tr/\\/\//;
$file =~ tr/\\/\//;
before, I get the same error with a / this time : ===> mkdir C:/test/netlist/C:/: Invalid argument at ... <=== so the / are not the cause....
Thanks for your suggestions
03-14-2012 12:20 AM
It's really strange... Try to set in 'System Generator' block parameter 'Hardware Description Language' to VHDL.
I can't generate pcore for your model in Verilog mode (error in SgPass2Netlist.pm).
But it's ok with VHDL.
03-14-2012 08:41 AM - edited 03-14-2012 08:55 AM
Good day Vitality,
you are perfectly right it works now in VHDL...
(I though I had made the test but maybe I missed the combination between vhdl/verilog & AXI/PLB or maybe my change in the environment variable made the trick)
=> So it seems that there is something fishy in the verilog PCORE generation part.
For confirmation of the bug, could you try to generate the simple pcore example under (just in/out buffers) and specify the version of your tools/os? This basic diagram crash the same way when I select Verilog and your info might help Xilinx to track down the bug.
Any Xilinx employee can confirm if it's a known bug?
Our projects are verilog based, so while I can temporary use mixed designs (I guess), but it would be great to have a fix.
Thanks all for your help,
03-15-2012 03:04 AM
Yes, I have same error in SgPass2Netlist.pm while trying to generate pcore for simplePcore.mdl in Verilog mode.
But there are no errors with VHDL. I'm using System Generator 13.4 and Matlab R2011a.
03-15-2012 11:02 AM
Great thanks Vitaly,
I'll try to open a webcase support to see what can be done.
If anyone else can try to generate this pcore in Verilog, please do and confirm/infirm the bug.
I'll keep the thread updated with the progress of the support case.
03-19-2012 12:08 PM
Good day all,
I just got an answer from the support (see under) and it's right now an open bug that can only be avoided by selecting the VHDL version of the AXI pCore.
I'll post any other update as they come.
Answer from Xilinx support:
So I found out that this is apparently a known issue that was found previously but there is no patch at this time.
I also spent some time in the perl myself trying to get a temporary workaround for you. However, it is a bit more complicated because there are multiple calls to this procedure from diffferent places so it is a bit difficult to just hard-code the correct directories and files.
At this point, we will have to wait for the developer to get back on this. So what I have done is attached the Change Request to this case and you can track its progress through the webcase portal to see when it is fixed.
If you need a patch in the mean time, you will need to go through your FAE who can file a patch request. Otherwise, your workarounds are to use VHDL for now or generate HDL code and create your own pcore in XPS using the Create Import Peripheral wizard.
03-28-2012 03:19 PM
It's official, we'll have to wait for the 14.2 version :
>> Yeah, unfortunately we don't have a solution on this yet. Apparently this particular bit of code has been used untouched for quite some time now without issue, so it will require someone to dig back into it. The only other information I have now is that the issue is scheduled to be fixed in 14.2.