X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=dWbTo+gkt8DZhtvuDizqUCIDXYm5JFrqhovAQm21aEo=; b=lKn3SUWVdT7vl0UVq2+LLWaj10SWpMxRnzk6SMb/rvDgu0On8E4nRnYarP17Ys2sLm cyFMkPyY3qrtH773tI+RKfNVQrs8q+yLTNBHbVxda5XXs2c4zO5Y+H5Z5N8zoDWJbf8p I9XKX5uA+/Bnr9CiVmjYd2F8eX8hmNvYrLesbBqYQeBlTt6Qon/9jmY7t87sJkj7+qQt MqYPf0Z9nzZCHFV+kubuiyUoD68k61TdEerkOoSWgIehhwTRZqtFK/GF00B8CCvWE0eI O/LEtQzWNr/n6xFbFU0Y9J+mziIjK2Fk5ccZXPT0hJ4MbxC1C791mymCk3YrWn6tZkDL z1lQ== X-Gm-Message-State: AA+aEWbIhGEO0gLuo/E2JAVSEZIX3IZRwKjiQx55jATbzOh9StZ95UoF lmeD0BNOOyk3MobsdQMtuSBC9WTAZhEdLCXkMDSTPg== X-Google-Smtp-Source: AFSGD/Wv+GncYIDhU5b07naq4hfg98zfmnO/N1SuAgvzyPgOeCqHW79B0kp3WlMn5pJo/P5BwZYfjHWc7dyhcvxn5HA= X-Received: by 2002:a67:4711:: with SMTP id u17mr5617862vsa.27.1545025419695; Sun, 16 Dec 2018 21:43:39 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Stephen Ecob Date: Mon, 17 Dec 2018 16:43:28 +1100 Message-ID: Subject: Re: [geda-user] underconstrained netlists (was: Re: pcb: save connection data of - anyone ever used this?) To: geda-user AT delorie DOT com Content-Type: text/plain; charset="UTF-8" Reply-To: geda-user AT delorie DOT com Hi Igor, That's great! I'll switch to pcb-rnd next time I need to design a PCB. I don't know when that will be, but will let you know when I do, Best regards, Stephen On Mon, Dec 17, 2018 at 3:23 PM wrote: > > > > 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 > -- Stephen Ecob Silicon On Inspiration Sydney Australia www.sioi.com.au