cr1901_modern has quit [Ping timeout: 246 seconds]
citypw has joined #yosys
gsi_ has joined #yosys
gsi__ has quit [Ping timeout: 255 seconds]
knielsen has quit [Ping timeout: 246 seconds]
jevinskie has joined #yosys
knielsen has joined #yosys
PyroPeter has quit [Ping timeout: 258 seconds]
proteusguy has quit [Ping timeout: 246 seconds]
<dormando>
is it possible to get nextpnr to visualize/outline wires specific to a module?
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<tnt>
dormando: not that I know.
<tnt>
you can select them one by one ...
<dormando>
heh. I did that for a few minutes. it's the one thing I miss from the ISE atrocity
<tnt>
Maybe a small python script could help.
jevinskie has joined #yosys
rohitksingh_work has joined #yosys
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
proteusguy has joined #yosys
jevinskie has joined #yosys
citypw has quit [Ping timeout: 258 seconds]
citypw has joined #yosys
alcorn has quit [Ping timeout: 258 seconds]
citypw has quit [Ping timeout: 258 seconds]
citypw has joined #yosys
citypw has quit [Ping timeout: 258 seconds]
rohitksingh_work has quit [Ping timeout: 258 seconds]
m4ssi has joined #yosys
emeb_mac has quit [Ping timeout: 255 seconds]
Cerpin has quit [Ping timeout: 248 seconds]
Cerpin has joined #yosys
pie___ has quit [Ping timeout: 258 seconds]
fsasm has joined #yosys
vidbina has joined #yosys
vidbina has quit [Ping timeout: 244 seconds]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
cr1901_modern has joined #yosys
vidbina has joined #yosys
proteusguy has quit [Ping timeout: 244 seconds]
thasti has joined #yosys
<bluesceada>
hey everyone, i want to NOT initialize BRAM in my ice40, to analyze the start up state of RAM, this is possible in lattice icecube2, but how would it be possible with yosys/nextpnr ?
<bluesceada>
i am already using the bare SB_RAM40_4K, but that alone doesn't help it
<bluesceada>
i tried withou specifying parameters, and I tried with giving all INIT parameters don't care's like: .INIT_0(256'hxxxx....xx) to .INIT_F(256'hxxx..xx)
<bluesceada>
in icecube2 we need to check a box in the tool to not initialize memories, while somewhere else they document to use the SB_RAM40_4K as a non-initialized memory ... but it soemhow is always reset to all-0's
<bluesceada>
(if we do not check the box, that is, otherwise it contains all seemingly random data)
vidbina has quit [Ping timeout: 244 seconds]
MoeIcenowy has quit [Quit: ZNC 1.6.5+deb1+deb9u1 - http://znc.in]
MoeIcenowy has joined #yosys
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<tnt>
bluesceada: not sure it's supported
<bluesceada>
ok let's wait a bit if someone else shows up that might know
<tnt>
I'm looking at the icepack sources and I don't see anything that would disable it.
<bluesceada>
ah thanks for looking into it, you mean disabling the initialization?
<bluesceada>
seems yosys also goes with 'xxxx', so it must happen after yosys
<bluesceada>
so, probably the x will be replaced with 0 in some later step?
<tnt>
yeah, that's the very last step when converting the .asc into the .bin file ...
<bluesceada>
or rather, if there is no initialization, the packer will make it initialize to 0
<bluesceada>
ok
<tnt>
so even if supported this wouldn't be in verilog, it would be an option during the icepack step.
<bluesceada>
ok that would also be fine of course
<tnt>
because as discussed recently you can't do that "per bram", it's per quadrant.
<bluesceada>
ok yes I think that is also how it's shown in icecube2
<bluesceada>
seems every second byte is still 00, but that might be another problem
<bluesceada>
from comparing the bitstream filesizes, it is now roughly on par with the icecube2-non-initialized one, but not exactly the same size
alcorn has joined #yosys
rohitksingh has joined #yosys
dys has joined #yosys
<bluesceada>
ok got it, will try to make it a pull request for icepack soon...
alexhw has joined #yosys
<bluesceada>
tnt, it was actually right what you said and I had another issue with word/byte addresses, however I also found that it is sufficient to exclude the last part of that if-condition in which BRAM is initialized
<tnt>
bluesceada: yeah, very possible you can comment less, but the rest of the commands written in that block wouldn't have any effect if you don't write any data, so they're useless.
<tnt>
but you could make the option allow to specify which bank # you want to include or not, maybe as a bitmask
<bluesceada>
ok i thought these might have to do with the mode of addressing, but yeah in the end it was wrong verilog
<bluesceada>
i dont have much time for this so I would just add a simple option ...
<bluesceada>
next thing we need later in the semester will be placement constraints, but i see this has been added to nextpnr :-)
<bluesceada>
so this lab will be completely on open source software :-)
MoeIcenowy has quit [Quit: ZNC 1.6.5+deb1+deb9u1 - http://znc.in]
MoeIcenowy has joined #yosys
<tnt>
syntax is different than icecube for placement. (tbh I'm not even sure what the syntax was for icecube)
<bluesceada>
i think it is better, can work inline verilog code
<bluesceada>
more similar to how xilinx supports I think
<bluesceada>
but have to still take a closer look..
<tnt>
Do you have an example howit was for icecube ?
vidbina has joined #yosys
MoeIcenowy has quit [Client Quit]
MoeIcenowy has joined #yosys
<bluesceada>
it needs to be inside the constraints file, not easy to handwrite imo, generated from the icecube gui
MoeIcenowy has quit [Client Quit]
MoeIcenowy has joined #yosys
<bluesceada>
if you want a full example, i can somehow make it accessible to you
<tnt>
nah it's fine, I was just curious
<bluesceada>
probably not too bad to support both ways
blunaxela has quit [Quit: Lost terminal]
MoeIcenowy has quit [Client Quit]
MoeIcenowy has joined #yosys
<bluesceada>
for xilinx i was using a LOC constraint in a constraint file to place a full block. Then, within the block, relative location constraints (RLOC) as vhdl attributes (also works in verilog)
blunaxela has joined #yosys
fsasm has quit [Ping timeout: 244 seconds]
alcorn has quit [Quit: alcorn]
vid has joined #yosys
vidbina has quit [Ping timeout: 255 seconds]
emeb has joined #yosys
fsasm has joined #yosys
dys has quit [Ping timeout: 246 seconds]
m4ssi has quit [Remote host closed the connection]
vid has quit [Ping timeout: 246 seconds]
fsasm has quit [Ping timeout: 246 seconds]
emeb_mac has joined #yosys
gnufan_home has joined #yosys
vid has joined #yosys
Laksen has joined #yosys
vid has quit [Ping timeout: 246 seconds]
jevinskie has joined #yosys
jevinskie has quit [Client Quit]
rohitksingh has quit [Ping timeout: 268 seconds]
X-Scale` has joined #yosys
X-Scale has quit [Ping timeout: 255 seconds]
X-Scale` is now known as X-Scale
rohitksingh has joined #yosys
vonnieda has joined #yosys
adjtm has joined #yosys
adjtm_ has quit [Ping timeout: 258 seconds]
vid has joined #yosys
rohitksingh has quit [Ping timeout: 246 seconds]
jevinskie has joined #yosys
vid has quit [Ping timeout: 258 seconds]
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jevinskie has joined #yosys
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<mithro>
Anyone know the best way to write a yosys pass that would propagate parameters following signal input / output cones?
<mithro>
daveshah: would this be something you could do with the new python API?
<mithro>
Anyone used the new Python API in Yosys?
<daveshah>
mithro: I haven't used the Python API yet, but this is the sort of thing it is designed for
<mithro>
daveshah: Is there any examples I might be able to crib from?