<wpwrak>
hmm, i could have described that bug in fewer words ...
<wpwrak>
lemme rewrite that ...
<wolfspraul>
wpwrak: do you want the LV3 shipped to you with or without an invoice?
<wpwrak>
ah, better to do everything strictly by the book
<wpwrak>
the argentine administration is currently running mad. today, they technically shut down all imports.
<wpwrak>
but they lifted that later on
<wpwrak>
("until further notice")
<wolfspraul>
"by the book" sounds great, but what does it mean?
<wolfspraul>
you get the unit for free
<wolfspraul>
as a gift
<wpwrak>
so the fewer excuses customs get for creating trouble, the better
<wolfspraul>
that's reality, "by the book"
<wpwrak>
ah, attach some small price. USD 100 or such.
<wolfspraul>
ok
<wolfspraul>
so much for "by the book" :-)
<wpwrak>
it's from china, right ? ;-)
<wolfspraul>
yeah
<wolfspraul>
by the Chinese book
<wpwrak>
everything is cheap in china :)
<wolfspraul>
(actually it's from Germany, and I think most of his supply chain is in Germany too)
<wpwrak>
including faderfox clones ;-))
<wpwrak>
will he send it directly ? or via you ?
<wolfspraul>
well I very much hope directly
<wolfspraul>
let's see
<wolfspraul>
I'm so slow again
<wolfspraul>
will reply in the next hour or so, cc you as before
<wpwrak>
(cc) great
<wpwrak>
(slow) flu still on ?
<wolfspraul>
no no
<wolfspraul>
just too many things, spread too thin
<wpwrak>
actually, thinking of it, perhaps declaring it as an evaluation sample without value may work better
<wpwrak>
that might trigger the "no samples" prohibition at customs, but that should only result in them putting their own value (i hope)
<wpwrak>
you/he could still specify a pro forma price, just in case
<wolfspraul>
hmmm
<wpwrak>
because, if it comes with a real invoice, that could run into the new tax agency's madness. and then i would have to prove the payment
<wolfspraul>
actually I just realize we have a shipment of another m1 rc3 scheduled, after the final rc4 design verification, which depends on selection of the final reset ic :-)
<wpwrak>
ah yes. and maybe a ben for miriam, too :)
<wpwrak>
i actually thoght you had planned to get the LV3 to  HK/CN first, so that you could have a look at it as well :)
<wolfspraul>
well sure
<wolfspraul>
I need more
<wolfspraul>
but which?
<wolfspraul>
typically when we try to stack too many things together, it's all stuck
<wolfspraul>
we are already moving there now
<wpwrak>
yeah, that's true
<wolfspraul>
miriam waits for a shipping opportunity
<wolfspraul>
rc4 reset ic not selected yet
<wolfspraul>
thus adam cannot order
<wolfspraul>
thus adam cannot prepare the rc3+fixes for you
<wolfspraul>
now the controllers
<wolfspraul>
:-)
<wolfspraul>
gordian knot
<wpwrak>
not quite ... yet ;-)
<wpwrak>
gimme 3 min to finish my dinner
<wolfspraul>
I will ask faderfox to ship two lv3 out asap
<wolfspraul>
so that's moving
<wolfspraul>
the one to Berlin should be there in a few days
<wolfspraul>
the one to you later
<wolfspraul>
in fact I need to get an m1 to him
<wolfspraul>
take your time, enjoy
<wpwrak>
okay. dinner finished :)
<wpwrak>
regarding reset, i think with ~4.0 V chip, it ought to be safe, although imperfect
<wpwrak>
for perfection, all power rails going to FPGA core and NOR would have to be monitored
<wpwrak>
right now, i have that ~4.4 V chip, and it doesn't act up in steady operation. don't know how it likes me connecting peripherals and such, though
<wolfspraul>
cannot follow
<wolfspraul>
perfection, imperfection ?
<wolfspraul>
which chip is good, which one should we settle on?
<wpwrak>
the "run reset chip from 5 V rail" solution has the imperfection that it's an unregulated input
<wpwrak>
so that could - in theory - vary widely without affecting the rest of the system
<wolfspraul>
yes
<wolfspraul>
but your tests show no problems, afaik
<wpwrak>
in practice, the amount of badness there is limited. so i think it may be safe, particularly if we use a 4.0 V reset chip (instead of the 4.4 V chip i have)
<wpwrak>
(my tests) correct. but so far they're not very demanding either
<wolfspraul>
is the 4.0 chip sufficiently better than the 4.4v chip to justify the additional spending of time and risks to try that one?
<wpwrak>
there are two types of "my tests": 1) the NOR corruption ones. they consisted in senselessly hammering the system. these results do look very good. i still need to do a bigger run, but i don't expect surprises.
<wpwrak>
2) unintended consequences. such as resets caused by transients. i haven't explored into that much yet.
<wpwrak>
i'd feel safer with 4.0 V :-) 4.4 V could respond to very short transients that shouldn't go as deep as 4.0 V
<wpwrak>
particularly if the power supply is already well < 5.0 V
<wolfspraul>
hmm
<wolfspraul>
that safety costs time and money
<wolfspraul>
ok then, so which one? can we pick one?
<wpwrak>
same model. 4.0 V version
<wolfspraul>
aw_: you there?
<wpwrak>
if we want to get more fancy, it would be the chip suggested on the list. with three inputs and a few extra components. nothing crazy, but more complex.
<wpwrak>
it would have the advantage of operating behind our regulators. i.e., it would monitor the real voltages that go to the FPGA et al., not the common input
<wpwrak>
so the 4.0 V chip would provide a worst-case interpretation of the power situation
<wpwrak>
each time it errs, there would be an unnecessary system reset
<wolfspraul>
the simplest solution that we believe works should do
<wpwrak>
but i don't quite know yet how often such an error would occur. maybe never :)
<wolfspraul>
we cannot always err on the side of 'safety' otherwise we cannot build hardware
<wpwrak>
then i'd go for 4.0 V, single input
<aw_>
wolfspraul, hi
<wpwrak>
we already know that 4.4 V, single input works in at least one case. so that's a good start ;-)
<wolfspraul>
aw_: it sounds like we want to switch the reset ic to the 4.0v variant of the same chip
<wolfspraul>
but this time let's just buy 5 or so of them
<wpwrak>
i don't think they're very expensive :)
<aw_>
so will wpwrak and you want to confirm this 4.0V chip on my site firstly after buy 5pcs?
<wolfspraul>
aw_: the plan is like this: you buy some of the 4.0v variant reset ic, then you rework your own rc3 + another rc3 with all proposed rc4 reset changes
<wolfspraul>
then we ship that rc3+fixes board to Werner for double-checking
<wolfspraul>
let's also do the gate fix on those 2 boards
<wolfspraul>
so the entire circuit should be like on rc4
<wpwrak>
i think 4.0 V is a safe change from my 4.4 V. so i don't think i need to try this first myself. i can always do torture testing later.
<wolfspraul>
what I want is that Adam does a full rework on 2 boards, his own and one we send to you
<wolfspraul>
'full' meaning with the final circuit as proposed for rc4, including reset ic and gate
<wolfspraul>
we have fiddled around this so long, I'm worried there are misunderstandings as to what the final one should be now
<wolfspraul>
wpwrak: can you make a quick partial drawing of the final rc4 reset circuit?
<aw_>
so which one will be sent to me from someone?
<wolfspraul>
yeah
<wolfspraul>
:-)
<wolfspraul>
there we start
<wolfspraul>
aw_: here is the process
<wolfspraul>
#1
<wolfspraul>
you source 5 or so of the new 4.0v reset ic
<wolfspraul>
#2
<wolfspraul>
you understand the complete rc4 reset circuit, with gate, reset ic, whatever
<wolfspraul>
#3
<wolfspraul>
you rework _two_ boards with that proposed rc4 circuit, one your own board, and another one to be sent to Werner after you reworked it
<wolfspraul>
#4
<wolfspraul>
you ship that rc3+reset fixes board to Werner
<wolfspraul>
:-)
<wolfspraul>
that's all
<wolfspraul>
if we are able to execute this, everybody should have the same reset circuit in mind, and we double-check it sufficiently in terms of rework and testing
<wpwrak>
(and please include the usual case elements. minus the button parts - i now mill them myself ;-)
<wolfspraul>
first I'm worried that the rc4 circuit is clearly understood
<wolfspraul>
I highly doubt that is the case right now
<wpwrak>
(partial drawing) yeah. need to remember the latest net after the reset chip, too. that'll be something for tomorrow. dinner with wine doesn't go well with design :)
<wolfspraul>
oh sure, no rush
<wpwrak>
yes, we have two sides - the reset chip itself, and what happens with its output
<wolfspraul>
ok then
<wolfspraul>
aw_: can you source those 4.0v reset ics?
<wolfspraul>
just 5 or so
<wpwrak>
the output is "solved" now, but in an ugly way. and the "official" design (schematics) is even worse
<wolfspraul>
wpwrak: yes they are 'cheap' but I should keep a checklist how often someone tells me this or that special case (=loss) is 'cheap'
<wolfspraul>
only 100 USD here
<wolfspraul>
only 50 USD there
<wolfspraul>
only 500 USD here
<wolfspraul>
and so on
<wpwrak>
naw, the chip are trivial. the shipping isn't :)
<wolfspraul>
in hardware, all that is irretrievably lost
<wolfspraul>
one fundamental difference between hardware experiments and software experiments
<wpwrak>
au contraire. in hardware, you still have the chips ;-)))
<kristianpaul>
lekernel: nice way how do you modified M1 bios in the TDC core :)
<wpwrak>
lekernel: sorry, i forgot - do you prefer an AND gate for RP# or an open-collector driver with IO_L48N_1 mixes in with a pull-up ? i think it was AND, but I'm not 100% sure
<wpwrak>
AND would be 74AUP1G08whatever
<kristianpaul>
lekernel: btw anything you had learn from that SPEC board, you wished to adapt in M1 One?
<lekernel>
this seems strange that so many things are set to 8...
<lekernel>
is that just an oversight?
<wpwrak>
dunno. maybe because doubles are 8 bytes ?
<lekernel>
with soft-fp, it doesn't matter, does it?
<lekernel>
the MIPS BSP aligns structure to cache lines... not sure if it matters
<wpwrak>
could there be hard-fp ? or is lm32 always soft-fp ?
<lekernel>
alwys soft fp
<wpwrak>
cache lines are a performance optimization :)
<lekernel>
yeah, but does it matter to align structures on cache lines?
<wpwrak>
it often helps, given that you often have "busy" elements at the beginning of the structure. that way, you may need only one line instead of two.
<wpwrak>
but this won't affect code correctness, just efficiency
<lekernel>
so, should we use the correct MM SoC cache line length instead?
<lekernel>
(32 bytes for L2)
<lekernel>
we need efficiency :)
<lekernel>
inefficiency = low FPS = bugs :)
<lekernel>
i'll give it a go, worst cast it'll use a tad more RAM, which doesn't matter at all
<wpwrak>
depends a bit on how large the structs are and if the elements are properly ordered. this is a whole branch of science ...
<lekernel>
case
<wpwrak>
yeah. can't hurt
<wpwrak>
to get a clearer picture, you would need to make performance measurements.
<lekernel>
yeah sure
<wpwrak>
and maybe even run the thing under something like cachegrind. that would tell you what exactly is going on.
<lekernel>
well, let's pick our battles :)
<wpwrak>
you could replace audio input with a PRNG and then whole process should be 100% reproducible and free from time dependencies. that would help a lot with evaluation. it's always nice if you don't need to run things a thousand times just to get those numbers to converge :)
<lekernel>
audio DMA's into the L2 cache, and the CPU invalidates L1 after DMA... so this won't be 100% accurate if you want to go nitpicking
<lekernel>
may still provide a decent model, though
<wpwrak>
ah, interesting. dma into cache. nice :)
<lekernel>
yeah, it's simple to implement
<lekernel>
if we DMA to DRAM, it takes more resources (bus is wider and burst only)
<lekernel>
and we have to take care of L2 coherency, which either increases complexity and resource usage even more, or invalidate L2, which may be slower than DMAing into L2 in the end
<lekernel>
only large bandwidth consumers like TMU and VGA use DRAM DMA
<lekernel>
and L2 is invalidated
<lekernel>
(though VGA uses simple coherency so framebuffer writes appear immediately on the screen... otherwise software becomes a mess)