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

Mon Jun 27, 2011 10:36 pm   

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

Mon Jun 27, 2011 11:30 pm   

On 27/06/11 23:36, Jonathan Bromley wrote:

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

Tue Jun 28, 2011 10:33 am   

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

Tue Jun 28, 2011 6:44 pm   

On 06/27/2011 03:36 PM, Jonathan Bromley wrote:

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

Tue Jun 28, 2011 9:47 pm   

On Tue, 28 Jun 2011 05:33:42 -0500, "RCIngham" wrote:


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

Tue Jun 28, 2011 9:57 pm   

On Tue, 28 Jun 2011 00:30:13 +0100, Alan Fitch wrote:


including me; and yes, I did listen at the time :-)


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


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

Wed Jun 29, 2011 11:42 am   

On Tue, 28 Jun 2011 11:44:49 -0700, Tim Wescott wrote:


heh. Best laugh for days. Walk this way!
--
Jonathan Bromley

Wed Jun 29, 2011 12:15 pm   

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


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

Wed Jun 29, 2011 6:37 pm   

On 28/06/11 22:57, Jonathan Bromley wrote:

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

Wed Jun 29, 2011 8:09 pm   

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


Hmm, getting seriously OT here, but anyhow...


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

Thu Jun 30, 2011 1:09 pm   

On Wed, 29 Jun 2011 13:15:02 +0100, Jonathan Bromley wrote:


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.


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

Fri Jul 01, 2011 10:34 am   

Brian Drummond <brian_at_shapes.demon.co.uk> writes:


Only for (some - V5 and S3 I think) old devices - AFAIK from 6-devices
onwards it's the new parser only.


So far it has been IME...


Do let us know how you fare :)

Cheers,
Martin

--
martin.j.thompson_at_trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.co.uk/capabilities/39-electronic-hardware

Wed Jul 20, 2011 4:01 am   

On Thu, 30 Jun 2011 11:09:12 +0000 (UTC)
Brian Drummond <brian_at_shapes.demon.co.uk> wrote:


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

Wed Aug 03, 2011 8:54 pm   

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


(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