«

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

"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

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