Optimal width for long signal traces?

Go To Last Post
49 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have an application that will have three, 12 inch pcbs connected via pin header connectors.  

 

Three signals will be passed from one pcb to the other two.   Trace length will be  30 - 36"--pretty darn long.

 

I have series resistors at the signal sources to slow the signals down, if necessary.   The series resistance probably will NOT be necessary, since the signals are driven by an ATTiny.

 

I also have a series RC network at the receive end, to match transmission line impedance, if necessary.

 

Two of the signals are I2C and maybe driven from an external controller.  The other is a 50 Khz signal, but the faster the rise/fall times I can get, the better, since the edges provide timing info.  Slower edges will mean I'll have to worry more about phase jitter.

 

There's plenty of space on the boards, so I can make them wide Up to about 30 mils), if wide is better.   But, while wider means less series inductance, it also means more capacitance.

 

Any suggestions?

 

Thanks!

This topic has a solution.
Last Edited: Wed. Apr 1, 2020 - 12:13 PM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

For signal traces in a classic AVR system not designed for a particular characteristic impedance, trace width not a big deal. Even ordinary narrow traces are just a few 10s of milliohms per meter, DC resistance. 

 

I would NOT try to terminate TWI/I2C signal lines. That is rarely done. They are slow, on purpose ( there should be slew rate limiting inside each device ). Here is my rule of thumb: the propagation velocity in a PCB trace is about 1 foot per 1ns. Classic AVR port pins have rise and fall times on the order of 10-15ns. If the round trip time, from the pin to the end of the trace, and back, is less than the rise time, the logic will never see the transmission line effect. 

 

If you have a trace with critical timing, I would do the following (1) make it reasonably narrow, maybe 10 mils and (2) minimize the ground plane underneath. For a signal line driven by an AVR port pin, trace capacitance is going to have a much larger effect than anything else. The edge will be slowed by the 100-odd ohm output resistance of most classic AVR port pins and load capacitance.

 

Hope this helps

Jim

 

 

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Tue. Mar 31, 2020 - 11:30 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For the 50 KHz signal, you could use a bus driver (basically a high power gate) to help keep the rise time sharp & maintain best timing edge--of course the trace capacitance & inductance work against you.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Wed. Apr 1, 2020 - 07:41 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There are I2C bus extender ICs, e.g. P82B715. Do you have control over the I2C bus speed ? 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Forgot the bus extender option. Good suggestion.

 

Bus capacitance is a real limiting factor for I2C. That is because the rise time is set by the product of the pull-up resistance and the bus capacitance. The FALL time tends to be a lot faster since there is a live transistor pulling down. In many cases, this is the real limiter of bus clock speed. Long traces make it that much worse. 

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

 The other is a 50 Khz signal, but the faster the rise/fall times I can get, the better

Need us, ns, ps rise/fall?  How good do you need? If ns or ps, don't forget the jitter of the 50 KHz itself could (probably) affect any timing measurement.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You can get I2C bus extender chips.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I shouldn't have mentioned the I2C signals.  There's no speed requirement at all for the I2C bus and it will run at whatever the R pull up, C parasitic dictates.  So, it's really just about the 50 Khz signal.

 

I'll use a driver with lower output resistance if necessary, but the same pcb will have the signal as an output on the master instance, and as an input on the others.  Only processor firmware will differ between master and slave pcbs.  So, it would be better not to have a separate driver. 

 

Even ordinary narrow traces are just a few 10s of milliohms per meter, DC resistance. 

I think the series inductance is the potential issue, not the series resistance.  If it's too high for the driven rise time, I'll probably have to slow the signal down using  a higher series source resistance (non 0 value of a 0603 resistor) to avoid overshoot and ringing.  

 

There's no absolute spec on the 50 khz rise/fall time.  Faster is just better since it means less phase jitter.   Slave processors are spinning in poll loop watching the signal (spin loop verus PCI to avoid the ISR latency) and when the edges occur, 500 Khz PWM outputs are enabled/disabled.  The 50 Khz pulses are counted to determine each processor's time slots. 

 

Jitter in the start of a  PWM time slot will result in the sample window time at the receive side being not optimal.  I can't tell "good enough", until a complete system is built.  A guess would be 20 nsec phase jitter would be ok.

 

I'll use a driver with lower output resistance if necessary, but the same pcb will have the signal as an output on the master instance, and as an input on the others.  Only processor firmware will differ between master and slave pcbs. So, it would be better to avoid use of a separate driver.

 

But, there are a lot of a degrees of freedom (things I could do) to get a faster edge, but the easy one (the one I'm asking about) is trace width.  So, I'm just trying to choose the width intelligently.  Maybe doesn't matter, but it's free and easy to make it wider if that helps.  

 

I could also shorten the driven trace width by having the slave processors output the signal from its input using the LUT (ATTiny1614).   So, rather than a single SYNC signal that's a bus to each pcb, there could be SYNC_IN and SYNC_OUT on each card.

 

I could do a simulation with ATTiny GPIO model and a parameterized transmission line model, if it's not obvious whether "wider is better" or "narrow is better". 

 

 

 

 

Last Edited: Wed. Apr 1, 2020 - 12:00 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Remember the hole path.

Your reference (Gnd) is evenly important. (If you controlle high power gnd can be ugly ) 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

May i suggest that timing jitter due to prop and rise time will most likely be trivial compared to the freq/phase difference between your micros?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

May i suggest that timing jitter due to prop and rise time will most likely be trivial compared to the freq/phase difference between your micros?

 

The uP's are running at 20 Mhz, so that 50 nsec cycle time.   So, the slave processors will introduce a cycle of phase jitter (fixed delay doesn't matter, just the jitter in the delay).

 

That's important, but I thought the jitter due to rise/fall time might be on the same order and should be minimized

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you have a trace with critical timing, I would do the following (1) make it reasonably narrow, maybe 10 mils and (2) minimize the ground plane underneath. For a signal line driven by an AVR port pin, trace capacitance is going to have a much larger effect than anything else. The edge will be slowed by the 100-odd ohm output resistance of most classic AVR port pins and load capacitance.

 

I think I'll go with the 10 mil traces on a first pass, no ground plane underneath.  SYNC_IN, SYNC_OUT each processor. 

 

Remember the hole path.

Your reference (Gnd) is evenly important. (If you controlle high power gnd can be ugly ) 

You make a good point.  The cards have both a PGND and GND.  The PGND s relatively dirty, since FETS switching 1 amp at 500 khz are on it.  Locally decapped with 10 uF ceramic caps, but still...

 

Currently, only PGND is on the connector.  Something else to think about, but it would be a hassle to get the source processor's clean ground on the connector too. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

With no ground plane underneath the track, it will radiate. More so with faster edges. If there’s a lot of ground noise, maybe a current loop with optos, transformer coupled or RS422/485 drivers/receivers.
I2C definitely will not appreciate ground noise.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Radiated EMC isn't a concern.  The pcbs are inside an 1" square aluminum tube and are consequently well shielded.

 

I doubt I2C will be affected--lots of capacitance is on the net and I could add more if needed (I don't care about I2C speed).

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

davethomaspilot wrote:
Slave processors are spinning in poll loop watching the signal (spin loop verus PCI to avoid the ISR latency) and when the edges occur, 500 Khz PWM outputs are enabled/disabled.

davethomaspilot wrote:

The uP's are running at 20 Mhz, so that 50 nsec cycle time.   So, the slave processors will introduce a cycle of phase jitter (fixed delay doesn't matter, just the jitter in the delay).

 

That's important, but I thought the jitter due to rise/fall time might be on the same order and should be minimized

  You can't poll at CPU speed. There is an input synchronizer circuitry, then you read the pin and take a decision based on it. I would say that you need at least 5 cycles for the poll which means expect at least 250ns jitter overall.

 

  If this is to drive mosfets, why not send the 500kHz from master, so you no need to worry about synchronizing the two slaves ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

spin loop verus PCI to avoid the ISR latency

If you are polling you will certainly have a lot of latency---how often can you poll?  All of your code will be happening between polls. Maybe you are only polling every 10ms, 1ms, or 50us?  And the code loop is asynchronous with your edges (meaning jitter).   Or are you ONLY going to poll & do nothing else software-wise?   If that is the case, maybe use a gate instead of polling (or perhaps some of the newer AVR chip's logic can be used to make a gated PWM).  

Could you use an opto approach?...flash an led & pick it up on other boards...might work good in a sealed tube & is noise immune to gnd troubles.

 

some nice pcb info

https://courses.cs.washington.edu/courses/cse467/04wi/handouts/HighSpeedSignaling.pdf

https://blog.zuken.com/how-to-calculate-trace-length-from-time-delay-value-for-high-speed-signals/

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Thu. Apr 2, 2020 - 03:47 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Isn't the input synchronization just two FIXED clock delays?  I'm trying to optimize line width for to minimize edge jitter, not latency.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 All of your code will be happening between polls.

 

The slave processors are in spin loops doing nothing but watching the SYNC input.   There is no other "all your code".    

 

The processor outputs ARE pwm from timers.  The slave processors simple enable the hardware pwm on the appropriate output during the correct timeslot.  I could use a simple decoder to do the same thing, at the expense of having to pass more signals between pcbs for the decoder input. 

 

There are a lot of design alternatives.   But, the approach I'm using has been implemented successfully and in use for several years.  I'm doing a new design to scale it up in frequency, I used.  It's very likely the phase jitter won't be an issue at the higher target frequency, but a slow rising edge on a long timing signal is one consideration.  

 

I don't want to be rude and thanks for the suggestions, but I'm really only interested in the impact of trace width on long singal wires--not suggestions for alternative designs.   

 

Thanks for the reference on high speed signals!  I'll take a look at them.

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

angelu wrote:
There is an input synchronizer circuitry, then you read the pin and take a decision based on it. I would say that you need at least 5 cycles for the poll which means expect at least 250ns jitter overall.

 

Is that correct?  

 

Please explain why input synchronization adds jitter (I understand the delay).  I would think it would the number of clock cycles in the poll loop and that the input synchronizer only contributes to latency, not jitter.

Last Edited: Thu. Apr 2, 2020 - 01:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm looking at the PORT block diagram for the attiny1614:

 

 

For my application, I don't think a two clock cycle fixed delay matters, but more generally, when I read an input am I getting the circled net  or the output of the synchronizer?  I'm thinking the synchronized input is an optional feature for peripherals like the LUT, but I can't find a place in the spec where it makes it clear what's read for a simple digital input.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

 

This is just an aside, I'm afraid I can't actually contribute to your quest, but:

davethomaspilot wrote:
Isn't the input synchronization just two FIXED clock delays?
Not fixed.  Variable.  Hence 'synchronization'.

 

The datasheet for the t1614 doesn't seem to specify this, but the input synchronizer will result in a >>variable<< delay.  That's how it synchronizes an unknown edge arriving at any time to the the I/O clock.  The variability is, for other AVR, 0.5-to-1.5 I/O clock cycles.

 

However, given that:

davethomaspilot wrote:
I don't think a two clock cycle fixed delay matters
... then I suppose a variable delay of 0.5-1.5 cycles won't matter either.

 

From a mega datasheet:

 

 

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

  You have a jitter for the simply fact that the CPU clock is not synchronized with your 50kHz signal. Then you add the loop jitter.

 

  I wanted to point out that the hardware jitter is small in comparison with the "software" one unless the signal arrives noisy. To counter the noise, I would look at RS485.

 

  I would also go with a 10mil trace with ground plane underneath. If you use 1.6mm PCB, than trace width is about 6.3 times smaller than the PCB thickness so capacitance should not be that high.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

joeymorin wrote:

 

This is just an aside, I'm afraid I can't actually contribute to your quest, but:

 

davethomaspilot wrote:

Isn't the input synchronization just two FIXED clock delays?

 

Not fixed.  Variable.  Hence 'synchronization'.

 

The datasheet for the t1614 doesn't seem to specify this, but the input synchronizer will result in a >>variable<< delay.  That's how it synchronizes an unknown edge arriving at any time to the the I/O clock.  The variability is, for other AVR, 0.5-to-1.5 I/O clock cycles.

 

However, given that:

davethomaspilot wrote:

I don't think a two clock cycle fixed delay matters

 

... then I suppose a variable delay of 0.5-1.5 cycles won't matter either.

 

From a mega datasheet:

 

 

 

 

I think the .5 to 1.5 cycles is what you get by asynchronously (digitally) sampling and external signal.    It just depends how close the input latch gets clocked relative to the input signal transition.

 

But, there is also an "synchronizer" on the attiny1614 that appears to be two latches (see above).   So, if that synchronizer is used, I think the delay would be between 2 1/2 and 3 1/2 cycles.  

 

My point was that the delay itself is not important in my application, but the variability in delay (jitter) IS important. 

 

Not sure how many cycles are in minimum spin loop, but I think its two instructions.  That adds another cycles of jitter, since the input edge transition may occur during the conditional branch instruction instead of the "read input" instruction.  So I'm thinking worst case jitter is 2 cycles 

 

But, maybe it's just one cycle of jitter it doesn't matter when the transition occurred in the machine cycle unless  the current instruction is the input instruction.  So, I'm thinking its just one cycle of jitter. 

 

I'm not sure the two latch synchronizer is actually in the path when an input is read (my earlier question), but I don't think it really matters for what I'm looking at now.  It just adds a fixed delay--the variability in the delay is due to when the input transition occurs relative to not only which of two machine instructions are in the spin loop, but also where within the cycle the edge occurs (if it occurs during the input instruction and not the conditional branch instruction). 

 

 

 

 

Last Edited: Thu. Apr 2, 2020 - 03:45 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I wanted to point out that the hardware jitter is small in comparison with the "software" one unless the signal arrives noisy. 

 

I hope you're right.  I need to do a little math or a analog simulation to estimate the rise and fall times to  convince myself.  Maybe your experience tells you that it's an order of magnitude faster than 100 nsec?

 

Yes, I could add a driver, but I don't want to do that if it's not necessary (I doubt it is).  I just wanted to pick a trace width intelligently--which is better, narrow or wider.

 

I haven't seen an answer to that question yet.  I'll do the math or simulation and report back.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you want to opto-isolate things, isolate those FET drives.  Better, get the FETs onto an entirely separate board(s?) and take their reference ground (if you need it) all the way back to the power supply, in their own cable.  S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 I wanted to point out that the hardware jitter is small in comparison with the "software" one unless the signal arrives noisy. To counter the noise, I would look at RS485.

 

Using an online pcb trace width calculator, I'm getting about 1.3 pf/ inch for 10 mil wide trace, 1.6 mm thick board, 1 ounce copper.  So, modelling as a lumped capacitance that's about 40 pf for a 30 inch trace.  Add another 9 pf for AVR  I/O input capacitance and a rough estimate is 50 pf.

 

Time constant with assuming an AVR drive impedance of 100 ohms would be only be about 5 nsec.   And that's assuming a ground plane on the bottom of the pcb--it would be lower without the ground plane. 

 

So, Angelu seems right--5 nsec negligible compared to the 2 or 3 cycles of jitter that's a result of the processors running asynchronous compared to the 50 khz signal.  

 

Thanks!

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You are just plain better off using a gate (maybe an and gate) to gate the pwm on and off.  When the 50KHZ is high the pwm will pass though the gate & when low, it will not pass through.  Then the effect is "immediate", within 10ns or so. and thus the jitter is less than that as well.  A software reading and taking any action will be much much slower.   Probably knowing how tight you need it would really help settle the question--if you are worried about the signal trace rise/fall times then you are down to these sub microsecond timeframes.

 

Or perhaps you are indeed leading to the reverse question...if the processor response is fast enough (your are happy with it ), then the trace timings really don't matter.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Thu. Apr 2, 2020 - 06:07 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


davethomaspilot wrote:
I'm not sure the two latch synchronizer is actually in the path when an input is read
I has to be.  Otherwise the input logic would be subjected to metastability.  The compromise is a 0.5-1.5 cycle latency.  This is true of any mcu's digital inputs.  The standard way to accomplish this is with two latches.  As I've mentioned, it appears the datasheet for the t1614 glosses over this, but the synchronizer it mentions is undoubtedly for this purpose, and is not circumventable.  That is, no peripheral, GPIO, interrupt, or core logic has access to the raw, unsynchronized input signal from a pin.  Only the conditioned i.e. synchronized input signal is available, and it has an inherent jitter of 1 cycle, plus a fixed latency of 0.5 cycles.

 

The diagram you posted in #20 is similar to that in the mega datasheets (with the added functionality present in the t1614, e.g. inversion control):

 

 

However as others have said this is less than the jitter of your polling loop.

 

And again, I concede that this is likely irrelevant to your question and your application.  I simply wanted to correct what seemed to be a misunderstanding w.r.t. the input synchronizer.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That is, no peripheral, GPIO, interrupt, or core logic has access to the raw, unsynchronized input signal from a pin.

 

Probably should be a new thread at this point, since it's not relevant to the original question, but I'm thinking several peripherals DO have access to unsynchronized signals on the ATtiny1614.

 

The diagram I posted for the ATTiny1614 shows the input to the synchronization latches as being available for interrupt generation and "Digital Input/Asynchronouse Event".  The Atmega blockdiagram you posted shows a similar unsychronized signal as DIxn.

 

Reading the spec for the ATtiny1614, it appears the the raw input signal IS available for some logic blocks: 

 

EVSYS

 

A channel path can be either asynchronous or synchronous to the main clock. The mode must be
selected based on the requirements of the application.

 

You can choose whether you want the synchronized or  synchronous version 

 

 

 

PORT

 

A channel path can be either asynchronous or synchronous to the main clock. The mode must be
selected based on the requirements of the application.

 

(but it's not clear if that's just for waking the part from a sleep when no no clocks are running)

 

 

Interrupts (as noted above).

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You are just plain better off using a gate (maybe an and gate) to gate the pwm on and off.  When the 50KHZ is high the pwm will pass though the gate & when low, it will not pass through.

Cant' be a simple AND gate.  It could be a decoder. 

 

Something has to identify each PWM channel's output (active) timeslot. 

 

The obvious way is to use 4 input lines for a decoder.   The output of that decoder could then gate (something like the and gate you mention) the PWM signal.  Or simpler, the PWM signal is one of the inputs to the decoder and use the enable signals of the decoder to help qualify when the decoder should be active.

 

But the input signals required by that decoder are needed.  That's the expense I was referring to.  I have to pass the inputs of decoder to all instances rather than a single signal (new tongue twister!)

 

But a better way (except for a bit of phase jitter) is to use a single signal and have each process identify its timeslot by counting pulses on the signal.   A processor doesn't cost much more than a decoder nowadays and provides the flexibility to choose which timeslot each PWM channel should be active, or maybe even multiple channels active in a single timeslot.

 

 

 

 

Last Edited: Thu. Apr 2, 2020 - 06:54 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Problem I see with interrupt generation is that you don't know what instruction you just interrupted - or at what cycle in it -  and that instruction will complete before the interrupt is serviced.

 

At the moment, the only way I can see to get several AVRs cycle-by-cycle perfectly synchronized is by gating the clock to all of them and holding them in RESET for awhile.  Then you let go the reset line, wait a bit, and then start firing clock pulses at them.

 

There might be a better way - I dunno.  S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was just correcting the statement that raw input signals were not available to any digital peripherals on the Attiny1614.  I'm not considering using an interrupt all.

 

At the moment, the only way I can see to get several AVRs cycle-by-cycle perfectly synchronized is by gating the clock to all of them and holding them in RESET for awhile. 

 

They would only stay synchronized for a very short period of time--the individual oscillators will differ in frequency.

 

It is not necessary to have them cycle-by-cycle perfectly synchronized for my application.  

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

davethomaspilot wrote:

 

At the moment, the only way I can see to get several AVRs cycle-by-cycle perfectly synchronized is by gating the clock to all of them and holding them in RESET for awhile. 

 

 

They would only stay synchronized for a very short period of time--the individual oscillators will differ in frequency.

 

In this particular thought experiment, they're not using their own internal oscillators - their fuses have been blown to use only an external clock that I get to carefully supply.  Anyhow, as you pointed out, not required here.  Off Topic, I guess.  'ta!  S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm not clear...how do the different boards know "which" slot they are in fact reacting to on the 50KHz pulses?  Each pulse looks the same.  What keeps them all from reacting to the same pulse, rather than taking turns?

Perhaps some info is missing in the description.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Each pulse does NOT look the same.  There is one wide pulse that all processors use to identify pulse 0.  Then they each count edges to have a common notion of the current timeslot.

 

Again, I'm not interested in suggestions for an alternative implementations.  I'm fairly confident the implementation I have will work fine at 10x the frequency of the old design.  I was just considering whether wide traces on the SYNC signal would be better from a phase jitter standpoint.   The conclusion is "Not enough to matter".

 

  

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


 

davethomaspilot wrote:
Probably should be a new thread at this point, since it's not relevant to the original question
Agreed.  I won't create a new thread, as I don't wish to divide attention away from your question.  I also think it will be difficult (with the current forum software) for a moderator to spin off the pertinent posts into a new thread.

 

Let me just say a couple of more things on this sidetrack and I'll be done!

 

davethomaspilot wrote:
The Atmega blockdiagram you posted shows a similar unsychronized signal as DIxn
The table immediately after that figure has this:

 

 

It's not clear exactly what "used as a clock source" means.  Clock sources could be:

  • external input or oscillator input for the system clock
  • external input or oscillator input for a low-frequency timer peripheral's clock
  • T0/T1 timer peripheral external clock
  • SCK for SPI in slave mode
  • XCK for USART
  • SCL for TWI slave

 

The system clock is inherently irrelevant here, since the core must necessarily be clocked from it.

 

A low-frequency timer may be clocked from an unsynchronised source, but all interaction with the rest of the core is via other synchronisation mechanisms like double-buffering of relevant SFR.

 

T0/T1 external clocks are synchronised:

 

Although the datasheet is not explicit w.r.t. SPI slave mode, there is no mention of the word 'asynchronous' w.r.t. SPI slave mode.  The overriding signals table shows that DI is used by SCK input, but a private synchronisation of SCK is implied by the requirement that:

the minimum low and high periods should be:

Low periods: Longer than 2 CPU clock cycles.

High periods: Longer than 2 CPU clock cycles.

XCK is synchronised:

External clock input from the XCKn pin is sampled by a synchronization register to minimize the chance of meta-

stability. The output from the synchronization register must then pass through an edge detector before it can be

used by the Transmitter and Receiver. This process introduces a two CPU clock period delay

According to the overriding signals table, SCL does not employ DI.

 

davethomaspilot wrote:
waking the part from a sleep when no no clocks are running
This.

 

While DI is used as the input to the pin-change interrupt logic, that logic included its own synchronizer:

 

So I was imprecise with my assertion that:

That is, no peripheral, GPIO, interrupt, or core logic has access to the raw, unsynchronized input signal from a pin.

However, from the standpoint of anything that code can sample, the effect is that at least one synchronisation mechanism will stand between any external signal and any means of sampling that signal via an opcode.

 

 

    EDIT:  cruft removed, quotes added.

    "Experience is what enables you to recognise a mistake the second time you make it."

    "Good judgement comes from experience.  Experience comes from bad judgement."

    "Wisdom is always wont to arrive late, and to be a little approximate on first possession."

    "When you hear hoofbeats, think horses, not unicorns."

    "Fast.  Cheap.  Good.  Pick two."

    "We see a lot of arses on handlebars around here." - [J Ekdahl]

     

    Last Edited: Fri. Apr 3, 2020 - 12:43 AM
    • 1
    • 2
    • 3
    • 4
    • 5
    Total votes: 0

    I think that's pretty much right..

     

    But, it might be worth mentioning if one had a true need to avoid the delay of the synchronizer,  the CCL can also have inputs that don't go through the synchronizer.   And its output can be an "event" to any of several peripherals.  

     

    The CCL can also contain sequential logic, and the clock used for those latches need not be synchronous to the system clock.   It's like having some glue logic to play with on the chip.

     

    Output of the CCL can be routed to output pins without any intervening sequential logic, and its outputs can be used by several chip peripherals.  Counters can count "Events" instead of clock edges.

     

    If I go with a SYNC_IN, SYNC_OUT in my design, I'll use the CCL.  No code, no synchronization delay.  Would also work for the decoder implementation I mentioned, if I routed the required signals to each processor.

     

    The CCL and event system open up lots of new ways of doing things!

     

     

     

    Last Edited: Thu. Apr 2, 2020 - 11:27 PM
    • 1
    • 2
    • 3
    • 4
    • 5
    Total votes: 0

    That's what I was getting at in #16, you can avoid some of the processor timing slop, and replace it with faster gate logic.  There are then more techniques at your disposal to also detect the wider "zero pulse".     

    When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

    • 1
    • 2
    • 3
    • 4
    • 5
    Total votes: 0

    Just following up, now that I have the pcbs up and running.  Maybe a future reader will have a similar question...

     

    I ended up making the trace 10 mils wide over a ground plane.   1 ounce copper, 1.6 mm pcb thickness.

     

    It drives from an ATTiny1614 in  center of a 12" pcb across a pin header type connector to the center of another pcb.   Total trace length is about 12"

     

    It's driving an input of another Attiny1614 on the second pcb.  No series resistance or shunt capacitance has been added, though I've footprints for termination network(s) either at the source or receive side of the trace.

     

    The yellow trace in the o-scope picture below is the loaded trace.  The blue trace is the (unloaded) output of the second ATtiny.  This  output is driven by a LUT--the LUT has an async event channel input that is associated with the input (yellow trace).  So, the blue trace is just a buffered version of the yellow input trace.

     

     

     

     

    Attiny1614 driving 12" trace and input of 2nd Attiny1614

     

    The rise time is roughly 10 nsec.  Significant overshoot is observable, but I'm not using differential probes.  So, it's probably not as bad as it looks. 

     

    Still, I don't like seeing that much, so I'll play with the source and sink termination RC values to get something closer to critical damped and a little slower rise time isn't going to hurt.

     

    The delay in to out (LUT + async event channel + output driver delay) is about 20 nsec.

     

    The blue trace has much more overshoot--it's not currently driving another processor input.  It's shape should look identical to the yellow trace, when another pcb is connected.

     

    No phase jitter is observable between the two signals --none expected, since everything in to out is async to CPU clock.

     

    The signal  also  gates counting of Timer A.  That uses (requires) a synchronous event channel, so there will be some "jitter" in the time when the when the counter actually starts each timeslot  I think it's a maximum of 1 20 Mhz clock cycle (50 nsec).  That's much better than I think I need.

     

    • 1
    • 2
    • 3
    • 4
    • 5
    Total votes: 0

     

    If you are using a gnd clip lead on your scope probe, you can see all kinds of funny business & easily be misled (good or bad).  To be sure  to avoid it, "solder" your scope probe to the board (you can wrap some resistor lead around the probe gnd & tip and solder that to the PCB...they also sell "spring things" that are made to do this.  Of course, ensure your probe is compensated to give a proper response shape.  When doing these type of measurements, avod the clip lead at all costs--while you may see little difference, it's cheap insurance.

     

     

    so I'll play with the source and sink termination RC values

     You can really clean up the wave when things are terminated properly

     

    Overshoot in and of itself may not be an issue, as long as it doesn't interfere with the digital trip point.  An analog video signal, however, would not appreciate it so much.

    When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

    Last Edited: Sat. May 9, 2020 - 06:40 PM
    • 1
    • 2
    • 3
    • 4
    • 5
    Total votes: 0

    All in all, your scope traces are not at all surprising. The overshoot, in both cases, is probably not in the native signal, but are probably due to the scope probe connection.

     

    avrcandy's method of low inductance probe connections to circuit boards is long standing "necessary practice" (since 1970s, at least). You can make spring-things with 24 gauge copper wire. If you don't have bare wire, just strip the insulation off some solid (not stranded) 24 gauge wire. Wrap the wire on forms that are a little smaller than your probe nose parts. Then, when you push the probe into the wire coils, they will be forced to expand slightly, and make good contact. 

     

    Be careful to solder the spring wires to the circuit board BEFORE you insert the probe!

     

    Jim

     

     

     

     

    Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

    • 1
    • 2
    • 3
    • 4
    • 5
    Total votes: 0

    Yes, I'm aware of having to keep the ground loop short to get an accurate picture.   Also, differential probes help--the scope ground lead can introduce disturbances, even with the tight local loop.

     

    But experience tells me (and by looking at other signals with the same probe and ground connection) that the overshoot is excessive.  Not as bad as the oscope picture shows (as I said), but a termination network should be used.

     

    Thanks,

     

     

     

     

    • 1
    • 2
    • 3
    • 4
    • 5
    Total votes: 0

    Overshoot in and of itself may not be an issue, as long as it doesn't interfere with the digital trip point.  

     

    Overshoot can forward bias the input protection diodes.   Or, if inputs don't have protection diodes, it can inject parasitic current into a  Pwell. This can cause issues (or at least it did back on chips back in the late 70's) :-)

     

    Also, overshoot causes radiated noise.  

     

    But, I agree it's not likely to cause a functional issue.  But, usually a series resistor is all that is necessary to get critically damped signal.

     

     

     

     

     

    • 1
    • 2
    • 3
    • 4
    • 5
    Total votes: 0

    A 12" trace with nothing on the other end is an antenna.  You should expect it to radiate (poorly) and resonate (likewise).  S.

    • 1
    • 2
    • 3
    • 4
    • 5
    Total votes: 0

    But, I agree it's not likely to cause a functional issue.

    That's the nice thing about digital, it ignores interference & distortion until it quits working cheeky 

     

    Also, overshoot causes radiated noise.  

    Perhaps, if the overshoot is very spikey and narrow---many times its a slow boilover (no faster slope than the main ristime).

    When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

    Last Edited: Sun. May 10, 2020 - 05:47 AM
    • 1
    • 2
    • 3
    • 4
    • 5
    Total votes: 0

     is an antenna

    For 1 and 2 layer pcb yes, if more put ground around it. (and yes all wires are antennas but has to be a stub before i really would call it one )  

    • 1
    • 2
    • 3
    • 4
    • 5
    Total votes: 0

    For 1 and 2 layer pcb yes

    Prob the most common thing is to accidentally make a large area loop antenna...but it can be heard to "see it" geometrically.  Start at the current source & walk the loop til you get to the sink (final gnd) Maybe along the way a big loop was formed.    Of course a nice loop antenna can also pick up noise and conveniently bring it into your circuit.  Other geometries make fine antennas too, so the battle never ends.

    When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

    • 1
    • 2
    • 3
    • 4
    • 5
    Total votes: 0

    sparrow2 wrote:

     is an antenna

    has to be a stub

     

    What else would you call a trace with nothing on the other end?  S.

    • 1
    • 2
    • 3
    • 4
    • 5
    Total votes: 0

    ?

    That is why you have shielded cables, and that what you also try to make on the pcb, and that is it!