Timothy Miller wrote:
>
> BTW, I see two good ways of doing the counters. First of all, for a
> counter of n bits, then when the counter is n, then bit n is set.
> That is, the register is (1<<n). As such, when the counter hits "0"
> (which is a value of 1), we want it to stop counting.
>
> There's this way:
>
> reg [15:0] counter;
> always @(posedge clock) begin
> ...
> counter <= counter[0] ? 1 : counter[15:1];
> ...
> end
>
> But here's another way that might be interesting:
>
> always @(posedge clock) begin
> ...
> counter <= counter | counter[15:1];
> ...
> end
That should be 'counter <= {1'b0,counter[15:1]}', I assume.
>
> The last one has the advantage of lower fan-out on the lowest bit, as
> well as being able to tell, for instance, if we're at most 4 cycles
> from hitting zero, then counter[4] will be set and stay that way.
>
> I prefer the latter.
I agree. It reminds me of the set-theoretic definition where every
number includes all previous numbers, e.g. 2 = {1, 0} = {{0}, 0} =
{{{}}, {}}, so x < y becomes x ∈ y. This is a bit different, but it
still make ordering operations simple:
max x y --> x | y
min x y --> x & y
x > c --> x[c], c known constant
x > y --> x & ~y != 0 (well, this one has logarithmic depth)
>
> You could compare the current counter value to what you want
> to set it to and leave it alone if it's already greater.
That's what I called a max-function... I'm just sloppy with the language.
> Why don't you have separate names for the different pieces of the
> request? If you do that, the synthesizer can produce better warnings
> if there is a size mismatch in instantiation. Then you don't need the
> functions, right?
>
>> [...]
>> // Stage 0
>> reg[req_width-1:0] s0_req;
>> always @(posedge clock) begin
>> if (!busy) begin
>> s0_req <= req;
>> end
>> end
>>
>> // Stage 1
>> reg[req_width-1:0] s1_req;
>
> Oh, I get it! You've made it gobs easier to pass the command properly
> down the pipeline. Interesting.
>
It probably wasn't worth it. I think I'll split up the request. As you
say, it's better to allow the synthesiser to check the widths.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
