X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Date: Mon, 17 Dec 2018 05:23:19 +0100 (CET) X-X-Sender: igor2 AT igor2priv To: geda-user AT delorie DOT com X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu" From: gedau AT igor2 DOT repo DOT hu Subject: [geda-user] underconstrained netlists (was: Re: pcb: save connection data of - anyone ever used this?) In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Mon, 17 Dec 2018, Stephen Ecob wrote: >On Sun, Dec 16, 2018 at 12:43 AM wrote: >> Since those times, we have introduced back annotation [...] >> Would that make a good alternative to this custom export format? > >Yes, back annotation would suit my needs well. > >For me the best solution would be to support underconstrained >netlists; by this I mean a netlist where I can specify 8 data pins on >a DRAM IC and specify that each of those pins needs to connect to one >and only one of a set of (say) 10 pins on the FPGA. During manual >routing selecting one of the DRAM data pins would highlight the 10 >possible corresponding pins on the FPGA. >I'd love to have this feature, but not enough to invest the time to >code it up, so perhaps log it as a feature request for now :) > Cool, thanks! I think it wouldn't be too hard to do that. Now that find.c is fully rewritten, the next such rewrite will be netlist.c, perhaps in the next development cycle (mid February). Netlist rewrite is a much smaller task. It needs to happen because the old code is unnecessarily complicated because of historical reasons (I think the whole data structure is built around and was named after how the netlist window menu widgets were created in the Xaw version of PCB!). I am sure that just with find.c we will be able to have a smaller, cleaner and faster code. This part will happen independently of your feature request. Once that's done, I could add the feature you described above. It sounds like 10..20 hours of work on pcb-rnd side at most, so not a big deal. However: 1. Feature requests need active pcb-rnd user I would do it only if you already used pcb-rnd by then. Rationale: we have some features once requested, added, but then never used in production (or even tested) by anybody, including the original requester. (Which is not surprising: needing a feature is cheap, investing the time in switching to a different EDA tool is expensive.) So around 2016 I started this policy that for accepting such feature requests I require the requester to start using the svn version of pcb-rnd regularly before I code anything, because that's the only way he will be around to actually test/use the feature when it happens. Please let me know if you are still interested. 2. Bad news: schematics side with gschem This is the harder problem. I don't expect gschem to grow support for the schematics side of this, so you'd need to manually write a netlist or use some intermediate tool to patch your netlist or use a different schematics editor. 3. Good news 1: schematics side with xschem We have xschem in our ecosystem (CoralEDA). It's a much smaller and simpler schematics editor than gschem or lepton. For example it doesn't depend on guile, glib or gtk. But what's even more important: it has a very active developer who keep the pace with pcb-rnd and believes in cooperation. So new features that need code both on pcb layout and sch edit side do happen these day. Which is essential from the user's point of view, because an electronics project is typically not an sch-only or spice-only or pcb-only project. And xschem _does_ understand the concept of networks in the GUI editor, so back annotation will be much simpler. We already have plans for back annotation, and we already have better forward annotation than gschem or lepton has to pcb-rnd - see below. So if the above feature happens, it won't be "we did our side on pcb-rnd but nothing supports it yet, let's wait and hope". Instead, it will be tested with xschem on our side which means we'll have a working flow, usable to the end user as-is, without any hacking or patching. 4. Good news part 2: slots in fwd annotation! The forward annotation format we prefer, tEDAx netlist, already has lines for describing slots. Xschem already writes these lines. After the netlist rewrite I will have native support for netlist slots in pcb-rnd. Together with back annotation, this will make pcb-rnd able to 'swap slots and back annotate'. This was originally intended for the classic slot cases, like when you have 4 NAND gates or 2 opamps in an IC or 2 discrete FETs in a 6 pin device. In those cases which slot you use within a device won't matter, you'd be free to choose on pcb-layout time. Then when you are done you will be able to back annotate the swaps. But nothing keeps you from having slots with one pin. So you could just say your fpga pins are single-pin slots within the same gpio or dram data device, then in pcb-rnd you will be able to swap slots and back annotate the changes. (Or if you need to keep dram data nibbles together, then 4 pin slots.) The real good news in this is that the slot swapping feature will happen independently of your feature request. And I think it may solve your problem, so maybe we don't even need to add special code for underconstrained netlists. Best regards, Igor2