Hallo Tristian, only a suggestion to improve the information at the output.
I have got also some outputs length of value does not match length or bounce not correct or similary. The errors was correct. Only the information are not informative enough. ISE output is more information. left is type of.......... and right is type of......... Rene Tristan Gingold schrieb: > On Mon, Nov 09, 2009 at 08:25:03AM -0500, Dan Clemmensen wrote: > >> Thanks, Tristan. >> I found the problem, and of course it is both obvious and trivial -- >> in retrospect. >> >> The problem is that the port-signal clk2x is defined in unisim DCM.vhd >> as a std_ulogic, but my test bench, which derived from the old oc_ddr >> project, connected this port to a signal tclock defined as std_logic. >> Apparently, the DCM definition changed some time during the last two >> years. to fix it, I simply changed tclock to std_ulogic. >> > > Great. That's a good news. > > >> I did find this by brute-force simplification, so the effort was not >> wasted, but this is a very inefficient debugging technique. I will >> study the --trace-signals and --disp-time options. In retrospect, what >> is need is a way to ask GHDL "what are the inputs to signal X at time >> Y?" However, until I learn some more VHDL, my guess is that I will not >> really understand the answer. >> > > --trace-signals should answer to this question, but I agree that this is > not particularly user-friendly. > > Tristan. > > >> In this instance, (apparently) the input >> is some sort of underlying attribute of any signal defined as >> std_logic. For those adept at VHDL, a connection of a std_logic to a >> std_ulogic is probably as easy to understand as adding an integer to a >> float in C, but it is very subtle to a newcomer. >> >> >> On Mon, Nov 9, 2009 at 12:23 AM, Tristan Gingold <[email protected]> wrote: >> >>> On Sun, Nov 08, 2009 at 08:54:31PM -0500, Dan Clemmensen wrote: >>> >>>> 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. >>>> >>> Hi, >>> >>> there are some debug options that may help you (--trace-signals, >>> --disp-time). >>> You can also send me the simplified design and I can investigate. >>> >>> Tristan. >>> >>> _______________________________________________ >>> 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 >> > > _______________________________________________ > 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
