<rjo>
_florent_: lots of changes to misoc! looks good. did you and sb0 agree on a policy on what can and can not go into misoc?
<rjo>
he was worried about it becoming a rotting opencores-migen ;) i would not be so worried about that if there were tests and ci.
<_florent_>
hi rjo
<_florent_>
there is no real policy, we just have to try that it does not becomes like opencores
<_florent_>
but the cores I added have lots of tests
<rjo>
but really great work!
<_florent_>
we should have similar test to the already existing modules that are not well tested (in simulation)
<rjo>
_florent_: it would be cool if they were build and run on each commit.
<rjo>
exactly. but someone needs to run them on a regular basis.
<_florent_>
yes I'm not very familiar with travis-ci but yes it would be really cool
<_florent_>
yes, I've tried to add auto-checks in the test, so it should not be that hard to adapt if we use something to automate tests
<rjo>
so your testbenches are actually functional unittests. that is great. if they were wrapped as unittests (like those that i did in migen) you would get tools to collect and run them for you.
<rjo>
and as a second step we can have the full bitstream generation as a test. for all xilinx targets in targets/*.py at least.
<_florent_>
OK, I will look at what you've done :)
<rjo>
no rush. but if you get a few unittests up and running i'd be happy to do the travis-ci and xilinx toolchain stuff.
<_florent_>
cool! (I'm not familiar with that)
<_florent_>
I'll try to make some unittests next week
sb0__ has joined #m-labs
<sb0__>
_florent_, hi
<_florent_>
hi
<sb0__>
when I tried running the latest soc on the kc705 yesterday it would not boot
<sb0__>
printed a newline on the uart and then froze
<sb0__>
have you fixed that?
<sb0__>
by the way we found the flashing problem
<_florent_>
hmmm OK, I add the same issue with the de0nano, I have access to the KC705 and Mixxeo today, I'm going to test that in the weekend
<sb0__>
executive summary is it was hardware jtag data corruption, and we fixed it
<sb0__>
it seems to come from your latest changes, it booted right after the liteeth merge
<_florent_>
OK I'm going to fix that
<sb0__>
just flashed the latest git - still the same boot bug
<sb0__>
reverting ...
<_florent_>
was it working with ppro?
<sb0__>
not tried, we have enough trouble with the kc705 right now
<_florent_>
I'm going to try now and compare the verilog
<_florent_>
should be fixed in 1 hour
<sb0__>
rjo, shall we merge nist-dds-ttl-tester into artiq?
<sb0__>
there would be soc/software/runtime and soc/software/dds-ttl-tester
<sb0__>
and make it compatible with the rtio-dds
<rjo>
sb0__: isn't it mostly there already?
<rjo>
ah you mean just the runtime?
<sb0__>
yeah, the dds core and soc design are there. the C test software isn't.
<rjo>
ok. we can also start putting the hardware there.
<sb0__>
I propose we make the C test software work with whatever the artiq soc design is, and put it into artiq/soc/software/dds-ttl-tester
<sb0__>
or just 'tester' as we may want to extend it to other devices
<rjo>
_florent_, sb0__: (re current misoc shuffling) it all misoc/migen works fine on pipistrello btw
<rjo>
sb0__: or add a command-line mode to the current full-artiq runtime
<rjo>
then you don't have to reflash stuff
<sb0__>
you can flterm-load it
<sb0__>
you need the uart anyway
<rjo>
yeah. still needs compiling, loading etc.
<sb0__>
ok, what about having the runtime drop into tester mode when it receives a certain character on the uart during boot?
<_florent_>
sb0: with bios in ROM (-Ot with_rom True) it works fine on the KC705
<rjo>
sb0__: perfect.
<GitHub39>
[migen] enjoy-digital pushed 1 new commit to master: http://git.io/xZeC
<GitHub39>
migen/master b53e2b0 Florent Kermarrec: fix xilinx/programmer with Vivado
<rjo>
i am about to hack this fire alarm reporting system and modify it to have nimoy say "live long and prosper" instead of that dumb message...
<_florent_>
rjo: on the pipistrello, the BIOS is in SPIFlash?
<rjo>
almost. the number of dummy cycles seems to be of by one.
<sb0__>
_florent_, on the kc705 with spi flash, misoc a3909bb5e2c21b37f822f1738ccf8c4bcbf387a5 + migen ba26a400e3c43e3c32d0c13c6487ed994bd0e691 are good
<_florent_>
ok thanks, going to compare verilog
<rjo>
hmm. no. the bios just spits out 0xff.
<_florent_>
verilog is OK, it's an issue with mem.h and regions.ld (ROM_BASE is 0x00000000)
<_florent_>
I'm fixing that
<sb0__>
did you also change the csr maps? runtime binaries built with the current code do not work with the older code
<_florent_>
yes I've reserved csr 0-->16 for the SDRAMSoC
<_florent_>
(with cache_size in wishbone2lasmi, 10 was not enough)
<rjo>
good thing is that i can run about ten s6lx45 bitstream compiles before a single kx705 compile completes ;)
<GitHub24>
[misoc] enjoy-digital pushed 1 new commit to master: http://git.io/xZmM
<GitHub24>
misoc/master 165a5b6 Florent Kermarrec: soc: use self.cpu_reset_address as rom mem_map address and increase default bios size to 0xa000
<_florent_>
it should be OK now, verilog is identical (except csr mapping), mem.h and regions.ld are OK
<sb0__>
i really can't get the runtime to work anymore...
<sb0__>
_florent_, have you tested this on hardware including flterm load?
<rjo>
works fine with lasmicon, s6ddrphy and with_l2=True
<sb0>
rjo, I guess that what _florent_ means is that misoc never supported minicon with sdrams larger than the wishbone bus
<rjo>
the sdram is 16 bit data-width
<sb0>
DDR plus 2x clock makes it 64
<rjo>
ah. ok. understood.
<sb0>
the proper thing to do is to store the full 64-bit word, and serve it to the 32-bit wishbone (without re-accessing the dram) when it makes a burst access.
<sb0>
I was planning to have ysionneau look into this, but then there were controllers etc. to write ...
<rjo>
;)
<rjo>
ok. a few patches coming your way.
<rjo>
now there is only the weird fact that xc3sprog does not work with the pipistrello...
<sb0>
what is going on with the sdram cs_n btw?
<sb0>
on your board
<rjo>
tied low.
<rjo>
want me to remove it?
<rjo>
and rzq?
<_florent_>
going to bed... if you find others issues with the changes I made, please post it on IRC, I'll read the log tomorrow
<_florent_>
bye
<sb0>
why does it have a fpga pin associated with it then?
_florent_ has quit [Quit: Leaving]
<sb0>
did they connect the fpga pin with cs_n and then tie both low?
<rjo>
sb0: not not connected to fpga and tied low on dram chip.
<rjo>
i guess they had it in the ucf because of mcb
<rjo>
but i am happy to dump it.
<rjo>
an old artiq runtime from november that i accidentally flashed stars but complains about uncaught exception ID=2. ;)
<rjo>
starts
<sb0>
or did you need a dummy pin to make the PHY not bomb? in that case it would be better to fix the PHY...
* sb0
loves talking about bombs while on airport wifi
<sb0>
ah, yeah let's dump it then
<rjo>
ha. non-ssl irc over public wlan?
<rjo>
no. no dummy pin needed for s6ddrphy and sdramphy. it is commented out.
<rjo>
want me to send patch or are you going to?
<sb0>
yup ;)
<rjo>
_florent_: ack. thanks.
<rjo>
sb0: want apples or bananas? yes.
<rjo>
i also hate it if they add pullups/downs in the ucf _and_ on the pcb.
<sb0>
rjo, let me just remove them
<rjo>
too late. sent a patch to the ML.
<rjo>
for some weird reason that i did not figure out, 80MHz sysclk does not jive well with the 115200 uart. needs about 120000 baud to become readable.
<GitHub44>
[migen] sbourdeauducq pushed 3 new commits to master: http://git.io/xnVO
<GitHub44>
migen/master 75290aa Robert Jordens: pipistrello: switch back to xc3sprog and fast (papilio) speed