Hi this is a little complicated but I'll try to be clear: 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. so in the .qsf file I have something like: set_location_assignment PIN_A1 -to "my_srffe:b2v_inst1|Q" when I look in the floor plan I can see that the pin is assigned to the IO. but in the compilation report I get a warning that the assignment have been ignored because the node does not exist in the design. when I program the device it seems that the pin is not assigned. I tried using the keep attribute in the component architecture, but it didn't help. any ideas?

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

assigning pins location to a component pin

16 Replies

Altera_Forum
Honored Contributor
14 years ago
Hi Dave

I'll take you up on your offer :), please see this simple top level entity:

--- Quote Start ---

package tcl_test is
type HW is (dff_board, srff_board);
end tcl_test;

LIBRARY ieee;
USE ieee.std_logic_1164.all;
LIBRARY work;
USE work.tcl_test.all;

ENTITY simple IS
GENERIC (board: HW);
PORT
(
--for dff board
D : IN STD_LOGIC_VECTOR(1 DOWNTO 0);
CLK : IN STD_LOGIC;
ENA : IN STD_LOGIC;
Q : OUT STD_LOGIC_VECTOR(1 DOWNTO 0);
-- for srff board
S : IN STD_LOGIC;
CLK2 : IN STD_LOGIC;
R : IN STD_LOGIC;
Q3 : OUT STD_LOGIC
);
END simple;

ARCHITECTURE bdf_type OF simple IS

-- for dff board
COMPONENT my_dffe
GENERIC
(
BUS_WIDTH : INTEGER
);
PORT
(
D : IN STD_LOGIC_VECTOR(BUS_WIDTH - 1 DOWNTO 0);
CLK : IN STD_LOGIC;
ENA : IN STD_LOGIC:= '1';
Q : OUT STD_LOGIC_VECTOR(BUS_WIDTH - 1 DOWNTO 0)
);
END COMPONENT;

-- for srff board
COMPONENT my_srffe
PORT(S : IN STD_LOGIC;
CLK : IN STD_LOGIC;
R : IN STD_LOGIC;
Q : OUT STD_LOGIC
);
END COMPONENT;

BEGIN

tagDFF: IF (board= dff_board) GENERATE
b2v_inst : my_dffe
GENERIC MAP
(
BUS_WIDTH => 2
)

PORT MAP(D => D,
CLK => CLK,
ENA => ENA,
Q => Q);
END GENERATE;

tagDFF: IF (board= srff_board) GENERATE
b2v_inst1 : my_srffe
PORT MAP(S => S,
CLK => CLK2,
R => R);
Q => Q3);
END GENERATE;

END bdf_type;

--- Quote End ---

as you can see in this simple project there are 2 kinds of board: one for DFF and the other for SRFF. the board type is defined by an external tcl script.
please show me how to write tcl that declares only the pins (and components) related to the current hardware.

thanks in advance

Ron

P.S
i'll try to get a hold on one of Brent Welch's books so I can study more on my own
Altera_Forum
Honored Contributor
14 years ago
Hi Ron,

--- Quote Start ---

I'll take you up on your offer :), please see this simple top level entity:

--- Quote End ---
Sure, I'll write some Tcl code.

Cheers,
Dave
Altera_Forum
Honored Contributor
14 years ago
Hi Ron,

Your example is a little too simple, in that it does not really show what we were discussing (its more like two completely separate designs). I was under the impression you had a design with a lot of common components, and then a few interfaces that needed to be different between boards.

I've attached some Tcl code (rename the file from _tcl.txt to .tcl). Source this in Quartus and it will generate two top-level entities. Not particularly exciting, but the Tcl constructs show you how to use loops over lists, printing into buffers, and then writing out to files.

The architecture bodies could be similarly generated.

You'll want to put the components you are using into a VHDL package file, that way you can just add "library mylib; use mylib.mypackage.all;", and the Tcl generator architecture section can just print out the VHDL you would normally write.

This may be enough for you to get started. If its not, send a project that actually has real components, synthesis constraints for two separate boards, etc.

Cheers,
Dave
example_tcl.txt3 KB
Altera_Forum
Honored Contributor
14 years ago
Hi Dave

thanks for the code, it's looks like tcl is much more powerful than I thought. I'll go over it. I also downloaded Brent Welch book draft from his personal site. It's not updated, but it's free :-P , and I believe it will be enough for me. (I work in a small company and we don't excatly have a library here)

you impression about my design was correct, but my boss wouldn't appreciate if I published source code on the web... I think my very simple code and your elaborate tcl will be enough to get me going.

just a technical question: how do I make Quartus run this script each time I switch revision \ run compilation? do I have to excute it manually from the tcl console, or can I call it from the qsf file?

thanks in advance
Altera_Forum
Honored Contributor
14 years ago
--- Quote Start ---
Hi Dave

just a technical question: how do I make Quartus run this script each time I switch revision \ run compilation? do I have to excute it manually from the tcl console, or can I call it from the qsf file?

--- Quote End ---

found my answer
http://www.altera.com/support/examples/tcl/auto_processing.html
Altera_Forum
Honored Contributor
14 years ago
--- Quote Start ---

you impression about my design was correct, but my boss wouldn't appreciate if I published source code on the web... I think my very simple code and your elaborate tcl will be enough to get me going.

--- Quote End ---
That is what I figured.

If you want to discuss your code off-list, just email me (via the email address that is my forum name).

Cheers,
Dave

Forum Discussion

assigning pins location to a component pin

16 Replies

Recent Discussions

Quartus 13.1 including Signal Tap License

I do not get an eMail with the generated license file

Installer cannot establish connection with SSL error

Quartus 20.1std compilation fails for Quartus map - Device 10AS057K2F40I1SG

Highlight similar instances of a selected word fails when scrolling