<rjo>
but it might be the bitstream. i messed with that as well.
<whitequark>
rjo: how does the brokenness look?
<rjo>
no output on serial port
<whitequark>
it is very unlikely that that would be the result of a bios miscompilation
<whitequark>
the banner print is one of the first things it does and there is little that can go wrong before that
<rjo>
i cab imagine a bunch of things going wrong before that!
<whitequark>
well, not inside the BIOS image, i mean.
<rjo>
but it is likely the bistream in this particular case.
<whitequark>
I'm not responsible for broken bitstream :p
<whitequark>
ok, let's fix... all of these bugs
<rjo>
that can change.
<whitequark>
rjo: mhm?
<rjo>
i presume you will start messing with the bitstream at some point.
<whitequark>
sure
<whitequark>
... i should get an i7 and overclock it to 4GHz or something. xst is aggravating
<rjo>
yeah. needs a different development style.
<whitequark>
i have this R134a based refrigerator i assembled for some reason. could put it to a good use.
<whitequark>
how high can you overclock a cpu that's at -20?
<rjo>
not much.
<whitequark>
also have a 20K cold head.
<whitequark>
but it's only about 4W at that temp.
<rjo>
i would guess 20% at most.
<rjo>
you can parallelize trian-and-error compilations with ise or vivado pretty well. but you have to remember what they are.
<rjo>
sb0: at some point i wanted to make ".add_constant()
<rjo>
" look more like a CSR
<rjo>
is that useful?
<sb0>
you could push some of the constants into the cores I guess
<rjo>
basically CSRConstant. Is a Signal(), can be used in FHDL, becomes a constant in csr.h
<sb0>
self.some_value = ExportedConstant(42)
<rjo>
self._fine_ts_width = CSRConstant(8)
<sb0>
a Signal()? how?
<sb0>
yes
<sb0>
you can use numerical values in FHDL
<sb0>
they don't need to be Signal
<rjo>
ok. even better. then just a "Value()".
<sb0>
the main issue is when you try to slice them
<sb0>
and it seems you need ruby to monkey-patch integer operations
<rjo>
is a Signal() to wasteful?
<sb0>
create a Signal() and then assign it a constant?
<sb0>
it will clutter the verilog output, but xst/vivado should generate the same netlist I think
<rjo>
yes. which do you prefer? slicing would be nice.
<sb0>
yes, but that's a general problem that is not limited to those constants that are exported
<sb0>
a way to fix it is to encapsulate all ints
<sb0>
but it clutters the syntax, e.g. x.eq(x + c(1))
<sb0>
though that may be a lesser evil than the slice problems
<sb0>
also easy to report errors when c() is omitted
<rjo>
hmm. are we talking about the same thing?
<rjo>
afaict CSRConstant would need encapsulation anyway
<sb0>
no, two things
<rjo>
because it needs a name etc to show up in the header
<sb0>
1) CSRConstant, that exports constants to csr.h
<rjo>
you are talking about making python integers more fhdl-amenable.
<sb0>
2) C() that allows slicing integers
<rjo>
ack. i'll look at 1)
<sb0>
you were proposing to workaround for the lack of #2, a general problem with migen, in the specific case of #1
<rjo>
no. just 1).
<rjo>
2) is pretty orthogonal to 1) afaict.
<sb0>
yes
<sb0>
so, slicing the value of a CSRConstant in FHDL will still break. no workaround with Signal().
<rjo>
why?
<sb0>
because all those workarounds have to be cleared up if/when C() or similar is introduced
<rjo>
ah. "will break in the future". yes. is that ok?
<sb0>
do you have the need to slice those constants right now?
<rjo>
not specifically. but i can see people wanting to flen() etc them.
<sb0>
flen(int) is fine
<sb0>
(which is why it's flen() and not len())
<rjo>
but it depends on the value, not the "type"
<sb0>
I meant: flen(some int)
<rjo>
ok. maybe a bad example.
<sb0>
another way to fix the slice problem would be to introduce a slice() function instead of using the python slice syntax
<sb0>
fslice
<rjo>
ack. i'll make CSRConstant expose a real python int as its .value.
<rjo>
did i not write fslice()?
<sb0>
as slices are used less often than int constants, I guess the overall amount of syntax clutter is less
<rjo>
there is fslice()
<sb0>
ok, then deprecate []?
<rjo>
[] is very sweet syntactical sugar compared to fslice().
<sb0>
but it breaks on ints.
<rjo>
even if it is not all that coherent.
<rjo>
yes. so use fslice() if you can also cope with an int, and [] if you expect a Value()
<sb0>
sounds a bit obscure ...
<rjo>
it would not make a purist smile. true.
<sb0>
also, you can be sure that someone will write a core that uses [], and then someone else will put an integer into it later
<sb0>
or the same person a few years later
<rjo>
yep. i guess i could cite a line from "import this" that anoints such an implementation ;)
<rjo>
imho it would be better to restrict the use of unencapsulated ints (by convention or by code) to some notion of "local use" where it is obvious that you can not [] them. and then only allow C() to be passed around.
<sb0>
how do you define "passed around"?
<sb0>
function arguments?
<rjo>
and and self attributes.
<sb0>
how do you write general code that can detect things like f({"a": 1}) vs. f({"a": C(1)}) ?
<sb0>
blocking "self.x = 1" would also be a problem
<rjo>
yes. Modules would need to define their signature.
<sb0>
modules have legitimate uses for int attributes
<rjo>
as part of their public FHDL interface?
<sb0>
public interface in general
<rjo>
i am not saying enforcing a module signature is a good or beautiful idea. but afaict it would be the only way to keep []-slicing and ints as valid operands.
<rjo>
well you would have to define a FHDL interface that Modules expose that only contains Signal(), Record(), Constant() etc things.
<whitequark>
I think signature enforcement is good
<whitequark>
you could return a proxy object from `params` or something
<whitequark>
mod.params.a = 1
<rjo>
but anyway. that fear of yours where somebody passes an into into a module that expects a Value() already works for passing a Record.
<sb0>
what if a Module exposes a submodule (or any other class really) that contains Signals?
<sb0>
or a module that exposes another class that exposes another class that contains signals
<rjo>
i prefer the flexibility of migen without having to write up interfaces all the time.
<rjo>
submodules would be part of the interface.
<rjo>
i think.
<sb0>
yes, Record should probably be more signal-like
<sb0>
that's something that's fixable I think, unlike int slicing that python won't allow
<rjo>
damn. i broke the gateware but have no idea how. head is broken on pipistrello. ae3a52c works, e95b06e doesn't.
<sb0>
is the pll locking?
<rjo>
would the rtio-pll not locking prevent the bios from booting?
<rjo>
sys_clk runs from the other pll.
<sb0>
does it have STARTUP_WAIT?
<rjo>
STARTUP_WAIT="FALSE"
<sb0>
for the DCM, not the PLL
<rjo>
aeh
<sb0>
i_RST=ResetSignal() on the DCM looks a bit suspicious
<rjo>
that worked fine so far.
<rjo>
what is wrong about it?
<sb0>
maybe there's nothing wrong, but why is it necessary?
<rjo>
do PLLs have STARTUP_WAIT? can't find it in ug382
<sb0>
they do on 7 series
<sb0>
is that new?
<rjo>
that i_RST on the DCM. it is fed by the other pll. does it not need to be held in reset while the first pll is not locked?
<sb0>
oh, you're cascading those things...
<sb0>
why not connect the DCM directly to the clock pin? is PAR failing?
<sb0>
"A cost table is nothing more than a random seed to placement."
<rjo>
"This option is available for Spartan®-3, Spartan-3A, Spartan-3E, and Virtex®-4
<rjo>
devices only"
<rjo>
and given that "default is 1", i would expect much more reproducibility.
<sb0>
Xilinx sometimes receive comments such as "All I did was change the net name and now my design does not meet timing"
<rjo>
sure. i see that all the time.
<sb0>
same :)
<rjo>
but the placer cost table can't be it.
<sb0>
that AR also lists S6
<rjo>
ah.
<rjo>
it is for MAP as well.
<rjo>
but then, "default is 1" implies it is not the only randomnes factor.
<rjo>
sb0: btw: i tried ppp on the new uart: no real change. but i suspect it might just be congestion and lack of flow control.
<rjo>
which i think you already suspected as well.
<sb0>
I think there are two bugs
<sb0>
congestion plus something else
<sb0>
even with a slow data rate on TCP it breaks
<rjo>
i did not test that. ping -f with size < ~180 bytes was fine, above that it got bad very quickly.
<sb0>
TCP crawls at one packet every 10 seconds or something like that
<rjo>
yeah. maybe rts/cts would be cool. it is all wired up. would just need hooking up to the fifo.
<rjo>
damn xilinx. i tolerated all the insults of ise when piecing together that clock cascade and made so many sacrifices to the xst/map/par gods. and no it won't make rain.
<rjo>
ah well. need sleep. see y'all tomorrow.
<sb0>
gn8
<sb0>
and yes, this is my general experience with clocking spartan-6s as well...
travis-ci has joined #m-labs
<travis-ci>
m-labs/artiq#343 (master - 1809a70 : Robert Jordens): The build has errored.
<whitequark>
i guess it means generating one instruction per global address load instead of three, but this has to be done consistently--why do loads like these use a 16-bit relocation and one instruction, but e.g. plain address calculations use three instructions and gotoffhi/gotofflo
<whitequark>
this makes no sense
<whitequark>
sb0: does the bios boot now?
<sb0>
or1k-linux-ld: bios.elf section `.rodata' will not fit in region `rom'
<sb0>
or1k-linux-ld: region `rom' overflowed by 908 bytes
<sb0>
can probably increase, just make sure it doesn't bump into anything else
<sb0>
otherwise, yes, sdram.c no longer crashes clang
<whitequark>
well, that much I know, I fixed it
<whitequark>
ohhhhhhh
<whitequark>
no, it won't work
<whitequark>
I completely misunderstood the point of that relocation.
<whitequark>
gotoff(x) is an offset from GOT itself to x, whereas got(x) is an offset to the position of x inside GOT
<whitequark>
so, the first is used in a pc-relative calculation of an address you already know, whereas the second is used in calculating the address of a pointer you *don't* know
<whitequark>
it also tells the linker it should actually put the GOT entry there, etc
<whitequark>
ok, what is the next thing that is broken?
<sb0>
mh, why do I get a merge after pulling llvm
<whitequark>
rebased it
<sb0>
I didn't modify anything
<sb0>
ah
<sb0>
the solution is "git reset --hard origin/master", correct?
<whitequark>
yes
<sb0>
flashing bios. hopefully that won't bork my board ...
<sb0>
works :)
<whitequark>
amazing
<whitequark>
clang with -fPIC, right?
<sb0>
yes
<sb0>
runtime is still crashing. one major difference is that I have lwIP
<whitequark>
how does it crash?
<sb0>
"ARTIQ runtime bui" and freezes
<sb0>
at boot
<whitequark>
sounds like an interrupt-related problem
<sb0>
if you want to try lwIP, you can get the ppp branch
<whitequark>
ok
<sb0>
or crashing while transmitting on UART
<whitequark>
that's unlikely, it works well on pipistrello
<sb0>
i.e. the banner gets put in the UART buffer, then slowly sent out while init continues and at some point crashes the CPU to the point that the UART ISR breaks
<cr1901_modern>
I noticed mibuild has an fpgalink programmer now... is that the better alternative to x3scprog and friends?
<sb0>
my favorite vacuum shop has changed its slogan. its no longer "the best for you love you forever", but "scinence (sic) initiates quality and sincerity creates a brand"
<cr1901_modern>
English is terrible.
<rjo>
i like how you can read it in different ways.
<rjo>
whitequark, sb0: current breakage status? ok to work on top of misoc-master? which llvm/binutils?
<rjo>
sb0: what's the rationale to LCK_cycle:6 per default in ise.py?
<sb0>
upstream binutils + llvm from whitequark's repos + clang-or1k + llvmlite from whitequark's repos (backport3.5 branch) is fine
<rjo>
in my exegesis of the xilinx scriptures that globally waits for all dcm/pll to lock irrespective of STARTUP_WAIT.
<sb0>
the only problem I've seen so far is the BIOS CRC check fails, but it's minor
<rjo>
now with 19 (i/o)serdes running at 500MHz this guy is getting a bit warm...
<rjo>
isn't llvm supposed to be fast (-er than gcc)?
<rjo>
that llvm tarball works (apart from the crc thing).
<rjo>
sb0: i'll have pipistrello put a 4x serdes on pmt0/1 and ttl0/1 and a 8x serdes on ttl2, will leave the higher ttls on a simple to try to save power.
<GitHub44>
[artiq] jordens pushed 3 new commits to master: http://git.io/vY9OP
<GitHub44>
artiq/master 9dfbf07 Robert Jordens: pipistrello: use 4x serdes for rtio ttl...
<GitHub44>
artiq/master fb339d2 Robert Jordens: serdes_s6: no need to reset
<GitHub44>
artiq/master 67715f0 Robert Jordens: pipistrello: only put serdes on the lower ttls...
<cr1901_modern>
sb0: Did you get any patches/emails from me? sendmail is being a POS
<cr1901_modern>
Nevermind... I broke postfix, so no you didn't
cr1901_modern has left #m-labs [#m-labs]
<whitequark>
rjo: yes, tarballs should be ok
cr1901_modern has joined #m-labs
<rjo>
whitequark: why is llvm so slow?
<whitequark>
rjo: huh?
<whitequark>
in what use case?
<rjo>
bios and runtime take ~3 times as long with llvm compared to gcc.
<rjo>
maybe twice as long.
<rjo>
but significantly longer.
<rjo>
iirc llvm was very proud of being fast.
<whitequark>
it is; building llvm itself, for example, used to be 2-3 times faster than gcc (then gcc caught up circa 4.9)
<whitequark>
I'm guessing some poor choices in the backen
<whitequark>
d
<whitequark>
ohhh wait
<whitequark>
no
<whitequark>
it's built with -DLLVM_ENABLE_ASSERTIONS=ON
<whitequark>
and I'm fairly sure -O1
<rjo>
that needs a remove-before-flight tag if we benchmark kernel compilation or "release".
<whitequark>
yes
<whitequark>
the former is kept currently because I would like the backend bugs to not be silently swallowed
<whitequark>
the latter, because -O3 or even -O4 takes a looooot of time
<rjo>
i kinda liked -Os for embedded systems that don't have such a perfectly optimized icache path. also that made the bios fit onto small boards.
<whitequark>
no, I mean LLVM itself is built with -O1
<whitequark>
which is why it's slow
<whitequark>
the code is still built with -Os; it's bloated right now because of -fPIC
<whitequark>
that reminds me.
* whitequark
hides from sb0
<whitequark>
we don't *actually* need -fPIC in libbase and friends. i thought these would be built into kernels. but then sb0 said that a kernel .so would just consist of the sole kernel object file, linked as shared object
<whitequark>
which makes sense
<whitequark>
and if that's the case, all the support libs are at known locations already. so no -fPIC needed.
<whitequark>
thus, yo'll get back your more compact code
<rjo>
whitequark: ack.
<whitequark>
I guess it is good that we debugged -fPIC anyway, since it will still be used for kernels themselves
<whitequark>
and just as well, we now know that it's safe to use if needed.