freeDFM & via issue

Hi,

When I'm testing it I have just one DRC error with design rule

www.my4pcb.com you have select !!!

Guy

PS: I'm affray, you don't use any condensators on this card !!!

I think you must minimum add decouplers condensators to be sure work ok !!!

"Ron" <viaEagleForum@RGMEusa.com> a écrit dans le message de news:

fohhbe$6br$1@cheetah.cadsoft.de...

I have a board I've submitted to freeDFM. Their error report for that board

is at:

.   https://www.freedfm.com/freedfm/0011385401921358/results/summary2.htm

The .brd file (only that file) I've made available at:

.   http://www.RGMEusa.com/Misc/USBto64RW.zip

 

I've already addressed all the issues not related to vias in another board

version, my only remaining problem is the one concerning freeDFM's

complaint

about every one of the board vias.

 

If you look at the freeDFM error report it appears to my eye that all the

vias have no drill and they appear to all be filled in as if they were

pads

instead of vias going through all 4 layers. I've also made available a

screen shot combination picture of the board concerning just one of the

via

issues (the X=0.7641", Y=2.2966" example):

.   http://www.RGMEusa.com/Misc/SampleVia.jpg

 

It all seems ok to me so I haven't a clue as to why freeDFM is

complaining.

In the combo screen shot I see it reports a drill for the example via as

0.015" and a diameter of "0.031/0.031 (auto)". I don't understand the

diameter syntax being used, meaning it looks to me like it is reporting 2

parameters separated by a "/" character. What is the definition of the 2

parameters which in the screen shot are identical to each other? If one

parameter is mathematically divided by the other the result is a zero

value;

is THAT the reason freeDFM is complaining?

 

I need help understanding the nature of the problem and how to fix it. I

did

generate the Execellon file while the board was displayed in the editor,

that's what was sent to freeDFM. TIA!

-Ron

 

 

Attachments:

Ron wrote:

I have a board I've submitted to freeDFM. Their error report for that board

is at:

..   https://www.freedfm.com/freedfm/0011385401921358/results/summary2.htm

The .brd file (only that file) I've made available at:

..   http://www.RGMEusa.com/Misc/USBto64RW.zip

 

I've already addressed all the issues not related to vias in another board

version, my only remaining problem is the one concerning freeDFM's complaint

about every one of the board vias.

 

If you look at the freeDFM error report it appears to my eye that all the

vias have no drill and they appear to all be filled in as if they were pads

instead of vias going through all 4 layers. I've also made available a

screen shot combination picture of the board concerning just one of the via

issues (the X=0.7641", Y=2.2966" example):

.   http://www.RGMEusa.com/Misc/SampleVia.jpg

 

It all seems ok to me so I haven't a clue as to why freeDFM is complaining.

In the combo screen shot I see it reports a drill for the example via as

0.015" and a diameter of "0.031/0.031 (auto)". I don't understand the

diameter syntax being used, meaning it looks to me like it is reporting 2

parameters separated by a "/" character. What is the definition of the 2

parameters which in the screen shot are identical to each other? If one

parameter is mathematically divided by the other the result is a zero value;

is THAT the reason freeDFM is complaining?

 

I need help understanding the nature of the problem and how to fix it. I did

generate the Execellon file while the board was displayed in the editor,

that's what was sent to freeDFM. TIA!

-Ron

 

 

I don't see any problem there. Lets see the Drill tab on your CAM

project. I bet something is not selected in the CAM properly.

--

Travis Grenell

The CarPC Store

404-403-0556

http://www.TheCarPCStore.com

Ron wrote:

I have a board I've submitted to freeDFM. Their error report for that board

is at:

.   https://www.freedfm.com/freedfm/0011385401921358/results/summary2.htm

The .brd file (only that file) I've made available at:

.   http://www.RGMEusa.com/Misc/USBto64RW.zip

 

I've already addressed all the issues not related to vias in another board

version, my only remaining problem is the one concerning freeDFM's complaint

about every one of the board vias.

 

If you look at the freeDFM error report it appears to my eye that all the

vias have no drill and they appear to all be filled in as if they were pads

instead of vias going through all 4 layers. I've also made available a

screen shot combination picture of the board concerning just one of the via

issues (the X=0.7641", Y=2.2966" example):

.   http://www.RGMEusa.com/Misc/SampleVia.jpg

 

It all seems ok to me so I haven't a clue as to why freeDFM is complaining.

In the combo screen shot I see it reports a drill for the example via as

0.015" and a diameter of "0.031/0.031 (auto)". I don't understand the

diameter syntax being used, meaning it looks to me like it is reporting 2

parameters separated by a "/" character. What is the definition of the 2

parameters which in the screen shot are identical to each other? If one

parameter is mathematically divided by the other the result is a zero value;

is THAT the reason freeDFM is complaining?

 

I need help understanding the nature of the problem and how to fix it. I did

generate the Execellon file while the board was displayed in the editor,

that's what was sent to freeDFM. TIA!

-Ron

 

 

Ron

Referring to "http://www.RGMEusa.com/Misc/USBto64RW.zip", I see problems

that will cause your board to fail to work correctly:

1) There are NO power and ground planes.  With a 4 layer board, usually

the 2 inner layers are used for power and ground.  In  your case, this

is VCC and VSS.  At the minimum, use a gridded power scheme.  Using

copper flooding for GND (VSS) is also a good idea.

2) I don't see any bypass/de-coupling and bulk capacitors.  There should

be a 0.1uF ceramic bypass cap near each TTL and CMOS chip.

Texas Instruments' publication # SZZA009 shows how to create a gridded

power and ground system.  This doc also has other good ideas.

HTH

-Dave Pollum

"Travis G" <fightspammers@gmail.com> wrote in message

news:fohqsm$tdq$1@cheetah.cadsoft.de...

Ron wrote:

I have a board I've submitted to freeDFM. Their error report for that

board is at:

..

https://www.freedfm.com/freedfm/0011385401921358/results/summary2.htm

The .brd file (only that file) I've made available at:

..   http://www.RGMEusa.com/Misc/USBto64RW.zip

 

I've already addressed all the issues not related to vias in another

board version, my only remaining problem is the one concerning freeDFM's

complaint about every one of the board vias.

 

If you look at the freeDFM error report it appears to my eye that all the

vias have no drill and they appear to all be filled in as if they were

pads instead of vias going through all 4 layers. I've also made available

a screen shot combination picture of the board concerning just one of the

via issues (the X=0.7641", Y=2.2966" example):

.   http://www.RGMEusa.com/Misc/SampleVia.jpg

 

It all seems ok to me so I haven't a clue as to why freeDFM is

complaining. In the combo screen shot I see it reports a drill for the

example via as 0.015" and a diameter of "0.031/0.031 (auto)". I don't

understand the diameter syntax being used, meaning it looks to me like it

is reporting 2 parameters separated by a "/" character. What is the

definition of the 2 parameters which in the screen shot are identical to

each other? If one parameter is mathematically divided by the other the

result is a zero value; is THAT the reason freeDFM is complaining?

 

I need help understanding the nature of the problem and how to fix it. I

did generate the Execellon file while the board was displayed in the

editor, that's what was sent to freeDFM. TIA!

-Ron

I don't see any problem there. Lets see the Drill tab on your CAM project.

I bet something is not selected in the CAM properly.

 

--

Travis Grenell

The CarPC Store

404-403-0556

http://www.TheCarPCStore.com

Hmmm. I don't think I have such an animal, Travis. I used the Excellon job

while the project was loaded, per the manual. It just spat out the 2 drill

files for gerber inclusion. I noticed theat one of the 2 files has a

different filename suffix than what the manual specifies it should be, but

freeDFM didn't complain about that (I don't think) so the format must have

been ok? They looked ok to me (which means little). Is that what you want to

see? If so, I'll have to put the Excellon file onto the server tonight after

work. When I look only at layer 44, Drills, I see what appears to be overlap

of drills but all vias are supposed to go through all layers and not some of

them through just some layers, so that's giving me some confusion. Or do you

mean you want to see the actual cam job, a modified GERBER_RS274X job? Gotta

hold my hand a bit here, I'm not experienced enough yet to understand some

things that in time will become crystal clear to me!

-Ron

Ron wrote:

  > Hmmm. I don't think I have such an animal, Travis. I used the

Excellon job

while the project was loaded, per the manual. It just spat out the 2 drill

files for gerber inclusion. I noticed theat one of the 2 files has a

different filename suffix than what the manual specifies it should be, but

freeDFM didn't complain about that (I don't think) so the format must have

been ok? They looked ok to me (which means little). Is that what you want to

see? If so, I'll have to put the Excellon file onto the server tonight after

work. When I look only at layer 44, Drills, I see what appears to be overlap

of drills but all vias are supposed to go through all layers and not some of

them through just some layers, so that's giving me some confusion. Or do you

mean you want to see the actual cam job, a modified GERBER_RS274X job? Gotta

hold my hand a bit here, I'm not experienced enough yet to understand some

things that in time will become crystal clear to me!

-Ron

I'd like to see the actual job (ends in .cam) plus your generated drill

files (usually .drd and also the .dri file) to compare everything, step

by step.

--

Travis Grenell

The CarPC Store

404-403-0556

http://www.TheCarPCStore.com

2) I don't see any bypass/de-coupling and bulk capacitors.  There should

be a 0.1uF ceramic bypass cap near each TTL and CMOS chip.

Agree with you

Guy

"Guy" <guy.dau_no_spam@free.fr> wrote in message

news:fohqh1$sgn$1@cheetah.cadsoft.de...

Hi,

 

When I'm testing it I have just one DRC error with design rule

www.my4pcb.com you have select !!!

 

Guy

 

PS: I'm affray, you don't use any condensators on this card !!!

I think you must minimum add decouplers condensators to be sure work ok

!!!

Yes, that version had too tight of clearance for those 2 pins - I corrected

that already. Annoyed me, as when I auto routed that one trace the DRC rules

were not followed and I had to move the trace manually one grid away from

IC1. Luckily, there is a DRC check button!

Guy, this design (and the hand wired proto) definitely does not need VCC

bypass capacitors. It's a state machine, no clocking, and the USB module

(it's not a chip) includes its own decoupling to the USB buss; what that

module connects to is not powered by the USB buss and it is rather slow and

usually just sitting in one state. I do, however, need to (or should)

increase distance between the Power class traces. I gotta rip again anyhow

when I find out why freeDRM doesn't like the vias, I'll change the class

then.

-Ron

"Ron" <Use@Forum.pls> a écrit dans le message de news:

foicn5$rug$1@cheetah.cadsoft.de...

"Guy" <guy.dau_no_spam@free.fr> wrote in message

news:fohqh1$sgn$1@cheetah.cadsoft.de...

Hi,

 

When I'm testing it I have just one DRC error with design rule

www.my4pcb.com you have select !!!

 

Guy

 

PS: I'm affray, you don't use any condensators on this card !!!

I think you must minimum add decouplers condensators to be sure work ok

!!!

 

Yes, that version had too tight of clearance for those 2 pins - I

corrected that already. Annoyed me, as when I auto routed that one trace

the DRC rules were not followed and I had to move the trace manually one

grid away from IC1. Luckily, there is a DRC check button!<smile>

 

Guy, this design (and the hand wired proto) definitely does not need VCC

bypass capacitors. It's a state machine, no clocking, and the USB module

(it's not a chip) includes its own decoupling to the USB buss; what that

module connects to is not powered by the USB buss and it is rather slow

and usually just sitting in one state. I do, however, need to (or should)

increase distance between the Power class traces. I gotta rip again anyhow

when I find out why freeDRM doesn't like the vias, I'll change the class

then.

-Ron

No !!

It's not because it's a state machine and no clocking then decoupling is not

necessary !!!

With all these circuits and not decoupling, alimentation can start in

resonance !!!

With many TTL and CMOS you don't know alimentation reaction !!

I think you must define any bypass/de-coupling and after perhaps not

necessary to put all but you don't know !!!!!

After many years of electronic developpement.......

Sorry for my english,

Guy

"Guy" <guy.dau_no_spam@free.fr> wrote in message

news:foiedu$vrq$1@cheetah.cadsoft.de...

 

"Ron" <Use@Forum.pls> a écrit dans le message de news:

foicn5$rug$1@cheetah.cadsoft.de...

"Guy" <guy.dau_no_spam@free.fr> wrote in message

news:fohqh1$sgn$1@cheetah.cadsoft.de...

Hi,

 

When I'm testing it I have just one DRC error with design rule

www.my4pcb.com you have select !!!

 

Guy

 

PS: I'm affray, you don't use any condensators on this card !!!

I think you must minimum add decouplers condensators to be sure work ok

!!!

 

Yes, that version had too tight of clearance for those 2 pins - I

corrected that already. Annoyed me, as when I auto routed that one trace

the DRC rules were not followed and I had to move the trace manually one

grid away from IC1. Luckily, there is a DRC check button!<smile>

 

Guy, this design (and the hand wired proto) definitely does not need VCC

bypass capacitors. It's a state machine, no clocking, and the USB module

(it's not a chip) includes its own decoupling to the USB buss; what that

module connects to is not powered by the USB buss and it is rather slow

and usually just sitting in one state. I do, however, need to (or should)

increase distance between the Power class traces. I gotta rip again

anyhow when I find out why freeDRM doesn't like the vias, I'll change the

class then.

-Ron

No !!

 

It's not because it's a state machine and no clocking then decoupling is

not necessary !!!

 

With all these circuits and not decoupling, alimentation can start in

resonance !!!

 

With many TTL and CMOS you don't know alimentation reaction !!

 

I think you must define any bypass/de-coupling and after perhaps not

necessary to put all but you don't know !!!!!

 

After many years of electronic developpement.......

 

Sorry for my english,

 

Guy

This is getting way off topic but I do respect and appreciate your usage of

English, please do not apologize. Although you could use a few less "!!!!!"

characters!!!!!  You are understandable and if the situation were

reversed I'd be, knowing only English, unable to return the courtesy.  But

most of all I respect your knowledge.

I would again try to qualify my agreement with what you say, which I believe

to be a reference to a phenomenon known as parasitic resonance and which is

a common annoyance in RF circuits. RF infers oscillation, and oscillating

circuits have maximum power response at a resonant frequency.  My point is

that there must be oscillation before there can be resonance, parasitic or

not. This occurs in digital circuits primarily because of repeating patterns

of current flow at high bit level changing rates (what I mean by "clocked",

be it data pattern repetition or any other time base). The capacitive

"decoupling" or "bypassing" is actually the detuning of the resonant

circuit, dampening the amplitude of unintended oscillations to negligible

level.  This is usually a very important consideration.

But, if my design works (and the prototype does) and it experiences

oscillations then it is malfunctioning because the amplitude of the

oscillation would have to be of sufficient energy as to overpower the power

supply as relates to the guaranteed high or low level specified for a gate

input. If the power supply is working and distributed properly then that

would have to be a rather huge amount of energy.  Without oscillation there

can be no resonance.  If there can be no resonance then decoupling is not

required.

In this board all I/O is inherently latched. Even when changing at USB 2.0

speed, the amount of time between cycles of a particular bit pattern that

just happens to be resonant is what keeps enough energy from entering the

tank to build sufficiently to overcome the power supply to a level where a

gate would see a logic change. There simply aren't enough such cycles within

a sufficiently small enough time period to build enough energy in a tank to

sustain oscillation. If Murphy gets into the act regardless, then the

mentioned time period can be lengthened by slowing down USB usage - thus

detuning the tank.

This board is an exception to the general rule that decoupling should be

used. Primarily because it is latched and not clocked by some means.

Repetitive tank pumping is not likely because repetitiveness does not exist

in a latched circuit like it does in a clocked circuit. It would not hurt to

use decoupling, except for production cost. My only worry with the entire

design is that I might be exceeding the fan out rating of the USB module. If

so, the resultant instability is not due to resonance or oscillation. On

this board decoupling would be of little use, malfunction must begin before

resonant oscillation can occur.

-Ron

"Guy" <guy.dau_no_spam@free.fr> wrote in message

news:foicb4$qva$1@cheetah.cadsoft.de...

2) I don't see any bypass/de-coupling and bulk capacitors.  There should

be a 0.1uF ceramic bypass cap near each TTL and CMOS chip.

 

Agree with you

 

Guy

Ok Guy(s)! Have mercy. I don't deny it's good design practice but I'm not

using the advice with this particular design. Please, I need to keep the

topic focus to the subject line of this thread.

-Ron