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.
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
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).
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...
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
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...
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 ", 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!)
(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.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.