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

Discussion in 'VHDL' started by Rafal Pietrak, Mar 8, 2006.

  1. 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
    Rafal Pietrak, Mar 8, 2006
    #1
    1. Advertising

  2. 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
    Mike Treseler, Mar 8, 2006
    #2
    1. Advertising

  3. 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
    Rafal Pietrak, Mar 8, 2006
    #3
  4. 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
    Mike Treseler, Mar 8, 2006
    #4
  5. 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, Mar 9, 2006
    #5
  6. Sorry,

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

    Weng
    Weng Tianxiang, Mar 9, 2006
    #6
  7. 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!
    Rafal Pietrak, Mar 9, 2006
    #7
  8. 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
    Weng Tianxiang, Mar 9, 2006
    #8
  9. 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
    Rafal Pietrak, Mar 9, 2006
    #9
  10. 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
    Rafal Pietrak, Mar 9, 2006
    #10
  11. Rafal Pietrak wrote:

    > 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
    Mike Treseler, Mar 9, 2006
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. ALuPin
    Replies:
    1
    Views:
    2,191
    Subroto Datta
    Apr 1, 2005
  2. Replies:
    1
    Views:
    577
    Eric Smith
    Jul 8, 2005
  3. Mircea Pleteriu

    .NET Componets

    Mircea Pleteriu, Aug 29, 2003, in forum: ASP .Net
    Replies:
    1
    Views:
    1,010
    Kevin Spencer
    Aug 29, 2003
  4. Shannon Gomes

    Bidirectional bus and virtual pins

    Shannon Gomes, Feb 3, 2007, in forum: VHDL
    Replies:
    18
    Views:
    1,387
  5. fcassia
    Replies:
    1
    Views:
    482
    Tom Anderson
    Feb 25, 2011
Loading...

Share This Page