FPGA can determine which gate is to be used?

[carpenter]

The specific design need to be able to combine well-defined blocks in the FPGA.
It is possible in VHDL (Spartan 3A) to determine which block and gate to use?
More precisely.
I need to connect two LUTs from CLB1 with LUT and XORCY from CBL2
as the case may be
LUT+LUT+XORCPY from CBL3 with LUT from CLB4

How?

 

[TrickyDicky]

I dont think you can do it directly with VHDL, you would probably have to do it with assignments.
Is there any reason you want to do the fitters job manually?

 

[carpenter]

This is simple I need two circuit with little different timing.
More precisely, I need two ring oscillator see picture.
I thing , in Spartan 3 this will be fast oscillator roughly 30-40ps quick as slow oscillator.

 

[mrflibble]

You can use RLOC ( or LOC) and BEL constraints to influence placement of your LUTs and such. Check out the xilinx constraint guide for the details.

Quick version in verilog:

(* RLOC = "X0Y0", BEL ="F" *)
LUT4 #(
.INIT(16’h0000) // Specify LUT Contents
) LUT4_A(
.O(O), // LUT general output
.I0(I0), // LUT input
.I1(I1), // LUT input
.I2(I2), // LUT input
.I3(I3) // LUT input
);



(* RLOC = "X0Y0", BEL ="G" *)
LUT4 #(
.INIT(16’h0000) // Specify LUT Contents
) LUT4_A(
.O(O), // LUT general output
.I0(I0), // LUT input
.I1(I1), // LUT input
.I2(I2), // LUT input
.I3(I3) // LUT input
);





(* RLOC = "X4Y0", BEL ="F" *)
LUT4 #(
.INIT(16’h0000) // Specify LUT Contents
) LUT4_C(
.O(O), // LUT general output
.I0(I0), // LUT input
.I1(I1), // LUT input
.I2(I2), // LUT input
.I3(I3) // LUT input
);



(* RLOC = "X4Y0", BEL ="G" *)
LUT4 #(
.INIT(16’h0000) // Specify LUT Contents
) LUT4_D(
.O(O), // LUT general output
.I0(I0), // LUT input
.I1(I1), // LUT input
.I2(I2), // LUT input
.I3(I3) // LUT input
);

This is 4 luts in two slices. They are explicitely placed in the F and G LUTs with the BEL constraint. The RLOC is for relative placement in the slices. You can use fpga editor or planahead to see what gets placed where.

Constraints guide here: https://www.xilinx.com/support/documentation/sw_manuals/xilinx13_4/cgd.pdf


On ring oscillators: you may just want a couple more elements (more inversions). Also, you can do the inversions just using LUTs, so no particular need for the XORCYs. So I'd just use LUTs to keep things simple. Unless ofcourse the XORCYs are an important part of you cunning plan...

 

[carpenter]

First of all thank you.
Cunning plan, it's hard to say. My plan is to get the two oscillators, with minimal difference in speed and use them to measure time more accurately than the time base clock.
I believe that the above oscillators will be the difference in the period of the order of 40ps in Spartan 3

 

[mrflibble]

Heh, was suspecting it might go in that direction.

I believe that the above oscillators will be the difference in the period of the order of 40ps in Spartan 3

A 40 ps difference can be done on spartan 3 yeah. You'll need some proper constraints to actually attain that figure though. If you don't make it configurable or add feedback you'll have to experiment a bit to get the right placement. You'll want them in the same general area on the die, AND you don't want too much fast logic in the neighbourhood.

Also, while experimenting it doesn't hurt to scribble down current temperature + voltage rails every now and then. Just saying.

 

[carpenter]

it is a highly experimental design
I saw something similar in Vertex 4 and oscillators have time difference 27ps, 32ps in the Spartan3 XC3S200FT256
I want to try the Spartan 3A, see what the temperature stability and repeatability

 

[mrflibble]

it is a highly experimental design
I saw something similar in Vertex 4 and oscillators have time difference 27ps, 32ps in the Spartan3 XC3S200FT256
I want to try the Spartan 3A, see what the temperature stability and repeatability

Short term stability over temperature and voltage will be reasonable, provided you put the 2 oscillators in neighbouring slices. Oscillator stability will be crap (not-so-good Allan deviation), but that's not something to worry about right now. I'm assuming you'll start/stop the ring oscillators based on some triggering event, and possibly XOR clocks + do some counters. After all, that's always popular when doing < 100 ps timing resolution things on fpga.