| *** tpb has joined #tomu | 00:00 | |
| MadHacker | gurke_: I think you're mostly reading the sampling performance of your meter. | 00:01 |
|---|---|---|
| gurke_ | uhm, true, that could also make sense :-) | 00:02 |
| gurke_ | i'm always forgetting about the electrical part | 00:02 |
| MadHacker | Mm. There's no such thing as a purely digital output. :) | 00:02 |
| gurke_ | it's a 60 mhz analog oscilloscope and i do have to push it to the limits, yes | 00:02 |
| gurke_ | yes :-) | 00:03 |
| MadHacker | Unless your probes are very good, the actual bandwidth won't even be 60, unfortunately. | 00:03 |
| gurke_ | yes | 00:03 |
| gurke_ | but i can read out the 48 MHz - even though the signal looks not very rectangular anymore | 00:04 |
| MadHacker | Yep, that's reasonable. | 00:04 |
| gurke_ | thanks! | 00:04 |
| MadHacker | Anyway; on your original question: You won't need to do anything special to output from a signal, sync or otherwise. Just specify its connection to the physical pins and you should be fine. | 00:05 |
| gurke_ | ok, i was just wondering about https://github.com/im-tomu/fomu-workshop/blob/master/verilog/blink-expanded/blink.v#L68 | 00:06 |
| tpb | Title: fomu-workshop/blink.v at master · im-tomu/fomu-workshop · GitHub (at github.com) | 00:06 |
| gurke_ | what's the buffering for? | 00:06 |
| MadHacker | Clock signals are special, because there's an internal clock distribution network inside the FPGA to connect it to all the flip-flops without delays etc. | 00:07 |
| MadHacker | In the case of that example, the code is instantiatng a clock buffer explicitly to connect a clock pin to the internal clock network. | 00:08 |
| gurke_ | ah, ok, makes sense | 00:09 |
| MadHacker | https://www.latticesemi.com/-/media/LatticeSemi/Documents/ApplicationNotes/IK/iCE40sysCLOCKPLLDesignandUsageGuide.ashx?document_id=47778 is the ice40 clocking datasheet and should explain the SB_GB bit properly. | 00:10 |
| gurke_ | yep, i've already read that | 00:10 |
| MadHacker | So, on page 2, you'll see it says " To use a global buffer along with a user interface or PIO, use the SB_GB primitive if it is not inferred automatically" | 00:11 |
| MadHacker | It's inferred automatically pretty often. | 00:11 |
| gurke_ | ok - and otherwise i'd notice probably? | 00:11 |
| MadHacker | Probably. I think you'll get warnings out of the build chain grumbling about using normal fabric signals for clocks. | 00:12 |
| MadHacker | I know you do on the Xilinx toolchains; I've never run into it on ice40, but I've never really put myself into situations where I'd expect inference to struggle. | 00:12 |
| gurke_ | ok | 00:13 |
| gurke_ | you may have noticed that i'm actually pretty new to FPGAs | 00:13 |
| gurke_ | but thanks a lot - that helps so far! | 00:16 |
| MadHacker | No problem. A lot of folks in the same position here, the more folks playing with them, the merrier. :) | 00:17 |
| *** im-tomu has left #tomu | 00:25 | |
| *** im-tomu has joined #tomu | 00:25 | |
| xobs | The ICE40 is small enough that we could probably get away without buffering. | 00:29 |
| xobs | But, for example, early versions of the USB core just used a flip-flop to divide down the 48 MHz clock to get 12 MHz, but we ran into phase alignment issues. | 00:30 |
| xobs | It would work sometimes, and on some boards with some machines. Sometimes even only on some USB ports. | 00:30 |
| gurke_ | oh, i see | 00:31 |
| xobs | Bottom line: clocks are weird. | 00:32 |
| xobs | I mean, even on real asics they're weird. Some ungodly high percentage of lots of chips are dedicated to clock routing. | 00:33 |
| gurke_ | i think, more generally, time is a weird concept ;-) | 00:34 |
| xobs | What even is time. | 00:34 |
| *** ewen has joined #tomu | 01:02 | |
| *** xkapastel has quit IRC | 02:00 | |
| mithro | xobs: http://www.contrib.andrew.cmu.edu/~somlo/BTCP/ | 03:08 |
| tpb | Title: A Trustworthy, Free (Libre), Linux Capable, Self-Hosting 64bit RISC-V Computer (at www.contrib.andrew.cmu.edu) | 03:08 |
| mithro | Opps wrong url | 03:09 |
| mithro | https://groups.google.com/d/msgid/linux-litex/20200111015354.GA29609%40crash.ini.cmu.edu | 03:09 |
| tpb | Title: Google Groups (at groups.google.com) | 03:09 |
| *** im-tomu has left #tomu | 04:49 | |
| *** im-tomu has joined #tomu | 04:49 | |
| *** im-tomu has left #tomu | 06:07 | |
| *** im-tomu has joined #tomu | 06:07 | |
| *** im-tomu has left #tomu | 06:38 | |
| *** im-tomu has joined #tomu | 06:38 | |
| *** ewen has quit IRC | 06:50 | |
| *** tac-tics has joined #tomu | 07:07 | |
| tac-tics | Is it to be expected that, after running dfu-util -D <FILE>, I can't run it a second time to flash a second file instead? | 07:10 |
| tac-tics | I've been having to unplug my Fomu each time | 07:10 |
| tac-tics | Also, I'm following the steps on https://workshop.fomu.im Everything has worked perfectly up to the Rust example. However, starting with the Verilog section, the examples seem not to work at all. Both the LED blink and Litex leave the board unblinking and unable to talk over the bus. | 07:15 |
| *** tommythorn has joined #tomu | 07:18 | |
| tac-tics | And it seems as though the verilog directory got renamed, but the documentation hasn't been updated in the rst file. | 07:18 |
| tac-tics | (or perhaps the website just hasn't been updated that recently). | 07:20 |
| tommythorn | Is getting “state(10) = dfuERROR, status(8) = Cannot program memory due to received address that is out of range” a known issue when trying to update the bootloader to pvt-updater-v2.0.3.dfu ? | 07:21 |
| tommythorn | I followed https://workshop.fomu.im/en/latest/bootloader.html | 07:22 |
| tac-tics | I didn't get any errors of any sort. | 07:25 |
| tac-tics | Also, I *think* I have the hacker version, but at the same time, when I went through the Python example, it seemed like I had the pvt version of the board. | 07:25 |
| tac-tics | It definitely looks like the hacker version | 07:25 |
| tommythorn | Thanks. I got mine through Crowdsupply, and it’s definitely pvt | 07:28 |
| *** tommythorn has quit IRC | 07:39 | |
| gurke_ | tac-tics: DFU is provided by the bootloader which flashes a single file and then "executes" it | 08:22 |
| *** ewen has joined #tomu | 08:23 | |
| gurke_ | tac-tics: so you cannot flash a second file, however after re-plugging, you can start the file you've flashed before again using dfu-util -e | 08:23 |
| gurke_ | tac-tics: yes, the verilog section is outdated, I'm working on a pull request to fix that currently | 08:24 |
| tac-tics | What does the `wishbone-tool 0xe0006000 0xac` command effectively do then? If I flash micropython onto the board, then run that command, I somehow get the DFU device to appear again in `dfu-utils -l` | 08:24 |
| tac-tics | ah, nice | 08:25 |
| gurke_ | ok, the bootloader is a bit more complicated :-) | 08:25 |
| gurke_ | there are different things happening | 08:25 |
| tac-tics | heh | 08:25 |
| tac-tics | It's something I'd like to learn more about | 08:25 |
| tac-tics | sometime | 08:25 |
| gurke_ | the bootloader loads a RISC-V cpu into the fpga and executes on it | 08:26 |
| gurke_ | if you flash micropython, it is executed on the very same cpu set up by the bootloader | 08:26 |
| tac-tics | The RISC-V softcore is just stored on the SPI flash with everything else, right? | 08:26 |
| tac-tics | If you're not careful, you can erase it and brick the device, can't you? | 08:26 |
| gurke_ | the bootloader also configures some configuration and status registers, among them the 0xe0006000 | 08:27 |
| gurke_ | using the 0xe0006000 register, you can direct the fpga to load some other bitstream (or reload the first one with the bootloader) | 08:27 |
| tac-tics | ah | 08:27 |
| gurke_ | however, if you load a "simple" verilog/migen bitstream without bootloader, then those registers do not exist and you have to physically unplug fomu to get back | 08:28 |
| gurke_ | more can be found here: http://rm.fomu.im/ | 08:28 |
| tpb | Title: Documentation for Fomu Bootloader Fomu Bootloader documentation (at rm.fomu.im) | 08:28 |
| tac-tics | thanks | 08:28 |
| gurke_ | and yes, the softcore is also stored on the flash | 08:28 |
| gurke_ | however, the bootloader normally prevents you from overwriting things, so you can freely experiment by flashing stuff | 08:29 |
| gurke_ | you would have to be careful if you start poking around in the flash directly over SPI | 08:29 |
| tac-tics | Because the USB is handled in the softcore, I imagine once you brick the thing, you might as well use the device as a USB dust protector, right? :) | 08:30 |
| tac-tics | In other words, there's no way to flash anything onto the drive if you put the SPI into a bad enough state | 08:31 |
| gurke_ | there are some testpads on the board which can be used to flash, however i guess that's quite a fiddly thing to do if you do not have the appropriate jig | 08:31 |
| gurke_ | (never tried that) | 08:32 |
| tac-tics | My level of hardware expertise is that if I need a solder gun to fix it, I just throw the thing away. It's clearly hopeless. | 08:32 |
| gurke_ | you don't have to go that far ;-) | 08:33 |
| gurke_ | i think the thing is quite hard to brick unless you try to do so on purpose (or do weird things on the SPI) | 08:33 |
| tac-tics | The tutorial showed how you can inspect the SPI in micropython. I was assuming that meant arbitrary poke and peek of memory. | 08:34 |
| tac-tics | And if not in micropython, then perhaps in assembly. | 08:34 |
| tac-tics | Although, I would think a sensible way to prevent that would be to avoid memory mapping those parts of the SPI on the bus. | 08:34 |
| gurke_ | well, reading out should never be an issue | 08:35 |
| gurke_ | however, I'm also only two weeks into the project now - so not everything might be 100% correct | 08:35 |
| tac-tics | In any case, I'll be eagerly awaiting your verilog blinky fix. | 08:36 |
| gurke_ | i've basically read the source for the bootloader, which showed me how a lot of things work: https://github.com/im-tomu/foboot | 08:36 |
| tpb | Title: GitHub - im-tomu/foboot: Bootloader for Fomu (at github.com) | 08:36 |
| gurke_ | tac-tics: did you try the blink-expanded? this one should actually work if you set the correct environment variable (export FOMU_REV=pvt if you have a production fomu) | 08:37 |
| *** ewen has quit IRC | 08:38 | |
| tac-tics | I tried both with FOMU_REV=pvt and =hacker, but while both seem to program without error, both leave the device with the LED off. | 08:40 |
| gurke_ | and you get something like "Built 'blink' for Fomu pvt" at the end of make? | 08:41 |
| tac-tics | Built 'blink' for Fomu hacker | 08:41 |
| gurke_ | and you have a hacker version? | 08:42 |
| tac-tics | I'm prettty sure | 08:44 |
| gurke_ | ok, no clue then, sorry | 08:44 |
| tac-tics | maybe | 08:44 |
| tac-tics | actually, the device itself reports 'P' for production in one of the registers | 08:45 |
| tac-tics | and the die actually looks more like the PVT | 08:45 |
| tac-tics | but the color is different. Mine is blue. | 08:45 |
| tac-tics | Mine must be a pvt after all | 08:45 |
| tac-tics | wtf. ok. whatever. it works now | 08:49 |
| *** gio has quit IRC | 08:56 | |
| tac-tics | Oh. And at least according to this brief explanation, it seems that there's a boot rom at 0x0000_0000. I would think that that means you can't clobber the base image quite as easily as I was thinking. | 08:59 |
| *** im-tomu has left #tomu | 09:36 | |
| *** im-tomu has joined #tomu | 09:36 | |
| *** gio has joined #tomu | 09:49 | |
| *** im-tomu has left #tomu | 10:15 | |
| *** im-tomu has joined #tomu | 10:16 | |
| *** im-tomu has left #tomu | 12:43 | |
| *** im-tomu has joined #tomu | 12:43 | |
| futarisIRCcloud | https://twitter.com/GregDavill/status/1215923939634888704?s=19 | 12:52 |
| *** im-tomu has left #tomu | 13:06 | |
| *** im-tomu has joined #tomu | 13:07 | |
| *** im-tomu has left #tomu | 15:08 | |
| *** im-tomu has joined #tomu | 15:08 | |
| *** coderobe has quit IRC | 17:15 | |
| *** coderobe has joined #tomu | 17:15 | |
| *** im-tomu has left #tomu | 17:46 | |
| *** im-tomu has joined #tomu | 17:46 | |
| *** im-tomu has left #tomu | 18:28 | |
| *** im-tomu has joined #tomu | 18:28 | |
| *** tpb has joined #tomu | 18:55 | |
| *** gio has quit IRC | 19:22 | |
| *** earthnative has quit IRC | 19:22 | |
| *** gio has joined #tomu | 19:24 | |
| *** earthnative has joined #tomu | 19:28 | |
| *** cdmatter has quit IRC | 21:50 | |
| *** GNUtoo has quit IRC | 22:02 | |
| *** GNUtoo has joined #tomu | 22:02 | |
| *** cdmatter has joined #tomu | 23:08 | |
| *** cdmatter has quit IRC | 23:12 | |
| *** cdmatter has joined #tomu | 23:18 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!