Hi, I wouldn't modify any part of the unisim library. You may be "breaking" the code of a component by modifying sections. The generics or constants should only be applied from outside the hierarchy of the component - i.e. at its instantiation.
(Core generating software like Coregen, etc. are GUIs that take your settings to define the generics of the component being generated, then instantiate the generic component in a wrapper that defines those settings. The user then instantiates the "pre-defined" component wrapper that has the name you gave to it.) I'm not sure if the DCM is a coregen component but you could do a workaround by replacing the xilinx DCM with your own (for sim). I'm not sure about the xilinx DCM but I have seen in Altera sims where PLL clocks are simple reproductions of the reference clock - i.e. no real PLL function going on. I suspect its the same for Xilinx. Greg On Sun, Nov 8, 2009 at 2:24 PM, Dan Clemmensen <[email protected]>wrote: > Colleagues: > > I am a software professional with very liittle VHDL experience. I need > some guidance on how to debug VHDL and/or GHDL compiler issues. > > I am attempting to simulate a test driver for the DDR DRAM on the > Spartan 3E starter kit. I downloaded the old package from > http://www.xdr.com/dash/fpga/ > And modified it for Xilinx ISE 11.1 in my environment. > > I compiled and ran the project with GHDL, but the DCM did not generate > the expected 2x clock: all the DCM output clocks remained > flat. > > Further investigation shows that this was reported on the Xilinx > forum: DCM fails to lock for GHDL but locks for Modelsim, for newer > ISE versions. > > Within the Xilinx unisim DCM.vhd, the code was changed in 2008 and > there now a generic called SIM_MODE. I set SIM_MIDE="FAST" > and instead of a failure to lock, I got a GHDL runtime error. The > runtime error output is: > > ../../../src/std/textio_body.v93:1018:5:@0ms:(assertion failure): real > read failure > ./mytb:error: assertion failed > ./mytb:error: simulation failed > ghdl: compilation error > > I began using classical brute-force software debugging techniques: I > simplified the VDHL down to a single instantiation of the DCM in a > single VHDL module, with the same results, namely failure to lock with > SIM_MODE defaulted and the error with SIM_MODE="FAST" > > I made a local copy of DCM.vhd and changed the entity name: same results. > > I intend to now continue to fault isolate by simplifying DCM.vhd. > > Now for my questions: > > 1) is there a simpler way? > 2) is this a GHDL problem or a problem with the Xilinx unisim? > > > My environment is 64-bit Gentoo Linux. > > Thanks > > _______________________________________________ > 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
