Virtex® Family FPGAs

[luklem]

Hello,

I've written a driver that is able to read-back FPGA registers via the ICAP interface. I've been searching through the datasheets but I can't figure out the direct relation between the FAR register and the location naming used in Plan Ahead.

The questions I currently have are;

 - Is my assumption correct that the Virtex6-240 FPGA has a TOP and a BOTTOM with each 3 HClkRow rows? 

 - Is my assumption correct that SLICE_X0Y[239 - 220] is the first MajorFrame and SLICE_X0Y220 is the first MinorFrame, SLICE_X0Y221 is the second MinorFrame? This would mean there are approx. 39 MinorFrames and +/-90 MajorFrames.

 - Is my assumption correct that every block in PlanAhead (e.g. SLICE_X0Y220, RAMB18_X0Y95, RAMB18_X0Y95, etc. ) is a single Frame and therefor also a single Configuration Word (32-bits)?

 - If I want to read the entire FPGA in single frame reads, what is the best way to increment the FAR address every read? 

Thank you in advance!

Luke

FYI: The command sequence I'm using for a single frame read-back in Linux is;

    0xffffffff    // Packet::Dummy,
    0xaa995566    // Packet::Sync,
    0x20000000    // Packet::Noop,
    0x20000000    // Packet::Noop,
    0x30008001    // ( ( 1 << 29 ) | ( 4 << 13 ) | ( 2 << 27 ) | 1 ),
    0x00000007    // Packet::Rcrc,
    0x20000000    // Packet::Noop,
    0x20000000    // Packet::Noop,
    0x30008001    // ( ( 1 << 29 ) | ( 4 << 13 ) | ( 2 << 27 ) | 1 ),
    0x00000004    // Packet::Rcfg,
    0x20000000    // Packet::Noop,
    0x20000000    // Packet::Noop,
    0x20000000    // Packet::Noop,
    0x30002001    // ( ( 1 << 29 ) | ( 1 << 13 ) | ( 2 << 27 ) | 1 ), 
    0xXXXXXXXX    // Set FAR register  ( ( Block << 21 ) | ( Top << 20 ) | ( HClkRow << 15 ) | ( MajorFrame << 7 ) | ( MinorFrame << 0 ) ),
    0x280060A2    // Frame-size ( ( 1 << 29 ) | ( 3 << 13 ) | (1 << 27 ) | 162 ), // 162 = 2305584 / 28464 * 2
    0x20000000    // Packet::Noop,
    0x20000000    // Packet::Noop,

[chenweit]

I assume you're referring to 6VLX240T and allow me to get the term right so we're on the same ground. A configuration frame for V6 is 81 words. Each word is 32 bits. A column, such as CLB, DSP, GT, etc can be made up of different number of frames. Frame address is made up of 32 bits with 6:0 specifying the minor addr, 14:7 targeting column, 19:15 row, 20 Top/Bot, 23:21 block type.

With that said, let me address the questions.

-6VLX240T is made up of 6 rows. Open any design with planahead and the left-most upper center region is where FAR starts.

-A frame is the length of a clock region. Again, check planahead to see how many slices/bram/dsp is included. Note that each column can be composed of different number of minor frames.

-If you want to readback the entire FPGA, start FAR at 0x0000 0000 and specify enough words to cover all block type 0 + overhead frames + 1 dummy frame (first readback frame is dummy) [+ 1 extra dummy word if you're in x8 bus width interface] For LX240T, 21,564 words (double check on that please) will include all dummy words. You can dump the first and last frame as dummy.

-For commands, please check the configuration user guide for V6. Xilinx.com -> documenetation link on top -> follow the flow.

-If you want to readback 1 frame at a time, you'll have to call out each FAR. Much more involved. You can get the FA by creating a dummy design and use bitgen's debug bitstream option for it to dump each fa for you. Use grep to get your list. Again, remember that you'll have to read 2 frames at a minimum with first one being dummy. And note that with this method, you'll get the two dummy frames at the end of row.

[luklem]

Hello,

Thank you for your quick response!

I assume you're referring to 6VLX240T and allow me to get the term right so we're on the same ground.

This is correct.

A configuration frame for V6 is 81 words. Each word is 32 bits. A column, such as CLB, DSP, GT, etc can be made up of different number of frames.

A column stretches from top to bottom of a clock region. There are 2 * 6 = 12 clock regions in my FPGA. A column is then for example SLICE_X0Y239 - SLICE_X0Y220 and RAMB36_X0Y47 - RAMB36_X0Y44.

- How does the frame numbering match the location in de column? 

Frame address is made up of 32 bits with 6:0 specifying the minor addr, 14:7 targeting column, 19:15 row, 20 Top/Bot, 23:21 block type.

Yes, I'm aware of this. This is also implemented in my read-back function. 

-6VLX240T is made up of 6 rows. Open any design with planahead and the left-most upper center region is where FAR starts.

Is that the location I've added to the picture attached to this posting?

-A frame is the length of a clock region. Again, check planahead to see how many slices/bram/dsp is included. Note that each column can be composed of different number of minor frames.

Does this mean that the Column Number is the major frame and inside the SLICE or DSP or BRAM there is a MinorFrame? Or are the rows inside the clock regions the minor frames? For the slices there are 239-220=19 rows inside the clock region. 

-If you want to readback the entire FPGA, start FAR at 0x0000 0000 and specify enough words to cover all block type 0 + overhead frames + 1 dummy frame (first readback frame is dummy) [+ 1 extra dummy word if you're in x8 bus width interface] For LX240T, 21,564 words (double check on that please) will include all dummy words. You can dump the first and last frame as dummy.

Yes I  was aware of these dummy frames. I thought it where 147600 configuration words but I'll recalculate that. 

-For commands, please check the configuration user guide for V6. Xilinx.com -> documenetation link on top -> follow the flow.

Yeah that is where I've copied the commands from. I just have difficulties relating the single frame read to the Plan Ahead floorplan. 

-If you want to readback 1 frame at a time, you'll have to call out each FAR. Much more involved. You can get the FA by creating a dummy design and use bitgen's debug bitstream option for it to dump each fa for you. Use grep to get your list.

I don't think I understand what you are stating here? You mean the bitgen allocation files generated with -g readback? rba, rbb, rbd and msd? What should I grep in these files?

Again, remember that you'll have to read 2 frames at a minimum with first one being dummy. And note that with this method, you'll get the two dummy frames at the end of row.

Every read in the column should consist of 2 words at minimum and the bottom of the column 4 works with the second word containing relevant information.

Thank you!

Luke

[chenweit]

Luke,

Example, FAR 0x0000 0000 is a IOB column since it's the left most column. Since it's IOB column, you have 44 frames there, so the far covering the IOB column is 0x0000 0000 to 0x0000 002B. Then you move on to CLB column, SLICE_X0Y120 to SLICE_X1Y159, where you have 36 frams per column (FAR 0x0000 0080 to 0x0000 00A3). Next you have another CLB column and you start with FAR 0x0000 0100 (which mapps to major addr 2). And yes, most of your CLB column frames cover routing config. Hopefully by now you understand clock region height and can derive what's resources are in a column for CLB/DSP/BRAM/etc.

21,564 is frame count. It's a mistype by me. x32 to get wd.

bitgen -b -g debugbitstream:yes

-b gets you rbt file

-g debugbitstream gets you frame address after "00000000000000000000000100000000"

grep for it and you have all your FAR.

One correction from my last post, does seem that bitgen will not print the dummy frame addr, so if you use the above method to grep your FA, you'll get all the FA without the dummy.

Suppose you want to read FAR 0x0000 0000, you have to read 81x2 words (2 frames). First frame is dummy, while second is the real data. If you are absolutely pressed for time, you skip then to 0x0000 0002 after that read since now the dummy for 0x0000 0002 is actually 0x0000 0001. This is due to the pipeline nature of config.

What you're trying to do is rather involving, and it may be a good idea to open a tech support case for full follow up.

Regards,

Wei

[luklem]

Hello Wei,

Thank you very much for your time. I've taken your remarks into account and I thought I'd managed to create a reader application. Currently I'm only willing to read-back the contents of BRAM blocks for starters. 

The BRAM blocks I'm using in my design are generated using the Core Generator and are by default filled with 0xDEADBEEF. This is also the value I read when I use the MicroBlaze to read the BRAM via AXI.

I've enabled the capture primitive to make sure the contents of the FPGA is stored. This CAPTURE_VIRTEX6 is supplied with a 80MHz clock, an always high "CAP" signal and ONESHOT set to false. 

 - Do I need the capture primitive to read-back the default block-ram contents? I assumed I would but I'm not a 100% sure.

The attached figure shows the location of the BRAM block. Taking your previous information into account I assume the location of the BRAM is.

 BlockType= 1 (content)

 Top=1 (since I want to address the bottom of the FPGA)

 ClkRow     = 1 (counting from center down 0,1,2)

 MajorFrame=0 (Most left BRAM column of the FPGA)

 MinorFrame=0 (Startframe is 0 )

 FramesPerCol=127

The command sequence used for reading this column of BRAMs is.

0xffffffff// Dummy
0xaa995566// Sync
0x20000000// Noop
0x20000000// Noop
0x30008001// Reset CRC ( ( 1 << 29 ) | ( 4 << 13 ) | ( 2 << 27 ) | 1 )
0x00000007// Rcrc

0x20000000// Noop
0x20000000// Noop
0x30008001// Set CMD reg ( ( 1 << 29 ) | ( 4 << 13 ) | ( 2 << 27 ) | 1 )
0x00000004// Rcfg
0x20000000// Noop
0x20000000// Noop
0x20000000// Noop
0x30002001// Set FAR ( ( 1 << 29 ) | ( 1 << 13 ) | ( 2 << 27 ) | 1 )
0x00308000// ( ( Block << 21 ) | ( Top << 20 ) | ( HClkRow << 15 ) | ( MajorFrame << 7 ) | ( MinorFrame << 0 ) )
0x28006880// Type1 ( ( 1 << 29 ) | ( 3 << 13 ) | (1 << 27 ) | 81 * FramesPerColumn + 81 )
0x20000000// Noop
0x20000000// Noop

From this moment I start reading 81 * FramesPerColumn + 81 32-bit words. The additional 81 words are added because the first frame is a dummy frame as you and the datasheet mentioned.

The data I read-back are all zeroes.

- Are block-rams standard initialized with zeroes and am I reading the an incorrect BRAM, or do I overlook something else?

Thank you in advance,

Best regards,

Luke

[chenweit]

Luck,

CAPTURE block captures only FD content. It has no effect on LUTRAM/SRL16/BRAM. When in doubt about FAR address of the BRAM/FD/LUTRAM/SRL16 bit locations, use bitgen's -l option to print out an additional file (.ll file). The additional logic allocation file will list all your utlized BRAM and bit location (with FA info as well).

Note that BRAM content is dynamic. If you overwrite the content, the readback value can reflect such. In addition, when reading back BRAM content, you'll have to pause any user operation on the BRAM to avoid any potential conflict with config logic. (this is why verify via iMPACT always includes placing device in SHUTDOWN)

Regards,
Wei