User Tools

Site Tools


pcb:drc

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
pcb:drc [2019/01/26 16:01]
cparker [DRC backend work]
pcb:drc [2019/03/26 09:50] (current)
cparker [DRC backend work]
Line 56: Line 56:
   ​   ​
 =====To Do List===== =====To Do List=====
 +====New DRC Violations====
 +Some useful DRC violations to add:
 +  * Check for text on copper layers (which is not tested by the DRC)
 +  * Check for object proximity to the edge of the board
 +  * Violations for holes being too close together
 +  * Floating copper
 +  * Pin/pad exit violations
 +  * Silk screen over pins/pads
 +  * Overlapping elements
 ====DRC tests==== ====DRC tests====
 +This is to describe ways of testing the DRC code, not things the DRC should check for.
 +
   * Go through the DRC code for different kinds of violations to check that all possible code paths are being tested   * Go through the DRC code for different kinds of violations to check that all possible code paths are being tested
-  * Review the DRC tests and check that the results are correct!+  * Review the DRC tests and check that the results are correct! ​(Done: 201901xx)
   * Generate graphical output for the DRC report   * Generate graphical output for the DRC report
   * Generate LaTeX output for the DRC report (wishlist!)   * Generate LaTeX output for the DRC report (wishlist!)
   * Figure out what else uses the "​ConnectionLookup"​ code and write tests so that we don't break anything else as we're reworking the DRC   * Figure out what else uses the "​ConnectionLookup"​ code and write tests so that we don't break anything else as we're reworking the DRC
 +
 ===Additional test cases=== ===Additional test cases===
 As I work through the code, I'm going to jot some things down here regarding tests that ought to be done. Much of this stuff tests the more general geometry code too, so, maybe two birds with one stone. As I work through the code, I'm going to jot some things down here regarding tests that ought to be done. Much of this stuff tests the more general geometry code too, so, maybe two birds with one stone.
  
   * Square pads \\ In lots of cases, square pads are handled differently than ones with round ends, so, square pads should definitely be tested.   * Square pads \\ In lots of cases, square pads are handled differently than ones with round ends, so, square pads should definitely be tested.
 +  * Objects in the same layer group (physical layer) but on different (logical) layers
 +  * End points of lines/arcs \\ The end point condition is frequently tested for, and a separate test is called for these cases.
  
 ====DRC backend work==== ====DRC backend work====
Line 76: Line 90:
   * Have DRC functions operate on "​DataType"​ objects so that you can selectively apply the DRC to, say, the objects in the buffer   * Have DRC functions operate on "​DataType"​ objects so that you can selectively apply the DRC to, say, the objects in the buffer
   * Work through more of Peter C's work to see how much of it we should incorporate (home/​cparker/​peterc_drc,​ he has quite a bit of good stuff here, but I'd like to include it intelligently instead of just picking the commits.)   * Work through more of Peter C's work to see how much of it we should incorporate (home/​cparker/​peterc_drc,​ he has quite a bit of good stuff here, but I'd like to include it intelligently instead of just picking the commits.)
 +  * Write functions to compute the distance between objects.
 +  * Put the testing into a background thread so that the GUI is still responsive while the test is executing
 +
 +====Online DRC====
 +The online part of the DRC is that part that is active during normal design activities. It does things like preventing you from drawing traces too close together.
 +
 +Right now this functionality exists only for lines and is present in the line.c source file.
  
 +====Multi-clearance====
 +One of the primary hurdles with implementing multi-clearance DRC, or, different DRC requirements for different traces or nets, is the way in which our DRC is implemented. Presently we use an algorithm that bloats or shrinks the objects we're testing, and looks for changes in connectivity. In a multi-clearance DRC environment,​ the amount that you would need to bloat your object now depends on the objects around it, which may not have been discovered yet.
 ====DRC interface==== ====DRC interface====
-  * Create a DRC panel in the preferences window that allows for adjusting settings (possibly with image descriptions of the violations) and running specific tests individually +  * Create a DRC panel in the preferences window that allows for adjusting settings (possibly with image descriptions of the violations) and running specific tests individually. This will require that parameterization in the back-end work to be finished first.
-  * Figure out what the lesstif HID requirements are for the DRC code (it works differently,​ presenting violation by violation)+
  
 ====DRC bugs==== ====DRC bugs====
-  * Highlight both offending objects instead of just one^^^ +  * Highlight both offending objects instead of just one (done: 4.2.0) 
-  * Find more than one "​insufficient overlap"​ or "​insufficient gap" per pin/pad/via^^^ +  * Find more than one "​insufficient overlap"​ or "​insufficient gap" per pin/​pad/​via ​\\ The insufficient overlap case cannot propagate, due to the nature of how it works, however, the insufficient gap one can, and it does now as of the 4.2.0 release. 
-  * Check for duplicate DRC errors before appending a new one (can happen if more than one pin is connected to an object)+  * Check for duplicate DRC errors before appending a new one (can happen if more than one pin is connected to an object) (done: 4.2.0)
   * On MacOS the images in the DRC window of the GTK HID are garbled   * On MacOS the images in the DRC window of the GTK HID are garbled
pcb/drc.1548536506.txt.gz · Last modified: 2019/01/26 16:01 by cparker