«

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

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.

On Jun 15, 3:57*pm, 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

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

VIPS wrote:

> 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

On Jun 16, 12:47*pm, Tricky <trickyh...@gmail.com> wrote:
> 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

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

> 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