Wednesday, 2019-03-06

*** tpb has joined #symbiflow00:00
*** Bertl is now known as Bertl_zZ00:01
*** proteusguy has joined #symbiflow00:35
*** _whitelogger has quit IRC00:49
*** _whitelogger has joined #symbiflow00:52
*** proteusguy has quit IRC01:20
*** citypw has joined #symbiflow03:18
*** sf-slack has quit IRC04:17
*** sf-slack1 has joined #symbiflow04:17
*** digshadow has left #symbiflow04:22
*** dfsdf has joined #symbiflow04:53
*** dfsdf has quit IRC05:07
*** OmniMancer has joined #symbiflow05:37
*** shivanshu1333 has joined #symbiflow07:17
*** t2shashwat has joined #symbiflow07:26
*** shivanshu1333 has quit IRC09:25
*** tmichalak1 has quit IRC10:04
*** citypw has quit IRC10:09
*** citypw has joined #symbiflow12:02
*** Bertl_zZ is now known as Bertl12:22
sf-slack1<pgielda> Hi Bertl12:31
Bertlso I'm still trying to wrap my head around the mapping between features and frame data12:31
Bertlfor example in 'CLBLL_L.SLICEL_X0.ALUT.INIT[00] 32_15', according to the code, the 32_15 means 'word column' 32 and 'word bit' number 1512:33
Bertlhte mapping to frame adds the 'word column' to the base address12:34
Bertland the 'word bit' to the offset (multiplied by the word size)12:34
Bertlthe 'frames' entry in e.g. "CLBLL_L_X20Y68" which is 36 probably refers to the total number of frames involved in the tile12:36
Bertlnow to me it seems that this can he horizontal or vertical and maybe even with gaps?12:37
sf-slack1<acomodi> yes, it should be like that. 32 is the offset and 15 the bit in that word. So 32_15 means the 15th bit in the 32nd word, starting from the tile base address12:37
Bertlacomodi: hmm, you make it sound like it would be the same frame, but I'm not so sure about that12:39
Bertlthe frame is identified by the frame address, which for me is the base address plus the word column12:41
Bertlthe offset in this frame then is the 'base offset' times word size plus the word_bit (offset in the bitstream)12:42
sf-slack1<kgugala> Bertl: did you read this
tpbTitle: Configuration Project X-Ray documentation (at
Bertlyes, I did read that, I also know how the frames are organized (not so much what the content means though)12:44
Bertlso to get back to the example above, I would conclude that INIT[00] for CLBLL_L_X20Y68 is located at:12:46
Bertlframe 0x00400A00 + 32 = 0x00400A2012:47
Bertlbit offset 36 * 32 + 15 = 1167 or word 36, bit 1512:49
sf-slack1<tmichalak> Bertl: I guess this code speaks better than words:
tpbTitle: prjxray/ at 05055fe0287ab33d956ffc67a773a88208f9ea9e · SymbiFlow/prjxray · GitHub (at
Bertlwell, that's what I've concluded from the code :)12:50
Bertlwhat I'm looking for is just confirmation that I didn't misinterpret it12:51
sf-slack1<tmichalak> yes, I guess you could say that 32_15 in this case means bit_00400A20_36_15, ie. frame add 0x00400A20, word 36, bit 1512:56
Bertlgreat! thanks for the confirmation!12:57
*** tmichalak has joined #symbiflow13:04
*** tmichalak has left #symbiflow13:05
*** tmichalak has joined #symbiflow13:05
*** OmniMancer has quit IRC14:09
sf-slack1<acomodi> update on picosoc: it's alive on HW! I have divided the clk 100MHz -> ~1MHz and now the leds are blinking (extremely slow) and everytime they do there is an UART data transmission to the host (I couldn't capture it yet, I'll use a logic analyzer to test it). There seems to be a timing issue which VPR cannot solve. Anyway it is executing code located in BRAM14:46
*** Ayazulla has joined #symbiflow14:52
sf-slack1<mkurc> @acomodi You can try changing the prescaler in code. Now it is 100e6/115200 ~ 868.14:52
*** Ayazulla has left #symbiflow14:52
sf-slack1<acomodi> @mkurc Could try that as well, where is the prescaler set?14:56
sf-slack1<mkurc> @acomodi Look into the `firmware/firmware.c` file at line 567.14:57
sf-slack1<mkurc> just at the beginning of the main()14:57
sf-slack1<acomodi> great, thanks14:58
*** felicis has joined #symbiflow14:59
*** felicis has quit IRC15:00
sf-slack1<mkurc> Update on tile grid split: I've managed to split all CLBs into individual slices along with all (almost all) the connections. I integrated it with the symbiflow build system and managed to generate a fasm files for xc7/tests/counter and xc7/tests/chain_packing designs. Still cannot generate a bitstream - its a work in progress. Here is a WIP pull request:
tpbTitle: WIP - Tile grid split by mkurc-ant · Pull Request #435 · SymbiFlow/symbiflow-arch-defs · GitHub (at
litghostWhy should getting a bitstream be hard?  Just emit the original tile prefixes, and everything should just work15:37
litghostThe FASM features should not change at all15:37
litghostacomodi: That's great!  It is totally unsuprising there is a timing issue.  It is time to emit a routing graph with timing information that isn't random values picked out of a hat!15:38
sf-slack1<mkurc> @litghost I never said that it'll be hard :slightly_smiling_face:15:39
*** t2shashwat has quit IRC16:05
sf-slack1<acomodi> mithro: can the db be updated with the latest info (in particular regarding the BRAM after the 025-bram fuzzer changes applied by litghost)?16:09
*** citypw has quit IRC16:27
sf-slack1<acomodi> Picosoc works at 25MHz on HW, UART included16:50
sf-slack1<acomodi> I will clean and issue a PR16:51
litghostacomodi: What about 50 MHz?16:52
sf-slack1<acomodi> I can test that as well, I'll keep you updated16:53
sf-slack1<acomodi> litghost: to have picosoc compiling there are two ways. The first is to set the Y_MAX in the harness to 51 instead of 52 (so the BRKH_INT row is not considered). The second would be to integrate the BRKH_INT bits through the `ppips` fuzzer. Which way you think is better?17:39
litghostacomodi: Shrink the Y_MAX17:39
sf-slack1<mkurc> @acomodi Don't forget to update the uart divider in firmware and attach the hex file.17:40
sf-slack1<acomodi> @mkurc Yep, I'll do that17:42
mithroacomodi: I'm pretty sure I pushed that already?17:43
sf-slack1<acomodi> mithro: Yes indeed, I have just checked that, I was using the previous version17:45
*** proteusguy has joined #symbiflow18:44
*** proteusguy has quit IRC19:27
*** proteusguy has joined #symbiflow19:45
mithrolitghost: Did my comment on make sense?19:47
tpbTitle: WIP - Tile grid split by mkurc-ant · Pull Request #435 · SymbiFlow/symbiflow-arch-defs · GitHub (at
litghostmithro: Yes and no.  If equivalent tiles are implemented it wont matter.  If the output tiles were only SLICE_L and SLICE_M, then disabling SLICE_M carry chains would enable 6/8 chains.  With the presence of round-robin prepacking and specialized carry chains, it won't matter either.19:48
litghostmithro: I think there is "ease of use" to emitting only SLICE_L and SLICE_M in terms of resource utilization19:49
litghostbut that is potentially a second order problem19:49
mithrolitghost: You mean because the sites will say that they can have both have CLBLL_L_SLICEL_X0Y0 and CLBLL_L_SLICEL_X1Y0 ?19:53
litghostmithro: Effectively, ya.19:53
*** proteusguy has quit IRC19:54
* mithro litghost: It feels to me like the line TILE_TYPES INT_R INT_L CLBLL_R CLBLL_L CLBLM_R CLBLM_L BRAM_L19:58
mithroShould become19:58
litghostI don't entirely disagree19:59
*** proteusguy has joined #symbiflow20:07
*** proteusguy has quit IRC20:56
*** proteusguy has joined #symbiflow22:26
*** proteusguy has quit IRC22:37
*** proteusguy has joined #symbiflow22:50
*** proteusguy has quit IRC23:04
*** proteusguy has joined #symbiflow23:19

Generated by 2.13.1 by Marius Gedminas - find it at!