Late answer:
[...]
>
> I'd expect the messages:
>
>
>
>
> warning: universal integer bound must be numeric literal or attribute
>
>
> have something to do with it, associated with lines 1192 and 1222 of
> X_RAMB8BWER.vhd and X_RAMB16BWER.vhd, which are likely derived from
> the same source, varying in size in the memory array.
>
>
> Syntax warnings
>
>
> Simply put there are no syntax warnings in VHDL, ambiguous syntax is
> not allowed. I'd imagine these 'warnings' are left over from the
> early days of ghdl. VHDL analyzers and simulators tend to be grown
> organically, and allowing questionable constructs by can allow you
> to continue development. It would likely signify something that
> wasn't properly revisited later and possibly due to a different
> cause are fatal during simulation here. To be clear this would
> represent a shortcoming in the ghdl implementation, something not
> yet finished.
No, the warning is here because the syntax is not valid, but this looks like an
error in the LRM.
> The warning message would have to do with the right bound of a for
> loop iteration scheme (see work around below, di'length-1). The
> right bound of the range for a standard logic vector di is
> determined by getting the length and subtracting 1, the left bound
> specified as 0. The issue is that ghdl seems to not properly
> propagate the type of the left hand side of a predefined operator to
> the output of the operator. I believe this has shown up twice this
> year on ghdl-discuss.
It does properly propagate the type.
> (I don't have the ability to release new versions of ghdl on
> ghdl.free.fr . It took Tristan's intervention to be able to make the
> Mac OS X mcode version available there. Because of that I haven't
> fixed it.)
>
>
> Semantic Restrictions on the for loop parameter specification
>
>
> Those simply interested in a potential solution can skip to the Is it
> possible to work around the ghdl problem? section below. Us VHDL
> lawyers try to never miss an opportunity to pontificate.
>
>
> Holding Tristan in high regard we can look for deeper meaning in the
> warning, checking semantics found in various versions of the LRM.
> The bound from the warning refers to the rightmost range bound given
> in the for loop range constraint.
>
> From IEEE 1076-1993 (LRM-93), 8.9 Loop statement , paragraphs 9 and
> 10:
>
>
>
>
> For a loop statement with a for iteration scheme, the loop parameter
> specification is the declaration of the loop parameter with the
> given identifier. The loop parameter is an object whose type is the
> base type of the discrete range. Within the sequence of statements,
> the loop parameter is a constant. Hence, a loop parameter is not
> allowed as the target of an assignment statement. Similarly, the
> loop parameter must not be given as an actual corresponding to a
> formal of mode out or inout in an association list.
>
>
> For the execution of a loop with a for iteration scheme, the discrete
> range is first evaluated. If the discrete range is a null range, the
> iteration scheme is said to be complete and the execution of the
> loop statement is therefore complete; otherwise, the sequence of
> statements is executed once for each value of the discrete range
> (subject to the loop not being left as a consequence of the
> execution of a next statement, an exit statement, or a return
> statement), after which the iteration scheme is said to be complete.
> Prior to each such iteration, the corresponding value of the
> discrete range is assigned to the loop parameter. These values are
> assigned in left-to-right order.
>
>
> Part of the understanding required to implement the semantic
> restrictions therein would be understanding what is meant by
> discrete range and whether di'length-1 is valid as a bound of a
> discrete range.
No, because of:
-- LRM 3.2.1.1 Index constraints and discrete ranges
-- For a discrete range used in a constrained array
-- definition and defined by a range, an implicit
-- conversion to the predefined type INTEGER is assumed
-- if each bound is either a numeric literal or an
-- attribute, and the type of both bounds (prior to the
-- implicit conversion) is the type universal_integer.
Tristan.
>
>
> From the LRM-93 Glossary:
>
>
>
>
>
> B.76 discrete range: A range whose bounds are of a discrete type.(§
> 3.2.1, § 3.2.1.1)
>
>
> B.77 discrete type: An enumeration type or an integer type. Each
> value of a discrete type has a position number that is an integer
> value. Indexing and iteration rules use values of discrete types. (§
> 3.1)
>
>
> From 14.1 Predefined Attributes (LRM-93):
>
>
>
>
>
> A'LENGTH[(N)] Kind: Value. Prefix:Any prefix A that is appropriate
> for an array object, or an alias thereof, or that denotes a
> constrained array subtype Parameter:A locally static expression of
> type universal_integer , the value of which must not exceed the
> dimensionality of A. If omitted, it defaults to 1. Result Type:
> universal_integer . Result:Number of values in the Nth index range;
> i.e., if the Nth index range of A is a null range, then the result
> is 0. Otherwise, the result is the value of T'POS(A'HIGH(N)) -
> T'POS(A'LOW(N)) + 1, where T is the subtype of the Nth index of A.
>
>
>
> So di'length is a type universal_integer which is the base type (in
> abstract) for integer types. Further the type of a result of a
> subtraction ("-") is the type of the left hand argument (di'length).
> You might expect the a range given as 0 to di-length-1 is discrete.
> (And note that Modeltech (mti) appears capable of elaborating and
> simulating the for loop iteration schemes found in these two
> models). This is where the supposition that ghdl is unfinished in
> this area comes from.
>
>
> You could note the "never referenced" messages aren't syntax warnings
> and my above statement on syntax warnings is not inconsistent with
> these warnings.
>
>
> "cannot allocate stack: memory exhausted"
>
>
> The runtime error "cannot allocate stack: memory exhausted" message
> comes from ghdl/translate/grt/grt-processes.adb line 126 in
> procedure Process_Register. grt is the GHDL Run Time, the simulator
> kernel that executes the model. Essentially the analyzer is
> constructing a model that the simulator can't execute faithfully,
> instead causing a memory leak. It would essentially be getting off
> the beaten track and likely never returning to the proper confines
> of the model. Likely a very large value is being taken as a range
> bound and something very large is being inferred.
>
>
> Is it possible to work around the ghdl problem?
>
>
> By definition this would imply modifying the Xilinx Models. I'd
> suggest first copying them somewhere else then compiling them into
> your simprim library after modification. You'd want to leave the
> original copies intact.
>
>
> We look at the two lines 1192 and 1222 in X_RAMB8BWER.vhd and lines
> 1199 and 1229 in X_RAMB16BWER.vhd to see what's peculiar
> (particular) about them.
>
>
> Both sets of noted lines reference a for loop:
>
>
>
>
>
> for i in 0 to di'length-1 loop
>
>
>
> One in procedure prcd_write_ram_col, one in procedure
> prcd_write_ram_ox. A quick survey shows these are the only two
> places di'length-1 is derived.
>
>
> Right about now we bog down a bit because these models were written
> to represent any width RAM then later caste (copied, instantiated)
> to particular entity/architecture pairs. This has to do with columns
> in the RAM array see prcd_col_wr_ram_b and prcd_ox_wr_ram_b for
> example, where we find that arguments to prcd_write_ram_col and
> prcd_write_ram_ox can contain different di ranges inherited from the
> argument subtype:
>
>
> dib_tmp(7 downto 0), dib_tmp(15 downto 8) dib_tmp(23 downto 16),
> dib_tmp(31 downto 24)
>
>
> as arguments to procedures prcd_write_ram_col and prcd_write_ram_ox
> for various RAM widths fitted into RAM columns (a physical cell
> restriction no doubt).
>
>
> These are used to assign array elements (bits) from the input (and
> constant) standard logic vector di to the mem_proc_tmp an alias for
> the mem_proc inout port standard logic vector value with a defined
> range of memproc-lenth-1 downto 0. There's this assumption the
> lengths of di and proc_mem match, that they are both byte width
> (length = 8).
>
>
> A secondary goal here is to not re-write the models, fraught with
> chance of introducing error., instead we're looking for a simple
> solution.
>
>
> You could note that if di and proc_mem match in length, that we also
> have an alias di_tmp whose range is specified identically to
> mem_proc_temp.
>
>
> In the for loop iteration schemes:
>
>
>
>
>
> for i in 0 to di'length-1 loop
>
>
>
> We could use the range of either di_tmp or proc_mem_tmp e.g. :
>
>
>
>
>
> for i in proc_mem_tmp'RANGE loop
>
>
>
> for lines ll92 and 1222 of X_RAMB8BWER.vhd and lines 1199 and 1229 of
> X_RAMB16BWER.vhd avoiding the problem of the expression
> (di'length-1) propagating the left hand type to the output type
> which ghdl appears to have problems with.
>
>
> When the left hand and right sides of the variable assignments in the
> following lines involve the _tmp aliases, it's unclear why di'length
> was used in any event. The goal is to have matching ranges for the
> di value and proc_mem value (their aliases).
>
>
> The Actual Fixes:
>
>
> So try changing the range constraint of the for loop iteration
> schemes to avoid using expressions, e.g.:
>
>
> for i in proc_mem_tmp'RANGE loop
>
>
> for lines 1192 and 1222 of X_RAMB8BWER.vhd and lines 1199 and 1229 of
> X_RAMB16BWER.vhd respectively.
>
>
> These should be guaranteed to be discrete ranges not depending on
> predefined operators passing their lefthand side type to the output
> type.
>
>
> Let us know if that works. You could note these changes should be
> compatible with how Xilinx uses the models.
>
>
>
>
>
> _______________________________________________
> Ghdl-discuss mailing list
> [email protected]
> https://mail.gna.org/listinfo/ghdl-discuss
>
_______________________________________________
Ghdl-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/ghdl-discuss
