I guess what I really want is for Protel's bus-naming stuff to work like ViewDraw.  
I've used it and it worked just fine (in this respect at least) for a much more 
complicated design.  
And above all, the way that it works, good or bad, is CLEARLY WRITTEN DOWN IN THE 
****ING MANUAL unlike Protel99...

In Viewdraw, the 'bus label' connecting to the submodule's port determines what gets 
hooked to what.  If draw a bus with label FOO[7,5,3,1] connected to a submodule port 
BAR[0:3] you get exactly what you drew--FOO[7]->BAR[0], FOO[5]->BAR[1], etc.  
Flexible, and WYSIWYG.
This is the only design I've ever seen that makes sense--other CAD vendors [hint hint] 
should wise up and rip it off!! 

-----Original Message-----
From: Abd ul-Rahman Lomax [mailto:[EMAIL PROTECTED]] 
Sent: Wednesday, February 12, 2003 2:50 PM
To: Peter W. Richards
Subject: RE: [PEDA] Buses

At 05:24 PM 2/10/2003, you wrote:
>I'm sure glad someone at Protel worked on that whizzy 3D board viewer
>instead of making buses/hierarchy actually work for nontrivial designs--NOT!

Actually I've seen a number of CAD systems fall down when one looks too 
closely at how hierarchical designs are handled. OrCAD Capture can be a 
nightmare, it is too unpleasant to remember, it would ruin my day.

with the workaround I gave, Protel actually works as it should, it is just 
a nuisance that one has to essentially rename the nets, but the renaming 
can be done at the top level, which is tolerable. In other words, the 
re-used sheets can be used as-is.

>On a related Protel-sabotaging-design-reuse note, is there a way to 
>a sub-module and connect one of its inputs to power or ground, without 
>getting ERC errors that claim I've shorted two nets (for example GND vs. 
>the net name

I'd have to think about this, and no time for that at the moment. But my 
comment is that once one knows the cause of an error or warning, and knows 
for sure that netlisting will be correct, it is both safe and advisable to 
place a No-ERC directive on the error or warning where it appears, thus 
suppressing it.

Nets are generally named at the highest level at which they occur, by the way.

Basically, once you know how to handle it, Protel works fine with design 
re-use. But for sure they could make it more transparent. And it would be 
helpful if buses could be connected sequentially instead of the present 
explicit requirement; note, however, that explicit at least has the 
advantage of being utterly .... explicit.

Sometimes one is only picking off part of a bus: which segment would be 
picked off if sequence is used instead of explicit identity? There is a way 
to deal with this, I am sure, but my point is that it is not quite as 
trivial a problem as it might seem. The present structure does allow what 
needs to be done -- through net renaming -- forcing one to be explicit.

In the instant case as I recall it, we wanted to connect, say, Y0-Y7 on a 
subsheet to Z8-Z15 out of a bus Z0-Z15 on the top level. If we simply 
connect the bus Z0-Z15 to the sheet entry Y0-Y7, how is Protel to know that 
we want anything other than Z0 to Y0, Z1 to Y1, etc.?

An answer would be if Protel treated a local bus net label as controlling 
assignment by sequence. If one has a bus A0-A15 and then places, on the bus 
wire immediately next to the sheet entry, a net label A[8..A15], Protel 
should know that we want to assign 8 to 0, 9 to 1, etc.

It appears that if a bus A[0..15] exists on a sheet, instances of subsets 
of that on the sheet are treated as equivalent. That is the problem, and 
this is why the fix is to use a completely different bus name and rename to 
make the equivalents explicit.

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* To post a message: mailto:[EMAIL PROTECTED]
* To leave this list visit:
* http://www.techservinc.com/protelusers/leave.html
* Contact the list manager:
* Forum Guidelines Rules:
* http://www.techservinc.com/protelusers/forumrules.html
* Browse or Search previous postings:
* http://www.mail-archive.com/proteledaforum@techservinc.com
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Reply via email to