<Fallenou_>
mwalle: why would you replace the DCM by a PLL in system.v ? *trying to understand the patch*
<Fallenou_>
to generate more different clock frequencies ?
voidcoder has joined #milkymist
<wolfspraul>
Fallenou_: maybe you already saw this, but I was also reading the patch now and at the top it says "use two chained PLLs to generate all needed clocks. this makes it possible to switch the USB clock to 72mhz"
<wolfspraul>
but reading through line by line is still above my head... learning :-)
rejon has joined #milkymist
rejon has joined #milkymist
sb0 has joined #milkymist
hypermodern has quit [#milkymist]
voidcoder has joined #milkymist
<wpwrak>
i find the one entitled "Switch USB clock to 72MHz" a bit scary. particularly the softusb_rx.v changes are far from obvious
<wpwrak>
Fallenou_: btw, does your recent success mean that you found the problem that prevented the MMU from working ?
sb0 has joined #milkymist
hypermodern has joined #milkymist
mumptai has joined #milkymist
roh has joined #milkymist
voidcoder has joined #milkymist
sb0 has joined #milkymist
Gurty has joined #milkymist
<mwalle>
wpwrak: yeah there is a need for some better commit messages ;)
<mwalle>
Fallenou_: you cant generate the 72mhz from one dcm using two plls you are able to generate all required clocks inside and outside the system, apart from the vga pixel clock
<mwalle>
and iirc xilinx doesnt recommend chaining two dcms
wolfspra1l has joined #milkymist
kilae has joined #milkymist
<Fallenou_>
wolfspraul: yes I saw the commit message, I was trying to understand why switching from DCM to PLL, just curious
<Fallenou_>
maybe there is more bugs, but at least those 15 test cases are passing for now :)
<Fallenou_>
so I must be making at least some progress :)
<Fallenou_>
if someone wants to write more tests, he is welcome !
<Fallenou_>
I would like to go on to the next chapter now
<Fallenou_>
i.e generating exception when dtlb miss, fix the mapping and then go back to the code
<Fallenou_>
but test cases can still be written as a background task
<Fallenou_>
it's pretty easy, just doing enable_dtlb(); some normal instructions using memory loads and stores disable_dtlb(); and check if the result is correct
<mwalle>
wpwrak: once the 72mhz usb has been verified to be working (or at least doesnt introduce any regressions ;) ) i'll elaborate on the commit message
<wpwrak>
hmm. these are the versions i have. daily therefore shouldn't work. let's see ...
<wpwrak>
yeah, same behaviour from FN. good. so it's not my fault ;-)
<wpwrak>
but USB looks very good. also the endless stream of errors is gone.
<sb0>
ok, good for commit then?
<wpwrak>
i think we can risk it :)
<Fallenou_>
nice !
<wpwrak>
if anything blows up, we can revert anyway. and it's not as if "bleeding edge" would always work - i.e., right now, it doesn't, due to the rtems/yaffs issue. annoyingly, just changing the permissions back didn't do the trick. so i'll have to find a set of versions that still works ...
<sb0>
yeah, this regular rtems breakage is quite annoying
<mwalle>
wpwrak: (streams of error) compared to the 48mhz variant?
<wpwrak>
mwalle: compared to softusb before your changes. i didn't test between your first (assignments) and second set (72 Mhz)
<mwalle>
wpwrak: the assignments shouldnt have any effect on the bitstream
<mwalle>
sb0: but please let me cleanup the patches before you commit them ;)
<mwalle>
sb0: and should i pin the pll by constraints? i dont know how i can find out the position/name/whatsoever
<sb0>
ok, time to go to the next destination anyway
<sb0>
yes, lock the PLLs. you can find the site names by opening the .ncd file in FPGA Editor
<mwalle>
sb0: ah one more, seems like the dcm implicitly inferred an IBUF on clk50, because the net was named clk50_IBUF in the constraints
<sb0>
or using xdl
<sb0>
yes
<sb0>
net names are messy
<sb0>
again you can find the one that the tools picked with fpga editor or xdl
<mwalle>
for the pll i had to infer it explicitly
<sb0>
or even directly in the netlist
<mwalle>
kk, will try
<mwalle>
the fpga editor wont start on my machine, i'll find out ;)
<sb0>
yes, it's a common problem
<sb0>
xdl has fewer bugs
<sb0>
bbl
<mwalle>
bye
<kristianpaul>
wpwrak: having a chipscope floss client will resolve your problems about getting signals easilly out of the fabric for debugging porpuses
<kristianpaul>
if is that what i undertood correclty you require from verilog
kyak has joined #milkymist
Thorn__ has joined #milkymist
Thorn__ has joined #milkymist
voidcoder has joined #milkymist
bhamilton has joined #milkymist
elldekaa has joined #milkymist
<wpwrak>
kristianpaul: ah, that may be something to look at, yes. anyway, it seems that mwalle already somehow made those errors go away. not having a problem beats having a great plan for solving it ;-)
<wpwrak>
it's kinda interesting to note that the autocrap bootstrap of rtems takes about half as long as synthesizing the FPGA. talk about efficient bureaucracy.
<Fallenou_>
it's horrible, the bootstrap
<Fallenou_>
fortunately, you don't have to bootstrap everything if you just changed a few files in a few directory
<Fallenou_>
a few makefiles/configure
<kristianpaul>
as long indeed
<wpwrak>
yeah, but if you jump around in the history, changing who knows what ... :-(
<kristianpaul>
thats why i dont use rtems atm :=
<kristianpaul>
and use a minimal SoC with cores just i need to the problem trying to solve
<kristianpaul>
that way synthesis dont get long than 15m
<kristianpaul>
at least..
<Fallenou_>
hehe
<Fallenou_>
8 minutes for me ;)
<Fallenou_>
I disactivated almost everything
<kristianpaul>
oh wow
<Fallenou_>
and Xst is running inside a debian virtual machine
<kristianpaul>
form setup.v or something else?
<kristianpaul>
wow
<Fallenou_>
yes setup.v
<Fallenou_>
oh, I kept memory card, I could remove it
<Fallenou_>
it could be even faster
<Fallenou_>
I kept FML meter I didn't know if it was mandatory
<kristianpaul>
i remenber only mandatory is memtest in some cases
voidcoder has joined #milkymist
<kristianpaul>
in the milkyminer i just kept FML, sysctl, sdram stuff and lm32 basically
<wpwrak>
FML is very optional
<wpwrak>
and it's a convenient source for a CSR address ;-)
<Fallenou_>
is it really hard to add 1 bit to csr addresses ?
<wpwrak>
dunno. maybe not. would mean editing lots of places, though
<Fallenou_>
yes I guess
<larsc>
you can decrease the per block space
<Fallenou_>
and hard to debug if it synthetizez and crashes the soc
<larsc>
i think it is 0x4000 currently
<kristianpaul>
Fallenou_: is not
<kristianpaul>
yes, some editing and replace in the cores
<larsc>
which is much more than what is currently used
<wpwrak>
hmm, in the led matrix controller, i use 9 address bits. three of them are reserved for geometries we don't use (but which could be selected by changing parameters)
<larsc>
512 registers?
<wpwrak>
good news: with the right amount of pinning, things look friendly. including working usb-midi
<wpwrak>
at least 256. could be more because it's a matrix. one bit switches between the PWM and the "administrative" bank
<Fallenou_>
wpwrak: your ledm.v contains so much things I would not have thought to be "synthetizable" by Xst. it's amazing it works :) like triple arrays [][][], tasks, disable XXX,
<Fallenou_>
but it makes the code looks nice
<wpwrak>
;-)
<wpwrak>
yeah, i was quite surprised how clean you can make things
<wpwrak>
there are still a number of silly oddities that don't seem technically necessary, such as having to name blocks for "disable" (to express my disdain, i thus used "_"), but verilog does seem to have a decent enough set of features for things of medium complexity
<wpwrak>
oh, but i also ran into trouble: if you take the handling of "Z" too far, xst falls apart and generates an incorrect system
<Fallenou_>
arg :/
<Fallenou_>
what does "disable" do ?
<Fallenou_>
first time I see it
<Fallenou_>
gn8 !
<mwalle>
gn8
<wpwrak>
it's basically like a "break" or "return" in C
<wpwrak>
it exits the block. so instead of if ... a little ... else ... lots of code ... you can just if ... begin ... disable end and leave out the else branch, along with indentation
<mwalle>
mh my interrupts for the navre core seems to work somehow :)
<wpwrak>
nice :) that's for USB out ?
<mwalle>
wpwrak: i'm using the mm as a usb device, so its usb in from my pov
<wpwrak>
ah, device mode. interesting.
<wpwrak>
so we'll have an alternative to ethernet. well, for things that don't have to be very fast :)
<mwalle>
think of another gdb channel (maybe fast this time ;) ..), DFU, mass storage, dunno ;)