| *** tpb has joined #symbiflow | 00:00 | |
| *** Bertl is now known as Bertl_zZ | 00:01 | |
| *** proteusguy has joined #symbiflow | 00:35 | |
| *** _whitelogger has quit IRC | 00:49 | |
| *** _whitelogger has joined #symbiflow | 00:52 | |
| *** proteusguy has quit IRC | 01:20 | |
| *** citypw has joined #symbiflow | 03:18 | |
| *** sf-slack has quit IRC | 04:17 | |
| *** sf-slack1 has joined #symbiflow | 04:17 | |
| *** digshadow has left #symbiflow | 04:22 | |
| *** dfsdf has joined #symbiflow | 04:53 | |
| *** dfsdf has quit IRC | 05:07 | |
| *** OmniMancer has joined #symbiflow | 05:37 | |
| *** shivanshu1333 has joined #symbiflow | 07:17 | |
| *** t2shashwat has joined #symbiflow | 07:26 | |
| *** shivanshu1333 has quit IRC | 09:25 | |
| *** tmichalak1 has quit IRC | 10:04 | |
| *** citypw has quit IRC | 10:09 | |
| *** citypw has joined #symbiflow | 12:02 | |
| *** Bertl_zZ is now known as Bertl | 12:22 | |
| Bertl | Greeting! | 12:30 |
|---|---|---|
| sf-slack1 | <pgielda> Hi Bertl | 12:31 |
| Bertl | so I'm still trying to wrap my head around the mapping between features and frame data | 12:31 |
| Bertl | for 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 15 | 12:33 |
| Bertl | hte mapping to frame adds the 'word column' to the base address | 12:34 |
| Bertl | *the | 12:34 |
| Bertl | and the 'word bit' to the offset (multiplied by the word size) | 12:34 |
| Bertl | the 'frames' entry in e.g. "CLBLL_L_X20Y68" which is 36 probably refers to the total number of frames involved in the tile | 12:36 |
| Bertl | now 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 address | 12:37 |
| Bertl | acomodi: hmm, you make it sound like it would be the same frame, but I'm not so sure about that | 12:39 |
| Bertl | the frame is identified by the frame address, which for me is the base address plus the word column | 12:41 |
| Bertl | the 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 https://prjxray.readthedocs.io/en/latest/architecture/configuration.html? | 12:43 |
| tpb | Title: Configuration Project X-Ray documentation (at prjxray.readthedocs.io) | 12:43 |
| Bertl | yes, I did read that, I also know how the frames are organized (not so much what the content means though) | 12:44 |
| Bertl | so to get back to the example above, I would conclude that INIT[00] for CLBLL_L_X20Y68 is located at: | 12:46 |
| Bertl | frame 0x00400A00 + 32 = 0x00400A20 | 12:47 |
| Bertl | bit offset 36 * 32 + 15 = 1167 or word 36, bit 15 | 12:49 |
| sf-slack1 | <tmichalak> Bertl: I guess this code speaks better than words: https://github.com/SymbiFlow/prjxray/blob/05055fe0287ab33d956ffc67a773a88208f9ea9e/utils/segprint.py#L68 | 12:49 |
| tpb | Title: prjxray/segprint.py at 05055fe0287ab33d956ffc67a773a88208f9ea9e · SymbiFlow/prjxray · GitHub (at github.com) | 12:49 |
| Bertl | well, that's what I've concluded from the code :) | 12:50 |
| Bertl | what I'm looking for is just confirmation that I didn't misinterpret it | 12: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 15 | 12:56 |
| Bertl | great! thanks for the confirmation! | 12:57 |
| *** tmichalak has joined #symbiflow | 13:04 | |
| *** tmichalak has left #symbiflow | 13:05 | |
| *** tmichalak has joined #symbiflow | 13:05 | |
| *** OmniMancer has quit IRC | 14: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 BRAM | 14:46 |
| *** Ayazulla has joined #symbiflow | 14:52 | |
| sf-slack1 | <mkurc> @acomodi You can try changing the prescaler in code. Now it is 100e6/115200 ~ 868. | 14:52 |
| *** Ayazulla has left #symbiflow | 14: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, thanks | 14:58 |
| *** felicis has joined #symbiflow | 14:59 | |
| *** felicis has quit IRC | 15: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: https://github.com/SymbiFlow/symbiflow-arch-defs/pull/435 | 15:05 |
| tpb | Title: WIP - Tile grid split by mkurc-ant · Pull Request #435 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 15:05 |
| litghost | Why should getting a bitstream be hard? Just emit the original tile prefixes, and everything should just work | 15:37 |
| litghost | The FASM features should not change at all | 15:37 |
| litghost | acomodi: 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 IRC | 16: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 IRC | 16:27 | |
| sf-slack1 | <acomodi> Picosoc works at 25MHz on HW, UART included | 16:50 |
| sf-slack1 | <acomodi> I will clean and issue a PR | 16:51 |
| litghost | acomodi: What about 50 MHz? | 16:52 |
| sf-slack1 | <acomodi> I can test that as well, I'll keep you updated | 16: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 |
| litghost | acomodi: Shrink the Y_MAX | 17: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 that | 17:42 |
| mithro | acomodi: 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 version | 17:45 |
| *** proteusguy has joined #symbiflow | 18:44 | |
| *** proteusguy has quit IRC | 19:27 | |
| *** proteusguy has joined #symbiflow | 19:45 | |
| mithro | litghost: Did my comment on https://github.com/SymbiFlow/symbiflow-arch-defs/pull/435 make sense? | 19:47 |
| tpb | Title: WIP - Tile grid split by mkurc-ant · Pull Request #435 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 19:47 |
| litghost | mithro: 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 |
| litghost | mithro: I think there is "ease of use" to emitting only SLICE_L and SLICE_M in terms of resource utilization | 19:49 |
| litghost | but that is potentially a second order problem | 19:49 |
| mithro | litghost: You mean because the sites will say that they can have both have CLBLL_L_SLICEL_X0Y0 and CLBLL_L_SLICEL_X1Y0 ? | 19:53 |
| litghost | mithro: Effectively, ya. | 19:53 |
| *** proteusguy has quit IRC | 19: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_L | 19:58 | |
| mithro | Should become | 19:58 |
| mithro | TILE_TYPES INT_R INT_L SLICEL SLICEM BRAM_L | 19:59 |
| litghost | I don't entirely disagree | 19:59 |
| *** proteusguy has joined #symbiflow | 20:07 | |
| *** proteusguy has quit IRC | 20:56 | |
| *** proteusguy has joined #symbiflow | 22:26 | |
| *** proteusguy has quit IRC | 22:37 | |
| *** proteusguy has joined #symbiflow | 22:50 | |
| *** proteusguy has quit IRC | 23:04 | |
| *** proteusguy has joined #symbiflow | 23:19 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!