On Jan 14, 2012, at 11:10 PM, [email protected] wrote:
>> 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.
You're, right.
3.1.2 Integer types
An integer type definition defines an integer type whose set of values includes
those of the specified range.
integer_type_definition ::= range_constraint
An integer type definition defines both a type and a subtype of that type. The
type is an anonymous type, the range of which is selected by the
implementation; this range must be such that it wholly contains the range given
in the integer type definition. The subtype is a named subtype of this
anonymous base type, where the name of the subtype is that given by the
corresponding type declaration and the range of the subtype is the given range.
Each bound of a range constraint that is used in an integer type definition
must be a locally static expression of some integer type, but the two bounds
need not have the same integer type. (Negative bounds are allowed.)
Integer literals are the literals of an anonymous predefined type that is
called universal_integer in this standard. Other integer types have no
literals. However, for each integer type there exists an implicit conversion
that converts a value of type universal_integer into the corresponding value
(if any) of the integer type (see 7.3.5 ).
The position number of an integer value is the corresponding value of the type
universal_integer.
But the statement offering a qualified enable of conversion found in 3.2.1.1
isn't a prohibition for doing so otherwise. That's found here:
7.3.5 Type conversion
...
In certain cases, an implicit type conversion will be performed. An implicit
conversion of an operand of type universal_integer to another integer type, or
of an operand of type universal_real to another floating point type, can only
be applied if the operand is either a numeric literal or an attribute, or if
the operand is an expression consisting of the division of a value of a
physical type by a value of the same type; such an operand is called a
convertible universal operand. An implicit conversion of a convertible
universal operand is applied if and only if the innermost complete context
determines a unique (numeric) target type for the implicit conversion, and
there is no legal interpretation of this context without this conversion.
The language is also in VHDL-87. It's tempting to want to make it work
because as in this case di is globally static.
The only advantage to the limitation I can see is the ability to unroll loops,
and even then there are ways around it including the known exceptions. Declare
a range constraint as a type in a block declarative region, the alias as the
work around showed... Any case where the loop constraints aren't locally
static.
I wrote a test case using one of the RAM16BWER procedures offending procedures
and it simulates just fine. Your warning isn't being interrupted as an error
and isn't causing a memory leak.
>> red@linux-nrd1:~/projekt/mips/LM_CPU/ise/netgen/map> make run
>> ghdl -r tb_lm_cpu --sdf=./=lm_cpu_map.sdf --wave=tbench.ghw --stop-time=500us
>> ./tb_lm_cpu:internal error: cannot allocate stack: memory exhausted
>> ghdl: compilation error
>> make: *** [run] Error 1
>>
>> That runs out of stack space. I have use the stack size option 200MB but
>> this crashed anywhere.
>> I feel it is a short step into the goal.
What's causing the memory leak? I ran the test case (admittedly with only one
offending for loop case) for 8 seconds of simulation time and collected over a
half Gigabyte of dump file without the execution process memory size changing
after the simulation started for six signals (40 ns cycle time). All this in
mcode code converter version running on a Mac. The memory leak isn't to do
with loop constraints (directly).
There's uncertainty involved not having the original model to test with.
> ghdl -m -g -Psimprim -Wa,--32 -Wl,-m32 --warn-no-vital-generic
> --ieee=synopsys -fexplicit tb_lm_cpu
> ../../../src/vital2000/timing_b.vhdl:196:15:warning: procedure "vitalerror"
> is never referenced
> ../../../src/vital2000/timing_b.vhdl:217:15:warning: procedure "vitalerror"
> is never referenced
> ../../../src/vital2000/prmtvs_b.vhdl:1041:15:warning: function "toedge" is
> never referenced
> /opt/Xilinx/13.1/ISE_DS/ISE/vhdl/src/simprims/primitive/other/X_RAMB16BWER.vhd:277:5:
> VITAL scalar timing type expected
> /opt/Xilinx/13.1/ISE_DS/ISE/vhdl/src/simprims/primitive/other/X_RAMB16BWER.vhd:278:5:
> VITAL scalar timing type expected
> /opt/Xilinx/13.1/ISE_DS/ISE/vhdl/src/simprims/primitive/other/X_RAMB16BWER.vhd:279:5:
> VITAL scalar timing type expected
> /opt/Xilinx/13.1/ISE_DS/ISE/vhdl/src/simprims/primitive/other/X_RAMB16BWER.vhd:283:5:
> VITAL scalar timing type expected
> /opt/Xilinx/13.1/ISE_DS/ISE/vhdl/src/simprims/primitive/other/X_RAMB16BWER.vhd:287:5:
> VITAL scalar timing type expected
> /opt/Xilinx/13.1/ISE_DS/ISE/vhdl/src/simprims/primitive/other/X_RAMB16BWER.vhd:288:5:
> VITAL scalar timing type expected
> /opt/Xilinx/13.1/ISE_DS/ISE/vhdl/src/simprims/primitive/other/X_RAMB16BWER.vhd:289:5:
> VITAL scalar timing type expected
> /opt/Xilinx/13.1/ISE_DS/ISE/vhdl/src/simprims/primitive/other/X_RAMB16BWER.vhd:293:5:
> VITAL scalar timing type expected
These are worrisome but there's nothing yet telling me they're fatal to the
simulation effort. (Trisatan would have a better idea. It may be worth
documenting the meaning of output messages in GHDL).
These message come from ghdl/ieee-vital_timing.adb, procedure
Check_Vital_Delay_Type.
-- IEEE 1076.4 4.3.2.1.2 Timing generic subtypes
-- * If the timing generic is associated with a single port and that port
-- is a scalar, then the type of the timing generic shall be a scalar
-- form of delay type.
-- * If such a timing generic is associated with a single port and that
-- port is a vector, then the type of the timing generic shall be a
-- vector form of delay type, and the constraint on the generic shall
-- match that on the associated port.
The message is generated with Error_Vital, which we assume is why it's fatal.
While I found a copy of 1076.4-1995 yesterday, I'll defer to Tristan. the
simprims/primitive/other are supposed to be the VITAL95 compliant models.
These are the default generic declarations for the X_RAM16BWER lines 277
through 293:
tisd_ADDRA_CLKA : VitalDelayArrayType(13 downto 0) := (others => 0 ps);
tisd_DIA_CLKA : VitalDelayArrayType(31 downto 0) := (others => 0 ps);
tisd_DIPA_CLKA : VitalDelayArrayType(3 downto 0) := (others => 0 ps);
tisd_ENA_CLKA : VitalDelayType := 0 ps;
tisd_REGCEA_CLKA : VitalDelayType := 0 ps;
tisd_RSTA_CLKA : VitalDelayType := 0 ps;
tisd_WEA_CLKA : VitalDelayArrayType(3 downto 0) := (others => 0 ps);
ticd_CLKB : VitalDelayType := 0 ps;
tisd_ADDRB_CLKB : VitalDelayArrayType(13 downto 0) := (others => 0 ps);
tisd_DIB_CLKB : VitalDelayArrayType(31 downto 0) := (others => 0 ps);
tisd_DIPB_CLKB : VitalDelayArrayType(3 downto 0) := (others => 0 ps);
tisd_ENB_CLKB : VitalDelayType := 0 ps;
tisd_REGCEB_CLKB : VitalDelayType := 0 ps;
tisd_RSTB_CLKB : VitalDelayType := 0 ps;
tisd_WEB_CLKB : VitalDelayArrayType(3 downto 0) := (others => 0 ps);
Without building a model I't think they are likely fatal to the effort, a
matter of where the blame falls.
ADDRA (the first one) is an array signal (13 downto 0). CLKA apparently it's
clock (along with other things on the A port of the RAM). DIA is DataIn Aport
...
From going through the posts in this thread it appears the VITAL scalar timing
type expected messages were suppressed by turning off the vital checks:
ghdl -m -g -Psimprim -Wa,--32 -Wl,-m32 --warn-no-vital-generic
--no-vital-checks --ieee=synopsys -fexplicit tb_lm_cpu
where the memory leak is noted.
I created a model of bug 9597 using primsim models and found that it had
trouble with a particular SDF timing specification not being implemented.
Along the way I checked it for memory leaks and found none, and also found that
the simulation time wouldn't advance without a clock model defined and running.
The simulation never finished.
That sort of behavior can be caused by how a clock is generated at the
testbench level.
It may be worth copying your model and converting the model to use unisim
primitives which are untimed. The result would represent a gate level model
without timing.
Think of it as separating vital issues from gate level representation issues.
Depending on simprim and unisim matching it should be a matter of changing
entity (instance) names and throwing out generic maps in the copy assuming the
port declarations match. The simprim VITAL models are derived from the unisim
untimed models except for drift. Doing a difference on X_RAMB16WER.vhd and
RAMB16WER.vhd for example only shows VITAL differences.
There are a few odd delays in the unisim model, e.g.
constant SYNC_PATH_DELAY : time := 100 ps;
which are probably intended to overcome cycle order delays or in signal
assignment chains or something. The vital model appears to count on generic
timing to do the same thing.
You could also wonder if zero'ing out some of the numbers in the SDF file might
upset the model.
Once you've got a near 'zero' timed gate level model (those delays added
intrinsically to make the model operate) working you can try the vital delay
version propagating any testbench changes.
There are two possible scenarios. The memory leak could show up in both gate
level models or only show up in the vital model. If there are any problems
that show up in the (nearly) un-timed gate level model you might get closer to
any vital problems, where in you could build an mcode code converter version of
ghdl to turn on things like Dump_Flag to display what's going on in
grt-vital_annotate.adb or the like.
Another thing you can try is cranking your clocks down slower to see if there's
timing delay paths longer that you're current cycle time. (This sort of
assumes you haven't done thorough static timing analysis in ISE which might
also affect the usefulness of your sdf back annotation file).
From having looked at GNA ghdl bug 9597 just recently I know there are some
vital timing constructs used that ghdl doesn't currently handle (the recent bit
with X_BUFGMUX getting the clock setup and hold time checks going with respect
to the S select input). You could also try not annotating the SDF file. Any
delays the model needs to run should be generic defaults (not guaranteed
without checking your used simprims).
The underlying theme here is to try and separate your problems into different
categories. It also says you could attempt a serious static timing analysis in
ISE if you haven't done one already.
Someone could also bite the bullet and write a test case model for the
X_RAM16BWER model and see if it can have an SDF back annotation loaded
successfully short circuiting any effort using GHDL if it can't or modifying
the simprim model as an alternative.
_______________________________________________
Ghdl-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/ghdl-discuss
