At 09:01 AM 9/27/2002 -0500, Robison Michael R CNIN wrote: >I've drawn a schematic and now I'm attempting to interactively >route the traces to match some old artwork, but I've run into >some guard traces that I haven't got in the schematic. At >least I think they are guard traces. They have a via to GND >at one end and follow beside another trace for a while, and >then simply stop close by the termination of the actual signal >trace.
Yes, this sounds like a guard trace. Whether or not it has a useful function we obviously cannot tell from what information has been given. Some designers use guard traces without having the foggiest idea of what is needed and what is not. Others know what they are doing.... >To be honest, I don't really care about their electrical func- >tion. However, we are attempting to as closely match the orig- >inal artwork as possible, so the are definitely going on the >board. Yes, as they should, since, presumably, the board was functioning and it is possible that it will fail or that function will be degraded if the guard trace is removed. Only if it is clear that it is useless, which is an engineering decision, should it be removed under the circumstances described. >My question is how do I add these to the board without causing >a bunch of design rule errors in the end? Right now I'm simply >laying the track and punching the via at the end and assigning >the via to GND. No, you're doing it backwards (unless you edit the first segment of the track you put in to GND before you place more). Place the via and assign it to GND [hint; fastest way may be to pop the via down in contact with GND copper, then move it to the desired position). Then run the track from the via, it will be assigned the GND net. The way you described doing it, the track will have No-Net, and thus it will create a violation with the GND via. > I know the DRC is gonna hate this, and I depend >on the DRC to verify my design and I'd like to not have to sift >thru the DRC to decide what is a valid error and what isn't. I >want a clean DRC at the end of my board design. I think I answered the question, and what I described should be sufficient. However, if you really want to be assured that the guard trace remains even if you run the autorouter, and/or move stuff around, you can use the virtual short technique (or one of the similar alternatives) to place a virtual short at the via end, with one side going to GND -- this will have the through hole in it -- and the other side goes to a new net, I'll call it GUARD. Place on the schematic a single pin component with a pin connected to the GUARD net. (You don't have to name the net "GUARD" as long as you connect the pin to the non-ground side of the virtual short, but why not leave clues for future generations? ...) This pin gets placed at the other end of the guard trace. I think you could even with some autorouters specify this as a pair to be routed with the guarded net, but I don't know much about that. Without a routing pair rule, what I have written will not guarantee that the guard follows the guarded net closely, which usually it should, but it will guarantee that it remains on the board, DRC will detect if it is missing or broken, if not that it is misrouted. (There is a technique which can be used to route guarded traces together with the guard which is to start out with a single net, and assign a sufficiently wide trace to that net. Then, when the board is done, the single net can be replaced with two. This can be used in general to create routed pairs. Whether or not it is worth the trouble is the kind of judgement that discriminates efficient designers from those who are not....) * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To leave this list visit: * http://www.techservinc.com/protelusers/leave.html * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * Forum Guidelines Rules: * http://www.techservinc.com/protelusers/forumrules.html * * Browse or Search previous postings: * http://firstname.lastname@example.org * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *