What does the "desync_flag" parameter do?

[RobB720]

Hi,

We are having an issue synthesising the configuration block as I have an inconsistency in the setting of the "desync_flag" paramater.

What should this be set to?

For information, the demo has it set to 20 - which is the same as MaxFramesPerCol=20 and in the BRAM block "WRITE_ENABLE_FROM_DATA = 20".

Many thanks,
Rob.

[KelvinChung2000]

I don't know what that does, either. I have forwarded it to @dirk-koch and am still waiting for a reply. He is quite busy recently, so might take a while.

[KelvinChung2000]

Dirk:
We allow headers in front of a bitstream.
This can be handy for various situations, including adding software binaries into a single file.
However, in order to encode when we should start with interpreting the bitstream, we mandate that the header is padded to 32-bit (4 bytes) and that the first word is FAB0 FAB1.
We configure frame by frame and each frame starts with an 32-bit address and then one extra 32-bit word per fabric row (CLB row or elementary block). This is slightly different to Xilinx who do a frame autoincrement and in FABulous you may write frames in arbitrary order and even multiple times, if required.
This is used to initialize BRAMs and the register-file tiles.
We had deliberately not foreseen an extra port for configuration (nobody would do that); and instead of multiplexing an existing port, we can directly use the fabric to initialize anything (takes a little more time, if needed, but is cheaper).
Anyway, in order to tell the FPGA (i.e. the configuration state machine in ConfigFSM.v) that we are done with configuration (a time out is not a clean way to do that), we simply use one bit in the address field of a frame to indicate that. You can then even send meta data again and config data.
By using different FAB0 FABx keys, we could configure multiple paralleled fabrics from the same bistream

One thing that we will change in the bitstream format is that the we will also use a binary format to address frames within a column (so a binary format for both major and minor addresses.
Right now, we have a 20-bit bitmask for frames (minor addresses) which, well limits the number of frames to 20 (without further encoding). And with this, we have 32x20 config bits, which is likely too little for LUT-6 fabrics.