Signal naming styles in schematics

[tggzzz]

The bigger question is what do we do about different logic levels? I like MOSI_1V8 and MOSI_3V3 for example, but other opinions would be appreciated.

That sounds like you are confusing analogue voltages with digital signals.

[dmills]

You are very lucky these days if your digital signals are all one logic level for high.

My current design has 1.5V (40R terminated, DDR3 Data and address), 1.5V differential (DDR Clocks), 80 ohm terminated, USB (90 ohm lines), LVDS (100R diff pairs), 1.8V LVCMOS, 2.5V LVCMOS, 3.3V LVCMOS, some 5V doings, some 12Gb/s CML down at the 1V common mode and a few hundred mV signal level, and that is before we get to the nominally 'analogue' doings (All the fast stuff is functionally analogue, if you have to look at eye diagrams then it is analogue design).

FPGA Projects be like that.

The days when all logic had the same reference voltage are LONG GONE, that basically never happens to me on work projects these days and annotating nets with expected voltage is valuable at review time for making checking easier.

[richard.cs]

No mention of directionality yet? At work we've started naming UART signals with things like "uC_TX_ext_RX", "uC_RX_ext_TX", "Modem_TX_Controller_RX" because too many instances of TX/RX crossovers escaped review, and many of the micros we use don't allow us to fix it by switching around in software. It seems to have helped, fewer screwups since.

[dmills]

RS232 is a hot mess for that, the whole DCE/DTE thing.
But that is why in my view SDO and SDI are right out and MOSI and MISO in for SPI, been bitten by a contractor.

Regards, Dan.

[richard.cs]

But that is why in my view SDO and SDI are right out and MOSI and MISO in for SPI, been bitten by a contractor.

Yes, I think it was that SPI naming convention that inspired the UART one.

[tggzzz]

You are very lucky these days if your digital signals are all one logic level for high.

My current design has 1.5V (40R terminated, DDR3 Data and address), 1.5V differential (DDR Clocks), 80 ohm terminated, USB (90 ohm lines), LVDS (100R diff pairs), 1.8V LVCMOS, 2.5V LVCMOS, 3.3V LVCMOS, some 5V doings, some 12Gb/s CML down at the 1V common mode and a few hundred mV signal level, and that is before we get to the nominally 'analogue' doings (All the fast stuff is functionally analogue, if you have to look at eye diagrams then it is analogue design).

FPGA Projects be like that.

The days when all logic had the same reference voltage are LONG GONE, that basically never happens to me on work projects these days and annotating nets with expected voltage is valuable at review time for making checking easier.

I understand where you are coming from, but if you go in that direction where do you stop? 50ohm, differential, terminations...

Presuming the tool allows it, I would prefer to set a net's attribute to indicate voltage. That might enable further automated DRC.

Failing that, I'd stick a comment on the schematic.

[madires]

2: Indicate the assertion level. This I do by using this style: RESET(L), ENABLE(H), LOAD(L) etc. This indicates the assertion level without compromising the net's functional name.

Don't forget to add a legend explaining that naming convention to prevent any confusion.

[dmills]

I understand where you are coming from, but if you go in that direction where do you stop? 50ohm, differential, terminations...
Presuming the tool allows it, I would prefer to set a net's attribute to indicate voltage. That might enable further automated DRC.

Failing that, I'd stick a comment on the schematic.

My usual practise is that everything gets a net class that deals with the impedance and such, and that I don't designate voltage on things like LVDS or DDR3 when it ought to be clear from the context.

Things like SPI, I2C, and other random LVCMOS stuff however do get the voltage tacked on, especially if a port name heading off to another page or such where notes on the originating page may not be remembered.

There is little point in getting dogmatic about any of this stuff, you can wind up so far down the 'coding standard' rabbit hole that you stop asking the two questions that really matter : Does it make the intent clearer for the next guy (Or me in a year), and does it help the reviewers to spot errors? Consistency is nice, but those two questions are the IMPORTANT ones. 

Regards, Dan.

[tggzzz]

There is little point in getting dogmatic about any of this stuff, you can wind up so far down the 'coding standard' rabbit hole that you stop asking the two questions that really matter : Does it make the intent clearer for the next guy (Or me in a year), and does it help the reviewers to spot errors? Consistency is nice, but those two questions are the IMPORTANT ones. 

Very true

To a large extent it is a matter of taste, and what is tasteful here isn't necessarily tasteful there.

"A foolish consistency is the hobgoblin of a little mind" - Ralph Waldo Emerson.

[emece67]

.

[nigelwright7557]

The biggest danger of using net names is accidentally duplicating one.
I try to draw gates fairly close so I just run the nets without a name.
This changes with things like GND and VCC when I just use net name tags.