<lain>
even for fine-pitch work. you can get the edge of it into tight spaces almost every time, and it delivers a lot of heat quickly
<lain>
I tried using an ultra fine tip but at least for my irons, it just doesn't work well. can't move enough heat to the end to be useful in most cases.
<lain>
then I have one of the rightmost tips from that image, it usually fits where the big one won't, and it's still going to deliver heat way more effectively than a small conical
kuldeep_ has joined ##openfpga
kuldeep__ has quit [Ping timeout: 258 seconds]
kuldeep__ has joined ##openfpga
kuldeep__ has quit [Max SendQ exceeded]
kuldeep__ has joined ##openfpga
kuldeep_ has quit [Ping timeout: 250 seconds]
kuldeep_ has joined ##openfpga
kuldeep__ has quit [Ping timeout: 264 seconds]
kuldeep__ has joined ##openfpga
kuldeep_ has quit [Ping timeout: 258 seconds]
digshadow has quit [Quit: Leaving.]
Ardeshir has joined ##openfpga
kuldeep__ has quit [Remote host closed the connection]
kuldeep__ has joined ##openfpga
kuldeep__ has quit [Remote host closed the connection]
kuldeep__ has joined ##openfpga
kuldeep__ has quit [Remote host closed the connection]
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
scrts has joined ##openfpga
digshadow has joined ##openfpga
Ardeshir has quit [Quit: Leaving]
Ardeshir has joined ##openfpga
Ardeshir has quit [Quit: Leaving]
clifford_ has quit [Ping timeout: 265 seconds]
<whitequark>
cr1901_modern: needs more flux
Ardeshir has joined ##openfpga
<rqou>
I use a thinner "chisel" tip (the rightmost one)
<rqou>
conical soldering iron tips are useless
<rqou>
if you're really fancy there's a tip that looks like the leftmost "hoof" one except that it has a small cavity where the flat part is
<whitequark>
those are really great
<whitequark>
and not "fancy", I consider them an essential tool
<rqou>
this cavity holds a small amount of solder that can cling to pins when you drag the tip across
clifford has joined ##openfpga
<rqou>
feeling lonely at the openfpga assembly table right now
<rqou>
balrog, rvense, pie_, who else?
<nats`>
I would like to be here
<nats`>
I have to go to C3 one day
<nats`>
I'm located in Paris so it should be easy :D
SalvorH_ has quit [Ping timeout: 268 seconds]
SalvorH has joined ##openfpga
<rqou>
azonenberg: i don't believe i have access to the openfpga wiki
Bike has quit [Quit: terror]
<pie_>
rqou, where are you
<pie_>
rqou, ill be the guy with the face mask lol :/
<rqou>
i'm at the openfpga assembly
<pie_>
yeah ok but where is that
<rqou>
in the corner of hall 3 near the soldering irons
<pie_>
ah ok
<rqou>
there's an icoboard poster
<rqou>
and a demo running a breakout game
<pie_>
actually ill be over a littlelaterthanexpected
<nats`>
you flood all the pin and then suck it with solderwick ?
<nats`>
I do that on package with 1.27 pitch
<cr1901_modern>
Yea b/c I expect the flux to drag the solder to the pin
<nats`>
but at 0.5mm it's not a good idea
<nats`>
put flux before and just touch the pin/pad with the tip
<nats`>
sometime it'll short circuit 2 or 3 of them but you can easily remove it with solderwick
<nats`>
the danger is too flood all the row and then getting lot of solder behind pin
<nats`>
in that case it's a fucking pain in the ass to remove it
<nats`>
especially on cheap pcb with crappy soldermask
<cr1901_modern>
like oshpark :P?
<cr1901_modern>
I'll keep that in mind when I do another board
<nats`>
oshpark is far from being the worst
<nats`>
seeedstudio for example is a nightmare
<cr1901_modern>
well, just saying... I can def destroy those soldermasks
<nats`>
yep
<cr1901_modern>
Now that I can actually do SMD... idk if I'm going to do more boards myself. I may pay someone like macrofab or a friend to do it for me
<cr1901_modern>
I mean, doing that board took me a few hours (I'm not a quick solderer)
<nats`>
it really depends on what you like
<nats`>
I lofve mounting new challenging board :)
<nats`>
but for small serie I would like to use a supplier
<nats`>
problem it costs a lot
<nats`>
try skillet reflow maybe ?
<nats`>
I pretty like this technic
<cr1901_modern>
The reflow oven I want costs $700 (that's b/c cost of labor to put it together)
<nats`>
(take care of using only leaded solder)
<nats`>
all those chinese oven are crap
<cr1901_modern>
and said oven is "optimized" for unleaded solder
<nats`>
if you go for an oven make one yourself or get a decent one
<nats`>
or skillet reflow :)
<nats`>
SKILLET REFLOW FOR THE WIN ! :D
<cr1901_modern>
whitequark suggested skillet reflow. Went looking for one at a thrift store and didn't have much luck.
<cr1901_modern>
should do it again
<cr1901_modern>
And then I should buy some of that solder paste that can be made on-demand
<nats`>
main advantage with skillet reflow... you can use a supaaa cool PID
<nats`>
name Eye to Hand Controller :D
m_t has quit [Quit: Leaving]
<cr1901_modern>
Best PID control there is
<cr1901_modern>
shame it's not automated :(
<nats`>
you can easily :)
<nats`>
take a SSR an AVR and a thermistor
* cr1901_modern
was joking in the sense that human-initiated PID is still the best PID
<cr1901_modern>
SSR? Solid State Relay?
<cr1901_modern>
Wouldn't that be on-off?
<nats`>
yep :D
<nats`>
it is
<nats`>
but again the inertia is big enough so you can cut for 5 second then on for 3
<nats`>
etc...
<nats`>
it's not like if you need a 1kHz PWM :D
<cr1901_modern>
True
<cr1901_modern>
What skillet do you use?
<nats`>
a 15€ low cost one :D
<nats`>
no ref
<nats`>
say "super cheap chineese"
kuldeep has quit [Remote host closed the connection]
kuldeep has joined ##openfpga
kuldeep has quit [Excess Flood]
kuldeep has joined ##openfpga
kuldeep has quit [Remote host closed the connection]
kuldeep has joined ##openfpga
<rqou>
hey, before i waste another several hours on this, can anybody give me a working example of .v --> .jed for xilinx cplds?
<rqou>
i've spent like two hours on this already
kuldeep_ has joined ##openfpga
<rqou>
waiting for a double-tunnelled x-over-ssh-over-ssh to just render ise
kuldeep has quit [Read error: Connection reset by peer]
kuldeep_ has quit [Remote host closed the connection]
<pie_>
i think clash has a lot of neat things though
<pie_>
put the open in openfpga xD
<rqou>
azonenberg: up yet?
kuldeep__ is now known as kuldeep
kuldeep has quit [Remote host closed the connection]
kuldeep has joined ##openfpga
m_t has joined ##openfpga
kuldeep has quit [Remote host closed the connection]
kuldeep has joined ##openfpga
<nats`>
pie_, certainly but it means learning a really different language to use it :)
<nats`>
that's why I'm not sure it's a good idea for a start :D
<nats`>
scala based one are easier to learn
<nats`>
and they are open too
kuldeep has quit [Remote host closed the connection]
* qu1j0t3
has tried Chisel ... the developer of SpinalHDL used to drop into #scala and ask for helpers
kuldeep has joined ##openfpga
* qu1j0t3
might take whitequark 's lead and try Migen
<nats`>
migen is a little heavy in my opinion but usable with a lot of support :)
<whitequark>
heavy in what way?
<nats`>
all the declaration, the syntax, I don't know how to say
<nats`>
you have a lot of line to write to do simple things
<nats`>
but again just an opinion
<nats`>
I have to retry it soon becaus eit was a long time ago
<whitequark>
that sounds like a lack of abstraction to me tbh
<nats`>
maybe yes
<nats`>
that's why I said that
<nats`>
could be my problem :)
<whitequark>
but I also think migen shoud probably come with more abstractions out of box
<nats`>
scala has some nice stuff, but too young and unstable imo
kuldeep_ has joined ##openfpga
<felix_>
scala isn't that young and unstable
<whitequark>
scala is the C++ of FP
<whitequark>
which is to say I see why people are drawn to it but I condemn them
kuldeep has quit [Ping timeout: 258 seconds]
<qu1j0t3>
nats`: it's 13 years old
<qu1j0t3>
nats`: I've used it extensively in production... arguably more robust than Java if you are using its facilities
<qu1j0t3>
(and certainly shitloads less work)
<qu1j0t3>
whitequark: like C++, or any language really, just use a "sane subset" (doesn't everyone develop this strategy eventually...?)
<cr1901_modern>
One gripe I have w/ migen is propogating signals between submodules. Kinda mitigateable with Records and proper submodule management, but you can potentially end up w/ a lot of redundant signals.
<whitequark>
qu1j0t3: disagree
<whitequark>
some languages are susceptible to this far more than others
<whitequark>
if you're using, say, OCaml, the only thing you probably don't want to use is, ironically, object-oriented parts
<whitequark>
if you're using C++ then it's far more complex, and far less agreeable between different people
kuldeep_ has quit [Remote host closed the connection]
kuldeep_ has joined ##openfpga
<cr1901_modern>
I like how OCaml references don't condemn you to purgatory for using the imperative parts.
<whitequark>
there's rarely any point for going pure functional *shrug*
<qu1j0t3>
whitequark: well, JS was the classic example ("the good parts"). There is some of Scala i don't use because it's ill considered. A lot of people use a sane subset, and i've seen this tactic widely discussed in many languages. ymmv
<whitequark>
qu1j0t3: yes. my mileage varies. "the good parts" is a strategy for coping with a badly designed language, not an universal
<qu1j0t3>
most languages have some features that are just badly considered
<qu1j0t3>
Scala is one of them, but not the only one by a long shot
<qu1j0t3>
but then it was smart enough to borrow good ideas from ML family as well. mixed bag.
<rqou>
btw clifford is here at 33c3 now
<rqou>
at the openfpga table
kuldeep__ has joined ##openfpga
kuldeep_ has quit [Remote host closed the connection]
kuldeep_ has joined ##openfpga
kuldeep__ has quit [Read error: Connection reset by peer]
<rqou>
azonenberg?
<rqou>
awake?
<rqou>
azonenberg_work?
<nats`>
I was not talking about scala but spinal
<nats`>
sorry I wasn't clear
<nats`>
I think I'll stay with system verilog for long :D
amclain has joined ##openfpga
kuldeep_ has quit [Remote host closed the connection]
kuldeep_ has joined ##openfpga
<pie_>
nats`, btw it compiles to systemverilog too ;D
<nats`>
yep I know that :)
<nats`>
I pretty like clash because for what I tested the code is really readable
<nats`>
(the generated one)
moondeck has joined ##openfpga
<moondeck>
hi
<moondeck>
is OpenFPGA ever going to be supporting Xilinx FPGAs and CPLDs?
pie__ has joined ##openfpga
<azonenberg>
rqou: back
<azonenberg>
rqou: Invite sent
<moondeck>
also, these old AMD PLAs?
pie_ has quit [Ping timeout: 240 seconds]
<moondeck>
sorry, PAL
<azonenberg>
rqou: who's at c3?
<azonenberg>
you, clifford, who else?
kuldeep_ has quit [Remote host closed the connection]
kuldeep_ has joined ##openfpga
<nats`>
balrog IIRC
pie__ has quit [Ping timeout: 240 seconds]
moondeck has quit [Remote host closed the connection]
* felix_
is also at the 33c3
<felix_>
azonenberg: rqou looked at your coolrunner2 project
<azonenberg>
felix_: yeah i want to revive that
<azonenberg>
most of the RE is done, it's now toolchain dev
<azonenberg>
plus a little bit of poking at the macrocell clock stuff
<rqou>
balrog pie_ felix_
<rqou>
and some other people
<rqou>
azonenberg: i have decided that for ccc i will try to fix up your xc2 work
<azonenberg>
I just dont have time to write a compiler for every chip on the planet myself
<azonenberg>
Which is why i want minions :p
<rqou>
i'm trying to understand the larger chip's ZIA bits
<azonenberg>
rqou: please don't work on bitstream gen
<azonenberg>
Focus on PAR
<azonenberg>
I have some refactoring i wanted to do on the bitgen code and basically rewrite it from scratch with a more structural understanding of the chip
<azonenberg>
rather than hard coding offsets and tables
<azonenberg>
i think the greenpak xbpar library would map nicely to coolrunner's crossbar
<azonenberg>
as far as larger chip ZIA, there is no pattern
<azonenberg>
it was generated by starting with a full array then randomly deleting entries to get an X percent probability of routing any given random netlist
<azonenberg>
you can't derive it
<azonenberg>
you can either look at the ISE data files (EULA violation) or decap a chip
<rqou>
I've looked at the data files and it still doesn't quite make sense
<azonenberg>
I know the exact files in $XILINX/ISE_DS/ISE/xbr/data/
Bike has joined ##openfpga
<azonenberg>
and where the config is
<azonenberg>
and was able to double-check my decapped data against it
<azonenberg>
I just cant (legally) look at the config for a larger chip
<rqou>
e.g. xc2c64 has 16 zia bits in the jed
<azonenberg>
it has to be derived cleanly in a traceable fashion, with the photos to prove it
<rqou>
but there should only be 12 inputs
<azonenberg>
So most likely 14 one-hot inputs plus vdd/vss
<azonenberg>
sec, let me pull up a die photo
<azonenberg>
The chips bigger than the 64a are a 2D structure
<azonenberg>
not just one bus
<azonenberg>
I dont know how that ZIA is built
<rqou>
what about the macrocell bits?
<azonenberg>
Do you have fc: access on pr0n?
<rqou>
probably not?
<azonenberg>
Ok
<azonenberg>
Let me make a PDF export...
<azonenberg>
for now
<rqou>
anyways, a single and gate on xc2c64 has three zero bits
kuldeep_ has quit [Remote host closed the connection]
<azonenberg>
so everything in coolrunner is active low, as a general rule
kuldeep_ has joined ##openfpga
<azonenberg>
since blank eeprom=1 and that means off
<azonenberg>
in xc2c32a i observed that either pull-up or pull-down was active low
<azonenberg>
active high*
<azonenberg>
such that 0xFF ZIA is a well-defined non-floating value
<azonenberg>
i forget which
<azonenberg>
aside from that special case, two bits are low during typical use
<azonenberg>
one one-hot input plus "no pull"
<azonenberg>
rqou: See PM
<rqou>
arrgh my wifi is dead
<azonenberg>
That contains all of my notes from decapping plus some things i didn't want to share publicly
<nats`>
I trust you but the example feels pretty useless wen you know verilog or vhdl
<whitequark>
yes, the led blinker example is not better than verilog at all
<whitequark>
I absolutely agree
<nats`>
you have a reset in that code ?
<whitequark>
its purpose is not so much to show how migen is better but rather to demonstrate its basic syntax
<whitequark>
yes
<whitequark>
in migen, every module has a reset and a clock
<nats`>
uhhhh
<whitequark>
(in fact you can only describe synchronous logic in migen)
Ardeshir has quit [Quit: Leaving]
<nats`>
there is a way to remove it?
<nats`>
because there are a lot of case where you need only init not reset
<nats`>
especially high speed pipeline etc
<whitequark>
sure
<whitequark>
well, you don't need to
<whitequark>
migen also emits an initializer (I didn't show it above, it's a typo) and if you never use reset the optimizer will prune it
kuldeep_ has quit [Remote host closed the connection]
<whitequark>
but the sweet part is that you don't have to insert resets manually. if you need them they're always ready
<nats`>
you men if it's not propagated
<nats`>
I'll give it a try again soon to see if I can finally use it :)
<nats`>
my other fear is the timing constraint
<whitequark>
if your module isn't connected to a clock domain with a reset, or with a reset that's never assigned to, it will be pruned
<whitequark>
well
<whitequark>
what about it?
Ardeshir has joined ##openfpga
<whitequark>
you can insert them through the platform code, there is a function
<nats`>
with vivado xilinx removed a lot of tool to meet timing
<whitequark>
false path constraints and such too
<nats`>
and for my hdmi2 core I meet constraint by few ps
<nats`>
each time I change something it is again the random PAR
<whitequark>
nats`: another thing you want to know about migen, dunno if you'll love it or hate it
<whitequark>
there's no x
<nats`>
X ?
<whitequark>
yeah
kuldeep_ has joined ##openfpga
<whitequark>
the verilog "unknown logic value"
<nats`>
what do you mean by there is no x ?
<nats`>
ahh I don't like when I see x :p
<nats`>
if I see x in my sim I fix everything
<whitequark>
in migen everything is always initialized to some value, all combinatorics goes to zero if it's never assigned to
<whitequark>
or whatever you put in Signal(init=...)
<nats`>
sure that point seems sane
<rqou>
azonenberg: so reading your secret doc it seems we don't know enough to actually generate any xc2 bitstreams that use a clock?
<whitequark>
some people love having X
<whitequark>
because it helps validation
<nats`>
oO ?
<nats`>
ahhh to detect problem ?
<whitequark>
yes
<whitequark>
like UB in C. if you have UB then you can have ubsan
<whitequark>
because most programs don't actually *need* signed overflow
<nats`>
ah wait other question
<whitequark>
if you remove that UB then you no longer have vulns added by the compiler, but still have genuine logic bugs, and you can't use a hammer like ubsan to highlight them
<whitequark>
it's a double-edged sword...
<nats`>
in vhdl there is a nasty trick, in simulation integer overflow block the simulation
<nats`>
but in hardware there are no such thing
<nats`>
how behave migen with integer ?
<whitequark>
what
<whitequark>
in migen integer overflow just wraps
<nats`>
does it generate the integer "roll off" ?
<nats`>
ok
<whitequark>
the vhdl behavior sounds insane
kuldeep_ has quit [Read error: Connection reset by peer]
kuldeep_ has joined ##openfpga
<nats`>
I'm talking about signed integer
<whitequark>
migen doesn't have signed integers
<nats`>
it seems sane in simulation to assume that's an error to wrap signed integer
<whitequark>
it only has one signal type, which is unsigned integer
<rqou>
anyways, diamondman and i discussed this at mtvre already
<rqou>
why is it awful?
<cr1901_modern>
I don't think the OpenOCD code is *that* bad... their cathedral-like development tho? Pretty bad.
<lain>
mostly it is slow, but also I had some issues getting it to work with iMPACT, trying to remember what specifically
<rqou>
well, i don't have time to yak shave on jtag stuff either, so i'm ignoring that part for now
<rqou>
also, i'm about to go to bed
<nats`>
anyway if you don't want to loose time get a FTDi based cale compatible with digilent HS2
<lain>
it was something like.. it didn't reset the jtag state machine properly, I think?
<rqou>
it's almost midnight in germany
<nats`>
it'll be cheap and faster to start real work
<rqou>
lain: yeah, the tmbinc code hacks around that
<lain>
I ended up writing my own solution
<rqou>
nats`: i can't do any real testing right now anyways
<rqou>
i'm waiting for azonenberg to get back to me about some of the macrocell bits
<rqou>
otherwise i can't actually generate full bitstreams
<cr1901_modern>
clifford has a JTAG state machine impl for libxsvf that I *THINK* is standalone?
<rqou>
unless anyone knows how to feed a fully P&R design into the xilinx tools?
<nats`>
oky :)
<rqou>
(CPLD flow, not FPGA flow)
<nats`>
time for bed too
<nats`>
23:53
<nats`>
:D
<cr1901_modern>
I've never actually successfully used the CPLD flow
<rqou>
i got an and gate to work in the cpld flow
<rqou>
using the gui
<nats`>
:D
<lain>
oh I remember also: iMPACT and vivado ignore the virtual cable buffer size thing, so it will always send very slowly, and the protocol is very inefficient also
<cr1901_modern>
Migen doesn't support it, though sb0 said he'd accept a patch for it. Never really got around to it
<nats`>
lain it explains why chipscope is so fucking slow