<GitHub36>
[migen/master] Abstract actor graphs - Sebastien Bourdeauducq
antgreen has joined #milkymist
Martoni has quit [Quit: ChatZilla 0.9.88.2 [Firefox 13.0/20120601201853]]
azonenberg has quit [Ping timeout: 245 seconds]
jimmythehorn has joined #milkymist
azonenberg has joined #milkymist
elldekaa has quit [Remote host closed the connection]
<azonenberg>
Just curious, how do you guys typically debug?
<azonenberg>
Simulation? Observe actual behavior in hardware? Break signals out to GPIOs and use a LA? Chipscope? All of the above?
<azonenberg>
i'm trying to debug some of my code that uses DRAM and thus would be difficult to downclock, and it's too big to simulate in the free ISim at a reasonable speed
<azonenberg>
and its too fast for my LA
<kristianpaul>
I use most the scope and cheap LA (not very often)
<kristianpaul>
for the rest i let software debug hw
<azonenberg>
So i decided to build my own internal LA similar to chipscope, it currently has 128 channels and programmable triggers (rising, falling, low, and high on each of 128 channels, AND the results together and OR with external trigger)
<azonenberg>
logs 512 samples to block RAM on a provided clock
<kristianpaul>
oh ho
<azonenberg>
then dumps over a UART and renders in gtkwave
<kristianpaul>
sharing is caring azonenberg :-) (ABout internal LA)
<azonenberg>
if anybody is interested once i polish the toolchain a bit i'll be looking for beta testers, it's BSD licensed
<azonenberg>
or will be once i post it somewhere public, right now its just a directory on my laptop :P
<azonenberg>
Think you guys would find it useful?
<kristianpaul>
yes of course, have an alternative to chipscope is AWESOME
<azonenberg>
on spartan6 -3 it can get up to almost 200 MSa/sec (180 i think) and if you cut the number of channels to 64 or 32 it would be even faster
<kristianpaul>
dunno if it can buffer bunch of stuff for usb debugging
<azonenberg>
uses four block ram and a few dozen slices
<azonenberg>
The current implementation has 512 samples deep memory but that would be easy to tweak
<kristianpaul>
it have its own uart code that how fast?
<azonenberg>
its not fully parameterizable yet, thats one of the things i plan to tweak before release
<azonenberg>
It uses the open source uart core i wrote a while ago
<azonenberg>
i didnt like the opencores ones since they were wishbone and i needed native interface
<kristianpaul>
u said toolchain, u mean it run a minisoc or such?
<azonenberg>
Well
<azonenberg>
there's four components to it
<azonenberg>
first is the core LA
<azonenberg>
which is trigger and a dual ported block ram
<azonenberg>
second is the wrapper that, when the LA asserts DONE, dumps to the PC over some interface
<azonenberg>
right now that's a uart at 500 Kbps but you could replace it with usb, ethernet, etc easily
<azonenberg>
third is a short C++ program that takes data from the uart and reformats it into a standard .vcd file, taking the 128-bit raw samples and splitting them up according to the signals you defined (buttons and count in this screenshot)
<azonenberg>
then fourth is the waveform viewer, i'm using an existing tool (gtkwave) for that
<kristianpaul>
looks simple, good
<azonenberg>
its all modular so by replacing blocks 2 and 3 you could easily adapt it to any interface other than uart
<azonenberg>
uart is what i had on this board
<azonenberg>
plus 100mbit ethernet but i dont have HDL to interface to it yet
<azonenberg>
the big thing left to do before a v0.1 alpha release is to make component 3 a little more polished
<kristianpaul>
but 512 samples, is just fifo, ring buffer?
<azonenberg>
for example don't hardcode /dev/ttyUSB0
<kristianpaul>
i mean it just sample 512 and stop?
<azonenberg>
and dont hardcode the channel-to-signal mappings
<azonenberg>
and allow trigger to be updated at run time rather than hardcoded on the FPGA
<azonenberg>
It samples continually
<azonenberg>
in a ring buffer
<azonenberg>
thereare three pointers
<azonenberg>
start, write, and stop
<azonenberg>
in the "waiting for trigger" state, write is start+16
<azonenberg>
and stop is start+512
<azonenberg>
once triggered, start and stop freeze
<azonenberg>
and it stops capture when write = stop\
<kristianpaul>
publish publish ! (and blog about it ;_)
<azonenberg>
so you get 16 samples before trigger and (512-16) after
<azonenberg>
then once the wrapper has sent the data tothe PC it resets the LA
<azonenberg>
so you can capture again
<azonenberg>
in my screenshot i had the trigger set as rising edge of buttons[0]
<azonenberg>
the red cursor is at the trigger point
Hawk777 has quit [Quit: Coyote finally caught me]
Hawk777 has joined #milkymist
<lekernel>
azonenberg: why not use the milkymist dram controller?
<azonenberg>
lekernel: thats irrelevant, the code is in my bridge between the CPU and the dram
<azonenberg>
not the MCB
<azonenberg>
the bug*
<lekernel>
ah, you're using the MCB
<azonenberg>
i intend to try using it in the future
<azonenberg>
it should be drop-in for the MCB if i rewrite the bridge
<azonenberg>
the problem i have now is that the bridge is occasionally losing data or something like that (hangs)
<azonenberg>
and i cant clock it any slower
<azonenberg>
and the MCB primitive wont simulate in isim lite
<azonenberg>
and i dont have a chipscope license
<azonenberg>
solution? make my own
<kristianpaul>
okay i got lost, i need a cpu to "run" or can be indepent?
<azonenberg>
This is completely standalone
<azonenberg>
you have two modules
<azonenberg>
RedTinLogicAnalyzer is the core
<lekernel>
if you used the milkymist dram controller, you would not have simulation problems
<azonenberg>
then (unnamed wrapper thats currently part of my testbench) reads the data from that into a PC interface such as a uart
<azonenberg>
you could even log to SD if you didnt have a pc handy
<lekernel>
and it can work at any frequency (if you disable the DLL in the DRAM)
<azonenberg>
and then analyze the capture later
<azonenberg>
lekernel: interesting but isim still has a 50k line limit
<lekernel>
then use iverilog
<azonenberg>
which i will hit sooner or later
<azonenberg>
probably sooner
<azonenberg>
I intend to explore that
<lekernel>
or verilator, if you need speed (it's faster than modelsim)
<azonenberg>
In any case that's all irrelevant, the point is i'm workign on this tool and i'll have an alpha out for you guys to play with soon
<azonenberg>
and its free software
<kristianpaul>
irrelevant, agreed !
<azonenberg>
I'll be polishing it for another day or two and then release an alpha on google code probably this weekend some time
<azonenberg>
when that happens i'll do a short blog post on it
<azonenberg>
lekernel: chipscope or the MCB?
<lekernel>
the MCB stuff
<lekernel>
and the CPU
<azonenberg>
mcb, because i had been using it before i knew your controller existed
<azonenberg>
cpu, because i like mips and there's no good open source mips core out there
<azonenberg>
plasma is so-so (3 stage pipeline and slow), mine is meant to go faster
<lekernel>
what advantage does mips have over lm32?
<azonenberg>
i have an existing codebase for it with lots of asm
<azonenberg>
thats really the main reason
<kristianpaul>
asm, urgh ;-)
<azonenberg>
i was working on pic32 and outgrew its RAM capacity
<lekernel>
having lots of asm is also reinventing wheels and is evil
<azonenberg>
its a kernel
<azonenberg>
not really an alternative for asm in context switching etc
<azonenberg>
and i'm doing my thesis work on OS architecture and such so i need a cpu/os that is bare bones and simple to modify
<azonenberg>
linux is a little too big to be easy to make sweeping changes to
<lekernel>
that's not what i'd call "lots of asm"... it's much faster to rewrite that context switch code for LM32 than reinvent yet another open source softcore
<lekernel>
or use an existing kernel and reinvent one wheel less
<lekernel>
nuttx is pretty good
<azonenberg>
i also wanted practice in cpu design
<azonenberg>
before i went on to the NEXT stage of my research which will involve major cpu architecture changes
<azonenberg>
and chipscope, well...
<azonenberg>
there is no open source alternative that i could find
<azonenberg>
so it was a pretty simple decision
<lekernel>
yeah, I don't question the chipscope alternative.
<lekernel>
tbh this is your first FPGA project that I find interesting
<azonenberg>
well if you dont like my cpu you dont have to use it :p
<azonenberg>
Most of my other projects were done to get experience with the technology and learn
<azonenberg>
like the cpu
<kristianpaul>
what compile pic32 uses gcc?
<azonenberg>
i wanted to learn more about how to build an efficient pipelined microarchitecture given the instruction set but no details of how to implement it
<azonenberg>
kristianpaul: yes
<azonenberg>
its a fork of gcc with some pic-specific patches
<azonenberg>
that arent in mainline yet
<azonenberg>
but it is gcc and you can get source
<kristianpaul>
and libc?
<azonenberg>
proprietary libc i think on pic32
<azonenberg>
i didnt use it
<azonenberg>
my core is designed to work with mainline gcc plus a custom linker script for my memory map
<azonenberg>
mipsel-elf target
* kristianpaul
loves mainline word
<kristianpaul>
lekernel: so he basically same you did with navre, you are fair now ;-)
<kristianpaul>
basically did*
<azonenberg>
the original goal was to take my existing tens of thousands of lines of pic32 code
<azonenberg>
and move it onto a similar platform with more ram
<azonenberg>
will be pushing my code to it later today
<kristianpaul>
erghh google just changed again project feeds urls..
<lekernel>
and of course, you trusted the Milkymist DRAM controller even less than e.g. NASA did, and you went for the proprietary MCB which is causing you trouble now :)
<azonenberg>
lekernel: the mcb is actually not giving me any trouble
<azonenberg>
its the bridge between it and my code
<azonenberg>
i'm overrunning their fifos
<azonenberg>
and i cant figure out why
<kristianpaul>
NASA, ahh did they finally crashed because of it? ;-)
voidcoder has quit [Read error: Connection reset by peer]
<lekernel>
last time I heard from it (a month ago actually) they were happy with it.
<kristianpaul>
ok, now are you happy that azonenberg is coding a LA that could help us debug MM SoC? :-)
<lekernel>
yeah, this is good news :)
voidcoder has joined #milkymist
antgreen has quit [Remote host closed the connection]
elldekaa has joined #milkymist
<Fallenou>
I wonder why people still use google code
<Fallenou>
I find the UI ugly
<Fallenou>
and it seems to be using svn instead of git
<Fallenou>
is it possible to use git with it ?
<azonenberg>
You can use git, svn, or hg
<azonenberg>
i prefer svn
elldekaa has quit [Ping timeout: 245 seconds]
<Fallenou>
oh ok, nice
<Fallenou>
nice project your LA
<azonenberg>
Lol well it isnt done yet
<azonenberg>
and there's absolutely zero documentation atm :p
<Fallenou>
I mean the way you describe it, it sounds like a nice tool :)
<azonenberg>
I'd prefer to say "it's going to be nice" :p
<azonenberg>
right now its a work in progress lol
<azonenberg>
i just synced my repo over to the google code and will be doing future development there
<azonenberg>
next step is going to be removing some of the hard-coded config and making it more tweakable
<Fallenou>
well good luck to continue/finish it !
<Fallenou>
luck/courage/fun
wolfspraul has quit [Ping timeout: 244 seconds]
wolfspraul has joined #milkymist
rejon has quit [Read error: Connection reset by peer]
elldekaa has joined #milkymist
rejon has joined #milkymist
mumptai has quit [Quit: Verlassend]
mumptai has joined #milkymist
rejon_ has joined #milkymist
rejon has quit [Ping timeout: 265 seconds]
elldekaa has quit [Ping timeout: 252 seconds]
hypermodern has joined #milkymist
<larsc>
Fallenou: the problem is the sf gui is even more ugly
<Fallenou>
I agree
<Fallenou>
I kind of like gitorious and github
<larsc>
and github is nice but has become pretty bloated with lots of js
<larsc>
gitorious is ok
<Fallenou>
I guess it's bloated, but it still runs fine on my laptop
elldekaa has joined #milkymist
elldekaa_ has joined #milkymist
elldekaa has quit [Read error: Connection reset by peer]
azonenberg has quit [Remote host closed the connection]
TachyonDev has quit [Read error: Connection reset by peer]
azonenberg has joined #milkymist
elldekaa_ has quit [Ping timeout: 244 seconds]
antgreen has joined #milkymist
elldekaa_ has joined #milkymist
antgreen has quit [Remote host closed the connection]
elldekaa_ has quit [Ping timeout: 265 seconds]
<wpwrak>
the gui is the least of sf's problems. the main issue is its download system that doesn't let you have direct links. well, you can circumvent it by putting your files in the web space, but i'm not sure if they'd tolerate that for busy projects