sf-slack has quit [Remote host closed the connection]
sf-slack1 has joined #symbiflow
digshadow has left #symbiflow [#symbiflow]
dfsdf has joined #symbiflow
dfsdf has quit [Ping timeout: 256 seconds]
OmniMancer has joined #symbiflow
shivanshu1333 has joined #symbiflow
t2shashwat has joined #symbiflow
shivanshu1333 has quit [Quit: Page closed]
tmichalak1 has quit [Read error: Connection reset by peer]
citypw has quit [Ping timeout: 245 seconds]
citypw has joined #symbiflow
Bertl_zZ is now known as Bertl
<Bertl>
Greeting!
<sf-slack1>
<pgielda> Hi Bertl
<Bertl>
so I'm still trying to wrap my head around the mapping between features and frame data
<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
<Bertl>
hte mapping to frame adds the 'word column' to the base address
<Bertl>
*the
<Bertl>
and the 'word bit' to the offset (multiplied by the word size)
<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
<Bertl>
now to me it seems that this can he horizontal or vertical and maybe even with gaps?
<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
<Bertl>
acomodi: hmm, you make it sound like it would be the same frame, but I'm not so sure about that
<Bertl>
the frame is identified by the frame address, which for me is the base address plus the word column
<Bertl>
the offset in this frame then is the 'base offset' times word size plus the word_bit (offset in the bitstream)
<Bertl>
well, that's what I've concluded from the code :)
<Bertl>
what I'm looking for is just confirmation that I didn't misinterpret it
<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
<Bertl>
great! thanks for the confirmation!
tmichalak has joined #symbiflow
tmichalak has left #symbiflow [#symbiflow]
tmichalak has joined #symbiflow
OmniMancer has quit [Quit: Leaving.]
<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
Ayazulla has joined #symbiflow
<sf-slack1>
<mkurc> @acomodi You can try changing the prescaler in code. Now it is 100e6/115200 ~ 868.
Ayazulla has left #symbiflow [#symbiflow]
<sf-slack1>
<acomodi> @mkurc Could try that as well, where is the prescaler set?
<sf-slack1>
<mkurc> @acomodi Look into the `firmware/firmware.c` file at line 567.
<sf-slack1>
<mkurc> just at the beginning of the main()
<sf-slack1>
<acomodi> great, thanks
felicis has joined #symbiflow
felicis has quit [Client Quit]
<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
<litghost>
Why should getting a bitstream be hard? Just emit the original tile prefixes, and everything should just work
<litghost>
The FASM features should not change at all
<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!
<sf-slack1>
<mkurc> @litghost I never said that it'll be hard :slightly_smiling_face:
t2shashwat has quit [Ping timeout: 256 seconds]
<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)?
citypw has quit [Ping timeout: 250 seconds]
<sf-slack1>
<acomodi> Picosoc works at 25MHz on HW, UART included
<sf-slack1>
<acomodi> I will clean and issue a PR
<litghost>
acomodi: What about 50 MHz?
<sf-slack1>
<acomodi> I can test that as well, I'll keep you updated
<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?
<litghost>
acomodi: Shrink the Y_MAX
<sf-slack1>
<mkurc> @acomodi Don't forget to update the uart divider in firmware and attach the hex file.
<sf-slack1>
<acomodi> @mkurc Yep, I'll do that
<mithro>
acomodi: I'm pretty sure I pushed that already?
<sf-slack1>
<acomodi> mithro: Yes indeed, I have just checked that, I was using the previous version
<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.
<litghost>
mithro: I think there is "ease of use" to emitting only SLICE_L and SLICE_M in terms of resource utilization
<litghost>
but that is potentially a second order problem
<mithro>
litghost: You mean because the sites will say that they can have both have CLBLL_L_SLICEL_X0Y0 and CLBLL_L_SLICEL_X1Y0 ?
<litghost>
mithro: Effectively, ya.
proteusguy has quit [Ping timeout: 252 seconds]
* 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