How Remapping works #261
-
|
After reading the documentation, I'm still a little confused about bitstream remapping. First, I checked the generated .v file and paper “How to shrink my FPGA” to understand its role in changing configMem to optimize the area, but I didn't understand how to change? For example, why does configMem.csv in LUT tile in demo project mask some bits in some frames? The documentation states that the user does not need to change the configMem, but I noticed in the demo project that the configmem.csv for the LUT4AB tile was provided before any moves, but not for the other tiles. Should I change configMem.csv if I replace original BLE with another? Secondly, I don't understand the role of bitstream remapping after physical implementation at all, it seems to be used to generate readable hex files as a reference table? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 5 replies
-
|
The configmem.csv we provided for LUT4AB is the best configuration we got using the methodology from the paper. We have only done the optimisation on the LUT4AB tile, since it is the dominant tile in the design. The frame data and frame strobe can be think of as a grid. In a less dense area not all grid point within an area is used, so some of the bit is masked off. During PnR we do not need to care where the configuration bit is, only what feature is required. After the physical implementation, we will need a way to tell which latch is for that feature. The mapping is linking the required feature to the where it should physically locate. |
Beta Was this translation helpful? Give feedback.
-
|
Does <ConfigBits_ranges> in ConfigMem.csv represent its physical location? |
Beta Was this translation helpful? Give feedback.
-
|
Oh, I think that's where it is in the bin file. |
Beta Was this translation helpful? Give feedback.
-
|
The terminology used make explaining very difficult 🤦🏻. If you take the example above, and count the 1's you should get 26, which matches the 25:0, 26 bit in total. The feature bit 0 is mapped to frame 16 bit 7. In this case the feature bit 123 is mapped to frame 16 bit 7. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for your patience! |
Beta Was this translation helpful? Give feedback.
-
|
By default we will map your most significant configuration bit to frame 0 bit 0 and increment by bit then by frame. Then if you want to do optimisation, let say by putting the most significant configuration bit at the frame 20 bit 32 instead of frame 0 bit 0 to yield better area, then you modify the configmem.csv |
Beta Was this translation helpful? Give feedback.
The configmem.csv we provided for LUT4AB is the best configuration we got using the methodology from the paper. We have only done the optimisation on the LUT4AB tile, since it is the dominant tile in the design.
The frame data and frame strobe can be think of as a grid. In a less dense area not all grid point within an area is used, so some of the bit is masked off.
During PnR we do not need to care where the configuration bit is, only what feature is required. After the physical implementation, we will need a way to tell which latch is for that feature. The mapping is linking the required feature to the where it should physically locate.