How to replace Triscend - Xilinx plans for the future

Two months after Xilinx acquired Triscend, it now seems they are planning to kill the Triscend products. We recently got the End-of-life notification for the A7 processor, and I guess the E5 is also going.

Can anybody guess what their plans might be? What is the point of buying a company and dropping the products? Except for the purpose of getting irritated customers who will get enourmous redesign work using some other processor.

I can't imagine that Triscend was a very big threat to the Microblaze market, to warrant shutting it down just to kill the competition.

Does anybody know of a replacement for the Triscend A7 processor? We are using it together with a Xilinx FPGA (at least until now...) and have implemented a FIFO in the CSL to move data at high speed from the FPGA to external SDRAM (Up to 128 Mbits/second in packets of 8 32-bit words). This link seems to be difficult to implement using a "standard" ARM7 processor.

Any suggestions and views are appreciated.

/Anders

Reply to
Anders
Loading thread data ...

I did some design on Triscend A7. Very powerfull system, with their FAStchip software.

Maybe, Xilinx wants to play in the TRUE Embedded world ! Merging Triscend software/hardware know-how with Coolrunner II techno, you move to a true SoC platform for Embedded porducts -> high speed and low power !

Buying Triscend, Xilinx may enter in the Embedded market very quickly.

Laurent

formatting link

Reply to
Amontec, Larry

I think Triscend was much less a threat to the MicroBlaze, than ARM offering a licensable ARM+FPGA flow, was to the FPGA market.

This is also topical, from Altera :

formatting link
?articleID=20301002

" It now says it won't come out with a successor to its Excalibur line, which includes a hardwired ARM processor core. Excalibur is based on the company's older Apex FPGA architecture. The company said it prefers the flexibility of soft processor cores, which can handle more tasks at various points in the FPGA fabric. "We learned that putting in a hard core is tricky," Plofsky said.

My reading was always that these 'System on Chip' offerings were more marketing and ego driven, than sound engineering decisions. "jack of all trades, master of none" is what you get, and they struggle to hit critical mass, so the big hurdle is not the first device, but getting to the 'next iteration'. [Atmel FPslic anyone ? ]

So, you are left looking at Standard ARM offerings, and FPGA, or maybe NIOS II (etc).

What you should do depends on your CPU/FPGA/Memory relative loadings.

There are a LOT of Arm cores comming as MCU, with on chip FLASH, and that solves the smaller-memory end, by removing the memory BUS layout problems.

Look at Philips LPC2xxx, STm STR7xxx, Analog Devices ADuC7xxx, TIs TMS470, Sony, etc for FLASH+ARM offerings, many with external memory interfaces. Then, there are the ARM MPUs (external code memory), with Atmel AT91RM9200, up to Intel's XScale families.

What WOULD make sense, is a highspeed serial interface layer, on these ARM MCUs, so they can interface with FPGAs with reduced pin count :) - The SSC/i2s could approach that.

Following that idea, a peek at Atmel's 9200, gives the MII interface at 100Mbaud, or the devices triple SSC/i2s channels as LPC-FPGA candiates. SSC specs as

Reply to
Jim Granville

I am surprised that Xilinx is ending the A7 line. I expected that they were buying Triscend to get an ARM license and technology to compete more directly with the Altera ARM/FPGA chips. I agree that it makes no sense unless they are going to produce a new device with the ARM7/9 combined with one of their own FPGAs like the V2Pro. But I am sure they know better how to approach this market than I do. :)

--
Rick "rickman" Collins

rick.collins@XYarius.com
 Click to see the full signature
Reply to
rickman

.. I should have included Motorola's MAC7100 ARM devices, TQFP144,

512KF, 32KR, Automotive specs..

-jg

Reply to
Jim Granville

Wow! This is a part I have been looking for for quite sometime. I don't see any info on pricing or availability... any idea? I have sent an email to Arrow, we'll see what they say.

It does not look like this part will interface directly to SDRAM... too bad, that is the only lacking feature for my app, but I can live without it.

--
Rick "rickman" Collins

rick.collins@XYarius.com
 Click to see the full signature
Reply to
rickman

"Anders" skrev i meddelandet news: snipped-for-privacy@localhost.talkaboutelectronicequipment.com...

If you use a controller like the AT91R40008 with 256 kB internal SRAM and implement the SDRAM controller in the FPGA it is a piece of cake. CPU runs at 60 MIPS, no sweat when executing out of internal SRAM. You can make a lot of transfers per microsecond... Use the FIQ interrupt into the ARM7 to get maximum throughput.

The FPGA can implement its own DMA controller. Alternatively the ARM7 can do a move multiple from internal SRAM to the DRAM at a "high" address, using a special chip select signal When the FPGA sees this chipselect active, it can ignore data coming in over the CPU bus and take it from a FIFO in the FPGA. 128 Mbit / second is 8 x 16 words so you need to do 8 x 16 bit transfers per microsecond.

If you dont want to worry about SDRAM controllers, use PseudoRAM (DRAM with an SRAM interface). Maybe implement a page mode feature in the FPGA.

Hopes this helps Since you seem to be based in Sweden, you can contact me directly. If you have any decent volume, we have better solutions.

--
Best Regards,
Ulf Samuelsson   ulf@a-t-m-e-l.com
 Click to see the full signature
Reply to
Ulf Samuelsson

Nope, but when I saw 5V and Automotive I did think of you :) The date tags on the info gives some idea - looks 'real' to me.

I'd guess it's like the TMS470, targeted to the Automotive sector in the truest sense of the term. (ie helps if you're called Ford, GM, BMW.. ) - but I'm sure both TI and Motorola are seeing customers in the 'tough industrial' sectors who would like these devices too..

-jg

Reply to
Jim Granville

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.