Reverse engineering Anlogic AL3_10 FPGA

[pcprogrammer]

Having it working in the simulator makes the naming job easier

I added all the enable signals I found in the code to the waveform display and sorted them on their place in time. Saved the list and formatted it into my renaming table et voila another 56 nets done.

A lot easier then tracing them in the code and figuring out which state they belong to. Naming the belonging bits that are stored on these enables is now just looking through the code and pick the nets that are loaded on these enables.

[pcprogrammer]

Hmmm, I found something weird. While simulating the sampling part of the design I found that the clock signals for the ADC's are 50MHz instead of 100MHz when the highest sample rate is selected. So to verify this I got my big scope on the bench and started measuring the signals both for the original and the reverse engineered version.

It turns out that the sampling clocks are indeed to slow compared to the original, while the 1KHz probe calibration signal is ~1KHz for both versions. So I must have missed something in the clock setup.

But the big question is what.

It can't be the PLL setting, because doubling it would mean a 2KHz output on the probe calibration signal.

One more puzzle to be solved

[pcprogrammer]

I gave the gate level verilog a try to see what the frequency of the sampling clock is then, and it comes out as 100MHz, but the sampling it self appears to be not working.

This means that my translation to higher level verilog is not correct where it comes to this bit of the design. Why the sampling fails for the gate level verilog is yet another question. Might well be that the interpretation of the embedded memory block macro settings is wrong.

More simulation of what I have now is needed to provide some insight in the sampling setup, to allow me to translate it to better readable code. I already started with some simple bits like the main clock divider and the 1KHz probe calibration signal. The latter I tweaked to be actually for 1KHz. The original is of by a count of one 50MHz cycle.

[pcprogrammer]

The problem with the frequency has been found. It turns out that I did not pay attention to a carry in on add or subtract chains. For the dividing of the ADC clock the carry output of a subtract is used. The inputs are the set divider value and subtracted from that is the output of a counter. It is here that there is an input carry that needs to be subtracted too.

It now simulates the 100MHz for setting 0 and 50MHz for setting 1, etc.

Getting the sampling bit working in the simulator is not going that well unfortunately. I need to work on my test bench skills for this or something in the verilog to simulate the memory is not set up right. I can see the setup do its work, where the sampling is reset, and then started, leading to buffers being filled, but when I try to read the data it is not showing any output.

In the test bench I have to make some setup with modules if possible to make sending commands and reading data more clear and robust. Have to do some reading up on the subject 

Still in the learning phase of the art of simulation

[pcprogrammer]

Decided not to be bothered to much by the simulation not showing output and started converting the code to more readable and concise code.

Started with a simple parameterizable counter module to be used in the clock division parts. Based the 50MHz and 1KHz clock on it and that tested fine. Reduced the sizes of the counters to what is needed. So slight deviation from the original.

Did the code for the command loading and the multiple byte writing and reading. Started with just a few write commands like the sampling rate divider and the channel DC offset setting. Also improved on the test bench with tasks to simply write a command or the different sizes of data. Makes the test bench more clear.

Now I have to run some tests in the simulator to check if the correct bytes are set and then implement the PWM parts for the channel DC offsets. Step by step I'm going to write the code for all the bits found in the original, and test each bit along the way.

When it all checks out I will run it on the scope to see if it works as intended.

[pcprogrammer]

More and more parts are added to the better readable verilog design.

Just did the sample write clock which is variable and can be changed with command 0x0D. Tested it in the simulator and is works just like the original.

Here is the code with a test bench I made so far. It is an attempt to recreate it like the original code with just minor improvements. I believe there can be improved on a lot of the original design, but that is not the goal.

A funny thing that I found is that the scope firmware writes to a couple of commands at startup, but these commands are not implemented in the FPGA

Another thing I found is that I did not understood the meaning of command 0x3C when reverse engineering the firmware. I thought it did something with the battery level, but it turns out that what is written to the FPGA with command 0x3C is read with command 0x41. In the original firmware the data from command 0x41 is used as an address to read from the touch panel. Some weird and unnecessary stuff they did in this scope.

Next up is the trickier part of dissecting the sampling and trigger code together with the read back of the samples.

[pcprogrammer]

Found an oversight while testing the sampling system reset functionality based around command 0x01 and 0x05. Forgot to filter the writing of the registers on data and write state, so on every MCU clock signal the last selected register was written leading to unexpected results. 

Forgot the same in the read part, where it should only be on data and read state.

Easily fixed by adding a "if" statement in the related always blocks.

[pcprogrammer]

Getting to the bottom of the sampling bit is a lot of searching through the generated code and determining which signal is used for what.

I did figure out what the data set with the command 0x0E does. It makes up a delay before the system decides the sampling is done. This is only used in auto trigger mode. When no trigger is found the sampling runs until it has done the set amount of samples.

For instance for the highest sample clock (100MHz) the setting is 411100, and this means that as long as no trigger is seen it takes 411100 samples before it signals the MCU it can read the samples from memory. And this is where it is a bit weird, it only has memory for 4096 samples

So to speed up the process it can be reduced without real consequences. But for the lowest sample rates the original firmware used 800, and this explains why it only read 750 samples for that setting, because it stops after 800 samples in auto mode.

Still have to figure out how the trigger part is done. It uses the samples from memory, which means a mixing of the write and the read clock is done. For the logic in rising and falling edge together with the set trigger level I have to go through a bunch of still unnamed nets.

But the end is nearing

[pcprogrammer]

The way the trigger system is implemented is definitely not how I would have done it. Still working through the signals and converting it all to more readable code and it ain't simple.

After the sampling system reset has been lifted by the MCU the sampling starts, and 1600 samples are taken, then it starts the trigger process, where it starts reading the samples from address 800, and as soon as it finds a trigger point in the data it stops the write process and this is signaled by the MCU with command 0x0A.

When no trigger is found it just keeps on writing until the time base timeout signal is set. This is after the number of samples, set with command 0x0E, have been taken. In this case it would be possible to read 8K of samples per channel from the buffer (4K for each of the two ADC's for each of the channels) In the case of a trigger this is limited to 1600 plus the number of samples it took to find the trigger.

When the trigger is found the address in memory where the trigger has been found is captured and can be read with the MCU by command 0x14. This provides some insight in what is done in the software to determine the starting point for reading the data.

How the trigger is found, I still have to investigate further. I believe it keeps a previously read sample and then compares it with the next, but the implementation is not to clear, so needs simulation to find the logic.

[pcprogrammer]

Here is what I see in the simulation for the input signal, what it reads back for finding the trigger and the previous data is uses for it too.



The trigger is found under the yellow cursor line. The weird spikes are caused by the registering of the top two address bits, which select the data from the different memory blocks. The other deformations are probably caused by the signals used to determine the trigger. After sampling stops writing the counters keep running, and the checking keeps on going too.

[pcprogrammer]

Getting the trigger signals right is a bit of a pain in the bum.

By the looks of it I have the rising edge part working as intended, but the falling edge is wrong. As written before the way it is done is not how I would do it, and that makes it more difficult to grasp the logic behind it.

It involves quite a bit of signals that are combined together making up detects and enables for the rising and the falling edge, and with the aid of simulation I was able to determine that it uses "less then or equal to" against the set level for both the current and the previous sample, and based on the trigger edge setting it uses one of the signals to decide on being triggered.

So a bit more investigating is needed to find why the falling edge is not working as expected.

[pcprogrammer]

Not exactly like the original but in simulation it looks like it works for both the rising and the falling edge.

Next up is the part to read the samples with the MCU, and then run a test on the actual scope.

Not sure if I'm going to tackle the I2C part in the making it more readable. The journey was to see if it was possible to reverse engineer a FPGA and that has been confirmed.

[pcprogrammer]

Bit of a downer

I finished of the translation and compiled it with the Tang Dynasty IDE. Had to fix a small issue with loading a register from two sources, but that was easy to solve. Without the I2C part in it the number of used bits is about 55% of the original

But dammit it did not work on the scope.

Tried using timing constraints and it failed to reach the 200MHz timing The crude reverse engineered code did though, so a bit of a mystery as to why this one fails.

Will play a bit more with the simulator to see if it reacts as expected and if so try to improve the code a bit.

I did find another missing thing. The software writes to command 0x28 to select between sampling via memory or direct reading the samples, but there is nothing in the FPGA for supporting command 0x28

[pcprogrammer]

Decided it is time to move on to other projects.

The more readable version I distilled from the crude version compiles with timing problems and does not work on the scope, but in simulation the response seems to be correct. Since it is a crap design I don't feel the urge to continue on it.

With the crude version of the design, generated with the tool I wrote for it, it is proven that it is possible to get a somewhat working design from a given bit stream. Renamed most of the nets, and the ones left are for reading the data with the MCU and for the I2C part of the design.

Granted it is not perfect, and there are still issues when compiling it back into a bit stream due to compiler version, timing constraints and differences in place and route.

Conclusion is that it requires a lot of patience, skill and persistence to get a thing like this done. It was fun and I learned a lot from it about the working of FPGA's and simulation.

I uploaded the latest results to the repository https://github.com/pecostm32/Anlogic_AL3-10_Analyzing

[tv84]

Decided it is time to move on to other projects.

The more readable version I distilled from the crude version compiles with timing problems and does not work on the scope, but in simulation the response seems to be correct. Since it is a crap design I don't feel the urge to continue on it.

With the crude version of the design, generated with the tool I wrote for it, it is proven that it is possible to get a somewhat working design from a given bit stream. Renamed most of the nets, and the ones left are for reading the data with the MCU and for the I2C part of the design.

Granted it is not perfect, and there are still issues when compiling it back into a bit stream due to compiler version, timing constraints and differences in place and route.

Conclusion is that it requires a lot of patience, skill and persistence to get a thing like this done. It was fun and I learned a lot from it about the working of FPGA's and simulation.

I uploaded the latest results to the repository https://github.com/pecostm32/Anlogic_AL3-10_Analyzing

First of all: my deepest RESPECT for what you accomplished here. 

It's mind-blowing the level of knowlege, wit and resilience you showed! Doing all this quest alone is quite a feat. 

I had surfed your MCU software investigations but I had never seen this FPGA reversing thread, until today. Just to be able to follow your descriptions requires a unique ammount of knowledge (that I unfortunately only have a small part) but, nonetheless, provides a perfect sense of a reverse process goes along and how a reverser's mind work.

Love the iteration, bug catching, optimization, head banging, adaptation, accomplishment satisfaction, return to start...

Very well done. This is pure reversing and looks amazing in one's curriculum!   

I hope to see (one day) you finish the work with the official HYPER-CRAP design and tools... (I know, from experience, that such an endeaveour is never finished, in one's mind, if we don't proper close it...  )

[pcprogrammer]

Thanks tv84,

It was quite the quest indeed.

To finish it it would mean a lot of trial and error to find the right version of the IDE, the proper optimization settings and maybe even the order in how the verilog is written. Not sure if my curiosity is big enough for it. 

Since you just now spotted this, you probably also missed the grandeur joke I made about it in the FNIRSI thread. 

Reversing the programming: only in God mode...

Ok it took way more then 7 days, but if I had a son I would have to rename him Jesus, because I did it. 

It is the curse of the curious mind though, that I persisted and might dive into a new reversal adventure with the Hantek DSO2D15 FPGA. A bit more of a challenge and a lot harder due to almost no knowledge of the workings of it. But first some other projects like modernizing a FischerTechnik 27MHz remote control set.