<asinghan1>
And I'm having the issue where when I create a design with a block RAM with 9-bit width and 2048-bit depth, everything works fine
<asinghan1>
but if i increase it to 9-bit width and 4096-bit depth, yosys suddenly decides to use distributed RAMs instead of BRAMs
<asinghan1>
with everything else remaining the same
<az0re>
I guess this is yet another memory inference problem
<asinghan1>
(the 9-bit width and 4096-bit depth would require 2 block RAMs in the cascaded configuration, is there no way to infer the cascaded config?)
<asinghan1>
Do I just need to instantiate multiple memories and MUX between them in my BRAM wrapper?
<az0re>
I'm sorry, I don't really know enough about this part of Yosys to help you, but I think others like @whitequark and @mwk might know more (though you will need to be patient).
<az0re>
> Do I just need to instantiate multiple memories and MUX between them in my BRAM wrapper?
<az0re>
From my ignorant position, I say: Try it. Sounds like it should work to me.
<az0re>
Maybe the ideal solution is to have it done automatically, but as a workaround to get your design working now, try it.
Degi has quit [Ping timeout: 260 seconds]
Degi has joined #yosys
X-Scale` has joined #yosys
X-Scale has quit [Ping timeout: 265 seconds]
X-Scale` is now known as X-Scale
FabM has joined #yosys
dys has joined #yosys
cr1901_modern has quit [Read error: Connection reset by peer]
cr1901_modern has joined #yosys
<corecode>
awygle: yea, it's still quite some work
<daveshah>
9 bit width and 4096 depth should definitely map to multiple BRAM automatically
<daveshah>
I've done similar things many times, something else must be going on that's stopping it from mapping
emeb_mac has quit [Quit: Leaving.]
vidbina has joined #yosys
BinaryLust has joined #yosys
jeanthom has joined #yosys
jakobwenzel has joined #yosys
Asu has joined #yosys
craigo has quit [Ping timeout: 240 seconds]
BinaryLust has quit [Ping timeout: 246 seconds]
az0re has quit [Remote host closed the connection]
kgugala has joined #yosys
N2TOH_ has quit [Read error: Connection reset by peer]
N2TOH has joined #yosys
Asu has quit [Remote host closed the connection]
Asu has joined #yosys
vidbina has quit [Ping timeout: 260 seconds]
<jeanthom>
Hi everyone! Does anyone know if you can use tristate signals in cxxrtl?
kgugala_ has joined #yosys
kgugala has quit [Ping timeout: 240 seconds]
kgugala_ has quit [Read error: Connection reset by peer]
vidbina has joined #yosys
<ZirconiumX>
jeanthom: In what context?
<ZirconiumX>
I'm fairly sure if Yosys understands it cxxrtl can translate it, but the expert on it would be whitequark herself
kgugala_ has joined #yosys
<jeanthom>
ZirconiumX, I'm working on a "VirtualLatticeECP5Platform" for nMigen that uses CXXRTL instead of nextpnr. The goal here is to be able to emulate nMigen code that uses platform.request()
<ZirconiumX>
Mmm. That's the wrong approach, IMO
<jeanthom>
I got a PoC working (I can emulate LambdaSoC on it and get uart I/O) but I wanted to make sure that cxxrtl "officially" supports bi-directionnal signals (say for SD card emulation)
<ZirconiumX>
CXXRTL - AFAIK - is considered entirely the wrong approach
<ZirconiumX>
.....
<ZirconiumX>
I'm brainfarting today
<ZirconiumX>
Please excuse me
<ZirconiumX>
"CXXRTL is considered entirely a different platform"
<ZirconiumX>
Additionally, "bidirectional" - AKA inouts - are supported fine by Yosys, but "tristate" issues warnings
<ZirconiumX>
If you want to simulate an SD card, don't do it by simulating how a particular FPGA simulates an SD card
<ZirconiumX>
jeanthom: ^
FFY00 has quit [Ping timeout: 260 seconds]
FFY00 has joined #yosys
<jeanthom>
ZirconiumX, What do you mean by "a different platform"? I know that by doing it this way my emulation will be far from being accurate (no timing emulation, etc.) but I thought it would be sufficient for doing basic things.
<ZirconiumX>
nMigen has platforms, right? That gets passed as the platform argument to elaborate()
<jeanthom>
yup
<ZirconiumX>
So, instead of trying to emulate an ECP5's approach to doing things, just emulate the actual object somebody requests
<ZirconiumX>
When the user asks for an SD card, they're not asking for how an ECP5 does an SD card.
kgugala has joined #yosys
kgugala_ has quit [Ping timeout: 264 seconds]
kgugala has quit [Read error: Connection reset by peer]
kgugala has joined #yosys
vidbina has quit [Ping timeout: 264 seconds]
vidbina has joined #yosys
emeb has joined #yosys
dxld has quit [Ping timeout: 256 seconds]
dxld has joined #yosys
vidbina has quit [Ping timeout: 264 seconds]
citypw has quit [Remote host closed the connection]
thardin has joined #yosys
dys has quit [Ping timeout: 260 seconds]
jakobwenzel has quit [Quit: jakobwenzel]
az0re has joined #yosys
<whitequark>
jeanthom: yeah what ZirconiumX says is correct
<whitequark>
I don't foresee adding a Virtual* platform for every existing platform
<whitequark>
if we do end up with platform simulations upstream (we probably will; #113) then it will happen without having to change user code
<ZirconiumX>
yay
<whitequark>
probably by adding another file generated by the build process or something like that, I'd have to think about it
<whitequark>
jeanthom: also regarding tristate signals, you cannot use tristate signals in cxxrtl as it has no concept of 'z
<whitequark>
and it is unlikely that it ever will, wires driven from multiple processes or assignments are a really bad fit for its architecture
<jeanthom>
whitequark, thanks for your reply. My virtual platform wasn't meant to be upstreamed, it was just a PoC that I would have used for basic nmigen tutorials
<whitequark>
I mean, people are asking for platform simulations, so it's probably better to have something that works for everyone
<whitequark>
if we're going to have it at all
<whitequark>
by tutorials, do you mean using CXXRTL to integrate a simulation with a simple GUI?
<jeanthom>
whitequark, yup
<whitequark>
cool! is there a reason you're using ECP5 specifically?
<whitequark>
platform.request() doesn't actually have to use tristate IO
<whitequark>
it gives to the nmigen code a triple of (i,o,oe) which cxxrtl is perfectly fine with, so those signals could be added as toplevel ports
<whitequark>
is it just to reuse the ECPIX-5 board definition?
<jeanthom>
I'm working on some example code/tutorials for ECPIX-5 and I thought that having a simulator would be cool (not sure about the usefulness :D)
<whitequark>
ahh I see, yeah I do think it is quite cool!
<jeanthom>
using the original board definition with few modifications was a goal of mine, I know someone who spent countless hours debugging gateware because they used PinsN instead of Pins in their gateware, and it wasn't visible in their simulation :)