<digshadow>
it relies on the verdi command line tool
<digshadow>
(which is proprietary)
<digshadow>
this converts it to vcd for loading
<digshadow>
its hacky and only midly helpful
<digshadow>
oh wait
<digshadow>
hmm there is a second note
<digshadow>
eh
<digshadow>
yeah the other thing is just linking to the propreitary library
<cr1901_modern>
ZipCPU: Caved and tried SUMP2. As usual, the command line interface sucks/there's no examples for when I'm in a hurry. As usual, I can't build the GUI (because fuck pygame, seriously). As usual, PulseView doesn't support SUMP2 because of course it doesn't (I swear 2 god PV is only useful for FTDI devices). Lost patience and gave up.
<ZipCPU>
Did you purchase any hardware to do this?
<cr1901_modern>
I used my IceStick. bitstream flashed fine. Bitstream's never the problem.
<cr1901_modern>
It's "trying to get a goddamn measurement without a realtime interface like on a oscilloscope" that's always the problem
<ZipCPU>
Hmm ... was sump2 an open source solution?
<ZipCPU>
If not, want to try an open source alternative?
<cr1901_modern>
Yes. Sump2 is open source. I'm open to trying an alternative some other night
<ZipCPU>
Heheh ... yeah, it's pretty late too ... and I'm getting frustrated myself with what I'm working with.
<ZipCPU>
Only in my case ... it's my own code, so I have no one else to blame.
<ZipCPU>
Ahh ... found the bug ... I turned if(condition) break; into if(condition) fprintf(debug...); break; without adding the {}'s.
<ZipCPU>
Or ... I found the bug in the debugging code. Still looking for the *real* bug ...
<cr1901_modern>
Well, holy smokes... PulseView was useful for something (using my Shikra, which is my default JTAG programmer, as an LA)
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
digshadow has quit [Ping timeout: 246 seconds]
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
amclain has quit [Quit: Leaving]
pie__ has quit [Ping timeout: 240 seconds]
<azonenberg_work>
Welp, i managed to save one of the boards
<azonenberg_work>
The other two i'm probably not going to bother reworking
<azonenberg_work>
it was a pain in the butt and i'm respinning it anyway
<balrog>
azonenberg_work: that annoying?
<azonenberg_work>
Trying to clean out PTH holes to swap connectors is a massive PITA
<azonenberg_work>
honestly i'd rather solder an 01005 than do that
pie__ has joined ##openfpga
scrts has quit [Ping timeout: 276 seconds]
<balrog>
azonenberg_work: how many pins?
<balrog>
and don't tell me you're trying to use wick
<azonenberg_work>
I was
<azonenberg_work>
I dont have a sucker, i threw it out after it broke and never bought another
<azonenberg_work>
It did work, just took forever
<azonenberg_work>
Had to cut all of the pins on the header
<azonenberg_work>
heat them up one by one with an iron, pull them out
<azonenberg_work>
then wick out each hole one by one
<azonenberg_work>
Took over an hour for a 20 pin connector
<azonenberg_work>
gimme a BGA any day
<balrog>
azonenberg_work: I have MUCH better success with vacuum desoldering pumps
<balrog>
I'll take a hand one over wick any day
<balrog>
and an SC7000Z or similar desoldering iron is great
<balrog>
all the wick I've tried is garbage
<qu1j0t3>
i've heard bad about wick. but my sucker is pretty hard to use
* qu1j0t3
blames himself
<azonenberg_work>
I just do so much SMT that its not worth me spending time on PTH rework tools
<azonenberg_work>
time or money*
<balrog>
qu1j0t3: does it hold a vacuum
<balrog>
?
<qu1j0t3>
hm.. good question. it's cheap junk
<balrog>
if it can't hold a vacuum if you put your thumb over it, then it's useless
<balrog>
the cheap junk ones are 50/50
<balrog>
some hold a good vacuum, others don't hold one at all
pie__ has quit [Ping timeout: 260 seconds]
<felix_>
when you add flux to the desoldering wick before using it, it'll be much useable. for the vacuum desoldering pumps getting a silicone tip that is plugged onto the plastic one is a good idea. and yeah, when those devices don't hold the vacuum, you should replace them ;)
<balrog>
felix_: for most of them the tip isn't plastic but is really fiberglass
<balrog>
that's why it doesn't burn when you press it against the iron
<qu1j0t3>
mine seems kinda melty. i'd say it's a gold standard cheap crap
<qu1j0t3>
museum grade china product
scrts has joined ##openfpga
<balrog>
buy an edsyn soldapullt if you want one that's made well
<balrog>
I learned PTH on those... and got pretty good at it
<balrog>
azonenberg: yeah I was gonna say -- digilent :)
<azonenberg>
Only way to get a more minimalistic board than that is to make it
<azonenberg>
and you may still have trouble beating that price
Hootch has joined ##openfpga
<cr1901_modern>
"may"?
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
Hootch has quit [Ping timeout: 240 seconds]
<qu1j0t3>
:D
Hootch has joined ##openfpga
<rqou>
woo the f*cking idiots who manage this apartment finally fixed the washing machine
<rqou>
apparently it only took about a month
azonenberg_work has joined ##openfpga
<rqou>
hmm i just took apart a very "interesting" hdmi-over-cat6 device
<rqou>
the rx just has a max3815 channel equalizer between the ethernet jack and the hdmi port
<rqou>
the tx has a SiI9187B "HDMI processor" (presumably hdcp and resolution stuff) going into a chip with rubbed-out part numbers
<rqou>
no magnetics
<azonenberg_work>
TX is probably a TMDS141 or similar
<azonenberg_work>
just a repeater
<azonenberg_work>
Any AC coupling caps?
<rqou>
yeah, there are series ac coupling caps on the output of the mystery chip
<rqou>
unfortunately this is unlikely to work with my idea of just sticking some media converters in the middle so that i can go over a ridiculously-long fiber
<azonenberg_work>
Depends
<azonenberg_work>
it should work with a QSFP+
<rqou>
no, i meant those 1000base-t to sgmii/base-x things
<azonenberg_work>
But... on second thought no
<azonenberg_work>
It's probably TMDS at the physical layer
<azonenberg_work>
Which doesnt have enough edges to sync clock recovery to
<azonenberg_work>
it's an 8-to-10 code but the exact opposite goal of the IBM 8/10 code maximizing edges
<rqou>
oh what
<azonenberg_work>
TMDS video uses a ref clock at the pixel frequency on one pair
<azonenberg_work>
then one pair for R/G/B each at 10x the pixel freq
<rqou>
and it's not even good at being low-EMI
<azonenberg_work>
you PLL up the refclk and sample the R/G/B
<rqou>
why does TMDS suck?
<rqou>
> mithro: oh and btw, in case you were confused, this isn't ieee's 8b10b
<azonenberg_work>
well what i was concerned about was, if you were going to run it over fibewr
<azonenberg_work>
all of the conversion might introduce enough jitter that you wouldnt be able to sync a refclk to it
<azonenberg_work>
or skew
<azonenberg_work>
you'd be fine if you had embedded clocking that you could recover, but you dont
<azonenberg_work>
displayport for example should work over fiber no problem
<azonenberg_work>
with basically no conversion
<rqou>
also pcie? :P
<azonenberg_work>
Since that's actual 8b10b
<azonenberg_work>
pcie and sata have out-of-bnad low speed signaling
<azonenberg_work>
may or may not work
<rqou>
ooh right, i forgot about that
<rqou>
brb, going to go acquire breakfast
<azonenberg_work>
Aand brb my boat is docking
<azonenberg_work>
:p
azonenberg_work has quit [Ping timeout: 260 seconds]
<pointfree>
cyrozap: I'm going to need a new stratagem for finding routes that *don't* work on the PSoC 5lp logic fabric. The routing works by short-circuiting.
<pointfree>
I guess the PSoC 5LP really does effectively give me some of that in-hardware logic synthesis without any extra work.
<pointfree>
The bitstream generated by tools Cypress gets from a third party (SoftJin) are actually not taking advantage of this at all.
<pointfree>
It will short along the port interface! I think this actually pretty cool. We'd only need more switching when the configuration becomes more crowded.