Bug in gowin_unpack.py

[pecostm32]

Not a serious issue, but in gowin_unpack.py there is a typo in the definition:

//The DSP has 9 cells: the main one and a group of auxiliary ones. def get_dsp_main_cell(db, row, col, typ): if type[-6:-2] == '_AUX': col = 1 + (col - 1) // 9 return row, col

It should be:

//The DSP has 9 cells: the main one and a group of auxiliary ones. def get_dsp_main_cell(db, row, col, typ): if typ[-6:-2] == '_AUX': col = 1 + (col - 1) // 9 return row, col

The variable typ is not used as is, instead type is used and this makes the code fail when unpacking a bitstream with used DSP cells in it. With the fix it runs through without errors.

Any way thanks for doing the hard investigative work. It would be nice if there was a bit more documentation about how the bitsream relates to the tiles in the FPGA, but you can't have it all I guess :)

[pepijndevos]

Nice catch!

I'm actually working on better documentation, so any suggestions are welcome.

Sent from Proton Mail Android

-------- Original Message -------- On 19/10/2024 19:34, pecostm32 wrote:

Not a serious issue, but in gowin_unpack.py there is a typo in the definition:

The DSP has 9 cells: the main one and a group of auxiliary ones.

def get_dsp_main_cell(db, row, col, typ): if type[-6:-2] == '_AUX': col = 1 + (col - 1) // 9 return row, col

It should be:

The DSP has 9 cells: the main one and a group of auxiliary ones.

def get_dsp_main_cell(db, row, col, typ): if typ[-6:-2] == '_AUX': col = 1 + (col - 1) // 9 return row, col

The variable typ is not used as is, instead type is used and this makes the code fail when unpacking a bitstream with used DSP cells in it. With the fix it runs through without errors.

Any way thanks for doing the hard investigative work. It would be nice if there was a bit more documentation about how the bitsream relates to the tiles in the FPGA, but you can't have it all I guess :)

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[pecostm32]

@pepijndevos For the documentation I see three documents that could be helpful.

1) Bitstream. A full description of the three types in existence. Text, binary and extended binary. A precise layout specifying the header, frames and footer and how they are formatted.

The text version uses single bit binary coding, which leads to big files, with linefeed as a separation between the commands and frames.

The binary type uses bytes to code 8 bits in one byte and needs decoding based on the predetermined lengths, like 20 0xFF as a start sequence, 4 byte preamble, commands based on predetermined lengths per command. (4 byte and 8 byte). The frame length, which might vary per FPGA version. (430 bytes for GW2A-18).

The extended binary, where there is a info length followed by the same info found at the start of the text version. The rest of the file is the same as the binary version.

2) Fuse file description with a full explanation of the way it is constructed.

3) A description of how the configuration bits in the bitsream relate to the different tiles in the FPGA.

As a side note, your work helped me in finishing my reversal of an Anlogic AL3-10 FPGA design. (https://github.com/pecostm32/Anlogic_AL3-10_Analyzing) The information in the prjtang (https://github.com/mmicko/prjtang) helped a lot to get it started, but missed information about how the routing worked, and your document architecture.md revealed how it is done in the Gowin devices, and that same setup is used in the Anlogic devices. So thanks for that.