Basys 3 implemented design

[Chirag]

I have implemented a design based on microblaze in Basys 3. I have the implemented design and it is attached here. I don't know how to interpret the implemented design.

1. What are the six big squares?

2. Where are the LUTs located in this FPGA layout?

3. What are I/O Banks and how can I use them ? (Some cells on the edges are named I/O Banks) 

4. Can I change locations of the placed cells manually after implementation? 

Can someone please answer my above queries? Thanks!

[D@n]

@Chirag,

What you are looking at is an image of the underlying silicon die within the chip, showing the layout of the various parts physically.

1. The six big squares are clock regions IIRC.  You can save some power and some wires if you can restrict a clock to a given region.  That said, I tend to run all my designs with one giant system clock, so this hasn't helped me much.
2. In your example above, the LUTs being used are in the middle row and colored light blue.  There's more there than just LUTs, but that's where the LUTs are.  What more is there?  I can't be certain, but examples might be memory and DSP slices.  If you zoom in on this area you'll see sub-pictures showing four LUTs to a slice, the FFs in the slice, and possibly the various mux-7 and mux-8 components as well.  (It's been a while since I've done so)
3. The I/O banks are all on the edges of the design.  You can use them via the various IBUF, OBUF, IOBUF, IDDR, ODDR, ISERDESE, OSERDESE, etc. primitives.  A wire going to or from an I/O port will naturally use one of these, or they can be manually instantiated as well for more control of what takes place.
4. Yes, you can change cell locations manually, but knowing what you are doing enough to be successful doing so can be a real challenge.  I know some folks who have hand placed their designs to great effect.  I also know of at least one open source project to do the same.  Indeed, at one time I tried to build a placer to map logic to FPGA elements--my efforts didn't work out so well.  That said, I know my own limits and don't try to move components around myself.

Dan

[Chirag]

@D@n,

Thanks for your reply. I have few follow up questions - 

1. Can you share some resources/tutorials on how and why to use the primitives.

2. I see an option to enable use of DSPs in the design while synthesizing. Is that the option to select to use DSPs? How can I force the implementation engine to use DSP slices to synthesize particular logic in my design?

Thanks,

Chirag

[D@n]

@Chirag,

I currently only have one digital design tutorial.  (Digilent has more.)  It does not go into "how and why to use the (Xilinx) primitives".  The problem with using the Xilinx primitives (if you don't need them) is that it renders your logic specific to a Xilinx device, so if you ever switch to either a Lattice, Intel, or an ASIC design flow, or even an open source simulator, you'd need to start over with a new set of primitives.  The more you can do without them--the better.  That said, I do use vendor specific IO primitives--especially when I need high speed I/Os.

As for enabling DSPs in your design, I'd recommend using a programming construct (from Verilog) that looks like:

always @(posedge clk)
if (enable)
    result <= ina * inb;

Anything more than this may not necessarily map to a DSP.  I'd also strongly discourage you from directly instantiating the DSP primitive: the interface isn't necessarily obvious, and the number of options are ... too numerous and confusing (IMHO).  If you can instantiate the DSP by a simple statement, like the one above, your code will be easier to read and it will likely work with other tool chains as well.

Dan

[xc6lx45]

one hint: You can zoom in (I think it's the middle mouse wheel) and at some level the primitives become visible.

You'll see that for a small design the utilization is very sparse so the picture does not give a good visual indication of used resources (use the design report).

Using inference (via the "*" operator) is generally a good idea. Read the tool output / warnings, it'll tell you a lot about what happens internally. The DSP48 is happiest if there are a few registers in the path so it can absorb them into the DSP48's internal hardware registers. This matters if you intend to go beyond maybe 100 MHz, give or take some.

The same applies to BRAM, "inference" works pretty well and it's time well spent to figure out how it works.