Re: Really Rusty in VHDL...

Discussion in 'VHDL' started by KJ, Mar 30, 2012.

  1. KJ

    KJ Guest

    On Thursday, March 29, 2012 12:17:35 PM UTC-4, Matthew Jeschke wrote:
    > 8 years ago I studied VHDL quite extensively in college.
    >
    > Now I've been hired by a small company as their resident expert and
    > I'm finding I have to relearn everything all over again... I'm sure
    > my mistakes are novice but I'm not even sure where to go for help.
    >
    > Attached below is what I've written and it has all sorts of issues
    > with it. It should be a simple 15 minute project but it's taken me
    > over a day and I'm getting frustrated lol Any feedback would be
    > greatly appreciated, I'm not sure where else to start. Are there any
    > good reference books you guys would recommend?


    - The "if rising_edge(clock)" must be the outermost statement
    - Don't use rising and falling edges (this is a digital design rule, not VHDL)

    Other than that, you never stated exactly what problem you're having so I'm not going to try to figure it out for you.

    Kevin Jennings
    KJ, Mar 30, 2012
    #1
    1. Advertising

  2. KJ

    Andy Guest

    On Mar 29, 8:39 pm, KJ <> wrote:
    >
    > - The "if rising_edge(clock)" must be the outermost statement
    > - Don't use rising and falling edges (this is a digital design rule, not VHDL)
    >
    > Other than that, you never stated exactly what problem you're having so I'm not going to try to figure it out for you.
    >
    > Kevin Jennings


    As long as the same variable/signal is not updated on two different
    clocks/edges, most synthesis tools worth using will accept a single
    process with both, as is the case here. Simulation does not care.

    Assuming this is a simulation model (inout data port), you need to
    define the output as (others => 'Z') when not performing a read. That
    will allow someone externally driving the data to control the value.
    Likewise, when they are not writing, they need to assign the signal
    with (others => 'Z').

    If this is intended to be a synthesizable component (e.g. in an FPGA
    or ASIC), then I strongly urge you not to use bidirectional inout mode
    ports unless this port is bound to a primary device level port, where
    tri-state logic is an option. Some synthesis tools will automatically
    transform internal tri-state drivers into multiplexers and decoders as
    required to implement the logical behavior of the bus.

    Also, if this is a synthesizable module, most FPGA BRAMs can have
    independent clocks, so I don't think that is an issue for this
    example, assuming your target is a BRAM. However, the output register
    on some FPGA BRAMs does not have a clock enable, so that could be an
    issue if you are not getting BRAMs inferred by the synthesis tool. In
    most cases, simply reading a BRAM has no side effect, so it should be
    no problem to remove the condition from the read, and simply always
    read it (not withstanding the inout port mode issues mentioned above).

    However, as KJ mentioned, the evaluation of the instr should be moved
    inside the rising/falling_edge sections. Since these are effectively
    clock enables, than can also be combined with their respective rising/
    falling_edge() statement (e.g. if rising_edge(clk) and instr = write
    then...)

    You do not need the other "elsif instr = ... then null; end if;
    statements in a clocked process.

    Ditto on not using std_logic_arith package(s). I would go one step
    further, and if this is not the device level interface, I would
    declare the addr port as unsigned(6 downto 0), since it will always
    have an unsigned numeric interpretation.

    As a side note, define the range of the page array index based on the
    range of the addr port (e.g. 2**addr'length - 1 downto 0) so the array
    and port sizes are forever linked together.

    Define the subtype for wordsize as positive so that errant values for
    the generic are caught as early and directly as possible.

    I strongly urge you to define constants for the different instr
    values, rather than relying upon comments and bit string literals.
    Meaningfully named constant definitions can be their own comments for
    the reader, with the added benefit that they are checked/enforced by
    the compiler. Assuming these values are used in different modules,
    define the constants in a package accessible to each module that reads
    or writes instr so that all are "singing the same hymn".

    Andy
    Andy, Apr 2, 2012
    #2
    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. Sam
    Replies:
    1
    Views:
    308
    Keith Thompson
    Sep 24, 2008
  2. M. Norton

    Rusty with Configurations

    M. Norton, Mar 16, 2010, in forum: VHDL
    Replies:
    9
    Views:
    681
    Martin Thompson
    Mar 23, 2010
  3. M. Norton
    Replies:
    7
    Views:
    585
  4. Tricky

    Re: Really Rusty in VHDL...

    Tricky, Mar 30, 2012, in forum: VHDL
    Replies:
    1
    Views:
    737
    MBodnar
    Mar 30, 2012
  5. Nicholas Paul Collin Gloucester

    Re: Really Rusty in VHDL...

    Nicholas Paul Collin Gloucester, Apr 6, 2012, in forum: VHDL
    Replies:
    0
    Views:
    782
    Nicholas Paul Collin Gloucester
    Apr 6, 2012
Loading...

Share This Page