Prev: Does Xilinx Spartan 6 support NAND flash?
Next: VIRTEX5 (XUPV5-LX110T) Ethernet
From: Vips on 15 Jun 2010 06:55
Hi All

I am designing a module and I am having some issues .. Let me explain
what I am doing.

I am getting data as 64 bytes in each clock cycle . In these 64 bytes
I look for sync bits which is "01" and then a fixed pattern of "1111"
for the start of the frame . The next byte tells us the length of the
payload . Now the minimum payload could be of 4 byes so there is a
chance that in the current 64 bytes we can have multiple short frames
of 4 bytes and henceforth we can have many start and stop bytes .

Once we have detected a sync and the start of frame pattern then we
have to make sure it is not mistakingly taking the patter in the
payload as the start of the frma e again .

I have made a loop that goes 63 downto 0 and looks for each byte for
sync and start bit pattern

if it finds the sync and the start fame pattern then i am using a flag
to make sure it is not mistakingly taking the pattern in the payload
as the another start frame once it has detected the start of the frame
and sync successfully.

Solution : I have made a counter that runs inside the loop (63 down to
0) and it is 13 bits wide ( as there could be 8192 max payload)

so once the count length is equal to payload length I am disabling the
flag to allow it to go into detection of sync and start of the frame.

Problem: The problem is that whe i am using a 13 bit counter inside a
loop that goes 64 iterations makes a very large HW during syntheis .

Can you provide a solution to this problem as i would be able to
detect smallest payload ( 4 bytes in this case) as well as max payload
bytes in an efficient way.

I will really appreciate you help in this regard.


Regards

Vips
From: Gabor on 15 Jun 2010 10:54
On Jun 15, 6:55 am, Vips <thevipulsi...(a)gmail.com> wrote:
> Hi All
>
> I am designing a module and I am having some issues .. Let me explain
> what  I am doing.
>
> I am getting  data as 64 bytes in each clock cycle . In these 64 bytes
> I look for sync bits which is "01" and then a fixed pattern of "1111"
> for the start of the frame . The next byte tells us the length of the
> payload . Now the minimum payload could be of 4 byes so there is a
> chance that in the current 64 bytes we can have multiple short frames
> of 4 bytes and henceforth we can have many start and stop bytes .
>
> Once we have detected a sync and the start of frame pattern then we
> have to make sure it is not mistakingly taking the patter in the
> payload as the start of the frma e again .
>
> I have made a loop that goes 63 downto 0 and looks for each byte for
> sync and start bit pattern
>
> if it finds the sync and the start fame pattern then i am using a flag
> to make sure it is not mistakingly taking the pattern in the payload
> as the another start frame once it has detected the start of the frame
> and sync successfully.
>
> Solution : I have made a counter that runs inside the loop (63 down to
> 0) and it is 13 bits wide ( as there could be 8192 max payload)
>
> so once the count length is equal to payload length I am disabling the
> flag to allow it to go into detection of sync and start of the frame.
>
> Problem: The problem is that whe i am using a 13 bit counter inside a
> loop that goes 64 iterations makes a very large HW during syntheis .
>
> Can you provide a solution to this problem as i would be able to
> detect smallest payload ( 4 bytes in this case) as well as max payload
> bytes in an efficient way.
>
> I will really appreciate you help in this regard.
>
> Regards
>
> Vips

It seems to me that you are trying to do an awful lot in one
clock cycle. How fast is your clock? Can you run logic at
many times the clock rate in order to serialize this task?
I don't see how else to reduce the size of the hardware
generated. Basically all of your loops are being unrolled
to create hardware, so I'm not surprised that the HW is
very large.

Regards,
Gabor
From: Sandro on 15 Jun 2010 13:34
On Jun 15, 12:55 pm, Vips <thevipulsi...(a)gmail.com> wrote:
> ...
> Once we have detected a sync and the start of frame pattern then we
> have to make sure it is not mistakingly taking the patter in the
> payload as the start of the frma e again .
> ...

Hi,

If you are designing the whole system (i.e. both sender and
receiver)... what about using bit-stuffing ?

Regards
Sandro
From: backhus on 16 Jun 2010 03:03
On 15 Jun., 12:55, Vips <thevipulsi...(a)gmail.com> wrote:
> Hi All
>
> I am designing a module and I am having some issues .. Let me explain
> what  I am doing.
>
> I am getting  data as 64 bytes in each clock cycle . In these 64 bytes
> I look for sync bits which is "01" and then a fixed pattern of "1111"
> for the start of the frame . The next byte tells us the length of the
> payload . Now the minimum payload could be of 4 byes so there is a
> chance that in the current 64 bytes we can have multiple short frames
> of 4 bytes and henceforth we can have many start and stop bytes .
>
> Once we have detected a sync and the start of frame pattern then we
> have to make sure it is not mistakingly taking the patter in the
> payload as the start of the frma e again .
>
> I have made a loop that goes 63 downto 0 and looks for each byte for
> sync and start bit pattern
>
> if it finds the sync and the start fame pattern then i am using a flag
> to make sure it is not mistakingly taking the pattern in the payload
> as the another start frame once it has detected the start of the frame
> and sync successfully.
>
> Solution : I have made a counter that runs inside the loop (63 down to
> 0) and it is 13 bits wide ( as there could be 8192 max payload)
>
> so once the count length is equal to payload length I am disabling the
> flag to allow it to go into detection of sync and start of the frame.
>
> Problem: The problem is that whe i am using a 13 bit counter inside a
> loop that goes 64 iterations makes a very large HW during syntheis .
>
> Can you provide a solution to this problem as i would be able to
> detect smallest payload ( 4 bytes in this case) as well as max payload
> bytes in an efficient way.
>
> I will really appreciate you help in this regard.
>
> Regards
>
> Vips

Hi Vips,
did I get that right, that your sync word consists of 2+4= 6 Bits?
Like Sandro said, things would be a lot easier if you could expand
this to 8 bits, so you would be able to work on whole bytes only.
Of course, to handle the data frames you need to do it at a higher
clock rate than the data rate of your 64-Byte interface.

How about this:
Make your 64-Byte buffer a barrel shifter capable of moving the data
by 1/4/8-Bit width. (This needs a 5-input LUT in front of each FF,
actual FPGAs have 6-input LUTs and can do this at maximum clock speed)
So you make a detection FSM at the end, that searches for '01'. If
that is detected, a 4 bit comparator can tell you wether the following
four bits are "1111" or not.
If Not, you continue searching, if Yes you shift by 4 once to get rid
of the "1111" nibble.
Then you take the next byte to load your payload counter. (How can you
have payloads between 4 and 8192 bytes with an 8 bit information? is
it nonlinear?)
Now you are moving the data by 8 bits at a time and forward it to the
following stages until the end of the frame.
You don't need a special flag, since everything is controlled by your
FSM and the Frame Counter.
After reading the last byte your FSM starts alll over again and
searches for the next sync signal.

The bad thing is that you have to search for a 2+4 bit pattern that
can be anywhere in the 64 bit .
This serial approach is nice, but needs high overclocking (in the
worst case 512 times, but with some moderate use of combinatorical
preprocessing, this may be reduced to 64 times).

The problem is in the frame format, which doesn't fit into whole
bytes.
Do the 64 Bytes come from some deserializer?
Why is the syncing not done on that level? It's low effort for a small
FSM, so it could run on high frequencies.
In that case you would just have a Frame Length byte at the beginning
of your 64 byte buffer and need only 8 times overclocking and a
bytewise-only barrel shifter, which is simple.
All the junk data and sync bits have already been thrown out.

I hope there have been some helpful suggestions for your problem.
Have a nice synthesis
Eilert


From: Sandro on 16 Jun 2010 10:14
On Jun 16, 9:03 am, backhus <goous...(a)googlemail.com> wrote:
> ...
> did I get that right, that your sync word consists of 2+4= 6 Bits?
> Like Sandro said, things would be a lot easier if you could expand
> this to 8 bits, so you would be able to work on whole bytes only.
> Of course, to handle the data frames you need to do it at a higher
> clock rate than the data rate of your 64-Byte interface.
> ...

I should be more clear...
I don't mean to bring 2+4=6 bits to 8 bits.

I mean to use a bit-stuffer on the transmit module (just before the
"framer") in
order to completely avoid the sync and/or start sequence to be present
in the
payload and a bit-destuffer on the receiver side just after the
"deframer"...

Regards
Sandro
 |  Next  |  Last
Pages: 1 2
Prev: Does Xilinx Spartan 6 support NAND flash?
Next: VIRTEX5 (XUPV5-LX110T) Ethernet