Interesting - and complex! All of the above design comments are usefully correct and should be followed.
For TTL, as noted, up to 10 inputs can be tied high together through a single 10K resistor for a 'one'. (Not using a resistor will work but isn't good practice.)
Any input can be connected directly to 0V for a 'zero'. Unless it's an exotic IC which specifically notes otherwise in the datasheet, unused inputs should never be left floating. (Else, it may work as hoped - some of the time!) An undefined input may also be sensitive to static depecding upon the logic family - at best it would change the state - at worst it could destroy the input/chip.) Not good or professional.
As for outputs, (check the datasheet for your family), a red LED with a 470R resistor to +5V can be driven from a logic '0', but you should not try to drive an LED by connecting it to ground, If you must connect it ground or need more than 10mA of drive, some form of power buffer (transistor, etc) is required. Other colours of LED than red have different voltdrops: recalculate as necessary, but blue LEDs won't usually work here.
As to your design, from the outline spec you gave, it seems a little compex with undescribed features? I don't know your intended use for this, which may be exactly fulfilled by your design, but as a general idea could I suggest another approach?
Your design appears to be based on the american system as the british have an additional phase of R+Y as 'prepare to go'. But what concerns me is that there is no dwell built in to allow traffic to stop in one direction before being released in the other. Also, with a longer green cycle, there's no way a matching cross stream could be equally timed.
With a timebase of 3 seconds, could I suggest R=10, G=5, Y=1 which will allow a matching cross stream on the same count base: R=1, G=5, Y=1, R=9
This could be more easily implimented with a 0-15 decoder and combining the groups from this for each LED:
- Logic can combine every required count to light a specific LED, or
- Specific counts can set/clear flipflops for each LED
Plus, as this the american system, only one LED is on at a time for each direction, so Red (10 counts) can only be on when Green (5 counts) and Yellow (1 count) are both off.... which Simplifies the decoding even further! (You could now use a 4 bit binary counter instead of the 0-15?)
So, see how things could be simplified. e.g. the count number for each transition doesn't have to be as implicitely defined, as after the first 16 counts, it isn't synchronised to anything. i.e your design could define a Yellow as the 0000 count or 1111 count as it's easier to decode, but does that impact adversely on any other logic design requirement? POR logic may need to clear the counters/flipflops That way, at least it would start up on all red!
Sorry if I've gone off on a tangent, but it may be of interest to some other reader. Remember: think outside the box, don't give up, and good luck with your design.
- - - Updated - - -
Having thought about the design concept a little more (having just woken up from a nightshift!) a couple of other points arise. It usually pays to consider enhancements / expansion or variations, even if they don't make their way into the final design as they may have a bearing on the design philosophy.
For example, my back-of-a-fag-packet design for two streams has a 0-15 counter, 2 flipflops, and a few gates for POR and Red decodes. If the streams are non-symmetrical, or on-demand, do you need a way to pause the counter or shorten the cycle? Choose different trigger counts etc? More resolution? Turn filters? A heartbeart (Clock) LED could be reassuring. Designing a PCB for production could incorporate alternate choices without actually populating them. Octal driver chips are good too for outputs! Going to CMOS would ease power supply requirements. ... And so it goes on.
But then again, the more complex you make it, the more a PIC or micro looks attractive.... But it doesn't change the basic design points outlined above by others! Make it foolproof. (Idiots are too intelligent and will break it anyway!)