Low budget FPGA needed

[PCB.Wiz]

I want to implement 16 serial channels (free running sample clock) each with a 32-bit pattern detector (1 Mbps).
So each channel needs a 32 bit shift register and a 32 bit comparator with a detection-output signal.

So you have a 16 x 1MHz  clocks, or 1 x 1MHz clock ?  There are 16 different patterns to check ?

How is the 32b framed - do you know when it starts, or do you simply want to trigger whenever the last-32-bits-seen matches some pattern ?
You realize that has a finite false-positive rate on random data ?

How do you plan to change the compare pattern info ? eg is that compiled-in, or does it update over some serial link ?

[PCB.Wiz]

When released for production, it should be in the range of 5.000 pcs/a.

What packages can you manage in production, or will you look for a module ?

[dietert1]

..
Why would anyone think bench testing is easier???

For a beginner nothing is easy with FPGA. And some people prefer taking important hurdles in the beginning. It can be very motivating to do so.
Yes, the problem of debugging is quite impressive for beginners coming from MCU. 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. At some point there will be insight about simulation - which has its limits, too.

Regards, Dieter

[gnuarm]

..
Why would anyone think bench testing is easier???

For a beginner nothing is easy with FPGA. And some people prefer taking important hurdles in the beginning. It can be very motivating to do so.
Yes, the problem of debugging is quite impressive for beginners coming from MCU. 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. At some point there will be insight about simulation - which has its limits, too.

Regards, Dieter

Different strokes for different folks.  The only reason to debug on the bench that I can see, is if you have some interface that is hard to code in the test bench.  But if you have trouble with that, you are going to have trouble with every aspect of the project. 

Trying to learn and get working so many different moving parts is not a beginner's best way to get started.  Simulation is useful to any project with any real complexity, and as others have mentioned, even somewhat simple projects.  It requires that you can learn about two things, the FPGA design you wish to test (duh!) and how to run a simulation.  Once you have your LED blinker program, it should be five minutes to getting the test bench running.  Using real code for a real design is not much more effort.  Not so true with real hardware. 

[mikeselectricstuff]

My point is, getting the hardware to work is not as simple as people will tell you, at least, not always. 

Which is why you should always  start with a devboard, so you know the hardware works, and  there will usually be some known-working example projects to get started

Why would anyone think bench testing is easier???

Because for someone very experienced in hardware design but new to FPGAs,  building and testing may be a more attractive option that learning how to use simulations because it fits their skillset better.
Different approaches work for different people. There are plenty of solutions for simulation on MCUs, but not many people use them and few would regard them as essential.

If you're dealing with non-trivially complex interactions with external hardware, it can easily be faster to test in hardware (it that's what you're used to doing) than generating a simulation model.

I've only ever done about half a dozen, not especially complex  FPGA designs, in each case I've built up from trivial designs, adding functionality a piece at a time until it all works. Never touched a simulator.

[mikeselectricstuff]

The problem with this approach is that as you work with progressively faster interfaces, the cost of equipment to "see" such signals very quickly goes above and boyond what most people can afford.

At some point you're always going to need suitable test equipment.
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?
 

[gnuarm]

My point is, getting the hardware to work is not as simple as people will tell you, at least, not always. 

Which is why you should always  start with a devboard, so you know the hardware works, and  there will usually be some known-working example projects to get started

Which is not what we have here.  The choice is using an arbitrary devboard with an FPGA before the FPGA has been chosen, or simulating before any hardware decisions have been made.  I think I know which is easier.

Why would anyone think bench testing is easier???

Because for someone very experienced in hardware design but new to FPGAs,  building and testing may be a more attractive option that learning how to use simulations because it fits their skillset better.
Different approaches work for different people. There are plenty of solutions for simulation on MCUs, but not many people use them and few would regard them as essential.

What do you think is going on here?  A simulation essentially works like a logic analyzer with the ability to probe anything in the design, and especially display in very useful ways.  If you can use a scope or logic analyzer, you can use a simulator. 

If you're dealing with non-trivially complex interactions with external hardware, it can easily be faster to test in hardware (it that's what you're used to doing) than generating a simulation model.

That's a very interesting "IF". 

I've only ever done about half a dozen, not especially complex  FPGA designs, in each case I've built up from trivial designs, adding functionality a piece at a time until it all works. Never touched a simulator.

Exactly!  So you have zero information with which to compare the two approaches. 

This is what many people don't understand about doing literally 99.9% of your work on the simulator.  This is the easy path, giving complete access to the entire design.  Then, when the design is working to the point of being "trivial", you transition to the lab bench and have very, very few problems to debug.

I don't recall exactly where I read this, but it is common material in system design training, that for every bug you miss in the earlier stages of the design process, it takes 10x more work to find them in the next stage.  Running simulations lets you not just find bugs, but lets you automate many bug finding, allowing the design to be fully tested each time you make a change.  Bugs can be found and automatically reported.  That's hard to do on the lab bench.

[rfspezi]

So you have a 16 x 1MHz  clocks, or 1 x 1MHz clock ?  There are 16 different patterns to check ?

How is the 32b framed - do you know when it starts, or do you simply want to trigger whenever the last-32-bits-seen matches some pattern ?
You realize that has a finite false-positive rate on random data ?

How do you plan to change the compare pattern info ? eg is that compiled-in, or does it update over some serial link ?

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.

Concerning the implementation i could imagine to only use one instance of comparator which is applied sequencially on each channel at 16x the datarate i.e. running at 16 MHz.
Hoping to reduce the FPGA size needed.

[mikeselectricstuff]

What do you think is going on here?  A simulation essentially works like a logic analyzer with the ability to probe anything in the design, and especially display in very useful ways.  If you can use a scope or logic analyzer, you can use a simulator. 

Except the simulator does not have access to the hardware you're using the FPGA to interface to.
I can easily route probe points to FPGA pins, and there are also soft logic-analyser add-ons for FPGAs that allow dynamic probing.

[mikeselectricstuff]

If you're dealing with non-trivially complex interactions with external hardware, it can easily be faster to test in hardware (it that's what you're used to doing) than generating a simulation model.

That's a very interesting "IF". 

Most FPGAs interface to some other hardware. The reason you're using an FPGA and no an MCU is that the requirements are too fast or too complex for an MCU.

I've only ever done about half a dozen, not especially complex  FPGA designs, in each case I've built up from trivial designs, adding functionality a piece at a time until it all works. Never touched a simulator.

Exactly!  So you have zero information with which to compare the two approaches. 

I'm not comparing anything, simply pointing out that there is no "right" answer.

FPGAs are a massive learning curve, personally I find that getting to real hardware as quickly as possible is a productive way to learn. YMMV.
.
For some of the things I've done, I have no clue how I could simulate the external hardware with any meaningful accuracy, and doing so would add significantly to that learning curve. But I do have the hardware and the test gear to see what's going on, and can easily instrument any internal FPGA signals. Not much different from building something with standard logic.

As I mentioned, I don't do much FPGA stuff, so the time learning something new can be a substantial, and more importantly, unpredictable proportion of overall project time.
I'm sure if I spent a lot more time doing FPGA stuff, the time spent on learning to do simulation would be worthwhile, but for the odd 1-off project, I didn't feel a need for it, and it worked out fine.
 

[langwadt]

So you have a 16 x 1MHz  clocks, or 1 x 1MHz clock ?  There are 16 different patterns to check ?

How is the 32b framed - do you know when it starts, or do you simply want to trigger whenever the last-32-bits-seen matches some pattern ?
You realize that has a finite false-positive rate on random data ?

How do you plan to change the compare pattern info ? eg is that compiled-in, or does it update over some serial link ?

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.

Concerning the implementation i could imagine to only use one instance of comparator which is applied sequencially on each channel at 16x the datarate i.e. running at 16 MHz.
Hoping to reduce the FPGA size needed.

is it the same clock for all channels? or do they each have a seperate asynchronous clock?

[rfspezi]

is it the same clock for all channels? or do they each have a seperate asynchronous clock?

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.

[langwadt]

is it the same clock for all channels? or do they each have a seperate asynchronous clock?

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.

if you don't sync on edges or have a reference clock that is synchronous to the clock generating the 1Mbit data then things might not be so simple, things will inviably drift in and out of phase and you'll be sampling edges etc.

[rfspezi]

is it the same clock for all channels? or do they each have a seperate asynchronous clock?

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.

if you don't sync on edges or have a reference clock that is synchronous to the clock generating the 1Mbit data then things might not be so simple, things will inviably drift in and out of phase and you'll be sampling edges etc.

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.

[gnuarm]

What do you think is going on here?  A simulation essentially works like a logic analyzer with the ability to probe anything in the design, and especially display in very useful ways.  If you can use a scope or logic analyzer, you can use a simulator. 

Except the simulator does not have access to the hardware you're using the FPGA to interface to.
I can easily route probe points to FPGA pins, and there are also soft logic-analyser add-ons for FPGAs that allow dynamic probing.

What you call easy in the hardware is actually not so easy compared to connecting things in simulation.

I'm starting to see a pattern.  People imagine the attached hardware as something overly complex and difficult to simulate.  The hard part to creating a simulation model is the high level stuff.  That comes later in debugging.  In fact, that is often not simulated at all.  But it is important to get the lower level protocol debugged, which can be hard to do with the hardware, since that is typically something out of your hands, inside a unit running proprietary software.

I'm sure there are many add on products you can buy that will make your life complex.  Simulations are the easy way to make it work.  The OP is not trying to debug an IP network interface.  Simulation is the better way for him to get started, now, without dealing with development boards, or logic analyzer tools, etc.  Just start the simulation and run.

[gnuarm]

If you're dealing with non-trivially complex interactions with external hardware, it can easily be faster to test in hardware (it that's what you're used to doing) than generating a simulation model.

That's a very interesting "IF". 

Most FPGAs interface to some other hardware. The reason you're using an FPGA and no an MCU is that the requirements are too fast or too complex for an MCU.

I've only ever done about half a dozen, not especially complex  FPGA designs, in each case I've built up from trivial designs, adding functionality a piece at a time until it all works. Never touched a simulator.

Exactly!  So you have zero information with which to compare the two approaches. 

I'm not comparing anything, simply pointing out that there is no "right" answer.

Not for 100% of cases, but for this guy, it is silly to buy a dev board, learn to debug some designs, then choose his device and buy a new dev board, only to then learn the simulator.

FPGAs are a massive learning curve, personally I find that getting to real hardware as quickly as possible is a productive way to learn. YMMV.

A software type worked with me for a short time, by posts like these and emails and got his demo FPGA design working.  Clearly it was not too difficult.  Zero experience to 60 in a couple of weeks.  That included the simulation as well as working on hardware.  No flashing LEDs.

For some of the things I've done, I have no clue how I could simulate the external hardware with any meaningful accuracy, and doing so would add significantly to that learning curve. But I do have the hardware and the test gear to see what's going on, and can easily instrument any internal FPGA signals. Not much different from building something with standard logic.

I don't know what to tell you.  If you don't know how to model units, then I'm not sure how you could design the FPGA.  It is very seldom that you need to model the entire FAA RADAR system.  Normally you only need to model the bus protocol at some fundamental level to make sure the handshake is happening.  If your FPGA has higher level protocol happening, you must understand it, or you could never design the FPGA.

I acknowledge this takes time and effort, often writing the simulation models takes as long as the FPGA design.  Why would that surprise anyone?  I run simulations on each module I write.  I learned this in writing software, and it reaps huge rewards.  Pay me now, or pay me 10X later.

As I mentioned, I don't do much FPGA stuff, so the time learning something new can be a substantial, and more importantly, unpredictable proportion of overall project time.
I'm sure if I spent a lot more time doing FPGA stuff, the time spent on learning to do simulation would be worthwhile, but for the odd 1-off project, I didn't feel a need for it, and it worked out fine.

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. 

Since you have never used simulation, you are in no position to compare it to working without it.  And don't tell me you aren't comparing the two, you just did!  I suppose you just don't have much confidence in yourself learning new things.  I've always been the opposite, ready to jump in and learn things that will pay rewards as I progress.

[gnuarm]

is it the same clock for all channels? or do they each have a seperate asynchronous clock?

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.

if you don't sync on edges or have a reference clock that is synchronous to the clock generating the 1Mbit data then things might not be so simple, things will inviably drift in and out of phase and you'll be sampling edges etc.

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.

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.

[dietert1]

I also see a pattern here: Trying to make beginners struggle with something they don't need to do. Simulation doesn't give you a low budget FPGA. Setting up meaningful simulation will cost much more than buying a learning board or an evaluation board as i recommended. And whatever you do: A simulation is nothing but a simulation. In the end you need hardware. It's a bad idea to get development hardware that fits for one project. Get something much more capable. Design/optimization for production is another step anyway

Regards, Dieter

[mikeselectricstuff]

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.

[mikeselectricstuff]

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.   

[nctnico]

What do you think is going on here?  A simulation essentially works like a logic analyzer with the ability to probe anything in the design, and especially display in very useful ways.  If you can use a scope or logic analyzer, you can use a simulator. 

Except the simulator does not have access to the hardware you're using the FPGA to interface to.
I can easily route probe points to FPGA pins, and there are also soft logic-analyser add-ons for FPGAs that allow dynamic probing.

The truth is somewhere in the middle. I use both simulation and testing with hardware. In some cases I even have a large mux in the FPGA design that can bring out various signals on dedicated debug pins. It allows to monitor whether various blocks inside an FPGA design work well together. OTOH I use simulation to develop pieces of logic that are later integrated into a larger design. I like to use GHDL as a simple VHDL simulator. It doesn't need much to setup and produces output that can be viewed using a waveform viewer.

It also depends on how long the compilation cycle for the FPGA design is. Some of the FPGA projects I work on need like 4 to 8 hours to 'compile'. You can't do without simulation for such designs if you want to retain any kind of development speed.

[dietert1]

A beginner won't have that compile time problem.
I think simulation is important as a "unit test" in order to verify components of a larger solution. Nobody working in a team should hand out a component without verifying it by simulation. Besides that a simulation makes a redundant description of the component interface, a usage example. The other person can see what has been tested.

Regards, Dieter

[SiliconWizard]

I think simulation is important as a "unit test" in order to verify components of a larger solution. Nobody working in a team should hand out a component without verifying it by simulation. Besides that a simulation makes a redundant description of the component interface, a usage example. The other person can see what has been tested.

Agreed. Be aware that simulation (unless you're gonna use very fancy simulators out of reach for hobbyists) will not be able to simulate clock domain crossing issues, and these are the ones that are particularly hard to debug unless you are already fully aware of them. As an example, someone who will implement UARTs which are inherently clock domain crossing designs, even if they look simple on the surface, will bang their head on their bench if they haven't thought of this problem, and no simulation will save them here.

So while simulation is a requirement IMO for anything that is not trivial, it will never replace real hardware testing.

Actually implementing a fully correct UART on FPGA (managing clock domain crossing properly) is not something I would ask a complete beginner to do - the chances they'll come up with something correct are neari 0.

[ve7xen]

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.

[rfspezi]

Now that you - the experienced FPGA developers - know about the project details, what would you recommend to choose as:

A) Manufacturer      (cheap!)
B) Simulation tool   (free!)

Or should i better ask for a ranking of possible candidates?