clifford changed the topic of #yosys to: Yosys Open SYnthesis Suite: http://www.clifford.at/yosys/ -- Channel Logs: https://irclog.whitequark.org/yosys
emeb has quit [Quit: Leaving.]
twnqx has quit [Ping timeout: 240 seconds]
emeb_mac has joined #yosys
N2TOH_ has joined #yosys
N2TOH has quit [Ping timeout: 258 seconds]
rohitksingh has quit [Ping timeout: 255 seconds]
citypw has joined #yosys
rohitksingh has joined #yosys
N2TOH_ is now known as N2TOH
captain_morgan06 has quit [Read error: Connection reset by peer]
captain_morgan06 has joined #yosys
emeb_mac has quit [Quit: Leaving.]
OK_b00m3r has quit [Ping timeout: 265 seconds]
rohitksingh has quit [Ping timeout: 240 seconds]
fsasm has joined #yosys
m4ssi has joined #yosys
twnqx has joined #yosys
N2TOH_ has joined #yosys
N2TOH has quit [Read error: Connection reset by peer]
captain_morgan06 has quit [Quit: Ping timeout (120 seconds)]
captain_morgan06 has joined #yosys
X-Scale` has joined #yosys
X-Scale has quit [Ping timeout: 240 seconds]
X-Scale` is now known as X-Scale
strongsaxophone has joined #yosys
X-Scale` has joined #yosys
X-Scale has quit [Ping timeout: 272 seconds]
X-Scale` is now known as X-Scale
vidbina has joined #yosys
develonepi3 has quit [Quit: Leaving]
jakobwenzel has quit [Quit: jakobwenzel]
gromero has joined #yosys
seraxis has quit [Quit: おやすみ]
seraxis has joined #yosys
fsasm has quit [Ping timeout: 268 seconds]
m4ssi has quit [Ping timeout: 260 seconds]
m4ssi has joined #yosys
m4ssi has quit [Ping timeout: 255 seconds]
dys has joined #yosys
emeb has joined #yosys
vidbina has quit [Ping timeout: 240 seconds]
citypw has quit [Ping timeout: 240 seconds]
dys has quit [Ping timeout: 245 seconds]
_whitelogger has quit [Ping timeout: 248 seconds]
_whitelogger has joined #yosys
rohitksingh has joined #yosys
emily has quit [Ping timeout: 240 seconds]
fevv8[m] has quit [Ping timeout: 252 seconds]
promach3 has quit [Ping timeout: 246 seconds]
rjo has quit [Ping timeout: 248 seconds]
pepijndevos[m] has quit [Ping timeout: 245 seconds]
nrossi has quit [Ping timeout: 245 seconds]
jryans has quit [Ping timeout: 272 seconds]
fsasm_ has joined #yosys
nrossi has joined #yosys
pepijndevos[m] has joined #yosys
fsasm has quit [Ping timeout: 240 seconds]
vidbina has joined #yosys
fevv8[m] has joined #yosys
fevv8[m] has quit [Client Quit]
nrossi has quit [Quit: killed]
pepijndevos[m] has quit [Quit: killed]
rohitksingh has quit [Ping timeout: 240 seconds]
rohitksingh has joined #yosys
Jybz has joined #yosys
Jybz has quit [Ping timeout: 246 seconds]
vidbina has quit [Ping timeout: 255 seconds]
promach3 has joined #yosys
vidbina has joined #yosys
vidbina has quit [Read error: Connection reset by peer]
vidbina has joined #yosys
rohitksingh has quit [Ping timeout: 248 seconds]
N2TOH_ has quit [Ping timeout: 255 seconds]
N2TOH has joined #yosys
N2TOH_ has joined #yosys
N2TOH has quit [Ping timeout: 255 seconds]
nrossi has joined #yosys
fevv8[m] has joined #yosys
rjo has joined #yosys
jryans has joined #yosys
emily has joined #yosys
pepijndevos[m] has joined #yosys
somlo has quit [Remote host closed the connection]
somlo has joined #yosys
rohitksingh has joined #yosys
gromero has quit [Ping timeout: 272 seconds]
fsasm_ has quit [Ping timeout: 258 seconds]
<twnqx> so... what do yosys and friends do with unused pins on an fpga? tristate, output, input?
<daveshah> Totally unused? input with pullup, same as if the FPGA is not configured at all
<daveshah> (for iCE40)
strongsaxophone has quit [Quit: Lost terminal]
<mwk> twnqx: that does not depend on yosys, fyi; yosys doesn't even know what pins the fpga has
<twnqx> that's what i was hoping for, great
<twnqx> hence "and friends" :P not sure if part of nextpnr or icepack
<twnqx> also, i just realized i actually have to figure out tristate buffers as my SPI bus is shared :/
<sensille> you can assign 'Z' to the signal
<twnqx> uh. i am not quite sure that will correctly end up with a tristate-enabled SB_IO
<mwk> assign pin = oe ? o : 1'bz;
<mwk> that should do the trick
<mwk> (and if not, report a bug)
<twnqx> (and if not - magic smoke) :P
<twnqx> actually, i should a) be able to test it nondestructively, and b) be able to see it in icepack's GUI, no?
<twnqx> err nextpnr's
<mwk> right
<twnqx> except nextpnr insists on either the right device, or loading a json :(
emeb_mac has joined #yosys
<awygle> Is there anything better than yosys' dot graph output for visualizing synthesis results?
<awygle> I thought I'd seen an interactive schematic thing at Latch-Up or one of those conferences
vidbina has quit [Read error: Connection reset by peer]
vidbina has joined #yosys
vidbina has quit [Read error: Connection reset by peer]
vidbina has joined #yosys
<awygle> oh there's an online demo of netlistsvg, that's not bad
<twnqx> yeah, clearly doesn't work with just wire MISO = CS ? 1'bz : MOSI; - output follows mosi regardless of cs
<mwk> twnqx: could you give me a reproducible test case?
<twnqx> difficult as i use my own fpga + cpu system for the tests
<mwk> you're literally claiming a single line example doesn't work
<twnqx> i am removing everything else and boiling it down to that right now.
<twnqx> https://gist.github.com/chrschmidt/6e90479cd0b8d27a419cab1f70184369 in this case, i observe MISO following MOSI regardless of CS
<tpb> Title: gist:6e90479cd0b8d27a419cab1f70184369 · GitHub (at gist.github.com)
<twnqx> unless i have a physical short between MISO and MOSI.
<twnqx> in which case i doubt i could program the fpga, but still i'll check that
<mwk> twnqx: a test case should include a command line
<twnqx> updated
<twnqx> i mean, i can't provide a command line for the physical test i am doing...
<mwk> I know, I just want to see if yosys and/or nextpnr do something stupid
<twnqx> i've seen others use inout for their tristate tests.. i should check with that
<twnqx> though this is purely an output
<mwk> try that, although it should work with an output
<daveshah> At a glance, looks like nextpnr is dealing with the tristate there fine
<daveshah> I'm assuming that your nextpnr is fairly recently built though?
<twnqx> git head from some time yesterday
<daveshah> No problem there
<daveshah> Can you share the asc file you actually get?
<twnqx> ... i'll check another IC's datasheet first
<twnqx> are any pullup/pulldown involved in tristate?
<daveshah> I think pullups should be disabled by default for used pins
<twnqx> inverting the test sequence, it seems that a pretty strong (stronger than my cpu's pullup) keeper circuit is involved...
<twnqx> and it's not following after all
<twnqx> now to figure out if that level shifter is to blame
<twnqx> i really should have deisgned the PCB with more test points :(
<mwk> ... you have a level shifter on something where tristates are involved?
<mwk> and pullups?
<twnqx> automatic direction sensing & bidirectional.
<mwk> oh god
<twnqx> and no, the pullup is activated for the test only and not normally
<mwk> that *never* ends well
<twnqx> how else could i use 5V and 3.3V things on one SPI bus...
<mwk> uhh, by using CS as output enable?
<mwk> and a non-automatic level shifter
<mwk> seriously, automatic direction sensing is the work of the devil
vidbina has quit [Read error: Connection reset by peer]
<twnqx> i did not have space for 3-4 level shifters :(
<twnqx> but the txb0106 so far never caused issues
vidbina has joined #yosys
vidbina has quit [Read error: Connection reset by peer]
<twnqx> also, what's wrong with pullups? if all slaves on an SPI bus are in tristate, the master's input would float. that's never a good state.
vidbina has joined #yosys
<ZirconiumX> I think mwk's point is that *not* having the pullups ends poorly
<mwk> pullups interfere badly with direction auto-detect
<mwk> see glasgow revA/revB for an example
<twnqx> especially if they are too strong
<awygle> _having_ pull-ups with autosensing level shifters is not going to work out well
<twnqx> yes, they act as keepers - so you don't really need them either
<twnqx> i was misunderstanding the remark as "tristate and pullups don't match"
<awygle> (also those level shifters tend to turn into oscillators if you sneeze on them)
<awygle> (just to back up what mwk was saying)
<twnqx> so far i never had issues with them is all i can say
<twnqx> but i never used them in a case like this.
<twnqx> well, if this blows up, i'll have an excuse to ditch the AVR, use an STM32 or other cortex m, and go all 3.3V
<awygle> in case anybody was wondering, this is what i was thinking of before: https://observablehq.com/@nturley/netlistsvg-how-to-draw-a-better-schematic-than-graphviz
<tpb> Title: Netlistsvg / Neil Turley / Observable (at observablehq.com)
tpb has quit [Remote host closed the connection]
tpb has joined #yosys