Sign in

username:

password:



Not a member?

Search Comp.Arch.FPGA



Search tips

fpga by Keywords

Altera | ASIC | CPLD | Cyclone | DCM | DDR | DSP | Ethernet | ISE | JTAG | Linux | LVDS | Microblaze | ML310 | Modelsim | NIOS | OPB | PCI | Quartus | RocketIO | SDRAM | Spartan | Spartan3 | SRAM | Stratix | Verilog | VHDL | Virtex | Virtex-4 | Virtex-II | Xilinx | XST


Ads

See Also

DSPEmbedded SystemsElectronics

Comp.Arch.FPGA | Do Xilinx really want people to report INTERNAL_ERRORs?

There are 2 messages in this thread.

You are currently looking at messages 0 to 2.

Do Xilinx really want people to report INTERNAL_ERRORs? - Philip Pemberton - 2010-05-23 15:30:00

... because it certainly seems like they don't.

A couple of minutes ago, I made some changes to my project which made the 
synthesizer fall flat on its face:

INTERNAL_ERROR:Xst:cmain.c:3464:1.56: Process will terminate. For 
technical support on this issue, please open a WebCase with this project 
attached at http://www.xilinx.com/support.

OK, seems like a fair request. This project (or most of it) is probably 
going open-source at the end of its development cycle, so giving up a 
chunk of unfinished code really isn't a problem. So I go to the 
aforementioned URL, and try to register for Webcase access. And I'm met 
with this:

WebCase Access Request Denied
Your request for access to WebCase was denied.

No explanation, just "access denied".
So... do Xilinx really want to fix bugs, or is this a subtle way of 
saying "we don't care about making our software any better than it 
already is"?

Hmmm.

-- 
Phil.
u...@philpem.me.uk
http://www.philpem.me.uk/
If mail bounces, replace "10" with the last two digits of the current year
______________________________
Join the blogging team on FPGARelated.com and earn rewards! Details Here.



Re: Do Xilinx really want people to report INTERNAL_ERRORs? - Philip Pemberton - 2010-05-23 20:05:00

On Sun, 23 May 2010 19:30:37 +0000, Philip
Pemberton wrote:

> INTERNAL_ERROR:Xst:cmain.c:3464:1.56: Process will terminate. For
> technical support on this issue, please open a WebCase with this project
> attached at http://www.xilinx.com/support.

OK, in the interests of documentation... this is how you provoke the bug, 
and how to work around it.


Phase 1: Provocation
====================
Create a bus port in the design's 'top' module, but make it wider than 
the UCF pin specification. Assign an IOB constraint (IOB=TRUE or 
IOB=FORCE) to it. Assign a varying value to all pins of the bus (that is, 
a value that can change depending on the input to the logic).

For example:
// top.v
(* IOB = "TRUE" *) output  [12:0]  SDRAM_A

# top.ucf
NET "SDRAM_A<0>"   	LOC = "J12" | IOSTANDARD = LVTTL ;	

NET "SDRAM_A<1>"   	LOC = "A3"  | IOSTANDARD = LVTTL ;	

# ...
NET "SDRAM_A<10>"  	LOC = "J13" | IOSTANDARD = LVTTL ;	

NET "SDRAM_A<11>"  	LOC = "C4"  | IOSTANDARD = LVTTL ;	

# NET "SDRAM_A<12>"  	LOC = "D11" | IOSTANDARD = LVTTL ;	

Note that SDRAM_A12 is commented out in the UCF.


Phase 2: Resolution (or rather "workaround")
============================================
Either specify a pin location constraint for SDRAM_A[12] in the UCF, or 
reduce the size of the SDRAM_A bus in the Verilog source.


Phase 3: The Executive Summary
==============================
Xst doesn't like it when you specify an IOB constraint on an output port 
that hasn't been assigned a pin on the chip.


I'd still like to find out how to report this to Xilinx... "just open a 
Webcase" is only a valid solution when you can actually get to Webcase...

-- 
Phil.
u...@philpem.me.uk
http://www.philpem.me.uk/
If mail bounces, replace "10" with the last two digits of the current year
______________________________
Join the blogging team on FPGARelated.com and earn rewards! Details Here.