| Fallenou | hi! | 09:57 |
|---|---|---|
| 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 ?) | 09:59 |
| lekernel | no, it's another board for some physics experiment | 10:13 |
| lekernel | of course mixxeo will use the same FTDI connections as the M1 - I'm not looking for trouble :) | 10:14 |
| lekernel | the board was already designed this way when I got it | 10:14 |
| Fallenou | oh ok | 10:25 |
| Fallenou | does someone have a flickernoise binary (latest version with MIDI USB support) that I can flash on my M1? | 10:26 |
| Fallenou | I think the web storage of releases is down | 10:26 |
| 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 :) | 10:28 |
| lekernel | web storage isn't down... http://milkymist.org/updates/ | 10:36 |
| lekernel | it's independent from sharism/qi-hw | 10:36 |
| Fallenou | oh, good! | 10:37 |
| Fallenou | so current should contain usb midi stuff? | 10:38 |
| lekernel | yeah... gateware in git also contains some usb fixes that are not in the binaries - if you need those | 10:40 |
| Fallenou | ok I will generate the gateware myself and take the flickernoise from your link then | 10:41 |
| Fallenou | thanks! | 10:41 |
| lekernel | so rtems is even worse than ise? ;) | 10:41 |
| GitHub3 | [milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/EwprEA | 10:43 |
| GitHub3 | milkymist-ng/master d487dc6 Sebastien Bourdeauducq: software: add nofloat libbase for size-optimized binaries | 10:43 |
| Fallenou | it's just that there is too much dependencies :p | 10:44 |
| Fallenou | generating the bitstream is just "make bitstream" and you're done | 10:44 |
| Fallenou | (ok it's long) | 10:45 |
| 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 | 12:11 |
| 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. | 12:12 |
| wpwrak | that in turn should allow determining how the errors differ from the expected pattern | 12:13 |
| lekernel | hmm, that's an idea | 12:13 |
| wpwrak | e.g., whether it's a shift of the whole pattern, whether one bit moved, etc. | 12:13 |
| larsc | good idea | 12:14 |
| lekernel | a bit tricky to implement since you need BRAM and then do 1 read + 1 write at different addresses at every cycle | 12:14 |
| lekernel | (different addresses because the read will take one cycle) | 12:14 |
| wpwrak | how many counters could you have without using difficult structures ? | 12:15 |
| wpwrak | let's say, 16 bit counters | 12:15 |
| lekernel | so you're using the two ports to do that, and then you also need read capability in the system clock domain | 12:15 |
| lekernel | alternatively, you could try reading using bitstream readback :) | 12:15 |
| 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 | 12:16 |
| 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 | 12:17 |
| 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. | 12:17 |
| wpwrak | hmm, isn't "doing weird things" one of the mottoes of xilinx ? :) | 12:17 |
| lekernel | why not do that with the TFTP solution by the way? | 12:18 |
| wpwrak | you mean retrieval ? | 12:19 |
| lekernel | use the existing design that can send raw data from one channel to the computer with TFTP then do the processing with software | 12:19 |
| wpwrak | could simply be keystroke, like 0 and 1. it's not as if you'd need to do this continuously | 12:20 |
| 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. | 12:20 |
| wpwrak | but already 1 second should contain hundreds of error patterns | 12:21 |
| 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 | 12:22 |
| lekernel | why do you want to do this in gateware? | 12:22 |
| wpwrak | ah yes, that would make it single-cycle | 12:22 |
| lekernel | what's wrong with sending the frames with TFTP? | 12:22 |
| wpwrak | ah, i see. you'd record to DRAM. | 12:23 |
| wpwrak | and then send the buffer. yes. that's an option. | 12:23 |
| lekernel | it's not all noise btw - http://milkymist.org/dvi_working.png was recovered via raw TFTP data + processing in python | 12:23 |
| wpwrak | pretty neat | 12:23 |
| lekernel | of course, it looks suspiciously free of errors | 12:23 |
| lekernel | that was without the 24 ohm resistors | 12:24 |
| wpwrak | oh, wow | 12:24 |
| wpwrak | that's suspicious indeed | 12:24 |
| lekernel | https://github.com/sbourdeauducq/dvidebug | 12:24 |
| lekernel | use with this core https://github.com/milkymist/milkymist-ng/blob/master/milkymist/dvisampler/debug.py | 12:25 |
| lekernel | with a single ASMI port with 3 slots, and run the SoC at 83MHz again | 12:25 |
| lekernel | or maybe not that suspicious since I sometimes get WER = 0 | 12:26 |
| lekernel | over 600ms | 12:26 |
| lekernel | and that's only less than 3 frames, less than 50ms | 12:27 |
| wpwrak | (WER = 0 for a while) ah, interesting. so it's very bursty. | 12:27 |
| lekernel | the WER counter resets every 2**24 words which is about 600ms with a 25MHz pixel clock | 12:28 |
| Fallenou | what's the prefered way of installing python3.3 on Ubuntu (which already has python3.2)? compiling the python3.3 from sources? | 12:28 |
| lekernel | and you actually get lots of zeros or values under 5, at least with the resistors | 12:28 |
| 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) | 12:29 |
| lekernel | it's only one channel | 12:30 |
| wpwrak | ah yes, silly me | 12:30 |
| lekernel | each pixel is 10 bits + 6 bits of padding to align them to byte boundaries | 12:30 |
| wpwrak | 116 frames then. more than a second :) | 12:30 |
| lekernel | you should try running the current dvidebug stuff first | 12:31 |
| lekernel | I have changed things in the core and haven't tested it for a while | 12:31 |
| wpwrak | sound good. but first, breakfast with a lot of coffee :) | 12:38 |
| 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 ?? | 13:27 |
| Fallenou | which would mean then ... 0x1800 0000 ?? | 13:28 |
| Fallenou | wpwrak: what's the range() operator doing when applied to a fader in FPN again? | 13:30 |
| Fallenou | I mean, what's the difference between fader1 and range(fader1) | 13:31 |
| wpwrak | fader1 = fader(...) gets you the fader device | 14:05 |
| wpwrak | var = range(fader1) defines how the device's values are interpreted | 14:06 |
| Fallenou | ok, I've done so far things like fader1 = fader(1, 0) | 14:06 |
| wpwrak | see also: cd flickernoise/src/compiler/doc && make && make again && xpdf midi.pdf | 14:06 |
| Fallenou | oh ok :) | 14:07 |
| wpwrak | (i had to look it up myself - been a long time ;-) | 14:07 |
| Fallenou | hehe | 14:07 |
| Fallenou | arg flash and ram have shared address bus on the Nexys3 board | 14:08 |
| wpwrak | basically foo = fader(...) or such maps control elements to functions. and bar = range(...) binds those functions to variables | 14:08 |
| Fallenou | that will lead to poor mibuild device file :/ | 14:08 |
| wpwrak | does mibuild/migen even support bus sharing ? :) | 14:08 |
| Fallenou | I will implement it inside the "submodule" | 14:09 |
| Fallenou | I will call the block "Memory" and then do the differenciation ram/flash inside the Memory submodule | 14:09 |
| Fallenou | so all flash/ram pads will be "Memory" pads | 14:09 |
| larsc | wpwrak: well internally it is all connected to the same bus anyway | 14:22 |
| Fallenou | wpwrak: does the below(var, value) still work? | 15:17 |
| 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 | 15:17 |
| Fallenou | 5 lines from the bottom of the file | 15:17 |
| Fallenou | per_frame=warp = warp + if (below(kick,0), 0.5*treb, 0); | 15:17 |
| wpwrak | the below ought to work, yes | 15:30 |
| Fallenou | hum ok | 15:31 |
| Fallenou | I don't get how to send commands to the Micron np8p128a13t1760e flash | 15:31 |
| Fallenou | there are addr[] data[] buses, we, ce, oe etc but I don't see any "control" bus | 15:32 |
| Fallenou | and the datasheet gives a list of "commands" | 15:32 |
| Fallenou | how the hell do I send any command? | 15:32 |
| wpwrak | Fallenou: all regression tests pass, so below() works :) | 15:37 |
| wpwrak | the regression tests also check the patches | 15:37 |
| GitHub196 | [flickernoise] wpwrak pushed 1 new commit to master: http://git.io/xX7I_w | 15:40 |
| GitHub196 | flickernoise/master 3c4e04f Werner Almesberger: test/fold: fix "nothign" typos | 15:40 |
| wpwrak | now it's perfect :) | 15:41 |
| Fallenou | :p | 15:41 |
| Fallenou | ok thanks | 15:41 |
| lekernel | Fallenou, upper bound is exclusive so it's bits 27 and 28 | 16:00 |
| lekernel | and the address (a signal) is in 32 bit words | 16:00 |
| lekernel | so the first address to match becomes 0x60000000 in bytes | 16:00 |
| 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. | 16:02 |
| wpwrak | that's roughly how i imagined it. sharing rarely comes for free :) | 16:03 |
| Fallenou | ok so it's bits 29 and 30 for CPU access (byte access) | 16:03 |
| Action: Fallenou is having troubles with PLL_ADV stuff for Nexys3 since clk is 100 MHz instead of 50 MHz on that board | 16:04 | |
| lekernel | Fallenou, you should make a combined flash/psram core | 16:04 |
| Fallenou | something is wrong in the dynamic calculous | 16:04 |
| Fallenou | lekernel: yes that's what I thought | 16:04 |
| lekernel | I suppose the controls are similar | 16:04 |
| lekernel | then you just assert the proper chip enable depending on one address bit | 16:05 |
| Fallenou | yes | 16:05 |
| Fallenou | http://pastebin.com/fawiuwyC ISE complaining | 16:06 |
| Action: Fallenou checks in m1crg.v | 16:07 | |
| lekernel | interesting that you need to login for the flash errata but not the datasheet | 16:07 |
| Fallenou | yes =) | 16:08 |
| Fallenou | they want to hide their errors | 16:08 |
| lekernel | it's not even technically flash | 16:08 |
| lekernel | http://en.wikipedia.org/wiki/Phase-change_memory | 16:08 |
| Fallenou | in the datasheet they don't say when the address is latched for a READ they only say it for a write | 16:09 |
| lekernel | it could be asynchronous access? | 16:09 |
| lekernel | like NOR? | 16:09 |
| Fallenou | hum maybe | 16:09 |
| lekernel | To perform a READ operation, RST# and WE# must be de-asserted while CE# and OE# | 16:10 |
| lekernel | are asserted. CE# is the device select control. When asserted, it enables the Flash | 16:10 |
| lekernel | memory device. OE# is the data output control. When asserted, the addressed Flash | 16:10 |
| lekernel | memory data is driven onto the I/O bus. | 16:10 |
| lekernel | that's all | 16:10 |
| lekernel | just be wary of the 135ns address-to-data delay | 16:10 |
| larsc | Fallenou: what's the output frequency? | 16:10 |
| 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 | 16:11 |
| Fallenou | yes it works, bitstream is now generated :) | 16:11 |
| Fallenou | somehow the PLL_ADV seems to multiply the input clock internally and then divide it for the output | 16:12 |
| lekernel | you can try to boot the board with just the flash to start with | 16:12 |
| 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 | 16:12 |
| lekernel | see if you get any serial output and BIOS prompt | 16:12 |
| lekernel | then add the PSRAM | 16:12 |
| lekernel | all you need is read only flash which is trivial... just take the existing norflash core | 16:12 |
| Fallenou | yes read only flash | 16:13 |
| 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? | 16:14 |
| Fallenou | before latching the data_out | 16:14 |
| 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." | 16:14 |
| lekernel | ah, those self-serving wikipedia edits ... :-) | 16:15 |
| Fallenou | =) | 16:15 |
| lekernel | if you're just reading, hold OE# constant | 16:16 |
| lekernel | # is negation yes | 16:16 |
| Fallenou | I don't understand the norFlash python file at all :o | 16:16 |
| lekernel | and just wait for a couple cycles after the address is changed | 16:16 |
| Fallenou | the timeline stuff and the rd_timing | 16:16 |
| lekernel | it's simple - address and data of wb are sent to the flash, all the time | 16:17 |
| Fallenou | of 12 is the rd_timing it seems | 16:17 |
| Fallenou | -of+oh | 16:18 |
| 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 | 16:18 |
| lekernel | so you ack the wb request with delay | 16:18 |
| lekernel | I think you can probably take the norflash core as-is, maybe adjust rd_timing and a couple details, and it would work | 16:19 |
| 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 ? | 16:20 |
| Fallenou | -os+so | 16:20 |
| lekernel | I like how Micron always says "Easy BGA" instead of "BGA" | 16:22 |
| lekernel | almost sounds orwellian | 16:22 |
| Fallenou | lol | 16:22 |
| Fallenou | Fast Spartan6 (Fastan 6 ?) | 16:23 |
| Fallenou | win 18 | 16:35 |
| lekernel | wow, Chua's paper is so full of academic BS. I'm glad I don't have a PhD. | 16:40 |
| lekernel | "the periodic table of circuit elements" lol | 16:41 |
| Fallenou | oh, original norflash was already 16 bits access | 16:50 |
| Fallenou | nice | 16:50 |
| 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 ? | 16:51 |
| lekernel | first one is lsb | 16:52 |
| Fallenou | arg :( | 16:52 |
| Fallenou | I've put MSB first, damn it | 16:52 |
| Fallenou | have to rewrite all the pads :) | 16:52 |
| Fallenou | or change the order of the Cat( ) in norFlash/__init__.py maybe ... | 16:53 |
| lekernel | better do it cleanly and invert that list | 16:56 |
| lekernel | and heh | 16:56 |
| lekernel | it's python :) | 16:56 |
| lekernel | l = [those pads you have written] | 16:56 |
| lekernel | print(list(reversed(l))) and you're done | 16:56 |
| lekernel | with just a bit of copy paste | 16:57 |
| Fallenou | yes I just did that with a python cmdline :) | 16:59 |
| Fallenou | hum I think I forgot to clock the flash | 17:02 |
| Fallenou | it seems the flash clk is directly hooked to one of the FPGA IO | 17:02 |
| lekernel | there is no clock | 17:07 |
| lekernel | except for spi which you don't use | 17:07 |
| Fallenou | ok | 17:10 |
| lekernel | would be cool to parameterize lm32 with verilog parameters instead of that messy and non-reentrant include | 17:25 |
| GitHub44 | [milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/IbCjOQ | 17:46 |
| GitHub44 | milkymist-ng/master 3eb41f7 Sebastien Bourdeauducq: Simplify system ID | 17:46 |
| Fallenou | antgreen: how do you write your code to Nexys3 Flash? You have some kind of "FPGA<->Flash" bridge? (like fjmem.bit) | 17:48 |
| Fallenou | or do you still use an embedded ROM? | 17:49 |
| antgreen | Fallenou: I don't yet. The only external memory I'm using is the pseudo-static RAM device | 17:49 |
| antgreen | (16M). | 17:49 |
| antgreen | Yes, also embedded memory | 17:50 |
| antgreen | ROM & RAM | 17:50 |
| antgreen | I have my initial bootloader in embedded memory | 17:50 |
| Fallenou | oh, ok | 17:50 |
| antgreen | it downloads srec programs into psram and executes from there | 17:50 |
| Fallenou | do you know if there is any easy way to write something to Flash? | 17:50 |
| Fallenou | any tool? something? | 17:50 |
| antgreen | only on windows :-( | 17:51 |
| Fallenou | oh | 17:51 |
| Fallenou | The Flash chip does not even seem to be on the JTAG chain :o | 17:51 |
| antgreen | if I had a flash controller, then I could create one easily | 17:51 |
| antgreen | that would be a good next project | 17:51 |
| antgreen | I'm leaving on a 4 day trip business tomorrow, and always get lots done then | 17:52 |
| antgreen | maybe I'll try it. | 17:52 |
| antgreen | http://electronics.stackexchange.com/questions/34807/accesing-the-pcm-flash-memory-on-a-nexys-3-board | 17:54 |
| lekernel | Fallenou, you can put the BIOS in BRAM | 17:54 |
| lekernel | fits in less than 16K if you trim it down | 17:54 |
| antgreen | yes, that's where my bootloader lives | 17:54 |
| antgreen | and it runs in BRAM RAM as well | 17:54 |
| antgreen | hehe - that stack exchange question was asked by a moxie user | 17:55 |
| antgreen | does the lm32 have a bus watchdog, or something that looks for unmapped memory accesses? | 17:56 |
| lekernel | there is an exception vector for when the wb error signal is asserted | 18:01 |
| 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 | 18:20 |
| Fallenou | but then I will really need to put a program in flash :) | 18:20 |
| lekernel | no, you sfl-boot or net-boot directly to PSRAM | 18:21 |
| lekernel | and completely ignore the flash | 18:21 |
| Fallenou | oh, why not yes | 18:23 |
| Fallenou | having the bios download application to RAM | 18:23 |
| Fallenou | and put the bios in ROM | 18:23 |
| GitHub198 | [mibuild] sbourdeauducq pushed 1 new commit to master: http://git.io/0pEemQ | 18:26 |
| GitHub198 | mibuild/master e272e68 Sebastien Bourdeauducq: platforms/papilio_pro: swap tx/rx to be consistent with M1 | 18:26 |
| antgreen | what is sfl-boot? | 18:37 |
| antgreen | oh, serial line | 18:39 |
| GitHub0 | [migen] sbourdeauducq pushed 2 new commits to master: http://git.io/woQIkQ | 18:56 |
| GitHub0 | migen/master 7ada015 Sebastien Bourdeauducq: bus/csr/SRAM: support init | 18:56 |
| GitHub0 | migen/master 5208baa Sebastien Bourdeauducq: bus/wishbone/SRAM: support init and read_only | 18:56 |
| 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 | 19:00 |
| wpwrak | "self.submodules.dma = spi.DMAWriteController(" hmm .. SPI ? wow | 19:03 |
| lekernel | simple processor interface | 19:47 |
| lekernel | and yes | 19:47 |
| lekernel | the infrastructure is still there; dvisampler stores pixels and that's why there's a separate "debug" core that stores raw | 19:48 |
| lekernel | ftdi_eeprom won't even compile... yes, libftdi "is easy to use" and "works perfectly" - I see ... | 19:50 |
| wpwrak | ah ! that's where it went. thanks ! | 19:50 |
| wpwrak | there are lies, damn lies, and then there's marketing :) | 19:50 |
| lekernel | cmake even produces a blank makefile, lol | 19:50 |
| wpwrak | crapmake ? :) | 19:51 |
| lekernel | ./ftdi_eeprom --read-eeprom conf.conf | 19:58 |
| lekernel | Warning: Not writing eeprom, you must supply a valid filename | 19:58 |
| lekernel | ahem | 19:58 |
| lekernel | did a Xilinx engineer write this? | 19:59 |
| larsc | well better than if it actually did write the eeprom | 20:00 |
| lekernel | ?! the poor shit has a read eeprom mode, but then you can't rewrite the backup file you just made? | 20:16 |
| lekernel | oh my ... | 20:17 |
| lekernel | eeprom_set_value(ftdi, VENDOR_ID, cfg_getint(cfg, "vendor_id")); | 20:18 |
| lekernel | ... | 20:18 |
| lekernel | eeprom_set_value(ftdi, CHANNEL_A_DRIVER, DRIVER_VCP); | 20:18 |
| lekernel | eeprom_set_value(ftdi, CHANNEL_B_DRIVER, DRIVER_VCP); | 20:18 |
| lekernel | eeprom_set_value(ftdi, CHANNEL_C_DRIVER, DRIVER_VCP); | 20:18 |
| lekernel | eeprom_set_value(ftdi, CHANNEL_D_DRIVER, DRIVER_VCP); | 20:18 |
| lekernel | ahem .... | 20:19 |
| lekernel | great error reporting, too http://pastebin.com/KbQwh3Lz | 20:25 |
| wpwrak | don't worry, there's a lot more badness where that came from :) | 20:38 |
| lekernel | ftdi stuff is like raspberry pi, two devices with a large open source-ish community and no one to get things right | 20:42 |
| 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. | 20:52 |
| 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 .... | 20:55 |
| wpwrak | gee, so many surprises :) | 20:57 |
| wpwrak | don't worry, the writes that go slightly wrong will only change undocumented bits that completely alter the function of the device | 20:57 |
| 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. | 21:05 |
| 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 | 21:06 |
| lekernel | very clever :) | 21:07 |
| wpwrak | don't worry, that's just a minor detour. you'll get back to the real road to hell quickly enough. | 21:13 |
| lekernel | ah, you are right | 21:18 |
| lekernel | though it was just ftdi_set_eeprom_buf() ignoring its size parameters. finally got my original backup written correctly. | 21:24 |
| lekernel | the amount of bugs in ftdi chips and libftdi is quite impressive | 21:25 |
| davidc__ | use the windows tool - I hate to say it but, libftdi / the ftdi_eeprom tool is completely fucking broken | 22:05 |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!
