fpga memory issues

All the current Xilinx parts have both distributed and block memory, lots of it. Some of the Spartan parts are, like, $5, and plenty fast for what you want to do.

John

What lines of VHDL tell it to use RAM?

Tim

I don't know; I don't drive the FPGA software myself. I think that, for device-specific hard blocks, like RAM or PLLs or dram controllers, you name them and adhere to their interface definition. The actual things are often encrypted IP blocks you import and can't see inside of.

Something like that. Ask in the FPGA group.

The Xilinx block rams are very flexible and very fast. We make a couple of 8-channel ARBs that use only block ram to store waveforms.

John

I'm considering the ProASIC3 for a project, as well. To answer your question, you need to go to the 060 to get memory. AFAICT, there is no memory in a ProASIC3, other than registers. Since the LUT configuration isn't SRAM, rather flash, it's not available for distributed RAM. It's a severe limitation of the small Actel stuff.

That said, I'm either going to use the Actel A3PN030 or an Altera EPM570. I'm in the process of writing the VHDL and will target it for both. The Altera has a better package selection and is cheaper overall, though a little smaller. I'll use the Altera the design fits.

Small is good, but I can't use the .4mm or .5mm pitch BGAs. Our comfort limit is .8mm. Altera has a 100 ball 1mm pitch package.

Can't you deserialize and run parallel memory?

Could be. They like to have some reason for you to use expensive spread.

If that's the case, just do the serdes in the FPGA and go parallel from there.

1. Inferred memory from logic. A "fully" specified CASE with 2^n terms will generate ROM. Memory, even dual port, can be inferred directly from the VHDL, as long as you keep it obvious.
2. You can instantiate either block memory or distributed memory blocks directly (not recommended)
3. You can use their memory builder macro. Xilinx (haven't gotten that far with Actel or Altera yet) has a pretty substantial library of RAMs, ROMs, Synchronous and Asynchronous DualPorts with various read/write configurations. This stuff is trivial with the Xilinx tools.

I'll have to check some other makers then. I was hoping I could use some of the flipflops for memory but I guess not.

I don't want bga, at least not at this point. But basically I can't add a lot of support circuitry(about 1sqin of room).

Not sure what you mean. If you mean one memory per ic then I can but it requires too much space and probably overly costly.

How? The fpga is right between the uC and the IC's. To do the serdes is outputing parallel. But because it is a matrix application it requires state information. That is the fgpa needs to remember the the on/off state of the led's and, in fact, compute them because it will also be doing PWM.

Basically each IC needs a 16x3*(5 to 10). The 5 to 10 is the PWM resolution. The fgpa will look up the value for the current led and determine if it should turn on the bit. The uC will modify those values when needed.

If I had some small memory IC that had "banks" that could be read in parallel and written simutaneously then that would solve the problem. I'll look for a fpga that has this stuff.

Look at Lattice MACHXO - the two larger ones have RAM or at the XP2 range (they all have RAM). Both ranges are cheap and instant on (config memory is on chip). The MACHXO can be go in 3.3V only versions. The tools work and are not expensive.

Michael Kellett

They don't seem to have enough(except the largest one).

In they datasheet they say

"Memory Cascading

Larger and deeper blocks of RAMs can be created using EBR sysMEM Blocks. Typically, the Lattice design tools

cascade memory transparently, based on specific design inputs."

I'm not sure what that means though. They have distributed ram and I don't know what that means either. One has 2k distributed ram. Does this mean that each "meta block" has 2k or 2k for all the meta blocks.

From one of your earlier posts I go the idea that you needed 16*3*10 *n bits (n is the number of ICs). If so, then for n = 8 you need 3840 bits and the LCMXO1200 would do. (It may not have enough logic for you). Failing that look at the XP2s.

The Lattice tools let you infer RAM or use explicitly instanciated blocks. There are ways of joining block RAMs together if you must.

The 5000 LUT XP2 is about the same price as the 2280 LUT MACHXO.

Michael Kellett

No, The fgpa needs about 1500 bits for the LED's state(16-ch drivers driving

3 rows each and about 30 drivers). But I would need to store the PWM of each LED. This is where it costs a lot of memory. 1500 LED's with a PWM resolution of 2^n. For n = 5, or 32 PWM steps, requires a memory of 48k. ( would like to get 2^8 PWM steps)

I then need to change PWM table randomly by the uC(since it would be too slow to update the whole block if only one value changed).

the fgpa basically looks at the PWM value for the LED and determines if it should send a 0 or 1. e.g. if PWM < counter then send 1, else 0.

That is basically all it does but just organizes the data to the right IO lines. It would also need to communicate with the uC(or maybe USB or some other method) for changing the PWM values but this doesn't require any memory.

It also needs to change the row's by driving the appropriate row mosfets but this is just a simple counter, one for each IC.

If I were to use external sram then I have to decide if I can use one large single SRAM or have to use one per IC. The one per IC is probably not going to fit on the board and cause other problems(I'm trying to get this all on a

2-layer board also). The single sram has to be accesses very fast because all the IC's are in parallel so the PWM data can only be accessed serially. (hence 30 times faster than the IC data rate)

I don't think this is necessarily an issue with a 300Mhz fpga and SRAM but I'd like to find another option if possible.

the IC's are in

than the IC data

I'd be very careful here.

You can probably design an FPGA implementation on two layers that will work with low speed IO but if you're synchronously driving a large number of IO then you will probably have problems with ground bounce etc.

This will cause problems with comms to the uC.

For a reliable FPGA implementation with fast IO you want _at_least_ a four layer board.

Nial.

I guess that should be 1500*5~=10k instead.

Jon Slaughter schrieb:

Distributed RAM is using the internal LUT4s as 16 entry RAM blocks. Every second LUT4 can be configured into a RAM Mode. Distributed Mem is nice for small 16-64 entry RAMs but you don't want to store larger amounts of data in distributed mem as it consumes logic resources and becomes ineffective for larger memory blocks. The 2k number is a rather theoretical, you only get that amount of distributed memory if you use half your LUTs (and all LUTs with a RAM Mode) as RAM. For the 1500*8 =

12kbits a EBR, block ram etc. is what you need. He could also look at the older Lattice XP Chips, these are available in a 1.8-3.3V version. The smallest XP chip contains 6 EBR Blocks with 9kbits each. So two EBR Blocks should be enough for his application, could even use 4 EBR and double buffer.

Jan