| *** tpb has joined #yosys | 00:00 | |
| *** pacak has quit IRC | 00:29 | |
| *** pacak has joined #yosys | 00:29 | |
| *** emeb_mac has joined #yosys | 00:53 | |
| *** gsi__ has joined #yosys | 01:25 | |
| *** gsi_ has quit IRC | 01:28 | |
| *** lutsabound has quit IRC | 01:45 | |
| *** proteusguy has quit IRC | 02:40 | |
| *** PyroPeter has quit IRC | 03:04 | |
| *** citypw has joined #yosys | 03:16 | |
| *** PyroPeter has joined #yosys | 03:17 | |
| *** AlexDaniel has quit IRC | 03:19 | |
| *** citypw has quit IRC | 03:32 | |
| *** rohitksingh_work has joined #yosys | 04:43 | |
| *** stuckpixel has joined #yosys | 05:29 | |
| *** proteusguy has joined #yosys | 06:34 | |
| *** proteusguy has quit IRC | 06:40 | |
| *** cr1901 has joined #yosys | 06:58 | |
| *** cr1901 has quit IRC | 06:58 | |
| *** emeb_mac has quit IRC | 07:07 | |
| *** m4ssi has joined #yosys | 07:22 | |
| *** futarisIRCcloud has joined #yosys | 08:00 | |
| corecode | so i'm trying to figure out why i get a context check assertion | 08:36 |
|---|---|---|
| corecode | after my rgb modifications | 08:36 |
| daveshah | corecode: most likely that net users or driver doesn't match the net stored on the cell port | 08:44 |
| tnt | corecode: is your current code on github ? | 08:46 |
| *** gsi__ is now known as gsi_ | 08:47 | |
| corecode | not yet | 09:10 |
| corecode | i tried figuring it out first | 09:10 |
| corecode | oh now i got it to work | 09:32 |
| corecode | oO | 09:32 |
| corecode | something about not erasing in a loop | 09:34 |
| corecode | i guess | 09:34 |
| tnt | Ah yeah, you can't iterate over something you modify. | 09:35 |
| tnt | In nextpnr usually it creates a list of 'to delete' during iteration and then does the actual deletion. | 09:36 |
| corecode | https://github.com/YosysHQ/nextpnr/compare/master...corecode:u4k?expand=1 | 09:40 |
| tpb | Title: Comparing YosysHQ:master...corecode:u4k · YosysHQ/nextpnr · GitHub (at github.com) | 09:40 |
| corecode | hm | 09:49 |
| corecode | ERROR: Module `\SB_LED_DRV_CUR' referenced in module `\top' in cell `\led_drv_cur' is not part of the design. | 09:49 |
| corecode | who says that, and what does it mean | 09:49 |
| corecode | this is during icefuzz make timings | 09:49 |
| tnt | huh line 1056 arch.cc is weird ... like you changed your mind. | 09:50 |
| corecode | yes, because i did | 09:51 |
| corecode | heh | 09:51 |
| corecode | thanks | 09:51 |
| corecode | ah i need a hierarchy generate statement in timings.ys | 09:52 |
| *** stuckpixel has quit IRC | 09:56 | |
| corecode | https://github.com/cliffordwolf/icestorm/compare/master...corecode:u4k?expand=1 | 09:56 |
| tpb | Title: Comparing cliffordwolf:master...corecode:u4k · cliffordwolf/icestorm · GitHub (at github.com) | 09:56 |
| tnt | corecode: my only issue ith the code is that during a time you have the RGBPU port that still exists and still has a 'net' pointer in it that points to free'd memory. | 09:59 |
| tnt | (AFAIU) | 10:00 |
| corecode | i think they are smart pointers | 10:00 |
| corecode | but yes, i agree that it isn't great | 10:00 |
| corecode | well, unique_pointer | 10:00 |
| daveshah | Can't you just set the port net to nullptr here: https://github.com/YosysHQ/nextpnr/compare/master...corecode:u4k?expand=1#diff-ca9370dbce6cd2a98691928e85456f53R1121 | 10:00 |
| tpb | Title: Comparing YosysHQ:master...corecode:u4k · YosysHQ/nextpnr · GitHub (at github.com) | 10:01 |
| corecode | ah | 10:01 |
| daveshah | user.cell->ports.at(user.port).net = nullptr | 10:01 |
| corecode | https://github.com/YosysHQ/yosys/compare/master...corecode:u4k?expand=1 | 10:01 |
| tpb | Title: Comparing YosysHQ:master...corecode:u4k · YosysHQ/yosys · GitHub (at github.com) | 10:01 |
| corecode | and never delete the port? | 10:03 |
| corecode | or still delete it | 10:03 |
| daveshah | Probably best to delete it too | 10:06 |
| corecode | ok | 10:07 |
| *** futarisIRCcloud has quit IRC | 10:10 | |
| *** citypw has joined #yosys | 10:23 | |
| *** citypw has quit IRC | 10:28 | |
| *** proteusguy has joined #yosys | 10:41 | |
| corecode | ok, i submitted the changes as PRs | 10:49 |
| tnt | corecode: did you test the resulting bitstream ? | 10:54 |
| corecode | i'm on it right now | 10:54 |
| corecode | so the bitstream fails to configure if the drive strength is not set properly | 11:01 |
| corecode | should we warn/fail during pnr? | 11:02 |
| corecode | i don't think we do for RGBA | 11:02 |
| corecode | also i don't know whether the current limit works | 11:02 |
| tnt | what do you mean not set properly ? | 11:03 |
| corecode | all 0s, for example | 11:03 |
| corecode | i.e. the default | 11:03 |
| corecode | ah yea i can observe a change in LED brightness | 11:04 |
| corecode | that means the current limit does do something | 11:04 |
| *** proteusguy has quit IRC | 11:04 | |
| daveshah | Yes, it would probably be good to add a warning for that case if it produces a bitstream that doesn't work at all | 11:05 |
| daveshah | if not an error | 11:05 |
| corecode | where would you add that | 11:06 |
| corecode | in bitstream or in pack? | 11:06 |
| *** futarisIRCcloud has joined #yosys | 11:06 | |
| daveshah | In pack would probably be best | 11:06 |
| corecode | aaah | 11:07 |
| corecode | hang on | 11:07 |
| corecode | "0b000000" = 0mA. // Set this value to use the associated SB_IO_OD instance at RGB | 11:07 |
| corecode | // LED location. | 11:07 |
| corecode | so why wouldn't it configure? | 11:07 |
| corecode | weird | 11:07 |
| tnt | Yeah, I find it weird that it would not configure at all. | 11:07 |
| corecode | maybe it did | 11:07 |
| daveshah | Do you have anything on those pins? | 11:07 |
| corecode | i think it could be my misinterpretation | 11:08 |
| *** proteusguy has joined #yosys | 12:13 | |
| corecode | ok, i pushed a new version | 12:15 |
| *** develonepi3 has joined #yosys | 12:53 | |
| *** rohitksingh_work has quit IRC | 13:10 | |
| *** vonnieda has quit IRC | 13:55 | |
| *** futarisIRCcloud has quit IRC | 14:06 | |
| *** wifasoi has joined #yosys | 14:21 | |
| *** vonnieda has joined #yosys | 14:24 | |
| *** emeb has joined #yosys | 14:27 | |
| *** rohitksingh has joined #yosys | 14:49 | |
| corecode | daveshah: thanks for committing | 14:52 |
| *** vonnieda has quit IRC | 14:55 | |
| *** vonnieda has joined #yosys | 14:56 | |
| emeb | corecode: so you're just waiting for clifford to approve the icestorm pr? | 15:11 |
| *** Laksen has joined #yosys | 15:35 | |
| corecode | yes | 15:59 |
| *** m4ssi has quit IRC | 16:10 | |
| *** dxld_ has joined #yosys | 16:15 | |
| *** dxld has quit IRC | 16:17 | |
| *** dxld_ is now known as dxld | 16:17 | |
| *** rohitksingh has quit IRC | 16:29 | |
| *** wifasoi has quit IRC | 16:41 | |
| *** dxld has quit IRC | 16:47 | |
| *** dxld has joined #yosys | 16:50 | |
| *** rohitksingh has joined #yosys | 17:00 | |
| *** maikmerten has joined #yosys | 17:19 | |
| maikmerten | heh, making Mandelbrot slow again: | 17:30 |
| maikmerten | https://paste.debian.net/1087268/ | 17:30 |
| tpb | Title: debian Pastezone (at paste.debian.net) | 17:30 |
| maikmerten | (my RV32I core @25.125 MHz, doing everything in soft-float) | 17:30 |
| emeb | Nice | 17:35 |
| emeb | maikmerten: what FPGA is that running on? | 17:38 |
| maikmerten | ice40 HX8K | 17:38 |
| maikmerten | about 1000 - 1100 LEs for the CPU | 17:38 |
| maikmerten | (of 7680) | 17:38 |
| maikmerten | with single-cycle shift operations, resource consumption goes up to about ~1300 LEs for the CPU | 17:39 |
| emeb | not bad. your own design for risc-v? | 17:39 |
| maikmerten | and then it renders in ~32000 ms | 17:39 |
| maikmerten | yup | 17:39 |
| emeb | fun | 17:39 |
| maikmerten | yes, indeed! | 17:39 |
| emeb | Just serial I/O for now? | 17:40 |
| maikmerten | no, it also has 640x480@16 colors VGA-signal output | 17:41 |
| maikmerten | but I haven't wired that mandelbrot renderer to the VGA framebuffer yet | 17:41 |
| emeb | doo eeet! | 17:41 |
| maikmerten | oh, I will. I will. | 17:42 |
| emeb | I imagine that will take some time tho ;) | 17:42 |
| emeb | (to render) | 17:43 |
| maikmerten | yes, and will also make the CPU ~20% slower | 17:43 |
| maikmerten | (because the VGA unit will steal every other RAM clock cycle when in active display region) | 17:43 |
| emeb | Hmm... | 17:43 |
| maikmerten | so that whole thing is pretty much like a Sinclair Spectrum: If you want to go fast, you have to disable display output ;-) | 17:44 |
| emeb | External RAM I suppose. | 17:44 |
| maikmerten | yes, 512kx8 SRAM | 17:45 |
| tnt | maikmerten: how much cycle per instruction do you use ? | 17:45 |
| emeb | Can't run the RAM interface @ 2x and interleave access? | 17:45 |
| maikmerten | emeb, in theory, yes. I don't trust such high-frequency operations over 2.54 mm pin headers, though. Also I don't trust my board design ;-) | 17:46 |
| maikmerten | tnt, oh, quite a lot, actually | 17:47 |
| maikmerten | I have a state diagram somewhere, wait a sec | 17:47 |
| emeb | maikmerten: should at least try - you may be pleasantly surprised. | 17:47 |
| maikmerten | tnt, https://imgur.com/a/gBZznrQ | 17:48 |
| tpb | Title: Imgur: The magic of the Internet (at imgur.com) | 17:48 |
| maikmerten | emeb, yeah :-) | 17:49 |
| maikmerten | the usual ALU-Ops work in fetch - decode - exec, so three states | 17:49 |
| maikmerten | (I do register writeback in fetch) | 17:50 |
| emeb | maikmerten: I've done SDR stuff @ 40-80MSPS over 2.54mm pin headers w/ Lattice & Xilinx parts on my own boards and it worked fine. | 17:50 |
| *** Laksen has quit IRC | 17:51 | |
| maikmerten | HOWEVER, my SRAM is 8 bits wide, instructions are 32 bit, so I need 4 accesses to SRAM - plus one cycle to get things moving. So 5 cycles are spent on fetch. So that is the bottleneck | 17:51 |
| maikmerten | emeb, ah, that's good to hear | 17:51 |
| maikmerten | emeb, my extension board design might be horrible, though: https://github.com/maikmerten/hx8k-breakout-extension | 17:52 |
| tpb | Title: GitHub - maikmerten/hx8k-breakout-extension: A PCB with SRAM, buttons, LEDs and some pmod-compatible connectors for the Lattice HX8K Breakout Board (at github.com) | 17:52 |
| maikmerten | signals look good on the oscilloscope, though | 17:52 |
| maikmerten | (and yes, one single pin-connector does not have enough signals for that SRAM, so I have to borrow signals from two) | 17:52 |
| emeb | maikmerten: what HX8k board are you using? | 17:54 |
| tnt | I pushed 300 Mbps though a 2.54mm connector not that long ago. | 17:55 |
| maikmerten | emeb, that one: https://www.mouser.de/ProductDetail/Lattice/ICE40HX8K-B-EVN?qs=ooqgTKD20drSds2K%2FEAnQg== | 17:55 |
| maikmerten | it's a wacky little board, with a lot of IO accessible. | 17:55 |
| emeb | indeed | 17:55 |
| maikmerten | currently on its way from asia is another extension board, which will give me another three pmod-ports (and one IR-receiver) | 17:57 |
| emeb | RAM is one of the reasons I prefer the iCE40 Ultra Plus over the HX, even though its got slower timing. | 17:58 |
| maikmerten | yeah, the embedded SPRAM is a big bonus | 17:58 |
| emeb | having 128kB on-chip makes small system design a whole lot easier. | 17:59 |
| maikmerten | indeed. | 17:59 |
| maikmerten | but I was hell-bent on 640x480 with at least 16 colors, so that doesn't fit | 17:59 |
| maikmerten | with 512kx8 I even have room for several framebuffers (err... exactly three), so I could do double-buffering if needed | 18:00 |
| emeb | Nice | 18:00 |
| emeb | tnt has an interesting video system in the works with lots of indirection that manages to do some nice hi-res color in minimal RAM using lots of maps and tiling. | 18:01 |
| maikmerten | (also allows for simple and zero-CPU scrolling: https://drive.google.com/open?id=1CbMtQZBxJyuepFnHBiFgf9rDobqatjGK ) | 18:02 |
| tpb | Title: vgascroll.mp4 - Google Drive (at drive.google.com) | 18:02 |
| emeb | That looks very nice | 18:02 |
| maikmerten | thanks. Horrible phone-video though. | 18:03 |
| maikmerten | yeah, with tiling or char-based graphics one can do wonderful things in very little RAM | 18:04 |
| maikmerten | (see GameBoy or basically any 8- or 16-bit video console) | 18:05 |
| maikmerten | https://www.youtube.com/watch?v=HyzD8pNlpwI <-- worth everyone's time | 18:05 |
| emeb | I've been working on an 800x600 VGA using 8x8 characters w/ 16 color fore/back selectable on a per-char basis. Full screen fits in < 16kB | 18:06 |
| maikmerten | oh, nice | 18:10 |
| maikmerten | I also have a primitive 40x30 text mode, 8x8 pixels per character, 8 bit color (split for fore- and background) | 18:11 |
| maikmerten | currently uploading a little demo | 18:11 |
| maikmerten | that one is reasonably fast ;-) | 18:11 |
| maikmerten | (upload takes forever) | 18:17 |
| maikmerten | (yeah consumer DSL) | 18:17 |
| emeb | heh | 18:17 |
| maikmerten | (~66% done) | 18:18 |
| emeb | I need to add a pixel-graphics mode to mine. It'll be just 1bpp and 400x300 to keep it fitting in the available RAM, but at least I can draw monochrome stuff. | 18:18 |
| maikmerten | yeah, that'd still be very useful | 18:19 |
| maikmerten | keep in mind the first Mac was 1bpp, too | 18:19 |
| emeb | True. You can do a lot w/ a bit of dithering. | 18:22 |
| tnt | I also tried temporal dithering, how it turns out highly depend on the screen. PC monitors tend to be fine. TVs ... not. | 18:31 |
| emeb | interesting. | 18:32 |
| maikmerten | non-optional Bad Apple demo: https://drive.google.com/file/d/1-6S2-pWhovTNroUEn83Zp2s6kCquv7ds/view | 18:34 |
| tpb | Title: badapple.mp4 - Google Drive (at drive.google.com) | 18:34 |
| emeb | cute. how did you get all that data into the FPGA? | 18:36 |
| maikmerten | emeb, there's a 32 MBit SPI-Flash device (that tiny board hanging onto the SRAM-extension board, visible at around ~0:40) | 18:37 |
| maikmerten | it's all character-based graphics, but the font is not hardcoded. The font is generated on my PC by reading in all frames, determining all 8x8 pixel blocks - and then doing k-means clustering | 18:39 |
| tnt | neat ! | 18:40 |
| maikmerten | so I basically have one 256-entry codebook, and every frame is 1200 bytes | 18:40 |
| maikmerten | but I compress that down with simple run-length encoding | 18:40 |
| emeb | amaze | 18:40 |
| tnt | Definitely would be interested to see that code :) | 18:40 |
| maikmerten | so on average every frame is about 280 bytes | 18:40 |
| emeb | haha | 18:41 |
| emeb | I guess that explains the "torn paper" edges. | 18:41 |
| maikmerten | heh | 18:41 |
| emeb | "art" | 18:41 |
| maikmerten | yes | 18:41 |
| maikmerten | it's basically very bad vector quantization, but in motion things end up being "fine-ish" | 18:42 |
| emeb | looks like your changing the color sometimes too | 18:43 |
| maikmerten | nope, I don't. Camera cleverness, I guess. | 18:43 |
| emeb | how does white balance work? :) | 18:44 |
| maikmerten | "badly" | 18:44 |
| maikmerten | tnt, oh, I can provide the code. It's horrible. | 18:46 |
| maikmerten | tnt, on a scale of evilness, it's about 8.79 metric Cthulus | 18:47 |
| emeb | lol | 18:48 |
| emeb | "Disclaimer: running this (or even looking at it too long) may invoke Old Gods" | 18:48 |
| tnt | lol | 18:48 |
| maikmerten | this is the player code that runs on the RV32I-CPU: https://paste.debian.net/1087282/ | 18:50 |
| tpb | Title: debian Pastezone (at paste.debian.net) | 18:50 |
| maikmerten | (eeek. Also, I'm not really a C guy. It is messy, but compact. I'm so sorry. So very very sorry.) | 18:50 |
| tnt | Doesn't really look that bad. | 18:51 |
| emeb | seems fine to me. | 18:52 |
| maikmerten | well, for instance, I think in 2019 one *could* use stuff like uint8_t and whatnot instead of char. | 18:53 |
| maikmerten | but I know the bittyness of the various types on RV32 and I don't plan for a port, so... lazy. | 18:53 |
| emeb | of all the things to worry about, that rates pretty low. | 18:54 |
| maikmerten | I also cast things around until GCC gives up complaining, so there's that | 18:55 |
| tnt | yeah sure, of course. and uint8_t works fine :p | 18:55 |
| tnt | For instance look at https://github.com/smunaut/ice40-playground/blob/usb-test/projects/riscv_usb/fw/spi.c#L31 | 18:56 |
| tpb | Title: ice40-playground/spi.c at usb-test · smunaut/ice40-playground · GitHub (at github.com) | 18:56 |
| tnt | and a few lines later the definition of spi_regs | 18:56 |
| *** rohitksingh has quit IRC | 18:57 | |
| tnt | this is how I do hw registers now and it works and maps fine without any overhead vs directly doing the lenghty *((volatile char*)REG_ADDRESS) | 18:57 |
| maikmerten | heh | 18:57 |
| maikmerten | oh, and the compressor that compresses the animation is written in Java. Anyone really wants to see *that* code? | 18:59 |
| tnt | hehe, sure. | 18:59 |
| maikmerten | eeek. | 18:59 |
| tnt | Although I don't really like most implementations of java, I actually find the language pretty nice. Haven't used it in forever but I loved the concept of interface / implemtation and also the fact it came with a standard lib that was actually useful. | 19:00 |
| tnt | Compared to other languages at the time, I think it was nice. | 19:00 |
| tnt | btw, I found that talk interesting https://www.youtube.com/watch?v=zBkNBP00wJE using modern C++ constructs for small cpu without overhead :) | 19:02 |
| maikmerten | tnt, here you go: https://paste.debian.net/1087286/ | 19:02 |
| tpb | Title: debian Pastezone (at paste.debian.net) | 19:02 |
| maikmerten | the pain starts... NOW! | 19:02 |
| tnt | interesting way to ship files :p | 19:03 |
| emeb | rofl | 19:03 |
| maikmerten | hehe | 19:03 |
| maikmerten | it's inspired by some RFC file attachements | 19:04 |
| maikmerten | for instance, for the Opus audio codec, the reference implementation is enclosed as base64-encoded tarball | 19:04 |
| tnt | you have audio in that demo as well ? | 19:05 |
| maikmerten | tnt, not yet | 19:07 |
| maikmerten | I have vague plans of doing PWM-based audio output | 19:07 |
| maikmerten | (in the FPGA) | 19:07 |
| maikmerten | but I first need to construct a lowpass-thingie that turns that into something non-horrible | 19:08 |
| corecode | tnt: thanks | 19:08 |
| emeb | maikmerten: that's easy. | 19:08 |
| maikmerten | the ADPCM-decoder in that tarball is just to demonstrate to myself that I understand how to decode that audio | 19:09 |
| *** develonepi3 has quit IRC | 19:09 | |
| tnt | corecode: for what ? | 19:09 |
| tnt | (I mean, I'll take it, but ... still I wonder) | 19:09 |
| maikmerten | (so the audio would be ADPCM-compressed, decoded by the RV32 CPU, and then written to a PWM output) | 19:09 |
| tnt | maikmerten: make it PDM rather than PWM :) | 19:10 |
| maikmerten | emeb, I think I should construct a Butterworth lowpass | 19:10 |
| maikmerten | tnt, PDM? | 19:10 |
| tnt | Pulse Density Modulation. AKA Delta Sigma. | 19:10 |
| maikmerten | ah, k | 19:11 |
| tnt | https://github.com/smunaut/ice40-playground/blob/usb-test/cores/misc/rtl/pdm.v | 19:11 |
| maikmerten | I should research into that | 19:11 |
| tpb | Title: ice40-playground/pdm.v at usb-test · smunaut/ice40-playground · GitHub (at github.com) | 19:11 |
| tnt | Basically this pushes the noise at much higher frequencies than PWM, making it easier to filter out. | 19:11 |
| maikmerten | ah, neat | 19:12 |
| maikmerten | thanks | 19:12 |
| tnt | and in FPGA you can do PDM just as easy as PWM. | 19:12 |
| corecode | tnt: the video | 19:12 |
| tnt | In microcontroller usually not ... they have pwm peripheral but not pdm. | 19:12 |
| tnt | corecode: Ah oki :) Yeah it's fun stuff. | 19:12 |
| maikmerten | yeah, the idea of using PWM is basically µC-inspired | 19:13 |
| maikmerten | for instance, how the RPi handles its audio | 19:13 |
| maikmerten | (well, that is not a µC) | 19:13 |
| maikmerten | but if PDM pushes the noise much higher, then I can get away with a less steep lowpass | 19:14 |
| tnt | Exactly :) | 19:14 |
| maikmerten | perhaps RC or whatever | 19:14 |
| tnt | Yeah and if you have 45 min to waste you can listen to my rambling about tricks to increase precisions and lower noise even more : https://www.youtube.com/watch?v=2pAy5DvuidA | 19:18 |
| maikmerten | subscribed. | 19:19 |
| tnt | Heh thanks :) | 19:22 |
| maikmerten | btw, this is my very safe proposal for a Steam-replacement: https://paste.debian.net/1087287/ | 19:24 |
| tpb | Title: debian Pastezone (at paste.debian.net) | 19:24 |
| maikmerten | (contains a game. It's harmless.) | 19:25 |
| maikmerten | but somehow people freak out when I just append an autostart feature. Dunnowhy ;-) | 19:25 |
| maikmerten | (small board game, with AI) | 19:26 |
| tnt | maikmerten: fun :) Did you port it to your riscv ? | 19:36 |
| maikmerten | tnt, yup | 19:37 |
| maikmerten | that's why on normal environments it needs -DSTDLIB to build | 19:37 |
| maikmerten | (using proper functions instead of my wacky input stuff) | 19:38 |
| tnt | yeah, I suspected :p | 19:38 |
| maikmerten | I originally wrote it for the Commodore 64 | 19:38 |
| maikmerten | (yes, in C) | 19:38 |
| maikmerten | (which is why comments refer to multiple files) | 19:39 |
| maikmerten | there's nothing neater than a 1 MHz machine outsmarting people (in that particular scenario) | 19:39 |
| tnt | :) | 19:39 |
| maikmerten | https://csdb.dk/release/?id=130405 <-- there | 19:40 |
| tpb | Title: [CSDb] - Nuclear Reaction 2100 by Really Proud Lamers (2014) (at csdb.dk) | 19:40 |
| tnt | Oh nice. I never had a C64 (although I've been watching a lot of retro video on yt recently which included a lot of c64 stuff :p) | 19:43 |
| cr1901_modern | maikmerten: This game of yours stole my passwords and drained my bank accounts :( | 19:46 |
| maikmerten | that's unfortunate. Sorry. | 19:50 |
| cr1901_modern | :P | 19:52 |
| *** togo has joined #yosys | 20:01 | |
| *** maikmerten has quit IRC | 20:52 | |
| emeb | tnt: interesting looking at your pdm.v module vs the way I did it. | 20:57 |
| emeb | your acc preserves the overflow bit from one cycle to the next - mine always resets it. | 20:57 |
| emeb | mine sounds fine though, so I'm curious about the difference. | 20:57 |
| tnt | I'm not sure there is one because I add { acc[WIDTH], in } .... so that bit will always be reset if it's one. | 20:58 |
| emeb | Ah ok. | 20:59 |
| emeb | Seems the do the same thing, just via slightly different syntax. | 20:59 |
| tnt | yeah :) | 20:59 |
| emeb | Do you notice much difference in audio quality w/ dither turned on? | 21:01 |
| tnt | emeb: I have not used it for sound | 21:01 |
| emeb | tnt: just for a DAC for generating control voltages? | 21:02 |
| tnt | yup | 21:02 |
| tnt | at some point I want to try and write a small sound core but didn't get to it yet .. | 21:04 |
| emeb | the one I did is pretty simple - fun thing is you can sum multiple channels into a single Sigma-Delta acc. | 21:05 |
| emeb | mixes just fine. | 21:06 |
| *** vonnieda has quit IRC | 22:14 | |
| *** vonnieda has joined #yosys | 22:14 | |
| *** vonnieda has quit IRC | 22:38 | |
| *** togo has quit IRC | 22:59 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!