Topic for #milkymist is now Radical Tech Coalition :: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs
<wpwrak>
only very roughly. as in overcurrent / not overcurrent
<wpwrak>
you'd have to add current sensors and an ADC if you really need to know with better granularity
<wolfspraul>
can or should we add circuitry to make this more precise?
<wpwrak>
seems an unusual feature
<wolfspraul>
yes. ok then, just came to my mind...
<wpwrak>
the playful control freak in me likes it, of course :)
<wolfspraul>
nah, I can live without
<wolfspraul>
I don't understand the exact use case right now, besides having some fancy current monitor displaying how much each USB socket consumes...
<wpwrak>
you could dim the USB leds accordingly ... ;-)
<wolfspraul>
indeed - the more power a usb socket draws, the brighter the light :-)
<wpwrak>
maybe make them flicker when the current if very high, to suggest power is at the point of failing ;-)
<wolfspraul>
but no, I don't need that still
<wolfspraul>
and I assume adding this would be quite a complication
<wpwrak>
you'd need a bunch of sensor chips with resistors, plus some sort of adc (or mcu) to gather the data
<wolfspraul>
I just ran into it because I have a bunch of USB devices and hubs on one machine, and I lost overview over who needs how much power
<wolfspraul>
do I need to power the hub? or not?
<wolfspraul>
how much does the wifi dongle need? the speaker? the remote keyboard?
<wolfspraul>
and so on
<wpwrak>
your multimeter is your friend :)
<wolfspraul>
sounds like we surely don't want that
<wolfspraul>
but I'm basically guessing around, moving usb from hub to host machine, here there
<wolfspraul>
guessing who might need how much...
<wolfspraul>
for example usb nand storage - probably rather little?
<wpwrak>
you could make a little passive pcb with usb a upstream, usb a downstream, interrupted VBUS, and two connectors to put a multimeter in the middle
<wpwrak>
then you could measure what exactly is going on
<wolfspraul>
ok then the guessing is easier :-)
<wolfspraul>
but surely such a small usb current measuring pcb sounds fun
<wolfspraul>
I could take a short extension cable and open some of the wires
<wpwrak>
yes, that works too. a bit finicky, though
<wpwrak>
while you're at it, you probably also want to bring out GND. that way, you can replace the PC with a lab power supply
<wpwrak>
or do things like supplying power from the lab power supply but still doing the signaling with the PC
<wolfspraul>
no no :-)
<wolfspraul>
I know when to stop
<wolfspraul>
I was *wondering* about power when I had a little trouble arranging a pile of USB devices
<wolfspraul>
but simple trial and error solved the problem already
<wolfspraul>
enlightenment doesn't always win
<wolfspraul>
btw, a small thing maybe for some, but I had to chew on this for a while
<wpwrak>
such a setup was rather useful for certain experiments with gta02 and hxd8 ;-)
<wolfspraul>
I feel very confident now talking about Milkymist as a "SoC" project, SoC being the category
<wolfspraul>
before I was oscillating between CPU and SoC helplessly
<wolfspraul>
CPU is the more generally known term, but it's misleading and the main point of Milkymist doesn't come across
<wolfspraul>
so it's like Linux is a kernel, Apache a web server, Milkymist a SoC - that kind of analogy
<wolfspraul>
of course sebastien was talking about "leading free SoC" all along, nothing new for him...
<wpwrak>
yes, soc is accurate. sounds a tad smallish. but i guess we can't have everything
<wolfspraul>
smallish?
<wpwrak>
well, most people would associate "SoC" with relatively small devices
<wpwrak>
smartphones, pads, this kind of thing. already a laptop has "CPU" and "peripherals"
<wpwrak>
of course, that's gradually changing, too
<wolfspraul>
no I think it's SoC everywhere now, even Intel is being talked about making "SoCs" now
<wolfspraul>
anyway I feel confident about this now, only SoC from me now
<wpwrak>
ok. so we're like the big guys then :)
<wolfspraul>
(and I just added Milkymist to the "List of SoC suppliers" in Wikipedia :-))
<wpwrak>
phew .. :)
<wolfspraul>
we're between Maxim and MIPS
<wpwrak>
btw, i think you missed this one in the backlog:
<wpwrak>
wolfspraul: the weird little corner of the jtag board does actually have a use: it helps you to align the board with the connectors. otherwise, you would have to "feel" for correct alignment. sort of fumblish.
<wolfspraul>
saw it
<wolfspraul>
good point :-)
<wpwrak>
(just noticed that when re-seating the jtag board i had plucked out to look at the memory card connector when you asked about ubb)
<GitHub88>
[flickernoise] wpwrak pushed 1 new commit to direct-midi: http://git.io/Mby8Gw
<GitHub88>
[flickernoise/direct-midi] MIDI documentation (still WIP, on-going) - Werner Almesberger
<wpwrak>
writing documentation helps to understand those use cases ;-)
lekernel has joined #milkymist
abushcrafterforg has joined #milkymist
cladamw has joined #milkymist
xiangfu has joined #milkymist
<kristianpaul>
xiangfu: hello
<kristianpaul>
(replying to yday Hi ;-))
<xiangfu>
kristianpaul, Hi. good morning
<kristianpaul>
hey :)
<xiangfu>
want let you know I finish a simple payload.py for your m1 using mining core
<cladamwa>
so with the same method, I'm thinking using same theory for audio line-in.
<cladamwa>
yeah...but it's okay. we can draw idea fristly then ask joerg for help then, how do you think? ;-)
<wpwrak>
(line in) there goes the nice ground :)
<wpwrak>
yup. leave it to him to tear those ideas apart :)
<cladamwa>
wpwrak, yes, although current there goes to ground, but I'll also let there to be reached liek 'low' sc level 'normally' (i.e. not plugg-in yet).
<cladamwa>
wpwrak, yes, so i'll edit audio sche page again then for help . ;-)
<kristianpaul>
xiangfu: n8, thanks for the script now i have a basis to debug my niner :)
<cladamwa>
wpwrak, btw, i did really apply yet joerg's idea on those DC blocking 2 pins header for un-used audio input path, how do you think this?
<xiangfu>
kristianpaul, n8
<wpwrak>
mmh, not sure which of the many audio changes you mean
Gurty has joined #milkymist
<cladamwa>
wpwrak, since i don't know if we need to use more route space for TP47~TP51( which were I added ), but original idea from you was to leave solder-pad only.
<wpwrak>
i'd just put the caps close to the chip and NC them. no antenna = no RF trouble, right ? :)
<cladamwa>
you wanted to keep those un-used footprint for DC blocking if one can use them for playing them. but joreg suggested put them in ground when no use.
<cladamwa>
yes, your idea thoughts not bad and reasonable, but from Joreg's suggestions that he wanted us to reduce audio input noise as possible, so he said that we may use 2 pins headers to short to ground those un-used caps.
<wpwrak>
i think that may be overkill
<wpwrak>
of the traces between chip and the NC caps are short, not much can crawl in anyway
<cladamwa>
from my simple idea is quite same like you and even just put footprint only and NO test points, and DNP them.
<wpwrak>
and i'd NC the caps :)
<wpwrak>
yup
<wpwrak>
NC == DNP :)
<cladamwa>
okay, so let's not add Test points and DNP them. done?
<wpwrak>
sounds great to me :)
<cladamwa>
okay, done. ;-) then I edit the plugg-in and detection idea and ask in list for joerg again. ;-)
<cladamwa>
btw, to have detection idea, can you see your rc2 sch now?
<wpwrak>
rc2 ?
<cladamwa>
yes
<cladamwa>
although we replaced R23/R24 (6.8K ohm) with varistor V27/V28 now,
<cladamwa>
correct?
<wpwrak>
M1rc2 ? where are the schematics of that ? and what is there about detection ? and where ?
<lekernel>
but I have a very precise idea of what needs to be done. now it's just coding and debugging ...
<lekernel>
phew, active low resets... I never got it
<Fallenou>
lekernel: are store words working correctly for you using migen & milkymist-ng ?
<Fallenou>
on sram
<lekernel>
it's something competely useless in a FPGA and, in ASICs, optimizing the reset polarity should be done by the tools, not the coder
<lekernel>
Fallenou: yes
<Fallenou>
ok
whitequark has joined #milkymist
mirko has joined #milkymist
ximian has joined #milkymist
<lekernel>
mirko: you're at in-berlin?
<mirko>
lekernel: kinda.. hosting stuff there..
antgreen has joined #milkymist
rejon has joined #milkymist
kilae has joined #milkymist
elldekaa has joined #milkymist
kilae_ has joined #milkymist
Thihi has joined #milkymist
kyak has joined #milkymist
kyak has joined #milkymist
juliusb has joined #milkymist
bkero has joined #milkymist
[florian] has joined #milkymist
togi has joined #milkymist
cxadams has joined #milkymist
aeris- has joined #milkymist
cjdavis has joined #milkymist
Scopeuk has joined #milkymist
wpwrak has joined #milkymist
jonand has joined #milkymist
kill_me2 has joined #milkymist
guyzmo has joined #milkymist
kristianpaul has joined #milkymist
fpgaminer has joined #milkymist
roh has joined #milkymist
stekern has joined #milkymist
Gurty has joined #milkymist
wolfspraul has joined #milkymist
VJTachyon has joined #milkymist
qi-bot has joined #milkymist
mwalle has joined #milkymist
proppy_ has joined #milkymist
whitequark has joined #milkymist
mirko has joined #milkymist
ximian has joined #milkymist
rejon has joined #milkymist
elldekaa has joined #milkymist
Thihi has joined #milkymist
kyak has joined #milkymist
larsc_ has joined #milkymist
radii has joined #milkymist
antgreen has joined #milkymist
kilae_ has joined #milkymist
sh4rm4 has joined #milkymist
lekernel has joined #milkymist
ChanServ has joined #milkymist
Fallenou has joined #milkymist
devn has joined #milkymist
djbclark has joined #milkymist
<Fallenou>
And I somehow end up with sram data_in being 32'bX in soc.v
<Fallenou>
exactly during the write (when sram0_wishbone_we_i == 1)
<Fallenou>
which is kind of a problem :p
qi-bot5 has joined #milkymist
proppy_ has joined #milkymist
Thihi_ has joined #milkymist
guyzmo has joined #milkymist
<GitHub76>
[flickernoise] wpwrak pushed 1 new commit to direct-midi: http://git.io/s9hqng
<GitHub76>
[flickernoise/direct-midi] More work on the MIDI documentation - Werner Almesberger
mumptai has joined #milkymist
elldekaa has joined #milkymist
<larsc_>
hm, what's the result of expressions like 'assign a = ~a' and more interestingly 'assign a = b | ~a'
<wpwrak>
local overheating ?
<larsc_>
my generic flow control logic model resolves to 'ack_o = ack_i & ~stb_o; stb_o = stb_i & ack_o;' for combinatorial actors
<larsc_>
this could either mean my model is still to generic, it is wrong, or there are some special rules on how to handle self contradicting logic
<larsc_>
and if you build the truth tables it show that for the cases where the logic is coherent it is equivalent to ack_o = ack_i;stb_o = stb_i
<wpwrak>
hmm :)
<wpwrak>
i'm actually a bit surprised that you can get away with assign a = f(b); assign b = f(a); i.e., a cyclic dependency
<larsc_>
i'd expect it to settle to a fixed point. if it has one
<lekernel>
yeah, combinatorial loops can be messy
<lekernel>
you can actually build sequential systems with them :)
<wpwrak>
did you check the logs for suspicious warnings ? like "confusing logic set to 0" or such ? i noticed that xst rather likes to do such things
<lekernel>
there's even a generic method to build any (asynchronous) FSMs using combinatorial logic only
<lekernel>
(which I forgot, because it's of little use in FPGAs)
<lekernel>
larsc_: I think you can resolve the problems without combinatorial loops... afaik all you need is a way to track partial acks when you have several outputs