Vhdl 'device_family'

--- Quote Start ---

Is there an equivalent of the AHDL predefined Altera parameter DEVICE_FAMILY in VHDL? I have a single module to instantiate a Fifo (as I don't like to generate fixed components using the MegaWizard). Now I'm trying to impose the type of block-ram to be used, but e.g. Stratix II has M512, M4k and M-Ram, where e.g Cyclone IV only has M9K. I want to specify the RAM_BLOCK_TYPE using the 'lpm_hint' generic but I then I need to identify the device family at hand.

--- Quote End ---

You could try "AUTO" as the RAM type and then let Quartus select the "right" RAM for you.

You could add a generic at the top-level called "DEVICE_FAMILY" or "RAM_TYPE" and then pass that down into the design. This is a pain, since you then have to push that generic all the way to the top-level of the design. Another option is to have a configuration package that each design that uses a RAM includes. That VHDL package file would be board specific. Inside this package you can have the constant RAM_TYPE, or multiple names, eg. FIR_COEFFS_RAM_TYPE, RESULTS_RAM_TYPE, etc. Since this package would be included by the components that use RAM, there would be no generics that would have to propagate to the top-level of the design.

There may be Quartus synthesis directives for RAM use that might be available; I have not used any. But if they existed, and allowed you to specify a RAM by its hierarchical path, then at least that would be independent of the VHDL, and would go in the synthesis script for the design.

Cheers,

Dave

--- Quote Start ---

You could try "AUTO" as the RAM type and then let Quartus select the "right" RAM for you.

--- Quote End ---

that is where it went wrong : the compiler at one point abused a M-Ram to implement 4096 bits while at the same time using 32 M4Ks to build another fifo and subsequently failing to fit... so I went into the Fifo module and cleared that up, at least for the current project. That code will provoke a warning when we will build our next Cyclone IV design, and I (try to) write code without unnecessary warnings.

--- Quote Start ---

You could add a generic at the top-level called "DEVICE_FAMILY" or "RAM_TYPE" and then pass that down into the design. This is a pain, since you then have to push that generic all the way to the top-level of the design. Another option is to have a configuration package that each design that uses a RAM includes. That VHDL package file would be board specific. Inside this package you can have the constant RAM_TYPE, or multiple names, eg. FIR_COEFFS_RAM_TYPE, RESULTS_RAM_TYPE, etc. Since this package would be included by the components that use RAM, there would be no generics that would have to propagate to the top-level of the design.

--- Quote End ---

Pushing the RAM-type down as a generic, what were you thinking?

Of course I thought about the possibility of the project package but this is only warranted for true project definitions. It would also mean that for any sub-module project I would have to define a project package, or a default package for each family, that's just clumsy. I can work around by writing a AHDL module that exports the DEVICE_FAMILY for use in VHDL modules, but that AHDL file would have to be manually included too ... I would be tempted to modify the Altera supplied LPM library, as that get's included in about every VHDL file as I tend to use the std_logic_2D a lot. But I can hear the FLAK coming!

--- Quote Start ---

There may be Quartus synthesis directives for RAM use that might be available; I have not used any. But if they existed, and allowed you to specify a RAM by its hierarchical path, then at least that would be independent of the VHDL, and would go in the synthesis script for the design.

Cheers,

Dave

--- Quote End ---

So it would be nice if Altera provided such a predefined parameter. It is not only is useful for fifos /rams but possibly also in other projects where the family used could matter.

Quartus does provide the "ramstyle" synthesis attribute, but that is only for infered rams.

-- First, declare a signal that represents a RAM

type memory_t is array (0 to 63) of std_logic_vector(0 to 7);

signal my_ram : memory_t;

attribute ramstyle : string;

attribute ramstyle of my_ram : signal is "M512";

But for the FIFOs, I have only ever done it via LPM_HINT

--- Quote Start ---

Quartus does provide the "ramstyle" synthesis attribute, but that is only for infered rams.

-- First, declare a signal that represents a RAM

type memory_t is array (0 to 63) of std_logic_vector(0 to 7);

signal my_ram : memory_t;

attribute ramstyle : string;

attribute ramstyle of my_ram : signal is "M512";

But for the FIFOs, I have only ever done it via LPM_HINT

--- Quote End ---

I have never inferred Rams, and probably never will. I'll cross that bridge if ever we switch to Xilinx or Lattice or ...?

I was just looking for a VHDL equivalent of the AHDL predefined "DEVICE_FAMILY' parameter. Can you suggest to Altera to add a 'device_family' function to the LPM library?

--- Quote Start ---

You dont need to specify the device family if you're specifying M9K or MLAB or whatever. The device family is picked up from the project settings.

--- Quote End ---

I landed in the situation where I try / have to maximise the use of the M512 / M4K / M-Ram in a Stratix II GX project. At some point The compiler ran out of M4K blocks and I added a generic to force M512 blocks up to a certain size. This has compiled fine for several months but yesterday the compiler messed everything up, so I went into my FIFO module and augmented the LPM_HINT directive and added a rule to only use M-Ram when warranted. But the code is only valid for Stratix II (and up?) devices and will throw a warning for Cyclone families. And I don't like my code to throw unnecessary warnings. Hence the request for the predefined DEVICE_FAMILY parameter/generic/constant.

--- Quote Start ---

could you not use one yourself, and use genetes or something to modify the LPM hint based on your selection of device family? I dont understand why a package constant is going to be a problem for this, because the device family will hold true for all elements, and then you can modify the LPM_HINT on a FIFO by FIFO bases if you want some in MRAMs and some in M4Ks

--- Quote End ---

You have a point there, I could just add the generic ram_block_type : string := "auto"; and forget about it for most projects and only in this special one where we use a lot of Block Ram force it to whatever appropriate.

But the question was not how to manage my RAM, but rather whether the 'DEVICE_FAMILY' predefined parameter existed in VHDL, or there was another way to get the information. E.g I am building a DDR2 PHY for Cyclone devices as a 'midnight project' and there the information whether I have a Cyclone II, II or IV device at hand may be useful. BTW that same information should also be available for TimeQuest. But now I am really asking too much, aren't I?

--- Quote Start ---

But the question was not how to manage my RAM, but rather whether the 'DEVICE_FAMILY' predefined parameter existed in VHDL, or there was another way to get the information. E.g I am building a DDR2 PHY for Cyclone devices as a 'midnight project' and there the information whether I have a Cyclone II, II or IV device at hand may be useful. BTW that same information should also be available for TimeQuest. But now I am really asking too much, aren't I?

--- Quote End ---

Why don't you like the idea of having a generic at the top-level of your design. If the generic is simply DEVICE_FAMILY, or VENDOR and DEVICE, if you are playing with Altera, Xilinx, and Lattice devices. Down in the lower levels of your code, you can have generate statements based on the generics.

The top-level simulation, synthesis, and TimeQuest scripts can all use the same generic values to determine their operation.

Cheers,

Dave

--- Quote Start ---

Why don't you like the idea of having a generic at the top-level of your design. If the generic is simply DEVICE_FAMILY, or VENDOR and DEVICE, if you are playing with Altera, Xilinx, and Lattice devices. Down in the lower levels of your code, you can have generate statements based on the generics.

The top-level simulation, synthesis, and TimeQuest scripts can all use the same generic values to determine their operation.

Cheers,

Dave

--- Quote End ---

Probably because I belong to the stubborn class of people :)

I haven't considered using Xilinx or Lattice or another FPGA vendor. In fact I once selected Lattice for a project, even bought the SW and then got stage-fever and stayed with Altera ... the profits didn't weigh off against the learning/experience curve.

But even if I would port a project to another FPGA type, I still would try to take the decision at the lowest level. Propagating the Device Type from the top level down to the lowest module via generics doesn't sound appealing to me. The same holds for a Project Package because then to develop the lower-level modules I would need to include a Project Package, just adding more clutter. The AHDL predefined "DEVICE_FAMILY" parameter was just nice. As a stopgap I will probably do what I described to Tricky

I don't use any scripts to do top-level synthesis, simulation or to run TimeQuest, doing everything from within the Quartus environment(s).