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
<wpwrak> so not super-cheap as resistors, but not really "expensive" either
<wolfspraul> 14*9=1.31 USD
<wpwrak> ah, super bright green
<wolfspraul> 0603
<wolfspraul> maybe we can use the opportunity to cost-down a little :-)
<wpwrak> hmm. marginally
<wpwrak> seems to be a close relative to the one you have
<wolfspraul> are they switching to metric slowly?
<wolfspraul> 1608?
<wpwrak> 7.15 cents @ 100 at digi-key
<wpwrak> apparently
<wolfspraul> that'll be a lot of work for many years, throughout the toolchain and machines etc.
<wpwrak> the japanese seem to like metric
<wpwrak> us not so much
<wpwrak> kingbright sound chinese
<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?
<wolfspraul> roh and wpwrak - THANKS!
<wolfspraul> I think it's concise enough now to translate to actions...
<wolfspraul> the "14 new leds proposal"
<wpwrak> xiangfu: just a lot of LEDs, metric or not ;-)
<wolfspraul> xiangfu: 'metric' is just the measurement unit of the smd package
<wolfspraul> whereas until now often the base unit is 1/1000th inch (25.4 mm)
<xiangfu> wolfspraul, oh. thanks. I though it is like 16x16 led square lights.
<xiangfu> on top of milkymist. :)
<wpwrak> heh, not yet :)
<wpwrak> makes me remember the mystery led matrix of gta03 ;-)
<xiangfu> oh. it's 'matrix' not 'metric'. sorry.
<kristianpaul> routing 16 LEDs.. in the botton? :-)
<wpwrak> we can add jumper wires ;-)
<xiangfu> wolfspraul, there are already two led light inside the ethernet port.
<xiangfu> ok. I saw this 'Werner proposed adding LEDs to the ports to indicate'
<aw_> wpwrak, i just draw manually a usb switch sch, let's check if i understood them exactly: http://en.qi-hardware.com/wiki/File:M1rc4_usbswitch_design_verification_draft_sch_v1.JPG
<kristianpaul> wpwrak: if you think in wires, could consider the already routed/populated exp header
<aw_> wpwrak, i temporarily used J21 expansion header to implement.
<aw_> two leds are independently so that's not hard-wired power status logic, cf. ben charging led ;-) so from fpga (s/w side)
<aw_> wow..sorry that I didn't see the new proposals in RC3 Know issues, one line to mention leds for each connectors. phew~
antgreen joined #milkymist
xiangfu joined #milkymist
aw_ joined #milkymist
aw joined #milkymist
<aw_> wpwrak, hmm..seems that two pull-ups for FLGs must be connected to 3V3 not 5V. I was wrong i think. ;-)
<aw_> see if I interpreted it correctly. ;-)
<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 :)
<wolfspraul> oh
<wolfspraul> :-)
<lekernel_> 3.4V? that much?
<lekernel_> wow
<wpwrak> white and blue are greedy
<wpwrak> the 3.4 V was the cheapest i could find at digi-key: http://search.digikey.com/us/en/products/597-3901-830F/350-2340-1-ND/2444772
<wpwrak> this one is a little nicer, 2.7-3.15 V at 5 mA: http://search.digikey.com/us/en/products/LTW-C194TS5/160-1839-1-ND/2356240
<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_> wpwrak, so I also marked C238 to be DNP. ;-)
<wpwrak> ah, R30 was about the reset chip. let's see ...
<wpwrak> C238: good ! :) no voodoo caps ! ;-)
<aw_> i guessed your m1 is still came with a real C238 and new APX803-44SAG
<aw_> so yes, we knew when we use AND gate, we want to verify C238 and R30 value. of course the C238 now is DNP for surely. ;-)
<lekernel_> so? mosfets and white LEDs on 5V?
<aw_> so my next question is : the IO_L48_1's pull up I marked TBD firstly. ;-)
<wpwrak> yes, i still have that critter there. but i also don't have the AND gate :)
rejon joined #milkymist
<aw_> yes, we still keep C238 there, just DNP.
<wpwrak> R30 = 10 kOhm sounds good
<GitHub111> [milkymist] sbourdeauducq pushed 2 new commits to master: http://git.io/r7Lu7g
<GitHub111> [milkymist/master] flterm: make kernel image optional - Michael Walle
<GitHub111> [milkymist/master] flterm: bump version number and fix print_usage output - Sebastien Bourdeauducq
<aw_> how about that pull-up for IO_L48N_1? the same?
<GitHub149> [milkymist] sbourdeauducq pushed 1 new commit to master: http://git.io/o1nfNQ
<GitHub149> [milkymist/master] bios: fix initrd end pointer - Michael Walle
<wpwrak> lekernel_: seems to get a bit complex ...
<wpwrak> aw_: IO_L48N_1 doesn't really need anything anymore. it had the pull-up because it was used as a wired-AND. so either remove or DNP.
<aw_> wpwrak, okay...let's mark it as DNP for now. ;-)
<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.
wolfspraul joined #milkymist
<wpwrak> aw_: excellent !
<aw_> tks all inputs here. dinner time. ;-)
<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> oh, and have you seen this critter ? http://www.usb.org/developers/whitepapers/siewp.pdf
<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
<GitHub158> [flickernoise/master] Reorganize files - Sebastien Bourdeauducq
<wpwrak> still compiles. phew :)
<wpwrak> my LV3 has reached argentina. let's see how long it takes for it to crawl through the system.
<kristianpaul> wpwrak: what are you planning with ISE, implement your own logic analizer? tap some USB wires?
<kristianpaul> i guess TAP and let your scope/logic analizer make its work :-)
<wpwrak> tap some internal USB signals for now. making my own LA would be tempting, but probably a bit more work :)
<GitHub31> [scripts] sbourdeauducq pushed 1 new commit to master: http://git.io/OrIy1g
<GitHub31> [scripts/master] Update libjpeg to v8c - Sebastien Bourdeauducq
<lekernel_> there's xilinx chipscope, but I never got it to work
<wpwrak> record to FPGA RAM ? that may be what all those PC LAs use :)
<kristianpaul> lekernel_: but this chipscope how well works over jtag? had you seen it work?
<lekernel_> yes, but it sends everything through JTAG... which is a good idea if it worked correctly
<lekernel_> I also doubt the compatibility with our cable
<kristianpaul> indeed
<wpwrak> sounds slow. i'd stream to DRAM and then to the PC via ether
<wpwrak> maybe make ether a little faster in the process ;)
<lekernel_> of course... but then you need an existing DRAM infrastructure at least
<kristianpaul> etehr over tftp i think there is a lib in milkymist software for that
<lekernel_> JTAG is 30MBps with our cable (6MBps with the xilinx one)
<kristianpaul> oh, wow
<kristianpaul> si
<wpwrak> that's user data ? or bit clock ?
<lekernel_> bit clock
<lekernel_> but you can define arbitrarily large scan chains in the FPGA, so user data is transferred with little overhead
<wpwrak> how bad is the protocol overhead in the transmission mode they use ?
<wpwrak> ah, that sounds good then
<lekernel_> I don't know how chipscope does it... proprietary java software I won't touch without a 10-meter pole :)
<wpwrak> ;-))
gbraad joined #milkymist
<stekern> I did this quick hack to avoid using chipscope: http://git.chokladfabriken.org/?p=trace_logger.git;a=blob;f=rtl/verilog/tracer.v;h=1c80abb727e4d0f9624de81014e455aa55d75f78;hb=3586cce68814fd4d9ec3af0466b532a0dcbd7168
gbraad joined #milkymist
gbraad joined #milkymist
<lekernel_> wpwrak: btw, I'm able to run the USB part at up to 77MHz
<lekernel_> we can use 72MHz if needed
<lekernel_> that's 6 cycles per USB bit time
<wpwrak> kewl ;) but lemme see first what goes on at 48 MHz. let's now change too many parameters at once :)
<GitHub90> [flickernoise] sbourdeauducq pushed 3 new commits to master: http://git.io/5V8_EA
<GitHub90> [flickernoise/master] Update gitignore - Sebastien Bourdeauducq
<GitHub90> [flickernoise/master] File dialog: filter several extensions - Sebastien Bourdeauducq
<GitHub90> [flickernoise/master] System settings: allow JPG files as wallpapers - Sebastien Bourdeauducq
<wpwrak> sweet. a tar file containing xz-packed zips. no ARC ? no cpio ? no rar ? not even binhex ? now i'm disappointed :)
<lars_> xilinx ise?
<wpwrak> aye
<wpwrak> well, tjere
<wpwrak> 's other stuff in there too
<wpwrak> so i have to install the WebPACK. not the default choice, "ISE Design Suite: System Edition" ?
<wpwrak> "acquire or manage a license key" is set by default. do i need this ?
<lars_> just installed 13.3 today too and had one problem with their settings64.sh
<lars_> wpwrak: yes
<lars_> you can get a webpack license by email
<lars_> i think
<wpwrak> okay. let's see what happens ...
<wpwrak> i should probably sprinkle a bit of underberg on my disk, do help it digest all that bloat
<wpwrak> lars_: have you been able to solve the settings64.sh problem ?
<wpwrak> where do i apply for the license ?
<wpwrak> let's see if there is anything in the licensing solution center ...
<wpwrak> that is, if it ever loads ...
<GitHub24> [flickernoise] sbourdeauducq pushed 1 new commit to master: http://git.io/5uXyhQ
<GitHub24> [flickernoise/master] pixbuf: basic support for JPEG - Sebastien Bourdeauducq
<wpwrak> thanks. just went through the process. it showed me no licenses with konqueror, but i seem to have made it with firefox. let's see ...
<wpwrak> now .. build_bitstream ? :)
<wpwrak> let's see what happens .. "Building FPGA bitstream..."
<wpwrak> xst running. do any of these tools need additional encouragement to use multiple cores ? (like make's -j option)
<wpwrak> ngbuild ...
<wpwrak> map .. running out of nowhere. od.
<wpwrak> ah, common.mak
<lekernel_> wpwrak: if you want to cut synthesis times in USB debugging cycles, look at boards/milkymist-one/rtl/setup.v
<lekernel_> note that removing some stuff will sometimes prevent flickernoise from working at all, while the demo firmware fails more gracefully
<lars_> wpwrak: (settings64.sh issue) yes
<lars_> though i'm not sure whether it's a bug in my shell or their script
<lars_> there is a for loop which reads like 'for i in $var ...'
<lars_> and $var contains a list of directorys separated by space
<lars_> but the loop only runs once and $i contains the whole $var
<lars_> my fix was to replace $var with `echo $var`
<lars_> wpwrak: multi-core support? whats that?
<GitHub104> [flickernoise] sbourdeauducq pushed 1 new commit to master: http://git.io/xa4nZQ
<GitHub104> [flickernoise/master] JPEG loader: error handling - Sebastien Bourdeauducq
zer0her0 joined #milkymist
<mwalle> hi
<mwalle> lekernel: any comments on my bigger patch series?
<lekernel> haven't thoroughly looked at it yet... but I committed your small ones, thanks!
<mwalle> lekernel: the new flickernoise snapshots includes the driver for the new uart, right?
<lekernel> those on milkymist.org don't
<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?
<lekernel> yes
azonenberg joined #milkymist
mumptai joined #milkymist
<mwalle> lekernel: http://git.rtems.org/rtems/tree/c/src/lib/libbsp/lm32/shared/milkymist_ac97/ac97.c in read_cr() are you waiting for crrequest irq first?
<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 :')
r33p joined #milkymist
<wpwrak> kristianpaul: http://projects.qi-hardware.com/index.php/p/wernermisc/source/tree/master/neocon/ holds the answer to all your desires :) (option -c)
<kristianpaul> ONLCR ;-)
<kristianpaul> nice
<kristianpaul> !!
<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
<lekernel> just the basic tools in command line
<lekernel> mwalle: yes we can, but why?
lekernel_ joined #milkymist
cjdavis joined #milkymist
<wpwrak> lekernel: good. here's a sanitized version of the settings script: http://projects.qi-hardware.com/index.php/p/wernermisc/source/tree/master/m1/tools/xse-sane-init64
<wpwrak> (i wonder if xse is a valid acronym in xlinxverse. i think i saw it somewhere. well, x* is xilinx :)
<mwalle> lekernel_: have a look at the cover letter mail, gdbstub has to disable the bus erros in case it reads from the first 512kb
<mwalle> gn8