Prev: Does Xilinx Spartan 6 support NAND flash?
Next: VIRTEX5 (XUPV5-LX110T) Ethernet
From: jas on 16 Jun 2010 10:46
On Jun 16, 12:03 pm, backhus <goous...(a)googlemail.com> wrote:
> 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

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
From: -jg on 16 Jun 2010 16:59
On Jun 15, 10:55 pm, 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 .

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
From: Vips on 17 Jun 2010 02:07
On Jun 16, 12:03 pm, backhus <goous...(a)googlemail.com> wrote:
> 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

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
From: rickman on 17 Jun 2010 07:21
On Jun 17, 2:07 am, Vips <thevipulsi...(a)gmail.com> wrote:
> On Jun 16, 12:03 pm, backhus <goous...(a)googlemail.com> wrote:
>
>
>
> > 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
>
> 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

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
First  |  Prev  | 
Pages: 1 2
Prev: Does Xilinx Spartan 6 support NAND flash?
Next: VIRTEX5 (XUPV5-LX110T) Ethernet