SigmaStar SSC33x Camera SoCs are pin-to-pin compatible with Hisilicon Hi3516/Hi3518 processors

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.

Sigmastar ssc336d ssc336q processor
SSC336D/SSC336Q Block Diagram

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
  • Storage
    • 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.
  • Audio
    • 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
SSC336 module
SigmaStar SSC336D/Q module

BR16.com has a comparison table of the different SSC (SigmaStar Camera) chips which we’ve translated into English.

ProcessorCoresEmbedded MemoryCameraAI AcceleratorProcess Compatible Hisilicon SoC
SSC333Cortex-A7512 Mbit1080p30, 3MP @ 20 fpsNo28nmHi3518EV300
SSC335Cortex-A7512 Mbit3MP @ 30 fpsNo28nmHi3518EV200
SSC333DCortex-A71 Gbit1080p30, 3MP @ 20 fpsNo28nm
SSC335DCortex-A71 Gbit3MP @ 30 fpsNo28nm
SSC337DCortex-A71 Gbit1080p60, 5MP @ 20 fpsNo28nmHi3516EV300
SSC336D2x Cortex-A71 Gbit3MP @ 30 fps0.5 TOPS22nmHi3516CV500
SSC336Q2x Cortex-A72 Gbit3MP @ 30 fps0.5 TOPS22nmHi3516CV500
SSC338Q2x Cortex-A7 (TBC)2 Gbit4K @ 20 fps0.5 TOPS22nmHi3516DV300
SSC338G2x Cortex-A7 (TBC)No4K @ 20 fps1 TOPS22nmHi3516DV300
SSC339G2x Cortex-A7 (TBC)No4K @ 30 fps1 TOPS22nm

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).

SSC336Q development kit
SSC336Q development board

Thanks to dgp for the tip.

Share this:
FacebookTwitterHacker NewsSlashdotRedditLinkedInPinterestFlipboardMeWeLineEmailShare

Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress

ROCK Pi 4C Plus

10 Replies to “SigmaStar SSC33x Camera SoCs are pin-to-pin compatible with Hisilicon Hi3516/Hi3518 processors”

  1. “…which we’ve translated into Chinese.”
    @cnx-software I guess you’ve translated those FROM chinease

  2. 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.

    1. 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…
      https://github.com/rockchip-linux/rknn-toolkit

      1. >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+ChdypSsJfV8svqxP7U-cpg@mail.gmail.com/. 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…
        >https://github.com/rockchip-linux/rknn-toolkit

        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.

        1. It was not meant as a serious comment, I am simply making fun of the vendors for their excessive secrecy.

          1. Still wondering if it’s excessive secrecy or just blatant incompetence…

Leave a Reply

Your email address will not be published. Required fields are marked *

Khadas VIM4 SBC
Khadas VIM4 SBC