Hi David, thanks for the detailed echo. I wasn't very precise about the illegal values - they're way above 9, it really is garbage, and I haven't figured out where it came from. Unfortunately my gdb can't seem to go further into the GNAT internals the verbose way, I guess this would need some extensive analysis (hopefully not down to assembly). One thing I can tell though, that the variable is previously assigned to something legal. Some memory trashing is happening on the way to that specific procedure.
So the main question is: Can bad VHDL code cause internal garbage? Looks like a buffer overflow effect, but I couldn't detect that anywhere. More comments below: > > I didn't follow your regime exactly and didn't get these warnings and errors. > > > All the 32 bit buses were always zero, the clk was running the model was > introducing stimulus from the looks of things, but it was running. > > david-koontz-VirtualBox:/mnt/share/fptest% !so > source script > fptop.vhd:120:1:warning: component instance "my_test" is not bound > fptop.vhd:51:14:warning: (in default configuration of fptop(behavioral)) > ./fp_tb:info: simulation stopped by --stop-time > When you're not binding my_test, the critical code won't be entered, so can't crash. Right? I don't understand why my_test is not bound though. Maybe put a --std=93c flag in the ghdl -m build rule. > The warnings were due to the architecture not being specified. The > simulation stopped after 10 usec. > > I didn't have access to the ISE 11.1 you used, and with a bandwidth cap and > having just downloaded 13.2, I'm not inclined to download another version > just to get the XilinxCoreLib and Unisim libraries sources to match yours. > I'd consider the modifications I made to the iteration schemes to be less > than ideal, and I'd search for something that told me the changes were > necessary. That the Xilinx source has a few of these makes you wonder who's > right. > Don't bother with v11, I am soon going to have to upgrade anyhow. Maybe the problem then disappears. If you still would like to try reconstructing this crash, I can also pack the relevant libraries into a .tgz and put them somewhere. Let me know. > I can't help but wonder what's going on in your IEEE libraries (or ghdl) that > you were getting those warnings and error, but have no visibility into the > problem from here. I also couldn't elaborate with an mcode version and > couldn't successfully use ieee=synopsys when analyzing > floating_point_v4_0_xst_comp.vhd: > I guess it's not in the ieee libs, so much I can tell from the GDB tracing. But then again, no proof that there are some unknown side effects.. Here my version info: GHDL 0.29 (20100109) [Sokcho edition] Compiled with GNAT Version: 4.4.3 About the std_logic_arith: I am aware of those issues, but I don't get around it when importing the Xilinx code. And there's no way to rewrite all that with numeric_std functions (moreover, Xilinx would not like their code to be altered, let aside redistributing it). Greetings, - Martin _______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
