Electronics > FPGA

Reverse engineering Anlogic AL3_10 FPGA

(1/19) > >>

I'm trying to reverse engineer the bitstream of an Anlogic AL3_10 FPGA, but have trouble matching the configuration bits onto logical names.

With the information from prjtang (https://github.com/mmicko/prjtang) I'm able to make a map of the used tiles, but mapping the actual bits fails. To check things, I made a simple design in the Tang Dynasty IDE and the bitstream generator tells me how many configuration bits are set one. This matches with output of my rudimentary tool mapping these bits to the tiles.

The json database files for the bits show a x,y coordinate system, for which I tried several matching options, but the resulting bit names make no sense. For most of the tiles it is just two bits for making connections over the interconnect, and one would expect logical names with something like "mux" in them to pop up.

To get a better understanding I'm also trying to decode the work files of the IDE, which is slowly coming together, but I'm not sure if that will provide the answer. The prjtang data is a big help in this quest but it lacks information about how the mapping of the bits is done.

So if anyone has some in-depth knowledge of this, I would appreciate if it is shared here.

When there is an interest in the code I'm making (written in either C or python) let me know. I have no problem with sharing it.

I'm new to modern FPGA's and certainly new to the internals of them. My quest to reverse engineer one is a learning one, so questions come up.

Here is one I hope someone has an answer for. When in an IO tile that holds 4 pads, a single pad is enabled for either input or output, do the other pads need to be configured then too?

I made a simple verilog project with just two wires connected to each other. P23 as input connected to P112 as output. When I list the configuration bits, it looks like the Tang IDE sets unused bits and bits for the other pads.

Attached is the list file I made and a zip of a bitmap I made showing the tiles and the configuration bits.

It took a lot of thinking and looking through the data to figure out what was wrong. At first I gave up on the whole quest due to not getting the wanted results, but the brain kept on wondering.

What I did wrong was to assume that the 4 pad bits each frame of the configuration data has were at the end.

At some point in the process I thought, hang on, when I change the "pulltype" property on a pin certain bits have to change, and looking in the bits file for the io tile in question and the pin used, showed these to be the bits in column 3 (x) and rows 14 and 16 (y), but in my generated image the bits were on column 3 and rows 18 and 20. So an offset of 4, and then the quarter dropped :o

I knew about the bit stream having 257 bytes per frame which is 2056 bits and the database only using 2052 of them. My programmers instinct naturally assumed the not used bits to be at the end. It turns out they are at the beginning.

After testing with more io pins at all sides of the chip this was confirmed and I now have clear data on the configuration bits.

It turns out that the Tang Dynasty software always sets the source and sink property bits for all the pads in a tile even when the pad is not used or connected to the actual pins. The other bits are only controlled when a pad is used.

Still a lot to figure out to get from the bit listing to a net list and from that back to hdl.

I'm revisiting this topic after new information came up.

For the Gowin FPGA's more has been done on the front of the open source tools, and I was looking into that in regards to the Gowin FPGA used in the Hantek DSO2000 series. I learned from it about the naming convention in the routing. So to gain more experience on FPGA reverse engineering I decided to try the probably simpler design of the in the FNIRSI-1013D used Anlogic FPGA.

Still a lot of discovery to be done, but think it is possible to trace the connections through the FPGA.

The configuration bits are set based on a logic equation on input parameters. For the routing these are like "ARCVAL(S6BEG0,E1END0)" where this means a connection between a south going wire spanning 6 blocks and an east going wire spanning a single block. The first character is the direction letter, the second character is the span, being either 1,2 or 6. Then followed by a tap point being "BEG", "MID" or "END" and a last character being the wire index.

For the single block span it looks like there are only 4 wires per route. For the multi block spans there seem to be 8 wires per route.

I made a listing of all the separate ARCVAL entities to gain more insight.

The screen shot shows a routing in the Tang IDE chip viewer.

I have a question about interconnect wires in a FPGA.

Are they unidirectional?

In the Anlogic AL3_10 FPGA I'm trying to reverse engineer a design from, I'm progressing slowly and gain more insight in the interconnect and wonder if I'm right in thinking that the interconnect wires are indeed unidirectional.

The Tang Dynasty IDE has a chip viewer and I found some new features that allow highlighting of the RSB/PIB SWI lines. It has three types, namely 1 hop, 2 hop and 6 hop lines. When viewing these for a single block it shows only 4 lines per type originating from the block. See the attached pictures.

This leads to the below and the total number of connections match up.

--- Code: ---outgoing      incoming
 4x  1 hop     4x  1 hop
 4x  2 hop     8x  2 hop (4 mid and 4 end)
 4x  6 hop     8x  6 hop (4 mid and 4 end)

total connections
12      +     20 = 32 (4 x 8)

--- End code ---

I made a listing of the arcval pairs found in the database and this seems to confirm my idea. The pairs have the following meaning (endpoint, startpoint). For instance (W6BEG5,Q0) signals a connection between a logic block output Q0 and a wire start W6BEG5. In the list it only shows connections to the BEG wires and not the MID or END wires. There are of course also connections to logic block inputs like A0, B0, etc.

Another question is if this setup is proprietary to the Anlogic FPGA's or a rather common thing?


[0] Message Index

[#] Next page

There was an error while thanking
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod