On Jan 14, 2012, at 11:10 PM, tging...@free.fr 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 Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss