Low budget FPGA needed - Page 1
Forum section: electronics / general

author: rfspezi
author_rank: Regular Contributor
timestamp: August 15, 2023, 03:34:32 pm
content: 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?

author: ataradov
author_rank: Super Contributor
timestamp: August 15, 2023, 03:47:55 pm
content: 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.

author: langwadt
author_rank: Super Contributor
timestamp: August 15, 2023, 04:01:12 pm
content: one-of or production?

author: rfspezi
author_rank: Regular Contributor
timestamp: August 15, 2023, 04:29:02 pm
content: When released for production, it should be in the range of 5.000 pcs/a.

author: dietert1
author_rank: Super Contributor
timestamp: August 15, 2023, 05:01:12 pm
content: 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

author: gnuarm
author_rank: Super Contributor
timestamp: August 15, 2023, 06:02:42 pm
content: Quote from: rfspezi on August 15, 2023, 03:34:32 pmPersonally, 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.QuoteI 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!QuoteMCU/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.

author: rfspezi
author_rank: Regular Contributor
timestamp: August 15, 2023, 08:08:36 pm
content: Quote from: gnuarm on August 15, 2023, 06:02:42 pmYou 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?

author: gnuarm
author_rank: Super Contributor
timestamp: August 15, 2023, 08:31:38 pm
content: Quote from: rfspezi on August 15, 2023, 08:08:36 pmI 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?

author: langwadt
author_rank: Super Contributor
timestamp: August 15, 2023, 08:35:15 pm
content: Quote from: gnuarm on August 15, 2023, 06:02:42 pmsure, 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

author: Scrts
author_rank: Frequent Contributor
timestamp: August 15, 2023, 08:42:29 pm
content: 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.

author: rfspezi
author_rank: Regular Contributor
timestamp: August 15, 2023, 08:45:52 pm
content: Quote from: gnuarm on August 15, 2023, 08:31:38 pmDetecting/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.

author: gnuarm
author_rank: Super Contributor
timestamp: August 15, 2023, 09:56:20 pm
content: Quote from: langwadt on August 15, 2023, 08:35:15 pmNot 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.

author: gnuarm
author_rank: Super Contributor
timestamp: August 15, 2023, 09:58:14 pm
content: Quote from: Scrts on August 15, 2023, 08:42:29 pmYes, 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.

author: gnuarm
author_rank: Super Contributor
timestamp: August 15, 2023, 10:03:03 pm
content: Quote from: rfspezi on August 15, 2023, 08:45:52 pmI'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.

author: langwadt
author_rank: Super Contributor
timestamp: August 15, 2023, 10:03:21 pm
content: Quote from: gnuarm on August 15, 2023, 09:56:20 pmonly free if it will fit

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 15, 2023, 10:19:04 pm
content: Quote from: Scrts on August 15, 2023, 08:42:29 pmYes. 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.

author: gnuarm
author_rank: Super Contributor
timestamp: August 15, 2023, 10:30:33 pm
content: Quote from: langwadt on August 15, 2023, 10:03:21 pmExactly! Same as in an MCU!

author: gnuarm
author_rank: Super Contributor
timestamp: August 15, 2023, 10:32:01 pm
content: Quote from: SiliconWizard on August 15, 2023, 10:19:04 pmTwo 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???

author: langwadt
author_rank: Super Contributor
timestamp: August 15, 2023, 11:03:15 pm
content: Quote from: gnuarm on August 15, 2023, 10:30:33 pman fpga is a very expensive way to buy memory to run code from

author: dietert1
author_rank: Super Contributor
timestamp: August 15, 2023, 11:15:44 pm
content: 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

author: gnuarm
author_rank: Super Contributor
timestamp: August 15, 2023, 11:27:48 pm
content: Quote from: langwadt on August 15, 2023, 11:03:15 pmYou are making all sorts of assumptions. No point in continuing this further.

author: gnuarm
author_rank: Super Contributor
timestamp: August 15, 2023, 11:30:39 pm
content: Quote from: dietert1 on August 15, 2023, 11:15:44 pmIt'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.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: August 15, 2023, 11:35:25 pm
content: Quote from: dietert1 on August 15, 2023, 11:15:44 pmBecause 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

author: gnuarm
author_rank: Super Contributor
timestamp: August 16, 2023, 12:15:48 am
content: Quote from: mikeselectricstuff on August 15, 2023, 11:35:25 pmIn 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???

author: asmi
author_rank: Super Contributor
timestamp: August 16, 2023, 12:53:00 am
content: Quote from: mikeselectricstuff on August 15, 2023, 11:35:25 pmI 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.Quote from: mikeselectricstuff on August 15, 2023, 11:35:25 pmThe 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.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: August 16, 2023, 03:19:11 am
content: Quote from: rfspezi on August 15, 2023, 03:34:32 pmSo 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 knowwhenit 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 ?

author: PCB.Wiz
author_rank: Super Contributor
timestamp: August 16, 2023, 03:44:53 am
content: Quote from: rfspezi on August 15, 2023, 04:29:02 pmWhat packages can you manage in production, or will you look for a module ?

author: dietert1
author_rank: Super Contributor
timestamp: August 16, 2023, 06:31:42 am
content: Quote from: gnuarm on August 16, 2023, 12:15:48 amFor 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

author: gnuarm
author_rank: Super Contributor
timestamp: August 16, 2023, 07:29:47 am
content: Quote from: dietert1 on August 16, 2023, 06:31:42 amDifferent 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.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: August 16, 2023, 08:39:14 am
content: Quote from: gnuarm on August 16, 2023, 12:15:48 amWhich 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 startedQuoteBecause 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.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: August 16, 2023, 08:43:05 am
content: Quote from: asmi on August 16, 2023, 12:53:00 amAt 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?

author: gnuarm
author_rank: Super Contributor
timestamp: August 16, 2023, 09:03:36 am
content: Quote from: mikeselectricstuff on August 16, 2023, 08:39:14 amWhich 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.QuoteWhat 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.QuoteThat's a very interesting "IF".QuoteExactly! 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.

author: rfspezi
author_rank: Regular Contributor
timestamp: August 16, 2023, 09:08:01 am
content: Quote from: PCB.Wiz on August 16, 2023, 03:19:11 amEach 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.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: August 16, 2023, 09:21:49 am
content: Quote from: gnuarm on August 16, 2023, 09:03:36 amExcept 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.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: August 16, 2023, 09:35:00 am
content: Quote from: gnuarm on August 16, 2023, 09:03:36 amI'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,unpredictableproportion 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.

author: langwadt
author_rank: Super Contributor
timestamp: August 16, 2023, 09:40:52 am
content: Quote from: rfspezi on August 16, 2023, 09:08:01 amis it the same clock for all channels? or do they each have a seperate asynchronous clock?

author: rfspezi
author_rank: Regular Contributor
timestamp: August 16, 2023, 10:27:01 am
content: Quote from: langwadt on August 16, 2023, 09:40:52 amSame 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.

author: langwadt
author_rank: Super Contributor
timestamp: August 16, 2023, 10:48:50 am
content: Quote from: rfspezi on August 16, 2023, 10:27:01 amif 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.

author: rfspezi
author_rank: Regular Contributor
timestamp: August 16, 2023, 10:59:31 am
content: Quote from: langwadt on August 16, 2023, 10:48:50 amYou'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.

author: gnuarm
author_rank: Super Contributor
timestamp: August 16, 2023, 01:08:51 pm
content: Quote from: mikeselectricstuff on August 16, 2023, 09:21:49 amWhat 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.

author: gnuarm
author_rank: Super Contributor
timestamp: August 16, 2023, 01:40:55 pm
content: Quote from: mikeselectricstuff on August 16, 2023, 09:35:00 amNot 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.QuoteA 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.QuoteI 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.QuoteBut 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.

author: gnuarm
author_rank: Super Contributor
timestamp: August 16, 2023, 01:42:30 pm
content: Quote from: rfspezi on August 16, 2023, 10:59:31 amI see no reason why a CRC will help with this. The CRC only checks for bit errors. It has nothing to do with alignment.

author: dietert1
author_rank: Super Contributor
timestamp: August 16, 2023, 02:03:42 pm
content: 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 anywayRegards, Dieter

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: August 16, 2023, 03:40:07 pm
content: Quote from: gnuarm on August 16, 2023, 01:42:30 pmOf 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.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: August 16, 2023, 03:42:18 pm
content: Quote from: gnuarm on August 16, 2023, 01:40:55 pmI 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.QuoteMaybe 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.

author: nctnico
author_rank: Super Contributor
timestamp: August 16, 2023, 03:56:17 pm
content: Quote from: mikeselectricstuff on August 16, 2023, 09:21:49 amThe 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.

author: dietert1
author_rank: Super Contributor
timestamp: August 16, 2023, 04:33:23 pm
content: 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

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 16, 2023, 08:59:58 pm
content: Quote from: dietert1 on August 16, 2023, 04:33:23 pmAgreed. 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.

author: ve7xen
author_rank: Super Contributor
timestamp: August 16, 2023, 09:19:04 pm
content: 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.

author: rfspezi
author_rank: Regular Contributor
timestamp: August 16, 2023, 10:36:44 pm
content: 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?

author: ataradov
author_rank: Super Contributor
timestamp: August 16, 2023, 10:43:22 pm
content: 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.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: August 17, 2023, 12:35:16 am
content: Quote from: rfspezi on August 16, 2023, 10:59:31 amSo youdohave 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 saySame 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 ?Quote from: rfspezi on August 16, 2023, 09:08:01 amDo you have control of the 200 bits, or is that 3rd party ?Of course, you may not need a FPGA at all1MBps 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.IfSame clock for each channelmeans those signals are phase aligned, life gets simpler as a single clock wait/start works on 4+ sync channels.

author: gnuarm
author_rank: Super Contributor
timestamp: August 17, 2023, 02:05:24 am
content: Quote from: mikeselectricstuff on August 16, 2023, 03:40:07 pmOk, problem solved. We can move onto the next problem.

author: gnuarm
author_rank: Super Contributor
timestamp: August 17, 2023, 02:07:06 am
content: Quote from: mikeselectricstuff on August 16, 2023, 03:42:18 pmI'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.

author: gnuarm
author_rank: Super Contributor
timestamp: August 17, 2023, 02:09:16 am
content: Quote from: ve7xen on August 16, 2023, 09:19:04 pmYes, 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.

author: asmi
author_rank: Super Contributor
timestamp: August 17, 2023, 02:36:46 am
content: Quote from: dietert1 on August 16, 2023, 06:31:42 amBoth 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.

author: gnuarm
author_rank: Super Contributor
timestamp: August 17, 2023, 02:41:18 am
content: Quote from: asmi on August 17, 2023, 02:36:46 amI 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.

author: asmi
author_rank: Super Contributor
timestamp: August 17, 2023, 02:43:17 am
content: Quote from: mikeselectricstuff on August 16, 2023, 08:43:05 amWell 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.Quote from: mikeselectricstuff on August 16, 2023, 08:43:05 amMost 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).

author: asmi
author_rank: Super Contributor
timestamp: August 17, 2023, 02:46:19 am
content: Quote from: gnuarm on August 17, 2023, 02:41:18 amYes 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.

author: gnuarm
author_rank: Super Contributor
timestamp: August 17, 2023, 04:06:09 am
content: Quote from: asmi on August 17, 2023, 02:46:19 amThen, 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?

author: rfspezi
author_rank: Regular Contributor
timestamp: August 17, 2023, 11:15:16 am
content: Quote from: PCB.Wiz on August 17, 2023, 12:35:16 amThe first 32bits are the sync-pattern.Quote from: PCB.Wiz on August 17, 2023, 12:35:16 amNo 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.Quote from: PCB.Wiz on August 17, 2023, 12:35:16 amI 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.Quote from: PCB.Wiz on August 17, 2023, 12:35:16 amGot total control over the bitsream source.Quote from: PCB.Wiz on August 17, 2023, 12:35:16 amThank you for the hint!This one sounds really interesting.Quote from: PCB.Wiz on August 17, 2023, 12:35:16 amNot quite... as mentioned before with a 2x oversampling i don't need a synced local clock.Quote from: PCB.Wiz on August 17, 2023, 12:35:16 amSame clock-speed but not phase-aligned.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: August 17, 2023, 11:33:49 am
content: Quote from: rfspezi on August 17, 2023, 11:15:16 amI 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

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: August 17, 2023, 11:35:24 am
content: Quote from: rfspezi on August 17, 2023, 11:15:16 amIn which case could you simply use an initial rising edge and timeout to do the framing?

author: gnuarm
author_rank: Super Contributor
timestamp: August 17, 2023, 02:46:45 pm
content: Quote from: rfspezi on August 17, 2023, 11:15:16 amI 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.Quote from: rfspezi on August 17, 2023, 11:15:16 amThe 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.Quote from: rfspezi on August 17, 2023, 11:15:16 amThis gets better all the time.

author: gnuarm
author_rank: Super Contributor
timestamp: August 17, 2023, 02:49:33 pm
content: Quote from: mikeselectricstuff on August 17, 2023, 11:33:49 amMetastability 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.

author: fourfathom
author_rank: Super Contributor
timestamp: August 17, 2023, 03:46:11 pm
content: Quote from: gnuarm on August 17, 2023, 02:46:45 pmYes. 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.

author: gnuarm
author_rank: Super Contributor
timestamp: August 17, 2023, 03:53:58 pm
content: Quote from: fourfathom on August 17, 2023, 03:46:11 pmYes, I described the digital PLL I had implemented, which is what you are recommending be used here.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: August 17, 2023, 03:55:06 pm
content: QuoteSeems 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.

author: langwadt
author_rank: Super Contributor
timestamp: August 17, 2023, 05:18:38 pm
content: Quote from: gnuarm on August 17, 2023, 04:06:09 amthat if you are pushing utilization and/or performance adding a connection might make it impossible to meet timing ...

author: langwadt
author_rank: Super Contributor
timestamp: August 17, 2023, 05:25:29 pm
content: Quote from: rfspezi on August 17, 2023, 11:15:16 amasync 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

author: PCB.Wiz
author_rank: Super Contributor
timestamp: August 17, 2023, 08:00:54 pm
content: Quote from: rfspezi on August 17, 2023, 11:15:16 amI'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 Ithinkthe 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.

author: rfspezi
author_rank: Regular Contributor
timestamp: August 17, 2023, 08:13:07 pm
content: Quote from: langwadt on August 17, 2023, 05:25:29 pmI 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 CRC3x oversampling could be used for redundancy/sanity check.However it adds unnecessary cost.

author: langwadt
author_rank: Super Contributor
timestamp: August 17, 2023, 08:28:53 pm
content: Quote from: rfspezi on August 17, 2023, 08:13:07 pmonly ones of those that does anything is crc and that is by discarding whole framesQuote from: rfspezi on August 17, 2023, 08:13:07 pmit'll also be far better because it'll give you 1/3 bit of margin for drift instead of effectively zero

author: rfspezi
author_rank: Regular Contributor
timestamp: August 17, 2023, 08:54:45 pm
content: Quote from: langwadt on August 17, 2023, 08:28:53 pmImagine 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.--> DONEEven 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.

author: langwadt
author_rank: Super Contributor
timestamp: August 17, 2023, 09:06:58 pm
content: Quote from: rfspezi on August 17, 2023, 08:54:45 pmbut 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 datastreamyour 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

author: rfspezi
author_rank: Regular Contributor
timestamp: August 17, 2023, 09:22:48 pm
content: Quote from: langwadt on August 17, 2023, 09:06:58 pmI am not sure if the complexity is worth it since the streams are buffered and analyzed in an companion cpu anyway.I want to keep the FPGA complexity as low as possible beeing able to use a really cheap one.

author: langwadt
author_rank: Super Contributor
timestamp: August 17, 2023, 09:49:23 pm
content: Quote from: rfspezi on August 17, 2023, 09:22:48 pmbeginning to sound more and more like an XY problemdo you actually have 16 separate streams or is just 16 phase shifted copies of the same stream and 16 comparators is your attempt at finding the right one?so you really just need to sync and extract the data from a single stream?

author: PCB.Wiz
author_rank: Super Contributor
timestamp: August 17, 2023, 11:16:21 pm
content: Quote from: rfspezi on August 17, 2023, 09:22:48 pmAn extreme version of that approach, would be to use a couple of jelly bean MCU's to do parallel to serial capture, at 2Msps -> 16 MHz SPI for 8 wide sample. Plenty can manage that.You might even find a better one that can do 2Msps x 16b -> 32MHz SPI, if you companion cpu manages 32MHz SPI ?Then all your 'buffered and analyzed' is moved to your companion cpu - more CPU resource needed, but super cheap and simple capture.

author: gnuarm
author_rank: Super Contributor
timestamp: August 18, 2023, 12:03:51 am
content: Quote from: langwadt on August 17, 2023, 05:18:38 pmOk, you win the "Raising Virtually Impossibly Unlikely Problems" award.

author: fourfathom
author_rank: Super Contributor
timestamp: August 18, 2023, 12:04:04 am
content: Quote from: rfspezi on August 17, 2023, 08:13:07 pmNo, 2X sampling will not be reliable, unless you are willing to discard bad-CRC frames. There will be a one clock-period ambiguity in the detection of the input transition, so where do you put the sample-point? It could end up anywhere between the data mid-point and on top of the next data transition.Clock drift (and jitter) *always* matter, there is no escaping this fact. And not just the receive clock, there's also the transmit clock and noise on the data signal. All of these add to the sampling uncertainty.I'm seeing lots of complicated suggestions, just to avoid using a faster sampling clock. A 32X clock doesn't mean a 32X increase in gatecount. You have a little more complexity at the input (but not much), and some extra circuitry for the clock-enable controls, but the final result is likely to be simpler.Yes, you could probably do this is a uController, but this job would be easy in a small to medium low-cost FPGA. And 32 MHz is *not* fast for a modern FPGA. With 16 inputs of 1Mbit/s I would be tempted to run the internal clock at 64 MHz, letting me have a single datapath, and shared resources for the 16 channels. If I thought about it more I could probably reduce the clock rate and still have a single shared datapath... But 64 MHz is still easy.

author: dietert1
author_rank: Super Contributor
timestamp: August 18, 2023, 05:38:46 am
content: For asynchronous input most people use a digital low pass filter to avoid metastability and noise issues. This filter uses oversampling. Oversampling ratio can be configurable. Clock recovery also needs oversampling. Clock recovery means initial determination and then tracking of incoming data clock phase.If the OP wants to determine initial clock phase by sync pattern matching: In order to guarantee some phase margin, one needs more than one match. If one finds 3x consecutive pattern matches one can select the middle one. A modern FPGA also implements 48 bit or 64 bit shift registers.Regards, Dieter

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: August 18, 2023, 09:44:40 am
content: Quote from: rfspezi on August 17, 2023, 08:13:07 pmI doubt it would add any noticeable cost as you have plenty of bandwidth for a 1Mbit stream, and may actually end up smaller/simpler as it's easier to determine framing if you have more samples to play with.

author: Canis Dirus Leidy
author_rank: Regular Contributor
timestamp: September 06, 2023, 08:03:26 pm
content: Quote from: ataradov on August 16, 2023, 10:43:22 pmGHDL. Good enough if gate-level simulation isn't required and vendor (or propiertary) IP blocks aren't used. Plus it can be used for syntax checking by editors like Emacs.1. Well, there is example ofusing it with Xilinx Unisym library, but I have not come across detailed descriptions and manuals.

author: bywqdq
author_rank: Contributor
timestamp: November 14, 2023, 02:52:10 am
content: AG1K, which is cheap in China, only costs about $1

author: up8051
author_rank: Frequent Contributor
timestamp: November 16, 2023, 08:47:47 am
content: Quote from: bywqdq on November 14, 2023, 02:52:10 amMore interesting is AGM AG6K SoC but where to by it?BR JarekC

author: colorado.rob
author_rank: Frequent Contributor
timestamp: November 16, 2023, 09:03:13 pm
content: Quote from: bywqdq on November 14, 2023, 02:52:10 amWhere can these be found outside of China?