1. Home
  2. Field-Programmable Gate Arrays
  3. Synthesizer is creating unwanted global resources

Synthesizer is creating unwanted global resources

Hello all, I was experimenting a design with V4 lx60. Synthesizer is synplify 8.0 and xilinx ISE7.1 for PAR. Two clocks to the design clk and ckl4x. But in the pacakage pin assignment tool lot of signals are listed under the global resource. Locked clk and clk4x to global clk IO. But at the maping stage the MAP is telling to LOCK the clock resources which i think is this extra created global signals. Why the synthesizer is creating extra signals which behaves like clocks. Also if i apply a timing constrain to the internal signal this problem will not be there at the mapping stage. But the PAR will never complete. After about 6 hrs work it says that the design is unroutable. Is this because of this extra global signals. But if i use lx200 instead lx60 there is no problem in the above two step and MAP and PAR completes successfully. How can i eliminate creation of such global clocks by synthsizer. regards Sumesh V S

Reply to
vssumesh
Loading thread data ...

Not using the global clock resources wastes gates and makes it very difficult to meet hold requirements. That's why your constrained design won't route. Check the utilization and static timing reports and look at the rtl viewer. Consider a single clock design.

-- Mike Treseler

Reply to
Mike Treseler

I am using global resources for two clocks. But dont want global resource for newly created signals which PAR considers as clocks. Looked at the warning messages in the map stage it reports that "Clock net -Signal Name- is sourced by combinatorial logic. This is not a good design. try to use CE of FFs......" But the referred signal is actually a gate signal to latch(LD). Why this gate signals are treated as clock nets. And from the device utilisation summary its found that 100% of the 32 BUFGs and all the DCM are used though i am using only two clocks. I strongly belive that the increased clock nets is causing problem with PAR. Also there is lot of other latches in my design but those enables are not treated as clock nets. Is there any way to force the PAR to consider these signlas as ordinary signals. Please suggest me way out. Thanks and regards Sumesh V S

Reply to
vssumesh

To reduce skew.

Eliminate the latches from your design to solve the problem.

-- Mike Treseler

Reply to
Mike Treseler

And how can we eliminate taking enable as clock signals.

And to eliminate latches is not possible as it is part of the design....

Reply to
vssumesh

Why the PAR is showing unroutable design..... why it is not giving output with a large delay.....

Reply to
vssumesh

I suggest you step back and re-implement your design in a more conventional fashion. Unless you do something very unconventional or extremely fast, there is no need for using latches. Try to build your design with fli-flops and one common clock, or perhaps with a few, but be aware of the difficulties and dangers of multiple clocks. Peter Alfke, Xilinx Applications

Reply to
Peter Alfke

Mine is actually a demux. A 8 bit data goes to any of the 256 locations. Thus a statement like below will create latch. reg [256*8-1:0] out; out[ind*8+7:ind*8] = in; this can be converted to FFs by following statement

always@ (posedge clk4x) out1[ind1*8+7:ind1*8] = in1;

clk4x because to reduce size i am using TD multiplexing. The output goes to another FF which latches on the +ve edge of the clk. so how this can be possible. I think i have to phase shift the clk4x advance it wrt to the clk by a small amount. These are my problems in using FFs.

I tried the FF type (not given important to functionality). But found that that design is also not routing. The LUT is 88% FF is 33% Slice is

96%. Now only 20 or less latches in the design ( most of then are part of the complicated case statements). If that too is also a problem will avoid that. regards Sumesh V S
Reply to
vssumesh

One main doubt, why assign out = in[ind]; is possible but assign out[ind] = in; is not possible Because of this i think demuxing can only be done with FFs or latches created in a behavioural code. Or is there any other method ???? but always @(*) out[ind] = in; is creating all the logic needed for the demuxing only the storage is to be avoided How can we extract the combinatorial logic part?

Reply to
vssumesh

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.