digshadow has quit [Quit: Leaving.]
digshadow1 has joined ##openfpga
digshadow1 has quit [Ping timeout: 240 seconds]
digshadow has joined ##openfpga
Lord_Nightmare has quit [Ping timeout: 244 seconds]
Lord_Nightmare has joined ##openfpga
doomlord has joined ##openfpga
talsit has joined ##openfpga
digshadow has quit [Ping timeout: 272 seconds]
digshadow has joined ##openfpga
eightdot_ has quit [Ping timeout: 240 seconds]
doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
digshadow1 has joined ##openfpga
digshadow has quit [Ping timeout: 240 seconds]
<pointfree> http://www.arachnidlabs.com/blog/2013/02/25/freeloader/ <--- says a lot about Cypress as a company.
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
<rqou> wow
<rqou> that's an order of magnitude better than the typical "even this .h file of registers has a restrictive license"
digshadow1 has quit [Ping timeout: 244 seconds]
digshadow has joined ##openfpga
<azonenberg> Not bad
<azonenberg> rqou: i'm used to having to make my own register.h files from the datasheet
<azonenberg> lol
<azonenberg> And either implement the libc functions i need, or port a libc
<rqou> what happens if the hardware vendor decides that they won't document certain registers and require you to either use their .a or to jump to a helper in rom?
<azonenberg> Never had that happen
* rqou looks at NXP
<azonenberg> I've mostly used MCHP parts
<rqou> the LPC11U37F doesn't have documentation for at least the eeprom bits
<azonenberg> ...
<rqou> idk why that's even secret
<azonenberg> Why is the datasheet for the marvell 88e1111 ethernet PHY secret?
<azonenberg> like, gigabit ethernet is probably 20 years old
<rqou> it is?
<rqou> that's also dumb
<azonenberg> i doubt there's much secret in the register interface
<azonenberg> that, plus the fact that the chips are difficult to get hold of, is one of the reasons why a) i think it's dumb that fpga devkits use them
<azonenberg> and b) i will never use their parts in a design
<azonenberg> marvell, vitesse, broadcom are my current blacklist
<rqou> i'm pretty sure some random driver in linux probably knows how to poke that phy though
<azonenberg> qualcomm is de facto blacklisted but i knew better than to try buying their stuff
<azonenberg> So i never actually had a bad experience that would put them on it :p
<azonenberg> yeah i was able to find enough registers to use it on my devkits
<azonenberg> But i refuse to use it in new designs on moral principle
<rqou> how about realtek and their infinity bugs?
<azonenberg> Never tried using a realtek part
<rqou> 51 different versions of the same/similar chip
<azonenberg> lool
<rqou> scrolling down then shows a number of really obvious and intuitive _phy_config functions
<rqou> 3300 static const struct phy_reg phy_reg_init[] = {
<rqou> 3301 { 0x1f, 0x0002 },
<rqou> 3302 { 0x10, 0x0008 },
<rqou> 3303 { 0x0d, 0x006c },
<rqou> 3304
<rqou> 3305 { 0x1f, 0x0000 },
<rqou> 3306 { 0x0d, 0xf880 },
<rqou> etc.
<azonenberg> thats ust a list of register IDs and values lol
<azonenberg> Good enough to put it in whatever config the driver expects
<azonenberg> but...
<azonenberg> for example my fpga ethernet mac expects RGMII in-band status
<azonenberg> Which is supported in most phys but requires a special register setting to use
<rqou> huh, wasn't aware of that feature
<rqou> i thought you needed MDIO to poll phy status
<azonenberg> No
<azonenberg> In RGMII mode specifically
<azonenberg> There is an optional, not mandatory, feature
<azonenberg> where when tx_en is low
<azonenberg> link speed/state are encoded in the data words
<azonenberg> Some phys support it in gmii mode, like the 88e1111
<azonenberg> (again non-default)
<azonenberg> and nonstandard
<azonenberg> My MAC certainly could implement polling, i used to do that
<azonenberg> but the in-band mode was less gates
<azonenberg> I may eventually make it configurable at synth time
<rqou> i love how "what the spec says the phy does" and "what people actually use in the phy" don't match up at all
<azonenberg> Lol
<azonenberg> i forget what 802.3 specifies for data when rx_en is low
<azonenberg> i know in RGMII the spec defines the in-band status feature
<azonenberg> But it's a MAY, not a MUST
<azonenberg> So far most but not all phys i've found support it
<azonenberg> there was one microsemi one that did not
<azonenberg> which i cant use with my core unless i poll
<rqou> my father had some interesting stories of phy/switch hacks at the network equipment company
<azonenberg> I primarily use the KSZ90x1RN in my designs
<azonenberg> Which is RGMII, QFN, in-band status supported
<azonenberg> So thats what i've tested most
<azonenberg> Also if anybody is curious
<rqou> they had a box whose architecture was basically "xilinx fpga inserted between broadcom switch and the phys"
digshadow1 has joined ##openfpga
<azonenberg> https://github.com/azonenberg/antikernel antikernel code, raw repo export into a subdir of the github repo
<rqou> apparently they did a thing where the phy and switch were configured to use different interframe gaps
<rqou> and then the fpga would steal some of the cycles to compute stuff
<azonenberg> this will gradually get refactored as the build system matures enoguh i can start building parts of antikernel with it
<azonenberg> at some point i will be moving libjtaghal out of that to a separate repo
<azonenberg> So it can be used standalone
<openfpga-github> [yosys] azonenberg pushed 48 new commits to master: https://git.io/vPvyY
<openfpga-github> yosys/master 2343dda Kaj Tuomi: Use dict lookup instead of many ifs.
<openfpga-github> yosys/master 279298c Kaj Tuomi: Fix: Unresolved reference.
<openfpga-github> yosys/master 74dd36a Kaj Tuomi: Some syntax fixes. Generator and comma separated list modifications.
digshadow has quit [Ping timeout: 272 seconds]
digshadow1 has quit [Ping timeout: 240 seconds]
eightdot has joined ##openfpga
amclain_ has quit [Quit: Leaving]
digshadow has joined ##openfpga
digshadow1 has joined ##openfpga
digshadow has quit [Ping timeout: 244 seconds]
cr1901_modern has quit [Read error: Connection reset by peer]
doomlord has joined ##openfpga
digshadow1 has quit [Quit: Leaving.]
digshadow has joined ##openfpga
Bike has quit [Quit: one]
doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
doomlord has joined ##openfpga
cr1901_modern has joined ##openfpga
<whitequark> azonenberg: anything happening in openfpga?
<azonenberg> whitequark: It's been slow because of work travel
<azonenberg> i did a bunch of work on the DAC but still have some bugs to iron out
<azonenberg> i'm traveling until the 12th of next month and away from the dev boards so i can't test
<azonenberg> doing antikernel stuff in the meantime
<whitequark> azonenberg: ok I see
<azonenberg> Hopefully after that things will reach some semblance of normalcy
<azonenberg> wedding and all near-term travel out of the way
<azonenberg> possible 1-day trip for work next month and a conference in january but thats it
<whitequark> ack
<reportingsjr> whitequark: I feel bad for asking this here, but I searched and couldn't find anything reasonable.. In solvespace do you know if the best way to make a workplane off of a circle is to draw construction lines constrained to that circle?
<reportingsjr> (btw, solvespace is absolutely fantastic)
<whitequark> I'm glad you like it
<whitequark> and yes
<whitequark> well, if the circle is parallel to xy/xz/yz
<whitequark> then you can just select the center.
<reportingsjr> ohhh, that is much easier
<reportingsjr> huh, so I extruded one circle, then made a concentric circle inside of that one (in a new workplane) and extruded that, and now my original extruded circle isn't shown.
<reportingsjr> The extruded circle's dimensions are shown, but the 3d part isn't.
<whitequark> show me the file?
<reportingsjr> certainly
<reportingsjr> g006 is supposed to be a small cylinder and then g008 is supposed to be a cylinder stacked on top of that one
<reportingsjr> which should exist in g007 and g009 respectively
<whitequark> you've selected g006 and then extruded, right?
<reportingsjr> Yep
<whitequark> and then... you've inserted another sketch just before the extrusion group?
<reportingsjr> Then I made a new workplane off of g006 by selecting the center point of that circle and made g007.
<whitequark> the sequence is a bit confusing
<reportingsjr> Yeah, I noticed that the groups are out of order. I don't know why it did that.
<whitequark> when a new groupis inserted, it's inserted right after the active group
<whitequark> used to be that you couldn't do that at all
<whitequark> but that meant you sometimes can't do an operation at all
<whitequark> ok
<whitequark> so the reason for your issue is in g006
<whitequark> activate it
<whitequark> do you see the error message?
<reportingsjr> ohhhh
<reportingsjr> I forgot to mark those as construction lines. Doh!
<whitequark> yup
<reportingsjr> Beautiful, thank you!
Orfeil has joined ##openfpga
<Orfeil> Hi
<Orfeil> May be a stupid question. How I fix "cannot find -llog"?
<whitequark> did you check out submodules?
<Orfeil> Yes. git submodule update
<Orfeil> Also yosys built. and cmake .. -DYOSYS_COMMAND=$HOME/code/yosys/yosys done
<Orfeil> In make, here: [ 76%] Linking CXX executable ../../bin/gp4par -llog is required
Orfeil has quit [Quit: Page closed]
<whitequark> what's your system/compiler?
digshadow has quit [Ping timeout: 264 seconds]
amclain has joined ##openfpga
Bike has joined ##openfpga
azonenberg_work has joined ##openfpga
digshadow has joined ##openfpga
balrog has quit [Ping timeout: 252 seconds]
doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
azonenberg_work has quit [Ping timeout: 244 seconds]
doomlord has joined ##openfpga
<reportingsjr> whitequark: thanks for you help earlier! The three.js stuff is pretty nifty :) (http://jonneal.me/omron-tl-q5mc1-3d-model/ )
<whitequark> three.js seems to be one of the most used features in solvespace
<reportingsjr> haha, really?
<whitequark> yes
<whitequark> and for me it was practically an afterthought
<reportingsjr> It is really nice to be able to present models on a web page so easily
<whitequark> reportingsjr: tip: before exporting, center your view on the center of the part with F4
<reportingsjr> althought it was mildly confusing at first. I didn't realise there were three different js libraries that I needed to include
<whitequark> (this needs git master, iirc)
<whitequark> then it will rotate properly and not like you have now
<reportingsjr> I am using git master. I was centered I believe until I adjusted the viewport size.
<whitequark> hmmmm
<whitequark> oh yeah
<whitequark> this is not very ergonomic
<whitequark> anyway, did you realize that what you can do is export a .html and then look into it for the libraries?
<whitequark> how can I improve that flow? "download the version I used here" suggests it is a bad flow
<reportingsjr> I just centered it via F4 and reuploaded it. Still not centered, will investigate in a bit.
<whitequark> and for the other two libs that you can download... well
<whitequark> the thing is that there's no guarantee newer versions will be compatible
<reportingsjr> whitequark: The two options currently are download just the js for the mesh or download a standalone html file
<whitequark> but the ones that ship embedded in the solvespace binary, definitely will be
<whitequark> yeah
<reportingsjr> fair enough
<whitequark> the idea is that you download a standalone html to see how it works
<whitequark> and then for your website if you need more than one model (and not an iframe)
<whitequark> you rip that apart and copy wherever convenient
<whitequark> I'm not sure how can I simplify that, given that for anyone with an understanding of webdev basics a working example is probably the most convenient way
<reportingsjr> Right, I personally would have preffered that the html version would have been just copy and paste on to the page where I want it and voila
<whitequark> well
<whitequark> it's a very large file
<reportingsjr> Yep
<whitequark> you can insert it using an iframe
<reportingsjr> true, but that is kinda yucky
<whitequark> it should scale up to the size of the iframe, I believe
<whitequark> why?
<reportingsjr> not a fan of iframes. They don't behave well when you need to change the sizes of things.
<whitequark> but don't yu have the exact same problem right now?
<whitequark> an explicitly sized iframe vs explicitly sized div
<reportingsjr> here was the issue I had with the workflow. There is a "demo" export basically where it is tidily packaged up. Then there is the advanced one where people are expected to know how to embed everything already. That would have been fine if searching for "solvespace js" would have turned up anything. :P
<whitequark> right, so my thinking was that the "demo" is enough of documentation
<whitequark> guess not
<reportingsjr> whitequark: I'm not sure what's up with the centering issue as I'm feeding the height and width in to the SolveSpaceControl object rather than making a div of a certain size.
<reportingsjr> whitequark: it would have been if Three.js wasn't 95% of the file. I actually scrolled through most of the file quickly to see what was there, separated out the SolveSpaceControls library and included three.js on its own.
<reportingsjr> Then when that didn't work I looked at the source of one of your blog posts and realized there were two other much smaller libraries hidden in there.
<whitequark> ack
<whitequark> regarding centering...
<whitequark> I'm actually unsure myself
<reportingsjr> whitequark: I think a small comment at the top of the demo version specifying that there are three libraries there would have cleared things up.
<whitequark> usually what I do is build the model such that it's centered around origin
<reportingsjr> whitequark: if you would like I can create a PR for that.
<whitequark> yeah, please do!
<whitequark> just an issue is fine
<reportingsjr> ok
<reportingsjr> whitequark: yeah, the origin is in the bottom left of that file though. Definitely not where it is currently centering.
<whitequark> ok. hm.
<whitequark> no idea :D
<whitequark> maybe ask cr1901_modern, he wrote most of the exporter code... though not the part that copies the viewport settings into the viewer
<reportingsjr> cr1901_modern: Hi! I embedded a model from solvespace in a blog post (http://jonneal.me/omron-tl-q5mc1-3d-model/ ) and passed it a width and height param and for some reason the model isn't centered. I'm going to poke at it, but if you might have an idea of what would cause that I'm all ears.
<whitequark> is it centered without w/h params?
<whitequark> (in the demo)
<reportingsjr> hah
<reportingsjr> whitequark: There was an offset specified... :)
<reportingsjr> cr1901_modern: ignore me
<whitequark> yes, the offset is supposed to be specified
<whitequark> it's the offset of viewport origin during export vs model origin
<whitequark> the point at this offset is supposed to ... oh
<reportingsjr> Is the model origin specified by F4?
<whitequark> no, F4 alters viewport origin
<reportingsjr> ok
<whitequark> model origin is always at (0,0,0)
<whitequark> i.e. the initial reference point
<reportingsjr> Yep
<whitequark> reportingsjr: going out on a limb: try inverting the offset x/y/z
<whitequark> I'm wondering if I made a sign error
<reportingsjr> I just manually centered it
<reportingsjr> one moment
<reportingsjr> whitequark: no, that did not help
<whitequark> mmmkay
<reportingsjr> whitequark: so I rexported the html with the origin centered and it gave me the same offset numbers.
<whitequark> what
<whitequark> do you move the model at all after pressing F4?
<reportingsjr> Ah, small mistakes are annoying
<reportingsjr> whitequark: nvm, it zeroed it correctly
<whitequark> ok
<reportingsjr> I'm gonna keep playing around with this. If I find anything I actually think is an issue I'll let you know. :P
<reportingsjr> whitequark: I forgot that whenever you choose a new export file type (e.g. from js to html) the dialog changes the filename to untitled. I wonder if that is easily fixable.
<whitequark> wait, does it?
<whitequark> I just tried on Linux+GTK2 and it doesn't
<whitequark> which OS/GUI do you use?
<reportingsjr> Fedora 23, not sure about which GTK version is being used
<reportingsjr> whitequark: more specifically it does it when I open one of the export dialogs
<whitequark> where did you obtain solvespace?
<reportingsjr> whitequark: compiled it from github master ~1 week ago
<whitequark> ok, so unless you opted in gtk3, it will use gtk2
<whitequark> that's bizarre
<whitequark> do i understand this right, you are opening a dialog, modifying the filename, then changing the filter selection
<whitequark> and it resets the filename to untitled?
<whitequark> I fail to see how, in absence of a gtk bug, it could ever dig "untitled" from anywhere...
<reportingsjr> whitequark: no, sorry
<reportingsjr> whitequark: just open a dialog and it always defaults to untitled.someexthere
<reportingsjr> changing the export type in a dialog keeps the correct file name
<whitequark> reportingsjr: oh
<whitequark> yeah, that's because if you do 2d exports, you will usually want different filenames
<whitequark> and even with 3d it might be different positions etc
<cr1901_modern> whitequark: Is the viewer broken? Tbh, I don't remember being able to specify an offset for the viewer
<whitequark> you didn't implement that
<whitequark> I did
<cr1901_modern> Okay I see it now, fair enough
<cr1901_modern> reportingsjr: Just to make sure... the black section running down your model is just black color? It's not meant to be see-thru?
<reportingsjr> cr1901_modern: correct
<reportingsjr> cr1901_modern: It is a very shallow difference extrude colored black.
digshadow has quit [Ping timeout: 276 seconds]
<cr1901_modern> reportingsjr: Reason I asked is that in the past I've had problems with rendering surfaces inside surfaces. Has to do with THREE.js' default shader. But now that I think about it, that problem doesn't apply to you
talsit has left ##openfpga [##openfpga]