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 Jun 15, 6:55=A0am, Vips
<thevipulsi...@gmail.com> wrote:
> Hi All
>
> I am designing a module and I am having some issues .. Let me explain
> what =A0I am doing.
>
> I am getting =A0data 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

On Jun 15, 12:55=A0pm, Vips
<thevipulsi...@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

On 15 Jun., 12:55, Vips
<thevipulsi...@gmail.com> wrote:
> Hi All
>
> I am designing a module and I am having some issues .. Let me explain
> what =A0I am doing.
>
> I am getting =A0data 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=3D 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

On Jun 16, 9:03=A0am, backhus
<goous...@googlemail.com> wrote:
> ...
> did I get that right, that your sync word consists of 2+4=3D 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=3D6 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

On Jun 16, 12:03=A0pm, backhus
<goous...@googlemail.com> wrote:
> On 15 Jun., 12:55, Vips <thevipulsi...@gmail.com> wrote:
>
>
>
> > Hi All
>
> > I am designing a module and I am having some issues .. Let me explain
> > what =A0I am doing.
>
> > I am getting =A0data as 64 bytes in each clock cycle . In these 64 byte=
s
> > 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=3D 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 =A0'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
> =A0 Eilert

Hi   Eilert /Sandro

Thanks for the suggestion. I would like to slightly modify the spec
here , may be i did not made clear.  I have made a record and date is
separate with includes the frame pattern "1111" other 4+ 8 is the
length. The sync bit is separately moved in record so i just try to
see the sync bits "01" in the recored.

I am getting the frame in the form of record that has (4+ 8) array of
64 values.

I have no choice as i am getting the record type as input so i have to
process it the way i am getting it.

Again if i do sequential search then i will have to use a loop to
detect the sync and the frame start pattern

thanks

vipul

On Jun 15, 10:55=A0pm, Vips
<thevipulsi...@gmail.com> wrote:
> Hi All
>
> I am designing a module and I am having some issues .. Let me explain
> what =A0I am doing.
>
> I am getting =A0data as 64 bytes in each clock cycle .

What are your actual Data, and Max FPGA clock speeds ?

> 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 .

Most sync protocols avoid this by design.
What sync protocol are you using on the transmit ?

-jg

On Jun 16, 12:03=A0pm, backhus
<goous...@googlemail.com> wrote:
> On 15 Jun., 12:55, Vips <thevipulsi...@gmail.com> wrote:
>
>
>
> > Hi All
>
> > I am designing a module and I am having some issues .. Let me explain
> > what =A0I am doing.
>
> > I am getting =A0data as 64 bytes in each clock cycle . In these 64 byte=
s
> > 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=3D 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 =A0'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
> =A0 Eilert

Hi   Eilert /Sandro

Thanks for the suggestion. I would like to slightly modify the spec
here , may be i did not made clear.  I have made a record and date is
separate with includes the frame pattern "1111" other 4+ 8 is the
length. The sync bit is separately moved in record so i just try to
see the sync bits "01" in the recored.

I am getting the frame in the form of record that has (4+ 8) array of
64 values. I am working with PCI E 3.0

I have no choice as i am getting the record type as input so i have to
process it the way i am getting it.

Again if i do sequential search then i will have to use a loop to
detect the sync and the frame start pattern

thanks

vipul

On Jun 17, 2:07=A0am, Vips
<thevipulsi...@gmail.com> wrote:
> On Jun 16, 12:03=A0pm, backhus <goous...@googlemail.com> wrote:
>
>
>
> > On 15 Jun., 12:55, Vips <thevipulsi...@gmail.com> wrote:
>
> > > Hi All
>
> > > I am designing a module and I am having some issues .. Let me explain
> > > what =A0I am doing.
>
> > > I am getting =A0data as 64 bytes in each clock cycle . In these 64 by=
tes
> > > 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 fla=
g
> > > 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 fram=
e
> > > and sync successfully.
>
> > > Solution : I have made a counter that runs inside the loop (63 down t=
o
> > > 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 th=
e
> > > 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 payloa=
d
> > > 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=3D 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 =A0'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
> > =A0 Eilert
>
> Hi =A0 Eilert /Sandro
>
> Thanks for the suggestion. I would like to slightly modify the spec
> here , may be i did not made clear. =A0I have made a record and date is
> separate with includes the frame pattern "1111" other 4+ 8 is the
> length. The sync bit is separately moved in record so i just try to
> see the sync bits "01" in the recored.
>
> I am getting the frame in the form of record that has (4+ 8) array of
> 64 values. I am working with PCI E 3.0
>
> I have no choice as i am getting the record type as input so i have to
> process it the way i am getting it.
>
> Again if i do sequential search then i will have to use a loop to
> detect the sync and the frame start pattern
>
> thanks
>
> vipul

This explanation is less clear to me than your original problem
statement.  What does "(4+ 8) array" mean?  I think I understand that
your 64 bytes (if you are receiving 64 bytes in each clock cycle,
which I am not sure of) can hold multiple frames of data.  I have no
understanding of what a frame is at this point.  Does the frame start
with "1111"?  Does it start with "01" and the "1111" is a
marker for
the end of header and start of data?  How do you find the byte
count?

I will say that your design WILL have to use a lot of logic.  I'm not
clear if your frames are byte aligned or not.  If they are, then you
will have 64 copies of the logic required to detect a frame, including
the counter logic that must be decoded or possibly combinatorially
counted down (depending on your how your code is written), which is
very messy.  If your frames are not byte aligned this logic must be
repeated for each bit, 512 times!

If you want this to be efficient, start drawing some block diagrams of
how you expect the logic to be implemented and see just how complex it
is.  Right now you seem to be writing software which is translated
into hardware.  When you do this you have little control over the
resulting hardware.  If you figure out what hardware you want, then
you can use your Hardware DESCRIPTION Language to actually describe
the hardware you want rather than letting the tools give you the
hardware it wants.

If you can make your problem clear, perhaps we can help you with the
details of how to structure your hardware.

Rick