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
