Saturday, 2019-03-09

*** tpb has joined #tomu00:00
*** futarisIRCcloud has joined #tomu00:26
*** xkapastel has quit IRC00:35
*** AmosSam has left #tomu01:12
*** AmosSam has joined #tomu01:12
*** ewen has joined #tomu02:07
*** Farscrap has quit IRC05:24
*** rohitksingh has joined #tomu06:33
xobsYay, I managed to get the sigrok-cli decoder working with gtkwave!  Thanks, tnt.  Any idea why it fails sometimes?  If I just keep pressing "Ctrl-R", then about 15% of the time it decodes wrongly.07:26
* xobs uploaded an image: image.png (23KB) < https://matrix.org/_matrix/media/v1/download/matrix.org/hRtbHyyelJEfVVOdnlDyYCEw >07:27
tntxobs: I'm not sure tbh, but I didn't really did deep either. I guess I should write a debug mode where it saves the input vcd to a different file and see if there are variations.07:30
xobsAh, so you noticed that as well?  Seems that it doesn't necessarily like the skew.  But oh well.07:31
tntand for some reason if I use lxt2 source file instead of vcd ... can't get it to work at all.07:31
xobsPhew, the testbench works much better if I actually drive clk48.  Makes sense that the PLL isn't simulated.  They're complicated.07:51
tntAhah, yeah having a clock helps.07:56
rohitksinghxobs: fomu-flash doesn't result in any activity on the SPI bus...just initially it asserts (pulls down) CRESET pin....On the other hand if I use python spidev library, I can see some activity on the SPI bus.... these are my connections https://www.dropbox.com/s/k2re3cp8mz499lw/fomu-flash-diff.png?dl=008:07
tpbTitle: Dropbox - fomu-flash-diff.png (at www.dropbox.com)08:07
rohitksinghI followed the pinouts provided in the readme here: https://github.com/im-tomu/fomu-flash08:08
tpbTitle: GitHub - im-tomu/fomu-flash: Utilities to flash Fomu from a Raspberry Pi (at github.com)08:08
rohitksinghanytime I might be missing here?08:08
rohitksingh*anything08:08
xobsrohitksingh: Those definitions don't look quite right.  Did you specify the header pins instead of the BCM pins?  For example, your S_MOSI is BCM19, which is pin 35 on the header (and is a hardware MISO pin), and your S_CLK is BCM23, which is on pin 16 o fthe header.08:11
xobsThe default S_MOSI is BCM10, which is located on pin 19 of the header.08:11
rohitksinghxobs: facepalm! indeed I used "header" pin numbers08:12
xobsLikewise, the default S_MISO is BCM9, which is located on pin 21 of the header (going based on https://pinout.xyz/)08:12
tpbTitle: Raspberry Pi GPIO Pinout (at pinout.xyz)08:12
rohitksinghxobs: thank you so much! let me try with correct values :)08:12
xobsrohitksingh: no problem!  You can also remap them without compiling by specifying a command line switch.  I forget which one it is.08:13
xobsAlso, note that the F_RESET is different on the very first Raspberry Pi devices, which is why it's not a #define.08:13
rohitksinghyup it was "-g i:PIN" like that08:14
rohitksinghsure, thanks! let me try08:14
rohitksingh:)08:14
rohitksinghxobs: so the default pin mapping in your code itself was the correct one, lol...it's working now! \o/ https://www.dropbox.com/s/edkjxgv9lokhjme/fomu-flash-spi-id.png?dl=008:24
tpbTitle: Dropbox - fomu-flash-spi-id.png (at www.dropbox.com)08:24
rohitksinghtime to set up ice40 toolchain and try some basic designs08:25
xobsHooray! \o/08:25
xobsAre you using your own Raspberry Pi image/08:25
rohitksinghyup the standard raspbian08:25
rohitksinghdo we have separate image for fomu development?08:26
xobsI ask because there are images at https://github.com/im-tomu/fomu-pi-gen/releases -- I really ought to upload a replacement that has lm32 support as well.08:26
tpbTitle: Releases · im-tomu/fomu-pi-gen · GitHub (at github.com)08:26
rohitksinghoooh, that is awesome! it will spare me the headache of setting up toolchain! thanks again! let me try the image :)08:27
xobsYou can just install packages, though.08:27
rohitksinghoh okay08:27
xobshttps://github.com/im-tomu/fomu-pi-gen/tree/master/stage2-fomu/04-fomu/files08:27
tpbTitle: fomu-pi-gen/stage2-fomu/04-fomu/files at master · im-tomu/fomu-pi-gen · GitHub (at github.com)08:27
xobsActually, that would also be a nice thing to have.  Just packages, for people who already have an install.08:27
rohitksinghnice, all the packaged toolchains are available! I spot lm32 too there, added probably 4 days back. So maybe that's why you mentioned the last release image doesn't have lm32?08:32
xobsIt doesn't, and I haven't tested it yet.  I actually haven't tested the "Pre-release" image either, though I assume it works.  But that's the major reason why I haven't promoted it to "Latest release".08:33
rohitksinghah okay08:33
rohitksinghstill I have to say these packaged version have made the setting up part as easy as I can expect! props to you xobs!08:34
xobsYay!08:34
*** futarisIRCcloud has quit IRC08:34
xobsIt's not particularly fast, but it's quick to set up.08:45
*** ewen has quit IRC09:18
tntxobs: btw, did you have a look at the patch I posted see if it did anything wrt to the corruption on real hw ?09:35
xobstnt: Let me set up some real hardware and give that a shot.10:05
tntxobs: note that (1) here at least I noticed that the clock constraint are not applied correctly because the post-synthesis net name for the clk doesn't match what's in the pre_pack.py file generated by migen. (2) it didn't meet timing without adding the "-relut -dffe_min_ce_use 4" options to yosys synth_ice40 for me.10:12
xobsThat's a little concerning.  The clock stuff, at least.  What do those arguments to synth_ice40 do, and what are the tradeoffs of using them?10:18
tnt'relut' applies another optimization pass to pack more into LUTs. Tradeoff is ... well it's one more pass, takes a tiny bit of time I guess.10:22
tnt'dffe_min_ce_use 4' prevents yosys from generating a Clock Enable signal that's used by less than 4 FFs.  Yosys tends to be pretty agressive into generating CE (vs a MUX with the old value) and on the ice40 CE is shared between 8LCs, so if you have a CE used by only one FF, you wasted 7 LCs.10:24
tntSo far I have never seen a case where those two options had a global negative effect on either size or timing.10:24
xobsI'll add those to the Foboot synthesis, then.  And see if I can't fix the clk48 generation.10:29
xobsNeed to head out soon, though :(10:30
xobsI wonder if that's a bug in nextpnr, then...10:35
xobsThe top.v has `always @(posedge usb_48_clk) begin` for example, but nextpnr reports `Warning: net 'usb_48_clk' does not exist in design, ignoring clock constraint`10:35
xobsOr maybe Yosys is doing something to that net name.10:36
tntMmm, when looking at the .json I think the same internal wire has several names. But I'm not sure nextpnr can deal with multiple names per net ...10:46
*** rohitksingh has quit IRC11:15
*** AmosSam has left #tomu13:47
*** Farscrap has joined #tomu13:51
*** AmosSam has joined #tomu14:07
*** cbjamo has joined #tomu14:49
*** xkapastel has joined #tomu15:00
*** rohitksingh has joined #tomu15:46
*** rohitksingh has quit IRC17:06
*** rohitksingh has joined #tomu17:27
*** AmosSam has left #tomu18:40
*** AmosSam has joined #tomu18:40
*** cbjamo has quit IRC18:54
mithroxobs: We should turn on the option which causes a missing clock constraint to be a fatal error19:43
mithroxobs: I'm going to look at doing the 48MHz->12MHz transition on the rx right now19:44
mithroI'm guessing you are probably asleep19:44
tntmithro: it's an error by default now.19:49
tntmithro: but one of the issue was that the clock constraint wasn't being applied19:50
mithrotnt: ignoring clock constraints should cause a fatal error19:53
tntnot an easy fix19:56
*** auscompgeek has quit IRC20:17
*** esden has quit IRC20:18
*** esden has joined #tomu20:21
*** rohitksingh has quit IRC21:17
*** rohitksingh has joined #tomu21:20
*** rohitksingh has quit IRC23:30

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