delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2018/12/16/23:24:37

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: <CAKakQcddj77zaBOSsseFFzNOn_U7+d9SZQ+Zd-pTbuTS3UVHwg@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1812170430530.21900@igor2priv>
References: <alpine DOT DEB DOT 2 DOT 00 DOT 1812140530380 DOT 21900 AT igor2priv> <CAKakQcfwxCititS-gcKyAuuawZoA1men4-O5vQ85eK8Y3OKk_g AT mail DOT gmail DOT com> <alpine DOT DEB DOT 2 DOT 00 DOT 1812151432380 DOT 21900 AT igor2priv> <CAKakQcddj77zaBOSsseFFzNOn_U7+d9SZQ+Zd-pTbuTS3UVHwg AT mail DOT gmail DOT com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
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


On Mon, 17 Dec 2018, Stephen Ecob wrote:

>On Sun, Dec 16, 2018 at 12:43 AM <gedau AT igor2 DOT repo DOT hu> 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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019