passing status register bits

[Marco]

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

 

[KJ]

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

 

[Mike Treseler]

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]

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]

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

Marco



Marco ha scritto:

 

[Mike Treseler]

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

 

[KJ]

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