<bubble_buster>
:( I think my icebreaker might be kill
<bubble_buster>
is there some jumper or something required to program icebreaker?
<bubble_buster>
when I plug it in via usb it either dimly lights up or does a lot of blinking
<bubble_buster>
but does not show up in lsusb
<bubble_buster>
with same cable and usb port, upduino does show up in lsusb
emeb_mac has quit [Ping timeout: 240 seconds]
emeb has quit [Ping timeout: 245 seconds]
specing has quit [Remote host closed the connection]
emeb_mac has joined ##openfpga
emeb has joined ##openfpga
_whitelogger has joined ##openfpga
cr1901_modern1 has joined ##openfpga
cr1901_modern has quit [Ping timeout: 240 seconds]
Bike has quit [Quit: Lost terminal]
<bubble_buster>
I think I created a short when I soldered the pmod headers
<bubble_buster>
one of the voltage regulators gets extremely hot as soon as I plug it in
<bubble_buster>
my soldering is definitely sloppy but I don't see any shorts
cr1901_modern has joined ##openfpga
<bubble_buster>
I'll try desoldering tomorrow. guess I should order a multimeter or something to check for shorts in the future
<bubble_buster>
got my upduino to work at least
cr1901_modern1 has quit [Ping timeout: 240 seconds]
emeb has quit [Quit: Leaving.]
mkru has joined ##openfpga
<tnt>
which regulator ?
<tnt>
bubble_buster: ^^
<bubble_buster>
The one further from the usb port
<bubble_buster>
Closer to flash
<tnt>
Did you solder anything to the 'RGB' header ?
<bubble_buster>
No just the pair of pmod headers
<tnt>
That's the 1v2 regulator, and that power rails isn't exposed to PMODs, so that's weird.
<ktemkin>
anyone know the proper way to shout documentation corrections at Lattice, or should I just be shouting them into the void? ^^
<ktemkin>
[I figure if someone's gone through the effort of figuring that out, it's likely someone in here =P]
emeb_mac has quit [Ping timeout: 276 seconds]
rohitksingh has quit [Ping timeout: 245 seconds]
jn___ is now known as jn__
Bob_Dole has quit [Ping timeout: 245 seconds]
ironsteel has joined ##openfpga
<ironsteel>
hi guys, me again... so looking at the datasheet for the ECP5 it says that for LVDS pairs you can omit the (-) pin of the pair in the design and only specify the IO_TYPE to LVDS for both ends of the pair, does this also apply for the yosys/trellis/nextpnr?
<whitequark>
yes
<ironsteel>
whitequark, thanks allot! I was kind of confused because in xilinx land for example you use IBUFDS and explicitly hook both ends of the pair.
<tnt>
Not sure about the ECP5 but for the ice40 it's not even that you _can_ .. you have to :) There is no way to do it with both wires and having anything connector / assigned to the other wire in the pair will actually cause a conflict and not build.
<whitequark>
on ECP5 you could use one of their primitives that hooks up both P and N pins
<whitequark>
actually, hm
<whitequark>
ah no I think you have to do that on ECP5 too
edmund_ has joined ##openfpga
<edmund_>
ktemkin: You can DM me the bug in the documentation. I would forward it to the product manager of ECP5. In the past I forwarded bugs in the ice40 documentation found by whitequark to the product manager of ice40. I dont know if or when a new documentation gets released with the fixes. Sending in bug reports buys us some good will.
<ironsteel>
whitequark, tnt, yes, as far as I understand non of the IOB primitives have pairs for LVDS so its implicitly inferred, looking at the examples from FleaFPGAOhm indeed it's using only the positive end of the pair