Thursday, 2018-07-05

*** tpb has joined #timvideos00:00
xobscr1901_modern: It works by poking instructions into the softcore and reading whatever register gets updated, so it's whatever the vexriscv sees.01:28
cr1901_modernI would have to see an example, but 0xe0000000-part of the address space is uncached, so a read from the serial port reg shouldn't return a stale value01:30
*** rohitksingh_work has joined #timvideos03:47
*** sb0 has quit IRC04:13
xobsActually, it might just be me not understanding how the serial port works.  I think that for some reason the serial port is starting out with data in the fifo.  I'm adding something to uart_init() to drain the fifo to see if that helps things.06:23
thaytansecret startup codez06:49
thaytan"It turned out that each time the device was booted, my long dead grandmother could send me 16 bytes of ASCII message"06:50
thaytanxobs, the fifo indices not being initialised, or something actually sending bytes somehow?06:51
xobsthaytan: I haven't figured that out yet.  Definitely some garbage in the fifo.  It's nice that it's not a cache problem.06:52
_florent_xobs: maybe you can try the workaround i provided yesterday to reset the fifo06:55
_florent_sorry not the fifo, but the uart06:55
_florent_you can also connect this reset to a button of pin if it's easier06:56
xobs_florent_: I'll add that and see if it helps.06:58
*** sb0 has joined #timvideos07:12
*** sb0_ has joined #timvideos07:19
xobs_florent_: Initial tests seem to show that helps quite a bit.  Thanks!07:21
_florent_xobs: ok, but i still don't understand why you get the data you send in the rx fifo07:28
cr1901_modernI'm guessing the design isn't public?07:30
xobsIt is, but I haven't pushed anything in a while.  The goal was to get it reliable before pushing.07:31
xobsAlso, I feel I need to rewrite my openocd<->vexriscv bridge.  I'm not very good with Python so I wrote it first in C.07:31
cr1901_modern_florent_: Here is a super-important and definitely-not-bikeshedding PR: https://github.com/enjoy-digital/litex/pull/7607:44
tpbTitle: Update README by cr1901 · Pull Request #76 · enjoy-digital/litex · GitHub (at github.com)07:44
_florent_cr1901_modern: what incompatibilities have you seen?08:02
cr1901_modern_florent_: I'm handwaving "incompatibilities" as "sometimes ppl only send PRs to Litex or Migen, but not both, for board files, so they can sometimes go out of sync. Then eventually cr1901 fixes them :P."08:04
cr1901_modernRight now, arty s7 is incompatible b/c I haven't made a PR to sync recent Migen changes back to LiteX.08:05
cr1901_modern_florent_: I don't remember any particular instance offhand where someone _deliberately_ introduced an incompatibility, if that's what you're asking08:06
_florent_ok, i'll reformulate your PR and will add it the README and will also sync platforms file08:07
cr1901_modern_florent_: Also Arty A7 differs, and Idk if you remember, but we agreed that you'd sync the Migen changes (rgb leds) back to LiteX08:11
cr1901_modernThanks for saving me the trouble, btw08:11
_florent_cr1901_modern: on the rgb_led, that's not really an incompatibility, just that the plarforms are different08:14
_florent_you can still use the platform from Migen with Litex, just that you have to request the rgb_leds in a different way08:15
cr1901_modern_florent_: By incompatibility, I mean "the Migen platform can't be used in LiteX as-is (or vice versa!) without you having to change your source code that uses Migen/Litex."08:17
cr1901_modernSo in my eyes, rgb layout _is_ an incompatibility b/c you can't interchange platform files if you use rgb leds08:17
cr1901_modernIn any case, I'll stop complaining for tonight :)08:18
_florent_yes but that's not what we want to do08:19
_florent_platforms/targets in LiteX should be working together08:20
_florent_not plaforms from Migen and targets from LiteX08:20
_florent_otherwise, i should just move all platforms to Migen08:20
_florent_so the design can choose, to use the platforms/targets from LiteX08:21
_florent_or use the platform from Migen and create is own SoC08:21
cr1901_modernAnd then a user who mostly uses LiteX decides to try Migen, and thinks the board files are the same and quickly finds out they aren't, and then has to memorize all the places where they aren't08:22
cr1901_modernif they choose to switch between Migen and Litex08:22
cr1901_modern(in a word, me! Though tbf, I don't really use MiSoC much anymore)08:23
cr1901_modern_florent_: Even if you can't swap litex and migen boards, I still think it's fair that I/O in each file should have the same format between migen and litex08:27
cr1901_modernWhich, migen and litex _do_, except for rgb leds08:27
_florent_cr1901_modern: i agree on the idea and i'm ok to try to keep things compatible08:28
_florent_that's just that when someone improves something in Migen for example08:28
_florent_i'm not able to get things in sync immediately, since it potentially breaks things for me and for some private projects08:29
cr1901_modernokay, that's fair >>08:29
_florent_so i first have to do the changes in the design08:30
cr1901_modernWell I don't mind making PRs and leaving them there until you're ready08:30
cr1901_modernhttps://irclog.whitequark.org/~h~openfpga/2018-07-05#1530774422-1530774481;08:30
tpbTitle: ##openfpga on 2018-07-05 — irc logs at whitequark.org (at irclog.whitequark.org)08:31
_florent_and that's also one of the reason i prefer to have the platforms i generally used defined in LiteX08:31
_florent_cr1901_modern: i'm trying to sync things now08:31
cr1901_modern_florent_: Right. Feel free to change the wording of my PR if you take issue w/ "incompatibilities".08:32
cr1901_modernThose IRC messages were tonight, I have a few litex PRs incoming that will fix a few bugs once migen accepts them (so it's a copy/paste job ;)...)08:32
cr1901_modernI'm basically trying to finish a number of "low effort" PRs that have been on my todo list for months b/c... well, easy things pile up!08:33
cr1901_modernLiteX will soon get preliminary cygwin support and a patch for Mimasv2 PMODs08:33
_florent_but just one thing, why is the initial copyright removed on arty on Migen?08:34
xobscr1901_modern: What's cygwin support for?08:48
xobsAlso, I'm going to clean up my vexriscv debugging patches and submit a PR.08:49
cr1901_modern_florent_: Oversight I guess (I didn't commit that)08:50
cr1901_modernxobs: https://github.com/m-labs/migen/pull/88#issuecomment-40257510808:50
tpbTitle: xilinx/ise: Add Cygwin path to Windows conversion in xst files. by cr1901 · Pull Request #88 · m-labs/migen · GitHub (at github.com)08:50
xobsIck08:53
cr1901_modernxobs: Idk if "ick" is the word I'd use. It's mainly that There's Ten Ways To Shoehorn *nix Into Windoze09:07
cr1901_modernsince most open source projects have decided that *nix is the One True OS09:07
_florent_cr1901_modern: everything should be fine now regarding platforms09:22
_florent_cr1901_modern: i also added a comment in the README09:22
cr1901_modern_florent_: https://github.com/enjoy-digital/litex/commit/d35dc5cdeae97c51b066e54d9cfbc0a3bc204cc8#diff-5bc78ceadf12ce9f8b5ce6dd88f81642R245 Hmmm I think 0.750 was in fact correct09:27
tpbTitle: platforms/arty: merge with Migen · enjoy-digital/[email protected] · GitHub (at github.com)09:27
* cr1901_modern should've caught this before the Migen PR was merged, but didn't :/09:27
cr1901_modern_florent_: Tyvm for your work09:27
_florent_cr1901_modern: if the DDR3 is using 1.35v, then 0.675v is fine09:28
_florent_1.35/2=0.675v09:28
_florent_0.750 is for 1.5v09:29
cr1901_modernRight, but I thought DDR3 on Arty A7 was using 1.5v09:29
cr1901_modernand Arty S7 was using 1.35v09:29
_florent_in the schematic it's 1.35v09:30
cr1901_modernOh, then nevermind... maybe it's the old Arty (before Arty A7) that used 1.5v09:30
_florent_Arty A7 is the same than Arty A7 no?09:31
cr1901_modernhttps://reference.digilentinc.com/reference/programmable-logic/arty/reference-manual Apparently so09:31
tpbTitle: Arty Reference Manual [Reference.Digilentinc] (at reference.digilentinc.com)09:31
cr1901_modern(1.35V)09:32
cr1901_modernNote this is the old manual09:32
_florent_ok so we are fine09:33
cr1901_modernI think so09:33
cr1901_modern_florent_: mithro wanted an ArtyS7 port to litex-buildenv. He may want arty s7 back in litex, but he should be the one to say something not me :P. >>09:38
cr1901_modernAdditionally, there's a bug in the Arty S7 file in migen, so you just fixed a bug by removing the file ;)09:38
cr1901_modernThank you for your help09:38
_florent_Let's avoid duplicating too much things, if we make sure platforms are compatible between Migen/LiteX, let's use the platforms from Migen09:39
cr1901_modernFine w/ me09:40
_florent_I still want to have platforms in LiteX for non-regression on the boards i'm using09:40
_florent_What's the bug in Arty S7?09:41
cr1901_modernI accidentally put PMODs under I/O instead of _connectors09:41
_florent_should i fix that now?09:42
cr1901_modern_florent_: Actually, yes, I would appreciate that if you did. It would help me a lot09:43
cr1901_modern...oh wait09:43
cr1901_modernhmmm09:43
_florent_i'm looking at that but not sure to see what's the problem09:44
cr1901_modern_florent_: I'm checking something09:45
cr1901_modernhttps://github.com/m-labs/migen/commit/fd7ce92c2408eb6ce44003ca5bce2946156f3997 Okay, it was already done, so nevermind09:45
tpbTitle: Moved pmods to _connectors, removed _1x from spiflash · m-labs/[email protected] · GitHub (at github.com)09:45
cr1901_modernthe idea was I wanted to commit that fix back to litex, but never did09:45
cr1901_modern_florent_: Btw, I think this is going to break any migen platforms that use diamond but aren't in litex: https://github.com/enjoy-digital/litex/blob/c3652935d9f0560ac32d55335b56a11199c45878/litex/build/lattice/diamond.py#L19-L2309:49
tpbTitle: litex/diamond.py at c3652935d9f0560ac32d55335b56a11199c45878 · enjoy-digital/litex · GitHub (at github.com)09:49
cr1901_modernisinstance is going to return False for litex.build.generic_platform.Pins b/c a migen platform will use migen.build.generic_platform.Pins09:50
cr1901_modernI think the easiest solution right now is to just recommit s7 (with the fix from migen) and live w/ the duplication for now. :/09:54
_florent_ok done10:07
cr1901_moderncool! You agree w/ my analysis, btw? (Easy way to fix it would be to check for migen _or_ litex Pins)10:08
cr1901_modernIn the future I'd be happy to test which platforms work fine in litex using the migen platforms, just not prepared to do so tonight10:08
_florent_i need to look at that10:30
*** tinyfpga has quit IRC11:29
*** tinyfpga has joined #timvideos11:29
*** sb0 has quit IRC12:13
*** rohitksingh_work has quit IRC12:33
*** sb0 has joined #timvideos13:14
mithroYes, I'm after all the Arty boards in litex BuildEnv15:40
CarlFKmithro: I owe you an Opsis purchase.    I bought $1000 worth of NeTV2s, 1 Arty for Aeva - if I buy myself one more and bug someone other than you about hooking it to my Jenkins tester, would that cover my lack of Opsis purchasing?15:48
*** sb0 has quit IRC15:56
mithroOne more NeTV2 or Opsis?16:06
mithroOne more NeTV2 or Opsis?16:06
CarlFKArty boards16:12
CarlFKreally I want one handy to give out next time someone wants to try your Linux on FPGA thing16:13
CarlFKmithro: ^^16:17
mithroCarlFK: I would prefer you had an opsis for hooking up to jenkins17:00
mithroCarlFK: I can probably get you ~5 Arty's to have spares to hand out17:00
CarlFKmithro: I have an Opsis hooked up to jenkins, and I think I got my one test running17:31
*** thaytan has quit IRC18:32
*** Kamilion has quit IRC18:47
*** Kamilion has joined #timvideos18:52
cr1901_moderntinyfpga: https://github.com/m-labs/migen/pull/111 The internal oscillator stuff has actually been quite difficult to get right. Hopefully migen/litex will have this platform soon19:45
tpbTitle: build/platforms: Add tinyfpga_a platform. by cr1901 · Pull Request #111 · m-labs/migen · GitHub (at github.com)19:45
*** thaytan has joined #timvideos20:07
*** ChanServ sets mode: +v thaytan20:07
*** CarlFK has quit IRC21:39
*** CarlFK has joined #timvideos21:43
*** ChanServ sets mode: +v CarlFK21:43

Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!