Topic for #milkymist is now Radical Tech Coalition :: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs
_whitelogger1 [_whitelogger1!~whitelogg@kaunan.whitequark.org] has joined #milkymist
_whitelogger1 [_whitelogger1!~whitelogg@kaunan.whitequark.org] has joined #milkymist
<GitHub8> [milkymist] sbourdeauducq pushed 5 new commits to master: https://github.com/milkymist/milkymist/compare/6f50e96...14a31d4
<GitHub8> [milkymist/master] milkymist: remove unused variables in libbase/softfloat.c - Werner Almesberger
<GitHub8> [milkymist/master] milkymist: use -Wstrict-prototypes - Werner Almesberger
<GitHub8> [milkymist/master] milkymist: try -Wmissing-prototypes - Werner Almesberger
<GitHub4> [flickernoise] sbourdeauducq pushed 1 new commit to master: http://git.io/ZdOP5w
<GitHub4> [flickernoise/master] parser_helper.c: use asprintf instead of DIY solution - Werner Almesberger
<wpwrak> is the MIDI test cable a regular MIDI cable or does it have some special features ?
<lekernel> wpwrak: why are you returning const char * in fpvm_parse? it's a dynamically allocated string ...
<lekernel> regular MIDI cable
<wpwrak> (const char *) because the recipient isn't supposed to change it.
<lekernel> mh... if you want... but then you have to cast it when passing to free()
<wpwrak> yes, i do that
<lekernel> C's "const" is broken anyway... use as you would use someone else's toothbrush
<lekernel> yeah, but it's more typing
<wpwrak> heh :) yes, "const" is a bit quirky. and i don't like it that "free" needs casts. but it helps in all the other places where such a string may be used.
<GitHub76> [flickernoise] sbourdeauducq pushed 1 new commit to master: http://git.io/tYEw_g
<GitHub76> [flickernoise/master] ptest: fix memory leak - Sebastien Bourdeauducq
<lekernel> another detail is it's a little confusing to name stuff in FN with a "fpvm_" prefix
<wpwrak> yes ... most of that can go anyway. just a question of cleaning up a little more
<wpwrak> i kept fpvm_ because some thing are from there, so i didn't have to change the callers. since then, i've eliminated most of the callers :)
<wpwrak> hmm. autotest is unhappy. hates my midi :-(
<wpwrak> there are a few other things, like the comments ending up in infra-fnp.h, the "_xy" variable, adding things like per_vertex to the name table. little details that slow things down.
<lekernel> wpwrak: maybe the autotest doesn't support mwalle's new UART core?
<lekernel> so you plan to remove parser_helper?
<wpwrak> but for now my goal is functionality. then the cleanup. there are a few more things that want cleaning up anyway, like the symbol lookups
<wpwrak> (parse_helper) haven't consider that yet. i think it has its uses.
<lekernel> well, all it contains is fpvm_parse and fpvm_parse_free you said you would remove
<wpwrak> (UART core) hmm, could be. there were a lot of interrupt changes as well, weren't there ?
<lekernel> yes
<wpwrak> ah, i was thinking of the things in fpvm.c
<wpwrak> fpvm_parse* only need a renaming :)
<wpwrak> (uart) maybe i'll leave this to you then :) you already know what to change.
<lekernel> yes, i'll have a look
<lekernel> you see I'm doing efforts to support Linux :) easier Linux support was the main motivation for the new UART
<wpwrak> hehe, great :)
<wpwrak> the usb test is funny. asks to press enter/left button on port A then on port B. but you can just do both on the same port ;-)
<wpwrak> of course, there's no way to tell anyway, at that level :)
mumptai [mumptai!~calle@brmn-4db716f8.pool.mediaWays.net] has joined #milkymist
<GitHub108> [autotest-m1] sbourdeauducq pushed 1 new commit to master: http://git.io/59j1xg
<GitHub108> [autotest-m1/master] Remove dependency on libmath - Sebastien Bourdeauducq
<GitHub15> [milkymist] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/milkymist/commit/14ad8baf3a5d3a2cc01698ff3439e5e2894f2f93
<GitHub15> [milkymist/master] Remove libmath - Sebastien Bourdeauducq
<wpwrak> hehe, die libmath, die ! ;-)
<wpwrak> so we just haev softfloat to produce lots of complains with -Wmissing-prototypes not
<wpwrak> s/not/now/
<lekernel> and the autotest
<wpwrak> yes, i've seen some function() there as well. haven't tried to crank up the warnings over there yet, though
<whitequark> lekernel: I have another question then
<whitequark> xilinx docs say that BRAM works on _both_ edges
<whitequark> then, can I first latch in an address in a manner described above
<whitequark> and then wait for 1/2 of clock cycle and disable CE?
<whitequark> output buffers should still be active, and I'll be able to make a second request in a very next clock cycle
<whitequark> like this:
<whitequark> CLK _|‾|_|‾|_|‾|_|‾|_|‾
<whitequark> CE _|‾‾‾|___|‾‾‾|___|‾
<whitequark> A ̅_X​‍̅_̅̅‍̅_̅_X​‍̅_​‍̅_̅_X​‍̅_​‍̅_̅_X​‍̅_​‍̅_​‍̅_X​‍̅_​‍
<whitequark> D ———<̅_̅1̅_X​‍̅_̅2̅_X​‍̅_̅3̅_X​‍̅_̅4̅_
<whitequark> REG —————<̅_̅1̅_X​‍̅_̅2̅_X​‍̅_̅3̅_X​‍̅_
<whitequark> oh
<whitequark> CE should have been = CLK.
<whitequark> and freenode ate my precious combining unicode.
<juliusb> i'm not sure if IRC is the best medium for waveform viewing
<whitequark> juliusb: well, I've been drawing these ones... for a while and didn't want to throw them out.
<whitequark> otoh, they are still meaningful.
<mwalle> lekernel: is autotest the production test suite?
<juliusb> :)
<whitequark> TI: "Your device is a product of superior design and craftsmanship and should be treated with care."
<whitequark> have they ever heard of modesty? :D
<whitequark> (after that, they suggest that I should "Do not attempt to open the device.
<whitequark> well, it's fine, except for the fact they are describing a PCB.
<whitequark> also, since when PCBs have "moving parts"?..
<wolfspraul> juliusb: why is irc not good for waveforms? I think those are awesome! whitequark - more plase :-)
<whitequark> wolfspraul: I'm thinking about releasing a library for drawing (awesome) unicode waveforms
<whitequark> a "library"
<wolfspraul> definitely
<wolfspraul> we need to get more beginners into this scene, and we know it's a worthwhile endeavor so we can build bridges wholeheartedly
<wolfspraul> it's not a fad that will go away in a year or two
<whitequark> what I see in Russia is a horrible, horrible lack of sensible engineers
<mumptai> and drawing waveforms will help?
<wolfspraul> discussing about them, definitely imho
<whitequark> especially young ones (< 50 yrs.), because old-schoolers, at least here, often prefer... suboptimal methods
<wolfspraul> and discussion may be eased with a drawing :-)
<whitequark> so it would be very good if it actually worked.
<kristianpaul> i agree with wolfspraul , the ascii waves are not bad
<wolfspraul> when I saw them I was first taken aback, but that's cool. new idea! waveform ascii art in irc - cool! :-)
<kristianpaul> of course the link to a vcd file download is not bad either :)
<wolfspraul> how useful we find out over time
* whitequark goes back to writing a pipelined brainfuck cpu core with branch prediction
elldekaa [elldekaa!~hyviquel@abo-168-129-68.bdx.modulonet.fr] has joined #milkymist
<wpwrak> roh: hmm, using http://projects.qi-hardware.com/index.php/p/m1/source/tree/master/cad/protocase_v7_laser.dxf, how can i tell what is engraving (text) and what is a cut through the board ?
<whitequark> looking at RTL makes me feel quite stupid.
<whitequark> can I assume that a trigger has an implicit delay inside, and if several ones are connected in a sequence, a clock pulse _first_ latches the state of output to the input of next one, and _then_ switches the output?
<lars_> more or less
<lars_> but it all happens at the same time. so not "first" and "then"
<whitequark> well, it happens at the same time for each of the individual flip-flops, yes
<whitequark> what I don't understand
<whitequark> if it happens _really_ at the same time
<whitequark> then you cannot build a working chain of flip-flops at all
<whitequark> they all will switch simultaneously
<lars_> there is propagation delay
<whitequark> that's what I have asked
<whitequark> without propagation delay, synchronous circuits cannot work, can they?
<lars_> probably not
<lars_> at least not the way we expect them to work
<whitequark> thanks, I understand the idea now
<whitequark> looking at RTL really helps to understand how the circuit you've just designed really works
<whitequark> or maybe I'm just fooled by C-look-alike-ness of verilog
<lars_> do you use a lot of blocking statements?
<whitequark> lars_: none of them
<kristianpaul> urghh
<whitequark> kristianpaul: hm?
<kristianpaul> non blocking way go, i agree with sebastien
<kristianpaul> also use as much you can always statements
<kristianpaul> life easier :)
<whitequark> yes, I've already notices that
<whitequark> *noticed
<lars_> i fully agree. i never use blocking statements
<whitequark> if I put everything in one always statement, XST tends to infer some monstrosity
<whitequark> and if I don't, then it's a nice clean set of primitives as they should be
<lars_> but imo non blocking is already quite close to rtl
<whitequark> blocking statements look quite foreign to FPGA's for me. they hide some internal state and tend to generate suboptimal code
<whitequark> lars_: maybe that's just how my brain works: if it sees C-like text, it thinks procedurally, and if a circuit, then in a proper way
<whitequark> just guessing
<whitequark> but the thing I'm doing now had not started to work until I stared for 30 minutes at RTL.
<whitequark> the logic was completely wrong
rejon [rejon!~rejon@216.106.26.9.reverse.socket.net] has joined #milkymist
<lekernel> whitequark: no, BRAMs do not work on both edges. what they probably mean is you can select between reacting to rising or falling edges.
<lekernel> but you can't do both
<lekernel> if you want to have 1 request per cycle, you can pipeline them
<lekernel> but keep everything synchronous... no half-cycles or things like that
<whitequark> lekernel: I'm pipelining everything
<whitequark> well
<lekernel> FPGAs aren't made for this, and it's a source of bugs and time wastage
<whitequark> and yes, everything I do is only done @(posedge clk)
<whitequark> but I've thought of a "clever trick" for RAM access
<whitequark> assign ram_ce = should_fetch && clk;
<whitequark> damn.
<whitequark> INTERNAL_ERROR:Xst:cmain.c:3464:1.56 -
<whitequark> (not related to the ram_ce)
<lekernel> oh, and yes, if you try asynchronous designs, this tickles synthesizer bugs as well :-)
<lekernel> clk should be connected *only* to clock ports
<whitequark> lekernel: ah okay, then it is possibly related.
<whitequark> hm
<whitequark> maybe there is a clock gate
<whitequark> primitive I mean
<lekernel> wtf?
<lekernel> I told you to do a synchronous design
<lekernel> forget about clock gating
<whitequark> ok
<lekernel> the FPGA architecture is optimized for synchronous designs, and the tools expect synchronous designs
<whitequark> hm
<whitequark> then I don't understand how one can get one request per cycle
<lekernel> by presenting a new address after each clock edge
<whitequark> ahh, so it does not need CE edges
<whitequark> yes indeed it does not. stupid
<lekernel> and yes, this means that the data pins have the values from the previous address. that's where pipeline hazards and other niceties come from :-P
<whitequark> yeah. I've read See MIPS Run several times
<lekernel> CE is a synchronous pin that tells it to read the new address when it's high
<whitequark> MIPS is a horribly bad processor design, but the book describes a lot of interesting things about processor internals
<lekernel> its purpose is to _disable_ the RAM read for some cycles
<whitequark> nah
<whitequark> still "INTERNAL+ERROR"
<whitequark> lekernel: can you take a look at my code? it just dies somewhere in the parser
<whitequark> with a double free.
<lekernel> mwalle: yes, autotest is the production test software
wolfspraul [wolfspraul!~wolfsprau@p5B0AF641.dip.t-dialin.net] has joined #milkymist
stekern [stekern!~stefan@nblzone-224-141.nblnetworks.fi] has joined #milkymist
<whitequark> okay. an undocumented xst option -use_new_parser yes fixes that.