Xilinx "something's wrong" error

Hi All,

I'm trying to synthesize a pretty complex system which simulates fine in
ModelSim (I know that this doesn't mean it's synthesizable, but I'm
trying to get to that point).

Part-way through the synthesis (on the second component that it actually
tries to do HDL synthesis on, after it does all the generics
instantiation and all that), ISE gives me it's famous "something went
wrong... contact support" error message.

Is there any indication about *where* it went wrong, so I can at least
try to re-write that code? What's the best way of trying to tackle this
issue?

Thanks,

Sergey

Sergey Katsev

Sergey Katsev wrote:

> Is there any indication about *where* it went wrong, so I can at least
> try to re-write that code? What's the best way of trying to tackle this
> issue?

With vhdl simulation.
Maybe you gave synthesis an impossible task
that it hasn't seen before.
Start with a working example or
design the uut using a synchronous template
that has a chance to work.
Write and run a testbench that shows the logic is right.
Run synthesis and view the RTL schematic.


http://home.comcast.net/~mike_treseler/

Mike Treseler

Thanks for your response Mike.

As far as I know, the code is synchronous and should be synthesizable.
It's several components comprised of generically generated systolic
arrays, but the array elements are just arithmetic operations.

The element that it "dies" on should just be two flip-flops:

entity A1circ is
port( clk : in std_logic := '0';
X : in sfixed_c := (others=> '0'); -- input
flag_in : in std_logic := '0';
Y : out sfixed_c := (others=> '0'); -- output
flag_out : out std_logic := '0'
);
end A1circ;

architecture behav of A1circ is

begin
process(clk)
begin
if rising_edge(clk) then
Y <= X;
flag_out <= flag_in;
end if;
end process;
end behav;

Is there anything wrong with that piece of code?... or does the fact
that the fatal error occurs when synthesizing this unit doesn't
necessarily imply that this is where the problem resides?

Thanks again...

Here's the XST output (the last few lines):

================================================== =======================
* HDL Synthesis *
================================================== =======================

Performing bidirectional port resolution...

Synthesizing Unit <validator>.
Related source file is
"C:/thesis/SDRE/VHDL/FINAL/final/validator.vhdl".
Unit <validator> synthesized.


Synthesizing Unit <A1circ>.
Related source file is "C:/thesis/SDRE/VHDL/FINAL/final/A1circ.vhdl".
FATAL_ERROR:Xstortability/export/Port_Main.h:127:1.16 - This
application has discovered an exceptional condition from which it cannot
recover. Process will terminate. To resolve this error, please consult
the Answers Database and other online resources at
http://support.xilinx.com. If you need further assistance, please open a
Webcase by clicking on the "WebCase" link at http://support.xilinx.com

Process "Synthesize" failed



Mike Treseler wrote:
> Sergey Katsev wrote:
>
>> Is there any indication about *where* it went wrong, so I can at least
>> try to re-write that code? What's the best way of trying to tackle
>> this issue?
>
> With vhdl simulation.
> Maybe you gave synthesis an impossible task
> that it hasn't seen before.
> Start with a working example or
> design the uut using a synchronous template
> that has a chance to work.
> Write and run a testbench that shows the logic is right.
> Run synthesis and view the RTL schematic.
>
>
> http://home.comcast.net/~mike_treseler/

Sergey Katsev

"Sergey Katsev" <> wrote in message
news8ydnW6apIYP-...
> Hi All,
>
> I'm trying to synthesize a pretty complex system which simulates fine in
> ModelSim (I know that this doesn't mean it's synthesizable, but I'm trying
> to get to that point).
>
> Part-way through the synthesis (on the second component that it actually
> tries to do HDL synthesis on, after it does all the generics instantiation
> and all that), ISE gives me it's famous "something went wrong... contact
> support" error message.

We all hate this error.

Could you specify what version of ISE you are using

> Is there any indication about *where* it went wrong, so I can at least try
> to re-write that code? What's the best way of trying to tackle this
> issue?

A few ideas:

Try synthesizing the subcomponent in isolation (rather than in the context
of the larger system) and see if the issue still occurs.

Look for pieces of VHDL syntax that are "ambitious" (e.g. calculating
constants using complicated functions, using records, arrays of records,
records of records, anything that's not straight out of a textbook).

Try the "binary search" method - comment out half your file and re-run
synthesis; if it starts working then the error is in the commented-out half;
iterate until you've found the line it doesn't like.

If you can post some of your code at any stage of the debugging process, you
might find that someone in this newsgroup can tell you exactly what the
problem is straight away. These sorts of banging-head-against-the-wall
issues tend to stick in the mind somewhat...

Cheers,

-Ben-

Ben Jones

Thanks for your response Ben...

I'm using ISE 8.2i

I posted the piece that I think it's getting stuck on in a previous
message... but (unless I'm missing something obvious), I don't really
see how it could get stuck on that code...

-- Sergey

Ben Jones wrote:
> "Sergey Katsev" <> wrote in message
> news8ydnW6apIYP-...
>> Hi All,
>>
>> I'm trying to synthesize a pretty complex system which simulates fine in
>> ModelSim (I know that this doesn't mean it's synthesizable, but I'm trying
>> to get to that point).
>>
>> Part-way through the synthesis (on the second component that it actually
>> tries to do HDL synthesis on, after it does all the generics instantiation
>> and all that), ISE gives me it's famous "something went wrong... contact
>> support" error message.
>
> We all hate this error.
>
> Could you specify what version of ISE you are using
>
>> Is there any indication about *where* it went wrong, so I can at least try
>> to re-write that code? What's the best way of trying to tackle this
>> issue?
>
> A few ideas:
>
> Try synthesizing the subcomponent in isolation (rather than in the context
> of the larger system) and see if the issue still occurs.
>
> Look for pieces of VHDL syntax that are "ambitious" (e.g. calculating
> constants using complicated functions, using records, arrays of records,
> records of records, anything that's not straight out of a textbook).
>
> Try the "binary search" method - comment out half your file and re-run
> synthesis; if it starts working then the error is in the commented-out half;
> iterate until you've found the line it doesn't like.
>
> If you can post some of your code at any stage of the debugging process, you
> might find that someone in this newsgroup can tell you exactly what the
> problem is straight away. These sorts of banging-head-against-the-wall
> issues tend to stick in the mind somewhat...
>
> Cheers,
>
> -Ben-
>
>

Sergey Katsev

"Sergey Katsev" <> wrote in message
news:NcudnTpr-...
> Thanks for your response Ben...
>
> I'm using ISE 8.2i
>
> I posted the piece that I think it's getting stuck on in a previous
> message... but (unless I'm missing something obvious), I don't really see
> how it could get stuck on that code...

Yes, it does look like the simplest of the simple...

Is sfixed_c just an explicitly ranged subtype of std_logic_vector?

-Ben-

Ben Jones

Ben Jones wrote:
> "Sergey Katsev" <> wrote in message
> news:NcudnTpr-...
>> Thanks for your response Ben...
>>
>> I'm using ISE 8.2i
>>
>> I posted the piece that I think it's getting stuck on in a previous
>> message... but (unless I'm missing something obvious), I don't really see
>> how it could get stuck on that code...
>
> Yes, it does look like the simplest of the simple...
>
> Is sfixed_c just an explicitly ranged subtype of std_logic_vector?
>
> -Ben-
>
>
The sfixed_c type is from David Bishop's fixed point library... and that
synthesizes fine in a smaller test case I have.

-- Sergey

Sergey Katsev

Sergey Katsev wrote:
> Thanks for your response Mike.

> The element that it "dies" on should just be two flip-flops:
>
> entity A1circ is
> port( clk : in std_logic := '0';
> X : in sfixed_c := (others=> '0'); -- input

I expect that sfixed_c type requires
a more specific assignment than (others=> '0');
Run vcom on the source for a better error description.

-- Mike Treseler

Mike Treseler

Hmm...

sfixed_c is just a subtype defined to sfixed(32 downto -32).

However, when I try to do
in1, in2 : in sfixed(32 downto -32) := (others=>'0')

ISE tells me that "type of in1 is incompatible with type of aggregate".
Could it be that when I "mask" the type by using a subtype, ISE gets
confused?

(I can't actually test on the other code right now since I dont have it
with me)

How would I assign the inputs more explicitly? Or, do you mean just do
it inside of a process?

Thanks,

Sergey

Mike Treseler wrote:
> Sergey Katsev wrote:
>> Thanks for your response Mike.
>
>> The element that it "dies" on should just be two flip-flops:
>>
>> entity A1circ is
>> port( clk : in std_logic := '0';
>> X : in sfixed_c := (others=> '0'); -- input
>
> I expect that sfixed_c type requires
> a more specific assignment than (others=> '0');
> Run vcom on the source for a better error description.
>
> -- Mike Treseler

Sergey Katsev

Sergey,
Perhaps you could consider not initializing all of the
inputs and outputs.

If you are using this to imply
some form of power-on reset, keep in mind that this is
a Xilinx specific feature and will not port to other
FPGA technologies. I would recommend instead coding
reset explicitly (with a reset line).

Cheers,
Jim

> Hmm...
>
> sfixed_c is just a subtype defined to sfixed(32 downto -32).
>
> However, when I try to do
> in1, in2 : in sfixed(32 downto -32) := (others=>'0')
>
> ISE tells me that "type of in1 is incompatible with type of aggregate".
> Could it be that when I "mask" the type by using a subtype, ISE gets
> confused?
>
> (I can't actually test on the other code right now since I dont have it
> with me)
>
> How would I assign the inputs more explicitly? Or, do you mean just do
> it inside of a process?
>
> Thanks,
>
> Sergey
>
> Mike Treseler wrote:
>> Sergey Katsev wrote:
>>> Thanks for your response Mike.
>>
>>> The element that it "dies" on should just be two flip-flops:
>>>
>>> entity A1circ is
>>> port( clk : in std_logic := '0';
>>> X : in sfixed_c := (others=> '0'); -- input
>>
>> I expect that sfixed_c type requires
>> a more specific assignment than (others=> '0');
>> Run vcom on the source for a better error description.
>>
>> -- Mike Treseler


--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~
Jim Lewis
Director of Training private.php?do=newpm&u=
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~

Jim Lewis