Generate a pulse with a definite width

N

nba83

Guest
hi
is it a good practice to generate a pulse strobe in Verilog with this code
or do i need to write a fsm for such applications?
BoardConfigReceivedStrobe is set elsewhere in the process. for resettin
this signal after some delay, I used this code,I 'm skeptical that thi
code is not efficient
if(BoardConfigReceivedStrobe)
begin
DelayCounterBoardConfig<=DelayCounterBoardConfig+1;
if(DelayCounterBoardConfig>100)
begin
DelayCounterBoardConfig<=0;
BoardConfigReceivedStrobe<=0;
end
end

tnx in advanced for any comments
Neda

---------------------------------------
Posted through http://www.FPGARelated.com
 
On Monday, July 2, 2012 5:26:51 AM UTC-4, nba83 wrote:
hi
is it a good practice to generate a pulse strobe in Verilog with this code?
or do i need to write a fsm for such applications?
BoardConfigReceivedStrobe is set elsewhere in the process. for resetting
this signal after some delay, I used this code,I 'm skeptical that this
code is not efficient
if(BoardConfigReceivedStrobe)
begin
DelayCounterBoardConfig<=DelayCounterBoardConfig+1;
if(DelayCounterBoardConfig>100)
begin
DelayCounterBoardConfig<=0;
BoardConfigReceivedStrobe<=0;
end
end

tnx in advanced for any comments
Neda

---------------------------------------
Posted through http://www.FPGARelated.com
Click to expand...
For a fixed count value like you have a more efficient way of counting is usually an LFSR. Since a binary counter to 100 as you have now is not really that large to begin with it may not save you all that much.

Kevin Jennings
 
KJ wrote:
On Monday, July 2, 2012 5:26:51 AM UTC-4, nba83 wrote:
hi
is it a good practice to generate a pulse strobe in Verilog with this code?
or do i need to write a fsm for such applications?
BoardConfigReceivedStrobe is set elsewhere in the process. for resetting
this signal after some delay, I used this code,I 'm skeptical that this
code is not efficient
if(BoardConfigReceivedStrobe)
begin
DelayCounterBoardConfig<=DelayCounterBoardConfig+1;
if(DelayCounterBoardConfig>100)
begin
DelayCounterBoardConfig<=0;
BoardConfigReceivedStrobe<=0;
end
end

tnx in advanced for any comments
Neda

---------------------------------------
Posted through http://www.FPGARelated.com

For a fixed count value like you have a more efficient way of counting is usually an LFSR. Since a binary counter to 100 as you have now is not really that large to begin with it may not save you all that much.

Kevin Jennings
Click to expand...
The only thing that looks unnecessarily complex is the magnitude
comparison "> 100" instead of an equallity comparison like "== 101"
which should give the same results unless your counter increments
outside of the posted part of the logic.

-- Gabor
 
On Monday, July 2, 2012 3:32:21 PM UTC-4, Gabor wrote:
KJ wrote:
On Monday, July 2, 2012 5:26:51 AM UTC-4, nba83 wrote:
hi
is it a good practice to generate a pulse strobe in Verilog with this code?
or do i need to write a fsm for such applications?
BoardConfigReceivedStrobe is set elsewhere in the process. for resetting
this signal after some delay, I used this code,I 'm skeptical that this
code is not efficient
if(BoardConfigReceivedStrobe)
begin
DelayCounterBoardConfig<=DelayCounterBoardConfig+1;
if(DelayCounterBoardConfig>100)
begin
DelayCounterBoardConfig<=0;
BoardConfigReceivedStrobe<=0;
end
end

tnx in advanced for any comments
Neda

---------------------------------------
Posted through http://www.FPGARelated.com

For a fixed count value like you have a more efficient way of counting is usually an LFSR. Since a binary counter to 100 as you have now is not really that large to begin with it may not save you all that much.

Kevin Jennings

The only thing that looks unnecessarily complex is the magnitude
comparison "> 100" instead of an equallity comparison like "== 101"
which should give the same results unless your counter increments
outside of the posted part of the logic.
Click to expand...
Actually using > can result in less logic than =. Take for example >96. You would only need to compare to "11-----" (two bits) rather than the full seven bits. Not always less, but sometimes.

Kevin Jennings
 
On Mon, 02 Jul 2012 14:02:06 -0700, KJ wrote:

On Monday, July 2, 2012 3:32:21 PM UTC-4, Gabor wrote:
KJ wrote:
On Monday, July 2, 2012 5:26:51 AM UTC-4, nba83 wrote:
hi is it a good practice to generate a pulse strobe in Verilog with
this code?
or do i need to write a fsm for such applications?
BoardConfigReceivedStrobe is set elsewhere in the process. for
resetting this signal after some delay, I used this code,I 'm
skeptical that this code is not efficient
if(BoardConfigReceivedStrobe)
begin
DelayCounterBoardConfig<=DelayCounterBoardConfig
+1;
if(DelayCounterBoardConfig>100)
begin
DelayCounterBoardConfig<=0;
BoardConfigReceivedStrobe<=0;
end
end

tnx in advanced for any comments Neda

---------------------------------------
Posted through http://www.FPGARelated.com

For a fixed count value like you have a more efficient way of
counting is usually an LFSR. Since a binary counter to 100 as you
have now is not really that large to begin with it may not save you
all that much.

Kevin Jennings

The only thing that looks unnecessarily complex is the magnitude
comparison "> 100" instead of an equallity comparison like "== 101"
which should give the same results unless your counter increments
outside of the posted part of the logic.


Actually using > can result in less logic than =. Take for example >96.
You would only need to compare to "11-----" (two bits) rather than the
full seven bits. Not always less, but sometimes.

Kevin Jennings
Click to expand...
You mean >=96, of course.

I'm wondering if it wouldn't be faster to compare on zero, load with 100,
and count down.

--
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com
 
Tim Wescott wrote:
On Mon, 02 Jul 2012 14:02:06 -0700, KJ wrote:

On Monday, July 2, 2012 3:32:21 PM UTC-4, Gabor wrote:
KJ wrote:
On Monday, July 2, 2012 5:26:51 AM UTC-4, nba83 wrote:
hi is it a good practice to generate a pulse strobe in Verilog with
this code?
or do i need to write a fsm for such applications?
BoardConfigReceivedStrobe is set elsewhere in the process. for
resetting this signal after some delay, I used this code,I 'm
skeptical that this code is not efficient
if(BoardConfigReceivedStrobe)
begin
DelayCounterBoardConfig<=DelayCounterBoardConfig
+1;
if(DelayCounterBoardConfig>100)
begin
DelayCounterBoardConfig<=0;
BoardConfigReceivedStrobe<=0;
end
end

tnx in advanced for any comments Neda

---------------------------------------
Posted through http://www.FPGARelated.com
For a fixed count value like you have a more efficient way of
counting is usually an LFSR. Since a binary counter to 100 as you
have now is not really that large to begin with it may not save you
all that much.

Kevin Jennings
The only thing that looks unnecessarily complex is the magnitude
comparison "> 100" instead of an equallity comparison like "== 101"
which should give the same results unless your counter increments
outside of the posted part of the logic.


Actually using > can result in less logic than =. Take for example >96.
You would only need to compare to "11-----" (two bits) rather than the
full seven bits. Not always less, but sometimes.

Kevin Jennings

You mean >=96, of course.

I'm wondering if it wouldn't be faster to compare on zero, load with 100,
and count down.

Loading with a value and using the carry chain for compare (up or down)
Click to expand...
often works faster, but this is quite dependent on the architecture.
In a Xilinx FPGA, the carry chain logic is quite fast compared to
LUT's, but most CPLD's only care about how many product terms the
equation needs - equality comparison generally only needs one - and
that affects the size of the logic more than speed (you hit a speed
bump if you exceed the product terms you can have locally for a
single macrocell).

-- Gabor
 
I'm wondering if it wouldn't be faster to compare on zero, load with 100,
and count down.
Click to expand...

Don't compare at all.
Use a signed count value with one extra bit, start at N-2, count down,
and stop if highest bit is set (or reload in your case).

or do i need to write a fsm for such applications?
Click to expand...
Of course you do (and you did).
Anything involving a delay must have state (continous or discrete) and
if you can build it, it also is finite.

Kolja Sulimma
www.cronologic.de
 
Am 05.07.2012 17:37, schrieb Kolja Sulimma:
I'm wondering if it wouldn't be faster to compare on zero, load with 100,
and count down.


Don't compare at all.
Use a signed count value with one extra bit, start at N-2, count down,
and stop if highest bit is set (or reload in your case).
Click to expand...
In principle, this should not make a difference. The counter must
compare the lower bits anyway to decide whether to toggle the higher
bits.

Thomas
 
On Jul 6, 5:01 pm, Thomas Heller <thel...@ctypes.org> wrote:
Am 05.07.2012 17:37, schrieb Kolja Sulimma:



I'm wondering if it wouldn't be faster to compare on zero, load with 100,
and count down.

Don't compare at all.
Use a signed count value with one extra bit, start at N-2, count down,
and stop if highest bit is set (or reload in your case).

In principle, this should not make a difference.  The counter must
compare the lower bits anyway to decide whether to toggle the higher
bits.
Click to expand...
Exactly. And if you are smart you define the counter in a way that the
same adder can be used for both instead of using two adders.
(The solution described by my parent poster compares ==0 and <0 in the
same clock cycle. This needs two adders of N bits or registering of a
temporary result.
My proposal uses only one adder of N+1 bits.

Kolja
www.cronologic.de
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top