I thought of that. In the origional code, the instantiation connects clk2x to a signal named tclock, which in turn is connected to clk_fb and to nothing else. Just in case, I broke the connection from tclock to clk_fb, so clk2x is in effect connected to nothing externally. My "project" is now stripped down to a single VHDL file named mytb.vhd, plus the copied and stripped version of DCM.vhd, but it still exhibits the problem.
This leads back to the original question: how do I debug this? I don't know ADA or VHDL very well, but I do know the GCC tools and their internals. On Sun, Nov 8, 2009 at 6:45 PM, Greg Beaton <jgbea...@gmail.com> wrote: > Yeah, that looks like a bug unless something is driving clk2x externally? > > On Sun, Nov 8, 2009 at 6:33 PM, Dan Clemmensen <danclemmen...@gmail.com> > wrote: >> >> 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 > > > _______________________________________________ > 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
