Mail Archives: geda-user/2018/12/16/23:24:37
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 -