cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
pierlum
Voyager
Voyager
5,101 Views
Registered: ‎05-30-2017

LDCE and ILOGIC2 very strange problem

Jump to solution

Making some test I found a strange problem. I have a 16-bit bus as inout. Each bit of the bus go through an IOBUF and then in a IODELAY2 that I connect to ILOGIC2 with DATAOUT output. If all ILOGIC2 block are realized using a LATCH-D (using FDCE, FPCE, MUX, etc)  design cant't route. If 13 or less ILOGIC2 are realized with a D-LATCH and 3 or more ILOGIC are realized with a IDDR2 design can route without any problem and PAR is ok. This problem remain also if I remove the ucf file from the project and if I create a little project having only this bus as input to test this problem. What could be the mistake, someone has never had experience in this? Searching in documentation I can find nothing about this. Thank you. 

0 Kudos
1 Solution

Accepted Solutions
eilert
Teacher
Teacher
7,443 Views
Registered: ‎08-14-2007

Hi,

my sugestion would be the following.

Instead of the LDCE primitive use a IDDR2 primitive.

 

 

genvar   X; 
 generate
    for (X=0; X < BUSSIZE ; X=X+1) begin : IBUF_bus_x
	 assign O[X]=OBu[X];
	
   IODELAY2 #(    ...all the parameters)
      IODELAY2_sp6 (..all the pins);

     IDDR2 #(    ...all the parameters)
      LDCE_REPLACEMENT_sp6 (..all the pins);
	
    end
 endgenerate  

Of course you will only use one Clock of the DDR2 and tie the other to GND, so the DDR2 works as a simple D-FF.

Maybe your design can work with a FF too. Then you are done.

If you really really need a latch there (why?) you could afterwards change the behavior of the Input-FF either by some TCL script or manually inside the FPGA editor.

 

But the problem with the mapping and placement should vanish, since IDDR2 can only appear in ILOGIC cells.

 

Have a nice synthesis

  Eilert

 

 

 

 

View solution in original post

13 Replies
pierlum
Voyager
Voyager
5,087 Views
Registered: ‎05-30-2017

I discovered another very strange thing. If I increment the bus size to 20 instantiating other 4 IBUF. Then 16 IBUF output go trough a D-LATCH in a ILGIC2 e 4 IBUF output are trimmed during mapping in this PAR is OK. So I can do what I want only if I instantiate 4 dummy IBUF. I work with spartan-6 XC6SLX150T-FGG900 and ISE 14.7.

0 Kudos
eilert
Teacher
Teacher
5,027 Views
Registered: ‎08-14-2007

Hi pierlum,

maybe you can provide some code example and the reports that you got for these examples.

Having a design with wide bidirectional busses is not a rare thing.

e.g. You find this whereever DDR-Ram is connected to the FPGA.

So your routing problems must have a special cause, which can only bee seen by inspecting the code.

Maybe you need some special property settings for the toolchain.

 

Have a nice synthesis

  Eilert

 

 

pierlum
Voyager
Voyager
5,024 Views
Registered: ‎05-30-2017

Thanks for the reply. Continuing to investigate the problem I discovered a strange thing looking at the netlist with fpga editor. The flow for the inout pins of the bus is correct except for the bit 6,7 8 e 9. Looking at the .ncd starting from MPD_B[6] (but also 7,8 or 9) the input go correctly from pin MPD_B[6] to IODELA2 but from the output DATAOUT of IODELAY2 it doesn't go to the adjacent block ILOGIC2 where there is the latch as described in my verilog code but in far OLOGIC2 block and for this cause the routing is not possible. Also with manual routing this connection it's impossible to establish. I attached .ncd and the .pcf files. However the problem is indipendent from the assignment because also without .ucf don't routes.

0 Kudos
pierlum
Voyager
Voyager
5,019 Views
Registered: ‎05-30-2017

@eilert

If it is useful I can attach also the code but the flow is the same for all the 16 inout pin so I think this a bug in the mapping process.

0 Kudos
pierlum
Voyager
Voyager
5,017 Views
Registered: ‎05-30-2017

@eilert I attached the .zip of the project and the .v. This is a test project created to work on this problem. In the .v if you change the parameter BUSSIZE from to 16 to 20 you can see that the project route.

0 Kudos
pierlum
Voyager
Voyager
4,979 Views
Registered: ‎05-30-2017

During the instantiation of the 16 latches using genvar I inserted if(X==6) (* LOC = "ILOGIC_X11Y2"*). IN this way I force ISE to map the latch in a ILOGIC and not in OLOGIC as automatically and erroneously ISE does. The only explenation is that this is an IS bug. What do you think? Thank you.

0 Kudos
eilert
Teacher
Teacher
4,975 Views
Registered: ‎08-14-2007

Hi,

your analysis is correct. I came to the same result.

 

In your code you are instantiating generic LCDE latches.

The tool seems to absorb them into ti I/O logic by random choice.

So some are placed into unroutable locations.

Maybe you could instantiate dedicated input latches in the same generate loop as the input delay blocks.

That should give the best result.

 

I changed some synthesis properties and got the design routed:

       Pack I/O Registers into IOBs - NO

 

However, this will probably affect the timing in a bad way.

 

The first mentioned way should work, but you need to change your code.

 

 Hope it works as expected.

 

Have a nice synthesis

 Eilert

 

pierlum
Voyager
Voyager
4,977 Views
Registered: ‎05-30-2017

Thank you very much for the time that you spent for me! In my original project the instantiation of latches and delay blocks is in the same loop but the problem still remain. I made two different loops for testing purpose. It's interesting that changing Pack I/O Registers into IOBs to NO allow the design to be routed. This convince me that this error it's a bug of MAP and under certain condition occurs and only with a constraint is possible to workaround it. What do you think? I attached the project with the constraint for ILOGIC  

0 Kudos
pierlum
Voyager
Voyager
4,969 Views
Registered: ‎05-30-2017

@eilert In this test project I tried to constraint only latch 6 and in this way I solved the problem for other three latches (7,8 and 9). In the original and bigger project constrain only latch 6 doesn't work so I tried to constraint all the latches and now I'm waiting the end of implementation to see if in this way PAR is ok. 

0 Kudos
eilert
Teacher
Teacher
7,444 Views
Registered: ‎08-14-2007

Hi,

my sugestion would be the following.

Instead of the LDCE primitive use a IDDR2 primitive.

 

 

genvar   X; 
 generate
    for (X=0; X < BUSSIZE ; X=X+1) begin : IBUF_bus_x
	 assign O[X]=OBu[X];
	
   IODELAY2 #(    ...all the parameters)
      IODELAY2_sp6 (..all the pins);

     IDDR2 #(    ...all the parameters)
      LDCE_REPLACEMENT_sp6 (..all the pins);
	
    end
 endgenerate  

Of course you will only use one Clock of the DDR2 and tie the other to GND, so the DDR2 works as a simple D-FF.

Maybe your design can work with a FF too. Then you are done.

If you really really need a latch there (why?) you could afterwards change the behavior of the Input-FF either by some TCL script or manually inside the FPGA editor.

 

But the problem with the mapping and placement should vanish, since IDDR2 can only appear in ILOGIC cells.

 

Have a nice synthesis

  Eilert

 

 

 

 

View solution in original post

pierlum
Voyager
Voyager
3,841 Views
Registered: ‎05-30-2017

@eilert

Probabily the best solution would be to re-write my code using an IDDR2 and not FDCE. I could also turn off Pack I/O Registers into IOBs. In my project I strictly control the flow of input and output data instantiating IBUF, OBUF, etc explicitly and so I don't think that this impact timing. Constraining ILOGIC doesn't work well. If I constrain more than one LDCE in the corrisponding ILOGIC it appears reading the console that the constarins are correct but then looking at the fpga editor it seems that the constrains are ignored. 

0 Kudos
pierlum
Voyager
Voyager
3,810 Views
Registered: ‎05-30-2017

I solved the problem. Not only latches but also D flip-flops are present in ILOGIC2, OLOGIC2 and SLICE and so this ambiguity is a problem for ISE during mapping. Constraining all the input latches and input flip-flops I solved the problem. There is another related strange thing that I noticed. In my project I have a LATCH as ILOGIC2 resource and the output of the LATCH goes to a FFD clocked with the inverted gate signal of the latch. This FFD is outside the ILOGIC2. But if I disconnect (floating) the gate of the latch, for an erroneous optimization process ISE trims the LATCH and packet the FFD in ILOGIC2 and this prevents routing. In this particular condition if I constrain the FFD with (* IOB = "FALSE" *) map fails because ISE would put FFD in ILOGIC2 but the constraint prevents this. Using a latch that has gate unconnected is not correct and is not what I want to do but I think that is useful to report this bug.

0 Kudos
pierlum
Voyager
Voyager
3,809 Views
Registered: ‎05-30-2017

@eilert,

I solved the problem the problem in another way but your suggested workarounds are valid solutions to solve my problem. Thank you very much for the help!

0 Kudos