SiP Integration Requests

[Greg Sheridan]

Use this thread to tell us what you would like us to integrate into our next SiP.  This can be new features or devices into our current line up or a completely new family of devices.

Let us know what would make your lives easier!

[Mike]

We have some long-term products which base on AM3358 / BeagleBone Black and would prefer to stay on this hardware-platform and board format.

So to further-develop these products it would be great to have a fully AM335x-compatible SiP like the OSD335x (which easily could be used for a further-developed BeagleBone) but – in order of our priority – in future perhaps with:

1. higher system clock (1GHz is meanwhile not so fancy and the lower end for compareable embedded devices)
2. higher PRU clock
3. larger L1 and L2 cache
4. two or more 16 bit analogue outputs
5. additional PRUs

Regards

Mike

 

[Greg Sheridan]

Hi Mike,

Thanks for the input.  It sounds like you are looking for a different SoC.  We don’t design SoC’s but are looking for SoCs to integrate into our products.  Would an AM43x device or an AM57x device meet your requirements?

[Mike]

It sounds like you are looking for a different SoC

No, not necessarily. I also would be happy with exactly the same hardware and with my suggestion from point 1.

 

[Greg Sheridan]

Ok thanks for the feedback.  Those kind of changes are a bit out of our scope as they require new silicon.  We will pass that info along to TI and see if they have any plans to create something like what you are asking for.

 

Thanks,

Greg

[gauravs]

Adding an FPGA core would provide more versatility and power for handling more computationally intensive tasks. Of course, that leads to the question of how do you handle core-to-core communication.

[Michael]

I’m happy with the current peripherals of the AM3358/SIP3358. But how about some additional CPU cores that can work in parallel?

[Greg Sheridan]

Thanks Michael,
We are looking at a couple of things that would be similar to the AM335x peripheral set but with more/different cores. Stay tuned.

-Greg

[avikde]

Are there any plans to make an AM57x version?

[avikde]

Are there any plans to make an AM57x version? In addition, do you think is it feasible to have some degree of pin compatibility in the SiP packages between the OSD335x-SM and OSD57x-SM (hypothetical)?

[Greg Sheridan]

Hi Avikde,

Thanks for your question.  The AM57 is something we are actively exploring.  What are the features of the AM57 you would like to take advantage of?  How would you plan on using it?

Unfortunately given the increased power and number of IOs on the AM57, the chances of being able to create a version compatible with the OSD335x-SM is very small.  We would look to take the same approach when designing the pin map however.

Thanks,

Greg

[avikde]

Thanks for the quick response. The features in the AM57 that are appealing are

• integrated DSPs (for matrix math and other robotics algorithms)
• 5x the DMIPS of the AM335 in order to be able to run more complicated algorithms

Makes sense about non-compatibility with the 335 SiP.

When you say “actively exploring” is there any roadmap? I’m asking since it could affect my company’s roadmap. Is there a different channel of communication that would be better (happy to have NDA’s etc.)

—

Avik De
Ghost Robotics CTO

http://www.ghostrobotics.io  | Twitter

[Greg Sheridan]

I will have one of our Business Development Managers reach out to you.

Thanks,

Greg

[kiwisdr]

Greg,

If you guys want to set the world on fire you should consider a SiP using the low-end Xilinx Zynq 7z007s FPGA / Cortex-A9 SoC. Although this part is fairly new it seems to be available in decent retail quantities and I’d bet you’d have no problems getting dice from Xilinx. And probably full backing from Xilinx marketing as well. It would be a huge win for them in their eternal battle against Altera/Intel (translation: easier for you to negotiate better than the $46 retail price).

Now this is obviously a huge departure from what you’ve been doing. But the philosophy remains the same. The worst problems for us as FPGA/SoC developers are the routing of the DDRx memory interface and the multi-voltage requirement pushing us into 6-layer (or more) PCBs. If you put a 512 MB DDR3L and one of the many FPGA-specific PMICs in the SiP that would be enough (same as you do now). It’s easy these days to deal with external USB, Ethernet PHY, SDIO etc as you are well aware.

There are lots of challenges of course. The die size will determine the difficulty. The 7z007s already has limited I/O pins for the SoC peripherals and you wouldn’t want to make that situation any worse. I’d trade a larger SiP package to get all the I/Os. Your packaging will effect the high-end performance of the FPGA I/Os. But for a low-end device most people aren’t so worried about that I would think. For example my application is limited to about 70 MHz.

• This reply was modified 6 years, 2 months ago by kiwisdr.

[Greg Sheridan]

HI KiwiSDR,
Thanks for the feedback. This is something we have been looking into. The question with FPGA’s is what do we actually design to. They are so flexible with so many use cases we have had problems scoping something that met the needs of most of the market without being overkill. Any help you can provide on your application and actual requirements would be very helpful.

If you don’t want to share them here feel free to send us a note through the contact form.

Thanks,
Greg

[kiwisdr]

Thanks Greg. I’ll be sending a contact form reply soon. Need to do a little more research first.

[andyolivares]

I also see some potential on lower-end MPUs also. Even though having a good Cortex-A processor at 1 GHz speeds is very nice, I see some other markets where that is just unneeded/overkill, and a simpler MPU at lower speeds, could solve many problems and be more cost effective. OSD335x-SM at current price tag is somewhat prohibitive for some projects that would greatly benefit from an MCU with Linux.

For example, take the AT91SAM9G25 (ARM926 at 400 MHz) for example; it would be nice to have a SiP with integrated RAM, power management and above all, a friendly pin distribution and spacing for accesible 4-Layer PCBs like the current offering. Atmel MPUs (now Microchip’s) have also an active community and good Linux support AFAIK.

Maybe you can consider a lower-end & lower-cost option, specially for those making the transition from an MCU to an MPU for industrial and IoT applications.

My two cents 🙂

[Greg Sheridan]

HI Andy,
Thank you for the feedback. This is an idea we have kicked around and are looking into. Is there anything special you like about the AT91SAM9G25? Are there any other processors in this class that would be interesting for you?

[andyolivares]

There’s nothing particularly special about that MPU except its price. My humble opinion is that a cost effective SiP for (power-)constrained IoT applications could contain:

– CPU @ 400 Mhz or more (with good Linux support)
– RAM (256 MB seems acceptable)
– microSD interface
– Ethernet interface
– 2+ x SPI
– 1+ x I2C
– 1+ x I2S or similar
– 1 x USB device
– 1 x USB host
– Some GPIOs
– (Optional) Flash memory (4GB+)
– (Optional) LCD interface & touch controller

That’s on top of my mind for now.

I’ve been looking for other possible MPU options on that leagle and NXP i.MX28 (ARM926) series looks like a good candidate. Also, NXP has low-cost Cortex-A options like the i.MX 6ULZ or 6ULL series. Although, I don’t know about NXP’s Linux support and community.

I assume you’re aware that Microchip has their own SiP offering based on their ATSAMA5D27 Cortex-A5 MPU (ATSAMA5D27C-D1G-CU) at about ~$15 @ 100pcs, but its 0.8mm ball spacing and pin layout is still hard for cost-effective PCB design.

A price around $20 @ 100pcs seems reasonable to me, but of course that’s just my wish 🙂

[MichM]

> – CPU @ 400 Mhz or more (with good Linux support)
> – RAM (256 MB seems acceptable)
> – microSD interface
> – Ethernet interface
> – 2+ x SPI
> – 1+ x I2C
> – 1+ x I2S or similar
> – 1 x USB device
> – 1 x USB host
> – Some GPIOs

this is something where i also could imagine some very nice applications – when it would provide a lot GPIOs instead only some 😉

[Greg Sheridan]

Thanks for the detailed info. Like I mentioned this is something we are looking into. We will let you know if we have something that might fit with what you are looking for.

Thanks,
Greg

[MichM]

i found this thread too late, so please delete any double posts.

what i’m would be interested in is more computing power while staying (somewhat) compatible with the AM335x, means more main CPU cores and/or higher clock and/or more PRU-cores.

my application is bare metal/embedded where computing power is the bottleneck, RAM is more then enough available at the moment (but would not matter when it is more than on the BBB)

[Greg Sheridan]

Hi MichM,
No problem. I will clean up the other post. Would a AM57x work for your application? If so which version 1, 2, or 4?

Thanks,
Greg

[MichM]

> Would a AM57x work for your application? If so which version 1, 2, or 4?

not sure, i’m not familar with it. we currently have a plain bare metal application, so no linux or something like that involved. is there a starterware-like board support package available for this SoC?

[Greg Sheridan]

The AM57x is a little more complicated. Multicore A15s and a couple of DSPs. Has 4 PRUs. http://www.ti.com/processors/sitara/arm-cortex-a15/am57x/overview.html

I am not familiar with anybody running starterware on it but it be possible.

[cospan]

If you do an AM57X SIP I would like a USB-C interface. Something like the TI:TPS65981 chip with USB 3.0 and DisplayPort. This would be nice because the designer would only need to add one port to the board and they can both power the board and have an entire desktop environment using a decent USB-C hub (USB Host ports, USB Ethernet, HDMI Output). USB-C supports dual role mode so you can still boot the board over USB. If you allow the user to modify the EEPROM of the USB chip you can request up to 20V.

[Greg Sheridan]

Interesting Idea. Thanks for the input. I will add it to the list.

[emh203]

Are TI based SOC’s a constraint? I would love to see something from the NXP i.MX series. (i.e. the new i.MX8 with Cortex A53’s and A72’s).
The new i.MX8 devices use LPDDR4 which is challenging to route. A SIP would be a very nice product! A Multicore SOC built on a smaller geometry process for power efficiency would be a helpful. The current TI parts seem to run quite hot at idle.

Having a part with an easily accessibly datasheet for the SoC (which pretty much limits you to TI and NXP these days) is a big deal for me. I avoid anything “Rasberri Pi” like as it is impossible to dig into any details unless you have lawyers to deal with Broadcomm directly.

[Greg Sheridan]

Hi emh203,

We are not restricted to TI and I appreciate your input.  I have not looked at these NXP devices yet.  Besides the cores is there anything that stands out to you as a differentiator?  Any special peripherals that are must haves?

 

Thanks,
Greg

[avikde]

NXP is starting up their own version of this https://www.nxp.com/products/single-chip-modules:SINGLE-CHIP-MODULE

[Greg Sheridan]

Yes those were announced by Freescale before they were acquired by NXP.  I still haven’t seen them in the wild.  Have you?

[emh203]

@avikde:

These modules were never generally available and are EOL. I have some internal knowledge of the history and you will never seem them through general distribution in low quantities like the Octavo product. They are only being offered to teir 1 customers. Also, the BGA package is *very* difficult with the POP RAM. It is a .65mm BGA and much more difficult than the current octavo offerings. Once you go down that road you might as well use the raw chips.

@Greg:

The i.MX integrates standard cortex MCU microcontroller cores along side the application processors. It is a bit easier to do development vs the PRU’s as there is a lot more cortex M support in the wild.

The new Quad Max devices support hardware virtualization. I was at a training event where a couple VM’s were created with the internal cores/peripherals partitioned in hardware. It is an advanced use case but it is possible to boot android for a GUI and Linux for a processing backend on a single chip. Also, some of the device support instant on video for applications that require cameras to come on with graphics before linux is booted.

This is certainly on the high end but the i.MX is a good family for automotive and robotics.

I would be happy with a TI part inside built on a smaller process node for the power efficiency and to get a bit more horsepower. The other key feature to keep is the easy BGA layout!

[andyolivares]

Easy BGA layout is definitely one of the best features of current Octavo System’s offering. Where I live, it is very difficult to find high-end PCB houses and using Octavo System products has enabled us to make some products that we didn’t have any chance to do a couple of years ago.

Relaxed BGA ball spacing and optimized ball layout allow people like me (with no experience in high speed layouts) to tackle projects I didn’t think of.

So keep the easy BGA routing… it’s definitely a must! 🙂

[Greg Sheridan]

Thank you both for the feedback.  We are glad the BGA placement has been a benefit to you.  That was definitely one of our main goals when creating these devices.

Please keep sharing your thoughts.  We do take your feedback into consideration when developing our road map.

[lajash]

Hi Greg,

Just as a follow up to Avik’s question – are there any plans to have a AM57X C-SIP ? We would be very interested in this. Thanks

[Greg Sheridan]

Hi lajash,

Yes the AM57x is something we are strongly looking at.  We are trying to narrow down what the correct configuration would be for a SiP.  Should we build it around the AM570, 1, 4, or 8.  How much DDR memory is required, what peripherals are required.

Can you give us any insights into your application and how you would be using the AM57?  What are your system requirements?

If you don’t feel comfortable discussing on the forum please contact us directly.

 

Thanks,

Greg

[Beko]

Hi Octavo Team,

Thanks for the good-work so far. The OSD32MP15x has been a great addition to your product portfolio. Most embedded developers need a SIP that can run Linux but can also do some “real-time” stuff. However, we do not really need the dual-core STM, a low-cost single core version would suffice most not-so-high-end applications. Thus a single core variation of the OSD32MP15x with STM32MP151C, eMMC (1 or 2GB would suffice most) and oscillator could be your best-seller with the right price tag.

[Author]

Posts