undefined | Better HN

0 pointstubetime2y ago0 comments

This is the most useful comment in the thread (so far)!

This product would not work at all for any analog or power designs--EEs like to visualize current flow and a schematic is the best way to do that. Maybe if it could interoperate with small blocks of schematics, treating them as modules, it could be useful. If there was a way to parameterize part values, like those used to build analog filters, that could also be useful, but not in the current text-only form.

The one thing it could be useful for is creating net connectivity for large numbers of pin to pin connections, like DDR memory or PCIe buses. Schematics for these end up looking like large data tables anyway, and can be tedious to create and prone to errors.

I see so many EDA startups using their product for simple Arduino boards and other low to medium complexity designs. It's far more effective to start with the most complex board design. Take a server board from the OpenCompute project with a few thousands parts and a few tens of thousands of nets. What would that look like in this language? Would it have too much boilerplate code? What would the experience of creating it be like? How do you handle back annotation? How do you handle pin swaps, or part section swaps? How about BOM variants?

0 comments

1 comments · 1 top-level

robomartin2y ago

> The one thing it could be useful for is creating net connectivity for large numbers of pin to pin connections, like DDR memory or PCIe buses. Schematics for these end up looking like large data tables anyway, and can be tedious to create and prone to errors.

This is a good example. I'll expand it to include such things as breaking up the symbols for a large FPGA (say, over 1000 pins) into multiple schematic blocks and managing them as the schematic design progresses. Very often you have to move pins around within the same block or between blocks just to arrange them logically or align them with whatever they might connect to.

For example, take the output of an FPGA bank and connect it to the input of an HDMI transmitter chip. You would want to align the red, green, blue, clock and control pins so that you can connect them with a bus that looks right. If someone reading this isn't clear, imaging arranging the pins on each device in random order where, for example, the first chip has R0,B8,R1,G5 and the second chip is R0,R1,R2, etc.

This kind of thing is tedious and painful.

The way we solve the problem with Altium was to write code that allows us to fully define an FPGA (and other IC's) using data entry in Excel. One turn of the crank creates all symbols and PCB patterns and exports into the libraries. This took something that was a days-long torture to maybe 45 minutes of work. After that, if you need to move pins around, it takes minutes to update everything.

This is also an example of why a text file based approach would not be as useful. Entering data in Excel is very easy. Editing it is just as easy. In some cases you can even copy and paste from datasheets and easily edit or rearrange. I can also write formulas to generate sequences of pins, etc.

Having to manage this in a text file would not be as slick. Over the years, I have found that Excel, coupled with VBA code, is a very powerful tool for schematic entry and PCB design.