Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > VHDL design hierarchy, modules/componets and I/O pins

Reply
Thread Tools

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

 
 
Rafal Pietrak
Guest
Posts: n/a
 
      03-08-2006
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
 
Reply With Quote
 
 
 
 
Mike Treseler
Guest
Posts: n/a
 
      03-08-2006
Rafal Pietrak wrote:

> 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
 
Reply With Quote
 
 
 
 
Rafal Pietrak
Guest
Posts: n/a
 
      03-08-2006
On Wed, 08 Mar 2006 11:08:04 -0800, Mike Treseler wrote:
>
> 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
 
Reply With Quote
 
Mike Treseler
Guest
Posts: n/a
 
      03-08-2006
Rafal Pietrak wrote:

> 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
 
Reply With Quote
 
Weng Tianxiang
Guest
Posts: n/a
 
      03-09-2006
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

 
Reply With Quote
 
Weng Tianxiang
Guest
Posts: n/a
 
      03-09-2006
Sorry,

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

Weng

 
Reply With Quote
 
Rafal Pietrak
Guest
Posts: n/a
 
      03-09-2006
On Wed, 08 Mar 2006 18:46:14 -0800, Weng Tianxiang wrote:
> 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!

 
Reply With Quote
 
Weng Tianxiang
Guest
Posts: n/a
 
      03-09-2006
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

 
Reply With Quote
 
Rafal Pietrak
Guest
Posts: n/a
 
      03-09-2006
On Wed, 08 Mar 2006 18:49:27 -0800, Weng Tianxiang wrote:
> 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
 
Reply With Quote
 
Rafal Pietrak
Guest
Posts: n/a
 
      03-09-2006
On Wed, 08 Mar 2006 14:54:47 -0800, Mike Treseler wrote:
> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Any GSM J2ME phone with RS232 pins and bluetooth? fcassia Java 1 02-25-2011 01:33 PM
VHDL-2002 vs VHDL-93 vs VHDL-87? afd VHDL 1 03-23-2007 09:33 AM
Bidirectional bus and virtual pins Shannon Gomes VHDL 18 02-07-2007 11:09 PM
VHDL (Assigning pins in xilinx) amanpervaiz Hardware 3 12-02-2006 04:37 PM
Basic VHDL question regarding pins googlinggoogler@hotmail.com VHDL 1 07-07-2005 11:10 PM



Advertisments