Topic for #milkymist is now Milkymist One, Milkymist SoC & Flickernoise development channel (LLHDL/Antares are welcome too) :: Logs: http://en.qi-hardware.com/mmlogs :: JFDI
gbraad_ joined #milkymist
gbraad_ joined #milkymist
aw joined #milkymist
aw_ joined #milkymist
xiangfu joined #milkymist
xiangfu joined #milkymist
xiangfu joined #milkymist
rejon joined #milkymist
<kristianpaul>
wpwrak: that xse-sane allow to use in the same shell the lm32-gcc ?
<wpwrak>
there should be no conflict
<wpwrak>
i kinda wonder if build_bitstream.sh would tell me if it found an error. or if we would just proceed with the old file and let me find it somewhere in the megabytes of diagnostics
<wpwrak>
s/we/it/
<kristianpaul>
not use that script
<kristianpaul>
ah well it oes
<kristianpaul>
does, some build.log
<kristianpaul>
i wonder when i stoped using it..
<wpwrak>
so if there's an error, will it fail ? or will it just continue ?
<kristianpaul>
now i just type time make soc.fpg | tee soclog under boards/milkymist-one/flash/
<wpwrak>
and yes, it's only a question of time until i get rid of it :) i really dislike those scripts that hide vital information from you
<kristianpaul>
errors stop verything
<kristianpaul>
and warnings pass silent...
<kristianpaul>
get rid of it, yes yes !
<wpwrak>
good. then i either made no detectable errors so far ... or the thing is really slow at detecting them :)
<kristianpaul>
ucf errors may take a while to show up
wolfspraul joined #milkymist
<kristianpaul>
btw be _aware_ that by default soc and soc-rescue bitstream are build
<kristianpaul>
so you spend TWICE time syntheising !!
<wpwrak>
i'm a bit worried about the vast amount of warnings. is it normal to for verilog to have so many warnings ? it basically means they're useless
<wpwrak>
HMMM
<kristianpaul>
:_D
<kristianpaul>
please confirm
<kristianpaul>
i just had tha sad experience when get into M1 "hdl developmemnt"
<wpwrak>
i looked for -rescue but didn't see anything. lemme have a closer look then
<kristianpaul>
yeah, actually i thing that is just present in boards/milkymist-one/flash/Makefile
<kristianpaul>
just share your timings, i'm curios how long it taks on a fast machine like yours :-)
<kristianpaul>
taks/takes
<wpwrak>
rescue would be in boards/milkymist-one/synthesis/build-rescue/
<wpwrak>
and i have nothing there. so i think i'm good
<kristianpaul>
phew
<wpwrak>
a system with default config took about 25 minutes. with all peripherals except USB disabled, about 10 minutes
<kristianpaul>
wow
<wpwrak>
oh nice. errors are not reported as such
<wpwrak>
so maybe the 10 minutes were an incomplete build
<kristianpaul>
dint said build fail?
<wpwrak>
oh, right
<kristianpaul>
i think buid_bitstream report errors, at least with a generic fail..
<wpwrak>
very discrete :)
<kristianpaul>
;)
<wpwrak>
okay, so system with nothing but USB, proper build, 10 min 35 sec
<kristianpaul>
not bad...
<wpwrak>
and my PC's CPU isn't all that fast. it's a Q6600. that was "modern" some 4 years ago
<kristianpaul>
seems i need a dual core machine at least, system with no thong but namuru (one correlator arm) takes 30minutes here :-|
<kristianpaul>
ok
<kristianpaul>
thong/thing
<wpwrak>
pentium I, 60 MHz ? :)
<kristianpaul>
nah, amd sempron 2.4ghz
<kristianpaul>
the cheapest 2 years ago :)
<wpwrak>
maybe namru is complex then
<kristianpaul>
perhaps
<kristianpaul>
too many mixers and counters :-)
<kristianpaul>
ucf erros are the last to show from i remenber, and very dicusting after wait almost 80% of time
<kristianpaul>
btw i think. you also can run all this synthesis steps one by one
<wpwrak>
it's more like 95% ...
<kristianpaul>
wpwrak: ;-)
<kristianpaul>
why? well to avoid repeat all of then.. afaik i nevr tried, i just have some logs from lekenerl trying to do P&R in parallel
<kristianpaul>
like a farm build or such, very intresting
<wpwrak>
well, i have to admit that the DRC was right ..
<wpwrak>
"make" should take care of skipping steps that aren't necessary
<kristianpaul>
YES
<kristianpaul>
i just hack the makefile for quick
<wpwrak>
i don't see anything parallelizable there, though. but maybe that's just how the makefiles are written
<wpwrak>
parallel P&R would be nice - i have 4 cores to play with, so that would help :)
<wpwrak>
now, ERROR after 2 minutes
<GitHub143>
[autotest-m1] xiangfu pushed 1 new commit to master: http://git.io/3m2pcw
<GitHub143>
[autotest-m1/master] support new uart core - Xiangfu Liu
* xiangfu
try to follow recently milkymist develop. Sebastien have commit some pictures support code, great.
<kristianpaul>
oh
<wolfspraul>
and I am lobbying people to take on the Linux on M1 port :-)
<wolfspraul>
wolfy the beggar
<wolfspraul>
:-)
<kristianpaul>
jpeg.. hope load fast
<kristianpaul>
wallpaper was not a great experience
<wolfspraul>
kristianpaul: I see we are making progress on expectation management :-)
<wpwrak>
aha ! the build script doesn't honor dependencies
<wolfspraul>
(I'm serious)
<kristianpaul>
wolfspraul: hum?
<wolfspraul>
expectation management is so difficult.
<wpwrak>
i changed system.v, and it didn't process it, because it had (incorrect) output from a previous run
<kristianpaul>
i wonder what i did about that topic :-)
<wolfspraul>
kristianpaul: well, you hear about jpeg, but you are cautious as to how well it will actually perform. yet you are still excited to see it coming :-)
<wolfspraul>
GOOD!
<kristianpaul>
;_)
<wolfspraul>
being disappointed is not a good experience, ever
<kristianpaul>
i see coming a jpeg boost core :-D
<wolfspraul>
so the skill in expectation management is to get people excited about something, but then still slightly over-deliver on what they expected
<kristianpaul>
or gif support? :-)
<wolfspraul>
yeah yeah
<wolfspraul>
:-)
<kristianpaul>
:-)
<wpwrak>
maybe we can get hardware-accelerated PPM ;-)
<kristianpaul>
jpeg not joking, wasnt stekern metionted some experience about it in the past?
<kristianpaul>
scrts***
<xiangfu>
wpwrak, (the build script doesn't honor dependencies) which one? scripts.git?
<kristianpaul>
llvm, lemon..
<kristianpaul>
i guess?
<wpwrak>
milkymist.git/build_bitstream.sh
<wpwrak>
well, and also build_bios.sh for that matter :)
<wpwrak>
e.g., change softusb/main.c and run make (without making libhal) it'll never know. you have to make libhal manually, then it's happy
<wpwrak>
things are getting more interesting: ERROR:Pack:1654 - The timing-driven placement phase encountered an error.
<xiangfu>
wpwrak, then it maybe something woring with the boards/milkymist-one/synthesis/Makefile.xst
<wpwrak>
funny, it's drive strength conflict :)
<kristianpaul>
indeed boards/milkymist-one/flash/ is a better place
<wpwrak>
well, not strength. let's say driver type.
<wpwrak>
kristianpaul: synthesis/Makefile.xst is what gets invoked from flash/Makefile :)
<kristianpaul>
yes...
<wpwrak>
xiangfu: yeah, probably. the whole build system could use some cleaning. perhaps starting in rtems :) e.g., linux kernel-style short messages. CC foo.c instead of blah-gaga-gcc -Weird -madness -freak -B ../../../down/deeper/still-more/../../../../oops/lets/do/this/again/../finally -I ...
<wpwrak>
kristianpaul: the corollary is that some of the bugs you may observe could simply be build dependencies that weren't correctly handled :)
<wpwrak>
particularly helpful with tests of the sort "if i change X, does this make the problem go away" ? you change, gazillions of lines scroll by, so you have no idea what was actually done, then you get the final binary. you try it and the problem is still there. so you think changing X didn't help. but in reality, you're still using the code before the change. so you'll never know. and your mental image of reality has distanced itself a litt
<wpwrak>
le more from objective reality.
<kristianpaul>
bugs, yes that why i still using the clean_all.sh :-)
<wpwrak>
heh :)
<wpwrak>
there's a "clean" target in synthesis/Makefile.xst that looks suitably radical
<wpwrak>
yes ! it built
<xiangfu>
wpwrak, so there are three place needs cleanup: the softusb-input, the build_bitstream.sh and the script.git(the output style)
<wpwrak>
semi-incremental build. 8:45 :)
<xiangfu>
wpwrak, it needs about 45 mins in my computer.
* kristianpaul
not alone
<xiangfu>
wpwrak, compile whole bitstream and flickernoise needs about ~1 hour.
<wpwrak>
build_bios.sh (or something it calls), build_bitstream.sh (or something it calls), and the makefiles for the output style. i think scripts.git don't have anything to do with it
<wpwrak>
oh, that's a very reduced soc.fpg i'm building. the only peripheral is USB
<wpwrak>
let's see if it boots
<wpwrak>
yeah
<wpwrak>
now, the fun part. let's see if the debug signal is being emitted :)
<xiangfu>
wpwrak, ok. I wills tart with build_bios.sh.
<xiangfu>
wpwrak, ( change softusb/main.c and run make (without making libhal) it'll never know.) <-- about this. just checkout. didn't find any problem with softusb.
<wpwrak>
the following test should work: 1) run build_bios 2) edit softusb/main.c, e.g., change the banner message. 3) make 4) run build_bios again 5) flash the new bios. 6) now, it should still show the old banner
<wpwrak>
to make it work, make -C software/bios clean && ./build_bios.sh
<wpwrak>
about 5), the one in software/bios/bios.bin
<xiangfu>
about 3) run make under softusb/ right?
<wpwrak>
yes
<xiangfu>
wpwrak, I will try to fix this first. :)
<wpwrak>
have you been able to reproduce it ?
<xiangfu>
doing that now.
antgreen joined #milkymist
<xiangfu>
yes. I can reproduce that. (and I use the m1nor to reflash bios)
<wpwrak>
perfect ;-)
<wpwrak>
i don;t know if you even need the "make" in softusb. maybe it happens without it, too
<xiangfu>
wpwrak, there are even more depends problem in softusb-input. :)
<wpwrak>
hmm, i think i can clean up all the scope/LA debugging stuff quite a bit if i just route signals to J21 and pick them up there with some nice connector and a reasonable cable
antgreen joined #milkymist
antgreen joined #milkymist
aw_ joined #milkymist
aw joined #milkymist
mumptai joined #milkymist
mumptai joined #milkymist
<stekern>
FWIW, ISE P&R supports multithreading, command line switch; -mt 4
wolfspraul joined #milkymist
mumptai joined #milkymist
<xiangfu>
stekern, thanks.
isa joined #milkymist
<xiangfu>
stekern, will try to enable this next build :)
kristianpaul joined #milkymist
mumptai joined #milkymist
lekernel__ joined #milkymist
Martoni joined #milkymist
nightlybuild joined #milkymist
<wpwrak>
stekern: aaah, nice. thanks ! let's see how many years of my life it'll save ...
<wpwrak>
hmm, is there a "standard" makefile variable for things like -j ?
<xiangfu>
there are : .NOTPARALLEL
<wpwrak>
"This current release of ISE limits the number of cores used by the Placer to 2. Setting -mt to 2." ;-(
<xiangfu>
13.2?
<wpwrak>
13.3
<wpwrak>
NOTPARALLEL sounds like the opposite :)
<xiangfu>
yes.
<xiangfu>
there is on opposite for -j :)
<xiangfu>
s/on/only
azonenberg joined #milkymist
<wpwrak>
hmm, seems to be just as slow as before :-(
<wpwrak>
with -mt 4 on map and par: real 10m39.300s user 11m35.040s
<stekern>
maybe they just added that command line switch to shut up users complaining about no parallel par support ;)
r33p joined #milkymist
mumptai joined #milkymist
Martoni joined #milkymist
<lekernel__>
yes, multithread map/par is lousy
<wpwrak>
without -mt 4: real 10m54.634s user 10m48.300s
<wpwrak>
stekern: your theory seems quite plausible :)
<GitHub40>
[milkymist] sbourdeauducq pushed 2 new commits to master: http://git.io/o4FzUA
<GitHub40>
[milkymist/master] connect the dependency between softusb and libhal, add libs dependency to bios - Xiangfu Liu
<lekernel>
better than gnuplot imho and directly accessible from python
<wpwrak>
hmm, don't think i tried it. i'm reasonably familiar with the gnuplot language, so i don't mind using it
<wpwrak>
a bit annoying that verilog doesn't treat (a, b, c, ) as equivalent to (a, b, c). one more thing to learn to copy from C :)
rejon joined #milkymist
<wpwrak>
a verilog question: i tried to connect rx_pending to an i/o pin. my first attempt was to use a new net name in common.ucf, then pass it down the hierarchy into softusb_sie.v, where i "exported" rx_pending. this gave me a warning because i had re-declated rx_pending (as port vs. the previous register), but it worked
<wpwrak>
next, i tried to leave everything in its original state but declared the pin as NET "usb/sie/rx_pending" LOC = K16;
<wpwrak>
this got me a warning that it couldn't be done because "those design objects do not contain or drive any instances of the correct type."
<wpwrak>
and indeed, this one doesn't work
<wpwrak>
i think the path i used is correct. so what would be a clean way for making such a "tap" ? can i just share the output of the existing register or do i have to introduce a register, explicitly assign to it, etc. ?
<wpwrak>
(which may change the timing)
antgreen joined #milkymist
<lekernel>
I don't think you can connect internal nets to I/O pins with such an UCF constraint
<lekernel>
you have to propagate the signal into the hierarchy up to system.v
<kristianpaul>
indeed, and the propagate fun begin...
<lekernel>
maybe you can hack it by instantiating an OBUF, but I have not tried
<kristianpaul>
there is not JTAG tap controler or such?
<kristianpaul>
let see..
<wpwrak>
mmh. propagating sounds messy.
<wpwrak>
let's see if i can "clone" it into a wire
<lekernel>
you can define a new output x and use "assign x = rx_pending;"
<lekernel>
or try the OBUF hack with something along the lines of OBUF foo(.I(rx_pending)); and the UCF constraint you tried earlier
<wpwrak>
in terms of changes, the two seem equivalent ?
<wpwrak>
lets try assign ...
<wpwrak>
assign in system.v: "Signal <rx_pending> is used but never assigned." (assign dbg = usb.sie.rx_pending;)
<wpwrak>
i wonder if it would tell me if i mistyped the name. or maybe that's just a warning ?
<wpwrak>
let's see
<wpwrak>
no, it does tell
<wpwrak>
assign, version 2: assign in softusb_sie.v, pick it out from there from .ucf
<stekern>
wpwrak: iirc ise does not want to understand such constructs
<stekern>
usb.sie.rx_pending, that is
<stekern>
simulation tools usually does (at least modelsim and icarus)
<wpwrak>
my verilog book claims they're perfectly valid
<wpwrak>
and even xilinx documentation says .ucf is fine with pa/th/s
<stekern>
ise obviously doesn't always play by the books :)
<wpwrak>
sigh
<stekern>
for pin mappings? pa/th/s does work for timing constraints etc
<wpwrak>
now i put assign dbg = ...; into softusb_sie.v: NET "usb/sie/dbg" not found.
<wpwrak>
let's try that OBUF hack
<wpwrak>
stekern: i guess all constraints are the same, no ? syntax is gives as NET "full name" constraint;
<wpwrak>
same error, NET "usb/sie/dbg" not found
<stekern>
yes, syntax is the same, but allowing to pin map signals not present in the top level module is not something I would expect to work
<wpwrak>
why not ? it's just a net name
<wpwrak>
net is net, no ? i mean, the whole build is on the whole design too. no hierarchical "linking", where nets could indeed be elimitated
<stekern>
yes, I don't think about it as technical impossible
cocoadaemon joined #milkymist
<stekern>
apart from debug purposes I wouldn't want to do it neither
<wpwrak>
hmm, all those "warnings" about fairly serious problems suggest that verilog, or at least xilinx's implementation of it, doesn't exactly share python's obsessive-compulsive concern for neatness :)
<wpwrak>
fun fact: NET "usb/sie/dbg" ... causes an error because it can't find the object
<stekern>
wpwrak: that's what VHDL is for... :)
<wpwrak>
NET "usb/sie/rx_pending", where rx_pending is declared one line above the "dbg", does complain about mismatched type
<wpwrak>
so it seems whether it can find it or not depends entirely on the purpose - if it's to produce an error, it can find it with disdainful ease. if it's to make things work, no way.
<wpwrak>
let's try a variant ...
<stekern>
is dbg a reg or wire?
<wpwrak>
a wire. with a reg, it complains that it's the wrong type.
<kristianpaul>
nah thats not a language problem, just all junk of non-free software that claim to works..
<wpwrak>
with a wire, it doesn't find it.
<kristianpaul>
you are doing the assign in the top module right?
<kristianpaul>
i mean
<wpwrak>
i tried tht. didn't work. then i sent it to the bottom. doesn't work either.
<kristianpaul>
you need to propagate from the usb softcore the the top
<wpwrak>
that's what i'm trying to avoid :)
<kristianpaul>
sure in the botton will not work i think
<kristianpaul>
wpwrak: you cant !! at least with assigns..
<wpwrak>
i don't want to have to "bubble" things through intermediate layers. it's for debugging. so changing a lot of files is BAD.
<kristianpaul>
but only way, at least that OBUF thing works..
<wpwrak>
i tried OBUF at the bottom but that didn't work either
<kristianpaul>
so no choice
<wpwrak>
haven't tried OBUF at the top, though
<kristianpaul>
"you can include test point in all designs is just matter of used to it"
<wpwrak>
mmh ?
<kristianpaul>
test points in the top and the route the the core you need
<kristianpaul>
you dont need to change lots of files, because you already include then (testpoints) ;-)
<stekern>
but it's just insane that mod1.mod2.signal doesn't work
<kristianpaul>
indeed
<stekern>
in that sense alteras signal probe is "good", it lets you probe signals wherever
<wpwrak>
what does OBUF exactly do ? declare an output port on the current module ? create a global output port ?
<wpwrak>
stekern: sounds just like what i'm looking for :)
* kristianpaul
looks lekernel
<wpwrak>
stekern: J21 could be an excellent debug port if it wasn't too hard to route signals there
<wpwrak>
using J21 wuold have numerous advantages over attaching probes to various points in the system, including: 1) easy access, 2) possibility to make an even more convenient adapter board, 3) short ground loop (ringing), 4) no contamination of original signal by probe
<wpwrak>
(adapter board) e.g., with small coaxial connectors to attach a scope. or a header for LA probes
<kristianpaul>
anyway if we want something portable, model some Test Points in verilog is not bad idea at all..
<kristianpaul>
or use chipscope.. :-S
<wpwrak>
what's also unpleasant about "bubbling up" is that each change, if made at the end of the parameter list, does in fact affect two lines: the line where the probe signal is added and the line above it, which gets a comma
<kristianpaul>
yeap..
<wpwrak>
OBUF doesn't create a global port. just tried that.
<kristianpaul>
..
<wpwrak>
sigh. so bubble it is. let's do it at least without "warnings".
<kristianpaul>
but wait IFDEF and such may help, so you can use the define tap
<kristianpaul>
zero warnings? :-)
<kristianpaul>
s/tap/enable_tap
<wpwrak>
yeah, sure. make the code REALLY messy ;-)
<kristianpaul>
i dont said the contrary :-)
<stekern>
wpwrak: put your "bubble" topmost, then you don't need the extra comma at least
<wpwrak>
stekern: ugly :) like ", my_stuff" would be. it's hard to be a perfectionist ...
<stekern>
hehe, yeah
<wpwrak>
lekernel: this time, i used the LA of the mighty rigol to monitor rx_pending. D15 shows that it can be on for a pretty long time. up to about 500 ns.
<wpwrak>
and that's just the time until we grab the last byte of the packet. without any processing.
<wpwrak>
so this eats already about 200 ns from the 540-1300 ns time budget until the ACK timeout.
<wpwrak>
540 ns if we aim for full compliance, even if hubs are added
<wpwrak>
1300 ns if we just want to survive in a best-case scenario
<wpwrak>
there may also be a rx_pending vs. EOP race. e.g., what if the following sequence of events happens ? 1) test for RX. 2) byte finishes and rx_pending is set. 3) eop is detected. 4) test for EOP. we may just be slow enough that this could happen. haven't checked yet if hw suppresses signaling of EOP while rx_pending is set, though
<wpwrak>
ok, bubbled. now the diagnostics are more friendly
<wpwrak>
this is with a duration trigger: trigger only if rx_pending was high for > 510 ns.
<wpwrak>
this happens irregularly, at about 1 Hz long-term average
<wpwrak>
or maybe 2 Hz
<wpwrak>
what's interesting here is that rx_pending rises quite early in the last bit. this suggests that the sample clock may indeed be a little early
juliusb joined #milkymist
nightlybuild1 left #milkymist
kilae joined #milkymist
<lekernel>
wpwrak: an alternative to "bubbling" is editing the FPGA manually
<Artyom>
kristianpaul: Do I understan right that MM executes program from nor-flash? But keeps all the data (program variables) in SDRAM? Isn't it slow to execute program from slow flash-memory?
<Artyom>
(I watched system.v in rtl directory and linker.ld in bios directory)
<Artyom>
Or processor cache works very efficient in this case?
<kristianpaul>
very good question
<kristianpaul>
i was sure just few programs we're executed from flash, bios for example
<kristianpaul>
Artyom: you menan for the tdc-core?
<Artyom>
no, I wrote about MM bios
<Artyom>
You gave the answer :)
<Artyom>
in demo directory, according to the linker.ld program is executed from RAM
<Artyom>
SDRAM
<kristianpaul>
yes loaded to ram
<Artyom>
But then I would like to ask: How is demo program can be run after booting bios? With the flterm?
<kristianpaul>
yes
<kristianpaul>
flterm load it to bios and bios load it to ram and executed it i think
<kristianpaul>
flterm is menthod for uart, there are also other methods like boot from network (tftp boot) and memory cards
<Artyom>
runnig SDRAM becomes the most important task... ;)
<Artyom>
thanks for your help Kristianpaul :) time to sleep for me. bye!
<kristianpaul>
you could, flterm all you need
<kristianpaul>
ah well sdram support too ;-)
<kristianpaul>
but that i think was solved in milkymist casrlos port
<kristianpaul>
and load bios in a block-ram like in the tdc-core or papilio board fork