bibor has quit [Quit: WeeChat 1.0.1]
talsit has joined ##openfpga
tecepe has quit [Remote host closed the connection]
bibor has joined ##openfpga
tecepe has joined ##openfpga
<azonenberg> whitequark: did you see my yosys issue?
<azonenberg> tl;dr clifford is not going to fix it
<azonenberg> i should really write a verilog linter
* dalias waiting for vhdl frontend and xilinx backend for yosys
<azonenberg> there is partial xilinx back-end support already
<azonenberg> and clifford is working on 7 series bitstream RE
<azonenberg> so when that moves further i expect xilinx back end support to improve massively
<azonenberg> vhdl front end, not sure about
<dalias> what does the partial backend do now?
<azonenberg> just synthesizes to edif, you have to feed to the ISE/vivado map/par after that
<dalias> https://github.com/nickg/nvc is close to covering what you'd need for a vhdl frontend
<azonenberg> it only replaces xst
<azonenberg> whitequark: we should make a list of common RTL coding errors (and suggested rules)
<azonenberg> and look at f/oss verilog linters
<rqou> nobody willing to hack on the giant pile of duct tape known as ghdl? :P
<azonenberg> see if any of them catch most/all of them
<azonenberg> Then decide whether to implement our own, write patches to an existing one, or use it as is
<dalias> ghdl is awful
<dalias> nobody can even figure out how to compile it
<rqou> you don't want to have to take your code and somehow embed it into the gcc tree? :P
<azonenberg> lool
<rqou> it literally does that
<rqou> afaik it duct tapes part of the gcc ada parser and gcc codegen backend with some extra stuff in the middle
<azonenberg> .....
<rqou> you literally compile it as gcc with --enable-languages=c,vhdl or similar
<rqou> it outputs ELF files as the final output
<rqou> and when you execute it, it simulates your design
<azonenberg> lool
<azonenberg> so it doesnt even generate gnu C/ada code
<azonenberg> and feed that to gcc
<azonenberg> That's how i'd implement a quick and dirty simuilator
<rqou> here's some example symbols from ghdl:
<rqou> 00000000004134b0 l F .text 00000000000001ba ieee__numeric_std__xsrl
<rqou> 0000000000413670 l F .text 00000000000002a6 ieee__numeric_std__xrol
<rqou> 0000000000413920 l F .text 00000000000002c8 ieee__numeric_std__xror
<rqou> 0000000000413bf0 l F .text 00000000000003f1 ieee__numeric_std__add_unsigned
<rqou> 0000000000413ff0 l F .text 00000000000003f1 ieee__numeric_std__add_signed
<rqou> 00000000004143f0 l F .text 000000000000033e ieee__numeric_std__xsra
<rqou> 0000000000414730 l F .text 000000000000007e ieee__numeric_std__unsigned_less_or_equal
<rqou> 00000000004147b0 l F .text 00000000000001c3 ieee__numeric_std__signed_less_or_equal
<rqou> 0000000000414980 l F .text 000000000000007e ieee__numeric_std__unsigned_less
<rqou> 0000000000414a00 l F .text 00000000000001c3 ieee__numeric_std__signed_less
<rqou> 0000000000414bd0 l F .text 0000000000000079 ieee__numeric_std__unsigned_equal
<rqou> 0000000000414c50 l F .text 0000000000000079 ieee__numeric_std__signed_equal
<rqou> ghdl and its runtime are also written in ada for extra bonus points
<azonenberg> lol
<rqou> at least debian packages gnat (the ada compiler)
<qu1j0t3> dumb question, what about icarus?
<rqou> iirc icarus is written in C
<rqou> it outputs some custom IR format
<qu1j0t3> no good as a linter?
<rqou> oh idk about that
<rqou> i thought you were referring to icarus vs ghdl
<qu1j0t3> nah, more responding to the linter idea
<azonenberg> qu1j0t3: I'm writing up a page on the wiki to include wishlist requirements for a linter
<azonenberg> The plan is then to check all known linters and see if any detect most/all of these
<azonenberg> and if not, how hard they'd be to extend
<qu1j0t3> azonenberg: ah, perfect
<azonenberg> but first i want to figure out what bugs we're looking for
<azonenberg> Suggest additions
<dalias> nvc is like that except it's an llvm frontend
<dalias> it generates llvm ir that llvm then converts into object files
<dalias> and when you link and run it, it runs your simulation
<dalias> the difference of course is that llvm is made to be used this way
<dalias> it's not some horrible paste-in hack
<azonenberg> lol yeah
<dalias> the problem for using nvc as a yosys frontend tho is that, being designed this way, it relies on the llvm backend to do some of the glorified constant-folding needed for compiling vhdl
<dalias> so it's not sufficient to produce a netlist that can go into the next phase of yosys
<dalias> at least that's how i understand the problem
carl0s has joined ##openfpga
carl0s has quit [Quit: Leaving]
<pointfree> cyrozap: "Note: In order to use an external power supply, while KitProg is connected to the PCB USB, remove diode, D1, from the board. This ensures that VTARG supply from KitProg is not supplied to the target device. KitProg measures the target voltage and adjusts the logic levels on the programming pins accordingly."
kuldeep has joined ##openfpga
<pointfree> I don't really feel like removing a diod from the board right now.
<cyrozap> pointfree: You're using CY8CKIT-059 right?
<pointfree> cyrozap: Yes.
<pointfree> btw, I didn't realize Cypress provides the board design files for the CY8CKIT-059 which may come in handy when I get to designing my own PSoC 5LP product: http://www.cypress.com/file/157976/download
<cyrozap> Oh, yeah, they provide shematics for all their dev kits (or at least all the ones I've looked at)
<pointfree> I got your latest openocd changes too. Thank you!
<cyrozap> np
<cyrozap> And you can separate the two parts of CY8CKIT-059 and power them separately--just don't connect VTARG
<cyrozap> Also, I can't remember if I mentioned this already or not, but I've started to add preliminary support for the 5LP in libopencm3
<pointfree> I haven't yet snapped the board in two. Maybe I should consider it...
<pointfree> You did not yet mention it to me.
<pointfree> (until now)
<pointfree> I have been using that PSOC_compiler repo for my PSoC 5LP ARM samples lately.
<pointfree> ...it has a way to include your own config.conf which generates your own config.hex
<cyrozap> Ah, well, it got me thinking about how we'll eventually combine the programmable logic and executable code during development
<cyrozap> Yeah, I've seen that before
<pointfree> yeah
<cyrozap> I really want to avoid the situation with Cypress's tools where it does parameterized code generation
<cyrozap> Since that makes debugging a total pain
<pointfree> agreed
<cyrozap> and I fell like there's better ways than doing that
<cyrozap> *feel
<cyrozap> Since all the UDBs are basically the same, maybe it would be possible to do dynamic soft-peripheral loading
<cyrozap> Though it would probably increase code size, and I'm not looking to build a whole RTOS...
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
<pointfree> I think that could work out because the routing fabric is intended to be configured/rerouted dynamically.
<cyrozap> Maybe it would be possible to have something like a Device Tree for loading soft-peripherals into UDBs, and have that data structure also point to the drivers for those peripherals so they can be loaded at runtime, kind of like how Linux can dynamically load kernel modules based on what hardware is detected
<cyrozap> So maybe not a full-blown dynamic partial reconfiguration, but have this stuff configurable at startup so you don't have to recompile your C every time you change your Verilog
<cyrozap> I think *that* would provide an enormous benefit over how Cypress's toolchain works right now
<cyrozap> libopencm3 will be used for built-in peripherals (I2C, USB, DMA, etc.)
<pointfree> I really liked the device tree environment in openfirmware. I wonder why it isn't used on microcontrollers currently.
<cyrozap> Microcontrollers are a much more constrained environment than most AP SoCs
<cyrozap> Also, you know how the embedded world is when it comes to tooling :P
<eric_j> only a couple of files change when you change the verilog
<pointfree> The config.hex and the .route?
<cyrozap> pointfree: I think eric_j is talking about the source files
<pointfree> oh
<eric_j> config.hex and cyfitter_cfg.c, plus the boilerplate files
<eric_j> so i could see how it could be useful to have several sets of config
<eric_j> hmm, i don't have a .route file
<pointfree> <project_name>.route ?
<pointfree> (under codegentemp/)
<eric_j> ah, i found it, in codegentemp
<eric_j> yeah
<eric_j> i've split the gcc stuff into a separate dir
<eric_j> i guess the .route is a temporary file or maybe just a report output
<pointfree> .route corresponds to the contents of config.hex
<pointfree> I can read more of it now thanks to your digital system map, eric_j. But there are still a few mysteries in how its contents corresponds to the registers and what goes in them.
<eric_j> well, it doesn't have the datapaths
<pointfree> Neither does the config.hex unless you choose to use the datapaths.
<eric_j> good, yeah, i'm in the dark on most of it
<pointfree> What I still don't understand about the .route file is the coordinate pairs:
<pointfree> e.g:
<pointfree> switch ":udbswitch@[UDB=(2,4)][side=top]:31,93"
<eric_j> mine has the DSI, PLD, datapaths, port config, DAC, and some other stuff i don't recognize
<pointfree> what is 31,93 ?
<eric_j> hmmm...
<pointfree> how does it correspond to register values?
<pointfree> is it the register number times 8 plus the bit position in the register?
<eric_j> do you have an understanding of the 'term' line?
<pointfree> They seem to be either macrocell outputs from a PLD or pin outputs.
<pointfree> ...and input pins
<pointfree> in my 2-to-4 decoder sample q_ set the bit number of the ORT register:
<pointfree> e.g:
<pointfree> switch ":udb@[UDB=(3,4)]:pld0:mc0.q==>:udb@[UDB=(3,4)]:pld0:output_permute0.q_0"
<pointfree> switch ":udb@[UDB=(3,4)]:pld0:mc1.q==>:udb@[UDB=(3,4)]:pld0:output_permute2.q_1"
<pointfree> switch ":udb@[UDB=(3,4)]:pld0:mc2.q==>:udb@[UDB=(3,4)]:pld0:output_permute1.q_2"
<pointfree> switch ":udb@[UDB=(3,4)]:pld0:mc3.q==>:udb@[UDB=(3,4)]:pld0:output_permute3.q_3"
<pointfree> sets:
<pointfree> B0_P1_U0_PLD_ORT0 = 0x01
<pointfree> B0_P1_U0_PLD_ORT2 = 0x02
<pointfree> B0_P1_U0_PLD_ORT1 = 0x04
<pointfree> B0_P1_U0_PLD_ORT3 = 0x08
<eric_j> cool
<eric_j> think udbswitch would be in PLD_* registers too?
<whitequark> azonenberg: whihc verilog issue?
<pointfree> I think those might be B*_P*_ROUTE_* registers, eric_j.
<azonenberg> whitequark: tl;dr combinatorial assign to a reg was allowed by yosys
<eric_j> that would make sense
<whitequark> to a reg?
<pointfree> DSI*_HC* (HC Tile) registers connect to the DSI*_DSIOUTT* and DSI*_DSIINP* (PI Tile, Port Interface) registers and those in turn go to the pins.
<pointfree> B*_P*_ROUTE_HC* HC Tiles work the same way when connecting to PLD*IN* PI Tiles of the UDB's.
<pointfree> The structure of the DSI and ROUTE tiles are identical for the most part.
<azonenberg> whitequark: yes
<azonenberg> not a wire
<azonenberg> even if the reg was assigned by a clocked always block
<pointfree> (The HC Tile)
<whitequark> ah
<whitequark> oh yeah I've hit that problem!
<whitequark> in general I've hit lots of problems where yosys accepts shitty verilog
<azonenberg> Yes
<whitequark> clifford was very unhappy with my code and "synthesis before simulation" :)
<whitequark> not like we have gp4 simulation anyway
<azonenberg> So i'm trying to fix that by writing/fixing/using a static analyzer
<whitequark> I would prefer to not write Verilog
<azonenberg> And step zero of that is to detect the problems in the first place
<whitequark> now that I've learned Migen I am not going to write any Verilog manually for my personal projects
<azonenberg> define*
<defparam_> azonenberg: do you have a check for assignments of a register in a clocked process.. if there is a state in which they register does not get assigned then it is consider a latch
<azonenberg> If unclocked, you mean
<azonenberg> It's totally legal to not assign in one state of a *clocked* process
<azonenberg> that's just a clock enable
<azonenberg> if combinatorial, then you get latches
<azonenberg> that's already on my list
<azonenberg> To be clear, none of this is implemented yet
<azonenberg> Just coming up with requirements at this point
<defparam_> ah yes, thanks for clearing that up. Thats what i meant
<defparam_> OK :)
<pointfree> ...you can see that the horizontal wire is connected in two places with the 0..7S wires and the vertical interface lines are also connected in two places. This allows routing signals from HV blocks to upper and lower UDB's or even in a U-turn (I would think) if both 0U and 0S bits are set for instance.
<pointfree> ...also notice the connections go in a diagonal pattern. This means the PI nyble for the upper UDB is flipped in the register.
<eric_j> do you have a map of the stubs? (istub and ostub)
<pointfree> eric_j: Those look like they refer to PI Tiles
<pointfree> switch "Stub-:udbswitch@[UDB=(2,4)][side=top]:v23==>:udb@[UDB=(3,4)]:pld0:input_permute.input_11"
<pointfree> corresponds to:
<pointfree> B0_P1_ROUTE_PLD0IN2 = 0x80
<pointfree> ...but that was for a udbswitch into a PLD input term.
<pointfree> notice how the Stubs for dsiswitch's all end with a dsihc_
<rqou> i think i asked this before, but opinions on Migen vs MyHDL?
<rqou> also vs Chisel or <your favorite "alternative" HDL>
<azonenberg> rqou: i have found none that i like
<azonenberg> i dont like python
<rqou> that's unusual
<whitequark> python is garbage
<rqou> I usually don't hear too many bad things about python
<whitequark> it's very badly designed
<whitequark> not as badly designed as php, mind you ;p
<azonenberg> whitequark: that is a hard bar to top
<azonenberg> :p
<whitequark> which is why i guess it got so popular
<eric_j> i think the idea of using python is good, but myhdl doesn't use it to its full capability
<rqou> sure, it's made of duct tape, but it's reasonably sane and consistent
<azonenberg> rqou: verilog with a slightly better type system and curly braces instead of begin/end would be fine for generic RTL in my opinion
<azonenberg> then custom code generation for complex abstractions of things like NoCs
<whitequark> rqou: myhdl is also quite badly designed, because it uses python syntax to describe logic, instead of using python semantics to build up data structures to describe logic
<rqou> but vhdl has a "slightly better" (depending on your opinion) type system
<azonenberg> Which is basically what i do
<whitequark> myhdl with quasiquotation/antiquotation would be more acceptable
<whitequark> havne't used chisel, haven't used hardcaml enough to comment
<eric_j> whitequark, yeah, separate compile-time from the thing you are actually synthesizing
<whitequark> yeah, needs staging
<whitequark> like racket
<whitequark> there's actually some hdl in racket innit?
<rqou> but afaik myhdl doesn't run your python to do synthesis
<rqou> it manipulates the ast
<rqou> how is that different from explicitly building data structures?
<whitequark> how do you abstract over control flow?
<whitequark> that's exactly the problem with myhdl, that it is actually completely unrelated to python
<whitequark> it abuses the python syntax
<rqou> isn't that just the difference between a shallowly embedded DSL and a deeply embedded DSL?
<whitequark> in technical terms, yes
<whitequark> and I consider deeply embedded DSLs without quasiquotation bad design
<whitequark> myhdl is also event-driven which is stupid
<rqou> as opposed to?
<whitequark> migen explicitly models combinatorial and synchronous circuits
<whitequark> in different clock domains
<rqou> but why do you have to explicitly specify that?
<rqou> as opposed to it happening "by magic"?
<whitequark> what?
<rqou> combinatorial vs synchronous
<rqou> and clock domains
<rqou> as opposed to the event driven model where FFs/latches are inferred
<whitequark> why would I *want* the event driven model?
<whitequark> most of the valid programs written using the event driven model are unsynthesizable
<whitequark> migen is just following the "make illegal states irrepresentable" principle
<rqou> afaik myhdl doesn't feel the need to guarantee that
<whitequark> that's why it's bad
<whitequark> migen doesn't aim to produce code for anything but synchronous digital logic, and it also doesn't aim to describe simulations (which are done by simply cosimulating with python)
<whitequark> s/produce/express/
<rqou> but that means that migen isn't suitable for wizards/lunatics who want to do weird stuff like asynchronous logic
<whitequark> not true
<rqou> so you can still describe something like that?
<whitequark> you can't. but you can write that in verilog (assuming your synthesis toolchain takes verilog, which is usually true) and instantiate that from migen
<rqou> but then you're forced to use verilog
<rqou> afaik myhdl wants to be able to substitute _all_ the use cases of verilog
<whitequark> that's exactly what's bad about it, yes
<whitequark> you will never design a language better than C++ by trying to solve all of the use cases of C++
<whitequark> the vast majority of logic doesn't need the weird shit you describe, so why is it expressible? that'll just create bugs
<whitequark> for the odd case where you *do* need the weird shit, you have the escape hatch
<rqou> i guess part of the problem is that in the HDL world the escape hatch is quite annoying to use
<rqou> you have to create a separate module and screw around with getting cosimulation to work
<whitequark> you can also just instantiate the primitives directly
<whitequark> (in migen, that is)
<whitequark> yes, cosimulation will be trickier, as migen's simulator cannot be used. you'll need to run iverilog on the compiled output
<whitequark> and then interface that through VPI or something. this isn't currently implemented
<rqou> but what if your testbench isn't compiliable into verilog?
<whitequark> it doesn't need to be?
<rqou> then your testbench needs to poke VPI manually
<whitequark> no? it just pokes migen as usual
<whitequark> and migen would translate that into VPI calls
<rqou> that does work?
<rqou> or it's not implemented yet?
<whitequark> planned but not implemented
<rqou> ah ok
<whitequark> there's nthing fundamentally troublesome with it, it just needs to be done
<whitequark> i looked into it like a year ago
<rqou> in general imho we need a significantly less shitty cosimulation interface as opposed to the current "half of VPI"
<whitequark> agreed
amclain has quit [Quit: Leaving]
<rqou> it should be possible to have a duct tape soc project that has modules written in migen, myhdl, vhdl, verilog, chisel, etc.
<rqou> and cosimulate them all together
<rqou> ideally
<rqou> oh for bonus lulz
<whitequark> imo this only needs some shared RTL format, and some black box interface to abstract testbenches etc
<rqou> ghdl (the FOSS VHDL simulator) is best interfaced with using VPI
<whitequark> today... that's verilog and vpi
<rqou> not VHPI
<whitequark> let's not talk about ghdl
<whitequark> it's gcc-related.
<whitequark> of *course* it is crap
<rqou> supposedly it's currently the most complete FOSS VHDL simulator
<rqou> although I'm definitely not going to hack on it anytime soon
<whitequark> gcc is often the most complete something, that's true
<rqou> can't be bothered to deal with both Ada and the awful build system
<whitequark> except if we're talking about libstdc++
<rqou> i thought they claimed libstdc++ had all of c++11 done?
<rqou> and most of 1y and 1z?
* whitequark looks at the calendar
<whitequark> well
<rqou> hey, msvc doesn't have it all done :P
<whitequark> my chief complaint is that libstdc++ shipped present but completely broken std::regex in 4.8 and 4.9
<whitequark> msvc is actually very rapid with C++, they just don't care about C
<rqou> wait regex is under std::? (don't use c++ much)
<whitequark> (std::regex) specifically it would compile and you could use it
<whitequark> but it silently did nothing if you used a + qualifier or something like that
<rqou> is it DFA or backtracking?
<whitequark> iirc dfa
<whitequark> read the spec
<whitequark> never mattered for my use case
<rqou> so why do people keep using external libraries like pcre?
<rqou> (I don't usually use regexes at all)
<whitequark> pcre accept substantially more regexps than std::regex
<whitequark> you have stuff like unicode character classes
<whitequark> for simple cases though pulling in pcre would be dumb
<rqou> but stuff like unicode character classes doesn't give you any more computational power
<rqou> it's just simpler to write
<whitequark> technically speaking, C++ doesn't give you any more computational power as opposed to writing x86 opcodes by hand
<whitequark> it's just simpler to write
<rqou> ok, fine :P
<whitequark> well, pcre also explicitly permits backtracking
<whitequark> i think std::regex also misses stuff like lookaheads and lookbehinds
<rqou> ah ok
<rqou> yeah, i remember that pcre supposedly did have more computational power than DFA
digshadow1 has joined ##openfpga
digshadow has quit [Quit: Leaving.]
<whitequark> has both DFA and NFA apparently
<whitequark> and it does in fact have character classes
<rqou> i should really relearn c++ at some point
<whitequark> unicode ones that s
<whitequark> but no lookaheads or lookbehinds
<whitequark> anyway there is quite little reason to pull in pcre IMO
<rqou> imho c++ has had an awkward transition from "C with classes" to whatever it is now
<whitequark> I'm not sure if it ever was "C with classes"
digshadow has joined ##openfpga
<rqou> c++98?
<whitequark> that has templates already
<whitequark> and stuff like SFINAE
<whitequark> not like C with classes is a good idea, you are combining several of the worst ideas in the history of computing
digshadow1 has quit [Ping timeout: 250 seconds]
<rqou> C, and classes? :P
<whitequark> C and what people mistakingly consider object-oriented programming
<whitequark> not that the actual object-oriented programming is much better, but it at least has redeeming properties
<pointfree> eric_j: I think I've figured out the dsiswitch Stubs:
<pointfree> DSI1_DSIOUTT0: 0x400141D4 <- 0xC0 dsihc_bottom:v90==>:ioport0:inputs1_mux.in_2 (v90) and dsihc_bottom:v91==>:ioport0:inputs1_mux.in_3 (v91)
<pointfree> DSI1_DSIOUTT1: 0x400141D6 <- 0x20 dsihc_bottom:v85==>:ioport0:inputs1_mux.in_1 (v85)
<pointfree> DSI1_DSIOUTT2: 0x400141D8 <- 0x40 dsihc_bottom:v98==>:ioport0:inputs2_mux.in_2 (v98)
<pointfree> 90, 91, 85, 98 appear to be global bit coordinates for at least DSIOUTT. Bit coordinates because high and low nybles are included contiguously. You can see if you subtract them from each other.
<pointfree> 98-85=13 0b00100000 (0x20) 0b01000000 (0x40), Count from the start of the byte (least signficant bit) for the v-number, both nybles are included.
<pointfree> Now we just need to find out what's at the origin :)
<pointfree> I think the origin for the bottom row of DSI's is at DSI0 because there are 6 DSIOUTT registers and 6 DSI's per row: 6*8*2=96, about in the range of the numbers I was getting for the above example which was for DSI=(1,4) aka DSI1.
digshadow has quit [Quit: Leaving.]
<eric_j> ah nice so you've got 1 bit per v-coordinate?
<pointfree> yes, it seems so.
<pointfree> I imagine it works the same way for the other types of DSI and ROUTEing registers.
digshadow has joined ##openfpga
digshadow1 has joined ##openfpga
<pointfree> eric_j, I think we will find there is a separate v-coordinate system for each type of routing register (HC, HS, VS, PI, HV_L, and HV_R).
<eric_j> PI being PLD*, etc?
<pointfree> PI being Port Interface (PLD*IN*, DSIINP*, and DSIOUTT* for instance)
<eric_j> right
digshadow1 has quit [Client Quit]
<pointfree> right
digshadow has quit [Ping timeout: 252 seconds]
digshadow has joined ##openfpga
<pointfree> There's a VS bit for every hvswitch triple. This includes both ROUTE and DSI registers together. Horizontal Segments (HS) and Vertical Segments being routes that take a signal away from a UDB Pair, etc.
<pointfree> Unlike the DSIOUTT, these VS bits appear to be counted nyble-wise. That's probably because they are associated with different sides of the UDB array (top or bottom row of DSI's and such)
massi has joined ##openfpga
Bike has quit [Quit: slosh]
hexagon5un has joined ##openfpga
hexagon5un has left ##openfpga [##openfpga]
<whitequark> rqou: what are those spinny things outside of half of the shops?
<whitequark> some kind of charm or?
<rqou> ?
<rqou> in HK?
<whitequark> yup
<rqou> i'm not sure exactly what you're referring to? got a pic?
<whitequark> an illuminated cylinder with a spiral printed in it, which spins around its axis
<rqou> a barber pole? I haven't seen those around "half the shops"
<whitequark> hm
<rqou> wow my firefox is lagging like shit right now
<rqou> 8gb ram resident, maybe that's why :P
* rqou closes some tabs
<whitequark> I had no idea
<whitequark> why is it spinning anyway
<rqou> hmm I actually never considered why it's spinning
<rqou> "In some parts of Asia, a red, white and blue barber pole is used as a symbol for a brothel.[citation needed]"
<rqou> I actually never knew that
<whitequark> [citation needed]
<rqou> :P
<rqou> some other parts of that section do have citations though
<rqou> hmm 8gb resident memory really seems to be tripping something in firefox
<rqou> it gets MUCH laggier
<rqou> closed some tabs to 6gb and it's not lagging anymore
<nats`> those barber pole are representing bleeding bandage in the wind IIRC
m_w has joined ##openfpga
<azonenberg> rqou: lol
<azonenberg> i generally kill all of my ff instances and restart them ~weekly
<azonenberg> if the OOM killer in that VM doesn't do it for me
<azonenberg> if i'm away from home for a few days, i often come home and find the browser in my facebook vm has terminated
<azonenberg> b/c fb leaks ram so badly
digshadow has quit [Ping timeout: 265 seconds]
ylm has joined ##openfpga
amclain has joined ##openfpga
ylm has quit [Ping timeout: 245 seconds]
X-Scale has quit [Quit: HydraIRC -> http://www.hydrairc.com <- The alternative IRC client]
digshadow has joined ##openfpga
digshadow has quit [Ping timeout: 260 seconds]
Bike has joined ##openfpga
azonenberg_work has joined ##openfpga
tecepe has quit [Remote host closed the connection]
massi has quit [Remote host closed the connection]
digshadow has joined ##openfpga
<Lord_Nightmare> dalias: are you the same dalias from gnuboy?
<dalias> /msg nickserv info dalias
<Lord_Nightmare> so, yes. gotcha.
<Lord_Nightmare> been a long time
tecepe has joined ##openfpga
ylm has joined ##openfpga
ylm has quit [Ping timeout: 260 seconds]
MZPX has joined ##openfpga
<cr1901_modern> dalias: Doing /msg nickserv didn't tell me anything :P
<cr1901_modern> Most references to gnuboy point to a defunct website. Just assuming that people tend to keep the same aliases over time.
MZPX has quit [Read error: Connection reset by peer]
X-Scale has joined ##openfpga
digshadow1 has joined ##openfpga
digshadow has quit [Read error: Connection reset by peer]
digshadow1 has quit [Read error: Connection reset by peer]
digshadow has joined ##openfpga
digshadow has quit [Client Quit]
<azonenberg_work> So, leaving work shortly
<azonenberg_work> waiting for a rom to dump now :p
<azonenberg_work> When i get home i think i'm gonna do some work on the HiL testing flow
<cr1901_modern> Been looking into getting back into amp design (and I'll need to add at least an impedance converter amp to my FPGA PCB). I'd love a curve tracer, 'cept for the part where they're $10,000. Maybe I'll make a DIY version...
<cr1901_modern> Joys of not having an oscilloscope.
<rqou> you really should pick up an oscilloscope
<rqou> unfortunately, finding one cheaply may not be easy depending on where you are
<cr1901_modern> No space. No money :(.
<cr1901_modern> http://www.ebay.com/itm/Transistor-Curve-Tracer-adapter-Oscilloscopes-Plus-Power-supply-UnAssembled-Kit-/291531434190 This is cute though. Mildly concerned about the power PCB that it comes with (shouldn't there be more clearance at the AC end?)
<rqou> heh, if I really need to use a curve tracer, I can just convince someone to let me into one of UCB's teaching labs
<rqou> they have maybe 8 curve tracers that are nowhere near fully utilized
<cr1901_modern> I don't really need a curve tracer lol. I just think the graphs are pretty :P. I don't think this kit will let me plot a load line anyway
<rqou> as for oscilloscopes, a low end Rigol scope is ~$300 (USD)
<cr1901_modern> http://i.ebayimg.com/images/g/UvYAAOSwyQtVwN6W/s-l500.jpg Great board. AC GND and AC connections. One of them is live, but which one is neutral and earth?
<azonenberg_work> Gonna guess it doesnt matter
<rqou> wait is that board feeding 170VDC straight into a 7815?
<azonenberg_work> lol i hope it is doing some kind of switching
<azonenberg_work> but it might just be a voltage divider :P
<rqou> definitely no switching
<rqou> possibly a divider
<rqou> but I don't see where it is
<cr1901_modern> there appear to be no resistors on this board
<azonenberg_work> wtf
<rqou> wtf
* azonenberg_work looks again
<cr1901_modern> those are all diodes
<rqou> the max input voltage is supposed to be 35V
<azonenberg_work> So there is a... fuse?
<azonenberg_work> then a bridge rectifier
<azonenberg_work> two big caps
<azonenberg_work> oh, lol
<azonenberg_work> It says AC
<azonenberg_work> doesnt say what voltage
<azonenberg_work> i bet this is for like 24VAC
<azonenberg_work> after a xformer
<cr1901_modern> Ahhh
<azonenberg_work> to, in combination, make a cheap heavy inefficient linear PSU
<cr1901_modern> inefficient and linear are redundant
<azonenberg_work> not necessarily
<rqou> that's a pretty basic PSU
<azonenberg_work> at ultra low loads, they're better than a switcher
<rqou> how much are they asking?
<azonenberg_work> like, nA to uA range
<cr1901_modern> Still am not sure about something... looks like "G" connects to the gnd terminal of the caps and regulators, but the rectifier's reference point is the second "AC" connection.
<azonenberg_work> I guess that is the one they call neutral
<azonenberg_work> this is clearly not an isolated converter
* cr1901_modern doesn't know what that entails
<cr1901_modern> Are "G" and "AC" going to be referenced to each other? IIRC, earth ground isn't even supposed to carry current unless something goes wrong
<cr1901_modern> azonenberg: Are you referring to the fact that the caps and rectifier's grounds might be at different potentials and related to each othe?
azonenberg_work has quit [Ping timeout: 245 seconds]
digshadow has joined ##openfpga