We’ve been writing a fair amount of posts about SigmaStar SSD201/SSD202D processors for smart displays in recent times. But the company also has various camera SoC’s with SSC333, SSC335, SSC336, SSC337, SS338, and SSC339 parts.
Those processors feature one or two Cortex-A7 core, embedded RAM, as well as an optional AI accelerator called DLA (Deep Learning Accelerator). The chips manufactured using a 28nm or 22nm process, with the latter being used for parts with the AI accelerator. Most of the Sigmastar SCC33x processors also happen to be pin-to-pin compatible with HiSilicon Hi3516 or Hi3518 SoC that are found in a wide range of IP cameras.
Let’s take SSC336D/SSC336Q processor as an example since it comes with the AI accelerator and we have a datasheet courtesy of linux-chenxing.com.
SigmaStar SSC336D/SSC336Q camera SoC key features & specifications:
- CPU – Dual-core Arm Cortex-A7 processor @ 1 GHz with Neon and FPU
- Embedded Memory – Embedded 1Gbit (128MB) or 2Gb (256MB) 16-bit DDR3 memory up to 2133Mbps
- NOR/NAND Flash Interface
- SD Card/eMMC Interface
- SDIO 2.0 Interface
- Camera support
- 8/10/12-bit parallel interface for raw data input
- MIPI interface with 2/4 data lanes and 1 clock lane
- Max. 3M (2304×1296) pixels video recording and image snapshot
- High Dynamic Range (HDR) support
- Wide Dynamic Range (WDR) support with local tone mapping
- Advanced Color Engine
- Video Encoders
- H.265/HEVC & H.264 up to 3M + HD + D1 30fps
- MJPEG up to 3M 30 fps
- Deep Learning Accelerator – 0.5 TOPS Hardwired accelerator with support for various video analysis functions like FD/FR, human detection, MD/OD, object tracking, etc.
- 1x stereo ADC for microphone input
- 2x stereo DMIC inputs
- 1x stereo DAC for lineout
- 8K/16K/32KHz/48KHz sampling rate audio recording
- I2S digital audio input and output with TDM up to 8-ch input and 2-ch output
- Networking – 10/100M MAC and PHY
- USB – 1x USB 2.0 host or device
- Other I/Os & peripherals
- GPIOs, up to 11x PWM outputs
- 3x generic UART, 1x fast UART with flow control
- 2x SPI masters, 3x I2C masters
- 4-channel SAR ADC
- 3x generic timers, 1x watchdog timer
- Security – AES/DES/3DES/RSA/SHA-I/SHA-256, secure booting
- Misc – Real-Time Clock (RTC), internal temperature sensor
- Operating Voltage
- Core: 0.9V
- I/O: 1.8 ~ 3.3V
- DRAM: 1.5V (DDR3) or 1.35V (DDR3L)
- Package – QFN with 128 pins, 12.3mm x 12.3mm
BR16.com has a comparison table of the different SSC (SigmaStar Camera) chips which we’ve translated into English.
|Processor||Cores||Embedded Memory||Camera||AI Accelerator||Process||Compatible Hisilicon SoC|
|SSC333||Cortex-A7||512 Mbit||1080p30, 3MP @ 20 fps||No||28nm||Hi3518EV300|
|SSC335||Cortex-A7||512 Mbit||3MP @ 30 fps||No||28nm||Hi3518EV200|
|SSC333D||Cortex-A7||1 Gbit||1080p30, 3MP @ 20 fps||No||28nm|
|SSC335D||Cortex-A7||1 Gbit||3MP @ 30 fps||No||28nm|
|SSC337D||Cortex-A7||1 Gbit||1080p60, 5MP @ 20 fps||No||28nm||Hi3516EV300|
|SSC336D||2x Cortex-A7||1 Gbit||3MP @ 30 fps||0.5 TOPS||22nm||Hi3516CV500|
|SSC336Q||2x Cortex-A7||2 Gbit||3MP @ 30 fps||0.5 TOPS||22nm||Hi3516CV500|
|SSC338Q||2x Cortex-A7 (TBC)||2 Gbit||4K @ 20 fps||0.5 TOPS||22nm||Hi3516DV300|
|SSC338G||2x Cortex-A7 (TBC)||No||4K @ 20 fps||1 TOPS||22nm||Hi3516DV300|
|SSC339G||2x Cortex-A7 (TBC)||No||4K @ 30 fps||1 TOPS||22nm|
There’s very limited public information about the chips, at least in English. The Linux SDK and DLA SDK can be acquired from SigmaStar after signing an NDA. BR16 lists some SSC33x modules and expensive development boards, but SigmaStar SS336D/SSD336Q camera SoC itself can also be purchased on Taobao for 49.5 RMB (about $7.6 US), while an SSC338Q module is offered for 108 RMB (~$17.6 US).
Thanks to dgp for the tip.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
10 Replies to “SigmaStar SSC33x Camera SoCs are pin-to-pin compatible with Hisilicon Hi3516/Hi3518 processors”
“…which we’ve translated into Chinese.”
@cnx-software I guess you’ve translated those FROM chinease
For anyone that’s interested: The DLA (NPU I guess..) seems to be from cambricon. The kernel configs have an option to enable the “DLA” which in turn adds an empty directory called cambricon to the kernel build. I think you’re meant to be given something to put in there and that’ll give you access to the DLA..
Seems like a GPL violation to me.
Don’t you understand how this works? The companies want to keep this technology secret. So the best way to do that is not let their customers have the info. It follows that if you have no customers then you have perfect security for your secrets.
I have learned long ago, I am wasting MY time if I am working on something the vendor wants to keep highly secret. It is a total waste of time working on something where you have to beg for every little scrap of information. So I have a solution — you keep your secret and don’t tell it to me, I won’t waste my time working on your secret chips.
This is the entire philosophy behind DRM. Make your product so hard to use with encryption and special tools and special software that no one can use it. Then you can rest assured no one will steal it.
Meanwhile I will go back to working on my nice Rockchip NPU with docs and code here…
How does the Amlogic NPU in some SoC fare Jon ?
I have not tried it.
>Don’t you understand how this works?
>The companies want to keep this technology secret.
I’m perfectly aware of this. I’m not sure why you think you need to educate me on this. I was simply stating that it might be a cambricon design in there. Maybe someone already knows how that hardware works and we can get open tools working with it. A hand solderable Linux system that just needs power rails and has an NPU is pretty interesting to hobbyist IMHO.
>So the best way to do that is not let their customers have the info.
A few things:
– I’m not their customer. With nothing but the kernel binary and dtb from a camera module it was possible to get Linux working to the point you could have a shell in days. I did it for the fun of it. You might have business requirements etc but I don’t. If I wasn’t doing this for fun I would play it safe and use an NXP or similar part. But NXP don’t make an almost 2GHz capable dual core SoC that is only slightly more difficult than a Cortex M4 to homebrew a board for..
– They left the driver for the CEVA shim in their kernel code, they also leaked the upstream vendor driver for their H265 hardware. They don’t seem to be very good at actually hiding stuff.
>I have learned long ago, I am wasting MY time if
>I am working on something the vendor wants to keep highly secret.
That’s fine for you. These guys aren’t my vendor.
Working out how their stuff works in spite of them being stinky old kernel shipping, GPL violating bandits that don’t have proper datasheets is good fun.
>It is a total waste of time working on something where
>you have to beg for every little scrap of information.
If you are working towards a product you can sell maybe. If you are having fun scraping together info, dumping out registers and putting together crappy drivers it’s really invigorating when it all comes together. Something like this thread: https://lore.kernel.org/netdev/CAFr9PX=Ky2QuXNH09DmegFV=e-4+ChdypSsJfV8svqxP7Ufirstname.lastname@example.org/. Ethernet performance was total garbage. A few hours of experimenting later it’s now very good.
FYI a script that periodically uses github’s code search API with some strings you know are in blobs you want look inside of will often, eventually, find what you are looking for.
>So I have a solution — you keep your secret and don’t tell it to me,
>I won’t waste my time working on your secret chips.
Ok, great for you. I’ll keep buying junk from taobao and putting Linux on it.
>Make your product so hard to use with encryption
>and special tools and special software that no one can use it.
FWIW I think chips in this family are already in a few highend dash cameras that are sold outside of China. So someone is using them.
>Meanwhile I will go back to working on my nice Rockchip
>NPU with docs and code here…
Great. Don’t rockchip still have binary blobs for the DDR init? And you need a special blob for your exact DDR chip, the uart you want to use for the debug uart etc.. and unless you have the secret source code to rebuild those binaries you better never change your DDR chip. So you are in the exact same situation when push comes to shove.
Anyhow my TL;DR; is this:
Silicon vendors suck at software. We don’t want their software. We want them to make cost effective chips and document how they should be programmed. The reason they don’t do that is because they have to make software part of the package otherwise they’d actually have to come up with competitive products.
It was not meant as a serious comment, I am simply making fun of the vendors for their excessive secrecy.
Still wondering if it’s excessive secrecy or just blatant incompetence…
It’s secrecy resulting from incompetence.
SigmaStar SSC337DE is used in Foscam SPC camera