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

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

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

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

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

Dave,

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

Regards,

Josy

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

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

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

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.