<tpb>
Title: [WIP] reducing RAM primitives to DPRAM32/64 by HackerFoo · Pull Request #663 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
<hackerfoo>
Any tips?
<hackerfoo>
It's weird, because the RAMs seem to have just disappeared entirely from ram_shifter_*1xs, but no errors. I can't find the INIT bit pattern either.
<hackerfoo>
Maybe the problem is in Yosys, because the eblif looks different.
<litghost>
hackerfoo: Does the eblif has the right blackbox's?
Bertl_oO is now known as Bertl_zZ
<hackerfoo>
I can't even find the .cname for the ram.
<litghost>
huh, ya that sounds like a yosys bug
<litghost>
did you update the cells_sim.v file?
<hackerfoo>
There's no RAM .subckt
<litghost>
So not a yosys bug, but a techmap issue
<litghost>
Sorry*
<hackerfoo>
I just did. I thought that was only for simulation?
<litghost>
Yosys uses it for defining blackbox's
<litghost>
Yosys tends to just eat poorly defined techmaps, something to watch for
<litghost>
it will vomit in the Yosys log
<hackerfoo>
Thanks. Now I see it in the eblif and fasm.
citypw has quit [Ping timeout: 245 seconds]
citypw has joined #symbiflow
<hackerfoo>
I have RAM32X1S working on hardware!
<hackerfoo>
Now I have to fix up the dual port RAMs.
<hackerfoo>
RAM64X1D works, but RAM32X1D is broken the same way it was before. At least I fixed X1S.
futarisIRCcloud has joined #symbiflow
<elms>
hackerfoo: woot! Progress
<hackerfoo>
RAM32X1S now passes through VPR->fasm2v->Vivado->bitstream without errors. I'm going to load it and see what happens.
<hackerfoo>
Doesn't work.
<elms>
:/
<elms>
hackerfoo: you can take it back to fasm and compare right?
<hackerfoo>
Yeah, I could do that later, but I really want to get RAM32X1D working, which is what I meant to run through Vivado. It gives and error, though.
<hackerfoo>
ERROR: [Vivado 12-2285] Cannot set LOC property of instance 'CLBLM_R_X11Y110_SLICE_X14Y110_RAM32X1D_CD', for bel C6LUT Element SLICE_X14Y110.C5LUT can not be used as a route-through for net CLBLL_R_X13Y110_SLICE_X18Y110_AMUX taged to C5LUT_O5 because a RAM or shift register is placed there
lopsided98_ is now known as lopsided98
<hackerfoo>
The `_CD` seems weird. I can't find anything on it, except RAM128X1S_CD in clb_models.py
<elms>
hackerfoo: Is that ganging the C and D LUTs?
<hackerfoo>
That would be my guess, but I'm only using one.
<elms>
still doesn't help with that error. What is CLBLL_R_X13Y110_SLICE_X18Y110_AMUX in the design?
<litghost>
The output wire from the slice
<litghost>
From a slice
<elms>
ok and it's trying to route through the slice used for the RAM. I guess I'm wondering if there is something the understand from what that net is the the design.
<elms>
May be it doesn't matter, but it points to the RAM32x1D not correctly excluding that in VPR.
<hackerfoo>
Funny, sometimes the error is different? ERROR: [Vivado 12-2285] Cannot set LOC property of instance 'CLBLM_R_X11Y110_SLICE_X14Y110_RAM32X1D_CD', for bel C6LUT Element SLICE_X14Y110.CFFMUX is not routable
<hackerfoo>
Nondeterministic errors are never boring.
<elms>
Are you just rerunning just vivado? or through VPR as well.
<hackerfoo>
I re-ran VPR when it changed. It seems to be the same from just re-running Vivado.
<elms>
good. place and route (eg Synthetic annealing) is pseudo-random. You can record the seed if you need to reproduce. I have not looked at how to do this with VPR.
<hackerfoo>
Nevermind. The second one was my fault. I switched SPO/DPO to see if that had anything to do with it.
<hackerfoo>
It's something to do with the packing, because I removed the stub from RAM32X1D in the techmap and it works! Almost. The address is off by 5, but otherwise it works.
<hackerfoo>
Somehow one of the SMALL bits are missing in the FASM.
kraiskil has joined #symbiflow
OmniMancer has joined #symbiflow
kraiskil has quit [Read error: Connection reset by peer]
GuzTech has joined #symbiflow
kraiskil has joined #symbiflow
<hackerfoo>
Holy shift registers, all of RAM{32,64]X1{S,D} work on hardware! Thanks for the help everyone.
<tpb>
Title: Yosys Open SYnthesis Suite :: Command Reference :: select (at www.clifford.at)
adjtm has quit [Ping timeout: 258 seconds]
<mithro>
kgugala: Things seem to work better when you do that reg change...
<mithro>
kgugala: Looking at how we can make that warning an error
<sf-slack2>
<kgugala> Yosys stops complaining about assigning a wire i always block
adjtm has joined #symbiflow
<sf-slack2>
<kgugala> @mithro can we assume the if an output is affected by an input, and the output has an associated clock, the input should also have this clock associated?
tux3 has quit [Quit: Quitting]
tux3 has joined #symbiflow
<mithro>
kgugala: Unsure
<sf-slack2>
<kgugala> I implemented such approach and it doesn't seem to break other tests
<sf-slack2>
<kgugala> I'll push that in a minute
kraiskil has quit [Read error: Connection reset by peer]
<mithro>
kgugala: I pushed an update to how yosys runs
Bertl is now known as Bertl_oO
<sf-slack2>
<kgugala> yeah I see that
<sf-slack2>
<kgugala> @mthro I see you push-forced the v2x-clock-tests
<sf-slack2>
<kgugala> it conflicts with mine changes, I resolved the conflicts, but it'd be nicer if I rebase the whole thing
<tpb>
Title: Include the v2x model + pb_type xml files into VPR architecture XML file and check VPR can load it · Issue #668 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
space_zealot has quit [Remote host closed the connection]
space_zealot has joined #symbiflow
<mithro>
kgugala: I'll work on #668 if you are working on the v2x stuff
<sf-slack2>
<kgugala> Ok
space_zealot has quit [Remote host closed the connection]
space_zealot has joined #symbiflow
<hackerfoo>
How can I set a FASM feature based on the input to a mux in VPR? Do I need to use modes instead?
<hackerfoo>
I can see the equivalent to what I want for <direct>
<hackerfoo>
Can I use the output of a mux directly as the input to another? "Message: Syntax error processing port string 'B_DRAM.DI1 SLICEM_MODES.AI' (output from interconnect from parent is not an input or clock pin)"
synaption[m] has joined #symbiflow
<litghost>
hackerfoo: Nope
<litghost>
hackerfoo: That's the reason for the "PARENT_DI" stuff
<litghost>
hackerfoo: It is simply converting the input port to an output port
<litghost>
hackerfoo: Or vise-versa
<litghost>
hackerfoo: Been a while since I messed with this stuff
<hackerfoo>
I guess I need an internal wire.
<elms>
litghost: has there been any discussion around how to support different speed grades?
<litghost>
elms: Speed grades are just another take on the corner analysis, kind of
<litghost>
elms: If VPR supported multiple corners, and we could select which corners we used in analysis, that would cover speed grades
<elms>
litghost: makes sense. Last week I thought about it and realized forking pb_types would be terrible. Do you think the difference in speed grades are uniform enough to have little impact on PnR?
<litghost>
elms: Hard to say, I lack an intuition on that topic
<elms>
If it just adds constants I would imagine little impact on the routing for example. It would impact fmax.
<elms>
ok
<litghost>
elms: Given that we are controlling the import, we can just emit pbtypes and rrgraphs at a particular speed grade, yes?
<elms>
litghost: yes, but we would have to generate one for each grade which would be mostly identical except for the timing. Or just emit for 1 speed grade and say that's good enough for now.
<elms>
litghost: I think this points to another aspect that could be optimized in the representation format. We will want an 1:N mapping for timing. Yes I agree about that issue. But I think as we look forward to other formats, it will be better to separate them to a separate data structure
<litghost>
elms: Sure, which is what I mean by a symbolic solution, e.g. a side lookup