| *** tpb has joined #yosys | 00:00 | |
| *** seldridge has joined #yosys | 00:03 | |
| *** digshadow has quit IRC | 00:14 | |
| *** promach_ has joined #yosys | 00:25 | |
| *** digshadow has joined #yosys | 00:45 | |
| *** dxld has quit IRC | 00:55 | |
| *** dxld has joined #yosys | 00:57 | |
| *** m_w has quit IRC | 01:43 | |
| promach_ | $global_clock is the same as smt_clk , right ? | 02:05 |
|---|---|---|
| promach_ | smt_clock | 02:05 |
| *** promach_ has quit IRC | 02:20 | |
| *** promach_ has joined #yosys | 02:21 | |
| ZipCPU | emeb_mac: It's pipelined. That part isn't configurable. However, you can configure the size of the FFT, the number of bits in the input, the number of bits in the output, the number of multiplies used, whether or not the FFT is to accept two samples per clock, 1 sample per clock, 1 sample every two clocks, or 1 sample every three clocks. | 02:59 |
| ZipCPU | Beyond that, the FFT is limited by your hardware ... | 03:00 |
| ZipCPU | and by the fact that the updates I'm working through aren't (yet) working. So ... without the new updates that I'm working on, the FFT only does 2 samples per clock plus the other configurables. | 03:01 |
| emeb_mac | ZipCPU: sounds pretty useful. | 03:11 |
| ZipCPU | The 1 clock per sample and the 2 clocks per sample just passed my test at 2048 points! Yaaay ... (3 clocks per sample still fails) | 03:11 |
| ZipCPU | Oh, and thanks! | 03:12 |
| emeb_mac | the radio I'm working on now needs two 1024-pt 16-bit in/out transforms for the RX and a 2048 16 in/out on the TX. | 03:12 |
| emeb_mac | we're using the Xilinx IP core for these and we've been pretty luck that they are working well | 03:13 |
| emeb_mac | (other IP cores from Xilinx have turned out to be disasters) | 03:13 |
| ZipCPU | ;) Yeah, the Xilinx cores seem to be reliable enough. | 03:15 |
| ZipCPU | Once mine start working, they'll still need some tuning and optimization to match what Xilinx has done ... if I can do it at all. | 03:16 |
| emeb_mac | ZipCPU: that's strong competition - they've got good performance and well optimized resource usage. | 03:17 |
| ZipCPU | Exactly. Like I said, I don't know if I'll make a good showing in the end there, but at least what I have will work. | 03:17 |
| emeb_mac | IIRC the 1kpt transforms we use require only 18 of the MAC cores | 03:18 |
| ZipCPU | Let's see ... in the one I'm doing, you can tell it how many DSP cores you have. If you go full bore, 1 sample per clock, you'll need (10-2)*3 = 24 multiplies. | 03:19 |
| ZipCPU | You could do it for less, at the cost of more LUT's. | 03:19 |
| ZipCPU | On the other hand, if you want 2 clocks per sample, it would take (10-2)*2 = 16 multiplies, or if you want 3 clocks per sample it will take 8 multiplies. | 03:20 |
| emeb_mac | That's not bad | 03:20 |
| ZipCPU | On the other hand, if you are doing two samples per clock, then you'll want (10-2)*6 = 48 multiplies. It's all a tradeoff. | 03:21 |
| ZipCPU | The soft multiply option isn't all that efficient though. I've got a slower option that's more efficient still, and I've thought of integrating that one in later. | 03:22 |
| ZipCPU | The current soft multiply used is fully pipelined, so ... it requires a lot of flip flops and luts at every stage of the multiply. | 03:22 |
| emeb_mac | Nice to have the option for soft multiplies | 03:24 |
| ZipCPU | Yep! | 03:25 |
| promach_ | ZipCPU: which soft multiply are you referring to ? | 03:25 |
| ZipCPU | What do you mean? | 03:25 |
| promach_ | you have your own multiply algo ? | 03:25 |
| ZipCPU | Yes. | 03:25 |
| emeb_mac | I try to avoid FPGAs w/o some hard multiplier resources for DSP stuff, but sometimes you gotta go with what's available | 03:26 |
| promach_ | wallace, Is uppose ? | 03:26 |
| ZipCPU | It's a basic shift/add multiply, nothing fancy in this case. | 03:26 |
| promach_ | ok | 03:26 |
| ZipCPU | I've built a wallace before, but ... the FFT doesn't use it. | 03:26 |
| ZipCPU | Ok, 1, 2, and 3 clocks per sample now works using hardware multiplies, time to double check the soft multiplies | 03:31 |
| emeb_mac | so does 1clk/sample allow continuous feed w/o any gaps? | 03:34 |
| ZipCPU | Yes. | 03:34 |
| ZipCPU | You can also feed it with unpredictable gaps too. | 03:34 |
| emeb_mac | roughly what latency do you see from input to output? | 03:35 |
| ZipCPU | Depends on the size of the FFT. Curious about a 1k FFT? I can go measure that. | 03:35 |
| emeb_mac | yeah! | 03:35 |
| ZipCPU | Looks like about 4176 clocks from the start of the first frame going in to the start of the first output frame. | 03:38 |
| *** AlexDaniel has quit IRC | 03:38 | |
| *** seldridge has quit IRC | 03:39 | |
| *** AlexDaniel has joined #yosys | 03:39 | |
| ZipCPU | There's probably a couple clocks in there I could whittle out if latency was an issue, but that's what it is currently. | 03:39 |
| emeb_mac | That's not bad. | 03:39 |
| ZipCPU | Are you looking for low latency? | 03:39 |
| emeb_mac | Generally yes - these radio designs tend to have fairly long datapaths with lots of things going on in them. | 03:40 |
| ZipCPU | I'm not quite sure how I would, or if I would, redesign things for lower latency. | 03:43 |
| emeb_mac | IIRC the cores we use have about 3k clocks latency. I don't think 4k would be a huge disadvantage tho | 03:44 |
| ZipCPU | Hmm ... not sure where I'd find a full 1k latency from this design .... | 03:45 |
| ZipCPU | Sure, there's a clock or two in each stage, but at ten stages that'd be at most 20 clocks. | 03:45 |
| emeb_mac | Well, you're ahead of me. I've never thought too much about how to build an FFT. | 03:46 |
| emeb_mac | about 20 years ago a guy I shared an office with architected one as a single-chip ASIC so I've only had peripheral exposure to it from discussing w/ him. | 03:47 |
| ZipCPU | :) | 03:48 |
| ZipCPU | I suppose I might go faster if I did something other than a Radix two FFT ... | 03:48 |
| * ZipCPU tugs at his beard | 03:48 | |
| emeb_mac | Aha - that must be it. Radix-4 was part of the optimization he did on his. | 03:48 |
| ZipCPU | I might have to look into that in the future. | 03:50 |
| ZipCPU | For now, I just want to get it running in the first place. | 03:51 |
| ZipCPU | I'm pretty close, but ... not all cases work (yet) | 03:51 |
| *** ar3itrary has quit IRC | 04:08 | |
| *** ar3itrary has joined #yosys | 04:13 | |
| *** AlexDaniel has quit IRC | 04:21 | |
| *** AlexDaniel has joined #yosys | 04:22 | |
| *** ar3itrary has quit IRC | 04:29 | |
| *** ar3itrary has joined #yosys | 04:36 | |
| cr1901_modern | FFT was one of those things where I had to derive "how it works" exactly once and now I don't remember how to do it :(. I know you can split into bins by time or frequency (either works), but Idk if any way is better | 04:52 |
| *** emeb_mac has quit IRC | 05:30 | |
| *** xerpi has joined #yosys | 06:25 | |
| *** marbler has quit IRC | 06:27 | |
| *** jfng has quit IRC | 06:27 | |
| *** samayra has quit IRC | 06:27 | |
| *** indefini has quit IRC | 06:27 | |
| *** nrossi has quit IRC | 06:27 | |
| *** lok[m] has quit IRC | 06:27 | |
| *** swick has quit IRC | 06:27 | |
| *** pointfree1 has quit IRC | 06:28 | |
| *** Guest18568 has quit IRC | 06:28 | |
| *** fevv8[m] has quit IRC | 06:28 | |
| *** weebull[m] has quit IRC | 06:28 | |
| *** cr1901_modern1 has joined #yosys | 06:31 | |
| *** cr1901_modern1 has quit IRC | 06:33 | |
| *** cr1901_modern has quit IRC | 06:33 | |
| *** cr1901_modern1 has joined #yosys | 06:34 | |
| *** cr1901_modern1 has quit IRC | 06:34 | |
| *** cr1901_modern has joined #yosys | 06:34 | |
| *** promach_ has quit IRC | 06:35 | |
| *** promach_ has joined #yosys | 06:36 | |
| *** cr1901_modern has quit IRC | 06:43 | |
| *** cr1901_modern has joined #yosys | 06:44 | |
| *** samayra has joined #yosys | 07:41 | |
| *** promach_ has quit IRC | 07:43 | |
| *** Guest16831 has joined #yosys | 08:24 | |
| *** lok[m] has joined #yosys | 08:24 | |
| *** jfng has joined #yosys | 08:24 | |
| *** fevv8[m] has joined #yosys | 08:24 | |
| *** pointfree1 has joined #yosys | 08:24 | |
| *** swick has joined #yosys | 08:24 | |
| *** marbler has joined #yosys | 08:24 | |
| *** indefini has joined #yosys | 08:24 | |
| *** nrossi has joined #yosys | 08:24 | |
| *** weebull[m] has joined #yosys | 08:24 | |
| *** indy has quit IRC | 08:34 | |
| *** promach_ has joined #yosys | 08:45 | |
| *** pie_ has quit IRC | 09:56 | |
| *** dys has joined #yosys | 10:37 | |
| *** indy has joined #yosys | 10:45 | |
| *** m_t has joined #yosys | 12:50 | |
| *** emeb_mac has joined #yosys | 15:00 | |
| emeb_mac | ZipCPU: You've spoken before about the difficulty of applying formal to multipliers. Would it be a safe assumption that formal is generally not practical for DSP datapaths which rely heavily on math operations like multiplication / division / transformation? | 15:02 |
| ZipCPU | Yes and no .... there are some ways around the problems. | 15:02 |
| emeb_mac | I get the impression that the best way to apply formal in these types of designs is to partition complex control logic out and apply formal at the unit level. | 15:02 |
| ZipCPU | I've had mixed success with data paths including multiplication or division. | 15:02 |
| * ZipCPU rummages through his designs for an example .... | 15:03 | |
| ZipCPU | Here's an example of an FIR filter (multiplies and all) where I manage to formally verify that the impulse response is correct using an abstract multiply: https://github.com/ZipCPU/dspfilters/blob/master/rtl/fastfir.v | 15:04 |
| tpb | Title: dspfilters/fastfir.v at master · ZipCPU/dspfilters · GitHub (at github.com) | 15:04 |
| ZipCPU | You might find the abstract multiply a fascinating read in and of itself: https://github.com/ZipCPU/dspfilters/blob/master/bench/formal/abs_mpy.v | 15:05 |
| tpb | Title: dspfilters/abs_mpy.v at master · ZipCPU/dspfilters · GitHub (at github.com) | 15:05 |
| emeb_mac | Interesting. | 15:06 |
| emeb_mac | Would you call that exercise difficult? I have very little basis for comparison, but it seems somewhat contorted compared to simply running a stimulus / response simulation. Does it provide you with significantly more confidence in the design than a simpler approach? | 15:09 |
| ZipCPU | Not sure. | 15:20 |
| ZipCPU | Let's just say that, in this example, the jury is still out. | 15:20 |
| ZipCPU | Consider this, I'm working with a perfect example right now ... I have 6 types of code for a butterfly. Three use DSP elements, three do not. | 15:21 |
| ZipCPU | The three that use DSP elements work, the three that do not ... don't. | 15:21 |
| ZipCPU | I'm trying to find out why. | 15:21 |
| ZipCPU | If I try to apply formal methods to those other three right now, the formal methods don't complete. The multiply is just too difficult for them. | 15:21 |
| ZipCPU | Even when I bring it down to a three bit multiply they are struggling. | 15:22 |
| ZipCPU | For example, one of those soft multiply-based butterflies has now run its formal proof for over 12 hours, and has only made it to state 14 of 30. | 15:23 |
| ZipCPU | On the other hand, the two butterflies that didn't require hardware multiplies could be formally verified quite quickly. | 15:25 |
| awygle | iceradio continues to look awesome, btw | 15:33 |
| ZipCPU | http://www.iceradio.ca ? | 15:37 |
| promach_ | Can https://github.com/ZipCPU/dspfilters/blob/master/bench/formal/abs_mpy.v actually multiply ? why "abstract" ? | 15:43 |
| tpb | Title: dspfilters/abs_mpy.v at master · ZipCPU/dspfilters · GitHub (at github.com) | 15:43 |
| ZipCPU | It's abstract because it's not really a multiply, but yet it still maintains many of the properties of a multiply. | 15:43 |
| ZipCPU | The idea behind abstraction is that if (AB)->C and I can prove that A->C irrespective of B, then I've proved AB->C as well. | 15:46 |
| ZipCPU | It's useful in those cases where B is really hard to express or work with. | 15:46 |
| emeb_mac | awygle: Thanks! I haven't done much with it for the last year due to $DAYJOB getting in the way, but I've got plans for more features. | 15:54 |
| emeb_mac | ZipCPU: Thanks for the insight. | 15:56 |
| *** m_t has quit IRC | 15:59 | |
| *** dxld has quit IRC | 16:01 | |
| *** dxld has joined #yosys | 16:02 | |
| *** dxld has quit IRC | 16:12 | |
| *** dxld has joined #yosys | 16:14 | |
| *** luismarques has joined #yosys | 16:15 | |
| awygle | The biggest upgrade to the iceradio for my purposes would be a lower power adc. I can't afford 73mW :-( | 16:16 |
| awygle | But the DSP is the hard part from my perspective, I can always replace the afe if I decide to do something with it | 16:17 |
| awygle | Oh it's actually much more. Idk what adc I was looking at lol | 16:19 |
| *** emeb_mac has quit IRC | 16:26 | |
| *** luismarques has quit IRC | 17:38 | |
| *** luismarques has joined #yosys | 17:39 | |
| *** promach_ has quit IRC | 17:40 | |
| *** luismarques has quit IRC | 17:46 | |
| *** luismarques has joined #yosys | 17:48 | |
| *** dxld has quit IRC | 17:49 | |
| *** dxld has joined #yosys | 17:49 | |
| *** xerpi has quit IRC | 18:02 | |
| *** luismarques has quit IRC | 18:04 | |
| cr1901_modern | ZipCPU: I think awygle means this: http://ebrombaugh.studionebula.com/radio/iceRadio/index.html | 18:09 |
| tpb | Title: iceRadio (at ebrombaugh.studionebula.com) | 18:09 |
| cr1901_modern | it does look cool. Idk what I could do w/ it tho | 18:10 |
| awygle | cr1901_modern is correct | 18:10 |
| ZipCPU | Thanks, that makes a lot more sense than the other. | 18:10 |
| cr1901_modern | I've had my ham radio license since the end of 2013; I've made like 4 or so contacts b/c I don't like voice all that much, and there's little to no digital activity | 18:12 |
| *** luismarques has joined #yosys | 18:16 | |
| *** luismarques has quit IRC | 18:21 | |
| *** luismarques has joined #yosys | 18:51 | |
| *** pie_ has joined #yosys | 19:05 | |
| *** luismarques has quit IRC | 19:12 | |
| *** proteus-guy has quit IRC | 19:16 | |
| *** X-Scale has joined #yosys | 19:27 | |
| *** proteus-guy has joined #yosys | 19:28 | |
| *** luismarques has joined #yosys | 19:37 | |
| *** luismarques has quit IRC | 19:42 | |
| *** luismarques has joined #yosys | 19:47 | |
| *** digshadow has quit IRC | 19:57 | |
| *** luismarques has quit IRC | 20:04 | |
| *** m_w has joined #yosys | 20:06 | |
| *** luismarques has joined #yosys | 20:31 | |
| *** luismarques has quit IRC | 20:37 | |
| *** sklv has quit IRC | 20:40 | |
| *** sklv has joined #yosys | 20:41 | |
| *** luismarques has joined #yosys | 20:43 | |
| *** sklv has quit IRC | 20:46 | |
| *** luismarques has quit IRC | 20:48 | |
| *** luismarques has joined #yosys | 20:56 | |
| *** [X-Scale] has joined #yosys | 21:04 | |
| *** X-Scale has quit IRC | 21:06 | |
| *** [X-Scale] is now known as X-Scale | 21:06 | |
| *** luismarques has quit IRC | 21:13 | |
| *** emeb_mac has joined #yosys | 21:19 | |
| *** sklv has joined #yosys | 21:28 | |
| *** digshadow has joined #yosys | 21:29 | |
| *** luismarques has joined #yosys | 21:34 | |
| *** luismarques has quit IRC | 21:42 | |
| *** dys has quit IRC | 21:45 | |
| *** luismarques has joined #yosys | 21:51 | |
| *** luismarques has quit IRC | 21:58 | |
| *** luismarques has joined #yosys | 22:03 | |
| *** luismarques has quit IRC | 22:11 | |
| *** luismarques has joined #yosys | 22:12 | |
| *** luismarques has quit IRC | 22:25 | |
| *** luismarques has joined #yosys | 22:29 | |
| *** luismarques has quit IRC | 22:34 | |
| *** m_w has quit IRC | 22:35 | |
| *** luismarques has joined #yosys | 22:38 | |
| *** ar3itrary has quit IRC | 22:38 | |
| *** digshadow has quit IRC | 22:39 | |
| *** luismarques has quit IRC | 22:43 | |
| *** m_w has joined #yosys | 22:43 | |
| *** luismarques has joined #yosys | 22:49 | |
| *** X-Scale has quit IRC | 23:05 | |
| *** luismarques has quit IRC | 23:10 | |
| *** X-Scale has joined #yosys | 23:11 | |
| *** seldridge has joined #yosys | 23:12 | |
| *** luismarques has joined #yosys | 23:14 | |
| *** luismarques has quit IRC | 23:22 | |
| *** luismarques has joined #yosys | 23:23 | |
| *** luismarques has quit IRC | 23:40 | |
| *** luismarques has joined #yosys | 23:41 | |
| *** promach_ has joined #yosys | 23:46 | |
| *** luismarques has quit IRC | 23:51 | |
| *** luismarques has joined #yosys | 23:56 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!