<mithro>
hackerfoo: In fact I think that example comes from me testing exactly this issue
hzeller_ has joined #symbiflow
<hackerfoo>
mithro: I'm confused. Does it work? If so, what's the issue you discovered?
<hackerfoo>
Or so you mean you rediscovered the solution?
<hackerfoo>
*Or do you
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
kraiskil__ has joined #symbiflow
<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`)
<sf-slack2>
<acomodi> @hackerfoo: then on UART there's a menu with 9 options, and it just halts there waiting for an input
<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)
<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.
<tpb>
Title: Google Docs - create and edit documents online, for free. (at docs.google.com)
kraiskil has joined #symbiflow
kraiskil_ has joined #symbiflow
OmniMancer has quit [Quit: Leaving.]
kraiskil has quit [Ping timeout: 246 seconds]
Vonter has quit [Ping timeout: 258 seconds]
tharaka27 has joined #symbiflow
tharaka27 has quit [Client Quit]
kraiskil_ has quit [Ping timeout: 244 seconds]
Bertl is now known as Bertl_oO
kraiskil_ has joined #symbiflow
hzeller_ has quit [Ping timeout: 248 seconds]
kraiskil_ has quit [Ping timeout: 244 seconds]
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jevinskie has joined #symbiflow
Vonter has joined #symbiflow
jevinskie has quit [Client Quit]
kraiskil_ has joined #symbiflow
Bertl_oO is now known as Bertl
jevinskie has joined #symbiflow
jevinskie has quit [Client Quit]
jevinskie has joined #symbiflow
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kraiskil_ has quit [Ping timeout: 244 seconds]
<mithro>
kgugala: Morning?
<mithro>
s/Morning/Evening/
<sf-slack2>
<kgugala> @mithro evening on this side of Atlantic
<sf-slack2>
<kgugala> :slightly_smiling_face:
<mithro>
kgugala: I've ended up doing a pretty big rework of the vlog_to_pbtype.py program
<sf-slack2>
<kgugala> great, I'd like to test it with verilogs I have for arch definitions
futarisIRCcloud has joined #symbiflow
<hackerfoo>
> Because the 3 sites with the BRAM are affected by the BRAM mode, each site cannot be handled independently.
<hackerfoo>
Does this mean you can only use 18k or 36k RAM blocks for the whole device?
<hackerfoo>
Or just per-block of one 36k or two 18k.
<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).
<hackerfoo>
Thanks. I'm looking at Vivado right now, and it makes more sense.
<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.
<hackerfoo>
So I guess I don't need to combine RAMB18E1s in any way to get a RAMB36E1.
<litghost>
hackerfoo: A RAM36E1 is kind of built out of two RAM18E1, but the vivado site definition is of 3 sites
<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
<hackerfoo>
litghost: Is this what you meant when you said they were routed differently?
<litghost>
hackerfoo: Yes
<litghost>
hackerfoo: It is also worth noting that the RAMB36 has more routed pins than the other two sites (kind of)
<litghost>
hackerfoo: Consider the upper address lines
<litghost>
hackerfoo: On the RAM18 sites they are "ADDRATIEHIGH0/1"
<litghost>
hackerfoo: On the RAM36 site it is "ADDRA15" or whateever
<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?
<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.
<litghost>
hackerfoo: Doubled up
<litghost>
hackerfoo: The bits are doubled up
<litghost>
hackerfoo: So take DOA_REG, RAM36 sets both the upper and lower RAM18 DOA_REG's
<litghost>
hackerfoo: This only applies to port wide examples
<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)
<litghost>
hackerfoo: etc
<hackerfoo>
Interesting. I wonder why Vivado represents block RAM this way.
<litghost>
hackerfoo: I think if you site down and diagram out the RAM36 versus the RAM18 it will make sense
<litghost>
hackerfoo: Consider that ECC support is only in the RAM36 (I think)
<litghost>
hackerfoo: Along with a handful of other features
<litghost>
hackerfoo: Note how few bits are RAM36 only
<litghost>
hackerfoo: But they do exist
<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
<hackerfoo>
I would think drawing it as a block that contains 2x18k + ECC blocks would make more sense, the way CLBs have multiple LUTs.
<litghost>
hackerfoo: I don't disagree
<hackerfoo>
Xilinx has a lot of overlapping diagrams that show different interpretations of the actual hardware. It's hard to infer what is real.
<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?
<litghost>
hackerfoo: I don't think the BRAM address decoders are that flexible
<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
_whitelogger has joined #symbiflow
<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.