Topic for #milkymist is now Milkymist One, Milkymist SoC & Flickernoise development channel (LLHDL/Antares are welcome too) :: Logs: http://en.qi-hardware.com/mmlogs :: JFDI
sh4rm4 joined #milkymist
<kristianpaul>
unload? there is a reason for that.. a also what's the fpga state after that unload..
<wpwrak>
its just in the standby loop
<wpwrak>
and no, the unload doesn't do anything really useful. except of course entering standby. so you can boot with a button press instead of having to force a boot (or power cycle, then button press)
<wpwrak>
sigh. i don't think i can figure out what's going on here without changing the soc :-(
<wpwrak>
seems that CRC just takes too long. but i can't be sure if it's really that
<wpwrak>
*hmm* just found an interesting bug
<kristianpaul>
ah yes, pld reconfigure is the "unload", for a moment i was thinking in something else
aw_ joined #milkymist
aw joined #milkymist
aw_ joined #milkymist
<wpwrak>
aw_: so ... seems that we have an agreement for the USB switch:
<wpwrak>
1) sebastien is no longer concerned about "gliches", as long as we make sure usb power is off at reset time. the fpga resets with pull-ups enabled. so an active-low enable would do the trick.
<wpwrak>
2) no need for 0 R series resistors
<aw_>
1) understood. ;-)
<aw_>
for 2) can you tell me more clearly about 0 R series resistors?
<aw_>
i've placed orders last week for 5 active-low switches and else parts we knew.
<wpwrak>
perfect
<wpwrak>
2) means that we can connect them to the FPGA. no 0402 footprints needed.
<wpwrak>
i.e., "keeping it simple" :)
<aw_>
sorry, for 2) I reflashed my head, i understood it now. that one you'd pre-placed resistors for needs.
wolfspraul joined #milkymist
<aw_>
current rc3 the usb socket(J16/J20)'s pin1(VBUS) hole directly be connected with inside 5V, so I think I'll take usb sockets out firstly then so 'operation' on them. ;-)
<wpwrak>
yeah. not the easiest kind of rework :(
<wolfspraul>
wpwrak: let me ask about the leds for ports again
<wolfspraul>
which color?
<wpwrak>
a color you can clearly see through the case
<wpwrak>
i don't know what works well. i don't have the blue plastic :)
<wolfspraul>
solomonic answer
<wpwrak>
you should know what to expect ;-)
<roh>
well.. atleast the led color is easy to change. no board layout changes needed ;)
<wpwrak>
unless you have very very specific requirements for the led :)
<roh>
__very__ ;)
<wpwrak>
yes :)
<wolfspraul>
roh: which color do you think would be good?
<wolfspraul>
or even different colors?
<wolfspraul>
one for in, another one for out?
<wolfspraul>
some ports are both in and out :-)
<kristianpaul>
grmbl, 33m42.515s to synthesize..
<roh>
wolfspraul: where should the leds go and what should they signal? are talking about 2 leds, one for each usb port only? of do you want to add led to every socket?
<wolfspraul>
he
<wolfspraul>
I was trying to narrow this down but not very successful yet
<wolfspraul>
we can just spray paint 20 leds across the board...
<wolfspraul>
Werner's idea was 'a led for every port'
<wolfspraul>
does that include the power socket? infrared? memory card?
<roh>
well... not the worst idea ;) just difficult to place nicely on all sockets in a 'regular' pattern
<wolfspraul>
I think if we don't understand the purpose well it's hard to actually execute
<roh>
regular as in 'the same scheme for all port to led placing'
<wolfspraul>
the goal is to make m1 look more active/alive?
<roh>
another question is.. do we have enough free pins on the fpga or what are we talking about?
<wolfspraul>
don't know, but last time I checked I think the answer was "we have a lot"
<wolfspraul>
now that will go down a little in rc4, with dvi-i and the usb power switch
<roh>
ok. so we need to check if routing is easy and possible or if it will complicate things too much. and if we can drive the leds directly or need extra driver-transistors
<wolfspraul>
well
<wolfspraul>
first we need to understand the purpose of this exercise
<wolfspraul>
we can also position the leds to form a 'M' on the board :-)
<wolfspraul>
I'll wait a little and think about it more.
<wpwrak>
what to indicate: demand, activity, problems
<roh>
demand?
<wpwrak>
demand = patch wants to use feature X but nothing seems to be connected
<wolfspraul>
ahh
<wpwrak>
activity = an aperiodic flash every now and then
<wolfspraul>
good idea!
xiangfu joined #milkymist
<wpwrak>
problems = maybe periodically blink
<roh>
well.. light up if it makes sense to connect something, flicker on activity, and regular blinking for errors?
<wolfspraul>
then demand would be red
<wpwrak>
roh: see. it's intuitive ;-)
<wolfspraul>
red = something missing?
<roh>
forget colors. you can see lit up or not lit.
<wpwrak>
wolfspraul: you have a color filter in the the way. so red may not be red. or maybe it is :)
<wolfspraul>
roh: you mean because it goes through the light-blue acrylic?
<wpwrak>
e.g., with the purple case, green is yellow :)
<roh>
i'd plan for green leds now, simply because they are cheap, and really light compared to the current. just the same type we use for the 3 leds in rc2 and 3 already
rejon joined #milkymist
<roh>
wolfspraul: ack
<wpwrak>
green tend to be weak compared to other colors. but they probably go along well with the blue case, so in the end they may work better than bright red leds.
<roh>
ack.
<wpwrak>
(some modern red leds are about as nasty as blue leds. at a fraction of the power :)
<wolfspraul>
so what now? same leds as we have now?
<roh>
just dont use blue ones. looks cheap from my pov;)
<wpwrak>
blue also have inconvenient voltages
<roh>
wolfspraul: for now. remember.. we can always swap them easyily
<wolfspraul>
then the idea is to indicate demand/activity/problems..
<wolfspraul>
that means, one for:
<roh>
well.. for green, red, yellow that is ;)
<wolfspraul>
1. DMX (separate in and out?)
<wpwrak>
wolfspraul: you may want to get a few different colors and try what looks good
<wpwrak>
i would try to have one led per connector
<wpwrak>
rgb is three connectors :)
<wolfspraul>
2*dmx, 2*midi
<wolfspraul>
the video-in: 1 or 3?
<wpwrak>
people sticking wires into MIDI are perverts. they still get only one LED :)
<wpwrak>
3
<wpwrak>
led-on-sd is "nice to have". sd in general is almost unusable in m1, but an activity indicator can't hurt
<wolfspraul>
1 led for midi?
<wpwrak>
power ... why not. we already have one, but at a less intuitive place
<wpwrak>
1 led for each midi connector
<wolfspraul>
I don't think I want to touch those 3 leds that are there
<wolfspraul>
keep compatibility etc.
<wpwrak>
led for IR ? definitely. unless you have infra-vision ;-)
<wpwrak>
yeah, let them be. also the three stooges^H^H^H^H^H^H^Hbuttons :)
<wolfspraul>
2*dmx, 2*midi, 3*video-in, power, 2*usb, ir, dvi-i, ethernet
<wolfspraul>
3 buttons as well?
<wolfspraul>
that's 16 already
<wolfspraul>
Sebastien will get a heart attack
<wpwrak>
naw, no leds on the buttons, i think
<wpwrak>
that might get confusing :)
<wolfspraul>
13
<wolfspraul>
memcard 14
<wolfspraul>
are we sure those thingies are cheap?
<wpwrak>
he'll be happy to have an excuse for demanding a bigger fpga :)
<wolfspraul>
so let's try again
<wolfspraul>
2*dmx, 2*midi, 3*video-in, power, 2*usb, ir, dvi-i, ethernet, memcard
<wpwrak>
(cheap) depends on what specs you want :)
<wolfspraul>
all green, all the same one as what we have right now
<wpwrak>
what size are we looking for ? 0603 or 0402 ?
<wolfspraul>
I would pick the cheaper one unless there is an overriding factor
<wpwrak>
LTST-C190KRKT (nice bright red) costs you 5 cents if you buy a tape. others from the same family are similarly priced
<wpwrak>
(tape&reel)
<wolfspraul>
what we have now we bought for 9 cents
<roh>
wpwrak: well.. wait for the end of the current money crisis.. i would really wonder if the us can continue to run non-metric alone with burma forever
<wpwrak>
right now, eu is doing its best to keep people from paying too much attention to the us. i hope merkel & co. will get a medal of honor and for patriotic duty well beyond the call of duty. from obama ;-)
<wpwrak>
well, or palin. whoever the successor
<roh>
;)
<xiangfu>
are you talking about add metric led to milkymist?
<aw_>
if IO_L48N_1 connects a pull-up which is supposedly to be the same as R30(10K). But I still marked it as "TBD" and since an AND gate instead of diode which should not be haven current leakage acted like diode. so I marked C238 as 'DNP'.
<aw_>
if somewhere I was wrong, correct me. tks. ;-)
rejon joined #milkymist
aw_ joined #milkymist
aw joined #milkymist
rejon joined #milkymist
xiangfu joined #milkymist
Martoni joined #milkymist
r33p joined #milkymist
xiangfu joined #milkymist
mumptai joined #milkymist
mumptai joined #milkymist
azonenberg joined #milkymist
lekernel joined #milkymist
lekernel_ joined #milkymist
mumptai joined #milkymist
wolfspraul joined #milkymist
<wpwrak>
good morning :) let's see ..
<lekernel_>
morningf
<lekernel_>
-f
<lekernel_>
wolfspraul: what about white LEDs?
<lekernel_>
also for the existing ones
<wolfspraul>
sure why not
<lekernel_>
or try UV LEDs with the fluorescent acrylic ;)
<wpwrak>
aw_: what would you think of putting a silo cap on the "inside" of the switch ? like the current 220 uF ?
<wolfspraul>
lekernel_: you tell me
<lekernel_>
well... I was joking a bit. the fluorescent acrylic doesn't look nice anyway
<lekernel_>
but the white LEDs, why not
<lekernel_>
I think they should look nice with the light-blue case
<wpwrak>
lekernel_: white LEDS have inconvenient voltages. they hover around 3 V, with large variations, e.g., 2.8-3.4 V
<wpwrak>
lekernel_: they're also about 4x the price of green :)
<aw_>
wpwrak, please check the FLG's pull-ups resistors, i think they are connected to 3V3 not 5V. ;-)
<aw_>
wpwrak, mm...silo cap...
<wpwrak>
but .. i wonder if you won't get large brightness variations with such a small drop. if you design for 20 mA at 2.7 V (30 Ohm), you'd get only 5 mA at 3.15 V
<lekernel_>
we can use the 3.3V or better 5V supplies
<lekernel_>
yes, that would be the problem
<lekernel_>
can we get away with the 5V supply and just a protection diode to limit the voltage to 3.3V when the FPGA isn't driving its output low?
<wpwrak>
aw_: (FLG) yes, better to keep it in the 3.3 V domain. i wouldn't trust 5 V enough to bring it near the FPGA :)
<lekernel_>
i.e. make the LED control signals active low, cathode of the LED to FPGA, anode to 5V, and protection diode to prevent 5V from reaching the FPGA when it's not driving its IO
<lekernel_>
of course, if Murphy takes care of this circuit, the FPGA can get damaged ...
<wpwrak>
the protection would be tricky. zeners don't work at very low currents
<lekernel_>
nah, not zener
<lekernel_>
normal diode
<lekernel_>
and connected to the 2.5V or 3.3V supply, not ground
<wpwrak>
hmm. then you'd be close to the minimum diode drops for low currents. so you may have a non-zero current even if not driven
<lekernel_>
now the problem is the diode will still have 5V-2.5V/3.3V (minus protection diode forward voltage) when supposed to be off, and might still light a little
<wpwrak>
exactly :)
<lekernel_>
well... the proper way to do it is with external transistors. it's safer for the FPGA, too.
<wpwrak>
yes. and then my simple idea starts to get a little complex :)
<lekernel_>
hooking a small MOSFET is easy, no?
<lekernel_>
it's just one part more
<aw_>
lekernel_, the unexpected condition should be occurred is the reset duration from the ramp curve of 5V to 4.0V threshold. mmm...seems your idea is avoid of it.
<wpwrak>
N x 1 part more :)
<wpwrak>
lekernel_: would you put pull-ups on the USB power switch enable signals, to catch the FPGA's outputs going Z ?
<lekernel_>
they shouldn't go Z
<lekernel_>
you can add a "DNP" resistor that we can use if we have problems... or for debugging
<lekernel_>
it would also serve as test point
<lekernel_>
aw_: how much is a small NMOS with ~30mA drain-source current?
<wpwrak>
maybe populate them by default ? might deny us the joy of chasing problems, but .. :)
<wpwrak>
aw_: (reset) i think we want the WE# and CE0 pull-ups, even if they didn't affect my reset tests. that would be 4k7 each.
<wpwrak>
heh, if we want to keep R60, it should probably be pull-down ;-)
<aw_>
lekernel_, you mean like 2N7002 NMOS? it's about USD 0.018
<aw_>
even if it's not ~30mA but it's reference price i think. ;-)
<wpwrak>
9 cents if you buy 100 :)
<aw_>
wpwrak, R60 to pull down?
<wpwrak>
and that's SOT23-3. probably not what you want
<wpwrak>
SOT-323 starts at 15 cents at 100 units
<aw_>
wait...hehe..let's review all parts in reset circuit. ;-)
<aw_>
1. two pull-ups for FLASH WE#/CE0 to 4.7K
<wpwrak>
aw_: (r60) naw, you can keep it. it wouldn't do anything either way. maybe one day we want a open collector gate or whatever :)
<aw_>
2. I checked irc log, you thought R30 value needs to be determined while applying this AND gate. so it may not 10K.
<wpwrak>
hmm, i don't remember. what was the reason i gave ?
<aw_>
wpwrak, i see. I am collecting to put possible place holder in advance, if we think it needs pull down, then I may draw another resistor(pull down) marked TBD. ;-)
<aw_>
so next for usb-switch circuit: seems still needs more discussions? ;-) complex if using mosfet. :)
<wpwrak>
(reset) looking good !
<wpwrak>
(usb switch) i'd treat the LEDs as a separate issue
<wpwrak>
we also need to see about placement, etc.
<aw_>
what you're considering placement, is it related to luminance with different color acrylic color case?
<wpwrak>
naw, that's yet another issue :)
<wpwrak>
placement is mainly about making it clear which led is associated with which port
<aw_>
even if yes, I'd still hope that can we settle down (usb switch) now?
<aw_>
hmm..are meaning to include the idea of led matrix for all related connectors?
<wpwrak>
not a matrix :) just one line doing to each :)
<wpwrak>
s/doing/going/
<aw_>
wpwrak, hehe .:)
<wpwrak>
(usb switch) i'd add a silo cap and connect the pull-ups to 3V3. then i think it's fine. lemme check the connection to the FPGA ...
rejon joined #milkymist
<wpwrak>
FLG1 to pin 3 ? :)
<aw_>
ha..good catch. i blinded though. ;-O
<aw_>
is pin 5. I'll update them after discussions. ;-)
<wpwrak>
the rest looks good
<aw_>
wpwrak, could you describe more about your "aw_: what would you think of putting a silo cap on the "inside" of the switch ? like the current 220 uF ?"
<lekernel_>
wpwrak: the USB sample point change I proposed makes things worse (compared to my initial full-speed attempt). even that USB stick that passed the "set address" doesn't work at all anymore.
<aw_>
are you saying to add a capacitor at the 'input' of usb-switch. (i.e. pin2 add it beside that 1uF)?
<lekernel_>
trying with only your patches to compare ...
<lekernel_>
but it seems it receives 100% garbage now
<aw_>
wpwrak, are you saying that you want to add a 220uF beside(in front of) that 1uF for pin2 of usb-switch? sorry I tried to not misunderstand your idea. ;-)
<wpwrak>
lekernel_: 100% garbage with my patches and with or without the sample point change ?
<wpwrak>
aw_: yes, so that the 5V rail has some more buffering
<wpwrak>
aw_: but you can try without it and measure how things go
<aw_>
wpwrak, we can add it to this draft first, then we measure them to compare while design verification stage. ;-)
<lekernel_>
wpwrak: with the sample point change. I'm testing without the change now ...
<wpwrak>
lekernel_: in general, i'm seeing a lot of timing weirdness in USB when trying to add CRC checking. it may just be that CRC is too expensive. or maybe something else is going on. that may also affect operation without CRC.
<wpwrak>
lekernel_: i'll need more precise diagnostic signals. e.g., one that isn't modulated by rx/tx activity (like OE# is). and maybe even one that tells me when exactly EOP is indicated. because i'm having my doubts about the timing of that.
<wpwrak>
so i guess i;ll have to figure out how to synthesize that soc :-(
<wpwrak>
i read that some people at opencores think it's over-engineered
<lekernel_>
yes, I used this document to design the softusb core... it's even referenced in the source
<wpwrak>
ah, cool
<lekernel_>
and all the opencores usb stuff has, of course, more bugs than a typical rainforest
<wpwrak>
yes. when reading their comments on it, i thought "consider the source" ;-)
<lekernel_>
things like bitstuffing not working near a EOP... hopelessly corrupts those packets
<lekernel_>
I tried to use the opencores stuff in a first version of softusb, but it has been, as usual, a waste of my time
<stekern>
fullspeed usb seems to work with it though
<stekern>
;)
<lekernel_>
oh, it works with our design too. see! my USB stick responds to the "set device address" message.
<wpwrak>
:)
<wpwrak>
which version of ISE is recommended ?
<lekernel_>
13.3
<lekernel_>
wpwrak: no improvement without the sample point change ...
<wpwrak>
hmm. i guess i'll what it is when i have better instrumentation. right now there are a number of events where i can't really see when then happen or when they are handled.
<wpwrak>
s/i'll/i'll see/
<stekern>
hehe, "seems to work" included a bit more than that, but I'm just being facetious
<wpwrak>
e.g., i'm getting fun things like a flurry of RX timeouts if i add a delay after sending an ACK in the data phase of SETUP. that doesn't even begin to make sense :)
<wpwrak>
(that was in an attempt to move the CRC out of the receive loop)
errordeveloper joined #milkymist
<GitHub8>
[flickernoise] sbourdeauducq pushed 1 new commit to master: http://git.io/dG0hCw
<GitHub8>
[flickernoise/master] Use image loading library - Sebastien Bourdeauducq
mumptai joined #milkymist
<wpwrak>
3 GB, zzz .... i wonder, if they made DVDs smaller and networks slower, would people write more compact code ?
<GitHub158>
[flickernoise] sbourdeauducq pushed 1 new commit to master: http://git.io/88CA1w
<lekernel>
hopefully they do, but those are built by Xiangfu...
<mwalle>
lekernel: do you have one, which you are sure thats included? i'd like to test qemu-1.0rc2
<lekernel>
mh, I don't see any new patches in his script directory. so it's probably not included, and neither are wpwrak's fixes which aren't committed to RTEMS CVS yet
<lekernel>
sure
<lekernel>
mwalle: mailed
<mwalle>
looks much better
<mwalle>
although rendering isnt working
<lekernel>
let me check that I didn't break it ...
<lekernel>
I did
<lekernel>
moment ...
<lekernel>
new mail coming soon
<mwalle>
thx :)
<mwalle>
lekernel: ok line drawing is working, but are you able to return to the gui using esc or right mouse button?
<mwalle>
lekernel: and could it be that it is not possible to return to the GUI if there is no audio device?
<wpwrak>
the whole thing took 25 minutes. a bit slow, but okay. and the best thing: it boots ! ;-)
<mwalle>
wpwrak: only 25 minutes? :)
<wpwrak>
hmm. 218 warnings from Bitgen, 242 warnings frmo Par, 224 warnings from map, 7 warnings from NGDBUILD, 703 warnings from xst
wolfspraul joined #milkymist
<wpwrak>
hmpf. xst diagnostics include a "table of contents". i somehow also remember compilers on early mainframes being rather chatty about what they were doing. thinking of it, they were also very slow. maybe there's a connection. if you can't compile it quickly, make a big fuss about all the little things you did ;-)
<wpwrak>
lars_: seems that the loop problem didn't do anything to me
mumptai joined #milkymist
<lars_>
wpwrak: did you actually use the settings64.sh script?
<wpwrak>
yes. i think it sets up environment variables, no ?
<lars_>
yes
<lars_>
ok, so it's my shell that is broken
<wpwrak>
my shell is /bin/bash 4.1.5(1)-release
<wpwrak>
to make things more interesting, /bin/sh is dash (ubuntu's choice, not mine)
<kristianpaul>
lekernel: are you around?
Artyom joined #milkymist
<wpwrak>
hmm 12 minutes without most of the peripherals
<Artyom>
kristianpaul: I think that even if there is no signed div/mul operations they can be easily implemented in software.
<kristianpaul>
i wonder is it is implemented in milkysmt libc
<kristianpaul>
and yes there is hardware support for div/mul
<Artyom>
yes, I've seen it :)
<kristianpaul>
lekernel: you have a demo or posible math opertation that milkymist libc can do? or any know limitations?
mumptai joined #milkymist
<Artyom>
btw kristian you mentioned that not every terminal program works with bios. I've noticed it ;) Do you know why is it so?
<kristianpaul>
ah yes, long history
<kristianpaul>
i think there is a missing or extra carriage return
<kristianpaul>
so so far i know just flterm (located in the tools folder) and gtkterm handle it
<kristianpaul>
why exactly this, well lekernel seems very pick in what he code :')
<wpwrak>
(not that flterm would be such a horrible choice. though its use of ^C is a bit ... unusual :)
wolfspraul joined #milkymist
<wpwrak>
hmm, kicking out ether and memcard only saves 50 seconds. well, better than nothing
<wpwrak>
lekernel: all i care about for now is to get into the BIOS. there, i can already see enough of the drama unfold
<mwalle>
wpwrak: are you benchmarking all possible combinations? :b
<wpwrak>
naw, just removed the ones that looked exposed for killing. then tried the rest. sometimes, things that are a little hidden are such for a reason :)
wolfspraul joined #milkymist
wolfspraul joined #milkymist
r333p joined #milkymist
<mwalle>
wpwrak: is gdb and new uart really working reliable for you?
<mwalle>
never seen odd timeouts?
<wpwrak>
do we use EDK or PLANAHEAD, ?
<wpwrak>
mwalle: i didn't use it much. just fired it up to check the NULL pointer detection and to confirm to you that it works
<wpwrak>
let's see how things go with a reduced setup
<mwalle>
Sending packet: $m0,4#fd...[+]Ack
<mwalle>
doh!
<mwalle>
lekernel: can we put an enable signal to the bus error comparator? that gdbstub can disable it?
<wpwrak>
hmm, where are signals assigned to physical pins ?
<mwalle>
wpwrak: ucf file
<mwalle>
boards/milkymist-one/synthesis/system.ucf or sth like that
<wpwrak>
aah, boards/... thanks !
<wpwrak>
pretty hardcore - from symbolic name straight to ball position ;-)
Gurty joined #milkymist
<lekernel>
wpwrak: we are using neither EDK or planahead