Electronics > FPGA

Reverse engineering Anlogic AL3_10 FPGA

<< < (8/18) > >>

After a holiday break back on the project. By the looks of it getting a gate level verilog that will yield the exact same bit stream seems to be hard to accomplish. Had to make more tweaks after implementing the LUT3 macro and was able to get the exact same output from the original verilog and the generated gate level verilog.

But then after implementing the LUT4 macro it failed again. Found that it had to do with the naming of the macros and was able to get it back on track, but now after implementing the LUT5 macro it is of again :o

So will not try to get it to match, but will continue implementing the logic for generating the gate level verilog. Even if it does not yield the exact same bit stream it is still possible to verify the result by running the new bit stream through the reversal code and check the outcome against the first run.

As long as it is just routing that changes and not the logic equations the functionality should be the same. :)

The mapping of the inputs on the lookup tables is different to what I wrote before. For 1, 2 and 3 input LUT's it uses dedicated mappings, but for the 4 and 5 input LUT's there is a 1 to 1 relation between the signals.

At least it is all taking shape and even though still a lot to do, it is leading to a satisfactory result.

It involves a lot of research through all the data to get to the bottom of what the different settings for the logic blocks do. Some are also hard to verify due to the fact that the IDE has a will of its own. For instance it won't create a LUT6 using one slice even when I specifically provide the LUT6 macro. It just splits it up in two or more separate LUT's spread over different slices.

Another one that is hard to verify is a LUT5 made within a single mslice. The bit stream of the original 1013D FPGA seems to have these in it, and another design I have in actual verilog source of, does use it to, and it took some thinking and looking at the data to get an understanding of it. The easiest way to deal with it in my code is to create 3 LUT macros though.

The two LUT4's of the mslice get the same signals on their inputs, but not always in the same order, as can be seen in the attached pictures. This is why I now create two LUT4 macros and a LUT3 macro to select between the signals of the other two based on the "mi_0" input.

Then there is the fact that slice 0 of every logic tile differs from slice 1, because there are some settings bit missing for this slice. Where slice 1 seems to route the "mi" input to the flip flop input by default, slice 0 has the "f" output routed to the flip flop and only switches to the "fx" output when the FX MUX is turned on. :palm:

If someone is ever going to make the open source place and route software for these devices they have a lot of stuff to figure out 8)

I think I have the MSLICE handling down. Did some random checks on what is in the generated gate level verilog and the listed settings in the block list and it looks like it is matching up.

A full test by running it via the Tang Dynasty IDE is not possible due to the clock part not being done yet, and most likely a lot of signals are not connected since the rest of the logic is not yet generated. Did some tests with a simple 4 bit adder and registers to iron out the kinks though.

The LSLICE has more abilities so will be a bit more work, but with the increased knowledge gathered from doing the MSLICE it should go faster.

The LSLICE was less work then I thought. Just implemented what is used in the 1013D bit stream, so not suitable for full reverse engineering of every bit stream out there.

For the PLL I already did some exploring and have the verilog IP for it, which I will manually copy into the gate level verilog file I'm generating, so what is left is the block ram. This means looking through the settings bits to generate the proper settings for the parameters of the block ram macro, and connect all the signals to the blocks.

A fair bit of coding but not to complex.

And when that is done the big question is, if what I generate compiles into a bit stream that does what the original bit stream does.

If so it will then need translation to more readable verilog, which will not be that simple, but will cross that bridge when I get to it :)

Well I managed to get output that can be compiled with the IDE, but if it is correct needs to be verified.

Due to the fact that I manually did the clock signals I can't just run my reverse engineering program on the newly generated bit stream and expect it to be able to compile again. When the clock generation blocks are moved to different tiles the names I have fixed in the code will not be the correct ones :(

But a quick inspection showed me that the newly generated bit stream uses about 3000 bits less, and I'm not sure if this is just due to a different placement and routing.

One way to test of course is to load it into the actual scope and see what it does. So fingers crossed and hope it does not blow up :palm:

I will do a bit more checking of what is generated though.


[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Go to full version