Request Help - Non-blocking read-write problem

Sun Aug 01, 2010 10:35 am   

Could some Verilog guru please help ? I am using structural Verilog to
design a serial-parallel converter. The special characteristic of
incoming serial bits is that it is its own clock. That is when the
signal is high, it represents logic '1' and vice-versa. I am using non-
blocking assignment in the shift register. The problem is that
although the test harness is generating the appropriate sequence of 1s
and 0s (tested with '$display(.....)' ) the register always contains
zeros. I am using non-blocking assignment to shift the bits in the
shift register. I am not sure what exactly the problem might be. I
have attached the source for reference, and I am using Icarus Verilog
0.9.1.
Any hints, suggestions would be of immense help.

`timescale 1ns/1ns

module shiftregister(clk, pls_data_req,
txd0, txd1, txd2, txd3,
txd4, txd5, txd6, txd7);
parameter MAX = 64;
parameter BLANK64 =
64'b0000000000000000000000000000000000000000000000000000000000000000;
parameter BLANK8 = 8'b00000000;
parameter PERIOD = 1;

input clk;
input pls_data_req;
output [7:0] txd0;
output [7:0] txd1;
output [7:0] txd2;
output [7:0] txd3;
output [7:0] txd4;
output [7:0] txd5;
output [7:0] txd6;
output [7:0] txd7;

reg [7:0] txd0;
reg [7:0] txd1;
reg [7:0] txd2;
reg [7:0] txd3;
reg [7:0] txd4;
reg [7:0] txd5;
reg [7:0] txd6;
reg [7:0] txd7;

reg [63:0] q;
reg [63:0] qtmp;
integer count;

initial
begin
q = BLANK64;
qtmp = BLANK64;
txd0 = BLANK8;
txd1 = BLANK8;
txd2 = BLANK8;
txd3 = BLANK8;
txd4 = BLANK8;
txd6 = BLANK8;
txd7 = BLANK8;
count = 0;
end

always
#(PERIOD)
begin
if(count < MAX)
begin
$display("%b",pls_data_req);
q[0] <= pls_data_req;
q[1] <= q[0];
q[4] <= q[3];
q[5] <= q[4];
q[6] <= q[5];
q[7] <= q[6];
q[8] <= q[7];
q[9] <= q[8];
q[10] <= q[9];
q[11] <= q[10];
q[12] <= q[11];
q[13] <= q[12];
q[14] <= q[13];
q[15] <= q[14];
q[16] <= q[15];
q[17] <= q[16];
q[18] <= q[17];
q[19] <= q[18];
q[20] <= q[19];
q[21] <= q[20];
q[22] <= q[21];
q[23] <= q[22];
q[24] <= q[23];
q[25] <= q[24];
q[26] <= q[25];
q[27] <= q[26];
q[28] <= q[27];
q[29] <= q[28];
q[30] <= q[29];
q[31] <= q[30];
q[32] <= q[31];
q[33] <= q[32];
q[34] <= q[33];
q[35] <= q[34];
q[36] <= q[35];
q[37] <= q[36];
q[38] <= q[37];
q[39] <= q[38];
q[40] <= q[39];
q[41] <= q[40];
q[42] <= q[41];
q[43] <= q[42];
q[44] <= q[43];
q[45] <= q[44];
q[46] <= q[45];
q[47] <= q[46];
q[48] <= q[47];
q[49] <= q[48];
q[50] <= q[49];
q[51] <= q[50];
q[52] <= q[51];
q[53] <= q[52];
q[54] <= q[53];
q[55] <= q[54];
q[56] <= q[55];
q[57] <= q[56];
q[58] <= q[57];
q[59] <= q[58];
q[60] <= q[59];
q[61] <= q[60];
q[62] <= q[61];
q[63] <= q[62];
count = count + 1;
end
else if(count == MAX)
begin
$display("%b", q);
count = 0;
qtmp <= q;
q <= BLANK64;
fork
txd0 <= qtmp[7:0];
txd1 <= qtmp[15:8];
txd2 <= qtmp[23:16];
txd3 <= qtmp[31:24];
txd4 <= qtmp[39:32];
txd5 <= qtmp[47:40];
txd6 <= qtmp[55:48];
txd7 <= qtmp[63:56];
join
qtmp <= BLANK64;
/*
$display("txd0=%b txd1=%b txd2=%b txd3=%b txd4=%b txd5=%b txd6=%b
txd7=%b", txd0, txd1, txd2, txd3, txd4, txd5, txd6, txd7);*/
end
end

endmodule

Sun Aug 01, 2010 5:45 pm   

"Daku" <dakupoto_at_gmail.com> wrote in message
news:1b530234-9173-423d-b47e-17207e28d323_at_g21g2000prn.googlegroups.com...

Where do you set q[2] and q[3], if al all?

Where do you make clk actually do anything other
than appearing in the inputs list? I'd recommend
edge-triggering on it.

Robert Miles

Sun Aug 01, 2010 6:48 pm   

On Aug 1, 3:35 am, Daku <dakup...@gmail.com> wrote:

Isn't this the same problem you were trying to address earlier? Your
code now has an external clock - a great first step - but you're not
using the clock internally at all.

If you read up on how a UART works, you'll note that the UART uses a
local clock to extract the data from the incoming stream within an
expected frequency range. You cannot recover an unencoded NRZ data
stream with a frequency range from DC to daylight. You need to know
what the approximate frequency range or ranges may be and design to
recover the data knowing that your bit period should be relatively
constant. Depending on the coding (or lack thereof) you may need to
reevaluate the frequency after the decode of the first bits is
attempted.

Good luck - it sounds like you don't understand the fundamentals of
the problem you're trying to solve yet. Figure that out first and you
may be on better footing.

Mon Aug 02, 2010 3:58 pm   

On Aug 1, 9:45 pm, "Robert Miles" <mile...@usenet-news.net> wrote:


I have already tried
always @ (posedge clk)
begin
.....
end

and
always @ (negedge clk)
begin
.....
end

In both cases data is recovered, but sometimes
bits get displaced e.g., 10101110 instead of
10101011. Using $display statements in the test
harness, I know the exact sequence of bits being
sent out. I do not know what exactly is causing
this bit displacement.

Tue Aug 03, 2010 1:15 am   

"Daku" <dakupoto_at_gmail.com> wrote in message
news:ca4eb274-529b-4ad0-9835-fa9ded015390_at_g6g2000pro.googlegroups.com...

close to the clock edge that sometimes one occurs
first, and sometimes the other?

Robert Miles