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
XST 13.1 explodes with generic of enum type with only one member
Started by ●June 27, 2011
Reply by ●June 27, 20112011-06-27
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.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
Reply by ●June 28, 20112011-06-28
>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 BromleyI haven't met this, but it's the sort of degenerate case that I would not expect many parsers to handle well. Did you simulate it? --------------------------------------- Posted through http://www.FPGARelated.com
Reply by ●June 28, 20112011-06-28
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.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
Reply by ●June 28, 20112011-06-28
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?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
Reply by ●June 28, 20112011-06-28
On Tue, 28 Jun 2011 00:30:13 +0100, Alan Fitch wrote:> I've always told peopleincluding 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 :-)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.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
Reply by ●June 29, 20112011-06-29
On Tue, 28 Jun 2011 11:44:49 -0700, Tim Wescott wrote:>vesa_abnormal_brain_do_not_useheh. Best laugh for days. Walk this way! -- Jonathan Bromley
Reply by ●June 29, 20112011-06-29
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.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
Reply by ●June 29, 20112011-06-29
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...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
Reply by ●June 29, 20112011-06-29
On Wed, 29 Jun 2011 19:37:53 +0100, Alan Fitch wrote:>I am still confused by constantness (constantosity??) in SV.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.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
