Arrays of arrays: How to assign them to instances of components?

VHDL is very specific when it comes to using types.

Rather than defining a new type in your second component, i.e., sub_RAM_integer_array, use the type RAM_integer_array from your package, since that is what is returned when indexing into the array.

Cheers,

Dave

Hi, and thanks a lot for your response!

Hm. When i simply use RAM_integer_array in bla instead of sub_RAM_integer_array Quartus complains with:

Error (10482): VHDL error at bubb.vhd(153): object "RAM_integer_array" is used but not declared File: c:/blubb.vhd Line: 153

So i think that i have to declare it in the sub-component, and the only way i found by searching the web was by packages in the sub-component.

When i search-replace sub_RAM_integer_array with RAM_integer_array in bla and in blubb, and remove the then doubled declaration of the array in blubb, there seems to develop some kind of loop in the compilation...? :

Out of memory in module quartus_map.exe (3136 megabytes used)

Best regards :-)

If your data types are located in a package, and that package is used in each VHDL file, then there should be no problem.

Write and test your code in Modelsim first.

Quartus will not synthesize VHDL that does not map to hardware. Your description sounds like "simulation-only" VHDL. If you need to implement your logic in hardware, then you have to code appropriate to the hardware.

Cheers,

Dave

Hi, and thanks again :-),

well... i have a system of 48 Altera Stratix IV here, where i am co-developing the electronics, and where i am supposed to develop the firmware now, why i started learning VHDL a few months ago :-), and the only thing of my now about-6000-lines-code i programmed and tested all the time, with interfaces (e.g. I2C and SPI to a lot of peripheral systems), busses (e.g. 48 highspeed-ADCs per Stratix with DDR-serial-interfaces, DSPs, LVDS-Interfaces plus substantial protocols to other FPGAs (cyclone II, ...), a VME bus system, and lots of more stuff...) which now does not compile and synthesize are just these memory arrays, cause i simply dont know yet how to instantiate them correctly, and i dont find any information how to do it :-)

I will try-and-error more tomorrow, such as different approaches of locating the package...

Best regards :-)

--- Quote Start ---

well... i have a system of 48 Altera Stratix IV here, where i am co-developing the electronics, and where i am supposed to develop the firmware now, why i started learning VHDL a few months ago :-), and the only thing of my now about-6000-lines-code i programmed and tested all the time, with interfaces (e.g. I2C and SPI to a lot of peripheral systems), busses (e.g. 48 highspeed-ADCs per Stratix with DDR-serial-interfaces, DSPs, LVDS-Interfaces plus substantial protocols to other FPGAs (cyclone II, ...), a VME bus system, and lots of more stuff...) which now does not compile and synthesize are just these memory arrays, cause i simply dont know yet how to instantiate them correctly, and i dont find any information how to do it :-)

--- Quote End ---

Why don't you explain your system to me, and what you want to do with it, and I'll try to help provide some direction for you.

I have a lot of experience with large FPGA-based systems; the system I am working on uses 250 Stratix IV GTs.

If you don't want to discuss the project on this list, then send me an email (to my forum name).

Cheers,

Dave

hi,

Thanks for the offer; but i workarounded the problem for now: I put the RAMs directly into bla instead of blubb instead of instantiating it, and implemented a protocol to read and write from and to the RAM in blubb... (maybe i will have a closer look to the problem again later, but now i can't invest more time in that :-) ).

If you are interested in what the electronics i am developing is for: Its the readout system (including analog-to-digital-conversion and first level data processing) of a silicon detector of a particle accelerator (very similar to that of the LHC at CERN).

Best regards :-)

--- Quote Start ---

Thanks for the offer; but i workarounded the problem for now: I put the RAMs directly into bla instead of blubb instead of instantiating it, and implemented a protocol to read and write from and to the RAM in blubb... (maybe i will have a closer look to the problem again later, but now i can't invest more time in that :-) ).

--- Quote End ---

Rather that try and "work-around" something, you should try to understand the language first. Understanding how to use VHDL will serve you well in the longer run.

--- Quote Start ---

If you are interested in what the electronics i am developing is for: Its the readout system (including analog-to-digital-conversion and first level data processing) of a silicon detector of a particle accelerator (very similar to that of the LHC at CERN).

--- Quote End ---

Cool. Are these various boards supposed to talk to each other?

Your VHDL code is *not* written in a style that maps well to hardware. For example, FPGA RAM comes in specific sizes. In general, the synthesis tool will not "optimize" your arrays of arrays for you, and map them efficiently into various RAMs. Its really up to you as the designer to understand how to use the dual-ported RAM in the FPGA, the sizes of the various blocks in the FPGA, and then write code to efficiently move data into and out of those RAMs.

If your VME bus has a main host computer, and the FPGA boards are configured to DMA data back and forth to that host computer, then you need to understand how bridges and DMA controllers work.

The array of arrays you are "playing" with now might actually be a cascade of various protocols, eg., ADC samples the data and writes that data into a doubled-buffered dual-port RAM, when the RAM is filled, a DMA is initiated so that the data is transferred to the host, or to another FPGA board in the VME backplane.

This system can easily be described in VHDL and simulated (as a system) in Modelsim. Once your simulation works, you can synthesis the multiple designs, and test them in hardware.

You commented that you are new to VHDL. Don't be afraid to ask questions on this forum. Just make sure to ask intelligent questions, i.e., show you have tried to figure things out, and when someone gives you advice, take it, or if you could not understand the advice, ask further questions.

Cheers,

Dave

Hi,

> Your VHDL code is *not* written in a style that maps well to hardware. For example, FPGA RAM comes in specific sizes. In general, the synthesis tool will not "optimize" your arrays of arrays for you, and map them efficiently into various RAMs. Its really up to you as the designer to understand how to use the dual-ported RAM in the FPGA, the sizes of the various blocks in the FPGA, and then write code to efficiently move data into and out of those RAMs.

Yes, the compiler told me that. But i have to read out multiple values of these data tables simultaneously and asynchroneously in various different code locations (the contents are i.e. parameters for pedestal and threshold corrections of the analog values of the individual silicon sensor strips, and later also e.g. for FIR-filter-parameters etc..., and there are multiple stages of these corrections which use the same tables...), so i think that normal dual-ported RAM does not work here. Whenever possible, I of course use optimized RAMs as found in alteras design recommendations.

> ask further questions

I will do that, thanks :-)

Best regards :-)

--- Quote Start ---

But i have to read out multiple values of these data tables simultaneously and asynchroneously in various different code locations

--- Quote End ---

In general, there's no such thing as asynchronous inside the FPGA :)

Your FPGA is a clocked device, perhaps with multiple clocks, eg., one for each of your external devices. Your system needs some form of control path, eg., the VME backplane or 1GbE connections to all the boards. This interface would provide control and command, eg., downloading of filter coefficients, monitoring of voltages and currents. Data travels via multiple synchronous domains, with clock crossing logic between each domain.

--- Quote Start ---

(the contents are i.e. parameters for pedestal and threshold corrections of the analog values of the individual silicon sensor strips, and later also e.g. for FIR-filter-parameters etc..., and there are multiple stages of these corrections which use the same tables...), so i think that normal dual-ported RAM does not work here. Whenever possible, I of course use optimized RAMs as found in alteras design recommendations.

--- Quote End ---

You have two choices for your RAM; single-ported or dual ported, and that's it. It either works for your application or it does not. The trick is finding a way to make it work :)

For example, keep in mind that the FPGA memory can operate at several hundred MHz. If your multiple sensors require the same RAM contents at a slower rate, the RAM can simply be read multiple times. For example, lets say all sensors need to be updated at 100Hz. The sensors each use a 32-bit parallel word, and that word comes from a RAM. There are 100 sensors to simultaneously update with a different value, and because all the values you need can fit in a single RAM, you only want to use a single RAM (not 100 RAMs). The way to implement this is to have each sensor use a double-buffered register; one register with the current value, another register to store the next value to use. The next value gets loaded at 100Hz rate by a global control signal, eg., something derived from a GPS tick (i.e., the register-to-register path has an enable control that pulses every 100Hz). The task of the RAM-to-sensor register interface is to update the double-buffered next register within the next 100MHz period, i.e., as soon as that double buffered register has transferred to the "in-use" register, a control FSM will go and update the 100 other values. The requirement is to read 100 RAM locations and write them to 100 registers. The implementation that requires the minimum resources is to configure the 100 "next" registers as a shift register, as then it take 100 clocks at the memory rate to update the next value.

The key to FPGA design is to first determine what needs to happen, then jot down a few ideas, synthesize some of those ideas to see how many resources are being used and whether it has good timing margin (which indicates a poor design, i.e.., poor in the sense that it does not map well to FPGA resources).

Drawing a block diagram is a good start. Asking questions, or presenting your ideas clearly for others to review is also a good way to get feedback.

Cheers,

Dave