Low budget FPGA needed

[rfspezi]

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.

Since i am new to VHDL programing, i can only guess that the FPGA will need roughly 1500 macrocells???

Can anybody recommend a FPGA brand which is known to have really affordable devices?


P.S.: Since i also plan to use an STM32 MCU, maybe there are solutions available which combine an MCU and FPGA in one device and thus come cheaper?

[ataradov]

Lattice devices are always on the cheaper side and generally are available from regular distributors.

It is hard to predict exact resource allocation, since FPGA structure varies and comparing "macrocells" is mostly not helpful. But this does not seem like a hard project to prototype and see how much it actually takes.

Gowin has FPGAs with Cortex-M3 MCU core, but their availability was terrible and I don't know where you would even buy them today.

[langwadt]

one-of or production?

[rfspezi]

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

[dietert1]

For somebody new to HDL and FPGA one would recommend one of the usual Digilent learning boards. The modern ones include a JTAG and can be used with a free IDE. Another one i used is Lattice "MachXO2 7000HE Breakout Board".
Once you have your design working, you can still select the part. Your project doesn't seem to require special predefined hardware blocks like RAM, DSP or the like, so it will be easy to port to the selected part.

Regards, Dieter

[gnuarm]

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.

Since i am new to VHDL programing, i can only guess that the FPGA will need roughly 1500 macrocells???

Personally, I think your design should not focus on the 32 bit size of the data, making everything 32 bits wide.  Instead, the data source needs to be 32 bits wide and everything else just 1 bit.  Once you find the first bit, you can start your compares and spit out a result every 32 bits.  No need to receive a 32 bit result or to have a 32 bit comparator. 

So, you need to address the source 32 bits of data, have a 1 bit comparator and logic to count off 32 bits and do whatever you need with the result on the 32nd bit.

Can anybody recommend a FPGA brand which is known to have really affordable devices?

I am starting a new design where component availability is paramount.  I ended up with an Efinix part.  They are very affordable and readily available.  Gowin is the name that often comes up, but they are basically a Chinese company and this shows in the docs.  When I was trying to learn about the Gowin math units, it might as well have been in Greek! 

P.S.: Since i also plan to use an STM32 MCU, maybe there are solutions available which combine an MCU and FPGA in one device and thus come cheaper?

MCU/FPGA combo tends to be pretty pricey.  It's often easier and certainly cheaper to roll your own CPU in the FPGA.  It can run pretty fact in terms of real speed (most MCUs running from Flash have to use cache to get over 20 MIPS). 

If you have not designed your own CPU before, it's probably a bit daunting, but doable.

[rfspezi]

Personally, I think your design should not focus on the 32 bit size of the data, making everything 32 bits wide.  Instead, the data source needs to be 32 bits wide and everything else just 1 bit.  Once you find the first bit, you can start your compares and spit out a result every 32 bits.  No need to receive a 32 bit result or to have a 32 bit comparator. 

So, you need to address the source 32 bits of data, have a 1 bit comparator and logic to count off 32 bits and do whatever you need with the result on the 32nd bit.

You mean like.... starting to compare each incoming bit with a reference pattern and counting up until it counted/matched 32 bits or otherwise reseting the counter and restart every time a mismatch happens?

[gnuarm]

Personally, I think your design should not focus on the 32 bit size of the data, making everything 32 bits wide.  Instead, the data source needs to be 32 bits wide and everything else just 1 bit.  Once you find the first bit, you can start your compares and spit out a result every 32 bits.  No need to receive a 32 bit result or to have a 32 bit comparator. 

So, you need to address the source 32 bits of data, have a 1 bit comparator and logic to count off 32 bits and do whatever you need with the result on the 32nd bit.

You mean like.... starting to compare each incoming bit with a reference pattern and counting up until it counted/matched 32 bits or otherwise reseting the counter and restart every time a mismatch happens?

I can't tell you what to do when you find a mismatch.  That depends on  your requirements.  I don't know what this circuit is doing.  I guess I made an assumption, that because you didn't say anything about framing the data, that was already handled.

My point is simply, that because you are only handed one bit at a time, you can just do the comparison one bit at a time and save on the registers, etc.  This can be a very small design, using a very, very small FPGA.

But if you are searching for a data pattern, then maybe you do need 32 bit registers and do a full 32 bit compare on each new data bit.  What do your requirements say?

[langwadt]

MCU/FPGA combo tends to be pretty pricey.  It's often easier and certainly cheaper to roll your own CPU in the FPGA.  It can run pretty fact in terms of real speed (most MCUs running from Flash have to use cache to get over 20 MIPS). 

If you have not designed your own CPU before, it's probably a bit daunting, but doable.

sure, as long as you can live with very basic code/debug tools compared to an MCU and need very limited memory because memory in an FPGA is orders of magnitude more expensive than memory in an MCU

[Scrts]

I'd recommend downloading a synthesis tool for more common suppliers (Lattice, Intel, AMD) and trying to implement it on the smallest FPGA - see if your design fits. This is a zero cost estimation. From there, you can see which FPGA would be the cheapest that fits your design.

[rfspezi]

But if you are searching for a data pattern, then maybe you do need 32 bit registers and do a full 32 bit compare on each new data bit.  What do your requirements say?

Detecting/synchronizing on a synch-pattern match is exactly what i need.
So i will not come around a 32 bit comparator and check each time a new bit arrives.

[gnuarm]

MCU/FPGA combo tends to be pretty pricey.  It's often easier and certainly cheaper to roll your own CPU in the FPGA.  It can run pretty fact in terms of real speed (most MCUs running from Flash have to use cache to get over 20 MIPS). 

If you have not designed your own CPU before, it's probably a bit daunting, but doable.

sure, as long as you can live with very basic code/debug tools compared to an MCU and need very limited memory because memory in an FPGA is orders of magnitude more expensive than memory in an MCU

Not sure what you are trying to say.  You can use preexisting designs that have full support from all manner of tools.  Once you have an FPGA on your board, everything in it is free. 

[gnuarm]

I'd recommend downloading a synthesis tool for more common suppliers (Lattice, Intel, AMD) and trying to implement it on the smallest FPGA - see if your design fits. This is a zero cost estimation. From there, you can see which FPGA would be the cheapest that fits your design.

Yes, I agree 100%.  Simulations are both powerful and easy with FPGAs and HDL.  There is very little reason to work with hardware until the firmware is working as well as possible in simulation.

[gnuarm]

But if you are searching for a data pattern, then maybe you do need 32 bit registers and do a full 32 bit compare on each new data bit.  What do your requirements say?

Detecting/synchronizing on a synch-pattern match is exactly what i need.
So i will not come around a 32 bit comparator and check each time a new bit arrives.

I'm not sure I understand.  If you are trying to detect the synch pattern, it will lock in as quickly as possible by using a 32 bit shift register and 32 bits of comparator. 

You can get away with comparing one bit at a time, but you need to restart the hunt in a methodical way to assure you have checked each of the 32 alignments.  If you don't do that, there will be data patterns that cause the hunt to start on some, but not all possible alignments.  So, compare one bit at a time, but always check the full 32 bits, if no match, skip one more before starting the next hunt.

[langwadt]

MCU/FPGA combo tends to be pretty pricey.  It's often easier and certainly cheaper to roll your own CPU in the FPGA.  It can run pretty fact in terms of real speed (most MCUs running from Flash have to use cache to get over 20 MIPS). 

If you have not designed your own CPU before, it's probably a bit daunting, but doable.

sure, as long as you can live with very basic code/debug tools compared to an MCU and need very limited memory because memory in an FPGA is orders of magnitude more expensive than memory in an MCU

Not sure what you are trying to say.  You can use preexisting designs that have full support from all manner of tools.  Once you have an FPGA on your board, everything in it is free.

only free if it will fit

[SiliconWizard]

I'd recommend downloading a synthesis tool for more common suppliers (Lattice, Intel, AMD) and trying to implement it on the smallest FPGA - see if your design fits. This is a zero cost estimation. From there, you can see which FPGA would be the cheapest that fits your design.

Yes. But given that the OP said they were new to VHDL itself, I'm not sure picking some FPGA right off the bat makes a lot of sense. One step at a time. So as some others have said, I'd recommend buying a dev board with an entry-level FPGA, and gain enough knowledge from there to move on to the next step.

[gnuarm]

MCU/FPGA combo tends to be pretty pricey.  It's often easier and certainly cheaper to roll your own CPU in the FPGA.  It can run pretty fact in terms of real speed (most MCUs running from Flash have to use cache to get over 20 MIPS). 

If you have not designed your own CPU before, it's probably a bit daunting, but doable.

sure, as long as you can live with very basic code/debug tools compared to an MCU and need very limited memory because memory in an FPGA is orders of magnitude more expensive than memory in an MCU

Not sure what you are trying to say.  You can use preexisting designs that have full support from all manner of tools.  Once you have an FPGA on your board, everything in it is free.

only free if it will fit

Exactly!  Same as in an MCU!

[gnuarm]

I'd recommend downloading a synthesis tool for more common suppliers (Lattice, Intel, AMD) and trying to implement it on the smallest FPGA - see if your design fits. This is a zero cost estimation. From there, you can see which FPGA would be the cheapest that fits your design.

Yes. But given that the OP said they were new to VHDL itself, I'm not sure picking some FPGA right off the bat makes a lot of sense. One step at a time. So as some others have said, I'd recommend buying a dev board with an entry-level FPGA, and gain enough knowledge from there to move on to the next step.

Two reasons to not buy any hardware, to start.

1)  Why mess with a device you aren't going to use in your design???

2)  Why mess with hardware at all until you have completed all the simulations???

[langwadt]

MCU/FPGA combo tends to be pretty pricey.  It's often easier and certainly cheaper to roll your own CPU in the FPGA.  It can run pretty fact in terms of real speed (most MCUs running from Flash have to use cache to get over 20 MIPS). 

If you have not designed your own CPU before, it's probably a bit daunting, but doable.

sure, as long as you can live with very basic code/debug tools compared to an MCU and need very limited memory because memory in an FPGA is orders of magnitude more expensive than memory in an MCU

Not sure what you are trying to say.  You can use preexisting designs that have full support from all manner of tools.  Once you have an FPGA on your board, everything in it is free.

only free if it will fit

Exactly!  Same as in an MCU!

an fpga is a very expensive way to buy memory to run code from

[dietert1]

Why mess with hardware at all until you have completed all the simulations???

For a beginner learning how to run and test his design on hardware is invaluable and more important than learning how to verify complex designs by simulation. He will start with meaningless designs anyway, like the usual LED blinking or the 7 segment display many of the Digilent boards include.

Regards, Dieter

[gnuarm]

MCU/FPGA combo tends to be pretty pricey.  It's often easier and certainly cheaper to roll your own CPU in the FPGA.  It can run pretty fact in terms of real speed (most MCUs running from Flash have to use cache to get over 20 MIPS). 

If you have not designed your own CPU before, it's probably a bit daunting, but doable.

sure, as long as you can live with very basic code/debug tools compared to an MCU and need very limited memory because memory in an FPGA is orders of magnitude more expensive than memory in an MCU

Not sure what you are trying to say.  You can use preexisting designs that have full support from all manner of tools.  Once you have an FPGA on your board, everything in it is free.

only free if it will fit

Exactly!  Same as in an MCU!

an fpga is a very expensive way to buy memory to run code from

You are making all sorts of assumptions.  No point in continuing this further.

[gnuarm]

Why mess with hardware at all until you have completed all the simulations???

For a beginner learning how to run and test his design on hardware is invaluable and more important than learning how to verify complex designs by simulation. He will start with meaningless designs anyway, like the usual LED blinking or the 7 segment display many of the Digilent boards include.

Regards, Dieter

It's just the opposite.  There's no need at all to mess with all the ugly details of trying to get even an LED flasher to blink, until you have some idea of how to write code.   The LED flasher is specifically to make you write all but no code, so you can learn all the ugliness of getting something loaded into a board.  Then you need to learn that all over again when you use a board with the actual chip you want to use. 

Skip the mess, learn to program, then worry with your hardware. 

[mikeselectricstuff]

Why mess with hardware at all until you have completed all the simulations???

Because it may be quicker to get some hardware running with the actual thing  you want to interface to, than generate simulations for said thing.
Because some people just prefer to tinker around with real signals on a real scope as a way to get familiar with something new
 

[gnuarm]

Why mess with hardware at all until you have completed all the simulations???

Because it may be quicker to get some hardware running with the actual thing  you want to interface to, than generate simulations for said thing.
Because some people just prefer to tinker around with real signals on a real scope as a way to get familiar with something new

In this case, there is no hardware.  The boards discussed use just two of the many, many FPGAs available.   Heck, I've seen experienced FPGA designers not be able to get a board loaded the first time.  In fact, I was working at a sizeable company making military radios and was asked to come to the lab to assist in bringing up the FPGA on the board I designed.  I had not picked the FPGA or anything else, other than design the board it was on.   

When I arrived, they had two FPGA guys (one a consultant), two managers and a newbie at the bench.  I figured, since I had been specifically requested, I would offer my advice.  I tried asking a few questions as to what they had tried (they were programming by a simple bit bang on a Xilinx part).  I then pointed out the few parts that had to be right, CCLK present, check!  Well, I can't run down the list from memory, but it includes checking for the one or two handshakes and sending a few extra clocks at the end of the file to get the state machine out of configuration mode.  All, very clearly explained in the documentation. 

They said they had done each of those steps.  They had even sent 64k extra CCLK pulses.  Then it hit me.  Not one person at the bench understood that you had to do ALL THESE THINGS TOGETHER to make it work.  I pointed that out and you could see the light bulbs coming on.  The guy working as an FPGA manager had been a Xilinx FAE for Christ's sake!!!

So, now it was loading, the LED was blinking and I walked off.  Later my manager asked me why I left, as if it was my job to hold their hand every inch of the way!!!

My point is, getting the hardware to work is not as simple as people will tell you, at least, not always.  There are lots of small details to go from a  compiled and simulated design to actually getting the chip loaded and running.  I much prefer to work in the software domain where I can see, not just the wire to the LED by touching it with the scope probe, but every signal in the chip, LITERALLY EVERY ONE, simply by viewing it in the simulation!!!  The simulation will also show all manner of invalid states and transitions, things that are very, very hard to see with a scope.   

Why would anyone think bench testing is easier???

[asmi]

Because it may be quicker to get some hardware running with the actual thing  you want to interface to, than generate simulations for said thing.

I don't know what kind of peripherals you are working with, but in my experience this has NEVER been the case. Heck, I couldn't even get a simple AXI4-light PWM controller for LEDs to work right without sims.

Because some people just prefer to tinker around with real signals on a real scope as a way to get familiar with something new

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.