| *** tpb has joined #yosys | 00:00 | |
| *** emeb_mac has joined #yosys | 00:58 | |
| *** seldridge has joined #yosys | 01:08 | |
| *** seldridge has quit IRC | 01:13 | |
| *** proteusguy has quit IRC | 01:38 | |
| *** proteusguy has joined #yosys | 01:51 | |
| *** AlexDaniel has quit IRC | 02:17 | |
| *** gsi_ has joined #yosys | 02:42 | |
| *** gsi__ has quit IRC | 02:45 | |
| *** emeb has quit IRC | 03:24 | |
| *** rohitksingh_work has joined #yosys | 03:51 | |
| *** citypw has joined #yosys | 03:54 | |
| *** tpb has joined #yosys | 04:37 | |
| *** tpb has joined #yosys | 04:41 | |
| *** SpaceCoaster has joined #yosys | 06:16 | |
| *** jevinski_ has quit IRC | 06:52 | |
| *** jevinskie has joined #yosys | 06:52 | |
| keesj | FOSDEM anyone? | 06:53 |
|---|---|---|
| *** jevinski_ has joined #yosys | 06:57 | |
| *** jevinskie has quit IRC | 06:58 | |
| *** emeb_mac has quit IRC | 07:10 | |
| *** NPHK has quit IRC | 07:26 | |
| *** proteusguy has quit IRC | 07:57 | |
| *** dys has quit IRC | 07:58 | |
| *** proteusguy has joined #yosys | 08:11 | |
| *** rohitksingh has joined #yosys | 08:55 | |
| *** rohitksingh has quit IRC | 09:07 | |
| *** rohitksingh has joined #yosys | 09:08 | |
| *** TFKyle has quit IRC | 09:14 | |
| *** goatama has left #yosys | 09:23 | |
| *** TFKyle has joined #yosys | 09:26 | |
| *** rohitksingh has quit IRC | 09:50 | |
| *** citypw has quit IRC | 09:56 | |
| *** rohitksingh has joined #yosys | 10:07 | |
| *** rohitksingh has quit IRC | 10:40 | |
| *** rohitksingh_work has quit IRC | 10:40 | |
| *** keesj has quit IRC | 10:47 | |
| *** fsasm has joined #yosys | 10:50 | |
| *** rohitksingh_work has joined #yosys | 10:54 | |
| *** citypw has joined #yosys | 10:55 | |
| *** sxpert has joined #yosys | 11:15 | |
| *** rohitksingh has joined #yosys | 11:19 | |
| sxpert | now that I have tested my module with iverilog, how would I run yosys on it ? | 11:23 |
| daveshah | sxpert: You will want to do something like `yosys -p "synth_ice40 -top top -json design.json" design.v`; `nextpnr-ice40 --up5k --json design.json --pcf design.pcf --asc design.asc`; `icepack design.asc design.bin` | 11:29 |
| daveshah | changing the name and device type as appropriate | 11:29 |
| sxpert | ok | 11:32 |
| daveshah | You can see an example of a Makefile for this at https://github.com/cliffordwolf/picorv32/blob/master/picosoc/Makefile#L47-L86 | 11:34 |
| tpb | Title: picorv32/Makefile at master · cliffordwolf/picorv32 · GitHub (at github.com) | 11:34 |
| sxpert | daveshah: how do I tell it to ignore the testbench bits ? | 11:36 |
| daveshah | Wrap them in `ifdef SIM | 11:36 |
| daveshah | or `ifndef SYNTHESIS | 11:37 |
| sxpert | `ifdef SIM seems to work | 11:39 |
| *** rohitksingh has quit IRC | 11:45 | |
| sxpert | hmm, design is too slow | 11:47 |
| sxpert | need to add registers in there | 11:47 |
| sxpert | good | 11:47 |
| sxpert | guess I need to add some clocking ;) | 11:48 |
| sxpert | daveshah: thanks, I have things to work on now ;) | 11:50 |
| *** leviathanch has joined #yosys | 12:40 | |
| *** indy has quit IRC | 13:04 | |
| *** rohitksingh_work has quit IRC | 13:05 | |
| *** indy has joined #yosys | 13:07 | |
| sxpert | daveshah: hmm, can't figure it out... | 13:35 |
| sxpert | daveshah: can't get the simulation to show up the clock changing, what am I doing wrong ? https://pastebin.com/7vEvs7kw | 13:37 |
| tpb | Title: [VeriLog] module mask_gen ( // ports clk, nibble_width, nibble_start, - Pastebin.com (at pastebin.com) | 13:37 |
| daveshah | sxpert: try `clk = (clk === 1'b0);` instead of `clk = !clk` | 13:38 |
| daveshah | sorry, `clock = (clock === 1'b0);` | 13:39 |
| sxpert | am getting nothing between "run scheduler | 13:39 |
| sxpert | and "execute StartOfSim callbacks" | 13:40 |
| daveshah | ah, you need to pass -DSIM to Icarus | 13:41 |
| sxpert | ah ! | 13:41 |
| MoeIcenowy | interestingly... tried iCECube2 recently and found that synplify pro is still LUT efficient than Yosys on my design... | 13:43 |
| sxpert | daveshah: ah HA ! | 13:46 |
| daveshah | MoeIcenowy: yes, that's not too surprising, Yosys isn't brilliantly tuned by any means | 13:47 |
| daveshah | `-relut` might help synth_ice40 a bit | 13:48 |
| MoeIcenowy | (yes it do help a bit | 13:49 |
| MoeIcenowy | (BTW the reason why I'm considering this is because I currently only own a too small iCE40 | 13:49 |
| MoeIcenowy | LP384 ;-) | 13:49 |
| MoeIcenowy | daveshah: is the gate->lut process done by ABC? | 13:49 |
| daveshah | Yes | 13:49 |
| daveshah | whitequark has been looking at alternative options too | 13:49 |
| MoeIcenowy | maybe I should give -noabc a try? | 13:51 |
| MoeIcenowy | haha even worse | 13:51 |
| * sxpert is actually targetting ecp5 | 13:51 | |
| daveshah | That will be considerably worse, replacing abc with the new `flowmap` command will be better than that but still probably worse than abc | 13:51 |
| sxpert | but that's ok, I think I got the right options | 13:51 |
| MoeIcenowy | daveshah: by the way it seems that currently it's still not possible for a Linux distro to provide nextpnr w/ prjtrellis? | 13:52 |
| MoeIcenowy | (although I have no ECP5 | 13:52 |
| zkms | sometimes -relut and/or -abc2 helps, idk | 13:52 |
| daveshah | sxpert: have a look at https://raw.githubusercontent.com/SymbiFlow/prjtrellis/master/examples/versa5g/Makefile | 13:52 |
| zkms | at least sometimes i get faster timings with my designs | 13:52 |
| daveshah | MoeIcenowy: Arch (AUR) provides it | 13:53 |
| MoeIcenowy | haha aur provides everything ;-) | 13:53 |
| *** citypw has quit IRC | 13:54 | |
| sxpert | daveshah: thanks ! | 13:55 |
| *** citypw has joined #yosys | 13:55 | |
| daveshah | The `-nomux` isn't needed any more, other than that that example should be up to date | 13:55 |
| *** proteusguy has quit IRC | 14:10 | |
| sxpert | daveshah: yay, my module compiles and can be placed in the fpga successfully | 14:18 |
| daveshah | sxpert: yay! | 14:25 |
| sxpert | now, I have no idea if it works but... | 14:26 |
| sxpert | need to build more things first | 14:26 |
| sxpert | daveshah: for instance, need to figure out how to build staggered clocks | 14:27 |
| daveshah | don't :P | 14:27 |
| daveshah | use staggered clock enables instead | 14:27 |
| sxpert | hmm | 14:28 |
| sxpert | daveshah: have a link ? | 14:29 |
| daveshah | sxpert: http://zipcpu.com/blog/2017/06/02/generating-timing.html | 14:29 |
| tpb | Title: Controlling Timing within an FPGA (at zipcpu.com) | 14:29 |
| sxpert | thanks | 14:32 |
| *** proteusguy has joined #yosys | 14:35 | |
| sxpert | daveshah: small nextpnr question | 14:53 |
| sxpert | I can only see white boxes, no traces or anything, is this normal ? | 14:54 |
| daveshah | That's a defect in the ecp5 architecture, no-one has added the GUI data for the wires or switchboxes yet | 14:54 |
| *** rohitksingh has joined #yosys | 14:54 | |
| sxpert | daveshah: ah, ok. | 14:55 |
| sxpert | will wait ;) | 14:55 |
| *** emeb has joined #yosys | 15:01 | |
| MoeIcenowy | daveshah: BTW any suggestions for an ECP5 board? ;-) | 15:09 |
| daveshah | Depends what you want to do. https://www.digikey.co.uk/product-detail/en/lattice-semiconductor-corporation/LFE5UM5G-85F-EVN/220-2197-ND/9553907 if you want lots of LUTs and IO | 15:09 |
| tpb | Title: LFE5UM5G-85F-EVN Lattice Semiconductor Corporation | Development Boards, Kits, Programmers | DigiKey (at www.digikey.co.uk) | 15:09 |
| daveshah | ULX3S is also worth a look, although a bit harder to get hold of right now | 15:10 |
| daveshah | https://www.digikey.co.uk/product-detail/en/lattice-semiconductor-corporation/LFE5UM5G-45F-VERSA-EVN/LFE5UM5G-45F-VERSA-EVN-ND/6286581 if you want PCIe etc | 15:10 |
| tpb | Title: LFE5UM5G-45F-VERSA-EVN Lattice Semiconductor Corporation | Development Boards, Kits, Programmers | DigiKey (at www.digikey.co.uk) | 15:10 |
| sxpert | they just received a batch as we speak, you may be lucky | 15:10 |
| MoeIcenowy | oh official EVN... they're usually quite expensive... | 15:10 |
| daveshah | the 85F-EVN is very good value | 15:10 |
| sxpert | 200€ a piece. not bad | 15:11 |
| sxpert | well it's a 45F, but that's the same as 85F... | 15:11 |
| MoeIcenowy | for iCE40 I choose to do a UP5K board by myself (currently pending due to Chinese New Year) because all existing boards are too expensive (maybe except UPduino) | 15:12 |
| MoeIcenowy | but I heard that UPduino doesn't feature an onboard crystal oscillator | 15:12 |
| emeb | It doesn't | 15:13 |
| emeb | got one right here | 15:13 |
| sxpert | what's it using then ? integrated pll thingie ? | 15:14 |
| emeb | on-chip 48MHz RC osc | 15:14 |
| sxpert | ah | 15:14 |
| emeb | or 10kHz low freq osc if you want | 15:15 |
| sxpert | good enough if you're not too timing sensitive | 15:15 |
| MoeIcenowy | FleaFPGA seems interesting | 15:15 |
| emeb | yep | 15:15 |
| emeb | I've done a few personal boards w/ LP4K/UP5K (pin compatible) | 15:16 |
| emeb | they're pretty easy to do | 15:16 |
| emeb | Don't copy UPduino design tho - there are some problems with the power supply circuitry. | 15:16 |
| sxpert | ah | 15:17 |
| sxpert | good to know | 15:17 |
| emeb | and grounding isn't ideal. It works but it could be a lot better. | 15:17 |
| MoeIcenowy | emeb: what problem? | 15:17 |
| MoeIcenowy | lack of decoupling capacitor on VCCPLL? | 15:18 |
| emeb | MoeIcenowy: That's a big one. | 15:18 |
| MoeIcenowy | emeb: I found it's fixed in 2.0 | 15:18 |
| MoeIcenowy | I currently put a 104 and a 106 for VCCPLL on my board | 15:18 |
| emeb | Yep. Plus diode/cap reversed on Vpp ckt | 15:19 |
| emeb | didn't put cap on FPGA side of diode. | 15:19 |
| MoeIcenowy | emeb: Y? | 15:19 |
| emeb | why what? I don't know why upduino did it that way, but it doesn't provide good bypass due to high impedance of diode on half wave of ripple. | 15:21 |
| MoeIcenowy | I think the cap should be the FPGA side, not the VCC3V3 side... | 15:22 |
| MoeIcenowy | from my (limited) experience cap should be near the chip... | 15:22 |
| emeb | Correct | 15:22 |
| emeb | but on upduino it's not. | 15:22 |
| MoeIcenowy | oh sorry | 15:22 |
| MoeIcenowy | I misread your sentence | 15:22 |
| MoeIcenowy | you mean "UPduino didn't put cap on FPGA side" | 15:23 |
| emeb | yes. | 15:23 |
| MoeIcenowy | I read it as "Don't put cap on FPGA side" | 15:23 |
| MoeIcenowy | checked... not fixed on UPduino 2.0 | 15:23 |
| emeb | Sorry for confusion. | 15:23 |
| MoeIcenowy | emeb: no sorry | 15:23 |
| MoeIcenowy | just my mother tongue is not en | 15:23 |
| emeb | I'm sure it's better than my understanding of your language. :) | 15:24 |
| * emeb speaks toddler-grade german plus some spanish. :P | 15:24 | |
| MoeIcenowy | at least they're all Indo-European | 15:24 |
| emeb | I suspect I'd be useless with anything that didn't use roman alphabet. | 15:25 |
| MoeIcenowy | BTW what's VPP_2V5 for? | 15:27 |
| MoeIcenowy | programming the NVCM? | 15:27 |
| emeb | That would be my guess. | 15:27 |
| daveshah | It's also needed for a few other bits and pieces | 15:27 |
| MoeIcenowy | (to be honest I do not like any kind of OTP | 15:28 |
| daveshah | In particular trimming for the oscillators is read from NVCM at boot | 15:28 |
| MoeIcenowy | (I do not like irreversible things | 15:28 |
| MoeIcenowy | daveshah: oh | 15:28 |
| daveshah | If Vpp_2V5 is bad then the oscillator frequency will be way off | 15:28 |
| emeb | Good for saving pennies on high volume stuffs | 15:28 |
| emeb | but it would be nice if it could erase | 15:29 |
| emeb | daveshah: didn't you figure out that osc can be tuned via the FPGA fabric? | 15:30 |
| daveshah | Yes, it can be | 15:30 |
| *** rohitksingh has quit IRC | 15:31 | |
| emeb | would be interesting to make FLL with that. | 15:31 |
| emeb | use 1PPS from GPS or something. | 15:31 |
| *** rohitksingh has joined #yosys | 15:44 | |
| *** Cerpin has joined #yosys | 15:55 | |
| ZipCPU | emeb: Been there, done that, it's not all that hard. Requires a bit of a tracking loop. I used a filter together with a 2nd order loop to track both phase and frequency. It works fairly well. | 16:15 |
| ZipCPU | The code to do it is part of my open arty project, at https://github.com/ZipCPU/openarty | 16:15 |
| tpb | Title: GitHub - ZipCPU/openarty: An Open Source configuration of the Arty platform (at github.com) | 16:15 |
| emeb | ZipCPU: Yes - I've looked at your GPS-disciplined clock project before. IIRC though it's using a fixed external clock and locking a divided down version of that by putting a control loop on the divider ratio. I'm talking about locking the on-chip RC oscillator of the UP5k by controlling the tuning word which is kind of a hidden parameter that Lattice doesn't give you easy access to. | 16:20 |
| ZipCPU | Yeah, okay, that's different. That actually takes updated hardware to do. | 16:21 |
| ZipCPU | ;) | 16:21 |
| ZipCPU | On the other hand, you can use the GPS schooled logic to create a GPS-disciplined oscillator ... | 16:22 |
| ZipCPU | (It'll jump a bit every second, as currently built....) | 16:22 |
| emeb | It's just a wild idea. I don't know how easy it would be to control that tuning parameter in realtime - just something that jumped into my brain when daveshah: mentioned the tuning param was available. | 16:22 |
| emeb | On the other hand - if it is available then it could be used to lock a USB device to the SOH pulse. | 16:23 |
| ZipCPU | Ooohh ... I definitely need to read more of the backlog ... logically controlling a tuning parameter based upon GPS input? That would be quite vascinating | 16:23 |
| ZipCPU | *fascinating | 16:23 |
| emeb | That's how the STM32F042 chip manages to get stable USB operation without an external crystal. | 16:23 |
| emeb | That would make it super cheap to put USB onto a UP5K part. | 16:25 |
| emeb | See here section 7 on the CRS here -> https://www.st.com/content/ccc/resource/technical/document/reference_manual/c2/f8/8a/f2/18/e6/43/96/DM00031936.pdf/files/DM00031936.pdf/jcr:content/translations/en.DM00031936.pdf | 16:27 |
| * ZipCPU browses around | 16:29 | |
| *** seldridge has joined #yosys | 16:32 | |
| MoeIcenowy | emeb: emmm on UP5K osc can sync to external signal? | 16:52 |
| emeb | MoeIcenowy: it's not a normal feature of the oscillator, but daveshah found that there are hidden hooks on the IP core that could be used for that. | 17:08 |
| MoeIcenowy | hidden ;-) | 17:09 |
| MoeIcenowy | only utilizable with IceStorm? ;-) | 17:10 |
| emeb | MoeIcenowy: Probably. | 17:12 |
| *** rohitksingh has quit IRC | 17:54 | |
| *** leviathanch has quit IRC | 17:56 | |
| *** danieljabailey has quit IRC | 17:58 | |
| *** dys has joined #yosys | 18:11 | |
| emeb | Trying to build nextpnr on Fedora 28 using instructions at http://www.clifford.at/icestorm/ and cmake -DARCH=ice40 is failing due to not finding Boost::Python | 18:31 |
| tpb | Title: Project IceStorm (at www.clifford.at) | 18:31 |
| emeb | Any clues on what to do next? | 18:31 |
| emeb | I did install all the listed prereqs as defined in the instructions. | 18:32 |
| *** m4ssi has quit IRC | 18:33 | |
| emeb | I also installed boost-python3 and boost-python3-devel but cmake is still unhappy | 18:34 |
| emeb | oh wait - looks like it's just kicking out warnings now. | 18:35 |
| emeb | OK - all happy. Nevermind. :P | 18:39 |
| emeb | (might want to add the boost-python3 and boost-python3-devel dependencies to the list on the icestorm page though) | 18:39 |
| *** fsasm has quit IRC | 18:56 | |
| emeb | So, trying out nextpnr on my up5k SDR front-end. It seems to chew through it OK, but the critical ADC input path isn't meeting timing. | 20:28 |
| emeb | I see that nextpnr doesn't use a .sdc file to specify clock freq goals but instead has a single freq argument on the cmd line. Is this the only knob available to turn? | 20:29 |
| daveshah | emeb: https://github.com/YosysHQ/nextpnr/blob/master/docs/constraints.md#clock-constraints | 20:36 |
| tpb | Title: nextpnr/constraints.md at master · YosysHQ/nextpnr · GitHub (at github.com) | 20:36 |
| emeb | daveshah: oh cool - thanks! | 20:37 |
| *** tmeissner has joined #yosys | 20:51 | |
| *** seldridge has quit IRC | 21:03 | |
| emeb | clock constraints successfully added. unfortunately that didn't improve the final results very much. This is a pretty challenging design though - lots of giant adder trees for a CIC decimator that need to run at 50MHz. | 21:09 |
| ZipCPU | Why do you need an adder tree for a CIC decimator? | 21:11 |
| ZipCPU | You should be able to build that with just 3 adds as I recall | 21:11 |
| ZipCPU | ... for any decimation | 21:11 |
| daveshah | You can try adding -relut to Yosys' synth_ice40 command | 21:12 |
| daveshah | This can improve QoR for some carry chain structures | 21:12 |
| ZipCPU | Sure, you could, but if you are fighting with the hardware on this one then you are designing the CIC wrong | 21:13 |
| ZipCPU | CIC's should be simple to implement | 21:13 |
| ZipCPU | (Overflow helps) | 21:13 |
| tmeissner | Hi everone | 21:13 |
| tmeissner | I'm at FOSDEM this eekend | 21:13 |
| ZipCPU | Afternoon, tmeissner! | 21:13 |
| tmeissner | Anyone also there from this group? | 21:14 |
| daveshah | Hey tmeissner, I'll be there too! | 21:14 |
| tmeissner | Yeah, I saw that you have a talk in the EDA room :) | 21:14 |
| ZipCPU | emeb: Are you at a University at all? Check out frederic harris' book on "multirate signal processing" | 21:15 |
| tmeissner | I think I'm in this room to hear some of the talks | 21:15 |
| emeb | ZipCPU: I'm not at a uni but I've got a copy of that book | 21:16 |
| emeb | ZipCPU: perhaps "tree" was the wrong term - adder chains. | 21:16 |
| ZipCPU | No, that's the right term for the wrong implementation | 21:16 |
| ZipCPU | You want to use two implementations similar to this one: http://zipcpu.com/dsp/2017/10/16/boxcar.html | 21:17 |
| tpb | Title: Implementing the Moving Average (Boxcar) filter (at zipcpu.com) | 21:17 |
| ZipCPU | You shouldn't need any adder trees or adder chains at all--CICs are *REALLY* easy to implement | 21:17 |
| ZipCPU | If you check out the boxcar.html page on zipcpu.com, check out figure 3 which shows what I'm talking about | 21:18 |
| ZipCPU | Instead of needing to add N values together to get the next output, you add the difference of the new value with the old value that falls off the end | 21:18 |
| emeb | ZipCPU: yes - nothing fancy about the math in my CIC. | 21:19 |
| emeb | But the wordlenghts are large | 21:19 |
| ZipCPU | ?? How big? | 21:19 |
| emeb | 14-bit inputs, 8 bits growth per stage, 4 stages, so 46 bits on the output of the integrator. | 21:20 |
| emeb | I've tried it with truncation and without | 21:21 |
| ZipCPU | What happens with truncation? | 21:21 |
| emeb | throw away some lsbits between the integrator and comb stages. | 21:22 |
| emeb | just to reduce the complexity of the comb stages. | 21:22 |
| ZipCPU | Why not cascade the CICs at different rates, to keep the bit widths down? | 21:23 |
| ZipCPU | Oh, another question, how fast does this need to operate? | 21:23 |
| emeb | here's one of my designs -> https://github.com/emeb/iceRadio/blob/master/FPGA/rxadc_2/verilog/src/cic_dec_3.v | 21:23 |
| tpb | Title: iceRadio/cic_dec_3.v at master · emeb/iceRadio · GitHub (at github.com) | 21:23 |
| emeb | that's an older one that only uses 10-bit inputs | 21:24 |
| emeb | I'm running this one at 50MHz in a UP5k | 21:24 |
| emeb | iCEcube has no trouble building it | 21:24 |
| emeb | but yosys + nextpnr only hits about 24MHz | 21:25 |
| ZipCPU | Which nextpnr? ... as in, how recent? | 21:25 |
| daveshah | Does this PR improve anything? | 21:25 |
| daveshah | https://github.com/YosysHQ/nextpnr/pull/171 | 21:25 |
| tpb | Title: WIP: Reworking placer1 by daveshah1 · Pull Request #171 · YosysHQ/nextpnr · GitHub (at github.com) | 21:25 |
| ZipCPU | daveshah: Is that on the main branch? | 21:26 |
| emeb | ZipCPU: nextpnr built from git this morning. | 21:26 |
| daveshah | No, that PR isn't merged yet | 21:26 |
| daveshah | That's why I suggested it | 21:26 |
| emeb | daveshah: git newb here - what do I need to do to build with that? | 21:26 |
| *** seldridge has joined #yosys | 21:26 | |
| ZipCPU | daveshah: You've gotten good results on the metrics for that, right? Care to share any of those metrics here? | 21:27 |
| daveshah | emeb: run | 21:27 |
| daveshah | git checkout -b daveshah1-crit_driven_placer master git pull https://github.com/daveshah1/nextpnr.git crit_driven_placer | 21:27 |
| tpb | Title: GitHub - daveshah1/nextpnr: nextpnr portable FPGA place and route tool (at github.com) | 21:27 |
| daveshah | Sorry, should be a newline between master and git | 21:28 |
| emeb | ok | 21:28 |
| daveshah | git checkout -b daveshah1-crit_driven_placer master | 21:28 |
| daveshah | git pull https://github.com/daveshah1/nextpnr.git crit_driven_placer | 21:28 |
| tpb | Title: GitHub - daveshah1/nextpnr: nextpnr portable FPGA place and route tool (at github.com) | 21:28 |
| daveshah | Then rebuild | 21:28 |
| emeb | on it | 21:28 |
| daveshah | I've seen this give results within 5-10% of the Lattice tools | 21:28 |
| daveshah | But large adder chains might be a bit of a weak spot atm | 21:29 |
| ZipCPU | emeb: Having looked at your code, I take back my initial conclusion(s) ;) | 21:30 |
| emeb | ZipCPU: :) | 21:30 |
| ZipCPU | You should be able to drop bits before integration tho ... there's no reason why you need to go into there with 10 bits if you don't want 46 bits out | 21:30 |
| emeb | ZipCPU: well, in my experience it's good to start with the best dynamic range you can get, and I've got a 14-bit ADC. | 21:31 |
| ZipCPU | Yeah ... I can understand that perspective completely | 21:32 |
| emeb | I've got a version of this DDC running on a Spartan 6 with 100MHz 14-bit ADC inputs and a hardware AGC on the output of the CIC that gives me a nice bit of dynamic range. | 21:33 |
| emeb | but in the UP5k version I just carry 16-bits output and do the AGC in software | 21:33 |
| emeb | daveshah: OK - checked out your branch, rebuilt and reran on my design. Didn't make much difference on the timing. | 21:39 |
| emeb | I'd be happy to bundle this up as a testcase if you'd like. | 21:42 |
| daveshah | That would be great | 21:43 |
| daveshah | I think this is probably more of a synthesis than nextpnr issue | 21:43 |
| emeb | Could well be | 21:44 |
| daveshah | At the moment carry chains prevent a number of logic optimisations from working properly | 21:44 |
| daveshah | We are investigating alternative ways of interfacing with abc to improve this | 21:44 |
| emeb | sounds hairy | 21:50 |
| emeb | daveshah: testcase built - where should I send it? | 21:52 |
| daveshah | [email protected] | 21:52 |
| emeb | sent | 21:56 |
| daveshah | Got it, cheers! | 21:56 |
| emeb | cool - hope it's helpful. | 21:57 |
| *** tmeissner has quit IRC | 22:25 | |
| *** seldridge has quit IRC | 22:43 | |
| *** q3k is now known as ```q3k``` | 23:07 | |
| *** ```q3k``` is now known as `q`3`k` | 23:07 | |
| *** seldridge has joined #yosys | 23:10 | |
| *** `q`3`k` is now known as q3k | 23:21 | |
| *** q3k is now known as ][ | 23:43 | |
| *** ][ is now known as [`] | 23:43 | |
| *** [`] is now known as q3k | 23:44 | |
| *** seldridge has quit IRC | 23:52 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!