| *** tpb has joined #symbiflow | 00:00 | |
| *** hzeller_ has joined #symbiflow | 00:37 | |
| hackerfoo | I got picosoc to use 32 bit dist. RAM. How do I know if it works? | 00:46 |
|---|---|---|
| litghost | hackerfoo: Look in the README? | 00:48 |
| litghost | hackerfoo: I think it blinks an LED? | 00:48 |
| litghost | hackerfoo: https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/tests/9-soc/picosoc/firmware/firmware.c | 00:48 |
| tpb | Title: symbiflow-arch-defs/firmware.c at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 00:48 |
| hackerfoo | I didn't see anything in the README | 00:48 |
| litghost | hackerfoo: Ya, me neither, we should fix that | 00:49 |
| litghost | hackerfoo: The murax one describes the expected behavior | 00:49 |
| litghost | hackerfoo: Looks like it opens a little command problem on the UART? | 00:50 |
| litghost | hackerfoo: I know acomodi tested picosoc last go around | 00:51 |
| litghost | hackerfoo: https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/tests/9-soc/picosoc/firmware/firmware.c#L567 | 00:51 |
| tpb | Title: symbiflow-arch-defs/firmware.c at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 00:51 |
| litghost | hackerfoo: Might be 115200 baud? | 00:51 |
| hackerfoo | No luck. I just get a repeating character. | 01:01 |
| litghost | hackerfoo: I would wait till acomodi is around | 01:07 |
| hackerfoo | Okay. Until then, I'm retrying without my changes (using 64 bit dist. RAM) | 01:08 |
| hackerfoo | It works with 64 bit RAM. I'll have to make a simpler test. | 01:27 |
| *** futarisIRCcloud has quit IRC | 02:03 | |
| *** hzeller_ has quit IRC | 02:10 | |
| *** futarisIRCcloud has joined #symbiflow | 02:10 | |
| mithro | hackerfoo: Well, I just discovered the issue you mentioned about being unable to chain muxes | 02:15 |
| hackerfoo | mithro: 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 |
| mithro | hackerfoo: You can do it with empty pb_type objects | 02:17 |
| hackerfoo | Yeah, if I understand what VPR is doing, it won't know what to do with that. I could be wrong, though. | 02:19 |
| hackerfoo | It won't know when to route through the empty pb_type. | 02:22 |
| hackerfoo | I think that I can maybe make the flattening approach work with pack_pattern, otherwise VPR needs to support muxing buses. | 02:25 |
| mithro | hackerfoo: I'm sure I had fixed the ability to route through empty pb_type objects? | 03:01 |
| hackerfoo | mithro: I certainly could be wrong; I didn't try it. Is there an example? | 03:10 |
| mithro | hackerfoo: https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/testarch/tiles/lutff3/lutff3.pb_type.xml | 03:12 |
| tpb | Title: symbiflow-arch-defs/lutff3.pb_type.xml at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 03:12 |
| mithro | hackerfoo: In fact I think that example comes from me testing exactly this issue | 03:15 |
| *** hzeller_ has joined #symbiflow | 03:15 | |
| hackerfoo | mithro: I'm confused. Does it work? If so, what's the issue you discovered? | 03:38 |
| hackerfoo | Or so you mean you rediscovered the solution? | 03:38 |
| hackerfoo | *Or do you | 03:39 |
| *** futarisIRCcloud has quit IRC | 04:13 | |
| *** kraiskil__ has joined #symbiflow | 06: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 input | 08: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 https://pastebin.com/TccrC6mr | 08:42 |
| tpb | Title: Terminal ready Press ENTER to continue.. Press ENTER to continue.. Press ENTE - Pastebin.com (at pastebin.com) | 08:42 |
| sf-slack2 | <acomodi> I will update the README.md | 08:43 |
| *** jevinskie has quit IRC | 08:55 | |
| *** kraiskil__ has quit IRC | 08:56 | |
| *** jevinskie has joined #symbiflow | 08:57 | |
| *** Bertl_zZ is now known as Bertl | 09:18 | |
| *** futarisIRCcloud has joined #symbiflow | 09:34 | |
| *** yang1yang1 has joined #symbiflow | 10:18 | |
| *** yang1yang1 has left #symbiflow | 10:19 | |
| *** kraiskil has joined #symbiflow | 10:46 | |
| *** alexhw has quit IRC | 10:59 | |
| *** alexhw has joined #symbiflow | 11:01 | |
| *** futarisIRCcloud has quit IRC | 11:43 | |
| *** kraiskil has quit IRC | 11:53 | |
| *** OmniMancer has joined #symbiflow | 12:34 | |
| sf-slack2 | <mkurc> I prepared a document which describes my idea of adding FASM metadata to V2X: https://docs.google.com/document/d/1J8lLT4SzlK_56-vBfz0f2DaNLHPn9rABUB0Fu1ljF4M | 12:37 |
| tpb | Title: Google Docs - create and edit documents online, for free. (at docs.google.com) | 12:37 |
| *** kraiskil has joined #symbiflow | 12:42 | |
| *** kraiskil_ has joined #symbiflow | 13:26 | |
| *** OmniMancer has quit IRC | 13:29 | |
| *** kraiskil has quit IRC | 13:29 | |
| *** Vonter has quit IRC | 13:45 | |
| *** tharaka27 has joined #symbiflow | 13:46 | |
| *** tharaka27 has quit IRC | 13:48 | |
| *** kraiskil_ has quit IRC | 14:47 | |
| *** Bertl is now known as Bertl_oO | 15:18 | |
| *** kraiskil_ has joined #symbiflow | 15:27 | |
| *** hzeller_ has quit IRC | 15:53 | |
| *** kraiskil_ has quit IRC | 16:07 | |
| *** jevinskie has quit IRC | 16:45 | |
| *** jevinskie has joined #symbiflow | 16:47 | |
| *** Vonter has joined #symbiflow | 16:47 | |
| *** jevinskie has quit IRC | 16:47 | |
| *** kraiskil_ has joined #symbiflow | 16:57 | |
| *** Bertl_oO is now known as Bertl | 17:26 | |
| *** jevinskie has joined #symbiflow | 17:32 | |
| *** jevinskie has quit IRC | 17:35 | |
| *** jevinskie has joined #symbiflow | 17:39 | |
| *** jevinskie has quit IRC | 17:52 | |
| *** kraiskil_ has quit IRC | 18:16 | |
| mithro | kgugala: Morning? | 21:00 |
| mithro | s/Morning/Evening/ | 21:00 |
| sf-slack2 | <kgugala> @mithro evening on this side of Atlantic | 21:09 |
| sf-slack2 | <kgugala> :slightly_smiling_face: | 21:10 |
| mithro | kgugala: I've ended up doing a pretty big rework of the vlog_to_pbtype.py program | 21:10 |
| sf-slack2 | <kgugala> great, I'd like to test it with verilogs I have for arch definitions | 21:11 |
| *** futarisIRCcloud has joined #symbiflow | 21:55 | |
| hackerfoo | > Because the 3 sites with the BRAM are affected by the BRAM mode, each site cannot be handled independently. | 22:14 |
| hackerfoo | Does this mean you can only use 18k or 36k RAM blocks for the whole device? | 22:15 |
| hackerfoo | Or just per-block of one 36k or two 18k. | 22:16 |
| elms | hackerfoo: 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 |
| hackerfoo | Thanks. I'm looking at Vivado right now, and it makes more sense. | 22:36 |
| hackerfoo | It'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 |
| hackerfoo | So I guess I don't need to combine RAMB18E1s in any way to get a RAMB36E1. | 22:41 |
| litghost | hackerfoo: A RAM36E1 is kind of built out of two RAM18E1, but the vivado site definition is of 3 sites | 22:42 |
| litghost | hackerfoo: Given that we have a routing graph for all 3 sites, we can just wire our blackbox at the site location of the RAMB36 | 22:42 |
| hackerfoo | litghost: Is this what you meant when you said they were routed differently? | 22:42 |
| litghost | hackerfoo: Yes | 22:42 |
| litghost | hackerfoo: It is also worth noting that the RAMB36 has more routed pins than the other two sites (kind of) | 22:43 |
| litghost | hackerfoo: Consider the upper address lines | 22:43 |
| litghost | hackerfoo: On the RAM18 sites they are "ADDRATIEHIGH0/1" | 22:43 |
| litghost | hackerfoo: On the RAM36 site it is "ADDRA15" or whateever | 22:44 |
| hackerfoo | Do 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 |
| hackerfoo | At 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 |
| litghost | hackerfoo: Doubled up | 22:47 |
| litghost | hackerfoo: The bits are doubled up | 22:47 |
| litghost | hackerfoo: So take DOA_REG, RAM36 sets both the upper and lower RAM18 DOA_REG's | 22:47 |
| litghost | hackerfoo: This only applies to port wide examples | 22:48 |
| litghost | hackerfoo: 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 |
| litghost | hackerfoo: etc | 22:49 |
| hackerfoo | Interesting. I wonder why Vivado represents block RAM this way. | 22:49 |
| litghost | hackerfoo: I think if you site down and diagram out the RAM36 versus the RAM18 it will make sense | 22:50 |
| litghost | hackerfoo: Consider that ECC support is only in the RAM36 (I think) | 22:50 |
| litghost | hackerfoo: Along with a handful of other features | 22:50 |
| litghost | sit* | 22:50 |
| litghost | hackerfoo: https://github.com/SymbiFlow/prjxray-db/blob/master/artix7/segbits_bram_l.db#L447 | 22:51 |
| tpb | Title: prjxray-db/segbits_bram_l.db at master · SymbiFlow/prjxray-db · GitHub (at github.com) | 22:51 |
| litghost | hackerfoo: Note how few bits are RAM36 only | 22:51 |
| litghost | hackerfoo: But they do exist | 22:51 |
| litghost | hackerfoo: 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 active | 22:52 |
| hackerfoo | I would think drawing it as a block that contains 2x18k + ECC blocks would make more sense, the way CLBs have multiple LUTs. | 22:52 |
| litghost | hackerfoo: I don't disagree | 22:53 |
| hackerfoo | Xilinx has a lot of overlapping diagrams that show different interpretations of the actual hardware. It's hard to infer what is real. | 22:55 |
| hackerfoo | If 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 |
| litghost | hackerfoo: I don't think the BRAM address decoders are that flexible | 23:00 |
| litghost | hackerfoo: The reason you use a RAMB36 over a RAMB18 is you need something wider or deeper than the RAMB18 can do, or you want ECC | 23:01 |
| *** _whitelogger has quit IRC | 23:14 | |
| *** _whitelogger has joined #symbiflow | 23:16 | |
| hackerfoo | Hardware 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 irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!