VIPS
Guest
Tue Jun 15, 2010 1:57 pm
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
Tricky
Guest
Wed Jun 16, 2010 10:47 am
On 15 June, 11:57, VIPS <thevipulsi...@gmail.com> wrote:
Quote:
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 sounds like you're trying to write VHDL like software. You have to
remember that in VHDL loops un-roll into parrallel hardware, hence
your very large HW. Loops are not usually what you want when you're
trying to look at sequential data.
Post up some of your code so we can have a look.
Brian Drummond
Guest
Wed Jun 16, 2010 11:44 am
On Tue, 15 Jun 2010 03:57:55 -0700 (PDT), VIPS <thevipulsinha_at_gmail.com> wrote:
Quote:
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 .
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)
If you MUST do it all in one cycle, there is no need for a 13-bit counter in the
inner loop, because you cannot get more than 64 bytes of message content in that
cycle.
So when you detect the start of a large message, then all you need to do in
subsequent cycles is subtract 64 from the message length remaining, until the
remaining count < 64 which indicates the last cycle is coming.
You need to separately consider first and last cycles of a long message
separately, as well as the case where multiple short messages appear in one
cycle, and the cases where a message header is split across two cycles.
The first step will be to look for all possible sync bits in parallel - your
loop still has to do that. Next step is to validate each one with the fixed
pattern. Next step is to detect the first that cannot be part of a previous
message (hint: the previous message sets a mask whose length is controlled by
the prev byte count. This can be applied before the "first step" if you wish),
and use its byte count to mask off false sync patterns. As this may ripple
through several messages, it may be slow, in which case you may consider a
pipelined approach to this part of the design.
The rest is up to you.
- Brian
vipin lal
Guest
Wed Jun 16, 2010 12:16 pm
On Jun 15, 3:57 pm, VIPS <thevipulsi...@gmail.com> wrote:
Quote:
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
Do you have any other clock(other than the clock which supplies 64
bytes to your module) available in the system?If you have a clock
which has a time period of 1 byte length then you can use it to create
a state machine.This will reduce the hardware considerably.
--vipin
Mike Treseler
Guest
Wed Jun 16, 2010 5:31 pm
VIPS wrote:
Quote:
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 .
Without bit or byte stuffing the data,
it is impossible to tell the flags (sync bits) from the data.
-- Mike Treseler
VIPS
Guest
Thu Jun 17, 2010 12:16 pm
On Jun 16, 12:47 pm, Tricky <trickyh...@gmail.com> wrote:
Quote:
On 15 June, 11:57, VIPS <thevipulsi...@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 sounds like you're trying to write VHDL like software. You have to
remember that in VHDL loops un-roll into parrallel hardware, hence
your very large HW. Loops are not usually what you want when you're
trying to look at sequential data.
Post up some of your code so we can have a look.
Yes i know loop gives a large HW and more worse a 13 bit counter
inside a loop that runs 64 iterations...
But what is the way to look for sync bits and fixed patter "1111" for
start of the frame .MInd you you can have actual start also that has
to be separated out with false start.
Thanks
Vips
Pieter Hulshoff
Guest
Thu Jun 17, 2010 3:42 pm
VIPS,
What kind of bandwidth and clock frequency are you working with to end up with a 512 bit wide databus?
In any case: you're looking for a 6 bit pattern in a 512 bit databus, so you'll need a 512+(6-1)=517
bit wide sliding window. You can either do this in multiple clock cycles, or split the databus into
small parts with a 5 bit overlap, and combine the results. In either case, it's wise to separate your
framing algorithm from your data handling part, and don't look at the data until you're in-frame.
With regards to your framing algorithm: build in some rebustness against bit errors and false framing
patterns.
Kind regards,
Pieter Hulshoff
Mike Treseler
Guest
Fri Jun 18, 2010 9:18 pm
Quote:
But what is the way to look for sync bits and fixed patter "1111" for
start of the frame .MInd you you can have actual start also that has
to be separated out with false start.
To pick packets out of a data-stream I either have to insert fixed flag
patterns that are *only* used between packets, or a fixed frame
size with assigned counts for variable data and fixed frame bits.
In the first case I just watch for flags and unstuff the data.
In the second case, I have to synch up to the data by
counting from an arbitrary start bit and checking the frame bits.
If a frame bit is wrong, I reset the counter and try again
until they are all correct.
While synced, I know which counts to output as data.
-- Mike Treseler
