Hi,
----- Mail original ----- > > > On Jan 14, 2012, at 11:10 PM, [email protected] wrote: [...] > > 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). I don't think there is a memory leak. VITAL simulation by ghdl isn't very efficient because there are a lot of non-sensitized processes. > 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). Warnings aren't fatal, errors are. But there is an option to disable VITAL checks. Also, VITAL implementation isn't yet complete. Tristan. > 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 > _______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
