Pixel output 0#4
Conversation
majorbonghits420
left a comment
majorbonghits420
left a comment
There was a problem hiding this comment.
Maybe it is away somewhere, but I also can't see where CLOCK_PIXEL is set. Fix you variable names since I talked to you about. Fix overflow issues.
|
|
||
| // laser output | ||
| reg [1:0] laser_intensity; | ||
| reg [8:0] pixel_column; // what pixel we are projecting now |
There was a problem hiding this comment.
Fix comment, just the column of the pixel does not indicate what pixel is being projected, just the column of it.
| // keep track of prev y axis position so we can reset the x axis when y axis changes lines | ||
| reg [7:0] y_axis_position_prev; | ||
| always @(posedge CLOCK_PIXEL) | ||
| y_axis_position_prev <= y_axis_position_prev; |
There was a problem hiding this comment.
Why are you setting a thing to itself?
| if (reset) begin | ||
| pixel_column <= 0; | ||
| end | ||
| else if (y_axis_position_prev != y_axis_position_prev) begin |
There was a problem hiding this comment.
This will never be true?
I assume something will always be equal to itself
|
|
||
| // assign the address and receive the pixel. | ||
| // The pixel will be two cycles delayed, but that is OK. | ||
| assign framebuffer_address = (y_axis_position * 640) + pixel_column; |
There was a problem hiding this comment.
This will always overflow.
There was a problem hiding this comment.
Wait nevermind, I'm not sure how large framebuffer_address, I assume it is large enough
Thought something was wrong because 640 is more than y_axis_position can hold, but multiplication should(?) still work
Though note that this will only get up the bottom [OUR_ROWS, OUR_COLS] of the framebuffer it looks like
There was a problem hiding this comment.
yeah I think its all good size wise. what is get up the bottom?
|
|
||
| always @(posedge CLOCK_PIXEL or posedge reset) begin | ||
| if (reset) begin | ||
| pixel_column <= 0; |
There was a problem hiding this comment.
Also want to reset y_axis_position?
There was a problem hiding this comment.
thats in the above state machine (line 359 at the time of authoring)
There was a problem hiding this comment.
But it is on a different clock
| // assign the address and receive the pixel. | ||
| // The pixel will be two cycles delayed, but that is OK. | ||
| assign framebuffer_address = (y_axis_position * 640) + pixel_column; | ||
| assign laser_intensity = (y_axis_state == y_axis_state_return) ? 0 : // blank on reset |
There was a problem hiding this comment.
We probably want it to be off in the reset state too
2 participants
Just take a look at that pixel output logic commit, the other one is machine generated.