High Speed USB 2.0 (Target) + CPU + 2GByte RAM - suitable processor?

The processor has a fairly simple life.

Mode 1) We want to take data in quickly over USB at about 1 Mbyte/sec to the CPU, decompress it by a factor fo about 4, and save it. The buffer can be >1GByte Mode 2) We take data out of memory and send it to a custom interface at around 6 MBytes/second. I would expect the processor to be able to mediate these transfers.

Using things we've used before, I could stick a Cypress FX2LP in, and use the GPIF interface for the bulk end point transfers via a modest FIFO to the CPU. However, that leaves me with finding a clean way of handling the End Point 0 transfers. Some would be handled by the Cypress itself (those concerned with programming the Cypress, or operating USB), but others need to go to the CPU and processor/processor interfaces can be awkward (Cypress is an I2C Master).

When I started looking at ARM with >1GByte memory access, they tend to come with everything else (Ethernet, CAN, compost heap, coffee maker, etc).

Have I missed something in the confusion?

TIA, Bill

Reply to
Bill Davy
Loading thread data ...

Compost heap and coffee maker are obviously for Java support.

SCNR, Scott

Reply to
Not Really Me

Op Thu, 15 Mar 2007 12:50:38 +0100 schreef Bill Davy :

What's wrong with good old bank switching? Surely you don't need all this memory simultanously.

--
Gemaakt met Opera's revolutionaire e-mailprogramma:  
http://www.opera.com/mail/
Reply to
Boudewijn Dijkstra

Bank switching? How quaint. Gosh, I could even dig out an old 8088 and use segments. Do you know, back in the bad old days, before the IBM/PC, I suggested to readers of PCW that they paid attention to the 8088.

And I had mistakenly thought the 68000 was progress. How wrong I was.

What a difference 35 years makes.

Of course I could use bank switching. I could interface to memory over a one bit serial line.

Sorry, but I did not find that contribution very helpful, but am grateful nonetheless.

Bill

Reply to
Bill Davy

This sounds like a good application for an FPGA; implement an SDRAM controller and the USB interface and everything else in one chip.

Reply to
larwe

Because you are asking too much for a small device. You want 1MB xfer and 1G mem, which would not be small or cheap anyway. Why bother dealing with a host processor at all? Just process the data with xfer with Ethernet.

Reply to
linnix

Not sure if the ARM comment means you don't want to use one - the NXP LC2888 is something I've looked at (but not used). Has USB 2.0 High Speed and 1MB flash and the usual peripherals. It's not one of the big PDA type processors, though, still fairly simple about $13 (qty 1) at DigiKey.

formatting link

Andrew

Reply to
andrew queisser

I had a project with somewhat similar performance requirement about a year ago. I also looked at ARM's, but ended up using a Analog Blackfin BF-533 @ 600 MHz + external USB 2.0 high speed controller. Today, the BF-52x series has builtin HS USB. See:

formatting link

Leo Havmøller.

Reply to
Leo Havmøller

That sounds like you have either failed to explain your original problem, or you don't understand bank switching, or you don't understand embedded systems design.

Bank switching is alive and well in modern designs. It's even alive and well in modern pc's - you get bank switching inside DRAM, and 32-bit machines with more than 3 GB ram use bank switching. Just because you don't see it, does not mean it is not there - it is hidden by the DRAM controller, the MMU, and the operating system.

Bank switching is an inconvenience if your program needs to be aware of it for normal program access or data access. But your system will need a program of perhaps a few tens of K in length at most, plus a very large buffer memory. It does not matter if you need bank switching on the buffer. It does not matter if it is ram, dram, flash, or whatever, as long as it can sustain the speeds you need (which are not particularly high).

And ironically your best bet might well be a one bit serial line - an SD interface to a flash card.

Reply to
David Brown

Op Thu, 15 Mar 2007 16:58:45 +0100 schreef Bill Davy :

Part of finding the solution is opening your mind to possible solutions.

Reply to
Boudewijn Dijkstra

Hi Andrew,

Many thanks for thjis. I do wonder if I am missing something, but the memory map does not seem to have a 1GByte (let alone 2GByte) contiguous space. Presumably I do not have to implement the Static Memory Banks if I don't want to, but there seems to be Reserved Chunks taken out as well.

As I do (or will probably) have to access the large buffer, it really would help if it was contiguous.

TIA, Bill

Reply to
Bill Davy

Hi Leo, Looking at the BF-52x External Memory map, it appears to support SDRAM up to

512MByte, although I do not quite understand:

"The PC133-compliant SDRAM controller can be programmed to interface to up to 512M bytes of SDRAM. A separate row can be open for each SDRAM internal bank and the SDRAM controller supports up to 4 internal SDRAM banks, improving overall performance."

BF-54x fars no better.

Or have I missed something?

Bill

Reply to
Bill Davy

Since your large memory block is nothing but a FIFO buffer, it is totally irrelevant if it is contiguous or not, just as it is irrelevant what type of memory you are using. Once you realise this and stop worrying about it, you'll find your project much, much easier. You'll be able to base it around familiar technology (be it FPGA, ARM, or whatever).

Reply to
David Brown

Is it? I think it probably is not.

There may be a small FIFO from USB into the processor (whatever comes in a single pack), but after that, it is a bitmap and some manipulation may be necessary, and manipulating a gigabyte bit map is time consuming enough without having paging (by which I do not mean automatic cache operations) going on.

If the USB uses DMA straight into memory instead of messing about with an external FIFO, so much the better.

I'm always and all in favour of simple solutions, but they need to work now, and in the future.

So, an embedded processor with a 1 or 2 gigabyte external address space, please. If there are none, I will have to look at other architectures, but this thread is addressing this architecture.

TIA,

Bill

Reply to
Bill Davy

OK, Actel M7 Fusion.

32 bits address bus 32 bits data bit. Dual port SDRAM. Arm 7 instructions. Jtag programming. USB 2.0
Reply to
linnix

The only information we had on your use of the memory was as a simple buffer - look back at your original post. Thus you get answers based on the information. If you'd said earlier that you needed random access, and answered Boudewijn's question "What's wrong with good old bank switching?" instead of insulting him, then we could have avoided this time wasting.

There is no problem using DMA and switched banks - you just run in blocks. You could even use DMA along with flash (which is the easiest and cheapest way to get 2 GB storage, if it is fast enough - it's not too suitable for random manipulation of the data, however).

It's a balancing act.

The ColdFire MCF547x devices have support for 1 GB DDR ram, along with USB high speed, Ethernet, DMA, and plenty of processing power.

Other than that, I'd go for an FPGA - you could fit DDR / DDR2 support, soft-processor, USB, and DMA into a Cyclone II using standard peripherals. You don't even need to understand programmable logic language - Altera's software lets you put the bits together on an internal bus, and generates all the interconnections automatically.

Reply to
David Brown

I'm sorry if you feel I insulted Boudewijn, though I accept I derided his suggestion.

ColdFire MCF547x does indeed come close to my goal (2GByte) but does not quite reach it, but thank you for pointing that range out. It's a nice processor though.

It would appear that there are no embedded processors at present with a straightforward 2 GByte address space.

Many thanks to all who have contributed,

Bill

PS Amongst the many constraints I did not mention was that the product needs a lifetime of 15 years, and has to be proven by a show in spring 2008. Lokks like trickery is going to be involved.

Reply to
Bill Davy

I'm a fan of the ColdFire, although I've only used the v2 cores - the v4 cores are bigger than I've needed so far.

It is not common to have such a large data set requirement on an embedded system without it being an embedded PC. With 32-bit processors, you only have 4 GB address space (baring hacks or banking) - by the time you've reserved some of that for a slow bus (for booting, or external peripherals), internal peripherals, PCI address space, and so on, then it is not uncommon simply not to have a 2 GB contiguous address area.

If I were to guess an architecture that might be better, I'd look at MIPS. They are popular for high-end network devices, and you might find some that have direct support for such large address spaces. You'll also find 64-bit MIPS cores, which may be a better choice.

Good luck!

mvh.,

David

Reply to
David Brown

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.