<cr1901_modern> Looks like the smallest I can reliably do is 0805
kuldeep__ has joined ##openfpga
kuldeep__ has quit [Remote host closed the connection]
kuldeep__ has joined ##openfpga
kuldeep_ has quit [Ping timeout: 256 seconds]
<lain> cr1901_modern: reflow, or iron?
<cr1901_modern> iron... too cheapass to buy an oven
<lain> cr1901_modern: what tip?
<lain> personally I prefer the leftmost one
<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
seu has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
seu has joined ##openfpga
<qu1j0t3> alittlejelly
<pie_> rqou, there was noone at the table witha cyclone 3 box on it
<rqou> i have no idea what table that is
<pie_> ok lol nevermind then
<pie_> i was at the tables basically next to the door
<pie_> rqou, want to come find me? :P
<rqou> i'm next to _a_ door
<rqou> are you in hall 3?
<pie_> ill go back, and then yo find the guy with a facemask next to a door ner the icoboard poster
<pie_> :P
<pie_> ETA 40 seconds
kuldeep__ has joined ##openfpga
kuldeep__ is now known as kuldeep
hobbes- has quit [Read error: Connection reset by peer]
hobbes- has joined ##openfpga
m_t has joined ##openfpga
<cr1901_modern> lain: Tip on the right is closest to what I have
<cr1901_modern> whitequark: Prob do need more flux. The QFP job I did was dodgy (but all pins made a connection)
<nats`> cr1901_modern lot of flux and you can even make tqfp with a 2mm head
<nats`> my advice is more to use a tiny drop of solder on the tip
<nats`> if you have enough flux you just touch the pad and it'll slip to the pin
<nats`> you should avoid use the solderbread technic
<nats`> you'll often have shortcircuit behind the tqfp pin
espes_ has joined ##openfpga
<cr1901_modern> solderbread?
<nats`> google translate may help
<nats`> solderwick sorry
<cr1901_modern> ahhh, yea that's what I used
<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]
kuldeep_ has joined ##openfpga
kuldeep__ has joined ##openfpga
kuldeep__ has quit [Changing host]
kuldeep__ has joined ##openfpga
kuldeep_ has quit [Ping timeout: 252 seconds]
m_w has joined ##openfpga
seu has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
seu has joined ##openfpga
<whitequark> nats`: I disagree
<whitequark> "cut for 5 seconds then on for 3" makes for real bad cooking
<whitequark> I'd guess that also puts undue thermal stress on components...
<whitequark> nats`: 15 eur for a skillet, wow
<nats`> whitequark it was an example
<nats`> but I'm pretty sure on nearly all those electric heater it makes no difference
<nats`> the thermal inertia seems to be really big
<nats`> I should measure time on an off I do by hand to stay around 150°C during the ramp up
<pie_> rqou, my plan for ccc, learn how to use this: http://www.clash-lang.org/
<nats`> ahhh clash...
<nats`> I trized it
<nats`> haskell based hardware
<nats`> do you have any knowledge in haskell ?
<pie_> nats`, sadly not much
<nats`> or at least in functionnal language ?
<pie_> im working on it xP
<nats`> in that case I would not go that way
<nats`> I would learn haskell first as haskell
<nats`> and then only go to clash
<pie_> yeah makes sense
<nats`> if you want to learn higher HDL system maybe spinal/chisel or migen if you prefer python
<nats`> I'm thinking about learning Xilinx HLS system
<nats`> they made it free recently but it's again time to spend learning without doing anything productive :p
<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
bpye has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
<rqou> hmm there is a bug somewhere in the gnome stack between screen locking, "keychains" and wifi
<azonenberg> Sooo apparently i do not have an xc2c64a high res shot anywhere?
<azonenberg> But there are four groups of ZIA bus on metal 4
<azonenberg> You have 64 I/O pins plus 64 macrocells which means 128 signals
<azonenberg> So probably 32 signals per group
<azonenberg> how they're divided within that i dont know
<nats`> azonenberg if interested I could decap and image a 144
<rqou> anyways, reading your private report right now
<rqou> hmmm ccc wifi is having problems
<rqou> he claims he basically no longer remembers anything
<rqou> btw azonenberg there is guy here who claimed he did xc2 re many years ago but didn't publish anything
<nats`> I wouldn't use the ccc wifi
<nats`> I would use a data connexion on lte or 3G
<nats`> just saying
<rqou> apparently my sim doesn't allow tethering in europe
<nats`> so vpnize everything
<nats`> I would rent a VPS to put a vpn on it :D
<nats`> but hey I'm paranoid
<rqou> anyways, azonenberg can you explain what has/has not been added to yosys at this point?
<azonenberg> nats`: i have a top metal image
<azonenberg> just no analysis past that
kuldeep_ has quit [Remote host closed the connection]
<azonenberg> rqou: zero work has been done on xc2 synthesis
<azonenberg> i did bitstream RE and a very minimal par
<azonenberg> that basically has to be rewritten from scratch
<azonenberg> trivial greedy PoC
<rqou> and xbpar?
<azonenberg> that's the generic crossbar-device par engine i wrote for greenpak
<rqou> and what's the status of it?
<azonenberg> it should work on coolrunner if you made a front end
<azonenberg> look at gp4par to see an example of how to use it
kuldeep_ has joined ##openfpga
<azonenberg> i would suggest you work either on figuring out the clocking stuff in the macrocell
<azonenberg> or synthesis and initial par
<azonenberg> if you put serious time into that i'll clean up and rewrite my bitgen code and move it to github
<azonenberg> Heading out for a bit, keep me posted
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 joined ##openfpga
kuldeep_ has quit [Read error: Connection reset by peer]
kuldeep__ has quit [Ping timeout: 258 seconds]
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]
kuldeep_ has joined ##openfpga
kuldeep__ has joined ##openfpga
MikeFair_ has joined ##openfpga
kuldeep_ has quit [Ping timeout: 250 seconds]
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
kuldeep_ has joined ##openfpga
kuldeep__ has quit [Remote host closed the connection]
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]
kuldeep_ has joined ##openfpga
kuldeep_ has quit [Remote host closed the connection]
kuldeep_ has joined ##openfpga
m_t has quit [Quit: Leaving]
kuldeep_ has quit [Remote host closed the connection]
kuldeep_ has joined ##openfpga
<rqou> azonenberg: how does PTA/PTB/PTC/CTC/CTR/CTS/CTE work?
<rqou> are they fixed p-terms or selectable?
<rqou> if selectable, then 16*3 for PTA/PTB/PTC = 48
<rqou> there are 56 p-terms
<rqou> so there are 8 not accounted for
<rqou> *if fixed
<rqou> if you subtract the CTx from the 8 you still have 4
m_t has joined ##openfpga
kuldeep_ has quit [Remote host closed the connection]
kuldeep_ has joined ##openfpga
<nats`> whitequark
<nats`> taking a look at migen again the first example is frightening :D
<whitequark> nats`: hmmm? which?
<mtp> i <3 crossbar switches
<nats`> from migen import *
<nats`> plat = m1.Platform()
<nats`> from migen.build.platforms import m1
<nats`> led = plat.request("user_led")
<nats`> m = Module()
<nats`> counter = Signal(26)
<nats`> m.comb += led.eq(counter[25])
<nats`> m.sync += counter.eq(counter + 1)
<nats`> plat.build(m)
<nats`> shit wanted to past url
<mtp> operate my select magnet, buddy
<nats`> from the readme in github
<whitequark> oh yeah
<whitequark> what's so bad about it?
* whitequark is puzzled
<whitequark> seems like every line is doing something useful?
<nats`> m.comb m.sync etc, it feels a lot to write just to blink a led when counter[25] is 1
brizzo has joined ##openfpga
<whitequark> how would you write it?
<nats`> right now I only ave the verilog way in my head
<whitequark> sure, but that's even worse in verilog
<whitequark> let me write the expansion
<nats`> always @(posedge clk) counter <= counter + 1;
<nats`> assign led = counter[25];
<nats`> ?
<whitequark> this is exactly equivalent to m.comb... line and m.sync... line
<whitequark> add a reg [26:0] counter and you're even
<whitequark> but
<whitequark> that's less than what migen does, anyway
_MetalliC_ has joined ##openfpga
<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
<whitequark> I see your point about vhdl now
<nats`> so there are no real type in migen ?
<cr1901_modern> whitequark: Signal(2, signed=True)
<whitequark> cr1901_modern: TIL
<whitequark> nats`: so there *is* signed integer after all
<cr1901_modern> I try not to use it of course, but it is there
<whitequark> nats`: by real type do you mean floating point?
<nats`> I was more thinking about type checked at "compilation time"
<nats`> like signed validity etc
<nats`> like checking length
<whitequark> nats`: no, not really, I actually dislike that part about migen
<nats`> one classic fuck of verilog wire [7:0] signal = {tata[1:0], HERE_A_PARAMETER};
<nats`> thos kind of line is always fun to have in a code
<nats`> if you forget the slice the parameter correctly it'll take 32bit
<nats`> so your signal value will always be PARAM[7:0]
<cr1901_modern> ewww
<cr1901_modern> figuring out multiplication width is also screwy.
<nats`> yep and that's not hard to check
<nats`> the compiler could see if the rules are respected
<nats`> taking account of signedness
<nats`> in the summary of special attribute they show line about self.comb
<nats`> I guess it respect the order used to add statement ?
<whitequark> yes
<nats`> oky
<whitequark> so if you assign twice last wins
<nats`> in combinatorial ?
<nats`> ah yes I see wht you mean
<nats`> but it'll be evaluated like always @*
<nats`> ?
<whitequark> that's what it is lowered into
<nats`> as blocking assignment
<whitequark> blocking?
<cr1901_modern> I don't think Migen will generate blocking assignments
<whitequark> it won't
<nats`> m.comb += led.eq(counter[25])
<nats`> if I add a m.comb depending on led ?
<whitequark> it will generate an always @(*) plus a hack to make it initially run in simulation
<whitequark> I don't understand the question
<nats`> always @*
<nats`> c = a;
<nats`> a = b;
<whitequark> migen won't generate this sort of code, no
<cr1901_modern> it'll prob do assign a = b; assign c = a; I think?
<nats`> same but a little less readable and maybe harder for a simulator
<nats`> but not sure about last point
<nats`> do you have example a little more complex with like equation or stuff like that in m.seq()
<nats`> I'm wondering how you write long sequential block
<nats`> and fsm
<whitequark> also has a testbench example
<nats`> cool thx :)
<nats`> just a note it would be cool to post the generated verilog for comparison :)
<nats`> always a good thing in those kind of post :
<nats`> :)
trap15_ has joined ##openfpga
trap15_ is now known as trap15
<nats`> whitequark I'm not sure to understand what you say in that part "No Verilog processes"
<whitequark> which part exactly? that's three paragraphs
<whitequark> oh, hm
<whitequark> so in migen generated code there's one always statement per clock domain
<nats`> the first paragraph as a start it seems totally logic to assigna signal in one always block only
<nats`> I means it would make no sense exactly because you have no precendance information
<nats`> but you can write:
<nats`> always @(posedge clk) begin
<nats`> a <= b;
<nats`> if(b == c) a <= d;
<nats`> end
<nats`> this is valid
<whitequark> no that's not what I mean
<whitequark> in veirlog I cannot write something like
<whitequark> always @(posedge clk) if(cond) ClockDiv.foo <= 1;
<whitequark> or even
<whitequark> reg [10:0] a; always @(posedge clk) if(cond) a <= 5; always @(posedge clk) a <= a + 1;
<nats`> that's logic
<nats`> how do you know which one has to be the first one in the physical chain
<nats`> I don't see what is troubling you on that point
<whitequark> mmmh, that's actually a good point
<nats`> self.submodules.rx_fsm <= when you do that in fact you're creating a new always block I guess
<nats`> or at least a logical block with a logical order inside for each operation
<cr1901_modern> In the second example, I would've thought the Verilog compiler would treat both always blocks with equal precedence, thus it's "UB"
<whitequark> cr1901_modern: it's not synthesizable
<nats`> you could maybe simulate it but clearly not physically implement it
<nats`> it would end in a short circuit
<nats`> a real one
Ardeshir has quit [Quit: Leaving]
<rqou> does anybody here actually have xc2c32a hardware?
<nats`> yep
<rqou> alright, you will (at some point) become the testing victim :P
<rqou> i apparently only have an xc2c64a
<nats`> doing a small board is not complicated :)
<nats`> it's a tiny tqfp few cap and you're good :)
<nats`> IIRC seeedstudio have small board with xc32 on it
<rqou> i also don't have a modern iMPACT compatible jtag dongle
<rqou> and last time i tried using xsvf + <whatever> it didn't work
<nats`> get a digilent compatible one
<nats`> avoid the old platform usb cable
<rqou> i have an old platform parallel cable :P
<nats`> :D
<rqou> and a ftdi thingy that isn't xilinx-compatible
<nats`> you can even make a digilent clone easily :)
<nats`> in fact if the IO are layouted on good output you can make it compliant
<rqou> i don't have time to be yak shaving
<nats`> I don't remember which channel of the ftdi digilent is using but if you have luck you only have to change vid/pid
<nats`> sure
<nats`> but you'll need it later for your test so... :)
<rqou> there is an ftdi digilent thing?
<rqou> not the old fx2?
<nats`> digilent cable is a ftdi
<nats`> nop
<rqou> i have a fx2 thing on a digilent eval board
<rqou> the spartan 3e starter kit + xc2c64a
<rqou> my ftdi is the amontec jtagkey tiny
<rqou> apparently not compatible
<rqou> can openocd play an xsvf file now?
<rqou> last time i was trying it many years ago with some piece of shit software
<rqou> iirc urjtag
<nats`> urjtag is pretty good
<rqou> not when i tried it
<rqou> maybe part of the complication is that this board has two devices on the scan chain
<nats`> I like it but anyway you can find ftdi cable having same layout or pay 50$ for digilent one
<rqou> once i have an ftdi cable how to i actually program the cpld?
<nats`> if compatible with impact it'll appear there :)
<nats`> and that's really the easiest way for a start
<nats`> or IIRC you can use openocd
<rqou> it's definitely not compatible with impact
<nats`> IIRC I used that
<rqou> "Fixing OpenOCD"
<rqou> i'm tired of doing that
<cr1901_modern> Yes, I can attest to that
<nats`> you see why I use official tool when I dev :p
<cr1901_modern> Their dev process is slow as molasses
<nats`> maybe it's stupid but I always have supported tools
<nats`> did you look at the openocd code ?
<nats`> last time I did it was a nightmare
<cr1901_modern> fwiw, the only reason OpenOCD for S6 works is someone from m-labs added it
<whitequark> openocd is a nightmare alright
<rqou> right, i was going to complain to diamondman about something
<rqou> diamondman: add this thing (http://debugmo.de/2012/02/xvcd-the-xilinx-virtual-cable-daemon/) to your jtag thing
<cr1901_modern> say please, rqou
<rqou> please
<nats`> you should have said "please, rqou"
<nats`> :D
<rqou> lol
<lain> ehhhh
<lain> xilinx virtual cable is pretty awful :D
<cr1901_modern> errrr
<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
<lain> nats`: yeah, virtual cable is REALLY slow
<nats`> whn I see altera signaltap.....
<nats`> fucking software guys again :p
<lain> lol
<nats`> rqou https://www.seeedstudio.com/XC2C64A-CoolRunner-II-CPLD-development-board-p-800.html if it's the same pinout you could replace it by a 32
<nats`> good night guyz :)
kuldeep__ has joined ##openfpga
kuldeep__ has quit [Changing host]
kuldeep__ has joined ##openfpga
kuldeep_ has quit [Ping timeout: 258 seconds]
kuldeep__ has quit [Remote host closed the connection]
kuldeep__ has joined ##openfpga
kuldeep_ has joined ##openfpga
kuldeep__ has quit [Ping timeout: 252 seconds]