Thanks, Greg. I do not intend to modify the actual unisim library (except of course for the modifications needed to get GHDL to compile at all.) I copied DCM.vhd into my working directory and then began changing it, solely to use to debug the GHDL/DCM interaction. I do not intend to use this copy with the Xilinx toolchain at all.
DCM.vhd is 2700 lines of VHDL, It is more than 1700 lines after the initial simplifications, but the bug is still there. So far, I am concentrating on the SIM_MODE = "SAFE", since the problem in the other path (SIM_MODE="FAST") is clearly associated with some sort of console input. for the "SAFE" path, the problem is now isolated to the actual connection of the internal signals to the port signals. GHDL shows that the internal signal (e.g., clk2x_out_o) is switching correctly, but the port (e.g., clk2x) is not, even when the only reference to clk2x in the whole module is the line clk2x<=clk2x_out_o; as the first line after the "begin" in the architecture. A trivial analysis would say that something in the structure of the file is confusing GHDL. On Sun, Nov 8, 2009 at 5:18 PM, Greg Beaton <jgbea...@gmail.com> wrote: > 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 <danclemmen...@gmail.com> > 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 >> Ghdl-discuss@gna.org >> https://mail.gna.org/listinfo/ghdl-discuss > > > _______________________________________________ > Ghdl-discuss mailing list > Ghdl-discuss@gna.org > https://mail.gna.org/listinfo/ghdl-discuss > > _______________________________________________ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
