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 :)
<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>
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>
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>
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
<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>
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