Mail Archives: geda-user/2015/09/13/13:13:47
Oh, and one more thought. Was this really “back” annotation? I think of it as a design merge forward into a new branch, although the mechanics perhaps worked backward. Regardless, I think simply “annotation” is what we really want.
On Sep 13, 2015, at 10:56 AM, John Doty <jpd AT noqsi DOT com> wrote:
> Story,
>
> Back in the spring, on one of my projects, the FPGA designer and the board designer hatched a conspiracy. One of my designs used an FPGA and a microcontroller in combination: the FPGA did the “heavy lifting” on the 160 Mb/s data paths, and the microcontroller configured and supervised the process. For various reasons, these folks wanted an FPGA-only solution, but for some reason they thought I’d be upset with that, even though two different branches of this design had already gone that direction with my approval. So, the board designer made the changes directly in the Osmond layout without consulting me.
>
> The trouble was that the technician who had to make this work wound up with a board, but no schematics. So, he asked me for schematics, and all I could reply was, “Huh?”
>
> The perpetrators had made hasty notes, but I didn’t trust the notes, for good reason as it turned out. But, they had an Osmond layout, which included the “as built" netlist. So, I started from their notes, and made the schematic changes. Then, with a simple script, I extracted a canonicalized form of the Osmond netlist. The same script canonicalized the output of “gnetlist -g osmond”. Then, it was simply a matter of using “diff” and editing until it was silent. It turned out to be much easier than I’d feared.
>
> It’s essentially like merging changes in a software revision control system. This case was beyond any reasonable completely automatic solution, but with a little scripted help it was pretty easy. I don’t see any problem with full automation for simpler cases.
>
> It seems that the key thing we need is a neutral, canonical netlist file format (others have noted this need for other reasons). One minor issue with this is that tools generally enumerate anonymous nets in a way that’s difficult to predict and impossible to fully control.
>
> In this vision, each layout tool needs to be able to export an “as built” netlist, and needs a converter to the canonical format. This shouldn’t be difficult: netlist formats are generally designed to be easy to parse. The harder part is the patch tool to apply the diffs to the schematic, but that can be an incremental development. Start out with manual patches, then a tool that can handle the simplest cases, complicate as needed. I don’t think you’ll reach the point of being able to handle the case above (deletion of a 100 pin part and its support fungus, new FPGA with new pinout and power supply arrangements, and some other incidental changes) automatically. But just being able to “diff” proved to be a huge help.
>
> John Doty Noqsi Aerospace, Ltd.
> http://www.noqsi.com/
> jpd AT noqsi DOT com
>
>
>
>
John Doty Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd AT noqsi DOT com
- Raw text -