Low budget FPGA needed

[ataradov]

1. Lattice or already mentioned Efinix.

Efinix are cheap and their development environment is good. But most of their parts are in BGA packages. Only very recently they started adding TQFP and QFN, but the selection is still very limited.

And as far size goes - pick a vendor, install their tools, build the project (at least a close approximation), see what is the smallest device it fits into.

2. Whatever comes with the vendor tools. From the really free ones, I use iverilog, but that's only for Verilog. No idea what exists for VHDL.

[PCB.Wiz]

..
Same clock for each channel.
And since there is no syncing on edges or reference clock, i am doing 2x oversampling (2 MHz) and get two phase-shifted streams from which the sync-pattern detector will give me the correct one.
...
You'r absolutely right but since the data packages are very small (around 200 bits only) and an extended CRC is used, i am confident that this will work.

So you do have data boundaries ? Where does the desired 32bits fall within that 200bits ? anywhere, or aligned  ?
You have no clock that is generated with the data ?  Usually that's what sync data means, there is a CLK and DATA.
Does that also mean the 16 channels are phase-variable ? (tho you also say Same clock for each channel. ) ?

Maybe you can do a 'start-bit' on the leading edge ? Are those 200 bits continual and crystal generated ?
What is the gap between 200 bit bursts ?

Each of the 16 serial channels has a datarate of 1Mbps.
The pattern that is checked for is the same for each channel and fixed/compiled-in.
There is no framing available.
Whenever the shift register content matches the pattern, the trigger is appied.
To handle false-positives on random data i plan to use an approriate CRC on top.
However, random data should not occure with this design anyway.

Do you have control of the 200 bits, or is that 3rd party ?

Of course, you may not need a FPGA at all 
1MBps is not super fast, and the Parallax P2X8C4M64P has 8 cores / 180MHz, and has multiple Sync and Async channels. It can manage 16 RX and 16 clocks if needed.
 
If each core manages let's say 4 channels, you have appx 20+ opcodes per channel per delivered bit.
The pins can SYNC receive 1-32 bits, (which would be easy if you had a clock)

With no clock, you need to create a clock that is sync'd, that bit could get tight if you have 4 unknown phased starts, all wanting to start 1 of 4 clock bursts.

If Same clock for each channel means those signals are phase aligned, life gets simpler as a single clock wait/start works on 4+ sync channels.

[gnuarm]

I see no reason why a CRC will help with this.  The CRC only checks for bit errors.  It has nothing to do with alignment.

Of course it can be used to check alignment - CRC passes when data is aligned, so if you can do a CRC every bit period, this can be used for alignment detection.

Ok, problem solved.   We can move onto the next problem.

[gnuarm]

If you don't know how to model units, then I'm not sure how you could design the FPGA. 

I don't need to know how to use the software needed to create models of a thing to design hardware/HDL to interface to that thing.

But you've said you've done multiple FPGA projects.  You see learning time as wasted.  I see it as invested.  You have been doing yourself a disservice by not learning the most important part of FPGA design, simulation. 

Maybe 5 projects over ten years. Many things needed to be re-learned anyway because of the gaps.
How can you argue that simulation is the most important part?  You can build a working thing knowing just HDL (or even schematic entry if you really want!) and the IDE/programming tools. Those are the most important, as without those you can can't do anything useful at all.

I'm not arguing anything at this point.  Positions have been taken and explained ad infinitum.   There's nothing more to say.  To each, his own.

[gnuarm]

As a complete beginner, when I was playing around with FPGAs, I struggled as much with properly defining a test bench as I did with the HDL for my actual project. It was impossible to know whether my test bench was misbehaving, or my design was. This is very frustrating when you are trying to figure out how it all works, and it is absolutely helpful to bring things out to a place where you can be confident in your observations and stimulus.

I agree it is a necessary skill to become competent, but at the beginning it makes the learning curve even steeper, IME.

Yes, if your skills in your HDL are poor, you are going to do badly no matter what approach you take.  That's a given.  You don't need a GPS to guide your route, if you can't drive the car without crashing.

[asmi]

One can try and supplement a simple FPGA design by debugging signals brought out to pins. Xilinx even provide logic analyzer IP to support that.

Both of those ways only work on relatively slow designs and they significantly change placement and routing, so they are extremely bad idea for anything that hopes to claim any sort of performance. The first one is of course orders of magnitude worse then the other one, but still ILA prevents some optimizations and thus can affect the QoR.

[gnuarm]

One can try and supplement a simple FPGA design by debugging signals brought out to pins. Xilinx even provide logic analyzer IP to support that.

Both of those ways only work on relatively slow designs and they significantly change placement and routing, so they are extremely bad idea for anything that hopes to claim any sort of performance. The first one is of course orders of magnitude worse then the other one, but still ILA prevents some optimizations and thus can affect the QoR.

I often design in a debugging port, just for this purpose.  It can work great.  If you have to worry about introducing timing errors in your FPGA, you don't understand how timing is handled in FPGA design.  You should never work with FPGAs.   

I would also point out that such a debugging port is a last resort when I can't find the bug in my simulations. 

[asmi]

At some point you're always going to need suitable test equipment.

Well after a number of years I'm yet to reach that point. I've implemented multiple designs with multi-gigabit serial links, and I'm yet encounter a need for dedicated test equipment. BTW figuring out how to connect such equipment in a way as to not significantly alter what's going on on a line is also far from trivial, and the higher the speed is, the more likely you'll render your design completely non-functional just by connecting a TMI. It follows without saying that whatever you "measure" in such a case will be the classic example of GIGO (garbage in - garbage out) as none of it will reflect what is actually going on in the line.

Otherwise what do you do when your perfectly-simulated design fails to work correctly, and you don't know if it's a problem with your simulation, the HDL design or hardware? How do you know how much real-world margin you have?

Most FPGAs capable of running high-speed interfaces have capabilities to figure this out without any external equipment (which, as I mentioned above, can do more bad than good if you don't know what are you doing).

[asmi]

I often design in a debugging port, just for this purpose.  It can work great.  If you have to worry about introducing timing errors in your FPGA, you don't understand how timing is handled in FPGA design.  You should never work with FPGAs.   

Yes I do understand how timing is handled in FPGA designs. Hence why I know that sometimes an extra connection can mess up the placement & routing, because I've seen this happened multiple times. And the higher is your clock frequency, the more likely you are to see this problem, especially if you want to "debug" high-fanout nets.

[gnuarm]

I often design in a debugging port, just for this purpose.  It can work great.  If you have to worry about introducing timing errors in your FPGA, you don't understand how timing is handled in FPGA design.  You should never work with FPGAs.   

Yes I do understand how timing is handled in FPGA designs. Hence why I know that sometimes an extra connection can mess up the placement & routing, because I've seen this happened multiple times. And the higher is your clock frequency, the more likely you are to see this problem, especially if you want to "debug" high-fanout nets.

Then, you should know how to detect the timing problem, and how to fix it. 

Are you just trying to be difficult?  What is your point?

[rfspezi]

So you do have data boundaries ? Where does the desired 32bits fall within that 200bits ? anywhere, or aligned  ?

The first 32bits are the sync-pattern.

You have no clock that is generated with the data ?  Usually that's what sync data means, there is a CLK and DATA.
Does that also mean the 16 channels are phase-variable ? (tho you also say Same clock for each channel. ) ?

No clock-line available - pure data-stream.
By 2x oversampling there is always a valid phase captured.
The 16 channels are phase-variable but run with the same clock-speed.

Maybe you can do a 'start-bit' on the leading edge ? Are those 200 bits continual and crystal generated ?
What is the gap between 200 bit bursts ?

I really want to avoid any syncing on edges - 2x oversampling should resolve a lot of issues from the beginning.
The gap between the 220 bit bursts are about the same time as the 200 bit burst itself.

Do you have control of the 200 bits, or is that 3rd party ?

Got total control over the bitsream source.

Of course, you may not need a FPGA at all 
1MBps is not super fast, and the Parallax P2X8C4M64P has 8 cores / 180MHz, and has multiple Sync and Async channels. It can manage 16 RX and 16 clocks if needed.

Thank you for the hint!
This one sounds really interesting.
 

With no clock, you need to create a clock that is sync'd, that bit could get tight if you have 4 unknown phased starts, all wanting to start 1 of 4 clock bursts.

Not quite... as mentioned before with a 2x oversampling i don't need a synced local clock.

If Same clock for each channel means those signals are phase aligned, life gets simpler as a single clock wait/start works on 4+ sync channels.

Same clock-speed but not phase-aligned.

[mikeselectricstuff]

No clock-line available - pure data-stream.
By 2x oversampling there is always a valid phase captured.

I think in practice it may be helpful to use more than 2x oversampling, especially once you consider tolerance/jitter on the clock frequency. If nothing else, 3x or 4x is likely to make things simpler.
WIth 2x, you'd also probably need to double-latch the inputs to avoid issues with metastabily, though higher oversampling may reduce the need for that as you'll always have 2 chances to get each bit

[mikeselectricstuff]

Got total control over the bitsream source.

In which case could you simply use an initial rising edge and timeout to do the framing?

[gnuarm]

So you do have data boundaries ? Where does the desired 32bits fall within that 200bits ? anywhere, or aligned  ?

The first 32bits are the sync-pattern.

You have no clock that is generated with the data ?  Usually that's what sync data means, there is a CLK and DATA.
Does that also mean the 16 channels are phase-variable ? (tho you also say Same clock for each channel. ) ?

No clock-line available - pure data-stream.
By 2x oversampling there is always a valid phase captured.
The 16 channels are phase-variable but run with the same clock-speed.

Maybe you can do a 'start-bit' on the leading edge ? Are those 200 bits continual and crystal generated ?
What is the gap between 200 bit bursts ?

I really want to avoid any syncing on edges - 2x oversampling should resolve a lot of issues from the beginning.
The gap between the 220 bit bursts are about the same time as the 200 bit burst itself.

I suppose 2x oversampling and detecting valid sync pattern to tell you which phase is appropriately aligned could work, but it seems to me you will get drift.  This will mean the two sampling phases will drift in and out of alignment, so the phase with the valid alignment will change.  When this changes, you may lose a bit of data.

When I received data with no clock, I used a higher oversampling rate, and essentially used a digital phase lock loop to adjust my digitally generated sampling clock.  I believe I used a 5x oversampling rate, and selected the data on the clock phase that was two after a data transition. 

I'm afraid I can't verify how well it worked in the field.  It was a product feature they may not have ever sold.  It was included in an upgrade to help win a sales contract, which they subsequently lost.  It's still in the product, but I don't think it gets used. 

Not quite... as mentioned before with a 2x oversampling i don't need a synced local clock.

The problem is you get two data streams and you will never know which is the correct stream until you get the sync pattern.  Meanwhile, the alignment can change subtly in the middle of the message. 

I just think your scheme is more complex than you are admitting to.  2x is the Nyquist value for oversampling retaining all frequencies in an analog signal.  I think being on the edge of 2x sampling will not be easy to pick out the data in this case. 

Same clock-speed but not phase-aligned.

This gets better all the time.

[gnuarm]

No clock-line available - pure data-stream.
By 2x oversampling there is always a valid phase captured.

I think in practice it may be helpful to use more than 2x oversampling, especially once you consider tolerance/jitter on the clock frequency. If nothing else, 3x or 4x is likely to make things simpler.
WIth 2x, you'd also probably need to double-latch the inputs to avoid issues with metastabily, though higher oversampling may reduce the need for that as you'll always have 2 chances to get each bit

Metastability should not be an issue.  The stream that samples when the data is changing is the stream you wish to reject anyway, so why do you care if it's metastable?  Essentially, the 2x sampling is already dealing with metastability. 

[fourfathom]

The problem is you get two data streams and you will never know which is the correct stream until you get the sync pattern.  Meanwhile, the alignment can change subtly in the middle of the message. 

I just think you scheme is more complex than you are admitting to.  2x is the Nyquist value for oversampling retaining all frequencies in an analog signal.  I think being on the edge of 2x sampling will not be easy to pick out the data in this case. 

Yes.  This exactly.  With 2X sampling the drift and jitter will cause data ambiguity (or worse) from time to time.

The good news is that the data rate is only 1MHz (per channel).  This is extremely slow for any FPGA, which gives you lots of options.  Perhaps sample each input at 3 or 4MHz (or 32 MHz), and use sampled edge-detection to run a very simple per-channel digital PLL that gives you a good clock-enable sample point.  This PLL requires no filtering, it just resets the sample-enable point whenever it sees an input transition.  The only catch is to not allow double-sampling, but that's just a bit of simple logic.  After this stage the pattern detectors can all run synchronously.  Depending on the FPGA it might save resources to have all input sections share a common "match" circuit, using the internal 32X clock.  I've done this type of data-path pipelining before in ASICs.

The edge-detector will need to have double-buffered input to avoid metastability issues, but you will end up using this same stage to clean up the data anyway.

[gnuarm]

The problem is you get two data streams and you will never know which is the correct stream until you get the sync pattern.  Meanwhile, the alignment can change subtly in the middle of the message. 

I just think you scheme is more complex than you are admitting to.  2x is the Nyquist value for oversampling retaining all frequencies in an analog signal.  I think being on the edge of 2x sampling will not be easy to pick out the data in this case. 

Yes.  This exactly.  With 2X sampling the drift and jitter will cause data ambiguity (or worse) from time to time.

The good news is that the data rate is only 1MHz (per channel).  This is extremely slow for any FPGA, which gives you lots of options.  Perhaps sample each input at 3 or 4MHz (or 32 MHz), and use sampled edge-detection to run a very simple per-channel digital PLL that gives you a good clock-enable sample point.  This PLL requires no filtering, it just resets the sample-enable point whenever it sees an input transition.  The only catch is to not allow double-sampling, but that's just a bit of simple logic.  After this stage the pattern detectors can all run synchronously.  Depending on the FPGA it might save resources to have all input sections share a common "match" circuit, using the internal 32X clock.  I've done this type of data-path pipelining before in ASICs.

The edge-detector will need to have double-buffered input to avoid metastability issues, but you will end up using this same stage to clean up the data anyway.

Yes, I described the digital PLL I had implemented, which is what you are recommending be used here. 

[mikeselectricstuff]

I really want to avoid any syncing on edges - 2x oversampling should resolve a lot of issues from the beginning.

Seems you're effectively trying to create a UART with a 200-bit word length, albeit with some additional error detection. There are reasons people don't do that.
The worst-case absolute error and jitter rates are going to be crucial to figuring out what's possible.
As others have said, you need to deal with both the initial shift in the sampling point as well as any drift during the frame.

If you have complete control of the bitstream, why not just turn it into a burst of 1-2MBaud UART bytes by forcing a start and stop bit every byte.
That way you can easily sync on the startbit of each byte, and only need a few percent timing accuracy. 
Or use a Manchester type encoding which self-clocks on every bit.

[langwadt]

I often design in a debugging port, just for this purpose.  It can work great.  If you have to worry about introducing timing errors in your FPGA, you don't understand how timing is handled in FPGA design.  You should never work with FPGAs.   

Yes I do understand how timing is handled in FPGA designs. Hence why I know that sometimes an extra connection can mess up the placement & routing, because I've seen this happened multiple times. And the higher is your clock frequency, the more likely you are to see this problem, especially if you want to "debug" high-fanout nets.

Then, you should know how to detect the timing problem, and how to fix it. 

Are you just trying to be difficult?  What is your point?

that if you are pushing utilization and/or performance adding a connection might make it impossible to meet timing ...

[langwadt]

I really want to avoid any syncing on edges - 2x oversampling should resolve a lot of issues from the beginning.
The gap between the 220 bit bursts are about the same time as the 200 bit burst itself.

async and 2x oversampling almost certainly won't work, you could get a match with you 2x sampling a fraction of a ns before or after the data edge and half a burst later you have drifted to the other side of the data edge

[PCB.Wiz]

So you do have data boundaries ? Where does the desired 32bits fall within that 200bits ? anywhere, or aligned  ?

The first 32bits are the sync-pattern.

I really want to avoid any syncing on edges - 2x oversampling should resolve a lot of issues from the beginning.
The gap between the 220 bit bursts are about the same time as the 200 bit burst itself.

Got total control over the bitsream source.

Of course, you may not need a FPGA at all 
1MBps is not super fast, and the Parallax P2X8C4M64P has 8 cores / 180MHz, and has multiple Sync and Async channels. It can manage 16 RX and 16 clocks if needed.

Thank you for the hint!
This one sounds really interesting.

I'm assuming 'good' crystals set the data rates here.

If you have control of the 200/220? bits, and sync is always first, some modest tuning can make your life a whole lot simpler.

Edge sampling is not a problem, with over sampling you are effectively making the edge decision later, but are never really sure which one to reject.

If you have gaps, and sync is first bits, you already have a start-edge, so you can define the first sync info as zero == start bit and read the next 31/32 bits,
( or you can make the stream fully 32b async, and send 7 wide characters = 238 bit times )

It is not mandatory to make the stream async, it just puts you on a path more travelled.
eg I think the P2X8C4M64P is ok with an undefined STOP bit, so it could grab the first 32 bits of a sync stream, then pause until break found, then repeat.

The  P2X8C4M64P has 60+ x 1-32b UARTS, and there are MCUs with UARTS up to 32bits.
The P2X8C4M64P also has break/gap in edges detector, so that can give block-sync info, you just need to define edges-rules. A 200b gap is quite relaxed for break detect.

If it was me, I'd change to 32b async and then a single core in P2X8C4M64P could manage all 16, or you could spread over 4 cores, to reduce the worst case trigger jitter.
My reading has the P2X8C4M64P UART sync to the start edge and interrupts/flags on the last mid bit, so it has very low jitter.
Your worst case would be if all 16 channels are very close to phase locked, but I'd guess sub 200ns jitter on trigger out is possible, 4 channels per core.

 

[rfspezi]

async and 2x oversampling almost certainly won't work, you could get a match with you 2x sampling a fraction of a ns before or after the data edge and half a burst later you have drifted to the other side of the data edge

I am confident, that 2x oversampling in combination with the following constellation will do the job just fine.

-) Short frames (standard clock drift does not matter)
-) Low datarate
-) Long sync pattern
-) Enhanced CRC

3x oversampling could be used for redundancy/sanity check.
However it adds unnecessary cost.

[langwadt]

async and 2x oversampling almost certainly won't work, you could get a match with you 2x sampling a fraction of a ns before or after the data edge and half a burst later you have drifted to the other side of the data edge

I am confident, that 2x oversampling in combination with the following constellation will do the job just fine.

-) Short frames (standard clock drift does not matter)
-) Low datarate
-) Long sync pattern
-) Enhanced CRC

only ones of those that does anything is crc and that is by discarding whole frames

3x oversampling could be used for redundancy/sanity check.
However it adds unnecessary cost.

it'll also be far better because it'll give you 1/3 bit of margin for drift instead of effectively zero

[rfspezi]

only ones of those that does anything is crc and that is by discarding whole frames

it'll also be far better because it'll give you 1/3 bit of margin for drift instead of effectively zero

Imagine two "sample streams" A and B running at 2 MHz but with stream B being 1/2 bittime delayed compared to stream A.

Worst case scenario ist that e.g. "sample stream A" samples around the edges of the datastream and detects a valid sync-pattern but further databits are fluctuating.
At the same time, "sample stream B" samples perfectly in the middle of the bitstream.

CRC check of both streams will mark stream A as invalid and stream B as valid.--> DONE

Even if stream A somehow passes the CRC and both streams are marked valid, a final sanity check - which compares both streams will detect an inconsitency and mark both streams invalid.

[langwadt]

only ones of those that does anything is crc and that is by discarding whole frames

it'll also be far better because it'll give you 1/3 bit of margin for drift instead of effectively zero

Imagine two "sample streams" A and B running at 2 MHz but with stream B being 1/2 bittime delayed compared to stream A.

Worst case scenario ist that e.g. "sample stream A" samples around the edges of the datastream and detects a valid sync-pattern but further databits are fluctuating.
At the same time, "sample stream B" - which is 1/2 bit-time delayed - samples perfectly in the middle of the datastream.

CRC check of both streams will mark stream A as invalid and stream B as valid.--> DONE

Even if stream A somehow passes the CRC and both streams are marked valid, a final sanity check - which compares both streams will detect an inconsitency and mark both streams invalid.

but then you have to sample and store the full frame for both streams, much more efficient to do the match at a higher rate and then only store the bits you know are in the middle of the datastream

your usual UART that does 16 time over sampling doesn't store 16 copies of a frame the decides which one is good.
It find the frame at 16 times the bit rate and the samples the bits at 1x at the now known middle of the bits