initialisation of controller

F

feng

Guest
Hi,
Assume i have a counter which i want to set to 0 at the first clock
edge. For this, i set its value to the maximum during the reset phase,
i.e.

if reset='1' then
counter_int<="1111"
elsif rising_edge(clk) then,,,

hence at the first clock edge, it turns to zero. Likewise, if i have
two cascaded blocks: block1 and block2 with . a counter in block2.
The counter should start at a certain value when block1 starts
generating meaningful data. To set the counter accordingly at this
starting value, i compute the time to generate block1 data in terms
of number of cycles. By using the counter period, i deduce the initial
value of the counter at the reset phase. Similar code to the above is
then written. my whole architecture is pipelined and fed with
continous stream of data frames

Would you recommend this approach? Any comments about its pros and
cons? I understand that we can use a sort of handshaking between
block1 and block2. For this a dedicate signal needs to be generated,
which requires logic and might descrease the speed of the architecture
[its path to block2 might be long]. that's why i use the above
approach. Regardless this signal might need to be initialised as well

Thank you
 
On Feb 24, 8:40 pm, feng <xu_feng...@yahoo.com> wrote:
Hi,
Assume i have  a counter which i want to set to 0 at the first clock
edge. For this, i set its value to the maximum during the reset phase,
i.e.

if reset='1' then
counter_int<="1111"
elsif rising_edge(clk) then,,,

hence at the first clock edge, it turns to zero. Likewise, if i have
two cascaded blocks: block1 and block2 with .  a counter in block2.
The counter should start at a certain value when block1 starts
generating meaningful data. To set the counter accordingly at this
starting value, i  compute the time to generate block1 data in terms
of number of cycles. By using the counter period, i deduce the initial
value of the counter at the reset phase. Similar code to the above is
then written. my whole architecture is pipelined and fed with
continous stream of data frames

Would you recommend this approach? Any comments about its pros and
cons? I understand that we can use a sort of handshaking between
block1 and block2. For this a dedicate  signal needs to be generated,
which requires logic and might descrease the speed of the architecture
[its path to block2 might be long]. that's why i use the above
approach. Regardless this signal might need to be initialised as well

Thank you
Click to expand...
How can we know how to advise you? We know nothing of your design and
have no idea what your trade offs are. It sounds like you do know
exactly what you want. What are you looking for in the way of
advice?

Rick
 
Thank you Rickman for your answer. I wanted to know which design
approach is better and safer if the architecture prototyped in real
hardware. The simulation of my design works fine but i am afraid it
won't work on real hardware with the first approach, i.e. relying on
the initial reset pulse to set the registers accordingly.
 
feng <xu_feng_xu@yahoo.com> writes:

The simulation of my design works fine but i am afraid it
won't work on real hardware with the first approach, i.e. relying on
the initial reset pulse to set the registers accordingly.

In order for this to have any chance of working, you also need to make
Click to expand...
sure that you deassert the reset pulse with adequate setup time before
the clock edge so that you do not cause a race condition. A race could
occur when the reset is turned off very close to the clock. some of the
counter bits might take their "new state " 0 value, while the others
keep their "reset state" 1 value, causing your counter to come out of
reset with an undefined value. If your two blocks use different clocks
you must of course satisfy this timing requirement for both
simultaneously.

This is the kind of thing that simulation will typically not find, since
(1) people are generally not twisted enough to try to throw bad timing
at the design in simulation, and (2) a high level behavioural sim won't
typically exhibit the same failure modes as the hardware because it's
not modelling prop delays the same way.

HTH,

- Kenn
 
Feng,

What Kenn said: Make sure you asynchronously assert and synchronously
deassert (and meta-reject) the asynchronous reset signal before you
distribute it to the reset of the design.

I may be paranoid, but I usually try to initialize up counters to even
values, and down counters to odd values, or so that only the LSB is in
question coming out of reset. Or I make sure the counter is not
enabled (or I don't care about its value) on the first clock out of
reset (this is often the case).

plus:

Why do you think comparing a counter to a value will take less time
than a handshake signal? Maybe it would, but maybe it would not. Maybe
it wouldn't matter anyway (highly likely), in which case I would
prefer the more robust and flexible handshake implementation (see
below).

I'm not certain I followed all of your explanation, but it seems to me
that coding information in block 2 that is dependent upon the latency
of block 1 may not be a good idea, unless you have a really good idea
that block 1 latency will not change over the course of the design.

Andy
 
Many thanks for your replies. Andy, thank you for the tip re. the
asynchronous assertion and synchronous de-assertion. It is extremely
helpful.
Regarding the second part of my question. I am undecided about the
best way to set a counter/controller on a particular value/state
starting from the J th clock cycle of the actual operation of my
architecture.

To simulate my design, I am setting the reset and clock signals as
follows:
Reset pulse high from 0 to 10 ns. The clock period is 20 ns. The
first rising edge of the clock happens at instant 20 ns.

If a counter should have the value zero at the J th clock and
assuming the counter period is P, I set the counter value to
P-(J mod P) during the main reset pulse. For instance if J=15 and P=4,
then the initial value of the counter during the reset is
4-(15 mod 4)=4-3=1.
This can be extended to the case where we have cascaded blocks where
the latency of the blocks are fix and known. If the second block has
any counter which should be at the value zero at the first valid
output from block 1, i set the value of this counter during the reset
pulse as explained above. With this, I don’t need to create any logic
for the handshaking signal with all its routing path which might lower
the speed of the final architecture.

Would you recommend such approach or will it be better to use the
inverse of the reset signal as the enable signal for my whole
architecture. Furthermore, a counter is used to generate the carry out
pulse at the (J-1) clock cycle. This pulse will be used to reset
synchronously my counter in the second block. However this signal
should be routed from block1 to block 2. As such pipeline registered
might be needed which depending on its delay might lead us to generate
the carry out pulse at a different clock cycles than J-1

I hope I have explained my problem clearer. in nutshell, what is the
best option to force a state machine to be on a particular state S at
the clock cycle J? Could we just deduce the initial value during the
reset pulse or instead synchronously setting the state machine by
using the reset pulse along with a counter?

Aside from this what about the GSR signal? Should we not rely on it?
 
My preference is for handshaking, since if the latency of a block
changes, I can take care of that right there in the same block that
changed.

I don't know if you can synchronize the deasserting edge of the GSR
without synchronizing the asserting edge also. Which may be fine, but
it won't work if the clock fails (just beware if that is an issue).
The skew across the chip on GSR is typically quite large, so it may
not work for you depending upon your clock speed. I typically code the
reset in vhdl, and let the synthesis tool figure out how to distribute
it from the synchronization/meta-rejection module, and have not looked
at how it was routed in a while.

Another method of trying to make sure everything starts up on the same
clock is to have a single counter that starts counting after reset,
then when it reaches a predetermined count, enable a global clock
enable to every flop on that clock. Since this clock enable is one
more thing to plumb to every module, I usually do not do this, but it
does work.

Andy
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top