Vhdl 'device_family'

[Altera_Forum]

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.

[Altera_Forum]

--- 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

[Altera_Forum]

--- 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.

[Altera_Forum]

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

[Altera_Forum]

--- 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?

[Altera_Forum]

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.

[Altera_Forum]

--- 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.

[Altera_Forum]

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

[Altera_Forum]

--- 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?

[Altera_Forum]

--- 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

[Altera_Forum]

--- 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).

[Altera_Forum]

--- 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

[Altera_Forum]

--- 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.

[Altera_Forum]

--- 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

[Altera_Forum]

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

[Altera_Forum]

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

[Altera_Forum]

Dave, 

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

[Altera_Forum]

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

[Altera_Forum]

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

[Altera_Forum]

--- 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

[Altera_Forum]

Dave, 

 first thing I did this morning was to set up the projects and compile/test all three. Made a small change to example three and 'played' it. It works great and I will certainly use this approach in my project. The only thing to change is that we have different sensors on one side and different interfaces at the other side. In the past we just kept the list of general IO pins, like s[7..0], id[11..0], ld[27..0], and declared most of them all bidirectional and the connected them to their respective pins from the sub-module. This off course provokes a considerable amount of warnings. Apart from the fact that now we also may have to cope with different But I can add different sections in the share\scripts\constraint.tcl file, set a variable before sourcing the constraint.tcl script and ready we are!  May I suggest you create a page on the Altera Wiki, what you made up here surpasses the examples in the Altera documentation by far.  Thanks again and best regards,  Josy  BTW. You can avoid that 'unschöne' (unbeautiful?) 'assertion is false' in the Message window by encapsulating a report statement in a process:  process( all ) begin report "an informational message" ; end process ;  It took me a while to find that out.