lekernel changed the topic of #milkymist to: Mixxeo, Migen, Milkymist-ng & other Milkymist projects :: Logs: http://en.qi-hardware.com/mmlogs :: Mixxeo preorder lists.milkymist.org/pipermail/devel-milkymist.org/2013-May/003344.html
mumptai has joined #milkymist
lekernel has joined #milkymist
Alarm_ has joined #milkymist
lekernel has quit [Ping timeout: 256 seconds]
lekernel has joined #milkymist
<Fallenou> hi!
<Fallenou> lekernel: you were talking about the Mixxeo board, right? who picked the slow flash? and the ftdi chip? (and who did the "bad design" for this board ?)
Guest79831 has quit [Quit: Coyote finally caught me]
Hawk777 has joined #milkymist
<lekernel> no, it's another board for some physics experiment
<lekernel> of course mixxeo will use the same FTDI connections as the M1 - I'm not looking for trouble :)
<lekernel> the board was already designed this way when I got it
<Fallenou> oh ok
<Fallenou> does someone have a flickernoise binary (latest version with MIDI USB support) that I can flash on my M1?
<Fallenou> I think the web storage of releases is down
<Fallenou> bios and bitstream are easy for me to generate, flickernoise has tons of dependencies I would like to skip the big xiangfu script part :)
<lekernel> web storage isn't down... http://milkymist.org/updates/
<lekernel> it's independent from sharism/qi-hw
<Fallenou> oh, good!
<Fallenou> so current should contain usb midi stuff?
<lekernel> yeah... gateware in git also contains some usb fixes that are not in the binaries - if you need those
<Fallenou> ok I will generate the gateware myself and take the flickernoise from your link then
<Fallenou> thanks!
<lekernel> so rtems is even worse than ise? ;)
<GitHub3> [milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/EwprEA
<GitHub3> milkymist-ng/master d487dc6 Sebastien Bourdeauducq: software: add nofloat libbase for size-optimized binaries
<Fallenou> it's just that there is too much dependencies :p
<Fallenou> generating the bitstream is just "make bitstream" and you're done
<Fallenou> (ok it's long)
Alarm_ has quit [Ping timeout: 246 seconds]
<wpwrak> lekernel: how sure are you of the clock-to-data synchronization ? i was thinking that, if we have a fairly regular pattern, perhaps an array of 1024 counters, indexed by the received pattern, could be used to gather statistics
<wpwrak> e.g., the all black pattern would have two high counts (for the "mostly high" and the "mostly low" pattern), plus a number of small counts, most of which would be the errors.
<wpwrak> that in turn should allow determining how the errors differ from the expected pattern
<lekernel> hmm, that's an idea
<wpwrak> e.g., whether it's a shift of the whole pattern, whether one bit moved, etc.
<larsc> good idea
Alarm_ has joined #milkymist
<lekernel> a bit tricky to implement since you need BRAM and then do 1 read + 1 write at different addresses at every cycle
<lekernel> (different addresses because the read will take one cycle)
<wpwrak> how many counters could you have without using difficult structures ?
<wpwrak> let's say, 16 bit counters
<lekernel> so you're using the two ports to do that, and then you also need read capability in the system clock domain
<lekernel> alternatively, you could try reading using bitstream readback :)
<wpwrak> that's enough for about one second even when things are very very bad. 10 seconds or more if they're a bit more civilized
<lekernel> assuming bitstream readback is a real third "hidden" port and won't do weird things if you access the BRAM from the design at the same time
<wpwrak> with < 1024 counters, you'd just hash or mask. as long as the data is more or less the same, you still get the same results. but it's of course more involved.
<wpwrak> hmm, isn't "doing weird things" one of the mottoes of xilinx ? :)
<lekernel> why not do that with the TFTP solution by the way?
<wpwrak> you mean retrieval ?
<lekernel> use the existing design that can send raw data from one channel to the computer with TFTP then do the processing with software
<wpwrak> could simply be keystroke, like 0 and 1. it's not as if you'd need to do this continuously
<wpwrak> well, maybe you do. but we'd find out about that when seeing the first results. if it's all noise, maybe it needs deeper analysis.
<wpwrak> but already 1 second should contain hundreds of error patterns
<larsc> you could probably use two brams, use one to count the even words and one to count the odd ones and then just sum them up in sw
<lekernel> why do you want to do this in gateware?
<wpwrak> ah yes, that would make it single-cycle
<lekernel> what's wrong with sending the frames with TFTP?
<wpwrak> ah, i see. you'd record to DRAM.
<wpwrak> and then send the buffer. yes. that's an option.
<lekernel> it's not all noise btw - http://milkymist.org/dvi_working.png was recovered via raw TFTP data + processing in python
<wpwrak> pretty neat
<lekernel> of course, it looks suspiciously free of errors
<lekernel> that was without the 24 ohm resistors
<wpwrak> oh, wow
<wpwrak> that's suspicious indeed
<lekernel> with a single ASMI port with 3 slots, and run the SoC at 83MHz again
<lekernel> or maybe not that suspicious since I sometimes get WER = 0
<lekernel> over 600ms
<lekernel> and that's only less than 3 frames, less than 50ms
<wpwrak> (WER = 0 for a while) ah, interesting. so it's very bursty.
<lekernel> the WER counter resets every 2**24 words which is about 600ms with a 25MHz pixel clock
<Fallenou> what's the prefered way of installing python3.3 on Ubuntu (which already has python3.2)? compiling the python3.3 from sources?
<lekernel> and you actually get lots of zeros or values under 5, at least with the resistors
<wpwrak> i suppose the capture could also be extended to capture more data. maybe 64 MB. that should be ...58 frames (assuming each pixel occupies 30 bits)
<lekernel> it's only one channel
<wpwrak> ah yes, silly me
<lekernel> each pixel is 10 bits + 6 bits of padding to align them to byte boundaries
<wpwrak> 116 frames then. more than a second :)
<lekernel> you should try running the current dvidebug stuff first
<lekernel> I have changed things in the core and haven't tested it for a while
<wpwrak> sound good. but first, breakfast with a lot of coffee :)
azonenberg has quit [Read error: Operation timed out]
mumptai has quit [Quit: Verlassend]
<Fallenou> lekernel: when you write (lambda a: a[27:29] == 3, self.wishbone2csr.wishbone) < it means bits [29:27] (in verilog syntax) of transaction address are 3'b011 ??
<Fallenou> which would mean then ... 0x1800 0000 ??
<Fallenou> wpwrak: what's the range() operator doing when applied to a fader in FPN again?
<Fallenou> I mean, what's the difference between fader1 and range(fader1)
<wpwrak> fader1 = fader(...) gets you the fader device
<wpwrak> var = range(fader1) defines how the device's values are interpreted
<Fallenou> ok, I've done so far things like fader1 = fader(1, 0)
<wpwrak> see also: cd flickernoise/src/compiler/doc && make && make again && xpdf midi.pdf
<Fallenou> oh ok :)
<wpwrak> (i had to look it up myself - been a long time ;-)
<Fallenou> hehe
<Fallenou> arg flash and ram have shared address bus on the Nexys3 board
<wpwrak> basically foo = fader(...) or such maps control elements to functions. and bar = range(...) binds those functions to variables
<Fallenou> that will lead to poor mibuild device file :/
<wpwrak> does mibuild/migen even support bus sharing ? :)
<Fallenou> I will implement it inside the "submodule"
<Fallenou> I will call the block "Memory" and then do the differenciation ram/flash inside the Memory submodule
<Fallenou> so all flash/ram pads will be "Memory" pads
<larsc> wpwrak: well internally it is all connected to the same bus anyway
<Fallenou> wpwrak: does the below(var, value) still work?
<Fallenou> parser says there is an error over there: http://www.milkymist.org/updates/current/patches/Rozzor%20&%20Aderrasi%20-%20Canon%20%28DMX%20out%29.fnp
<Fallenou> 5 lines from the bottom of the file
<Fallenou> per_frame=warp = warp + if (below(kick,0), 0.5*treb, 0);
<wpwrak> the below ought to work, yes
<Fallenou> hum ok
<Fallenou> I don't get how to send commands to the Micron np8p128a13t1760e flash
<Fallenou> there are addr[] data[] buses, we, ce, oe etc but I don't see any "control" bus
<Fallenou> and the datasheet gives a list of "commands"
<Fallenou> how the hell do I send any command?
<wpwrak> Fallenou: all regression tests pass, so below() works :)
<wpwrak> the regression tests also check the patches
<GitHub196> [flickernoise] wpwrak pushed 1 new commit to master: http://git.io/xX7I_w
<GitHub196> flickernoise/master 3c4e04f Werner Almesberger: test/fold: fix "nothign" typos
<wpwrak> now it's perfect :)
<Fallenou> :p
<Fallenou> ok thanks
<lekernel> Fallenou, upper bound is exclusive so it's bits 27 and 28
<lekernel> and the address (a signal) is in 32 bit words
<lekernel> so the first address to match becomes 0x60000000 in bytes
<lekernel> wpwrak, all bus sharing needs a special core, no matter which language they are written in. then you'd have that special "bus shared" interface in the mibuild description.
<wpwrak> that's roughly how i imagined it. sharing rarely comes for free :)
<Fallenou> ok so it's bits 29 and 30 for CPU access (byte access)
* Fallenou is having troubles with PLL_ADV stuff for Nexys3 since clk is 100 MHz instead of 50 MHz on that board
<lekernel> Fallenou, you should make a combined flash/psram core
<Fallenou> something is wrong in the dynamic calculous
<Fallenou> lekernel: yes that's what I thought
<lekernel> I suppose the controls are similar
mumptai has joined #milkymist
<lekernel> then you just assert the proper chip enable depending on one address bit
<Fallenou> yes
<Fallenou> http://pastebin.com/fawiuwyC ISE complaining
* Fallenou checks in m1crg.v
<lekernel> interesting that you need to login for the flash errata but not the datasheet
<Fallenou> yes =)
<Fallenou> they want to hide their errors
<lekernel> it's not even technically flash
<Fallenou> in the datasheet they don't say when the address is latched for a READ they only say it for a write
<lekernel> it could be asynchronous access?
<lekernel> like NOR?
<Fallenou> hum maybe
<lekernel> To perform a READ operation, RST# and WE# must be de-asserted while CE# and OE#
<lekernel> are asserted. CE# is the device select control. When asserted, it enables the Flash
<lekernel> memory data is driven onto the I/O bus.
<lekernel> memory device. OE# is the data output control. When asserted, the addressed Flash
<lekernel> that's all
<lekernel> just be wary of the 135ns address-to-data delay
<larsc> Fallenou: what's the output frequency?
<Fallenou> I think I need to change in m1crg.v the 4*f_mult and 4*f_div by 2*f_mult and 2*f_div
<Fallenou> yes it works, bitstream is now generated :)
<Fallenou> somehow the PLL_ADV seems to multiply the input clock internally and then divide it for the output
<lekernel> you can try to boot the board with just the flash to start with
<Fallenou> it was too much multiplied at the entry I guess so that the internal oscillator of the PLL could not survive such a frequency
<lekernel> see if you get any serial output and BIOS prompt
<lekernel> then add the PSRAM
<lekernel> all you need is read only flash which is trivial... just take the existing norflash core
<Fallenou> yes read only flash
<Fallenou> 18:10 < lekernel> just be wary of the 135ns address-to-data delay < IIUC I need to wait for OE# (what's the # for? negation ?) and that's all, right?
<Fallenou> before latching the data_out
<lekernel> "Leon Chua, who is considered to be the father of non-linear circuit theory, has argued that all 2-terminal non-volatile memory devices including phase change memory should be considered memristors."
<lekernel> ah, those self-serving wikipedia edits ... :-)
<Fallenou> =)
<lekernel> if you're just reading, hold OE# constant
<lekernel> # is negation yes
<Fallenou> I don't understand the norFlash python file at all :o
<lekernel> and just wait for a couple cycles after the address is changed
<Fallenou> the timeline stuff and the rd_timing
<lekernel> it's simple - address and data of wb are sent to the flash, all the time
<Fallenou> of 12 is the rd_timing it seems
<Fallenou> -of+oh
<lekernel> when a wb request arrives, you need to wait rd_timing cycles for the "wb address -> flash address pins -> flash read delay -> flash data pins -> wb data" process to complete
<lekernel> so you ack the wb request with delay
<lekernel> I think you can probably take the norflash core as-is, maybe adjust rd_timing and a couple details, and it would work
<Fallenou> os timeline() is a tool to be able to act upon a start event (strobe+cyc) and then do stuff after x sys_clk cycles and then y sys_clk cycles etc ?
<Fallenou> -os+so
<lekernel> I like how Micron always says "Easy BGA" instead of "BGA"
<lekernel> almost sounds orwellian
<Fallenou> lol
<Fallenou> Fast Spartan6 (Fastan 6 ?)
<Fallenou> win 18
<lekernel> wow, Chua's paper is so full of academic BS. I'm glad I don't have a PhD.
<lekernel> "the periodic table of circuit elements" lol
<Fallenou> oh, original norflash was already 16 bits access
<Fallenou> nice
<Fallenou> lekernel: in m1's mibuild "python style" ucf file, the pads for flash addr and flash data, are they from MSB to LSB or the other way round ?
<lekernel> first one is lsb
<Fallenou> arg :(
<Fallenou> I've put MSB first, damn it
<Fallenou> have to rewrite all the pads :)
<Fallenou> or change the order of the Cat( ) in norFlash/__init__.py maybe ...
<lekernel> better do it cleanly and invert that list
<lekernel> and heh
<lekernel> it's python :)
<lekernel> l = [those pads you have written]
<lekernel> print(list(reversed(l))) and you're done
<lekernel> with just a bit of copy paste
<Fallenou> yes I just did that with a python cmdline :)
<Fallenou> hum I think I forgot to clock the flash
<Fallenou> it seems the flash clk is directly hooked to one of the FPGA IO
<lekernel> there is no clock
lekernel has left #milkymist ["Leaving"]
lekernel has joined #milkymist
<lekernel> except for spi which you don't use
<Fallenou> ok
<lekernel> would be cool to parameterize lm32 with verilog parameters instead of that messy and non-reentrant include
<GitHub44> [milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/IbCjOQ
<GitHub44> milkymist-ng/master 3eb41f7 Sebastien Bourdeauducq: Simplify system ID
<Fallenou> antgreen: how do you write your code to Nexys3 Flash? You have some kind of "FPGA<->Flash" bridge? (like fjmem.bit)
<Fallenou> or do you still use an embedded ROM?
<antgreen> Fallenou: I don't yet. The only external memory I'm using is the pseudo-static RAM device
<antgreen> (16M).
<antgreen> Yes, also embedded memory
<antgreen> ROM & RAM
<antgreen> I have my initial bootloader in embedded memory
<Fallenou> oh, ok
<antgreen> it downloads srec programs into psram and executes from there
<Fallenou> do you know if there is any easy way to write something to Flash?
<Fallenou> any tool? something?
<antgreen> only on windows :-(
<Fallenou> oh
<Fallenou> The Flash chip does not even seem to be on the JTAG chain :o
<antgreen> if I had a flash controller, then I could create one easily
<antgreen> that would be a good next project
<antgreen> I'm leaving on a 4 day trip business tomorrow, and always get lots done then
<antgreen> maybe I'll try it.
<lekernel> Fallenou, you can put the BIOS in BRAM
<lekernel> fits in less than 16K if you trim it down
<antgreen> yes, that's where my bootloader lives
<antgreen> and it runs in BRAM RAM as well
<antgreen> hehe - that stack exchange question was asked by a moxie user
<antgreen> does the lm32 have a bus watchdog, or something that looks for unmapped memory accesses?
<lekernel> there is an exception vector for when the wb error signal is asserted
<Fallenou> 19:54 < lekernel> Fallenou, you can put the BIOS in BRAM < yes, I think I will do that for now to validate the rest of the soc
<Fallenou> but then I will really need to put a program in flash :)
<lekernel> no, you sfl-boot or net-boot directly to PSRAM
<lekernel> and completely ignore the flash
<Fallenou> oh, why not yes
<Fallenou> having the bios download application to RAM
<Fallenou> and put the bios in ROM
<GitHub198> [mibuild] sbourdeauducq pushed 1 new commit to master: http://git.io/0pEemQ
<GitHub198> mibuild/master e272e68 Sebastien Bourdeauducq: platforms/papilio_pro: swap tx/rx to be consistent with M1
<antgreen> what is sfl-boot?
<antgreen> oh, serial line
bhamilton has joined #milkymist
jevin has joined #milkymist
bhamilton has quit [Ping timeout: 256 seconds]
<GitHub0> [migen] sbourdeauducq pushed 2 new commits to master: http://git.io/woQIkQ
<GitHub0> migen/master 5208baa Sebastien Bourdeauducq: bus/wishbone/SRAM: support init and read_only
<GitHub0> migen/master 7ada015 Sebastien Bourdeauducq: bus/csr/SRAM: support init
<wpwrak> hmm .. is the infrastructure for the dvidumper even around anymore ? the dma controls have changed completely and as far as i can tell, dvisampler now stores pixels, not raw patterns
<wpwrak> "self.submodules.dma = spi.DMAWriteController(" hmm .. SPI ? wow
azonenberg has joined #milkymist
<lekernel> simple processor interface
<lekernel> and yes
<lekernel> the infrastructure is still there; dvisampler stores pixels and that's why there's a separate "debug" core that stores raw
<lekernel> ftdi_eeprom won't even compile... yes, libftdi "is easy to use" and "works perfectly" - I see ...
<wpwrak> ah ! that's where it went. thanks !
<wpwrak> there are lies, damn lies, and then there's marketing :)
<lekernel> cmake even produces a blank makefile, lol
Alarm_ has quit [Ping timeout: 246 seconds]
<wpwrak> crapmake ? :)
Alarm_ has joined #milkymist
<lekernel> ./ftdi_eeprom --read-eeprom conf.conf
<lekernel> Warning: Not writing eeprom, you must supply a valid filename
<lekernel> ahem
<lekernel> did a Xilinx engineer write this?
<larsc> well better than if it actually did write the eeprom
bhamilton has joined #milkymist
bhamilton has quit [Quit: Leaving.]
<lekernel> ?! the poor shit has a read eeprom mode, but then you can't rewrite the backup file you just made?
<lekernel> oh my ...
<lekernel> eeprom_set_value(ftdi, VENDOR_ID, cfg_getint(cfg, "vendor_id"));
<lekernel> ...
<lekernel> eeprom_set_value(ftdi, CHANNEL_A_DRIVER, DRIVER_VCP);
<lekernel> eeprom_set_value(ftdi, CHANNEL_B_DRIVER, DRIVER_VCP);
<lekernel> eeprom_set_value(ftdi, CHANNEL_D_DRIVER, DRIVER_VCP);
<lekernel> eeprom_set_value(ftdi, CHANNEL_C_DRIVER, DRIVER_VCP);
<lekernel> ahem ....
<lekernel> great error reporting, too http://pastebin.com/KbQwh3Lz
<wpwrak> don't worry, there's a lot more badness where that came from :)
Alarm__ has joined #milkymist
Alarm_ has quit [Ping timeout: 246 seconds]
<lekernel> ftdi stuff is like raspberry pi, two devices with a large open source-ish community and no one to get things right
bhamilton has joined #milkymist
bhamilton has quit [Client Quit]
<wpwrak> in many "communities" there's sub-"community" of "makers" and one of "followers". sometimes, there's hardly a difference between them. in other cases, there's a rather sharp divide.
<lekernel> finally found the right options, but for some reason the it would only write the first 128 bytes of the 256 from my backup ....
<wpwrak> gee, so many surprises :)
<wpwrak> don't worry, the writes that go slightly wrong will only change undocumented bits that completely alter the function of the device
<wpwrak> this is kinda fun :) in an iain banks, the wasp factory kind of way. well, from the perspective of the one watching the wasp struggle towards the inevitable, of course.
<lekernel> indeed, when you erase the eeprom and then attempt to flash it from a backup file, it reads a word from the eeprom that was just erased to determine its size
<lekernel> very clever :)
<wpwrak> don't worry, that's just a minor detour. you'll get back to the real road to hell quickly enough.
bhamilton has joined #milkymist
bhamilton has left #milkymist [#milkymist]
bhamilton has joined #milkymist
bhamilton has left #milkymist [#milkymist]
<lekernel> ah, you are right
<lekernel> though it was just ftdi_set_eeprom_buf() ignoring its size parameters. finally got my original backup written correctly.
<lekernel> the amount of bugs in ftdi chips and libftdi is quite impressive
<davidc__> use the windows tool - I hate to say it but, libftdi / the ftdi_eeprom tool is completely fucking broken
lekernel has quit [Quit: Leaving]
mumptai has quit [Ping timeout: 252 seconds]
mumptai has joined #milkymist