VHDL design hierarchy, modules/componets and I/O pins

[Rafal Pietrak]

Hi All!

Have started to learn VHDL quite recently and by now I'm building my first
'packaged' designs.... still in tutorial mode if I may say so.

.... and here comes a challenge (for me .

To focus on something concrete, let's say I build a microcontroller;
components are: ALU, register-file, some dedicated I/O pins, RAM, ROM and
external memory access controller.

I have all those components in separate files and appropriate Package file
to make a sort of library out of them.

Now the only way I've learned to create the whole design is to create an
encapsulating entity referring (instantiating) and interconnecting my
components. That's what I've found as examples my textbook and in the
internet.

The problem is, that according to those examples, the encapsulating entity
defines the whole design I/O list. But a design like this microcontroller,
have majority of its I/O pins coming from external memory access
subsystem... which in some instantiations (different target FPGA) may even
be missing at all.

My question is: what is the appropriate VHDL construct, that allows the
designer have his/her master entity ports (instantiated by synthesize
tools as device I/O pins) PROVIDED by *generated* instance of some other
modules within that entity? Like: one variant has 16-bit wide RAM port
provided by, say: SRAM.vhd; while another variant will have 128-bit wide
SDRAM provided by quite a different SDRAM.vhd module.

Is this possible at all?

-R

 

[Mike Treseler]

Now the only way I've learned to create the whole design is to create an
encapsulating entity referring (instantiating) and interconnecting my
components.

Yes. I prefer direct instances, but you can
do it with components.

The problem is, that according to those examples, the encapsulating entity
defines the whole design I/O list.

That's the way it is for a top entity.

But a design like this microcontroller,
have majority of its I/O pins coming from external memory access
subsystem... which in some instantiations (different target FPGA) may even
be missing at all.

The *pins* are a result of the entity port declarations,
*and* a driving and/or receiving assignment in top architecture scope.
Unreferenced ports will be deleted by synthesis.

My question is: what is the appropriate VHDL construct, that allows the
designer have his/her master entity ports (instantiated by synthesize
tools as device I/O pins) PROVIDED by *generated* instance of some other
modules within that entity?

Port drivers or users can be instanced, but not the top pins.

Like: one variant has 16-bit wide RAM port
provided by, say: SRAM.vhd; while another variant will have 128-bit wide
SDRAM provided by quite a different SDRAM.vhd module.

I use generic constants or separate top entities
to handle things like this.

-- Mike Treseler

 

[Rafal Pietrak]

Unreferenced ports will be deleted by synthesis.

Hmm, nice. I haven't thought of that.

.... but now, when I try to follow those lines and write:

-----------file with component xmem-----------
entity xmem is generic (CPU_WORD: natural := 8;
ADDR_SPACE: natural := 16; -- internal bus
MEM_WIDTH: natural := 16; MEM_SIZE: natural := 24);
ports (dbus: inout std_logic_vector(MEM_WIDTH-1 downto 0);
abus: out std_logic_vector(MEM_SIZE-1 downto 0);
internal: inout std_logic_vector(CPU_WORD-1 downto 0);
...);
end xmem;
---------file with library definition-------------
package my_library is
component xmem is generic (CPU_WORD: natural; ADDR_SPACE: natural;
MEM_WIDTH: natural; MEM_SIZE: natural);
ports (dbus: inout std_logic_vector(MEM_WIDTH-1 downto 0);
abus: out std_logic_vector(MEM_SIZE-1 downto 0);
internal: inout std_logic_vector(CPU_WORD-1 downto 0);
...);
end component;
end my_library;
------------master file with main entity-------------
entity cpu is generic (REG_SIZE: natural := 8;
XDATA: natural := 8; XADDR: natural := 12);
port (data: inout std_logic_vector(500 downto 0);
addr: out std_logic_vector(500 downto 0);
clk: in std_logic;
...);
end cpu;
architecture my of cpu is
begin
mem_instance: xmem generic map (CPU_WORD => REG_SIZE,
ADDR_SPACE => 2*REG_SIZE,
MEM_WIDTH => XDATA, MEM_SIZE => XADDR)
port map ( dbus => data(XDATA downto 0),
abus => addr(XADDR downto 0),
....);
end my;
======================================================
(I hope I haven't omitted anything critical form the source).

But I get "ERROR:Xst:751 -...: Bad association for formal port 'dbus' of
component 'xmem'" from Xilinx ISE-7.1 synthesizer.

Somehow, synthesizer didn't understood me, while my intention was:
1. instantiate XMEM component with its DBUS having XDATA wires.
2. connect 'lower' XDATA wires of DATA port-pins of entity CPU to the DBUS
wires of component XMEM (the exact number of DBUS wires, XMEM is
instantiated with).
3. have all the spurious XDATA up to nr.500 wires of DATA bus of CPU
entity purged by the synthesizer tool as 'not connected'.

Somehow, the fine plan didn't work. So I miss something vital. Can you
give me a hand here?

-R

 

[Mike Treseler]

But I get "ERROR:Xst:751 -...: Bad association for formal port 'dbus' of
component 'xmem'" from Xilinx ISE-7.1 synthesizer.

That's why I suggested a direct instance.

Somehow, synthesizer didn't understood me, while my intention was:

Don't even fire up synthesis until your simulation runs ok.

Somehow, the fine plan didn't work. So I miss something vital.

Yes. Simulation.

Can you give me a hand here?

No, but I would suggest that you find a simpler example
with a single entity and simple in and out ports to
learn simulation.

-- Mike Treseler

 

[Weng Tianxiang]

Hi,
Your problem is here:

XDATA: natural := 8 -- it is at the title
port map ( dbus => data(XDATA downto 0),

Your definition:
MEM_WIDTH: natural := 16
ports (dbus: inout std_logic_vector(MEM_WIDTH-1 downto 0);

Now you are assigning a 9-bit bus to a 17-bit bus.

Weng

 

[Weng Tianxiang]

Sorry,

Now you are assigning a 9-bit bus to a 16-bit bus.

Weng

 

[Rafal Pietrak]

Hi,
Your problem is here:

XDATA: natural := 8 -- it is at the title
port map ( dbus => data(XDATA downto 0),

Your definition:
MEM_WIDTH: natural := 16
ports (dbus: inout std_logic_vector(MEM_WIDTH-1 downto 0);

THENX!!!!!

Actually, the problem was, that I should write: "( dbus => data(XDATA-1
downto 0)," instead.

But while learning new things this late at night I rather thought, that
the design doesn't work because of VHDL limitations, not because of my
stupid misstypes (XDATA instead of XDATA-1).

Thenx again!

 

[Weng Tianxiang]

Hi,
Your opinion is wrong: "because of VHDL limitations".

VHDL can do everything an electronical engineer wants to do, that
situation
is limited only by your imagination, never limited by your talents.

Weng

 

[Rafal Pietrak]

Sorry,

Now you are assigning a 9-bit bus to a 16-bit bus.

Weng

Hmmm.... With the indicated correction, literally: XDATA --> XDATA-1, I
get:
1. the synthesize goes without a glitch.
2. resulting RTL-schematics looks 100% OK.

I will test it further making more exercises, sure. And I will build
similar circuits soon, but at first glance it looks like the construct
actually works and the VHDL source really creates what I've actually
intended.

-R

 

[Rafal Pietrak]

No, but I would suggest that you find a simpler example
with a single entity and simple in and out ports to
learn simulation.

Yes. There will come time for that.

But Mike. My current problem is, that even if I ran a simulation on the
project, and even if the simulation results would show, that the circuitry
is wrong, I wouldn't be able to correct the design, since I don't know how
to express my 'plan' to the executor - be it simulator or synthesizer. As
of today, I'm not VHDL 'speaker' (which I'd like to change). A good
example of this is a "Xilinx RAM block instanciation" post I've created a
few days ago - the design consists of just wires: two simple vectors of
those and signal concatenation. Nothing to simulate, while RTL-schematics
show, that one 'VHDL sentence' is understandable for a synthesizer, while
the other is not. Why? I don't know. Simulation would only show me what
RTL already did - the VHDL design is wrong. But why? I had to ask the
group.

So, when posting questions to the newsgroup, I try to resolve ambiguities
I have after 'quick-read' of a text book. You responses are invaluable. My
road through VHDL would be horribly painfull (or really require a tutor
without this group.

But I assure you, that I know what I'm doing regarding the learning path.
And I hope you'll spare your time taking a look at my subsequent posts
when I'll submit any ... I'll really appreciate that.

-R

 

[Mike Treseler]

Yes. There will come time for that.

When the time comes, here's a starting point:
http://groups.google.com/groups/search?q=shell+test_uart

But I assure you, that I know what I'm doing regarding the learning path.

Do whatever the prof says to get a good grade,
but it seem to have little to do with
learning vhdl.

-- Mike Treseler