Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Valued Contributor III
1,274 Views

Vhdl 'device_family'

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.

0 Kudos
27 Replies
Highlighted
Valued Contributor III
1 View

Re: 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
0 Kudos
Highlighted
Valued Contributor III
1 View

Re: Vhdl 'device_family'

 

--- 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.
0 Kudos
Highlighted
Valued Contributor III
1 View

Re: Vhdl 'device_family'

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
0 Kudos
Highlighted
Valued Contributor III
1 View

Re: Vhdl 'device_family'

 

--- 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?
0 Kudos
Highlighted
Valued Contributor III
1 View

Re: Vhdl 'device_family'

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.

0 Kudos
Highlighted
Valued Contributor III
1 View

Re: Vhdl 'device_family'

 

--- 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.
0 Kudos
Highlighted
Valued Contributor III
1 View

Re: Vhdl 'device_family'

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

0 Kudos
Highlighted
Valued Contributor III
1 View

Re: Vhdl 'device_family'

 

--- 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?
0 Kudos
Highlighted
Valued Contributor III
1 View

Re: Vhdl 'device_family'

 

--- 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
0 Kudos
Highlighted
Valued Contributor III
1 View

Re: Vhdl 'device_family'

 

--- 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).
0 Kudos
Highlighted
Valued Contributor III
1 View

Re: Vhdl 'device_family'

 

--- Quote Start ---  

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

 

--- Quote End ---  

I can understand that :) 

 

 

--- Quote Start ---  

 

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. 

 

--- Quote End ---  

Yeah, I'm not a big fan of it either, but it would work. 

 

The other option is to use VHDL configurations. I haven't used them, but I believe they could be coaxed into being used for your application. You'd have a component definition, eg., 'fifo', that does not have a corresponding architecture definition, its really just a place-holder within your design. In your top-level configuration file you would effectively do something like; for <heirachical path to 'fifo'> use fifo_cycloneII, where fifo_cycloneII has the same ports as the fifo component, or you can map port names in the configuration file. You'd do something similar for a 'ram' component. Then when you changed target devices, you'd have a configuration file that mapped to fifo_cyloneIV. In fact, you could probably have the mapping to lpm_scfifo, and just configure the generics and lpm_hint as you want. 

 

I'm beginning to like this solution ...  

 

 

--- Quote Start ---  

 

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

--- Quote End ---  

I prefer the scripting approach. If you'd like an example on how to correct the error of your ways, let me know, and I'll send you example scripts :) 

 

Cheers, 

Dave
0 Kudos
Highlighted
Valued Contributor III
1 View

Re: Vhdl 'device_family'

 

--- Quote Start ---  

I prefer the scripting approach. If you'd like an example on how to correct the error of your ways, let me know, and I'll send you example scripts 

--- Quote End ---  

 

Now I may be stubborn, but I'm always willing to learn, and how can one better learn than from a 'real' example. Running synthesis/mapping/fitting from a script sounds promising as we will start on a project where we can use that approach. It is a CMOS camera with a choice of both sensors and interfaces so it would be nice to build al possible combinations from a single top file. I'll probably use a 'custom' preprocessor to parse a C-style 'if defined()' source text, to produce a nice and readable top-file.
0 Kudos
Highlighted
Valued Contributor III
1 View

Re: Vhdl 'device_family'

 

--- Quote Start ---  

Now I may be stubborn, but I'm always willing to learn, and how can one better learn than from a 'real' example. 

 

--- Quote End ---  

I'll contrive a 'real' example :) 

 

 

--- Quote Start ---  

 

Running synthesis/mapping/fitting from a script sounds promising as we will start on a project where we can use that approach. It is a CMOS camera with a choice of both sensors and interfaces so it would be nice to build al possible combinations from a single top file. 

--- Quote End ---  

Would this design contain a single FPGA with an identical pin assignment, even if some of those pins change function between the designs, or multiple FPGAs with different pinouts? Just so I can give you something realistic ... 

 

Cheers, 

Dave
0 Kudos
Highlighted
Valued Contributor III
1 View

Re: Vhdl 'device_family'

The FPGA will be the 'common' thing. But don't loose time over it, I'm good in extracting information from examples, especially from the better ones ... 

 

Regards, 

Josy
0 Kudos
Highlighted
Valued Contributor III
1 View

Re: Vhdl 'device_family'

Hi Josy, 

 

 

--- Quote Start ---  

The FPGA will be the 'common' thing. 

 

--- Quote End ---  

'The FPGA' meaning what exactly? Device type, pin assignments, i.e., its the thing on one board, and that board is re-purposed for different projects? 

 

 

--- Quote Start ---  

But don't loose time over it, I'm good in extracting information from examples, especially from the better ones ... 

 

--- Quote End ---  

I've got plenty of different designs so it won't take much to put an example together. No guarantee that its better, just different :) 

 

Cheers, 

Dave
0 Kudos
Highlighted
Valued Contributor III
1 View

Re: Vhdl 'device_family'

Dave, 

 

it will be a EP4CE15F17C7, and effectively will sit on its own PCB between the sensor and the interface PCB.  

 

Regards, 

 

Josy
0 Kudos
Highlighted
Valued Contributor III
1 View

Re: Vhdl 'device_family'

Hi Josy, 

 

Please take a look at the attached zip file. There are three designs in there. I'll just copy the readme.txt inline as it describes the files; 

 

 

--- Quote Start ---  

 

VHDL generics and configurations examples 

----------------------------------------- 

 

7/1/2011 D. W. Hawkins (dwh@ovro.caltech.edu

 

These design examples target the BeMicro-SDK stick. I downloaded 

each synthesized design and checked they worked (each design uses 

a different blink rate to distinguish them in hardware). 

 

In all cases the design implements a simple blinking LEDs example. 

However, each design implements hierarchy in a different manner. 

 

1. example1/ 

 

This is the simplest version of the design. The top-level file 

bemicro_sdk takes generics that specify the LED blink parameters. 

The values of the generics are specified by the synthesis script. 

 

The blink_leds counter is implemented using generic VHDL. 

 

The LED blink rate is set to 1.0s 

 

2. example2/ 

 

This design adds additional generics to the top-level design that 

are passed down to a counter component in the blink_leds component, 

 

The generics can be set to select a "GENERIC" implementation of a 

counter (as used in example1), or an "ALTERA" specific implementation. 

The "ALTERA" implementation can be "GENERIC" which instantiates 

code that corresponds to Altera's recommended HDL coding style for 

correct inference of logic (in this case, its no different than 

example1), or "DEFAULT" or "LPM" which implements an LPM counter. 

 

The LED blink rate is set to 0.5s 

 

3. example3/ 

 

Rather than using generics to specify the counter, this design uses 

VHDL configurations. 

 

The counter used in the blink_leds component implemented using 

a component interface description called up_counter. There is 

no corresponding entity/architecture pair for this component. 

 

A configuration file is then used to specify the mapping from 

up_counter to either a generic counter or an Altera specific 

counter. 

 

The LED blink rate is set to 0.25s 

 

------- 

 

To synthesize the designs; 

 

1. Start Quartus (I tested this on 10.1) 

 

2. Open the Tcl console via View->Utility Windows->Tcl Console 

 

3. Change directory to the example, eg. 

 

tcl> cd {C:\temp\vhdl_configurations\example1} 

 

The curly braces pass the directory as a 'list' to Tcl and 

it correctly interprets the path under windows. I don't think 

they're required under Linux. 

 

4. Run the synthesis script via: 

 

tcl> source scripts/synth.tcl 

 

5. Once the design is synthesized, you can rebuild via the 'play' 

button in the Quartus GUI, or you can re-source the script. 

 

If you edit the designs and get synthesis error, then the Tcl 

path might be set to the work folder, so up-arrow to the cd 

command, and then re-source the script. 

 

6. The synthesis scripts play nicely in that you can switch between 

designs without having to close them in Quartus, eg. 

 

tcl> cd {C:\temp\vhdl_configurations\example1} 

tcl> source scripts/synth.tcl 

tcl> cd {C:\temp\vhdl_configurations\example2} 

tcl> source scripts/synth.tcl 

tcl> cd {C:\temp\vhdl_configurations\example3} 

tcl> source scripts/synth.tcl 

 

and then back to example 1 

 

tcl> cd {C:\temp\vhdl_configurations\example1} 

tcl> source scripts/synth.tcl 

 

will synthesize each design correctly.  

 

--- Quote End ---  

Take a look at the scripts/synth.tcl scripts. They're the examples of synthesis scripts I was going to send. 

 

However, what I have also done with these examples is show you how you can abstract your FIFO component so that you could instantiate a specific FIFO implementation. Example 2 shows how you can customize the component using generics, while example 3 shows customization using a configuration. 

 

Enjoy! 

 

Cheers, 

Dave
0 Kudos
Highlighted
Valued Contributor III
1 View

Re: Vhdl 'device_family'

Hello Dave, 

 

i quickly perused the zip.file at this late hour(just before going to bed) and I'm starting to see better. I'm still not that comfortable pushing down generics but I don't think the VHDL committee will be easy to persuade. How do we reach them, anyway? 

 

I'll install the files tomorrow, and make the LEDs on my BeMicro SDK flash ... 

 

Thanks and best regards, 

 

Josy
0 Kudos
Highlighted
Valued Contributor III
1 View

Re: Vhdl 'device_family'

 

--- Quote Start ---  

 

i quickly perused the zip.file at this late hour(just before going to bed) and I'm starting to see better. 

 

--- Quote End ---  

I'm sure it'll help you go to sleep :) 

 

 

--- Quote Start ---  

 

I'm still not that comfortable pushing down generics but I don't think the VHDL committee will be easy to persuade. How do we reach them, anyway? 

 

--- Quote End ---  

Hey, its our code, we can 'push around' whatever we like :) 

 

I don't think the VHDL police will be checking on how the language is used or abused. 

 

 

--- Quote Start ---  

 

I'll install the files tomorrow, and make the LEDs on my BeMicro SDK flash ... 

 

--- Quote End ---  

Perhaps you'll even see the error in your GUI-using ways ... 

 

Cheers, 

Dave
0 Kudos