passing status register bits

Discussion in 'VHDL' started by Marco, Aug 10, 2006.

  1. Marco

    Marco Guest

    Hi all,

    after some time spent in many other jobs, now it seems I have the
    opportunity to work on my vhdl project, so here's a question for you...
    in an older post
    (http://groups.google.com/group/comp.lang.vhdl/browse_thread/thread/
    ce626188d09ba630/8e89407cff5ed51a?lnk=gst&q=&rnum=9&hl=en#8e89407cff5ed51a)
    I asked you about variables scope in order to understand a good way to
    pass some bits of a status register located in the top most entity down
    to each lower level entity that may need those signals. I've been told
    that there's no way to declare something as "global", as each
    synthetizer has it own way to handle it. Mike and others suggested to
    use a single process or to pass those signals as ports on each
    sub-entity. I was considering as first option, fitting it better within
    my design, the latter one, but here's my doubt. If I need a sub-entity
    to both read and write some of those bits of the register I need to
    declare them as "INOUT" ports, but this way if I want to read them I
    can't as I can't read outputs, so I have to use also a "local" signal
    to which I assign the value of the INOUT signal asynchronously, then I
    read it. This should work, but it seems not an nice approach to me,
    what do you think, is it common to do so?

    Thanks,
    Marco
     
    Marco, Aug 10, 2006
    #1
    1. Advertising

  2. Marco

    KJ Guest

    > I asked you about variables scope in order to understand a good way to
    > pass some bits of a status register located in the top most entity down
    > to each lower level entity that may need those signals.


    Presumably these status bits though begin life down inside the design and
    have to propogate 'up' through the design in the first place in order to
    make it to the top level in order for them to be pushed down to lower
    levels. This is just a comment for now, but will come into play further
    down the post.

    > I've been told
    > that there's no way to declare something as "global", as each
    > synthetizer has it own way to handle it.


    Tis generally true yes.

    > Mike and others suggested to
    > use a single process or to pass those signals as ports on each
    > sub-entity. I was considering as first option, fitting it better within
    > my design, the latter one, but here's my doubt. If I need a sub-entity
    > to both read and write some of those bits of the register I need to
    > declare them as "INOUT" ports,


    Back up and think first why an entity would need to drive as output what you
    first declared as being a status bit that was being passed down through the
    design. Since they are 'status' bits to these lower levels they should only
    be used as inputs. What I'm guessing is that the time you run into this
    situation is when you hit the entity that is actually generating the status
    bit in the first place (see my very first comment about how is the status
    bit getting to the top in the first place).

    If that is the case, then the 'solution' is to just sort of 'forget' about
    the fact that this entity is generating the status bit and treat the
    received status bit as if it was something totally different that is just
    passing through. This simply implies that the 'input' status bit has a
    different signal name than the 'output' status bit.

    > but this way if I want to read them I
    > can't as I can't read outputs, so I have to use also a "local" signal
    > to which I assign the value of the INOUT signal asynchronously, then I
    > read it. This should work, but it seems not an nice approach to me,
    > what do you think, is it common to do so?


    See previous paragraphs, pretend that you don't 'know' that the top level
    entity will be tying the status bit output of the entity back to the input
    of the entity on another signal name. That way you avoid the inouts and the
    resulting confusion and simply treat the 'passing through' status bits as
    inputs as they should be.

    KJ
     
    KJ, Aug 10, 2006
    #2
    1. Advertising

  3. Marco wrote:
    > If I need a sub-entity
    > to both read and write some of those bits of the register I need to
    > declare them as "INOUT" ports, but this way if I want to read them I
    > can't as I can't read outputs, so I have to use also a "local" signal
    > to which I assign the value of the INOUT signal asynchronously, then I
    > read it. This should work, but it seems not an nice approach to me,
    > what do you think, is it common to do so?


    No.

    I would recommend *not* collecting status registers
    registers in the top entity -- just the tristate buffers.
    Use a local bus on sub-entities as in the reference design ports:
    address : in std_ulogic;
    writeData : in std_logic_vector(char_len_c-1 downto 0);
    write_stb : in std_ulogic;
    readData : out std_logic_vector(char_len_c-1 downto 0);
    read_stb : in std_ulogic;

    Infer status registers right
    in the process where they are used.

    My reference design shows an example where the
    control and status registers and all users of
    these registers are in the same process.
    In this case, no signals other than the
    bus ports are needed.

    A status or control bit is a register output
    that is memory-mapped to a bus address and packed in
    a specific bit position; read for status, write for control.

    Search for read_data_v(0) here:
    http://home.comcast.net/~mike_treseler/uart.vhd
    for the hardware description of a memory mapped status flag.
    See uart_pkg in the same file for the register
    bit and address assignments.

    Search for valid_handshake_c here:
    http://home.comcast.net/~mike_treseler/test_uart.vhd
    to see how this flag is used in a simulated read cycle.

    -- Mike Treseler
     
    Mike Treseler, Aug 10, 2006
    #3
  4. Marco

    Marco Guest

    Hi Mike,

    I looked both your code and Ian's, then I started writing down the code
    of my application the same way, using variables inside the same process
    and procedures if needed.
    The problem now is that in my project I have to deal with a DSp and a
    temp sensor, both with spi-like serial communication, but with
    different rate and being the master with respect to the temp sensor and
    the slave with respect to the DSP (that sends its own clock). In this
    situation I can no longer use a common, top-level, process moved by the
    fpga_sys_clock, because I have 3 clock domains and maybe in the future
    they become even more if other components will be connected to the
    FPGA.
    What I've done to keep using a variable approach is to declare in the
    architecture of the top level entity some shared varaiables, in order
    to let them being seen from every process (one on each clock domain),
    but I'd like to hear what kind of drawback I could be moving to coding
    this way.

    Thanks,
    Marco



    Mike Treseler ha scritto:

    > Marco wrote:
    > > If I need a sub-entity
    > > to both read and write some of those bits of the register I need to
    > > declare them as "INOUT" ports, but this way if I want to read them I
    > > can't as I can't read outputs, so I have to use also a "local" signal
    > > to which I assign the value of the INOUT signal asynchronously, then I
    > > read it. This should work, but it seems not an nice approach to me,
    > > what do you think, is it common to do so?

    >
    > No.
    >
    > I would recommend *not* collecting status registers
    > registers in the top entity -- just the tristate buffers.
    > Use a local bus on sub-entities as in the reference design ports:
    > address : in std_ulogic;
    > writeData : in std_logic_vector(char_len_c-1 downto 0);
    > write_stb : in std_ulogic;
    > readData : out std_logic_vector(char_len_c-1 downto 0);
    > read_stb : in std_ulogic;
    >
    > Infer status registers right
    > in the process where they are used.
    >
    > My reference design shows an example where the
    > control and status registers and all users of
    > these registers are in the same process.
    > In this case, no signals other than the
    > bus ports are needed.
    >
    > A status or control bit is a register output
    > that is memory-mapped to a bus address and packed in
    > a specific bit position; read for status, write for control.
    >
    > Search for read_data_v(0) here:
    > http://home.comcast.net/~mike_treseler/uart.vhd
    > for the hardware description of a memory mapped status flag.
    > See uart_pkg in the same file for the register
    > bit and address assignments.
    >
    > Search for valid_handshake_c here:
    > http://home.comcast.net/~mike_treseler/test_uart.vhd
    > to see how this flag is used in a simulated read cycle.
    >
    > -- Mike Treseler
     
    Marco, Aug 25, 2006
    #4
  5. Marco

    Marco Guest

    A single top process with all the 3 clock domains in its sensitivity
    list?

    Marco



    Marco ha scritto:

    > Hi Mike,
    >
    > I looked both your code and Ian's, then I started writing down the code
    > of my application the same way, using variables inside the same process
    > and procedures if needed.
    > The problem now is that in my project I have to deal with a DSp and a
    > temp sensor, both with spi-like serial communication, but with
    > different rate and being the master with respect to the temp sensor and
    > the slave with respect to the DSP (that sends its own clock). In this
    > situation I can no longer use a common, top-level, process moved by the
    > fpga_sys_clock, because I have 3 clock domains and maybe in the future
    > they become even more if other components will be connected to the
    > FPGA.
    > What I've done to keep using a variable approach is to declare in the
    > architecture of the top level entity some shared varaiables, in order
    > to let them being seen from every process (one on each clock domain),
    > but I'd like to hear what kind of drawback I could be moving to coding
    > this way.
    >
    > Thanks,
    > Marco
    >
    >
    >
    > Mike Treseler ha scritto:
    >
    > > Marco wrote:
    > > > If I need a sub-entity
    > > > to both read and write some of those bits of the register I need to
    > > > declare them as "INOUT" ports, but this way if I want to read them I
    > > > can't as I can't read outputs, so I have to use also a "local" signal
    > > > to which I assign the value of the INOUT signal asynchronously, then I
    > > > read it. This should work, but it seems not an nice approach to me,
    > > > what do you think, is it common to do so?

    > >
    > > No.
    > >
    > > I would recommend *not* collecting status registers
    > > registers in the top entity -- just the tristate buffers.
    > > Use a local bus on sub-entities as in the reference design ports:
    > > address : in std_ulogic;
    > > writeData : in std_logic_vector(char_len_c-1 downto 0);
    > > write_stb : in std_ulogic;
    > > readData : out std_logic_vector(char_len_c-1 downto 0);
    > > read_stb : in std_ulogic;
    > >
    > > Infer status registers right
    > > in the process where they are used.
    > >
    > > My reference design shows an example where the
    > > control and status registers and all users of
    > > these registers are in the same process.
    > > In this case, no signals other than the
    > > bus ports are needed.
    > >
    > > A status or control bit is a register output
    > > that is memory-mapped to a bus address and packed in
    > > a specific bit position; read for status, write for control.
    > >
    > > Search for read_data_v(0) here:
    > > http://home.comcast.net/~mike_treseler/uart.vhd
    > > for the hardware description of a memory mapped status flag.
    > > See uart_pkg in the same file for the register
    > > bit and address assignments.
    > >
    > > Search for valid_handshake_c here:
    > > http://home.comcast.net/~mike_treseler/test_uart.vhd
    > > to see how this flag is used in a simulated read cycle.
    > >
    > > -- Mike Treseler
     
    Marco, Aug 25, 2006
    #5
  6. Marco wrote:

    > The problem now is that in my project I have to deal with a DSp and a
    > temp sensor, both with spi-like serial communication, but with
    > different rate.


    Single process implies a single clock.
    If a pulse from other clock domain
    is wider than a clock period it can be
    resynchronized procedurally as shown
    in procedure retime.

    > What I've done to keep using a variable approach is to declare in the
    > architecture of the top level entity some shared varaiables, in order
    > to let them being seen from every process (one on each clock domain),
    > but I'd like to hear what kind of drawback I could be moving to coding
    > this way.


    It won't synthesize this way.

    If you need to describe logic
    in a different clock domain, make
    a second single process entity.


    -- Mike Treseler
     
    Mike Treseler, Aug 25, 2006
    #6
  7. Marco

    KJ Guest

    > What I've done to keep using a variable approach is to declare in the
    > architecture of the top level entity some shared varaiables, in order
    > to let them being seen from every process (one on each clock domain),
    > but I'd like to hear what kind of drawback I could be moving to coding
    > this way.


    One drawback is that your design most likely will not work in a real
    system. The 'shared' variable will still be created in only a single
    clock domain (at best...at worst it will be a combination of all which
    would be yet another clock domain) and will likely not be synchronized
    correctly for use in any of the other processes outside that
    domain....unless the only thing being implemented in those other clock
    domains is a shift register and nothing else.

    KJ
     
    KJ, Aug 25, 2006
    #7
    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. GGG
    Replies:
    10
    Views:
    12,698
    Donar
    Jul 6, 2006
  2. sarmin kho
    Replies:
    2
    Views:
    847
    A. Lloyd Flanagan
    Jun 15, 2004
  3. Miki Tebeka
    Replies:
    1
    Views:
    455
    Marcin 'Qrczak' Kowalczyk
    Jun 14, 2004
  4. sergey

    "casting" bits to bits?

    sergey, Nov 8, 2006, in forum: VHDL
    Replies:
    1
    Views:
    740
    sergey
    Nov 8, 2006
  5. Replies:
    12
    Views:
    605
Loading...

Share This Page