02-03-2012 05:11 AM - edited 02-03-2012 06:30 AM
I am using spartan3 xc3s5000 in my design. How can I stop xilinx ISE from routing my clock to BUFGMUX? what's happening is that when I instantiate a core of chipscope in my design, xilinx routes the clock to BUFGMUX. The clock is a direct output of DCM and the clock is also driving other modules.
Also, xilinx routes my two other internal signals to BUFGMUX as well. How can I tell xilinx not to do it and route the signals using local routing?
Here's my clock report:
|Clock Net||Routed||Resource||Locked||Fanout||Net Skew(ns)||Max Delay(ns)|
As you can see in this report control0<0> is routed to BUFGMUX6, also my two internal signals last_round_done1 & 2, I want to use these resources for other purposes but this thing is not allowing me to do so.
-- Hassan --
02-03-2012 07:42 AM - edited 02-03-2012 07:43 AM
what's happening is that when I instantiate a core of chipscope in my design, xilinx routes the clock to BUFGMUX. The clock is a direct output of DCM and the clock is also driving other modules.
A BUFGMUX is a global clock buffer. When it is being used as a simple clock buffer -- instead of being used as a clock mux + buffer -- it is usually called (simply) BUFG.
The global clock buffer ensures that clock skew is essentially zero across the enture FPGA. If a clock is distributed in "local routing", clock skews are almost guaranteed to cause even a very small design to fail. Remember, skew will cause design failure at ANY clock frequency.
Is XST buffering non-clock signals with clock distribution buffers? If so, this is unusual. Would you be willing to post your code for a quick second-opinon type check?
-- Bob Elkind
02-05-2012 01:53 AM - edited 02-05-2012 01:55 AM
here's the code snippet , the reported signal is in encryption core and decryption core.
the signals last_round_done1 in clock report refers to the aes_last_round_done_key2 in encryption core and
the signals last_round_done2 refers to the aes_last_round_done_key2 in decryption core
always @(posedge mclk or posedge reset)
if (reset) aes_last_round_done_key2 <= 1'b0;
else aes_last_round_done_key2 <= aes_last_round_done;
assign aes_last_round_done = (aes_round == 4'hb) &&
1- aes_round is a counter counting on the basis of state machine.
2- msm_start_9th_AES_round is the signal generated on the basis of state machine.
I don't know if this code will be of any help, I don't see any point of XST routing it to BUFGMUX.
02-05-2012 02:02 AM - edited 02-05-2012 02:04 AM
Also, regarding the chipscope instantiation thing, the mclk_50Mhz signal in the clock report is the output of my DCM. Here's how we have floorplanned the signals:
mclk -> GCLK
mclk goes to DCM.
mclk_50Mhz is the output of DCM, so it is going to a BUFGMUX, that i understand.
mclk_50Mhz is used in the entire FPGA, and it is already buffered, then why would it rebuf the signal for chipscope core only? Am I missing something here ?
Because when I comment the chipscope core and then run P&R, the clock report doesn't show control0<0> in the clock report so my BUFGMUX is available for use.
08-23-2012 11:04 AM
please start a new thread.
-- Bob Elkind
08-23-2012 11:23 AM
How to start a new thread?
Navigate to the forum in which you want to post your thread. Then click on the "new message" button.
-- Bob Elkind