FNIRSI-1013D "100MHz" tablet oscilloscope

[pcprogrammer]

The fact that the F1C100s gets quite hot is not a good sign. Have not measured current consumption, but 1.3A seems high.

The GT911 has FLASH memory for the configuration. It is only written when the CRC is correct and the write flag is set. There is also a check on the version number (first byte of the config data) but not sure when it discards a configuration based on it.

With an Arduino on 3V3 or level conversion in the I2C lines it is possible to test the touch panel. You can most likely find some sketches online that use the GT911 touch panel. When you write a new configuration to the touch panel it will remember it. That is why the new firmware only reads the configuration. There are different models in circulation where the sensor array is different or wired reversed, so writing a specific configuration gives problems like described in this thread. Coordinate reversal in either x and or y direction.

To test the processor port A there is the sunxi-fel tool. For this load the fel boot on a SD card and start the scope. With the sunxi-fel tool it is possible to write to the configuration and data register of port A. This way you can confirm if there is a problem in the processor. The F1C100s data sheet is also in the repository. Disconnect the touch panel just to be save.

I'm not behind my development system at the moment, so can't give the details on this, but with the information in the repository you should be able to get it done.

This way you can also see if the current draw drops and if the F1C100s stays cooler.

Edit: I hooked my scope up to a power supply with builtin A meter and on 4.1V (~full battery charge) it draws around 800mA. I had the current limit set to 1A at first but then it does not start properly, so there is some initial current draw of >1A. With the limit set to 1.5A it starts just as normal and the current reading is unstable but it stays below 900mA.

This might point to a faulty F1C100s. It is possible to buy some from Aliexpress for 3 dollar a piece or so. But be aware that it has a ground pad underneath, so de-soldering the old one needs special attention, like pre-heat from underneath with infrared or hot air.

[Gustavo]

Have no words to thank you for your valuable time dedicated to this small toy. Im an electronic engineer and works mainly with microwave links and ultrasonic welding machines, have a pretty decent laboratory, but Im obsessed putting this oscilloscope to run correctly.

"write the image () to a SD card and stick it in your device. This will boot it into FEL mode and allow flash programming via USB"

I folowed the instructions and copied (in a windows 10 machine) the sunxi-fel tool (is this the image?) to the 1GB micro SD that came inside the oscilloscope in order to gain control of the osc. through the USB port, installed the SD, booted the osc and nothing happened, it booted normaly, am I doing something wrong?
Should the sunxi-fel tool be copied with my linux equiped raspberry PI3B
Its very obvious Im not a computers expert.

BTW, feels weird analyzing this FNIRSI with a $2K Keysight oscilloscope, but I wont rest till I fix it (hpefully with your help). Not an easy task finding people dedicated to save a $150 plastic brick and to help people for free!.
Again and again, THANKS  A LOT.

[pcprogrammer]

Hi Gustavo,

your welcome. I'm happy to help.

I'm not experienced with windows anymore but take a look here: https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg3825029/#msg3825029
On windows you will also need a version of sunxi-fel compiled for it, so using a raspberry pi with linux could make live easier. Since you can't use the scope as card reader/writer you need one you can connect to your pi. (The one on the pi probably has the os in it)

Attached is the file that needs to be written onto the SD card. First you have to find the device the SD card is connected to. Linux command "lsblk" lists all the block devices on the system. On my system it mostly connects to /dev/sdc, but on the pi it might be /dev/sda or something else.

The bs=1024 combined with the seek=8 puts the file on sector 16 of the SD card. This is were the F1C100s looks to see if there is a boot loader. If it works the scope should start with a black screen. Connect the scope via USB to the pi and use "lsusb" to see if the scope is in fel mode. ("Bus 001 Device 008: ID 1f3a:efe8 Onda (unverified) V972 tablet in flashing mode")

Code: [Select]

sudo dd if=fel-sdboot.sunxi.txt of=/dev/sdc bs=1024 seek=8

See: https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/msg3825029/#msg3825029 for more info

The sunxi-fel tool for linux is also attached. Remove the .txt and make it executable with "chmod +x"

I also attached a file I use as a memory aid with the commands I used for testing. Testing port A is also in there. Ignore the rest of the crap

Success,
Peter

[Fungus]

Hi, new here. I was looking for info about this oscilloscope which I plan to buy for checking stuff around the house (utility power, UPS, and portable generator outputs, etc.)

For that usage I'd worry a lot more about getting the cables and safety procedures correct than any firmware updates. It can show a 50Hz/60Hz sine wave just fine without any mods.

[Gustavo]

Thanks so much. I´ll do all you suggest to do. GREAT!
Yesterday I got a black screen and tought something was wrong 
Late this afternoon  I will use your tools to test the port, I gess port A is the oneconnected to de TP, am I right?

Thanks again.

NOTE:

Why I gess there is a problem with the TP (maybe just configuration) is because touching the panel send no I2C signals at all to the 100S.

[pcprogrammer]

Yes that is correct. In the schematic of the processor part you can see which pin has what function.

[pcprogrammer]

Why I gess there is a problem with the TP (maybe just configuration) is because touching the panel send no I2C signals at all to the 100S.

The touch panel only works as a slave. The F1C100s has to request data from the touch panel. There is the interrupt line form the touch panel, but that is not used as such.

With the touch panel disconnected the F1C100s will still try to communicate, so it should be possible to measure a clock signal in bursts.

Since the lines always seem to be high it can also be that they are shorted to VCC, causing larger currents to flow when the F1C100s makes these lines low. This could explain the high temperature of it.

[Fungus]

Since the lines always seem to be high it can also be that they are shorted to VCC, causing larger currents to flow when the F1C100s makes these lines low. This could explain the high temperature of it.

Hopefully it's through a resistor:

https://en.wikipedia.org/wiki/Pull-up_resistor

https://en.wikipedia.org/wiki/Open_collector

[pcprogrammer]

It is fault finding, so if the lines are kept high by a short there is no real series resistor. In normal operation the lines have 10K pull up resistors, which is high for I2C but it works.

Not sure if the F1C100s port A pins use open drain or open collector or push pull, but when set low there will be a connection to ground with the possibility of a larger current then intended.

It is all guessing from my side since I don't have the broken scope on my desk.

My approach would be to disconnect the touch panel and do measurements. First without power to check on continuity between the port pins and VCC or GND. Then with another scope to see if there are signals on any of the pins. Another test would be with the FEL mode to control the pins statically.

[Gustavo]

Hi there. PCPROG, today I had a time window and made some basic tests on the oscilloscope.

1. Disconnected the TP and there is no signals whatsoever at the processor pins, no SCL nor SDL, the SCL impedance measured with 3.3 V bus as reference  is 10K, as expected, but the SCL impedance is 42 ohms, crazy low,my conclusion is that the CPU is faulty.
Made all the possible atempts to have live USB, booting with the linux utility, no success at all.
I´ll look for the F1C100S in China.
Hope I will be able to unsolder the central dssipation pad.

Thanks a lot.

[1audio]

Help me understand the larger picture of how the scope operates- Essentially it has a dedicated stripped down Linux OS that boots and runs from an uSD card that is formatted Fat32 if I understand what has transpired. So if I can copy the "drive" image to a uSD card and swap it for the original I would be running your software.

If so it opens the opportunity to make more focused customized versions that can easily be deployed. There are limitations (2 ch 8 bits and the limits of the native ADC stuff) but within those limits one could make some interesting devices. Everything from a vibration or acoustic analyzer to some smart auto diagnostic stuff.

[pcprogrammer]

Hi 1audio,

neither the original nor the new firmware uses linux. It is bare metal programming.

The way it works is that the F1C100s has a fixed startup program in ROM, the so called BROM. This program does a simple initialization of the processor and then reads sector 16 of a SD card if present of-course. When there is a correct boot header in the first 32 bytes of sector 16 the BROM will load the belonging program and executes it.

If no SD card or no boot header is found it tries the FLASH memory if present.

This is to our benefit, and what I use to load the new firmware without modifying the scope. By loading the new firmware package to sector 16 of the SD card in the scope it is forced to start the new firmware first.

Within the limitations of the original FPGA it is possible to make it what ever you like. The new firmware is not to complex and offers a display library to do simple graphics and text.

All that is needed to make your own stuff is a SD card boot loader and a main program. The boot loader is needed to enable the DRAM in the F1C100s, where the main program then is loaded and executed. The boot loader itself is loaded by the BROM in 32KB SRAM that is always enabled. To do display stuff this is not enough memory, hence the two stage startup.

To have my startup image displayed I use an extra step in the loading process.

• The boot loader that enables the DRAM and loads and executes the startup image program
• The startup image program that show the startup image, loads and executes the main scope program
• The main scope program.

To do this kind of process from the FLASH a different boot loader is needed. It has to address the FLASH instead of the SD card.

Hope this clears things up.

Cheers,
Peter

[pcprogrammer]

Did not have a lot of time to work on the project the last week, but this morning I finished the mod on the scope to get JTAG connected.

It was not easy with older eyes and not as steady in the hand anymore as time has gone by rather quickly. One moment you are in your forties and then you are almost sixty. Did not do it like morris6, to whom I applaud for a job well done. I used a male flat cable connector. At first I tried to solder the flat cable wires directly, but that was no success. So I used lacquered copper wire to solder to the components and soldered the lacquered copper wires to the flat cable.

Used a bit of hot glue to fix the wires to the board.

And it works. Am able to reprogram the FPGA with the JTAG programmer and the Tang Dynasty IDE.

[Gustavo]

Hi there everyone, neeed help with two things please.

1. Where in the states can I get some F1C100s, the ones foun in China take 6 weeks to arrive to Miami!

2. Attached is a picture of the processor schematic showing an USB interface IC. No such IC in my oscilloscope

Thanks in advance

[pcprogrammer]

Hi Gustavo,

can't help you with the first thing.

About the second one, you forgot to attach the picture, but I think you misread the schematic. If you are referring to the schematic in the repository, of which I attached the bit with the "USB ic" this is actually the USB connector. Since it is a USB-C connector it has a lot of pins to allow the insertion of the plug in either orientation.

I was thinking about your scope and wonder what caused the problem in the first place. The original firmware has some test code in it that suggests factory testing before packaging. Within this test code there is a bit for testing the touch panel. It involves touching the four corners and the center. It will not continue to normal operation without completion of the tests.

Unless the tests are skipped all together, which can be done by writing a flag in the FLASH memory, it should not have left the factory if it was already defective.

So my advise is to also test the touch panel itself on defects by static measurements and / or using an Arduino, and check the PCB after the F1C100s has been removed on any shorts just to make sure it is only the processor that is defective.

Hope you get it fixed,
Peter

[Gustavo]

  Hi PCP, sorry  for my blindness about the connector. Today I´ll remove the F1C100s, I´m just looking for a good infrared sporce in order to rise the oposite side temperature of the board.
Y already ordered some processors from Aliexpress any way. Thanks so much!

[robca]

It was not easy with older eyes and not as steady in the hand anymore as time has gone by rather quickly. One moment you are in your forties and then you are almost sixty.

I'm also a kid of the 60s. And when I started working with electronics, components were big and my eyes were good. Then components kept getting smaller and my eyes getting worse, untl I crossed a threshold.

Then I bought an old Bausch&Lomb SZ4 stereo microscope (barely younger than I am ) and everything was easy again. I can now easily rework boards with 0402 components and solder to a single pin of an FPGA. It's hard to believe, but hand steadiness is completely dependent on how well you can see (unless there are actual neurological problems). With proper magnification, my hands are rock solid and I can work on the tiniest details

I cannot recommend enough a stereo microscope for anyone working with electronics, ideally with zoom. You'll also need a good support (which can cost more than the microscope itself), a ring led light and ideally a Barlow lens. A Barlow lens reduces magnification but increases depth of field. Most of the work I do uses much smaller magnification than I expected. Most of it is 10x: around 2x zoom, 10x oculars and the 0.5x Barlow lens. With a 4x zoom, I have a max 20x magnification, and I find it almost excessive for most cases. So the Barlow lens is a good tradeoff: most of the times, lack of depth of field is more impactful than magnification

I now enjoy soldering again, and I actually like SMD work more than the old style thru the hole. BTW: if you live in the USA, Hakko USA sells incredibly good SMD tweezers for ~$5, much cheaper than Amazon (and with $25 order there's free shipping)

[pcprogrammer]

Since it is not that often that I do this kind of soldering a microscope like that is a bit expensive. I have a digital one from banggood with a 7inch screen. It does the job, but the depth perception is not great. Also the base of the stand is not that big so makes working on larger objects like this scope a problem.

A friend of mine has an optical stereo one and I must say it is definitely better than the digital one I have. Still it is something you have to get used to, working with a magnifying aid. Positioning tweezers and soldering iron is, for me at least, keeping your mind focused on the job. Might have to do with the fact that I often exchange left for right

You are right about that SMD is much nicer then through hole. No bending and clipping wires. Way faster to finish a board with only SMD then the same circuit with through hole components.

At the moment I'm looking into the original FPGA and the open source bitstream tools of mmicko, frenky pointed to on page 51 of this thread. Managed to revert the .bin from the FLASH back to a .bit file, which I can use in the Tang Dynasty IDE to reprogram the FPGA. Getting the CRC in the header right was a bit of a search over which data it needed to be calculated.

The https://github.com/mmicko/prjtang/blob/master/docs/architecture/bitstream_format.rst is not to clear on this and the code found there is lacking good commenting. The code in the repository is written in either phyton or C++. Can read it, but not to experienced with it. More of a regular C fan. Might be more work to do stuff, but I find it better readable then C++. Did not manage to build the code yet. Have to do more research into the projects that are needed for this open source FPGA development.

A bit of a problem in this open source community is the lack of proper documentation. Sure I'm also not to big on writing documentation, but try to make things clear, I hope.

It is a challenge to reverse the bitstream data back to RTL and maybe verilog, but not sure how to. A good learning opportunity into the working of FPGA's. Not a big deal if I fail in this quest. On the background morris6 is doing a nice job in creating new programming for the FPGA.

[JimBeam]

Hi Peter,

I'm very thankful, that you are more of a C type - like me... That's why poking around in your code is a lot more fun than trying to understand what someone wanted to say in Python... Though python isn't sooo much different from C, and also C++ isn't sooo much different from C. You could also i.e. have used RUST - that would have been an absolute  shopstopper for me.

Having started as a hardware guy (I learned radio/tv technician) with some PC software programming in PASCAL, firmware design in 8051 assembler, later with KEIL C51, then some early PICs in assembler, moved on to AVRs and currently using ARMs in my designs (yes, I still am primarily a hardware guy), C is my favourite.

And, for the record, I am 61 now, too. And my eyes are also getting worse over the years... My trick is to wear reading glasses OVER my normal floating-focus glasses (are they called like that? Anyway, I guess you get the point) 

Andreas

[pcprogrammer]

Pfffffff, managed to get the prjtang to do things. Looked at prjtrellis, which has more documentation on prerequisites and steps to take to build stuff. Not sure if the cpp stuff is needed for the python code, but got it build and installed.

I now have a database for the Anlogic FPGA devices that can be used with the Yosys and nextpnr projects. Next step is to see if it is possible to revert the original bitstream into a net-list and try to identify the logic in there and see if it is possible to turn it into verilog.

Attached is a html file with the layout of an AL3-10

[Mal]

Hi everyone I'm a newbie I have a 2013d but the screen is cracked not the front glass it doesn't work at all does anyone know of a screen I can replace it with the makers do not want to know at all ⁴

[pcprogrammer]

Hi everyone I'm a newbie I have a 2013d but the screen is cracked not the front glass it doesn't work at all does anyone know of a screen I can replace it with the makers do not want to know at all ⁴

Typo or another model then the one discussed here?

If it is a typo you can get a new LCD from Aliexpress: https://nl.aliexpress.com/item/32693491775.html

More useful items are listed here: https://github.com/pecostm32/FNIRSI-1013D-Hack/blob/main/Aliexpress%20links%20to%20handy%20stuff

[pcprogrammer]

The FPGA reversal is taking some shape. Still quite the road ahead.

Yesterday I was a bit stuck on how to map the configuration bits onto the tiles. I tried contacting mmicko by email, but did not get a response yet. After a short afternoon nap a light went on and I found how the configuration bit - tile relation is. Wrote my own code to convert the "fpga describing json data" to C header files, to speed things up. Just finished a bit of code to load a .bit file and map the configuration bits to their tiles.

To verify things, I created two simple designs in the Tang Dynasty IDE. This tells how many bits are set for the design and my listings of both the .bit files show the same numbers. Next up is verify the tile names with the chip viewer in the IDE.

Below is a list of what I have so far.

Code: [Select]

frame  bit   tilename            type                 x       y
0	826	 mic_lr_x0y22	 miscs_mic_io_l	0	22
0	828	 mic_lr_x0y22	 miscs_mic_io_l	0	22
0	829	 mic_lr_x0y22	 miscs_mic_io_l	0	22
0	880	 mic_lr_x0y22	 miscs_mic_io_l	0	22
0	882	 mic_lr_x0y22	 miscs_mic_io_l	0	22
0	883	 mic_lr_x0y22	 miscs_mic_io_l	0	22
0	904	 mic_lr_x0y22	 miscs_mic_io_l	0	22
0	906	 mic_lr_x0y22	 miscs_mic_io_l	0	22
0	907	 mic_lr_x0y22	 miscs_mic_io_l	0	22
0	923	 mic_lr_x0y22	 miscs_mic_io_l	0	22
0	958	 mic_lr_x0y22	 miscs_mic_io_l	0	22
0	960	 mic_lr_x0y22	 miscs_mic_io_l	0	22
0	961	 mic_lr_x0y22	 miscs_mic_io_l	0	22
1	914	 mic_lr_x0y22	 miscs_mic_io_l	0	22
1	921	 mic_lr_x0y22	 miscs_mic_io_l	0	22
1	932	 mic_lr_x0y22	 miscs_mic_io_l	0	22
2	940	 x0y20	 pib	0	20
3	619	 x0y26	 pib	0	26
4	621	 x0y26	 pib	0	26
5	942	 x0y20	 pib	0	20
24	975	 x0y19	 pib	0	19
27	975	 x0y19	 pib	0	19
156	620	 x5y26	 plb	5	26
158	620	 x5y26	 plb	5	26
246	616	 x8y26	 pib	8	26
249	297	 x8y32	 pib	8	32
250	295	 x8y32	 pib	8	32
250	617	 x8y26	 pib	8	26
433	285	 x14y32	 plb	14	32
435	284	 x14y32	 plb	14	32
617	297	 x20y32	 plb	20	32
619	296	 x20y32	 plb	20	32
801	292	 x26y32	 plb	26	32
802	294	 x26y32	 plb	26	32
811	27	 x26y37	 pib	26	37
813	26	 x26y37	 pib	26	37
880	22	 x28y37	 pib	28	37
882	23	 x28y37	 pib	28	37
882	57	 x28y36	 plb	28	36
885	57	 x28y36	 plb	28	36
887	11	 mic_tb_x28y37	 miscs_mic_io_t	28	37
887	21	 mic_tb_x28y37	 miscs_mic_io_t	28	37
887	23	 mic_tb_x28y37	 miscs_mic_io_t	28	37
888	13	 mic_tb_x28y37	 miscs_mic_io_t	28	37
888	20	 mic_tb_x28y37	 miscs_mic_io_t	28	37
888	22	 mic_tb_x28y37	 miscs_mic_io_t	28	37
890	8	 mic_tb_x28y37	 miscs_mic_io_t	28	37
890	21	 mic_tb_x28y37	 miscs_mic_io_t	28	37
890	23	 mic_tb_x28y37	 miscs_mic_io_t	28	37
918	14	 mic_tb_x29y37	 miscs_mic_io_t	29	37
918	16	 mic_tb_x29y37	 miscs_mic_io_t	29	37
918	23	 mic_tb_x29y37	 miscs_mic_io_t	29	37
919	18	 mic_tb_x29y37	 miscs_mic_io_t	29	37
919	20	 mic_tb_x29y37	 miscs_mic_io_t	29	37
919	22	 mic_tb_x29y37	 miscs_mic_io_t	29	37

When this is found to be correct it is looking into naming the configuration bits and determine what they do. This is still a bit of a mystery. The json "database" has a tilegrid file, which provided the data in the list, and a set of "bits" files. Some are easy to map from the tile type, like "pib", but the "miscs_mic_io_t" don't have a direct matching counter part.

But with a bit of tenacity I will get there.

Edit: Checked the tiles in the IDE and they match, so I'm on the right road. Ran the program on the FNIRSI fpga data and it shows only 51429 of the 2205900 configuration bits to analyze. Piece of cake

[pcprogrammer]

Not making a lot of progress

I have started a topic in the FPGA section to see if there is some needed knowledge out there, because I'm not having a lot of success. Mapping the configuration bits to understandable names is failing due to lack of information.

Have some hope that the work files of the Tang Dynasty IDE can supply some information, but the file I managed to some what decode is still quite cryptic. One upside, I'm learning python. A friend of mine pointed me to the pyCharm IDE, which makes it quite easy to code and debug. I'm using the decoder mmicko made for prjtang, so he did the hard work there but it is still a big search to which number means what in the data count.

Code: [Select]

o56v~ 3 0 
CcD 4 25 qPn"QxyGnwTr}5E.6 1 r|c\tR3qHSxT 2 r|c\tR3qPdeD 3 r|c\tR3rPT5CutIa 4 tN3}E_5D}ucVtVvd 5 E[5Or#cQ"G3|Ycg 6 C}2QP&as|In"W(e 7 E[5Or#cQ"G3|Yci 8 C}2QP&as|In"W(g 9 E[5Or#cQ"G3}Y[*3i+5G 10 tN3}E_5D}uc\+N(i\H 11 tN3}E_5D}uc\+Ze 12 qPn#C$2JF#W, 13 qPn#C$2JG#W, 14 qPn#C$2KP*Ge 15 qPn#C$2P[#W, 16 qPn#C$2Pd*3 17 r|c\tR3|Yce 18 C}2QP&a}(XB 19 tN3}E_5N)'8 20 P"a~qTn"W(e 21 E[5Or#c[+Vg 22 qPn#C$2Qd"V3qHS 23 tN3}E_5O)+8 24 P"a~qTn)G% 25 
CerA 5 45 C}2QP&a}(X@ 26 tN3}E_5N)'5n5f99e!uBv 27 r|c\tR3|Yce 28 C}2QP&a}(XA5a88jpKnH 29 qPn#C$2Pd*5 30 r|c\tR3|Ycfa37iu7w@G 31 E[5Or#c[+Ve 32 qPn#C$2Pd*632ht<cI?x 33 P"a~qTn"W(e 34 E[5Or#c[+Vf2cs;h5Hp!t 35 tN3}E_5N)': 36 P"a~qTn"W(fcn:g:4y{J 37 C}2QP&a'uU 38 P"a~qTn)G%2cs;h5Hp!t 39 tN3#Lh5D&qQBeM32ht<cI?x 40 P"a$x]nuTr}cn:g:4y{J 41 C}2TW/at|OS|X32ht<cI?x 42 P"a$x]nyKw"cn:g:4y{J 43 C}2TW/axsPZ5a88jpKnH 44 qPn&J-2M^vN|2cs;h5Hp!t 45 tN3#Lh5N'|MRxa3?f{;73b 46 E[5Ry,c[)NzsIn5n6?iE53 47 r|c_{[3|W[|Ev2c{8n92q!uN63b 48 E[5Ry,c[)NzsIn5nG8une 49 C}2TW/a~&PXvG32qqBge26 50 P"a$x]n#U}yGT5aA5pthab 51 qPn&J-2Qb"KtucnCd@8cp:f9EcA 52 tN3#Lh5O'|MRxa3@f{;a;4xtgac 53 qPn&J-2Qb"KtucnCd@8c|Kze25 54 P"a$x]n#U}yGT5aAFi!q54 55 r|c_{[3}Y[*3i2c|KnHa<!xd:3a 56 E[5Ry,c\+N(a<n5oI?xHN;3b 57 E[5Ry,c_tF32ht<cI?x 58 P"a$x]n,Rrtcn:g:4y{J 59 n6?iD 60 Bd@8: 61 {8n92q!uN6 62 A5ptg 63 o6?iD 64 Cd@8cp:f9E 65 qqBg3:e!t;6 66 A5pt5oIK8 67 |KnHa<!xd: 68 AHp!tlzj 69 Fi!q 70 
FjM 6 19 qPn&J-2FP$M&uJ 71 P"a$x]nuTr} 72 E[5Ry,cQ(C~c6Z 73 tN3#Lh5Ev~X\+Z 74 r|c_{[3sPZwK* 75 qPn&J-2G^$Hzw 76 E[5Ry,cR)D 77 r|c_{[3vMU% 78 C}2TW/axsPZ 79 tN3#Lh5K#sPZ 80 tN3#Lh5N'|MRx 81 C}2TW/a~&PXvG 82 r|c_{[3}Y[*3i 83 qPn&J-2Sbv 84 C}2TW/a$qH 85 P"a$x]n&Ks 86 qPn&J-2T[" 87 C}2TW/a$%I\+Z 88 r|c_{[3)TPw 89 
r=Ac!t;uH2xsFc7> 1 1 txDaH8w!t 90 
FkB2xtIv3Gh!r;c8 1 1 Cm}5v9Fx 91 
!p?p3Gi!sJaH7v!tB 1 1 r=Ac!t;uH 92 
Js!rA 0 1 r=Ac!t;uH 93 
qPn"QxyGnwTr}5E.6 2 5 1 0 1
8< 1 vp:fF 2 Jes:t 3 K6pz 4 Mg 5 
8B 6 

Data shown above translates into what is shown below

Code: [Select]

macro 3 0
map 4 25 AL_LOGIC_DRAM16X4 1 AL_MAP_ADDER 2 AL_MAP_ALU2B 3 AL_MAP_BLE_ADDER 4 AL_MAP_BLE_GATE4 5 AL_MAP_BLE_LUT4 6 AL_MAP_BLE_LUT5 7 AL_MAP_BLE_LUT6 8 AL_MAP_BLE_LUT7 9 AL_MAP_BLE_MULT18X18 10 AL_MAP_BLE_MULT9X9 11 AL_MAP_BLE_MUX4 12 AL_MAP_F7MUX 13 AL_MAP_F8MUX 14 AL_MAP_GATE4 15 AL_MAP_LLMUX 16 AL_MAP_LUT1 17 AL_MAP_LUT2 18 AL_MAP_LUT3 19 AL_MAP_LUT4 20 AL_MAP_LUT5 21 AL_MAP_LUT6 22 AL_MAP_MULT_ADD 23 AL_MAP_MUX4 24 AL_MAP_SEQ 25
pack 5 45 AL_MAP_LUT1 26 AL_MAP_LUT1__default 27 AL_MAP_LUT2 28 AL_MAP_LUT2__default 29 AL_MAP_LUT3 30 AL_MAP_LUT3__default 31 AL_MAP_LUT4 32 AL_MAP_LUT4__default 33 AL_MAP_LUT5 34 AL_MAP_LUT5__default 35 AL_MAP_LUT6 36 AL_MAP_LUT6__default 37 AL_MAP_SEQ 38 AL_MAP_SEQ__default 39 AL_PHY_BRAM32K__default 40 AL_PHY_BRAM__default 41 AL_PHY_CLKDIV__default 42 AL_PHY_FIFO__default 43 AL_PHY_GCLK__default 44 AL_PHY_IOCLK__default 45 AL_PHY_LSLICE__lble5_2 46 AL_PHY_LSLICE__lble6_1 47 AL_PHY_LSLICE__lble_mux4_2 48 AL_PHY_LSLICE__lseq_2 49 AL_PHY_MSLICE__mble4_2 50 AL_PHY_MSLICE__mble5_1 51 AL_PHY_MSLICE__mble_adder_2 52 AL_PHY_MSLICE__mble_gate4_2 53 AL_PHY_MSLICE__mble_mux4_1 54 AL_PHY_MSLICE__mseq_2 55 AL_PHY_MULT18__mult18x18_1 56 AL_PHY_MULT18__mult9x9_2 57 AL_PHY_PAD__default 58 AL_PHY_VPAD__default 59 lble5 60 lble6 61 lble_mux4 62 mble4 63 mble5 64 mble_adder 65 mble_gate4 66 mble_mux4 67 mult18x18 68 mult9x9 69 seq 70
phy 6 19 AL_PHY_BANKREF 71 AL_PHY_BRAM 72 AL_PHY_BRAM32K 73 AL_PHY_CENTMUX 74 AL_PHY_CLKDIV 75 AL_PHY_CONFIG 76 AL_PHY_CSB 77 AL_PHY_FIFO 78 AL_PHY_GCLK 79 AL_PHY_IOCLK 80 AL_PHY_LSLICE 81 AL_PHY_MSLICE 82 AL_PHY_MULT18 83 AL_PHY_OSC 84 AL_PHY_PAD 85 AL_PHY_PIB 86 AL_PHY_PLL 87 AL_PHY_PREMUX 88 AL_PHY_VPAD 89
pin_test_tdpack 1 1 pin_test 90
pin_test_tdread 1 1 pin_test 91
pin_test_tdrtl 1 1 pin_test 92
work 0 1 pin_test 93
AL_LOGIC_DRAM16X4 2 5 1 0 1
di 1 raddr 2 waddr 3 wclk 4 we 5
do 6

Despite some frustration it is still interesting to pursue.

[pcprogrammer]

Again a small step in understanding the fabric of the FPGA.

Decided to visualize the configuration bits within the FPGA structure. Still have to figure out how the bits relate to the information in the Anlogic database files. The visualization did make things more clear. The FPGA has an array of configuration bits which is 1075 bits wide and 2052 bits tall. These map to the tiles (blocks) as can be seen in the bitmap. I expect that the bits within the tiles use a similar x,y coordinate system. Within the tilegrid tiles can have multiple parts. This is only in the x direction, causing the number of blocks to double. In the y direction blocks can be extended over several tiles. This is the case for the embedded memory and the left and right io blocks.

Attached is a zip of the original FPGA data so far and a zip of the Anlogic json database for those interested. The code to make the bitmap and other data is still work in progress, but if anyone wants it as is just let me know.