clifford changed the topic of #yosys to: Yosys Open SYnthesis Suite: http://www.clifford.at/yosys/ -- Channel Logs: https://irclog.whitequark.org/yosys
tpb has quit [Remote host closed the connection]
tpb has joined #yosys
emeb has quit [Quit: Leaving.]
Degi has quit [Ping timeout: 256 seconds]
Degi has joined #yosys
smkz has quit [Quit: ~]
smkz has joined #yosys
craigo has quit [Ping timeout: 256 seconds]
N2TOH__ is now known as N2TOH
cr1901_modern has quit [Read error: Connection reset by peer]
cr1901_modern has joined #yosys
emeb_mac has quit [Quit: Leaving.]
y2kbugger has quit [Read error: Connection reset by peer]
y2kbugger has joined #yosys
futarisIRCcloud has joined #yosys
Asu has joined #yosys
jakobwenzel has joined #yosys
kraiskil has joined #yosys
flammit has quit [Ping timeout: 244 seconds]
flammit has joined #yosys
dys has joined #yosys
proteusguy has quit [Ping timeout: 256 seconds]
proteusguy has joined #yosys
kraiskil has quit [Ping timeout: 272 seconds]
kraiskil has joined #yosys
Asuu has joined #yosys
Asu has quit [Ping timeout: 246 seconds]
craigo has joined #yosys
kraiskil has quit [Read error: Connection reset by peer]
kraiskil has joined #yosys
jakobwenzel1 has joined #yosys
jakobwenzel1 has quit [Client Quit]
jakobwenzel1 has joined #yosys
kraiskil has quit [Read error: Connection reset by peer]
Asuu has quit [Read error: Connection reset by peer]
Asuu has joined #yosys
kraiskil has joined #yosys
craigo has quit [Quit: Leaving]
SpaceCoaster_ has joined #yosys
adjtm has quit [Quit: Leaving]
kraiskil has quit [Read error: Connection reset by peer]
craigo has joined #yosys
emeb has joined #yosys
AdamHorden has joined #yosys
kraiskil has joined #yosys
craigo has quit [Ping timeout: 258 seconds]
jakobwenzel1 has quit [Quit: jakobwenzel1]
maartenBE has quit [Ping timeout: 256 seconds]
maartenBE has joined #yosys
kraiskil has quit [Ping timeout: 265 seconds]
bubble_buster_ has joined #yosys
esden_ has joined #yosys
ovf has quit [Disconnected by services]
ovf_ has joined #yosys
az0re has joined #yosys
lukego has quit [*.net *.split]
rjeli has quit [*.net *.split]
bubble_buster has quit [*.net *.split]
esden has quit [*.net *.split]
nurelin has quit [*.net *.split]
dxld has quit [*.net *.split]
heijligen has quit [*.net *.split]
Kamilion has quit [*.net *.split]
cyrozap has quit [*.net *.split]
bubble_buster_ is now known as bubble_buster
esden_ is now known as esden
dys has quit [Ping timeout: 244 seconds]
fevv8[m] has quit [Read error: Connection reset by peer]
promach3 has quit [Write error: Connection reset by peer]
rjeli has joined #yosys
lukego has joined #yosys
heijligen has joined #yosys
dxld has joined #yosys
Kamilion has joined #yosys
fevv8[m] has joined #yosys
indy has joined #yosys
promach3 has joined #yosys
nurelin has joined #yosys
craigo has joined #yosys
somlo has quit [Ping timeout: 240 seconds]
<ross_s> Does anyone have a good handle on how to debug inout problems in yosys? I have a PMOD port defined as inout wire [7:0] PMOD, and some signals are assigned driven nets, others are used as inputs. I have generally had this work in the past, but now I have connected a motor peripheral and the gate drive outputs from the fpga are getting distorted, even though they are connected to inputs on the peripheral.
<ross_s> Changing the port def from inout to output fixes the problem, but breaks the input parts of the port.
<ross_s> Does anyone know why this behaviour is occurring? Is there a solution other than changing the placement file to break the pmod into inputs and outputs?
<ross_s> I notice that yosys warns a lot about 'limited support for tri-state logic', how limited is limited?
somlo has joined #yosys
<daveshah> This seems like it is a more subtle issue
<daveshah> The limited tristate support is for more complex cases than this
<daveshah> It is possible that enabling the input buffer or tristate control is messing something up
<daveshah> What do you mean by distorted?
<daveshah> and is this ECP5 or iCE40
<ross_s> ECP5. The expected output signal is the 6 gate high / gate low outputs from a three channel complementary timer
<ross_s> On the scope, with no load attached, the signals look correct. If I attach the pmod and the top level ports are inout, I see a 'breathing' effect where the duty cycles of the signals wobble slowly by a significant margin
nengel has quit [Ping timeout: 256 seconds]
<daveshah> What IO standard?
<daveshah> Is the rise/fall time still OK? Or does it change too?
<ross_s> 3.3v?
<ross_s> rise/fall seems fine
<daveshah> Nothing differential presumably
<ross_s> no, single-ended
<daveshah> I think it would need a small example to look further
<daveshah> Then you could use Yosys show to try and see what was going on
<ross_s> I'll try and pare it down to something small that exhibits the issue
<daveshah> Thanks, that should make things a lot easier
<Lofty> ...sorry
<Lofty> I'll go
Lofty has left #yosys ["Leaving"]
Lofty has joined #yosys
<ross_s> It looks like if I use any member of the port as an input, it triggers the problem https://gist.github.com/rschlaikjer/1c7125fd3dbb4a6bd4e135f93bae24f1
<tpb> Title: pmod_bldc.v · GitHub (at gist.github.com)
<ross_s> (still working on making a complete compilable example)
Asuu has quit [Ping timeout: 240 seconds]
Asuu has joined #yosys
<daveshah> If you don't use any ports as an input, then Yosys will demote the port to an output
<daveshah> so that behaviour so far makes sense
<daveshah> Is there any possibility that it is actually the input part that is misbehaving?
<daveshah> There was a bug in nextpnr a while ago where the input part of a inout, with the output path unused, actually ended up as an output driving 1
<daveshah> That should long since have been fixed but maybe it has surfaced in another form
jakobwenzel has quit [Remote host closed the connection]
<ross_s> hm, I don't think that there's any unexpected output from the input port. Still struggling to get a small repro; currently at the point where the original project (top containing a field oriented control module containing a timer) causes the problem, but if I detach the foc module timer outputs and instantiate a second copy of the same timer module it contains and attach that instead, the problem disappears
<daveshah> Very interesting. Do you know if other small design changes trigger it?
<daveshah> It is possible that it is another issue and the inout/not inout distinction peturbs the design enough to trigger it
<daveshah> Do you have multiple clock domains in the problematic functionality?
<ross_s> the only other change I have noticed that triggers it is detaching the input line from the module. There is only one clock domain. The only yosys warnings I get are re: limited tristate, a 'replacing memory with list of registers' and some ABC combinatorial warnings
<daveshah> None of those sound problematic in any way
m4ssi has joined #yosys
citypw has quit [Remote host closed the connection]
citypw has joined #yosys
Asuu has quit [Quit: Konversation terminated!]
<ross_s> Alright, afer much debugging I'm ashamed to say this may just be user error. I had forgotten that the data from the input pin was involved in the datapath for the pwm generation, and so it is actually expected that it will shift around as circumstances change. Disconnecting the pin causes the spi to read a consistent value, removing the floating behaviour. Sorry for any wasted time!
<whitequark> happens to the best of us
ananan is now known as aaaa
emeb_mac has joined #yosys
X-Scale` has joined #yosys
X-Scale has quit [Ping timeout: 264 seconds]
X-Scale` is now known as X-Scale
m4ssi has quit [Remote host closed the connection]
SpaceCoaster_ has quit [Ping timeout: 244 seconds]
X-Scale` has joined #yosys
X-Scale has quit [Ping timeout: 246 seconds]
X-Scale` is now known as X-Scale
citypw has quit [Remote host closed the connection]
citypw has joined #yosys