<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
<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
<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
<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.