sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
<GitHub144> [sinara] gkasprow pushed 1 new commit to master: https://github.com/m-labs/sinara/commit/377e6033c46612b8265bcb010da421e43584be1a
<GitHub144> sinara/master 377e603 Greg: fixed power sequencing
<FelixVi2> sb0, is there tests that are run for papilio targets? I can't seem to figure out why the bios appears to be too large
<FelixVi2> it tells me it overflowed by 1156 bytes
<FelixVi2> sb0, from what I can see it means that the papilio sdram is too small to hold the bios - is that assumption correct?
<FelixVi2> a build for pipistrello is going through fine
<FelixVi2> any advice about what to do?
<FelixVi2> sb0, it wasn't sdram but flash causing the problem. I could get it to compile by specifying a larger rom size i.e.
<FelixVi2> self.register_rom(self.spiflash.bus,rom_size=0xb000)
<cr1901_modern> FelixVi2: The llvm targer for lm32 doesn't work, so yes both llvm/gcc compilers are compatible w/ misoc
<FelixVi2> default is 0xa000. Do you think this will work or is this a problem as memory blocks in flash start overlapping?
<cr1901_modern> I don't have the mental bandwidth tonight for the other q's :(
<FelixVi2> no worries, I'm making some progress
<FelixVi2> looks like everything is working under cygwin
<FelixVi2> I just don't have a good feel for whether I'm breaking stuff as I'm trying to get it to work :)
<FelixVi2> Will try to run it on a papilio tomorrow - unfortunately that's the only board from the target list that I currently have
<FelixVi2> plan will be to migrate to a LX45 with 512Mb SDRAM, so a lot of these issues should go away
<FelixVi2> To get things to work, I applied the python3.6 patch and changed the flash size setting for the bios block - hopefully that doesn't break things
<FelixVi2> will be back tomorrow morning... thanks for the help!
rohitksingh_work has joined #m-labs
<GitHub18> [artiq] sbourdeauducq opened issue #851: searching in log messages https://github.com/m-labs/artiq/issues/851
<GitHub164> [artiq] sbourdeauducq commented on issue #850: It's not built into the scheduler, but you can implement that yourself in the experiment using ARTIQ's [EnumerationValue](http://m-labs.hk/artiq/manual-release-3/core_language_reference.html#artiq.language.environment.EnumerationValue) and Python's [Logger.setLevel](https://docs.python.org/3/library/logging.html#logging.Logger.setLevel). https://github.com/m-labs/artiq/issues/850#issuecomment-345
<GitHub24> [artiq] sbourdeauducq commented on issue #850: It's not built into the scheduler, but you can implement that yourself in the experiment using ARTIQ's [EnumerationValue](http://m-labs.hk/artiq/manual-release-3/core_language_reference.html#artiq.language.environment.EnumerationValue) and Python's [Logger.setLevel](https://docs.python.org/3/library/logging.html#logging.Logger.setLevel). https://github.com/m-labs/artiq/issues/850#issuecomment-34516
<GitHub35> [artiq] sbourdeauducq commented on issue #850: The log level is in ``expid["log_level"]``. It expects an integer with the same conventions as the Python logging module, e.g. ``logging.WARNING``. https://github.com/m-labs/artiq/issues/850#issuecomment-345161806
<GitHub141> [artiq] sbourdeauducq commented on issue #850: And the current ``expid``, if you need that, is ``scheduler.expid``. https://github.com/m-labs/artiq/issues/850#issuecomment-345162065
FabM has joined #m-labs
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh has joined #m-labs
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined #m-labs
rohitksingh1 has joined #m-labs
rohitksingh has quit [Ping timeout: 240 seconds]
rohitksingh1 has quit [Quit: Leaving.]
rohitksingh has joined #m-labs
<GitHub60> [artiq] jbqubit commented on issue #851: I like (1). It's helpful when focusing on a specific logged event type to see both its history and new events of that type as they happen. https://github.com/m-labs/artiq/issues/851#issuecomment-345269156
rohitksingh has quit [Quit: Leaving.]
FabM has quit [Quit: ChatZilla 0.9.93 [Firefox 52.3.0/20170811091919]]
<FelixVi2> Does anybody have insight into the rom issue with papilio? Any hint will be appreciated :)
<FelixVi2> what are the two numbers in --integrated-rom-size arguments?
<rjo> there should be only the size
rohitksingh has joined #m-labs
rohitksingh has quit [Client Quit]
<FelixVi2> the other one appears to be cpu_reset_address
<FelixVi2> I'm writing up an issue with more details
<FelixVi2> When gateware is compiled and one uploads the bitfile, there should be a bios prompt that can be seen via serial, correct?
<rjo> yes.
<FelixVi2> then something must have gotten broken on the way here
<FelixVi2> is it easiest to get help in here or is submitting a new issue on this the preferred way?
<FelixVi2> let me start writing up exactly how I got here, that needs to happen anyways
<FelixVi2> but I think I'm pretty close - it's probably something minor somewhere
<FelixVi2> wait a second - does one need to upload top.bit and a rom image to different memory locations?
<rjo> please add the full code. otherwise this is tedious to reproduce.
<rjo> the spi flash should not be your issue if you are using the integrated rom.
<rjo> yes. bios/rom needs to be after the bitstream in the flash at the correct address.
<FelixVi2> i bet that is the problem
<FelixVi2> should there be an uploader generated based on xc3sprog?
<rjo> yes, or openocd.
<FelixVi2> I can't seem to find it - it's not generated by build_top.bat
<FelixVi2> does it not show up when you use the --no-compile-gateware flag?
<FelixVi2> how do you tell if target uses BIOS execute-in-place?
<rjo> the bios is in misoc*/software/bios/
<rjo> if you don't specify an integrated-rom-size, it expects the bios in the flash and does xip.
<FelixVi2> that bin file need to go to some flash address, right?
<rjo> yes.
<rjo> the spi flash is mapped to 0x0000, i.e. you need to put it at the reset address. the defaults should all be ok. there should not be any code writing you need to do.
<FelixVi2> so, flash boot address is where that goes
<FelixVi2> sorry, this is confusing - default for papilio is registering rom
<FelixVi2> register_rom(self.spiflash.bus)
<FelixVi2> so is this using flash and xip or integrated rom?
<FelixVi2> does integrated rom mean it's using bram? So in this case there'd only be one programming file?
<rjo> flash xip (it says "spiflash")
<rjo> yes. integrated rom is rom integrated into the bitstream (bram). yes
<FelixVi2> so the easiest test would then be to allocate sufficient rom and upload
<FelixVi2> let me try that
mumptai has joined #m-labs
<FelixVi2> rjo, that worked - there's a bios prompt
<FelixVi2> but it says sL5DdSMmkekro Timeout No Boot medium found
<FelixVi2> maybe that's normal - is there any documentation on where to go next?
<FelixVi2> the serialboot command returns timeout
<rjo> the sL5... is the magic to upload your runtime over serial (use flterm.py). otherwise it'll try the flash and there is nothing there.
<rjo> i.e. you are done. could you check whether your issues are still applicable?
<FelixVi2> rjo, both issues are still applicable
<FelixVi2> I'll see if I can fix the Cygwin problem myself
<FelixVi2> the papilio rom size is a minor things that one of you might be able to fix when you push next
<FelixVi2> it's just one character that needs to be changed - if rom size doesn't interact with anything else... I just wasn't too sure
<FelixVi2> rjo, is there some tutorial that allows you to print to console or switch I/O pins on and off?
<FelixVi2> apart from that, I have opened issue for everything I had trouble with and commented on the Python 3.6 support issue for migen. Let me know if anything else I did is useful to know
<cr1901_modern> FelixVi2: What's the cygwin issue again?
<FelixVi2> I'm thinking that adding a flag for the cygwin base path might be the best solution
<FelixVi2> something like --cygwin-dir d:\cygwin64
<FelixVi2> and it just parses that in and flips forward to backward slashes
<cr1901_modern> This is probably a migen error, not a misoc error. And this is probably my fault.
<FelixVi2> no worries, I think it's a simple fix
<FelixVi2> the issue is that if ISE is installed under windows, linux-style paths won't work
<cr1901_modern> Erm, the solution I in general suggest for this is to use cygpath
<FelixVi2> but ISE expects a windows-style path
<cr1901_modern> I know, cygpath can do the reverse
<FelixVi2> oh cool, I didn't know that
<cr1901_modern> Windows to unix path conversion and vice-versa is sufficiently screwed up that I don't recommending a hand rolled solution
<FelixVi2> then it might be even easier than I thought :)
<FelixVi2> do you want to look into it? I'm happy to take a peek myself, but I have little experience and might need some input from you
<cr1901_modern> I'll make a PR for it in Migen (this is a migen issue not misoc)
<FelixVi2> awesome
<FelixVi2> do you have experience creating new targets?
<FelixVi2> I'm looking to add Numato Saturn and Waxwing
<cr1901_modern> https://www.wdj-consulting.com/blog/migen-port.html Article I wrote about 2 months ago
<FelixVi2> awesome, thanks!
<FelixVi2> so these things are really migen related and not misoc
<cr1901_modern> So yes, I could add them, but why don't you try using my article as a guide and try yourself?
<cr1901_modern> correct
<FelixVi2> good to know, I'm learning as we go... :)
<FelixVi2> I'll give it a shot
<FelixVi2> is there any testing involved? I think syntax should be straightforward, but I'm not sure what I should do beyond trying to boot bios
<FelixVi2> or do you consider a port successful at that point and call it good?
<cr1901_modern> We just added platform tests a few days ago; your target should be picked up automatically. Right now a successful Build(run=False) is considered success
<FelixVi2> ah, cool - let me see what I can do. I might ask you once I'm ready for testing
<cr1901_modern> "but I'm not sure what I should do beyond trying to boot bios" create a couple of dummy migen files that exercise I/O functionality
<cr1901_modern> in the case of saturn, which doesn't really have LEDs or fun stuff, hook up an LA to various pins as see if they toggle from a counter
<FelixVi2> that's the part I haven't done
<FelixVi2> I just got my first bios booted and am now a bit lost
<cr1901_modern> Forget about misoc before you're comfortable w/ migen IMO
<cr1901_modern> It's not difficult to learn if you're familiar w/ verilog or another HDL
<FelixVi2> yeah, I think I'm good on that end
<cr1901_modern> So create some Migen-only designs that have GenericPlatform.request("my_io") in it, build those files and run them to test your platform
<FelixVi2> so that's just direct I/O access without a CPU, right?
<cr1901_modern> right
<cr1901_modern> You may commit a platform file w/ a mistake in it. Not ideal, but it happens. I've done it before: https://ssl.serverraum.org/lists-archive/devel/2016-July/004222.html
<FelixVi2> migen seems a bit more difficult to start with compared to misoc
<FelixVi2> is there a tutorial for synthesis somewhere? the repo file is currently empty
<cr1901_modern> FelixVi2: Example provided at the end of my blog post
<cr1901_modern> ... which has a mistake, b/c of course it does
<cr1901_modern> (Incidentally, if you ever do use yosys, it probably does not require a path fix, since yosys can just be compiled for cygwin)
<FelixVi2> cr1901_modern: Thanks so much! I think I got enough to work off of for now
<FelixVi2> let's see how this goes
<FelixVi2> ah and migen creates a programmer - misoc doesn't seem to do that for you
<FelixVi2> that'd be a nice feature to add I'd say
<cr1901_modern> You have to do plat.create_programmer() to get a programmer, and pass in the platform to misoc anyway, so I don't see the point.
<cr1901_modern> Fortunately, looks like fixing cygwin support is a few line fix. Because we chdir() to the build directory before building, the only
<cr1901_modern> time we ever need absolute paths is for the input verilog files to the toolchains (at least for Xilinx)
<FelixVi2> cr1901_modern: I concur. For me, everything was building fine after modification of the two files I point at in the issue report
Gurty has quit [Ping timeout: 240 seconds]
<FelixVi2> cr1901_modern: the autogeneration for programmers in migen also seems broken
<FelixVi2> I think it's likely a path error - it can' find a flash proxy bitstream
<FelixVi2> other then that, I got an LED to blink :)
<cr1901_modern> Felix: Not broken, you have to download a repo: https://github.com/jordens/bscan_spi_bitstreams
Gurty has joined #m-labs
<FelixVi2> cr1901_modern: I cloned that and am still getting the same error
<cr1901_modern> Need to put them under ~/.migen
<cr1901_modern> wait a second..
<cr1901_modern> Okay _after_ that, you need to set flash_proxy_basename to the name of the bitstream which corresponds to your FPGA
<cr1901_modern> i.e. plat.create_programmer(flash_proxy_basename="bscan_spi_xc3s200a.bit")
<cr1901_modern> if that doesn't work, wait for rjo to come back b/c the bitstreams are kinda in flux (and quite personally I would rather just see more platform-specific command line programmers)
<cr1901_modern> FelixVi2: Please test this fix https://github.com/cr1901/migen/tree/ise-cygwin
<cr1901_modern> Is this my fix? I have no idea what's causing that error
<cr1901_modern> FelixVi2: Show me the file you tried compiling _exactly_
mumptai has quit [Remote host closed the connection]
<FelixVi2> cr1901_modern: maybe my installation got messed up
<FelixVi2> cr1901_modern: I don't have virtual environments under cygwin, give me a sec
<cr1901_modern> FelixVi2: Again, show me the file you tried compiling?
<cr1901_modern> This works just fine on my machine...
<FelixVi2> i think it's my installation
<FelixVi2> ok, that isn't it
<cr1901_modern> I have no provisions for installing cygwin and it would be extremely inconvenient to do so. I'm not sure why that file is failing, but it's
<cr1901_modern> failing in a part of Migen that relies on Python black magic: backtraces
<cr1901_modern> (well not black magic, but arguably the most evil Python feature)
<FelixVi2> cr1901_modern: oh, this is python 3.6
<cr1901_modern> How did you get it to work earlier?
<cr1901_modern> Oh, well maybe the patch didn't fix everything
<FelixVi2> it's not in the version on github
<FelixVi2> so if you forked that, it still needs to be applied
<cr1901_modern> FelixVi2: I'm not using python 3.6 and I have no plans to upgrade it tonight
<cr1901_modern> What I was saying is that you may have stumbled upon a legit bug
<cr1901_modern> and the patch didn't fix it
<FelixVi2> yes, it did
<FelixVi2> and it worked for me now, too
<cr1901_modern> Then why did it break between 3 hours ago and now?
<FelixVi2> running synthesis right now, will see about the programming part in a sec
<cr1901_modern> Is it because you installed _my_ copy of migen instead?
<FelixVi2> yeah, mine was patched (i did it to get it running)
<FelixVi2> pathced yours and can synthesize again
<FelixVi2> but it still complains about proxy bitstreams
<FelixVi2> what folder is it looking in for those?
<cr1901_modern> ~/.migen
<cr1901_modern> FelixVi2: Now try a Misoc CPU w/ my patch and see if the paths output are correct
<FelixVi2> cr1901_modern: it doesn't find the bitstream files
<cr1901_modern> FelixVi2: Why don't you try debugging yourself why it can't find the bitstream files as an exercise later then?
<FelixVi2> cr1901_modern: yeah, i can live without that feature - just wanted to try your patch
<cr1901_modern> FelixVi2: My patch doesn't fix the bitstream files
<cr1901_modern> It fixes finding verilog files whenever you run misoc
<FelixVi2> cr1901_modern: oh, i see :) let me try that
<cr1901_modern> And if the patch fails I want a backtrace so I can tweak
<cr1901_modern> (Or maybe you can tweak it and make it your first PR!)
<FelixVi2> yeah, i might look at it
<cr1901_modern> This... should've been fixed (And didn't misoc _work_ 3 hours ago?!)
<cr1901_modern> omit used to be called leave_out
<cr1901_modern> I have _no_ idea why your misoc/migen versions don't match
<FelixVi2> yeah, my version works fine
<FelixVi2> just swapped them and that's all good
* cr1901_modern is very confused what's going on
<cr1901_modern> So does my patch work or not?
<FelixVi2> my version is fine, your patch has the error shown in pastebin
<FelixVi2> trying to get a diff now
<cr1901_modern> That doesn't make any sense... my version should be new enough that "omit" replaced "leave_out"
<FelixVi2> yeah, that's the same
<FelixVi2> but after using setup.py it reverted to leave_out
<cr1901_modern> The hell?
<cr1901_modern> Do you have multiple conflicting copies of misoc?
<FelixVi2> no, and even if I did none of them would have this bug
<FelixVi2> the other copy I have works fine
<cr1901_modern> I have no idea without being physically at your computer. Just delete my copy of migen and copy/paste the lines into your installed version.
<cr1901_modern> I need to move on to other things tonight
<sb0> _florent_, whitequark, ping
<cr1901_modern> How does your copy of migen "magically" revert to an old version w/ leave_out?! ._.
<FelixVi2> FileNotFoundError: [Errno 2] No such file or directory: 'cygpath -wf -': 'cygpath -wf -'
<FelixVi2> this is what I get after copy and paste
<cr1901_modern> FelixVi2: Try "subprocess.Popen(["cygpath", "-wf", "-"], stdin=subprocess.PIPE,"
<cr1901_modern> i.e. split the command into a list of input args
<FelixVi2> ERROR:HDLCompiler:281 - "D:\cygwin64\lib\python3.6\site-packages\misoc-0.6.dev0-py3.6.egg\misoc\cores\lm32\verilog\submodule\rtl\/lm32_include.v" Line 61: Cannot open include file "lm32_config.v".
<cr1901_modern> The cascade never ends
<FelixVi2> just one exrta forward slash, otherwise it's good
<cr1901_modern> the extra forward slash is okay
<cr1901_modern> that's not the issue
<FelixVi2> you're right
<FelixVi2> D:\cygwin64\lib\python3.6\site-packages\misoc-0.6.dev0-py3.6.egg\misoc\cores\lm32\verilog\submodule\rtl\lm32_include.v
<FelixVi2> this is the correct path
<cr1901_modern> Right... erm, paste the contents of the .xst file
<FelixVi2> the last line didn't seem to get the right path
<cr1901_modern> FelixVi2: Look in ise.py and change to "xst_contents += "-vlgincdir " + sanitize(path) + "\n""
<FelixVi2> but that's not what ise complained about
<cr1901_modern> FelixVi2: Actually I'm pretty sure it was
<cr1901_modern> ISE tried parsing that include path, as a Windows path and complained
<cr1901_modern> when it couldn't find lm32_config.v
<FelixVi2> yeah, that's right
<FelixVi2> running fine now
<cr1901_modern> So the bug is fixed then?
<FelixVi2> cr1901_modern: yeah, looks like it
<cr1901_modern> Alright I'll submit the fix as a PR then
<FelixVi2> cr1901_modern: awesome, thanks so much for the help
<cr1901_modern> Yw
<cr1901_modern> FelixVi2: I would _strongly_ suggest for the time being to checkout migen/misoc as git repos and do setup.py develop for the time being
<FelixVi2> hopefully I can figure out the proxy bitstream stuff and target generation
<FelixVi2> yeah, that's probably how my version got downgraded
<cr1901_modern> And keep them both up to date
<cr1901_modern> Also don't track my copy either :). I'm about to break it w/ a force push
<FelixVi2> ah, cool
<FelixVi2> i'll try to keep track of all the changes I got going on and make my own fork
<cr1901_modern> Aaand done: https://github.com/m-labs/migen/pull/88
<FelixVi2> so then maybe I don't have to make my own fork?
<FelixVi2> oh well, it doesn't include the python 3.6 patch - based on the issue I might need to dig into that and try to understand what's going on
<cr1901_modern> FelixVi2: Nah, I'll leave that patch up to you :D
<FelixVi2> that's fair