assigning pins location to a component pin

--- Quote Start ---

in order to get a clearer VHDL code, I want to reduce the number of ports in the top level entity.

so I wanted to assign pins location to pins directly in the components, instead of connecting them to ports in the top level entity.

--- Quote End ---

That does not make sense. The top-level entity ports *are* the pins on the device.

--- Quote Start ---

any ideas?

--- Quote End ---

Assigning pins in VHDL code does not really make much sense, except in the limiting case of the top-level entity. However, even in that case, I don't think it makes any sense, given that it clutters the design file. Having a Tcl script for constraints (device type, pin assignments, etc) makes for a cleaner approach.

If you do assign pins in a component, what happens when you instantiate two of those components? What happens when you change boards, and the FPGA pinout changes?

Your VHDL should be independent of the device - as much as possible anyway - at some point you may have to instantiate vendor specific or device specific IP.

How about you explain what you are trying to do a little clearer, and I'll offer suggestions?

If you are looking for suggestions on code organization/clarity, perhaps the following will help ... here's my code layout:

lib/<component>/src, test, scripts

boards/<board name>/<device name>/share/src, test, scripts

boards/<board name>/<device name>/<project>/src, test, scripts

The library folder 'lib' contains the majority of VHDL. The code is written as generically as possible, though it includes Altera IP blocks. The lib scripts folders contain Modelsim testbench scripts.

The boards folder contains the various boards I use. Each board can have one or more FPGAs on it, so each FPGA gets a subfolder. In the share subfolder is a constraints file with the common constraints, eg. the boards pin assignments. In the <projects> folders are the various small and large designs that can be downloaded to the board. The scripts folder contains Modelsim testbench scripts and Quartus synthesis scripts.

The boards src folder generally contains either a single design file, or a few design files. This is the top-level design constructed from reuseable components located in the lib folder. If some components are only reuseable on a per board basis, they go in the share folder in the boards directory.

As your code evolves, you move it from the board folder in the lib folder. I use a version control system to keep track of changes.

Cheers,

Dave

Hi Dave

I'm sorry but you missed my point, I guess I wasn't clear enough.

let me explain again my motivation:

I want to use the same code and top level entity for multiple boards.

for example one have serial LCD and the other have parallel LCD.

so each board has it own LCD interface component, and I use the "if generate" statement to instantiate the appropriate component. the instantiation includes of course port mapping to the top level entity ports.

so far so good...

now, in my top level entity I have to define ports for data bus, rd, wr etc and for SPI data, clk, CSn and so on.

I can assign the virtual pin attribute to the unused pins, and probably Quartes will ignore them, but the code will be messy.

my intention is, not to define any pins connected to the LCD in the top level entity, and instead to assign the pin location to the pin in the serial \ parallel interfaces.

as I wrote before, the assignment is done in the .qsf file (I use a different .qsf for each board) not in the VHDL code itself.

I hope I'm clearer now :)

--- Quote Start ---

I'm sorry but you missed my point, I guess I wasn't clear enough.

--- Quote End ---

OK, lets try again :)

--- Quote Start ---

let me explain again my motivation:

I want to use the same code and top level entity for multiple boards.

for example one have serial LCD and the other have parallel LCD.

so each board has it own LCD interface component, and I use the "if generate" statement to instantiate the appropriate component. the instantiation includes of course port mapping to the top level entity ports.

so far so good...

--- Quote End ---

Not quite ...

These two boards have unique physical pins, correct. One board will have the top-level pins for the parallel interface, while the other will not.

If the two interfaces are similarly named, then you might be able to come up with a port list and several generics that control which ports actually need to be connected (analogous to an SRAM controller that has different data, byte, address widths).

I think what you are really after is dynamic port names. Since VHDL and Verilog do not support 'ifdef' type logic within port definitions, I think what you are trying to do is going to be difficult, or at best ugly, eg., a component with both the serial and parallel interface port names, and in a specific design only one set of ports gets connected.

Alternatively you can take the Verilog solution to the lack of types and pack your ports into a big-long bit-vector ... but that would be pretty unreadable.

How many multiplexed interfaces are you trying to support?

How about the following example scenario;

Lets say I have an SOPC System design that is essentially identical and reused across multiple boards. The system has an Avalon-MM slave interface to your LCD controller, and that interface is not instantiated in the SOPC System (allowing it to be switched out without having to re-generate the system).

On boards with a parallel interface LCD, the top-level entity instantiates the SOPC System component, and the parallel LCD controller component. Similarly, on the boards with the serial interface LCD, the top-level entity instantiates the SOPC system and the serial interface LCD component.

I'm not sure that I see any advantage in trying to wrap this multiplexing of logic into a single 'LCD parallel/serial' component.

If you think it'd be clearer to work this out using code, we can do that ...

Cheers,

Dave

--- Quote Start ---

OK, lets try again :)

--- Quote End ---

and again:)

--- Quote Start ---

Not quite ...

These two boards have unique physical pins, correct. One board will have the top-level pins for the parallel interface, while the other will not.

If the two interfaces are similarly named, then you might be able to come up with a port list and several generics that control which ports actually need to be connected (analogous to an SRAM controller that has different data, byte, address widths).

--- Quote End ---

sometimes there is no LCD at all... this is why I rather not declare what I don't use.

--- Quote Start ---

How many multiplexed interfaces are you trying to support?

--- Quote End ---

at the moment I have 4, but the sales department keep them coming..

I still have a lot of schematic to VHDL migration to do, but that's another story

--- Quote Start ---

How about the following example scenario;

Lets say I have an SOPC System design that is essentially identical and reused across multiple boards. The system has an Avalon-MM slave interface to your LCD controller, and that interface is not instantiated in the SOPC System (allowing it to be switched out without having to re-generate the system).

On boards with a parallel interface LCD, the top-level entity instantiates the SOPC System component, and the parallel LCD controller component. Similarly, on the boards with the serial interface LCD, the top-level entity instantiates the SOPC system and the serial interface LCD component.

--- Quote End ---

it's a nicer way of doing what I do with the if generate statement. I use a generic that is defined in the .qsf file. only problem is that I will also use Xllinx FPGA soon...

--- Quote Start ---

I'm not sure that I see any advantage in trying to wrap this multiplexing of logic into a single 'LCD parallel/serial' component.

If you think it'd be clearer to work this out using code, we can do that ...

Cheers,

Dave

--- Quote End ---

I'm trying to use 2 components for the 2 boards, but I'm trying to export the signals to the outer world without going through the top level entity. the strange thing is that the assignment editor allows me to use the location assignment to a node that is not a port of the top level entity.

the problems begins later...

the ifdef option in C is what gave me the idea of one code for multiple projects. this is how our SW team works, I'm trying to do the same.

Ron

Hi Ron,

--- Quote Start ---

sometimes there is no LCD at all... this is why I rather not declare what I don't use.

--- Quote End ---

Man, you just want to have your cake an eat it too, eh? :)

How about something like this (apologies for the VHDL);

component generic_system is
  generic (
           LCD_TYPE : string := "PARALLEL"  -- or "SERIAL"
  );
  port (
     -- System reset
    rstN : std_logic;
     -- System Clock
     clk : std_logic;
    -- Some sort of control interface here
    -- Parallel LCD interface
    p_lcd_en      : out std_logic;
    p_lcd_rs      : out std_logic;
    p_lcd_rd_wrN  : out std_logic;
    p_lcd_dq      : in  std_logic_vector(7 downto 0) := (others => '0');
    p_lcd_dq_out  : out std_logic_vector(7 downto 0);
    p_lcd_dq_oe   : out std_logic
    -- Serial (SPI) LCD interface
    s_lcd_sel   : out std_logic;
    s_lcd_sck   : out std_logic;
    s_lcd_mosi  : out std_logic;
    s_lcd_miso  : in std_logic := '0'
);
end component;

This component would internally use the generic to decide which signals were actually driven by an instantiated component. The unused signals would be driven to deasserted levels. For example, lets say I want the parallel interface, then I set the generic appropriately, and inside this component the generic block that gets triggered for the parallel interface wires up the parallel LCD controller to this component's ports and that same generic block deasserts the serial LCD ports, eg. s_lcd_sel <= '0', etc. The generic block for the serial LCD interface does the opposite.

In the top-level entity for each specific board, you just instantiate an instance of this generic_system component. You leave the unused ports dangling, and the synthesis tool will eliminate them (note how the inputs on the component definition have been assigned default values. This will stop the synthesis tool complaining when you have nothing connected to those inputs). The pin assignments for the LCD interface go with the synthesis script for the board, eg., in a Tcl script.

In this scheme, there is no need for pin constraints embedded in the VHDL. You do have to have a top-level 'wrapper' that is board specific in which to drop your generic_system component, but that is really very little work.

How's that sound?

Cheers,

Dave

--- Quote Start ---

I use a generic that is defined in the .qsf file. only problem is that I will also use Xllinx FPGA soon...

--- Quote End ---

Quartus and Xilinx tools can both be controlled by Tcl scripts. For example, in a 'blink LEDs' design I have generics for the number of LEDs and the blink counter width.

1) Quartus

set_parameter -name LED_WIDTH 4

set_parameter -name COUNT_WIDTH 27

2) Xilinx ISE

project set "Generics, Parameters" {LED_WIDTH=4 | COUNT_WIDTH=27} -process "Synthesis - XST"

Cheers,

Dave

--- Quote Start ---

Hi Ron,

Man, you just want to have your cake an eat it too, eh? :)

--- Quote End ---

Don't we all? :)

I'm not what you call a skinny person...

--- Quote Start ---

How about something like this (apologies for the VHDL);

component generic_system is
  generic (
           LCD_TYPE : string := "PARALLEL"  -- or "SERIAL"
  );
  port (
     -- System reset
    rstN : std_logic;
     -- System Clock
     clk : std_logic;
    -- Some sort of control interface here
    -- Parallel LCD interface
    p_lcd_en      : out std_logic;
    p_lcd_rs      : out std_logic;
    p_lcd_rd_wrN  : out std_logic;
    p_lcd_dq      : in  std_logic_vector(7 downto 0) := (others => '0');
    p_lcd_dq_out  : out std_logic_vector(7 downto 0);
    p_lcd_dq_oe   : out std_logic
    -- Serial (SPI) LCD interface
    s_lcd_sel   : out std_logic;
    s_lcd_sck   : out std_logic;
    s_lcd_mosi  : out std_logic;
    s_lcd_miso  : in std_logic := '0'
);
end component;

This component would internally use the generic to decide which signals were actually driven by an instantiated component. The unused signals would be driven to deasserted levels. For example, lets say I want the parallel interface, then I set the generic appropriately, and inside this component the generic block that gets triggered for the parallel interface wires up the parallel LCD controller to this component's ports and that same generic block deasserts the serial LCD ports, eg. s_lcd_sel <= '0', etc. The generic block for the serial LCD interface does the opposite.

In the top-level entity for each specific board, you just instantiate an instance of this generic_system component. You leave the unused ports dangling, and the synthesis tool will eliminate them (note how the inputs on the component definition have been assigned default values. This will stop the synthesis tool complaining when you have nothing connected to those inputs). The pin assignments for the LCD interface go with the synthesis script for the board, eg., in a Tcl script.

In this scheme, there is no need for pin constraints embedded in the VHDL. You do have to have a top-level 'wrapper' that is board specific in which to drop your generic_system component, but that is really very little work.

How's that sound?

Cheers,

Dave

--- Quote End ---

this is what I have right now.

the problem is that either I get a very messy top level entity (because of all the pin declarations)

or I can use multiple "wrapper" files as you suggested, but it kind of bits the purpose of unifying multiple projects into one. any change I will make in the components connectivity, I will have to copy paste it into the others... even when using version control there is a lot of room for errors.

I really liked the option of assigning locations to components pins. and it looked like Qurtus accepts it at first. it built up my expectations.:cry:

Is there anyone who thinks it's doable? I'm using version 8.1 at the moment, but I'm about to upgrade to 11 soon.

--- Quote Start ---

Quartus and Xilinx tools can both be controlled by Tcl scripts. For example, in a 'blink LEDs' design I have generics for the number of LEDs and the blink counter width.

1) Quartus

set_parameter -name LED_WIDTH 4

set_parameter -name COUNT_WIDTH 27

2) Xilinx ISE

project set "Generics, Parameters" {LED_WIDTH=4 | COUNT_WIDTH=27} -process "Synthesis - XST"

Cheers,

Dave

--- Quote End ---

I know that ISE uses tcl as well, and I intend to take advantage of that.

I only mentioned migrating to Xillinx because you wrote about SOPC builder.

have a nice day

Ron

Hi Ron,

--- Quote Start ---

the problem is that either I get a very messy top level entity (because of all the pin declarations)

--- Quote End ---

I'm not sure I follow you here.

I always design a top-level entity for a board that has all the pins used in the schematic design. I then create a 'basic' design that deasserts all output signals, and typically blinks an LED. This same top-level file is then used for all subsequent designs. This allows the top-level pins and pin assignments to always exist, and there are no warnings from Quartus regarding invalid assignments.

With this approach the 'messy' would just be the connection of the port names on your generic_system component to your specific board pins.

Arguably it is a duplication of effort, but you're really just working within the limitations of the language.

I bet with a little effort you could write a Tcl script to create the wrapper.

--- Quote Start ---

or I can use multiple "wrapper" files as you suggested, but it kind of bits the purpose of unifying multiple projects into one. any change I will make in the components connectivity, I will have to copy paste it into the others... even when using version control there is a lot of room for errors.

--- Quote End ---

This is where I would probably go for a common Tcl procedure that generates the top-level wrapper. Part of the build script could determine whether the wrapper .vhd needs to be created, and then you have no manual coding. As your designs evolve, its the Tcl script that evolves.

--- Quote Start ---

I really liked the option of assigning locations to components pins. and it looked like Qurtus accepts it at first. it built up my expectations.:cry:

--- Quote End ---

I think that can work for ports that exist on the top-level entity, but I don't see how it can work for a pin with ports hidden inside the design. I suspect its just not supported, since when the netlist is flattened, as far as the VHDL language is concerned, you have a signal that goes nowhere.

--- Quote Start ---

Is there anyone who thinks it's doable? I'm using version 8.1 at the moment, but I'm about to upgrade to 11 soon.

--- Quote End ---

I don't think its possible.

--- Quote Start ---

I know that ISE uses tcl as well, and I intend to take advantage of that.

I only mentioned migrating to Xillinx because you wrote about SOPC builder.

--- Quote End ---

Is that a dig at SOPC Builder? I'm not a big fan of its features ... it just seemed like the kind of thing you'd drop an LCD into ... I wasn't trying to drive you away :)

Cheers,

Dave

now it's start to get interesting,

you mean I can generate the VHDL code itself from tcl? including ports and signal decelerations?

so far I thought I can use only the if generate statement as in the blink LED example you showed, but that's only valid for the architecture "body" where I instantiate and define the logic.

I'm new to tcl, so far I used the GUI, so I'm learning about it's capabilities. can you recommend any good (and free) guide to tcl, aimed at VHDL preferably?

Ron

--- Quote Start ---

you mean I can generate the VHDL code itself from tcl? including ports and signal decelerations?

--- Quote End ---

Of course, VHDL files are just text, and Tcl can generate text :)

--- Quote Start ---

so far I thought I can use only the if generate statement as in the blink LED example you showed, but that's only valid for the architecture "body" where I instantiate and define the logic.

--- Quote End ---

So think of these if-def conditionals now as the arguments to Tcl VHDL generator functions. The Tcl procedure will output a top-level entity without any generics, and the body will be VHDL code that wires up your LCD component along with appropriate generics on its ports.

--- Quote Start ---

I'm new to tcl, so far I used the GUI, so I'm learning about it's capabilities. can you recommend any good (and free) guide to tcl, aimed at VHDL preferably?

--- Quote End ---

What I am proposing is writing text files, and is not specific to VHDL.

Any good book on Tcl will work for you. I like the books by Brent Welch.

For SOPC system components, I will often use a top-level template .txt file, and then in the 'elaborate' callback, use Tcl to search-and-replace strings within the template file. The reason I need to do this is I use time and real generics on my component, and SOPC does not directly support these types. I use strings in the SOPC builder GUI elements, parse them with Tcl, and then implement the logic.

I don't mind writing a simple Tcl example for you.

Write a simple VHDL design for me, including two different top-level entity definitions, with bodies that include mostly the same logic (like the generic_system component). Make sure it compiles in Modelsim, as we'll use that as our VHDL syntax checker. I'll then write a Tcl script that regenerates the top-level wrappers, and you can take it from there.

Cheers,

Dave