Length tuning with a 74LS123 in one of the six data lines

[luiHS]

 
This is the first time I use length tuning in a PCB design. This circuit has 6 data lines, with a HEF4050 to convert the signal levels, from 5v to 3.3v for an NXP RT1020 microcontroller.

One of the data lines with a clock signal also has a 74LS123 that formats this signal so that it accurately triggers the interruption in the microcontroller. My question is how to calculate the total length of this track to adjust the length tuning.

I calculated the total length, adding the length of the two tracks, the one that input (42.5%) and the one that output (57.5%) of 74LS123, and I adjusted to the same length as the rest of the data lines, but I'm not sure if it's correct. In the attached image, the two tracks of this data line are lit.

[Ian.M]

Anything that uses 4000 series or 74LS series logic is too slow to need length tuning.   e.g. 74LS123 typical propagation delay is 23ns, which is nearly 7m at C.   Even 1% variation in propagation delay will swamp the effects of different tracelength on any reasonable size PCB with non-pathological layout.

[montemcguire]

I agree 100% with Ian.M, and will elaborate a bit. Even if some of the data is delayed relative to other bits, you need to think about the setup and hold times of the device that is receiving the data, and skip the idea that data can be aligned really tightly through trick PCB traces and latched at infinitesimally small moments in time - there's no need for this, and it never works.

Synchronous logic will have a global clock, and you can use either transition to generate or latch data, the 0->1 or 1->0 transition. If your data gets generated a little after the clock line's 0->1 transition, arrange for the receiver to clock it at the clock line's 1->0 transition, maybe by using an inverting clock input or an explicit inverter on the clock line. That way, you have one half clock cycle for the data to stabilize and charge the input circuit of the receiving device before you tell the receiver to latch the data, and you have another half cycle where the sender's data is still stable, so that the receiving device can properly latch the data without it changing.

You can alternatively skew the clock of the data producing circuit by one half cycle (generate on clock 1->0) if you want to keep the controller's clock set to latch on a rising (0->1) clock pulse - it's only the relative clock transitions that matter. But, to repeat, the important trick is to produce data and latch the data on opposite transitions of the clock line, so that you get a free half cycle of clock delay to let everything settle. With any sensible clock frequency, a half cycle will be much longer than your entire PCB, so squiggly traces are not needed at all, nor are they reliable. Always check the setup and hold times of the receiver circuit (the GPIO pins on your microcontroller?) to make sure - that, along with the delays and skew of your external logic will determine the maximum half-period of your clock. It's likely that this will still be an extremely small number, allowing a very fast clock if you need it.

[In Vacuo Veritas]

Jesus, that's like putting the exhaust of a Lamborghini Huracán on a Yugo. Why do newbies copy things they see without understanding what they do or why they're used or why they're completely irrelevant to their circuit?

Is it to look k3wl??

[Ian.M]

Rear Admiral Grace Hopper had a very good visual aid for the lengths involved at the nanosecond timescale.

Cut yourself a 'nanosecond' and stick it up along the edge of a shelf behind your bench, to make yourself permanently immune to speed of light delay stupidity.

Edit: original video went AWOL.

[luiHS]

I agree 100% with Ian.M, and will elaborate a bit. Even if some of the data is delayed relative to other bits, you need to think about the setup and hold times of the device that is receiving the data, and skip the idea that data can be aligned really tightly through trick PCB traces and latched at infinitesimally small moments in time - there's no need for this, and it never works.

Synchronous logic will have a global clock, and you can use either transition to generate or latch data, the 0->1 or 1->0 transition. If your data gets generated a little after the clock line's 0->1 transition, arrange for the receiver to clock it at the clock line's 1->0 transition, maybe by using an inverting clock input or an explicit inverter on the clock line. That way, you have one half clock cycle for the data to stabilize and charge the input circuit of the receiving device before you tell the receiver to latch the data, and you have another half cycle where the sender's data is still stable, so that the receiving device can properly latch the data without it changing.

You can alternatively skew the clock of the data producing circuit by one half cycle (generate on clock 1->0) if you want to keep the controller's clock set to latch on a rising (0->1) clock pulse - it's only the relative clock transitions that matter. But, to repeat, the important trick is to produce data and latch the data on opposite transitions of the clock line, so that you get a free half cycle of clock delay to let everything settle. With any sensible clock frequency, a half cycle will be much longer than your entire PCB, so squiggly traces are not needed at all, nor are they reliable. Always check the setup and hold times of the receiver circuit (the GPIO pins on your microcontroller?) to make sure - that, along with the delays and skew of your external logic will determine the maximum half-period of your clock. It's likely that this will still be an extremely small number, allowing a very fast clock if you need it.

Probably you are right, but then this is the problem.

A circuit that receives data signals from a machine, Data, Clock and some synchronism signals that trigger interrupts to process data by DMA.  The 4050 is used to convert data signal levels from 5v to 3.3v to connect it to a Kinetis MK66 microcontroller.

If the 4050 is not very close to the microcontroller, with very fast signals there is a loss of synchronism in the data captured by DMA (SPI), of one or two bytes, the same happens if a CD4050 is used instead of a HEF4050, and seem that work better with 74LS123 than with 74HCT123.

I'm trying things, that's how you discover what happens and how to solve it. If, as you say, there is no sense in tuning the track length, then:

1.- Why with very fast signals some data is lost if the 4050 is not very close to the microcontroller?, Shorter tracks, and therefore also less length difference between them.

2.- Why, if I install a CD4050 instead of a HEF4050, do I have the same problem with fast signals?


PS: for the other guys who are dedicated to disrespect, it's not worth responding, it's better to ignore them. Unfortunately in all places there are undesirable people, what we are going to do, patience.

[Ian.M]

Any brand of CMOS 4050 hex buffer is a *lousy* choice for downwards logic level conversion.  Although its specced to operate down to  3V Vcc, none of its timing or output level or drive  parameters are specced below 4.5V Vcc, and even at 5V, its propagation delay and output drive capability is not very good.   At 3.3V I'd bet its weak enough that noise pickup on long output traces is likely to be a significant problem, hence your need to position it close to the MCU.  Total capacitive load is also an issue so you'd need to be careful with the total area of the output traces and also need to minimise the fanout.

What you should be doing is either using a dedicated level converter with separate Vcc supplies for its input and output, or a 3.3V optimised logic family with 5V tolerant inputs.   You'll find both within many manufacturers versions of the 74LVC logic family.

e.g 74LVC1G45 bidirectional single, and 74LVC2G45 bidirectional two bit, level converters with a direction control pin and separate VccA and VccB pins that can convert between any levels in the range 1.8V to 5.5V, or the 74LVC245, an octal bus transceiver that runs at 3.3V but is 5.5V tolerant on all inputs.   The worst case propagation delay will be under 8ns.

I don't know what you are trying to do with a 74xx123 monostable, but neither the 74HCT or 74LS families are specced for operation below 4.5V, so unless you have added logic level conversion after them, they aren't suited for use with a 3.3V MCU.   Perhaps look at the 74LVC1G123.

Fast logic needs an effective ground plane.  Long slots in it caused by routing signal or power traces on the same side as the groundplane are highly undesirable.   Patching together islands of copper on both sides stitched together by a minimal number of vias does *NOT* provide an effective groundplane.  Try and keep the signals on the other side, and minimise trace lengths on the groundplane side even though it will need extra vias to swap sides more frequently.
 

[In Vacuo Veritas]

"I'm trying things, that's how you discover what happens and how to solve it."

¡Joder! It's also how you waste time re-inventing a square wheel, and arriving at preposterous conclusions. Then having convinced yourself that you're right, you repeat the bullshit to others.

¡Fíjate! Part of learning is realizing you were wrong.

So, did you simulate the delay of the vias? How can you be sure the rising edges arrive at the same femtosecond on your 20MHz logic chip in a SOIC package?