XST 13.1 explodes with generic of enum type with only one me

J

Jonathan Bromley

Guest
It was all going so well until I asked XST to compile a
VHDL entity with a generic of this type:
type video_modes_e is (vesa_1024x768_65Hz);
I guess I'll have more modes later, but just now I
need only the one. But as soon as I put a generic
of type video_modes_e on any entity, I get
INTERNAL_ERROR:Xst:cmain.c:3464:1.56 - Process will terminate
followed by nice friendly suggestions about filing a WebCase.

Anyone else met this? I fixed it by adding a dummy value to
the enumeration, but that's a bit rubbish, isn't it?

I'll file the case, but thought y'all might be interested.
--
Jonathan Bromley
 
On 27/06/11 23:36, Jonathan Bromley wrote:
It was all going so well until I asked XST to compile a
VHDL entity with a generic of this type:
type video_modes_e is (vesa_1024x768_65Hz);
I guess I'll have more modes later, but just now I
need only the one. But as soon as I put a generic
of type video_modes_e on any entity, I get
INTERNAL_ERROR:Xst:cmain.c:3464:1.56 - Process will terminate
followed by nice friendly suggestions about filing a WebCase.

Anyone else met this? I fixed it by adding a dummy value to
the enumeration, but that's a bit rubbish, isn't it?

I'll file the case, but thought y'all might be interested.
Click to expand...
Hi Jonathan,
I've always told people it was safest to stick to generics that are
integer (and subtypes thereof). Recently, I'd changed my tune, as
various tools coped fine with boolean, enum, etc.. Now I will change my
tune back again :)

Generally broken stuff in XST can be worked around by writing a wrapper
round the top level - which is also a bit rubbish I suppose.

regards
Alan


--
Alan Fitch
 
It was all going so well until I asked XST to compile a
VHDL entity with a generic of this type:
type video_modes_e is (vesa_1024x768_65Hz);
I guess I'll have more modes later, but just now I
need only the one. But as soon as I put a generic
of type video_modes_e on any entity, I get
INTERNAL_ERROR:Xst:cmain.c:3464:1.56 - Process will terminate
followed by nice friendly suggestions about filing a WebCase.

Anyone else met this? I fixed it by adding a dummy value to
the enumeration, but that's a bit rubbish, isn't it?

I'll file the case, but thought y'all might be interested.
--
Jonathan Bromley
Click to expand...
I haven't met this, but it's the sort of degenerate case that I would no
expect many parsers to handle well. Did you simulate it?


---------------------------------------
Posted through http://www.FPGARelated.com
 
On 06/27/2011 03:36 PM, Jonathan Bromley wrote:
It was all going so well until I asked XST to compile a
VHDL entity with a generic of this type:
type video_modes_e is (vesa_1024x768_65Hz);
I guess I'll have more modes later, but just now I
need only the one. But as soon as I put a generic
of type video_modes_e on any entity, I get
INTERNAL_ERROR:Xst:cmain.c:3464:1.56 - Process will terminate
followed by nice friendly suggestions about filing a WebCase.

Anyone else met this? I fixed it by adding a dummy value to
the enumeration, but that's a bit rubbish, isn't it?

I'll file the case, but thought y'all might be interested.
Click to expand...
Yes, it's a bit rubbish. You'd expect tools to be able to gracefully
handle this sort of thing.

But the pain involved in defining an element
vesa_abnormal_brain_do_not_use or vesa_xst_sucks is pretty low, and if
you choose the name right there's not much chance folks will mistake it
for the real deal.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html
 
On Tue, 28 Jun 2011 05:33:42 -0500, "RCIngham" wrote:

... it's the sort of degenerate case that I would not
expect many parsers to handle well. Did you simulate it?
Click to expand...
I'm only slightly insulted :)

Yes, I did, and it does.

Clearly this is a slightly odd case, but actually the idea
of an enum with only one value is far from crazy. In this
case, I'm using the enum to index into a table of constant
records. Consequently, if I add a dummy enum, I'm obliged
to add a dummy record too. Evidently this problem will go
away of its own accord as soon as I have a second useful
entry in the table, but the broken parser/elaborator is
nevertheless disappointing - and it cost me a wasted
evening on my little playtime project, an excuse to start
using VHDL and Xilinx tools again after a long absence
(and my first brush with ISE 13, which on balance seems
to be A Good Thing).
--
Jonathan Bromley
 
On Tue, 28 Jun 2011 00:30:13 +0100, Alan Fitch wrote:

I've always told people
Click to expand...
including me; and yes, I did listen at the time :)

it was safest to stick to generics that are
integer (and subtypes thereof). Recently, I'd changed my tune, as
various tools coped fine with boolean, enum, etc.. Now I will change my
tune back again :)
Click to expand...
Well, I thought to myself "that Alan Fitch isn't
mentoring me any more, so I am free to do all manner
of wild and wacky things", and look where it got me...

Generally broken stuff in XST can be worked around by writing a wrapper
round the top level - which is also a bit rubbish I suppose.
Click to expand...
Ho hum. At least it's about four orders of magnitude less
horrible than the day job's current concern, which is all
about what is or isn't a constant in SystemVerilog
covergroups. Never in the field of, etc, etc, have
so many different tools given so many different
"not yet implemented" errors...
--
Jonathan Bromley
 
On Tue, 28 Jun 2011 11:44:49 -0700, Tim Wescott wrote:

vesa_abnormal_brain_do_not_use
Click to expand...
heh. Best laugh for days. Walk this way!
--
Jonathan Bromley
 
On Mon, 27 Jun 2011 23:36:49 +0100, Jonathan Bromley wrote:

It was all going so well until I asked XST to compile a
VHDL entity with a generic of this type:
type video_modes_e is (vesa_1024x768_65Hz);
I guess I'll have more modes later, but just now I
need only the one. But as soon as I put a generic
of type video_modes_e on any entity, I get
INTERNAL_ERROR:Xst:cmain.c:3464:1.56 - Process will terminate
[...]
I'll file the case, but thought y'all might be interested.
Click to expand...
Wow. Serious kudos to Xilinx's support team. I got an
intelligent, courteous response overnight, and then a
real working fix three hours later.

The fix is to add

-use_new_parser yes

to the XST command line (or, equivalently, put it in
Synthesis Process Properties/Other XST Command Line Options).

Apparently it's the default if you're using newer devices,
though I haven't investigated that in detail. I'm using
a heritage Spartan-3.

Problem solved, job done, happy customer.
--
Jonathan Bromley
 
On 28/06/11 22:57, Jonathan Bromley wrote:
On Tue, 28 Jun 2011 00:30:13 +0100, Alan Fitch wrote:

snip
Generally broken stuff in XST can be worked around by writing a wrapper
round the top level - which is also a bit rubbish I suppose.

Ho hum. At least it's about four orders of magnitude less
horrible than the day job's current concern, which is all
about what is or isn't a constant in SystemVerilog
covergroups. Never in the field of, etc, etc, have
so many different tools given so many different
"not yet implemented" errors...
Click to expand...
I am still confused by constantness (constantosity??) in SV. I tried
putting a const in a package, and then initialising another constant to
it in a module. Quartus threw it out as not constant. localparams seem
to work fine. I guess I've been mis-guided by VHDL

Alan

--
Alan Fitch
 
On Wed, 29 Jun 2011 19:37:53 +0100, Alan Fitch wrote:

I am still confused by constantness (constantosity??) in SV.
Click to expand...
Hmm, getting seriously OT here, but anyhow...

I tried putting a const in a package, and then
initialising another constant to
it in a module. Quartus threw it out as not constant. localparams seem
to work fine.
Click to expand...
First thing to get straight is that const doesn't mean
constant in SV; it's closer to "read-only". Consts
can be initialised, but not altered after initialisation,
unless they're data members of a class in which case they
can be written only once in the class's constructor, or
they are ref arguments to a subprogram in which case
they refer to something that's read-only from the
subprogram's point of view. In all these cases, the
things in question are variables, not constants.

Parameters and localparams, au contraire, are truly
constant (look for "constant expression" in 1800-2009).
Their value is determined during elaboration and is
immutable thenceforward. This elaboration-time
determination of value means that parameters, and
indeed constant expressions in general, can be used
to specify and control the attributes of a data type
such as bit-width. Can't do that with a const.
Similarly, any attributes scavenged from a data type
such as $left() are also constant expressions.

And then, just for laughs, there are the rules about
constant expressions not being allowed to include
any hierarchical (cross-module) references.

Never mind, it could be worse. I spent about four
months fighting the function/operator overload
resolution rules in C++ a little while ago. That
was truly a nightmare. Bring back VHDL...
--
Jonathan Bromley
 
On Wed, 29 Jun 2011 13:15:02 +0100, Jonathan Bromley wrote:

On Mon, 27 Jun 2011 23:36:49 +0100, Jonathan Bromley wrote:

INTERNAL_ERROR:Xst:cmain.c:3464:1.56 - Process will terminate
[...]
I'll file the case, but thought y'all might be interested.

Wow. Serious kudos to Xilinx's support team. I got an intelligent,
courteous response overnight, and then a real working fix three hours
later.

The fix is to add

-use_new_parser yes
Click to expand...
AHA!

I had heard that XST13 used a new VHDL front end, and was dreading
training it to understand code tweaked to suit old XST foibles.

If this is a problem with the old parser, that suggests older versions of
XST might blow up in the same way. Have you tried XST12 or earlier?

Also it's good to know that both parsers are available in case of trouble.

Apparently it's the default if you're using newer devices, though I
haven't investigated that in detail. I'm using a heritage Spartan-3.

Problem solved, job done, happy customer.
Click to expand...
And if newer really = better, then kudos to the XST team.

I haven't got around to trying out my carefully cultivated nest of vipers
on ISE13 yet.

- Brian
 
Brian Drummond <brian@shapes.demon.co.uk> writes:

Also it's good to know that both parsers are available in case of trouble.
Click to expand...
Only for (some - V5 and S3 I think) old devices - AFAIK from 6-devices
onwards it's the new parser only.

Apparently it's the default if you're using newer devices, though I
haven't investigated that in detail. I'm using a heritage Spartan-3.

Problem solved, job done, happy customer.

And if newer really = better, then kudos to the XST team.
Click to expand...
So far it has been IME...

I haven't got around to trying out my carefully cultivated nest of vipers
on ISE13 yet.
Click to expand...
Do let us know how you fare :)

Cheers,
Martin

--
martin.j.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.co.uk/capabilities/39-electronic-hardware
 
On Thu, 30 Jun 2011 11:09:12 +0000 (UTC)
Brian Drummond <brian@shapes.demon.co.uk> wrote:

-use_new_parser yes

AHA!

I had heard that XST13 used a new VHDL front end, and was dreading
training it to understand code tweaked to suit old XST foibles.

If this is a problem with the old parser, that suggests older
versions of XST might blow up in the same way. Have you tried XST12
or earlier?

Also it's good to know that both parsers are available in case of
trouble.

Apparently it's the default if you're using newer devices, though I
haven't investigated that in detail. I'm using a heritage
Spartan-3.

Problem solved, job done, happy customer.

And if newer really = better, then kudos to the XST team.

I haven't got around to trying out my carefully cultivated nest of
vipers on ISE13 yet.

- Brian
Click to expand...
I do see one unfortunate change from the old parser to the new, at
least for Spartan 3A synthesis: it no longer tells you as clearly when
it recognizes macros. The old parser used to tell you when it
recognized, say, an 8-bit up counter, under "Synthesizing Unit <Foo>",
along with the name of the signal constituting the counter. The new
synthesizer only reports registers and adders. It then goes on to
"Advanced HDL Synthesis", during which it talks about absorbing
registers into counters, and afterwards tells you how many of each
counter there are, but that seems to be it—it was nice to have the
macro recognition right there in the first step, so one could easily
differentiate between "a register and an adder" vs "a counter"; with
the new parser, one would have to cross-check between the two locations
("HDL Synthesis" and "Advanced HDL Synthesis") to make sure everything
that should have been recognized was (since the Advanced HDL Synthesis
section doesn't reprint the list of plain vanilla registers).

Otherwise, it caught a couple of sloppy practices that had previously
escaped (good!) and also reduced my slice count by a bit (better!)

Chris
 
On Fri, 01 Jul 2011 11:34:28 +0100, Martin Thompson wrote:

Brian Drummond <brian@shapes.demon.co.uk> writes:

I haven't got around to trying out my carefully cultivated nest of
vipers on ISE13 yet.
Do let us know how you fare :)
Click to expand...
(about a month later...) By and large, now trouble free.
A couple of workarounds for previous bugs are now illegal (or always
were, but are now detected) but that's OK because the original bugs have
been fixed.

Type conversions are now usable on output ports (but in the new parser,
i.e. by default for newer devices only!)

The only defect I have seen is that ISIM is dog slow and has a huge
memory footprint for post-route sims on new devices (Spartan-6) - about
an order of magnitude larger/slower than the same simulation targetting
Spartan-3.

A definite improvement.
- Brian
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top