| *** tpb has joined #yosys | 00:00 | |
| *** promach__ has joined #yosys | 00:25 | |
| *** emeb_mac has joined #yosys | 00:32 | |
| *** promach__ has quit IRC | 01:04 | |
| *** digshadow has left #yosys | 01:24 | |
| *** digshadow has joined #yosys | 01:24 | |
| *** seldridge0 has quit IRC | 01:26 | |
| emeb_mac | ZipCPU: Nice blog on filters | 01:28 |
|---|---|---|
| ZipCPU | Thanks! | 01:28 |
| emeb_mac | I've designed so many DSP pipelines that this kind of stuff is 2nd nature, but that doesn't mean it can't have rough spots. | 01:29 |
| emeb_mac | Just wrapped up HDL design work on a big OFDM receiver - there were some "fun" bits in that. A frequency domain equalizer with all kinds of memory and feedback that took me nearly a month to get working... | 01:30 |
| awygle | dang, that's impressive. ofdm is scary | 01:31 |
| ZipCPU | ... Still working on my FFT here ... | 01:31 |
| emeb_mac | Oh fun! | 01:31 |
| ZipCPU | Once the FFT is done, the rest of any OFDM design should be fairly easy in comparison. | 01:31 |
| ZipCPU | ;) | 01:31 |
| emeb_mac | We just plopped down IP cores from the FPGA vendor. | 01:31 |
| awygle | i did a DSSS receiver once and the hardest part was locking to the code | 01:32 |
| ZipCPU | awygle: Yep! Now, knowing what I do, I could probably do a DSSS receiver a lot cheaper than the last one I did ... | 01:32 |
| emeb_mac | Not really much point in putting effort into the FFT when the vendor core is free and well optimized & debugged. | 01:32 |
| awygle | ZipCPU: if i ever get back into the satellite radio market, i'll give you a call ;) | 01:33 |
| ZipCPU | :) | 01:33 |
| ZipCPU | emeb_mac: To each their own calling. | 01:33 |
| awygle | i have like 75% of a design for a quarter-watt couple-MHz SDR board for cubesats | 01:33 |
| emeb_mac | ZipCPU: if you're having fun :) | 01:33 |
| awygle | but my business fell apart before i had reason to pull the trigger on it | 01:33 |
| emeb_mac | ZipCPU: and FWIW - there's a lot more to a successful OFDM system than just the FFT. | 01:34 |
| ZipCPU | emeb_mac: There's more to it than just that. I keep seeing students trying to figure out why the proprietary vendor design isn't doing what they are expecting. A nice clear open source design would therefore be valuable for understanding what's going on under the hood. | 01:34 |
| ZipCPU | emeb_mac: Well said, well said. | 01:34 |
| emeb_mac | and yeah - having access to source is a good thing | 01:35 |
| emeb_mac | On a previous project we had the option of building or buying an LDPC decoder and decided to build it in house. | 01:35 |
| ZipCPU | I mean .... even if the design component works, sometimes it helps to trace through it to understand why your wrapper isn't working. | 01:35 |
| emeb_mac | It was hard but we learned a lot. | 01:35 |
| ZipCPU | Oooohh ... LDPC, that's a fun one. | 01:35 |
| emeb_mac | Yeah | 01:36 |
| awygle | LDPC is super cool | 01:36 |
| awygle | another good satellite tech | 01:36 |
| emeb_mac | It took a while but actually was cheaper than buying. | 01:36 |
| ZipCPU | The last FEC decoder I built in Verilog was a product code, quite a fun challenge. | 01:36 |
| emeb_mac | because the folks selling them want arm + leg. | 01:36 |
| ZipCPU | Well, if it works, it might just be worth both arms and legs ... just to spare you the hassle of finding the bugs in your own. | 01:37 |
| emeb_mac | OTOH, for this project we needed a rate 1/2 Viterbi decoder and didn't want to waste effort on that so we just bought the Xilinx core. | 01:37 |
| sorear | It would be nice if you could assume commercial IP was bug-free | 01:38 |
| ZipCPU | Heheh ... I remember building a 1/2 rate Viterbi decoder--wasn't in Verilog though. C++ instead. | 01:38 |
| ZipCPU | sorear: Don't steal my innocence, please. :D | 01:38 |
| emeb_mac | There's a lot of open source code for that stuff. | 01:38 |
| emeb_mac | We had a project that needed a BCH decoder and found one written in Verilog. | 01:39 |
| emeb_mac | Converted it to our own favorite VHDL and it worked fine. | 01:39 |
| awygle | i wrote a BCH encoder in C recently | 01:39 |
| awygle | it really annoys me when FEC people don't pubish test vectors | 01:39 |
| emeb_mac | heh | 01:39 |
| ZipCPU | Aw, come on ... it's just a linear system. | 01:40 |
| awygle | like "i'm TRYING to be compatible to your stupid standard, throw me a bone here!" | 01:40 |
| ZipCPU | Pick your favorite basis set and go. That should be sufficient. | 01:40 |
| awygle | CRCs are the worst this way, historically lol | 01:40 |
| emeb_mac | https://github.com/russdill/bch_verilog | 01:40 |
| tpb | Title: GitHub - russdill/bch_verilog: Verilog based BCH encoder/decoder (at github.com) | 01:40 |
| ZipCPU | Yeah, okay, I'll grant you CRC's. There are just too many implementations of them. Do they start with the zero state or the ones state, do you xor the result with zeros or ones when done, which way do the bits go in, etc. | 01:41 |
| emeb_mac | I know Russ from elsewhere on IRC and actually sent him some bugfixes we found while using his stuff. | 01:41 |
| ZipCPU | I've wanted to blog about how formal can help doing CRC's for ethernet, but ... haven't gotten that far. Really makes building them easy. | 01:41 |
| emeb_mac | I'll bet | 01:41 |
| emeb_mac | CRCs are interesting - we're using some in the OFDM project | 01:42 |
| ZipCPU | Heh ... it's even easier when you control the whole link. | 01:42 |
| emeb_mac | yes, very. | 01:42 |
| emeb_mac | match up the tx & rx. done. | 01:42 |
| emeb_mac | but then we model *everything* in Matlab before starting to code HDL | 01:43 |
| emeb_mac | so we know what's going to happen up front. | 01:43 |
| ZipCPU | Well, why not? It's often faster and easier to do so. | 01:43 |
| emeb_mac | yes | 01:43 |
| ZipCPU | What I don't get are the newbies that try to build something really complex without first understanding the technology. | 01:43 |
| emeb_mac | and since we don't grok formal, all our testing is vector-based with references from the Matlab sim | 01:44 |
| ZipCPU | They then get confused as to why it doesn't work. You ask about their pre RTL simulation, and just get blank looks. | 01:44 |
| emeb_mac | lol | 01:44 |
| emeb_mac | yes - we see that too | 01:44 |
| ZipCPU | Formally verifying an FIR filter was a fun challenge. Not your typical formal proof. | 01:44 |
| emeb_mac | so many of our customers just start out throwing HDL at the wall | 01:44 |
| emeb_mac | no verification process at all | 01:45 |
| emeb_mac | "we can debug on the bench - FPGAs make it easy!" | 01:45 |
| ZipCPU | Lol! | 01:45 |
| emeb_mac | When an edit/compile/test cycle takes 2 hours, you can't get much debugging done in a workday. | 01:45 |
| emeb_mac | I use Matlab to generate stimulus / response (with fixed-point implementation code) for the entire datapath. | 01:47 |
| emeb_mac | then we unit test each step in the path and end-to-end after integration | 01:47 |
| ZipCPU | Yeah ... but you can do a *lot* of blogging during that time! | 01:47 |
| emeb_mac | haha | 01:47 |
| emeb_mac | or watch cat videos! | 01:48 |
| ZipCPU | Been there, done that, blogging increases my code quality, cat videos don't. | 01:48 |
| awygle | or play fetch with the cat | 01:48 |
| ZipCPU | Fooseball anyone? | 01:48 |
| awygle | cat doesn't know how to play that yet | 01:49 |
| ZipCPU | The other fun alternative here is to distract the security officer. | 01:50 |
| emeb_mac | heh - work from home. no security officer. | 01:50 |
| ZipCPU | She's works for a "Shepherd Security Services" firm. It's a German company. | 01:50 |
| emeb_mac | lol | 01:51 |
| emeb_mac | Tacos al pastor Aleman | 01:51 |
| *** digshadow has quit IRC | 02:09 | |
| *** seldridge0 has joined #yosys | 02:19 | |
| *** digshadow has joined #yosys | 02:26 | |
| *** digshadow has quit IRC | 02:35 | |
| *** develonepi3 has quit IRC | 02:41 | |
| *** digshadow has joined #yosys | 02:50 | |
| *** digshadow has quit IRC | 03:00 | |
| *** maartenBE has quit IRC | 03:09 | |
| *** maartenBE has joined #yosys | 03:10 | |
| *** digshadow has joined #yosys | 03:21 | |
| *** seldridge0 has quit IRC | 04:48 | |
| *** dys has quit IRC | 05:40 | |
| *** indy has quit IRC | 06:29 | |
| *** promach_ has quit IRC | 06:31 | |
| *** indy has joined #yosys | 06:33 | |
| *** GuzTech has joined #yosys | 07:06 | |
| *** emeb_mac has quit IRC | 07:38 | |
| *** leviathan has joined #yosys | 07:54 | |
| mattvenn | ZipCPU: re: What I don't get are the newbies that try to build something really complex without first | 08:09 |
| mattvenn | I think it's because when someone doesn't understand something, they don't understand how hard it will be | 08:09 |
| mattvenn | so they are apt to choose projects well beyond their abilitites | 08:09 |
| mattvenn | but it's not necessarily a bad thing if they have patience and a lot of time | 08:09 |
| *** promach_ has joined #yosys | 08:23 | |
| *** knielsen has quit IRC | 08:27 | |
| *** knielsen has joined #yosys | 08:33 | |
| *** promach_ has quit IRC | 09:42 | |
| *** leviathan has quit IRC | 11:33 | |
| *** cemerick has joined #yosys | 11:56 | |
| *** cemerick_ has joined #yosys | 12:06 | |
| *** cemerick has quit IRC | 12:09 | |
| *** develonepi3 has joined #yosys | 12:28 | |
| *** cemerick has joined #yosys | 12:39 | |
| *** cemerick_ has quit IRC | 12:42 | |
| *** eduardo__ has joined #yosys | 12:43 | |
| *** eduardo_ has quit IRC | 12:47 | |
| *** cemerick_ has joined #yosys | 13:05 | |
| *** cemerick has quit IRC | 13:09 | |
| *** dmin7 has joined #yosys | 13:11 | |
| dmin7 | route time 2089.26s | 13:11 |
| dmin7 | :s | 13:12 |
| ZipCPU | dmin7: Which chip? And ... how full was the design? | 13:37 |
| dmin7 | pretty full x) LCs 6628 / 7680 | 13:55 |
| dmin7 | i'm back to 160s now tho, all good | 13:56 |
| *** X-Scale has quit IRC | 13:58 | |
| dmin7 | i do have a question though, if you have a moment | 14:08 |
| dmin7 | https://pastebin.com/6p8F7jkv | 14:08 |
| tpb | Title: [VeriLog] module icosoc_mod_trigger #( parameter integer CLOCK_FREQ_HZ = 0, parameter - Pastebin.com (at pastebin.com) | 14:08 |
| dmin7 | seems like i am addressing the triggers (2d) array wrong | 14:09 |
| dmin7 | (the for loop is just for some debugging data) | 14:10 |
| dmin7 | ctrl_addr[3:0] should contain an id from 0-15 | 14:10 |
| dmin7 | and i have to split the bus read/write into two times 32bit .. but that works fine for the counter, so that shouldn't be the problem | 14:11 |
| ZipCPU | Most block RAM's cannot be initialized on reset. | 14:18 |
| ZipCPU | $readmemh usually works much better. | 14:19 |
| *** X-Scale has joined #yosys | 14:20 | |
| *** cemerick has joined #yosys | 14:23 | |
| *** cemerick_ has quit IRC | 14:26 | |
| ZipCPU | Likewise, many design tools cannot recognize block RAM's buried deep into the logic of a process. They require reads to be as simple as either an assignment or a, always @(posedge i_clk) trigger_data <= triggers[ctrl_addr[3:0]; | 14:30 |
| ZipCPU | Sometimes you can do your selection on the next clock, "assign ctrl_rdat = (ctrl_state == 0) ? trigger_data[63:32] : trigger_data[31:0]; | 14:30 |
| *** seldridge0 has joined #yosys | 14:47 | |
| *** cr1901_modern has quit IRC | 14:47 | |
| *** cr1901_modern has joined #yosys | 15:06 | |
| *** develonepi3 has quit IRC | 15:09 | |
| *** develonepi3 has joined #yosys | 15:11 | |
| *** cemerick_ has joined #yosys | 15:13 | |
| *** cemerick has quit IRC | 15:16 | |
| *** GuzTech has quit IRC | 15:49 | |
| *** FabM has quit IRC | 15:49 | |
| *** emeb has joined #yosys | 15:55 | |
| *** cr1901_modern has quit IRC | 15:56 | |
| *** leviathan has joined #yosys | 16:07 | |
| *** leviathan has joined #yosys | 16:08 | |
| *** cr1901_modern has joined #yosys | 16:20 | |
| *** Aditya has joined #yosys | 16:45 | |
| shapr | y0 y0 y0 sys! | 17:04 |
| *** Aditya has quit IRC | 17:46 | |
| *** seldridge0 has quit IRC | 18:35 | |
| *** mazzoo_ has quit IRC | 18:53 | |
| *** mazzoo has joined #yosys | 18:53 | |
| dmin7 | ZipCPU: thanks for the hint. (the problem was the memory addresses / index's i tried to use; 0-15 instead of multiples of 4) | 18:55 |
| *** mazzoo has quit IRC | 19:01 | |
| *** mazzoo has joined #yosys | 19:02 | |
| *** digshadow has quit IRC | 19:44 | |
| *** develonepi3 has quit IRC | 19:47 | |
| *** leviathan has quit IRC | 19:52 | |
| *** digshadow has joined #yosys | 20:03 | |
| *** dys has joined #yosys | 20:24 | |
| *** cemerick_ has quit IRC | 20:37 | |
| *** jwhitmore has joined #yosys | 20:45 | |
| *** seldridge0 has joined #yosys | 20:49 | |
| *** azzizi has joined #yosys | 20:59 | |
| azzizi | hello | 20:59 |
| azzizi | Do I post my question here ? | 21:00 |
| azzizi | So write_verilog transfers the intermediate RTLIL information of a source code to synthesizing according to the platform intended. But suppose I wanted to see the RTLIL step for the code, capture it and edit some of it and then synthesize it, would it be possible with this tool? | 21:04 |
| azzizi | I suppose I can see the RTLIL of any code with the dump_rtlil but can I make any changes to the generated RTLIL before the synthesize step? | 21:05 |
| azzizi | Also, which intermediate format: ast1 or ast2 or ILANG or RTLIL is the strongest i.e. doesn't lose any information? With that I mean all the source code indormation is there in that format? | 21:05 |
| azzizi | And suppose I have a behavioral source code form where I get the platform-specific Verilog code using the write_verilog; my question is can I get back to the original behavioral code from the platform-specific Verilog code? | 21:05 |
| *** [X-Scale] has joined #yosys | 21:09 | |
| *** X-Scale has quit IRC | 21:10 | |
| *** [X-Scale] is now known as X-Scale | 21:10 | |
| *** Aditya has joined #yosys | 21:20 | |
| *** pie_ has quit IRC | 21:45 | |
| *** pie_ has joined #yosys | 21:58 | |
| *** Aditya has quit IRC | 22:17 | |
| *** dmin7 has quit IRC | 22:27 | |
| *** quigonjinn has quit IRC | 22:41 | |
| *** digshadow has quit IRC | 22:53 | |
| *** digshadow has joined #yosys | 23:09 | |
| *** cemerick_ has joined #yosys | 23:23 | |
| *** azzizi has quit IRC | 23:34 | |
| *** azzizi has joined #yosys | 23:36 | |
| *** digshadow has quit IRC | 23:42 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!