Friday, 2019-05-10

*** tpb has joined #symbiflow00:00
*** hzeller_ has joined #symbiflow00:37
hackerfooI got picosoc to use 32 bit dist. RAM. How do I know if it works?00:46
litghosthackerfoo: Look in the README?00:48
litghosthackerfoo: I think it blinks an LED?00:48
tpbTitle: symbiflow-arch-defs/firmware.c at master · SymbiFlow/symbiflow-arch-defs · GitHub (at
hackerfooI didn't see anything in the README00:48
litghosthackerfoo: Ya, me neither, we should fix that00:49
litghosthackerfoo: The murax one describes the expected behavior00:49
litghosthackerfoo: Looks like it opens a little command problem on the UART?00:50
litghosthackerfoo: I know acomodi tested picosoc last go around00:51
tpbTitle: symbiflow-arch-defs/firmware.c at master · SymbiFlow/symbiflow-arch-defs · GitHub (at
litghosthackerfoo: Might be 115200 baud?00:51
hackerfooNo luck. I just get a repeating character.01:01
litghosthackerfoo: I would wait till acomodi is around01:07
hackerfooOkay. Until then, I'm retrying without my changes (using 64 bit dist. RAM)01:08
hackerfooIt works with 64 bit RAM. I'll have to make a simpler test.01:27
*** futarisIRCcloud has quit IRC02:03
*** hzeller_ has quit IRC02:10
*** futarisIRCcloud has joined #symbiflow02:10
mithrohackerfoo: Well, I just discovered the issue you mentioned about being unable to chain muxes02:15
hackerfoomithro: That you can't do it directly? litghost suggested putting a black box between them, but I think that will cause other problems.02:17
mithrohackerfoo: You can do it with empty pb_type objects02:17
hackerfooYeah, if I understand what VPR is doing, it won't know what to do with that. I could be wrong, though.02:19
hackerfooIt won't know when to route through the empty pb_type.02:22
hackerfooI think that I can maybe make the flattening approach work with pack_pattern, otherwise VPR needs to support muxing buses.02:25
mithrohackerfoo: I'm sure I had fixed the ability to route through empty pb_type objects?03:01
hackerfoomithro: I certainly could be wrong; I didn't try it. Is there an example?03:10
tpbTitle: symbiflow-arch-defs/lutff3.pb_type.xml at master · SymbiFlow/symbiflow-arch-defs · GitHub (at
mithrohackerfoo: In fact I think that example comes from me testing exactly this issue03:15
*** hzeller_ has joined #symbiflow03:15
hackerfoomithro: I'm confused. Does it work? If so, what's the issue you discovered?03:38
hackerfooOr so you mean you rediscovered the solution?03:38
hackerfoo*Or do you03:39
*** futarisIRCcloud has quit IRC04:13
*** kraiskil__ has joined #symbiflow06:54
sf-slack2<acomodi> @hackerfoo picosoc expected behavior is to blink the first four leds (at higher frequency than human eye can track, so you would need an oscilloscope to see that or in turn add another clock divider in `basys3_demo.v`)08:26
sf-slack2<acomodi> @hackerfoo: then on UART there's a menu with 9 options, and it just halts there waiting for an input08:27
sf-slack2<acomodi> @hackerfoo: sorry, let me rephrase, there is no menu, just a `command>` line waiting for the input (you can type `9` or `0` and a benchmark routing will be run)08:31
sf-slack2<acomodi> @hackerfoo: also the first four leds are actually blinking at a normal rate, so no need of oscilloscope, I was mistaken. I have just ran a clean build on the latest symbiflow-arch-defs.08:40
sf-slack2<acomodi> @hackerfoo: this should be the output on terminal
tpbTitle: Terminal ready Press ENTER to continue.. Press ENTER to continue.. Press ENTE - (at
sf-slack2<acomodi> I will update the README.md08:43
*** jevinskie has quit IRC08:55
*** kraiskil__ has quit IRC08:56
*** jevinskie has joined #symbiflow08:57
*** Bertl_zZ is now known as Bertl09:18
*** futarisIRCcloud has joined #symbiflow09:34
*** yang1yang1 has joined #symbiflow10:18
*** yang1yang1 has left #symbiflow10:19
*** kraiskil has joined #symbiflow10:46
*** alexhw has quit IRC10:59
*** alexhw has joined #symbiflow11:01
*** futarisIRCcloud has quit IRC11:43
*** kraiskil has quit IRC11:53
*** OmniMancer has joined #symbiflow12:34
sf-slack2<mkurc> I prepared a document which describes my idea of adding FASM metadata to V2X:
tpbTitle: Google Docs - create and edit documents online, for free. (at
*** kraiskil has joined #symbiflow12:42
*** kraiskil_ has joined #symbiflow13:26
*** OmniMancer has quit IRC13:29
*** kraiskil has quit IRC13:29
*** Vonter has quit IRC13:45
*** tharaka27 has joined #symbiflow13:46
*** tharaka27 has quit IRC13:48
*** kraiskil_ has quit IRC14:47
*** Bertl is now known as Bertl_oO15:18
*** kraiskil_ has joined #symbiflow15:27
*** hzeller_ has quit IRC15:53
*** kraiskil_ has quit IRC16:07
*** jevinskie has quit IRC16:45
*** jevinskie has joined #symbiflow16:47
*** Vonter has joined #symbiflow16:47
*** jevinskie has quit IRC16:47
*** kraiskil_ has joined #symbiflow16:57
*** Bertl_oO is now known as Bertl17:26
*** jevinskie has joined #symbiflow17:32
*** jevinskie has quit IRC17:35
*** jevinskie has joined #symbiflow17:39
*** jevinskie has quit IRC17:52
*** kraiskil_ has quit IRC18:16
mithrokgugala: Morning?21:00
sf-slack2<kgugala> @mithro evening on this side of Atlantic21:09
sf-slack2<kgugala> :slightly_smiling_face:21:10
mithrokgugala: I've ended up doing a pretty big rework of the program21:10
sf-slack2<kgugala> great, I'd like to test it with verilogs I have for arch definitions21:11
*** futarisIRCcloud has joined #symbiflow21:55
hackerfoo> Because the 3 sites with the BRAM are affected by the BRAM mode, each site cannot be handled independently.22:14
hackerfooDoes this mean you can only use 18k or 36k RAM blocks for the whole device?22:15
hackerfooOr just per-block of one 36k or two 18k.22:16
elmshackerfoo: My very limited understanding is that in each tile you can either use 18k or 36k. In a tile vivado shows them as 2 18k sites and 1 36k site (3 sites total).22:35
hackerfooThanks. I'm looking at Vivado right now, and it makes more sense.22:36
hackerfooIt's weird that it shows them as 3 separate things. It seems like a RAMB36E1 would be built out of two RAM18E1's.22:39
hackerfooSo I guess I don't need to combine RAMB18E1s in any way to get a RAMB36E1.22:41
litghosthackerfoo: A RAM36E1 is kind of built out of two RAM18E1, but the vivado site definition is of 3 sites22:42
litghosthackerfoo: Given that we have a routing graph for all 3 sites, we can just wire our blackbox at the site location of the RAMB3622:42
hackerfoolitghost: Is this what you meant when you said they were routed differently?22:42
litghosthackerfoo: Yes22:42
litghosthackerfoo: It is also worth noting that the RAMB36 has more routed pins than the other two sites (kind of)22:43
litghosthackerfoo: Consider the upper address lines22:43
litghosthackerfoo: On the RAM18 sites they are "ADDRATIEHIGH0/1"22:43
litghosthackerfoo: On the RAM36 site it is "ADDRA15" or whateever22:44
hackerfooDo you know if the bits in the bitstream overlap? Is this an artifact of how Vivado works, or somehow present in the hardware?22:44
hackerfooAt any rate, we probably have to copy Vivado because that's what the fuzzers use, at least until we have a better understanding.22:45
litghosthackerfoo: Doubled up22:47
litghosthackerfoo: The bits are doubled up22:47
litghosthackerfoo: So take DOA_REG, RAM36 sets both the upper and lower RAM18 DOA_REG's22:47
litghosthackerfoo: This only applies to port wide examples22:48
litghosthackerfoo: SRVAL0 for example on the upper and lower RAM18's corisponds to SRVAL[0] and SRVAL[16] (unclear if the upper or lower is 0 or 16)22:49
litghosthackerfoo: etc22:49
hackerfooInteresting. I wonder why Vivado represents block RAM this way.22:49
litghosthackerfoo: I think if you site down and diagram out the RAM36 versus the RAM18 it will make sense22:50
litghosthackerfoo: Consider that ECC support is only in the RAM36 (I think)22:50
litghosthackerfoo: Along with a handful of other features22:50
tpbTitle: prjxray-db/segbits_bram_l.db at master · SymbiFlow/prjxray-db · GitHub (at
litghosthackerfoo: Note how few bits are RAM36 only22:51
litghosthackerfoo: But they do exist22:51
litghosthackerfoo: It is worth noting that there we have not found a bit that toggles between a RAM36 and a RAM18, so the address logic for the BRAM36 is likely always active22:52
hackerfooI would think drawing it as a block that contains 2x18k + ECC blocks would make more sense, the way CLBs have multiple LUTs.22:52
litghosthackerfoo: I don't disagree22:53
hackerfooXilinx has a lot of overlapping diagrams that show different interpretations of the actual hardware. It's hard to infer what is real.22:55
hackerfooIf a RAMB18E1 has two almost independent halves, it seems like a RAMB36E1 would actually have four mostly independent quarters, so you could use it as a quad port RAM. I'm not sure why that isn't exposed. Maybe it's not useful?23:00
litghosthackerfoo: I don't think the BRAM address decoders are that flexible23:00
litghosthackerfoo: The reason you use a RAMB36 over a RAMB18 is you need something wider or deeper than the RAMB18 can do, or you want ECC23:01
*** _whitelogger has quit IRC23:14
*** _whitelogger has joined #symbiflow23:16
hackerfooHardware people are much better at naming things, no ManagerBeanFactories. For example, who wouldn't immediately understand what RSTREGARSTREG means? It's memorable, too.23:34

Generated by 2.13.1 by Marius Gedminas - find it at!