Mail Archives: geda-user/2018/12/17/00:45:17
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 <gedau AT igor2 DOT repo DOT hu> wrote:
>
>
>
> 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
>
--
Stephen Ecob
Silicon On Inspiration
Sydney Australia
www.sioi.com.au
- Raw text -