Generate a pulse with a definite width

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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

Re: Generate a pulse with a definite width
Quoted text here. Click to load it

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

Re: Generate a pulse with a definite width
Quoted text here. Click to load it
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.
Quoted text here. Click to load it

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

Re: Generate a pulse with a definite width
Quoted text here. Click to load it
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.
Quoted text here. Click to load it

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

Re: Generate a pulse with a definite width

Quoted text here. Click to load it
+1;
Quoted text here. Click to load it
BoardConfigReceivedStrobe<=0;
Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: Generate a pulse with a definite width
Quoted text here. Click to load it
Loading with a value and using the carry chain for compare (up or down)
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

Re: Generate a pulse with a definite width


Quoted text here. Click to load it


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).

Quoted text here. Click to load it

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

Re: Generate a pulse with a definite width
Am 05.07.2012 17:37, schrieb Kolja Sulimma:
Quoted text here. Click to load it

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

Re: Generate a pulse with a definite width
Quoted text here. Click to load it

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 3D%3D0 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

Site Timeline