<litghost>
hackerfoo: If the high address lines are tied high, than it is two independent RAM18E1, if tied to signals one RAM36E1
<litghost>
hackerfoo: I don't have a good mental model of how this all works out
<hackerfoo>
That's similar to how tying A6 high keeps O5/O6 independent for two DPRAM32s.
<hackerfoo>
Once I get the 36k block working, I'll try drawing some schematics.
<litghost>
hackerfoo: If the scheme is the same as DPRAMs, that implies interesting things about the data ports which I don't think is supported by the routing. It'll be interesting to see the schematics
<litghost>
hackerfoo: Read data ports specifically
<hackerfoo>
Any idea why is RSTRAMARSTRAML called RSTRAMARSTRAMLRST in the db? It's RSTRAMARSTRAML in Vivado as expected.
<sf-slack2>
<acomodi> litghost: mainly because I believe that the change described in the comment requires a moderate amount of effort
<litghost>
acomodi: Sorry, can you provide more context?
<litghost>
acomodi: I haven't seen a comment from the VTR dev's since 27 days ago
<litghost>
acomodi: Why not have them first look at the implementation you have done, and evaluate it
<litghost>
acomodi: Rather than preemptively conforming to another design
<sf-slack2>
<acomodi> litghost: Ok, makes sense, I wanted to explore other possible designs and see if they were implementable.
<sf-slack2>
<acomodi> litghost: in the meanwhile though I am stalled until there is a preliminary evaluation. What do you think could I focus on?
<litghost>
acomodi: If you think the suggestion in the issue is worth pursuing I won't stop you, but my understanding is we have an implementation that works. How do the performance before/after numbers look?
<litghost>
acomodi: I would suggest ROI breakout work, e.g. VPR tiles for the clock column and IOB's
<sf-slack2>
<acomodi> litghost: ok first I will get some reports (e.g. run_time and placement cost), but I can extract those only from Symbiflow xc7 tests as equivalent tiles is supported only by those right now
<litghost>
acomodi: Oh, you need to write the arch top-level pb_type to tiles tool
<litghost>
acomodi: Did that happen?
<litghost>
acomodi: Because you should be able to run against the full suite through the tool, yes?
<sf-slack2>
<acomodi> litghost: you mean VTR test suite or the symbiflow one?
<litghost>
acomodi: VTR test suite
<sf-slack2>
<acomodi> litghost: anyway there is an initial PR with a script that moves the top level pb_types to the tiles tag (without adding the equivalent tiles though) https://github.com/SymbiFlow/symbiflow-arch-defs/pull/583
<tpb>
Title: WIP: added script to add tiles tag and equivalent tiles by acomodi · Pull Request #583 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
<litghost>
acomodi: But I believe there was agreement that script needed to live in VPR?
<litghost>
acomodi: Unless your PR allows old style arch-xml's to work as is?
<litghost>
acomodi: I thought your PR required the new style tiles definition?
<sf-slack2>
<acomodi> litghost: No, the script is needed as the pb_type cannot have some child tags anymore (e.g. fc, pinlocations, ...)
<litghost>
acomodi: I think we agree that the script is needed, and it should be a part of VPR because anyone using VPR would be affected
<litghost>
acomodi: Not just symbiflow
<sf-slack2>
<acomodi> litghost: Yes indeed, in fact I do believe that it will take a while before the PR will get merged as it introduces a great change in the whole architecture definition
<sf-slack2>
<acomodi> litghost: I will add the script to VPR then
<litghost>
acomodi: I think discussing that point directly with the VTR devs is worth doing
<sf-slack2>
<acomodi> litghost: to make CI green on VPR and be able to test on all the architectures
<litghost>
acomodi: Yes
<litghost>
acomodi: There is an open question in my mind if VTR should do the top level pb_type to tile conversion internally to avoid requiring a format change
<litghost>
acomodi: But I'll let the VTR devs drive that choice
<sf-slack2>
<acomodi> litghost: you mean change all the architectures to be compliant with the new tiles concept instead of using a script at runtime?
<litghost>
acomodi: As a fallback, or something
<litghost>
acomodi: Or maybe a config flag
<litghost>
acomodi: I haven't thought my about this, I'm just trying to explore other avenues to avoid required a lot of action for endusers of VPR
<litghost>
much*
<litghost>
acomodi: Overall, I would let the VRP devs guide the conversion on the breaking of backwards capability
<sf-slack2>
<acomodi> litghost: Makes sense. In fact, for now it is better to rely on a script, but it surely is something to discuss with VPR devs as you said
futarisIRCcloud has quit [Quit: Connection closed for inactivity]