<tnt>
adamgreig: I connected the led directly like it is on the icebreaker and many other boards ...
<tnt>
didn't work either.
<tnt>
I had to switch to a _blue_ led instead of red so that Vf is high enough and then it worked.
<whitequark>
bibor: have you done git submodule update --init
<whitequark>
?
<whitequark>
er, sorry, that was for biostar but they quit
OmniMancer has joined ##openfpga
gsi__ is now known as gsi_
rohitksingh has quit [Read error: Connection reset by peer]
m4ssi has joined ##openfpga
AndrevS has joined ##openfpga
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<adamgreig>
tnt: I have 8ish hx8k all with red LEDs sinking into CDONE, the latest only using the internal pull-up and none external
<adamgreig>
Wonder if you've gotten a very unlucky die
<adamgreig>
But maybe the sense is different... I have the LED light up when CDONE is being pulled low
<adamgreig>
So the LED is more of an error indicator
<tnt>
adamgreig: well, it might depend on the red led .. i mean, even just putting a multimeter probe on it makes it works.
<adamgreig>
:/
<tnt>
Ah yeah, if you have the RED wired like that then, then Vf won't matter.
<tnt>
I have the led light up when it's configured.
<adamgreig>
Yea, it will always float to vddio
<tnt>
I might end up doing that too ...
<adamgreig>
If you just short CDONE to gnd does it stop booting? I'll give that a go on mine
<tnt>
yes, it does.
<tnt>
That's what I first tried on an idebreaker I put some tweezers across the done led (which shorts cdone to gnd basically).
<tnt>
and it prevented it from booting ..
<keesj>
so.. what is a proper fix for this. this "floating" to vddio because it is bad enough for 20 of my leds to light up
<keesj>
do you need to control vddio itself?
<tnt>
wait what ?
<tnt>
the fix is to not use cdone to control a led in that way.
rombik_su has joined ##openfpga
ondrej3 has joined ##openfpga
ZombieChicken has quit [Ping timeout: 245 seconds]
wpwrak has quit [Read error: Connection timed out]
wpwrak has joined ##openfpga
Asu has joined ##openfpga
ZombieChicken has joined ##openfpga
<bibor>
whitequark: thx for the reminder that I'm idling in this channel for the last ~5 years
wpwrak has quit [Ping timeout: 245 seconds]
<gruetzkopf>
o/
<tnt>
bibor: hey, didn't even see you there :)
<bibor>
\o
<bibor>
o/
wpwrak has joined ##openfpga
ZombieChicken has quit [Ping timeout: 245 seconds]
massi_ has joined ##openfpga
massi_ has quit [Remote host closed the connection]
Asu has quit [Ping timeout: 248 seconds]
Asu has joined ##openfpga
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh_work has joined ##openfpga
rohitksingh_work has quit [Read error: Connection reset by peer]
<tnt>
daveshah: Mmm ... when using .IO_STANDARD("SB_LVDS_INPUT"), you can't use that pin as output ?
<daveshah>
I've never tried
<tnt>
Mmm. I can't even find a syntax that next pnr accepts. Because I need to drive the _n but the SB_IO instance is on the _p for lvds input. And I can't instanciate another SB_IO on the _n without conflict.
<daveshah>
Well, you could probably patch out that check and try
<tnt>
I'll try in icecube to see what syntax (if any) it accepts and if ti works, then I'll tyr to make nextpnr accept that syntax too :p
flea86 has quit [Quit: Goodbye and thanks for all the dirty sand ;-)]
Asu` has joined ##openfpga
Asu has quit [Ping timeout: 272 seconds]
Asu has joined ##openfpga
Asu` has quit [Ping timeout: 272 seconds]
genii has joined ##openfpga
Asu has quit [Ping timeout: 246 seconds]
Asu has joined ##openfpga
vonnieda has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
Asu` has joined ##openfpga
Asu has quit [Ping timeout: 248 seconds]
Asu` has quit [Ping timeout: 258 seconds]
vonnieda has joined ##openfpga
Asu has joined ##openfpga
Asu` has joined ##openfpga
Asu has quit [Ping timeout: 245 seconds]
ondrej3 has quit [Quit: Leaving]
<tnt>
Well .. I think it's just not supported ...
<tnt>
I mean, you can turn on the output driver for the P side, but only the P side will be active. And there is no way to instanciate any kind of SB_IO for the N side, it's detected as a conflict and icecube ignores the placement constraint and put it somewhere else.
<tnt>
So ... maybe the hw can do it, I'd have to hack nextpnr to try. But I don't really need it anyway so ... maybe later.
emeb has joined ##openfpga
Asu has joined ##openfpga
Asu` has quit [Ping timeout: 272 seconds]
Asu` has joined ##openfpga
Asu has quit [Ping timeout: 272 seconds]
Asu` has quit [Ping timeout: 246 seconds]
Asu` has joined ##openfpga
rohitksingh has joined ##openfpga
vonnieda_ has joined ##openfpga
vonnieda has quit [Ping timeout: 245 seconds]
vonnieda_ has quit [Read error: Connection reset by peer]
vonnieda has joined ##openfpga
AndrevS has quit [Remote host closed the connection]
mnr has joined ##openfpga
rohitksingh has quit [Ping timeout: 248 seconds]
rohitksingh has joined ##openfpga
wpwrak has quit [Read error: Connection reset by peer]
wpwrak has joined ##openfpga
m4ssi has quit [Remote host closed the connection]
jcreus has joined ##openfpga
rohitksingh has quit [Remote host closed the connection]
OmniMancer has quit [Quit: Leaving.]
rombik_su has quit [Ping timeout: 246 seconds]
<adamgreig>
tnt: not that it helps use it as an input, but shouldn't the SB_IO be on the _n?
<adamgreig>
use it as an output*
<daveshah>
No, the SB_IO is always on the positive side
<daveshah>
What's confusing is this is the "B" pin for LP/HX parts and the "A" pin for U/UP parts
<whitequark>
that's pretty much singlehandedly responsible for nmigen having native support for adding inverters in front of diff pair IOBs
<adamgreig>
oh right yep
<whitequark>
because i can't imagine any other situation where you'd want to invert a diffpair in fabric
<whitequark>
but this? this will require it *constantly*
<adamgreig>
the ice app note does suggests you just route whatever way around is convenient and define polarity in fabric anyway
<daveshah>
It's known to do that for PCB routing
<daveshah>
Some ASICs have polarity registers for this reason
<whitequark>
i think for outputs you have a mode where the output is inverted inside SB_IO
<whitequark>
but only for registered outputs
<whitequark>
and not for inputs
<whitequark>
so i just added some code that instantiates SB_LUT4 (instances to match delay)
<daveshah>
Obviously the one case this doesn't work so nicely is an SB_GB_IO
<daveshah>
I guess technically you could invert the clock edge of every user
<daveshah>
But that doesn't work for a few blocks like SPRAM
<whitequark>
uh. crap. I add an inverter...
<whitequark>
thanks for mentioning
<daveshah>
That would create an interesting layout
<daveshah>
Global to fabric into the inverter and then back through a SB_GB
<whitequark>
well, not always
<whitequark>
I mean I accept the combination of PinsN and GLOBAL=1
<whitequark>
I used to accept*, just committed it
futarisIRCcloud has joined ##openfpga
ZombieChicken has joined ##openfpga
ZirconiumX has quit [Quit: Love you all~]
ZirconiumX has joined ##openfpga
Bike has joined ##openfpga
vonnieda has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
genii has quit [Remote host closed the connection]
Asu` has quit [Quit: Konversation terminated!]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]