Is this *really* SSOP16 ?

[SpacedCowboy]

Looking at putting a USB hub into a project, and the SL2.1S caught my eye because it's dirt cheap and looks trivial to use. I thought I'd spin a test-board, but I'm having some difficulty creating the part in Eagle.

The below are the datasheet specs and what Eagle thinks an SSOP16 is - with the grid set to 1mm.

The Eagle part has an 'e' pin-separation of 0.65mm not 0.5mm, the 'B' width is 7mm not 4.15mm etc. Basically nothing matches. In the absence of anything else, I'm going to go with the data sheet obviously, but I was wondering if this is a standard size footprint that I just can't seem to find.

[wraper]

0.53mm pin pitch does not look standard at all.

[SpacedCowboy]

Yeah, for the extra $0.09, the SL2.2S seems to be in a standard SSOP28 package. Well, the pad-separation is 0.635 not 0.65mm, but that's probably fine.

I guess I'll go for the SL2.2S - and even get LEDs

[wraper]

Yeah, for the extra $0.09, the SL2.2S seems to be in a standard SSOP28 package. Well, the pad-separation is 0.635 not 0.65mm, but that's probably fine.

I guess I'll go for the SL2.2S - and even get LEDs

0.015mm difference on 28pin part is enough to cause problems with standard footprint. Outer pins will be shifted by 0.1mm if IC is centered to pins in the middle. Also it's a pin pitch, pad separation is way smaller.

[SpacedCowboy]

I got the same 0.1mm difference, pin width is 0.3mm, I guess I thought it would be ok. It ought to fit SSOP28 if it claims it in the data sheet - having said that, looking at what they were claiming was SSOP16, well...

Not such a big deal to change them anyway, so might as well

[mon2]

Do note that this hub controller is a single-TT design (STT). So if you have high speed & low speed products operating to use this hub, the high speed throughput will suffer.

Better solution is to use a MTT hub controller.

[SpacedCowboy]

Thanks for the heads-up, mon . I don't *think* it'll be an issue in this case, though.

The idea is I'm going to use it to split off the USB2 D+/- lines in the micro-USB3 connector, and then (from the hub), connect through to the FT601, which will talk to the FPGA. To program the FPGA I want to put in a microcontroller, probably the RP2040. Something like:

Code: [Select]

┌───────┐                      ┌──────┬─────────┐      ┌────────┐
│       │                      │ USB3 │         │      │        │
│       │◀━━━━━━━━━━━━━━━━━━━━▶│      │         │      │        │
│USB3 µB│      ┌────────┐      ├──────┤ FT601   │◀════▶│        │
│       │      │ SL2.2s │      │ USB2 │         │      │        │
│       │◀────▶│        │◀────▶│      │         │      │  FPGA  │
└───────┘      └────────┘      └──────┴─────────┘      │        │
                    ▲                                  │        │
                    │          ┌──────┬─────────┐      │        │
                    └─────────▶│ USB2 │ RP2040  │◀════▶│        │
                               └──────┴─────────┘      └────────┘

I'm pretty much fine with the speed of that subsystem being 12 MBit, it's just for (re)configuration and the FT601 can cope with either "Full" or "High" speed USB2. The real heavy lifting is going to be over the USB3 port.

I'm not actually sure yet whether you even need to connect up the USB2 hub part of the FT601, but you can't split a USB3 port across multiple targets (USB3->chip A, USB2->chip B) anyway, so the hub has to be there unless I want 2 USB ports, and it'd be neater to just have the one cable.

[eugene]

What's stopping you from creating a custom footprint? Once you understand the process, it can be done in less time than it took you to write up your adventure and post it here.

[rob77]

yes custom part in eagle is the way to go.  once you get the hang of it, you can create custom symbol + footprint in eagle faster than searching the web for it, especially if it's "weird" part.

[SpacedCowboy]

What's stopping you from creating a custom footprint? Once you understand the process, it can be done in less time than it took you to write up your adventure and post it here.

Nothing, and I did 

I’ve been using Eagle for almost 20 years now, I have a very extensive set of personal libraries. Normally when I see a part claim to be something, I expect it to fit that footprint though, and if it doesn’t, it means I’ve missed something…

I’ve had the occasional email back from the assembly folks along the lines of “Hey dummy, this part you specified isn’t SOIC-8, it’s xxx-8” , usually at the last stage of assembly when someone’s actually tried to put the part onto the board. Just thought I’d ask to see if this was another well-known part-type.

So I’ve shrunk the body width down to 4.1mm, and set the pad separation to 0.635mm, and I guess we’ll see how well it fits the data sheet when it comes back

I will admit to being opportunistically lazy, because the samacsys plugin is awesome, but I still modify their schematic symbols to suit

• I’m not a fan of “the symbol must reflect the physical location of the pins”
• I group my commonly-named pins as (example: GND@1,GND@11) rather than GND_1 and a separate GND_2
• I prefer my anchor point to be the center of the symbol
• If it’s NC then I like to use the ‘nc’ direction
• I use bottom-left anchors for >NAME & >VALUE and reposition them to top/bottom of the symbol
• The font-height in the footprint is too big (I prefer 32mil) and for some reason they superimpose name/value over each other
• I like to add a USE attribute at the device level, which is what my scripts look for to generate BOMs. There’s a warning if a part doesn’t have one of USE or DNF (do not fit)

… but having theirs as a starting point cuts down on linking together pin and pad, and measuring out the footprint (I swear some data sheet designers must be being maliciously compliant with providing all the necessary information in the least informative way…). The plug-in is also ridiculously easy to use, once installed: type the part-name, get it added to a library

Aside: The name@pin-index format is doubly useful. Eagle doesn’t render the @ or anything after it, so you just see the signal name, and the @pin shows up in the device creation step, making it trivial to get the pads guaranteed to be right. Just connect pin1 to @1 etc. if you make a wrong click (pin X connected to pad Y, say) without noticing it, you’ll find out when there’s no match for the corresponding pin Y a little later. You have to make two screw-ups instead of one to end up with an invalid device, which is far and away less likely. Once I started using this, I never did anything else.