Prev: Xilinx platform cable USB API?
Next: XILINX ISE PAR error: CLK0_BUFG_INST is not placed
From: Rebecca on 7 Mar 2007 17:18
Probably the EDK didn't take the changed file. I will check first and
let you know the result, Thank you for all your help.

From: WATomb on 7 Mar 2007 19:41
Well I was writing this at the same time. During builds sorry.


Hi Rebecca, 
I guess that didn't fix it sorry.
First you just said the E word oh the pain of EDK. I pray you have a
very very nice boss with deep pockets. If EDK only worked the same
way as Xilinx stated life would be great however they blame training.

Ok when I added DDR2 to my design(custom board) I also had the same
problem needed another DCM that was in ISE. Please try removing the
Global clock buffer from your DCM(ISE) output and see if that fixes
the problem. Or use the Coregen version of the DCM and see if that
fixes it. An even though you have output declared as a BUFG in Corgen
that sometimes fixes it.
Also you maybe running out of resources.
1st try this
I don't think you need this try removing it
Locked_BUFG_INST : BUFG
port map (I=>LOCKED_OUT_Buf,
O=>LOCKED_OUT);

Ok I am guessing you don't have a nice boss that gave you the
recommended computer with 16G. So have you ever used the FPGA
Editor?
Cheers, Bill

From: Daniel S. on 9 Mar 2007 07:18
You could try explicitly instantiating a BUFG/BUFGCTRL between CLK0 and CLKFB instead of
feeding dcm_0_FB back directly - the error message complains that only
BUFG/BUFGCTRL/PLL_ADV can be the source for CLKFB.

That is what I did to fix DCM synthesis warnings. Environment variables is a major
annoyance if you work on stuff on more than one PC and either forget to set them or
someone else changes them. Instantiating costs a few extra lines but after that, you'll
never have to worry about them mysteriously disappearing again.

Rebecca wrote:
> Hello, Bill:
> Thank you very much for your response.
> Buf after I set up the enviroment variable and run the route again, I
> got the same error several hours later. What can I do?
> When I set the DCM as the top file and do the implementation, the .bit
> file can be generated successfully.
> But when I put my vhdl files (include dcm3.vhd) as a uer define core
> in the EDK, I always got the above error. The system in the EDK also
> incudes a DCM. Is there something wrong as shown:
> BEGIN dcm_module
> PARAMETER INSTANCE = dcm_0
> PARAMETER HW_VER = 1.00.a
> PARAMETER C_CLK0_BUF = TRUE
> PARAMETER C_CLKDV_BUF = TRUE
> PARAMETER C_CLKDV_DIVIDE = 5.000000
> PARAMETER C_CLKIN_PERIOD = 10.000000
> PARAMETER C_CLK_FEEDBACK = 1X
> PARAMETER C_DLL_FREQUENCY_MODE = LOW
> PARAMETER C_EXT_RESET_HIGH = 1
> PORT CLKIN = dcm_clk_s
> PORT CLKDV = sys_clk_s
> PORT CLK0 = dcm_0_FB
> PORT CLKFB = dcm_0_FB
> PORT RST = net_gnd
> PORT LOCKED = dcm_0_lock
> END
>
From: Rebecca on 9 Mar 2007 15:06
Thanks for all your help.
The problem has been fixed. The reason is that EDK didn't take the
modified VHDL code. I need to remove the content in synthesis or
implementation directory ( i removed both, but probably we just remove
the content under the implementation directory).
And another thing is the EDK won't copy the files under the
directory.. user defined core....-> netlist to the implementation
directory automatically as said in the manual. I
I have to copy them manually. Probably I made another stupid mistake?
Bill, I added the BUFG for the locked signal because I found in the
Modelsim simulation, sometimes the generated clocks can't sample the
locked signal at its first rising edge but sometimes they can. I used
the following code in my program:

NextStateProc : Process(ClkX3, DCMLocked) is
begin
if(DCMLocked='0') then
CLKState <= CLK0;
elsif(rising_edge(ClkX3)) then
CLKState <= NextClkState;
end if;
end process NextStateProc;

There are other DCMs in my system to generated different clock
frequency and use such kinds of code for different states. They are
all synchronized. Although the generated clock shouldn't be able to
sample locked as high at its first rising edge because locked signal
is also synchronized with the input clock as said in the manual,
sometime they can. So I add the global buffer to solve the problem and
it worked.

Daniel said something about "instantiating costs a few extra lines but
after that, you'll
never have to worry about them mysteriously disappearing again.". I
am sorry I don't understand how to do the instantiation, so I just set
up the environment variables. Would you please talk more about that?

Again, Thanks for all your response,
Rebecca



First  |  Prev  | 
Pages: 1 2
Prev: Xilinx platform cable USB API?
Next: XILINX ISE PAR error: CLK0_BUFG_INST is not placed