Beginner Question on State Machine and Components

Discussion in 'VHDL' started by Brad Smallridge, Oct 10, 2004.

  1. Help!

    I have a state machine on my top level for an SRAM controller. The states
    are sram_state_read, sram_state_write, sram_state_idle, and
    sram_state_reset. Presently the design is flat with no components. I want to
    put the SRAM paths in a component by itself. Since the SRAM state machine
    may influence other parts of the design, I want to have a separate component
    for it, or leave it in the top level. Now it seems to me that one should be
    able to pass these states down to to the SRAM paths' component using the
    type that I decleare on the top level. However I have been unable to find
    the syntax for doing this. I suppose I could "hard code" the states into
    known patterns of 1s and 0s and pass the the info into the component using
    std_logic_vector but this seems counter to high level language philosophy.
    Can anybody help?

    Thanks,
    Brad Smallridge
    b r a d @ a i v i s i o n. c o m
     
    Brad Smallridge, Oct 10, 2004
    #1
    1. Advertising

  2. Brad Smallridge wrote:
    > I have a state machine on my top level for an SRAM controller. The states
    > are sram_state_read, sram_state_write, sram_state_idle, and
    > sram_state_reset. Presently the design is flat with no components. I want
    > to
    > put the SRAM paths in a component by itself. Since the SRAM state machine
    > may influence other parts of the design, I want to have a separate
    > component for it, or leave it in the top level. Now it seems to me that
    > one should be able to pass these states down to to the SRAM paths'
    > component using the
    > type that I decleare on the top level. However I have been unable to find
    > the syntax for doing this. I suppose I could "hard code" the states into
    > known patterns of 1s and 0s and pass the the info into the component using
    > std_logic_vector but this seems counter to high level language philosophy.


    I assume you have these states defined in an enumerated type of some sort?
    Just define that type within a package, and use that package in both your
    FSM, and the level in which you wish to use that FSM. That way you can use
    the enumerated type within your entity/component declarations, and for any
    signals you want to use to connect that information from one unit to
    another.

    Regards,

    Pieter Hulshoff
     
    Pieter Hulshoff, Oct 10, 2004
    #2
    1. Advertising

  3. "Brad Smallridge" <> wrote in message news:<>...
    > Help!
    >
    > I have a state machine on my top level for an SRAM controller. The states
    > are sram_state_read, sram_state_write, sram_state_idle, and
    > sram_state_reset. Presently the design is flat with no components.


    What's wrong with that?
    Consider enlarging or adding processes
    until testing gets difficult. Unless you
    have more than one designer involved, I
    see no reason for multiple entities
    in an SRAM controller.

    > I want to
    > put the SRAM paths in a component by itself. Since the SRAM state machine
    > may influence other parts of the design, I want to have a separate component
    > for it, or leave it in the top level.


    Consider either a single level or
    a top entity with only wires and instances.

    > Now it seems to me that one should be
    > able to pass these states down to to the SRAM paths' component using the
    > type that I decleare on the top level. However I have been unable to find
    > the syntax for doing this. I suppose I could "hard code" the states into
    > known patterns of 1s and 0s and pass the the info into the component using
    > std_logic_vector but this seems counter to high level language philosophy.


    You can package constants to share, but
    consider shooting for a single entity.
    In VHDL synthesis code, the synchronous
    process is most cpu-like environment.
    You can put a lot into a single process and let
    synthesis work out the parallel blocks.

    If you like thinking in hardware,
    you can write lots of hardware-like
    entities and wire them up. Just don't
    expect any "high level language"
    feel to netlist style-code. Good luck.

    -- Mike Treseler
     
    Mike Treseler, Oct 10, 2004
    #3

  4. >> Presently the design is flat with no components.


    > What's wrong with that?


    That was my original style because I generally do think in hardware. I also
    use to work on Atmel chips and found that flat, macroless hardware was
    easier to control and understand. But I am learning VHDL for Xilinx now and
    would like to understand the workings of the language. And also learn how to
    simulate the components. The final design will be more than the SRAM
    controller.

    I have been able to write the package for this type definition. The Xilinx
    component/instantiation tool doesn't seem to understand type in the entities
    so one must write your own. Everything seems fine with the state machine
    however the synthesize tool seems to want to throw away my bidirection data
    ports.

    Thanks for the help.
     
    Brad Smallridge, Oct 11, 2004
    #4
  5. Brad Smallridge

    rickman Guest

    Brad Smallridge wrote:
    >
    > >> Presently the design is flat with no components.

    >
    > > What's wrong with that?

    >
    > That was my original style because I generally do think in hardware. I also
    > use to work on Atmel chips and found that flat, macroless hardware was
    > easier to control and understand. But I am learning VHDL for Xilinx now and
    > would like to understand the workings of the language. And also learn how to
    > simulate the components. The final design will be more than the SRAM
    > controller.
    >
    > I have been able to write the package for this type definition. The Xilinx
    > component/instantiation tool doesn't seem to understand type in the entities
    > so one must write your own. Everything seems fine with the state machine
    > however the synthesize tool seems to want to throw away my bidirection data
    > ports.


    I'm not sure why anyone would suggest that a flat design is better.
    Using instantiation of components is not hard to learn and is a good way
    to decompose a design so that you have independently testable and
    reusable modules.

    Did you get an answer to your question on how to pass the state machine
    signal through the heirarchy?

    I would suggest that you consider a tool of software design, information
    hiding. I typically think of a state machine as a black box with inputs
    and outputs and code my state machine module accordingly. This can be a
    bit messy since there can be a lot of signals to pass in and out. But
    all the decisions about how to construct and code the FSM are "hidden"
    in the module. No need to change any other modules if a detail of the
    FSM changes (like a bug fix).

    To handle the complexity that comes from a large number of outputs to
    other modules, I often define busses for control signals. They are just
    indexed slvs, but I use named constants as the indicies which gives me
    useful names to work with. Here is an example


    PORT (
    DatTopReg: IN DataPathSLV;
    DatSecReg: IN DataPathSLV;
    ALUCntlSel: IN ALUCntlSLV;
    SysClk: IN STD_LOGIC;
    Reset: IN STD_LOGIC;
    ALULogBus: OUT DataPathSLV;
    );
    END ALU;

    ARCHITECTURE behavior OF ALU IS

    constant DataWidth : integer := DATA_WIDTH;
    SUBTYPE AdderBus IS STD_LOGIC_VECTOR(DataWidth+1 DOWNTO 0);

    SIGNAL ALULogRes: DataPathSLV;

    BEGIN

    with ALUCntlSel(AluLogBit1 downto AluLogBit0) select
    ALULogRes <=
    DatSecReg AND DatTopReg when ALUAND,
    DatSecReg OR DatTopReg when ALUOR,
    DatSecReg XOR DatTopReg when ALUXOR,
    DatSecReg when ALUPASS,
    DataPathSLV'(others=>'X') when others;


    The control bus is ALUCntlSel and in this example is indexed with
    AluLogBit1 and AluLogBit0. In the module with the FSM that assigns
    these values, I use named constants to assign all 7 bits in the bus at
    once... very tidy. The control module has some 8 or 9 of these
    control/input busses. This is much cleaner than the dozens of
    individual signals it would otherwise require.

    --

    Rick "rickman" Collins


    Ignore the reply address. To email me use the above address with the XY
    removed.

    Arius - A Signal Processing Solutions Company
    Specializing in DSP and FPGA design URL http://www.arius.com
    4 King Ave 301-682-7772 Voice
    Frederick, MD 21701-3110 301-682-7666 FAX
     
    rickman, Oct 11, 2004
    #5
  6. rickman wrote:

    > I'm not sure why anyone would suggest that a flat design is better.


    Not better. Just an alternative that should
    not be immediately ruled out for a simple design.

    -- Mike Treseler
     
    Mike Treseler, Oct 12, 2004
    #6
    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. David Lamb
    Replies:
    1
    Views:
    683
  2. Weng Tianxiang
    Replies:
    7
    Views:
    1,112
    Mike Treseler
    Nov 25, 2003
  3. Mickey Segal
    Replies:
    0
    Views:
    899
    Mickey Segal
    Feb 2, 2004
  4. Grumps
    Replies:
    2
    Views:
    691
    Grumps
    Feb 13, 2008
  5. fenster
    Replies:
    3
    Views:
    1,164
    jeppe
    Dec 23, 2011
Loading...

Share This Page