<terpstra> lekernel, (option b! option b!)
<larsc> mwalle: more or less
<juliusb> lekernel: hejsan, how are you?
<juliusb> I recall you had a synthesis tool you were working on, how is that going?
<juliusb> and where can I find the site it was on - I couldn't find a link from the milkymist website
<lekernel> hi
<lekernel> it's moving forward, though a bit slowly, my main priority is milkymist
<lekernel> lately I was analyzing the s6 bitstream format a bit
<juliusb> cool
<juliusb> yes I recently got a spartan6 board
<juliusb> still fixing issues on my older Xilinx boards but hope to get it working soon
<juliusb> ... but where is the synthesis project's source? I've seen it before but forgot what it was called
<lekernel> code is here=> github.com/sbourdeauducq
<lekernel> there's also a little doc at https://github.com/sbourdeauducq/llhdl/wiki
<juliusb> cool, thanks
<lekernel> which s6 board did you get? m1? :p
<juliusb> digilent atlys
<juliusb> i haven't even started synthesizing for it to be honest
<juliusb> interested to see the advance in technology
<lekernel> why not M1?
<juliusb> what is M1?
<juliusb> that Xilinx one?
<lekernel> our board... http://www.milkymist.org/mmone.html
<juliusb> we got the atlys quite cheap
<juliusb> it looks good, yours actually
<juliusb> how much is it?
<juliusb> how much to get one to my door?
<juliusb> running off for lunch, be back later
<lekernel> 380E + shipping
<guyzmo> ola
<guyzmo> lekernel - I did get some basic lua stuff to work, but nothing fancy
<guyzmo> it would be nice if I could be able to output something (video, sound, dmx...) from the MM1 with lua code
<guyzmo> to show off something better than just a lua interpreter blackbox
<lekernel> imo dmx is easier
<lekernel> complement **the set of functions related to file systems offered by the standard Lua distribution**.
<lekernel> imo you already have everything you need for DMX in that standard distribution
<guyzmo> lekernel - and do you have a rtfm to write well formatted DMX datagrams into the matching chardev ?
<lekernel> you don't have to format the DMX frames, the hardware does it for you
<lekernel> all you need to do is:
<lekernel> 1) open /dev/dmx_out
<lekernel> 2) seek to the channel you want (first position = channel 1, etc. by default the /dev file is opened at channel 1)
<lekernel> 3) write one byte to set the level of that channel - if you write more than one byte it will also assign to the next channels
<lekernel> 4) close /dev/dmx_out
<guyzmo> interesting implementation
<guyzmo> it sends the packet on flush() ?
<lekernel> no, it sends the packet all the time with the memorized channel values
<guyzmo> ok
<lekernel> it's like a DMX desk, and using /dev/dmx_out you touch the faders :-)
<guyzmo> ok, I'll get two DMX projectors for thursday and tomorrow I'll write a demo in lua
<guyzmo> (I don't have a DMX projector at the bear's cave)
<carlobar> lekernel: hi, i have made some changes on the hpdmc controller: on initialization i configure burst_length = 2, and now i made 32 bit read/write operations using burst, so i think that im ensuring a data flow during the burst length, but it still dont work. I dont know what else can i do, i dont know what is missing. any advice? thanks
<lekernel> based on this scarce information, i'd advise you to buy a M1 which i've spent a year or so to get the SDRAM to work on
<lekernel> have you run verilog simulations first, though?
<carlobar> hahaha, yes, in simulation it read and write without problem
<lekernel> including through the l2 cache?
<carlobar> what is the l2 cache? simulation includes: csrbrg, fmlbrg, hpdmc, ddr... buffers, double date rate flip flops  and the dcm_sp are simulated too. the problem that i had with IDDR2 and ODDR2 was solved adding a flip flop to each one, with that the behavior of these devices was achieved
<carlobar> on spartan3, ODDR2 and IDDR2 can only be implemented with the parameter: DDR_ALIGNMENT = "NONE", so adding a flip flop, the behavior of DDR_ALIGNMENT = "C0" is achieved
<lekernel> l2 cache is fmlbrg
<carlobar> i remember that i had changed the fmlbrg, i had modified it to support fml with 32bit data bus, and i wasnt sure if it worked or not, so i changed it. the fmlbrg uses a state machine to control when an instruction is sent to the fml bus, and when a result is sent to the wishbone bus...
<carlobar> these are the results when i write/read data:
<carlobar> mr 0x40000000 16:: 0x40000000  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<carlobar> mr 0x40002000 16:: 0x40002000  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<carlobar> mw 0x40000000 0xfade2bad
<carlobar> mr 0x40000000 16:: 0x40000000  fa de 2b ad 00 00 00 00 00 00 00 00 00 00 00 00  ..+.............
<carlobar> mr 0x40002000 16:: 0x40002000  fa de 2b ad 00 00 00 00 00 00 00 00 00 00 00 00  ..+.............
<carlobar> mw 0x40002000 0xabcdef00
<carlobar> mr 0x40002000 16:: 0x40002000  ab cd ef 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<carlobar> mr 0x40000000 16:: 0x40000000  ab cd ef 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<carlobar> i thought that the memory didnt recognize the bank or row address, so i made tests changing the bank address, and write/read operations worked...
<carlobar> im runing the system at a freq of 40MHz, so i modified the timing register
<lekernel> did you disable the dll in the dram chip?
<carlobar> you mean the "operating mode" at mode register?
<lekernel> something like that
<carlobar> it is in normal operation: 00000..... on the initialization sequence i just modified the burst length
<carlobar> and added the instructions to change the timing register
<carlobar> lekernel: do you spent one year working only on SDRAM or you were working in all the system?
<lekernel> only on SDRAM. but those were in the ML401 days, and I didn't have as much insight into digital design as I have now.
<lekernel> the M1 just uses roughly the same memory as the ML401 so I did not have to redesign that part
<carlobar> i just realized that the problem is in directions: 0x40000000, 0x40002000, 0x40004000 and so on.., but sometimes when i read at that directions, previous data is replaced with 0x00000000
<mwalle> gdb patch is upstream and will be included in gdb 7.3
<lekernel> the break problem? great :)
<mwalle> yep
<mwalle> and there will be target dependent linking for qemu, eg link only to libGL if target==lm32, so it will be enabled by default again
<wpwrak> lekernel: boring. should be with an electronic sensor. you could increase the resolution by vibrating the object.